Current iOS/iPadOS payment-policy, architecture, and App Review reference

Last verified	September 5, 2026
Primary authority	Apple Developer documentation + App Review Guidelines
U.S. legal status	Cross-checked against Ninth Circuit and Supreme Court dockets
Scope	Commission, IAP, external payments, regional programs, 0% architectures

For developers, founders, SaaS companies, CTOs, product managers, mobile architects, payment engineers, and startup teams.

Policy note: regional rules can change quickly. This document explicitly separates CURRENT rules from UPCOMING rules.

POLICY STATUS: This guide states rules verified on September 5, 2026. The EU has announced a unified fee model effective October 1, 2026; it is shown separately. U.S. linked-out fees remain subject to active federal litigation.

This is a technical/product-policy reference, not legal or tax advice. For high-revenue, regulated, or novel models, confirm the agreement applicable to your developer account and jurisdiction.

• 1. What exactly is Apple’s App Store commission?

• 2. Do not confuse these eight different charges

• 3. Master rate map: what Apple can charge in 2026

• 4. What is In-App Purchase (IAP)?

• 5. Apple Pay vs Apple IAP — they are not the same thing

• 6. Stripe, Razorpay, PayPal, Adyen, Braintree, Square, cards — can I use them?

• 7. Website payment does not automatically mean 0%

• 8. How to legally get Apple commission to 0%

• 9. Apple payment rules by region

• 10. Master decision tree — start with “What is the customer buying?”

• 11. Master scenario matrix — 60 practical cases

• 12. App design blueprints — recommended architecture by business model

• 13. Hybrid payment architecture — IAP customers + website customers

• 14. Subscription master section

• 15. Free app vs paid app vs freemium — how Apple treats each

• 16. App Store Review: what reviewers will inspect

• 17. Economic comparison — what the commission actually costs

• 18. Founder decision framework

• 19. Five architecture choices

• 20. Common myths — 25 corrections

• 21. Developer FAQ — 60 questions

• 22. Before Submitting an App That Has Payments — master checklist

• 23. SEO and publishing pack

• 24. Final quick reference

• 25. Official Apple reference links and high-authority legal sources

• 26. Completeness audit

Executive answer: the 60-second version

Apple does not take 30% of every payment that happens on an iPhone. The core question is what the customer is buying, where the value is consumed, and which storefront/rules apply.

Mental model:

DIGITAL VALUE USED IN THE APP
    -> Apple’s digital-commerce rules may apply.
    -> Under worldwide/default rules, IAP is normally required when the app sells
       the digital feature, content, currency, or subscription in the app.
    -> Reader, multiplatform, enterprise, companion, regional, and other exceptions
       can change the result.

PHYSICAL GOODS OR REAL-WORLD/OFFLINE SERVICES
    -> IAP must generally NOT be used.
    -> Use Apple Pay, Stripe, Adyen, Razorpay, PayPal, Braintree, Square, cards, etc.
    -> Apple App Store commission is generally 0% on the transaction.

That is the starting point, not the whole rule. Apple explicitly creates exceptions for reader apps, multiplatform services, enterprise services, real-time one-to-one services, free stand-alone companion apps, advertising-management apps, approved nonprofit fundraising, and some regulated financial use cases. Regional programs can also permit external payments for digital goods while still charging Apple fees. Apple App Review Guidelines, especially 3.1.1-3.1.5

The most important conclusions

1. Standard IAP is usually 30%, not universally 30%. The App Store Small Business Program can reduce paid-app/IAP commission to 15%. Standard auto-renewing subscriptions generally move from 70% developer proceeds to 85% after one year of paid service. Apple Small Business Program and subscription proceeds

2. Apple Pay is not IAP. Apple Pay is a wallet/payment method. IAP is Apple’s digital-commerce system. Physical goods and services consumed outside the app should use non-IAP payment methods, including Apple Pay or card entry. Guideline 3.1.3(e)

3. A website purchase can legitimately lead to 0% Apple commission when the sale is genuinely a web/enterprise/reader/companion/multiplatform transaction permitted by the rules and the iOS app merely recognizes the existing entitlement. But linking from the iOS app to that website can invoke different rules and fees depending on storefront.

4. United States storefront: current App Review Guidelines say an entitlement is not required for buttons, external links, or calls to action. As of September 5, 2026, the Ninth Circuit has stated Apple should not charge a linked-out commission until the district court approves an appropriate fee. Apple has proposed future fees, but the court has not approved them as of this verification date. App Review Guidelines and Ninth Circuit opinion

5. European Union: do not use a single fee table without a date. The existing alternative terms remain relevant through September 30, 2026 for developers on those terms; Apple’s new unified EU model starts October 1, 2026 (or later if the developer agrees later, per Apple’s transition language). EU changes

6. Japan and Brazil: digital alternative payments and out-of-app offers are permitted under newer regional programs, but Apple still charges defined commissions; these are not automatic 0% architectures. Japan payment options and Brazil payment options

7. South Korea: sanctioned third-party in-app payment requires the entitlement and a Korea-only binary, and Apple currently charges 26% on the price paid, gross of VAT. South Korea entitlement

8. Never hide a payment system from App Review. Hidden checkout, remote activation after approval, disguised digital purchases, or undocumented payment functionality is policy evasion and can result in rejection/removal/account action.

1. What exactly is Apple’s App Store commission?

The App Store commission is Apple’s contractual share of eligible paid-app and digital-goods/services transactions connected with App Store distribution. It is not the Apple Developer Program membership fee, it is not a tax, and it is not automatically the same thing as payment-processing cost.

Under the default worldwide App Store model, the familiar headline rates are:

• 30% standard commission for many paid apps and IAP transactions.

• 15% Small Business Program commission for eligible participating developers on paid apps and IAP.

• 15% on qualifying auto-renewing subscription renewals after one year of paid service under the standard subscription proceeds model.

Regional regimes can replace or decompose those rates into different components. For example, Japan’s current regional terms separate an App Store commission (21% standard / 10% reduced categories) from a 5% Apple payment-processing fee for IAP. The EU’s rules have their own current and upcoming structures. Therefore, saying “Apple takes 30%” without naming the storefront and program is no longer a reliable engineering statement.

1.1 When Apple charges commission

Apple commission commonly becomes relevant when the transaction pays for digital value used or experienced in the app, including:

• premium app features;

• subscriptions to digital app functionality;

• game currency, lives, gems, levels, and other virtual goods;

• access to premium digital content;

• recorded courses or other digital content sold in the app;

• digital credits that unlock in-app usage;

• social-media boosts or other digital promotion consumed in the same app;

• certain external or alternative digital purchases in regions where Apple explicitly imposes a store-services or alternative-payment commission.

Apple’s core worldwide rule is direct: when an app unlocks features/functionality — including subscriptions, in-game currencies, game levels, premium content, or a full version — it must use IAP unless an exception or regional program applies. Guideline 3.1.1

1.2 When Apple does not normally charge App Store commission

Common 0% App Store-commission categories include:

• physical goods delivered to the customer;

• food/grocery delivery;

• taxi/transportation rides;

• hotel, airline, vehicle-rental, and many real-world bookings;

• medical appointments and qualifying real-time one-to-one consultations;

• qualifying one-to-one tutoring, legal, consulting, coaching, or training sessions;

• direct enterprise/B2B licenses sold only to organizations/groups for employees/students;

• eligible free companion apps to paid web tools with no purchase or external-purchase CTA in the app;

• existing web customers signing into eligible reader/multiplatform/companion apps;

• approved nonprofit fundraising through permitted mechanisms;

• advertising campaign management when the ads are displayed outside the app;

• regulated banking/trading/insurance transaction flows where IAP is not the product-payment mechanism.

The important word is commission. The developer can still pay Stripe/Adyen/PayPal/etc. processing charges, card-network fees, tax, fraud costs, chargebacks, billing-system fees, or marketplace fees.

1.3 What amount is the percentage applied to?

Do not assume a universal tax base from a blog formula. Under standard App Store financial reporting, Apple commonly describes developer proceeds as customer price less applicable taxes and Apple commission. Regional alternative-payment terms can define a different basis. South Korea, for example, explicitly states that the 26% commission is on the price paid by the user gross of VAT.

For a simple comparison that ignores tax:

Customer price:                  $100.00
30% Apple commission:            $30.00
Illustrative developer proceeds: $70.00

Customer price:                  $100.00
15% Apple commission:            $15.00
Illustrative developer proceeds: $85.00

If taxes apply, use the applicable Apple agreement and storefront tax treatment rather than subtracting a made-up “VAT percentage” from every sale.

2. Do not confuse these eight different charges

Charge	What it is	Typical payer	Is it an App Store commission?
Apple Developer Program membership	Annual program membership; currently USD 99/year in the U.S. (local currency where available)	Developer	No
Apple Developer Enterprise Program membership	Annual enterprise membership; currently USD 299/year	Enterprise developer	No
App Store commission	Apple’s share of eligible app/digital commerce	Developer	Yes
IAP payment processing / commerce services	Payment-processing component, explicit in some regional fee structures	Developer	No; separate component where specified
External PSP fee	Stripe/Adyen/Razorpay/PayPal/Braintree/Square/card cost	Developer/merchant	No
Alternative-payment/store-services fee	Apple fee on certain non-IAP digital transactions in a regional program	Developer	Apple fee, but not necessarily “IAP commission”
Tax (VAT/GST/sales/consumption tax)	Government tax	Merchant/customer depending jurisdiction	No
Distribution/technology fee or commission	EU CTF/CTC or regional alternative-distribution charge where applicable	Developer	Separate Apple fee

Current Apple membership pricing is documented as USD 99/year for the Apple Developer Program and USD 299/year for the Enterprise Program. Program enrollment

3. Master rate map: what Apple can charge in 2026

3.1 Worldwide/default App Store model

Situation	Typical Apple commission / proceeds rule	Notes
Standard paid app or IAP	30%	Subject to program/category exceptions
App Store Small Business Program	15%	Eligible developers; USD 1M proceeds threshold rules apply
Standard auto-renewing subscription, first year	Developer generally receives 70% minus applicable taxes	Equivalent headline commission commonly described as 30%
Standard auto-renewing subscription after one year of paid service	Developer generally receives 85% minus applicable taxes	15% effective commission under the standard model
Small Business Program auto-renewing subscription	85% proceeds from day one under Apple program guidance	Subject to continued program eligibility
Physical goods / services consumed outside app	0% App Store commission	Must use non-IAP payment method
Qualifying P2P real-time one-to-one service	0% App Store commission	One-to-few / one-to-many must use IAP under default rules
Qualifying direct enterprise service	0% App Store commission on enterprise sale	Consumer/single-user/family sales must use IAP when sold in app

App Review Guidelines, Small Business Program, subscription proceeds

3.2 Small Business Program — exact practical rules

The program reduces paid-app and IAP commission to 15% for eligible developers.

Key rules:

• Existing developers can qualify when total prior-calendar-year proceeds across their apps are USD 1 million or less; new App Store developers can also qualify.

• Apple requires disclosure of Associated Developer Accounts when determining eligibility.

• If the developer’s current-calendar-year proceeds exceed USD 1 million, the standard commission applies to future sales after the threshold is crossed.

• If proceeds later fall below the threshold in a subsequent calendar year, the developer can qualify again for the following year under Apple’s rules.

• Enrollment is not simply “automatic because revenue is small”; the Account Holder must complete the program process and relevant agreements.

• Apple defines the threshold using proceeds, not gross billings; use Apple’s stated definition for eligibility calculations.

Apple App Store Small Business Program

Example

A developer enrolled in the program begins a year below the threshold. If eligible proceeds reach USD 1,000,000 and then exceed that threshold, the standard commission applies to subsequent sales for the remainder of that year. The program should not be modeled as “15% forever for the first million of gross revenue.”

3.3 Auto-renewable subscription commission timeline

Under the standard subscription model:

Paid service day 1 ——————– day 365+ cumulative paid service
Developer proceeds: ~70% Developer proceeds: ~85%
Headline commission: ~30% Headline commission: ~15%

Apple counts cumulative paid service. Paid offer periods can count; free periods do not. Upgrades/downgrades/crossgrades within the same subscription group are designed not to create a new unrelated subscription history. Billing interruption rules can pause or reset the accumulated paid-service calculation depending on the length of interruption. Auto-renewable subscriptions and subscription reporting

3.4 Regional alternative-payment rates are different

Do not reuse the 15/30 model in every country. Examples current on September 5, 2026:

• Japan: 21% App Store commission on digital sales including alternative in-app payments, 10% reduced categories, plus 5% Apple payment processing when IAP is used; actionable out-of-app links carry 15%/10% store-services commission for relevant sales within seven days. Japan

• Brazil: materially similar 21%/10% App Store commission, 5% Apple IAP processing fee, and 15%/10% actionable-link commission within seven days. Brazil

• South Korea: approved third-party in-app purchase under its special entitlement carries 26% Apple commission on the price paid, gross of VAT. South Korea

• Netherlands dating apps: special entitlement program reduces the developer’s otherwise applicable Apple commission by three percentage points for qualifying alternative payments; this remains a narrow dating-app exception, not a general Netherlands rule. Netherlands dating apps

