Apple Pay and Google Pay for cross-border checkout: what changes

A shopper who reaches a cross-border store on a phone often already has a card in Apple Pay or Google Pay. For that shopper, a wallet button replaces sixteen digits, an expiry date and a security code with a glance or a fingerprint. For the merchant, the same button raises questions the card form never did: which authentication it carries, which countries it works in, which provider decrypts it and what happens to local cards.

This article explains what Apple Pay and Google Pay are technically, what they change for SCA and liability, where they are available, how setup and routing work, and what stays the same for refunds and disputes. For how wallet tokens relate to other tokens, see network tokens vs PSP tokens; for the wider checkout, see checkout localisation.

What are Apple Pay and Google Pay, technically?

They are card payments, carried in a digital wallet. What differs is the credential the merchant receives.

Apple Pay. Apple’s security overview says that when a card is added, the issuer or its service provider creates a device-specific Device Account Number, encrypts it and sends it to Apple, which stores it on the device. When the shopper pays in an app or on a website, Apple sends that Device Account Number with a transaction-specific dynamic security code. Neither Apple nor the device sends the actual card number. The shopper authenticates with Face ID, Touch ID or the passcode.

Google Pay has two modes, which Google’s API reference calls authentication methods:

• CRYPTOGRAM_3DS: cards stored as Android device tokens. The response includes a 3-D Secure cryptogram generated on the device.
• PAN_ONLY: cards stored on file with the shopper’s Google account. The response includes the card number and expiry date.

Stripe’s documentation adds a third case: cards selected on a site that pays with Google Pay can be saved as e-commerce tokens, for which it says neither liability shift nor 3-D Secure is supported at this time. The device-token cases behave like a network token with a cryptogram. PAN_ONLY behaves like a typed card.

Credential	What the merchant receives	Built-in authentication	Liability shift
Apple Pay	Device Account Number and dynamic code	Face ID, Touch ID or passcode	Yes, per Checkout.com, subject to ECI
Google Pay CRYPTOGRAM_3DS	Android device token and cryptogram	Device unlock	Yes, by default, per Checkout.com
Google Pay PAN_ONLY	Card number and expiry	None for the card	Only with 3-D Secure

What do wallets change for authentication and SCA?

Device tokens usually satisfy authentication on their own; PAN_ONLY does not.

Checkout.com’s Apple Pay documentation says Apple Pay payments benefit from liability shift because of Apple’s built-in authentication, and that additional issuer authentication is not required. It adds two conditions: send the correct country code and show the final amount on the payment sheet. Liability still depends on the ECI value the issuer returns, and schemes can downgrade it during authorization.

For Google Pay, Checkout.com says CRYPTOGRAM_3DS offers SCA compliance by binding the credential to an Android device and letting issuers delegate authentication to Google. For PAN_ONLY, typical on desktop or non-Android browsers, payments in SCA scope must use a 3-D Secure exemption or be processed with 3-D Secure. Both Checkout.com and Stripe note that liability shift on Visa Google Pay payments requires an opt-in to Fraud Liability Protection for Visa Device Tokens in the Google Pay console, which Stripe handles automatically on its hosted products.

Google’s API reference also asks merchants who process in the EEA, or in any country subject to SCA, to send the acquirer’s country code. For a cross-border shop this means the wallet request has to match the route, not the shopper. Our guide to 3DS2 exemptions explains when strong customer authentication applies at all.

Where can shoppers use Apple Pay and Google Pay?

In most of the markets cross-border shops sell into, but not all. Apple lists where shoppers can add cards from participating banks and card issuers; Google lists where shoppers can pay online or in apps. We checked both in October 2026.

Market	Apple Pay	Google Pay online
Saudi Arabia, UAE, Qatar, Kuwait, Bahrain, Jordan	Listed	Listed
Egypt, Morocco	Listed	Listed
Kenya, Nigeria, Ghana	Not listed	Listed
Kazakhstan, Georgia, Armenia, Azerbaijan, Kyrgyzstan, Tajikistan	Listed	Listed
Uzbekistan	Listed	Listed
Turkey	Not listed	Not listed
Brazil, Mexico, Colombia, Peru, Chile, Argentina	Listed	Listed

Two cautions. A listed country does not mean every bank participates: Apple says cards must come from participating banks and card issuers, and Google says some features are only available in certain countries and on certain devices. And Apple says Apple Pay in third-party browsers needs an iPhone or iPad with iOS 18 or later and is not available in all markets.

What does the setup involve?

Less than a card integration, but with steps that are easy to miss.

