In-App Purchases and Subscriptions

When Apple and Google require their own in-app purchase system instead of Stripe, and how to implement it with receipt validation.

This guide covers when Apple and Google require their own in-app purchase (IAP) system instead of a payment processor like Stripe, and how to implement it.

Quick Answer

Digital content or features consumed inside the app (subscriptions, unlockable content, virtual currency) must use Apple's and Google's own in-app purchase systems, not Stripe; physical goods and most real-world services may use Stripe. Implement with react-native-iap or a service like RevenueCat, and validate receipts server-side.

1. The Rule That Actually Matters

Both app stores require their own IAP system, and take a cut (historically 30%, reduced to 15% for smaller developers/lower revenue tiers under each store's small business programs), for anything that unlocks digital content or functionality within the app: subscriptions, premium features, virtual currency, extra levels. Real-world goods and services (a physical product, a ride, a hotel booking) are allowed to use an external processor like Stripe. Using Stripe for the former is one of the most common App Store rejection reasons.

2. Choose an Implementation Path

  • react-native-iap gives direct access to StoreKit and Google Play Billing; you own more of the integration and the receipt validation.
  • A service like RevenueCat wraps both platforms behind one API and handles receipt validation and subscription state for you, at the cost of a revenue share on top of the store's own cut.

3. Set Up Products

Create the product SKUs in App Store Connect (In-App Purchases section) and Google Play Console (Products → Subscriptions or In-app products), matching identifiers you'll reference from the app.

4. Validate Receipts Server-Side

After a purchase, the store returns a receipt/token to the app. Send it to your backend and validate it against Apple's or Google's verification API before granting entitlement; trusting the client-reported "purchase succeeded" without server verification means a modified app could fake a purchase.

5. Handle Restore Purchases

Apple requires a visible "Restore Purchases" option for non-consumable purchases and subscriptions, so a user who reinstalls or switches devices can recover what they paid for without buying again. Missing this is a common rejection reason.

Common Issues

App rejected for using a third-party processor for digital content move that specific purchase flow to IAP; you can still use Stripe elsewhere in the same app for real-world purchases.

Purchases work but subscriptions don't renew as expected in testing use a sandbox/test account and be aware sandbox subscription periods are dramatically compressed (minutes instead of months) specifically for testing renewal.

Entitlement granted without verifying the receipt a purchase can be spoofed by a modified client; always verify server-side before unlocking content.

"Restore Purchases" missing required by Apple; add it even if you think users won't need it.

Verification Checklist

  • products/subscriptions are created in both store consoles with matching identifiers;
  • receipts are verified server-side before granting entitlement;
  • a Restore Purchases option exists and works;
  • sandbox test purchases and renewals have been exercised on both platforms;
  • Stripe (if used elsewhere in the app) is only used for real-world goods/services, not digital content.

Next Steps