Apple Pay for International Merchants

v2 Apple Pay for International Merchants: Acceptance, Integration, and Market Fit A customer reaches checkout on an iPhone. They never type a card number. They tap Apple Pay, review the payment sheet, confirm with Face ID, Touch ID, or their device passcode, and the merchant receives a payment result. From the customer's perspective, the card form almost disappeared. From the payment system's perspective, much less disappeared. For a card-funded Apple Pay ecommerce transaction, Apple creates an encrypted payment token containing a device-specific account number and transaction-specific cryptographic data. The merchant or its payment service provider handles that token, the PSP submits the transaction into the card-payment infrastructure, the card network processes the tokenized credential, and the issuer still decides whether to approve or decline the payment. That distinction is the key to evaluating Apple Pay for international merchants. Apple Pay can materially change credential entry, device authentication, and the checkout experience. It does not replace the merchant's underlying card acceptance, acquiring, payment-state, refund, or financial operations. The merchant question is therefore not simply: Can we put an Apple Pay button on checkout? It is: For which customers, devices and markets does Apple Pay make payment meaningfully easier—and can the rest of our payment stack process and operate those transactions correctly?

What Apple Pay changes when the customer never types a card number A conventional card checkout asks the customer to provide information such as: * Card number * Expiration date * Security code * Billing information With Apple Pay, an eligible payment credential is already provisioned into Apple Wallet. The customer selects Apple Pay, sees the Apple Pay payment sheet, chooses an eligible credential, and authenticates the payment using the device. Apple states that the merchant does not receive the customer's actual credit or debit card number through Apple Pay; instead, the payment process uses a device-specific account number and transaction-specific cryptographic data. That can remove a significant amount of manual credential entry. But the complete payment path still looks roughly like this: Customer → taps Apple Pay Apple Pay payment sheet → shows eligible credential and transaction information Device authentication → customer confirms intent Apple Pay payment token → encrypted token containing payment information Merchant / PSP → processes the payment token Card network → handles the tokenized card credential Issuer → approves or declines Merchant → receives the payment result and completes or withholds the order Apple's own merchant documentation describes the PSP as using the decrypted token to run an ecommerce card authorization and the network as translating the token into the underlying credit/debit account before sending the request to the issuer.

That is why Apple Pay should be viewed as a wallet and authentication experience layered onto eligible payment credentials and card infrastructure, not as a substitute for the merchant's entire card-payment stack.

Apple Pay is not Apple Wallet These terms are often used as though they mean the same thing. They do not. Apple Wallet is Apple's wallet application for storing and managing eligible payment cards along with other items such as tickets, boarding passes, keys and passes. Apple Pay is the payment capability customers use to make eligible purchases using payment credentials available through that ecosystem. Apple itself describes Apple Wallet as the place where payment cards and other passes are stored, while Apple Pay is the mechanism used to make purchases in stores, apps and on the web. For merchants, this distinction matters because having Apple Wallet does not prove that a customer has: * An eligible card * A supported payment network * Apple Pay available in their market * A credential valid for the merchant's transaction The checkout should determine actual payment eligibility rather than infer it from the customer's operating system alone.

Who can actually use Apple Pay? There are several different availability questions hiding inside the phrase “Apple Pay is available.” Is Apple Pay available to the customer? Apple currently lists Apple Pay consumer support across countries and regions in North America, Latin America and the Caribbean, Europe, the Middle East, Africa and Asia-Pacific. Customer availability still depends on participating banks or card issuers, and Apple notes that even some cards from participating issuers may not be supported. So: Apple Pay exists in the customer's country does not necessarily mean: this customer's card can use Apple Pay. Can the merchant accept Apple Pay? This is a different question. Apple's current merchant guidance states that merchants can accept Apple Pay regardless of the country or region in which they operate, provided their payment service provider supports Apple Pay. That is a useful international distinction. Consumer availability is geographically constrained. Merchant acceptance is primarily constrained by the merchant's payment integration and PSP/acquiring configuration. Does the merchant accept the underlying network? Even when the merchant supports Apple Pay, Apple says the merchant must also accept the payment network of the customer's card. So eligibility is closer to: Apple Pay customer eligibility × eligible device/browser × provisioned credential × supported payment network × merchant/PSP support × correct transaction configuration

