3D Secure und 3D Secure 2.0 im Überblick

Wie funktioniert 3D Secure bisher?


Das seit dem Jahr 2002 bestehende, weltweit standardisierte 3D Secure-Protokoll (3DS) bietet Händlern und Verbrauchern zusätzliche Sicherheit bei Kreditkartentransaktionen. Mit dem Verfahren verifizieren sich Onlinekäufer gegenüber ihrer kartenausgebenden Bank (Issuer) als rechtmäßiger Karteninhaber. Im Gegensatz zu einem herkömmlichen Bezahlvorgang per Kreditkarte im Internet verlangt 3D Secure einen zusätzlichen Sicherheits-Code. Auf diese Weise wird die missbräuchliche Verwendung von Kreditkarten deutlich erschwert.

Wie unterscheidet sich 3D Secure 2.0 vom bisherigen Verfahren?

Im Wesentlichen stellt 3D Secure 2.0 eine Weiterentwicklung des bisherigen 3D Secure-Protokolls dar. Mit jeder Bestellung per Kreditkarte werden fortan bis zu 100 Datenpunkte an den Issuer übermittelt; basierend auf diesen Datenpunkten führt der Issuer eine Echtzeit-Risikobewertung durch. Wird eine Transaktion hierbei als risikoarm eingestuft, kann sie direkt und ohne weitere Interaktion des Käufers autorisiert werden. Besteht jedoch Betrugsverdacht, wird der Käufer durch eine zusätzliche Sicherheitsabfrage (z. B. mittels Push-TAN) zur erneuten Bestätigung seiner Identität aufgefordert. Die Risikobewertung läuft für den Käufer nicht wahrnehmbar im Hintergrund ab. Die Erfassung und Weiterleitung der nötigen Daten erfolgt sowohl über das Shop-Backend des Händlers als auch durch den Payment Service Provider (PSP), über den 3D Secure 2.0 an den jeweiligen Shop angebunden ist.

Wann und weshalb wird 3D Secure 2.0 eingeführt?


Erklärtes Ziel der Einführung von 3D Secure 2.0 ist es einerseits, den Anforderungen an die Strong Customer Authentication (SCA) gerecht zu werden und sie ab dem 14. September 2019 für elektronische Zahlungsverfahren als Standard zu etablieren. Andererseits soll durch die Einführung auch die Kaufabbruchquote sinken: Durch die individuelle, datenbasierte Risikobewertung können Transaktionen in ca. 95 Prozent aller Fälle direkt und ohne weitere Käuferinteraktion freigegeben werden - ein Großteil der Käufe findet somit künftig ohne Eingabe eines 3D Secure Codes statt.

3D Secure 2.0 mit Computop. Jetzt live testen!

Hier gehts zur Test-Doku und dem Merchant Use Cases

WEITER

Wichtige Downloads

Videos

Monika Moser-Bärlehner (Computop):

Neues zu PSD II / 3D Secure

Sten Werner (Computop):

Improving usability for the 3D Secure 2.0 process - delegation of SCA

Häufig gestellte Fragen (FAQ) für Techniker und Integratoren

Ja. Egal welche Integrationsart (Formular, Server-to-Server, Hosted Payment Page) und ob Sie 3D Secure bereits genutzt haben oder nicht, Sie müssen Anpassungen vornehmen. Bei Verwendung der Computop-Formulare sowie der Paynow-Variante ist der Anpassungsaufwand am geringsten.

Diesbezüglich empfehlen wir Ihnen, sich direkt mit Ihrem Acquirer in Verbindung zu setzen.

 

3D Secure 2.0 kann auch bei Transaktionen mit geringem Wert eine Authentifizierung auslösen. Die Kartenausgebenden Banken speichern die Summe aller Zahlungen eines Kunden und können beim Überschreiten von Schwellenwerten eine Authentifizierung auslösen.

Der Aufwand ist vergleichsweise gering, da lediglich beim Aufruf des Computop-Kartenformulars mehr Daten gesendet werden müssen. Der Ablauf aus Händlersicht ändert sich nicht. In der Antwort des Paygate kommen dementsprechend mehr Werte zurück. Diese dienen jedoch nur der Information des Händlers und werden für nachfolgende Zahlungsvorgänge nicht benötigt. Daher steht es Ihnen als Händler frei, ob Sie die Ergebnisse der Authentifizierung und weiteren Information speichern oder nicht.

Vermutlich werden nicht alle Banken bis 14.09.2019 auf die Version 2.0 migrieren, sodass es für Sie notwendig sein wird, beide Versionen zu unterstützen. Durch die Verwendung der Computop-Formulare sind Sie automatisch für beide Varianten gewappnet.

VISA, MasterCard, American Express, Diners/Discover, JCB sowie China Union Pay (CUP).

Nein, für Sie als Händler gibt es keinen Unterschied.

In der nachgelagerten Kommunikation zwischen Computop und dem Directory Server der Kartenmarken gibt es Unterschiede, die jedoch von uns für Sie konsolidiert werden.

Ausschließlich der Karteninhaber selbst kann bei seiner Hausbank ausgewählte Händler "whitelisten". Dies reduziert deutlich die Wahrscheinlichkeit, dass der Kunde einer 3D Secure-Authentifizierung ausgesetzt wird. Dennoch kann es dazu kommen, wenn Schwellenwerte bei der Bank überschritten werden (z.B. durch einen sehr hohen Warenkorbwert).

Nein. Der bisherige Parameter "RTF" wird weiterhin bestehen bleiben. Für künftige Implementationen hat Computop den Parameter "credentialOnFile" als strukturiertes JSON-Objekt eingeführt, um die Logik besser abbilden zu können. Beides wird jedoch simultan unterstützt.

Es handelt sich hierbei um eine Customer Initiated Transaction und muss dementsprechend gekennzeichnet werden.

Nein. Dies hat keine Auswirkung auf 3D Secure.

Nein. Die Haftung liegt weiter bei der kartenausgebenden Bank.

Ja. Die Haftungsverschiebung bleibt weiterhin bestehen.

Aufgrund der neuen Anforderungen von 3D Secure erhöht sich die Anzahl der Zeichen im Zahlungsstring. Deshalb empfehlen wir dringend die Verwendung der POST-Methode, um Fehlern im Zahlungsaufruf vorzubeugen. Hintergrund ist eine mögliche Browserbeschränkung von 2048-Bytes für den GET-Aufruf.

Die AccVerify-Funktion kann ohne Einschränkung weiterhin verwendet werden. Die neuen 3D Secure 2.0-Parameter werden dennoch benötigt.

Bisher haben wir lediglich Acquirer Exemptions und Whitelisting über private Erweiterungen für MasterCard implementiert.

Die Whitelist wird nach alleinigem Ermessen des Issuers und Karteninhabers geführt. Vom Issuer erhält das Computop Paygate Whitelist-Informationen über seinen 3DS-Server, mit dem es am 3DS-Authentifizierungsfluss teilnimmt.

Häufig gestellte Fragen (FAQ) für E-Commerce Manager und Entscheider

Die Payment Services Directive 2 (Zahlungsdiensterichtlinie 2) wurde im Oktober 2015 verabschiedet und ist eine Regelung zur Regulierung von Zahlungsdiensten und -dienstleistern, die von der Europäischen Kommission als EU-Richtlinie verabschiedet wurde. Sie ist eine Weiterentwicklung der ersten PSD und gilt dementsprechend in der gesamten Europäischen Union sowie dem Europäischen Wirtschaftsraum. Sie soll mehr Sicherheit und höhere Transparenz im Zahlungsverkehr schaffen sowie für niedrigere Einstiegshürden für Zahlungsdienste und einen fairen Wettbewerb sorgen.

Die Regulierung betrifft im Wesentlichen zwei Bereiche: die Zahlungsbranche und den Verbraucher. Für die Zahlungsbranche schafft sie klare Regeln, die dafür sorgen sollen, den Wettbewerb innerhalb der EU zu stärken, indem sie die Position von Zahlungsdienstleistern verbessert. Sie beendet das Monopol der Banken auf Kontoinformationen und erlaubt es Drittanbietern, sogenannte Third Party Provider (TPP), Kunden Zugriff auf deren eigene Kontoinformationen zu geben. Darüber hinaus schafft sie die Voraussetzungen, die es TPP erlauben, Bezahlvorgänge direkt auszulösen, ohne dass eine Bank direkt in den Vorgang involviert ist.

