In-App Purchases in React Native: RevenueCat vs Going Direct

In-app purchases look simple in a demo: show a price, tap buy, get the feature. In production they're a distributed system with two app stores, receipts, renewals, grace periods, refunds, family sharing, price changes, restores on new phones, and users who subscribe on iPhone but expect access on Android too.

For React Native in-app purchases in 2026 you have two real paths: use a subscription platform like RevenueCat, or integrate the stores directly with expo-iap or react-native-iap and run the server logic yourself. I've shipped payments in 12+ apps, including RevenueCat and in-app purchases, and here's how I'd choose.

Key takeaways

• RevenueCat handles receipts, entitlements, renewals, cross-platform access, webhooks and analytics. It's free up to $2,500 in monthly tracked revenue, then 1%.
• Going direct means expo-iap (Expo projects) or react-native-iap v15+ (bare React Native 0.79+), plus your own server for validation and subscription state.
• Either way, validate on a server. The app's purchase result is a claim, not proof.
• On Android, purchases must be acknowledged within three days, or Google refunds them automatically.
• Choose RevenueCat for speed and fewer edge cases; go direct when fees at scale or full control matter more than build time.

The options

Other subscription platforms exist (Adapty, Qonversion and others) with similar trade-offs.

Library choices if you go direct

The direct-integration libraries split in 2025:

• expo-iap is the option for Expo projects, built as an Expo module.
• react-native-iap v15 and later targets bare React Native CLI projects on React Native 0.79+, built on Nitro Modules, using StoreKit 2 on iOS and a recent Google Play Billing library on Android. Its maintainers point Expo users to expo-iap.

Both leave receipt validation and entitlement logic to your backend, which is where most of the real work is.

Setting up in-app purchases in an Expo app

Store purchases need native code, so they run in a development build rather than Expo Go. The setup, in order:

1. Create the products in App Store Connect and Google Play Console with matching identifiers, and finish the Paid Applications agreement, tax and banking details on Apple's side.
2. Install expo-iap (or RevenueCat's SDK) and rebuild the development build.
3. On iOS, test with a StoreKit configuration file in development and sandbox accounts on a device.
4. On Android, upload a build to a testing track and add license testers; Google Play only returns products for apps it knows about.

Subscriptions follow the same path, with extra work for renewals, grace periods and upgrades or downgrades between tiers.

What your server must do either way

Whether RevenueCat does it for you or you build it, someone has to:

1. Validate purchases with Apple's App Store Server API and Google's Play Developer API, not trust the app.
2. Acknowledge Android purchases within three days, or Google automatically refunds them.
3. Track subscription state from App Store Server Notifications and Google's real-time developer notifications: renewals, cancellations, billing retries, grace periods, refunds and expirations.
4. Map purchases to your users, so access follows the person across devices and platforms.
5. Handle restores, so a user on a new phone gets back what they paid for.
6. Record revenue for analytics, taxes and support.

That's why "just add IAP" estimates are so often wrong. The purchase button is a day; the state machine behind it is weeks.

From the field: I've integrated Stripe, RevenueCat, in-app purchases, Razorpay and KNET across 12+ apps, with idempotent, webhook-driven billing. On MOVE, a subscription fitness platform with 100K+ active users, RevenueCat sat alongside Stripe. The billing logic that matters isn't the purchase call; it's handling every event that arrives afterwards exactly once.

What the stores take

Before comparing tools, know the store fees, because they dwarf any tool's cost:

That's why the choice between RevenueCat at 1% and a direct integration rarely decides profitability early on. Getting conversion, retention and pricing right matters far more. Enrol in Apple's Small Business Program if you qualify; it halves the commission for most small developers.

When RevenueCat is the right call

• You're launching subscriptions and want to ship in days, not weeks.
• You sell on both iOS and Android and need one view of each user's access.
• You want paywall experiments and subscription analytics without building them.
• Your revenue is below the level where 1% outweighs the engineering time saved.

When going direct makes sense

• Revenue is high enough that 1% of it would pay for a dedicated engineer.
• You need full control of data, or can't send purchase data to a third party.
• Your purchase model is simple (a few one-time purchases) and you already run a solid backend.
• You're integrating with a complex existing billing system.

Gift cards and store balance

Can an Apple Gift Card be used for in-app purchases? Yes: Apple Gift Card balance on a customer's Apple Account pays for apps, in-app purchases and subscriptions, and Google Play balance from gift cards works the same way on Android. Your app doesn't need to do anything; the store handles payment, and you receive the same transaction and webhook as for a card payment.

Testing in-app purchases

• iOS: use sandbox accounts and StoreKit testing in Xcode; sandbox subscriptions renew on an accelerated schedule, so you can watch renewals and expirations quickly.
• Android: add license testers in Play Console and test with a build installed from a testing track.
• Both: test restores on a fresh install, refunds, cancelled subscriptions, and a user switching platforms.
• Native code is required: in-app purchase libraries need a development build; Expo Go won't run them.

FAQ

Is RevenueCat worth it for a React Native app?

For most apps, yes, especially early on. It's free until $2,500 in monthly tracked revenue, then 1%, and it removes weeks of work on receipt validation, subscription state, cross-platform access and analytics. At very large revenue, building in-house can become cheaper, and that's when teams usually revisit it.

Can I use in-app purchases without RevenueCat?

Yes. Use expo-iap in Expo projects or react-native-iap v15+ in bare React Native, and build server-side validation and subscription tracking with Apple's App Store Server API and notifications and Google's Play Developer API and real-time notifications.

Why are my Android purchases being refunded?

Google Play automatically refunds purchases that aren't acknowledged within three days. Make sure your server (or your subscription platform) acknowledges each purchase after validating it, including purchases completed while your app was closed.

Do in-app purchases work in Expo Go?

No. In-app purchase libraries include native code, so they need a development build. Use EAS Build to create one, then test with sandbox accounts on iOS and license testers on Android.

Next steps

If you're adding subscriptions or in-app purchases to a React Native app, I can set up the purchase flow, the server side and the testing plan so renewals and refunds don't become support tickets. Get in touch, or see how I work as a React Native developer.

Sources

• RevenueCat pricing, RevenueCat
• expo-iap, GitHub
• react-native-iap, GitHub
• App Store Server API, Apple
• Integrate the Google Play Billing Library, Android Developers