Stripe vs RevenueCat for React Native: When to Use Which

March 2026

Here's the direct answer: use RevenueCat for mobile app subscriptions and in-app purchases. Use Stripe for web payments and one-time purchases that happen outside the app stores. They are not interchangeable, and trying to use Stripe where RevenueCat belongs (or vice versa) will either get your app rejected or cost you months of unnecessary work.

I sell Ship React Native through Stripe on the web. The apps I build with it use RevenueCat for in-app purchases. Both tools are excellent at what they do, and terrible at what they don't. This post explains when to use which, based on real experience shipping 10+ apps and running a product that uses both payment systems simultaneously.

Table of Contents

Why You Can't Just Use Stripe for Everything

This is the first thing most React Native developers get wrong. You're used to Stripe from web development. It's clean, well-documented, the API is a joy to work with. So you think: I'll just use Stripe in my mobile app too.

You can't. Not for digital goods.

Apple and Google have a non-negotiable rule: if your app sells digital content, features, or subscriptions that are consumed within the app, you must use their in-app purchase systems. That means StoreKit on iOS and Google Play Billing on Android. There is no negotiation here. There is no workaround. If you try to use Stripe to sell premium features, subscription access, or digital content inside your app, your app will be rejected during review. If it somehow slips through, it will be pulled later.

Stripe is for everything else: physical goods, services rendered outside the app, web-based subscriptions, and one-time purchases on your website. A food delivery app can use Stripe because you're paying for physical food. A SaaS product can use Stripe on its website. But the moment you're selling digital access inside a mobile app, you need the native billing systems.

That's where RevenueCat comes in. RevenueCat wraps StoreKit and Google Play Billing into a single, sane API. Instead of writing platform-specific billing code, dealing with receipt validation on both platforms, and managing subscription state yourself, RevenueCat handles all of it. One SDK, one dashboard, and the subscription logic just works across iOS and Android.

The Four Scenarios

1. Mobile App Subscriptions -- Use RevenueCat

If your app charges a monthly or annual subscription for access to features, content, or usage limits, this is RevenueCat territory. Period.

RevenueCat handles the entire flow: displaying paywalls, processing purchases through StoreKit and Google Play Billing, validating receipts server-side, managing subscription status, handling upgrades and downgrades, restoring purchases on new devices, and dealing with grace periods when payments fail.

I use RevenueCat in every app I ship. The integration in Ship React Native takes about 15 minutes to configure because most of the wiring is already done. You set up your products in App Store Connect and Google Play Console, add the API keys to RevenueCat, and the SDK handles the rest. Without RevenueCat, you'd spend 2-3 weeks building receipt validation and platform-specific billing code.

2. Physical Goods and Services -- Use Stripe

If your app sells physical products, delivers real-world services, or processes payments for things that exist outside the digital app experience, Stripe is the right choice.

Think food delivery apps, e-commerce, booking platforms, ride-sharing, or marketplace apps. The user is paying for something tangible -- a meal, a product shipped to their house, a service performed by a real person. Apple and Google don't take a cut of these transactions because they're not digital goods consumed within the app.

Stripe's React Native SDK (@stripe/stripe-react-native) is solid. You get a payment sheet, Apple Pay and Google Pay support, card tokenization, and the full Stripe API on your backend. For these use cases, Stripe is the better choice -- lower fees, more payment methods, and you keep full control of the customer relationship.

3. Web SaaS with a Mobile Companion -- Use Both

If you have a web-based SaaS product and a mobile app that accesses the same service, you typically need both systems.

Stripe handles subscriptions on your website. RevenueCat handles subscriptions initiated from the mobile app, where Apple and Google require their billing systems.

The tricky part is syncing subscription state across both. A user who subscribes through the web via Stripe needs access in the mobile app. A user who subscribes through the App Store needs access on the web. RevenueCat can handle this -- it supports a backend API where you can grant entitlements regardless of the payment source. You'll need to build some glue code on your server, but it's manageable.

