Accepting Google Pay as a merchant

Google Pay lets a customer check out with a card stored in their Google account, on Android, in Chrome and in apps. The card number never reaches you: the transaction carries a device-specific token rather than the underlying card number. For a merchant the interesting part is not the tap. It is that tokenised wallet traffic behaves differently from raw card traffic on fraud liability, on authorisation rates and on recurring billing continuity, and each of those has a number attached to it.

How to accept Google Pay as a merchant

You do not contract with Google Pay as you would with a scheme. You enable it through your PSP or gateway, submit the integration in the Google Pay and Wallet console, and it appears as a button in your checkout. Underneath, it is still a Visa or Mastercard transaction, so your existing acquiring relationship carries it. That is why the integration is quick and why the commercial questions are the ones worth spending time on instead.

Google Pay payment gateway and PSP support

Every significant gateway supports Google Pay, so support is not a differentiator. What separates providers is whether they surface the wallet-specific signals that make the method worth having. Two examples that carry real money: whether your PSP reports which transactions qualified for fraud liability shift, and whether they pass through token lifecycle notifications. A provider that supports the button but returns none of the surrounding data has given you the checkout convenience and none of the economics.

Liability

Fraud liability shift on device tokens

For Mastercard device tokens the liability already sits with the issuing bank. For Visa, eligible device token transactions also benefit from liability shift, and merchants in Europe were auto-enrolled rather than having to opt in. Qualifying transactions carry an eciIndicator value of 05, which your PSP can read after decrypting the payment token. The practical consequence is that fraud losses on those transactions move from you to the issuer. If nobody in your business has asked the provider for a report on liability-shift-eligible volume, that is a free ask with a direct effect on your chargeback line.

Lifecycle

Recurring payments and token lifecycle notifications

Google now provides lifecycle notifications for Google Pay payment tokens when the underlying credential changes, delivered to you or your PSP with the updated token state. For any subscription or merchant-initiated billing model this is a churn instrument rather than a technical detail. Involuntary churn from expired or reissued cards is one of the quietest revenue leaks in a subscription business, and being told a credential has changed before the next billing cycle is the difference between a proactive email and a failed payment.

What changed in 2026: direct checkout and payment authentication

At Money20/20 Europe on 4 June 2026 Google announced Google Pay direct checkout, which places Wallet payment credentials on the merchant’s own checkout page rather than moving the shopper to a Google surface. It went live first for selected merchants on Airwallex with Adyen support following. Google also updated its Secure Payment Authentication feature and reported, on its own testing, a 50% reduction in authentication time and a 3% increase in conversion. Separately, Google published documentation in March 2026 for a Universal Commerce Protocol in which checkout happens on Google surfaces while the merchant remains seller of record. Taken together the direction is clear: Google is positioning Wallet as the credential store for online purchasing, and merchants will be asked to decide how much of the checkout they hand over.

Control

What you keep when the checkout moves

Every arrangement that moves the payment step closer to a wallet moves something else with it. The question is not whether that is good or bad in the abstract. It is which specific things you are handing over and which you are keeping.

Three of them are worth naming before anything is signed. Who is seller of record, because that decides whose contract the customer has, who handles the refund and whose brand carries the complaint. What data comes back, because a checkout hosted elsewhere can return an order and a status and nothing else, and the analysis you run on decline reasons, card type and issuer goes with it. And whether your right to steer survives, which Article 62(3) of PSD2 protects: a payment service provider may not prevent you from steering a payer towards a given instrument or from offering a reduction for using it.

The pattern is familiar from every other layer that has been placed between a merchant and a customer. Convenience arrives first, the data question arrives second, and the pricing question arrives once the share is large enough that moving has become expensive. Ask all three at the start, while your share is small and your leverage is at its highest.

Portability

Whose token is it

A tokenised credential is stored value in the literal sense. It is your ability to bill a returning customer without asking them again. What is easy to miss is that the token may not be yours.

The questions are short. Are the stored credentials network tokens registered against your own merchant identity, or tokens issued by and scoped to your provider? If you changed provider tomorrow, which stored credentials would travel with you and which would have to be collected again? Who initiates a token migration, and what does your provider charge for it?

This matters because it prices something that never appears on a rate card. A provider whose tokens do not travel has raised the cost of leaving without ever quoting a number, and that cost lands on the one line no finance team forecasts: the share of returning customers who are asked to enter a card again and do not. Ask while you are still choosing, not while you are trying to leave.

Which payment provider supports Google Pay for merchants in Europe?

Adyen, Checkout.com, Stripe, Buckaroo, Trust Payments, Datatrans and PAYONE all document Google Pay, among others, as does every other provider of consequence, which makes it the wrong first question. The better one is what your provider charges on wallet volume, whether the card cost underneath is passed through or blended, whether they report liability shift eligibility, and whether they are in the first wave for direct checkout. Those four answers differ far more between providers than the presence of the button does.

Reviewing what Google Pay costs you

A wallet does not remove interchange, it adds a layer. What you pay is set in your PSP contract, and under blended pricing the wallet layer and the card economics beneath it disappear into a single average that cannot be decomposed. Start by establishing whether you are overpaying your PSP, or look at what payment performance optimisation does to authorisation rate and cardmix, which is where a wallet earns or costs you money.

Relevant markets: global