If any of those conditions fails, the Apple Pay logo alone does not create a usable payment method.

Apple Pay on the web is no longer a Safari-only question Older merchant guides frequently reduce Apple Pay web support to Safari. That is no longer a sufficient description. Apple now supports Apple Pay on compatible third-party web browsers. Apple describes support across additional browsers on Macs, PCs and other computers, where customers can initiate Apple Pay on the browser and complete the payment using an iPhone by scanning a code. Apple's consumer documentation states that compatible third-party-browser use requires an iPhone or iPad running iOS 18 or iPadOS 18 or later and notes that availability can still depend on market and participating merchant support. This changes how international merchants should measure Apple Pay. Do not simply segment: Safari versus non-Safari. Instead, consider: * Native iPhone/iPad checkout * Safari on Mac * Other supported browsers on Apple devices * Third-party desktop-browser flows requiring another Apple device * In-app checkout * In-app browsers where behavior may differ Apple's current applePayCapabilities API can be used to check Apple Pay support and payment-credential availability, including support for third-party browsers. Apple's older canMakePaymentsWithActiveCard method is now deprecated for this purpose. The practical rule is: Detect eligibility. Do not infer eligibility from browser name alone.

Web acceptance and app acceptance are different implementations Apple Pay can be integrated directly by a merchant or through a supporting ecommerce platform or PSP. Apple Pay on the web For merchants managing their own implementation, Apple's web setup includes an Apple Pay merchant identifier, certificates and domain verification. Apple's current documentation also describes merchant validation during an Apple Pay web session. Approved ecommerce platforms and PSPs can simplify parts of this process. Apple provides a Web Merchant Registration API that qualifying payment providers and platforms can use to register merchant websites using their own Apple Pay integrations. That means the operational setup depends partly on how the merchant integrates. A merchant using a PSP-hosted implementation may not perform exactly the same certificate and registration workflow as a merchant building directly against Apple's APIs. Apple Pay inside an app For direct native-app implementations, Apple requires the Apple Pay capability, merchant identifier and payment-processing configuration. There is also an important business-model boundary.

Apple's current App Review Guidelines distinguish purchases of physical goods or services consumed outside an app from certain purchases of digital content or functionality within the app. Apple explicitly lists Apple Pay as one possible payment mechanism for physical goods or services consumed outside the app; merchants selling digital goods inside native apps should verify the applicable App Store payment rules rather than assuming Apple Pay can replace required in-app purchasing mechanisms. For international merchants operating web, native app and mobile web simultaneously, “we support Apple Pay” may therefore represent several distinct integrations.

Wallet checkout is not necessarily express checkout Apple Pay can be presented as another payment method at the payment stage. It can also be integrated earlier as an accelerated checkout experience. Those are different product decisions. An Apple Pay payment request can include requested shipping and billing contact fields and shipping information, which can allow the wallet flow to supply information that would otherwise be entered elsewhere in checkout. That makes an express experience possible. It does not mean every Apple Pay implementation should skip the merchant's normal checkout steps. A merchant may still need information that Apple Pay does not provide or that must be collected separately—for example: * Account information * Product configuration * Tax information * Compliance information * Delivery instructions * Marketplace information * Subscription terms The merchant should therefore distinguish: Apple Pay as payment credential from: Apple Pay as accelerated checkout entry point. The first changes payment entry. The second changes the architecture of checkout itself. That broader placement question should be tested alongside Mobile-First Checkout Localization and Wallet Acceptance and Checkout Conversion, rather than assumed to be universally better.

Apple Pay authentication does not equal issuer authorization When a customer confirms an Apple Pay purchase, the device authenticates the user's intent using mechanisms such as Face ID, Touch ID or a device passcode. Apple's security documentation states that payment information is not sent until customer authentication occurs. That is the wallet authentication step. The card issuer still performs the payment authorization step. Apple's transaction flow shows that after the payment token reaches the payment infrastructure, the issuing bank receives the request and can approve or decline it. So: Face ID succeeded does not mean: the payment is approved. The transaction can still be declined because of: * Account status * Available funds or credit * Issuer risk * Card restrictions * Merchant/acquiring configuration * Other issuer or network factors That distinction matters when analyzing the wallet funnel. If wallet authentication completion is high but authorization is weak, redesigning the Apple Pay button is unlikely to solve the underlying problem.

