The Core Problem

What Counts as "Digital Goods"

What You'll Need to Manage

1. Stripe (Web)

• Keep using Stripe for your web app as-is.
• Users who subscribe via browser pay through Stripe.
• You control pricing, billing, and revenue fully.
• No platform cut.

2. Apple In-App Purchases (iOS)

• You must use StoreKit 2 (the modern Swift API) or a cross-platform library (see below).
• Apple takes 15–30% commission (15% for small developers / renewals after year 1).
• You configure products in App Store Connect (subscription groups, consumable top-ups).
• Apple handles the payment UI, receipt validation, and renewal logic.
• You receive a server-side webhook (App Store Server Notifications) to provision entitlements.

3. Google Play Billing (Android)

• You must use the Google Play Billing Library.
• Google takes 15–30% commission (15% for the first $1M/year under the reduced service fee program).
• You configure products in Google Play Console.
• Google sends Real-time Developer Notifications (RTDN) via Pub/Sub to your backend.

Your Backend Architecture

[iOS App]  → StoreKit purchase → Apple validates → Apple webhook → Your Backend
[Android]  → Play Billing     → Google validates → Google webhook → Your Backend
[Web App]  → Stripe           → Stripe webhook   → Your Backend

Your Backend → grants/revokes subscription access & top-up credits