• EU: separate current alternative terms exist through September 30, 2026, and Apple has announced a new unified model for October 1, 2026. See the regional chapter.

4. What is In-App Purchase (IAP)?

In-App Purchase is Apple’s App Store digital-commerce mechanism, implemented using StoreKit and configured in App Store Connect. It is used to sell digital content, digital functionality, subscriptions, and virtual goods that fall within Apple’s IAP rules.

Apple defines four classic IAP product types:

IAP type	What it does	Typical example	Restorable?
Consumable	Depleted with use; may be bought again	game gems, one-time credits	Generally not restored as an owned durable item
Non-consumable	One-time durable purchase	premium feature / filter pack	Yes
Auto-renewable subscription	Automatically renews until cancelled	SaaS, streaming, cloud storage	Entitlement must be recoverable
Non-renewing subscription	Time-limited access that does not auto-renew	fixed access period/catalog pass	App/developer must manage access/restoration behavior

Apple In-App Purchase types

4.1 When IAP is mandatory under default rules

IAP is normally mandatory when the app itself sells or unlocks digital value used in the app, such as:

• a Pro tier;

• an AI assistant subscription used inside the iOS app;

• image/video-generation credits used in the app;

• cloud-storage upgrade sold in the app;

• game currency;

• extra levels;

• premium filters;

• recorded digital content sold in the app;

• creator content subscriptions consumed in the app;

• a paid feature switch or lifetime “unlock Pro” button.

Do not replace IAP with a license key, QR code, cryptocurrency wallet, hidden web checkout, or another proprietary unlock path for the same in-app digital value. Guideline 3.1.1

4.2 When IAP is optional because another permitted model exists

The word “optional” needs precision. It can mean one of three things:

1. The app does not sell anything in-app: a web customer already purchased access, and the iOS app only authenticates and consumes the existing entitlement under a permitted reader/multiplatform/enterprise/companion model.

2. The transaction falls into an exception: e.g., qualifying real-time one-to-one service or enterprise-only licensing.

3. A regional program allows an alternative: e.g., Japan, Brazil, South Korea, EU, or Netherlands dating-app rules — often with entitlement, fee, reporting, and UI obligations.

4.3 When IAP is prohibited or unnecessary

For physical goods and services consumed outside the app, Apple says developers must use purchase methods other than IAP — for example Apple Pay or traditional card entry. Guideline 3.1.3(e)

Examples:

• a delivered laptop;

• food delivery;

• grocery order;

• Uber-like ride;

• hotel booking;

• airline ticket;

• car rental;

• in-person salon appointment;

• gym membership that grants access to a physical gym;

• real-world event ticket.

5. Apple Pay vs Apple IAP — they are not the same thing

This distinction prevents a huge amount of bad architecture.

Question	Apple Pay	Apple IAP
What is it?	Wallet/payment authorization method	App Store digital-commerce system
Typical use	Physical goods, real-world services, donations where permitted	Digital content/functionality/subscriptions/virtual goods
Does “Apple Pay” itself imply 30%?	No	IAP has App Store commission structure
Can developer use own PSP/acquirer?	Yes, through Apple Pay payment ecosystem/integration	Apple manages the App Store transaction
Who handles App Store entitlement?	Developer’s backend	StoreKit + developer backend

Good Apple Pay uses

• checkout for shoes delivered to the customer;

• hotel reservation;

• taxi fare;

• restaurant booking/deposit;

• eligible donation;

• real-world gym membership.

Wrong mental model

“I will use Apple Pay for my $9.99/month in-app AI Pro subscription, so Apple cannot charge commission.”

That is incorrect under default rules. The thing being sold is a digital subscription unlocking in-app functionality; choosing a wallet does not convert it into a physical transaction.

6. Stripe, Razorpay, PayPal, Adyen, Braintree, Square, cards — can I use them?

Yes or no depends on what is being sold and which storefront program applies. There is no meaningful policy answer to “Can I use Stripe on iOS?” without the product classification.

Sale	Stripe/PayPal/Razorpay/etc. inside app?	Default App Store answer
Physical ecommerce product	Yes	Use non-IAP checkout
Food delivery	Yes	Use non-IAP checkout
Taxi ride	Yes	Use non-IAP checkout
Hotel/air ticket	Yes	Use non-IAP checkout
One-to-one live consultation	Yes	Qualifying P2P exception
$10/month in-app digital Pro tier	Not as a substitute for required IAP under default rules	Use IAP unless regional/other exception applies
Game coins	No as substitute for IAP under default rules	IAP required
Web-first enterprise license	Website/invoice can use any suitable PSP	iOS app can recognize enterprise entitlement if rules met
Japan/Brazil alternative in-app digital payment	Yes if program/entitlement/requirements met	Apple still charges regional commission; not 0%
South Korea special in-app payment	Approved PSP under entitlement	Apple charges 26%; separate Korea-only binary

Practical gateway rule

The PSP name does not determine App Store compliance. Transaction classification does. Stripe, PayPal, Razorpay, Adyen, Braintree, Square, and direct card entry are simply payment rails. If IAP is mandatory, replacing StoreKit with a gateway is not compliant. If non-IAP payment is required or permitted, those gateways can be appropriate subject to their own platform availability, merchant rules, local law, and Apple regional requirements.

7. Website payment does not automatically mean 0%

This is the single most dangerous shortcut in App Store payment design.

Flow A — user independently buys on the web, then later logs in

Search / sales team / web marketing
        -> Website
        -> Account created
        -> Web checkout
        -> Subscription DB
        -> User later downloads iOS app
        -> Sign in
        -> Backend entitlement recognized

This can be a legitimate 0%-Apple-commission architecture when the app category and rules permit it — for example a qualifying reader, enterprise service, free stand-alone companion, or other web-first/multiplatform service. The app must still comply with the specific rules for its category.

Flow B — the iOS app steers the user to web checkout

iOS paywall
    -> “Buy on our website”
    -> external link / browser / WebView
    -> checkout

That is a separate policy event. Apple can regulate the link, call-to-action, entitlement, disclosures, attribution window, reporting, and fees depending on storefront. The U.S. currently differs materially from Japan, Brazil, Korea, the Netherlands dating carve-out, the EU, and worldwide/default storefronts.

7.1 Can the app mention a website price?

No single worldwide answer.

• In the U.S. storefront, current Apple Guidelines permit buttons, external links, and other calls to action without the former entitlement requirement; the active injunction/court proceedings affect Apple’s ability to charge linked-out commission today.

• An approved reader app’s External Link Account Entitlement has restrictive link formatting and specifically says the account-management link cannot be accompanied by website-price language.

• EU/Japan/Brazil regional programs can allow communication and promotion of outside offers under their entitlement/business terms, but relevant Apple fees/reporting can apply.

• Under default storefront rules, apps in the listed exception categories generally cannot encourage users inside the app to use another purchasing method unless an explicit exception applies.

7.2 Can I put Stripe Checkout in a WebView?

For a digital purchase that would otherwise require IAP, a WebView does not make the purchase “web commerce.” Some regional programs explicitly define whether native alternative payment, browser links, or WebViews are allowed. South Korea’s entitlement, for example, requires a native in-app alternative flow and says it may not be within a WebView. The reader-app account entitlement requires opening the default browser, not a WebView.

7.3 Can users purchase on a website and later sign in?

Often yes, but the classification matters. Reader apps expressly allow previously purchased media content/subscriptions. Multiplatform services can allow previously acquired content/subscriptions/features, with additional rules for consumables. Enterprise services can allow organization-purchased access for employees/students. Free stand-alone companion apps can accompany paid web tools when they contain no purchasing or purchase CTA. Guideline 3.1.3

8. How to legally get Apple commission to 0%

The goal is business-model and architecture compliance, not payment-policy evasion. A real 0% Apple-commission design normally works because the transaction legitimately falls outside Apple’s commission rules, not because the app hides where money is collected.

Model 1 — Physical goods / services

iOS app
-> select physical product or real-world service
-> Stripe / Adyen / Razorpay / PayPal / Apple Pay / card
-> merchant backend
-> physical delivery / offline performance

Why it can be 0%: Apple Guideline 3.1.3(e) says physical goods/services consumed outside the app must use payment methods other than IAP.

Examples: ecommerce merchandise, food, grocery, rides, car rental, hotel, air travel, salon appointments, physical event tickets.

Architecture recommendation: native/cart UI -> payment orchestration service -> external PSP -> order DB -> fulfillment. Do not create IAP products for these transactions.

Model 2 — Web-first SaaS

Website -> account -> web subscription -> entitlement service
                                      |
                                iOS sign-in
                                      |
                               feature access

When it works: the iOS app is legitimately allowed to recognize an existing subscription purchased elsewhere. The safest form has no in-app purchase flow and, where default rules require it, no in-app external-purchase CTA. Multiplatform/companion/enterprise rules may support this design.

What it does not mean: every consumer SaaS can place a “Subscribe cheaper on our website” button everywhere worldwide with no Apple fee. Linking/steering rules are storefront-specific.

Model 3 — Free stand-alone companion app

Apple explicitly says free apps that are stand-alone companions to paid web-based tools — examples include VoIP, cloud storage, email services, and web hosting — do not need IAP when there is no purchasing inside the app and no call to action for purchasing outside the app. Guideline 3.1.3(f)

Paid web tool -> web billing
                    |
                account / API
                    |
           free iOS companion
           (login + service use)

0% Apple commission: yes on the web subscription when the model complies. External PSP fees still apply.

Model 4 — Reader app

Eligible reader apps have media consumption as their primary functionality: magazines, newspapers, books, audio, music, or video. A user can sign in and consume previously purchased media/content subscriptions. Reader app support

Website -> media subscription
                |
          content entitlement
                |
        reader app login
                |
       read / watch / listen

External Link Account Entitlement: an eligible reader app can request it to provide an informational account-creation/management link. Apple imposes detailed formatting and destination rules: the developer-owned site, default browser, no WebView, no extra URL parameters, static submitted URL, no redirect, and no price language attached to that entitlement link. The entitlement is optional; it is not a blanket external-checkout entitlement.

U.S. note: current Guidelines separately state that U.S. storefront apps do not need the entitlement for buttons/external links/other CTAs.

Model 5 — Enterprise / B2B licensing

Apple’s enterprise-services exception is powerful but narrow:

Company procurement
-> invoice / contract / sales portal / web checkout
-> organization tenant + seat licenses
-> employees/students sign in to iOS app

If the app is only sold directly to organizations or groups for employees/students, the app may allow enterprise users to access previously purchased content/subscriptions. Consumer, single-user, or family sales do not get this exception and must use IAP when sold in-app. Guideline 3.1.3(c)

Safest B2B architecture: organization-level contract -> tenant provisioning -> administrator assigns seats -> app login via SSO/email -> entitlement service returns organization role/plan. Do not expose a consumer-style individual “buy a seat” paywall in the iOS app if relying on this exception.

Model 6 — Real-time person-to-person service

Apple allows non-IAP collection for real-time person-to-person services between two individuals, including tutoring, medical consultations, real-estate tours, and fitness training. Guideline 3.1.3(d)

Customer -> choose named professional
         -> schedule real-time 1:1 session
         -> external payment
         -> live service between two individuals

Critical boundary: one-to-few and one-to-many real-time services must use IAP under the default rule. A live group webinar is not transformed into one-to-one service merely because a teacher is present.

Model 7 — Multiplatform service

Apps operating across multiple platforms may allow users to access content, subscriptions, or features acquired on another platform or the developer’s website. Apple also allows consumable items acquired elsewhere in multi-platform games provided those items are also available as IAP inside the app. Guideline 3.1.3(b)

A common compliant pattern is web/desktop subscription + iOS login. If the app also merchandises the same digital subscription in-app under default rules, use IAP for that in-app sale.

Model 8 — Advertising-management service

If the app’s sole purpose is for advertisers to purchase/manage campaigns that run across media outside the app, IAP is not required. If the digital purchase is experienced in the same app — e.g., paying to boost a social post in that app — IAP is required. Guideline 3.1.3(g)

Model 9 — Marketplace architecture

Marketplace classification follows the underlying value:

PHYSICAL MARKETPLACE
Buyer -> marketplace -> PSP split/payment -> seller -> physical good/service
Apple IAP: normally not used
Apple App Store commission on transaction: generally 0%
Platform can still charge its own marketplace commission.

DIGITAL MARKETPLACE
Buyer -> digital item/content/service consumed in app
Apple IAP: normally required for in-app sale unless a specific exception applies.

A platform’s own marketplace fee is not an Apple commission. Keep buyer payment, seller payout, platform take-rate, tax, and Apple/PSP fees as separate accounting objects.

Model 10 — Region-specific external purchase flow

Regional options can be strategically useful but must not be mislabeled 0%:

• United States: current linked-out Apple commission is effectively 0% pending court approval of any permissible fee, while active litigation continues. This is a volatile legal state, not a guaranteed permanent business term.

• EU: current and October-2026 alternative terms impose Apple fees; not generally 0%.

• Japan: alternative in-app digital payments and actionable external links carry Apple commission; not 0%.

