Apple EU App Store Fees 2026: IAP vs Alternative Payments vs Web Distribution

Apple's EU app business terms change materially on October 1, 2026, but choosing an alternative payment method is not simply a matter of replacing a 26% App Store commission with a smaller percentage.

Under Apple's updated terms, EU App Store apps can combine Apple In-App Purchase with alternative in-app payment processing and out-of-app offers. Apple has also replaced the old per-install Core Technology Fee with a 5% Core Technology Commission on qualifying digital transactions in apps distributed outside the App Store.

The commercial decision now has four layers: Apple's commission, payment/tax responsibility, customer support and refunds, and engineering/reporting complexity.

The right question is not "Which option has the lowest Apple percentage?" It is "Which payment and distribution model has the lowest total operational cost for our product?"

What changes on October 1, 2026?

Apple updated its Developer Program License Agreement on August 18, 2026 with unified business terms for developers distributing apps in the European Union.

Apple says the new terms take effect on October 1, 2026 and replace the previous Alternative Terms Addendum for Apps in the EU and the StoreKit External Purchase Link Entitlement Addendum for EU apps.

The main changes include:

• adjusted commission rates for Apple In-App Purchase and alternative payment options
• ability to offer alternative payments alongside Apple IAP
• child-safety requirements for apps using alternative payment options
• a requirement to maintain the selected combination of payment options across EU storefronts for 12 months
• replacement of the per-install Core Technology Fee with a 5% Core Technology Commission for digital transactions in apps distributed outside the App Store
• elimination of the old Initial Acquisition Fee and Store Services Fee
• expanded eligibility for Web Distribution and alternative app marketplaces

The four models to compare

Reduced rates apply only to Apple's eligible categories, including specified developer programmes and qualifying subscriptions after their first year.

These percentages are not interchangeable discounts. Each option changes who operates the surrounding commerce system.

Apple In-App Purchase: higher commission, smaller operating burden

Apple's updated EU terms list:

• 26% standard App Store commission for Apple IAP
• 15% for eligible reduced-rate transactions

Apple describes IAP as providing payment processing, foreign-currency handling, tax support, customer service and subscription commerce.

A typical architecture stays compact:

iOS / Flutter app
      ↓
StoreKit / Apple IAP
      ↓
Apple commerce
      ↓
App Store Server API / notifications
      ↓
Your entitlement service

The app still needs reliable entitlement handling, especially for subscriptions, but the business does not need to operate the full payment, tax and refund stack.

For a small team, that operational value can outweigh the difference in headline commission.

Alternative in-app payment: 20% or 10% is not the total cost

Apple's current EU terms list:

• 20% commission for alternative payment processing within an App Store app
• 10% for eligible reduced-rate transactions

Apple is no longer the payment processor.

The developer becomes responsible for billing, refunds, purchase history, subscription management, customer support and applicable taxes.

So the actual cost becomes:

Apple commission
+
payment processor
+
VAT/tax operations
+
refunds and disputes
+
subscription infrastructure
+
engineering
+
customer support
+
Apple reporting

This is the correct comparison against IAP.

Not simply:

26% vs 20%

Alternative payment still carries an Apple commission under the current EU App Store terms.

Out-of-app offers: lower headline rate, attribution complexity

EU App Store apps can also direct users to offers outside the app, including a website, another app or an alternative marketplace.

For an actionable link, Apple's current Store Services commission is:

• 15% standard
• 10% for eligible reduced-rate transactions

Apple says relevant sales made within seven days after the user taps the link are subject to that commission.

That creates a reporting path:

User taps external offer
        ↓
Apple reporting token/context
        ↓
Website or other destination
        ↓
Purchase
        ↓
Your backend maps transaction to token
        ↓
Transaction reported to Apple

This is more than opening a checkout URL.

Monthly Apple reporting becomes part of the backend

Apple says applicable alternative-payment and alternative-distribution transactions must be reported monthly within 15 days after the end of the calendar month.

Reporting includes:

• completed purchases
• refunds
• corrections
• renewals
• one-time purchases
• tokens that did not result in a purchase

