11.7 — How Major Apps Handle Payments

Opening scenario

You’re staring at your own paywall, trying to decide: do I add an annual tier? Do I link out? Do I show prices in-app? You spend an hour googling “best iOS subscription strategy” and read 30 contradictory blog posts. Then you open Netflix, Spotify, Amazon Kindle, Duolingo, Calm, and Groupon side-by-side and observe what they actually ship. In 20 minutes you understand the entire field. The opening lecture they don’t give you in any monetization course: the field is your competitive intelligence.

This chapter is that 20 minutes, distilled.

Context taxonomy

PatternUsed byWhyApple cut
Reader app (no in-app signup)Netflix, Amazon Kindle, AudibleSubscription set up on web; iOS is consumption only0%
Reader app + External Link EntitlementSpotify (EU), some news appsAdds one “subscribe at our website” link0% on external, but Apple still claims 27% in US
StoreKit-onlyCalm, Headspace, Duolingo SuperFriction-free in-app conversion; mass-market15–30%
StoreKit + external upsell tierYouTube Premium (lower price on web)Hybrid — App Store for impulse, web for power users15–30% on StoreKit purchases only
Stripe (physical/services)Uber, Lyft, Amazon Shopping, GrouponApple has no claim on physical/real-world0%
Enterprise direct contractSalesforce, Workday, Slack BusinessB2B sold via direct sales0% (Apple Business Manager)
Alternative payment processor (EU DMA)Spotify (EU), Epic Games Store (EU)EU regulation allows; pass savings to users17% Apple + CTF
Family Sharing as growth leverApple Music, CalmBundle anchors expansion within household15–30%
Promotional offers as retentionDuolingo, NYT, Disney+Win back lapsed subscribers at discounted intro15–30% on the discounted amount

Concept → Why → How → Code

Concept. Every major app has architected payments around a specific business reality: their CAC, their LTV, their global distribution, their legal exposure. By reverse-engineering them you absorb decades of A/B-tested strategy.

Why. No one will publish their playbook. The apps in your App Store are the playbook. Reading them is faster and more accurate than any guide.

Case study 1 — Netflix (the reader-app gold standard)

What you see in the iOS app:

  • Open → login screen, no signup option
  • Successful login → content browser
  • “Manage account” tab → opens netflix.com in Safari

What this earns Netflix:

  • 0% Apple commission on subscriptions
  • Estimated annual savings: ~$800M+ at current scale (200M+ subscribers, ~$15/mo each)
  • Tradeoff: ~5–10% lower iOS new-subscriber conversion vs in-app signup. They accept the tradeoff because LTV math at their scale dwarfs CAC math.

How they made it work:

  • Massive cross-platform brand → people search “Netflix” in the App Store after signing up on web
  • Strong UX of the login flow (Apple ID sign-in, magic-link options)
  • Explicit Apple agreement (one of the original reader-app exception holders)

When to copy: you have a strong brand, web-first signup flow, and your math says LTV justifies the conversion loss.

EU version (post-DMA 2024):

  • Free tier with ads available globally
  • In-app upgrade flow uses Spotify’s own payment system
  • Prices ~10% lower than App Store equivalent (savings passed to user)
  • Apple commission: 17% + Core Technology Fee
  • Net to Spotify: still ~5–10% better than StoreKit’s 15–30%

US version (post-2024 court ruling):

  • External purchase link added to in-app upgrade flow
  • Web checkout offers $9.99/mo vs $14.99/mo on iOS direct
  • Apple still claims 27% on external purchases — Spotify disputes this is collectible in practice

Pre-2024 (the famous “Spotify can’t tell you the price” era):

  • iOS app intentionally hid pricing
  • Cryptic “go to our website to subscribe” with no link
  • Notoriously bad UX, but cheap

When to copy: you have meaningful pricing power, large EU/US user base, and the engineering bandwidth for alternative payment infrastructure.

Case study 3 — Duolingo (StoreKit-only mass-market with aggressive intro)

What they ship:

  • Free tier with ads (the acquisition engine)
  • Super Duolingo $6.99/mo or $59.99/yr (14-day free trial)
  • Duolingo Max $29.99/mo or $167.99/yr (AI-powered features)
  • Family Plan $9.99/mo (up to 6 users)
  • All via StoreKit; no external links

Retention tactics observed:

  • Aggressive 14-day free trial with friction-free conversion
  • “Streak” mechanic that creates psychological switching cost
  • Win-back offers (50% off first 3 months) sent to lapsed subs
  • Promotional offers issued during major holidays
  • Family Plan as natural expansion vector

When to copy: mass-market consumer app, casual price points (< $10/mo), strong daily-use loop.

Case study 4 — Calm (subscription + A/B paywall optimization)

What they ship:

  • 7-day free trial → $69.99/yr (charged annually)
  • Family Plan $99.99/yr
  • A/B testing of paywall presentation via RevenueCat-style infrastructure
  • Promotional offers for lapsed users

What’s not obvious from the surface:

  • The “1-year for $69.99” is psychologically anchored against the implied “$13.99/month” — they don’t even sell monthly prominently because annual converts much better
  • Free trial → annual auto-conversion produces 6× the LTV of monthly conversions
  • They’ve reportedly tested 200+ paywall variants

When to copy: high-engagement habit app where annual makes psychological sense.

Case study 5 — Amazon Kindle (the cleanest reader app)

What you see:

  • Open → empty library if not logged in
  • Login screen
  • Logged in → book library
  • No “Buy this book” button anywhere
  • No price displayed on any book
  • Tap a sample → read sample, but no purchase flow

