Google Pay (Google Wallet / Android Pay / GPay) Explained

Google Pay is Google's digital wallet, used to pay with a saved bank card on Android phones, Wear OS watches and inside Chrome on the web. It started life as Android Pay in 2015, became Google Pay in 2018, and merged with Google Wallet in 2022 — in the United States the brand is now Google Wallet, while in the UK and most other markets the wallet itself is still called Google Pay. Behind the scenes it uses tokenisation: the real card number is swapped for a Device Account Number, so what the merchant receives can't be reused by anyone else. Authentication is handled on-device by fingerprint, face, or PIN, which means Google Pay satisfies Strong Customer Authentication under PSD2.

Google Pay (sometimes still called Android Pay by older docs, and rebranded to Google Wallet in the US) does two distinct jobs that often get muddled. In a shop, it's an NFC contactless wallet — you unlock the phone, tap the terminal, and the card emulation chip sends a tokenised payment exactly the way a contactless card would. On the web and in apps, it's a one-tap checkout button that pulls a saved card out of your Google account and feeds it through the Payment Request API or the Google Pay JavaScript SDK. The customer-facing experience looks the same; the plumbing underneath is completely different.

The naming mess: Android Pay, Google Pay, Google Wallet

If you're confused about what to call it, that's because Google has changed the name three times in eight years. Android Pay launched in September 2015 as the contactless half. Google Wallet, which had been around since 2011 as a P2P payments product, was the storage half. In January 2018 Google merged them into a single brand called Google Pay. Then in 2022 it split them again — but only in the US, where the contactless wallet got renamed Google Wallet and "Google Pay" became the umbrella term covering the wallet plus other Google payment features.

In the UK, EU, and most of the rest of the world the wallet is still called Google Pay in everyday language, and Google's own documentation uses both names depending on which page you land on. For merchants integrating the checkout button, the SDK is still called the Google Pay API regardless of region. We'll use "Google Pay" throughout this entry because that's what the UK customer sees on the button.

How Google Pay actually works

When you add a card to Google Pay, Google doesn't store the card number on your phone. It hands the number to the card scheme — Visa, Mastercard, Amex — which issues back a Device Account Number, sometimes called a Device PAN. That token is what lives on your phone. Every time you tap to pay, your device sends the Device PAN plus a one-time cryptogram that's unique to that transaction. The acquiring bank routes the cryptogram back to the scheme, which de-tokenises it and tells the issuing bank to authorise the payment against your real card.

If your phone gets stolen, the Device PAN can be killed without cancelling your real card. That's why most banks treat Google Pay as a lower fraud risk than a manually-keyed card — the merchant never sees the real PAN, and the cryptogram can't be replayed.

The cryptogram in plain English

The cryptogram is a short piece of cryptographic data that proves three things at once: the payment came from a real Google Pay token, the token was authenticated on-device (fingerprint, face, or PIN), and the token hasn't been used before. The scheme network checks the cryptogram against keys it shared with the device when the card was provisioned. If anything's off — wrong key, replayed value, missing authentication flag — the transaction declines at the scheme level, before it even reaches the issuing bank.

This is the same EMV cryptogram model that physical contactless cards use, just generated by software on the phone instead of by the chip on the card. From the issuer's perspective the inbound message looks like a chip-and-PIN transaction, which is why Google Pay payments get the lowest interchange tier and the strongest fraud liability shift in favour of the merchant.

What the phone actually sends to the terminal

