Leitfaden zu 3-D-Secure-Status
1. Einleitung
Mit der Einführung der PSD2-Richtlinie, ist es wichtiger denn je, Ihre 3-D-Secure-Transaktionen im Auge zu behalten.
Egal, ob Sie Gehostete Zahlungsseite oder DirectLink verwenden, wir machen beides ganz leicht für Sie. In diesem Handbuch erfahren Sie, wo Sie die verfügbaren Informationen finden und wie Sie diese verstehen können.
Werden Sie in kürzester Zeit ein 3-D-Secure-Experte!
2. 3-D Secure Status verstehen
Abgesehen von klar definierten Ausschlüssen und Ausnahmen müssen Ihre Kunden eine 3-D-Secure-Authentifizierungsprüfung durchlaufen. Die Transaktion erhält einen 3-D-Secure-Status (das Ergebnis der Authentifizierungsprüfung) sowie einen globalen Transaktionsstatus (das Ergebnis der Autorisierungsanfrage).
Deshalb sind beide das Ergebnis von zwei verschiedenen Schritten:
- 3-D-Secure-Status: Zunächst müssen Ihre Kunden nachweisen, dass sie die rechtmäßigen Eigentümer der für die Transaktionen verwendeten Kreditkarten sind. Diese Authentifizierungsprüfung erfolgt in den Online-Portalen der Kreditkartenherausgeber Ihrer Kunden. Eine Übersicht über die möglichen Ergebnisse finden Sie in unserem Parameter Cookbook
- Globaler Transaktionsstatus: Als Nächstes prüfen Ihre Akzeptanzpartner, ob genügend Mittel für die Transaktion vorhanden sind. Dazu wenden sie sich an Ihre Kreditkartenherausgeber. Dies führt dann zu einer (nicht) erfolgreichen Autorisierung. Eine Übersicht über die möglichen Ergebnisse finden Sie in unserem Leitfaden zu Transaktionsstatus
Sie können die Ergebnisse selbst im Back Office sowie in unserem Reporting-Tool nachsehen:
- Back Office: Schlagen Sie die Transaktion unter Vorgänge > Transaktionsansicht nach. Aktivieren Sie in der Übersicht „Status“ (der globale Transaktionsstatus) und das Bild zusammen mit einer Beschreibung (der 3-D-Secure-Status).
Im Bild sehen Sie, wo Sie den 3-D-Secure-Status und den globalen Transaktionsstatus im Back Office nachsehen können. - Reporting: Achten Sie darauf, dass Sie Ihr Profil wie im entsprechenden Video. beschrieben konfigurieren. Die Parameter ECI/STATUS geben den 3-D-Secure-Status bzw. den globalen Transaktionsstatus an
Wenn Sie Transaktionen über Gehostete Zahlungsseite verarbeiten, führt unsere Plattform Version 1 automatisch für Sie aus. .
Diese Tabelle bietet Ihnen eine vollständige Übersicht über mögliche Szenarien und wie unsere Plattform sie Ihnen jeweils anzeigt:
| 3-D-Secure-Status (Back Office) | 3-D-Secure-Status (Parameter ECI in Reporting | Transaktionsstatus | Beschreibung |
|---|---|---|---|
| Ganzer Daumen nach oben/ "Cardholder has been successfully identified! V1“ |
5 | Je nach Autorisierungsergebnis Ihrer Akzeptanzpartner entweder 2 5 9 |
Ihre Kunden haben die Authentifizierungsprüfung bestanden. Bei betrügerischen Rückbelastungen haften die Kreditkartenherausgeber. |
| Daumen halb nach oben/ "Cardholder not identified: liability shift rules to be applied (depending on transaction date and credit card country)" |
6 12 |
Je nach Autorisierungsergebnis Ihrer Akzeptanzpartner entweder 2 5 9 |
Ihre Kunden konnten die Authentifizierungsprüfung nicht durchführen. Bei betrügerischen Rückbelastungen haften die Kreditkartenherausgeber. |
| Ausrufezeichen/ "Cardholder authentication failed!" |
91 | 2 | Ihre Kunden haben die Authentifizierungsprüfung aufgrund eines falschen Passworts/einer falschen PIN nicht bestanden. Unsere Plattform führt den Autorisierungsschritt nicht aus und bricht die Transaktion ab. |
| Kein Bild/ "Cardholder authentication not technically possible!!!" |
92 | Je nach Autorisierungsergebnis Ihrer Akzeptanzpartner und Ihrer Einstellung entweder 2 5 9 |
Die Authentifizierung war aufgrund eines technischen Fehlers nicht möglich. Unsere Plattform führt den Autorisierungsschritt standardmäßig nicht aus und bricht die Transaktion ab (Status 2). Auf unserer Plattform können Sie sich allerdings trotzdem wie im entsprechenden Kapitel beschrieben für die Autorisierung entscheiden. |
| Ganzer Daumen nach oben/ "Cardholder has been successfully identified! V2 challenge" |
5 | Je nach Autorisierungsergebnis Ihrer Akzeptanzpartner entweder 2 5 9 |
Ihre Kunden haben die Authentifizierungsprüfung bestanden und sich aktiv gemäß dem SKA-Protokoll ("aktive Authentifizierung") identifiziert. Bei betrügerischen Rückbelastungen haften die Kreditkartenherausgeber. |
| Ganzer Daumen nach oben/ "Cardholder has been successfully identified! V2 frictionless" |
5 | Je nach Autorisierungsergebnis Ihrer Akzeptanzpartner entweder 2 5 9 |
Ihre Kunden haben die Authentifizierung bestanden. Da Sie zusammen mit der Transaktion ausreichend Informationen gemäß dem SKA-Protokoll zur Verfügung gestellt haben, mussten sich Ihre Kunden nicht aktiv identifizieren („Authentifizierung im Hintergrund“). |
Beachten Sie, dass dies nur ein Anhaltspunkt ist, da die definitive Verantwortlichkeit von verschiedenen Faktoren abhängt.
3. Das Authentifizierungsprotokoll verstehen
Unserer Plattform ist nicht nur den 3-D-Secure-Status Ihrer Transaktionen bekannt, sondern sie speichert auch die Protokolldateien für jede Authentifizierungsprüfung. Diese Dateien enthalten detaillierte Informationen zum genauen Ablauf, der zum Ergebnis der Authentifizierungsprüfung führt.
Diese Informationen können Sie für jede Transaktion im Backoffice unter Vorgänge > Transaktionsansicht nachsehen. Wenn Sie in der Übersicht auf „AUTHENTICATION LOG“ klicken, können Sie die Tabellenübersicht aufrufen. Jede Zeile steht für einen einzelnen Schritt einer vollständigen Authentifizierungsprüfung.
.
| Spalte | Beschreibung |
|---|---|
| MsgType |
Ausgeführter Schritt der aktuellen Authentifizierungsprüfung.
Wenn unsere Plattform 3-D Secure Version 1 ausführen musste, sind diese Werte möglich:
|
| Status |
Status/Ergebnis des ausgeführten Schritts.
Wenn unsere Plattform 3-D Secure Version 1 ausführen musste, sind diese Werte möglich:
|
| Date |
Zeitstempel des ausgeführten Schritts |
| Details |
Informationen/Parameter zum ausgeführten Schritt
|
| Card N° |
Die im jeweiligen Schritt verwendete Kreditkarte |
Im Bild sehen Sie, wo Sie die Authentifizierungsprotokolle im Backoffice finden können.
Im Bild sehen Sie eine typische Tabelle mit Authentifizierungsprotokollen im Backoffice.
Rückfall auf 3-D Secure Version 1 und wie Sie damit umgehen
Unsere Plattform kann Transaktionen im Modus 3-D Secure Version 1 verarbeiten (siehe Spalte "MsgType" im entsprechenden Authentifizierungsprotokoll). Berücksichtigen Sie dies, da Version 1 im Oktober 2022 komplett eingestellt wird. Damit Sie erfahren, wie Sie mit solchen Transaktionen umgehen, sehen Sie sich die Tabelle mit möglichen Ursachen und Lösungen an:
| Fehlermeldung (Spalte "MsgType") | Beschreibung | Lösung |
|---|---|---|
| V2ParamMissing | Fehlende obligatorische Parameter für Version 2 | Achten Sie darauf, dass Sie Ihre DirectLink Integration zu aktualisieren. Wenn Sie Transaktionen über die Gehostete Zahlungsseite abwickeln, führt unsere Plattform dies automatisch für Sie aus |
| acquirerBIN/acquirerMerchantID not recognized | Sie müssen für Version 2 bei MasterCard registriert sein. | Kontaktieren Sie für eine entsprechende Anfrage entweder Ihren Akzeptanzpartner oder uns |
| "Detail":"billAddrCountry; V2Error caused fallback to v1 "Detail":"billAddrLine1,billAddrLine2 "Detail":"cardholderName; "Detail":"email; "Detail":"acctNumber; "Detail":"browserLanguage" "Detail":"acctInfo.nbPurchaseAccount,acctInfo.txnActivityDay,acctInfo.txnActivityYear" "Detail":"Name(s) of erroneous fields separated by (,) : acctInfo.suspiciousAccActivity,threeDSRequestorAuthenticationInfo.threeDSReqAuthMethod, acctInfo.shipAddressUsageInd,acctInfo.chAccAgeInd,acctInfo.shipNameIndicator,acctInfo.paymentAccAge,acctInfo.paymentAccInd,acctInfo.shipAddressUsage" |
Fehler vom directory server (DS) empfangen. ISO-Code gemäß ISO-Tabellen ungültig (für Land oder Währung) |
Ungültige Parameter für die (obligatorischen) v2-Parameter gesendet Achten Sie darauf, dass Sie Ihre DirectLink Integration entsprechend aktualisieren |
| Error received from the DS. Format of one or more elements is invalid according to the specification","Detail":"threeDSRequestorURL" | Die Angaben im Back Office zu Ihrer Website stimmen nicht (Konfiguration > Konto > Ihre Kontaktdaten > Homepage) |
Korrigieren Sie Ihre URL im Back Office |
| Specific reason fallbacks to V1 because transaction status will be blocked by issuer MC Fallback to V1 since Transaction status reason is 82 Cb Fallback to V1 since Transaction status reason is 13 |
Unbekannte Fehler |
Diese Fehler treten bei einer Drittpartei auf. Sie können sie nicht beheben |
4. Transaktion fortfahren/abbrechen
Gemäß den PSD2-Richtlinien erreichen Transaktionen, für die aufgrund technischer Probleme keine Authentifizierungsprüfung durchgeführt werden konnte, standardmäßig den Status 2. Unsere Plattform bricht die Transaktion ab, indem sie die Autorisierung nicht ausführt.
Sie können dieses Standardszenario jedoch außer Kraft setzen. Weisen Sie dazu unsere Plattform an, trotzdem mit dem Autorisierungsschritt fortzufahren. Mit diesen Schritten können Sie diese Option verwenden:
- Melden Sie sich im Back Office an. Gehen Sie zu Fortgeschritten > Betrugserkennung > 3D-Secure
- Wählen Sie die Zahlungsart aus, für die Sie das Standardszenario überschreiben möchten. Klicken Sie dazu auf “ÄNDERN”
- Wählen Sie die Optionsfeldoption “Weiter” für sowohl "Transaktion fortsetzen/unterbrechen, wenn ein technisches Problem die Verbindung zum American Express Verzeichnis während der 3D-Secure Registrierungsprüfung verhindert." als auch "Transaktion fortsetzen/unterbrechen, wenn der Service für die Identifikation des Karteninhabers vorübergehend nicht verfügbar ist.". Bestätigen Sie dies mit “ABSCHICKEN”
Das Bild zeigt, wo man im Back Office die Funktion zum Transaktionsfortfahren/-Unterbrechen einstellen kann
- Mit dieser Option können Sie für betrügerische Rückbelastungen haftbar gemacht werden
- Es besteht eine hohe Wahrscheinlichkeit, dass Ihre Transaktion trotzdem Status 2 erreicht, da jeder Online-Käufer gemäß PSD2 eine Authentifizierungsprüfung bestehen muss
5. Teilweises Ende der Haftungsumkehr
Alle unten aufgeführten Hauptsysteme sind aufeinander abgestimmt und planen, die offizielle Einstellung von 3DSv1 im Oktober 2022 tatsächlich erfolgen zu lassen:
- VISA
- Mastercard
- American Express
- JCB
- Diners Discover
VISA und Mastercard haben bereits eine Übergangsfrist zu EMV 3DS angekündigt.
Im Wesentlichen werden nur vollständig authentifizierte Transaktionen von VISA und Mastercard unterstützt. Das führt zu einer Verringerung des Betrugshaftungsschutzes für Händler, die 3DSv1 anwenden.
Sie können dies im Ingenico Backoffice als „Karteninhaber nicht identifiziert: anzuwendende Haftungsumkehrregeln (je nach Transaktionsdatum und Kreditkartenland)“ und ECI=12 im Feedback nach dem Verkauf sehen.
Für dieselbe Meldung „Karteninhaber nicht identifiziert: anzuwendende Haftungsumkehrregeln (je nach Transaktionsdatum und Kreditkartenland)“ und ECI=6 gilt die Haftungsumkehr weiterhin.
Visa
| Visa Secure 3DS V1 | Vor dem 16. Oktober 2021 | Nach dem 16. Oktober 2021 |
|---|---|---|
| Vollständig authentifiziert (Kreditkartenherausgeber nimmt teil) | Betrugshaftung geht auf den Kreditkartenherausgeber über (ECI = 5) | Keine Änderung |
| Versuchte Authentifizierung (Kreditkartenherausgeber nimmt nicht teil) | Betrugshaftung geht auf den Kreditkartenherausgeber über (ECI = 12) | Betrugshaftung liegt beim Händler (ECI = 12) Anmeldeergebnis = N |
Mastercard
| Mastercard Identity Check 3DS V1 | Vor dem 5. Oktober 2021 | Nach dem 5. Oktober 2021 |
|---|---|---|
| Vollständig authentifiziert (Kreditkartenherausgeber nimmt teil) | Betrugshaftung geht auf den Kreditkartenherausgeber über (ECI = 5) | Keine Änderung |
| Versuchte Authentifizierung (Kreditkartenherausgeber nimmt nicht teil) | Betrugshaftung geht auf den Kreditkartenherausgeber über (ECI = 12) | Betrugshaftung liegt beim Händler (ECI = 12) Anmeldeergebnis = N |