Using alternative payment options on the App Store in the European Union

To reflect the DMA’s changes, developers will have new options for digital goods and services transactions in their apps distributed on the App Store in the EU across iOS, iPadOS, macOS, tvOS, and watchOS. This includes the ability to use alternative payment service providers for in‑app purchases and linking out to their webpage to complete transactions.


What’s new

Developers can get started with these options in the beta release of Xcode 15.3 and iOS 17.4 starting today. The changes will become available to users in the 27 EU member states starting in March 2024.

To use these new payment options in an app, developers will need to agree to the Alternative Terms Addendum for Apps Distributed in the EU on all of their developer accounts, then use the StoreKit External Purchase Entitlement, the StoreKit External Purchase Link Entitlement, or both. Developers aren’t required to submit a separate binary to use alternative payment processing. Those who choose to use these new payment options (either using an alternative payment service provider or linking out to their webpage) can’t use the App Store In‑App Purchase system on the same EU storefronts and platforms as the new payment options.

  • Continue using the App Store In‑App Purchase system with the worldwide, commission model in the EU. If you want to choose this option, no action is required.
  • Adopt new payment processing options for apps distributed in the EU with new business terms.
    • App Store payment processing and related commerce services: Use the In‑App Purchase system from the App Store to complete user transactions for digital goods and services within your app.
    • Payment Service Providers (PSP): Use an alternative payment processor that lets users complete transactions within your app.
    • Linking out to purchase: Direct users to complete a transaction for digital goods and services on your external webpage. The presentation of the link out may communicate information for EU users about promotions, discounts, and other deals.

Adopting new payment options and terms

To get started with new payment processing options, the Account Holder of your Apple Developer Program membership needs to agree to the Alternative Terms Addendum for Apps in the EU for apps distributed in the European Union for all of their developer accounts. The agreement includes new business terms for apps distributed in the EU, which have three primary elements:

  • Reduced commission. For iOS apps on the App Store, you’ll pay a reduced commission of either 10% (for the vast majority of developers and for subscriptions after their first year) or 17% on transactions for digital goods and services, regardless of the payment processing system selected.
  • Payment processing fee. Apps on the App Store can use App Store payment processing for an additional 3% fee. You can use an alternative PSP within your app or link users to your external webpage to process payments with no additional fee from Apple.
  • Core Technology Fee (CTF). For iOS apps distributed on the App Store and/or an alternative app marketplace that reach significant scale, you’ll pay €0.50 for each first annual install over 1 million first annual installs.

To help you understand the potential impact of the new business terms, view our Fee Calculator.


Using alternative payment processing

If you agree to the Alternative Terms Addendum for Apps in the EU, your developer account will be assigned the StoreKit External Purchase Entitlement (for completing transactions within your app with an alternative PSP) and the StoreKit External Purchase Link Entitlement (for directing users to your webpage outside of your app to complete a transaction). These entitlements are enabled in Xcode and let your app use alternative payment processing. In addition to the entitlement, you’ll need to use required StoreKit External Purchase APIs, report external purchase transactions using the new External Purchase Server API, and follow usage requirements and templates designed to help protect people’s privacy and security, prevent scams and fraudulent activity, and support the user experience.

Important considerations

Using alternative PSPs and/or linking out can create new threats to user security and privacy, and may compromise the user experience. Developers considering use of alternative PSPs and/or link out should understand that some OS or App Store features may not work as users expect. Helpful App Store features — like Report a Problem, Family Sharing, and Ask to Buy — will also not reflect these transactions. Users may have to share their payment information with additional parties, creating more opportunities for bad actors to steal sensitive financial information. And on the App Store, users’ purchase history and subscription management will only reflect transactions made using the App Store In‑App Purchase system. Apple will have less ability to support or refund customers encountering issues, scams, or fraud.

If you use alternative payment processors and/or link out to complete a transaction for digital goods and services on your external webpage, you’re also responsible for managing payment or billing issues, taxes, and other features currently supported by the App Store system. In addition, you’re responsible for complying with all applicable laws and regulations related to payment processing, cancellation of transactions, refunds, privacy, etc.

