1 Allgemeine Vorgehensweisen und Sicherheitseinstellungen
   1.1 API-Benutzer
   1.2 Anfrageformat
   1.3 Sicherheit
      1.3.1 Verschlüsselung
      1.3.2 IP-Adresse
      1.3.3 Zusätzliche Sicherheit: SHA-Signatur
   1.4 Auswertung der Antwort (Parsing)
2 Neue Bestellungen anfragen
   2.1 Anfrage-URL
   2.2 Anfrageparameter
   2.3 Testseite
   2.4 Ausschluss spezifischer Zahlungsmethoden
   2.5 Bestellanforderungen mit 3-D Secure
   2.6 Aufteilung Kredit/Debit
   2.7 Transaktionen mit gespeicherten Anmeldedaten abwickeln
3 Rückmeldung zur Bestellung
   3.1 Duplicate request
4 Direkte Datenpflege: Pflege bestehender Bestellungsdaten
   4.1 Datenpflege-Anfrage
      4.1.1 Anfrage-URL
      4.1.2 Anfrageparameter
      4.1.3 Testseite
   4.2 Datenpflege-Antwort
   4.3 Doppelte Anfrage
5 Direktabruf: Bestellstatus abrufen
   5.1 Abruf-Anfrage
      5.1.1 Anfrage-URL
      5.1.2 Anfrageparameter
      5.1.3 Testseite
   5.2 Abruf-Antwort
      5.2.1 Mit e-Commerce verarbeitete Transaktionen
   5.3 Mögliche rückgemeldete Statuszustände
   5.4 Direktabruf als Fallback
6 Datenschutzrichtlinie-Anforderung
   6.1 Abruf-Anfrage
      6.1.1 Query-Anforderung
      6.1.2 Anforderungsparameter
      6.1.3 Testseite
   6.2 Abruf-Antwort
7 PM-Ausnahmen
   7.1 Direct Debits
      7.1.1 Direct Debits AT
      7.1.2 Direct Debits DE (ELV)
      7.1.3 Direct Debits NL
   7.2 PM nur mit Datenpflege möglich über DirectLink
8 3-D Secure v1.0
   8.1 Einleitung
   8.2 Ablauf der 3-D-Transaktion über DirectLink
      8.2.1 Zusätzliche Anfrageparameter
      8.2.2 Zusätzliche Rückgabefelder
      8.2.3 Anmerkungen
9 3-D Secure v2.1
   9.1 Introduction
   9.2 Ablauf der 3-D-Transaktion über DirectLink
      9.2.1 Zusätzliche Anfrageparameter
      9.2.2 Zusätzliche Rückgabefelder
      9.2.3 3-D Secure v2.1 MasterCard+
      9.2.4 Anmerkungen
   9.3 Ausschlüsse und Ausnahmen für 3DsV2
      9.3.1 3DSv2 und Ausschlüsse
      9.3.2 SCA und 3DS reibungsloser / Challenge-Flow
      9.3.3 Angabe des bevorzugten Flows
      9.3.4 Ausnahmen von 3DS

1 Allgemeine Vorgehensweisen und Sicherheitseinstellungen

Die folgenden allgemeinen Vorgehensweisen und Sicherheitskontrollen gelten für alle DirectLink-Anfragen: neue Bestellanfragen, Datenpflegeanfragen und Direktabrufe.

1.1 API-Benutzer

Ein API (Application Program Interface)-Benutzer wird benötigt, an den DirectLink-Anfragen gerichtet werden können.

Im Allgemeinen handelt es sich dabei um einen speziell erstellten Benutzer, der von einer Anwendung verwendet wird, um automatische Anfragen an die Zahlungsplattform zu richten.

Sie können in Ihrem Ingenico-Konto über „Konfiguration" > „Benutzer" einen API-Benutzer erstellen. Wählen Sie „Neuer Benutzer" und füllen Sie die Pflichtfelder aus.

Um den neuen Benutzer zu einem API-Benutzer zu machen, vergewissern Sie sich, dass Sie das Kästchen „Sonderbenutzer für API (Kein Zugriff auf Administration)" abhaken.

Creation of an API user

Wenn für einen API-Benutzer auch die verschiedenen Benutzerprofile zur Verfügung stehen, empfehlen wir Ihnen dringend, diesen Benutzer mit dem „Admin"-Profil zu konfigurieren.
Wenn Sie die Rechte für die Pflege von Transaktionen (Erstattungen, Abbruch, usw.) einschränken möchten, können Sie das Benutzerprofil noch zu z.B. „Kodierer“ ändern.

Wenn Sie nicht sicher sind, empfehlen wir Ihnen, das „Admin"-Profil zu wählen; oder wechseln Sie zu den Benutzerprofilen (Benutzermanager) für mehr Informationen.

Das Passwort eines API-Benutzers muss nicht regelmäßig geändert werden. Das ist praktischer, wenn das Passwort fest in Ihrer Anwendung hinterlegt werden muss. Jedoch empfehlen wir, das Passwort von Zeit zu Zeit zu ändern.

Mehr Informationen über Benutzertypen und wie das Passwort des API-Benutzers geändert wird, finden Sie unter "Benutzertypen" (Benutzermanager).

1.2 Anfrageformat

Für neue Bestellanfragen, Datenpflegeanfragen und Direktabrufe muss der Händler die Anfragen mit bestimmten Parametern an bestimmte URLs senden. Die Parameter für Zahlung/Datenpflege/Abruf müssen in einer Posting-Anfrage wie folgt gesendet werden:

PSPID=value1&USERID=value2&PSWD=value3&…

Der Type/Subtyp zur Anzeige des Medientyps im Content-Type Entity-Header Feld der POST-Anfrage muss „application/x-www-form-urlencoded" lauten.

DirectLink arbeitet im Modus „eine Anfrage - eine Antwort". Jede Zahlung wird einzeln verarbeitet. Unser System handhabt individuelle Anfragen via DirectLink und kann synchron arbeiten (wenn diese Option technisch unterstützt wird). D. h. wir warten auf die Antwort der Bank, ehe wir eine XML-Antwort auf die Anfrage zurücksenden.

1.3 Sicherheit

Wenn wir auf unseren Servern eine Anfrage empfangen, prüfen wir das Verschlüsselungsniveau und die IP-Adresse, von der die Anfrage stammt.

1.3.1 Verschlüsselung

DirectLink baut auf einem robusten und sicheren Kommunikationsprotokoll auf. Die API ist ein Instruktionsbestand, der über normale HTTPS Posting-Anfragen übermittelt wird. Wir erlauben dem Händler eine Verbindungsaufnahme mit uns nur im sicheren HTTPS-Modus.
Ein clientseitiges TLS-Zertifikat ist nicht notwendig.

1.3.2 IP-Adresse

Für jede Anfrage prüft unser System die IP-Adresse, von der die Anfrage kam, um sicherzustellen, dass die Anfragen wirklich vom Server des Händlers stammen. Im IP-Adressenfeld des Bereichs „Daten- und Ursprungsüberprüfung", Abschnitt „Überprüfungen für DirectLink" der Seite „Technische Informationen" Ihres Kontos müssen Sie die IP-Adressen oder IP-Adressbereiche der Server eintragen, die Ihre Anfragen an uns senden.

Wenn die IP-Adresse, von der die Anfrage stammt, im IP-Adressenfeld des Bereichs „Daten- und Ursprungsüberprüfung", Abschnitt „Überprüfungen für DirectLink", Seite „Technische Informationen" Ihres Kontos nicht angegeben ist, erhalten Sie die Fehlermeldung „unknown order/1/i". Die IP-Adresse, von der die Anfrage gesendet wurde, wird ebenfalls in dieser Fehlermeldung angezeigt.

