App Store External Purchase Link in the US: commission math, pricing strategy, and whether the bypass is worth it in 2026

The External Link Entitlement lets US iOS apps route users to an external checkout — but Apple still charges a commission and the economics only clear for apps above a certain revenue threshold. Here is what the math looks like and how to think about pricing strategy for the external path.

In April 2024, Apple implemented the External Link Entitlement for US-based apps — a direct result of the Epic v Apple antitrust proceedings. For the first time, iOS developers could include a single, clearly disclosed link inside their app that routes users to an external webpage where they can complete a purchase outside the standard in-app checkout system. By 2026, the feature has had two years to settle, and subscription app teams across categories are asking the same question: is the operational overhead actually worth the commission saving?

This post walks through what the entitlement covers, who qualifies, how the commission math stacks up against standard App Store proceeds, and what a realistic pricing strategy looks like if you go this route.

What the External Purchase Link entitlement is and why it exists

The External Link Entitlement (US) lets you embed a single link inside your iOS app that navigates users to a webpage you control — for the explicit purpose of purchasing digital content. It is not a replacement for your in-app paywall. The link is a navigation option, and Apple wraps it in several mandatory conditions before the user leaves the app.

Before a user taps through, Apple requires your app to display a system-provided disclosure sheet that informs the user they are leaving the App Store payment environment and that Apple's standard buyer protections (such as purchase dispute resolution) may not apply on the external page. You cannot design around this sheet — it is surfaced automatically by the SKExternalLinkAccount API, which is intentional: it ensures disclosure is consistent and cannot be suppressed or styled to minimise its impact.

Additional constraints Apple imposes:

• One external link per app — you cannot offer multiple destinations or payment-provider choices.
• The link must go to a webpage you operate, not directly to a third-party payment UI.
• The destination page cannot be used to direct users to install apps distributed outside the App Store.
• Purchases made through the external path must be reported to Apple for commission calculation — this is not an optional step.

Who qualifies and how the entitlement application works

To use the External Link Entitlement in the US, you must apply through App Store Connect and be approved. Apple reviews each application. The general eligibility criteria that have applied since launch:

• The app must be available in the US storefront.
• The app must not fall into a gaming category — gaming apps are excluded from the US entitlement under the current policy (a separate regime applies to games in some other jurisdictions).
• The developer must agree to Apple's External Link Account Entitlement addendum to the Developer Program License Agreement. Read this document carefully before signing — it sets out the commission reporting obligations.
• The destination webpage must comply with App Store guidelines: it cannot be used to promote alternative app distribution or make misleading claims about Apple's payment system.

Eligibility criteria have evolved since the initial 2024 implementation, and Apple has the ability to update them. If your app occupies a boundary category — a gamified productivity app, for example — it is worth reviewing the current guidelines and potentially contacting App Store Relations before committing significant engineering effort to the integration.

If your primary growth market is the EU rather than the US, a different and in some ways broader framework applies under the Digital Markets Act. Our dedicated post on EU DMA and iOS alternative payments in 2026 covers that regime separately, including the different commission structure and link mechanic that apply there.

The commission math: how the external route compares to standard App Store proceeds

