> ## Documentation Index > Fetch the complete documentation index at: https://documentation.qonversion.io/llms.txt > Use this file to discover all available pages before exploring further. # How Qonversion handles subscription infrastructure > What the SDKs, purchase validation, entitlements and analytics do underneath every other Qonversion product, which mode to pick, and how the revenue numbers line up with what the stores report. Every other thing in these docs stands on one layer: purchases collected by the SDK, confirmed with the store, turned into entitlements and into revenue numbers you can line up against App Store Connect and Google Play Console. Get this right once and campaigns, experiments and agents all read the same truth. ## What the layer does * **Collects purchases** on iOS, Android, Flutter, React Native, Unity, Cordova, Capacitor and Web, plus macOS Catalyst, watchOS and visionOS. *(In Subscription Management Mode. In Analytics Mode your own code makes the purchase and Qonversion observes it: automatically on iOS with StoreKit 1, through a sync call your code adds on Android and with StoreKit 2.)* * **Confirms them with the store** — the purchase is checked against Apple or Google on our server instead of being trusted from the device. Web purchases go through Stripe or Paddle instead, see [Stripe](/docs/stripe-integration) and [Paddle](/docs/paddle-integration). * **Resolves entitlements** — one answer to "is this user premium right now", the same answer on every device the user signs in to. *(Subscription Management Mode; in Analytics Mode entitlements stay with your own backend.)* * **Keeps the history** — trials, conversions, renewals, cancellations, refunds, upgrades and downgrades, as events you can query, export or forward. *(Both modes.)* * **Feeds everything else** — the analytics dashboard, cohorts, raw data export, webhooks, integrations, Apple Ads reporting, experiment results. *(Both modes.)* ## Which mode to choose | | Analytics Mode | Subscription Management Mode | | - | - | - | | **Your purchase code** | stays yours | Qonversion makes purchases and resolves entitlements | | **Setup work** | connect your stores, install the SDK, add purchase syncing where required | connect your stores, configure products and entitlements, integrate purchases, restores and access checks | | **Entitlement check** | your backend | `checkEntitlements()` | | **Analytics, integrations, webhooks, Apple Ads attribution, raw data export, experiments** | yes | yes | Subscription Management Mode includes everything Analytics Mode does; feature availability depends on your plan. If subscriptions already work in your app and you are not ready to touch that flow, start in Analytics Mode — see [How Qonversion works](/docs/how-qonversion-works). ## Why the numbers line up * Purchases are confirmed with the store, not inferred from client events. * Store server notifications, once you set them up, carry renewals and refunds that happen outside the app straight to Qonversion. Without them, subscription updates arrive later, and entitlements, analytics, integrations and webhooks can lag behind the store; App Store notifications are recommended for every app in production — [App Store notifications](/docs/ios-s2s-notifications), [Google Play notifications](/docs/google-developer-notifications). * Data lands as soon as the store reports it, and the store is the one setting that pace: some events arrive within seconds, some after the store's own delay. * Revenue analytics reports both **Sales**, before the store's commission, and **Proceeds**, after it. See [Revenue](/docs/revenue). * If something does not line up, the raw events are yours to check: [Raw data export](/docs/raw-data-reports). ## When something fails Qonversion runs Aegis, a standby service on Cloudflare's edge that answers like the main API from prepared caches during an outage and replays queued requests afterwards. Separately, the SDK can work from a **fallback file**: you download it from the dashboard and add it to your project by hand — it is not shipped inside the SDK, it has a supported-version floor per platform, and its filename must not be changed. Both mechanisms, the placement rules and the version table: [System reliability](/docs/system-reliability). ## Next steps Choose a mode, create a project, install the SDK, make a purchase. Per-platform install and configuration. Define what a purchase unlocks, and check it at runtime. Revenue, trials, subscriptions, cohorts and monitoring. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.