• Domain registration. Stripe says Apple Pay and Google Pay work with no extra configuration on its hosted checkout and payment links. For embedded forms, every domain that shows the button must be registered, including subdomains such as www, in production and testing.
• Merchant validation. For Apple Pay, Stripe creates the Apple Merchant ID and certificate signing request itself and tells merchants not to follow Apple’s own merchant validation steps. Other providers handle this differently, so ask who owns the Apple identifiers.
• Iframes. Stripe says an iframe’s origin must match the top-level origin, except in Safari 17 or later with the allow=“payment” attribute, and both domains must be registered if they differ.
• HTTPS. Stripe says Google Pay on the web needs a page served over HTTPS with a TLS domain-validated certificate.
• Terms. Google Pay requires acceptance of Google’s terms, and Apple Pay on the web has its own.

How do wallet payments reach a PSP?

Through a gateway token, in most setups. Google’s API reference offers two tokenization types. With PAYMENT_GATEWAY, the merchant names a gateway and its gateway merchant ID, and the encrypted payload is meant for that gateway. With DIRECT, the merchant decrypts the payload on its own servers; Google says this requires PCI DSS compliance validated by a Qualified Security Assessor, and that third parties supplying gateway services on behalf of merchants are not eligible.

This matters when you work with more than one provider. A wallet payload prepared for gateway A is not something gateway B can read. If you want to route wallet payments by country or cascade them after a soft decline, someone in a PCI DSS compliant position has to decrypt the payload and present the credential to whichever provider is chosen. Ask each provider whether it can process wallet credentials decrypted elsewhere, and keep wallets out of cascade rules until the answer is yes. Our article on card token portability covers why wallet tokens are usually left out of migrations.

For subscriptions, Stripe recommends Apple Pay merchant tokens for merchant-initiated payments, because they work across the customer’s devices and stay active when a device is lost or stolen.

Do local cards work inside the wallets?

Sometimes, and the route decides. Google’s API reference lists AMEX, DISCOVER, INTERAC, JCB, MASTERCARD and VISA as card networks, plus ELO and other networks for Brazilian combo cards. Domestic schemes such as mada, Troy or Humo are not on that list.

Inside Apple Pay, Checkout.com says that a merchant processing mada cards through Apple Pay outside Saudi Arabia must enforce Visa or Mastercard. A co-badged card then runs on the international scheme; a mada-only card cannot be used. Our guide to mada and local cards covers the configuration.

Worked example: adding wallets to a mobile checkout

Example figures, for illustration only.

An online fashion retailer sells to the Gulf and Kazakhstan. 20,000 mobile sessions a month reach the payment step, and 60% complete with the card form. It adds Apple Pay and Google Pay above the card form; 35% of sessions use a wallet, and they complete at 75%.

Path	Sessions	Completion	Orders
Before: card form only	20,000	60%	12,000
After: wallet button	7,000	75%	5,250
After: card form	13,000	60%	7,800
After: total	20,000	65.25%	13,050

The retailer gains 1,050 orders a month, 8.75% more. The catch is selection: shoppers who already use wallets may convert better anyway. Stripe measured this with a holdback experiment, in which, among eligible checkouts, global businesses that offered Apple Pay saw an average 22.3% increase in conversion and a 22.5% increase in revenue. Stripe also reports that showing Apple Pay early, with its express checkout, gave an average 2x increase in conversion against showing it at the end. A holdback on your own traffic is the only fair test.

How do refunds and disputes work?

Like card payments. Stripe supports full and partial refunds for both wallets, and its Google Pay documentation says refund and dispute processes are the same as for cards. Shoppers authenticate when they pay, which Stripe says reduces fraud and unrecognised payments, but they can still dispute afterwards, and the merchant submits evidence as for any chargeback.

What are the common mistakes?

• Treating Google Pay as one thing. PAN_ONLY payments need 3-D Secure in SCA scope; device tokens usually do not. Handle both modes.
• Registering one domain. A button on www or a shop subdomain fails silently if only the root domain is registered.
• A country code that does not match the acquirer. Google asks for the acquirer’s country in SCA markets, and Checkout.com ties Apple Pay liability shift to the correct country code.
• Assuming wallets cascade. A payload encrypted for one gateway cannot be retried at another unless your setup decrypts it in a compliant layer.
• Offering wallets where shoppers have none. In Turkey, neither wallet appears on the official lists we checked, so a card form and local methods do the work.
• Judging the wallet by its own completion rate. Wallet users are self-selected. Compare checkouts with and without the button.

How does Omno support Apple Pay and Google Pay?

Omno works around the wallet, not inside it. Wallet providers are among the provider types behind Omno’s one API, the hosted checkout shows the methods eligible for each customer’s country, and routing rules can choose providers by country, method and currency. Final statuses arrive by webhook, and the dashboard shows approval and decline reasons by provider, method and country. You still accept Apple’s and Google’s terms, register your domains, and confirm with Omno which wallet and decryption setup each connected provider supports. The hosted checkout page covers the flow.