On this page:
Overview
Apple Pay
Google Pay
Test and go live
FAQ
Overview
Apple Pay and Google Pay let shoppers pay with a card already saved in their wallet. On the hosted payment page the wallet
buttons appear at the top of the card step. The shopper taps a button, picks a card in the wallet's payment sheet,
confirms with their device (Face ID, Touch ID, fingerprint or passcode), and the payment is completed on the page.
Shoppers who prefer can still type their card.
Requirements
| Requirement | Description |
|---|
| Integration type |
Hosted payment page with the Flow design: send ui_version=11 in your request, or make Flow the default design of your account.
No other change to your request is needed. |
| Provider |
Your acquirer / payment provider must accept the wallet on the merchant account that processes your hosted page payments. |
| Setup steps |
Before you begin:
- Ask your provider to enable Apple Pay and/or Google Pay on your merchant account (see the details per wallet below).
- Send your account manager the wallet(s) you want and the details listed for each wallet below.
- We enable the wallet on your account, first on your test account.
|
| Certificates, keys, developer accounts |
Not needed. The hosted payment page runs both wallets under our own Apple and Google registrations.
If you want to use your own registrations on your own website, see External Wallet (S2S). |
Apple Pay
Apple Pay uses network tokenization: the card is stored on the shopper's Apple device as a device-specific number,
and each payment carries a one-time cryptogram created when the shopper confirms with Face ID, Touch ID or their passcode.
| Payment type | Wallet |
| Payment flow | On the page (no redirect) |
| Countries | Where Apple Pay is available and your provider accepts it |
| Currencies | The currencies of your hosted page request that your provider accepts |
| Refunds / partial refunds | Yes - as for card payments |
| Chargebacks | Yes - as for card payments |
| Recurring | No - use a card payment for recurring series |
| Payment method in reports | Apple Pay, with the brand of the card in the wallet |
Compatibility
The Apple Pay button is shown only when the shopper's device and browser can pay with Apple Pay, for example Safari on an
iPhone, iPad or Mac, with a card added to Apple Wallet. Apple Pay is available with participating card issuers in the countries
and regions where Apple offers it. Everyone else does not see the button and pays by card or another method.
Supported networks
Visa, Mastercard, American Express, Discover, JCB and Maestro, subject to what your provider accepts for your account.
Apple Pay certificate
Every Apple Pay payment needs an Apple Pay merchant registration and certificates. On the hosted payment page ours are used:
- You do not need an Apple Developer account, an Apple merchant ID, a certificate signing request (CSR) or a certificate.
- We verify the payment page domain with Apple. If your hosted payment page runs on your own custom domain, tell us the domain so we can verify it.
- We decrypt the Apple Pay payment data and send the device card number, expiry and cryptogram to your provider as an Apple Pay transaction.
Your provider must accept Apple Pay data decrypted by the payment service provider - ask them to confirm this for your account.
If your provider asks you to create a CSR or upload an Apple Pay certificate, that step is for merchants who run Apple Pay under their own Apple merchant ID.
You can skip it for the hosted payment page.
Liability shift
Apple Pay payments are authenticated on the shopper's device and carry a cryptogram, so the shopper is normally not asked for 3-D Secure again.
Whether the liability shifts to the issuer depends on the card network and region; your provider can confirm the rules for your account.
Details to send us
| Item | Description |
|---|
| Provider confirmation | Apple Pay is enabled on your merchant account, for data decrypted by the payment service provider. |
| Business name | Shown to the shopper in the Apple Pay sheet. We use the name on your account; tell us if it should be different. |
| Business country | Required by Apple on every payment request. We use the country on your account. |
| Custom domain (if any) | The domain your hosted payment page runs on, if it is not our standard payment page domain. |
Google Pay
With Google Pay, shoppers pay with a credit or debit card saved in their Google account, from Chrome and other supported browsers,
on Android and on desktop. Google Pay shows a payment sheet where the shopper picks a card and confirms the purchase.
| Payment type | Wallet |
| Payment flow | On the page (no redirect, except when the card needs 3-D Secure) |
| Countries | Where Google Pay is available and your provider accepts it |
| Currencies | The currencies of your hosted page request that your provider accepts |
| Refunds / partial refunds | Yes - as for card payments |
| Chargebacks | Yes - as for card payments |
| Recurring | No - use a card payment for recurring series |
| Payment method in reports | Google Pay, with the brand of the card in the wallet |
Compatibility
The Google Pay button is shown only when the shopper is signed in to a Google account with at least one card that can be used,
in a browser that supports Google Pay.
Supported networks
Visa, Mastercard, American Express, Discover and JCB, subject to what your provider accepts for your account.
How the payment data is protected
Google encrypts the card data in each payment for one party only. Which party depends on your provider, and decides what you need to send us:
| Mode | Who decrypts | What you need |
|---|
| Coriunder gateway (default) |
We do. We are a Google Pay supported gateway, so Google encrypts the payment for us; we send the card data and cryptogram to your provider. |
Nothing. You are identified to Google by your merchant number with us. |
| Your provider's gateway |
Your provider. It must be a gateway supported by Google Pay. |
From your provider: the gateway name they are registered under with Google, and your gateway merchant ID (the merchant account or ID they gave you).
No certificate or key. |
Your account manager tells you which mode applies to your provider.
Liability shift
A card can be saved in Google Pay in two ways:
- As a device token (mostly on Android): the payment carries a cryptogram and the shopper is normally not asked for 3-D Secure.
- As the card number itself (common on desktop): there is no cryptogram, so your provider may ask for 3-D Secure. The payment page then takes the shopper
through the issuer's verification, exactly as for a typed card.
Liability shift rules differ per card network and region; your provider can confirm them for your account.
Google merchant ID and domains
Google Pay works in production only on registered websites. The hosted payment page is registered by us with Google, so you do not need
a Google Pay & Wallet Console account or a Google merchant ID for it.
Details to send us
| Item | Description |
|---|
| Provider confirmation | Google Pay is enabled on your merchant account. |
| Gateway name (provider gateway only) | As given by your provider, for example the provider's name in lower case. |
| Gateway merchant ID (provider gateway only) | Your merchant account or ID at the provider. |
| Business name | Shown to the shopper in the Google Pay sheet. We use the name on your account. |
Test and go live
Test Apple Pay
- Use an Apple sandbox tester account on your test device and add Apple's test cards to its Wallet (see "Sandbox testing" on Apple's developer website).
- Open a hosted payment page on your test account with
ui_version=11 in Safari, tap the Apple Pay button and confirm.
- Check the result in your Merchant Control Panel transaction list: payment method Apple Pay.
Test Google Pay
- Sign in to a Google account in Chrome. On our test environment Google Pay runs in Google's test mode, so you can join Google's test card suite or use a real card - it is not charged.
- Open a hosted payment page on your test account with
ui_version=11, tap the Google Pay button and confirm.
- Check the result in your Merchant Control Panel transaction list: payment method Google Pay.
Before you go live
- Your provider confirmed the wallet is enabled on your live merchant account (for Apple Pay: for data decrypted by the payment service provider).
- For Google Pay through your provider's gateway: the live gateway merchant ID is sent to us (it can differ from the test one).
- A test payment was approved for each wallet you want.
- Custom payment page domain, if any, is sent to us so it can be verified before go-live.
- Your use of the wallets follows Apple's Apple Pay terms and guidelines and Google's Google Pay API terms and acceptable use policy.
We then switch the wallet on for your live account. Nothing changes in your requests.
Frequently asked questions
| Do I need to change my payment page request? |
No. Use the Flow design (ui_version=11, or set it as your default). The buttons appear once the wallets are enabled on your account. |
| Can I use Apple Pay and Google Pay together? |
Yes. Each shopper sees the button for the wallet their device supports; on a device that supports both, both are shown. |
| A payment was declined. Can the shopper try again? |
Yes. The wallet button comes back and the shopper confirms again, or pays by card. |
| My provider already offers Apple Pay on its own checkout page. |
That keeps working: the shopper selects Apple Pay in the payment method list and is taken to your provider's page. The buttons on this page are the alternative where the shopper never leaves the payment page. |
| I want to show the wallets on my own website. |
Use External Wallet (S2S). There you register with Apple and Google, handle the certificates and the payment sheet yourself, and send us the result. |