In the European Union you can send your iOS users to pay for a subscription outside In-App Purchase, from inside the app, with an actionable link. This isn't a grey area: there's an entitlement, an addendum your Account Holder signs, a StoreKit API for the disclosure sheet, and an obligation to report every transaction to Apple so it can invoice you its share.

That last sentence is what decides whether the project pays off. Apple still charges. What changes is how much, and everything that becomes yours: the payment gateway, fraud, refunds, tax, support and a monthly report.

Here's how it's done, top to bottom.

First: pick your addendum

There are two entitlements and they're mutually exclusive. Both must be accepted by your account's Account Holder:

External Purchase Link Entitlement, under the Alternative Terms Addendum for Apps in the EU.
StoreKit External Purchase Link Entitlement (EU) Addendum.

The practical difference is the fee structure — the first carries a per-install technology fee, the second a commission on sales — so the choice is made with the numbers in front of you, not by technical preference.

What Apple will charge you

This is where most estimates fall apart, because it isn't one commission: it's three layers that stack.

Under the StoreKit External Purchase Link Entitlement (EU) Addendum:

Item	Tier 1 (mandatory)	Tier 2 (optional)	Program rate*
Initial acquisition fee	2%	2%	0%
Store services fee	5%	13%	5% / 10%
Core Technology Commission (CTC)	5%	5%	5%

Under the Alternative Terms Addendum, the same first two layers and, instead of the CTC, the Core Technology Fee (CTF): €0.50 per first annual install, for apps exceeding one million first annual installs per year.

* The program rate applies to App Store Small Business Program members and to subscriptions after their first year.

What each one applies to:

Initial acquisition: purchases within 6 months of the customer's first install.
Store services and CTC: all sales within 12 months of the most recent install, update or reinstall.
Both include adjustments for refunds, reversals and chargebacks.

What they do NOT apply to, and this is real money:

Auto-renewals of subscriptions entered into before the app included the entitlement.
Transactions made outside the app without an actionable link.
Sales using In-App Purchase.

Do the maths on your own case before reading further: on Tier 1 at standard rates you're looking at 12% during the customer's first six months and 10% after, plus your gateway, plus the operational work. Compared with 30% or 15% on In-App Purchase there's margin — but it isn't free, and there's a floor of complexity that doesn't go down.

The rule that decides your architecture

"Due to the App Store's tight integration with In-App Purchase and to reduce confusion for users, you won't be able to offer In-App Purchase while communicating and promoting offers within the same app on the same App Store storefront and platform."

One or the other, per storefront. You can decide app by app and storefront by storefront, but not mix within the same one. Which means your app has to support two monetisation modes depending on the user's storefront country, and that choice isn't a setting: it's a product branch.

Implementation, step by step

1 · Entitlement and provisioning profile

Once the addendum is accepted, the account receives the entitlement. Enable it in Xcode from the capability library or on the developer portal:

com.apple.developer.storekit.external-purchase-link  →  Boolean  →  true

Adding the capability to the App ID means you must regenerate the provisioning profile. This is what most often breaks the first CI build: the cached profile doesn't have the capability and signing fails without saying why.

2 · Info.plist: the regions

<key>SKExternalPurchaseCustomLinkRegions</key>
<array>
  <string>es</string>
  <string>fr</string>
  <string>de</string>
  <!-- … -->
</array>

Valid codes are the 27: at, be, bg, hr, cy, cz, dk, ee, fi, fr, de, gr, hu, ie, it, lv, lt, lu, mt, nl, pl, pt, ro, sk, si, es, se.

Minimum versions: iOS and iPadOS 17.4, macOS 14.4, tvOS 17.4, visionOS 1.2, watchOS 10.4. Below those the functionality doesn't exist, so the app needs an alternative path for users on older releases.

3 · The URLs, which you no longer declare

Since autumn 2024 this got considerably simpler: you can use any number of URLs without declaring them in Info.plist, and parameters, redirects and intermediate landing pages are permitted.

That enables what any serious product team needs: passing user ID, campaign and offer in the URL, and landing on your own page before checkout.

4 · Eligibility, before showing anything

On iOS 18.1 and later it's a single property:

if ExternalPurchaseCustomLink.isEligible {
    // show the offer communication
}

Below 18.1 you implement the three checks manually:

canMakePayments() — if false, no eligibility.
Read the current storefront with Storefront.current and its countryCode.
Verify that storefront is among the permitted regions and that your app supports external purchase in that region.

You'll have to write that fallback anyway while you support older versions, and it's where the odd bugs live: a Spanish user whose storefront is set to another country isn't eligible even if they're physically in Spain. The storefront decides, not the location.