• Brazil: same principle; Apple fees remain.

• South Korea: alternative in-app payment carries 26% Apple commission.

• Netherlands dating apps: special reduced Apple commission, not 0%.

8.1 What does not count as a legal 0% model

Do not recommend or implement:

• hiding Stripe during App Review and enabling it remotely after approval;

• a secret URL scheme that opens digital checkout;

• a QR code whose purpose is to bypass required IAP;

• calling a digital subscription a “physical membership” when the real value is the app feature;

• reviewer-only feature flags that conceal the real commerce flow;

• undocumented payment methods;

• changing server configuration after approval specifically to evade payment rules.

The policy distinction is simple:

Legitimate: design a product whose transaction actually falls outside Apple’s commission rules or uses an explicit permitted program. Evasion: keep the same commissionable digital transaction but conceal or mischaracterize its payment path.

9. Apple payment rules by region

A user’s App Store storefront, not merely GPS location or IP address, is often the policy dimension that matters for regional App Store payment programs. Architect regional commerce from a trusted storefront signal and the specific StoreKit APIs/entitlements Apple requires — not from a home-grown “country = IP geolocation” assumption.

9.1 Regional master table — verified September 5, 2026

Region / program	IAP default	External digital payment?	Actionable external links?	Entitlement / special binary	Apple fee today	Reporting / major limitation
Worldwide/default storefronts	IAP for in-app digital unlocks	Only listed exceptions / programs	Generally restricted for digital purchase steering unless exception	Depends on category	Standard 30%, 15% SBP, subscription rules	Guideline 3.1 controls
United States storefront	IAP still available/required for in-app digital purchase path unless compliant external flow	Linked-out web purchase permitted under current anti-steering rules	Yes; current Guidelines say no entitlement required for buttons/links/CTAs	No former U.S. link entitlement required	0% on linked-out purchase currently, pending district-court-approved fee; IAP rates unchanged	Active Epic v. Apple litigation; verify immediately before launch
EU, current terms through Sep 30, 2026	Depends on terms selected	Yes under current alternative terms	Yes under current communication/promotion framework	Relevant EU terms/entitlements	Layered 17/10% IAP commission + 3% processing under Alternative Terms; external offers can incur acquisition/store-services/CTF or CTC depending agreement	Transaction reporting; taxes with alternative PSP; fee windows tied to install/update
EU, from Oct 1, 2026	New unified terms	Yes, alongside IAP	Yes	Updated DPLA/entitlement mechanisms	Apple announced 26% IAP / 15% reduced; 20% alternative in-app / 10% reduced; 15% linked-out / 10% reduced; 5% CTC outside App Store	New model; 12-month payment-option choice; child-safety rules
Japan	IAP available	Yes under regional program	Yes under regional program	StoreKit External Purchases or Offers Entitlement; iOS 26.2+	21% / 10% App Store commission; +5% Apple processing for IAP; external actionable-link 15% / 10% relevant sales	Monthly reporting; developer handles alt-payment tax/refunds; 7-day link window
Brazil	IAP available	Yes; alternative in-app option must follow current program requirements	Yes	StoreKit External Purchases or Offers Entitlement; iOS 26.5+	21% / 10% App Store commission; +5% IAP processing; external actionable-link 15% / 10%	Monthly reporting; 7-day link window; current rules require IAP to be presented when merchandising an alternative in-app digital payment
South Korea	Apple IAP or special alternative route	Yes, approved PSP in-app	Special entitlement focuses on alternative in-app payment	Korea-only new binary + entitlement; one PSP per entitlement	26% on price paid gross of VAT	Monthly fiscal-month reporting; Apple invoice; native flow; entitlement cannot coexist with IAP in same app
Netherlands dating apps	IAP or special dating alternative	Yes	Yes	Dating apps only; external purchase/link entitlement	Generally three percentage points below otherwise applicable commission (e.g., 27% from 30%, 12% from 15%)	Narrow program; entitlement app cannot use IAP for NL alternative flow; reporting/audit obligations

9.2 United States — current rule and litigation status

Current App Review position

Apple’s current App Review Guidelines state that the external-link entitlement is not required for developers to include buttons, external links, or other calls to action in United States storefront apps. This change followed the federal court’s anti-steering enforcement. Guideline 3.1.1(a) / 3.1.3(a)

Current linked-out commission

The Ninth Circuit’s December 11, 2025 opinion held that Apple’s prior 27% linked-out commission had a prohibitive effect and gave the district court guidance on a permissible future fee. Critically, the court said Apple should not be able to charge any commission for linked-out purchases until the district court has approved an appropriate fee. Ninth Circuit opinion, Epic Games v. Apple

As of September 5, 2026:

• the U.S. Supreme Court has granted certiorari on a contempt-related question in the case;

• Justice Kagan denied Apple’s August 13, 2026 application to stay the lower-court proceedings;

• Apple has proposed a future linked-out fee schedule, but that proposal is not yet an approved current fee.

Supreme Court docket 25-1311 and stay docket 26A194

Product implication

For a U.S. digital SaaS app today, an external web checkout linked from the app can be a current 0% Apple linked-out commission route, but the architecture must be feature-flagged by storefront and designed so a future court-approved fee can be introduced without rewriting the entitlement system. Do not price a five-year business plan on the assumption that the current U.S. 0% condition is permanent.

9.3 European Union — current terms through September 30, 2026

The EU is currently in a transition window. Apple’s support materials say developers may continue using the existing alternative-distribution/alternative-payment terms until the new unified terms begin on October 1, 2026.

Alternative Terms Addendum — current pre-October structure

For iOS/iPadOS App Store apps under the current Alternative Terms Addendum:

• App Store commission for digital goods/services: 17% standard, 10% for Small Business participants or qualifying subscriptions after one year.

• Apple App Store payment-processing/commerce fee when using IAP: +3%.

• Core Technology Fee: EUR 0.50 per first annual install above one million, subject to the detailed CTF rules/exemptions.

For apps that communicate/promote external offers using actionable links, current terms can layer:

• Initial acquisition fee: 2% standard / 0% program rate, within six months after first install.

• Store Services Tier 1: 5% within 12 months of the most recent install/update/reinstall.

• Store Services Tier 2: 13% standard / 10% program rate within the same 12-month window.

• Depending on the agreement used, CTF or a 5% Core Technology Commission can also apply.

Apple’s current materials state those acquisition/store-services/technology charges do not apply in specified cases such as qualifying outside-app transactions promoted without an actionable link, IAP transactions, and certain previously initiated subscription renewals. The definitions are agreement-specific. Current EU communication/promotion terms

Do not compress EU current fees into one percentage

A current EU linked-out sale can have multiple fee clocks and components. Your billing model needs fields for agreement version, first-install date, latest install/update/reinstall, link attribution, store-services tier, program rate, transaction tax, and technology fee status.

9.4 EU — announced unified terms effective October 1, 2026

Apple announced the following future structure, effective October 1, 2026 (or later for an account where Apple’s stated transition terms make the agreement date later):

Future EU digital route	Standard Apple rate	Reduced rate described by Apple
Apple IAP on App Store	26%	15%
Alternative in-app payment on App Store	20%	10%
Actionable out-of-app offer/link	15%	10%
Alternative distribution / Web Distribution digital transaction	5% Core Technology Commission	Waiver rules can apply to qualifying small marketplace operators

Other announced changes include allowing alternative payments alongside Apple IAP, eliminating the old Initial Acquisition Fee and Store Services Fee under the new model, replacing CTF with CTC, and requiring selected payment-option behavior to be maintained for 12 months. Apple EU changes — effective October 1, 2026

Do not apply these rates to September 2026 transactions. They are included so an architecture going live after October 1 does not ship against a fee model that is already scheduled to disappear.

9.5 Japan — iOS 26.2+ regional model

Japan now supports alternative in-app payment and out-of-app digital offers under the StoreKit External Purchases or Offers Entitlement.

Current Apple fee components:

• 21% App Store commission on digital goods/services, including alternative in-app payment, unless a reduced rate applies.

• 10% reduced commission for listed program participants and qualifying auto-renewable subscriptions after the first year.

• 5% Apple payment-processing fee for transactions processed by Apple IAP.

• 15% store-services commission on relevant out-of-app offers using an actionable link; 10% reduced rate. The actionable-link fee applies to relevant sales within seven days of the link tap.

• A 5% Core Technology Commission applies to specified digital transactions in apps distributed outside the App Store under the Japan alternative-distribution model.

The developer is responsible for alternative-payment taxes, billing/refunds/support, transaction tracking, and monthly reporting to Apple. Japan payment options

$100 digital purchase illustration — Japan, ignoring tax and PSP cost

Apple IAP, standard: 21% commission + 5% processing = $26 Apple fees
Alternative in-app PSP, standard: 21% Apple commission + external PSP cost
Actionable website link, standard qualifying sale: 15% Apple fee + external PSP cost

This is why “external payment = 0%” is wrong.

9.6 Brazil — iOS 26.5+ regional model

Brazil’s current model similarly allows alternative in-app payments and out-of-app offers under the StoreKit External Purchases or Offers Entitlement.

• App Store commission: 21% standard / 10% reduced.

• Apple IAP payment processing: +5%.

• Actionable out-of-app link: 15% / 10%, relevant sales within seven days.

• Alternative distribution: 5% Core Technology Commission on specified digital transactions.

• When merchandising digital goods/services using an alternative in-app payment method, Apple’s current Brazil requirements state that Apple IAP must also be presented as an option.

• Monthly alternative-payment transaction reporting is required, and the developer is responsible for taxes and customer-service obligations for the alternative transaction.

Apple payment options in Brazil

9.7 South Korea — not a 0% alternative

South Korea allows a special alternative in-app PSP route, but Apple requires:

• StoreKit External Purchase Entitlement;

• a new/separate iOS/iPadOS binary distributed solely in South Korea;

• one approved PSP per entitlement (Apple currently lists KCP, Inicis, Toss, and NICE, with other PSPs subject to approval);

• no Apple IAP in the same entitlement-enabled app;

• a native payment experience rather than WebView;

• Apple’s external-purchase disclosure flow/APIs;

• monthly transaction reporting.

Apple’s current commission is 26% of the price paid by the user, gross of VAT. South Korea entitlement

9.8 Netherlands dating apps

This is a category-specific exception created for dating apps on the Netherlands storefront. Developers can continue IAP or request entitlements for third-party in-app payment and/or a website purchase link. The special alternative-payment commission is generally three percentage points lower than the otherwise applicable commission — e.g., 27% instead of 30%, or 12% instead of 15% for an applicable reduced rate. Dating apps in the Netherlands

Do not treat this as a general rule for SaaS, gaming, productivity, or other Netherlands apps.

9.9 EEA music-streaming special case

Apple continues to publish a Music Streaming Services Entitlement (EEA) with category-specific eligibility. Apple notes that EU storefront usage is governed by applicable EU alternative terms for developers who agree to them, while the music-streaming entitlement’s special terms can remain relevant in Iceland and Norway. Music streaming entitlement — EEA

10. Master decision tree — start with “What is the customer buying?”

WHAT IS THE CUSTOMER BUYING?
|
+– A. Physical product / physical-world service?
|     |
|     +– Yes -> Use non-IAP payment (Apple Pay/card/PSP).
|     |          App Store commission normally 0%.
|     |
|     +– No -> continue.
|
+– B. Real-time service between exactly two individuals?
|     |
|     +– Yes -> Qualifying P2P exception can use external payment.
|     |          Examples: 1:1 doctor, tutor, lawyer, trainer, consultant.
|     |
|     +– Group / one-to-many -> default rule: IAP required.
|
+– C. Digital media reader (books/audio/music/video/news)?
|     |
|     +– Existing web purchase -> reader login/access can be allowed.
|     +– Need account link -> evaluate External Link Account Entitlement.
|     +– Need purchase CTA -> apply storefront-specific rules (US/EU/etc.).
|
+– D. Paid web service with free companion app?
|     |
|     +– No purchase or outside-purchase CTA in app -> companion exception
|     |   may provide 0% Apple web billing.
|
+– E. Enterprise-only organization/group sale?
|     |
|     +– Yes -> contract/invoice/web purchase; employees/students log in.
|     +– Consumer/single-user/family -> not covered by enterprise exception.
|
+– F. Multiplatform digital service?
|     |
|     +– Existing cross-platform entitlement can be recognized.
|     +– If sold in iOS app under default rules -> IAP.
|     +– Game consumables bought elsewhere -> must also be offered as IAP.
|
+– G. Advertising management for ads outside app?
|     |
|     +– Yes -> external payment can be used.
|     +– Boost/ad consumed in same app -> IAP.
|
+– H. Other digital feature/content/credit/subscription used in app?
      |
      +– Default -> IAP required.
      |
      +– Then check storefront:
            US -> external links/CTAs currently permitted; current linked-out
                  Apple commission 0% pending court-approved fee.
            EU -> current/future EU alternative terms and fees.
            Japan -> entitlement + regional Apple commission/reporting.
            Brazil -> entitlement + regional Apple commission/reporting.
            South Korea -> entitlement + 26% alternative-payment commission.
            Netherlands dating -> category-specific entitlement/fee.
            Other -> default rules unless another explicit exception applies.