Apple Pay and Strong Customer Authentication For merchants in the UK and European Economic Area, Apple documents Apple Pay support for Strong Customer Authentication requirements and provides specific implementation guidance around the merchant country code and final transaction amount. Apple warns merchants to verify regional requirements with their PSP and relevant authorities. This should not be translated into: Apple Pay automatically makes every European payment compliant. The implementation, transaction context, PSP/acquirer and applicable regulation still matter. International configuration matters elsewhere too. Apple's current regional guidance, for example, says merchants based in Saudi Arabia accepting domestic debit should include the mada network where applicable, while UAE merchants handling relevant domestic debit/prepaid transactions should account for the Jaywan network. The broader lesson is important: the same Apple Pay button can sit above different underlying network requirements in different markets.

What is actually tokenized? Apple Pay terminology becomes confusing because merchants may encounter several things called a token. At checkout, Apple Pay creates an encrypted payment token containing payment information that includes a device-specific account number and transaction-specific cryptographic data. The actual physical card number is not sent to the merchant as the customer's payment credential. That device-specific payment credential should not be confused with: * A merchant's internal customer-payment reference * A token created by the merchant's PSP * An Apple Pay Merchant Token used for eligible recurring relationships If the PSP receives the Apple Pay payment token and then gives the merchant a separate reusable token or stored-payment reference, that downstream token belongs to a different architectural layer. This matters for portability. A merchant should not assume that because an Apple Pay transaction is tokenized, every resulting credential can automatically move between PSPs. That question belongs in Payment Token Portability.

Recurring payments require a different Apple Pay design A successful one-time Apple Pay transaction should not automatically be interpreted as a reusable subscription credential. Apple supports Apple Pay Merchant Tokens for qualifying use cases such as recurring payments and automatic reload. Apple describes these merchant-specific tokens as enabling payment-information continuity independent of a particular device. Apple's recurring-payment APIs allow merchants to provide recurring-payment information and lifecycle-notification endpoints. However, Apple's documentation also states that Apple Pay issues a merchant token when the user's payment network supports merchant-specific payment tokens; otherwise, the payment request may use a device token instead. So subscription merchants need to verify at least four things: 1. Does the Apple Pay implementation support the recurring use case? 2. Does the relevant network support the required merchant-token model? 3. Does the PSP/acquirer support processing and lifecycle handling? 4. Does the merchant's own subscription platform understand what credential it is storing and charging? Apple Pay recurring support is therefore real, but it should not be described as universal. For subscription architecture, the merchant also needs to preserve: * Customer consent * Recurring-payment terms * Merchant token or provider token reference * Lifecycle notifications * Billing status * Cancellation/revocation handling * Retry logic

Apple also provides Wallet interfaces through which customers can view and, in supported scenarios, revoke preauthorized payment authorization. For SaaS and subscription merchants, recurring capability should be part of the Apple Pay decision before rollout, not added after significant wallet volume has already accumulated.

Refunds still belong to the merchant payment operation Apple Pay does not remove refund requirements. Apple's consumer guidance states that refunds for card purchases made using Apple Pay generally return to the payment card used for the transaction. In some merchant scenarios, the Apple Pay card number associated with the Wallet credential may be relevant rather than the number printed on the physical card. For ecommerce merchants, the more important operational test is whether their PSP and internal payment system can reliably: * Identify the original Apple Pay transaction * Initiate full refunds * Initiate partial refunds when supported * Link the refund to the original order * Report the refund correctly * Reconcile the financial result Do not build support workflows around asking customers for their physical card number if the original Apple Pay transaction can be identified internally. And do not assume the customer sees the refund immediately. Merchant initiation, processor/network handling and issuer posting are separate stages.

Apple Pay does not eliminate disputes Because card-funded Apple Pay transactions continue through the card-payment infrastructure, the merchant's dispute and chargeback exposure does not disappear merely because Apple Pay authenticated the customer. Apple's own payment-planning material places Apple Pay above the PSP, card network and issuer and explicitly recognizes refunds, voids and chargebacks as payment outcomes merchants may need to represent. The exact dispute process depends on the underlying network, issuer, acquirer and merchant arrangement. Merchants should therefore preserve ordinary dispute identifiers and evidence rather than treating Apple Pay as a dispute-free payment category.

