Sowohl 3DS1 als auch 3DS2 sind mit der End-to-End-Integration von Reservierungen im Actions Center kompatibel. Du kannst eine oder auch beide Methoden implementieren.
Sowohl 3DS1 als auch 3DS2 erfüllen die Anforderung zur starken Kundenauthentifizierung für PSD2, es gibt aber einige wichtige Unterschiede:
- 3DS1: Du kannst 3DS1 für eine Transaktion auslösen, wenn es Anzeichen für betrügerische Belastungen gibt.
- Für die Implementierung von 3DS1 sind Änderungen an deinem Buchungsserver erforderlich.
- 3DS2: 3DS2 wird nur für Transaktionen verwendet, für die PSD2 gilt (die ausführende Bank und die Bank des Kunden befinden sich im EWR).
- Für die Implementierung von 3DS2 sind Änderungen an deinem Händlerfeed erforderlich.
Implementierung von 3DS2
Um 3DS2 zu implementieren, musst du deinem Händlerfeed in der TokenizationConfig-Nachricht zusätzliche Felder hinzufügen. Wenn alle Zahlungen auf dasselbe Konto erfolgen, musst du den Wert in jedem Händlereintrag wiederholen. Sollten die Zahlungen auf verschiedene Konten erfolgen, muss jeder Händlereintrag die Werte für das entsprechende Konto enthalten.
Änderungen am Händlerfeed
merchant_of_record_name: Name des Merchant of Record (Vertragspartners). Dieser für Nutzer sichtbare Name wird in 3DS2-Aufforderungen angezeigt.payment_country_code: ISO 3166-1 Alpha-2-Ländercode für das Land, in dem die Transaktion verarbeitet wird.CardNetworkParameters-Nachricht: Diese Nachricht wird mit den Werten für verschiedene Netzwerke wiederholt (nur für Visa und American Express erforderlich).card_network: Das Netzwerk (Visa, American Express), für das diese Werte gelten.acquirer_bin: Die Bank Identification Number (BIN) der ausführenden Bank für die Verarbeitung der Karte.acquirer_merchant_id: Die Händler-ID, die die ausführende Bank dem Händler für die Transaktionsautorisierung zugewiesen hat (für Visa- und American Express-Transaktionen).
Wenn du diese Felder in deinen Händlerfeed einfügst, erhältst du ein 3DS2-Kryptogramm im unparsed_payment_method_token, das von deinem Buchungsserver empfangen wird, wenn PSD2 für die Transaktion gilt. Du solltest das unparsed_payment_method_token und sein eingebettetes Kryptogramm gemäß der Spezifikation deines Abwicklers an diesen übergeben.
Implementierung von 3DS1
Änderungen am Buchungsserver
Wir stellen eine CreateBooking-Anfrage. Wenn du feststellst, dass 3DS1 für die Transaktion erforderlich ist, gibst du einen Booking Failure aus deiner CreateBooking-Methode zurück. Dabei musst du PAYMENT_REQUIRES_3DS1 als Ursache angeben. In dieser Fehlerantwort musst du auch die ThreeDS1Parameters-Nachricht innerhalb der PaymentFailureInformation-Nachricht angeben:
acs_url: Die URL, von der ein Formular geladen wird, das dem Nutzer zur Authentifizierung angezeigt wird.pa_req: Eine PaymentAuthentication-Anfrage. Wird an das ACSUrl-Formular gesendet.transaction_id: Eine vom ACS-Anbieter verwendete Kennung. Wird an das ACSUrl-Formular gesendet.md_merchant_data: Daten für das Actions Center, die mit dem ACS-Anbieter geteilt werden, sofern angegeben.
Anschließend senden wir die ursprüngliche CreateBooking-Anfrage mit der pa_response in der PaymentInformation-Nachricht noch einmal. Das Feld pa_response enthält die Nutzlast, die von einem ACS-Anbieter an uns zurückgegeben wird. Du solltest es verwenden, um die Transaktion bei deinem Zahlungsabwickler zu autorisieren.
Das folgende Diagramm veranschaulicht den 3DS1-Ablauf:
