Aktuelle Informationen für Computop-Kunden zur Integration von 3D Secure 2

Händler, die Online-Kreditkartenzahlungen anbieten, müssen spätestens bis zum 16.10.2020 das 3D Secure 2-Protokoll unterstützen. Auf der folgenden Seite finden Sie alle relevanten Informationen zur fristgerechten und ordnungsgemäßen Umstellung.

+++ Letztes Update: 25.03.2020 +++

Was Sie als Händler beachten müssen

Bis wann muss die Umstellung erfolgt sein?

Ihr Acquirer ist seitens der Kartengesellschaften dazu angehalten, zum Stichtag 16.10.2020 sicherzustellen, dass Sie als Händler technisch in der Lage sind, Kreditkartenzahlungen über das 3D Secure 2-Protokoll (Version 2.2 oder höher) zu übergeben.

Für Sie bedeutet dies, dass Sie zum 16.10.2020 folgende Prozesse abgeschlossen haben müssen:

  • Anpassung der erforderlichen Transaktionsparameter zur Übermittlung an das Computop Paygate.

  • Erfolgreiches Testen der Datenübermittlung an unsere Schnittstelle.

  • Erfolgreiche Übermittlung von Testtransaktionen an Ihren Acquirer.

Nicht handeln ist keine Option!

Die Einführung des 3D Secure 2-Protokolls innerhalb des europäischen Wirtschaftsraumes ist eine verbindliche Vorgabe der Kreditkartengesellschaften.

Als Payment Service Provider haben wir keinen Einfluss auf geltende Fristen und das gesamte Prozedere des Rollouts. Fest steht, dass in naher Zukunft Kreditkartentransaktionen, die nicht über 3D Secure 2 abgewickelt werden, zur Weiterverarbeitung durch Ihren Acquirer und die Kartengesellschaften abgelehnt werden.

Aus diesem Grund möchten wir Sie in Ihrem eigenen Interesse dazu anhalten, bis Herbst 2020 alle erforderlichen Schritte vorzunehmen. Andernfalls können Sie Kunden aus dem europäischen Wirtschaftsraum ab 2021 keine Kreditkartenzahlungen in Ihrem Onlineshop anbieten.

Die Schritte zur Integration von 3D Secure 2 im Detail:

1. Anpassung der notwendigen Transaktionsparameter

Bitte passen Sie Umfang und Übergabe der Transaktionsdaten gemäß unserer Onlinedokumentation an. Beachten Sie dabei unsere Empfehlungen für die Auswahl der zusätzlichen Datenfelder, deren Übertragung dem Issuer eine optimale Transaktions-Risikoanalyse ermöglicht und somit Ihre Conversions optimiert.

2. Test-MID einrichten

Um die korrekte Datenübertragung an das Computop Paygate zu testen, müssen Sie eine Test-MID einrichten. Falls Sie eine eigene Test-MID bekommen haben (Sie erkennen sie daran, dass im Namen „Test“ enthalten ist), nutzen Sie diese, um Testtransaktionen zu übertragen.

Andernfalls finden Sie in Ihrem Computop Analytics-Account die allgemein gültige Computop Test-MID für 3D Secure 2. Optional können Sie auch bei unseren Merchant Services eine neue, individuelle Test-MID beantragen.

3. Senden einer Test-Transaktion an das Computop Paygate

Senden Sie unter Verwendung der Test-MID nun eine Transaktion an das Computop Paygate. Wenn Ihre Anpassungen an das 3DS-Protokoll korrekt sind, erhalten Sie auf Ihre Testtransaktion eine Erfolgsbestätigung.

4. Durchführung des Acquirer-Tests

Mit der Erfolgsbestätigung wenden Sie sich bitte an [email protected]. Unser Team wird sich umgehend mit Ihnen in Verbindung setzen, um die weitere Übertragung Ihrer Zahlungen an Ihre/n Acquirer zu testen.

Sollten Sie auf Ihre Testtransaktion eine Fehlermeldung erhalten, überprüfen Sie bitte noch einmal Ihre Anpassung auf Basis unserer Online-Dokumentation. Bei Problemen hilft unser Team Merchant Services gern.

 

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. Bitte prüfen Sie zudem, ob Ihr derzeitiger Vertrag mit Computop eine Bereitstellung des 3D Secure Protokolls beinhaltet. 

3D Secure 2 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 weitere Informationen speichern oder nicht.

Innerhalb einer Übergangszeit, die vermutlich bis zum 31.12.2020 andauert, wird es für Sie notwendig sein, 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.

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-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 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 TANs 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 nicht überschritten wurden oder mehr als fünf Zahlungen in Reihe ohne Anwendung der SCA erfolgt sind. 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.

3D Secure 2 beinhaltet eine Reihe von Verbesserungen gegenüber 3D Secure 1, 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 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 als niedrig einstuft, wird die Transaktion bewilligt. Sollte ein erhöhtes Betrugsrisiko bestehen, muss sich der Käufer über die pushTAN-App seiner kartenausgebenden Bank authentisieren.
 

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.

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 3D Secure-Verfahren 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-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-Verfahren sinnvoll einsetzen zu 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.

Bis zum 16.10.2020 müssen Sie zunächst Ihrem Acquirer nachweisen, dass Zahlungen in Ihrem Onlineshop per 3DS 2.2-Protokoll abgewickelt werden können. Voraussichtlich ab Anfang 2021 werden anschließend alle Online-Kreditkartentransaktionen von Acquirern abgelehnt, die nicht über 3DS 2.2 oder eine höhere Version eingereicht wurden.

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.

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 steht Ihnen Merchant Services gerne zur Seite.

Nutzen Sie für eine erste Kontaktaufnahme das nebenstehende Formular oder rufen Sie uns einfach an: +49 (0)951 98009-39

(* Pflichtfelder)

Diese Webseite nutzt Cookies

Zur Verbesserung Ihrer Nutzererfahrung setzen wir sowohl technisch notwendige als auch Google Analytics Cookies. Alle Details zu den gesetzten Cookies finden Sie in unserer Datenschutzerklärung.

Wenn Sie möchten, können Sie dem Setzten von Cookies auch widersprechen. In diesem Fall werden keine Cookies angelegt, trotzdem können Sie unsere Webseite nahezu uneingeschränkt nutzen.