Google Pay™ 3DS-Verarbeitung für PAN_ONLY-Payload

Bitte beachten Sie, dass Zahlungen aufgrund der PSD2-Verordnung eine SCA (Starke Kundenautenrisierung) aufweisen müssen. Dies gilt auch für Google Pay™. Google Pay™ bietet im Allgemeinen zwei Arten von PAyloads mit Zahlungsdaten an.

Bei der Payload CRYPTOGRAM_3DS ist die Zahlung bereits auf dem Kundengerät SCA-authentifiziert und die Payload enthält einen Authentifizierungsnachweis. Daher ist keine zusätzliche SCA in Form von 3-D Secure erforderlich.

Bei der Payload PAN_ONLY sind die Zahlungsdaten nicht SCA-authentifiziert. Um Soft Declines zu vermeiden, ist daher eine 3-D Secure-Authentifizierung erforderlich.

Nachstehende Anleitung beschreibt, wie 3-D Secure 2.0 für Google-Pay-Zahlungen angewendet werden kann.

Diese Anleitung kann für alle Google-Pay-Zahlungen angewendet werden, da PAN_ONLY-Nutzdaten dynamisch erkannt und der 3-D Secure-Prozess gestartet wird. Im Falle der CRYPTOGRAM_3DS-Nutzdaten wird 3-D Secure nicht gestartet.


Eine 3DS 2.0 Zahlungssequenz kann aus den folgenden verschiedenen Aktivitäten bestehen:

  • Versionierung
    • Anfrage von ACS- und DS-Protokol-Version(en), die mit dem Kartenkontenbereich korrespondieren sowie einer optionalen 3DS Method URL

  • 3DS Methode

    • Verbindet den Browser des Karteninhabers mit dem ACS des Issuers, um zusätzliche Browserdaten zu erhalten

  • Authentisierung

    • Übermittlung der Authentisierungs-Anfrage an den ACS des Issuers

  • Challenge

    • Challenge des Karteninhabers, falls angeordnet

  • Autorisierung

    • Autorisierung der authentisierten Transaktion beim Acquirer

Server-2-Server Sequenzdiagramm

Beachten Sie bitte, dass die Kommunikation zwischen Client und Access Control Server (ACS) über iFrames implementiert ist. Daher kommen die Antworten in einem HTML-Subdokument an und Sie können entsprechende Event-Listener in Ihrem Root-Dokument einrichten.

Alternativ könnten Sie alleinig auf die asynchronen Benachrichtigungen an ihr Backend vertrauen. In jenen Fällen müssen Sie eventuell Methoden wie Long Polling, SSE oder Websockets zum Update des Clients in Betracht ziehen.





Initiierung der Zahlung

Die anfängliche Anfrage an das  ist unabhängig vom zugrundeliegenden 3DS-Protokoll gleich.

Um eine Server-zu-Server 3-D Secure Kartenzahlungssequenz zu starten, senden Sie bitte folgende Schlüssel-Wert-Paare an direct.aspx.



Aufruf der Schnittstelle: allgemeine Parameter

Um eine Zahlung mit Google Pay über eine Server-zu-Server-Verbindung auszuführen, verwenden Sie bitte folgende URL:

googlepay.aspx

Aufruf-Elemente

 

Allgemeine Parameter für Kreditkartenzahlungen über Socket-Verbindungen

(info) Beachten Sie bitte die zusätzlichen Parameter für eine spezifische Kreditkartenintegration im Abschnitt „Spezifische Parameter“



Antwort-Elemente (Authentisierung)



versioningData

Das Objekt versioningData gibt die EMV 3DS Protokoll-Versionen (d.h. 2.1.0 oder höher) an, die vom Access Control Server des Issuers unterstützt werden.

Wenn die entsprechenden Felder der Protokoll-Version NULL sind, bedeutet dies, dass der BIN-Bereich des Karten-Issuers nicht für 3DS 2.0 registriert ist und ein Fallback auf 3DS 1.0 für Transaktionen erforderlich ist, die unter den Geltungsbereich der PSD2 SCA fallen.

Achten Sie beim Zerlegen von versioningData bitte auch auf das Subelement errorDetails, das den Grund angibt, falls einige Felder nicht ausgefüllt sind (z.B. Ungültige Kontonumber des Karteninhabers übergeben, nicht verfügbare Kartenbereichsdaten, Fehler beo Codieren/Serialisieren der 3DS Methoden-Daten usw.)

(info) BASEURL=



3-D Secure-Methode

Die 3DS Methode ermöglicht das Erfassen zusätzlicher Browserinformationen durch einen ACS vor Erhalt der Authensisierungsanfrage (AReq), um die Risikobeurteilung der Transaktion zu erleichtern. Die Unterstützung der 3DS Methode ist optional und liegt im Ermessen des Issuers.

Das Objekt versioningData enthält einen Wert für threeDSMethodURL. Der Händler sollte die 3DS Methode über einen versteckten HTML-iFrame im Browser des Karteninhabers aufrufen und ein Formular mit einem Feld namens threeDSMethodData über HTTP POST an die ACS 3DS Methoden-URL senden.

3-D Secure-Methode: threeDSMethodURL

Beachten Sie bitte, dass die threeDSMethodURL vom  ausgefüllt wird, falls der Issuer die 3DS Methode nicht unterstützt. Der 3DS Methoden-Formular-Post wie unten dargestellt muss unabhängig davon ausgeführt werden, ob dies vom Issuer unterstützt wird. Das ist notwending, um die direkte Kommunikation zwischen dem Browser und dem  im Falle einer angeordneten Challenge oder eines reibungslosen Ablaufs zu erleichtern.