Apple's External Purchase Server API is part of that workflow.

A robust design therefore needs a durable ledger:

Apple external-purchase token
        ↓
Commerce intent
        ↓
Payment attempt
        ↓
Processor event
        ↓
Entitlement event
        ↓
Refund/correction
        ↓
Apple reporting status

Payment state, entitlement state and Apple-reporting state should not be one boolean.

Alternative distribution: the old per-install CTF is being replaced

Apple's August 18 announcement says the previous Core Technology Fee, which was based on installs under the older alternative EU terms, will be replaced by a 5% Core Technology Commission on qualifying digital transactions in apps distributed outside the App Store.

This covers relevant alternative-distribution models such as Web Distribution and alternative app marketplaces.

The unit of economics changes from:

install volume
→ possible per-install fee

to:

qualifying digital transaction
→ 5% commission

That can materially change the business case for apps with high installs but low digital transaction volume.

Do not reuse an old Core Technology Fee spreadsheet for an October 2026 decision.

Does Web Distribution now make sense for every developer?

No.

A 5% Apple commission can look attractive beside App Store rates, but alternative distribution shifts more responsibility to the developer:

• acquisition without normal App Store discovery
• installation trust and friction
• notarisation/signing
• updates
• payment processing
• taxes
• customer support
• transaction reporting
• account recovery
• entitlement infrastructure

The App Store is not only a payment processor. It is also a distribution, trust, discovery and update channel.

A lower Apple percentage can still produce a more expensive operating model.

Use a total-cost model, not a commission comparison

For each option, calculate:

Total commerce cost
=
Apple commission
+
payment processing
+
tax/compliance operations
+
refunds/chargebacks
+
fraud
+
customer support
+
subscription operations
+
engineering/maintenance
+
reporting/reconciliation
+
distribution/conversion effects

Then compare:

Net contribution
=
Revenue
-
Total commerce cost

Simple headline-rate illustration

Suppose an app has €100,000 of qualifying digital revenue.

Before adding processor, tax, support or engineering costs:

These figures are not total cost.

For alternative models, add the commerce functions Apple is no longer operating for you.

Small Business Program economics are different

For eligible reduced-rate transactions, Apple's current rates narrow the gap:

• Apple IAP: 15%
• alternative in-app payment: 10%
• actionable out-of-app offer: 10%

A small developer may therefore be comparing:

15% Apple IAP

against:

10% Apple commission
+
processor
+
tax
+
support
+
reporting

Five percentage points may or may not justify another commerce stack.

A mature SaaS business that already runs web billing is in a very different position from a small mobile-only startup.

The 12-month commitment changes experimentation

Apple says developers must maintain their selected payment option or combination across EU storefronts for 12 months.

Before changing the model, test the business case on paper and in sandbox environments.

Model:

• pricing
• conversion
• processor costs
• tax
• customer support
• cancellation
• refunds
• subscription migration
• reporting
• failure recovery

This is not a weekly A/B switch.

Refunds become a distributed workflow

With alternative payment, a robust refund flow can look like:

Customer requests refund
        ↓
Support/admin system
        ↓
Payment provider refund
        ↓
Entitlement update
        ↓
Transaction ledger
        ↓
Apple reporting correction

A failure at any layer can create inconsistent access or reporting.

The backend should make refunds idempotent and traceable.

Use one entitlement service for multiple payment sources

If an app offers both Apple IAP and alternative payments, subscription state can fragment:

User A → Apple subscription
User B → web subscription
User C → alternative in-app processor

Do not let the mobile UI become the reconciliation engine.

Prefer:

Apple StoreKit events
        ↓
Alternative payment webhooks
        ↓
Web subscription events
        ↓
Entitlement service
        ↓
PREMIUM_ACTIVE / EXPIRED / GRACE
        ↓
iOS / web / backend

Keep the payment source attached for billing operations while exposing one coherent access state to the product.

Flutter architecture for multiple EU payment paths

A Flutter app should keep commercial rules above the payment implementation:

Flutter UI
    ↓