Zwei neue TPP sind in der PSD2 reguliert: der Payment Initiation Service Provider (PISP), auch Zahlungsauslösedienst genannt, und der Account Information Service Provider (AISP), auch Kontoinformationsdienst genannt. Um diesen Anbietern ihre Arbeit zu ermöglichen, müssen Banken ihre APIs (Application Programming Interfaces) denjenigen öffnen, die sie für diese regulierten Dienstleistungen anfragen und die gemäß der Vorgaben reguliert sind.

Für Verbraucher und Händler soll sich zudem die Sicherheit bei Transaktionen erhöhen, indem sie eine starke Authentifizierung (Strong Customer Authentication/SCA), auch Zwei-Faktor-Authentifizierung (2FA) bei E-Commerce-Transaktionen verlangt. Daraus ergeben sich strengere Regelungen für Kartenzahlungen und für die Betrugsprävention.

Alle Zahlverfahren für elektronische Fernzahlungen.

Die Erfordernis nach SCA (Strong Customer Authentication)/Zwei-Faktor-Authentifizierung (2FA) ist Bestandteil der Zahlungsrichtlinie PSD2. SCA wird immer dann gefordert, wenn ein Nutzer eine elektronische Zahlung auslösen möchte und verlangt für die Authentifizierung mindestens zwei der drei Faktoren Wissen, Inhärenz und Besitz. SCA findet bei E-Commerce-Zahlungen Anwendung, die von Kundenseite angestoßen wurden. Eine SCA fragt also mindestens zwei der Faktoren ab. Kann sie der Nutzer korrekt vorlegen, wird die Zahlung genehmigt.

Der Faktor Wissen wird mit einem Passwort oder einer PIN abgedeckt, die nur der Konto- oder Karteninhaber kennt.

Der Faktor Besitz kann das Smartphone des Users sein. Das Eigentum muss der Nutzer dann über eine Verifizierungsnachricht innerhalb einer App auf dem Smartphone beweisen. In der Praxis findet diese Herangehensweise beispielweise in Banken-Apps statt. Hierbei fragt die Bank eine TAN ab, die direkt in der Banking-App erzeugt und angezeigt wird. Es handelt sich hierbei zwar um ein sogenanntes Einmalpasswort/One Time Password (OTP), doch bei diesem Vorgang ist das mobile Endgerät, auf das es geschickt wird, der entscheidende Faktor: Besitz.

Nach PSD2 sind SMS-TANs übrigens sind nicht mehr zulässig. PSD2 schreibt vor, dass die Banken die Kontrolle über die Kanäle wahren müssen. Bei über SMS verschickten TANs ist diese Voraussetzung nicht gewährleistet. In TAN-Apps generierte TANs hingegen erfüllen die Standards.

Der Faktor Inhärenz wird durch biometrische Daten abgedeckt. Dabei authentifiziert sich der User beispielsweise auf seinem Smartphone über einen Fingerabdruck-, Gesichts- oder Iris-Scan.

Die SCA ist verpflichtend für die Auslösung elektronischer Zahlungen und für den Zugang zu Anwendungen, die elektronische Zahlungen auslösen und/oder Zugang zu Kontoinformationen ermöglichen. Eine Unterscheidung nach Handelsform oder Vertriebsweg ist nicht vorgesehen. Inwiefern eine Zahlart der SCA unterliegt, hängt davon ab, ob eine Kartenzahlung involviert ist bzw. ob der Verbraucher die Möglichkeit hat, die Zahlung nach Warenerhalt auszuführen oder zu widerrufen.

B2B-Zahlungen unterliegen der SCA genauso wie B2C-Zahlungen, mit einer Ausnahme: wenn die Zahlungen in einem typischerweise nur von Unternehmen benutzten Prozess ausgeführt werden, der nicht auf die Authentifizierung einer Einzelperson setzt und eine Behörde die Vergleichbarkeit der Sicherheit mit den Maßstäben der PSD2 bestätigt hat.

Verantwortlich für die Umsetzungen sind die Zahlungsdienstleister, die die Zahlungsauslösung ausführen bzw. den Zahlungspflichtigen authentifizieren. In der Regel die Anbieter der Zahlarten, also die Acquirer oder alternativen Zahlarten. Sie sind verpflichtet, den Prozess der SCA bereitzustellen.

