Receipt validation
Checking Apple's signed transaction or Google's purchase token before your server unlocks paid access.
See it
What it is
Receipt validation is checking store-issued purchase evidence before your backend grants paid access. The old umbrella word is receipt, from Apple's now deprecated verifyReceipt endpoint. Modern Apple flows use signed StoreKit 2 transaction data and the App Store Server API; Google Play gives the app a purchase token that your server checks with the Google Play Developer API.
Use it for every entitlement that matters across devices or has value on your server. Verify the app or package ID, product ID, environment, purchase state, and store account mapping, then write the entitlement idempotently. Reconcile again when refund, revocation, renewal, expiry, or billing-retry notifications arrive.
Gotcha: a valid signature proves that the store issued the record. Current access also depends on subscription state and the signed-in user's account mapping. Never trust a client-supplied isPro flag, never grant twice when the same transaction is replayed, and keep sandbox records from polluting production entitlements.
Ask AI for it
Implement server-side purchase validation for this entitlement model: [paste schema]. For Apple, verify the StoreKit 2 signed Transaction JWS chain and reconcile status through the App Store Server API. For Google Play, accept a purchaseToken over authenticated TLS and call purchases.products.get or purchases.subscriptionsv2.get as appropriate. Validate bundle or package ID, product ID, environment, purchase state, expiry, revocation, and signed-in account binding before an idempotent entitlement write. Add App Store Server Notifications V2 and Google Play Real-time Developer Notifications handlers, replay protection, sandbox fixtures, audit logging without raw tokens, and tests for renewal, refund, expiry, duplicate delivery, and out-of-order events.