1.3.3 Zusätzliche Sicherheit: SHA-Signatur

Für jede Bestellung erzeugt der Server des Händlers eine eindeutige Zeichenfolge, aus der mittels SHA1-, SHA-256- oder SHA-512-Algorithmus ein Hashcode generiert wird. Das Resultat dieses Hashvorgangs wird in der Bestellanfrage des Händlers an uns gesendet. Unser System rekonstruiert diesen Hashcode, um so die Datenintegrität der Bestellinformationen zu überprüfen, die an uns gesendet worden sind.

1.4 Auswertung der Antwort (Parsing)

Wir reagieren mit einer XML-Antwort auf Ihre Anfrage. Bitte sorgen Sie dafür, dass Ihre Systeme diese XML-Antwort mit größtmöglicher Toleranz auswerten (parsen). Vermeiden Sie beispielsweise Attributnamen, bei denen die Unterscheidung von Groß- und Kleinschreibung notwendig ist, schreiben Sie keine spezifische Reihenfolge für die in Antworten zurückgelieferten Attribute vor, sorgen Sie dafür, dass neue Attribute in der Antwort nicht zu Problemen führen, usw.

2 Neue Bestellungen anfragen

2.1 Anfrage-URL

  • Die Anfrage-URL in der TESTUMGEBUNG lautet https://secure.ogone.com/ncol/test/orderdirect.asp.
  • Die Anfrage-URL in der PRODUKTIVUMGEBUNG lautet https://secure.ogone.com/ncol/prod/orderdirect.asp.
Wichtig

Vergessen Sie nicht, in der Anfrage-URL die Zeichenfolge „test" durch „prod" zu ersetzen, wenn Sie auf Ihr reguläres Produktivkonto umstellen. Wenn Sie vergessen, die Anfrage-URL zu ändern und den regulären Betrieb mit realen Bestellungen aufnehmen, laufen Ihre Transaktionen weiter in die Testumgebung und werden nicht an die Akzeptanzpartner bzw. Banken gesendet.

2.2 Anfrageparameter

2.3 Testseite

Ein Beispiel für eine Bestellanfrage (eine Testseite) finden Sie unter https://ogone.test.v-psp.com/ncol/test/testodl.asp.

2.4 Ausschluss spezifischer Zahlungsmethoden

Wenn Sie verhindern möchten, dass ein Kunde bestimmte Zahlungsverfahren nutzt, können Sie dazu einen bestimmten Parameter nutzen.

Dies ist insbesondere bei Unter-Marken nützlich, wenn Sie eine Marke (z. B. MasterCard) akzeptieren möchten, nicht aber eine ihrer Unter-Marken (z. B. Maestro).

Der Parameter ist wie folgt zu verwenden:

Feld Verwendung
EXCLPMLIST
Liste der Zahlungsverfahren bzw. Kreditkartenmarken, getrennt durch Semikolon (;), die NICHT verwendet werden sollen.

Versucht ein Kunde, mit einer Karte zu bezahlen, die mit einem bestimmten Zahlungsverfahren bzw. einer (Unter-)Marke verknüpft ist, aber von Ihnen mittels Parameter EXCLPMLIST vom Gebrauch ausgeschlossen wurde, wird im Feld NCERRORPLUS die Fehlermeldung „Card number incorrect or incompatible“ („Falsche Kartennummer oder nicht zulässig“) zurückgesendet.

2.5 Bestellanforderungen mit 3-D Secure

Unser System unterstützt die Nutzung von 3-D Secure über DirectLink. Weitere Informationen zu diesem Feature finden Sie im Integrationsleitfaden für DirectLink mit 3-D Secure.

Wichtig

  • Wenn Sie 3-D Secure mit DirectLink nutzen möchten, müssen Sie in Ihrem Konto die Option D3D aktiviert haben.
  • Manche Acquirerbanken verlangen die Nutzung von 3-D Secure. Bitte klären Sie mit Ihrem Acquirer, ob dies bei Ihnen der Fall ist.

2.6 Aufteilung Kredit/Debit

Die Funktionalität zur Aufteilung von VISA und MasterCard in ein Debit- und ein Kreditkarten-Zahlungsverfahren erlaubt es Ihnen, Ihren Kunden diese Programme als zwei unterschiedliche Zahlungsverfahren anzubieten (z. B. VISA Debit und VISA Kredit). Sie können auch entscheiden, nur eines der Teilverfahren für beide Marken zu akzeptieren.

Um die Aufteilung von Kredit- und Debit-Karten via DirectLink zu nutzen, müssen Sie den Parameter CREDITDEBIT in die verborgenen Felder aufnehmen, die Sie an die Seite orderdirect.asp senden (und daher auch in die SHA-IN-Berechnung einschließen!).

Feld Format
CREDITDEBIT "C": credit card (Kreditkarte)
"D": debit card (Debitkarte)

Zugehörige Fehlermeldung: Wenn ein Käufer das Debitkarten-Zahlungsverfahren auswählt, aber die Nummer einer Kreditkarte eingibt, wird ein Fehler zurückgemeldet: „Wrong brand/Payment method was chosen“ (Falsche Marke/falsches Zahlungsverfahren ausgewählt).

Wenn die Zahlung mit dem Parameter CREDITDEBIT erfolgreich verarbeitet worden ist, wird der gleiche Parameter auch in der XML-Rückmeldung zurückgegeben bzw. kann mit einem Direct Query angefordert werden. Lauten die eingereichten Parameterwerte C bzw. D, ist der zurückgemeldete Wert "CREDIT" bzw. "DEBIT".

Sie finden diese Rückmeldungswerte in der Transaktionsübersicht über „View transactions“ (Transaktionen anzeigen) und „Financial history“ (Zahlungshistorie) sowie in den Berichten, die Sie nachfolgend herunterladen.

Konfiguration in Ihrem Konto

Die Aufteilungsfunktion kann auch in Ihrem Ingenico ePayments-Konto pro Zahlungsverfahren aktiviert und konfiguriert werden. Weitere Informationen finden Sie unter Split Credit/Debit Cards.

2.7 Transaktionen mit gespeicherten Anmeldedaten abwickeln

Bei der Credential-on-File-Transaktion (COF) werden bereits vom Händler gespeicherte, vorhandene Kreditkartendetails verwendet, um die Zahlung abzuwickeln. Bevor eine COF-Transaktion ausgelöst wird, muss der Karteninhaber zuerst den Händler autorisieren, die Kartendetails zu speichern. Credential-on-File (COF) wird hauptsächlich für wiederkehrende Zahlungen angewandt und gibt an, ob die Zahlung vom Karteninhaber oder Händler ausgelöst wird.

Es gibt zwei Arten von COF-Transaktionen: eine vom Karteninhaber ausgelöste Transaktion (CIT) oder eine vom Händler ausgelöste Transaktion (MIT). Eine vom Karteninhaber ausgelöste Transaktion (CIT) muss immer zuerst stattfinden, bevor eine vom Händler ausgelöst werden kann.

Bei der vom Karteninhaber ausgelöste Transaktion (CIT) ist der Karteninhaber an der Transaktion beteiligt und authentifiziert die Transaktion persönlich, z. B. durch eine Unterschrift, eine 3D Secure-Anwendung oder der Vorlage von IDs.

Beispiel für eine vom Karteninhaber ausgelöste Transaktion (CIT):