Apple Pay acceptance does not replace acquiring This is the architectural distinction international merchants should keep most clearly. Apple Pay can determine how the customer presents an eligible card credential. It does not by itself determine: * Which PSP processes the transaction * Which acquirer receives it * Which merchant ID is used * Whether acquiring is local or cross-border * What the merchant pays * Which currencies are processed or settled * How the merchant receives its funds Apple's own architecture shows Apple Pay passing the payment token into PSP and card-network processing rather than creating a completely separate merchant settlement rail. This means merchants evaluating Apple Pay internationally should still analyze the underlying card path. Accepting Apple Pay and improving card acquiring are related decisions. They are not the same decision.

The Apple Pay Merchant Readiness Checklist Before rollout, score these ten areas. 1. Customer and device share Measure how much checkout traffic comes from environments where Apple Pay could be relevant. Do not use total site traffic. Segment at least by: * iPhone/iPad * Mac * Other desktop browsers capable of the cross-device flow * Native app * Mobile web * Country The business case is strongest when eligible traffic is meaningful. 2. Market availability Confirm that customers in the target market can actually provision eligible credentials. Do not infer customer eligibility from Apple's merchant-acceptance availability. Check Apple's current country/region and participating-issuer documentation immediately before launch. 3. PSP and acquiring support Confirm: * Apple Pay is supported * Relevant card networks are supported * Required merchant entity/MID is supported * Required currencies are supported * Required regional card networks are supported * Refunds work * Recurring processing works if needed Apple itself recommends confirming Apple Pay support with the merchant's PSP. 4. Web and app implementation Determine whether Apple Pay will exist in: * Web checkout * Native app * Both * Express checkout * Standard payment-method selection Treat these as separate product surfaces. 5. Merchant and domain setup

For merchant-managed web integrations, verify merchant IDs, certificates, domain registration/verification and merchant-validation flows. If a PSP or ecommerce platform manages registration, verify exactly which responsibilities it assumes. 6. Token and payment handling Document: Apple Pay payment token → PSP/acquirer → merchant payment ID and, for recurring merchants: initial Apple Pay transaction → merchant/provider recurring credential → lifecycle management Do not describe all of these as one “Apple token.” 7. Refund operations Test: * Full refund * Partial refund if needed * Refund after card/account changes where supported * Customer-support lookup * Reconciliation 8. Recurring requirements If subscriptions matter, validate Apple Pay Merchant Token and PSP/network support before launch. 9. Analytics Capture the Apple Pay funnel separately from ordinary card entry. At minimum distinguish: eligible → visible → selected → initiated → authenticated → authorized → order completed 10. Rollout testing Apple provides an Apple Pay sandbox with test payment cards. Test the implementation across relevant devices, browser paths, markets, decline/error handling and recurring/refund flows rather than validating only one successful purchase on one iPhone.

How to measure whether Apple Pay is actually helping The wrong metric is: Apple Pay payment volume That tells you customers are using it. It does not tell you whether accepting it created additional completed orders. Start with the full wallet funnel. Apple Pay eligibility rate Apple Pay-eligible checkout sessions ÷ relevant checkout sessions Use actual eligibility where your implementation can determine it rather than Apple-device traffic as a proxy. Apple Pay visibility rate eligible sessions where Apple Pay was displayed ÷ Apple Pay-eligible sessions A low number indicates a checkout-presentation or technical problem. Apple Pay selection rate sessions selecting Apple Pay ÷ sessions where Apple Pay was eligible and visible This measures preference among customers who could actually choose it. Apple Pay authentication completion customers completing the Apple Pay device/payment-sheet confirmation ÷ Apple Pay initiations This isolates wallet-flow abandonment from issuer declines. Apple Pay authorization rate approved Apple Pay authorization attempts ÷ valid Apple Pay authorization attempts submitted Segment by country, issuer geography where appropriate, network, PSP/acquirer and transaction characteristics before comparing Apple Pay with manually entered cards. Apple Pay completed-order rate completed orders initiated with Apple Pay ÷ eligible Apple Pay payment initiations Define “completed” consistently with the merchant's broader payment reporting. Incremental completed orders