The NFC payload from the phone to the terminal contains the Device PAN, an expiry date for the token (which is shorter than the real card's expiry — Google rotates Device PANs periodically), the cryptogram, an Application Transaction Counter, and a flag saying the user authenticated on-device. The terminal handles it exactly like a contactless card transaction. Most modern terminals don't even know it's a phone — they just see EMV contactless data and pass it up the acquiring chain.

Google Pay on the web

Web Google Pay works through a JavaScript API and the standard Payment Request API in the browser. The merchant adds the Google Pay button to their checkout, and when the customer taps it, the browser shows a sheet listing the cards saved to that customer's Google account. The customer picks one, and Google returns a tokenised payment payload to the merchant's payment processor. The processor unwraps the token and runs the transaction.

Most major UK acquirers — Stripe, Adyen, Worldpay, Braintree, The payment gateway — support Google Pay natively, so for a merchant integrating into one of those gateways, turning it on is usually a config flag rather than a build project. The harder part is the merchant requirements: a verified domain, a payment processor that has Google Pay enabled, and a checkout that calls the Google Pay API correctly.

Two payment data formats: ECv2 and direct gateway tokens

The Google Pay API returns the card data in one of two formats depending on how the merchant has integrated. With gateway integration, the token is encrypted with the payment processor's public key and the processor unwraps it on its own infrastructure — Stripe, Adyen and the rest all do this. The merchant never holds anything that can be turned back into a card number, so the integration sits inside SAQ A scope.

With direct integration, the merchant takes the encrypted token themselves, decrypts it using their own scheme-issued keys, and forwards the decrypted PAN to their acquirer. This is rare in the UK because it pulls the merchant into a much larger PCI scope (SAQ D), and the only real reason to use it is if you're a payment service provider yourself. For 99% of UK merchants, gateway integration is the right answer.

Browser support and the Payment Request API

Google Pay on the web works in Chrome, Edge, Safari (on macOS and iOS), Firefox, and Samsung Internet. Chrome and Edge use the Payment Request API natively. Safari falls back to a JavaScript-based flow because Apple keeps the Payment Request API reserved for Apple Pay. The button looks identical to the customer, but under the hood Safari is loading the Google Pay JS SDK directly rather than going through the browser's payment sheet.

This matters for one specific case: if a customer is on iPhone Safari, they'll see both Apple Pay and Google Pay buttons if you've enabled both. Some merchants hide the Google Pay button on iOS Safari because the conversion rate on Apple Pay is higher for that segment. Whether to do that is a CRO call, not a technical constraint.

Google Pay over the phone: where it doesn't work

This is the gap that catches a lot of merchants out. Google Pay is built for in-person tap, app checkout, and web checkout. There's no telephone variant. If a customer rings your contact centre and wants to pay, you can't ask them to "use Google Pay" in any meaningful sense — the wallet has no audio channel, no DTMF route, no API call your agent can trigger from a CRM.

The closest you can get is to send the customer a payment link by SMS or email that opens a hosted checkout page with a Google Pay button on it. The customer clicks the link, taps Google Pay, authenticates with their fingerprint, and the payment completes. The agent stays on the call while it happens. This is the model Paytia's Pay-By-Link feature follows for customers who want to pay during a call without keying card digits.

For customers who do want to key the card number into the phone keypad, Google Pay isn't involved — that's DTMF capture with the digits suppressed before they reach the agent. The two methods coexist in most contact centres because not every caller has Google Pay set up, and not every transaction works through a web link.

Where Google Pay sits with PCI DSS

Because Google Pay payloads are tokenised before they reach the merchant, accepting Google Pay reduces the amount of card data that touches your systems. That doesn't make you PCI-exempt — the token is still treated as account data and the surrounding integration still needs PCI controls — but it does narrow the cardholder data environment compared to taking a manually keyed card number. For a merchant on SAQ A who already takes only tokenised payments through a hosted page, adding Google Pay generally fits inside the existing scope.

PCI DSS v4.0.1 specifics

Under the current standard (v4.0.1, in force since March 2024), the Google Pay integration on the web is treated as an outsourced e-commerce payment channel as long as the merchant uses gateway integration. The merchant has to keep evidence that the Google Pay JS SDK is loaded from Google's domain (not a copy hosted on the merchant's own server), that the page-level script-integrity controls under Requirement 6.4.3 are in place, and that the change-detection requirements under 11.6.1 cover the checkout page. Those are the same controls a merchant already needs for any hosted card form, so for SAQ A merchants the marginal compliance burden of adding Google Pay is small.

