Zurück zu den Leitfäden SECURITY

3D-Secure-Payment-Gateway: Wie 3DS2 Haendler vor Betrug schuetzt

3D Secure ist ein von den Kartensystemen entwickeltes Authentifizierungsprotokoll, das Online-Kartentransaktionen eine zusaetzliche Identitaetsverifizierungsebene hinzufuegt. Wenn ein Kunde ueber ein 3D-Secure-faehiges Gateway bezahlt, prueft seine ausgebende Bank die Transaktion vor der Autorisierung, entweder durch eine reibungslose Hintergrundpruefung oder indem der Kunde zur Authentifizierung ueber seine Banking-App aufgefordert wird. Fuer Haendler bietet 3D Secure zwei wesentliche Vorteile: Es reduziert Betrugsverluste bei Online-Transaktionen erheblich und verschiebt die Chargeback-Haftung bei Betrugsstreitigkeiten vom Haendler auf die ausgebende Bank. Dieser Leitfaden erklaert, wie 3D Secure funktioniert, wie sich Version 2 von Version 1 unterscheidet und wie man 3DS2 ueber RoxPay implementiert.

Was 3D Secure ist und wie es funktioniert

3D Secure (3DS) ist ein XML-basiertes Authentifizierungsprotokoll fuer Kartentransaktionen ohne physische Kartenpraesenz. Die drei Domaenen im Namen beziehen sich auf die Haendler-Domaene, die Acquirer-Domaene und die Interoperabilitaets-Domaene (das Kartensystemnetzwerk und die ausgebende Bank). Diese drei Parteien nehmen gemeinsam an der Verifizierung teil, dass die Person, die die Transaktion initiiert, der autorisierte Karteninhaber ist.

Transaktionsablauf mit 3DS:
Der Kunde gibt beim Checkout seine Kartendaten ein und schickt die Zahlung ab. Das Gateway des Haendlers sendet die Transaktion mit einer 3DS-Authentifizierungsanfrage. Das Kartensystem leitet die Anfrage an den Access Control Server des Kartenausgebers weiter. Der Aussteller fuehrt eine Risikobewertung der Transaktion durch. Wenn die Risikobewertung ein geringes Risiko anzeigt (reibungsloser Ablauf), wird die Transaktion ohne Kundeninteraktion authentifiziert. Liegt das Risiko ueber der Schwelle fuer den reibungslosen Ablauf, wird der Kunde zur Authentifizierung aufgefordert, typischerweise durch Bestaetigung einer Push-Benachrichtigung in seiner Banking-App, Eingabe eines Einmalpassworts oder biometrische Bestaetigung. Das Authentifizierungsergebnis (authentifiziert, versucht oder fehlgeschlagen) wird an das Gateway des Haendlers zurueckgesendet, das es in die Autorisierungsanfrage an den Acquirer aufnimmt.

Die Haftungsverschiebung: Wenn eine Transaktion erfolgreich ueber 3DS authentifiziert wurde und der Karteninhaber sie spaeter als betrueglich anficht, verschiebt sich die Chargeback-Haftung vom Haendler auf die ausgebende Bank. Die ausgebende Bank hat die authentifizierte Transaktion genehmigt; sie kann dann nicht erfolgreich anfechten, dass sie unberechtigterweise war. Diese Haftungsverschiebung ist der primaere kommerzielle Vorteil von 3DS fuer Haendler.

Fuer Haendler, die ein High-Risk-Payment-Gateway betreiben, ist die Implementierung von 3DS2 besonders wichtig, weil Hochrisikokategorien tendenziell erhoehte Betrugs- und Friendly-Fraud-Raten aufweisen, was den Haftungsschutz kommerziell bedeutsam macht.

3DS1 vs. 3DS2: Was sich geaendert hat und warum es wichtig ist

Die urspruengliche 3D-Secure-Spezifikation (3DS1) wurde Anfang der 2000er Jahre eingefuehrt. Obwohl sie einen Mechanismus zur Haftungsverschiebung bereitstellte, hatte sie erhebliche Usability- und Konversionsprobleme, die Haendler als Warenkorbabbruch beim Authentifizierungsschritt erlebten. 3DS2 (EMV 3DS) wurde entwickelt, um diese Probleme zu behoeben.

