Digital goods sold inside a mobile app have to use Apple and Google billing. That means products configured in both stores, server-side validation, a restore path and a subscription lifecycle that survives refunds, billing retries and plan changes.
StoreKit 2 · Play Billing · Subscriptions · Receipts · Restore
Digital content, features and subscriptions consumed inside the app generally have to use Apple's and Google's billing. Physical goods, real-world services and some reader-app content have different rules.
Routing digital purchases through an external gateway is one of the fastest ways to fail App Store review. I check the classification before writing the payment code.
Each product needs a stable id, a type, pricing and availability in both consoles. Consumables need a delivery record so a restore does not grant them twice; non-consumables need a restore path; subscriptions need groups, levels and upgrade behaviour.
Price changes and local pricing are managed in the stores, not hard-coded in the app.
The app receives a transaction, but the backend decides whether it is real. App Store Server API and the Google Play Developer API let the server verify the purchase, bind it to an account and record it idempotently.
Server notifications cover renewals, refunds and revocations that happen while the app is closed. Without them, access drifts from reality.
Subscriptions move through billing retry, grace period, on-hold and expiry. The product needs a deliberate rule for each state, and the UI needs to explain what is happening without blaming the customer's bank.
Test with StoreKit configuration and Play license testers, including interrupted purchases, restores and cross-device sign-in.
Explore examples of mobile, Smart TV and integrated product work.
Not for digital goods inside the app on iOS or Android. Store rules require Apple or Google billing for those. Physical goods, bookings and real-world services can use a payment gateway, which is why the classification matters before implementation.
For a production app, yes. Client-only validation is easy to bypass and cannot handle refunds, revocations or cross-device entitlements reliably. The backend verifies transactions and owns access.
Each store bills its own subscribers. A shared entitlement layer on your backend gives the customer the same access on both platforms, provided the accounts are linked.
Common reasons are missing restore purchases, external payment links for digital goods, unclear subscription terms, or a paywall without the required disclosures. I build the flow against the current review guidelines, though the final review decision is the store's.