1. Verify receipts/tokens from all three sources (never trust the client alone).
2. Map each platform's subscription state to your internal user entitlement.
3. Handle renewals, cancellations, refunds, and grace periods from all three sources.
4. Store which platform a user subscribed on (important — you can't move them across platforms).

Cross-Platform Libraries That Help

Practical Pricing Implications

1. Charge more on mobile — e.g., $10/month on web, $13/month on iOS (to offset the cut). Apple/Google allow this.
2. Funnel users to web — You cannot show a link inside the iOS app saying "subscribe cheaper on our website" (Apple cracked down on this). You can tell users verbally or via email, but not in-app UI. (Note: Post-Epic v. Apple ruling in the US, this is evolving — as of early 2026, Apple must allow links to external purchase options for US users. Check the current App Store guidelines.)
3. Freemium on mobile — Only offer a limited free tier through mobile apps and push subscription to web.

Summary: Your Action Plan

1. Keep Stripe for web — no changes needed there.
2. Integrate Apple StoreKit 2 for iOS subscriptions + consumable top-ups.
3. Integrate Google Play Billing for Android.
4. Consider RevenueCat to simplify both mobile integrations.
5. Build a unified entitlement endpoint in your backend that all three platforms post to.
6. Configure products in App Store Connect and Google Play Console — they must match your actual product tiers.
7. Never call Stripe from within the mobile app UI — any payment for digital goods inside the app must go through IAP.

What is RevenueCat?

The Problem It Solves

• Implement StoreKit 2 in Swift/Obj-C for iOS
• Implement Google Play Billing Library in Kotlin/Java for Android
• Build receipt validation servers for both (Apple and Google receipts are completely different formats)
• Handle renewals, cancellations, refunds, billing retries, grace periods from both platforms
• Build a subscriber state database — who has access, which plan, when does it expire
• Handle edge cases like family sharing, subscription upgrades/downgrades, promo codes, free trials
• Wire up webhooks from Apple (App Store Server Notifications) and Google (RTDN via Pub/Sub)

How It Works — Architecture

Your iOS App
  └── RevenueCat SDK ──→ Apple StoreKit 2 ──→ Apple
                    ──→ RevenueCat Backend ──→ Your Backend (webhook)

Your Android App
  └── RevenueCat SDK ──→ Google Play Billing ──→ Google
                    ──→ RevenueCat Backend ──→ Your Backend (webhook)

Your Web App
  └── Stripe ──→ Your Backend (webhook)
                    ↓
            Unified Entitlement Check

Key Features

1. SDK (Client-Side)

• Available for: iOS (Swift/Obj-C), Android (Kotlin/Java), Flutter, React Native, Unity, Capacitor, Cordova
• A few lines of code to initialize, fetch offerings, and trigger a purchase
• The SDK talks to both the platform's billing system AND RevenueCat's backend simultaneously

2. Entitlement System

• You define entitlements (e.g., "pro_access", "topup_credits") in the RevenueCat dashboard
• Each product (Apple subscription, Google subscription) maps to an entitlement
• Your app just checks: Purchases.shared.getCustomerInfo() → has entitlement "pro_access"? → show premium features
• No platform-specific receipt parsing needed in your app code

3. Offerings & Paywalls

• You configure your subscription packages (monthly, annual, top-up) in RevenueCat dashboard
• RevenueCat can serve these dynamically — meaning you can change pricing/packaging without an app update
• They also have a Paywall UI builder — you can visually build your subscription screen and it renders in-app

4. Receipt Validation (Server-Side)

• RevenueCat validates every purchase receipt with Apple/Google servers on their backend
• You never have to implement Apple's receipt validation API or Google's Purchase Verification API yourself

5. Webhooks to Your Backend

• RevenueCat sends a single unified webhook format to your server for all events:
  • INITIAL_PURCHASE, RENEWAL, CANCELLATION, REFUND, BILLING_ISSUE, PRODUCT_CHANGE, etc.
• One webhook handler in your backend handles all platforms — no separate Apple + Google handlers

6. Dashboard & Analytics

• Built-in revenue analytics: MRR, ARR, churn rate, LTV, trial conversion, active subscriptions
• Cohort analysis, charts, subscriber breakdown by platform/country/product
• This is data you'd otherwise have to build yourself

7. Integrations

• Stripe — RevenueCat has a Stripe integration so web purchases can be synced into RevenueCat's subscriber database, giving you a unified view across web + mobile
• Also integrates with: Mixpanel, Amplitude, Braze, Slack, Airship, etc.

Pricing (as of my knowledge)

What RevenueCat Does NOT Replace

• Stripe — RevenueCat has no web payment processing. Your web subscriptions still go through Stripe. RevenueCat just has an integration to sync Stripe subscriber data so you can see everything in one dashboard.
• App Store Connect / Google Play Console — You still need to create your products (subscription plans, consumables) there. RevenueCat just connects to them.
• Your own backend — You still need a backend to store user data and serve your AI app. RevenueCat is complementary — it tells your backend "this user has Pro access."

For Your Specific App (AI Chat with Subscriptions + Top-ups)

Should You Use It?

React Native + RevenueCat

• You write one JavaScript/TypeScript codebase for both iOS and Android purchases
• No need to write native Swift or Kotlin code for billing at all
• The SDK handles the bridge to StoreKit 2 (iOS) and Play Billing 6 (Android) under the hood

import Purchases from 'react-native-purchases';

// Initialize once at app start
await Purchases.configure({ apiKey: Platform.select({
  ios: 'appl_xxxx',
  android: 'goog_xxxx'
})});

// Fetch your offerings (subscription plans you configured in dashboard)
const offerings = await Purchases.getOfferings();
const monthly = offerings.current.monthly;

// Trigger purchase
const { customerInfo } = await Purchases.purchasePackage(monthly);

// Check entitlement
if (customerInfo.entitlements.active['pro_access']) {
  // unlock premium features
}

The Promo Codes / Multi-Tier Scenario — This Is Where It Gets Complex

Subscription Tiers (Upgrade / Downgrade)

• Upgrades/downgrades are possible but the timing and proration rules are set by Apple/Google, not you
• Apple: Downgrade takes effect at the next renewal period. Upgrade is immediate with proration credit. You can't force immediate downgrade.
• Google: More flexible — you can specify upgrade/downgrade modes (immediate, deferred, etc.)
• RevenueCat wraps this and gives you a simple purchasePackage() call for plan changes, but the underlying platform rules still apply

Promo Codes

Apple Promo Codes

• Apple has its own promo code system in App Store Connect
• You generate promo codes there and users redeem them in the App Store app or via a deep link
• They work for paid subscriptions — gives a user a free trial or discounted period
• You cannot inject a promo code from within your app UI (Apple reviews reject this)
• RevenueCat supports reading the resulting entitlement after redemption, but the code redemption happens outside your app

Google Play Promo Codes

• Google also has promo codes in the Play Console
• More flexible — you can redeem them inside your app via the Play Billing flow
• RevenueCat supports this natively

Your Stripe Promo Codes

• These work only on your web app — no connection to mobile IAP
• You cannot honor a Stripe promo code inside the mobile app — Apple/Google won't know about it

How to Sync Entitlements Across All Three (The Right Architecture)

User subscribes on iOS
  → Apple charges them
  → RevenueCat receives Apple webhook
  → RevenueCat sends unified webhook to YOUR backend
  → Your backend updates user record: { platform: 'apple', tier: 'pro', status: 'active' }

User subscribes on Web
  → Stripe charges them
  → Stripe sends webhook to YOUR backend
  → Your backend updates user record: { platform: 'stripe', tier: 'pro', status: 'active' }

Your AI app (mobile or web) checks access:
  → Calls YOUR backend: "does user X have pro access?"
  → Backend checks the record — doesn't care which platform
  → Returns yes/no

The "Subscriber Origin" Problem

• If a user subscribes on iOS and then uses your web app, their entitlement comes from Apple — you must check RevenueCat/Apple to verify their status
• If they subscribed on web, their entitlement comes from Stripe
• You cannot "migrate" them from Apple to Stripe or vice versa without them cancelling and re-subscribing
• You need to store subscription_platform per user in your DB and check the right source accordingly

Summary Table for Your Use Case

Bottom Line

• RevenueCat is still very much worth it for React Native — it's their most popular platform and the SDK is mature.
• Promo codes and tier management will need to be handled separately per platform — there's no unified promo code system across Stripe + Apple + Google. This is a genuine operational overhead you need to plan for.
• Your backend entitlement logic is the glue — that's where you unify all three platforms and answer the question "does this user have access right now?"

Think of RevenueCat as a "Billing Manager" Employee

• People who signed up on your website (paid via credit card / Stripe)
• People who signed up through Apple's App Store
• People who signed up through Google Play Store

RevenueCat is the Manager Who Talks to All Three Cashiers

1. Talk to Apple's cashier, Google's cashier, and your website cashier
2. Collect all the information
3. Give your front desk one simple answer: "Yes, this person is a valid Pro member" or "No, their subscription lapsed"

A Concrete Example With Your App

• Basic Plan – $9/month
• Pro Plan – $29/month

Without RevenueCat:

• User downloads your app on iPhone, subscribes to Pro
• Apple charges them and sends a receipt — but the receipt is in Apple's own complex format
• You need to build a server that reads Apple's receipt format and verifies it with Apple's servers
• Meanwhile, an Android user subscribes — Google sends a completely different format
• You build another verification system for Google
• A user upgrades from Basic to Pro — you need to handle Apple's upgrade rules, which are different from Google's
• A user's payment fails — Apple sends a notification in their format; Google sends it in their format
• You're now maintaining two completely separate systems, both complex, both with edge cases

With RevenueCat:

• User subscribes on iPhone → RevenueCat handles the Apple receipt automatically
• User subscribes on Android → RevenueCat handles the Google receipt automatically
• Both subscriptions show up in one RevenueCat dashboard
• Your app asks RevenueCat one question: "Is this user on Pro plan?" → Gets back: Yes or No
• If a payment fails, RevenueCat tells you in one standard format regardless of platform
• If a user upgrades, RevenueCat handles it and just updates the answer to your question

Is It Free?

Important: This is only for mobile revenue (App Store + Play Store). Your Stripe / web revenue is separate and RevenueCat doesn't charge you anything on that.

What RevenueCat Does NOT Do

• ❌ It does not process payments — Apple and Google still do that
• ❌ It does not replace Stripe on your website
• ❌ It does not take a cut of your revenue on top of what Apple/Google already take
• ✅ It just manages, tracks, and simplifies everything related to mobile subscriptions

One-Line Summary

RevenueCat is a middleman service that sits between your app and Apple/Google, so instead of building two complex billing systems yourself, you build one simple integration and RevenueCat handles the rest. It's free until you're making real money.