In-app purchases.
Store products and server verification.

01The store products

A product is an item you create in each store with a product id and a price. The app sells the ids you enter in the console; prices are set in the stores, never in the code.

The example plan sells only monthly and yearly; weekly and lifetime are empty until you add ids. Click paths for creating the products: Google Play Console, App Store Connect. A free trial, if you want one, is an introductory offer on the store product; the plan's trial days only change the text in the app.

02Everything is configured by you

Purchases are entirely buyer-configured. Nothing of the author is in the code:

• Product ids: the defaults above (pro_monthly, remove_ads, credits_small, …) are plain placeholder names, not products of any account. A product id only means something inside the store account that owns the app's package name or bundle id, which is yours after you rename the app (Release → ids). You can keep these names or enter your own in the console.
• Verification endpoints: the backend talks only to the stores' official APIs, androidpublisher.googleapis.com (Google Play Developer API) and api.storekit.itunes.apple.com (App Store Server API; api.storekit-sandbox.itunes.apple.com in sandbox), authenticated with your service account and your App Store key from Console → Store & purchases (firebase/functions/src/iap.ts). No receipt is sent anywhere else.
• The app's backend address is your own API_BASE_URL, set when you build; it is empty in the source (app/lib/core/env.dart), and the app shows a setup screen without it.
• Credentials: the package name, service account JSON, issuer id, key id, .p8 key and bundle id are empty until you enter them; the secret ones are stored encrypted and written only to config/private (schema).
• Money goes from Google Play and the App Store to your developer accounts. The code pays and reports nothing to the author.

03Google Play verification

1. Package nameConsole → Store & purchases → Android package name: your application id (for example com.yourcompany.yourapp).
2. Access to the Play Developer APIEnable "Google Play Android Developer API" in Google Cloud, then invite the service account in Play Console → Users and permissions with View financial data for your app. By default the backend uses the Cloud Functions runtime service account (<project-number>-compute@developer.gserviceaccount.com).
3. Or a separate service accountPaste its whole JSON key into Google Play service account (JSON) instead, and invite that account's e-mail the same way. The console's test only checks the file's shape ("Service account … — the file is complete."); nothing is sent.

Every click: Provider dashboards → Google Play Console.

04App Store verification

1. Create an In-App Purchase keyApp Store Connect → Users and Access → Integrations → In-App Purchase → generate a key and download the .p8 file (it downloads once).
2. Enter four valuesConsole → Store & purchases: iOS bundle id, App Store Connect issuer id, In-app purchase key id and In-app purchase key (.p8 contents) (paste the whole file including the BEGIN and END lines). The test checks that the key parses as an EC key.
3. EnvironmentApp Store environment: Sandbox (TestFlight) while you test, Production for the live app.

The backend reads each transaction from the App Store Server API with a token signed by this key. Every click: Provider dashboards → App Store Connect.

05Switch purchases on

1. Products approvedCreate and activate the products in both stores (Apple needs them submitted with an app version the first time).
2. PlansConsole → Plans: product ids, features, limits, Active (Plans and paywall).
3. Master switchConsole → Store & purchases → Sell in-app purchases on, Save.
4. Check Status"Store purchases configured" and "Plans are sellable" should pass.
5. TestAndroid: upload a build to an internal testing track and add licence testers in Play Console. iOS: TestFlight with a sandbox account and the Sandbox environment.

06What happens on a purchase

1. The store chargesThe app buys through Google Play Billing or StoreKit and receives a purchase token (Android) or transaction id (iOS).
2. The app asks the backendPOST /v1/purchases/verify with the product id and the token.
3. The backend verifieswith Google or Apple, maps the product id to a plan and period (or to Remove ads or a credit pack), then grants it once per order, stores purchases/{platform}_{orderId} and, when the store reports a price, writes one revenue event for the Revenue centre.

07One purchase, one account at a time

• A plan or Remove ads bought once belongs to one account at a time. If the same store purchase is restored while signed in to another account, the entitlement moves to that account and is removed from the previous one.
• A credit pack is credited once. Restoring or re-sending the same order never adds credits again.
• A plan granted by hand in the console (Users) is separate from the store plan and is never touched by a store purchase or restore; the user gets the active plan with the higher rank.
• For a plan to survive a reinstall or a new phone, the user should sign in (Google, Apple or e-mail) and tap Restore purchases.

08Before verification is set up

09Records and account deletion

When a user deletes their account, purchases and revenueEvents are kept (with the user id as an opaque id) because you may have to keep financial records. Mention this in your privacy policy (Account deletion).