Accepting 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.

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.

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.

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.

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