Sowohl 3DS1 als auch 3DS2 stehen für die End-to-End-Integration von Actions Center-Reservierungen zur Verfügung. Du kannst eine (oder beide) für deine Integration implementieren.
3DS1 oder 3DS2 erfüllen die Anforderung zur starken Kundenauthentifizierung für PSD2. Es gibt jedoch einige wichtige Unterschiede:
- 3DS1: Du kannst 3DS1 für eine Transaktion auslösen, wenn du Anzeichen für eine betrügerische Belastung hast.
- 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
Für die Implementierung von 3DS2 musst du deinem Händlerfeed in der TokenizationConfig-Nachricht zusätzliche Felder hinzufügen. Wenn alle Zahlungen auf dasselbe Konto erfolgen, wird der Wert in jedem Händlereintrag wiederholt. Wenn die Zahlungen an verschiedene Konten erfolgen, müssen die Werte in jedem Händlereintrag für das Konto gelten, auf das der Betrag im Rahmen der Transaktion überwiesen wird.
Änderungen am Händlerfeed
merchant_of_record_name: Name des Merchant Of Record (Vertragspartner) (MOR). Dieser für Nutzer sichtbare Name wird in 3DS2-Wettkämpfen angezeigt.payment_country_code: Land, in dem die Transaktion verarbeitet wird, im Format ISO 3166-1 alpha-2.CardNetworkParameters-Nachricht: Diese Nachricht wird mit den Werten wiederholt, die für verschiedene Netzwerke spezifisch sind (nur für Visa und American Express erforderlich).card_network: Das Netzwerk (Visa, American Express), für das diese Werte gelten.acquirer_bin: Die Bankidentifikationsnummer 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 deinem Händlerfeed hinzufügst, erhältst du ein 3DS2-Kryptogramm innerhalb der 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 das eingebettete Kryptogramm gemäß dessen Spezifikation an deinen Verarbeitungspartner übergeben.
Implementierung von 3DS1
Änderungen am Buchungsserver
Wir senden eine CreateBooking-Anfrage. Wenn du feststellst, dass 3DS1 für die Transaktion erforderlich ist, gib ein Booking Failure aus deiner CreateBooking-Methode zurück und gib PAYMENT_REQUIRES_3DS1 als Ursache an. In dieser Fehlerantwort müssen Sie auch die Nachricht ThreeDS1Parameters innerhalb der Nachricht PaymentFailureInformation 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, die vom Actions Center an den ACS-Anbieter weitergegeben werden, sofern angegeben.
Wir senden dann die ursprüngliche CreateBooking-Anfrage noch einmal mit der pa_response in der PaymentInformation-Nachricht. Das Feld pa_response enthält die Nutzlast, die von einem ACS-Anbieter an uns zurückgegeben wird. Sie sollte von dir verwendet werden, um die Transaktion bei deinem Abwickler zu autorisieren.
Das folgende Diagramm veranschaulicht den 3DS1-Ablauf:
