One subscription, three payment platforms

A consumer app that wants to sell subscriptions everywhere its users are ends up needing three completely different billing relationships: Stripe on the web, Apple's In-App Purchase on iOS, and Google Play Billing on Android. Each has its own receipt format, its own webhook or server-notification model, its own rules about refunds and cancellations, and its own idea of what a "subscription" even is. MamaPapa needed all three, because it's a family app and families are split across web, iPhones, and Android phones, often within the same household.

The rest of the app shouldn't know which provider granted access

The core design decision was to keep the provider-specific mess contained at the edges and expose one clean concept internally: an effective tier. Every feature check in MamaPapa (can this user upload video, can this family unlock another storybook, how much cloud storage do they have) asks "what's this user's effective tier" and gets a plain answer, without caring whether that tier came from a Stripe subscription, an Apple IAP receipt, or a Google Play purchase. All three providers' state gets normalized down to the same shape before anything else in the app touches it.

That sounds obvious in hindsight, but it's the difference between adding a fourth billing provider being a contained, provider-specific integration versus a change that ripples through every feature gate in the codebase.

The genuinely hard part: switching providers

Normalizing read access is the easy half. The hard half is what happens when a user who's paying via Apple decides they'd rather manage their subscription on the web through Stripe instead. The obvious-sounding approach (just start the new subscription and consider the user "upgraded") leaves a landmine: app stores can't be cancelled from a server. Only Apple or Google, acting on the user's own device or account settings, can actually stop billing an IAP subscription. If MamaPapa silently switched a user's effective tier to their new Stripe plan while their old Apple subscription kept auto-renewing in the background, that user would end up paying two providers for one app indefinitely, with no obvious way to notice.

So a cross-provider switch is handled as an explicit two-part operation: activate the new provider's subscription, and walk the user through actually cancelling the old one through that provider's own cancellation flow, since that's the only place cancellation can actually happen. The system tracks which provider is the current source of truth for a user's billing at any given time, specifically so it can detect this situation and surface it, rather than silently trusting whichever provider's webhook fired most recently.

Token currency sits on top, not underneath

Storybook generation (MamaPapa's AI-illustrated storybook feature) uses its own token currency layered on top of the subscription tier rather than being another tier-gated toggle. A family's plan determines their monthly token allowance; tokens are what actually get spent per generation. That separation exists because "how many storybooks can you make this month" turned out to be a much more natural unit for both users and pricing than trying to encode it as yet another permission bit alongside video uploads and storage limits. It also meant the token system could evolve (different generation types costing different amounts, top-ups, rollover rules) without touching the underlying multi-provider billing plumbing at all.

The result is a billing system where three fundamentally different payment platforms feed into one tier concept, one token ledger sits cleanly on top of that, and the parts of the app that actually gate features never had to learn the difference between an Apple receipt and a Stripe webhook. Read more about how that pricing shows up for users on MamaPapa's product page.