10.1 Classification of the prompt’s A–AX categories

Category	Default classification / safest starting architecture
A Physical product	Non-IAP gateway; 0% App Store commission
B Physical service	Non-IAP gateway; 0%
C Food delivery	Non-IAP gateway; 0%
D Transportation	Non-IAP gateway; 0%
E Vehicle rental	Non-IAP gateway; 0%
F Hotel booking	Non-IAP gateway; 0%
G Airline ticket	Non-IAP gateway; 0%
H Event ticket	Non-IAP gateway; 0%
I Medical appointment	Real-world service; non-IAP
J 1:1 medical consultation	P2P real-time exception; non-IAP
K 1:1 tutoring	P2P real-time exception; non-IAP
L Group class	Default IAP if a live digital group service consumed in app
M Online course	Depends on delivery; digital course sold in app -> IAP
N Recorded video course	Digital content -> IAP for in-app sale; web-first access may be possible under appropriate model
O Ebook	Reader model for existing purchases; IAP for in-app digital sale under default rules
P Streaming subscription	Reader model may allow web-purchased access; in-app sale -> IAP by default
Q Music	Reader/streaming rules; regional EEA/EU rules can apply
R SaaS subscription	IAP for in-app consumer sale; web-first companion/multiplatform/enterprise can be 0% Apple where compliant
S Cloud storage	Explicit companion example; web-first + no in-app purchase CTA is strong 0% model
T AI credits	Digital in-app consumable/functionality -> IAP by default
U API credits	If used to power in-app digital functionality -> IAP; off-app developer API sold on web can use companion architecture
V Game currency	IAP; cannot expire; multiplatform consumables acquired elsewhere must also be available as IAP
W Virtual goods	IAP by default
X Creator subscription	Digital content/functionality -> IAP unless eligible reader/other exception
Y Marketplace transaction	Classify underlying good/service: physical -> non-IAP; digital -> IAP by default
Z Donation	Approved nonprofit rules can allow Apple Pay; ordinary “donation” tied to digital value becomes purchase/IAP
AA Charity	Approved nonprofit fundraising rules or outside-app fundraising for other charities
AB Crowdfunding	Case-specific; money for physical/offline outcome differs from digital reward/access
AC Advertising services	External if sole-purpose campaign management for ads outside app; same-app boosts use IAP
AD Enterprise software	Organization/group sale -> enterprise exception
AE B2B SaaS	Enterprise contract/invoice is safest 0% model; self-serve individual sale may not qualify
AF Employee app	Usually organization-provisioned; no consumer commerce
AG Business-management app	Web-first companion/B2B model often safest; in-app individual digital sale uses IAP by default
AH Reader app	Existing media subscriptions can be accessed; account-link entitlement rules apply
AI Companion app	Free stand-alone companion + no purchase/CTA can avoid IAP
AJ Crypto functionality	Wallet/exchange/mining restrictions under 3.1.5; premium digital unlocks still separately classified
AK NFTs/digital collectibles	IAP can sell NFT-related services; ownership must not unlock app functionality; external-link treatment is storefront-specific
AL Financial services	Financial transaction itself normally not IAP; app must meet licensing/provider rules; premium digital features are separate
AM Banking	Banking transaction not IAP; bank/provider rules apply
AN Insurance	Insurance app must be free and cannot use IAP; regulated purchase/payment handled outside IAP
AO Investment/trading	Financial institution/licensing rules; trades are not IAP purchases
AP Dating	Digital subscription IAP by default; U.S. links and Netherlands special program can change purchase path
AQ Social media	Premium digital features/subscriptions/boosts use IAP by default
AR Productivity tools	Consumer digital unlock -> IAP; web-first/enterprise/companion models can apply
AS Developer tools	Consumer digital feature -> IAP; web/API enterprise companion can be structured externally
AT Remote desktop	Guideline 4.2.7 imposes strict host/client behavior; host-device transactions can be outside IAP under that rule
AU Cloud IDE	App Review functionality/distribution risk must be assessed separately; do not assume remote-desktop exception
AV VPN	Digital service; in-app sale -> IAP by default; web-first existing subscription can be recognized under appropriate model
AW AI assistant	Digital feature/subscription -> IAP for in-app sale; web-first existing subscriber architecture can be 0% Apple if compliant
AX Generative AI subscription	Same: digital subscription; IAP for in-app sale under default rules, regional/web-first alternatives where allowed

11. Master scenario matrix — 60 practical cases

Legend: “IAP required” means required for the in-app sale under worldwide/default rules, unless a regional program or listed exception changes that result. “External link” refers to purchase steering from the app, which is storefront-specific.

#	Scenario	What is sold / consumed	Default IAP?	External gateway?	In-app external link?	Apple commission	Safest 0% architecture / restriction
1	Amazon-like physical ecommerce	Physical goods delivered	No; use non-IAP	Yes	Yes for physical checkout	0% App Store	Native checkout -> PSP -> fulfillment
2	Food delivery	Prepared food delivered	No	Yes	Yes	0%	App -> PSP/Apple Pay -> restaurant/courier
3	Grocery delivery	Physical groceries	No	Yes	Yes	0%	Standard ecommerce order flow
4	Uber-like taxi	Real-world ride	No	Yes	Yes	0%	Card/Apple Pay/PSP, trip ledger
5	Bike/scooter rental	Physical-world rental	No	Yes	Yes	0%	External payment; rental entitlement is real-world access
6	Car rental	Physical vehicle rental	No	Yes	Yes	0%	Booking/payment backend
7	Hotel booking	Lodging	No	Yes	Yes	0%	Booking engine + PSP
8	Airline ticket	Transportation	No	Yes	Yes	0%	Airline/travel checkout
9	Property booking/tour	Real-world booking/service	No	Yes	Yes	0%	Booking/deposit gateway
10	Concert/event ticket	Physical event attendance	No	Yes	Yes	0%	Ticket PSP + ticket wallet
11	Restaurant reservation/deposit	Real-world service	No	Yes	Yes	0%	PSP + reservation backend
12	Doctor clinic appointment	Offline medical service	No	Yes	Yes	0%	Payment/booking outside IAP; healthcare law applies
13	1:1 telemedicine	Real-time person-to-person	No under 3.1.3(d)	Yes	Purchase method other than IAP permitted	0%	Named patient-professional 1:1 session
14	1:1 online tutoring	Real-time two individuals	No	Yes	Permitted payment path	0%	Tutor booking + PSP
15	1:1 personal trainer	Real-time two individuals	No	Yes	Permitted payment path	0%	Trainer marketplace/booking
16	1:1 legal/consulting/coaching	Real-time two individuals	No	Yes	Permitted payment path	0%	Preserve real-time 1:1 nature
17	Live group fitness class	One-to-many digital service	Yes	Not as substitute under default	Storefront-specific regional route only	Standard IAP	Do not misclassify group class as P2P
18	Live group tutoring/webinar	One-to-few/one-to-many	Yes	Not under default	Regional only	Standard IAP	IAP for in-app sale
19	Udemy-like recorded course	Digital video/course	Yes for in-app sale	Web can sell outside app; app steering varies	Storefront-specific	IAP if sold in app	Web-first existing account may be usable; reader eligibility depends primary content/model
20	Coursera-like education	Digital course/subscription	Usually yes for in-app consumer sale	Web purchase possible	Storefront-specific	IAP for in-app sale	B2B institution contract or web-first access can reduce Apple fee if rules fit
21	Kindle-like ebook reader	Books/read media	IAP if selling in app; reader exception for existing purchase	Website can sell books/account	Reader entitlement / U.S. special rules	0% on independent web sale; IAP if in-app sale	Reader app + web acquisition + login
22	Netflix-like video streaming	Video subscription	IAP for in-app sale; reader access allowed	Web subscription	Reader account link / regional rules	0% on compliant web subscription	Reader model; no unsupported global buy CTA
23	Spotify-like music streaming	Music subscription	Same basic reader logic	Web subscription	U.S./EU/EEA rules vary	Depends route	Reader + region-specific link strategy
24	Paid newsletter/news app	Digital publication	IAP if sold in app; reader access can apply	Web subscription	Reader entitlement / regional rules	0% web possible	Treat news program participation separately
25	Podcast/audio subscription	Audio media	Reader-like if primary functionality qualifies	Web subscription	Reader/regional rules	0% web possible	Verify primary-function eligibility
26	Consumer Dropbox-like cloud storage	Digital cloud service	IAP if sold in app	Web subscription	Default companion has no purchase CTA; U.S./regions differ	0% web companion possible	Explicit 3.1.3(f) companion example
27	Zoom-like communications SaaS	Digital SaaS	IAP if consumer subscription sold in app	Web subscription	Storefront-specific	0% web companion/multiplatform possible	Subscription != P2P service payment merely because calls are 1:1
28	Slack-like B2B SaaS	Organization software seats	IAP for consumer/single-user in-app sale	Invoice/web contract	Enterprise path need not sell in app	0% enterprise possible	Tenant contract -> employee login
29	GitHub-like developer platform	Digital SaaS/dev service	IAP for in-app consumer digital tier	Web/enterprise billing	Storefront-specific	0% web/enterprise possible	Keep iOS app as client/companion to web service
30	Canva-like productivity SaaS	Digital features/templates	IAP for in-app consumer sale	Web subscription	Storefront-specific	0% web-first possible	Existing web entitlement; use IAP if merchandised in app under default
31	ChatGPT-like AI subscription	Digital AI functionality	Yes for in-app sale	Web subscription possible	Storefront-specific	IAP or permitted external route	Web-first login can be 0% Apple; in-app AI credits are digital
32	AI image/video generation credits	Digital consumable credits	Yes	Regional alternatives only	Storefront-specific	IAP/default	Credits used in app are not physical service
33	API credits used only by external servers	Off-app developer API capacity	Case-specific	Yes on web	Avoid in-app purchase merchandising unless allowed	Can be 0% web	Best as developer portal + companion/status app; if credits unlock iOS app use, classify as digital IAP
34	Cloud compute/hosting management	External infrastructure service	Companion architecture is strongest	Web/contract	Default companion: no purchase CTA	0% web possible	Web hosting is explicit 3.1.3(f) example
35	Domain registrar app	Domain registration/management	Case-specific; avoid assuming physical exception	Web billing safest	Storefront-specific	0% web companion possible	Management companion + web purchase is lower-risk than in-app digital checkout claim
36	VPN subscription	Digital network service	IAP for in-app sale	Web subscription possible	Storefront-specific	Depends route	Web-first existing account can reduce Apple fee; meet VPN/privacy rules
37	Online game	Digital gameplay	IAP	No substitute under default	Regional only	Standard IAP	StoreKit for currency, levels, consumables
38	Game currency	Virtual consumable	Yes	No under default	Regional only	Standard IAP	IAP credits cannot expire; cross-platform rule applies
39	NFT mint/list/transfer service	Digital collectible service	Apple allows IAP for these services	External links vary by storefront	U.S. differs	Depends route	NFT ownership must not unlock in-app features
40	Creator fan subscription	Digital creator content/features	IAP for in-app sale	Web purchase possible	Reader only if content/category truly qualifies; otherwise regional rules	Depends	Do not call every creator/social app a reader app
41	Social-media post boost	Promotion consumed/displayed in same app	Yes	No under default	Regional only	Standard IAP	Explicit ad-management exception does not cover same-app boosts
42	Advertising campaign manager	Ads shown outside app	No	Yes	Yes	0%	Sole-purpose advertiser campaign management
43	Etsy-like physical marketplace	Physical goods	No	Yes	Yes	0%	Marketplace PSP/split pay; platform take-rate separate
44	Home-services marketplace	Offline physical service	No	Yes	Yes	0%	Buyer -> provider -> service in physical world
45	Freelancing marketplace	Human service/deliverable	Depends on service	Yes for qualifying real-world/1:1 service	Case-specific	Often 0%, but classify deliverable	Pure digital-content sale or group service can change outcome
46	Digital asset marketplace	Digital downloads used in app	IAP by default	Not substitute	Regional only	Standard IAP	Underlying value is digital, unlike physical marketplace
47	Enterprise database app	Organization access	No in-app sale needed	Contract/invoice	Usually no purchase CTA needed	0% enterprise	3.1.3(c) example class
48	Employee internal app	Employer-provisioned access	No consumer purchase	Employer procurement	N/A	0%	Organization-managed account/license
49	Remote desktop client	Remote host access	Special 4.2.7 rules	Host transaction can be outside IAP if rule met	Carefully constrained	Can be 0%	Host device must be user-owned PC/server and interface mirror/extension; thin cloud client caveat
50	Cloud IDE	Remote/cloud development environment	Review architecture carefully	Web billing possible	Case-specific	Depends	Do not rely blindly on remote-desktop exception; App Review functionality rules are separate
51	Gym membership	Physical facility access	No	Yes, Apple Pay/cards	Yes	0%	Real-world gym service; digital-only fitness tier is different
52	Approved nonprofit donation	Donation, no digital quid pro quo	No IAP	Apple Pay as permitted	Per nonprofit rules	0% App Store	Must meet nonprofit/fundraising eligibility and law
53	P2P monetary gift	Optional 100% gift to receiver	No if Apple conditions met	External	Permitted if no digital benefit	0%	If gift buys/relates to digital content/service, IAP applies
54	Insurance app	Insurance product/service	IAP prohibited; app must be free	External/regulated payment	As permitted	0% App Store	Must be submitted by legal entity providing service and comply with law
55	Banking app	Banking transactions	No IAP for banking transaction	Banking rails	N/A	0% App Store	Digital premium app features are classified separately
56	Stock brokerage	Trading/investing	No IAP for trades	Regulated financial rails	N/A	0% App Store	App must be submitted by licensed financial institution as required
57	Crypto exchange	Cryptocurrency exchange transaction	Not IAP purchase system	Regulated exchange rails	N/A	0% App Store transaction commission	Licensing/geography and crypto guideline 3.1.5 apply
58	Dating subscription	Digital membership/features	IAP by default	Regional alternatives	U.S.; Netherlands entitlement; EU etc.	Depends storefront	Netherlands special fee is not 0%; U.S. currently differs
59	Paid downloadable app	App itself	App Store paid-app transaction	N/A	N/A	Standard/SBP commission	Free web-first app may be better for SaaS if business model supports it
60	Freemium app with lifetime Pro unlock	Digital non-consumable	Yes	No substitute under default	Regional alternatives only	Standard/SBP IAP	Non-consumable IAP + restore purchases