Ein Karteninhaber kauft ein Zugticket online und bezahlt es. Er/Sie zahlt mit seiner/ihrer Kreditkarte und wird aufgefordert, die Zahlung zu authentifizieren und zu autorisieren. Gleichzeitig wird der Karteninhaber auch gefragt, ob er/sie die Kreditkarteninformationen im Zusammenhang mit dieser Zahlung speichern möchte. Wenn der Karteninhaber zustimmt, kann diese Information dann in zukünftigen, vom Händler ausgelösten Transaktionen wiederverwendet werden.
Einer vom Händler ausgelöste Transaktion (MIT) geht voraus, dass der Karteninhaber eine Transaktion ausgelöst und zuvor eine Dauerbestellung für gekaufte Waren und Dienstleistungen vereinbart hat. Der Karteninhaber muss dabei nicht an der Transaktion beteiligt sein.

Beispiel für eine vom Händler ausgelöste Transaktion (MIT):

Ein Händler kann automatisch eine Transaktion auslösen, um die Zahlung eines Karteninhabers für ein monatliches Zeitschriftenabonnement zu erfüllen.

In Übereinstimmung mit den von Visa und MasterCard für die Credential-on-file-Transaktion (COF) festgelegten Regeln müssen neue Parameter gesendet werden, um die COF-Transaktion zu bestimmen

Betroffen, wenn:

  • Sie ein Alias verwenden
  • Sie planen, wiederkehrende Transaktionen (regelmäßig oder nicht) auszulösen, nachdem Sie zum ersten Mal eine vom Karteninhaber ausgelöste Transaktion (CIT) ausgelöst haben

Erforderliche Aktion

Diese Parameter werden standardmäßig in einer DirectLink Transaktion verwendet:

Parameter-Werte COF_INITIATOR-COF_TRANSACTION-COF_SCHEDULE

Beschreibung

CIT-FIRST-UNSCHED
Gilt, wenn ein Alias verwendet oder erstellt wird
CIT-FIRST-SCHED

Gilt für eine erste regelmäßige Zahlung/ein Abonnement

MIT-SUBSEQ-UNSCHED
Gilt für wiederkehrende Zahlung
MIT-SUBSEQ-SCHED
Gilt für Ratenzahlung

Die Standardwerte werden markiert, wenn Sie keine Parameter hinzufügen. Wenn Sie sie jedoch ändern möchten, können Sie diese Standardwerte mit neuen Parametern überschreiben. Vergessen Sie nicht, die SHA-Signatur neu zu berechnen (klicken Sie hier, um weitere Informationen zur SHA-Signatur zu erhalten.)

Parameter

Werte

Beschreibung

COF_INITIATOR CIT Eine vom Karteninhaber ausgelöste Transaktion
MIT Eine vom Händler ausgelöste Transaktion
COF_SCHEDULE
SCHED Eine regelmäßige Transaktion
UNSCHED Eine unregelmäßige Transaktion
COF_TRANSACTION
FIRST Die erste von einer Reihe von Transaktionen

SUBSEQ

Weitere Reihen von Transaktionen

COF_RECURRING_EXPIRY Datum JJJJMMTT (z.B. 20190914) Enddatum: Tag der letzten regelmäßigen Zahlung einer Serie
COF_RECURRING_FREQUENCY numerisch zwischen 2 und 4 Stellen (z.B. 1, 031 oder 0031) Anzahl Tage welche zwischen regelmäßigen Zahlungen

3 Rückmeldung zur Bestellung

Unser Server sendet als Rückmeldung zur Anfrage eine XML-Antwort:

Beispiel einer XML-Antwort auf eine Bestellanfrag

<?xml version="1.0"?>

<ncresponse orderID="99999" PAYID="1111111" NCSTATUS="0" NCERROR="" NCERRORPLUS="" ACCEPTANCE="12345" STATUS="5" ECI="7" amount="125" currency="EUR" PM="CreditCard" BRAND="VISA"/>

Die folgende Tabelle enthält eine Attributliste zum ncresponse-tag:

FeldNutzung
ACCEPTANCE

Vom Akzeptanzpartner zurückgesendeter Akzeptanzwert.

amount

Betrag der Bestellung (nicht mit 100 multipliziert)

BRAND

Kartenmarke oder vergleichbare Informationen für andere Zahlungsmethoden.

currency

Währung der Bestellung.

ECI Electronic Commerce Indicator.
NCERROR

Fehlerwert.

NCERRORPLUS

Erklärung des Fehlercodes.

NCSTATUS

Transaktionsstatus.

orderID

Ihre Bestellnummer.

PAYID

Bezahlungs-ID als Referenz in unserem System.

PM

Zahlungsmethode.

STATUS

Transaktionsstatus.

Die Attributliste kann bei Händlern länger sein, die in ihren Konten bestimmte Optionen (z. B. Betrugserkennungsmodul) aktiviert haben. Bitte lesen Sie in der betreffenden Dokumentation weitere Informationen über zusätzliche Rückmeldungsattribute nach, die mit dieser Option verbunden sind.

3.1 Duplicate request

If you request processing for an already existing (and correctly processed) orderID, our XML response will contain the PAYID corresponding to the existing orderID, the ACCEPTANCE given by the acquirer in the previous processing, STATUS “0” and NCERROR “50001113”.

4 Direkte Datenpflege: Pflege bestehender Bestellungsdaten

Eine direkte Datenpflegeanfrage von ihrer Applikation aus ermöglicht Ihnen:

  • Eine Kontobelastung (Zahlung) einer autorisierten
  • Bestellung automatisch vorzunehmen (anstatt manuell im Back-Office)
  • Autorisierung einer Bestellung zu stornieren
  • Autorisierung einer Bestellung zu erneuern oder eine bezahlte Bestellung wieder gutzuschreiben.

4.1 Datenpflege-Anfrage

4.1.1 Anfrage-URL

  • Die Anfrage-URL in der TESTUMGEBUNG lautet https://ogone.test.v-psp.com/ncol/test/maintenancedirect.asp.
  • Die Anfrage-URL in der PRODUKTIVUMGEBUNG lautet https://secure.ogone.com/ncol/prod/maintenancedirect.asp.

Wichtig

Vergessen Sie nicht, in der Anfrage-URL die Zeichenfolge „test" durch „prod" zu ersetzen, wenn Sie auf Ihr reguläres PRODUKTIVKONTO umstellen. Wenn Sie vergessen, die Anfrage-URL zu ändern und den regulären Betrieb mit realen Bestellungen aufnehmen, laufen Ihre Datenpflege-Transaktionen weiter in die Testumgebung und werden nicht an die Akzeptanzpartner bzw. Banken gesendet.

4.1.2 Anfrageparameter

Die folgende Tabelle enthält die obligatorische Aufforderung Parameter zur Durchführung einer Wartungsarbeit:

Feld
Nutzung
AMOUNT

Betrag der Bestellung, mit 100 multipliziert. Nur obligatorisch, wenn der Betrag in der Datenpflegeanfrage sich von dem in der Originalautorisierung unterscheidet. Wir empfehlen jedoch, den Betrag immer anzugeben.

Unser System prüft, ob der Betrag in der Datenpflegeanfrage nicht zu hoch im Vergleich zum Betrag in der Originalautorisierung bzw. -zahlung ist.

OPERATION

