{"id":251496,"date":"2024-04-02T15:48:53","date_gmt":"2024-04-02T13:48:53","guid":{"rendered":"https:\/\/www.ecomstream.eu\/betaalmethoden\/google-pay\/"},"modified":"2026-08-30T11:12:17","modified_gmt":"2026-08-30T09:12:17","slug":"google-pay","status":"publish","type":"page","link":"https:\/\/www.ecomstream.eu\/nl\/betaalmethoden\/google-pay\/","title":{"rendered":"Google Pay"},"content":{"rendered":"\n\n
\n
\n
\n
\n
\n
\n

Google Pay accepteren als merchant<\/h1><\/div>\n

Met Google Pay rekent een klant af met een kaart die in zijn Google-account staat, op Android, in Chrome en in apps. Het kaartnummer bereikt u nooit: de transactie draagt een apparaatspecifieke token in plaats van het onderliggende kaartnummer. Voor een merchant ligt het belang niet bij de betaalhandeling in de checkout. Het zit erin dat getokeniseerd walletverkeer zich anders gedraagt dan ruw kaartverkeer op fraudeaansprakelijkheid, op de authorisation rate en op de continu\u00efteit van terugkerende incasso, en aan alle drie hangt een bedrag.<\/p><\/div>\n <\/div>\n<\/section>\n<\/div>\n<\/div><\/div>\n<\/div>\n<\/div>\n<\/div>\n

\n
\n
\n
\n
\n
\n

Google Pay accepteren als merchant<\/h2>\n
<\/div>\n

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\u00eble vragen de moeite van uw tijd waard.<\/p><\/div>\n <\/div>\n<\/section>\n<\/div>\n<\/div><\/div>\n<\/div>\n<\/div>\n<\/div>\n

\n
\n
\n
\n
\n
\n

Google Pay payment gateway en PSP-ondersteuning<\/h2>\n
<\/div>\n

Iedere gateway van betekenis ondersteunt Google Pay, dus ondersteuning is geen onderscheid. Wat providers onderscheidt is of zij de walletspecifieke signalen teruggeven die de methode de moeite waard maken. Twee voorbeelden met echt geld erachter: of uw PSP rapporteert welke transacties in aanmerking kwamen voor de verschuiving van fraudeaansprakelijkheid, en of zij token lifecycle-notificaties doorgeven. Een provider die de knop ondersteunt zonder de omringende data terug te geven, biedt gemak in de checkout maar geen inzicht in de onderliggende kostenstructuur.<\/p><\/div>\n <\/div>\n<\/section>\n<\/div>\n<\/div><\/div>\n<\/div>\n<\/div>\n<\/div>\n

\n
\n
\n
\n
\n
\n

Aansprakelijkheid<\/p>\n

Verschuiving van fraudeaansprakelijkheid bij device tokens<\/h2>\n
<\/div>\n

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.<\/p><\/div>\n <\/div>\n<\/section>\n<\/div>\n<\/div><\/div>\n<\/div>\n<\/div>\n<\/div>\n

\n
\n
\n
\n
\n
\n

Levenscyclus<\/p>\n

Terugkerende betalingen en token lifecycle-notificaties<\/h2>\n
<\/div>\n

Google levert nu lifecycle-notificaties voor Google Pay betaaltokens wanneer de onderliggende credential wijzigt, met de bijgewerkte tokenstatus, aan u of aan uw PSP. Voor elk abonnement of merchant-initiated model is dat geen technisch detail maar een churn-instrument. Onvrijwillige churn door verlopen of opnieuw uitgegeven kaarten is een van de stilste omzetlekken in een abonnementsbedrijf, en horen dat een credential is gewijzigd voor de volgende incassoronde is het verschil tussen een proactieve mail en een mislukte betaling.<\/p><\/div>\n <\/div>\n<\/section>\n<\/div>\n<\/div><\/div>\n<\/div>\n<\/div>\n<\/div>\n

\n
\n
\n
\n
\n
\n

Wat er in 2026 veranderde: direct checkout en payment authentication<\/h2>\n
<\/div>\n

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.<\/p><\/div>\n <\/div>\n<\/section>\n<\/div>\n<\/div><\/div>\n<\/div>\n<\/div>\n<\/div>\n

\n
\n
\n
\n
\n
\n

Regie<\/p>\n

Wat u overhoudt als de checkout verhuist<\/h2>\n
<\/div>\n

Elke constructie die de betaalstap dichter naar een wallet trekt, neemt iets anders mee. De vraag is niet of dat in het algemeen goed of slecht is. De vraag is welke dingen u precies weggeeft en welke u houdt.<\/p>

Drie daarvan verdienen het om benoemd te worden voordat er iets wordt getekend. Wie is seller of record, want dat bepaalt met wie de klant een contract heeft, wie de refund afhandelt en op wiens merk de klacht landt. Welke data komt terug, want een checkout die elders wordt gehost kan een order en een status teruggeven en verder niets, en de analyse die u draait op weigeringsredenen, kaarttype en uitgever verdwijnt daarmee. En blijft uw sturingsrecht overeind, dat artikel 62(3) van PSD2 beschermt: een betaaldienstverlener mag u niet beletten een betaler naar een bepaald instrument te sturen of korting te geven op het gebruik ervan.<\/p>

Het patroon is bekend van elke andere laag die tussen een merchant en een klant is gezet. Het gemak komt als eerste, de datavraag als tweede en de prijsvraag zodra het aandeel dusdanig groot is dat overstappen kostbaar is geworden. Stel alle drie aan het begin, wanneer uw aandeel klein is en uw positie het sterkst.<\/p><\/div>\n <\/div>\n<\/section>\n<\/div>\n<\/div><\/div>\n<\/div>\n<\/div>\n<\/div>\n

\n
\n
\n
\n
\n
\n

Overdraagbaarheid<\/p>\n

Van wie is die token eigenlijk<\/h2>\n
<\/div>\n

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.<\/p>

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?<\/p>

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\u00eble 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.<\/p><\/div>\n <\/div>\n<\/section>\n<\/div>\n<\/div><\/div>\n<\/div>\n<\/div>\n<\/div>\n

\n
\n
\n
\n
\n
\n

Welke payment provider ondersteunt Google Pay voor merchants in Europa?<\/h2>\n
<\/div>\n

Google Pay wordt onder meer gedocumenteerd door Adyen, Checkout.com, Stripe, Buckaroo, Trust Payments, Datatrans en PAYONE, en feitelijk door iedere provider van betekenis, en daarmee is het de verkeerde eerste vraag. De betere vraag is wat uw provider op walletvolume rekent, of de kaartkosten eronder pass-through of blended zijn, of zij aansprakelijkheidsverschuiving rapporteren, en of zij in de eerste golf zitten voor direct checkout. Die vier antwoorden verschillen veel sterker per provider dan de aanwezigheid van de knop.<\/p><\/div>\n <\/div>\n<\/section>\n<\/div>\n<\/div><\/div>\n<\/div>\n<\/div>\n<\/div>\n

\n
\n
\n
\n
\n
\n

Uw Google Pay-kosten tegen het licht houden<\/h2>\n
<\/div>\n

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<\/a>, of bekijk wat payment performance-optimalisatie<\/a> doet met uw authorisation rate en cardmix, want daar verdient of kost een wallet u geld.<\/p>

Relevante markten: wereldwijd<\/p><\/div>\n <\/div>\n<\/section>\n<\/div>\n<\/div><\/div>\n<\/div>\n<\/div>\n<\/div>\n

Wilt u weten of uw mobiele checkout is ingericht voor maximale conversie?<\/h2>
<\/div>