12. App design blueprints — recommended architecture by business model

The safest payment architecture does not begin with a payment SDK. It begins with a product classification, then maps payment sources into a single backend entitlement model.

12.1 Consumer SaaS

Recommended: hybrid-ready entitlement architecture

Use when: consumer conversion matters and you want IAP plus web acquisition.

Key rule: the app’s purchase UI must be storefront-aware. The backend should not care whether an entitlement came from IAP or web; it should care about validity, plan, scope, expiration, and source.

12.2 B2B SaaS

Safest policy posture: organization-level licensing, no consumer paywall, no individual self-serve purchase masquerading as “B2B.”

12.3 Streaming / reader

Web acquisition -> subscription -> media entitlement
                                  |
                             identity/account
                                  |
                           iOS reader app
                                  |
                         CDN / media service

Optional account link: only use External Link Account Entitlement if eligible and follow its exact UI/link requirements. Build U.S./EU regional purchase promotion separately rather than overloading the reader account link.

12.4 Education

Split education into three transaction families:

1:1 live tutor      -> external PSP -> live two-person session       (0% Apple)
Group live class    -> IAP/default -> group digital entitlement      (commission)
Recorded course     -> IAP if sold in app; web/institution model can differ
Enterprise school   -> institution contract -> student login         (0% enterprise)

Do not create one checkout rule for all “education.”

12.5 Marketplace

The catalog should carry a commerce_type or equivalent classification so the UI cannot accidentally route a digital SKU through a physical-goods PSP.

12.6 Ecommerce

Catalog -> cart -> shipping/tax -> Apple Pay/card/PSP -> order -> fulfillment

No StoreKit product is needed for the merchandise purchase. If the ecommerce app also sells a digital premium membership that unlocks in-app benefits, classify that membership separately rather than assuming the physical-store exemption covers it.

12.7 Booking / travel

Inventory/search -> quote -> booking hold -> external PSP -> reservation -> ticket/voucher

Maintain booking and payment state independently. Apple IAP should not be used for hotel, flight, rental-car, or comparable real-world reservations.

12.8 Healthcare

Payment compliance does not replace healthcare privacy, consent, prescription, medical-device, telemedicine, or licensing requirements.

12.9 Transportation

Rider -> route/fare -> trip request -> PSP authorization
                                   -> driver/vehicle
                                   -> trip completion
                                   -> capture/receipt

The fare is a real-world transportation service, so App Store digital IAP is not the right payment system.

12.10 AI SaaS

AI products often mix digital credits, subscriptions, external API usage, and enterprise contracts. Treat them separately.

                         +-> iOS individual subscription -> IAP/default
User/account -> plan —-+-> web individual subscription -> web entitlement
                         +-> enterprise contract ——–> org entitlement
                         +-> API-only credits ———–> developer entitlement

All sources -> normalized Entitlement Service -> iOS feature gates / API quotas

Important: an “AI token” does not become non-digital merely because computation occurs on a remote server. If the credit unlocks or pays for functionality consumed through the iOS app, it is digital app value under the default rule.

13. Hybrid payment architecture — IAP customers + website customers

Large SaaS products should assume multiple payment sources from day one even if they launch with one.

13.1 Normalize entitlement, not payment-provider objects

                    +——————+
                    | Apple StoreKit   |
                    | transaction data |
                    +———+——–+
                              |
                       validation/events
                              |
+————-+        +——v——-+        +—————-+
| Web billing +——->| Entitlement |<——-+ Enterprise CRM |
| Stripe/etc. | webhook| Service      | seats | / contracts    |
+————-+        +——+——-+        +—————-+
                              |
                    +———v———-+
                    | Subscription ledger |
                    +———+———-+
                              |
                   +———-v———-+
                   | Product/plan mapping |
                   +———-+———-+
                              |
                    +———v———+
                    | iOS + web clients |
                    +——————-+

13.2 Recommended subscription/entitlement schema

A production system needs more than the seven obvious columns, but these are a strong core:

Field	Purpose
user_id	Internal immutable user/account ID
organization_id	Tenant for B2B/enterprise access
plan_id	Internal normalized product plan
payment_source	apple_iap, web_stripe, web_adyen, enterprise_invoice, etc.
subscription_status	active, trialing, grace, retry, paused, canceled, expired, refunded
entitlement_status	Whether feature access is presently granted; do not equate blindly with billing status
started_at	Entitlement/service start
expiration_date	Current service expiration/end
original_transaction_id	Stable Apple subscription lineage identifier when Apple-backed
transaction_id	Current Apple transaction when relevant
external_customer_id	PSP customer identifier
external_subscription_id	PSP subscription identifier
storefront	App Store storefront associated with Apple/regional purchase logic
source_country	Billing/tax country if separately relevant
agreement_version	Fee/legal ruleset applied to the transaction
external_link_token	Regional external-purchase attribution token where applicable
latest_verified_at	Last successful authoritative verification
raw_event_ref	Immutable pointer to raw payment event for audit/replay

13.3 Event processing principles

1. Validate server-side. Do not trust a local “purchase succeeded” flag as durable entitlement authority.

2. Store raw immutable events. Preserve App Store Server Notifications/transaction data and PSP webhook payload references before deriving state.

3. Make processing idempotent. A retry must not grant two subscriptions or double-count revenue.

4. Separate billing status from entitlement status. Billing Grace Period is a classic example: payment may be in recovery while access remains valid.

5. Map products to internal plans. Apple product IDs and Stripe Price IDs are vendor identifiers, not your domain model.

6. Reconcile periodically. Compare the entitlement ledger against authoritative Apple/PSP states and flag drift.

7. Track refunds/revocations. A refund, chargeback, Family Sharing change, or revoked transaction can change access.

8. Persist storefront/fee rules. Regional compliance/reporting cannot be reconstructed reliably if you discard the source storefront and agreement version.

13.4 Purchase-source normalization example

Apple product com.example.pro.monthly
        -> internal plan PRO_MONTHLY

Stripe price price_web_pro_monthly
        -> internal plan PRO_MONTHLY

Enterprise contract SKU ENT_PRO_SEAT
        -> internal plan PRO_MONTHLY + organization scope

The iOS app asks the backend: “What can this account use?” not “Did this user pay Apple?”

14. Subscription master section

Auto-renewable subscriptions are not just recurring charges. They are a StoreKit lifecycle with pricing, renewal, grace, retry, offer eligibility, plan changes, cancellation, refund, and server-event implications.

14.1 Monthly and annual subscriptions

Both can be auto-renewable IAP products. Apple’s subscription guidelines require ongoing value, and an auto-renewable subscription period must be at least seven days. SaaS, cloud support, media libraries, and substantive ongoing updates are among Apple’s examples of appropriate subscription value. Guideline 3.1.2

14.2 Introductory offers and free trials

Apple supports introductory offers such as:

• free trial;

• pay as you go;

• pay up front.

Eligibility is tied to the subscription group and Apple’s offer rules. The client should request StoreKit eligibility rather than guess from a local “has_trialed” flag. Set up introductory offers

14.3 Promotional offers

Promotional offers can be used for existing or previously subscribed customers and can provide free or discounted subscription periods subject to Apple’s current limits and eligibility mechanics. Promotional offers

14.4 Offer codes and win-back offers

Offer codes can target new, active, or expired subscribers, and win-back offers can target eligible lapsed subscribers. These are lifecycle tools; they do not change the underlying rule that the subscription is an IAP subscription when sold through IAP. Offer codes and win-back offers

14.5 Upgrade, downgrade, and crossgrade

Use a single subscription group for mutually exclusive service levels. The important user-experience behavior is:

• Upgrade: normally effective immediately; Apple manages proration/refund behavior for the previous service level.

• Downgrade: normally effective at the next renewal date.

• Crossgrade: timing depends on whether the products are the same subscription level/duration and Apple’s rules.

Your backend should process authoritative transaction changes instead of manually calculating a “new expiry” from the button tap. Subscription level changes

14.6 Renewal and cancellation

Cancellation generally means “do not renew at the next billing boundary,” not immediate loss of already-paid service. Persist the current entitlement expiration separately from the auto-renew preference.

14.7 Billing retry and Billing Grace Period

If a renewal cannot be collected, the subscription can enter billing retry. Apple also supports Billing Grace Period, during which qualifying subscribers can retain paid-service access while Apple attempts recovery. Apple lets developers configure grace behavior and duration in App Store Connect. Billing Grace Period

Backend rule:

billing_status = retry/grace
entitlement_status = active <- can still be true during configured grace

Do not lock out a user solely because the PSP/IAP “latest payment succeeded” field is false.

14.8 Family Sharing

Eligible auto-renewable subscriptions and non-consumable IAP can support Family Sharing. Apple permits sharing with up to five additional family members when enabled. Model family access as a derived entitlement; do not duplicate the original purchaser’s transaction as a new purchase for each member. Family Sharing for IAP

14.9 Restore Purchases

Apple requires a restore mechanism for restorable purchases. A production app should expose a clear Restore Purchases action when applicable, verify the authoritative StoreKit state, and rehydrate the backend entitlement. Guideline 3.1.1

14.10 Which subscription events influence commission?

Under the standard worldwide model, the key fee dimension is cumulative paid service for auto-renewing subscriptions. Apple’s reporting distinguishes the “Rate Before One Year” from “Rate After One Year.” Small Business Program participation changes the proceeds rate from the beginning while eligible.

Regional programs add other clocks. Examples:

• Japan/Brazil actionable-link fee: relevant sales within seven days after link tap.

• Current EU pre-October terms: acquisition/store-services fee windows can depend on initial install and latest install/update/reinstall.

• New EU terms beginning October 1, 2026: different simplified commissions replace the pre-October layered model.

Your finance model therefore needs transaction date + storefront + agreement version + purchase source + attribution metadata, not merely plan and amount.

15. Free app vs paid app vs freemium — how Apple treats each

Free download

A free download itself has no App Store sales commission. But a “free app” can still generate commission when it sells digital IAP later. Free does not mean commission-free.

Paid download

The purchase price of a paid app is an App Store transaction and is subject to the applicable commission/program terms.

Freemium

The app downloads free; optional digital upgrades are sold using IAP under default rules. This is a common model for consumables, non-consumables, and subscriptions.

Paid feature / lifetime purchase

A permanent digital “Pro unlock” is normally a non-consumable IAP when sold in the app. It must support appropriate restoration.

Subscription

Recurring digital access generally uses auto-renewable IAP when sold in the app, with the subscription proceeds rules discussed above.

Free trial

A free trial is typically an introductory offer on an auto-renewable subscription. A free period does not itself create commission, but subsequent paid renewal does.

Consumable

Used/depleted and repurchasable, such as game currency or digital credits. Credits purchased via IAP may not expire under Apple’s guideline.

Non-consumable

Bought once and does not expire, such as a permanent feature unlock.

Auto-renewing subscription

Renews automatically until cancelled; ongoing value, subscription group design, and subscription lifecycle rules apply.

Non-renewing subscription

Time-limited access that requires a new purchase to extend. The app/developer has more responsibility for duration/renewal UX because it does not auto-renew.

16. App Store Review: what reviewers will inspect

App Review is not only a static-code check. Reviewers need to understand the business model and may test the real purchase/account experience. Apple’s Guidelines say a non-obvious business model should be explained in metadata and App Review notes, and review submissions should provide full access, a valid demo account/demo mode where needed, and a live backend. App Review Guidelines

16.1 Purchase and Subscribe buttons

Reviewers can ask:

• What does the button unlock?

• Is the value digital or physical?

• If digital and sold in-app, why is this not IAP?

• Is this a qualifying enterprise/P2P/reader/companion/regional flow?

