How does Apple Pay work for online payments?
Apple Pay replaces the card number with a token. When a shopper adds a card to Apple Wallet, the card issuer or its service provider creates a device-specific Device Account Number, encrypts it and sends it to Apple. It is stored in the Secure Element on the device and never on Apple’s servers, and Apple says it does not store the original card numbers. This Device Account Number is a device token: it stands in for the card and is bound to that one device.
At checkout the shopper taps the Apple Pay button, checks the amount on the payment sheet and confirms the payment with Face ID, Touch ID, the passcode or a double-click on their Apple Watch. For payments in apps and on websites, Apple says neither Apple nor the device sends the actual card number. The app or website receives the Device Account Number together with a transaction-specific dynamic security code, which the card network and issuer use to check that the payment came from that device.
The payment data reaches the merchant’s provider encrypted. Every Apple Pay merchant ID has a payment processing certificate. Apple Pay servers encrypt the payment data with the certificate’s public key, and the merchant or its payment service provider uses the private key to decrypt it. The provider then sends an authorisation to the card network like any other card payment. The issuer approves or declines, and settlement, refunds and disputes follow the rules of the card behind the wallet. Stripe, for example, supports full and partial refunds on Apple Pay and handles disputes as it does for cards.
For repeat charges Apple offers merchant tokens, also called MPANs. Apple describes them as network tokens for recurring, deferred and automatic reload payments on the web and in apps. Unlike a Device Account Number, a merchant token is not tied to one device, so it keeps working when the shopper changes phone or the card is reissued. Apple notifies the merchant through its Merchant Token Management API when the shopper or the issuer revokes a token, or when card details such as the expiry date change. As of January 2026, Apple lists American Express, Discover, JCB, Mastercard and Visa as supporting merchant tokens, on iOS 16, iPadOS 16 and macOS 13 or later. Stripe recommends merchant tokens for merchant-initiated payments such as renewals.
Where and how do shoppers use Apple Pay?
Shoppers use Apple Pay on iPhone, iPad, Mac and Apple Watch, in Safari and in apps. On iOS 18 or iPadOS 18 or later it also works in compatible third-party browsers, which Apple says is available with participating merchants and not in all markets.
Apple’s list of countries and regions, published on 27 October 2026, includes the United States, Canada, the United Kingdom, Germany, France, Spain, Italy, the Netherlands, Poland, Kazakhstan, Brazil, Mexico, Saudi Arabia and the United Arab Emirates. It also covers the rest of the EU, Norway and Switzerland, the other Gulf states, Jordan, Egypt, Morocco and South Africa, most of Latin America, and Central Asia and the Caucasus. Turkey is not on it. The list shows where shoppers can add cards from participating banks and card issuers, so a listed country does not mean every bank in it supports Apple Pay. What counts is where the shopper’s card was issued, not where the shop is.
Local card schemes depend on the route. Checkout.com’s documentation says that a merchant processing mada cards through Apple Pay outside Saudi Arabia must enforce Visa or Mastercard, so a co-badged card runs on the international scheme.
In iOS apps, Apple Pay is for physical goods and services. Stripe notes that for digital products, content and subscriptions, an iOS app can take Apple Pay only in the United States and the EEA, and only by redirecting to an external payment page.
What rules and costs should merchants know?
Strong customer authentication is built in. Apple says Apple Pay includes built-in authentication, already meets SCA requirements and does not need additional authentication by banks. SCA has applied in the EEA since 31 December 2020 and in the UK since 14 March 2022. Apple sets two conditions. The country code in the payment request must be the country where the funds are processed, which ensures a PSD2-compliant cryptogram when the merchant and the card issuer are both in the EEA. And the payment sheet must show the final amount, not a pending one, because the amount and a merchant identifier are included in the cryptogram for dynamic linking. Checkout.com adds that Apple Pay payments benefit from liability shift, but a payment for which the issuer returns no Electronic Commerce Indicator (ECI) value is not eligible.
Card rules still apply. An Apple Pay payment is a card payment, so the card’s interchange and scheme fees apply. In the EU, Regulation (EU) 2015/751 caps interchange at 0.2% of the transaction value for consumer debit cards and 0.3% for consumer credit cards, and Member States may set lower caps for domestic credit card payments. The European Commission says PSD2 bans surcharging wherever those caps apply, for domestic and cross-border payments, which it estimated at about 95% of card payments in the EU. In the UK, regulation 6A of the Consumer Rights (Payment Surcharges) Regulations 2012 bars a payee from charging a fee for payment by consumer cards.
Web setup has its own steps. Apple Pay on the web needs an Apple Developer account, a merchant ID, a payment processing certificate, a merchant identity certificate that authenticates sessions with Apple Pay servers, and verified domains. Every top-level domain and subdomain that shows the button must be registered and verified. Domains cannot sit behind a proxy or redirect, and one domain cannot be registered under two different Apple Developer teams. The certificates and the domain verification expire and must be renewed. Use is subject to Apple’s acceptable use guidelines. Stripe says Apple Pay works with no extra setup on its hosted checkout, handles Apple merchant validation itself and needs merchants to register every domain, including www, for embedded forms.
How would Omno handle Apple Pay?
- One checkout: Apple Pay would appear in the Omno hosted checkout next to cards, Google Pay, local methods and crypto, on devices where it is available. Merchants with their own payment screens would use Direct Links on their own buttons.
- Routing rules: The merchant would set rules by country, currency or amount that send Apple Pay payments to a connected provider that supports Apple Pay and holds the decryption keys. Omno connects through those providers; it is not an acquirer and does not hold funds.
- Cascading: In the hosted checkout, if the chosen provider is unavailable or rejects the request, the payment would move to the next provider in the rule until one accepts. Because the Apple Pay payload is encrypted for the holder of the processing key, the providers in an Apple Pay rule need to be ones that can process it.
- Status: The final result would reach the merchant by webhook.
What should merchants plan for?
Keep a card form and local methods next to the button. Shoppers on other devices, or with cards from banks that do not support Apple Pay, will not see it, and Turkey is not on Apple’s list at all.
Track expiry dates. The payment processing certificate, the merchant identity certificate and the domain verification all expire, and a lapsed one stops the button working. Register every subdomain that shows the button.
Match the country code to the route. In the EEA and the UK, the country code decides whether the cryptogram meets PSD2, so it should follow the country where the acquirer processes the payment.
Use merchant tokens for subscriptions. They survive a new phone or a reissued card, and the merchant needs a web service to receive Apple’s token lifecycle notifications.
Expect card disputes. Authentication lowers fraud, but shoppers can still dispute an Apple Pay payment through their card issuer, and the merchant answers with evidence as for any card chargeback.