Weiterleitungsablauf starten

Überblick

Mit dem Ablauf „Weiterleitung beginnen“ soll der Nutzer zum Zahlungsintegrator weitergeleitet werden und genügend Informationen vorliegen, um die Zahlung abzuschließen. Der Integrator wiederum leitet den Nutzer auf die Weboberfläche des Ausstellers weiter und leitet dabei die von Google bereitgestellten Informationen weiter. Der Nutzer kann dann der Anleitung des Ausstellers folgen, um eine Zahlung abzuschließen. Dadurch wird der Vorgang Vollständige Weiterleitung ausgelöst.

Ablauf

Nutzer haben zwei Möglichkeiten, den Aussteller auszuwählen, der als Zahlungsmittel verwendet werden soll.

  1. Der Nutzer wählt den Aussteller in der Benutzeroberfläche von Google aus.
  2. Der Nutzer wählt in der Benutzeroberfläche von Google den Integrator und in der Benutzeroberfläche des Integrators den Aussteller aus.

Nutzer wählt Aussteller in der Benutzeroberfläche von Google aus

In diesem Fall wählt der Nutzer bei der Auswahl des Zahlungsmittels in der Google-Benutzeroberfläche einen Aussteller aus. Daher enthält das Feld issuerId des Objekts formOfPayment in RedirectRequest eine von Google generierte eindeutige Kennung, die einen Aussteller darstellt. Wenn der Zahlungsintegrator und der Aussteller dieselbe Rechtspersönlichkeit sind, generiert Google ein issuerId für den Zahlungsintegrator. Für die Weiterleitungsanfrage wird eine HTTPS-GET-Methode verwendet, bei der die Parameter in der URL codiert sind.

Weiterleitungsvorgang starten (Aussteller ausgewählt)

Das folgende Sequenzdiagramm zeigt die Interaktion zwischen dem Browser des Nutzers, Google, dem Integrator und dem Aussteller, wenn der Nutzer in der Benutzeroberfläche von Google einen Aussteller auswählt:

Weiterleitung mit ausgewähltem Aussteller starten

Hier ist die Liste der Objekte im obigen Diagramm:

  • Nutzer: Person, die eine Zahlung ausführen möchte.
  • Google-UI: die Web- oder App-Oberfläche von Google, über die der Kunde eine Zahlung veranlasst.
  • Google-Server: Der Back-End-Server bei Google, der eine Weiterleitungsanfrage erstellt.
  • Zahlungsintegrator: Der Integrator, der den Nutzer und die Weiterleitungsanfrage an den Aussteller weiterleitet.
  • Aussteller: Der Aussteller, bei dem der Nutzer ein Konto hat.

Beim Vorgang „Weiterleitung beginnen“ gehen wir davon aus, dass sich der Nutzer im Google-Produkt (Google-UI) befindet und eine Zahlungsmethode auswählt. Hier fängt alles an.

  1. Der Nutzer wählt den Aussteller aus, mit dem er eine Zahlung ausführen möchte. Dadurch wird der Vorgang „Weiterleitung beginnen“ ausgelöst.
  2. Die Google-Benutzeroberfläche ruft den Google-Server (Back-End) auf, um eine neue Weiterleitungsanfrage zu erstellen.
  3. Der Google-Server erstellt eine Weiterleitungsanfrage.
  4. Die Weiterleitungsanfrage wird an die Google-Benutzeroberfläche gesendet.
  5. Die Google-Benutzeroberfläche leitet den Nutzer zum Server des Integrators weiter.
  6. Der Integrationspartner verarbeitet die Weiterleitungsanfrage von Google und generiert eine ausstellerspezifische Weiterleitungsanfrage.
  7. Der Integrator leitet den Nutzer zur Weboberfläche des Ausstellers weiter.
  8. Der Nutzer authentifiziert sich in der Weboberfläche des Ausstellers.
  9. Der Nutzer folgt der Anleitung auf dem Bildschirm, um die Zahlung abzuschließen.

Nutzer wählt Integrator in der Benutzeroberfläche von Google aus

In diesem Fall wählt der Nutzer den Integrator auf der Benutzeroberfläche von Google aus. Daher wird das Feld formOfPayment von RedirectRequest auf noneChosen gesetzt, weil nur Aussteller als gültige Zahlungsmethoden gelten. Der Integrator muss eine UI bereitstellen, über die der Nutzer einen der von Google genehmigten Aussteller auswählen kann. Für die Weiterleitungsanfrage wird eine HTTPS-GET-Methode verwendet, bei der die Parameter in der URL codiert sind.

Ablauf mit Weiterleitung beginnen (Integrator ausgewählt)

Das folgende Sequenzdiagramm zeigt die Interaktion zwischen dem Browser des Nutzers, Google, dem Integrator und dem Aussteller, wenn der Nutzer einen Integrator in der Benutzeroberfläche von Google auswählt:

Ablauf „Weiterleitung“ bei ausgewähltem Integrator starten

Hier ist die Liste der Objekte im obigen Diagramm:

  • Nutzer: Person, die eine Zahlung ausführen möchte.
  • Google-UI: die Web- oder App-Oberfläche von Google, über die der Kunde eine Zahlung veranlasst.
  • Google-Server: Der Back-End-Server bei Google, der eine Weiterleitungsanfrage erstellt.
  • Zahlungsintegrator: Der Integrator, bei dem der Nutzer einen Aussteller auswählt.
  • Aussteller: Der Aussteller, bei dem der Nutzer ein Konto hat.

Beim Vorgang „Weiterleitung beginnen“ gehen wir davon aus, dass sich der Nutzer im Google-Produkt (Google-UI) befindet und eine Zahlungsmethode auswählt. Hier fängt alles an.

  1. Der Nutzer wählt einen Integrator (nicht einen bestimmten Aussteller) für die Zahlung aus. Dadurch wird der Vorgang „Weiterleitung beginnen“ ausgelöst.
  2. Die Google-Benutzeroberfläche ruft den Google-Server (Back-End) auf, um eine neue Weiterleitungsanfrage zu erstellen.
  3. Der Google-Server erstellt eine Weiterleitungsanfrage.
  4. Die Weiterleitungsanfrage wird an die Google-Benutzeroberfläche gesendet.
  5. Die Google-Benutzeroberfläche leitet den Nutzer zur Weboberfläche des Integrators weiter.
  6. Der Integrator verarbeitet die Weiterleitungsanfrage von Google.
  7. Der Integrator zeigt dem Nutzer die verfügbaren Aussteller an.
  8. Der Nutzer wählt den Aussteller aus, mit dem er eine Zahlung ausführen möchte.
  9. Der Integrator generiert eine ausstellerspezifische Weiterleitungsanfrage.
  10. Der Integrator leitet den Nutzer zur Weboberfläche des Ausstellers weiter.
  11. Der Nutzer authentifiziert sich in der Weboberfläche des Ausstellers.
  12. Der Nutzer folgt der Anleitung auf dem Bildschirm, um die Zahlung abzuschließen.

Best Practices und weitere Überlegungen

Sicherheitsmaßnahmen

Die URL der Weiterleitungsanfrage enthält ein unverschlüsseltes callbackUrl-Feld und ein verschlüsseltes redirectRequest-Feld. Beide Felder enthalten das requestId für die aktuelle Transaktion. Der Anbieter sollte prüfen, ob die requestId sowohl in der callbackUrl als auch in der verschlüsselten Nutzlast identisch ist, um zu prüfen, ob sie zusammenhängen.