The strategic play here is to offer a slight discount on web subscriptions (since you're not paying the 30% store commission) and direct users to subscribe through the website. This is allowed, as long as you don't explicitly discourage in-app purchase within the app itself.

4. Credits and Tokens for AI Features -- Use RevenueCat (and Optionally Stripe for Web)

This is the scenario I deal with most. Users buy credits or tokens that they spend on AI generations -- chat messages, image generations, voice transcriptions.

Inside the app, these credits are digital goods. You must sell them through in-app purchases, which means RevenueCat. Set up consumable IAPs in App Store Connect and Play Store, configure them in RevenueCat, and track credit balances on your backend (I use Convex for this).

If you also have a web interface, you can offer credit top-ups through Stripe on the web. Same credit balance, different purchase channel. The web purchases avoid the 30% store fee, so you can offer more credits per dollar on the web. ChatGPT, Midjourney, and plenty of other AI products use this exact strategy.

Comparison Table

| | Stripe | RevenueCat |

|---|---|---|

| Platform | Web-first, mobile SDK available | Mobile-first (iOS + Android) |

| Primary use case | Web payments, physical goods, services | Mobile subscriptions, IAPs |

| Fee structure | 2.9% + $0.30 per transaction | Free up to $2.5k MTR, then 1% of tracked revenue |

| Receipt validation | Not applicable (handles own receipts) | Automatic for both App Store and Play Store |

| Subscription management | Built-in (Stripe Billing) | Built-in (wraps StoreKit + Google Play Billing) |

| Mobile integration | @stripe/stripe-react-native SDK | react-native-purchases SDK |

| Web integration | Stripe.js, Checkout, Elements | Webhook-based (no web purchase UI) |

| Apple/Google compliance | Not compliant for digital goods in apps | Fully compliant (uses native billing) |

| Refund handling | Direct refund API | Handled by Apple/Google, RevenueCat detects |

| Analytics | Stripe Dashboard | RevenueCat Charts (MRR, churn, trials) |

The "Stripe Tax" Misconception

I see this in developer forums constantly. Someone launches a React Native app, integrates Stripe for premium features, submits to the App Store, and gets rejected. Then they post asking why Apple rejected their app and how to "fix" it.

There is nothing to fix. You cannot use Stripe (or any external payment processor) for digital goods sold inside an iOS or Android app. Apple's App Store Review Guideline 3.1.1 is explicit: "If you want to unlock features or functionality within your app, you must use in-app purchase."

The confusion comes from web development, where Stripe handles everything. Developers assume the same applies on mobile. It does not. Some think they've found workarounds -- directing users to a website to pay, using deep links, or hiding Stripe behind a webview. Apple's review team has seen all of these. They will reject your app.

I've watched developers waste months building Stripe integrations for mobile apps, only to rip it all out after their first App Store rejection. Save yourself the time. If it's a digital good consumed in the app, use in-app purchases. RevenueCat makes this painless.

The only exception for Stripe in a mobile app is when you're selling physical goods or real-world services. A delivery app, a booking platform, an e-commerce app -- these can and should use Stripe. The rule is about what you're selling, not which SDK you prefer.

The Reader App Rule

There is one legitimate exception that confuses people: the Reader App rule. Apple allows "reader" apps -- apps that let you consume content purchased elsewhere -- to link to external websites for sign-up and account management. This is why Netflix, Spotify, Kindle, and other content consumption apps can direct you to their website to subscribe.

In 2022, Apple formalized this with the External Link entitlement. Reader apps can include a link to their website where users can manage accounts and subscriptions.

But here's the catch: this only applies to reader apps. Apps where users consume content like magazines, newspapers, books, audio, music, and video. It does not apply to apps that generate content, provide tools, or offer utility features.

If you're building an AI app that generates images, writes text, or transcribes audio, you are not a reader app. Your app creates content, it doesn't just display content purchased elsewhere. You cannot use the Reader App exception. I've seen developers try to argue that their AI app is a "reader" of AI-generated content. Apple does not buy this argument.

The line is clear: if your app is primarily a window into content the user already has access to from another platform, you might qualify. If your app does the actual work -- generating, transforming, or creating -- you don't.

Cost Breakdown

Here's what each payment path actually costs you:

RevenueCat + App Store/Play Store:

• Apple/Google take 30% of each transaction (15% if you qualify for the Small Business Program -- under $1M annual revenue)
• RevenueCat is free up to $2.5k in monthly tracked revenue (MTR)
• Above $2.5k MTR, RevenueCat charges 1% of tracked revenue
• Total effective cost: 15-31% of revenue

Stripe (web payments):

• Stripe charges 2.9% + $0.30 per transaction
• No platform commission from Apple or Google
• Total effective cost: roughly 3-4% of revenue

The math is brutal when you compare them side by side. A $9.99/month subscription through the App Store nets you roughly $7-8.50 after Apple's cut. The same subscription through Stripe on the web nets you about $9.40. That's a meaningful difference at scale.

This is why companies with both web and mobile products push hard for web subscriptions. It's also why Apple's policies are so controversial. But the reality is: if you want to be in the App Store, you play by Apple's rules. Budget for the 15-30% cut and price your subscriptions accordingly.

For indie developers and small teams, the RevenueCat free tier is generous. $2.5k in monthly tracked revenue covers most early-stage apps. You probably won't hit that limit until your app is generating meaningful revenue, at which point the 1% fee is trivial compared to what Apple and Google are already taking.

How Ship React Native Handles This

Ship React Native uses both payment systems, and this is a real-world example of the dual approach working in practice.

For the product itself (selling the starter kit): I use Stripe on the Ship React Native website. When you buy the kit at shipreactnative.com, you're purchasing a code license -- a one-time web payment. Stripe is the right tool here. I get the full payment minus Stripe's 2.9% + $0.30. No Apple or Google involvement.

For apps built with the kit: Ship React Native comes pre-configured with RevenueCat. When you build an app and sell subscriptions or credits through the App Store or Play Store, those transactions go through RevenueCat. The integration is already wired up -- configure your products, add API keys, and the paywall, purchase flow, and entitlement management work out of the box.

The RevenueCat integration in Ship React Native includes paywall screens, subscription status checking via Convex, entitlement-gated features, and restore purchase functionality. It took me several iterations across multiple apps to get this flow right, which is exactly why I packaged it into the starter kit.

Which One Do You Need

If you've read this far, you probably already know the answer. But to make it concrete:

Use RevenueCat if you're building a mobile app that charges for digital features, content, or subscriptions. Non-negotiable for App Store and Play Store compliance.

Use Stripe if you're selling physical goods through a mobile app, running a website that sells products or subscriptions, or processing payments for real-world services.

Use both if you have a web presence and a mobile app that both need to handle payments.

Don't overthink this. The platform rules dictate the choice. Stripe for web and physical goods. RevenueCat for mobile digital goods. Both when you need both.

If you're starting a new React Native app and want both payment systems pre-configured, Ship React Native ships with RevenueCat ready to go and the landing page template includes Stripe for web purchases. It's the setup I use for every app I build.