PurchaseService
    ↓
AvailablePurchaseOptions
    ↓
├── AppleIAPAdapter
├── AlternativePaymentAdapter
└── OutOfAppOfferAdapter
    ↓
Backend entitlement service

The app should ask:

Which payment options are allowed and appropriate for this user/storefront?

rather than simply:

if (Platform.isIOS) {
  // Apple purchase
}

The answer can depend on:

• EU storefront
• selected business terms
• app version
• existing subscription source
• product type
• Apple policy configuration

Do not infer EU eligibility from GPS

App Store commercial eligibility is not the same as physical device location.

A user can travel.

Use Apple's documented storefront/account mechanisms and APIs, not GPS, to drive App Store payment-policy decisions.

Taxes become the developer's responsibility with alternative payment

Apple's current tax guidance says developers using alternative payment options are responsible for determining, collecting, reporting and remitting applicable taxes.

The implementation therefore needs finance involvement.

Before launch, document:

• merchant/legal entity
• VAT treatment
• invoices/receipts
• refunds
• currencies
• accounting reconciliation
• Apple commission reporting
• relevant tax IDs

A checkout can technically succeed while the finance operation behind it is incomplete.

Child-safety requirements are part of the new model

Apple's August 2026 terms add child-safety requirements for apps using alternative payment options on the EU App Store.

Apps used by children or teenagers should review Apple's current requirements before enabling alternative commerce.

This is another reason payment eligibility should live in a policy layer rather than a universal checkout button.

When Apple IAP is probably the better choice

Start with IAP when:

• the app has a small operations team
• there is no mature web commerce stack
• tax/refund/subscription operations are lean
• App Store trust and conversion matter
• payment infrastructure is not product differentiation
• the reduced 15% rate already applies
• operational simplicity is more valuable than maximum payment control

There is no prize for owning extra payment infrastructure.

When alternative in-app payment becomes attractive

Evaluate it when:

• the business already operates mature web billing
• users need one subscription across web and mobile
• payment/tax/refund systems already exist
• the team can implement Apple reporting reliably
• the net saving remains positive after all operating costs
• payment control has strategic value

For a mature SaaS company, this can be an extension of existing infrastructure rather than a new platform.

When out-of-app offers may fit

Evaluate actionable out-of-app offers when:

• the business already has a strong web checkout
• users recognise the brand/account outside the app
• seven-day attribution/reporting is acceptable
• conversion loss from leaving the app is measured
• the business can reconcile the external-purchase reporting flow

Measure completed revenue, not link clicks.

When alternative distribution may fit

Web Distribution or alternative marketplaces can make more sense when:

• the business owns its acquisition channel
• App Store discovery is not essential
• users can tolerate alternative installation
• web commerce already exists
• distribution control matters strategically
• the 5% transaction-based commission plus total operating cost is attractive

For mainstream consumer apps, the App Store's distribution value can still dominate.

Decision matrix

Engineering checklist before switching

Commercial

• Confirm applicable Apple rate.
• Confirm reduced-rate eligibility.
• Model the 12-month option commitment.
• Define which transactions are reportable.

Payment

• Processor integration
• subscription renewals
• failed payments
• refunds
• chargebacks
• idempotency

Entitlements

• one backend source of truth
• Apple events ingested
• alternative-payment webhooks ingested
• refunds revoke/update access correctly
• cross-platform access tested

Apple reporting

• external-purchase tokens stored
• completed and non-purchase outcomes reportable
• refunds/corrections supported
• monthly 15-day deadline operationalised
• retries and reconciliation monitored

Tax/accounting

• tax/VAT owner identified
• receipts/invoices defined
• tax IDs configured where needed
• Apple commission invoices reconciled

Support

• refund channel
• purchase history
• subscription cancellation
• failed-payment support

Product

• storefront logic
• payment-option policy
• child-safety requirements
• provider outage fallback
• conversion measurement

What not to do

Do not compare 26% against a processor fee alone

Alternative in-app processing still carries Apple's commission.

Do not call the 5% Core Technology Commission a 5% App Store fee

