Letzte Aktualisierung 19/06/2014

2. 3-D Secure v2.1 (Verfügbar in Test)

2.1 Introduction

Im Jahr 2013 veröffentlichte die Europäische Kommission einen Vorschlag für die überarbeitete Version der Richtlinie über Zahlungsdienste (PSD2) zur Vereinfachung der Zahlungsabwicklung und Erstellung von Regeln und Vorschriften für Zahlungsdienste in der EU. Dort wurde auch die Notwendigkeit einer neuen Version von 3D Secure v2.1 erkannt.

Die größte Änderung besteht darin, dass Sie als Händler aufgefordert werden, mehr Daten zu teilen: Die Emittenten verlangen nach Datenpunkten zur Verbesserung der Genauigkeit ihrer Entscheidung, was letztendlich zu einem reibungslosen Szenario führt, aber Sie sind an der vordersten Front, um die Daten zu erfassen. Der 3DS v2-Ansatz zur Risikobewertung ist effektiver, erfordert jedoch eine Änderung des gesamten Ökosystems, sodass Sie die Daten an den Emittenten weitergeben können. 

Die Kreditkartenunternehmen haben mit der Einführung dieser neuen Richtlinie außerdem ihre 3DS-Logos aktualisiert. Da Sie Ihre eigene Zahlungsseite erstellen, sollten Sie dafür sorgen, dass Sie diese neuen Logos Ihrer Zahlungsseite hinzufügen (Visa / Mastercard / JCB /… ).

Der Transaktionsfluss umfasst die folgenden Schritte:

1. Sie senden uns eine DirectLink-Anfrage für die Transaktion mit einer Reihe zusätzlicher Parameter. 

Diese Parameter können aus drei Sätzen bestehen:

a. Erforderliche Parameter, die auf der Zahlungsseite erfasst werden müssen, auf der der Karteninhaber die Kartendaten eingibt.

Parameter Beschreibung Format  Verpflichtend 
browserAcceptHeader

Exakter Inhalt des von HTTP akzeptierten Headers, die vom Browser des Karteninhabers an den Händler gesendet werden.*

 Länge: variabel, maximal 2.048 Zeichen Datentyp: String Gültiger Wert: Wenn die Gesamtlänge des vom Browser gesendeten akzeptierten Headers 2.048 Zeichen überschreitet, schneidet der 3DS-Server den überschüssigen Teil ab.  Ja
browserColorDepth Wert, der die Bittiefe der Farbpalette für die Anzeige von Bildern in Bit pro Pixel darstellt. Wird vom Karteninhaber-Browser unter Verwendung der Bildschirmfarbeigenschaft ‚Tiefe‘ abgerufen. Datentyp: String
Gültige Werte:
1 = 1 Bit
4 = 4 Bit
8 = 8 Bit
5 = 15 Bit
16 = 16 Bit
24 = 24 Bit
32 = 32 Bit
48 = 48 Bit
 Ja
browserJavaEnabled Boolescher Wert, ob der Karteninhaber-Browser Java ausführen kann. Der Wert wird vom Attribut „Navigator-Java aktiviert“ zurückgegeben. Datentyp: Boolescher Wert
Gültige Werte:
wahr
falsch
 Ja
browserLanguage Wert, der die Browser-Sprache wie in IETF BCP47 definiert darstellt. Aus dem Attribut „Navigatorsprache“ zurückgegeben. JSON-Datentyp: String
Länge: variabel, 1–8 Zeichen
 Ja
browserScreenHeight Gesamthöhe des Karteninhaber-Bildschirms in Pixeln. Der Wert wird vom Attribut „Bildschirmhöhe“ wiedergegeben. Datentyp: Int
Zwischen 0 und 999999
 Ja
browserScreenWidth Gesamtbreite des Karteninhaber-Bildschirms in Pixeln. Der Wert wird vom Attribut „Bildschirmbreite“ wiedergegeben. Datentyp: Int 
Zwischen 0 und 999999
 Ja
browserTimeZone Zeitunterschied zwischen UTC-Zeit und Ortszeit des Karteninhaber-Browsers in Minuten. Datentyp: Int
Zwischen -720 und 840
 Ja
browserUserAgent Genauer Inhalt des HTTP-Benutzeragent-Headers. * Datentyp: String
Länge: variabel, maximal 2.048 Zeichen
Hinweis: Wenn die Gesamtlänge des vom Browser gesendeten Benutzeragents 2.048 Zeichen überschreitet, schneidet der 3DS-Server den überschüssigen Teil ab.
 Ja

*HTTP_ACCEPT und HTTP_USER_AGENT müssen nicht mit browserAcceptHeader und browserUserAgent gesendet werden, da wir sie sonst mit den Browserparametern füllen.

