Nativer Direktkauf – Übersicht

Damit Nutzer den Check-out durchführen können, müssen Sie die Integration des nativen Check-outs implementieren. Dazu müssen Sie eine Standard-REST API erstellen, mit der Google den Bezahlvorgang programmatisch mit Ihren Servern verwalten kann. Diese Methode bietet Nutzern die reibungsloseste Erfahrung. Anfangs wird Google die Benutzeroberfläche für den Käufer rendern. Zukünftig sollen auch andere Agenten 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 sieht so aus:

  1. Checkout-Sitzung erstellen:Der Nutzer und optional ein Kundenservicemitarbeiter fügen der Sitzung Artikel hinzu.
  2. Übergabe an eine Google-Benutzeroberfläche:Sobald der Nutzer sich für die Nutzung des Agents entscheidet (falls er aktiv ist), wird die Steuerung an eine Google-Benutzeroberfläche übergeben (die Daten der Abrechnungssitzung werden übergeben).
  3. Manuelle Kaufabwicklung:Der Nutzer interagiert jetzt nur noch mit der Google-Benutzeroberfläche, um vertrauliche Versand- und Zahlungsdetails einzugeben und die Bestellung aufzugeben. Der Agent ist an diesem Teil nicht beteiligt, was für Determinismus sorgt.
  4. Abschluss und Rückgabe:In der Google-Benutzeroberfläche wird eine „Danke“-Seite angezeigt, um die Bestellung zu bestätigen. Optional kann der Nutzer zurück zum Kundenservicemitarbeiter weitergeleitet werden, der möglicherweise bereits über den abgeschlossenen Kauf informiert wurde.

Lebenszyklus des Checkout-Sitzungsstatus

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

  • incomplete:Der ursprüngliche Status beim Erstellen einer Sitzung. Das bedeutet, dass obligatorische Informationen wie Versandarten, Steuern oder Nutzerdetails fehlen oder nicht berechnet wurden.
  • ready_for_payment:Der Status, der verwendet werden soll, nachdem der Nutzer seine Versandadresse aktualisiert und Sie Versandoptionen und Gesamtsummen berechnet haben, aber bevor das Zahlungsmittel abgeschlossen wird.
  • ready_for_complete:Der Status, der während der vollständigen Objekt-Hydrierung des Check-outs verwendet werden soll, sobald das Zahlungsmittel ausgewählt und alle Bestelldetails validiert 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 Kauf verhindert. Dieser Status ist in der UCP-Version 2026-04-08 und höher verfügbar.

Bezahlvorgang für mehrere Artikel:

Google unterstützt jetzt mehrere unterschiedliche Positionen in einer einzigen Abrechnungssitzung. Der allgemeine Ablauf sieht so aus:

  1. Der Nutzer startet den Bezahlvorgang über eine UCP-fähige Schnittstelle (z.B. durch Klicken auf „Jetzt kaufen“ für ein Produkt).
  2. Der POST /checkout-sessions-Aufruf wird ausgeführt und enthält alle eindeutigen Elemente im line_items-Array. Das line_items-Array enthält für jeden eindeutigen Artikel, der gekauft wird, ein separates Objekt.
  3. Der Nutzer kann sein Zahlungsmittel und die Versanddetails aktualisieren oder Rabatte anwenden, indem er PUT /checkout-sessions/{id}-Aufrufe verwendet.
  4. Wenn der Nutzer auf den Button „Mit GPay bezahlen“ klickt, wird der POST /checkout-sessions/{id}/complete-Aufruf ausgeführt.

Authentifizierung

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

Entwicklertools

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

  • UCP-GitHub-Repository:Im Haupt-Repository finden Sie 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:Validieren Sie Ihre API-Endpunkte anhand der UCP-Spezifikation mit der Konformitätstestsuite.

    So wird sichergestellt, dass Ihre Implementierung den erforderlichen Standards und Verhaltensweisen entspricht.

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

Service Level Objectives

Für die REST-API-Endpunkte für den nativen Checkout gelten die folgenden Service Level Objectives (SLOs). Unternehmen, die Google-Produkte einbinden, müssen diese Ziele für 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 im 95. Perzentil gibt an, dass mindestens 95% der Anfragen voraussichtlich innerhalb dieser Zeit abgeschlossen werden.

Nächste Schritte

Hier finden Sie die Checkout-API-Nutzlasten und technischen Implementierungsdetails für Ihre UCP-Version:

Wenn Sie als Drittanbieter integrieren, fahren Sie mit der Einrichtung des UCP Checkout-Dienstes fort, um Händlerprofile zu hosten und die Einrichtung von Konto-Beziehungshandshakes zu konfigurieren.

Zurück
Bestelllebenszyklus (nach dem Kauf)
Weiter
Fehlercodes