External payment links on iOS are not governed by one worldwide rule. Whether you can add one, and what it can say, depends on four separate variables: what the customer is buying, which storefront the download happened on, whether the app matches a documented entitlement or category, and which distribution terms your developer account is actually operating under. Get any one of the four wrong and a link that is legal in one storefront becomes a guideline violation in another.
Do not ship a single global link based on a US or EU headline you read once. Work the four variables below in order, read Apple’s live terms for your account, and get professional advice before treating any of this as a commercial or legal conclusion.
This workflow was checked against App Review Guidelines and Distributing reader apps with a link to your website on 4 August 2026. The first source controls the guideline text; the second supports the reader-app implementation boundary referenced below.
The short version
- Classify the purchase: digital content or functionality, physical goods, or a real-world/person-to-person service.
- Map every storefront the app is distributed on; a permission that exists in one does not travel to the rest.
- Check whether the app matches a documented entitlement or category, such as a reader app or the EU external purchase entitlement.
- Confirm which distribution/business terms your account has actually accepted. A capability you have not agreed to is not a capability you can ship.
- Request the narrowest link scope that covers your real use case, not a broad permission you might grow into.
Use the broader iOS subscription and in-app purchase review guide for the ordinary StoreKit release chain. Stay here when the disputed feature is a link that sends users outside that chain, because storefront and entitlement determine the decision.
Variable 1: what the customer is buying
Digital content or functionality consumed inside the app falls under Apple’s in-app purchase rules by default. That default only moves if a documented exception, entitlement, or regional option applies to your specific case; it does not move because a competitor’s app links out. Physical goods and real-world, person-to-person services are evaluated under different guideline language and can route around in-app purchase entirely, provided the transaction genuinely happens outside the app’s digital-content scope.
Write the classification in one sentence before doing anything else: “This purchase is [digital content / physical goods / a real-world service] because [reason].” If you cannot finish that sentence without hedging, resolve the classification before touching a payment processor or a link.
Variable 2: which storefront the app is on
Apple’s guideline changes for external links are not uniform across storefronts. Apple announced US storefront changes on 1 May 2025 in response to a US court order, and separately maintains a distinct set of terms for apps distributed in the European Union. A worldwide app is not one app for this purpose: it is one binary distributed into several separate regulatory environments, and each one needs its own answer.
List every storefront where the app is actually live, not just the ones you designed for. A link permitted under the US terms and shown to an EU or rest-of-world account is a different guideline violation, because the EU and RoW paths do not share the US legal basis.
Variable 3: entitlement or category fit
Some categories have a documented, named path to an external link. Reader apps have a dedicated Apple support page and an entitlement process for apps that let users access previously purchased content or content subscriptions. Multiplatform services, enterprise services, and real-time person-to-person services carry their own specific guideline language. The EU path has its own entitlement and addendum, separate from the reader-app entitlement.
Match your app against the documented definition, not against what a similar-looking competitor ships. “Their app does it” is not eligibility evidence. Apple grants these paths per account and per documented category, and an app that resembles a reader app without meeting the definition is not covered.
Variable 4: distribution and business terms
This is the variable most teams skip. Even when the purchase type, storefront, and category line up, the developer account still has to be operating under the business terms that make the link legal, such as the EU’s alternative terms addendum or the terms tied to the relevant US or category-specific entitlement. Confirm which addendum, if any, your account has accepted, and which disclosure and reporting obligations come attached to it before the link goes live. A link built correctly on an account that never accepted the underlying terms is a terms violation independent of how well the code works.
Combine the four before you ship anything
A link is only defensible where all four variables line up for that specific storefront. Use this table to decide, one storefront at a time:
| Purchase type | Storefront confirmed | Entitlement/category matched | Distribution terms accepted | Decision |
|---|---|---|---|---|
| Digital content | Yes | Yes (e.g. reader app) | Yes | Link permitted for that storefront, scoped to the entitlement |
| Digital content | Yes | No | Not applicable | Do not ship a link; use in-app purchase or pursue the entitlement first |
| Digital content | Yes | Not confirmed | No | Do not ship; accept and implement the required terms first |
| Physical goods or real-world service | Yes | N/A in most cases | N/A in most cases | Standard external payment is typically allowed; re-verify against current guideline text |
| Any type | Not yet mapped | Not confirmed | Not confirmed | Stop and map the storefront before deciding anything else |
Request only the scope this table actually justifies. Do not enable a link for every storefront because the code path is the same. A broad, blanket permission is exactly the shortcut that turns a compliant US or EU implementation into a worldwide violation.
Build and test for storefront boundaries
A worldwide app needs purchase UI that respects these boundaries at runtime, not just in a store listing. Test account-region changes, cached configuration, remote flags, and every route into the paywall, including deep links and restored sessions, to confirm the link cannot leak into a storefront where the four variables do not line up. If you cannot prove the link stays inside its permitted storefront, do not ship it yet.
Failure patterns to watch for
- A US storefront permission is applied worldwide because the code path was easier to ship as one build.
- An EU option is implemented without the account having accepted the required terms or entitlement.
- The app claims reader-app status without matching Apple’s documented reader-app definition.
- Digital and physical purchase rules are treated as interchangeable inside the same app.
- A link scope is requested broadly “to be safe,” instead of matching the narrowest case the app actually needs.
The cases above are boundary checks assembled from the AppRejectKit corpus; they say nothing about how frequently Apple cites external-link rules. Verify the storefront-specific rule in Apple’s current documentation before changing either metadata or the binary.
What not to change blindly
Avoid recreating in-app purchase products, rotating identifiers, or changing purchase types before you know which of the four variables actually failed. Those changes create new metadata and entitlement work while leaving the original storefront, category, or terms mismatch untouched.
Also avoid copying an App Store Connect path or entitlement request flow from an undated tutorial. Apple changes labels, entitlement forms, and submission workflows. Use the official pages linked in this article, then match the labels you actually see in your own account.
Legal and commercial boundary: This article was verified against Apple’s public pages on 4 August 2026. It is product and review guidance, not legal advice. Storefront rules, court orders, regional terms, fees, and entitlements can change. Check Apple’s live terms for your account and obtain professional advice before changing a payment model.
FAQ about iOS external payment links App Store
Does a US external link permission apply to my EU or rest-of-world users?
No. The US storefront change and the EU external purchase terms come from different legal bases and carry different obligations. A link built for one does not automatically cover the other, even inside the same binary.
My app is not a reader app. Can I still add an external link?
Only if a different documented path applies: physical goods, a real-world/person-to-person service, or a storefront-specific entitlement your account has accepted. Without one of those, digital content purchased in the app defaults to Apple’s in-app purchase rules.
Do I need to request a broad, all-storefront link permission to keep this simple?
No, and you should not. Request the narrowest scope that matches your confirmed purchase type, storefront, and entitlement. A broad permission increases the chance the link appears somewhere it is not authorized.
Does accepting the EU terms automatically let me use an external link in other regions?
No. The EU addendum only governs EU distribution. Every other storefront still needs its own check against the purchase type, entitlement, and applicable terms.
Where do I confirm which business terms my account has actually accepted?
Check your App Store Connect agreements and the relevant Apple developer program pages for the entitlement or addendum in question. Do not rely on a tutorial or another app’s behaviour, since acceptance is tracked per account.
Conclusion
Do not ship a single global link based on a US or EU headline. Classify the purchase, map every storefront, match the entitlement or category, and confirm the distribution terms your account has actually accepted. Then request only the scope that combination justifies.
Take the smallest, most defensible action for each storefront, and keep the evidence for each of the four variables with your submission. Get professional advice before treating any of this as a commercial or legal conclusion.
Sources and references
- App Review Guidelines: accessed 4 August 2026.
- Distributing reader apps with a link to your website: accessed 4 August 2026.
- Updated guidelines now available: accessed 4 August 2026.
- Update on apps distributed in the European Union: accessed 4 August 2026.
- Communication and promotion of offers on the App Store in the EU: accessed 4 August 2026.