This is the hardest—and most useful—question: How many customers completed because Apple Pay existed who otherwise would not have completed? Apple Pay volume cannot answer that. An existing card customer who shifts from typing their card to Apple Pay may represent a valuable convenience improvement without representing incremental customer access. Where feasible, compare controlled eligible cohorts, rollout periods, placement experiments, new versus returning customers, and comparable device/browser populations. If Apple Pay selection rises but the completed-order rate among eligible customers does not, the merchant should not describe the integration as a conversion improvement without further evidence.

Who should prioritize Apple Pay? Apple Pay deserves greater priority when several conditions overlap: * Significant eligible Apple-device traffic * Customers already using supported Apple Pay cards * High mobile checkout share * Meaningful abandonment around credential entry * Strong guest-checkout volume * Product categories where faster checkout is valuable * PSP/acquirer support without disproportionate implementation burden * Refund and recurring requirements that can be handled correctly The business case is weaker when eligible Apple Pay traffic is very small or when the merchant's main payment-access problem is not credential entry at all. For example, Apple Pay will not solve a market where customers predominantly need a local bank-transfer method, stored-value wallet or payment system that is not represented by the merchant's Apple Pay/card acceptance. That is why the larger wallet strategy should ask: Does this wallet add payment access, reduce payment friction, or merely move existing successful payments into another interface? All three can have value. They should not be measured as though they were the same.

A global payments provider can potentially reduce the integration burden of connecting wallet and card experiences across markets, but Apple Pay-specific capability must be verified at the product and merchant-configuration level.

* Supported countries or merchant entities * Web versus native-app support * Third-party-browser support * Apple Pay Merchant Tokens * Recurring transactions * Refund behavior * Supported networks * Settlement

The stronger merchant message is not that accepting one global wallet solves international payments. It is that the wallet should sit inside a payment stack capable of presenting the right payment experience to the right eligible customer while preserving the merchant's underlying acquiring, payment-state and operational controls.

Apple Pay merchant FAQ Is Apple Pay a separate payment rail from cards? For typical card-funded Apple Pay ecommerce payments, no. Apple Pay tokenizes and presents an eligible credential and provides the wallet-authentication experience, but the transaction continues through PSP/acquirer, card-network and issuer infrastructure. Can a merchant outside an Apple Pay consumer country accept Apple Pay? Apple's current merchant guidance states that merchants in any country or region can accept Apple Pay provided their PSP supports it. Customer eligibility remains dependent on supported countries, issuers, cards and devices. Does Apple Pay work only in Safari? No. Apple now supports Apple Pay on compatible third-party browsers, including cross-device flows where a customer can initiate payment on another computer and complete it on an eligible iPhone or iPad. Availability can depend on market, browser capability and merchant/PSP implementation. Does Face ID mean the issuer must approve the payment? No. Device authentication verifies the customer's payment intent. The issuer still receives the payment authorization request and can approve or decline it. Does Apple Pay expose the customer's physical card number? Apple states that the customer's actual card number is not shared with the merchant through Apple Pay. The payment flow uses device-specific payment credentials and transaction-specific cryptographic data instead. Can Apple Pay support subscriptions?

Apple provides Merchant Tokens for supported recurring and automatic-reload scenarios, but merchant-token availability depends in part on network support and the merchant's integration and PSP capabilities. A successful one-time Apple Pay transaction should not automatically be assumed to create a reusable recurring credential. How do Apple Pay refunds work? For card-funded Apple Pay purchases, Apple states that merchant refunds generally return to the payment card associated with the Apple Pay transaction. Exact merchant processing, partial-refund support and reconciliation depend on the PSP/acquirer implementation. Does Apple Pay automatically improve checkout conversion? It can remove manual credential-entry steps for eligible customers, but merchants should measure completed orders rather than infer improvement from wallet selections or transaction volume. Apple itself promotes checkout-speed and conversion benefits, but merchant performance should be validated against the merchant's own eligible customer cohorts. Final recommendation Treat Apple Pay as an eligible-customer checkout capability, not a logo to add to a global payment-method list. First determine who can actually use it. Then verify that the merchant's PSP, acquirer, payment networks, markets and transaction types can process it correctly. Then design the button and checkout experience. Then make sure authentication, authorization, refunds, recurring payments, reporting and settlement still work downstream.

