Nativer Direktkauf – Übersicht

Damit Nutzer zur Kasse gehen können, müssen Sie die native Checkout-Integration implementieren. Dazu müssen Sie eine standardmäßige REST API erstellen, mit der Google den Bezahlvorgang programmatisch mit Ihren Servern verwalten kann. Diese Methode bietet Nutzern die reibungsloseste Erfahrung. Zunächst rendert Google die Benutzeroberfläche für den Käufer. Zukünftig sollen weitere Agenten-basierte Funktionen unterstützt werden.

Bezahlvorgang

Für die native Integration müssen Sie eine RESTful API erstellen, die Google aufrufen kann, um Checkout-Sitzungen zu erstellen und zu verwalten.

Der allgemeine Ablauf ist wie folgt:

  1. Checkout-Sitzung erstellen:Der Nutzer und optional ein Agent fügen der Sitzung in einer Schleife Artikel hinzu.
  2. Übergabe an eine Google-Benutzeroberfläche:Wenn der Nutzer zur Kasse gehen möchte, übergibt der Agent (falls beteiligt) die Steuerung an eine Google-Benutzeroberfläche (und übergibt die Daten der Checkout-Sitzung).
  3. Manuelle Bezahlung:Der Nutzer interagiert jetzt nur noch mit der Google-Benutzeroberfläche, um vertrauliche Details zur Abwicklung und Zahlung einzugeben und die Bestellung aufzugeben. Der Agent ist an diesem Teil nicht beteiligt, um Determinismus zu gewährleisten.
  4. Abschluss und Rückgabe:Die Google-Benutzeroberfläche zeigt eine Dankesseite an, um die Bestellung zu bestätigen. Optional kann der Nutzer zurück zum Agenten weitergeleitet werden, der möglicherweise bereits über den abgeschlossenen Kauf informiert wurde.

Lebenszyklus des Status der Checkout-Sitzung

Während der Nutzer den Bezahlvorgang durchläuft, müssen Sie den status der Checkout-Sitzung aktualisieren, um den aktuellen Status widerzuspiegeln. Die Sitzung durchläuft den folgenden Lebenszyklus:

  • incomplete:Der anfängliche Status, wenn eine Sitzung erstellt wird. Dies bedeutet, dass obligatorische Informationen (z. B. Versandmethoden, Steuern oder Nutzerdetails) fehlen oder nicht berechnet wurden.
  • ready_for_payment:Der Status, der verwendet werden muss, nachdem der Nutzer seine Lieferadresse aktualisiert hat und Sie Versandoptionen und Gesamtsummen berechnen, aber bevor das Zahlungsmittel abgeschlossen ist.
  • ready_for_complete:Der Status, der während der vollständigen Hydrierung des Checkout-Objekts verwendet werden muss, nachdem das Zahlungsmittel ausgewählt und alle Bestelldetails bestätigt wurden.
  • completed:Der endgültige Status, der zurückgegeben wird, nachdem Sie die Zahlung erfolgreich verarbeitet und die Bestellung aufgegeben haben.
  • canceled:Der Status, der zurückgegeben wird, wenn die Checkout-Sitzung abgebrochen wird.
  • error:Der Status, der zurückgegeben wird, wenn ein nicht behebbarer Fehler in der Geschäftslogik den Bezahlvorgang verhindert. Dieser Status ist in UCP-Version 2026-04-08 und höher verfügbar.

Bezahlvorgang für mehrere Artikel:

Google unterstützt jetzt mehrere verschiedene Posten in einer einzigen Checkout-Sitzung. Der allgemeine Ablauf ist wie folgt:

  1. Der Nutzer initiiert den Bezahlvorgang über eine UCP-fähige Benutzeroberfläche (z.B. durch Klicken auf „Jetzt kaufen“ für ein Produkt).
  2. Der Aufruf POST /checkout-sessions wird ausgeführt, einschließlich aller einzelnen Artikel im Array line_items. Das Array line_items enthält ein separates Objekt für jeden einzelnen Artikel, der zur Kasse geht.
  3. Der Nutzer kann sein Zahlungsmittel und die Details zur Abwicklung aktualisieren oder Rabatte anwenden, indem er PUT /checkout-sessions/{id}-Aufrufe verwendet.
  4. Wenn der Nutzer auf die Schaltfläche „Mit GPay bezahlen“ klickt, wird der POST /checkout-sessions/{id}/complete Aufruf ausgeführt.

Authentifizierung

Weitere Informationen zum Sichern Ihrer nativen Checkout API-Endpunkte, einschließlich unterstützter Authentifizierungsmethoden wie API-Schlüssel und OAuth 2.0, finden Sie im Leitfaden zur Authentifizierung & Sicherheit.

Entwicklertools

Zur Unterstützung bei der Implementierung der nativen Checkout API finden Sie die folgenden Ressourcen im GitHub-Repository des Universal Commerce Protocol:

  • UCP-GitHub-Repository:Hier finden Sie eine umfassende Dokumentation, Spezifikationen und Community-Ressourcen.
  • SDKs:Mit den Software Development Kits können Sie die Integration beschleunigen. Es sind sprachspezifische SDKs verfügbar, darunter:

  • Konformitätstests: Mit der Konformitätstest suite können Sie Ihre API-Endpunkte anhand der UCP Spezifikation validieren.

    So wird sichergestellt, dass Ihre Implementierung die erforderlichen Standards und Verhaltensweisen erfüllt.

Wir empfehlen dringend, diese Tools zu verwenden, um den Entwicklungs- und Testprozess zu optimieren.

Service Level Objectives

Die folgenden Service Level Objectives (SLOs) gelten für die nativen Checkout REST API-Endpunkte. Unternehmen, die eine Integration mit Google vornehmen, müssen diese Ziele für die API-Leistung und ‑Verfügbarkeit erreichen.

Endpunkt Verfügbarkeit Latenz (50. Perzentil) Latenz (95. Perzentil)
POST /checkout-sessions (Erstellen) >= 95% <= 1 Sekunde <= 4 Sekunden
PUT /checkout-sessions/{id} (Aktualisieren) >= 95% <= 1 Sekunde <= 5 Sekunden
POST /checkout-sessions/{id}/complete (Abgeschlossen) >= 95% <= 6 Sekunden <= 10 Sekunden

Die Latenz des 50. Perzentils gibt an, dass mindestens 50% der Anfragen voraussichtlich innerhalb dieser Zeit abgeschlossen werden. Die Latenz des 95. Perzentils gibt an, dass mindestens 95% der Anfragen voraussichtlich innerhalb dieser Zeit abgeschlossen werden.

Nächste Schritte

Sehen Sie sich die Checkout API-Nutzlasten und technischen Implementierungsdetails für Ihre UCP-Version an:

Zurück
Authentication
Weiter
Bestelllebenszyklus (nach dem Kauf)