3DS1-Probleme:
3DS1 erforderte eine Weiterleitung zur Authentifizierungsseite des Ausstellers, die oft schlecht gestaltet und fuer Kunden verwirrend war. Das von vielen Ausstellern verwendete statische Passwortmodell (Verified by Visa, MasterCard SecureCode) war leicht zu vergessen und erzeugte bei jeder Transaktion Reibung. Auf Mobilgeraeten war der auf Weiterleitungen und Popups basierende Ablauf besonders problematisch. Viele Haendler haben 3DS1 deaktiviert, weil der Authentifizierungsschritt mehr Transaktionsabbrueche verursachte als die Betrugsverluste, die sie zu verhindern versuchten.

3DS2-Verbesserungen:
3DS2 fuehrt ein umfangreiches Datenteilungsmodell ein. Das Gateway des Haendlers sendet bis zu 150 Datenpunkte mit der Authentifizierungsanfrage, einschliesslich Geraete-Fingerabdruck, Browser-Eigenschaften, Bestellhistorie und Verhaltensignale. Der Aussteller nutzt diese Daten fuer eine Risikoentscheidung. Bei risikoarmen Transaktionen kann der Aussteller eine reibungslose Authentifizierung gewaehren, was bedeutet, dass der Kunde nie aufgefordert wird, etwas zu tun, und die Transaktion nahtlos fortschreitet.

Authentifizierungsmethoden in 3DS2: Wenn eine Authentifizierung erforderlich ist, unterstuetzt 3DS2 moderne Methoden: Push-Benachrichtigungen an eine Banking-App mit biometrischer Bestaetigung, Einmalpasswoerter per SMS und In-App-Authentifizierung ohne Weiterleitung. Diese sind erheblich weniger stoerend als die 3DS1-Popup-Weiterleitung.

PSD2 und Starke Kundenauthentifizierung: Die EU-Richtlinie ueber Zahlungsdienste (PSD2) schreibt die Starke Kundenauthentifizierung (SCA) fuer die meisten europaeischen Kartentransaktionen ohne physische Kartenpraesenz vor. 3DS2 ist der primaere Mechanismus fuer die SCA-Compliance. Aussteller sind verpflichtet, SCA auf Transaktionen anzuwenden, die sich nicht fuer eine Ausnahme qualifizieren. Haendler, die 3DS2 nicht unterstuetzen, stellen fest, dass Transaktionen von Ausstellern, die SCA erfordern, aber nicht abschliessen koennen, weil das Gateway keine 3DS2-Authentifizierungsdaten uebertraegt, soft-abgelehnt werden.

Wie 3D Secure die Chargeback-Haftung fuer Haendler reduziert

Die durch die 3D-Secure-Authentifizierung bereitgestellte Haftungsverschiebung ist der Mechanismus, durch den Haendler Chargeback-Verluste bei Betrugsstreitigkeiten reduzieren.

Wie die Haftungsverschiebung in der Praxis funktioniert: Ein Kunde schliesst einen Kauf ab und authentifiziert sich ueber 3DS2 (zum Beispiel durch Bestaetigung einer Push-Benachrichtigung in seiner Banking-App). Die Transaktion wird verarbeitet und die Waren werden geliefert. Einen Monat spaeter kontaktiert der Kunde seine ausgebende Bank und behauptet, die Transaktion war unberechtigt. Die Bank leitet einen Chargeback unter einem Betrugsgrundcode ein (Visa 10.4, Mastercard 4853).

Wenn das Gateway des Haendlers die Erwiderung einreicht, enthaelt es den 3DS2-Authentifizierungsdatensatz: die Authentifizierungstransaktions-ID (ATID), den Authentifizierungsstatus (authentifiziert) und den ECI-Wert, der eine vollstaendige Authentifizierung anzeigt. Dieser Datensatz beweist, dass die ausgebende Bank des Karteninhabers selbst die Transaktion authentifiziert hat. Das Dispute-Team der Bank sieht, dass dieselbe Bank, die jetzt den Streit bearbeitet, diejenige war, die die Transaktion authentifiziert hat. In der Praxis fuehrt dies in der ueberwiegenden Mehrheit der Faelle zur Umkehrung des Chargebacks.

Transaktionen, die nicht von der Haftungsverschiebung profitieren: Nicht alle 3DS2-Ergebnisse bieten eine Haftungsverschiebung. Eine Transaktion, die den Authentifizierungsprozess durchlaeuft, aber zu einem "versuchten" Authentifizierungsstatus fuehrt (die Karte unterstuetzt keine vollstaendige Authentifizierung), bietet begrenzten Schutz im Vergleich zu einem vollstaendig authentifizierten Ergebnis. Die Haftungsverschiebung gilt am staerksten fuer Transaktionen mit einem erfolgreichen Authentifizierungsergebnis und einem ECI-Wert von 05 (Visa) oder 02 (Mastercard).

