Überblick über die Unterstützung von vom Händler initiierten Transaktionen
Vom Händler initiierte Transaktionen (Merchant Initiated Transactions, MITs) sind Transaktionen, die verarbeitet werden, ohne dass der Nutzer aktiv in einer Sitzung ist. Diese Aktualisierung der Google Pay Online API bietet eine bessere Sichtbarkeit für diese Transaktionstypen, eine verbesserte Nutzererfahrung durch eine spezielle Benutzeroberfläche für Abrechnungsdetails und eine bessere Kontinuität bei Zahlungen.
Wichtige Anwendungsfälle
- Wiederkehrende Zahlungen:digitale Streamingdienste, Mitgliedschaften oder Versorgungsunternehmen
- Aufgeschobene Zahlungen:Hotelreservierungen, Vorbestellungen oder Gebühren für Nichterscheinen
- Automatische Aufladungen:Aufladen von Guthaben für Fahrkarten oder Geschenkkarten
Implementierung der MIT API
Die MIT API ist eine Erweiterung der vorhandenen
LoadPaymentData
API. Integratoren müssen genau ein *TransactionInfo-Objekt einfügen, um die Abrechnungsabsicht anzugeben.
Google bietet je nach Art der vom Händler initiierten Transaktion drei Optionen:
| Transaktionstyp | Objektname | Beschreibung |
|---|---|---|
| Wiederkehrend | RecurringTransactionInfo |
Wird für Gebühren mit fester Häufigkeit verwendet. Unterstützt Testzeiträume sowie Prepaid- und Postpaid-Abrechnung. |
| Aufgeschoben | DeferredTransactionInfo |
Wird für eine einmalige Gebühr zu einem festgelegten zukünftigen Zeitpunkt verwendet. |
| Automatische Aufladung | AutomaticReloadTransactionInfo |
Wird verwendet, um ein Guthabenkonto aufzuladen, wenn ein Guthaben unter einen Mindestwert fällt. |
Integrationsschritte
- Dokumentation:Während des Early Access-Programms haben Sie Zugriff auf die DevSite. Die drei neuen Objektdefinitionen finden Sie im Abschnitt „Objektreferenz“, und sie sind in der vorherigen Liste direkt verlinkt.
- Implementierung: Verwenden Sie in Ihrer API-Anfrage die entsprechenden
*TransactionInfoObjekte für Ihr System.- Hinweis: Pro Anfrage kann nur ein Objekt an die API übergeben werden. Es liegt im Ermessen des einzelnen Händlers, welches Objekt verwendet und wie die Felder ausgefüllt werden.
- Tests:Verwenden Sie die TEST-Umgebung, um zu prüfen, ob die Abrechnungsdetails im Zahlungsformular korrekt dargestellt werden.
- Start:Sobald die Parameter überprüft wurden, können Sie mit der Implementierung beginnen.
Token Lifecycle Management (TLM)
Token Lifecycle Management sorgt für Kontinuität bei Zahlungen, indem es Echtzeitbenachrichtigungen sendet, wenn sichere Zahlungstokens aktualisiert oder deaktiviert werden. Ausführliche Informationen finden Sie in der Token Lifecycle Management .
Wichtige Token-Ereignisse
- Deaktivierung/Löschung:Benachrichtigt, wenn ein Token nicht mehr verwendet werden kann.
- Aktualisierungen des FPAN-Suffix:Tritt auf, wenn die zugrunde liegende primäre Kontonummer für die Finanzierung aktualisiert wird.
Anforderungen an die Servereinrichtung
Direkte Händler und Zahlungsdienstleister (Payment Service Providers, PSPs) müssen ein System einrichten, um diese Nachrichten zu empfangen, zu entschlüsseln und zu verarbeiten.
| Anforderung | Beschreibung |
|---|---|
| Endpunkt | Sicherer HTTPS-Endpunkt zum Empfangen von POST-Aufrufen. |
| Authentifizierung | Muss die Signaturvalidierung und die Nachrichtenentschlüsselung verarbeiten. |
| Antwort | Gibt „SUCCESS“ zurück, um Benachrichtigungen fortzusetzen, oder „TOKEN_NOT_FOUND“/„TOKEN_NOT_IN_USE“, um sie zu beenden. |
| Händlerbenachrichtigung | PSPs müssen ihren Händlern den Tokenstatus mitteilen. |
Implementierungshinweise
Der tokenUpdateUrl-Endpunkt muss mit der Transaktion übergeben werden, um Aktualisierungen für das Token zu erhalten. Bei PSPs liegt es in ihrer Verantwortung festzulegen, wie Händler diese URL im entsprechenden *TransactionInfo-Objekt erhalten und ausfüllen.
Außerdem gibt die verschlüsselte Nutzlast für vom Händler initiierte Transaktionen ein zusätzliches optionales Feld zurück: merchantTokenId. Weitere Informationen finden Sie in der
Kryptografie von Zahlungsdaten
(für Händler) oder zur
Nutzlaststruktur (für PSPs).