Mögliche Werte:

  • REN: Erneuerung der Autorisierung, wenn die Originalautorisierung nicht mehr gültig ist.
  • DEL: Löschung der Autorisierung. Die Transaktion bleibt dabei für mögliche nachfolgende Datenpflegeoperationen geöffnet.
  • DES: Löschung der Autorisierung. Die Transaktion wird nach diesem Vorgang geschlossen.
  • SAL: Teilweise Kontobelastung (Zahlung). Die Transaktion bleibt für eine mögliche weitere Kontobelastung geöffnet.
  • SAS: (Letzte) teilweise oder vollständige Kontobelastung (Zahlung). Nach dieser Kontobelastung wird die Transaktion für weitere Kontobelastungen geschlossen.
  • RFD: Teilweise Gutschrift (einer bezahlten Bestellung). Die Transaktion bleibt für mögliche weitere Gutschriften geöffnet.
  • RFS: (Letzte) teilweise oder vollständige Gutschrift (einer bezahlten Bestellung). Nach dieser Gutschrift wird die Transaktion geschlossen.

Bitte beachten Sie bei DEL und DES, dass nicht alle Akzeptanzpartner das Löschen einer Autorisierung unterstützen. Wenn Ihr Akzeptanzpartner DEL/DES nicht unterstützt, können wir dennoch die Löschung der Autorisierung im Back-Office simulieren.

ORDERID

Sie können die PAYID oder die orderID zur Identifikation der Originalbestellung senden. Wir empfehlen die Verwendung der PAYID.

PAYID
PSPID

Anmeldedaten: PSPID und (API) USERID mit dem zur USERID gehörenden Passwort

PSWD
USERID
SHASIGN Mit dem Secure Hash Algorithmus gehashte Zeichenfolge (siehe SHA-IN-Signatur)

4.1.3 Testseite

Ein Beispiel für eine direkte Datenpflegeanfrage (eine Testseite) finden Sie unter: https://ogone.test.v-psp.com/ncol/test/testdm.asp

4.2 Datenpflege-Antwort

Beispiel einer XML-Antwort auf eine direkte Datenpflegeanfrage:

<?xml version="1.0"?>

<ncresponse orderID="99999" PAYID="1111111" PAYIDSUB="3" NCSTATUS="0" NCERROR="" NCERRORPLUS="" ACCEPTANCE="12345" STATUS="91" amount="125" currency="EUR"/>

Die folgende Tabelle enthält eine Attributliste zum ncresponse-tag:

Feld Nutzung
ACCEPTANCE

Vom Akzeptanzpartner zurückgesendeter Akzeptanzwert.

AMOUNT

Betrag der Bestellung (nicht mit 100 multipliziert).

CURRENCY

Währung der Bestellung.

NCERROR

Fehlerwert.

NCERRORPLUS

Erklärung des Fehlercodes.

NCSTATUS

Erste Ziffer von NCERROR.

ORDERID

Ihre Bestellnummer

PAYID

Bezahlungs-ID als Referenz in unserem System.

PAYIDSUB

Die PAYID der angewendeten Datenpflegeoperation auf Historien-Ebene

STATUS

Transaktionsstatus.

Weitere technische Einzelheiten zu diesen Feldern finden Sie im Parameter Cookbook.

Die Standardattribute des ncresponse-tags sind identisch mit denen der XML-Antwort auf eine neue Bestellung mit Ausnahme des zusätzlichen Attributs PAYIDSUB.

4.3 Doppelte Anfrage

Geht eine Datenpflegeanfrage für die gleiche Bestellung zweimal ein, wird die zweite theoretisch mit der Fehlermeldung „50001127" (Bestellung nicht autorisiert) abgelehnt, weil die erste erfolgreiche Transaktion den Bestellstatus geändert hat.

5 Direktabruf: Bestellstatus abrufen

Eine Direktabruf-Abfrage von Ihrer Applikation ermöglicht Ihnen, den Status einer Bestellung automatisch abzurufen (anstatt manuell im Back-Office). Sie können immer nur eine Zahlung gleichzeitig abrufen und erhalten nur in begrenztem Umfang Informationen über die Bestellung.

Wenn Sie weitere Details über die Bestellung benötigen, können Sie die Transaktion im Back-Office aufrufen oder einem manuellen bzw. automatischen Dateidownload vornehmen (siehe hierzu Transaktionen Ansehen und Advanced Batch Integrationsleitfaden).

5.1 Abruf-Anfrage

5.1.1 Anfrage-URL

  • Die Anfrage-URL in der TESTUMGEBUNG lautet https://ogone.test.v-psp.com/ncol/test/querydirect.asp.
  • Die Anfrage-URL in der PRODUKTIVUMGEBUNG lautet https://secure.ogone.com/ncol/prod/querydirect.asp.

Wichtig

Vergessen Sie nicht, in der Anfrage-URL die Zeichenfolge „test" durch „prod" zu ersetzen, wenn Sie auf Ihr reguläres PRODUKTIVKONTO umstellen.

5.1.2 Anfrageparameter

Die folgende Tabelle enthält die obligatorischen Anfrageparameter für die Durchführung eines Direktabrufs:

Feld
Nutzung
ORDERID

Sie können die PAYID oder die ORDERID zur Identifikation der Originalbestellung senden. Wir empfehlen die Verwendung der PAYID.

PAYID
PAYIDSUB

Sie können die ID der Historien-Ebene angeben, wenn Sie die PAYID zur Identifikation der Originalbestellung verwenden (optional).

PSPID

Anmeldedaten: PSPID und (API) USERID mit dem zur USERID gehörenden Passwort


PSWD
USERID

5.1.3 Testseite

Ein Beispiel für eine Direktabruf-Anfrage (eine Testseite) finden Sie unter: https://ogone.test.v-psp.com/ncol/test/testdq.asp.

5.2 Abruf-Antwort

Unser Server sendet als Rückmeldung zur Anfrage eine XML-Antwort:

Beispiel einer XML-Antwort auf eine Direktabruf-Anfrage:

<?xml version=”1.0”?>
<ncresponse orderID=”99999” PAYID=”1111111” PAYIDSUB=”3” NCSTATUS=”0” NCERROR=”” NCERRORPLUS=”” ACCEPTANCE=”12345” STATUS="9" ECI=”7” amount="125" currency="EUR" PM="CreditCard" BRAND="VISA" CARDNO="XXXXXXXXXXXX1111" IP="212.33.102.55"/>

Die folgende Tabelle enthält eine Attributliste des ncresponse-tags:

Feld
Nutzung
ACCEPTANCE Vom Akzeptanzpartner zurückgesendeter Akzeptanzwert.
amount Betrag der Bestellung (nicht mit 100 multipliziert).
BRAND Kartenmarke oder vergleichbare Informationen für andere Zahlungsmethoden.
CARDNO Maskierte Kartennummer.
currency Währung der Bestellung.
ECI Electronic Commerce Indicator.
IP IP-Adresse des Kunden, wie von unserem System in einer 3-Ebenen-Integration ermittelt oder uns vom Händler in einer 2-Ebenen-Integration gesendet.
NCERROR Fehlerwert.
NCERRORPLUS Erklärung des Fehlercodes.
NCSTATUS Erste Ziffer von NCERROR.
orderID Ihre Bestellnummer.
PAYID Zahlungsreferenz in unserem System.
PAYIDSUB Die PAYID der angewendeten Datenpflegeoperation auf Historien-Ebene.
PM Zahlungsmethode.
STATUS Transaktionsstatus

Die Standardattribute des ncresponse-tags sind identisch mit denen für die XML-Antwort auf eine neue Bestellung mit Ausnahme der zusätzlichen Attribute PAYIDSUB, CARDNO und IP.

Die Attributliste kann bei Händlern länger sein, die in ihren Konten bestimmte Optionen (z. B. das Betrugserkennungsmodul) aktiviert haben. Bitte lesen Sie in der Dokumentation der betreffenden Option weitere Informationen über zusätzliche Antwortattribute nach, die mit dieser Option verbunden sind.

