External Payment Links for Digital Purchases: What's Allowed in 2026

Few parts of the App Store rules generate more confusion than payments for digital goods. For years the answer was simple and strict: digital purchases go through In-App Purchase, full stop. That's no longer universally true — but the exceptions are regional and easy to get wrong. This guide explains where external payment links stand in 2026, and what still trips up submissions.

Important: Payment rules are among the fastest-changing parts of App Review, and they differ by country and by court ruling. Treat this guide as an orientation, not legal advice, and always verify against Apple's current documentation and entitlement pages before you build or submit.

The United States: External Links Are Allowed

In the US, apps can include buttons, external links, and calls to action that point to your own website or checkout for digital purchases — without needing a special entitlement to link out. Concretely, this means:

• You can put a "Subscribe on our website" button inside the app.
• You can link users to your own checkout page for a digital subscription or purchase.
• You can present this alongside Apple's In-App Purchase, not only instead of it.
• You're permitted to tell users the external option may be cheaper.

This is a meaningful shift from the old model. For US users, you're no longer forced to route every digital dollar through IAP, and you can be transparent about pricing differences between the two paths.

Outside the US: The Entitlement Requirement

The same freedom does not apply everywhere. In most regions outside the US, linking out to your own web checkout for digital goods generally requires the StoreKit External Purchase Link Entitlement. That's something you apply for, and it comes with its own conditions — disclosure requirements, reporting obligations, and specific rules about how the link and its surrounding UI must behave.

In other words, you can't take a US-style "just add a link to our checkout" approach and assume it ships globally. A flow that's perfectly compliant for a user in the US may be a rejection for the same app served to a user in another country. If you operate internationally, you have to design for the region — or apply for the entitlement and follow its rules.

Server-Side Flows vs. StoreKit

There's a common misconception that any external payment automatically means "you must use a specific StoreKit kit." Not necessarily. Some external payment flows are handled through your own backend server calls and don't route through StoreKit at all — the purchase happens on your infrastructure, and the app reflects the result.

Whether your particular flow needs an entitlement, needs StoreKit, or can be handled server-side depends on:

• The countries you ship in
• Whether the purchase is for digital goods consumed in the app (the heavily regulated case) versus physical goods or services consumed outside it (which have always been allowed to use external payment)
• How and where the user is directed to pay

Because the combinations matter, this is exactly the kind of thing worth confirming against Apple's current documentation — or raising with App Review before submission — rather than inferring from another app's behavior.

A Note on Physical vs. Digital Goods

The rules above are specifically about digital purchases — subscriptions, in-app currency, unlockable features, and similar. Physical goods and real-world services (ride-hailing, food delivery, physical retail) have always been allowed to use external payment methods and have never required In-App Purchase. If your app sells physical products, most of the digital-goods restrictions simply don't apply. The friction is almost entirely around digital content consumed inside the app.

Why Payment Submissions Draw Extra Scrutiny

Anything touching payments is among the most closely reviewed areas of the App Store, because it directly involves users' money and Apple's own purchase rules. External payment links, subscription management, and purchase restoration all tend to get a closer look during review.

The practical defense is clarity at submission time:

• Describe the payment flow explicitly in your App Review Notes — where the user taps, where they're taken, and what happens on the backend.
• Provide a working demo account with enough access that the reviewer can test the purchase path without spending real money.
• State which regions your external flow applies to, if it's region-gated.

A reviewer who can see exactly how your payment path works is far less likely to reject it on a misunderstanding. For a full template, see our guide on what to put in your App Review Notes.

The Bottom Line

External payment links for digital goods are real, but they're regional. In the US you have genuine freedom to link out and even advertise cheaper pricing. Outside the US, you generally need the External Purchase Link Entitlement and must follow its rules. Server-side flows can sidestep StoreKit in some cases, but "some cases" is doing a lot of work — the specifics of your app and your markets decide it. Because this area moves quickly, confirm the current rules before you commit engineering time, and make your payment flow easy for a reviewer to understand.

If a payment-related submission does get rejected, our guides on how to contact Apple App Review and how to appeal an App Store rejection walk through your options.

Keep Watch After You Ship

Payment changes and pricing experiments often show up first in your reviews — users are quick to complain when a checkout confuses them. AppStoreReview monitors your app across 175+ countries and sends instant alerts for new and negative reviews, with keyword filters so you catch payment complaints the moment they land.

Start monitoring for free →