User disclosures

To help users understand whether an app uses alternative PSPs or external purchase links, the App Store will display an informational banner on the app’s product page. Users will also be informed if an app contains either of these options on the purchase confirmation sheet when downloading an app. Apps that include these options must use StoreKit External Purchase APIs to present users with the system-provided disclosure sheet for each transaction, which explains that purchases are made through a source other than Apple.

Storefront options

You can define which EU markets will use alternative payment processors and which ones will use the App Store In‑App Purchase system. Due to the App Store’s tight integration with In‑App Purchase and to reduce confusion for users, you won’t be able to offer both In‑App Purchase and alternative PSPs and/or link out in your app on the same App Store storefront and platform. If you want to continue using the App Store In‑App Purchase system, you may do so and no action is needed.


Requirements when using an alternative PSP within your app

In addition to enabling the StoreKit External Purchase Entitlement, you’ll need to use required StoreKit External Purchase APIs and follow usage requirements designed to help protect people’s privacy and security, prevent scams and fraudulent activity, and maintain the overall quality of the user experience.

  • Alternative PSPs cannot be used on the same EU storefront and platform where the app uses the App Store In‑App Purchase system.
  • The in‑app payment flow you implement must:
    • Provide a native experience within the app. It may not be within a web view.
    • Not contain any hidden, dormant, or undocumented payment functionality or behavior.
  • If your app engages in misleading marketing practices, such as bait and switch, scams, or fraud, it will be removed from the App Store and you may be removed from the Apple Developer Program.
In-app system disclosure sheet

When using an alternative payment processor within your app, it will display a system disclosure sheet to customers explaining that purchases are made through a source other than Apple. For iOS 17.4, iPadOS 17.4, macOS 14.4, tvOS 17.4, and watchOS 14.4, this is implemented by using the StoreKit External Purchase API.

This sheet is displayed before:

  • Each payment flow where the user would make a purchase.
  • Each flow to enter payment information, even if not for a specific purchase.

Requirements for linking out to your webpage to complete a transaction for digital goods and services

In addition to using the StoreKit External Purchase Link Entitlement and required StoreKit APIs, you’ll need to follow usage requirements designed to help protect people’s privacy and security, prevent scams and fraudulent activity, and maintain the overall quality of the user experience.

The link you provide in your app must:

  • Go directly to your webpage without any redirect or intermediate links or landing page;
  • Open a new window in the default browser on the device, and may not open a web view;
  • Not pass additional parameters in the URL in order to protect the user (for example, their privacy);
  • Be statically-defined in the SKExternalPurchaseLink in your app’s Info.plist file before submission to the App Store;
  • Be submitted with your app to the App Store and resubmitted if the URL changes;
  • Be accompanied by language and a button adhering to the requirements provided in the Apple materials; and
  • Comply with any additional requirements provided in the Apple materials.

Your App Store product page may not include information about purchasing on your webpage, or link to your webpage for purchasing.

Digital goods and services sold on your webpage after link out that are marketed as being for use in an app must be available for use in that app.

If your app engages in misleading marketing practices, such as bait and switch, scams, or fraud, it will be removed from the App Store and you may be removed from the Apple Developer Program.

Design and language guidelines

Sign in screen

Account screen

App page

Templates

Use the templates that best fits your use case. Aside from the price, percentage off, and your website URL, the language used in your app must match the template language. Don’t modify or use the template in a manner that misleads customers.

Purchase template:

Purchase from the website at www.example.com Link-out iconLink-out icon

Special offer template:

For special offers, go to www.example.com Link-out iconLink-out icon

For a special offer, go to www.example.com Link-out iconLink-out icon

Lower price template:

Lower prices offered on www.example.com Link-out iconLink-out icon

Lower price offered on www.example.com Link-out iconLink-out icon

Percent off template:

To get XX% off, go to www.example.com Link-out iconLink-out icon

Specific price template:

Buy for $X.XX at www.example.com Link-out iconLink-out icon

Style and icon