Ausnahmen und Haftung: Bestimmte 3DS2-Ausnahmen (Transaktionen mit niedrigem Betrag unter 30 Euro, Vertrauensberechtigte-Eintraege, wiederkehrende Transaktionen) ermoeglichen es, Transaktionen ohne SCA fortzufuehren. Die Haftungssituation fuer auf Ausnahmen basierende Transaktionen variiert je nach Ausnahmetyp. Bei Transaktionen mit niedriger Ausnahme, bei denen der Aussteller die Ausnahme anwendet, verbleibt die Haftung beim Haendler. Transaktionen, bei denen der Haendler eine Ausnahme beantragt, die der Aussteller anschliessend genehmigt, koennen dazu fuehren, dass die Haftung beim Haendler verbleibt.

Wann 3D Secure erforderlich ist und wann es optional ist

Gemaess dem SCA-Mandat der PSD2 ist 3D Secure fuer die meisten europaeischen Kartentransaktionen ohne physische Kartenpraesenz erforderlich, aber eine Reihe von Ausnahmen und nicht im Anwendungsbereich liegenden Szenarien definieren, wann SCA nicht gilt.

Wann 3DS erforderlich ist (SCA gilt):
Alle standardmaessigen kartenzahlungen ohne physische Praesenz, die vom Kunden initiiert werden (kundeninitierte Transaktionen oder CITs) fuer Betraege ueber der Niedrigschwelle, unterliegen SCA. Die Standardposition ist, dass SCA erforderlich ist; Ausnahmen sind die Abweichungen.

Ausnahmen, die Transaktionen ohne 3DS ermoeglichen:
Transaktionen mit niedrigem Betrag: Transaktionen unter 30 Euro koennen sich fuer eine Ausnahme bei niedrigem Betrag qualifizieren. Aussteller verfolgen jedoch kumulative Betraege und Transaktionsanzahlen; sobald fuenf aufeinanderfolgende Ausnahmen mit niedrigem Betrag angewendet wurden oder der kumulative Betrag 100 Euro ueberschreitet, ist fuer die naechste Transaktion SCA erforderlich.
Transaktionsrisikoanalyse (TRA): Aussteller und Acquirer koennen TRA-Ausnahmen auf Transaktionen anwenden, die sie auf der Grundlage von Betrugsratenbenchmarks als risikoarm einschaetzen. Um eine TRA-Ausnahme auf Acquirer-Ebene anzuwenden, muss der Acquirer bestimmte, von PSD2 definierte Betrugsratenschwellen erfuellen.
Wiederkehrende Transaktionen: Die anfaengliche Zahlung in einer wiederkehrenden Serie erfordert SCA. Nachfolgende vom Haendler initiierte Transaktionen (MITs) in demselben wiederkehrenden Mandat koennen ohne SCA fortfahren, vorausgesetzt, die anfaengliche Transaktion wurde authentifiziert und die nachfolgenden Transaktionen folgen dem Rahmen fuer gespeicherte Anmeldeinformationen.
Vertrauensberechtigte: Karteninhaber koennen Haendler bei ihrem Aussteller auf eine Whitelist setzen und eine Vertrauensberechtigte-Ausnahme fuer zukuenftige Transaktionen mit diesem Haendler anwenden.

Nicht im Anwendungsbereich von SCA: Vom Haendler ohne Kundeninteraktion initiierte Transaktionen (MIT), Transaktionen, bei denen eine Partei ausserhalb des EWR ist (One-Leg-Out-Transaktionen), und Firmenkartentransaktionen sind in bestimmten Umstaenden nicht im Anwendungsbereich der PSD2-SCA.

3DS2 mit RoxPay implementieren

Das Payment-Gateway von RoxPay unterstuetzt 3DS2 nativ. Die Implementierung wird innerhalb der bestehenden Integrationsarchitektur abgewickelt, ohne dass ein separater 3DS-Anbieter oder ein zusaetzlicher Vertrag erforderlich ist.

Drop-in-UI-Ansatz: Wenn Sie das Drop-in-UI von RoxPay (JavaScript-basierte Karteneingabe) verwenden, wird 3DS2 automatisch behandelt. Wenn der Aussteller eine Authentifizierung erfordert, verwaltet die Bibliothek die Weiterleitung zur Authentifizierungsumgebung des Ausstellers, behandelt die Antwort und setzt den Zahlungsablauf fort, ohne zusaetzlichen Code auf Haendlerseite. Dies ist der einfachste Weg zur 3DS2-Compliance.

