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

Japan: Mobile Software Competition Act (MSCA)

All iOS apps on Japan App Store (all categories) with required entitlements

App-to-web purchases via Out-of-App Offers (external links to web checkout)

Alternative in-app payments via Alternative Payment Processing (non-Apple PSPs)

In-app display of prices and promotions for web purchases

Apple IAP and external payment options must coexist and be shown side-by-side

Alternative Payment Processing: 21% (10% reduced cases)

Out-of-App Offers (web): 15% (10% reduced cases; applies to renewals)

Apple IAP: 21% + 5% payment processing (10% + 5% reduced)

Alternative app marketplaces: 5% Core Technology Commission

External payments permitted under MSCA; Apple implements via entitlements, StoreKit APIs, disclosures, parity UI, default-browser links, and age restrictions

Read Apple’s announcement here.

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)

Japan: Mobile Software Competition Act (MSCA)

All apps distributed on Google Play in Japan (games and non-games), via program enrollment

User Choice Billing (UCB): side-by-side alternative in-app billing expanded to all apps

App-to-web purchases via new Google Play link-out program

In-app display of prices and promotions for web purchases

Google Play Billing and external options may coexist

Google Play Billing: 15% for first $1M/year, 30% above

Alternative in-app billing (UCB): standard service fee minus ~4%

App-to-web purchases: competitive fees via Google program (rates defined by Google)

MSCA compliance via expanded UCB and new app-to-web program; participation subject to APIs and safety/security requirements

Read Google’s announcement here.

United States: External Content Links Program (ECLP)

All apps and games on Google Play serving users in the US (mobile and tablet)

Developers can link users to an external website for in-app digital purchases or app downloads. Can be offered alongside or instead of Google Play Billing. Info screen shown before redirect.

Currently 0% (not yet enforced). Proposed: 10% subs, 20% other digital purchases. First $1M/year at 10%. Downloads: $3.65/install (games), $2.85/install (apps).

Created under Epic v. Google injunction. Enrollment required by Jan 28, 2026. Fees pending settlement ruling. Requires Google’s external links APIs.

Enrolling in the external content links program for users in the US

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!