RevenueCat vs Stripe for Mobile In-App Purchases: When to Use Which

Every mobile founder asks this eventually: should I use RevenueCat, Stripe, or both? The answers you'll find online are either "RevenueCat, always" (from RevenueCat) or "Stripe, always" (from developers who haven't shipped to the App Store). Neither is right.

Here's a decision tree based on what your app actually sells.

The one rule Apple and Google will enforce

If you sell digital goods consumed inside the app (subscriptions, credits, ad-free mode, premium features, unlocks), you must use Apple IAP on iOS and Google Play Billing on Android. This is non-negotiable. Apple takes 15–30%, Google takes 15–30%, and you can't route around it — they'll reject your app.

If you sell physical goods or services consumed outside the app (hardware, real-world bookings, SaaS that's also on the web), you must not use IAP. You have to use Stripe or similar.

So the real question is: do you fall into bucket 1, bucket 2, or a weird hybrid?

Bucket 1: subscriptions + in-app consumables

This is where RevenueCat shines. IAP on iOS and Android are completely different APIs with different lifecycles, different receipt formats, different refund behaviors, and different edge cases for family sharing, subscription upgrades/downgrades, and grace periods.

Without RevenueCat:

// You will write all of this yourself, twice
import { purchase as applePurchase } from "expo-iap";
import { purchase as googlePurchase } from "expo-iap";
 
// Then validate receipts with Apple's server
// Then validate receipts with Google's server
// Then sync both to your database
// Then handle renewal webhooks from both
// Then handle introductory offers, which work differently on each

With RevenueCat, it's one SDK, one customerInfo object, one webhook to your backend. The $0 free tier covers up to $2.5k MTR and paid tiers cap at 1% of revenue. For subscription apps, this is obviously correct.

Bucket 2: physical goods or web-parity SaaS

Use Stripe. Their React Native payment sheet is legitimately polished and supports Apple Pay / Google Pay natively. You keep your full margin (less Stripe's 2.9% + 30¢). No store review headaches about "where's the IAP flow."

The trap here is the "can I use IAP anyway?" temptation for digital goods that feel like services. Apple's guidelines are explicit: if consumers use the benefit inside the app, it's digital, and IAP applies. Don't get creative — you'll get rejected, and the appeal process takes weeks.

Bucket 3: hybrid — most SaaS apps

Your SaaS has a web signup (Stripe), but also wants to offer iOS/Android subscriptions because mobile users convert 3x better in-app. This is where you need both.

• Web: Stripe subscriptions, your backend is source of truth.
• iOS/Android: RevenueCat proxying Apple/Google, your backend reconciles.
• Entitlement check: a single isPremium boolean on your user row, written by whichever webhook fired last.

This is genuinely hard to get right. Cross-platform entitlement sync, grace periods that differ between Stripe (~7 days) and Apple (~16 days), and account recovery when a user signs up on iOS then pays on web — all of these are real bugs we've fixed in production.

The honest tradeoff

RevenueCat is a subscription layer: it knows what a subscription is, what a renewal is, what a family-shared entitlement is. It's worth the 1% revenue fee every time your app has subscriptions.

Stripe is a payment rail: it'll charge anything, but you write the business logic. For one-time digital non-IAP goods (which doesn't exist on mobile) or physical goods or web SaaS, it's the right layer.

Don't pick one as "your payment provider." Pick based on what each purchase is to Apple's App Review.

Both are wired into our starter kit — Stripe's payment sheet for the web subscription side, RevenueCat + expo-iap for mobile subscriptions, with a unified entitlement check that works across both.