Finally, measure whether eligible customers complete more orders—not simply whether they choose Apple Pay. For merchants with meaningful Apple-device traffic, that can make Apple Pay a high-priority checkout capability. For everyone else, its priority should be earned by evidence. The question is not whether Apple Pay is globally recognizable. It is whether Apple Pay materially improves payment access or checkout completion for the customers this merchant is actually trying to serve.

I treated the attached Editorial Brief 6: Apple Pay for International Merchants as the controlling specification. The article below keeps Apple Pay in its proper place in the payment chain: it changes how an eligible customer presents and authenticates a credential, but the merchant still depends on supported payment networks, PSP/acquirer connectivity, issuer authorization, refunds, reconciliation, and recurring-payment architecture. Editorial interpretation Unique evidence anchor: a customer can complete checkout without typing a card number, yet the resulting payment still travels through a supported card credential, PSP/acquirer, card network, and issuer. Apple's own merchant flow explicitly shows the PSP using the Apple Pay payment token to run an ecommerce credit/debit authorization, with the card network and issuer remaining downstream participants. Editorial position: prioritize Apple Pay where eligible Apple-device customers represent meaningful checkout traffic and where replacing manual credential entry with the wallet flow improves completed-order performance. Do not treat Apple Pay volume itself as proof of incremental conversion. Assumption challenged: “Adding Apple Pay creates an entirely separate rail from cards.”

Merchant decision: determine whether enough customers are actually Apple Pay-eligible, whether the merchant's PSP/acquirer supports their underlying payment networks, whether web/app implementation is complete, and whether downstream refunds, recurring payments, reporting, and settlement work correctly. Format: merchant-readiness and payment-flow guide. Structural rationale: follow the payment first, then determine customer/merchant eligibility, implementation, recurring/refund operations, and finally measurement. Supporting visual: Apple Pay merchant payment flow ELIGIBLE CUSTOMER iPhone / iPad / Mac / supported browser flow │ ▼ APPLE PAY BUTTON │ ▼ APPLE PAY SHEET Card + amount + merchant + requested details │ ▼ CUSTOMER AUTHENTICATION Face ID / Touch ID / passcode │ ▼ APPLE PAY PAYMENT TOKEN Device-specific credential + transaction cryptogram │ ▼ MERCHANT / PSP Decrypts or processes token │ ▼ ACQUIRER / NETWORK Tokenized card processing │ ▼ ISSUER Approve / decline │ ▼ MERCHANT PAYMENT STATE │ ┌──────┴───────┐ ▼ ▼ ORDER COMPLETE FAILURE / RETRY │ ▼ Refunds • disputes • reconciliation • settlement Visual title: What Changes—and What Doesn't—When a Customer Pays with Apple Pay Alt text: “Apple Pay ecommerce payment flow from eligible device and customer authentication through tokenized credential, PSP, acquirer, card network, issuer authorization, merchant order completion, refunds and settlement.” SEO package Field Recommendation SEO title Apple Pay for International Merchants: Integration & Acceptance H1

Apple Pay for International Merchants: Acceptance, Integration, and Market Fit URL /customers-cant-pay-their-way/digital-wallets/apple-pay-for-international-merchants/ Meta description Learn how international merchants can accept Apple Pay across web and apps, including eligibility, tokenization, recurring payments, refunds, devices and measurement. Primary keyword Apple Pay for international merchants Secondary keywords accept Apple Pay internationally; Apple Pay merchant integration; Apple Pay ecommerce; Apple Pay global merchant; Apple Pay checkout; Apple Pay countries merchants; Apple Pay recurring payments; Apple Pay payment processing Structured data Article or TechArticle + BreadcrumbList; FAQ markup only if desired and still useful for the implementation Excerpt Apple Pay can remove card-entry friction without replacing the card infrastructure underneath. Here is how international merchants should evaluate eligibility, devices, PSP support, tokenization, recurring payments, refunds and actual checkout performance. Related entities: Apple Pay, Apple Wallet, PassKit, Apple Pay JS, Face ID, Touch ID, Device Account Number, Apple Pay Merchant Token, payment token, network tokenization, PSP, acquirer, issuer, card network, SCA, PSD2, recurring payment. Internal linking