5.2.1 Mit e-Commerce verarbeitete Transaktionen

Wenn die Transaktion, deren Status Sie abrufen möchten, mit e-Commerce verarbeitet wurde, erhalten Sie die folgenden zusätzlichen Attribute (vorausgesetzt, Sie haben mit der ursprünglichen e-Commerce Transaktion diese Felder gesendet).

Feld
Nutzung
COMPLUS
Ein Wert, den Sie in der Antwort zurückgesendet bekommen wollten.
(paramplus Inhalt)
The parameters and their values you wanted to have returned

Beispiel einer XML-Antwort auf den Direktabruf bezüglich einer e-Commerce-Transaktion:

<ncresponse orderID=”99999” PAYID=”1111111” PAYIDSUB=”3” NCSTATUS=”0” NCERROR=”” NCERRORPLUS=”” ACCEPTANCE=”12345” STATUS="9" amount="125" currency="EUR" PM="CreditCard" BRAND="VISA" CARDNO="XXXXXXXXXXXX1111" IP="212.33.102.55" COMPLUS="123456789123456789123456789" SessionID="126548354" ShopperID="73541312"/>

5.3 Mögliche rückgemeldete Statuszustände

Das Feld STATUS enthält den Status der Transaktion. Eine vollständige Liste der möglichen Statuszustände finden Sie im Back-Office: Support > Integrations & Benutzerhandbücher > Benutzerhandbücher > Liste der Status- und Fehlermeldungen.

Nur der folgende Status bezieht sich speziell auf den Abruf selbst:

StatusNCERRORNCSTATUS Description
88

Der Abruf an querydirect.asp ist fehlgeschlagen.

5.4 Direktabruf als Fallback

Die Antwortzeit für die Anfrage bezüglich einer DirectLink Transaktion beträgt generell nur wenige Sekunden. Einige Akzeptanzpartner haben jedoch möglicherweise längere Antwortzeiten.

Wenn Sie innerhalb von 30 Sekunden keine Antwort von unserem System erhalten haben, können Sie eine Anfrage an querydirect.asp senden, die den Status der gerade an orderdirect.asp gesendeten Transaktion abruft. Wenn Sie eine sofortige Antwort erhalten, die für die Transaktion einen noch nicht abgeschlossenen Status meldet, liegen eventuell Probleme auf Akzeptanzpartnerseite vor.

Wenn Sie nach 10 Sekunden noch keine Antwort auf den Direktabruf erhalten haben, liegen eventuell Probleme auf unserer Seite vor. Sie können diese Anfrage an querydirect.asp alle 30 Sekunden wiederholen, bis Sie feststellen, dass eine Antwort innerhalb von 10 Sekunden bei Ihnen eintrifft.

Bitte beachten Sie:

  1. Dieses Prüfsystem kann nur dann Probleme auf unserer Seite anzeigen, wenn gleichzeitig eine Prüfung auf Ihrer Seite sicherstellt, dass die Anfragen Ihre Server korrekt verlassen.
  2. Ein Problem auf unserer Seite ist nicht notwendigerweise durch einen Systemausfall begründet, sondern kann auch das Ergebnis langer Antwortzeiten aufgrund von Datenbankproblemen sein.
  3. Bitte nutzen Sie diese Prüfmöglichkeiten mit Zurückhaltung, um ein Dauerbelastung unserer Server mit derartigen Anfragen zu vermeiden. Andernfalls sind wir eventuell gezwungen, Ihren Zugriff auf die Seite querydirect.asp zu sperren.

Wichtig

Um unser System vor unnötiger Überlastung zu schützen, unterbinden wir Prüfungen der Systemverfügbarkeit, die mit dem Senden vorgetäuschter Transaktionen oder systematischer Anfragen sowie mit systematischen Anfragen verbunden sind, die für jede Transaktion eine Transaktionsrückmeldung erfordern.

6 Datenschutzrichtlinie-Anforderung

Nach Artikel 12, 13 und 14 DSGVO ist der Datenverantwortliche verpflichtet, seine Endkunden über die zukünftige Verarbeitung ihrer persönlichen Daten zu informieren. Diese Informationen sollten auf der Grundlage der Art der für eine bestimmte Transaktion einzugebenden persönlichen Daten (z.B.: gewählte Zahlungsmethode, Controller/Verarbeiter, Acquirer, Betrug) spezifiziert werden. Das Ergebnis sollte zum Zeitpunkt der Datenerhebung verfügbar und sichtbar sein und dem Karteninhaber mit einer druckbaren und herunterladbaren Version angeboten werden. Gemäß der Datenschutz-Grundverordnung (DSGVO) müssen Sie Ihren Kunden vor deren Transaktionsbestätigung diese Informationen darlegen. Diese Informationen sind idealerweise auf derselben Seite anzuzeigen, auf der Ihre Kunden ihre Kreditkarten-/Kontoangaben eingeben.
Mit der folgenden Anfrage nach der Datenschutzrichtlinie erhalten Sie alle Informationen, die Sie Ihren Kunden für die Einhaltung der Datenschutz-Grundverordnung (DSGVO) über unsere Dienstleistungen anzeigen müssen.

6.1 Abruf-Anfrage

6.1.1 Query-Anforderung

• Die URL-Anforderung in der TEST-Umgebung ist https://secure.ogone.com/ncol/test/privacy-policy.asp

• Die URL-Anforderung in der PRODUKTIONS-Umgebung ist https://secure.ogone.com/ncol/prod/privacy-policy.asp
„Test“ in "Prod“ ändern
Ersetzen Sie „Test“ durch „Prod“ in der URL-Anforderung, wenn Sie zu Ihre Produktivkonto wechseln.

6.1.2 Anforderungsparameter

In der folgenden Tabelle sind die obligatorischen Anforderungsparameter aufgelistet, die Ihren Kunden hinsichtlich der Nutzung ihrer Datenschutzinformationen übermittelt werden:

Feld Format
Beschreibung
USERID Zeichenfolge Ihr API-Benutzer
PSWD Zeichenfolge
Ihr API-Benutzer-Password
PSPID
Zeichenfolge
Ihre Konto-PSPID
BRAND String (e.g. Visa) Optional: Zahlungsmethode Marke
Sie können dieses Feld mehrmals übermitteln, um das Ergebnis mehrerer Marken zugleich zu erhalten.
• Wird keine Marke übermittelt entspricht dies der Übermittlung aller Ihrer aktiven Marken
• Leere/fehlerhaft formatierte Marken werden ignoriert
LANGUAGE ISO 639-1: Zwei-Buchstaben-Codes (z.B. FR) Optional: Die Sprache, in der Sie den Text erhalten möchten.
Wenn nicht angegeben, wird der Text in der ursprünglich eingestellten Sprache des Händlers angezeigt.

6.1.3 Testseite

Sie können direkte Query-Anforderungen hier testen: https://secure.ogone.com/ncol/test/privacy-policy.asp

6.2 Abruf-Antwort

Im Folgenden finden Sie ein Verzeichnis von XML-Elementen und die zurückübermittelten XML-Antwortbeispiele für verschiedene Ergebnisse.