Händler sind nur verantwortlich, wenn sie selbst die Zahlungsauslösung vornehmen, zum Beispiel über eine Schnittstelle zu den Banken. Dann müssen sie sicherstellen, dass die Maßnahmen der Bank zur SCA in den Prozess eingebunden sind. 

Nein. Grundsätzlich ist festzuhalten, dass für die SCA immer die Zahlungsart zuständig ist. Der PSP übernimmt die SCA nicht. Lediglich bei der Lastschrift könnten der Händler oder der Zahlungsdienstleister eine SCA durchführen, allerdings ist sie derzeit für Lastschriften nicht erforderlich. Ein weiterer Sonderfall sind Instant Payments. Hierbei wären der PSP oder der Händler Zahlungsauslöser und müssten die Authentifizierungsverfahren der über eine Schnittstelle angebundenen Kundenbank ausführen sowie als Zahlungsauslösedienst reguliert sein.

Festzuhalten ist, dass der Händler keine Entscheidungsfreiheit hinsichtlich der SCA hat. Sie ist zwingende Voraussetzung im elektronischen Zahlungsverkehr. Der Händler bindet den SCA-Prozess lediglich ein. Die Abfrage findet technisch gesehen nie auf der Webseite des Händlers statt, sondern wird dort nur über ein iframe eingebunden.

Die Speicherung der Authentifizierungsdaten hängt vom verwendeten Verfahren ab. Bei der Verwendung von In-App-TAN erfolgt keine Speicherung, da die TAN für jede Zusendung neu erzeugt werden. Die biometrischen Daten werden nur im Gerät des Besitzers in einem geschützten Bereich gespeichert. Es erfolgt keine Übertragung von biometrischen Daten, zur Authentifizierung wird lediglich ein nicht rückentschlüsselbarer Hashwert abgeglichen. PIN und Passwörter werden wie bisher auf geschützten Servern der Zahlungsdiensteanbieter gespeichert. Sensible Daten wie Kartennummern dürfen nur PCI-zertifizierte Unternehmen speichern, viele Händler vertrauen dabei auf Payment Service Provider wie Computop. Der Handel kann dabei ganz auf die Speicherung der Originalnummern verzichten und speichert nur Pseudokartennummern, die im Fall des Datenverlustes keine Zahlung ermöglichen. Weitere Transaktionsdaten sind ebenfalls bei PSPs gespeichert sowie bei den Banken.

Das hängt vom gewählten Zahlarten-Anbieter ab. Apple Pay beispielsweise authentifiziert Online-Einkäufe über ein verbundenes iPhone mit biometrischer Erkennung. Online-Überweisungsverfahren verwenden häufig eine TAN aus einer geschützten App auf dem Smartphone. Erfolgt der Online-Einkauf auf einem Mobilgerät eines nachgewiesenen Besitzers, sind auch weiterhin als zweiter Faktor eine PIN oder ein Passwort möglich.

Das Dynamic Linking erfolgt bei der kontoführenden Bank des Kunden und wird im Zuge der Authentifizierung an den Kunden übertragen.

Vertrauenswürdige Zahlungsempfänger, sogenannte Trusted Beneficiaries können vom User innerhalb seines Online-Banking-Portals gekennzeichnet werden, sofern die Bank diesen Service anbietet. Dazu legt er eine Liste mit vertrauenswürdigen Empfängern an, die sogenannte Whitelist. Dieser Vorgang, das Whitelisting, sorgt dafür, dass Transaktionen an die gelisteten Empfänger nicht stark authentifiziert werden. Eine SCA findet lediglich einmalig statt, um die angelegte Whitelist oder den jeweiligen Trusted Beneficiary zu bestätigen. Alle folgenden Transaktionen an den Empfänger werden ohne SCA realisiert, sofern die Transaktionen keine allgemeinen Auffälligkeiten aufweisen.

Von der SCA befreit sind bei Fernzahlungen Kleinbeträge bis zu 30 Euro, solange seit der letzten SCA Transaktionen von insgesamt 100 Euro Volumen oder mehr als fünf Zahlungen ohne Anwendung der SCA nicht überschritten wurden. Allgemeine Voraussetzung auch für diese Ausnahme ist, dass die Transaktion keine offensichtlichen Risikomerkmale aufweist, wie z.B. eine gesperrte Kartennummer.