Your link must follow the Plain Button style, as specified in the Human Interface Guidelines. It may not be enclosed in a shape that uses a contrasting background fill. The background surrounding the text must match the background of your app’s page. The link out icon provided by Apple must be displayed directly to the right of your website URL. The icon size must visually match the size of the .text

www.example.com Link-out iconLink-out icon

In-app system disclosure sheet

When linking out to your webpage from within your app, Apple will display a system disclosure sheet to customers that explains to the user each time that they’ll be leaving the app and going to an external webpage through a source other than Apple. When a user taps the Continue button, they’ll be directed to your webpage within the device’s default web browser. For iOS 17.4, iPadOS 17.4, macOS 14.4, tvOS 17.4, and watchOS 14.4, this is implemented by using the ExternalPurchaseLink API.


Entitlements and implementation

You can choose to continue using the App Store In‑App Purchase system or use alternative payment options per EU storefront, which can be updated by changing the entitlement election in Xcode by updating the plist with a new app submission.

Configuring and enabling the entitlement in Xcode

Once the entitlements are assigned to your account and you’ve configured the App ID in Certificates, Identifiers & Profiles to support this entitlement, you’ll need to update your Xcode project, entitlements plist file, and Info.plist file to list the entitlement and metadata.

The Entitlement Profile is compatible with and may only be used in apps on EU storefronts on devices running iOS 17.4, iPadOS 17.4, macOS 14.4, tvOS 17.4, and watchOS 10.4.

Screenshot of the entitlement being enabled in Xcode Screenshot of the entitlement being enabled in Xcode
  1. In the Project Navigator, select the .entitlements file. The filename is prefixed with an [•] icon.
  2. In the entitlements property list file, add a new entitlement key pair by holding the pointer over the Entitlements File row and clicking the add button (+).
  3. Provide the following values for the entitlements::
    1. Key: com.apple.developer.storekit.external-purchase-link for link-outs. com.apple.developer.storekit.external-purchase for alternative payment service providers.
    2. Type: Boolean
    3. Value: True
  4. Provide the required metadata in your Info.plist file: SKExternalPurchase for payment service providers, and SKExternalPurchaseLink for linking out.

On the next build to your device or distribution request in Xcode Organizer, Xcode will detect that the .entitlements file and cached provisioning profile don’t match, and will request a new provisioning profile based on the latest App ID configuration to complete the code signing process.

Updating your Info.plist file

Each entitlement has unique requirements for the data that must be entered into your app’s Info.plist file. For general information on managing your app’s Info.plist file, see Managing Your App’s Information Property List.

SKExternalPurchaseLink
  1. Select the Info.plist file from the Project Navigator in your OS target.
  2. Provide the following values for this property list key:
    1. Key: SKExternalPurchaseLink
    2. Type: Dictionary with string values
      1. Key: A single ISO 3166-1 alpha-2 country code value for a country in the European Union.
      2. Value: A single destination URL

Include a key entry in the dictionary for each EU country code where your app supports linking out. At all times, the destination URLs (i.e., the links to your webpage) that you provide in the Info.plist file in Xcode must match the values in the app binary you submitted to App Review. Make sure that each value is a string that:

  • Uses the HTTPS scheme;
  • Forms a valid, absolute URL;
  • Contains no query parameters; and
  • Contains 1,000 or fewer ASCII characters.
SKExternalPurchase
  1. Select the Info.plist file from the Project Navigator in your OS target.
  2. Provide the following values for this entitlement:
    1. Key: SKExternalPurchase
    2. Type: Array with string values
      1. Values: One or more ISO 3166-1 alpha-2 country code values for the European Union countries.
European Union country codes

The valid EU country codes are: Austria (at), Belgium (be), Bulgaria (bg), Croatia (hr), Cyprus (cy), Czechia (cz), Denmark (dk), Estonia (ee), Finland (fi), France (fr), Germany (de), Greece (gr), Hungary (hu), Ireland (ie), Italy (it), Latvia (lv), Lithuania (lt), Luxembourg (lu), Malta (mt), Netherlands (nl), Poland (pl), Portugal (pt), Romania (ro), Slovakia (sk), Slovenia (si), Spain (es), Sweden (se)