Name Format Beschreibung
Response
Complex Root node, always present
Response.Status
String, possible values : Success, SuccessWithWarnings, Error
Always present
Response.Body
Complex
Present only when Response.Status = Success or SuccessWithWarnings
Response.Body.Html
String / html
Empty if Response.Status = SuccessWithWarnings & Response.Warnings.Warning.Code = NoContent
Response.Errors
Complex
Present only when Response.Status = Error
Response.Errors.Error
Complex
Can occur multiple times inside an <Errors> node
Response.Warnings
Complex
Present only when Response.Status = SuccessWithWarnings or Error
Response.Warnings.Warning Complex
Occurs multiple times inside a <Warnings> node
Response.Errors.Error.Code
Response.Warnings.Warning.Code
String, possible values :
•Inside an <Error> node : Unauthorized, InternalServerError
•Inside a <Warning> node : NoContent

Always present in an <Error> or <Warning> node
Response.Errors.Error.Message
Response.Warnings.Warning.Message
String
Optional

Wird Ihnen Response.Status=Error ausgegeben, beziehen Sie sich bitte auf den Response.Errors.Error, um den Fehler zu beheben.
Im Folgenden zwei erfolgreiche Beispiele:

1. Beispiel einer XML-Antwort für einen Erfolg mit Warnungen. Wird zurückgegeben, wenn keine Datenschutzinformationen dem Kunden offengelegt werden müssen.

<?xml version="1.0" encoding="utf-8"?>
<Response>
<Status>SuccessWithWarnings</Status>
<Warnings>
<Warning>
<Code>NoContent</Code>
</Warning>
</Warnings>
<Body>
<Html/>
</Body>
</Response>

2. Beispiel einer XML-Antwort für einen Erfolg mit Inhalt. Das Beispiel zeigt eine in 2 Bereiche aufgeteilte Anzeige.

<?xml version="1.0" encoding="utf-8"?>
<Response>
<Status>Success</Status>
<Body>
<Html><![CDATA[<ul><li><h2>Title 1</h2><p>Content 1</p></li><li><h2>Title 2 (VISA, American Express) </h2><p>Content 2</p></li></ul>]]></Html>
</Body>
</Response>

7 PM-Ausnahmen

Bei bestimmten Zahlungsmethoden weichen die Parameterwerte von den Kreditkarten-Standardwerten ab.

7.1 Direct Debits

7.1.1 Direct Debits AT

Die folgende Tabelle enthält die spezifischen Parameterwerte, die eine Übertragung von Direct Debits AT Transaktionen via DirectLink erlauben.

Format: AN=alphanumerisch / N=numerisch, die maximal erlaubte Anzahl der Zeichen
Feld
Beschreibung
Format/Wert
CARDNO

Bankkontonummer

AN, 21

Format: XXXXXXXXXXXBLZYYYYY

XXXXXXXXXXX: Kontonummer, numerisch, 11 Stellen.
YYYYY: Bankleitzahl, 5 Stellen.
CN Name des Karteninhabers AN, 35
ED
Verfallsdatum
„99/99“ oder „9999“
OPERATION

Operationscode (Auszuführende Aktion)

A, 3

Mögliche Werte:

  • RES: Autorisierung (Reservierung)
  • SAL/SAS: Geld vom Bankkonto abbuchen
  • RFD/RFS: Gutschrift auf das Bankkonto (*)
OWNERADDRESS Anschrift des Kontoinhabers AN, 50
OWNERTOWN Wohnort des Bankkontoinhabers AN, 40
OWNERZIP Kontoinhabers Postleitzahl AN, 10
PM Zahlungsmethode AN, 25

“Direct Debits AT”

(* Falls die Gutschrift Option verfügbar und aktiv ist, und DTAUS-Gutschrift verfügbar ist)

7.1.2 Direct Debits DE (ELV)

(* Falls die Gutschrift Option verfügbar und aktiv ist, und DTAUS-Gutschrift verfügbar ist)

Die folgende Tabelle enthält die spezifischen Parameterwerte, welche die Übertragung von ELV-Transaktionen über DirectLink (not Wirecard/Billpay).

Format: AN=alphanumerisch / N=numerisch, die maximal erlaubte Anzahl der Zeichen
Feld
Beschreibung Format/Wert
Obligatorisch
CARDNO
Bankkontonummer

IBAN: alphanumerische Zeichen

ODER

Bankkontonummer + BLZ. Format: XXXXXXXXXBLZYYYYYYYY
XXXXXXXXXX: Kontonummer, numerisch, 1 bis 10 Stellen.
YYYYYYYY: Bankleitzahl), 8 Stellen.
J
CN
Name des Bankkontoinhabers
AN, 35
J
ED
Verfallsdatum
„99/99“ oder „9999“ J
MANDATEID
Eindeutige Auftragsreferenz.
Telego:
Ohne Angabe übernimmt die Plattform die ORDERID oder PAYID
Note: Ohne Angabe erstellt easycash einen Wert.

Telego: AN, 35 / Zeichensatz: “A-Z a-z 0-9 Leerzeichen /-?:().,'+”
Ohne Angabe übernimmt die Plattform die ORDERID oder PAYID

Easycash: Format: AN, 27 / Zeichensatz: “A-Z a-z 0-9 Leerzeichen /-?:().,'+”
Note: Ohne Angabe erstellt easycash einen Wert.

N
OPERATION
Operationscode (Auszuführende Aktion)

A, 3

Mögliche Werte:

  • RES: Autorisierung
  • SAL/SAS: Einzug von Geld vom Bankkonto
  • RFD/RFS: Erstattung von Geld (*)
N
OWNERADDRESS
Adresse des Kontoinhabers
AN, 50 J
OWNERTOWN
Stadt/Ort des Kontoinhabers
AN, 40 J
OWNERZIP
Postleitzahl des Kontoinhabers
AN, 10 J
PM
Zahlungsmethode

AN, 25

"Direct Debits DE”

J

Note: Diese Felder können in der DirectLink XML-Antwort zurückgegeben werden und müssen in die SHA-IN-Berechnung eingeschlossen werden (optional auch SHA-OUT).

(* Falls die Gutschrift Option verfügbar und aktiv ist, und DTAUS-Gutschrift verfügbar ist)

7.1.3 Direct Debits NL

Die folgende Tabelle enthält die spezifischen Parameterwerte, welche die Übertragung von Bankeinzug NL-Transaktionen (Direct Debits NL) über DirectLink ermöglichen.

Format: AN=alphanumerisch / N=numerisch, die maximal erlaubte Anzahl der Zeichen
Feld
Beschreibung
Format/Wert
CARDNO
Bankkontonummer
Reguläre holländische Kontonummer: max. 10 alphanumerische Zeichen (falls weniger, links mit Nullen auffüllen).

ODER

IBAN-Kontonummer: max. 35 alphanumerische Zeichen (SEPA)

CN
Name des Bankkontoinhabers
AN, 35
ED
Verfallsdatum
„99/99“ oder „9999“
OPERATION

Operationscode (Auszuführende Aktion)

A, 3

Mögliche Werte:

  • SAL or SAS: Einzug von Geld vom Bankkonto
  • RFD or RFS: Gutschrift von Geld auf das Bankkonto (Erstattung)
OWNERTOWN
Stadt des Bankkontoinhabers
AN, 40
PM Zahlungsmethode

AN, 25

“Direct Debits NL”

Nur relevant für SEPA-Transaktionen (*):
BIC
Bankidentifikationscode.
AN, 11
MANDATEID

Eindeutige Auftragsreferenz.

Note: Ohne Angabe wird die ORDERID verwendet.

AN, 35

Keine Leerzeichen; darf nicht mit einem Schrägstrich "/" beginnen oder enden, und darf keine zwei aufeinanderfolgende Schrägstriche enthalten.

SEQUENCETYPE

Typs der Bankeinzugstransaktion

Note: Ohne Angabe wird die Transaktion als einmalig („OOFF“) betrachtet.