• Is the IAP item submitted, visible, functional, and testable?

Bad design: “Upgrade Pro — $9.99” opens an unapproved Stripe WebView for a digital feature under a default storefront.

Compliant design: “Upgrade Pro” uses StoreKit IAP for the in-app digital plan, or a storefront-specific approved external flow where applicable.

16.2 External links and “Buy on Website” CTAs

Reviewers can inspect:

• whether the storefront permits it;

• whether an entitlement is required;

• whether the app uses the required StoreKit external-purchase APIs;

• whether link text and price language follow the program;

• whether browser vs WebView rules are satisfied;

• whether disclosures are shown;

• whether regional UI appears only in valid storefronts.

Do not ship the U.S. CTA globally unless the global storefront logic is independently compliant.

16.3 Pricing text

A displayed website price can be treated as communication/promotion of an outside offer. Reader-account-link rules, default storefront rules, and regional external-purchase programs differ. The safest implementation is a policy engine that decides whether price text is legal for this storefront and program, not a hard-coded marketing label.

16.4 QR codes

Guideline 3.1.1 expressly rejects proprietary mechanisms such as QR codes as substitutes for required IAP to unlock app functionality. A QR code is not a compliance loophole.

16.5 WebViews and browser redirects

The rendering technology does not decide whether a transaction is IAP-eligible. Specific programs also impose UI restrictions:

• Reader External Link Account Entitlement: default browser, not WebView.

• South Korea alternative in-app payment: native experience; not a WebView.

• EU/Japan/Brazil programs have their own current StoreKit and user-disclosure requirements.

16.6 Hidden checkout / remote configuration

Apple prohibits hidden, dormant, or undocumented functionality and expects material product behavior to be disclosed in Review Notes. A remote config that changes prices or product presentation can be normal; a remote config whose purpose is to hide a prohibited payment flow from review is not.

BAD DESIGN

if app_review_ip_range:
show IAP
else:
activate secret Stripe checkout

COMPLIANT DESIGN

storefront = StoreKit storefront
policy = server_policy(storefront, app_category, approved_entitlements)
render only the payment routes Apple currently permits for that storefront
and document the behavior in App Review notes.

16.7 Account creation and login-only apps

An app may be login-only when the business model legitimately expects users to arrive with existing accounts, but reviewers still need test credentials or a review mode. If account creation is available in the app, Apple’s account-deletion rule applies: apps that support account creation must let users initiate account deletion from within the app. Offering account deletion in your app

16.8 Restore Purchases

If the app has restorable IAP, provide a clear restore path and make it actually restore the backend entitlement, not merely call StoreKit and show “Done.”

16.9 Sign in with Apple / login-service rule

If the app uses a third-party or social login service for the user’s primary account, Guideline 4.8 requires an equivalent login option with Apple’s specified privacy characteristics unless an exception applies, including certain enterprise/education/business and client-for-specific-third-party-service cases. Evaluate login compliance separately from payment compliance. Guideline 4.8

16.10 Metadata and screenshots

Do not assume only executable UI is reviewed. External purchase messaging in screenshots, promotional copy, review notes, and metadata can be policy-relevant. The U.S. injunction also addresses metadata in the anti-steering context, while Apple’s current Guidelines remain the operational submission reference.

16.11 Region-dependent payment UI

Recommended state machine:

startup
-> fetch StoreKit storefront
-> fetch signed server commerce policy for app version + storefront
-> confirm required entitlement capability is compiled/enabled
-> render allowed payment choices
-> log policy version for support/audit

Never determine a special payment route solely from locale language, device region, SIM, VPN, or IP address.

16.12 Common rejection reasons

1. Selling a digital feature through Stripe/PayPal/etc. instead of required IAP.

2. A “Go to website to subscribe” CTA in a storefront/program where it is not allowed.

3. Misusing reader-app status for an app whose primary function is not eligible media.

4. Calling a one-to-many digital class “person-to-person.”

5. Calling a self-serve consumer plan “enterprise.”

6. External-link entitlement implementation that violates link formatting/destination rules.

7. South Korea external purchase in a WebView or mixed with IAP in the same entitlement app.

8. Missing required regional disclosure sheets/APIs.

9. Hidden or remotely activated payment behavior.

10. Incomplete IAP metadata or purchase flow not testable by reviewer.

11. Missing Restore Purchases for restorable products.

12. Account creation without in-app account deletion.

13. Review account does not work or backend is offline.

14. Business model is unclear and not explained in Review Notes.

15. Digital product is disguised as physical/offline value.

17. Economic comparison — what the commission actually costs

A payment strategy is a unit-economics decision, not only a policy exercise. IAP can improve conversion because users have a stored payment method, familiar Apple purchase sheet, trust, subscription management, family/Ask-to-Buy ecosystem features, tax/commerce support, and fewer checkout steps. External billing can reduce Apple fees but adds PSP, billing, fraud, tax, refunds, customer support, and potentially lower conversion.

17.1 Illustrative annual revenue table

Assumptions solely for comparison:

• digital revenue before fees: values shown below;

• Apple 30% and 15% cases ignore tax to isolate commission;

• external-card example uses 2.9% + USD 0.30 per transaction, assuming an average transaction of USD 100, i.e. approximately 3.2% effective processing;

• does not include Stripe Billing, Tax, Radar, international-card, FX, chargeback, or other optional/additional fees;

• “web-first 0% Apple” means a business model legitimately outside Apple commission, not a prohibited bypass.

Stripe U.S. card pricing

Annual digital revenue	Apple 30%	Apple 15%	External processor ~3.2%	Web-first: Apple commission	Approx. net after processor only
$10,000	$3,000	$1,500	$320	$0	$9,680
$100,000	$30,000	$15,000	$3,200	$0	$96,800
$500,000	$150,000	$75,000	$16,000	$0	$484,000
$1,000,000	$300,000	$150,000	$32,000	$0	$968,000
$5,000,000	$1,500,000	$750,000	$160,000	$0	$4,840,000

These numbers do not prove external billing is better. A 30% commission with meaningfully higher conversion/LTV can beat a 3.2% processor with a checkout cliff. Test economics, not ideology.

17.2 Japan example: external payment is cheaper than IAP but not 0%

Ignoring tax and PSP cost on a $100 standard digital purchase:

• IAP: 21% App Store commission + 5% Apple processing = $26 Apple fees.

• Alternative in-app PSP: $21 Apple commission + PSP fee.

• Actionable external link within Apple’s relevant 7-day attribution window: $15 Apple store-services commission + PSP fee.

17.3 South Korea example

A $100 price paid through the sanctioned alternative in-app route is subject to Apple’s 26% commission, with the official basis stated gross of VAT; merchant PSP/tax economics sit on top according to the actual transaction. That may or may not be economically preferable to IAP depending on the full fee stack and conversion.

17.4 Current U.S. link-out example

As of September 5, 2026, the court-approved Apple linked-out commission is 0% because no future fee has yet been approved. A web processor still charges its own fees. Because Apple has proposed a future schedule and the Supreme Court litigation continues, model a contingency rather than assuming permanent zero.

18. Founder decision framework

Before choosing IAP, web-only, or hybrid, answer these ten questions.

1. Is the product digital or physical? If physical/offline, stop trying to use IAP.

2. Where is the value consumed? A remote server can still provide digital in-app value; location of CPU execution is not the test.

3. B2C or B2B? Enterprise-only organization sales have a specific exception; individual consumer sales do not inherit it.

4. Is the app truly a reader? Primary functionality must fit Apple’s reader media categories.

5. Is it truly a free stand-alone companion? No purchasing and, under the default companion rule, no external-purchase CTA.

6. Is the service exactly one-to-one in real time? If group, the P2P exception does not apply.

7. Is the user already a customer? Existing account access is different from acquiring the customer inside the iOS app.

8. Do you need iOS as an acquisition channel? If yes, IAP conversion may be worth the commission.

9. Which storefront applies? U.S., EU, Japan, Brazil, Korea, Netherlands dating, and default rules differ.

10. Is conversion more valuable than avoiding commission? Measure checkout completion, refund/support costs, LTV, churn, and cross-platform retention.

Decision scorecard

Factor	IAP-first advantage	Web-first advantage
Checkout friction	Strong	Usually weaker unless customer already on web
Stored payment trust	Strong	PSP/brand dependent
Global policy simplicity	Stronger for digital in-app sales	More category/storefront analysis required
Apple commission	Higher	Can be 0% in legitimate models; regional links may still have Apple fees
Merchant tax burden	Apple provides substantial commerce/tax handling for IAP	Developer/merchant generally owns more tax obligations
Refund/support	Apple ecosystem handles IAP workflows	Developer/PSP handles more
Cross-platform billing control	Lower	Strong
Pricing flexibility / bundles	StoreKit constraints	Strong web control
Enterprise invoicing	Poor fit	Excellent
App Review risk	Low when correctly implemented	Low only when classification/linking is correct

19. Five architecture choices

Architecture A — Maximum convenience: IAP-first

iOS -> StoreKit -> App Store -> server validation -> entitlement

Advantages: highest native convenience, trusted one-tap experience, Apple commerce infrastructure, simpler default global digital-sales compliance.

Disadvantages: Apple commission; less direct billing ownership; platform subscription constraints.

Apple fees: standard/regional IAP terms.

Gateway fees: Apple processing is embedded/decomposed according to the applicable Apple fee model; no Stripe card fee for the IAP transaction.

UX/conversion: usually strongest.

Complexity: medium.

Review risk: low if StoreKit/subscription UX is correct.

Architecture B — Lowest Apple commission: web-first

Web acquisition -> PSP -> entitlement -> iOS login

Advantages: can reach 0% Apple commission in legitimate reader/companion/enterprise/multiplatform/other permitted models; direct billing relationship.

Disadvantages: web acquisition burden, PSP/tax/support, possible lower conversion, in-app CTA restrictions outside special storefronts.

Apple fees: 0% only where the architecture actually falls outside commission; regional link programs may impose fees.

Gateway fees: PSP/card/billing fees.

Complexity: medium-high.

Review risk: low when the category is clean; high if the design is actually a disguised in-app digital sale.

Architecture C — Hybrid: web + IAP

IAP ——-> entitlement <——- web billing

Advantages: native iOS conversion plus direct web acquisition; flexible global strategy.

Disadvantages: two billing lifecycles, reconciliation, price parity/merchandising complexity, region-specific link UX.

Apple fees: Apple commission only for applicable Apple/region-attributed transactions.

Gateway fees: both Apple and external economics depending source.

Complexity: high, but best long-term architecture for many consumer SaaS products.

Review risk: medium unless payment UI is rigorously storefront-aware.

Architecture D — B2B enterprise: contract/invoice + login

Sales -> MSA/order form/invoice -> tenant -> seats -> SSO -> iOS

Advantages: 0% App Store commission on qualifying direct organization sale; supports procurement, annual contracts, invoicing, negotiated pricing.

Disadvantages: sales/provisioning systems required; not a consumer self-serve loophole.

Gateway fees: bank/ACH/card/invoice platform as negotiated.

Complexity: medium-high backend, simple app.

Review risk: low if the enterprise-only model is obvious and documented.

Architecture E — Physical services: native external checkout

iOS -> cart/booking -> Apple Pay/card/PSP -> fulfillment

Advantages: correct Apple model; no App Store commission.

Disadvantages: merchant owns payment/tax/refund/fraud stack.

Apple fees: 0% App Store commission on the physical/offline transaction.

Gateway fees: PSP/acquirer/card-network costs.

UX: Apple Pay can provide excellent native conversion.

Review risk: low if the product is genuinely physical/offline.

20. Common myths — 25 corrections

1. Myth: “Apple takes 30% of every app payment.”

Correction: Apple commission depends on digital vs physical value, storefront, program, entitlement, subscription age, and transaction path. Physical/offline transactions are generally outside IAP.

2. Myth: “If I use Stripe, Apple cannot charge me.”

Correction: A PSP does not change product classification. Some regional alternative-payment programs still impose Apple commission.

3. Myth: “Apple Pay means Apple takes 30%.”

Correction: Apple Pay is a payment method; IAP is App Store digital commerce.

4. Myth: “A free app never pays Apple commission.”

Correction: Free download can later sell commissionable digital IAP.

5. Myth: “If my website processes payment, Apple can never charge a fee.”

Correction: In-app steering to a website can trigger regional Apple fees/reporting. Independent web acquisition is a different flow.

6. Myth: “All subscriptions must use IAP.”

Correction: Enterprise, reader, companion, web-first existing-account, P2P, and regional rules can permit non-IAP models. In-app consumer digital subscription sales normally use IAP under default rules.

7. Myth: “Apple takes commission from Uber rides.”

Correction: Real-world transportation is a service consumed outside the app and uses non-IAP payment.

8. Myth: “Apple takes commission from Amazon physical purchases.”

Correction: Physical ecommerce checkout is outside IAP.

9. Myth: “B2B SaaS always needs IAP.”

Correction: Direct organization/group licensing for employees/students has an enterprise-services exception.

10. Myth: “Calling my consumer plan B2B makes it enterprise.”

Correction: Apple explicitly distinguishes consumer/single-user/family sales from direct organization/group sales.

