Practical guide · Updated July 25, 2026
How to enable in-app purchases
Apps with in-app purchases sell optional digital items, features or subscriptions inside the installed product. Enabling them safely requires agreement between the store product, client transaction, server entitlement and restore path.
What apps with in-app purchases actually sell
The store label means an app offers optional purchases after download. It does not mean payment is required to install the app.
Games, creator tools, fitness products, education apps and productivity products can all use these models. The right type follows the entitlement the user receives, not the label that appears easiest to configure.
Know when store billing is required
Digital content, features and subscriptions consumed inside an iOS or Android app generally use the platform billing system. Physical goods and real-world services normally use an external processor such as Stripe. Do not place Apple Pay, card checkout and in-app purchase into one implementation bucket.
- Classify every paid item as digital, physical, service or existing reader access
- Check current Apple and Google policies for the product and region
- Map the same entitlement across web, iOS and Android accounts
- Explain price, billing period and renewal before purchase
How do I enable in-app purchases?
Start by choosing stable product identifiers. Use a consumable for repeatable units, a non-consumable for permanent access, and a subscription for ongoing access. Define the identifiers before wiring the interface.
Create matching products in App Store Connect and Play Console, then record environment, price, tax category, review evidence and the internal entitlement each product grants.
Implement billing and a source of truth
Use StoreKit 2 on Apple and Google Play Billing on Android, or a service such as RevenueCat. A successful client callback is not enough to grant valuable access permanently.
- The client loads available products from the store.
- The user confirms the platform purchase sheet.
- The transaction is verified with the store or trusted billing service.
- The backend maps the verified product to an entitlement.
- The client refreshes access from that entitlement state.
Record transaction identity, environment and ownership without storing payment credentials.
Restore purchases and reconcile state
A paid user must recover access after reinstalling, switching devices or signing in again. Restore is a product flow, not a hidden support operation.
- Restore non-consumables and subscriptions
- Handle pending transactions and family or account changes where applicable
- Process renewal, expiry, refund, revocation and grace period
- Resolve duplicate callbacks idempotently
- Queue verified payments that temporarily fail to grant access
- Keep web and mobile accounts mapped to the same customer safely
Test the complete purchase lifecycle
Use sandbox accounts and signed TestFlight or Play testing builds. Test successful purchase, cancellation, failure, pending payment, restore, expiry, renewal, refund, revocation, account switching and offline return.
Analytics should distinguish purchase started, store sheet shown, verified transaction, entitlement granted and access displayed. This makes support possible when money and access disagree.
Give reviewers a complete path
Provide working products, review credentials and exact navigation notes. Apple may require associated in-app purchases to be submitted with the app version. Google requires accurate declarations and a reachable paid path in the reviewed build.
- Products are available in the reviewer storefront
- Review accounts do not require an unavailable second factor
- Restore purchases is visible
- Terms and privacy policy are reachable
- The listing does not promise unavailable paid features