Frequently Asked Questions
This page provides general information and FAQ about Google Pay API.
About Google Pay API
Google Pay enables effortless checkouts for your app and website. With the Google Pay API, your customers can use the cards saved to their Google Accounts for seamless checkout within your apps and sites.
How to get support
Register with the Google Pay & Wallet Console and select Contact support. We can help you troubleshoot your integrations. Additionally, reference our Android troubleshooting guide and Web troubleshooting guide to self-debug your integration.
Supported features
The Google Pay API has several supported features.
Supported forms of payment
The Google Pay API may return cards or network tokens.
Recurring billing and subscriptions
Support for recurring billing is tied to the payment method returned in the Google Pay API response. Both tokenized cards and cards on file can be used for recurring billing. To process recurring billing, the merchant doesn't have to call our API at a cadence. Rather, the payment credential is stored on the merchant side for recurring payments. The merchant uses their payment gateway APIs to manage recurring billing.
Google Pay supports recurring payments if the following statements are true:
- Merchants comply with network rules, such as merchant-initiated transactions.
- Terms of payment are disclosed and accepted by the user within the merchant's buyflow.
We also support recurring billing with variable amounts. For example, monthly phone bills for mobile carriers are supported. To get more information, merchants must contact their payment gateway representative.
Auto-reload or "top-up"
To process an auto-reload charge for the same cost, the merchant doesn't have to call our API each time. The payment credential is stored on the merchant side and reused. To get more information, merchants must contact their payment gateway representative.
Chargebacks
Merchants can handle transaction reversals for cancellations, reimbursements, or disputes in the manner that they currently handle chargebacks for other forms of payment. To get more information, merchants must contact their processors representative.
Donation collection
Approved nonprofit organizations (NPOs) can integrate the Google Pay API to collect donations, if, and only if, they provide documentation to prove, certify, and validate their nonprofit status. For example, US NPOs must provide valid 501(c)3 status proof from the IRS in order to qualify.
Liability shift
Payment liability shift
Google Pay supports liability shift to issuers for qualified facilitated transactions that use
Mastercard and Visa Android device tokens (CRYPTOGTAM_3DS
).
Liability shift features are made available to Google Pay API merchants through Visa and Mastercard programs and are subject to Visa and Mastercard rules. Google Pay supports these features and makes them available to merchants, but Google isn't responsible for determinations of fraud, program rules, eligibility requirements, or losses or errors as a result of enabling or disabling these features.
For Visa, merchants need to opt-in for "Fraud liability protection for Visa device tokens". To do so, log in to the Google Pay & Wallet Console, access the Google Pay API tab, and toggle the switch.
European merchants are automatically opted-in and continue to be covered by a Visa exception that grants liability protection for eligible transactions that involve cards issued by European issuersAs long as the appropriate Android or Web best practices are followed, no adjustments are required to your existing Google Pay API integrations for qualified liability shift.
Transaction liability is determined during facilitation, but it can change during transaction processing.
Liability shift for Visa device tokens
Merchants can opt-in to the "Fraud liability protection for Visa device tokens" option, and then all qualified transactions that are facilitated with Visa device tokens will benefit from liability shift for fraudulent transactions.
The qualified transactions for "Fraud liability protection for Visa device tokens" are marked and visible to Payment Service Providers (PSPs) and merchants with direct integration. The liability shift status isn't visible to merchants that use the gateway integration.
This option may cause a change in the user flow outside of Europe because users will be asked to unlock the device to complete the transaction. For EEA transactions where SCA is mandated, there will be no changes in the user flow.
Not all transactions qualify for "Fraud liability protection for Visa device tokens".
Be sure to set a price for all transactions. Google Pay API can't qualify transactions where
totalPrice
(Android,
Web) is unknown or set to
zero. Setting the correct price will reduce the chance of confusing your customers, because the
totalPrice
can be displayed to users in the payment sheet.
We are excited to bring liability shift for Visa device tokens in the coming months to our
merchants and Web integrations that use callbackIntents
, like
Authorize Payments,
Dynamic Price Updates, and
Promo Codes.
What is liability shift?
A change of responsibility in covering the losses from fraudulent transactions. The responsibility changes from the merchant to the issuing bank, or vice-versa.
What must merchants do to ensure that liability shift is applied?
Merchants need to opt-in for "Fraud liability protection for Visa device tokens", pass the
transaction amount (totalPrice
:
Android,
Web) and transaction currency
code (currencyCode
:
Android,
Web)
for each Google Pay API request.
If amounts are hard coded or set to $0
or currency codes don't match the currency
code used in payment authorization, those transactions don't qualify for liability shift and might
be declined.
For direct integrations, merchants need to ensure that the ECI value (Android, Web) is passed to the processor. Refer to your payment gateway documentation to ensure that the correct field for the ECI value is populated in the payment request.
For merchants with gateway integrations, Payment Service Providers (PSP) get the
eciIndicator
(Android,
Web) value and
need to pass it down the processing flow. Merchants need to check with their payment gateway to
make sure that ECI values aren't hard coded or altered.
The card networks qualify the transaction for liability shift during facilitation, but transactions that qualify for liability shift can be downgraded by the network during transaction authorization processing.
Transactions that are facilitated by Google Pay Web integrations with optional features that use
callbackIntents
, like
Authorize Payments,
Dynamic Price Updates, and
Promo Codes, can't qualify for Visa
liability shift.
How to opt-in for Visa liability shift
To enable "Visa liability shift," do the following:
- Sign in to the Google Pay & Wallet Console.
- Go to the Google Pay API tab.
- Go to the Settings tab.
- Enable Fraud liability protection for Visa device tokens.
If I use Google Pay API on a hosted checkout, how can I enable Visa liability shift?
Google Pay API hosted checkout can be provided by Payment Service Providers (PSP) and Platform partners. Please contact the hosted checkout provider and ask to enable Visa liability shift.
Why can't transactions that are facilitated by
Google Pay API integrations use callbackintents
to get Visa liability shift?
Google Pay API web integration offers optional features using callbackintents
like
Authorize Payments,
Dynamic Price Updates, and
Promo Codes that aren't supported on mWeb
(websites with Google Pay API Web integration, loaded on an Android device using a Chrome
browser).
We are excited to bring liability shift for Visa device tokens in the coming months to our
merchants and Web integrations that leverage callbackintents
.
How can I (as a merchant) tell where liability shift is applied?
The liability shift status isn't visible to merchants that use gateway integration. Please check with your Payment Service Provider to see whether they can provide a liability shift report.
Merchants with a direct integration
(Android,
Web) will be able to see this through
the ECI values that are returned in the encrypted message, eciIndicator
(Android,
Web).
Are there specific scenarios where this liability shift doesn't apply?
Liability shift is globally available for device tokens transactions with Mastercard and Visa, and are subject to rules and changes by the networks.
Mastercard device tokens don't have any exclusions.
Currently Visa in the US excludes the following high-risk MCCs:
4829
: Money Transfer5967
: Direct Marketing – Inbound Teleservices Merchant6051
: Non-Financial Institutions – Foreign Currency, Non-Fiat Currency (for example: Cryptocurrency), Money Orders (Not Money Transfer), Account Funding (not Stored Value Load), Travelers Cheques, and Debt Repayment6540
: Non-Financial Institutions – Stored Value Card Purchase/Load7801
: Government Licensed On-Line Casinos (On-Line Gambling) (US Region only)7802
: Government-Licensed Horse/Dog Racing (US Region only)7995
: Betting, including Lottery Tickets, Casino Gaming Chips, Off-Track Betting, Wagers at Race Tracks and games of chance to win prizes of monetary value
Terms and Policies
Google Pay API Terms of Service
All merchants must agree to and adhere to the Google Pay API Terms of Service.
Google Pay API Acceptable Use Policy
All merchants must agree to and adhere to the Google Pay API Acceptable Use Policy.
Gambling Policy
Our policy on Gambling is defined in our Google Pay API Acceptable Use Policy.
Our policy on gambling may change from time to time. All submissions are subject to review and approval.
We currently accept gambling integrations from companies based in the following countries: Australia, Canada, France, Germany, Ireland, Italy, Japan, the Netherlands, Spain, Sweden, and the United Kingdom. We might choose at a later date to expand support beyond the current level.
Gaining production access to the Google Pay API for gambling integrations requires completing a series of prerequisites:
- If you have an Android-only gambling integration based in one of the above countries, you must adhere to Google Play's gambling policy and onboard with Google Play's vetting process first. We can then evaluate your Android-only integration for production access to the Google Pay API.
- If you have a Web-only gambling integration based in one of the above countries, you must submit an authorized license to prove your eligibility to provide gambling services in-country during your onboarding process with the Google Pay API. We can then evaluate your Web-only integration for production access to the Google Pay API.
- If you have an Android and Web gambling integration in one of the above countries, you must adhere to Google Play's gambling policy and onboard with Google Play's vetting process first. We can then evaluate your Android and Web integrations for production access to the Google Pay API.
If you expand the Google Pay API into a country that you were not previously approved for, contact us to gain approval for the expansion. Please note that you will need to provide an authorized gambling license for each country in which you plan to offer gambling-related services. We do not allow the Google Pay API to be used for gambling services where they are aimed / addressed to individuals who are underage or are otherwise forbidden from gambling according to local laws.
Healthcare Policy
Our policy on Healthcare is defined in the Google Pay API Acceptable Use Policy.
Be prepared to share a relevant license when onboarding to validate your Healthcare use case. All submissions are subject to review and approval.
Financial Services Policy
Our policy on Financial Services is defined in the Google Pay API Acceptable Use Policy.
Be prepared to share a relevant license when onboarding to validate your Financial Services use case. All submissions are subject to review and approval.
General FAQ
The following FAQ apply to merchants.
The Google Pay API returns payment methods in a signed and encrypted payload. The returned payment methods consist of either PAN or tokenized cards made of device PAN (DPAN) and cryptograms.
Tokenized card payloads are processed without additional step-up or challenge.
Card payloads that consist of PAN require 3D Secure through an in-house or a PSP-provided solution.
If your PSP manages all the risk and SCA logic, make sure that your Google Pay API integration includes the following properties:
merchantInfo.merchantName
(Android, Web): The merchant name is rendered in the payment sheet.transactionInfo.countryCode
(Android, Web): This indicates where the transaction processes. You must specify the acquirer bank country.transactionInfo.totalPrice
(Android, Web): The total monetary value of the transaction with an optional decimal precision of two decimal places.
(CRYPTOGRAM_3DS)
. Both supported and unsupported cards are listed.