How does Google Pay work for online payments?
Google Pay hands the merchant’s provider a card from the shopper’s Google Account. The shopper taps the Google Pay button, picks a card in the payment sheet and confirms. What the provider receives depends on how the card is stored, and Google’s API names two authentication methods:
- CRYPTOGRAM_3DS: cards stored as Android device tokens. The payment data includes a 3-D Secure cryptogram generated on the device. Checkout.com describes this as binding the card to an Android device and letting issuers delegate authentication to Google.
- PAN_ONLY: cards stored on file with the shopper’s Google Account. The payment data includes the card number with its expiry month and year. Checkout.com says these credentials are not bound to a device, which is typical on desktop and on non-Android mobile browsers.
Stripe adds a third case: a card a shopper selects through Google Pay on a site or app that itself pays with Google Pay is saved as an e-commerce token, and Stripe says neither liability shift nor 3-D Secure is supported for those at this time.
The card reaches the provider encrypted. With the PAYMENT_GATEWAY tokenisation type, the merchant names its payment provider and its gateway merchant ID in the request, and Google encrypts the selected card for processing by that provider. With the DIRECT type, the merchant decrypts the response on its own servers, which Google says requires PCI DSS compliance validated by a Qualified Security Assessor; third parties that supply gateway or processing services on behalf of merchants are not eligible. The provider then authorises the payment on the card network like any card payment, and refunds and disputes follow the card’s rules. Stripe supports full and partial refunds and says the refund and dispute processes are the same as for cards.
Google Pay also supports merchant-initiated payments. Its API has recurring, deferred and automatic reload transaction types, each described by its own transaction info object in the request, and exactly one per request. A tokenUpdateUrl lets Google send token lifecycle notifications, such as a deactivated or deleted token or a new card number suffix, to an HTTPS endpoint. As the name says, the merchant initiates these later charges itself, through its provider. Stripe lists recurring payments as supported for Google Pay.
Where and how do shoppers use Google Pay?
Shoppers use Google Pay on Android phones and in Android apps, and in web browsers on desktop and other mobile devices. Stripe notes it can offer any credit or debit card saved to the shopper’s Google Account, including cards added through Google Play, YouTube, Chrome or an Android device. Google’s list of countries and regions where shoppers can pay online or in apps includes the United States, Canada, the United Kingdom, Germany, France, Spain, Italy, the Netherlands, Poland, Kazakhstan, Brazil, Mexico, Saudi Arabia and the United Arab Emirates. It also covers the rest of Europe, the Gulf states, North Africa, much of sub-Saharan Africa including Nigeria, Kenya and South Africa, Latin America, and Central Asia and the Caucasus. Turkey is not on it. Google notes that some features are only available in certain countries or regions and on certain devices.
The card networks Google Pay accepts are American Express, Discover, Interac, JCB, Mastercard and Visa. Domestic schemes outside that list need their own route, such as the card form or a local method.
Stripe notes that in Android apps, digital products, content and subscriptions sold in the United States or the EEA can be paid through a third-party processor; for other cases it points to Google Play’s developer terms on which purchases must use Google Play billing.
What rules and costs should merchants know?
SCA depends on the card type. Google’s SCA guide says merchants processing in the EEA must comply with strong customer authentication. Checkout.com says that for CRYPTOGRAM_3DS, Google handles the authentication and provides a payload that meets SCA, and these credentials receive liability shift by default. For PAN_ONLY, a payment in SCA scope must use a 3-D Secure exemption or be processed with 3-D Secure, and 3-D Secure is also what gives liability shift. Google asks merchants to request assurance details and, when the cardholder was not authenticated, to apply risk checks and step-up, including 3-D Secure where applicable. Both Checkout.com and Stripe say liability shift on Visa Google Pay payments needs an opt-in to Fraud Liability Protection for Visa Device Tokens in the Google Pay and Wallet Console, which Stripe handles itself on its hosted products. Card schemes can still downgrade liability shift during authorisation.
The country code matters. Google says merchants processing in the EEA or another SCA country must send the country code of the acquiring bank, not of the shopper.
Card rules still apply. A Google Pay payment is a card payment, so interchange and scheme fees follow the card. In the EU, Regulation (EU) 2015/751 caps interchange at 0.2% of the transaction value for consumer debit cards and 0.3% for consumer credit cards, and Member States may set lower caps for domestic credit card payments. The European Commission says PSD2 bans surcharging wherever those caps apply, for domestic and cross-border payments, which it estimated at about 95% of card payments in the EU. In the UK, regulation 6A of the Consumer Rights (Payment Surcharges) Regulations 2012 bars a payee from charging a fee for payment by consumer cards.
Web setup has its own steps. To go live directly, a merchant creates a profile in the Google Pay and Wallet Console, accepts Google’s Terms of Service and Acceptable Use Policy, adds each website by its top-level domain, chooses a gateway or direct integration and submits screenshots of the checkout for Google’s review. Google asks sites with more than 50 fully qualified domains to contact support first. Through Stripe, every domain and subdomain that shows the button, including www, must be registered, and the page must be served over HTTPS with a domain-validated TLS certificate.
How would Omno handle Google Pay?
- One checkout: Google Pay would appear in the Omno hosted checkout next to cards, Apple Pay, local methods and crypto, on browsers and devices where it is available. Merchants with their own payment screens would use Direct Links on their own buttons.
- Routing rules: The merchant would set rules by country, currency or amount that send Google Pay payments to a connected provider that supports Google Pay and is named as the gateway. Omno connects through those providers; it is not an acquirer and does not hold funds.
- Cascading: In the hosted checkout, if the chosen provider is unavailable or rejects the request, the payment would move to the next provider in the rule until one accepts. Because Google encrypts the card for the named gateway, the providers in a Google Pay rule need to be ones that can process that payload.
- Status: The final result would reach the merchant by webhook.
What should merchants plan for?
Handle both card types. Device tokens usually carry their own authentication, while PAN_ONLY cards from desktop browsers need 3-D Secure or an exemption in SCA scope. Ask each provider how it treats each type.
Switch on Visa liability shift. Without the Fraud Liability Protection opt-in in the console, Visa Google Pay payments outside a provider’s hosted pages may not get liability shift.
Register every domain. Each subdomain that shows the button, including www, needs to be registered, and Google reviews screenshots before a direct integration goes live.
Keep other ways to pay. Turkey is not on Google’s list, cards on domestic schemes outside Google’s network list cannot be used, and Stripe says e-commerce tokens support neither 3-D Secure nor liability shift.
Plan for renewals. For subscriptions, use the recurring transaction type, receive token lifecycle notifications, and charge each renewal through the provider.