// stack · schnittstelle
Google Pay ist kein Zahlungsdienstleister, sondern eine Bezahlmethode. Die Karte liegt im Google-Konto, der Geldfluss läuft über den Zahlungsdienstleister, der ohnehin hinter der Bezahlstrecke steht — bei siteway in der Regel Stripe. Diese Seite beschreibt, was Google Pay im Bezahlvorgang übernimmt, was dafür vorhanden sein muss und wie wir den Button in eine Website einbauen, die auch ohne ihn vollständig funktioniert.
// definition
methode, nicht dienstleister
Google Pay ist eine Bezahlmethode von Google. Wer im Google-Konto eine Karte hinterlegt hat, kann damit auf einer Website bezahlen, ohne die Kartennummer erneut einzutippen. Für Websites stellt Google dafür die Google Pay API for Web bereit: Beim Klick auf den Google-Pay-Button öffnet sich ein Auswahlblatt mit den hinterlegten Karten, und Google gibt anschließend ein Zahlungs-Token an die Website zurück.
Und hier liegt der Punkt, an dem viele Beschreibungen zu kurz greifen: Google Pay wickelt die Zahlung nicht selbst ab. Das Token geht zusammen mit den Kaufdaten an den eigenen Server, und von dort läuft die Zahlung über den Zahlungsdienstleister — bei uns in der Regel Stripe. Belastung der Karte, Abrechnung, Rückerstattung und Zahlungsausfall bleiben also dort, wo sie vorher schon lagen. Google Pay steuert Karten- und Adressdaten bei und verkürzt damit die Eingabe, nicht die Kette dahinter.
Damit ist auch die Reihenfolge im Projekt klar: Zuerst steht der Zahlungsdienstleister, dann kommt die Methode dazu. Genauso verhält es sich mit Apple Pay — dieselbe Rolle, anderes Ökosystem. In der Bezahlstrecke stehen beide nebeneinander, und wer keines von beidem nutzt, bezahlt auf dem regulären Weg. Wo Bezahlen überhaupt Thema wird, beschreibt die Leistung Shop & E-Commerce.
// praxis
zusatz · kein fundament
Wir bauen die Bezahlstrecke zuerst ohne Google Pay — vollständig, bedienbar, mit Tastatur erreichbar. Der Button kommt danach obendrauf. Das ist keine Stilfrage, sondern folgt aus der Technik: Der Button darf erst erscheinen, wenn Browser und Google-Konto die Methode überhaupt tragen. Diese Bauweise heißt Progressive Enhancement und ist bei siteway die Grundlage des gesamten Frontends — die Seite funktioniert auf der schmalen Grundlage und wird besser, wo mehr möglich ist.
Der nächste Schritt ist die Verfügbarkeitsprüfung. Bevor irgendetwas sichtbar wird, fragt die Website über die Methode isReadyToPay ab, ob eine Zahlung über Google Pay möglich ist. Erst wenn die Antwort positiv ausfällt, wird der Button erzeugt und eingesetzt. Fällt sie negativ aus, bleibt die Bezahlstrecke exakt so, wie sie ohne Google Pay aussieht. Beide Fälle gehören ins Konzept der Seite — der Platz, an dem der Button steht, darf im zweiten Fall keine Lücke hinterlassen.
Der Zahlungsvorgang selbst ist eine kurze, klar getrennte Kette. Das Auswahlblatt öffnet sich nur aus einem Klick heraus; Google verlangt dafür ausdrücklich ein Nutzer-Ereignis. Die Rückgabe ist ein Token, kein Kartendatensatz. Dieses Token schickt der Browser an einen eigenen serverseitigen Endpunkt, der es zusammen mit Betrag, Währung und Bestellbezug an den Zahlungsdienstleister übergibt. Betrag und Währung stammen dabei immer vom Server, nie aus dem Formular — sonst entscheidet der Browser über den Preis.
Dann der Abbruch, der in Angeboten gern fehlt. Schließt jemand das Auswahlblatt, wird die Zusage der Zahlungsdaten abgelehnt. Für die Seite heißt das: kein Fehlerdialog, keine halb abgeschickte Bestellung, sondern derselbe Stand wie vorher. Genauso behandeln wir den Fall, dass der Zahlungsdienstleister nicht antwortet — die Bestellung bleibt offen und nachvollziehbar, statt in einem unklaren Zustand zu enden.
Und schließlich das Mapping. Google Pay kann Rechnungsadresse, E-Mail-Adresse und Lieferadresse mitliefern. Was davon angefordert wird, entscheiden wir vorher und bilden es auf die Felder der Bestellung ab — angefordert wird, was gebraucht wird, und nicht, was möglich ist. Die buchbare Leistung dahinter beschreibt Schnittstellenentwicklung.
// technik · 6 details
belegt aus der doku
Was hier steht, stammt aus der Entwicklerdokumentation zur Google Pay API for Web — Methoden, Felder und Werte im Original. Zu Gebühren, Limits und Browserversionen im Detail steht dort nichts Allgemeingültiges, deshalb steht hier auch nichts dazu: Was der Zahlungsdienstleister kostet, steht in dessen Preisliste, und was der Browser konkret kann, entscheidet die Verfügbarkeitsprüfung zur Laufzeit.
// d-01einstieg
Der Einstieg ist eine von Google ausgelieferte Bibliothek, aus der ein PaymentsClient erzeugt wird. Er trägt die Umgebung — Test oder Produktion — und stellt alle weiteren Methoden bereit. Weil der Code von Google kommt, ist genau hier die Stelle, an der Datenschutz und Ladezeitpunkt zusammenfallen.
zweck: einbindung
// d-02prüfung
isReadyToPay klärt, ob über Google Pay überhaupt ein Zahlungsmittel zurückkommen kann. Das Ergebnis entscheidet über die Anzeige des Buttons. Die zusätzliche Abfrage existingPaymentMethodRequired gibt es zwar, Google rät aber davon ab, die Anzeige davon abhängig zu machen.
zweck: anzeigen oder nicht
// d-03button
Den Button erzeugt createButton als echtes button-Element in einem Container. Google gibt vor, ausschließlich die eigenen Schaltflächen zu verwenden und Schrift, Farbe, Radius und Innenabstand nicht zu verändern. Dabei fügt die Methode CSS-Regeln und eine SVG-Datei aus dem Google-CDN ein.
zweck: markenkonforme schaltfläche
// d-04anfrage
Die Anfrage beschreibt, was akzeptiert wird: allowedPaymentMethods mit den zugelassenen Kartennetzen, allowedAuthMethods mit PAN_ONLY und CRYPTOGRAM_3DS, dazu transactionInfo mit Betrag, Währung und Land sowie merchantInfo mit Händlerkennung und Anzeigename.
zweck: was akzeptiert wird
// d-05daten
Optional liefert Google Pay mehr als die Karte: billingAddressRequired für die Rechnungsadresse, wahlweise vollständig oder verkürzt, emailRequired für die E-Mail-Adresse und shippingAddressRequired für die Lieferadresse. Über callbackIntents lässt sich auf eine geänderte Adresse reagieren.
zweck: weniger tippen
// d-06abwicklung
Die tokenizationSpecification legt fest, wohin die Zahlungsdaten gehen. Der Regelfall ist PAYMENT_GATEWAY mit den Feldern gateway und gatewayMerchantId, also der Weg über den Zahlungsdienstleister. Die Variante DIRECT beschreibt Google nur für Händler, die selbst PCI-DSS-konform sind.
zweck: weg der zahlung
Der Gewinn liegt nicht in der Zahlung, sondern in der Eingabe. Kartennummer, Gültigkeit, Prüfziffer, Rechnungsadresse, oft noch die Lieferadresse — das sind auf einem kleinen Display viele Felder und viele Gelegenheiten, abzubrechen. Google Pay ersetzt diese Eingabe durch eine Auswahl: Die Daten liegen im Konto und werden im Auswahlblatt nur bestätigt. Aus mehreren Formularen wird ein Bestätigungsschritt.
Damit das trägt, muss die Website die zurückgegebenen Felder sauber auf ihr eigenes Datenmodell abbilden. Eine Rechnungsadresse in verkürzter Form ist etwas anderes als eine vollständige; wer beides gleich behandelt, hat später eine Bestellung ohne Hausnummer. Deshalb legen wir vorher fest, welche Felder angefordert werden, welche Pflicht sind und wie die Bestellung aussieht, wenn ein optionales Feld leer bleibt.
Der Punkt, der auf einer trackingfrei gebauten Website wirklich zählt, ist kein Vertrag, sondern eine Ladezeile: Für den Button wird Code von Google im Browser der Besucherinnen und Besucher geladen. Google beschreibt für die Button-Erzeugung ausdrücklich, dass dabei CSS-Regeln und eine SVG-Datei aus dem Google-CDN eingefügt werden. Auf einer Seite, die sonst ohne fremde Einbindungen auskommt, ist das ein sichtbarer Unterschied.
Deshalb gehört Google Pay in die Betrachtung der Einwilligung, und deshalb laden wir die Bibliothek nicht auf jeder Seite mit, sondern erst nach der Einwilligung beziehungsweise erst im Bezahlvorgang. Technisch ist beides sauber umsetzbar, weil der Button ohnehin erst nach der Verfügbarkeitsprüfung entsteht. Wie der Einzelfall rechtlich zu bewerten ist, gehört zur Rechtsberatung — die technische Grundlage bereiten wir vor, beschrieben im Stack unter Sicherheit & Datenschutz; wer den Bestand erst einmal aufgenommen haben will, findet das im Datenschutz-Audit.
// integration
drei systeme · ein muster
Der Weg ist in jedem System derselbe, und er ist erstaunlich unspektakulär. Im Frontend sitzen zwei Dinge im Template der Bezahlstrecke: die Verfügbarkeitsprüfung und der Platz, an dem der Button entsteht. Der Button erscheint nur bei Unterstützung durch Browser und Google-Konto — die Bezahlstrecke muss deshalb beide Fälle sauber darstellen. Mit Button ist er die erste, kürzeste Option; ohne Button steht dort keine leere Fläche und kein Hinweis auf etwas Fehlendes, sondern schlicht die reguläre Bezahlstrecke. Diese zweite Ansicht ist der Normalfall, nicht die Ausnahme, und wird genauso gestaltet und getestet wie die erste.
Der Zahlungsvorgang läuft danach nicht im Browser, sondern über den serverseitigen Endpunkt des Zahlungsdienstleisters. Das Auswahlblatt gibt ein Token zurück, das Token geht an eine eigene Route der Website, und diese Route spricht mit dem Zahlungsdienstleister — mit Betrag, Währung und Bestellbezug aus dem eigenen Bestand und mit Zugangsdaten, die in der Server-Konfiguration liegen und nie im Browser auftauchen. Was sich zwischen den Systemen unterscheidet, ist nur, wo diese Bausteine liegen: in welchem Template, in welcher Route, in welcher Konfigurationsebene.
// cms-01typo3
Wir bauen die Anbindung als eigene Extension. Der Button und die Verfügbarkeitsprüfung sitzen im Fluid-Template der Bezahlstrecke, eingebunden über ein eigenes Content-Element oder ein Plugin der Extension — sichtbar erst, wenn die Prüfung positiv ausfällt. Der serverseitige Endpunkt ist eine eigene Route der Extension mit passender Middleware; sie nimmt das Token entgegen, holt Betrag und Bestellbezug aus dem eigenen Datenmodell und spricht mit dem Zahlungsdienstleister. Die Zugangsdaten liegen als Umgebungsvariablen und werden über die Extension-Konfiguration ausgelesen, nicht im TypoScript des Frontends.
// cms-02wordpress
In WordPress entsteht die Anbindung als eigenes Plugin und nicht als Theme-Code — so überlebt sie den Theme-Wechsel. Verfügbarkeitsprüfung und Button liegen im Template der Kasse, ausgeliefert über ein Skript, das nur auf dieser Seite eingereiht wird und nicht auf der ganzen Website. Der serverseitige Endpunkt ist eine eigene REST-Route des Plugins: Sie prüft die Anfrage, nimmt das Token entgegen und ruft den Zahlungsdienstleister auf. Die Zugangsdaten stehen in der Server-Konfiguration und werden im Plugin ausgelesen — nie in einer Option, die im Frontend landen kann.
// cms-03statamic
Statamic läuft auf Laravel, und das macht diesen Teil besonders geradlinig. Verfügbarkeitsprüfung und Button sitzen in einem Antlers- oder Blade-Template der Bezahlstrecke. Der serverseitige Endpunkt ist eine Route plus Controller im Laravel-Unterbau: Der Controller validiert die Anfrage, nimmt das Token entgegen und übergibt es an den Zahlungsdienstleister. Die Zugangsdaten liegen in der Umgebungsdatei und werden über die Konfiguration eingelesen, sodass sie in keinem Template auftauchen. Static Caching bleibt davon unberührt, weil die Bezahlstrecke ohnehin dynamisch bleibt.
// voraussetzungen
nur belegtes
Die Liste ist kurz, und sie stammt aus der Dokumentation von Google und des Zahlungsdienstleisters. Alles, was sich schnell ändert — einzelne Browserversionen, Gebührensätze, Länderlisten — bleibt hier bewusst draußen und wird von siteway im Projekt am aktuellen Stand geprüft.
// v-01transport
Google nennt als Voraussetzung eine über HTTPS ausgelieferte Seite mit einem domainvalidierten TLS-Zertifikat. Das ist keine Empfehlung, sondern Bedingung — ohne sie kommt der Button nicht zustande. Auf einer sauber betriebenen Website ist das ohnehin der Zustand.
quelle: google · setup
// v-02browser
Google führt Google Chrome, Mozilla Firefox, Apple Safari, Microsoft Edge, Opera und UCWeb UC Browser als unterstützt auf. Konkrete Versionsstände nennen wir hier nicht, weil sie sich verschieben — verbindlich ist ohnehin die Antwort der Verfügbarkeitsprüfung im Browser der Besucherin.
quelle: google · setup
// v-03konto
Bezahlt wird mit dem, was im Google-Konto hinterlegt ist — Google nennt das Hinzufügen einer Zahlungsmethode ausdrücklich als Schritt der Einrichtung. Diese Voraussetzung liegt außerhalb der Website, weshalb der Button für einen Teil der Besucherinnen und Besucher schlicht nicht erscheint.
quelle: google · setup
// v-04abwicklung
Ohne eingerichteten Zahlungsdienstleister gibt es kein Google Pay, weil die Zahlung dort abgewickelt wird. Bei Stripe kommt ein konkreter Schritt dazu: Alle Domains, auf denen ein Google-Pay-Button erscheint, müssen registriert werden — inklusive der Subdomains, in Produktion wie im Test.
// v-05kennung
Für den Produktivbetrieb verlangt Google eine Händlerkennung im Feld merchantId, dazu einen Anzeigenamen in merchantName. Vor der Umsetzung stehen außerdem die Nutzungsbedingungen der Google Pay API und die Markenrichtlinien für den Button, die unter anderem eigene Nachbauten ausschließen.
quelle: google · referenz
// v-06einwilligung
Weil für den Button Code von Google im Browser geladen wird, gehört Google Pay in die Betrachtung der Einwilligung und in die Datenschutzerklärung. Technisch bereiten wir vor, dass die Bibliothek erst nach der Einwilligung oder erst im Bezahlvorgang lädt. Die rechtliche Bewertung selbst gehört in andere Hände.
// faq
Google Pay ist eine Bezahlmethode von Google. Wer im Google-Konto eine Karte hinterlegt hat, kann damit auf einer Website bezahlen, ohne die Kartennummer erneut einzutippen. Für Websites stellt Google dafür die Google Pay API for Web bereit. Die Website prüft damit die Verfügbarkeit, zeigt den Google-Pay-Button an und öffnet beim Klick ein Auswahlblatt mit den hinterlegten Karten. Google gibt danach ein Zahlungs-Token an die Website zurück, das serverseitig weiterverarbeitet wird.
Nein. Google Pay ist eine Bezahlmethode, kein eigener Zahlungsdienstleister. Der Geldfluss läuft weiterhin über den Zahlungsdienstleister, der ohnehin hinter der Bezahlstrecke steht — bei uns in der Regel Stripe. Google Pay steuert die im Google-Konto hinterlegten Karten- und Adressdaten bei und übergibt sie als Token; die Belastung der Karte, die Abrechnung, Rückerstattungen und der Umgang mit Zahlungsausfällen bleiben beim Zahlungsdienstleister. Google beschreibt das in seiner Dokumentation so, dass das Token zusammen mit den Kaufdaten an das eigene Backend geht und von dort über den Zahlungsdienstleister verarbeitet wird. Praktisch heißt das: Ohne eingerichteten Zahlungsdienstleister gibt es kein Google Pay.
Drei Dinge, und alle drei sind in der Dokumentation von Google belegt. Erstens muss die Seite über HTTPS mit einem domainvalidierten TLS-Zertifikat ausgeliefert werden. Zweitens braucht es einen unterstützten Browser; Google nennt dafür Google Chrome, Mozilla Firefox, Apple Safari, Microsoft Edge, Opera und UCWeb UC Browser. Drittens muss im Google-Konto eine Zahlungsmethode hinterlegt sein. Ob all das zutrifft, fragt die Website vor der Anzeige über die Methode isReadyToPay ab. Fällt die Antwort negativ aus, wird der Button gar nicht erst gezeigt.
Weil die Daten schon da sind. Die Karte liegt im Google-Konto, und die Anfrage der Website kann zusätzlich Rechnungsadresse, E-Mail-Adresse und Lieferadresse anfordern — über die Felder billingAddressRequired, emailRequired und shippingAddressRequired. Was sonst in Formularfelder getippt wird, kommt damit aus dem Konto und wird im Auswahlblatt nur noch bestätigt. Weniger Tippen heißt weniger Stellen, an denen jemand abbricht. Für die Website bedeutet es zugleich: Die Felder müssen sauber auf das eigene Datenmodell gemappt werden, sonst landen Adressen unvollständig in der Bestellung.
Dann passiert nichts Sichtbares — und genau so soll es sein. Wir bauen die Bezahlstrecke zuerst ohne Google Pay vollständig funktionsfähig und setzen den Button obendrauf. Ist er nicht verfügbar, fehlt eine Abkürzung, kein Weg. Dieselbe Haltung gilt für den Abbruch: Schließt jemand das Auswahlblatt, wird die Zusage der Zahlungsdaten abgelehnt, und die Bezahlstrecke steht unverändert an derselben Stelle. Diese Bauweise nennt sich Progressive Enhancement und ist bei uns kein Sonderfall, sondern die Grundlage des gesamten Frontends.
Es bedeutet, dass Code von Google im Browser der Besucherinnen und Besucher geladen wird. Der Button entsteht über eine Bibliothek, die von Google ausgeliefert wird; Google beschreibt für die Button-Erzeugung ausdrücklich, dass dabei CSS-Regeln und eine SVG-Datei aus dem Google-CDN eingefügt werden. Auf einer Website, die sonst ohne fremde Einbindungen auskommt, ist das ein sichtbarer Unterschied und gehört deshalb in die Betrachtung der Einwilligung. Unsere Bauweise: Die Bibliothek wird nicht auf jeder Seite geladen, sondern erst im Bezahlvorgang beziehungsweise erst nach der Einwilligung. Wie das im konkreten Fall rechtlich zu bewerten ist, gehört zur Rechtsberatung und damit nicht auf diese Seite — die technische Seite bereiten wir so vor, dass beide Wege umsetzbar sind.
Ja, und der Weg ist in allen drei Systemen derselbe. Im Frontend sitzen die Verfügbarkeitsprüfung und der Button im Template der Bezahlstrecke, serverseitig braucht es einen Endpunkt, der das Zahlungs-Token entgegennimmt und an den Zahlungsdienstleister weitergibt. In TYPO3 bauen wir dafür eine eigene Extension mit eigener Route und dem Button im Fluid-Template. In WordPress entsteht ein eigenes Plugin mit einer eigenen REST-Route und dem Button im Template der Kasse. In Statamic liegt Laravel darunter, also Route plus Controller im Laravel-Unterbau und der Button in Antlers oder Blade. Die Zugangsdaten des Zahlungsdienstleisters liegen in allen drei Fällen in der Server-Konfiguration und nie im Browser.
Die Rolle ist dieselbe, das Ökosystem ist ein anderes. Beide sind Bezahlmethoden, die im jeweiligen Konto hinterlegte Karten- und Adressdaten in die Bezahlstrecke einspeisen, und beide werden über den vorhandenen Zahlungsdienstleister abgewickelt. Unterschiedlich sind Verfügbarkeit, Einrichtung und die Bausteine, mit denen der Button entsteht. In der Bezahlstrecke stehen sie deshalb nebeneinander statt gegeneinander: Wer ein Google-Konto mit hinterlegter Karte nutzt, sieht den einen Button, wer im Apple-Ökosystem unterwegs ist, den anderen, und wer keines von beidem hat, bezahlt auf dem regulären Weg.
// womit das zusammenhängt
abwicklung, bauweise & leistung
// stack · abwicklung
Der Zahlungsdienstleister, über den Google Pay bei uns in der Regel abgewickelt wird — inklusive der Domains, die dafür registriert sein müssen.
zur technik →
// stack · bezahlmethode
Dieselbe Rolle, anderes Ökosystem: Karten- und Adressdaten aus dem Konto, Abwicklung über den Zahlungsdienstleister.
zur technik →
// stack · bauweise
Progressive Enhancement als Grundlage: Die Seite trägt ohne Zusatz und wird besser, wo der Browser mehr kann.
zur technik →
// stack · grundlage
Fremder Code im Browser, Zugangsdaten auf dem Server, Einwilligung vor dem Laden: die Grundregeln hinter dem Button.
zur technik →
// leistung · komponente
Die Komponente, in der die Bezahlstrecke überhaupt entsteht — vom Produktkatalog bis zur Kasse.
zur leistung →
// leistung · buchen
Die Technik hier, das Angebot dort: Konzept, Umsetzung, Endpunkt, Test und Betrieb der Anbindung. Hier wird gebucht.
zur leistung →
// Google Pay in deiner Bezahlstrecke?
Projekt anfragen