The highest-value internal links are Digital Wallets Explained from the Apple Pay-versus-wallet distinction; Mobile-First Checkout Localization from device/browser and express-checkout design; Wallet Acceptance and Checkout Conversion from incrementality measurement; and Payment Token Portability from the distinction between Apple Pay credentials, merchant tokens and PSP-issued tokens. I would also link into relevant country-payment guides where Apple Pay materially matters rather than turning this article into a country-by-country Apple Pay directory. Authoritative publication sources Use Apple's current Planning for Apple Pay materials as the core technical source because Apple explicitly maps merchant → PSP → card network → issuer and explains the encrypted payment token. Use Apple's current Countries and regions that support Apple Pay page for customer-market availability and third-party-browser conditions, rather than older wallet roundups. The page was updated May 19, 2026. Use current Apple Developer documentation for applePayCapabilities, web merchant setup, merchant validation, recurring-payment requests and Merchant Tokens. Use Apple Platform Security for device authentication and token/card-number claims, and Apple Support for refund behavior. For UK/EEA SCA and market-specific network configuration, retain Apple's regional-regulation guidance rather than secondary interpretations. Publication fact-check list

Wallet facts: re-check Apple's consumer-country list, current participating issuers/networks and Apple Pay brand terminology immediately before publication. Apple Pay availability changes over time. Country facts: do not convert Apple's consumer availability list into a list of countries from which merchants may accept Apple Pay. Apple currently makes the broader merchant statement that merchants anywhere may accept it if their PSP supports Apple Pay.

Eligibility facts: verify merchant entities, card networks, currencies, merchant categories and acquiring relationships. An Apple Pay-capable customer is not necessarily eligible for every merchant transaction.

Security/regulatory: have a payments/security reviewer validate token terminology. For EEA/UK use, validate merchant countryCode, final-amount handling and PSP implementation against current requirements. Apple itself says its regional guidance may not be complete. Amber-flag claims to avoid without internal evidence

Before publication, internally confirm: 1. Whether Apple Pay is currently supported. 2. Merchant models/products supporting it. 3. Supported merchant countries/entities. 4. Supported networks and currencies. 5. Web, native-app and third-party-browser availability. 6. Merchant registration/domain requirements. 7. Refund and partial-refund support. 8. Apple Pay Merchant Token/recurring support. 9. Reporting identifiers. 10. Settlement/acquiring model.

Proposed human accountability

Recommended reviewers: Apple-platform payments engineer, checkout product manager, tokenization/payment-security specialist, and payment-operations specialist. Add a recurring-billing reviewer if subscriptions remain prominent. Cluster sameness-audit record Field Apple Pay article Opening device Customer completes without typing card number Main wallet Apple Pay Main customer segment Eligible Apple-device ecommerce customer Format Merchant readiness + payment-flow guide Evidence anchor Credential entry changes; card infrastructure remains Editorial position Prioritize based on eligible traffic and completed orders Assumption challenged Apple Pay is a separate rail from cards Merchant decision Whether Apple Pay deserves acceptance priority Main asset Apple Pay Merchant Readiness Checklist Main visual Customer → token → PSP/network → issuer flow Primary metric Completed-order performance among eligible customers Device differentiator Current Safari + third-party-browser/cross-device support Operational differentiator Merchant Tokens + refunds Conclusion Eligibility and incrementality determine priority CTA direction Assess Apple Pay readiness / verify merchant availability Explicitly not owned Generic wallet definition, country wallet ranking, general conversion thesis

v1 Apple Pay for International Merchants Apple Pay reads as a solved problem for merchants — it's one toggle in most checkout providers, and the assumption is that once it's on, it works everywhere Apple sells an iPhone. In practice, availability, card network support, and even entity requirements vary by country in ways that matter for how a merchant configures checkout market by market. What "supported" actually means A country appearing on Apple's list of supported countries and regions doesn't mean every customer there can use Apple Pay by default — it means at least one bank or card issuer in that market can issue Apple Pay–compatible cards. Coverage within a "supported" country still depends on which bank issued the customer's card, and Apple maintains separate participating-bank lists by region because issuer support is added on a rolling basis rather than all at once. Treating "the country is supported" and "every customer can pay with it" as the same thing overstates actual coverage in markets where issuer adoption is still partial. Where Apple Pay isn't available at all