Bei wiederkehrenden Zahlungen erfolgt die Zahlungsauslösung durch den Händler, es handelt sich um sog. MIT (Merchant Initiated Transactions). Diese sind laut EBA (European Banking Authority) von der SCA befreit, wenn die ursprüngliche Autorisierung des Abonnements gemäß SCA authentifiziert wurde.

Diese Regelung zu wiederkehrenden Zahlungen schließt auch Abweichungen bei den Zahlungsbeträgen oder -zeitpunkten ein, sofern diese in einem vom Kunden erwartbaren Bereich liegen. Nicht abgedeckt ist die Zahlungsauslösung mit Card on File (COF), bei der der Händler dem Kunden eine vorhandene Kartennummer vorblendet, die der Kunde nur bestätigt, denn hier ist der Kunde der letztliche Zahlungsauslöser.

Vereinbarungen zu wiederkehrenden Zahlungen, die bereits vor Wirksamwerden der PSD2 getroffen wurden, gelten weiter und erfordern keine nachträgliche Starke Authentifizierung.

Nach §§ 18,19 der RTS kann der Issuer auf SCA verzichten, wenn

  1. die Betrugsrate für die entsprechende Art von Zahlungen (Karten bzw. Überweisungen) über die Gesamtheit des Zahlungsdienstleisters gerechnet bestimmte Werte nicht überschreitet (Tabelle),
  2. die Zahlungen nicht über die zugehörigen Schwellenwerte hinausgehen und
  3. keine ungewöhnlichen Szenarien wie z.B. abweichendes Zahlungsverhalten oder Ort mit hohem Risiko festgestellt werden.

MOTO-Transaktionen werden in der PSD2 nicht als elektronische Transaktionen betrachtet und fallen daher nicht unter die Verpflichtungen zur SCA. 

Die PSD2 erfordert in vielen Fällen eine SCA/2FA. 3D Secure (3DS) erfüllt die Anforderungen an SCA. Kreditkartenfirmen wie VISA, Mastercard, American Express und JCB nutzen die Technologie, um Missbrauch von Kreditkartendaten zu verhindern. Für den Händler reduzieren sich das Betrugsrisiko und mögliche Zahlungsausfälle. Wer als Händler 3D Secure einsetzt, erhält einen garantierten Zahlungseingang, denn wird die Transaktion trotz 3DS-Abfrage genehmigt und erweist sich dennoch als Betrug, haftet die herausgebende Bank der Kreditkarte (Issuerbank) für den Schaden.

3DS 2.0 beinhaltet eine Reihe von Verbesserungen gegenüber 3D Secure 1.0, die den Einkaufsprozess für Kunden und Händler einfacher gestalten. Wie auch schon bei dem Vorgänger identifizieren sich Onlinekäufer gegenüber ihrer Issuerbank per 3D Secure als rechtmäßige Karteninhaber. In der Version 2.0 wird die bisher statische Abfrage eines Sicherheitscodes durch eine in Echtzeit ablaufende Risikoanalyse ersetzt. Bei jeder Bestellung per Kreditkarte werden bis zu 100 Datenpunkte und damit bis zu 10mal mehr Informationen an die Issuerbank übermittelt. Die Erfassung und Weiterleitung der Daten erfolgt über das Shop-Backend des Händlers und durch den PSP. Die Übergabe der Daten findet in der gesicherten Umgebung des 3D Secure Servers statt. Wenn die anschließende Echtzeit-Risikobewertung durch den Issuer das Risiko niedrig einstuft, wird die Transaktion bewilligt. Sollte ein erhöhtes Betrugsrisiko bestehen, muss der Käufer per SMS oder Mail seine Identität bestätigen. Anders als bei der TAN geschieht dies mit einem bereits bestehenden Passwort, das der Nutzer einmalig bei der Anmeldung für 3D Secure festlegt. Bevor das Passwort nicht festgelegt wurde, ist eine 3D-Secure-Abfrage nicht möglich.

