# Selling Digital Goods Outside the App Store: A 2026 Compliance Playbook > Where and how to legally accept payments outside the App Store in 2026: US, EU DMA, South Korea entitlements, and the patterns that keep your iOS app compliant. - **Author**: Ayush Agarwal - **Published**: 2026-05-10 - **Category**: Compliance, Mobile, Payments - **URL**: https://dodopayments.com/blogs/digital-goods-outside-app-store --- For more than a decade, selling digital goods inside an iOS app meant one thing. Apple In-App Purchase, Apple's 30% cut, and no questions asked. That one-size rule has cracked open in the last few years. Court rulings, regulator pressure, and Apple's own entitlement programs now create regions where alternative payment flows are explicitly allowed. The question is no longer whether you can route digital goods outside the App Store. The question is where, how, and what compliance footwork you have to do to stay on the right side of the rules. This is the 2026 playbook for digital goods sold via iOS apps. It covers regional eligibility, the integration patterns that work, the categories where IAP is genuinely optional, and the failure modes that get apps removed from the store. ## The State of Play in 2026 ```mermaid flowchart TD A[Selling Digital Goods on iOS] --> B{Region} B -->|US| C[Court-mandated allowed per Epic v Apple] B -->|EU| D[Allowed via DMA External Purchase Entitlement] B -->|South Korea| E[Allowed via StoreKit External Purchase Entitlement] B -->|Other regions| F[IAP required for most digital goods] A --> G{Category} G -->|Services / certain content| H[IAP not required] G -->|Standard digital goods| I[IAP required unless region exempts] ``` Three regions allow alternative payment flows for digital goods: the United States (under court-mandated provisions stemming from Epic v Apple), the European Union (under the Digital Markets Act and Apple's External Purchase Entitlement), and South Korea (under StoreKit External Purchase Entitlement, which requires Korea-only binaries). Outside these regions, in-app purchase remains the default for most digital goods. Trying to route around it in non-supported regions is a fast way to get your app rejected or removed. There is one important nuance. For some categories of services and content, Apple does not require in-app purchase at all, anywhere in the world. This includes physical goods (irrelevant for digital products, but worth noting), services rendered outside the app, and certain categories of digital content where Apple's policy makes IAP optional. Verify your category before assuming you have to use IAP. For broader context on the merchant of record patterns this enables, see our guides on [merchant of record for SaaS](https://dodopayments.com/blogs/merchant-of-record-for-saas) and [global billing](https://dodopayments.com/blogs/global-billing). ## Region 1: The United States The US allows external payment links inside iOS apps, but only under specific court-mandated provisions from the Epic Games v Apple ruling. The current state of play: - Apps can include a link to an external website where users can pay - Apple still has rules about how the link is presented (button styling, warning copy) - Apple may charge a separate commission on these external transactions, depending on the app and the version of the rules in effect The thing to watch in the US is that Apple has been actively challenging and modifying these rules. The text on the entitlement page changes. The commission rates change. What was allowed last quarter may not be allowed this quarter without minor compliance updates. What this means in practice: - Use the official External Link Account Entitlement (Apple's name) - Follow the latest UI guidelines Apple publishes - Account for any commission Apple charges on external payments in your unit economics - Re-check the rules every quarter > The US ruleset is real but unstable. We see teams build perfect compliance and then find the rules nudged a quarter later. The pattern that works long term is to design the integration so the entitlement details (button copy, warning text, commission handling) are configurable. When the rules shift, you ship a config change, not a rebuild. > > - Ayush Agarwal, Co-founder & CPTO at Dodo Payments ## Region 2: The European Union The EU has the cleanest framework today, thanks to the Digital Markets Act. Apps targeting EU users can use Apple's EU Alternative Terms and apply for the External Purchase Entitlement. Once approved, the app can: - Link to external websites for payment - Process payments outside Apple's IAP entirely - Use any payment method or processor of choice The tradeoffs: - The Alternative Terms have their own fee structure (a Core Technology Fee in some cases) - The entitlement requires explicit Apple approval - The app must comply with EU-specific UI and disclosure requirements For SaaS targeting EU customers, this is the cleanest path to bypass the 30% IAP cut. You move to the Alternative Terms, get the entitlement approved, and route payments to your own merchant of record. Customers see prices that match your web prices, and you keep most of the revenue. For broader EU billing context, see our [merchant of record in France](https://dodopayments.com/blogs/merchant-of-record-in-france) guide and the [tax documentation](https://docs.dodopayments.com/features/tax). ## Region 3: South Korea South Korea allows external payments via the StoreKit External Purchase Entitlement, but only for Korea-only app binaries. This means: - You build a separate binary for the Korean App Store - That binary uses the entitlement to route payments externally - Other regions still use the standard iOS app with IAP This is more operationally complex than the EU path but reflects Korea's specific telecommunications law that mandated external payment options. For apps with significant Korean user bases, the math usually clears: a separate Korean binary is a one-time engineering cost, and the savings from bypassing IAP scale with revenue. ## What Is Not Allowed Apps cannot use external payments outside these three regions for digital goods that fall under Apple's IAP requirement. Specifically: - An app available globally cannot route US users to external payments unless it follows the US entitlement rules with the right UI and commission handling - An app cannot use the EU entitlement to serve users outside the EU - A Korea-only entitlement cannot be applied to a global build - An app cannot use external payments simply because the user is signed in via web first Trying to slip around these rules typically results in app rejection at review or app removal post-launch. The risk is not theoretical. Apple has removed apps for IAP violations in the past and continues to do so. ## Categories Where IAP Is Not Required This is the lever many teams miss. Apple's IAP requirement applies to digital content consumed inside the app. There are categories where IAP is not required, regardless of region. Common examples: - **Physical goods.** Not applicable to digital products, but listed for completeness. - **Real-world services.** A taxi app, a food delivery app, or a service-booking app where the service is rendered offline does not require IAP for the booking. - **Person-to-person services.** A platform connecting users to freelancers, tutors, or consultants where the service happens off-app. - **Cloud-based business services.** B2B SaaS for enterprise customers, where the platform is sold via direct contracts rather than consumer purchases. - **Reader apps for content the user already owns.** A music app that streams content the user paid for elsewhere can operate with the External Link Account Entitlement. If your app's monetization fits one of these categories, you may not need to use IAP at all, even in regions where IAP would normally be required. Check Apple's latest guidelines and consider getting an opinion from app store consulting specialists if your category is borderline. For more on category-specific MoR coverage, see [merchant of record for SaaS](https://dodopayments.com/blogs/merchant-of-record-for-saas), [merchant of record for individuals](https://dodopayments.com/blogs/merchant-of-record-for-individuals), and [merchant of record for digital creators](https://dodopayments.com/blogs/merchant-of-record-digital-creator). ## The Integration Patterns Once you know your region and category, the integration patterns are surprisingly consistent. Three patterns work for routing iOS users to external checkouts. ### Pattern 1: WebView Checkout The most common pattern. The app embeds a WebView that loads a payment link generated by your MoR. The customer completes payment inside the WebView, and a webhook tells your server the payment succeeded. Your server then enables access in the app. This pattern is clean because the actual payment never touches your app's native code. Apple's entitlement rules typically govern the link presentation, not what happens after the user follows it. ### Pattern 2: External Browser Redirect The app generates a payment URL and opens it in the user's default browser via SafariViewController or a system browser. The customer pays, returns to the app, and the app polls or receives a webhook to confirm. This pattern is sometimes preferred because it keeps payment fully outside the app surface. The downside is the user-experience break of leaving and returning. ### Pattern 3: Native UI with External Backend Less common, but used by apps with the EU entitlement and the resources to build native payment UI. The app collects payment details natively and submits them to an external processor's API. The customer never leaves the app. This pattern requires the most engineering and the most compliance work, since the app is now handling payment data. PCI compliance and Apple's specific entitlement requirements both apply. For implementation reference, the [Dodo Payments mobile integration documentation](https://docs.dodopayments.com/developer-resources/integration-guide) covers WebView and redirect patterns in detail. ## A Real Implementation Here is a typical setup for an EU-targeted iOS SaaS app using Dodo Payments as the MoR. 1. The app applies for the EU Alternative Terms and the External Purchase Entitlement. 2. Once approved, the in-app upgrade flow shows a button labeled "Upgrade on the web" with the required disclosure copy. 3. Tapping the button generates a payment link via the Dodo API. 4. The link opens in a WebView (or Safari, per the team's preference). 5. The customer completes checkout. Dodo handles payment processing, EU VAT collection, currency conversion, and customer invoicing. 6. A webhook fires to the app's backend on payment success. 7. The backend updates the user's subscription state. 8. The app polls or listens for the state change and updates the UI to show the new entitlements. Total app-side complexity: a button, a WebView wrapper, and a state-refresh mechanism. The heavy lifting (payment processing, tax compliance, currency, invoicing) lives outside the app. For a complete walk-through, the [iOS digital goods documentation](https://docs.dodopayments.com/features/appstore-digital-goods) covers the integration flow, regional availability, and category nuances. ## Compliance Pitfalls ### Pitfall 1: Mixing Entitlements Across Regions Each entitlement is region-specific. Building a single binary that tries to use the US entitlement for US users, the EU entitlement for EU users, and IAP for everyone else is technically possible but compliance-fragile. One small UI mistake can violate a regional rule. The cleaner pattern is region-based feature flags that hide non-applicable flows entirely. ### Pitfall 2: Outdated Disclosure Copy The required warning text and disclosure language Apple mandates changes from time to time. An app built last year may have outdated copy that violates current rules. Add a regular compliance audit to your release cycle. ### Pitfall 3: Routing IAP-Required Content Externally If your app has content that genuinely falls under IAP and you try to route it externally outside an allowed region, the app gets rejected at review. The classic case is a consumer app that decides to "test" external payments in Australia where there is no entitlement. Do not. ### Pitfall 4: Ignoring Apple's External Payment Commission In some regions and under some entitlement programs, Apple charges a commission on external transactions, sometimes 12-17%. This is lower than the standard IAP cut but it is not zero. Account for it in your unit economics or you will be surprised when the bills arrive. ### Pitfall 5: Not Tracking the Rules The entitlement programs are evolving. Apple updates them, courts modify them, regulators add new ones. An app that ships compliant in 2026 Q1 may not be compliant in 2026 Q4 without updates. Subscribe to Apple's developer updates and check the entitlement pages quarterly. ## Modeling the Economics The decision to build alternative payment flows is ultimately economic. The math: | Scenario | App Store IAP | External Payment (EU Entitlement) | |---|---|---| | Apple commission | 30% (or 15% for small biz program) | ~17% (Core Technology Fee in some cases) | | Tax handling | Apple handles tax | Your MoR handles tax | | Pricing flexibility | Apple price tiers | Any price you want | | Currency | Apple price tiers per currency | Real-time conversion via MoR | | Customer invoicing | Apple-issued | MoR-issued, your branding | | Engineering work | Minimal (StoreKit only) | More (WebView, webhooks, state) | For an EU-focused SaaS with $500K ARR, moving from IAP to external payments under the EU entitlement saves roughly $65K to $90K per year after netting the lower Apple commission, MoR fees, and engineering cost. The breakeven is usually under three months for businesses above $250K ARR. For smaller businesses still under the small business program (15% commission), the math is tighter and may not clear. Run the numbers before committing to the rebuild. For comparable platform economics, see our [PayPal alternatives](https://dodopayments.com/blogs/paypal-alternatives) and [Stripe alternatives](https://dodopayments.com/blogs/stripe-alternatives) guides. ## What This Means for Your Roadmap If you are building an iOS app in 2026, the right default is a hybrid stack. - For the regions and categories where external payments are explicitly allowed, route to your MoR - For the regions where IAP is required, use IAP - Build feature flags that let you flip a region from one to the other when rules change - Treat the external payment path as the strategic path, since the regulatory direction of travel is toward more openness, not less The cleanest implementations let you toggle the payment path per user, per region, with a single config change. That flexibility is what will keep you compliant in 2027 and beyond as the rules continue to evolve. For pricing transparency, see [dodopayments.com/pricing](https://dodopayments.com/pricing). ## FAQ ### Can I sell subscriptions outside the App Store? In the regions and categories where external payments are allowed, yes. The technical pattern is the same as one-time payments: generate a checkout link, open it in a WebView or browser, and update the user state on success. Subscription renewals run through your MoR, not Apple. ### What happens if I get the compliance wrong? The most common consequence is app rejection at review. If the app is already live and a violation is detected post-launch, Apple typically notifies the developer with a window to fix the issue. Persistent or willful violations can lead to app removal. The fix path is usually to update the integration to match current entitlement rules. ### Does Google Play have similar entitlements? Yes, Google Play has its own user choice billing program in select regions, with its own commission structure. The patterns are similar to Apple's, though the specifics differ. If your app ships on both platforms, plan for two parallel compliance tracks. ### Is the App Store small business program still better than external payments? For some businesses, yes. The small business program drops Apple's commission to 15% for the first $1M of annual revenue. If you are well under $1M and have low engineering capacity, IAP through the small business program may be simpler than building external payment flows. Above $1M, external payments under the EU or US entitlements typically clear the math. ### Can I A/B test IAP versus external payments? In the regions where both are allowed, yes. Apps can show different upgrade flows to different users to test conversion. The mechanics need to follow Apple's UI rules for the external option (button styling, disclosure copy). With those in place, A/B testing is a powerful way to measure the real conversion impact of the alternative flow. ## Final Take Selling digital goods outside the App Store in 2026 is not a workaround. For US, EU, and South Korea users, it is a sanctioned path with explicit rules. For some app categories, IAP was never required at all. The teams that win are the ones who treat this as a compliance exercise, not a hack. Get the entitlement. Follow the UI rules. Use a merchant of record that handles tax, payouts, and chargebacks for the regions you are routing to. Build feature flags that let you adapt as the rules continue to shift. The 30% Apple cut still exists, but it is no longer the only path. For SaaS founders shipping on iOS, knowing where and how to use the alternatives is one of the highest-leverage compliance skills of 2026. Visit [dodopayments.com](https://dodopayments.com) for the integration patterns that match these compliance paths. --- - [More Compliance articles](https://dodopayments.com/blogs/category/compliance) - [All articles](https://dodopayments.com/blogs)