You're viewing documentation for our latest API. This will not impact your integration, but you will need the documentation relevant to you. If you have an account with Checkout.com you have received an email confirming which version to use.
By integrating Google Pay into your website or Android application, your customers can securely make one-touch payments using any credit or debit card connected to their Google account.
To enable Google Pay in the UAE or Saudi Arabia, please request activation from your Account Manager.
To start processing Google Pay payments, you must first integrate directly with Google. Once integration is complete, you can add the Google Pay button to your checkout page and start requesting your customers' encrypted payment information.
Google Pay integration and payments can be simplified into a three-step method:
CRYPTOGRAM_3DS credentials receive liability shift by default. Applying 3DS for Google Pay enables liability shift for PAN_ONLY transactions.
Read more about Google Pay liability shift eligibility on our 3D Secure page.
Before going live, you are required to register with Google Pay & Wallet Console and select Checkout.com as your payment processor. You will also need to set up an allowlist for your domain. Note that you must be signed in as a Google Developer to do this. If not, you will be redirected to Google Pay's support page.
You will need to specify which card types and card schemes to support in your payment data request.
Once you have received the payment data from Google, you then need to call Checkout.com’s endpoint for tokenizing the encrypted payment data; you can find this payment data in the paymentMethodToken property of the Google Pay payment data request's response.
Now you have the token, it's time to authorize the payment. Take the token, and use it in the body of a card token payment request from your application or website's backend server.
Google Pay offers two authentication modes:
PAN_ONLY - the card is stored on file with your customer's Google account. Thus, the payment credentials are not bound to an Android device (for example, desktop or non-Android mobile web).
CRYPTOGRAM_3DS - Google Pay offers SCA compliance by binding payment credentials to an Android device and allowing issuers to delegate the authentication to Google for all subsequent payments on that device.
Find out below how you can comply with SCA requirements for PAN_ONLY scenarios.
Once you have received the payment data from Google, you first need to get the Checkout.com token to encrypt the payment data. You then receive a new token_format in the response to help you identify whether or not subsequent payments using this token already meet SCA requirements.
Google handles the authentication and provides a payload that meets the SCA requirements.
In cases where the Google Pay payment does not require a 3D Secure setup (for example, payments using a CRYPTOGRAM_3DS token), we will handle the non-3DS authorization request.
For in-scope transactions, the payment should use a 3D Secure exemption or be processed as 3D Secure.
After receiving your token, you can authenticate the transaction as follows:
Include the Google Pay token in the payment request body.
To process this transaction as a 3D Secure payment, set the 3ds.enabled field to true as in the request example below.
If the card is enrolled in 3D Secure, you will receive a 202 Success response. This response contains a redirect link for your customer.
We also support the ability to make payments using Google Pay tokens that you have decrypted. To make use of this feature, use the network_token source type and specify the token_type as googlepay. This source type allows you to provide the details about the token, as well as the cryptogram and ECI value obtained from the Google Pay token.
Use the details below to set up your request.
You can find the full list, as well as complete request and response examples, in our API reference.
If the approved field is true, your authorization was successful. If your authorization was not successful, it's possible the payment used an invalid/expired card, or a valid card with an insufficient available balance.
A successful response will include a payment_account_reference value, which is a unique reference to the underlying card for network tokens. If the card scheme provided us with an eci value, it will be included in the response. The value indicates the security level that the card scheme decided to request the payment with.