At all times, the country codes that you provide in the Info.plist file in Xcode must match the values in the app version you submitted to App Review.

Implementing required StoreKit External Purchase APIs for linking out

If your account receives the com.apple.developer.storekit.external-purchase-link entitlement, implement the following to offer an external purchase link:

  • Configure the com.apple.developer.storekit.external-purchase-link entitlement for your app.
  • Configure the SKExternalPurchaseLink property list key.
  • Use the ExternalPurchaseLink typeʼs canOpen property and open() method.
  • StoreKit appends the external purchase token to your webpage’s URL. Use the token to record purchases.
  • From your server, report your customerʼs purchases associated with the tokens by using the External Purchase Server API.
Implementing required External Purchase APIs for alternative payment processors

If your account receives the com.apple.developer.storekit.external-purchase entitlement, implement the following to use alternative payment processors within your app:

  • Configure the com.apple.developer.storekit.external-purchase entitlement for your app.
  • Configure the SKExternalPurchase property list key.
  • Use the ExternalPurchase typeʼs canPresent property to determine whether external purchase is available.
  • Call the presentNoticeSheet() method and use the external purchase token you receive from the ExternalPurchase.NoticeResult.continuedWithExternalPurchaseToken(token:) result to record purchases.
  • From your server, report your customerʼs purchases associated with the tokens by using the External Purchase Server API.

Submitting your app for review in App Store Connect

When submitting your new app binary for review in App Store Connect, make sure to follow these submission requirements as well as the Alternative Terms Addendum for Apps Distributed in the European Union, the App Store Review Guidelines, and the Apple Developer Program License Agreement.

  • Your app and in‑app disclosure sheet for your external payment flow is properly implemented and tested.
  • If linking out, the link is only displayed to users on EU storefronts and the webpage your app links to for purchases and support is fully functional.
  • Screenshots of your app’s UI where you show the link are included with your submission.
  • The name of your payment service provider (PSP) is included in the review notes. Make sure the PSP is ready to complete transactions from your app. Your PSP must:
    • Meet Level 1 Payment Card Industry (PCI) compliance for handling credit and debit card data; and
    • Make a customer service process available for users, including a process to dispute unauthorized transactions, manage subscriptions (if applicable), and request refunds.

If your submission is incomplete, review times may be delayed or your app may be rejected. Once your app has been reviewed, its status will update in App Store Connect and you’ll be notified.


Commission, transaction reports, and payments

If you support either alternative payment processing or link out to your webpage, you’re responsible for paying a commission to Apple on the sale of digital goods and services in the EU. iOS apps on the App Store will pay a reduced commission of either 10% (for developers participating in the App Store Small Business Program and for subscriptions after their first year) or 17% on transactions for digital goods and services, regardless of payment processing system selected; while for iPadOS, macOS, tvOS, and watchOS you’ll get a 3% discount on the commission you owe to Apple.

For linking out, the commission applies to sales of digital goods or services that are initiated within seven calendar days after the user taps “Continue” on the in‑app notice sheet. This includes any adjustments for refunds, reversals and chargebacks.

For auto-renewable subscriptions, a transaction is classified as, (i) a sale initiated, including with a free trial or offer, within seven calendar days after a link out; and (ii) each subsequent renewal after the subscription is initiated. For both linking out and in‑app transactions using an alternative payment service provider, subsequent subscriptions renewals will be included for commission until the customer cancels their subscription, performs a new purchase outside of the seven day window without using the link within the app, or until you inactivate their subscription due to payment issues. Renewals will continue on the payment processor where the subscription was initiated.

If you participate in the App Store Small Business Program and for subscriptions after their first year, the commission will be 10% for iOS and 12% for all other Apple platforms.

These commission rates apply to all prices payable by each user minus any transaction taxes charged by the app. You are responsible for the collection and remittance of any applicable taxes for sales processed by an alternative payment provider.

Transaction reporting