11. Myth: “Reader apps can sell anything externally.”

Correction: Reader status is limited to primary media categories and its account-link entitlement is tightly constrained.

12. Myth: “Small Business Program means all my payments are 15%.”

Correction: It reduces eligible paid-app/IAP commission; it does not turn physical PSP fees or every regional fee into 15%.

13. Myth: “Every subscription automatically drops to 15% after one calendar year.”

Correction: Apple’s standard rule is based on a subscriber accumulating one year of paid service, with detailed continuity rules.

14. Myth: “A WebView makes Stripe checkout compliant.”

Correction: Rendering checkout in HTML does not change what is being sold; some entitlements expressly disallow WebView.

15. Myth: “A QR code can bypass IAP.”

Correction: Guideline 3.1.1 expressly rejects proprietary unlock mechanisms including QR codes as substitutes for required IAP.

16. Myth: “AI credits are a physical compute service because servers do the work.”

Correction: Credits paying for in-app digital functionality are digital app value under the default classification.

17. Myth: “One teacher + many students is person-to-person.”

Correction: Apple states one-to-few and one-to-many real-time services must use IAP under default rules.

18. Myth: “All marketplaces avoid IAP.”

Correction: Physical/offline marketplaces do; digital in-app marketplaces generally do not.

19. Myth: “Advertising is always external-payment eligible.”

Correction: Sole-purpose management of ads shown outside the app is; buying a boost displayed in the same app uses IAP.

20. Myth: “South Korea alternative payment means 0% Apple.”

Correction: Apple currently charges 26% on the sanctioned alternative in-app route.

21. Myth: “Japan external checkout is 0% Apple.”

Correction: Current Japan regional terms specify Apple commissions on alternative in-app payments and actionable external links.

22. Myth: “The EU has one permanent 2026 fee schedule.”

Correction: There is a major transition on October 1, 2026; pre-October and post-October models must be separated.

23. Myth: “The U.S. 0% link-out status is guaranteed forever.”

Correction: It is the current result of active federal litigation pending a court-approved fee and Supreme Court proceedings.

24. Myth: “If App Review approved it once, the payment design is permanently safe.”

Correction: Policy, agreements, laws, storefront rules, and app behavior change. Approval is not a perpetual exemption.

25. Myth: “The best strategy is always to avoid Apple commission.”

Correction: IAP can increase conversion and reduce merchant billing/tax/support burden. Optimize lifetime economics, not fee percentage alone.

21. Developer FAQ — 60 questions

1. Does Apple take 30% from Stripe?

Not simply because Stripe is used. For physical/offline transactions, Apple App Store commission is generally 0%. For digital app value, Stripe cannot replace required IAP under default rules; in regional alternative-payment programs Apple may still charge its own commission in addition to Stripe’s fee.

2. Can I put Stripe Checkout in a WebView?

Not as a generic workaround for required IAP. The product classification still controls, and some programs expressly forbid WebView for the external payment flow.

3. Can I open Safari for payment?

For physical/offline goods, yes as part of an ordinary external checkout. For digital goods, whether the app may steer to Safari depends on storefront/category/entitlement. Reader account links must open the default browser; U.S. storefront rules currently permit external CTAs without the former entitlement.

4. Can I mention my website?

Yes in ordinary non-purchase contexts, but language that communicates or promotes an external digital purchase can be payment-policy relevant. Reader entitlement and regional programs have specific wording rules.

5. Can I show website prices in my iOS app?

It depends on storefront and entitlement. Do not globally show external digital prices based on U.S. rules. The reader account-link entitlement specifically restricts price language attached to that link, while some regional purchase-promotion programs allow price communication under their terms.

6. Can users create accounts in the app?

Generally yes. Reader apps may offer account creation for free tiers. If your app supports account creation, Apple requires users to be able to initiate account deletion in the app.

7. Can users log in to accounts purchased elsewhere?

Often yes under reader, multiplatform, enterprise, companion, or other valid existing-customer models. The exact exception must fit the product.

8. Can I disable signup on iOS?

Yes when a login-only experience is legitimate, but App Review still needs access/demo credentials and the business model must make sense rather than being a disguised attempt to force prohibited payment steering.

9. Can I make the app login-only?

Yes for many enterprise, reader, companion, and existing-customer applications. Explain the model clearly in App Review notes and provide a working test account.

10. Can users subscribe on Android and use iPhone?

Multiplatform services can allow access to content/subscriptions/features acquired on other platforms. If the app also sells the same digital service on iOS under default rules, that in-app sale uses IAP.

11. Can users subscribe on Windows and use iPhone?

Yes under the same existing-entitlement/multiplatform logic when the app/business model fits Apple’s rules.

12. Can a company buy licenses for employees?

Yes. Apple’s enterprise-services exception allows direct organization/group purchases for employees/students and subsequent app access. Consumer/single-user/family sales are different.

13. Can I invoice enterprise customers?

Yes for qualifying B2B/enterprise contracts. Provision tenant/seat entitlements and let users log in.

14. Can I sell API credits?

If the credits are truly for an external developer API and the iOS app is a management companion, web billing can be appropriate. If those credits pay for in-app digital functionality, they are normally IAP digital consumables under default rules.

15. Can I sell AI tokens or credits?

If consumed to run AI features in the iOS app, normally use IAP for the in-app sale. Website or enterprise purchase can be recognized where a valid web-first/multiplatform/enterprise model applies.

16. Can I sell cloud compute credits?

Classify what they unlock. External infrastructure credits sold through a web developer portal can fit a companion model; credits bought in the app to unlock in-app digital functionality are IAP territory.

17. Can I sell storage?

Cloud storage is one of Apple’s explicit free-stand-alone-companion examples. A web-paid storage service can have a free iOS companion with no in-app purchasing/CTA under that rule. If you sell the storage upgrade in the iOS app, use IAP under default rules.

18. Can I sell a Zoom-like subscription externally?

A web-first paid service with an iOS companion/multiplatform client can be legitimate. But a consumer subscription sold in the iOS app is a digital SaaS subscription and normally uses IAP.

19. Can I charge for one-to-one tutoring?

Yes through non-IAP payment when it is a real-time service between two individuals. Group tutoring does not qualify under that exception.

20. Can I sell recorded courses?

If sold in the app for consumption in the app, they are digital content and normally use IAP. Institutional sales or valid web-first content models can differ.

21. Can I charge for live group classes?

Under Apple’s default P2P rule, one-to-few and one-to-many real-time services must use IAP.

22. Can I charge for gym memberships?

A membership for a physical gym/service consumed outside the app can use Apple Pay/cards/PSP and has no App Store commission on the transaction. A digital-only workout subscription sold in the app is different.

23. Can I accept donations?

Approved nonprofits can conduct fundraising under Apple’s nonprofit rules, including permitted Apple Pay flows. A payment tied to digital benefits is not a pure donation and can become IAP.

24. Can I charge marketplace sellers?

Yes for legitimate marketplace/business services, but classify what the seller is buying. An advertising boost shown in the same app is a digital IAP; a commission on a physical marketplace transaction is outside IAP.

25. Can I take a commission on physical bookings?

Yes. Your platform’s commission/take-rate is separate from Apple. The buyer transaction for a physical/offline service is generally outside IAP.

26. Can I use Apple Pay?

Yes where Apple Pay is appropriate, especially physical goods/services and eligible donations. Apple Pay does not replace required IAP for digital in-app value.

27. Can I use Google Pay?

If your PSP/platform supports it in the relevant non-IAP context, payment rail choice is secondary to Apple’s product classification. Availability on iOS varies by provider/market. Do not treat it as an IAP substitute for digital app value.

28. Can I use PayPal?

Yes for physical/offline/permitted external transactions. Not as a generic replacement for required IAP.

29. Can I use Razorpay?

Yes in appropriate non-IAP or approved regional payment flows, subject to Razorpay market/product support and Apple’s applicable rules.

30. Can I use Adyen or Braintree?

Same principle: yes for transactions where external payment is allowed/required; no as a default-rule substitute for IAP digital commerce.

31. Can I use Square?

Yes for eligible real-world/physical commerce; classification still controls.

32. Can Apple reject my app over payment design?

Yes. Common causes include non-IAP digital checkout, unapproved external CTAs, misuse of an exception, hidden flows, missing regional disclosures, and an untestable IAP implementation.

33. Can Apple remove my developer account?

Serious or repeated deception, fraud, or deliberate policy circumvention can escalate beyond a single rejection. Apple explicitly warns that misleading entitlement/payment practices can lead to app removal and possible Developer Program removal.

34. Can I remotely enable Stripe after review?

Do not do this to conceal a noncompliant digital purchase path. Hidden/dormant/undocumented payment functionality is exactly the kind of evasion to avoid.

35. Can I use a QR code that opens my website checkout?

Not as a substitute for required IAP. Apple’s guideline explicitly lists QR codes among proprietary unlock methods that cannot replace IAP for app functionality.

36. Can I email users a web purchase offer?

Apple’s default guideline permits developers to communicate outside the app with users about purchasing methods other than IAP. Email/SMS marketing still has privacy, consent, anti-spam, and local-law obligations.

37. Can my website be cheaper than IAP?

Web pricing strategy is commercially possible, but what the app may say/show/link about that price depends on storefront and program. Also assess Apple’s regional business terms and any platform agreement constraints applicable to the transaction.

38. Do U.S. apps need the External Link Account Entitlement to link out?

Current App Review Guidelines say the entitlement is not required for buttons, external links, or other calls to action in U.S. storefront apps.

39. Does Apple currently charge a U.S. external-link commission?

As verified September 5, 2026, the Ninth Circuit says Apple should not charge linked-out commission until the district court approves an appropriate fee, and no such future fee has yet been approved. The case remains active, so verify again before launch.

40. Is Apple’s proposed 15% U.S. link-out fee current law/fee?

No. It is a proposal in ongoing litigation as of this guide’s verification date, not the currently approved linked-out fee.

41. Are EU external payments 0% Apple?

No, not generally. Current EU alternative terms impose layered Apple fees, and the unified terms announced for October 1, 2026 also specify commissions on alternative in-app and actionable linked-out digital sales.

42. What changes in the EU on October 1, 2026?

Apple’s announced unified model replaces the previous layered terms with new commission schedules, including 26% standard IAP, 20% standard alternative in-app, 15% standard actionable linked-out sales, and 5% CTC for specified digital transactions outside the App Store, with reduced rates/waivers in defined cases.

43. Are Japan external payments 0% Apple?

No. The current model has 21%/10% App Store commission on relevant digital sales and 15%/10% store-services commission on relevant actionable link-outs; IAP adds a separate 5% Apple processing component.

44. Are Brazil external payments 0% Apple?

No. Brazil’s current regional fee model similarly retains Apple commission and reporting obligations.

45. Is South Korea alternative payment 0% Apple?

No. Apple currently states a 26% commission on the sanctioned third-party in-app payment route.

46. Can I use IAP and South Korea alternative payment in the same app?

Under the current South Korea entitlement, no. Apple says the entitlement-enabled app cannot use Apple’s IAP and requires a separate Korea-only binary.

47. Can any Netherlands app use third-party digital checkout?

The special Netherlands entitlement described here is specifically for dating apps. Do not generalize it to all categories.

48. Does a reader app have to use IAP?

A reader app can let users sign in and access previously purchased eligible media content/subscriptions. If it chooses to sell qualifying digital content inside the app, the ordinary IAP rules apply unless a regional mechanism changes the purchase route.

49. Can a reader app link directly to checkout?

The classic External Link Account Entitlement is an account-creation/management link with strict rules, not a generic checkout button. U.S. and regional external-purchase rules can separately permit broader purchase promotion.

50. Can a social-media app call itself a reader because it has video?

Not simply because it displays media. Apple says media must be the app’s primary functionality for reader eligibility and gives social networking with streamed audiovisual content as a non-qualifying example.

51. Can my app sell NFTs with Stripe?

NFT rules distinguish NFT services, ownership, and functionality. Apple permits IAP for NFT minting/listing/transferring and restricts using NFT ownership to unlock app functionality. External-purchase links are storefront-specific; get specialized review for novel crypto/NFT flows.

52. Can a crypto exchange use IAP to buy cryptocurrency?

Cryptocurrency exchange transactions are governed by Apple’s crypto/financial-service rules and licensing requirements, not treated as ordinary IAP virtual goods. Premium digital app features remain a separate classification.

53. Can an insurance app use IAP?

Apple’s guideline says insurance apps must be free, comply with law, and may not use IAP. The regulated insurance transaction is handled through the provider’s permitted systems.

54. Can a brokerage use IAP for stock purchases?

No; securities trading is a regulated financial transaction, and Apple has separate provider/licensing rules. A premium digital analytics feature sold in the app is a separate question.

55. Can a remote-desktop app avoid IAP?

Potentially for transactions occurring on the host device if the app strictly meets Guideline 4.2.7’s remote-desktop conditions. Do not stretch that rule to an ordinary thin client for cloud apps.

56. Do I need receipt validation?