Mögliche Werte zur Angabe des Typs der Bankeinzugstransaktion (AN, 4):
  • "FRST": Erste Sammlung einer Reihe von Bankeinzugsanweisungen
  • "RCUR": Bankeinzugsanweisungen, wobei die Autorisierung des Debitors für reguläre, vom Kreditor eingeleitete Bankeinzugstransaktionen verwendet wird
  • "FNAL": Letzte Sammlung einer Serie von Bankeinzugsansweisungen (danach kann dieselbe MandateID nicht mehr verwendet werden)
  • "OOFF": Bankeinzugsanweisung, wobei die Autorisierung des Debitors zur Einleitung einer einzelnen Bankeinzugstransaktion verwendet wird
SIGNDATE

Datum, an dem der Auftrag vom Kunden unterschrieben wurde.

Note: Ohne Angabe wird das Transaktionsdatum verwendet

JJJJMMTT

(*SEPA: Single Euro Payments Area)

Hinweis: Diese Felder können in der DirectLink XML-Antwort zurückgegeben werden und müssen in die SHA-IN-Berechnung (optional auch SHA-OUT) eingeschlossen werden.

Bei bestimmten (nicht mit Kreditkarten verbundenen) Zahlungsmethoden können Sie keine neuen Transaktionen via DirectLink senden. Sie haben jedoch die Möglichkeit, bestimmte Datenpflegeanfragen via DirectLink zu senden. Dies ist der Fall bei: PostFinance Card, PostFinance e-finance, PayPal Express Checkout und TUNZ. Beim Senden einer Datenpflegeanfrage müssen PM/BRAND/CARDNO/ED nicht angegeben werden. Damit ist es auch nicht erforderlich, bestimmte Werte für diese Zahlungsmethoden zu senden.

8 3-D Secure v1.0

8.1 Einleitung

Das 3-D Secure-Protokoll gestattet es, den Karteninhaber während des Kaufprozesses zu identifizieren. Der Karteninhaber muss während des Identifikationsprozesses mit dem Internet verbunden sein. Deshalb funktioniert 3-D Secure nicht für Callcenter- oder wiederkehrende Zahlungen.

Visa hat das Protokoll 3-D Secure unter dem Namen Verified By Visa implementiert, MasterCard unter dem Namen SecureCode, JCB unter dem Namen J-Secure und American Express unter dem Namen SafeKey.

Das Prinzip der Integration von DirectLink mit 3-D Secure ist, eine Zahlung im DirectLink-Modus zu initiieren und sie im e-Commerce-Modus zu beenden, wenn eine Authentifizierung des Karteninhabers verlangt wird.

Dieses Dokument beschreibt die Integration des Protokolls 3-D Secure in DirectLink. Weitere Informationen über DirectLink oder e-Commerce entnehmen Sie bitte der Dokumentation zu DirectLink oder e-Commerce.

Der Transaktionsablauf umfasst folgende Schritte:

  1. Sie senden uns für die Transaktion eine DirectLink-Anfrage mit einer Reihe von zusätzlichen Parametern (vgl. Zusätzliche Anfrageparameter).
  2. 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).
  3. Ist der Karteninhaber registriert, enthält die Antwort auf die DirectLink-Anfrage einen bestimmten Zahlungsstatus und HTML-Code, der an den Kunden zurückgegeben muss, um den Identifikationsprozess zu starten (vgl. Zusätzliche Rückgabefelder). Der Block aus HTML-Code startet automatisch den Identifikationsprozess zwischen dem Karteninhaber (Kunde) und seiner ausstellenden Bank.
  4. Der Karteninhaber identifiziert sich selbst auf der Seite der ausstellenden Bank.
  5. Unser System empfängt die Identifikationsantwort vom Aussteller.
  6. Wenn die Identifikation erfolgreich war, übermittelt unser System die eigentliche Finanztransaktion an den Acquirer.
  7. Das Ergebnis der globalen Identifikation und des Online-Autorisierungsvorgangs erhalten Sie über e-Commerce-Modus-Rückmeldungskanäle.

Anmerkungen:

  • Ob die Haftungsumkehr gilt, hängt von Ihrem Acquirer-Vertrag ab. Daher empfehlen wir Ihnen, die Allgemeinen Geschäftsbedingungen Ihres Acquirers zu prüfen.
  • Wenn der Karteninhaber nicht (in Schritt 3) registriert wurde, erhalten Sie die XML-Standardantwort mit dem Ergebnis des Online-Autorisierungsprozesses.
  • Um die genauen Zahlungsstatus-/Fehlercodes (in Schritt 7) zu erhalten, müssen Sie die Online- oder Offline-Post-Sale-Rückmeldungen wie in der E-Commerce-Dokumentation beschrieben implementieren.

8.2.1 Zusätzliche Anfrageparameter

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).

Für weitere Informationen siehe Transaction-feedback.

8.2.2 Zusätzliche Rückgabefelder

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.

8.2.3 Anmerkungen

Testkarten

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

Marke Kartenummer Ablaufdatum
Passwort
VISA 4000000000000002 Beliebiges Datum in der Zukunft 1111
MasterCard 5300000000000006 Beliebiges Datum in der Zukunft 11111
American Express 371449635311004 Beliebiges Datum in der Zukunft
11111
Falsche Identifikation

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

STATUS = 0

NCSTATUS = 5

NCERROR = 40001134

9 3-D Secure v2.1

9.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 /… ).

9.2 Ablauf der 3-D-Transaktion über DirectLink

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.

ParameterBeschreibungFormatVerpflichtend
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:
true
false
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 -840 und 720
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
CN Name des Karteninhabers (Kunden) Name des Karteninhabers (Kunden)
Länge: variabel,max. 35
Sonderzeichen sind erlaubt, außer Anführungszeichen. Die meisten Käufer überprüfen den Kundennamen nicht, da Namen auf verschiedene Arten geschrieben werden können
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.

Obwohl diese Parameter optional sind, wird jedoch von den großen Kartenanbietern dringend empfohlen, dass die folgenden Parameter in Ihrer Anfrage enthalten sein sollten, da dadurch die Chancen für einen reibungslosen Fluss steigen.

ECOM_BILLTO_POSTAL_CITY
ECOM_BILLTO_POSTAL_COUNTRYCODE
ECOM_BILLTO_POSTAL_STREET_LINE1
ECOM_BILLTO_POSTAL_STREET_LINE2
ECOM_BILLTO_POSTAL_STREET_LINE3
ECOM_BILLTO_POSTAL_POSTALCODE
REMOTE_ADDR
CN
EMAIL

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.

9.2.1 Zusätzliche Anfrageparameter

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.

9.2.2 Zusätzliche Rückgabefelder

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.

9.2.3 3-D Secure v2.1 MasterCard+

Um die Wahrscheinlichkeit eines reibungslosen Flusses zu maximieren, hat MasterCard die spezielle Erweiterung „MasterCard 2.1+“ entwickelt. TDas bedeutet, dass Sie zusätzlich zu den empfohlenen Parametern drei weitere Parameter senden können.

ParameterNameBeschreibungFormat
Mpi.merchantFraudRate
Händlerbetrugsrate
Händlerbetrugsrate im EWR (jeder EWR-Kartenbetrug geteilt durch alle EWR-Kartenvolumina) berechnet gemäß PSD2 und den technischen Regulierungsstandards (Regulatory Technical Standards, RTS).

Achten Sie darauf, dass Sie die Rate gemäß PSD2/RTS Artikel 19 berechnen, da weder MasterCard noch wir die Bewertung validieren.

