Google Pay accepteren als merchant

U sluit met Google Pay geen contract zoals met een scheme. U zet het aan via uw PSP of gateway, dient de integratie in via de Google Pay and Wallet console, en het verschijnt als knop in uw checkout. Eronder blijft het een Visa- of Mastercard-transactie, dus uw bestaande acquiring-relatie draagt hem. Daarom is de integratie snel en daarom zijn juist de commerciële vragen de moeite van uw tijd waard.

Bij Mastercard device tokens ligt de aansprakelijkheid al bij de uitgevende bank. Bij Visa geldt de verschuiving ook voor in aanmerking komende device token-transacties, en merchants in Europa zijn automatisch aangemeld in plaats van dat zij zich moesten opgeven. Kwalificerende transacties dragen een eciIndicator met waarde 05, die uw PSP kan uitlezen na ontsleuteling van de betaaltoken. Het praktische gevolg is dat fraudeverliezen op die transacties van u naar de uitgever verschuiven. Heeft niemand in uw organisatie de provider om een rapport over aansprakelijkheidsverschuiving gevraagd, dan is dat een gratis vraag met direct effect op uw chargebackregel.

Op Money20/20 Europe op 4 juni 2026 kondigde Google Google Pay direct checkout aan, waarbij Wallet-betaalgegevens op de eigen checkoutpagina van de merchant komen te staan in plaats van dat de klant naar een Google-omgeving gaat. Het ging eerst live voor geselecteerde merchants op Airwallex, met ondersteuning voor Adyen daarna. Google werkte ook Secure Payment Authentication bij en rapporteerde, op basis van eigen tests, 50% minder authenticatietijd en 3% meer conversie. Daarnaast publiceerde Google in maart 2026 documentatie voor een Universal Commerce Protocol waarbij de checkout op Google-omgevingen plaatsvindt terwijl de merchant seller of record blijft. Bij elkaar is de richting duidelijk: Google positioneert Wallet als de bewaarplaats van betaalgegevens voor online kopen, en merchants zullen moeten besluiten hoeveel van de checkout zij uit handen geven.

Een getokeniseerde credential is opgeslagen waarde in de letterlijke zin. Het is uw vermogen om een terugkerende klant te belasten zonder het opnieuw te vragen. Een punt dat regelmatig onopgemerkt blijft, is dat de token mogelijk niet uw eigendom is.

De vragen zijn kort. Zijn de opgeslagen credentials network tokens die op uw eigen merchant-identiteit staan, of tokens die uw provider uitgeeft en die alleen bij hem gelden? Zou u morgen van provider wisselen, welke opgeslagen credentials gaan dan mee en welke moeten opnieuw worden verzameld? Wie start een tokenmigratie, en wat rekent uw provider ervoor?

Dit is van belang omdat hierin een kostenpost is verwerkt die niet op een tarievenkaart terugkomt. Een provider van wie de tokens niet meereizen heeft de kosten van vertrekken verhoogd zonder ooit een bedrag te noemen, en die kosten landen op de enige regel die geen enkele financiële afdeling begroot: het deel van de terugkerende klanten dat opnieuw een kaart moet invoeren en dat niet doet. Stel de vraag terwijl u nog kiest, niet terwijl u probeert te vertrekken.

Een wallet haalt geen interchange weg, een wallet voegt een laag toe. Wat u betaalt staat in uw PSP-contract, en onder blended pricing verdwijnen de walletlaag en de kaarteconomie eronder in een gemiddelde dat niet meer te ontleden is. Begin met de vraag of u te veel betaalt aan uw PSP, of bekijk wat payment performance-optimalisatie doet met uw authorisation rate en cardmix, want daar verdient of kost een wallet u geld.

Relevante markten: wereldwijd