Hinsichtlich der Fristen zu 3D Secure 2.0 ist zu beachten: Weder von Seiten des verantwortlichen Branchenverbands EMVCo noch seitens der Kreditkartengesellschaften wurde eine verbindliche Frist zur Integration des neuen Standards in Onlineshops gesetzt. Fakt ist: 3DS 2.0 selbst stellt keine gesetzlich vorgeschriebene Norm dar. Maßgeblich für den Händler ist die Frage, ob im eigenen Onlineshop bis zum 14. September 2019 ein Verfahren zur Abwicklung von Kreditkartentransaktionen bereitgestellt werden kann, welches den Maßgaben der SCA genügt. Als Minimallösung ist hierbei auch 3D Secure 1.0 zulässig.

Für Amazons Echo sind Zahlungen über Spracherkennung standardmäßig aktiviert. Amazon löst das Problem der Bestätigung aktuell über einen optionalen vierstelligen Code, den der Nutzer entweder vor jedem Einkauf aufsagen muss oder (sofern er seine Stimme von Alexa registrieren lässt) nur einmalig aufsagen muss und danach barrierefrei über seine Stimme einkaufen kann.

Für Google Home ist das Einkaufen über die Stimme bisher nur in den USA freigeschaltet. Um Zahlungen zu ermöglichen, muss der Nutzer sie in der Google-Home-App auf dem Smartphone oder dem Tablet aktivieren, die Zahlmethode festlegen und dann manuell in der App die Google-Home-Geräte auswählen, die berechtigt sind, Käufe zu tätigen.

Google erlaubt dem User zusätzlich eine optionale Bestätigung von Käufen über den Fingerabdruck auf dem Smartphone oder Tablet oder der Eingabe des Passwortes des Google-Kontos auf dem Smartphone oder Tablet.

Ohne 3D Secure wird eine Zahlung generell abgelehnt, die Version 3DS 1.0 reicht jedoch weiterhin als Minimallösung aus. Mittelfristig ist allerdings damit zu rechnen, dass die Einreichung mit 3DS 2.0 verbindlich wird.

Ein Kunde kann sich nicht selbst auf die Liste der vertrauenswürdigen Empfänger setzen, sondern nur Händler, denen er vertraut. Eine Generalbefreiung für alle Händler ist nicht möglich, die Händler müssen einzeln benannt werden. Zudem kann seine Bank im Einzelfall weiterhin das 3DS durchführen, wenn sie Hinweise auf ein erhöhtes Risiko der entsprechenden Transaktion hat. Generell sind die Banken außerdem nicht verpflichtet, eine Whitelist zu führen.

PayPal wird nach der neuen PSD2 Richtlinie in Zukunft nicht mehr über eine reine Passwortanmeldung (TAN) funktionieren. Die Umstellung auf die Zwei-Faktor-Authentifizierung, die PayPal bereits jetzt als freiwillige Lösung anbietet, wird mit Wirksamwerden der PSD2 verpflichtend werden. Sie obliegt PayPal und nicht dem Händler.

Daten, die vom Payment Service Provider (PSP) des Händlers erfasst, verarbeitet und anschließend an den 3D Secure Server übergeben werden, sind:

  • Kreditkartendaten, welche gemäß den Anforderungen an PCI DSS erhoben und verarbeitet werden müssen.
  • Transaktionsbezogene Daten: Hierzu gehören die zur Zuordnung von Transaktion und Händler benötigten Identifikationsnummern sowie die Kaufbetragshöhe und Währung.
  • Browserinformationen, die Aufschluss über das verwendete Endgerät und den Aufenthaltsort des Users geben. Diese umfassen unter anderem IP-Adresse, Bildschirmhöhe und -breite sowie die verwendete Browsersprache.

Die nachfolgenden Daten werden im Shopsystem des Händlers erfasst und über die Payment-Schnittstelle des PSPs an den 3D Secure Server übergeben:

  • Rechnungs- und Lieferadresse Die vollständige Rechnungs- und Lieferadresse der Bestellung.
  • Kundenkonto Daten, die im Rahmen eines bestehen­den Kundenkontos erfasst wurden. Hierunter fallen u. a. Angaben zur Dauer des Bestehens des Kundenkontos, die Anzahl an durchgeführten Transaktionen innerhalb bestimmter Zeitintervalle und die Häufigkeit der Änderung von Passwörtern und Lieferadressen.
  • Lieferdetails Daten zu Lieferdetails, wie z. B. die gewählte Versandmethode, Verfügbarkeit der Ware, das Lieferzeitfenster, die E-Mail- Adresse im Fall eines Versands digitaler Güter oder das Datum der Erstverfügbarkeit für noch nicht veröffentlichte Produkte.

