LaunchLint Academy
The short answer
- In-app purchases and subscriptions rarely fail review because of one isolated API call. Store configuration, product status, paywall claims, transaction handling, restoration, account linking, and reviewer access have to work as one coherent system.
- This guide provides a release gate for Expo and React Native apps. It connects Apple and Google store setup with clear pricing communication, resilient entitlement handling, lifecycle tests, and complete Review Notes.
- Use an entitlement matrix for final acceptance rather than relying on a paywall screenshot. Each row combines platform, product, store state, app account, and expected access. Cover a new purchase, restoration, pending payment, refund, expiry, and a store account already associated with another app account. Compare client presentation, backend entitlement, and store truth after every transition. The purchase system is release-ready only when those three layers converge again. Also define who can resolve contradictory webhooks or store outages and safely trigger reconciliation. Observe the user-facing state while reconciliation runs: access should not flicker unpredictably, duplicate benefits must not be granted, and support needs a traceable transaction reference that reveals no sensitive receipt data.
- After release, monitor purchase completion, entitlement latency, restoration errors, refunds, and support contacts by platform and product. Set alert thresholds beforehand and maintain a safe reconciliation runbook. A healthy checkout rate alone is insufficient when customers pay successfully but receive access late or cannot restore on another device.
Define the product model first
Classify every benefit as consumable, non-consumable, or recurring subscription. Document what it unlocks, how long the entitlement lasts, and whether it is linked to an app account, platform, or store identity.
Product, client, backend, and store configuration must share that contract. An informal list of IDs quickly causes incorrect periods, duplicate grants, or a paywall that promises something different from the store product.
Product contract
- Product type and benefit are explicit
- Duration and renewal are defined
- Account and platform ownership explained
- Product IDs maintained centrally
- Pricing owner assigned
Reconcile store products and status
Complete identifiers, names, descriptions, prices, tax, availability, and localization in App Store Connect and Play Console. Apple requires the first in-app purchase of a type to be submitted with a new app version; verify the current status before submission.
Google Play subscriptions use products, base plans, and optional offers. Check countries, prices, activation, and compatibility. An identifier present in code is not yet a purchasable store product.
Store setup
- Products completely localized
- Prices and countries checked
- Status ready for review or sale
- Apple products submitted correctly
- Google base plans and offers active
Make the paywall and consent clear
The paywall should clearly show price, billing period, auto-renewal, trial terms, and the main benefit. Read the localized price from the store API rather than hard-coding currency. The purchase button and headline must not obscure cost or timing.
Link required privacy and terms information and keep restoration discoverable. Test long currencies and translations; truncated periods and ambiguous discount wording are both UX and review risks.
Paywall acceptance
- Localized store price
- Period and renewal visible
- Trial and future charge clear
- Terms and privacy reachable
- Restore is discoverable
Process purchases and entitlements safely
Do not treat a client callback as permanent truth. Verify transactions server-side or through a reliable store provider, associate them idempotently with a user, and persist the current entitlement state.
Purchases may be pending, cancelled, refunded, revoked, or delivered more than once. Each transition must be retryable without duplicate credit or lost access. Secrets and full receipts must stay out of client logs.
Transaction pipeline
- Server-side verification
- Idempotent processing
- Pending and cancellation supported
- Refunds and revocation update access
- No secrets in the client
Test restoration and device changes
Non-consumables and active subscriptions need restoration after reinstall or device change. Test with the same store account, a new app login, and an already linked account so ownership conflicts appear before customers find them.
Provide useful messages for no purchase found, purchase linked elsewhere, store unavailable, and verification pending. A restore control without visible progress looks broken even when a background job later succeeds.
Restore matrix
- Reinstallation
- Device change
- New app account
- Ownership conflict
- Offline and error feedback
Handle subscription management and changes
Give users a clear route to manage or cancel the subscription in the appropriate store. Show current plan and status in the app and open the correct store destination without claiming the app itself cancelled a store contract.
Plan upgrades, downgrades, grace periods, billing retry, expiry, and refund. Access must not depend on one local boolean. Use the currently verified entitlement and handle time boundaries deliberately.
Subscription lifecycle
- Store management link
- Verified current entitlement
- Upgrade and downgrade
- Grace period and billing retry
- Expiry and refund
Cover sandbox, track, and failure cases
Test success along with cancellation, pending payment, network loss, duplicate delivery, already-owned items, restoration, refund, and expiry. Apple sandbox and Google test timing differ from production, so document expected accelerated cycles.
Use a store-distributed build when signing and product association matter. Record product ID, platform, test account, build, and expected state without retaining sensitive tokens or payment information.
Required tests
- Success, cancellation, and pending
- Duplicate delivery
- Restore and already owned
- Refund and expiry
- Network loss at critical points
Prepare submission and Review Notes
Before submission, products must be review-ready and connected to the appropriate app version. The reviewer needs to reach the paywall, exercise the purchase, and understand the locked benefit. Keep products, backend, and test account available throughout review.
Review Notes should state navigation, login, product, expected result, restoration, and unusual prerequisites. Clear steps reduce questions but cannot compensate for a broken end-to-end transaction.
Review package
- Products linked to version
- Backend and test account available
- Exact review path
- Expected result described
- Restore step documented
Frequently asked questions
Must the first in-app purchase be submitted with an app version?
Apple requires the first in-app purchase of a type to accompany a new app version; confirm its status in App Store Connect.
Can I hard-code paywall prices?
Avoid it. Use the localized store price so currency, formatting, and later price changes remain correct.
Is a successful client callback enough?
No. Verify and process transactions robustly and idempotently before granting durable access.
Does the app need restoration?
Restorable purchases and subscriptions need a clear, tested restoration path.
What helps reviewers test purchases?
Provide the test account, navigation, product, expected outcome, and keep the backend and products available during review.