API-Integrationsansatz: Fuer Haendler, die eine direkte API-Integration verwenden, werden 3DS2-Authentifizierungsdaten ueber die Payment-Intent-Parameter uebergeben. Die API gibt das Authentifizierungsergebnis und die erforderliche Aktion zurueck, die das Frontend des Haendlers gemaess dem standardmaessigen 3DS2-Challenge-Ablauf behandeln soll. Die vollstaendige Dokumentation ist unter app.roxpay.eu/api/v4/docs verfuegbar.

Optimierung der reibungslosen Rate: RoxPay uebertraegt die maximal verfuegbaren Daten in der 3DS2-Authentifizierungsanfrage, um hohe reibungslose Raten zu unterstuetzen. Reibungslose Authentifizierung bedeutet, dass der Kunde nie aufgefordert wird, etwas zu bestaetigen; der Aussteller genehmigt die Transaktion im Hintergrund. Je hoeher die reibungslose Rate, desto besser der Konversionseffekt von 3DS2.

Testen in der Sandbox: Die RoxPay-Sandbox bietet Testszenarien fuer jedes 3DS2-Ergebnis: reibungslose Authentifizierung, Challenge-Authentifizierung, Authentifizierungsfehler und nicht eingeschriebene Karte. Testen Sie alle Szenarien vor dem Go-Live, um sicherzustellen, dass Ihr Checkout jeden Ausgang korrekt behandelt.

Um Ihre RoxPay-Bewerbung zu starten und mit dem Testen von 3DS2 in der Sandbox zu beginnen, dauert die Registrierung unter zehn Minuten und Sandbox-Zugangsdaten werden sofort ausgestellt. RoxPay ist PCI-DSS-Level-1-zertifiziert (QS83A47X629) und ISO-27001-zertifiziert.

Häufig gestellte Fragen

Reduziert 3D Secure die Konversionsraten?

3DS2 hat bei ordnungsgemaesser Implementierung im Vergleich zu 3DS1 minimale Auswirkungen auf die Konversion. Der reibungslose Authentifizierungsablauf, bei dem der Aussteller die Transaktion im Hintergrund ohne Kundenaktion authentifiziert, macht 80-90 Prozent der authentifizierten Transaktionen fuer gut konfigurierte Haendler aus. Die verbleibenden Transaktionen, die eine Challenge erfordern (typischerweise Push-Benachrichtigung der Banking-App oder OTP), verzeichnen einige Abbrueche, aber dies ist erheblich geringer als der Abbruch, der mit dem Weiterleitungs- und statischen Passwortmodell von 3DS1 erlebt wurde.

Was ist der ECI-Wert bei der 3DS-Authentifizierung?

Der Electronic Commerce Indicator (ECI)-Wert in einer 3DS-Authentifizierungsantwort gibt das erreichte Authentifizierungsniveau an. ECI 05 (Visa) oder 02 (Mastercard) bedeutet, dass eine vollstaendige Authentifizierung abgeschlossen wurde und bietet eine vollstaendige Haftungsverschiebung. ECI 06 oder 01 bedeutet, dass die Karte eine Authentifizierung versucht hat, der Aussteller diese jedoch nicht unterstuetzt hat, was eine begrenzte Haftungsverschiebung bietet. ECI 07 bedeutet, dass keine Authentifizierung durchgefuehrt wurde; keine Haftungsverschiebung gilt.

Was passiert, wenn ein Kunde die 3D-Secure-Authentifizierung nicht besteht?

Wenn der Kunde die 3DS2-Challenge nicht abschliesst (die Push-Benachrichtigung der Banking-App abbricht, das falsche OTP eingibt oder die Sitzung ablaufen laesst), schlaegt die Authentifizierung fehl und die Zahlung wird nicht verarbeitet. Ihr Gateway sollte eine klare Fehlermeldung anzeigen und dem Kunden ermoeglichen, es erneut zu versuchen oder eine andere Zahlungsmethode zu verwenden. Fehlgeschlagene Authentifizierung ist kein Chargeback; die Transaktion wird einfach nicht autorisiert.

Mehr erfahren

Optimieren Sie Ihre Zahlungen heute

RoxPay unterstuetzt natives 3DS2 mit Optimierung der reibungslosen Rate, Haftungsverschiebung fuer authentifizierte Transaktionen und vollstaendigem Sandbox-Testing. PCI-DSS-Level-1-zertifiziert, IC++-Preise ab 0,45 Prozent.

Kostenlos starten → Mit einem Experten sprechen

✓ Keine monatlichen Fixkosten · ✓ Aktivierung in 24 Stunden · ✓ Dedizierter technischer Support