If your app adopts either of these entitlements, you’re required to use the External Purchase Server API to report transactions to Apple for commission calculation and collection purposes. This includes refunds, adjustments, renewals, one-time purchases, and transactions which didn’t result in a purchase.

Each ExternalPurchase and ExternalPurchaseLink API call will generate a unique, external purchase token from Apple. Apple expects you to return this transaction data for each token issued, regardless of whether a transaction has completed. Tokens for which transaction data aren’t returned after a period of three weeks will be flagged and you’ll receive an App Store server notification reminding you to complete your transaction reporting. Learn about technical implementation details.

Payments

You’ll receive a monthly invoice based on the reporting for commissionable transactions for digital goods and services for which commission is owed. Transactions will be aggregated and commissions calculated by Apple by the 15th of the following month. You’ll need to provide payment within 30 days of receiving the invoice.

Please note that Apple has audit rights pursuant to the Alternative Terms Addendum for Apps in the EU. This will allow Apple to review the accuracy of your record of digital transactions as a result of the entitlement, ensuring the appropriate commission has been paid to Apple. Late payments will accrue interest. Late payments accrue interest and nonpayment may result in the offset of App Store In‑App Purchase proceeds owed to you, removal of the app from the App Store, or removal from the Apple Developer Program.


Supporting customers

If your app adopts either of these entitlements, it’s your responsibility to provide timely support to customers if questions or issues arise. Apple won’t be able to assist customers with refunds, purchase history, subscription management, and other issues encountered when purchasing digital goods and services. You’ll be responsible for addressing these issues with customers directly.


Frequently Asked Questions

Can I support alternative payment service providers for a single EU country only, and use the App Store In‑App Purchases system for the rest of Europe and the world?

Yes. You may choose which EU storefronts use alternative PSP, link out, and the App Store In‑App Purchase system. For more information, see SKExternalPurchase. Due to the App Store’s tight integration with In‑App Purchase, and to reduce confusion for users, you may not offer both In‑App Purchase and alternative PSPs to users in your app on the same App Store storefront.

If a customer purchases a subscription using the App Store In‑App Purchase system, and the next version of the app uses an alternative payment processor, how is the customer billed for subscription renewals?

Subscriptions will continue to renew on the payment processing system used when the subscription started. In this example, the customer’s subscription would continue to use the App Store In‑App Purchase system until the subscription becomes inactive or the customer makes a new selection. You shouldn’t merchandize the same subscription to a user who already subscribed on the App Store In‑App Purchase system, as they’ll be double charged for the same service.

If I start using an alternative payment processor instead of the App Store In‑App Purchase system, will my users be charged twice for their subscriptions or in‑app purchases?

Subscriptions will continue to renew on the payment system where the subscription originated. When customers update their app to the version that supports alternative payment service providers or link out, one-time purchases from that point forward occur on alternative payment processors and not on the App Store In‑App Purchase system.

A customer launches my app, but then accesses my webpage on their own after ten days, and makes a purchase for my app. Do I owe commission to Apple?

In this example, no. Only when a customer goes to the your webpage after the app calls presentNoticeSheet() and the customer continues to your webpage would commission apply, as long as the customer completes a purchase within seven calendar days from the token issue date.

Can customers still use the App Store In‑App Purchase system if they’re running earlier OS versions or haven’t updated my app to the latest version that supports alternative payment options?

Anyone running an OS version earlier than iOS 17.4 or an earlier version of your app that doesn’t support alternative payment options (either linking out to the developers webpage or using an alternative payment service provider) can keep using the App Store In‑App Purchase system at the discounted commission rate, plus the payment processing fee. Once a customer updates to iOS 17.4 and the latest app version, they can take advantage of the new payment options. Please note that apps can’t use the App Store In‑App Purchase system and alternative payment options in the same storefront and OS (including the same OS version and app version) at the same time.

When can I start implementing these options for my app?

As soon as the Alternative Terms Addendum for Apps Distributed in the European Union is signed, you can add the entitlements to your app in Xcode and start testing locally. In late February, the External Purchase Server API will be available for testing transactions from your server. In March, the new APIs will be available for production transactions for customers in the EU.