Google Pay: In-App und Web

1) Was ist Google Pay Online

Google Pay (GPay) ist eine sichere Zahlungsschicht über Kartenschienen (Visa/Mastercard/usw.), bei der die PAN durch einen Geräte-/Netzwerk-Token (DPAN/Netzwerk-Token) ersetzt wird und die Transaktion mit einem einmaligen EMV-Kryptogramm signiert wird. Authentifizierung - Biometrie/Screen-Lock + Gerätebindung.
Für den Händler ist es im Wesentlichen eine CNP-Kartenzahlung mit erhöhter Conversion und weniger Frod. Dispute/Refands - nach Kartenregeln.

2) Kanäle und Szenarien

2. 1 Web

Integration über Google Pay JS (PaymentDataRequest).
Funktioniert in modernen Browsern (die beste UX ist Chrome/Android).
Bestätigung im Browser/über verknüpftes Gerät (Telefon/Uhr) mit Biometrie.

2. 2 In-App (Android)

Google Pay API for Android (native sheet).
Deep Link/App2App Bestätigung in der GPay-App, Rückgabe des Status an Ihre App.

2. 3 POS (NFC)

CP-Szenario über HCE/SE; außerhalb des Rahmens des Online-Artikels sind die Regeln für Chargebacks unterschiedlich.

3) Tokenisierung und Sicherheit

DPAN/Network Token wird vom Token Service des Netzwerks ausgegeben; Die PAN verlässt das Gerät nicht.
Für jede Zahlung wird ein EMV-Kryptogramm (einmalige Unterschrift) gebildet.
Der SCA wird durch die Biometrie/Bildschirmortung des Geräts geschlossen (PSD2-kompatibel).
Der Payment Token wird beim PSP/Gateway (Gateway-Mode) oder beim Merchant entschlüsselt, wenn entsprechende Zertifikate (Direct-Mode; selten).

4) SCA/3DS und Risikomodell

In EC/PSD2 wird SCA oft auf der Ebene von Google Pay ausgeführt → ein separater 3DS wird möglicherweise nicht ausgeführt (Bank/PSP entscheidet).
Der Emittent/das Netzwerk kann eine Dop-Validierung/Ablehnung der Transaktion verlangen (insbesondere für High-Risk MCC).
Bei empfindlichen Vertikalen sind selektive Ausfälle und reduzierte Grenzwerte möglich.

5) MIT/recurrent und COF

Der Google Pay-Token für eine One-Off-Transaktion ist nicht für eine erneute Abbuchung geeignet.

• Die erste Zahlung über GPay → die Zustimmung des MIT erhalten → die Karte im COF (Network Token/VTS/MDES) des PSP/Acquirers tokenisieren.
• Weitere Abschreibungen erfolgen als MIT mit einem COF-Token mit korrektem Transaktionsmarkup.
• Ohne COF und Zustimmung der Bank - hohe Decline/Chargeback-Risiken.

6) Verbindungsoptionen: Gateway vs direkt

Gateway (empfohlen): 'tokenizationSpecification. type = "PAYMENT_GATEWAY"' → Die PSP entschlüsselt das Token und autorisiert es. Schneller Start, weniger Compliance.
Direct: 'type =' DIRECT''→ der Merchant entschlüsselt das Netzwerk-Karten-Token selbst. Sie benötigen Zertifikate/Schlüssel und die strengste Sicherheit; wird selten verwendet.

• `allowedPaymentMethods` → `type: "CARD"`, `parameters. allowedAuthMethods` (`PAN_ONLY`, `CRYPTOGRAM_3DS`), `allowedCardNetworks`, `billingAddressParameters`.
• `tokenizationSpecification` → `gateway` или `direct`.
• 'transactionInfo' → Betrag/Währung/totalPriceStatus.
• `merchantInfo` → `merchantId`/`merchantName`.

7) Integrationsströme

7. 1 Web (Schritte)

1. GPay Client-Initialisierung → isReadyToPay-Validierung.
2. Erhebung von PaymentDataRequest (mit Netzwerken, Authentifizierungsmethoden und Tokenisierung).
3. Anzeige GPay Blatt → Benutzer bestätigt (SCA).
4. Empfangen von paymentMethodData (Chiffretoken) und Senden an PSP.
5. Ответ PSP: `authorized/succeeded/failed` + webhook.
6. „capture/refund“ nach Bedarf; recon - nach Tagesregistern.

7. 2 Android (in-app)

Ähnlich: 'PaymentsClient' anlegen, 'PaymentDataRequest' übergeben, Token erhalten und an das Backend/PSP übergeben.

8) Status, Berechnungen und Retouren

Online-Status: 'authorized/succeeded/failed/canceled' (+ 'pending' bei einigen PSPs).
Siedlung: durch PSP/Acquirer-Register, normalerweise T + 1/T + 2. Trennen Sie Online-Erfolg und Buchhaltung.
Refund: teilweise/vollständig nach Kartenregeln.
Chargeback: Das Kartenverfahren (INR/NAD usw.) bleibt relevant.

9) Häufige Fehlerursachen (declines)