Apple does not waive its commission when you use an external purchase link — it charges a reduced rate. The structure that has applied in the US (always verify current figures against Apple's External Link Account documentation, as these rates have been subject to ongoing legal and regulatory review):

The saving is consistently around 3 percentage points regardless of which tier you are on. That gap is meaningful at scale — but it does not account for the costs on your side of the ledger. Running an external billing system introduces:

• Payment processor fees: Stripe's standard card rate is 2.9% + 30¢ per transaction for most merchants, which absorbs a large portion of the commission saving on low-price subscriptions.
• Engineering overhead: maintaining a web checkout, handling subscription state across two billing systems, and building the attribution pipeline to connect in-app taps to web conversions.
• Fraud and dispute exposure: Apple's payment system absorbs chargebacks and fraud for in-app purchases. On your own web checkout, that risk sits with you (or your processor).
• Disclosure drop-off: a meaningful portion of users who tap the external link will not complete the checkout after seeing Apple's disclosure sheet. This conversion drag is structural — it does not improve with iteration.

For a deeper look at how Apple calculates your base proceeds before any of this arithmetic starts, see how Apple calculates your App Store net proceeds. And if you are on the Small Business Program, review what the 15% commission means for your pricing strategy first — at 12% vs 15%, the incremental saving is small enough that most indie teams will find the operational cost hard to justify.

Pricing strategy for your external purchase page

One underappreciated flexibility the external link enables is price differentiation: Apple does not mandate price parity between your in-app checkout and your external webpage. This creates several strategic options.

Web discount as a conversion incentive. Some teams offer a slightly lower price on the external page — for example, .99/month on the web vs .99 in-app — using part of the commission saving to incentivise users to complete the extra steps. This works best when your audience is price-aware and the app has a web presence that users already trust.

Annual plan emphasis on the external path. The disclosure friction and the browser context-switch tend to filter for higher-intent users. Several operators use the external page exclusively to push annual plans at a reduced effective monthly rate, reasoning that only motivated subscribers will push through. Annual plan conversion on the external path can improve LTV even with lower raw volume moving through the external channel.

Currency and market specificity. The External Link Entitlement in the US applies to the US storefront only. For the rest of the world, standard App Store in-app purchase pricing and mechanics apply (the EU DMA being a separate and distinct regime). In practice, this means you are managing two parallel pricing surfaces: App Store tiers for most of the globe, and your own external checkout pricing for the US market. Run any US external page price changes through the same governance process you use for App Store tier updates — they affect the same user base. Our post on pricing across territories covers how to keep these in sync without creating confusing price signals.

Setting up the entitlement and measuring your external purchase funnel

The implementation sequence in practice:

1. Apply for the entitlement. In App Store Connect, navigate to Agreements, Tax, and Banking and locate the External Link Account Entitlement addendum. Sign and submit — Apple will review your application.
2. Integrate SKExternalLinkAccount. Once approved, use this StoreKit API to surface the external link in your app. The API triggers Apple's mandatory disclosure sheet automatically; you do not need to build or design the disclosure UI yourself, which simplifies App Review.
3. Build or connect your web checkout. The destination page needs to handle subscription creation, payment processing, and post-purchase confirmation. If you already sell web subscriptions (a common pattern for productivity and SaaS-style apps), you may be able to route users to your existing checkout with minimal changes.
4. Instrument the handoff. Append attribution parameters — UTM tags or session identifiers — to the external URL so your web analytics and subscription backend can tie the web conversion back to the specific in-app tap. This link in your data pipeline is essential; without it, you cannot measure whether the external path is performing or optimise it over time.
5. Report sales to Apple. The External Link Account Entitlement documentation specifies how and when external-link sales must be reported to Apple for commission purposes. This is a contractual obligation, and the reporting cadence matters — do not treat it as optional.

Metrics worth tracking separately for external-link subscribers: tap-through rate from the in-app link, drop-off rate at the disclosure sheet, web checkout conversion rate, trial-to-paid rate (if your external page mirrors your trial structure), and month-one and month-three retention compared with subscribers who converted through your standard in-app paywall. Cohort-level retention differences between the two billing paths can reveal whether the self-selection effect of the external route produces meaningfully stickier subscribers — or whether the additional friction selects for users who are harder to retain once the novelty wears off.

Subscription management SDKs can help unify state across the two billing paths. RevenueCat, for example, supports webhook ingestion from external payment processors and can reconcile that data with App Store Server Notifications so your entitlement checks and churn analytics stay coherent regardless of which path a subscriber used to pay.

Is the external purchase link worth it for your app?

For most indie and small-team subscription apps, the honest answer is: not yet. The ~3 percentage point commission saving does not cover the engineering and operational overhead of running a parallel billing system, particularly for developers already on the Small Business Program at 15%.

The calculation looks more interesting for:

• Established apps generating several million dollars per year in US iOS subscriptions. At M in annual iOS revenue, 3 percentage points represents 50,000 — enough to fund meaningful engineering investment with room to spare.
• Apps that already operate a web subscription product. If the web checkout infrastructure exists, the marginal cost of enabling the external path is far lower than building from scratch.
• Apps with a substantial web-first acquisition channel. Users who first encounter your brand on the web, convert there, and then install the app already have a relationship with your external checkout. Routing them back to it is low-friction relative to cold in-app traffic.

For developers who do not fit those criteria, the effort is better directed at improving in-app paywall conversion, refining trial length, or optimising pricing for international markets. The External Link Entitlement represents a genuine structural improvement to the App Store ecosystem — it is now a real alternative where it was once unavailable — but the economics of implementing it require a clear-eyed assessment of your revenue scale, existing infrastructure, and user acquisition mix before committing.

Sources and further reading

• App Store Review Guidelines (Apple Developer) — authoritative source on external link eligibility and restrictions
• StoreKit documentation (Apple Developer) — includes SKExternalLinkAccount API reference
• Apple Developer Support — for current entitlement application process and commission reporting requirements
• RevenueCat Blog — subscription analytics, SDK integration, and multi-path billing guides
• Phiture Mobile Growth Stack — ASO and monetisation research for App Store developers