5 · The disclosure sheet, mandatory

Not optional and not customisable:

"When taking users to their destination using an actionable link (i.e., a link that can be tapped, clicked, or scanned), your app must use the ExternalPurchaseCustomLink API to display a system-provided disclosure sheet that explains to the user they'll be transacting with the developer and not Apple."

You call showNotice(type:) after a deliberate customer interaction — tapping a button — and before linking out. The sheet includes a continue button and a "Show This Reminder Next Time?" option.

For link design, Apple publishes templates localised in 40 locales, using the plain button style, along the lines of "Purchase from the website at www.example.com" or "Lower prices offered on www.example.com".

And one metadata restriction that gets forgotten: you can't include information about external purchases on your App Store product page. The communication lives inside the app.

The part nobody budgets: reporting

This isn't a compliance detail. It's a subsystem of your backend, and it's half the project.

"If your app adopts the StoreKit External Purchase Link Entitlement, you're required to use the External Purchase Server API to report transactions to Apple for applicable commission and fee calculation and collection purposes."

Tokens

At app launch you request tokens with token(for:), using two types:

ACQUISITION — tied to the customer's initial acquisition.
SERVICES — tied to the store services window.

Those tokens are associated with the customer's account on your server. That's the critical design piece: if your product has no persistent identity of its own, there's nowhere to store them, and without them you can't report correctly.

What must be reported

And here's what surprises every team:

Refunds.
Corrections.
Renewals.
One-time purchases.
And transactions which didn't result in a purchase.

That last one means instrumenting the whole funnel, not just success. If your payment site doesn't notify failed attempts to your backend, you're missing information you're obliged to send.

The monthly report

"You're required to send a report to Apple recording all sales of digital goods or services made on any platform. You need to provide this report monthly, within 15 calendar days following the end of Apple's fiscal month."

Read that carefully: all sales on any platform, not just the ones originating on iOS. And on Apple's fiscal calendar, which doesn't line up with the calendar month.

And the invoice

Apple aggregates transactions and calculates commissions by the 15th of the following month, and you have 30 days to pay from receiving the invoice. Late payment accrues interest and can end in offset against your In-App Purchase proceeds, removal from the App Store and removal from the Apple Developer Program.

In other words: this enters your company's billing cycle, with an owner. It isn't a mobile-team task.

What becomes yours

Apple says it plainly: if you adopt the entitlement, Apple won't be able to help your customers with refunds, purchase history, subscription management or other issues.

Translated into real work:

Payment gateway, with its integration, local methods and rate.
Tax: VAT per country is yours, or your provider's.
Refunds and disputes, with a policy and people behind it.
Subscription management: plan changes, pauses, cancellations. Everything the system's subscription settings do today.
Fraud and chargebacks.
Support, which generates the most volume.
Failed payment recovery, a discipline of its own in web subscriptions.

And one product detail visible in the metrics: taking the user out of the app breaks the funnel. You lose people at the jump, at the disclosure sheet and at web checkout. Measure that drop-off before celebrating the commission saving.

Architecture that survives both routes

Since the app has to support In-App Purchase in some storefronts and external payment in others, the only way this doesn't become a tree of conditionals is an entitlements layer:

Your backend is the source of truth for what each user has.
The app asks about the entitlement, never about the receipt or StoreKit state.
Payment mechanisms are providers feeding that table: In-App Purchase on one side, your gateway on the other, each with its webhook.
The user's storefront decides which mechanism is offered, and that's presentation data, not business logic.

With that, enabling external payment in a new country is configuration; and when the rules change — they will — you touch the provider, not the product.

When it pays off, with numbers

Before opening the project, three calculations:

Annual subscription volume in EU storefronts, separating first year from renewals. Remember renewals of subscriptions entered into before the entitlement fall outside these fees.
Gross saving: current commission minus the sum of the layers that apply to you.
Real cost: gateway, tax, building the reporting, support, payment recovery, and the conversion loss from the jump out of the app.

If you already run a web subscription platform — with its billing, tax and support — the maths usually works. If the app is your only channel, you're building a billing business from scratch to save a few points.

Implementation checklist

Fourteen items, and only five belong to the app. That ratio is the real answer to "how much does it cost to get out of Apple's commission?".

Primary sources, consulted on 14 August 2026: Communication and promotion of offers on the App Store in the EU and Updates to the StoreKit External Purchase Link Entitlement, Apple Developer. Fees change: check them against that page the same day before committing to a model.

External payment for iOS subscriptions in the EU: a technical guide