Nein. Die für die Definition des 3DS 2.0-Standards zuständige Organisation EMVCo (Branchenverband der Kreditkartenwirtschaft) unterscheidet zwischen verpflichtenden und optionalen Datenpunkten und Daten. Zu den letzteren gehören alle Daten, welche innerhalb des Bestellprozesses ausgehend vom Händler-Backend erhoben werden.

Um das neue 3DS 2.0-Verfahren sinnvoll einsetzen können, ist jedoch eine Erfassung und Übergabe aller Parameter dringend zu empfehlen: Je mehr Daten in die Transaktionsanalyse des Issuers einfließen, desto präziser fällt die Beurteilung der Betrugswahrscheinlichkeit einer Transaktion aus.

Maßgeblich für Händler ist die Frage, ob im eigenen Onlineshop bis zum 14. September 2019 ein Verfahren zur Abwicklung von Kreditkartentransaktionen bereitgestellt werden kann, welches den Anforderungen an eine starke Kundenauthentifizierung (Strong Customer Authentication) gerecht wird.

Als „Minimallösung“ steht hierfür das bisherige 3DS 1.0-Verfahren bereit, welches in seiner grundlegenden Funktionsweise den Anforderungen an SCA genügt, jedoch zahlreiche undurchsichtige Ausnahmeregelungen enthält, unter denen eine Abfrage des 3DS-Codes nicht zwingend erfolgen muss. 

Mit einer weiteren Verwendung von 3DS 1.0 laufen Händler daher Gefahr, bei einer fehlerhaften Anwendung der Ausnahmeregelungen gegen die Auflagen zur starken Kundenauthentifizierung zu verstoßen. Das in Abstimmung mit der europäischen Bankenaufsicht (EBA) entwickelte 3DS 2.0-Verfahren ist laut Aussage von EMVCo hingegen in jeder Hinsicht SCA-konform.

Händler, die das bisherige 3DS-Verfahren verwenden, werden um ein „Upgrade“ auf 3DS 2.0 in naher Zukunft nicht herumkommen. Grundsätzlich sollte hier die Devise gelten: Je früher desto besser. Jedoch wird das 3DS 1.0-Verfahren vermutlich auch noch nach September 2019 von den meisten Issuer-Banken auf unbestimmte Zeit als Fallback-Option akzeptiert werden.

Händler, die das 3DS 2.0-Verfahren in Ihren Shop integrieren möchten, müssen

  • mit ihrem Payment Service Provider abklären, ob dieser das 3DS 2.0-Protokoll unterstützt.
  • eine Anpas­sung der im Bestell-und Checkout-Prozess betroffenen Formulare vornehmen, um die erforderlichen Kunden­daten zur Übermittlung bereitzustellen und diese in Abstimmung mit ihrem PSP konfigurieren, um eine reibungslose Übergabe der Daten über die Schnittstelle zu gewährleisten.
  • das 3DS 2.0-Protokoll zusätzlich zum Onlineshop auch in ihre Mobile Shopping Apps integrieren (falls vorhanden).
  • eine Anpassung der allgemeinen AGBs und Datenschutzbestimmungen vornehmen und Ihre Kunden hierüber in Kenntnis setzen.
  • das unterstützte 3D Secure 2.0- Verfahren bei ihrem Acquirer anmelden.

Die gute Nachricht für unsere Kunden: Den Großteil der anstehenden Arbeit können wir Ihnen abnehmen. Wie bei allen unseren Produkten besteht der Anspruch an unsere 3DS 2.0-Lösung darin, den Integrationsaufwand für unsere Kunden so gering wie möglich zu halten.

Die Whitelist wird nach alleinigem Ermessen des Issuers und Karteninhabers geführt. Das Computop Paygate erhält Whitelist-Informationen über seinen 3DS-Server, mit dem es am 3DS-Authentifizierungsfluss teilnimmt.

