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 o