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 issuers

As 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" and pass the transaction amount (totalPrice: Android, Web) for each Google Pay API request. If amounts are hard coded or set to $0, those transactions don't qualify for liability shift.

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:

  1. Sign in to the Google Pay & Wallet Console.
  2. Go to the Google Pay API tab.
  3. Go to the Settings tab.
  4. 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 Transfer
  • 5967: Direct Marketing – Inbound Teleservices Merchant
  • 6051: 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 Repayment
  • 6540: Non-Financial Institutions – Stored Value Card Purchase/Load
  • 7801: 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.

I use a major PSP to manage all risk and Strong Customer Authentication. What should I know about GPay?

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.
How can merchants promote Google Pay acceptance in their apps and sites to their users?
To highlight support for Google Pay, make sure to use the assets available in our Android and Web brand guidelines.
If you have an Android integration, you can note in the Play Store description that you now support Google Pay. For web integrations, you can directly add a description to the merchant website.
Can ecommerce platforms support Google Pay?
Yes, Google Pay API supports onboarding ecommerce platforms. Payment processor, gateway, or ecommerce platform partners that host a checkout page on behalf of their merchants can use Google Pay’s hosted checkout feature.
Which payment providers support Google Pay?
To find a list of processors that support Google Pay, see our Google Pay processors list.
What countries and regions are supported for Google Pay?
Take a look at our list of supported countries that use Google Pay for payments online or in apps.
What countries and regions are supported for Google Pay tokens (CRYPTOGRAM_3DS)?
See our Find supported payment methods for in-store and contactless purchases page for a list of countries and the banks in each that support Google Pay tokens (CRYPTOGRAM_3DS). Both supported and unsupported cards are listed.
What's the difference between Google Play In-app Billing and the Google Pay API?
Google Play developers that sell digital goods and services on Android apps must use Google Play In-app Billing, as specified in the Play Developer Policy Center. Examples of In-app Billing include virtual game products, app functionality or content, and cloud software products. See the Google Play Billing overview page to learn more about In-app Billing.
When used in apps, the Google Pay API is only available for physical products and services.
Does Google Pay charge any fees?
Google Pay doesn't additionally charge users, merchants, and developers additional fees to use the Google Pay API for payments. Merchants, specifically, continue to pay processing fees to their payment processor.
What does Google do to validate credentials and prevent fraud?
All cards added to Google go through a verification authorization to validate card details, which include the card verification code (CVC). Google also runs a proprietary risk engine based on instrument data, Google Account profiles, purchase history, locations, and device information. Merchants, however, must continue to use their current fraud and risk assessment tools with Google Pay transactions.
Does the Google Pay API integration work in WebViews?
For Android apps which use WebViews, you must invoke platform specific Android Google Pay APIs. See Binding JavaScript code to Android code for examples. Note that the Google Pay API JavaScript library that is used for web applications does not work inside WebViews.