Over the past few years Apple and Google have opened the door for app-to-web, allowing developers to use external purchase flows for in-app subscriptions; making it possible to bypass app store fees and have more flexibility with pricing, promotions, and checkout experiments.
This has largely come about from court rulings like Epic Games v. Apple in the US and the Digital Markets Act in the EU, ultimately forcing Apple and Google to loosen strict requirements around in-app purchases (IAP).
For app teams, this opens up a new realm of app-to-web possibilities — but when it comes to the regulations surrounding app-to-web, it’s not quite so clear cut. New guidelines are constantly appearing and evolving, varying by country and app category, so it’s difficult to keep up with what’s allowed (or not).
To help, we’ve broken down the latest options, eligibility requirements, and commissions/fees for external payments around the world, on both the Apple App Store and Google Play Store. Here’s everything you need to know.
How external purchases with app-to-web work
Here’s a quick overview on how external purchases work, and the two primary ways to incorporate them in your app.
If you want to jump straight to Apple and Google’s purchase guidelines, click here.
1. External web link
Your app includes a link or button that sends the user to an external website (or opens a webview) where the user completes the purchase. The app then unlocks content/features based on that external purchase (usually by syncing with your backend).
Apple refers to this as using an External Purchase Link. For instance, a streaming app might have a “Subscribe on our website” button that opens its web checkout. After payment, the user can log into the app with the new subscription.
2. Third-party payment (in-app)
Your app integrates a non-Apple/non-Google payment gateway directly in the app’s UI. The purchase happens within the app, but not via App Store/Google Play billing. This is sometimes called alternative in-app payment.
A common example is using Stripe for in-app purchases, or showing a country-specific credit card form at checkout in lieu of App Store purchase dialogs.
While this used to be far trickier to implement, Apple v. Epic has meant third-party payments are much easier to use these days. However, Apple and Google have strict rules if you choose either of these paths:
Implementing third-party payment with Apple
- You’ll need to request Apple’s special entitlements before offering any kind of external purchase flow
- Depending on what you’re building, you’ll use either the External Purchase Link API (to send users to your web checkout) or the External Purchase Entitlement (to run a third-party payment flow inside the app)
- Before users leave the app or pay through a non-Apple method, Apple shows a built-in disclosure sheet letting them know the purchase isn’t handled by the App Store
- In some cases, if you use an external purchase entitlement, you cannot also offer Apple IAP in the same app in that region — it’s one or the other on a given storefront
Implementing third-party payment with Google
- Google’s User Choice Billing means the user is offered a choice between Google Play’s billing and an alternative billing method during checkout
- Developers must integrate Google’s alternative billing API to present this option
- For External Offers (EEA only), the app can directly link out to a purchase web page (and Google will display a ‘leaving Play’ prompt to users on tap)
- Like Apple, there are cases where you’re not allowed to mix standard Google Play Billing IAP with external offers
In-app purchases vs. external purchases: guidelines and regulations for Apple and Google
Most apps on both the Apple App Store and Google Play Store use the platform’s built-in billing system for subscriptions and digital goods. By default, you’re not allowed to direct users to a different payment flow inside your app unless you qualify for (and opt into) one of the external-purchase programs covered below.
For standard in-app purchases, each app store takes a cut. The standard commission for both Apple and Google Play is 30%, but both stores reduce this to 15% for developers making less than $1M/year from IAP. On Google Play, the 15% rate is also applied to recurring subscriptions after the first year.
To avoid these fees, apps are allowed to offer external purchases, as long as they adhere to the following guidelines:
Apple App Store external purchases guidelines
| Region/program | Eligible apps | What’s allowed for external payments | Commissions/fees | Notes and references |
| United States: External Purchase Links | All app categories in the US App Store (including games) | Can include external payment links in-app to a web checkout | 0% Standard App Store commission (15–30%) still applies to any purchases made via IAP | App Store Review Guidelines (United States) |
| EU/EEA: communication and promotion of offers Alternative terms/StoreKit External Purchase Link | All apps on an EU or EEA storefront | External purchases or payments allowed via link-out or third-party processing | If using IAP: 10-17% commission+ 3% payment processing If using external purchases: 2% Initial Acquisition fee + 5-13% (depending on optional store services) + €0.50 Core Technology Fee per first annual install over 1M | Requires opt-in to the Alternative Terms Addendum for Apps in the EU and/or StoreKit External Purchase Link Entitlement for EU storefronts Communication and promotion of offers on the App Store in the EU |
| EEA: music streaming services entitlement | Music streaming apps | External subscription link or button allowed to your website | Up to ~27% commission (roughly the normal 30% cut minus ~3% payment processing) If you instead opt into the EU Alternative Terms, external purchases are subject to the EU fee stack above (2% + 5–13% + 5% etc.) rather than a flat 27% | Music streaming services entitlement (EEA) |
| Netherlands: dating apps | Dating apps exclusive to the NL storefront | Alternate in-app payments and/or external link to web purchase are allowed alongside Apple IAP | Normal App Store commission minus 3% (e.g. 27% instead of 30%, 12% instead of 15% for small business/long‑running subs) | Distributing dating apps in the Netherlands |
| South Korea: StoreKit External Purchase Entitlement | All apps distributed solely on the South Korea App Store using a qualifying third‑party PSP | Alternate in-app payment providers allowed (no Apple IAP required) You cannot also offer IAP in the same SK app | 26% | Distributing apps using a third‑party payment provider in South Korea |
| Global: reader apps (External Link Account Entitlement) | ‘Reader’ apps whose primary purpose is providing magazines, newspapers, books, audio, music, or video, and that let users sign in to access previously-purchased content | Can include one link to your website for account creation and management The link must open in a browser Cannot offer IAP in the same app | 0% | Distributing reader apps with a link to your website |
Google Play Store external purchases guidelines
| Region/program | Eligible apps | What’s allowed for external payments | Commissions/fees | Notes and references |
| User choice billing: Australia, Brazil, Indonesia, Japan, South Africa, United Kingdom, United States and EEA | Non-game apps in Australia, Brazil, Indonesia, Japan, South Africa, United Kingdom, and United States All apps in EEA, South Korea, India | ‘User choice billing’ (UCB): apps can offer users a choice between Google Play’s billing and an alternative in-app billing method | If using IAP: 15% for the first $1M/year in revenue 30% above $1M/year If using external billing system: Normal service fee minus 4% (e.g. 11% instead of 15%, 26% instead of 30%) | User choice billing on Google Play |
| EEA: alternative billing only (no Google Play Billing in the app) | Apps targeting users in the EEA that want to remove Google Play Billing entirely and use only their own billing in‑app | You complete in‑app transactions through your own (or third‑party) billing system only You are not allowed to offer Google Play Billing as an option in the same app | Standard Google Play service fee minus 3% (e.g. 12% instead of 15%, 27% instead of 30%) | EEA alternative‑billing program |
| EEA: external Offers Program (link‑out program) | Apps in the EEA that want to promote offers in‑app and send users outside the app (browser, other store, webview) for purchases/subscriptions | You can show in‑app promotional units and hyperlinks (‘linkouts’) that take users to your site or other destinations to purchase digital items or subscriptions | 3% Initial Acquisition fee + 10% (required) Tier 1 service fee + 3% / 10% (optional) Tier 2 fee (10% for IAP or +3% for subs) + Variable per-install fees depending on app category | Fees are additive, so a typical Tier‑1 setup is roughly 13% on external sales, while Tier 1+2 can reach the mid‑20% range for some offers Changes to the external offers program for users in the EEA (includes IA %, Tier 1/2 fees, per‑install fee tables) |
Adding web checkout options to your app
If you’re reading this far, you’re probably already sold on app-to-web. The hard part isn’t why; it’s how to ship it quickly, stay compliant, and not turn your purchase flow into a science project.
RevenueCat Web is the simplest way to add a web checkout to a subscription app. Instead of stitching together a payment processor, entitlement sync, identity mapping, and analytics on your own, you get a full web billing stack that plugs into the RevenueCat setup you already use for mobile. Users can buy on the web and unlock access in iOS or Android right away, with one subscriber record and one source of truth.
Here’s how the pieces fit together:
Web Billing as your billing engine: Web Billing is RevenueCat’s native billing engine for web subscriptions. It manages the subscription lifecycle on the web and stays fully integrated with your RevenueCat products, customers, and entitlements. You don’t have to build or maintain separate web billing logic.
Web checkout surfaces that you can launch in minutes: once Web Billing is on, you can direct users to web checkout in a few different ways:
- Web Purchase Button inside your in-app paywall: add a button component to any RevenueCat Paywall; tapping it sends users to a web checkout
- Web Purchase Links: RevenueCat-hosted checkout URLs you can drop anywhere, including behind the Web Purchase Button — they work out of the box and support identified or anonymous flows
- Web Paywalls shown via the Web SDK: if you have your own web app or landing pages, you can render a RevenueCat Paywall directly on your site through Purchases.js, then complete checkout there
Everything stays connected. The Web overview dashboard shows you everything in one place, and your web and mobile offerings live in the same catalog, entitlements sync automatically, and events flow into the same analytics layer.
How to keep app-to-web conversion strong
Teams usually worry that a web step will convert worse than native checkout. This can be easily avoided by sending users to a web paywall that completes the purchase on the same page (aka, RevenueCat’s Express Purchase button).
If Apple Pay or Google Pay is available in the browser, a wallet button shows on the web paywall. The user taps once, confirms in their wallet, and the purchase completes. RevenueCat then syncs access back to the app automatically.
This keeps the handoff short: paywall in app → paywall on web → wallet confirmation = access unlocked.
Examples of app-to-web
- In-app upgrade with a web option: your in-app paywall includes a ‘Continue on web’ button. The web paywall opens with the same plan selected, and a wallet button appears when supported. Users who want a faster checkout finish in one tap.
- Win-back discount: a churned user sees a targeted in-app paywall with a comeback offer. The web button routes to a separate web offering with the discount already applied, so the user doesn’t need to hunt for the right plan.
- Campaign traffic you can measure: You share a Web Purchase Link in ads or email with UTM parameters intact. After purchase, a redemption step links the subscription to the user’s app account and unlocks access right away. You get clean attribution without custom glue code.
Ready to experiment with app-to-web?
As app-to-web guidelines continue to shift, your success depends on keeping checkouts flexible and compliant. We’ll keep this guide updated as Apple and Google refine their policies, so bookmark it and check back whenever you’re planning your next app-to-web iteration.
Whether you experiment with custom checkout code or get RevenueCat Web to do the heavy lifting, app-to-web can be an efficient and flexible purchase flow. Good luck, and happy testing!