Länge: max. 2 Zeichen
Format: Ganzzahl 1=> 99
Gültige Werte:

  • 1 (entspricht einer Betrugsrate von mindestens 1 Basispunkt [bp], was wiederum 0,01 % entspricht)
  • 2 (entspricht einer Betrugsrate zwischen 1 bp +/- und 6 bp)
  • 3 (entspricht einer Betrugsrate zwischen 6 bp +/- und 13 bp)
  • 4 (entspricht einer Betrugsrate zwischen 13 bp +/- und 25 bp)
  • 5 (entspricht einer Betrugsrate von mehr als 25 bp)

Mpi.secureCorporatePayment Sichere Unternehmenszahlungen Gibt an, dass dedizierte Zahlungsprozesse und -verfahren angewandt wurden und eine potenzielle Ausnahmeregelung für sichere Unternehmenszahlungen gilt.
Senden Sie dieses Feld nur mit „J“, wenn das Feld für die Käuferbefreiung leer ist, da sich
die Käuferbefreiung und sichere Zahlungen gegenseitig ausschließen.
Der Verzeichnisdienst (Directory Service, DS) validiert jedoch nicht die Bedingungen in der Erweiterung. Der DS übergibt die gesendeten Daten.
Sie können optional angeben, ob sie für die dedizierten Prozesse und Protokolle gemäß PSD2/RTS Artikel 17 gelten. Dadurch kann der Herausgeber möglicherweise die Befreiung von der sicheren Unternehmenszahlung beantragen.

Länge: 2 Zeichen
Datentyp: String
Gültige Werte:

  • Y
  • N
Mpi.threeDSRequestorChallengeIndicator Händlerabfrage-Indikator Gibt an, ob Sie für diese Transaktion eine Abfrage anfordern. Beispiel:
Für 01-PA haben Sie möglicherweise Bedenken hinsichtlich der Transaktion und fordern eine Abfrage an.
Für 02-NPA kann beim Hinzufügen einer neuen Karte eine Abfrage erforderlich sein.

Für lokale/regionale Mandate oder andere Variablen.
Länge: 2 Zeichen
Datentyp: String
Gültige Werte:
  • 01 = Keine Präferenz
  • 02 = Keine Abfrage angefordert
  • 03 = Abfrage angefordert; Händlerpräferenz 
  • 04 = Abfrage angefordert; Mandat
  • 05 = Keine Abfrage angefordert [Transaktionsrisikoanalyse wird bereits durchgeführt]
  • 06 = Keine Abfrage angefordert [nur Datenfreigabe]
  • 07 = Keine Abfrage angefordert [SCA wird bereits durchgeführt]
  • 80-99 = Reserviert für DS-Nutzung

Durch das Senden dieser Parameter erhalten alle Beteiligten viel mehr Informationen. Dies führt nicht nur zu mehr reibungslosen Flüssen, sondern auch zu höheren Bewilligungsquoten und weniger Betrugsfällen.
Beachten Sie, dass diese zusätzlichen Parameter nur mit MasterCard-Transaktionen funktionieren, aber nicht mit anderen Zahlungsmethoden.

9.2.4 Anmerkungen

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

9.3 Ausschlüsse und Ausnahmen für 3DsV2

9.3.1 3DSv2 und Ausschlüsse

Mit der Einführung von 3DSv2 wird die Authentifizierung der Karteninhaber im Allgemeinen obligatorisch, wie in der Zweiten Zahlungsdiensterichtlinie der EU (2015/2366 PSD2) festgelegt. Trotzdem werden einige Transaktionen von dieser Regel ausgeschlossen, wenn eines der folgenden Szenarien gilt:

  • Bestellung per E-Mail/telefonische Bestellung
  • One leg journey - Der PSP (der Acquirer) des/der Zahlungsempfängers/Zahlungsempfängin oder der PSP (die Hausbank) des/der Zahlenden befindet sich außerhalb des EWR
  • Übertragbare Prepaid-Karten mit Guthaben von bis zu 150€ (Artikel 63)
  • MIT - vom Händler initiierte Transaktionen

9.3.2 SCA und 3DS reibungsloser / Challenge-Flow

Teil dieser neuen Regelung ist die Strong Customer Authentication (SCA). Dies beinhaltet die Möglichkeit, dass der Herausgeber (die Bank des Karteninhabers) zusätzliche Angaben vom Karteninhaber erfragt. In einem solchen Szenario führt der Authentifizierungsprozess zu einem Challenge-Flow (erfordert vom Karteninhaber eine aktive Authentifizierung) und nicht zu einem reibungslosen Flow (erfordert keine Authentifizierung durch den Karteninhaber).

Wir bieten unseren Händlern allerdings die Möglichkeit, den bevorzugten Flow anzugeben. Dies kann durch die Übermittlung zusätzlicher Parameter erreicht werden, die vom Herausgeber zur Risikobewertung verwendet werden. Je nach Entscheidung des Herausgebers kann ein reibungsloser Flow stattfinden. In einigen Szenarien könnte 3DS sogar völlig übersprungen werden, wenn bestimmte Ausnahmen gelten

9.3.3 Angabe des bevorzugten Flows

Zur Angabe der Präferenz für einen reibungslosen Flow während der Authentifizierungsanforderung kann der Händler den zusätzlichen Parameter Mpi.threeDSRequestorChallengeIndicator senden. Je nach Einschätzung des Betrugsrisikos durch den Händler können spezifische Werte gesendet werden (z. B. für eine geringe Risikobewertung: 02, für ein erhöhtes Betrugsrisiko: 03)

Parameter Werte Obligatorisch / Optional
Mpi.threeDSRequestorChallengeIndicator 01 = Kein Präferenz
02 = Keine Abfrage angefordert
03 = Keine Abfrage angefordert; Händlerpräferenz
04 = Abfrage angefordert: Mandat
Obligatorisch (falls ein Flow bevorzugt wird)

Der Händler kann zusätzlich die Möglichkeit eines reibungslosen Flow / Umwandlungssatzes durch Senden weiterer optionaler Felder erhöhen.

9.3.4 Ausnahmen von 3DS

Bei einigen Transaktionen kann der Händler möglicherweise 3DS überspringen (was zu einem reibungslosen Flow führt) und sich direkt für die Autorisierung entscheiden. Dieser Prozess beschränkt sich auf Transaktionen, die entweder von SCA ausgeschlossen werden (wie oben beschrieben) oder die von spezifischen Ausnahmen profitieren können. Diese Ausnahmen müssen Teil einer Vereinbarung zwischen dem Händler und seinem Erwerber sein. In einem Szenario wie diesem gibt der Händler an, dass er den Authentifizierungsprozess überspringen möchte, indem er diese zusätzlichen Parameter sendet:


Parameter Werte Obligatorisch / Optional
FLAG3D
N = Überspringen des 3DS-Authentifizierungsprozesses Obligatorisch (falls 3DS übersprungen werden soll)
3DS_EXEMPTION_INDICATOR
Angabe einer Begründung für das Überspringen von 3DS. Die numerischen Werte können je nach Transaktion zutreffend sein

03 = Herausgeber TRA*
04 = Ausnahme für einen geringen Betrag
05 = Händler/Erwerber TRA*
06 = Auf die weiße Liste setzen
07 = Unternehmen
08 = Verspäteter Versand
09 = Delegierte Authentifizierung (zertifiziertes Wallet)
Obligatorisch (falls 3DS übersprungen werden soll)
* Analyse des Transaktionsrisikos

Es bleibt jedoch dem Herausgeber überlassen, ob ein Authentifizierungsprozess stattfinden muss. Falls der Herausgeber auf 3DS besteht, wird die Transaktion abgelehnt.