For the in-app NFC case, PCI doesn't apply to the consumer device itself — the phone is the customer's, not the merchant's — but the acquiring side still needs to be PCI compliant. That's the acquirer's problem, not the merchant's.

Scheme rules and liability shift

Visa and Mastercard both classify Google Pay transactions as card-present when the payment happens through NFC at a physical terminal, and card-not-present (with token cryptogram) when it happens on the web or in an app. The card-present treatment is the important one: a Google Pay tap at a terminal gets the same liability shift as a chip-and-PIN transaction, meaning the issuer carries the fraud risk if the cryptogram authenticated correctly. For e-commerce, the cryptogram counts as the SCA factor, which means the merchant doesn't need to add 3-D Secure on top.

Strong Customer Authentication and Google Pay

Under PSD2 (UK and EU), most online card payments need two of: something the customer knows, something they have, and something they are. Google Pay handles all of this on the device — possession is the phone itself, the inherence factor is the fingerprint or face scan, and the knowledge factor (PIN) is available as a fallback. The cryptogram the device sends to the merchant proves that on-device authentication happened, so the bank can mark the payment as SCA-compliant without firing a separate 3-D Secure challenge.

For merchants, this means Google Pay checkouts have noticeably higher completion rates than card-with-3DS checkouts, because the customer never sees a redirect to their bank. The flow is: tap button, fingerprint, done. We've seen UK e-commerce merchants pick up 6-10% conversion uplift on the Google Pay path compared to entering a card and going through a 3DS challenge.

What Google Pay won't do

Google Pay is a wallet, not a payment processor. It doesn't acquire transactions, it doesn't settle funds, and it doesn't underwrite fraud. All it does is present a saved card to a merchant in a tokenised, SCA-authenticated form — every other part of the payment journey runs through the same banks and schemes as a normal card payment. There's also no issuer fee in the UK or most other markets. The customer pays the same as they would with the underlying card, and the merchant pays the same interchange and scheme fees they'd pay for a contactless or CNP card transaction respectively.

One real limitation: Google Pay only works for cards from supported issuers. Most UK high-street banks and challenger banks support it, but a handful of corporate cards and prepaid cards still don't. If you're rolling out Google Pay as a checkout option, the practical answer is to leave card-not-present card entry as a fallback for customers whose card isn't enrolled.

Edge cases and failure modes

A few things to plan for if you're adding Google Pay to checkout. Rotated Device PANs: Google can re-issue the token on the device at any time, which means a saved-card-for-later flow needs to use the scheme's network token (held by the acquirer) rather than caching the Device PAN itself. Travel and SIM changes: Google Pay works in any country the underlying card is enabled for, but customers occasionally find their wallet locked out after a SIM swap until they re-authenticate, which can break a transaction mid-checkout. Refunds: refunds go back to the underlying real card, not to the Device PAN, so the customer sees the credit in their statement under the original card identity. That's fine for most use cases but trips up reconciliation logic that expects symmetric token IDs on the refund leg.

The most common failure we see in production is an unverified domain. Google Pay refuses to render the button on any domain that isn't pre-registered in the Google Pay Business Console. Merchants who add a new subdomain (checkout.example.com after launching on www.example.com) and forget to register it get a silent failure with no button rendered — the JS SDK just won't initialise. Always check domain registration first when the button stops appearing.

Comparing Google Pay to other wallet options

The other major mobile wallet in the UK market is Apple Pay, which works on the same EMV tokenisation principles but only runs on Apple devices. Most merchants enable both, because the audiences barely overlap — iPhone customers use Apple Pay, Android customers use Google Pay, and the cost of adding the second button after you've integrated the first is close to zero on every major UK gateway.