It applies to qualifying digital transactions in apps distributed outside the App Store.

Do not reuse old Core Technology Fee calculations

The per-install fee model is being replaced under the new unified terms.

Do not make the app your entitlement database

Centralise subscription/access state when more than one payment source exists.

Do not use payment-provider exports as your only Apple reporting system

Keep a durable internal transaction ledger.

Do not switch because the headline percentage is lower

Compare total cost, conversion and operational burden.

A safe migration sequence

Phase 1: model

Calculate economics using real processor contracts, revenue mix, support costs and tax requirements.

Phase 2: architecture

Define payment adapters, entitlement service, transaction ledger, Apple reporting, refund flow and accounting.

Phase 3: test

Test successful purchase, cancellation, decline, duplicate/delayed webhook, renewal, refund, correction, expiry, device change and existing subscriptions.

Phase 4: operational readiness

Finance and support need runbooks before release.

Phase 5: launch and measure

Track checkout conversion, net revenue, support tickets, refunds, payment failures, reporting errors and entitlement mismatches.

The lowest commission is irrelevant if the new checkout loses more revenue than it saves.

FAQs

What are Apple's EU App Store commission rates from October 1, 2026?

Apple's current terms list 26% standard for Apple IAP, 20% for alternative payment processing inside an App Store app, and 15% for qualifying actionable out-of-app offers. Reduced rates of 15%, 10% and 10% respectively apply to eligible transaction categories.

Can an EU App Store app offer Apple IAP and another payment method together?

Yes. Apple's August 2026 update allows alternative payment methods and offers alongside Apple IAP in EU storefronts, subject to the current terms and policies.

Does using Stripe or another processor remove Apple's commission?

No. Alternative in-app payment processing under the EU App Store terms still carries Apple's applicable commission. The developer also operates its own payment, tax, support and reporting stack.

What replaces the Core Technology Fee?

From October 1, 2026 under the new unified EU terms, Apple says the per-install Core Technology Fee is replaced by a 5% Core Technology Commission on qualifying digital transactions in apps distributed outside the App Store.

How often must alternative transactions be reported?

Apple says applicable transactions must be reported monthly within 15 days after the end of the calendar month, including refunds, corrections, renewals and tokens that did not result in a purchase.

Is alternative payment always cheaper than Apple IAP?

No. Its Apple commission is lower, but the developer takes on processor cost, tax, refunds, subscription operations, customer support, reporting and additional engineering. Compare total cost and conversion.

Conclusion

Apple's October 2026 EU changes create more choice, but they turn payment architecture into a more explicit business decision.

The headline models are:

Apple IAP
→ 26% / 15%

Alternative in-app payment
→ 20% / 10%
+ own commerce operations

Actionable out-of-app offer
→ 15% / 10%
+ attribution/reporting

Alternative distribution
→ 5% Core Technology Commission
+ own distribution and commerce

Those percentages are only the first line of the spreadsheet.

The real decision also includes payment processing, tax, refunds, subscriptions, support, engineering, Apple reporting, conversion and distribution value.

For a small app, Apple IAP may remain the cheapest system to operate even at a higher commission.

For a mature SaaS business with strong web commerce, alternative payments can fit naturally into an existing billing platform.

For direct-distribution products, the new 5% transaction-based Core Technology Commission materially changes the economics compared with the old per-install Core Technology Fee.

The strongest architecture keeps payment sources modular while entitlements, reporting and customer access remain centralised.

Need to evaluate or implement a multi-payment iOS/Flutter architecture for the EU? Softotic's mobile app development service can handle the app and StoreKit layer, while custom software development can build the entitlement, payment, reporting and reconciliation backend.

Sources and references

• Apple Developer: Payment options on the App Store in the EU
• Apple Developer: Changes for apps in the European Union — August 18, 2026
• Apple Developer: Getting started with Web Distribution in the EU
• App Store Connect: Reporting tokens and transactions to Apple
• Apple Developer: Reporting transactions for the Core Technology Commission
• App Store Connect: Understanding taxes