3-D Secure-Methode: Keine Issuer threeDSMethodURL

3-D Secure-Methode Form Post

Der ACS interagiert mit dem Browser des Karteninhabers über den HTML-iFrame und speichert dann die zutreffenden Werte mit der 3DS Server Transaction ID für die Verwendung, wenn eine nachfolgende Authentisierungs-Nachricht empfangen wird, welche die gleiche 3DS Server Transaction ID enthält.


Sie können nach eigenem Ermessen die Operationen init3DSMethod oder createIframeAndInit3DSMethod vom nca3DSWebSDK verwenden, um die 3DS Methode zu initialisieren. Bitte beachten Sie dazu das Integrations-Handbuch unter https://mpi.netcetera.com/3dsserver/doc/current/integration.html#Web_Service_API.

Nachdem die 3DS-Methode abgeschlossen ist, weist der ACS den Browser des Karteninhabers über das iFrame-Antwortdokument an, threeDSMethodData als ein verstecktes Formularfeld an die 3DS Method Notification URL zu übermitteln.

ACS Response-Dokument

3-D Secure-Methode Benachrichtigungs-Formular


Beachten SIe bitte, dass die threeDSMethodNotificationURL wie sie in den Base64-codierten threeDSMethodData eingebettet ist, auf das  weist und nicht verändert werden darf. Die Händler-Benachrichtigung wird an die URLNotify geliefert, wie sie in der Originalanfrage übermittelt oder für die MerchantID im  konfiguriert ist.


Authentisierung

Wenn die 3DS-Methode vom ACS des Issuers unterstützt wird und vom Händler aufgerufen wurde, setzt das  automatisch mit der Authentisierungsanfrage fort, nachdem die 3DS-Methode abgeschlossen ist (d.h. 3DS Methoden-Benachrichtigung).

Das Ergebnis der Authentisierung wird per HTTP POST an die URLNotify übertragen. Es kann anzeigen, dass der Karteninhaber authentisiert worden ist oder dass eine weitere Interaktion des Karteninhabers (d.h. Challenge) für den Abschluss der Authentisierung erforderlich ist.

Falls für den Karteninhaber eine Challenge für nötig angesehen ist, überträgt das  ein JSON-Objekt im Body der HTTP Browser-Antwort mit den Elementen acsChallengeMandated, challengeRequest, base64EncodedChallengeRequest und acsURL. Anderenfalls setzt das  in einem reibungslosen Ablauf automatisch fort und antwortet dem Browser des Karteninhabers, sobald die Autorisierung abgeschlossen ist.

Karteninhaber-Challenge: Browser-Antwort

Browser Challenge-Antwort

Datenelemente

Schema: Browser Challenge-Antwort

Beispiel: Browser Challenge-Antwort

Authentisierungs-Benachrichtigung

Die Datenelemente der Authentisierungs-Benachrichtigung stehen in folgender Tabelle.

Browser Challenge

Wenn eine Challenge für nötig angesehen wird (siehe challengeRequest), erfolgt die Browser Challenge im Browser des Karteninhabers. Zum Erzeugen einer Challenge ist es erforderlich, den Wert base64EncodedChallengeRequest über ein HTML-iFrame an die ACS URL zu posten.

Challenge-Anfrage

Sie können die Operationen init3DSChallengeRequest oder createIFrameAndInit3DSChallengeRequest aus dem nca3DSWebSDK verwenden, um die Challenge-Nachricht an den Browser des Karteninhabers zu übermitteln.

3DS Challenge-Anfrage initialisieren - Beispiel

Sobald die Challenge des Karteninhabers abgeschlossen, abgebrochen oder per Zeitüberschreitung beendet ist, weist der ACS den Browser an, die Ergebnisse per Post an die in der Challenge-Anfrage angegebene Benachrichtigungs-URL zu senden und eine Ergebnis-Anfrage (RReq) über den Directory Server an den 3DS Server zu senden.

Beachten Sie bitte, dass die in der Challenge-Anfrage übergebene Benachrichtigungs-URL auf das  zeigt und nicht verändert werden darf.



Autorisierung

Nachdem die erfolgreiche Authentisierung des Karteninhabers oder der Nachweis der versuchten Authentisierung/Verifizierung bereitgestellt ist, setzt das  die Zahlungsautorisierung automatisch fort.

Falls die Authentisierung des Karteninhabers nicht erfolgreich war oder der Nachweise der versuchten Authentisierung/Verifizierung nicht bereitgestellt werden kann, setzt das  nicht mit einer Autorisierungsanfrage fort.

In beiden Fällen liefert das  eine Benachrichtigung mit dem Ergebnis der Authentifizierung an die vom Händler angegebene URLNotify mit den Datenelementen gemäß nachstehender Tabelle.

Zahlungs-Benachrichtigung

 

Browser Zahlungs-Antwort

Zusätzlich werden nachstehende Datenelemente im JSON-Format im Body der HTTP-Antwort zum Browser des Karteninhabers übertragen. Beachten Sie bitte, dass die Datenelemente (d.h. MID, Len, Data) base64-codiert sind.

Datenelemente

Schema

Händler sollten diese Datenelemente zur Entschlüsselung und für den Abgleich mit der Zahlungs-Benachrichtigung am ihren Server weiterleiten. Basierend auf dem Zahlungsergebnis kann der Händler-Server eine entsprechende Antwort an den Browser des Karteninhabers senden (z.B. Erfolgsseite).

Entschlüsseltes Objekt Data

Beispiel für entschlüsseltes Objekt Data