Hinweis: Bitte vergessen Sie nicht, die Parameter in Ihrer SHA-Signatur zu berechnen.

Sie können den folgenden Javascript-Code verwenden, um diese Parameter zu erfassen.

<script type="text/javascript" language="javascript">

function createHiddenInput(form, name, value)
{
var input = document.createElement("input");
input.setAttribute("type", "hidden");
input.setAttribute("name", name); 
input.setAttribute("value", value);
form.appendChild(input);
}

var myCCForms = document.getElementsByName("MyForm");
if (myCCForms != null && myCCForms.length > 0)
{
var myCCForm = myCCForms[0];
createHiddenInput(myCCForm, "browserColorDepth", screen.colorDepth);
createHiddenInput(myCCForm, "browserJavaEnabled", navigator.javaEnabled());
createHiddenInput(myCCForm, "browserLanguage", navigator.language);
createHiddenInput(myCCForm, "browserScreenHeight", screen.height);
createHiddenInput(myCCForm, "browserScreenWidth", screen.width);
createHiddenInput(myCCForm, "browserTimeZone", new Date().getTimezoneOffset());
}
</script>

b. Zusätzliche benötigte Parameter (vgl. Zusätzliche Anfrageparameter).

c. Empfohlene Parameter (Liste der Parameter) die, wenn gesendet, sich positiv auf die Transaktions-Conversion-Rate auswirken. Basierend auf den in diesen Parametern enthaltenen Informationen kann ein potenzieller reibungsloser Authentifizierungsablauf stattfinden. Dabei muss sich der Karteninhaber nicht mehr authentifizieren und daher wird ein schnellerer Abschluss der Transaktion erwartet. Wenn jedoch keiner dieser Parameter angegeben wird, findet die normale Umleitung in Bezug auf die Authentifizierung statt.

Unser System empfängt die Kartennummer in Ihrer Anfrage und prüft online, ob die Karte im VISA-, Mastercard-, JCB- bzw. AmEx-Verzeichnis eingetragen ist (eingetragen bedeutet, dass eine Identifikation für die Kartennummer möglich ist, d. h. die Karte ist eine 3-D Secure-Karte).

2. Basierend auf der Systemverzeichnisantwort werden zwei potenzielle Flüsse erwartet, wenn der Karteninhaber registriert wird (in 3D Secure), wobei zu berücksichtigen ist, ob die zusätzlichen Parameter in 1.c (Empfohlene Parameter-Liste der Parameter) oben angegeben wurden:

2.1. Ein reibungsloser Fluss: Der Karteninhaber muss sich nicht physisch authentifizieren, da die Authentifizierung im Hintergrund ohne Eingabe erfolgt. In diesem Fall erfolgt die Haftungsschicht bei der ausstellenden Bank.

2.2. Ein problematischer Fluss: Der Karteninhaber muss sich weiter ausweisen.

i. Die Antwort auf die DirectLink-Anfrage enthält einen bestimmten Zahlungsstatus und einen HTML-Code. Dieser muss an den Kunden zurückgegeben werden, um den Identifikationsprozess zu starten (siehe Zusätzliche Rückgabefelder). Der HTML-Code-Block startet automatisch den Identifikationsprozess zwischen dem Karteninhaber (Kunden) und seiner ausstellenden Bank.

ii. Der Karteninhaber identifiziert sich selbst auf der Seite der ausstellenden Bank.

iii. Unser System empfängt die Identifikationsantwort vom Aussteller.

iv. Wenn die Identifikation erfolgreich war, übermittelt unser System die eigentliche Finanztransaktion an den Acquirer.

3. Das Ergebnis der globalen Identifikation und des Online-Autorisierungsvorgangs erhalten Sie über e-Commerce-Modus-Rückmeldungskanäle.

Neben den DirectLink-Standardparametern müssen auch folgende Informationen gesendet werden:

Feld Beschreibung
FLAG3D

Fester Wert: "Y"

Weist unser System an, bei Bedarf 3-D Secure-Identifikation auszuführen.
HTTP_ACCEPT Das Feld „Accept request header“ im Browser des Karteninhabers, mit dem angegeben wird, welche Medientypen für die Antwort angenommen werden können. Mit diesem Wert kontrolliert der Aussteller, ob der Browser des Karteninhabers mit dem Identifikationssystem des Ausstellers kompatibel ist. *
 Zum Beispiel:
Accept: */*
HTTP_USER_AGENT Das Feld „User-Agent request-header“ im Browser des Karteninhabers mit Informationen über den User Agent, von dem die Anfrage ausgeht. Mit diesem Wert kontrolliert der Aussteller, ob der Browser des Karteninhabers mit dem Identifikationssystem des Ausstellers kompatibel ist. *
 Zum Beispiel: User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0).
WIN3DS

Möglichkeit, dem Kunden die Identifikationsseite anzuzeigen. Mögliche Werte:

  • MAINW: Die Identifikationsseite im Hauptfenster anzeigen (Standardwert).
  • POPUP: Die Identifikationsseite in einem Popup-Fenster anzeigen und am Ende zum Hauptfenster zurückkehren.
  • POPIX: Die Identifikationsseite in einem Popup-Fenster anzeigen und im Popup-Fenster bleiben.
ACCEPTURL URL der Webseite, die dem Kunden angezeigt wird, wenn die Zahlung autorisiert ist.
DECLINEURL URL, an die der Kunde weitergeleitet wird, wenn die maximale Anzahl an fehlgeschlagenen Autorisierungsversuchen erreicht ist (Standardwert 10, er kann aber auf der Seite „Technische Informationen“, Registerkarte „Globale Transaktionsparameter“, Abschnitt „Zahlungswiederholungsversuche“ geändert werden).
EXCEPTIONURL URL der Webseite, die dem Kunden angezeigt wird, wenn das Zahlungsergebnis unsicher ist.
PARAMPLUS Feld zum Senden der verschiedenen Parameter und ihrer Werte, die in der Post-Sale-Anfrage oder in der endgültigen Weiterleitung zurückgegeben werden sollen.
COMPLUS Feld zum Senden eines Wertes, der in der Post-Sale-Anfrage oder in der Ausgabe zurückgegeben werden soll.
LANGUAGE Sprache des Kunden, zum Beispiel: "en_US"
Optional
TP Um das Layout der "order_A3DS"-Seite zu ändern, können Sie eine(n) Templatenamen/-URL mit diesem Parameter senden.
e-Commerce: Dynamische Vorlage).

*HTTP_ACCEPT und HTTP_USER_AGENT müssen beim Senden von browserAcceptHeader und browserUserAgent nicht gesendet werden.

Für weitere Informationen siehe Transaction-feedback.

Wenn der Karteninhaber nicht registriert ist, wird die normale DirectLink-Antwort zurückgegeben. Wenn der Karteninhaber registriert ist, werden die folgenden (zusätzlichen) Felder zurückgegeben:

Field Beschreibung
STATUS
Neuer Wert: "46" (Warten auf Identifikation)
HTML_ANSWER

BASE64-codierter HTML-Code zum Einfügen auf der HTML-Seite, die an den Kunden zurückgegeben wird.

Dieser Tag wird als untergeordnetes Element des globalen XML-Tags <ncresponse> hinzugefügt. Das Feld HTML_ANSWER enthält HTML-Code, der in die HTML-Seite, die an den Kunden zurückgegeben wird, eingefügt werden muss.

Dieser Code lädt automatisch die Identifikationsseite der ausstellenden Bank in einem Pop-up im Hauptfenster in Abhängigkeit vom Parameterwert WIN3DS.

Damit es nicht zu Wechselwirkungen zwischen HTML-Tags im Inhalt des XML-Tags HTML_ANSWER mit dem übrigen XML-Code kommt, der als Antwort auf die DirectLink-Anfrage ausgegeben wird, wird der Inhalt von HTML_ANSWER vor Ausgabe der Antwort BASE64-codiert. Deshalb muss dieser Inhalt BASE64-decodiert werden, bevor er in die HTML-Seite, die an den Karteninhaber gesendet wird, eingefügt wird.

Testkarten

Mit den folgenden Testkarten können Sie eine registrierte 3-D Secure-Karte in unserer Testumgebung simulieren:

Reibungsloser Fluss
Marke Kartenummer Ablaufdatum
VISA 4186455175836497 Beliebiges Datum in der Zukunft
Mastercard
5137009801943438 Beliebiges Datum in der Zukunft
American Express
375418081197346 Beliebiges Datum in der Zukunft

Problematischer Fluss
Marke Kartenummer Ablaufdatum
VISA 4874970686672022 Beliebiges Datum in der Zukunft
Mastercard
5130257474533310 Beliebiges Datum in der Zukunft
American Express
379764422997381 Beliebiges Datum in der Zukunft

Hinweis: Weitere Testkartennummern können hier heruntergeladen werden

Falsche Identifikation

Wenn eine Transaktion wegen einer fehlerhaften Identifikation blockiert ist, hat die Transaktion das Ergebnis:

STATUS = 0

NCSTATUS = 5

NCERROR = 40001134

© 2019 Viveum Zahlungssysteme GmbH