The trick: Amazon assumes you already bought the book on amazon.com. The iOS Kindle app is only a reader. Buying happens on web or in the Amazon shopping app.

This is the platonic ideal of reader-app architecture. Implementation is so strict that even tapping “buy this book” doesn’t exist in the iOS UI.

When to copy: you have a parent ecosystem (web, other apps) where purchase naturally happens.

Case study 6 — Groupon, Uber, Lyft (physical / real-world)

These never used StoreKit because they’re selling real-world stuff. Stripe, Adyen, or proprietary processors handle payment. Apple Pay surfaces are used for UX convenience (fingerprint/Face ID confirmation) — but the payment processor is the merchant’s, not Apple’s.

// Lyft pseudocode — Apple Pay as auth, Stripe as processor
PKPaymentAuthorizationViewController(paymentRequest: req) { result, completion in
    Task {
        // Send payment token to Lyft backend
        let chargeResult = try await lyftAPI.charge(
            stripeToken: result.token,
            amount: rideAmount
        )
        completion(chargeResult.success ? .success : .failure)
    }
}

Apple commission: 0%.

Case study 7 — Enterprise SaaS abstraction pattern

Slack, Zoom, Salesforce, Workday: the iOS app is a thin client of a web-managed service.

  • Buying seats happens via your admin’s web console or direct sales contract
  • iOS app: login-only, no plan management
  • Apple Business Manager handles enterprise distribution + invoicing if applicable
  • Apple commission: 0%

This is the same pattern as reader apps, applied to B2B.

Calm vs Headspace — same category, different choices

Both: meditation, subscription, 7-day free trial, ~$70/yr
                                 ↓
Calm                            Headspace
- StoreKit-only globally        - StoreKit + extensive web upsell
- A/B paywall heavy             - More conservative paywall variants
- Family Plan in-app            - Family Plan via website only
- Higher iOS ARPU               - Lower iOS ARPU but better margin on web conversions

Same product space, two valid architectures. Both companies have public revenue data; neither is obviously winning. The architecture flows from organizational structure (Calm is iOS-strong, Headspace is web-strong) more than user behavior.

In the wild

  • Apple TV+ uses StoreKit but bundles via the Apple One subscription — Apple absorbs the bundling math internally.
  • Disney+ initially used StoreKit only; added a “lower price on web” path after 2024 ruling for new US subscribers.
  • YouTube Premium charges $13.99/mo on iOS but $11.99/mo on web (Apple-tax-pass-through). They link to web from the iOS app.
  • Tinder/Match Group sued Apple in EU (2023), forced policy concessions, now uses both StoreKit and external payments depending on region.
  • Telegram Premium charges $4.99/mo via StoreKit but offers the same subscription cheaper on their website (~$2 if paid via crypto).

Common misconceptions

  1. “Reader apps lose conversion to in-app signup.” They do — 5–15% typically. They make it back in commission savings, often 10×.
  2. “You have to pick StoreKit OR external.” Many large apps use both: StoreKit for impulse iOS buyers, external links for power users seeking a deal.
  3. “Apple punishes apps that link externally.” They have process requirements (System Disclosure Sheet, entitlement application) but they don’t algorithmically punish.
  4. “Alternative payment processors are the future of EU.” Math says only for very high-volume apps. Many EU developers stayed on StoreKit because CTF + 17% > 30% on small scales.
  5. “Reader apps just give up in-app revenue.” They give up in-app conversion. They still earn revenue from the same users — just collected elsewhere.

Seasoned engineer’s take

TIP. Audit the top 20 apps in your category. Note for each: payment model, has free trial, monthly vs annual, family plan, in-app vs external upsell, A/B paywall (you can spot RevenueCat by the variation between cold installs). Within an hour you’ll have the field’s playbook.

WARNING. Copying surface UX without copying the underlying math is dangerous. Spotify can run a complex external-payment flow because they spend $30M+ on backend infra. You probably can’t justify that at $100k MRR.

The most underrated lesson: payment architecture should be revisited yearly. The 2024 court ruling changed US options; the 2024 DMA changed EU options; the 2025 Patreon exception changed creator-economy options. What was correct in 2023 might be leaving money on the table in 2026.

Interview corner

Junior“How does Netflix handle payment on iOS?” Reader app pattern — login only, no in-app signup or pricing. Subscription happens at netflix.com. Saves Apple’s 30% commission.

Mid“You’re building a B2B SaaS app. How do you handle payments?” Web-first signup with Stripe. iOS app is reader-pattern: login-only, no plan management. Apply for the External Link Entitlement to surface one “Visit acme.com for plans” link in-app. Apple’s commission: 0% on web purchases.

Senior“Design payment architecture for a global app launching simultaneously on iOS US, iOS EU, Android, and web.” Web payments via Stripe with PaymentIntents. iOS US: StoreKit primary + External Link Entitlement to web checkout (offers $X discount). iOS EU: evaluate alternative payment based on volume — at scale, switch to alternative; below 1M installs/yr, stay StoreKit. Android: Google Play Billing primary + external links permitted post-2024. Web: Stripe. All providers feed a unified subscription state machine keyed by user ID; entitlement queries go to your server, never trust client.

Red flag“We made architectural decisions based on a 2021 blog post.” Re-evaluate. The post-2024 regulatory landscape changed everything.

Lab preview

Lab 11.1 implements a StoreKit + RevenueCat paywall. Lab 11.2 covers automated pricing — the operational layer of any of these strategies.


Next: 11.8 — Enterprise & B2B Distribution