React Native IAP: The Store Bridge

WHY IT EXISTS: Apple and Google require that all digital goods sold inside mobile apps use their native billing systems so they can collect commission and manage tax compliance. React Native cannot access the App Store or Play Store billing APIs directly from JavaScript because those APIs are native, asynchronous, and tightly coupled to the platform's identity and sandbox. A bridge module marshals requests from the JS thread to the native StoreKit or billing client and returns purchase events back across the bridge.

THE MENTAL MODEL: Think of React Native IAP as a translator at a bank counter. Your JavaScript is the customer asking to buy, but the vault, cash handling, and receipt printer live in the native operating system. You hand a request slip across the counter, the native teller performs the transaction, and slides a receipt back. You never touch the money; you only react to whether the receipt is valid.

HOW IT WORKS: You initialize the store connection and fetch items using product IDs defined in App Store Connect or Google Play Console. When a user taps buy, the request hops over the bridge to the native module. The OS shows the system payment sheet, processes the charge, and emits a purchase event back to JavaScript with a transaction identifier and signed receipt. For consumables and non-consumables you must finish the transaction on the native side to confirm delivery; for subscriptions the store handles renewal but you must validate the receipt to check entitlement status. Validation can happen locally but should be done server-side to avoid spoofing.

WHEN TO USE IT: Use this for any digital content or feature accessed within the app, such as premium filters, extra lives, or monthly subscriptions. It is also the only allowed way to sell digital goods on iOS and Android inside the app. Physical goods, real-world services, or donations to nonprofits generally must use a different payment processor.

WHEN NOT TO USE IT: Do not use IAP for tipping creators, buying physical merchandise, or paying for ride-sharing trips; Apple and Google reject apps that use IAP for these categories and require Stripe, PayPal, or another out-of-app flow. Also avoid IAP if you need instant synchronous confirmation, because the purchase flow is always async and can be interrupted by parental controls, insufficient funds, or network loss.

ONE CANONICAL EXAMPLE: A meditation app offers a monthly subscription. On mount, it calls getSubscriptions with the SKU monthly_premium, renders the localized price, and shows a subscribe button. On tap, it calls requestSubscription, the OS presents the Face ID sheet, and upon success the app receives a purchase object. The app sends the receipt to its backend, which validates it with Apple's server API and flips an isPremium flag in the database. Finally the app calls finishTransaction so Apple knows delivery is complete and the charge sticks.