For IAP, use current StoreKit/App Store Server APIs and authoritative transaction verification; do not gate durable paid access on an unverified local flag. “Receipt validation” is often used generically, but modern StoreKit transaction/server verification should drive the architecture.

57. Do I need webhooks/server notifications?

For production subscriptions, yes. Use App Store Server Notifications for Apple lifecycle events and PSP webhooks for web billing, process them idempotently, and reconcile against authoritative state.

58. Should Apple and Stripe subscriptions share the same database table?

They should share a normalized entitlement/subscription domain model, while preserving provider-specific transaction/event tables. Do not throw away the source identifiers or raw audit data.

59. Should I store the App Store storefront on each transaction?

Yes when regional commerce logic may matter. Storefront, agreement/policy version, payment source, and external-link attribution are important for compliance, finance, and reporting.

60. What is the safest way to minimize Apple commission without rejection?

Choose a business model that genuinely qualifies: physical/offline service, enterprise organization sale, qualifying real-time one-to-one service, reader/companion/web-first existing-customer model, or an explicit regional program. Then document it clearly and implement the exact UI/entitlement/reporting rules. Do not hide the payment route.

22. Before Submitting an App That Has Payments — master checklist

Business-model classification

☐ We can state in one sentence exactly what the customer buys.

☐ Each SKU is classified as physical/offline, digital in-app, enterprise, P2P, reader, companion, advertising management, financial, donation, or another explicit class.

☐ We do not assume the entire app has one classification if it sells mixed products.

☐ We have documented why each non-IAP digital-looking transaction fits an Apple exception or regional program.

Storefront and regional rules

☐ We know which App Store storefronts the binary supports.

☐ Payment UI is keyed to StoreKit storefront/program eligibility, not IP geolocation alone.

☐ U.S. external-link behavior is isolated from worldwide/default behavior.

☐ EU logic distinguishes pre-Oct 1, 2026 terms from the new unified terms.

☐ Japan/Brazil/Korea/Netherlands special flows use the correct entitlement and OS/version requirements.

☐ We have a policy-version feature flag so a future legal/Apple change can be deployed safely.

IAP and StoreKit

☐ Required digital features use IAP unless a verified exception applies.

☐ App Store Connect products are complete, submitted, visible, and testable.

☐ Product IDs map to internal plan IDs; they are not the domain model.

☐ Purchases are verified authoritatively.

☐ App Store Server Notifications are processed idempotently.

☐ Restorable products have a working Restore Purchases path.

☐ Subscription group / upgrade / downgrade / crossgrade behavior is intentional.

☐ Billing Grace Period and retry states do not accidentally revoke valid access.

☐ Refund/revocation events are handled.

☐ Family Sharing behavior is handled if enabled.

External gateway / website

☐ The gateway is used only where external payment is allowed or required.

☐ We know who handles tax, refunds, chargebacks, fraud, and customer support.

☐ External checkout does not masquerade as a physical purchase.

☐ Reader account links meet the exact domain/browser/wording/URL rules.

☐ South Korea external payment is native, not WebView, and uses approved configuration.

☐ Regional actionable links implement required StoreKit APIs/tokens/disclosures.

☐ We can generate required alternative-payment transaction reports to Apple.

Backend entitlement architecture

☐ Apple and web payments feed one normalized entitlement service.

☐ Raw provider events are retained for audit/replay.

☐ Event handlers are idempotent.

☐ We store source, plan, status, expiry, transaction lineage, and external customer/subscription IDs.

☐ Storefront and agreement/policy version are persisted when relevant.

☐ A scheduled reconciliation job detects drift between providers and entitlement state.

☐ Account/organization roles cannot accidentally grant paid access without an entitlement decision.

App Review

☐ Review Notes explain the business/payment model in plain language.

☐ A valid demo account or full demo mode is provided if login is required.

☐ Backend services are live during review.

☐ Non-obvious features and IAP are explained.

☐ No hidden, dormant, reviewer-only, or remotely activated payment path exists.

☐ Screenshots/metadata do not advertise a payment flow the binary cannot legally present.

☐ Regional payment UI is testable and appears only in eligible storefronts.

☐ Account creation includes in-app account-deletion initiation.

☐ Login complies with Guideline 4.8 where applicable.

Legal, tax, and customer terms

☐ Privacy policy identifies payment/account data flows.

☐ Terms of service explain billing, renewal, cancellation, and refunds.

☐ External-payment tax responsibility is assigned and implemented.

☐ Required VAT/GST/sales-tax registrations and invoices are handled.

☐ Refund, cancellation, and dispute flows work for both Apple and external payment sources.

☐ Regulated products (health, finance, crypto, insurance) have separate legal/compliance review.

23. SEO and publishing pack

SEO title: Apple App Store Commission & IAP Guide 2026: External Payments and Legal 0% Architectures

Meta description: A current 2026 master guide to Apple App Store commission, 15%/30% fees, IAP, Stripe and external payments, reader/B2B/SaaS rules, U.S./EU/Japan/Korea/Brazil differences, and policy-compliant 0% Apple commission architectures.

URL slug: apple-app-store-commission-iap-external-payments-zero-percent-guide-2026

Suggested H1: Apple App Store Commission, In-App Purchase, External Payments & Legal 0% Commission Architecture — 2026 Master Guide

Recommended H2/H3 hierarchy

• H2: What Apple App Store Commission Really Means

• H3: When Apple Charges Commission

• H3: When Apple Does Not Charge Commission

• H3: Commission vs Taxes vs Processing Fees

• H2: In-App Purchase (IAP) Explained

• H3: When IAP Is Mandatory

• H3: When IAP Is Optional

• H3: When IAP Should Not Be Used

• H2: Apple Pay vs Apple IAP

• H2: Stripe, PayPal, Razorpay, Adyen and External Gateways

• H2: Website Payments and External Links

• H2: How to Legally Reach 0% Apple Commission

• H2: Apple Payment Rules by Region

• H3: United States

• H3: European Union

• H3: Japan

• H3: Brazil

• H3: South Korea

• H3: Netherlands Dating Apps

• H2: SaaS and B2B Payment Architecture

• H2: Hybrid IAP + Web Billing Architecture

• H2: Subscription Commission and StoreKit Lifecycle

• H2: App Review Rejection Risks

• H2: Economic Comparison

• H2: 60-Scenario Matrix

• H2: Developer FAQ

• H2: App Submission Checklist

Featured-snippet answers

Does Apple always take 30%?

No. Apple’s fee depends on the product and storefront. Physical goods and real-world services generally pay 0% App Store commission; Small Business Program IAP can be 15%; qualifying subscription renewals move to a 15% effective commission under the standard model; and regional payment programs use other fee structures.

Can an iOS app use Stripe?

Yes when external payment is allowed — for example physical goods, real-world services, qualifying one-to-one services, enterprise/web transactions, or an approved regional alternative-payment program. Stripe cannot simply replace required IAP for digital in-app value under default rules.

Can users pay on a website and use the iOS app?

Often yes. Reader, multiplatform, enterprise, and free companion models can recognize existing web purchases. Whether the app may actively link to or promote the website checkout depends on the App Store storefront and applicable entitlement/program.

When can Apple commission be 0%?

Common examples include physical/offline sales, qualifying one-to-one real-time services, direct enterprise organization licenses, compliant existing web subscriber access, approved companion/reader architectures, and — currently — U.S. linked-out purchases while the federal court has not approved a future Apple fee.

FAQ schema-ready question set

The 60 questions in Section 21 are written as concise standalone questions and can be mapped directly to FAQPage JSON-LD where search-engine policy permits. Do not mark up answers that are not visible on the published page, and do not assume FAQ rich results are guaranteed.

24. Final quick reference

Apple commission can often be 0% when

• physical goods are sold;

• real-world/offline services are sold;

• eligible real-time one-to-one services are sold;

• enterprise/B2B licenses are sold directly to organizations/groups for employees/students;

• existing web subscribers merely log in under a compliant reader/multiplatform/companion model;

• an eligible reader or companion architecture is used correctly;

• approved nonprofit/P2P-gift or other explicit exceptions apply;

• a current regional rule explicitly produces 0% Apple fees — notably current U.S. linked-out purchases as of the verification date, subject to active litigation.

Apple commission commonly becomes relevant when

• digital content;

• digital functionality;

• app subscriptions;

• virtual goods;

• digital consumables;

• premium features;

• game currency;

• in-app AI credits;

• same-app advertising/boosts

are sold through or in connection with the iOS app under a route governed by Apple’s digital-commerce terms.

Final rule to remember

1. CLASSIFY WHAT IS SOLD.
2. IDENTIFY WHERE THE VALUE IS CONSUMED.
3. CHECK APP CATEGORY / EXCEPTION.
4. CHECK THE APP STORE STOREFRONT.
5. CHECK THE ENTITLEMENT + AGREEMENT VERSION.
6. ONLY THEN CHOOSE IAP, APPLE PAY, STRIPE, PAYPAL, RAZORPAY, ADYEN, ETC.

Regional rules and entitlements can change the answer.

25. Official Apple reference links and high-authority legal sources

Core Apple policy

1. App Review Guidelines — especially 2.1, 2.3, 3.1.1-3.1.5, 4.2.7, 4.8, 4.9, 5.1.1.

2. In-App Purchase types — App Store Connect Help

3. StoreKit documentation

4. App Store business models

5. Auto-renewable subscriptions

6. View subscription data / proceeds rates

7. App Store Small Business Program

8. Apple Developer Program enrollment and fees

9. Reader apps / External Link Account Entitlement

10. External Purchase — StoreKit

11. Offering account deletion in your app

Regional payment/distribution programs

12. Changes for apps in the European Union

13. Communication and promotion of offers on the App Store in the EU

14. Store Services tiers in the EU

15. Music Streaming Services Entitlement — EEA

16. Changes to iOS in Japan

17. Payment options on the App Store in Japan

18. Changes to iOS in Brazil

19. Payment options on the App Store in Brazil

20. Third-party payment providers in South Korea

21. Dating apps in the Netherlands

22. StoreKit external purchases or offers entitlement

U.S. legal status

23. Epic Games, Inc. v. Apple Inc. — Ninth Circuit opinion, Dec. 11, 2025

24. U.S. Supreme Court docket 25-1311 — Apple Inc. v. Epic Games, Inc.

25. U.S. Supreme Court stay docket 26A194

External payment-cost reference used in economics example

26. Stripe pricing — used only for the illustrative external-processing comparison; actual merchant pricing varies.

26. Completeness audit

This guide has explicitly covered:

• Apple Developer Program membership vs commission vs payment processing vs PSP fees vs taxes;

• standard 30% / 15% models and subscription-after-one-year mechanics;

• Small Business Program threshold/associated-account logic;

• all four IAP types;

• Apple Pay vs IAP;

• Stripe, Razorpay, PayPal, Adyen, Braintree, Square, and card-payment classification;

• website purchase, login-only, external links, pricing text, CTAs, WebViews, QR codes;

• reader, companion/free stand-alone, multiplatform, enterprise/B2B, P2P, ad-management exceptions;

• physical goods/services, travel, transportation, healthcare, education, marketplace, donations, finance, crypto/NFT, remote desktop, VPN, SaaS, cloud, developer tools, AI;

• U.S., EU/EEA, Japan, Brazil, South Korea, Netherlands special rules;

• current EU pre-October terms and the October 1, 2026 announced transition;

• current U.S. court status and the fact that a proposed future fee is not yet the current approved fee;

• 60-scenario decision matrix;

• 10 architecture blueprints plus hybrid entitlement schema;

• subscription lifecycle, offers, grace, restore, Family Sharing;

• App Review rejection patterns and compliant alternatives;

• economic comparisons at $10K, $100K, $500K, $1M, and $5M;

• five founder architecture choices;

• 25 myths;

• 60 developer FAQs;

• submission checklist;

• SEO title, meta description, slug, hierarchy, featured snippets, and FAQ schema-ready question set.

Research stop condition: The material payment classifications are supported by current Apple primary documentation; fast-changing regional rules were checked against Apple’s current support pages; and the consequential U.S. link-out fee status was cross-checked against the Ninth Circuit opinion and current Supreme Court docket. Remaining uncertainty is explicitly identified where policy is pending future effective dates or active litigation.

Last verified: September 5, 2026

Apple’s policies, agreements, regional regulatory programs, and court-imposed U.S. rules can change. Before shipping a payment-flow change, re-check the applicable App Review Guidelines, developer agreement, regional support page, and entitlement terms for the exact storefront and app version.

Rajesh Kumar

I’m Rajesh Kumar, a DevOps, SRE, DevSecOps, Cloud, and Platform Engineering expert passionate about sharing practical knowledge, real-world experiences, and industry best practices. I have worked at Cotocus and regularly write about technology, travel, investing, health, product reviews, and digital marketing through my various platforms.

I publish technical articles at DevOps School, travel stories at Holiday Landmark, stock market insights at Stocks Mantra, health and fitness guidance at My Medic Plus, product reviews at TrueReviewNow, and SEO and digital marketing strategies at Wizbrand.

Find Trusted Cardiac Hospitals

Compare heart hospitals by city and services — all in one place.

Explore Hospitals

Find the Best Cosmetic Hospitals

Contents