There are also bank-specific wallets (Samsung Wallet, Barclays' app payments, Monzo Plus tap-to-pay) that work on similar plumbing but with much smaller adoption. For an e-commerce checkout, supporting Apple Pay + Google Pay covers ~95% of the wallet market in the UK; adding more wallet buttons rarely justifies the checkout clutter.

Then there's the broader bank-transfer category — Open Banking pay-by-bank flows that bypass card rails entirely. Those are a separate decision from whether to add Google Pay; they tend to suit higher-value B2B payments where the interchange saving matters, whereas Google Pay tends to win on consumer e-commerce where speed and SCA compliance matter more.

What it costs the merchant

Google doesn't charge merchants a per-transaction fee for Google Pay. The processor does — but at the same rate they'd charge for the underlying card. A Visa debit card on Google Pay costs the merchant the same as a Visa debit card entered manually, give or take the lower fraud reserves a processor might apply because of the tokenisation and SCA proof. Some processors actually price Google Pay transactions slightly cheaper than equivalent card-not-present payments because the cryptogram counts as SCA evidence and reduces their underwriting risk.

The integration cost is usually a few hours of front-end work to add the button and call the API, plus testing. There's no certification process the merchant has to go through beyond domain verification in the Google Pay Business Console.

How Paytia uses Google Pay

Paytia is a contact-centre payment platform, not a checkout button, so we don't render the Google Pay sheet on a merchant's website. Where Google Pay fits into our world is on the Pay-By-Link path: when a customer rings in and would rather not key card digits over the phone, our agents can send a one-tap link to a Paytia-hosted payment page. That page renders Google Pay (and Apple Pay) as options, the customer authenticates on-device, and the payment lands directly with the merchant's gateway. The agent stays on the call, the merchant never sees the card number, and the transaction completes with full SCA evidence. For callers who'd rather key their card into the keypad, our DTMF masking capture runs in parallel — the two methods cover the whole call-centre payment audience.

Frequently asked questions

Is Google Pay the same as Google Wallet?

In the US, Google Wallet is the wallet app and Google Pay is the broader payments brand. Everywhere else, the wallet is still called Google Pay. The underlying technology is identical — same Device PAN tokenisation, same cryptogram model, same SCA handling.

Does Google Pay reduce my PCI scope?

It can. If you're already on SAQ A using a hosted checkout, Google Pay sits inside that same scope and doesn't expand it. If you currently take card numbers directly into your own systems, adding Google Pay alongside doesn't shrink your scope — you'd need to move the card-entry path to a hosted form too.

Do I need 3-D Secure on top of Google Pay?

No. The cryptogram Google Pay sends already contains an SCA proof, and UK and EU issuers accept it as fulfilling PSD2 requirements without a separate 3DS challenge. Some acquirers still run a soft 3DS check on high-value transactions as a fraud control, but it doesn't show the customer a challenge screen.

Can I take Google Pay over the phone?

Not directly — there's no audio or DTMF channel for Google Pay. The workaround is to send a payment link by SMS or email during the call. The customer taps the link, completes Google Pay in their browser, and the agent stays on the line until the payment confirms.

Why is the Google Pay button not appearing on my checkout?

The most common cause is that the domain isn't registered in the Google Pay Business Console. The second most common is that the customer's device or browser doesn't have any cards saved to it — the button only renders when at least one supported card is available. Less common: ad-blockers occasionally block the Google Pay JS SDK on the merchant's CDN.

Do refunds go back to Google Pay or to the original card?

Refunds settle to the underlying real card, not to the Device PAN. The customer sees the credit in the same card statement they'd see for any other refund. For reconciliation purposes the refund ID will tie back to the original Google Pay transaction via the gateway, not via the token.

What happens to a Google Pay transaction if the customer's phone is offline?

For in-store NFC, Google Pay can complete a small number of transactions while offline because the cryptogram is generated on-device and validated later. For web and in-app payments, the device needs to be online — both to fetch the user's saved cards and to send the payload to Google's servers. There's no offline checkout option for e-commerce Google Pay.

Does Google Pay work for recurring or subscription payments?

Yes, via the scheme network token rather than the Device PAN. When the customer makes the first Google Pay payment, the acquirer can ask the scheme to issue a network token that's stable across rebills. Subsequent charges go through that token without needing Google Pay to re-authenticate each time — though the customer can revoke the token from their Google account if they want to stop the subscription.