Coverage spans dozens of countries and regions across North America, Europe, Asia-Pacific, Latin America, the Middle East, and parts of Africa, but several large markets are notably absent from Apple's official list, including India, Indonesia, Thailand, and the Philippines. This isn't a rollout delay so much as a structural gap — launching Apple Pay in a country requires agreements with local banks, card networks, and financial regulators, and in some of these markets, locally dominant mobile payment platforms and regulatory conditions have kept it out entirely rather than pending. Merchants targeting these markets need a wallet strategy that doesn't rely on Apple Pay as a fallback. (See Digital Wallets by Country and Top Digital Wallets Worldwide for what does have traction in those markets.) Country support and currency are two separate settings A detail merchants configuring checkout often miss: the list of countries a merchant enables for Apple Pay does not determine which currency the transaction uses — currency is set independently via its own ISO 4217 currency code, separate from the merchant's supported-country configuration. In practice, this means enabling a country for Apple Pay and localizing the currency shown at checkout are two different configuration steps, not one setting that handles both. (See Localizing Currency at Checkout.) Card network support varies by country, and some networks carry entity requirements

Apple Pay isn't a single uniform payment rail once it reaches the processor — which card networks are usable through it differs by country, and a few carry conditions merchants should know about before assuming a market is fully covered: * Eftpos in Australia and Elo in Brazil are both examples where a processor may require the merchant to hold a local business entity in that country before offering the network through Apple Pay * Interac in Canada carries a similar local-entity condition with some processors * Girocard in Germany and Cartes Bancaires in France are each scoped to their home market rather than usable elsewhere This means "Apple Pay is enabled" can still mean a materially different set of underlying card networks depending on the country — and in some cases, full network coverage is gated behind the same local-entity question that applies to acquiring more broadly. (See When Does a Merchant Need a Local Entity? for how that trade-off is usually evaluated.) What merchants actually need to accept Apple Pay internationally Beyond enabling it as a checkout option, accepting Apple Pay requires a small set of technical prerequisites that apply globally, not just in a specific market: * Domain verification for every web domain where Apple Pay will be offered * A merchant identity certificate used to validate the merchant session with Apple

* A processor or payment provider capable of decrypting the Apple Pay payment token, since the token itself is encrypted and not directly usable without that step * For web checkout specifically, a compatible browser — Apple Pay on third-party browsers has its own device and OS version requirements, and isn't available with every merchant or in every market even where the wallet itself is supported Most merchants handle this through their payment provider rather than building the certificate and token-decryption layer directly, which is also where country-specific network quirks (Eftpos, Elo, Interac, and similar) tend to get absorbed rather than needing separate handling per market. Treat it as a market-by-market configuration, not a global toggle The practical takeaway for a merchant expanding into new countries is that "we support Apple Pay" is not a single true/false statement. It's closer to a per-market configuration — which card networks are actually usable, whether local entity requirements apply, and how coverage compares to the country's actual issuer adoption — that's worth checking market by market rather than assuming uniform coverage everywhere Apple Pay technically appears on a list.

Internal links to build once corresponding pages are live: Digital Wallets by Country · Top Digital Wallets Worldwide · Localizing Currency at Checkout · When Does a Merchant Need a Local Entity? · Wallet Acceptance and Checkout Conversion. Figures used: 190+ markets, 200+ local payment methods — per current canonical figures. Country and card-network specifics checked against Apple's official supported-countries and participating-bank pages, and processor documentation, as of July 2026 — this list is updated by Apple on a rolling basis and should be reconfirmed before publishing. No unverified merchant-count or user-count claims used in this draft. Title Apple Pay for International Merchants Url /solve/customers-cant-pay-their-way/digital-wallets/apple-pay-for-international-merchants/ Pillar Customers Can't Pay Their Way Cluster B — Digital wallets Meta_description Apple Pay being 'supported' in a country doesn't mean what most merchants assume it means. Here's what actually varies market to market. Status draft — country/network specifics checked against Apple's official supported-countries page and processor documentation (July 2026); this list changes over time and should be reconfirmed before publishing