MCC/Vertical (iGaming/Quasi-Cache) - Selektive Sperren bei Emittenten/PSPs.
Mismatch geo (Land der Karte/IP/Standort des Händlers).
Falsche Konfiguration von 'PaymentDataRequest' (Netzwerke/Authentifizierungsmethoden), falsche' merchantId 'oder Tokenisierungsmodus.
MIT ohne COF/consent.
SCA-Timeouts/User-Flow-Unterbrechung.

10) UX-Muster (was die Konversion erhöht)

Mobile-First: Nehmen Sie die Google Pay-Schaltfläche als erste Methode auf Android heraus.
Großer GPay-Knopf auf Produktkarte/Warenkorb/Checkout; beachten Sie die Marke hyde.
Pre-fill Betrag/Steuern/Lieferung in Blatt (user-visible total).
Recovery: sichere Wiederholung bei Timeouts, Umschalten auf Karten/A2A bei wiederholten Ausfällen.
Desktop↔mobayl: QR/Hand-off, wenn der Benutzer auf dem Telefon bestätigt.

11) Intelligentes Routing

Bieten Sie GPay unter Android/Chrome und für BIN 's/Banken mit hohem Approve-Rave an.
GPay Auto-Derating auf bestimmte BIN/Geo bei der Verschlechterung der Leistung.
Für Recurrents: erste Zahlung über GPay → COF, dann MIT ohne Benutzerbeteiligung.

12) Sicherheit und Compliance

Validierung von Nachrichtensignaturen/PSP Web Hooks, strenge' redirect/return 'URI.
Schlüssel/Geheimnisse - in vault, IP-allowlist für callback endpoints.
Der PCI-Footprint ist im Gateway-Modus minimal (Sie berühren die PAN/Geheimnisse nicht).
Logs: device hints, reason codes, SCA/confirm time.

13) iGaming: Funktionen

Verfügbarkeit und Grenzen hängen von der Gerichtsbarkeit, dem PSP und dem Emittenten ab.
Erwarten Sie selektive Ausfälle und/oder reduzierte Grenzwerte; Überprüfen Sie die lokalen Regeln.
Wiederkehrende Abschreibungen - nur MIT mit COF und dokumentierten Spielerzustimmungen.
Halten Sie Alternativen: A2A/open-banking, lokale Geldbörsen, eCash. Geben Sie fallback bei hoher decline auf GPay ein.

14) Abstimmung und Berichterstattung (recon)

• „paymentId/transactionId“, „orderId“, Netzwerk (Visa/MC/...), BIN/Bank, Betrag/Währung, Status/Fehlercodes, Kanal (Web/In-App), Zeitstempel, ARN/UTR aus den Registern.

Täglicher Auto-Recon + periodischer Full-Recon.
Alerta: „Online-Erfolg ohne Register“, „doppeltes Erfassen“, „aging auth“.

15) KPI und Methodenmanagement

Approval rate GPay vs konventionelle Karten (durch Banken/BIN/Geo/Geräte).
Share of GPay im Android-Traffic, 'retry win-rate'.
Decline matrix (reason codes), доля SCA timeouts.
Chargeback rate/ODR, settlement lag, доля partial refunds.
Schwellenregeln für Auto-Derating (z. B. Approve <X% bei einer bestimmten BIN/Geo).

16) Checkliste Ausgabe in prod

1. Verbinden Sie GPay mit der PSP; erhalten merchantId, konfigurieren allowedPaymentMethods/networks und tokenizationSpecification.
2. Implementieren Sie Web/In-App Sheet, 'authorize/capture/refund', Webhooks (Signatur/NMAS), Idempotenz und Retrays.
3. Konfigurieren Sie die COF/Netzwerk-Tokenisierung für MIT + speichern Sie consent.
4. Aktivieren Sie Smart-Routing: Priorität GPay auf Android, Fallback auf Karten/A2A.
5. Überprüfung der Markenzeichen (Buttons/Icons/Copyrights).
6. Baue Recon und Alerts: Off-Sync, aging auth, double capture.
7. E2E-Tests: Web/Android, partielle Erfassung/Refund, Timeouts/Wiederholungen, PSP-Abbau, hohe Belastungen.

Landmark-Karte

Schiene: Karte (Visa/MC/...); Chargeback - nach den Regeln der Karten.
SCA: Biometrie/Screen-Lock (PSD2-kompatibel); 3DS wird in der Regel nicht separat benötigt.
Tokenisierung: DPAN + EMV-Kryptogramm; für recurrent - COF/Netzwerk-Token.
Статусы: `authorized/captured/succeeded/failed/refunded/voided`.
Siedlung: nach PSP-Registern (T + 1/T + 2).
Einschränkungen: Verfügbarkeit nach Gerät/Browser/Geo; für iGaming - PSP/Emittenten Politik.

Zusammenfassung

Google Pay ist ein „Beschleuniger“ für Kartenzahlungen mit hoher mobiler Conversion und integrierter SCA. Integrieren Sie über den Gateway-Modus, erfüllen Sie die Anforderungen an PaymentDataRequest, bauen Sie Webhooks + Idempotenz + Recon auf und nutzen Sie COF für Recurrents. Für iGaming - Halten Sie alternative Schienen und intelligentes Routing, da Verfügbarkeit und Grenzen von der Gerichtsbarkeit, der Bank und der PSP abhängen.