Die Übergangsfrist ist an bestimmte Voraussetzungen geknüpft. Zunächst liegt es im Ermessen der nationalen Aufsichtsbehörden, betroffenen Akteuren eine Übergangsfrist einzuräumen. Die BaFin hat deutlich gemacht, dass sie das Angebot der EBA annimmt. Allerdings wird keine konkrete Fristverlängerung eingeräumt, sondern lediglich „Flexibilität gewährt“. Voraussetzung dafür ist jedoch das Vorliegen eines expliziten Migrationsplans für die Umstellung auf die Starke Kundenauthentifizierung, der klar definierte Zwischenziele enthält. Händler sollten sich daher weiterhin am Umstellungsdatum 14.9. orientieren, denn eine verspätete Bereitschaft für SCA bedeutet weiterhin einen nicht rechtskonformen Zustand und bringt die Gefahr einer höheren Ablehnungsrate mit sich.

Die EBA hat klargestellt, dass 3DS 1.0 nicht an alle Anforderungen der PSD2 angepasst ist. Diese Aussage bezog sich konkret auf die Möglichkeit für Händler, von bestimmten Ausnahmen Gebrauch zu machen, welche von den PSD2-Anforderungen befreien. Gleichzeitig gilt die Abfrage eines Passworts im E-Commerce aber weiterhin als Element des Faktors Wissen, daher kann unserer Auffassung nach die Verwendung einer Passwortabfrage zur Authentifizierung nach 3DS 1.0 weiterhin unterstützt werden, sofern die Übertragung des Passworts an den Issuer PSD2-konform geschieht. Wir empfehlen, 3DS 1.0 dennoch nur als Fallback-Lösung einzusetzen, da es in jedem Fall zur Challenge, also zur Präsentation der Passwort-Abfrage kommt und durch die fehlenden Ausnahmen zu einer geringeren Konversionsrate im Checkout führen wird. Zudem haben die Kartenmarken bereits durchblicken lassen, dass das 3DS 1.0-Protokoll auf mittlere Sicht vom Markt genommen werden wird.

Glossar

Unternehmenszahlungsverkehr kann von SCA ausgenommen werden, wenn spezielle Voraussetzungen gemäß Artikel 17 (Sichere Unternehmenszahlungsprozesse und -protokolle) erfüllt sind. Eine Freistellung erfordert "spezielle Zahlungsverfahren oder -protokolle, die nur Kostenträgern zur Verfügung gestellt werden, die keine Verbraucher sind".

Der Begriff Merchant Fraud Rate ist in diesem Zusammenhang nicht zu verwechseln mit der Betrugsrate für einen spezifischen Händler. Die Merchant Fraud Rate im Rahmen von EMV 3DS bezieht sich auf die Artikel 18 und 19 der von der Europäischen Bankenaufsicht (EBA) veröffentlichten Regulatory Technical Standards (RTS) for Strong Customer Authentication (SCA).

Artikel 18 (Transaktionsrisikoanalyse) beschreibt die Bedingungen, die erfüllt sein müssen, um eine Befreiung von SCA aufgrund des geringen Risikos, das mit einer Transaktion verbunden ist, anzuwenden. Eine dieser Bedingungen ist der jeweilige Freistellungsschwellenwert (ETV) und die referenzierte Betrugsrate, wie in Artikel 19 (Berechnung der Betrugsraten) beschrieben. Der Erwerber (PSP in EBA-Terminologie) kann sich bei seinen lokalen Behörden für Ausnahmen von SCA registrieren lassen, da die niedrigen Betrugsraten für sein gesamtes E-Commerce-Handelsportfolio berechnet werden.

MasterCard hat einen Workaround über private Daten im Datenfeld der Nachrichtenerweiterung der Authentifizierungsnachricht eingerichtet, um dem Issuer die Betrugsraten des Acquirers mitzuteilen, wenn er eine Freistellung gemäß Artikel 18 beantragt.

 

Befindet sich einer der Teilnehmer, entweder der Zahlungsdienstleister des Zahlers (d.h. Issuer) oder der Zahlungsdienstleister des Zahlungsempfängers (d.h. der Acquirer) außerhalb des EWR (Europäischer Wirtschaftsraum), fällt die Transaktion nicht in den Anwendungsbereich der PSD 2 und somit findet SCA keine Anwendung. Die EBA stellt fest, dass "die europäischen PSPs in solchen Situationen alle angemessenen Anstrengungen unternehmen müssen, um die rechtmäßige Nutzung des Zahlungsinstruments festzulegen".

Bei Fragen, bitte kontaktieren Sie unseren Support.