EMV 3D-Secure

1 Über EMV 3-D Secure

1.1 Regulatorische Anforderungen

1.1.1 EBA Mandat

Die Europäische Bankenaufsichtsbehörde (EBA) hat angeordnet, dass alle Zahler, die online auf ihr Zahlungskonto zugreifen und elektronische Zahlungstransaktionen über einen Remote-Kanal auslösen, beginnend ab 14. September 2019 stark authentisiert werden müssen (alias Strong Customer Authentication (SCA)). Die Kartenorganisationen haben diese Möglichkeit ergriffen, um das etablierte Protokoll 3D-Secure für die Karteninhaber-Authentisierung zu überarbeiten und mehrere Probleme anzugehen, welche die Annahme im Markt gebremst haben.

1.1.2 3DSecure 2.0

Bisher hatten Internethändler die Wahl, dem Karteninhaber eine Challenge (z.B. TAN / Passwort) zu präsentieren oder 3DS gänzlich zu übergehen. Einige haben einen dynamischen Ansatz basierend auf dem PSP oder der eigenen Risikobewertung gewählt, aber viele Händler schätzten einen reibungslosen Kassenvorgang und hohe Konversionsraten mehr als die möglichen Vorteile einer Haftungsverschiebung. Die Gesamtstrategie der Kartenorganisationen für 3DS 2.0 ist es, Reibereien durch eine verbesserte Erfahrung der Karteninhaber (Geräte-Bewusstsein) zu verringern und Ausnahmen von der SCA basierend auf einer robusten Transaktionsrisikoanalyse (TRA) auszunutzen mit dem obersten Ziel, optimale Autorisierungsleistung und Konversionsraten zu erreichen. Daher ist die TRA entscheidend für reibungslose Zahlungsabläufe für Remote-Transaktionen mit geringem Risiko. Deshalb hat das Protokoll 3DS 2.0 eine Unmenge zusätzlicher Datenpunkte eingeführt, die dem Kartenherausgeber zur Unterstützung der Transaktionsrisikoanalyse und für die Anwendung von Ausnahmen der SCA übermittelt werden können.

SCA wird erforderlich, wenn:

• die Transaktion nicht außerhalb des Geltungsbereichs der PSD2 RTS ist
• keine Ausnahme der PSD2 SCA für eine Zahlungstransaktion zutrifft
• eine Karte zu einer Händler-Datenbank hinzugefügt wird (hinterlegte Karte)
• eine Vereinbarung für wiederkehrende Zahlungen über feste oder variable Beträge beginnt, einschließlich der Festlegung des anfänglichen Mandats für vom Händler ausgelöste Transaktionen (MIT)
• eine Vereinbarung für wiederkehrende Zahlungen zu einem höheren Betrag geändert wird (beispielsweise ein Premium-Angebot)
• ein White-Listing eingerichtet wird (oder zum Ansehen/Ändern von White-Lists)
• ein Gerät mit einem Karteninhaber verknüpft wird

1.1.3 Haftungsverschiebung

Als Daumenregel gilt, wenn die Authentisierung des Karteninhabers über 3-D Secure erfolgt ist, sind Händler normalerweise vor Streitigkeiten bezüglich Betruges im E-Commerce geschützt und die Haftung verschiebt sich vom Händler / Acquirer zum Kartenherausgeber. Es gibt jedoch Ausnahmen vom Schutz des Händlers vor Streitigkeiten. Im Kontext von 3DS 2.0 sind Händler regelmäßig nicht geschützt, falls gewährte Ausnahmen gemäß PSD2 RTS aktiv vom Händler / Acquirer angefragt worden sind.

Das folgende Diagramm zeigt Optionen und Haftungen unter den Anforderungen von PSD2 RTS gemäß MasterCard.

1.1.4 3DS 2.0 und Compliance mit der DSGVO

Karteninhabern müssen ausführliche Informationen darüber gegeben werden, wie ihre Daten erfasst, verarbeitet und verwendet werden. Das kann über eine Datenschutzerklärung erreicht werden, die mindestens die Arten der verarbeiteten Daten, den Zeck ihrer Verarbeitung, die verwendeten Daten usw. enthält. Kartenorganisationen und Kartenherausgeber verwenden die EMV 3DS Daten für keinen anderen Zwecke als Betrugsprävention und Authentisierung. Das schließt die Verwendung persönlicher Daten für andere Zwecke wie Verkauf, Marketing und Data-Mining (außer zur Betrugsprävention) aus.

1.1.5 Ausnahmen und Ausklammerungen der PSD2 SCA

Gemäß den technischen Regulierungsstandards (RTS) gibt es einige wichtige Ausnahmen der SCA, die unter verschiedenen Bedingungen gelten können, welche im folgenden Diagramm dargestellt sind.

1.2 Das 1cs Online Bezahlsystem

1.2.1 Authentisierungs-Optionen

Einem Acquirer kann erlaubt sein, infolge geringer Betrugsraten und TRA die SCA nicht anzuwenden. Für diese Ausnahmen gibt es verschiedene Optionen zur Verarbeitung, die im folgenden Diagramm dargestellt sind.

Hinweis: Standardmäßig schlägt die First Cash Solution anwendbare Ausnahmen (sofern unterstützt) im EMV 3DS Authentisierungsablauf dem Kartenherausgeber vor, um die bestmöglichen Zustimmungsraten der Autorisierung zu erreichen.

EBA-Op-2018-04, Paragraph 47 – Klarstellung zu PSP (Acquirer-Betrugsraten)

Die Betrugsrate ist im Anhang A der RTS definiert und wird für alle Überweisungs-Transaktionen und alle Kartenzahlungen berechnet und kann nicht pro einzelnem Zahlungsempfänger (z.B. Händler) oder pro Kanal (entweder App oder Web-Schnittstelle) definiert werden. Die Betrugsrate, die bestimmt, ob sich ein PSP für die SCA-Ausnahme qualifiziert oder nicht, kann nicht nur für bestimmte Händler berechnet werden, d.h. wenn der Zahler eine Zahlung an einen bestimmten Händler leisten möchte und dieser bestimmte Händler eine Betrugsrate unter dem Grenzwert hat. Während der PSP (Acquirer) des Zahlungsempfängers vertraglich vereinbaren kann, die Überwachung seiner Transaktionsrisikoanalyse an einen gegebenen Händler ‘outzusourcen’ oder nur bestimmten vordefinierten Händlern erlauben kann, von den Vorteilen von dieser PSP-Ausnahme zu profitieren (basierend auf einer vertraglich vereinbarten geringen Betrugsrate), muss die Betrugsrate, welche einen bestimmten PSP für eine Ausnahme gemäß Artikel 18 geeignet macht, dennoch auf Basis der ausgeführten oder akquirierten Transaktionen vom PSP des Zahlungsempfängers berechnet werden und nicht ausgehend von den Transaktionen des Händlers.

1.2.2 Message Version 2

Um die Menge der zusätzlichen zahlungsfremden Daten zu handhaben und die Abwärtskompatibilität soweit wie möglich zu erhalten, hat sich die First Cash Solution dafür entschieden, seine 1cs OBS-Kartenschnittstelle über den zusätzlichen Parameter MsgVer zu versionieren. Die aktualisierte API basiert weiterhin auf Schlüssel-Wert-Paaren, aber setzt stark auf Base64-codierte JSON-Objekte zur Unterstützung der Lesbarkeit und Skript-Nutzung auf der Client-Seite.

Händler können weiterhin unsere klassische Schnittstelle für Anfragen auch mit 3DS 2.0 verwenden, aber es gibt ein paar Einschränkungen:

• Viele zusätzliche Datenpunkte für die Risikoanalyse des Kartenherausgebers sind nicht verfügbar und daher kann die Quote der reibungslosen Transaktionen geringer sein
• Antworten und Benachrichtigungen der API enthalten neue JSON-Objekte, um für die Spezifikationen des Protokolls 3DS 2.0 zu sorgen und erfordern eine Modifikation vorhandener Händler-Integrationen

Aus diesen Gründen ist es sehr empfohlen, auf die Version 2 zu aktualisieren.

1.2.3 Handhabung von Soft decline

Falls eine Transaktion keine SCA hat, können Kartenherausgeber mit einem sogenannten Soft decline reagieren. Das bedeutet, die Autorisierung der Transaktion wird vom Kartenherausgeber angelehnt, dieselbe Transaktion kann jedoch erneut initialisiert werden. Der Hauptgrund für Soft declines im Kontext von 3D Secure ist, dass Kartenherausgeber die vom Händler angefragten SCA-Ausnahmen nicht akzeptieren, wenn diese direkt zur Autorisierung gesendet werden oder wenn der eine Zahlung ohne zuvor durchgeführte Authentisierung anfordert. Die beste Methode ist es dann, die Zahlung mit 3DS neu zu starten. Mit der Automatischen Handhabung von Soft Decline reagiert das 1cs OBS je nach Konfiguration auf eine Soft decline Antwort mit einem automatischen Neustart der Zahlung mit erzwungener SCA. Das 1cs OBS erzeugt dann automatisch eine neue Zahlung im Namen des Händlers und integriert den 3DS-Ablauf.

WICHTIG:

– Aus Sicht des Kunden bemerkt dieser keinen Unterschied und muss seine Kreditkartendaten nicht erneut eingeben. Der gesamte Prozess wird vom 1cs Online-Bezahlsystem gesteuert.

– Beachten Sie bitte, dass diese Lösung für Server-zu-Server Verbindungen nicht verfügbar ist, weil das 1cs Online-Bezahlsystem den Client (Browser) nicht zum Start des 3DS-Ablaufes steuern kann. Für Server-zu-Server-Verbindungen muss der Händler die Zahlung mit 3DS-Ablauf neu auslösen und vor allem die SCA-Challenge über den angegebenen Parameter JSON threeDSPolicy (challengePreference = mandateChallenge) erzwingen.

1.2.3.1 Whitelisting von vertrauenswürdigen Begünstigten

Ein Karteninhaber kann dafür optieren, einen Händler zu einer Liste vertrauenswürdiger Begünstigter hinzuzufügen, die beim Kartenherausgeber geführt wird, um diesen speziellen Händler bei zukünftigen Zahlungen von der SCA auszunehmen. Das passiert normalerweise während einer Challenge des Karteninhabers, aber Karteninhaber können beispielsweise auch über ihre Banking-App eine Liste vertrauenswürdiger Begünstigter verwalten.

Händler können von einer Whitelist-Ausnahme profitieren, wenn diese angefragt ist und wenn nicht anderweitig eine Challenge des Karteninhabers gefordert ist.

Beachten Sie bitte, dass die Whitelist-Funktion ab 3DS Version 2.2 und höher verfügbar ist. Derzeit unterstützten die Kartenherausgeber meistens 3DS 2.1.

Hinweis: Beachten Sie bitte, dass die Whitelist-Funktion ab 3DS Version 2.2 und höher verfügbar ist. Derzeit unterstützten die Kartenherausgeber meistens 3DS 2.1.

1.2.3.2 Wiederkehrende Transaktionen

Wiederkehrende Transaktionen sind eine Reihe von Transaktionen, die nach einer Vereinbarung zwischen einem Karteninhaber und einem Händler verarbeitet werden, wobei der Karteninhaber Waren oder Dienstleistungen über einen Zeitraum und mit einer Anzahl getrennter Transaktionen mit dem gleichen Betrag erwirbt Die anfängliche Transaktion muss authentisiert werden (d.h. vom Karteninhaber ausgelöste Transaktion (CIT)). Nachfolgende wiederkehrende Zahlungen liegen außerhalb vom Geltungsbereich der RTS SCA, da sie regelmäßig vom Händler ausgelöst werden (d.h. ohne, dass der Kunde in einer Sitzung ist).

1.2.3.3 Transaktionen mit geringem Wert

Kartenherausgeber können Transaktionen von der SCA ausnehmen, sofern die folgenden Bedingungen erfüllt sind:

• der Zahlungsbetrag übersteigt nicht 30 Euro,
• der kumulierte Betrag vorheriger Zahlungstransaktionen ohne SCA übersteigt nicht 100 Euro,
• die Anzahl der vorherigen Zahlungstransaktionen ohne SCA übersteigt nicht fünf aufeinanderfolgende Zahlungstransaktionen.

Beachten Sie bitte, dass die Ausnahmen für geringen Wert angefragt werden müssen, um für einen reibungslosen Authentisierungs-Ablauf berücksichtigt zu werden.

1.2.3.4 Transaktionsrisikoanalyse

Acquirer und Kartenherausgeber dürfen auf die SCA verzichten, sofern die gesamte Betrugsrate nicht höher als die Referenz-Betrugsrate für den Ausnahmengrenzwert (ETV) ist, der in folgender Tabelle angegeben ist und wobei die risikobasierte Beurteilung jeder einzelnen Transaktion als geringes Risiko angesehen werden kann.

1.2.3.5 One-Leg-Out-Transaktionen

One-Leg-Out-Transaktionen sind solche Transaktionen, wo sich entweder der Zahlungsdienstleister des Zahlers oder der Zahlungsdienstleister des Empfängers außerhalb der Europäischen Union befindet.

Zahlungsdienstleister im Kontext kartenbasierter Transaktionen und im Geiste der PSD2 sind regelmäßig Acquirer und Issuer.

Daher sind weder die Nationalität des Karteninhabers noch der Geschäftsort des Händlers für die Beurteilung relevant, ob eine Transaktion infolge der Regel ‘one-leg-out’ außerhalb des Geltungsbereiches liegt.

2 Integrationsmethoden

2.1 Hosted Payment Pages (paySSL)

Bei Kartenzahlunen über bei der First Cash Solution gehostete Formulare wird die Komplexität von 3-D Secure vollständig bei der Implementierung beim Händler entfernt.

Aus Sicht des Händlers unterscheidet sich die Sequenz nicht zwischen Zahlungen, die mit 3DS authentisiert sind, sowie nicht mit 3DS authentisierten Zahlungen, welche die Berücksichtigung zusätzlicher Parameter in Aufruf und Antwort erfordern.

Hinweis zum Cookie-/Session Handling: Bitte beachten Sie, dass einige Browser beim Rücksprung zu Ihrem Shop erforderliche Cookies blockieren könnten. Hier finden Sie weitere Informationen und verschiedene Lösungsansätze.

Zahlungsanfrage

Zum Abruf eines First Cash Solution-Formulars für Kartenzahlungen übermitteln Sie bitte folgende Parameter über einen HTTP POST Aufruf an

Hinweis
Aus Sicherheitsgründen lehnt das Paygate alle Zahlungsanfragen mit Formatfehlern ab. Bitte übergeben Sie deshalb bei jedem Parameter den korrekten Datentyp.

Die folgende Tabelle beschreibt die verschlüsselten Übergabeparameter:

Key	Format	Bedingnung	Beschreibung
MerchantID	ans..30	M	HändlerID, die von der First Cash Solution vergeben wird
MsgVer	ans..5	M	Message-Version.Wert: 2.0 Mit 3-D Secure 2.x wurde eine Vielzahl zusätzlicher Daten (Browser-Information, Rechnungs-/Versand-Adresse, …) erforderlich, um den Authentifizierungs-Prozess zu optimieren. Um diese Informationen zu handhaben, wurden die JSON-Objekte eingeführt. Der Parameter MsgVer zeigt an, dass diese Daten verwendet werden.
TransID	ans..64	M	Ihre eigene TransaktionsID, die für jede Zahlung eindeutig sein muss
ReqId	ans..32	O	Um Doppelzahlungen (z.B. durch ETM) zu vermeiden, übergeben Sie einen alphanumerischen Wert, der Ihre Transaktion oder Aktion identifiziert und nur einmal vergeben werden darf. Falls die Transaktion oder Aktion mit derselben ReqID erneut eingereicht wird, führt das 1cs OBS keine Zahlung oder weitere Aktion aus, sondern gibt nur den Status der ursprünglichen Transaktion oder Aktion zurück. Bitte beachten Sie, dass das  1cs OBS für die erste initiale Aktion einen abgeschlossenen Transaktionsstatus haben muss. Einreichungen mit identischer ReqID auf einen offenen Status werden regulär verarbeitet. Bitte beachten Sie, dass eine ReqID nur 12 Monate gültig ist, danach wird sie vom  1cs OBS gelöscht.
RefNr	ans..30	O	Eindeutige Referenznummer des Händlers, welche als Auszahlungsreferenz in der entsprechenden Acquirer EPA-Datei angegeben wird. Bitte beachten Sie, ohne die Übergabe einer eigenen Auszahlungsreferenz können Sie die EPA-Transaktionen nicht zuordnen, zusätzlich kann das  Computop Settlement File (CTSF) auch nicht zusätzlich angereichert werden. Informationen zum unterstützten Format finden Sie weiter unten in der zahlartspezifischen Beschreibung.
MAC	an64	M	Hash Message Authentication Code (HMAC) mit SHA-256-Algorithmus. Details finden Sie hier: HMAC-Authentisierung (Anfrage) HMAC-Authentisierung (Notify)
Amount	n..10	M	Betrag in der kleinsten Währungseinheit (z.B. EUR Cent) Bitte wenden Sie sich an First Cash Solution, wenn Sie Beträge < 100 (kleinste Währungseinheit) buchen möchten.
Currency	a3	M	Währung, drei Zeichen DIN / ISO 4217, z.B. EUR, USD, GBP. Hier eine Übersicht: Währungstabelle
Capture	ans..6	O	Bestimmt Art und Zeit der Buchung (engl. Capture). AUTO= Buchung sofort nach der Autorisierung (Standardwert) MANUAL = Buchung durch den Händler -in der Regel die Buchung zum Zeitpunkt der Warenauslieferung bzw. Leistungserbringung. <Zahl> = Verzögerung in Stunden bis zur Buchung (ganze Zahl; 1 bis 696).
PayTypes	ans..256	O	Mit diesem Parameter können Sie die akzeptierten Schemes übersteuern, d.h. Sie können innerhalb dieses Parameters durch Pipe getrennt entscheiden, welche der verfügbaren Kreditkartenschemes angezeigt werden. Das Template muss diese Funktion unterstützen wie zum Beispiel das “Cards_v1”. Beispiel: PayTypes=VISA|MasterCard
billingDescriptor	ans..22	O	Eine Bezeichnung, die auf dem Kontoauszug des Karteninhbaers gedruckt wird. Beachten Sie bitte auch die zusätzliche Hinweise an anderer Stelle für weitere Informationen über Regeln und Vorschriften.
OrderDesc	ans..768	O	Beschreibung der gekauften Waren, Einzelpreise etc.
AccVerify	a3	O	Indikator für Anforderung einer Kontoverifizierung (alias Nullwert-Authorisierung). Bei einer angeforderten Kontoverifizierung ist der übermittelte Betrag optional und wird für die tatsächliche Zahlungstransaktion ignoriert (z.B. Autorisierung).Zulässiger Wert: Yes
threeDSPolicy	JSON	O	Objekt, das Authentisierungs-Richtlinien und Vorgaben für die Ausnahmenbehandlung festlegt.
priorAuthenticationInfo	JSON	O	Das Objekt Prior Transaction Authentication Information enthält optionale Informationen über eine Authentisierung eines 3DS-Karteninhabers, die vor der aktuellen Transaktion erfolgt ist.
accountInfo	JSON	O	Das Objekt Kontoinformationen enthält optionale Informationen über das Kundenkonto beim Händler.
billToCustomer	JSON	C	Der Kunde, dem die Waren und / oder Dienstleistungen in Rechnung gestellt werden. Für EMV 3DS erforderlich, sofern nicht Markt- oder Regionalmandate die Übermittlung dieser Infomrationen beschränken.
shipToCustomer	JSON	C	Der Kunde, an den die Waren und / oder Dienstleistungen gesendet werden. Erforderlich, falls von billToCustomer abweichend.
billingAddress	JSON	C	Rechnungsadresse. For EMV 3DS erforderlich (falls verfügbar), sofern nicht Markt- oder Regionalmandate die Übermittlung dieser Infomrationen beschränken.
shippingAddress	JSON	C	Lieferadresse. Falls von billingAddress abweichend; für EMV 3DS erforderlich (falls verfügbar), sofern nicht Markt- oder Regionalmandate die Übermittlung dieser Infomrationen beschränken.
credentialOnFile	JSON	C	Objekt, das Art und Reihe von Transaktionen mittels Zahlungskonto-Zugangsdaten festlegt (z.B. Kontonummer oder Zahlungs-Token), die bei einem Händler für die Verarbeitung zukünftiger Einkäufe für einen Kunden gespeichert sind. Erforderlich, falls zutreffend.
merchantRiskIndicator	JSON	O	Der Händler-Risikoindikator enthält optionale Informationen über den bestimmten Einkauf des Kunden.Falls shippingAddress nicht vorhanden ist, ist es dringend empfohlen, das Merkmal shippingAddressIndicator mit einem entsprechenden Wert wie shipToBillingAddress, digitalGoods oder noShipment auszufüllen.
subMerchantPF	JSON	O	Objekt, das die Details des SubMerchant (Payment Facilitator) angibt. Wird ausschließlich von SafeCharge unterstützt.
URLSuccess	ans..256	M	Vollständige URL, die das 1cs Online Bezahlsystem aufruft, wenn die Zahlung gescheitert ist. Die URL darf nur über Port 443 aufgerufen werden. Die URL darf nur über Port 443 aufgerufen werden. Diese URL darf keine Parameter enthalten: Um Parameter durchzureichen, nutzen Sie stattdessen den Parameter UserData. Allgemeine Hinweise: Wir empfehlen, den Parameter “response=encrypt” zu verwenden, um eine verschlüsselte Antwort vom 1cs OBS zu erhalten Betrüger könnten das verschlüsselte DATA-Element kopieren, welches an URLFailure gesendet wurde, und betrügerisch dasselbe DATA an URLSuccess senden. Überprüfen Sie daher unbedingt den “code”-Wert des DATA-Elements. Nur eine Antwort mit “code=00000000” sollte als erfolgreich angesehen werden.
URLFailure	ans..256	M	Vollständige URL, die das 1cs Online Bezahlsystem aufruft, wenn die Zahlung gescheitert ist. Die URL darf nur über Port 443 aufgerufen werden. Diese URL darf keine Parameter enthalten: Um Parameter durchzureichen, nutzen Sie stattdessen den Parameter UserData. Allgemeine Hinweise: Wir empfehlen, den Parameter “response=encrypt” zu verwenden, um eine verschlüsselte Antwort vom 1cs OBS zu erhalten Betrüger könnten das verschlüsselte DATA-Element kopieren, welches an URLFailure gesendet wurde, und betrügerisch dasselbe DATA an URLSuccess/URLNotify senden. Überprüfen Sie daher unbedingt den “code”-Wert des DATA-Elements. Nur eine Antwort mit “code=00000000” sollte als erfolgreich angesehen werden.
URLBack	ans..256	O	Vollständige URL, die das 1cs Online Bezahlsystem aufruft, wenn der Kunde auf Abbruch klickt. Der Parameter “URLBack” kann sowohl unverschlüsselt ans Paygate übermittelt werden (Kompabilitätsmodus) als auch in den verschlüsselten Übergabeparametern (bevorzugte Variante) Wenn Sie Parameter/Werte in der URLBack übergeben möchten, so können Sie folgende Methode verwenden: URLBack=https://your.shop.com/back.php?param1%3Dvalue1%26param2%3Dvalue3%26status%3Dcancelled Wenn der Kunde auf Abbruch klickt, so wird die URL genauso aufgerufen, so dass Sie URL Decode verwenden können, um Parameter und Werte zu extrahieren.
Response	a7	O	Die Status-Rückmeldung, die das 1cs Online Bezahlsystem an URLSuccess und URLFailure sendet, sollte verschlüsselt werden. Dazu übergeben Sie den Parameter Response=encrypt.
URLNotify	an..256	M	Vollständige URL, die das 1cs Onlinebezahlsystem aufruft, um den Shop zu benachrichtigen. Die URL darf nur über Port 443 aufgerufen werden. Sie darf keine Parameter enthalten: Nutzen Sie stattdessen den Parameter UserData. Allgemeine Hinweise: Wir empfehlen, den Parameter “response=encrypt” zu verwenden, um eine verschlüsselte Antwort von dem 1cs OBS zu erhalten Betrüger könnten das verschlüsselte DATA-Element kopieren, welches an URLFailure gesendet wurde, und betrügerisch dasselbe DATA an URLSuccess/URLNotify senden. Überprüfen Sie daher unbedingt den “code”-Wert des DATA-Elements. Nur eine Antwort mit “code=00000000” sollte als erfolgreich angesehen werden.
userData	ans..1024	O	Wenn beim Aufruf angegeben, übergibt das 1cs Online Bezahlsystem die Parameter mit dem Zahlungsergebnis an den Shop.
Custom	ans..1024	O	Der “Custom”-Parameter wird vor der Verschlüsselung an den Aufruf angehängt und ist Teil des verschlüsselten “Data” im 1cs OBS Aufruf. Dadurch ist der Wert gegen Manipulation geschützt.  Der Custom-Wert wird dann in Klartext an die  1cs-OBS-Antwort angehängt und dabei wird “|” durch “&” ersetzt. Dadurch können Sie einen Custom-Wert übergeben und bekommen mehrere Key-Value-Paare zu Ihrer eigenen Verwendung in der Antwort zurück.
Plain	ans..50	O	Ein einzelner Wert, der von Ihnen gesetzt werden kann, um Informationen wieder unverschlüsselt in der Antwort bzw. im Notify zurückzugeben, z.B. die MID. Da der “Plain”-Parameter Teil des verschlüsselten “Data” im 1cs OBS ist, ist dieser vor Manipulationen geschützt.
expirationTime	ans..19	O	Zeitstempel für den Endzeitpunkt der Transaktionsverarbeitung, Angabe in UTC. Format: YYYY-MM-ddTHH:mm:ss

Das 1cs Online Bezahlsystem gibt in der Antwort ein HTML-Dokument zurück, welches das angeforderte Kartenzahlungsformular darstellt. Das Formular kann in die Checkout-Seite des Händlers integriert oder als selbständige Seite verwendet werden, auf die der Karteninhaber weitergeleitet wird.

Die Authentisierung des Karteninhabers sowie die Zahlungsautorisierung erfolgen, nachdem der Karteninhaber aller erforderlichen Kartendetails eingegeben und das Formular an das 1cs Online Bezahlsystem übermittelt hat.

Hinweis: Falls Sie ein eigenes Zahlungsformular verwenden (Corporate Payment Page), achten Sie darauf, dass der Name des Karteninhabers auf dem Formular enthalten ist. Der Name das Karteninhabers wird auf den Paygate API-Parameter “CreditCardHolder” abgebildet. Das Feld Cardholder name darf keine Sonderzeichen enthalten und muss eine Mindestlänge von 2 Zeichen und eine Maximallänge von 45 Zeichen haben.

Wenn die Zahlung abgeschlossen ist, sendet das 1cs Online Bezahlsystem eine Benachrichtigung an den Server des Händlers (d.h. URLNotify) und leitet den Browser an URLSuccess beziehungsweise URLFailure weiter.

Die per Blowfish verschlüsselten Parameter laut folgender Tabelle werden per HTTP POST an URLNotify und URLSuccess/URLFailure übertragen.

Hinweis: Bitte beachten Sie, dass der Aufruf der URLSuccess oder URLFailure bei einem Fallback zu 3-D Secure 1.0 mit GET stattfindet. Ihre Systeme sollten daher Parameter sowohl per GET als auch per POST entgegennehmen können.

HTTP POST an URLSuccess / URLFailure / URLNotify

Die folgende Tabelle beschreibt die Ergebnis-Parameter, die das 1cs Online Bezahlsystem an Ihre URLSuccess, URLFailure und URLNotify übergibt. Wenn Sie den Parameter Response=encrypt angegeben haben, werden die folgenden Parameter mit Blowfish verschlüsselt an Ihr System übergeben:

• es können jederzeit neue Parameter hinzugefügt bzw. die Reihenfolge geändert werden
• die Parameter (z.B. MerchantId, RefNr) sollten nicht auf Groß-/Kleinschreibung geprüft werden

Kreditkartenzahlung mit separater Autorisierung

Für Kreditkartenzahlungen kann im Prozessablauf die ORDER von der anschließenden Autorisierung und nachfolgenden Schritten getrennt werden. Dazu wird die SSL-Kreditkartenzahlung zunächst per Formular oder Server-zu-Server-Anbindung wie in den voranstehenden Kapiteln dargestellt mit einem zusätzlichen Parameter initialisiert und dann über die Schnittstelle authorize.aspx per Server-zu-Server-Verbindung autorisiert. Zur Initialisierung rufen Sie folgende URL auf:

https://www.computop-paygate.com/payssl.aspx

Bei Server-zu-Server-Anbindung rufen Sie folgende URL auf:

https://www.computop-paygate.com/direct.aspx

Die folgende Tabelle beschreibt die verschlüsselten Übergabeparameter:

Zusatzparameter für Kreditkartenzahlung mit separater Autorisierung

Um eine zuvor mit TxType=Order initialisierte SSL-Kreditkartenzahlung zu autorisieren, rufen Sie folgende URL auf:

https://www.computop-paygate.com/authorize.aspx

Hinweis: Bitte beachten Sie, dass bei einer initialen Order keine KPN/CVC/CVV-Prüfung erfolgen kann. Für die folgende Reservierungsanfrage kann diese ID auch nicht weitergegeben werden.

Hinweis: Aus Sicherheitsgründen lehnt das Paygate alle Zahlungsanfragen mit Formatfehlern ab. Bitte übergeben Sie deshalb bei jedem Parameter den korrekten Datentyp.

Die folgende Tabelle beschreibt die verschlüsselten Übergabeparameter:

Parameter für Kreditkartenzahlungen über authorize.aspx


Folgende Tabelle beschreibt die Ergebnis-Parameter, die das 1cs Online Bezahlsystem als Antwort zurückgibt:

Hinweis: es können jederzeit neue Parameter hinzugefügt bzw. die Reihenfolge geändert werden

Hinweis: die Parameter (z.B. MerchantId, RefNr) sollten nicht auf Groß-/Kleinschreibung geprüft werden 

Key	Format	Bedingung	Beschreibung
MID	ans..30	M	HändlerID, die von der First Cash Solution vergeben wird
PayID	ans32	M	Vom 1cs Online Bezahlsystem vergebene ID für die Zahlung; z.B. zur Referenzierung in Batch-Dateien sowie im Capture- oder Credit-Request.
XID	an32	M	Vom 1cs Online Bezahlsystem vergebene ID für die einzelnen Operationen, die zu einer Zahlung durchgeführt werden
Code	n8	M	Fehlercode gemäß 1cs Online Bezahlsystem Antwort Codes (Fehlercodes)
Description	ans.1024	M	Nähere Beschreibung bei Ablehnung der Zahlung. Bitte nutzen Sie nicht den Parameter Description, sondern Code für die Auswertung des Transaktionsstatus!
TransID	ans..64	M	Ihre eigene TransaktionsID, die für jede Zahlung eindeutig sein muss
Status	a..50	M	OK oder FAILED
RefNr		O	Eindeutige Referenznummer des Händlers, welche als Auszahlungsreferenz in der entsprechenden Acquirer EPA-Datei angegeben wird. Bitte beachten Sie, ohne die Übergabe einer eigenen Auszahlungsreferenz können Sie die EPA-Transaktionen nicht zuordnen, zusätzlich kann das Computop Settlement File (CTSF) auch nicht zusätzlich angereichert werden. Informationen zum unterstützten Format finden Sie weiter unten in der zahlartspezifischen Beschreibung. Es sind ausschließlich ASCII-Zeichen erlaubt. Sonderzeichen wie (“Umlaute”, …) sind nicht erlaubt und müssen ggf. durch ASCII-Zeichen ersetzt werden (z.B. ü → ue, é → e, …).

Ergebnis-Parameter für Kreditkartenzahlungen über authorize.aspx

Erweitertes Sequenz-Diagramm

2.2 Server-2-Server Integration

Eine 3DS 2.0 Zahlungssequenz kann aus den folgenden verschiedenen Aktivitäten bestehen:

• Versionierung
  • Anfrage von ACS- und DS-Protokol-Version(en), die mit dem Kartenkontenbereich korrespondieren sowie einer optionalen 3DS Method URL

• 3DS Methode
  • Verbindet den Browser des Karteninhabers mit dem ACS des Issuers, um zusätzliche Browserdaten zu erhalten
• Authensierung
  • Übermittlung der Authentisierungs-Anfrage an den ACS des Issuers
• Challenge
  • Challenge des Karteninhabers, falls angeordnet
• Autorisierung
  • Autorisierung der authentisierten Transaktion beim Acquirer  

Hinweis: Beachten Sie bitte, dass die Kommunikation zwischen Client und Access Control Server (ACS) über iFrames implementiert ist. Daher kommen die Antworten in einem HTML-Subdokument an und Sie können entsprechende Event-Listener in Ihrem Root-Dokument einrichten. Alternativ könnten Sie alleinig auf die asynchronen Benachrichtigungen an ihr Backend vertrauen. In jenen Fällen müssen Sie eventuell Methoden wie Long Polling, SSE oder Websockets zum Update des Clients in Betracht ziehen.

Initiierung der Zahlung

Die anfängliche Anfrage an das 1cs Online Bezahlsystem ist unabhängig vom zugrundeliegenden 3DS-Protokoll gleich.

Um eine Server-zu-Server 3-D Secure Kartenzahlungssequenz zu starten, senden Sie bitte folgende Schlüssel-Wert-Paare an https://www.computop-paygate.com/direct.aspx.

Aufruf-Elemente

Hinweis: Bei einer vom Händler initiierten, wiederkehrenden Zahlung sind die JSON-Objekte (außer credentialOnFile und card), die URLNotify und die TermURL keine Pflichtparameter, da kein 3D Secure und auch keine Risikobewertung durch die kartenausgebende Bank stattfindet und das Ergebnis der Zahlungsanfrage direkt in der Response mitgeteilt wird.

Antwort-Elemente

Folgende Tabelle beschreibt die Ergebnis-Parameter, die das 1cs Online Bezahlsystemals Antwort zurückgibt:

versioningData

Das Objekt versioningData gibt die EMV 3DS Protokoll-Versionen (d.h. 2.1.0 oder höher) an, die vom Access Control Server des Issuers unterstützt werden.

Wenn die entsprechenden Felder der Protokoll-Version NULL sind, bedeutet dies, dass der BIN-Bereich des Karten-Issuers nicht für 3DS 2.0 registriert ist und ein Fallback auf 3DS 1.0 für Transaktionen erforderlich ist, die unter den Geltungsbereich der PSD2 SCA fallen.

Achten Sie beim Zerlegen von versioningData bitte auch auf das Subelement errorDetails, das den Grund angibt, falls einige Felder nicht ausgefüllt sind (z.B. Ungültige Kontonumber des Karteninhabers übergeben, nicht verfügbare Kartenbereichsdaten, Fehler beo Codieren/Serialisieren der 3DS Methoden-Daten usw.)

  BASEURL= https://www.computop-paygate.com/

{

    "threeDSServerTransID": "14dd844c-b0fc-4dfe-8635-366fbf43468c",

    "acsStartProtocolVersion": "2.1.0",

    "acsEndProtocolVersion": "2.1.0",

    "dsStartProtocolVersion": "2.1.0",

    "dsEndProtocolVersion": "2.1.0",

    "threeDSMethodURL": "http://www.acs.com/script",

    "threeDSMethodDataForm":
    "eyJ0aHJlZURTTWV0aG9kTm90aWZpY2F0aW9uVVJMIjoiaHR0cHM6Ly93d3cuY29tcHV0b3A
     tcGF5Z2F0ZS5jb20vY2JUaHJlZURTLmFzcHg_YWN0aW9uPW10aGROdGZuIiwidGhyZWVEU1Nlcn
     ZlclRyYW5zSUQiOiIxNGRkODQ0Yy1iMGZjLTRkZmUtODYzNS0zNjZmYmY0MzQ2OGMifQ==",

    "threeDSMethodData": {

        "threeDSMethodNotificationURL": "https://www.computop-paygate.com/cbThreeDS.aspx?action=mthdNtfn",

        "threeDSServerTransID": "14dd844c-b0fc-4dfe-8635-366fbf43468c"

    }

}

3DS Methode

Die 3DS Methode ermöglicht das Erfassen zusätzlicher Browserinformationen durch einen ACS vor Erhalt der Authensisierungsanfrage (AReq), um die Risikobeurteilung der Transaktion zu erleichtern. Die Unterstützung der 3DS Methode ist optional und liegt im Ermessen des Issuers.

Das Objekt versioningData enthält einen Wert für threeDSMethodURL. Der Händler sollte die 3DS Methode über einen versteckten HTML-iFrame im Browser des Karteninhabers aufrufen und ein Formular mit einem Feld namens threeDSMethodData über HTTP POST an die ACS 3DS Methoden-URL senden.

3DS Methode: threeDSMethodURL

Beachten Sie bitte, dass die threeDSMethodURL vom 1cs Online Bezahlsystem ausgefüllt wird, falls der Issuer die 3DS Methode nicht unterstützt. Der 3DS Methoden-Formular-Post wie unten dargestellt muss unabhängig davon ausgeführt werden, ob diese vom Issuer unterstützt wird. Das ist notwending, um die direkte Kommunikation zwischen dem Browser und dem 1cs Online Bezahlsystem im Falle einer angeordneten Challenge oder eines reibungslosen Ablaufs zu erleichtern.

3DS Method: Keine Issuer threeDSMethodURL

3DS Method Form Post

<form name="frm" method="POST" action="Rendering URL">

    <input type="hidden" name="threeDSMethodData" value="eyJ0aHJlZURTU2VydmVyVHJhbnNJ
     RCI6IjNhYzdjYWE3LWFhNDItMjY2My03OTFiLTJhYzA1YTU0MmM0YSIsInRocmVlRFNNZXRob2R
     b3RpZmljYXRpb25VUkwiOiJ0aHJlZURTTWV0aG9kTm90aWZpY2F0aW9uVVJMIn0">

</form>

Der ACS interagiert mit dem Browser des Karteninhabers über den HTML-iFrame und speichert dann die zutreffenden Werte mit der 3DS Server Transaction ID für die Verwendung, wenn eine nachfolgende Authentisierungs-Nachricht empfangen wird, welche die gleiche 3DS Server Transaction ID enthält.

Hinweis: Sie können nach eigenem Ermessen die Operationen init3DSMethod oder createIframeAndInit3DSMethod vom nca3DSWebSDKverwenden, um die 3DS Methode zu initialisieren. Bitte beachten Sie dazu das Integrations-Handbuch unter https://mpi.netcetera.com/3dsserver/doc/current/integration.html#Web_Service_API.

Nachdem die 3DS Methode abgeschlossen ist, weist der ACS den Browser des Karteninhabers über das iFrame-Antwortdokument an, threeDSMethodData als ein verstecktes Formularfeld an die 3DS Method Notification URL zu übermitteln.

ACS Response Document:

<!DOCTYPE html>

<html lang="en">

<head>

    <meta charset="UTF-8"/>

    <title>Identifying...</title>

</head>

<body>

<script>

    var tdsMethodNotificationValue = 'eyJ0aHJlZURTU2VydmVyVHJhbnNJRCI6ImUxYzFlYmViLTc0ZTgtNDNiMi1iMzg1LTJlNjdkMWFhY2ZhMiJ9';

    var form = document.createElement("form");

    form.setAttribute("method", "post");

    form.setAttribute("action", "notification URL");

    addParameter(form, "threeDSMethodData", tdsMethodNotificationValue);

    document.body.appendChild(form);

    form.submit();

    function addParameter(form, key, value) {

        var hiddenField = document.createElement("input");

        hiddenField.setAttribute("type", "hidden");

        hiddenField.setAttribute("name", key);

        hiddenField.setAttribute("value", value);

        form.appendChild(hiddenField);

    }

</script>

</body>

</html>

3DS Method Notification Form

<form name="frm" method="POST" action="3DS Method Notification URL">

    <input type="hidden" name="threeDSMethodData" value="eyJ0aHJlZURTU
    2VydmVyVHJhbnNJRCI6ImUxYzFlYmViLTc0ZTgtNDNiMi1iMzg1LTJlNjdkMWFhY2ZhMiJ9">

</form>

Hinweis: Beachten SIe bitte, dass die threeDSMethodNotificationURL wie sie in den Base64-codierten threeDSMethodData eingebettet ist, auf das 1cs Online Bezahlsystem weist und nicht verändert werden darf. Die Händler-Benachrichtigung wird an die URLNotify geliefert, wie sie in der Originalanfrage übermittelt oder für die MerchantID im 1cs Online Bezahlsystem konfiguriert ist.

Authentisierung

Wenn 3DS Methode vom ACS des Issuers unterstützt wird und vom Händler aufgerufen wurde, setzt das 1cs Online Bezahlsystem automatisch mit der Authentisierungsanfrage fort, nachdem die 3DS Methode abgeschlossen ist (d.h. 3DS Methoden-Benachrichtigung).

Das Ergebnis der Authentisierung wird per HTTP POST an die URLNotify übertragen. Es kann anzeigen, dass der Karteninhaber authentisiert worden ist oder dass eine weitere Interaktion des Karteninhabers (d.h. Challenge) für den Abschluss der Authentisierung erforderlich ist.

Falls für den Karteninhaber eine Challenge angeordnet ist, überträgt das 1cs Online Bezahlsystem ein JSON-Objekt im Body der HTTP Browser-Antwort mit den Elementen acsChallengeMandated, challengeRequest, base64EncodedChallengeRequest und acsURL. Anderenfalls setzt das 1cs Online Bezahlsystem in einem reibungslosen Ablauf automatisch fort und antwortet dem Browser des Karteninhabers, sobald die Autorisierung abgeschlossen ist.

Karteninhaber-Challenge: Browser-Antwort

Browser Challenge-Antwort

Datenelemente

Schema: Browser Challenge Response

{     "$schema": "http://json-schema.org/draft-07/schema#",     "type": "object",     "properties": {         "acsChallengeMandated": {"type": "boolean"},         "challengeRequest": {"type": "object"},         "base64EncodedChallengeRequest": {"type": "string"},         "acsURL": {"type": "string"}     },     "required": ["acsChallengeMandated", "challengeRequest", "base64EncodedChallengeRequest", "acsURL"],     "additionalProperties": false }

Beispiel: Browser Challenge Response

{     "acsChallengeMandated": true,     "challengeRequest": {         "threeDSServerTransID": "8a880dc0-d2d2-4067-bcb1-b08d1690b26e",         "acsTransID": "d7c1ee99-9478-44a6-b1f2-391e29c6b340",         "messageType": "CReq",         "messageVersion": "2.1.0",         "challengeWindowSize": "01",         "messageExtension": [             {                 "name": "emvcomsgextInChallenge",                 "id": "tc8Qtm465Ln1FX0nZprA",                 "criticalityIndicator": false,                 "data": "messageExtensionDataInChallenge"             }         ]     },     "base64EncodedChallengeRequest": "base64-encoded-challenge-request",     "acsURL": "acsURL-to-post-challenge-request" }

Authentisierungs-Benachrichtigung

Die Datenelemente der Authentisierungs-Benachrichtigung stehen in folgender Tabelle.

Browser Challenge

Wenn eine Challenge angeordnet wird (siehe acsChallengeMandated), erfolgt die Browser Challenge im Browser des Karteninhabers. Zum Erzeugen einer Challenge ist es erforderlich, den Wert base64EncodedChallengeRequest über ein HTML-iFrame an die ACS URL zu posten.

Challenge-Anfrage

<form name="challengeRequestForm" method="post" action="acsChallengeURL">

    <input type="hidden" name="creq" value="ewogICAgInRocmVlRFNTZXJ2ZXJUcmFuc0lEIjogIj
hhODgwZGMwLWQyZDItNDA2Ny1iY2IxLWIwOGQxNjkwYjI2ZSIsCiAgICAiYWNzVHJhbnNJRCI6ICJkN2MxZW
U5OS05NDc4LTQ0YTYtYjFmMi0zOTFlMjljNmIzNDAiLAogICAgIm1lc3NhZ2VUeXBlIjogIkNSZXEiLAogICAg
Im1lc3NhZ2VWZXJzaW9uIjogIjIuMS4wIiwKICAgICJjaGFsbGVuZ2VXaW5kb3dTaXplIjogIjAxIiwKI
CAgICJtZXNzYWdlRXh0ZW5zaW9uIjogWwoJCXsKCQkJIm5hbWUiOiAiZW12Y29tc2dleHRJbkNo YWxsZW5
nZSIsCgkJCSJpZCI6ICJ0YzhRdG00NjVMbjFGWDBuWnByQSIsCgkJCSJjcml0aWNhbGl0e UluZGljYXRvciI6IGZh
bHNlLAoJCQkiZGF0YSI6ICJtZXNzYWdlRXh0ZW5zaW9uRGF0YUluQ2hhbGxlbmdlIgoJCX0KICAgIF0KfQ==">

</form>

Sie können die Operationen init3DSChallengeRequest oder createIFrameAndInit3DSChallengeRequest aus dem nca3DSWebSDK verwenden, um die Challenge-Nachricht an den Browser des Karteninhabers zu übermitteln.

3DS Challenge-Anfrage initialisieren – Beispiel

<!DOCTYPE html> <html lang="en"> <head>     <meta charset="UTF-8">     <script src="nca-3ds-web-sdk.js" type="text/javascript"></script>     <title>Init 3DS Challenge-Anfrage - Beispiel</title> </head> <body> <!-- Dieses Beispiel zeigt, wie Challenge-Anfragen für verschiedenen Fenstergrößen initialisiert werden. --> <div id="frameContainer01"></div> <div id="frameContainer02"></div> <div id="frameContainer03"></div> <div id="frameContainer04"></div> <div id="frameContainer05"></div> <iframe id="iframeContainerFull" name="iframeContainerFull" width="100%" height="100%"></iframe>    <script type="text/javascript">     // All Container laden     iFrameContainerFull = document.getElementById('iframeContainerFull');     container01 = document.getElementById('frameContainer01');     container02 = document.getElementById('frameContainer02');     container03 = document.getElementById('frameContainer03');     container04 = document.getElementById('frameContainer04');     container05 = document.getElementById('frameContainer05');           // nca3DSWebSDK.init3DSChallengeRequest(acsUrl, creqData, container);     nca3DSWebSDK.init3DSChallengeRequest('http://example.com', 'base64-encoded-challenge-request', iFrameContainerFull);         // nca3DSWebSDK.createIFrameAndInit3DSChallengeRequest(acsUrl, creqData, challengeWindowSize, frameName, rootContainer, callbackWhenLoaded);     nca3DSWebSDK.createIFrameAndInit3DSChallengeRequest('http://example.com', 'base64-encoded-challenge-request', '01', 'threeDSCReq01', container01);     nca3DSWebSDK.createIFrameAndInit3DSChallengeRequest('http://example.com', 'base64-encoded-challenge-request', '02', 'threeDSCReq02', container02);     nca3DSWebSDK.createIFrameAndInit3DSChallengeRequest('http://example.com', 'base64-encoded-challenge-request', '03', 'threeDSCReq03', container03);     nca3DSWebSDK.createIFrameAndInit3DSChallengeRequest('http://example.com', 'base64-encoded-challenge-request', '04', 'threeDSCReq04', container04);     nca3DSWebSDK.createIFrameAndInit3DSChallengeRequest('http://example.com', 'base64-encoded-challenge-request', '05', 'threeDSCReq05', container05, () => {         console.log('Iframe loaded, form created and submitted');     }); </script>    </body> </html>

Sobald die Challenge des Karteninhabers abgeschlossen, abgebrochen oder per Zeitüberschreitung beendet ist, weist der ACS den Browser an, die Ergebnisse per Post an die in der Challenge-Anfrage angegebene Benachrichtigungs-URL zu senden und eine Ergebnis-Anfrage (RReq) über den Directory Server an den 3DS Server zu senden.

Hinweis: Beachten Sie bitte, dass die in der Challenge-Anfrage übergebene Benachrichtigungs-URL auf das 1cs Online Bezahlsystem zeigt und nicht verändert werden darf.

Autorisierung

Nachdem die erfolgreiche Authentisierung des Karteninhabers oder der Nachweis der versuchten Authentisierung/Verifizierung bereitgestellt ist, setzt das 1cs Online Bezahlsystem die Zahlungsautorisierung automatisch fort.

Falls die Authentisierung des Karteninhabers nicht erfolgreich war oder der Nachweise der versuchten Authentisierung/Verifizierung nicht bereitgestellt werden kann, setzt das 1cs Online Bezahlsystem nicht mit einer Autorisierungsanfrage fort.

In beiden Fällen liefert das 1cs Online Bezahlsystem eine endgültige Benachrichtigung an die vom Händler angegebene URLNotify mit den Datenelementen gemäß nachstehender Tabelle.

Zahlungs-Benachrichtigung

Browser Zahlungs-Antwort

Zusätzlich werden nachstehende Datenelemente im JSON-Format im Body der HTTP-Antwort zum Browser des Karteninhabers übertragen. Beachten Sie bitte, dass die Datenelemente (d.h. MID, Len, Data) base64-codiert sind.

Datenelemente

Schema

{     "$schema": "http://json-schema.org/draft-07/schema#",     "type": "object",     "properties": {         "MID": {             "type": "string"         },         "Len": {             "type": "integer"         },         "Data": {             "type": "string"         }     },     "required": ["MID", "Len", "Data"],     "additionalProperties": false }

Händler sollten diese Datenelemente zur Entschlüsselung und für den Abgleich mit der Zahlungs-Benachrichtigung an ihren Server weiterleiten. Basierend auf dem Zahlungsergebnis kann der Händler-Server eine entsprechende Antwort an den Browser des Karteninhabers senden (z.B. Erfolgsseite).

Entschlüsseltes Objekt Data

Beispiel für entschlüsseltes Objekt Data

MID=YourMID&PayID=PayIDassignedbyOBS&TransID=YourTransID

2.2.1 3DS 1.0 Fallback

Falls der Access Control Server (ACS) der Bank des Karteninhabers keine EMV 3DS Protokoll-Version unterstützt (d.h. 2.0 oder höher, siehe acsStartProtocolVersion), wird das Element threeDSMethodDataForm des Objekts versioningData in der Zahlungsantwort Null.

Sequenzdiagramm

3DS 1.0 Authentisierung

Um eine 3DS 1.0 Authentisierungs-Anfrage über den Browser des Karteninhabers auszuführen, ist es erforderlich, ein Formular aus den in threeDSLegacy bereitgestellten Datenelementen zu konstruieren und es an die acsURL zu posten.

Die an den ACS gesendeten Formularfelder sind in nachfolgender Tabelle aufgeführt:

<html>

    <head>

        <script language=\"javascript\">

            <!--

                function sendpareq()                     {                          document.pareq_form.submit();                     }             // -->         </script>     </head>           <body onload="javascript:sendpareq();">         <form action="https://pit.3dsecure.net/VbVTestSuiteService/pit1/acsService/paReq?summary=ZTIwOWMwYmEtNTVhOC00NDExLThkZDktYzllODk1NmZlNDQ0" method="POST" name="pareq_form">             <input type="hidden" name="PaReq" value="eJxVUst22jAQ/RUfL7rpMZKFiQ0
            dK4dXgAVOTmuSpjvVGsApfkSWA+TrK/Fo0t29M6M7M3cEt4di57yhavKqjF2/Q10Hy
            6ySebmJ3VV650Wu02hRSrGrSozdIzbuLYd0qxAnPzBrFXJYYtOIDTq5jN1aCI
            EioyzywkhILwh7gddnFD1JMVyv15HfYz2Xw8PwO75yuPTmpnWHAblSo6myrSg1B5G9
            jhYJD266jHWBXCgUqBYTPk4fR4+M+jdAzgEoRYG8zrXGRn+dFb/nzhdR1N+ccQXk
            lIOsakutjpyF5tWVQKt2fKt1PSBkv993sqqoW13VHYlAbA7Ix0gPrUWN0Trkkv
            +aLVnyvjkuZ6tD8vS8Tya7l/unBXt+n8ZAbAVIoZGbMSPaY4HjB4MuHQR9I
            Kc4iMIOwX1KzXpnDLVtMfyU+BwA47sydzryfhiZHa4M8FCbM5kKY+U/DBKbjKfGD9P
            QQiAfC4zn1uFMG+vm+V06bad/Zi+rn6rrJ20xWt4P49h6fiqw8rnxyo/8s74lQ
            KwEuZyTXP6CQf/9kb8b1MvQ">             <input type="hidden" name="TermUrl" value="http://localhost:40405/test/3DTermURL.aspx?PayID=dc67820e15f049c9b6c1f0420729da8a&TransID=20180524-162741-084&MID=gustav">             <input type="hidden" name="MD" value="Optional merchant session data">         </form>     </body> </html>
value="Optional merchant session data" />

Sobald die Authentisierung abgeschlossen oder vom Karteninhaber abgebrochen worden ist, leitet der ACS den Karteninhaber über seinen Browser zur TermURL weiter, wie sie bei der anfänglichen Zahlungsanfrage angegeben ist.

Hinweis: Die Zahler-Authentisierungs-Antwort (PaRes) wird mittels HTTP POST Methode übertragen, während MID, PayID und TransID im HTTP-Anfrage-String gesendet werden (d.h. HTTP GET).

Zur TermURL übertragene Datenelemente

Autorisierung

Um eine mit 3DS 1.0 authentisierte Zahlung zu autorisieren, müssen die Parameter der nachfolgenden Tabelle unverschlüsselt per POST an

https://www.computop-paygate.com/direct3d.aspx

übermittelt werden. Die Antwort ist immer verschlüsselt (Len + Data).

Anfrage-Elemente

Antwort-Elemente

2.2.1.1 Felder der Payer Authentication Request

Das Nachrichtenfeld Payer Authentication Request (PAReq) ist ein vom Merchant Server Plug-in (MPI) der First Cash Solution konstruiertes Datenelement.

Das MPI baut die XML PAReq im kanonischen Format gemäß DTD. Es führt den XML-Stream zu einem RFC1951-konformen Kompressor, der einen RFC1950-konformen Ausgangs-Stream erzeugt, der Base64-codiert wird.

Für Informatiosnzwecke sind die PAReq Datenelemente in der nahstehenden Tabelle aufgeführt.
 

PAReq

2.3 Stille Auftragserteilung (PayNow)

Überblick
Eine Stille Auftragserteilung oder Direkte Erteilung ist eine Übertragunsmethode, bei der Formulardaten von einer Händler-Webseite direkt an einen Server eines Dritten abgeschickt werden. Das wird üblicherweise durch das Attribut form action erreicht, welches die URL angibt, wohin die Daten zu senden sind.

Hinweis: Sensible Daten wie Kartendetails können innerhalb der Händler-Webseite erfasst werden, ohne dass diese vom Server des Händlers verarbeitet werden, da der POST still übermittelt wird. Die URL im 1cs Online Bezahlsystem für den Empfang von Anfragen der Stillen Auftragserteilung wird als PayNow bezeichnet.

<form action="../payNow.aspx" method="post">

Dieser Ansatz ist sehr ähnlich zu den von der First Cash Solution gehosteteten Zahlungsformularen und lässt dem Händler die volle Kontrolle über den Bezahlvorgang, da alle Elemente der Webseite vom Server des Händlers bereitgestellt werden.

Hinweis: Händler, die Kartentransaktionen mit dem Modell der stillen Erteilung verarbeiten, müssen den Fragebogen PCI DSS Self-Assessment Questionnaire (SAQ) A-EP einreichen. Dieser SAQ ist umfangreicher und kann daher mehr Zeit und Ressourcen erfordern als der SAQ A für Händler, die gehostete Zahlungsseiten verwenden. Händler sollten sich jedoch immer mit ihrem Acquirer beraten, um das Maß der erforderlichen Compliance zu beurteilen und dabei die PCI DSS Richtlinien beachten. Das wirkt sich nicht auf die Verwendung von Pseudokartennummern aus, was ohne Einreichung des SAQ Fragebogens möglich ist.

Hinweis zum Cookie-/Session Handling: Bitte beachten Sie, dass einige Browser beim Rücksprung zu Ihrem Shop erforderliche Cookies blockieren könnten. Hier finden Sie weitere Informationen und verschiedene Lösungsansätze.

Sequenzdiagramm

Zahlungsanfrage

Bitte übermitteln Sie die folgenden Parameter für Kartenzahlungen über einen HTTP POST Aufruf an:

https://www.computop-paygate.com/payssl.aspx.

Formularelemente

Das 1cs Online Bezahlsystem wird weiterhin die alten Formulardatenfelder unterstützen, die derzeit verwendet werden.
 

Daten

Beispiel HTML-Formular

BASEURL= https://www.computop-paygate.com/schemas
 

<!DOCTYPE html>

<html>

    <head>

        <title>Merchant Checkout</title>

    </head>

    <body>

        <form name="card form" action="https://www.computop-paygate.com/payNow.aspx" method="post">

            <input type="hidden" name="MerchantID" value="MerchantID">

            <input type="hidden" name="Len" value="Length of the Blowfish encrypted data">

            <input type="hidden" name="Data" value="Blowfish encrypted data">

            Cardholder:

            <input type="text" name="cardholder"><br>

            Card number:

            <input type="text" name="number"><br>

            Expiry date:

            <input type="text" name="expiryDate"><br>

            CVV2:

            <input type="text" name="securityCode"><br>

            Card brand:

            <input type="text" name="brand"><br>

            <input type="submit" value="Submit">

        </form>

    </body>

</html>

Wenn die Zahlung abgeschlossen ist, sendet das 1cs Online Bezahlsystem eine Benachrichtigung an den Händler-Server (d.h. URLNotify) und leitet den Browser dementsprechend an URLSuccess oder URLFailure weiter.

Die in der folgenden Tabelle genannten per Blowfish verschlüsselten Datenelemente werden vom 1cs Online Bezahlsystem per HTTP POST Anfragemethode an URLNotify und URLSuccess/URLFailure übertragen.

Hinweis: Bitte beachten Sie, dass der Aufruf der URLSuccess oder URLFailure bei einem Fallback zu 3-D Secure 1.0 mit GET stattfindet. Ihre Systeme sollten daher Parameter sowohl per GET als auch per POST entgegennehmen können.
 

HTTP POST an URLSuccess / URLFailure / URLNotify

3 JSON Objekte

Wichtig: Beachten Sie bitte, dass alle JSON-Objekte Base64-codiert sein müssen.

Das Paygate validiert JSON-Objekte bei allen Requests, die den Parameter “MsgVer=2.0” enthalten. Dies passiert unabhängig davon, ob auch wirklich 3DSecure2 auf Ihrer MerchantID aktiv ist.

Bitte stellen Sie sicher, dass keine leeren Parameter oder Objekte gesendet werden. Das Paygate geht in solchen Fällen von einem Fehler aus und lehnt die Transaktion ab.

4 Wichtige Hinweise

4.1 3DS Authentication Hosting

Das 1cs Online Bezahlsystem unterstützt auch Szenarien, in denen Händler den 3DS Server (3DS 2.0) beziehungsweise 3DS MPI (3DS 1.0) der First Cash Solution als eine gehostete Lösung verwenden wollen und die Transaktion nachfolgend über eine Integration mit einer Drittpartei autorisieren wollen.

Hinweis: Bitte wenden Sie sich an den First Cash Solution Support und bitten um die nötigen Konfigurationsänderungen an Ihrer Merchant ID.

Authentication Hosting alleine wird unterstützt für

• Gehostete Formulare (paySSL) und
• Server-2-Server Integrationen

Alle zwischen der Händlerumgebung und dem 1cs Online Bezahlsystem ausgetauschten Nachrichten, Sequenzen und Datenelemente bleiben die gleichen wie für normale Zahlungen, außer dass das 1cs Online Bezahlsystem die Transaktion nicht mit einem Acquirer autorisiert. Die für nachfolgende Autorisierungen nötigen Authentisierungsdaten (z.B. authenticationValue und eci) werden über threeDSData und resultsResponse (nur Challenge-Abläufe) bereitgestellt.

Nachfolgenden sehen Sie eine Beispiel einer Zahlungsbenachrichtigung für eine erfolgreiche Transaktion nur zur Authentisierung:

MID=ACME&

PayID=9e944d5d56f3461da39380a666d346d1&

TransID=V3DSTestSuite_001&

XID=334ce1701a5b444db4e2296a680ae330& Code=00000000& Status=OK& Description=Authentication completed correctly& card= {     "number": "400001XXXXXX8323",     "brand": "VISA",     "country": {         "countryName": "United Kingdom of Great Britain and Northern Ireland",         "countryA2": "GB",         "countryA3": "GBR",         "countryNumber": "826"     } }& threedsdata= {     "authenticationStatus":true,     "acsProtocolVersion":"2.1.0",     "authenticationValue":"JAmi21makAifmwqo2120cjq1AAA=",     "eci":"05",     "threeDSServerTransID":"9e944d5d-56f3-461d-a393-80a666d346d1" }& resultsResponse= {     "threeDSServerTransID":"9e944d5d-56f3-461d-a393-80a666d346d1",     "acsTransID":"1e43b52f-3623-4e5d-8917-41c5c15b7218",     "acsRenderingType":{         "acsInterface":"native",         "acsUiTemplate":"text"     },     "authenticationType":"02",     "authenticationValue":"JAmi21makAifmwqo2120cjq1AAA=",     "challengeCancel":"",     "dsTransID":"c626e8a0-f2ba-42b3-aa6d-620658421f3a",     "eci":"05",     "interactionCounter":"01",     "messageCategory":"01",     "messageExtension":"",     "messageVersion":"2.1.0",     "sdkTransID":"",     "transStatus":"Y",     "transStatusReason":"" }& MAC=AE6E011454EB54858006007D73D766B7A0306AB8FD925D08C3BF222D4A366123

4.2 Amazon Payments MFA

Überblick

Um zur PSD2 konform zu sein, führt Amazon Pay die SCA für seine Transaktionen ein.

Das SCA-Upgrade führt einen “Bestätigungs-Ablauf” ein, um die Multi-Faktor-Authentisierung (MFA) durchzuführen, wenn diese erforderlich ist.

Wenn eine MFA erforderlich ist, zeigt der Bestätigungs-Ablauf dem Käufer die MFA-Challenge des Kreditkartenherausgebers. Nachdem der Käufder mit dem Bestätigungs-Ablauf (beispielsweise die MFA-Challange abgeschlossen hat) interagiert hat, wird der Käufer auf die Seite des Händlers zurückgeleitet (beispeilsweise die Seite der Bestellbestätiung).

Aktualisieren Sie bite den AmazonPay-Kassenablauf, nachdem der Käufer seinen Bestellabschluss ausgelöst hat und bevor Sie die Autorisierung aufrufen.

Änderungen

Neue JavaScript-Funktion confirmationFlow()

Gemäß MFA ist es nach der erfolgreichen Bestätigung einer Bestellung notwendig, einen neuen Aufruf zu beginnen, den Bestätigungs-Ablauf (ConfirmationFlow).

Zum Start des Arbeitsablaufes

• führen Sie bitte eine Bestätigung für die Bestellung am 1cs Online Bezahlsystem aus, nachdem Sie ein Ergebnis erhalten haben
• starten Sie den Bestätigungsablauf im Falle eines Erfolgs mit “confirmationFlow.success()”
• im Falle eins Fehlers beendet “confirmationFlow.error()” den Prozess.

Die Implementierung des neuen Javascript-Aufrufs ist nachstehend gezeigt. Dieser wurde für unsere Händler optimiert.

Hinweis: Diese Aktion sollte durch einen Klick auf die Schaltfläche “Jetzt kaufen” (“Buy Now”) ausgelöst werden!

function confirmationFlow()

{     // resultCode vom 1cs-Aufruf AmazonAPA.aspx, EventToken: COD erhalten     var resultCode_Computop = Paygate call to get the ResultCode from the Confirm, AP call COD or SCO.     // Ihre AmoazonSellerID / AmazonMerchantID     var amazonSellerId = 'Your_SellerID';     // Vom Adress-Widget erzeugte Amazon Bestellreferenz     var orderReferenceId = 'Your_Order_Reference';     //Bestätigungs-Ablauf initiieren     OffAmazonPayments.initConfirmationFlow(amazonSellerId, orderReferenceId, function (confirmationFlow)         {             if(resultCode_Computop = '00000000')             {                 confirmationFlow.success();             }             else             {                 confirmationFlow.error();             }         }     ); }

Beachten Sie für weitere Hilfe bitte auch https://developer.amazon.com/de/docs/eu/amazon-pay-onetime/sca-upgrade.html.

Der Händler sollte die Weiterleitung von der First Cash Solution (URLSuccess / URLFailure) mit der Ergebnis der MFA-Challenge handhaben können.

URLSuccess / URLFailure für Aufrufe ConfirmOrderDetails (COD) und SetOrderDetails und ConfirmOrder (SCO)

Bei “Order Now” muss der Händler die URLSuccess und URLFailure in den Aufrufen (EventToken=SCO | COD) senden, weil die Weiterleistung nach der MFA-Challange ausgeführt wird.

Nach “Order Now” wird Confirm (EventToken=SCO | COD) für die Zahlung ausgeführt und dann erfolgt die Weiterleitung zur Challenge mit dem oben gezeigten JavaScript-Code.

AmazonAPA.aspx

Die folgenden Ereignisaufrufe am 1cs Online Bezahlsystem sind von den Ädnerungen betroffen. Achten Sie bitte darauf, die neue Parameter mit einzubeziehen.

Benutzer-Ablauf und Sequenzen

Ablauf

1.     Klick auf die Schaltfläche AmazonPay zum Anmelden

2.     wählt eine Adresse im Widget

3.     wählt die Zahlungsmethode im Widget

4.     bestätigt die Bestellung

Option 1: SCO

Das ist die empfohlene Option.

Option 2: SOD und COD

1.     Der erste Aufruf dient dem Bestätigungs-Ablauf – damit kann AmazonPay die MFA handhaben, falls erforderlich. Hier ist confirmationFlow Fehler/Erfolg zu setzen. Referenz zur Datei Amazon Pay Widgets.js, die bereits für andere Widgets verwendet wird.

2.     Aufruf SetOrderDetails (SOD) einschließlich OrderTotal

3.     Aufruf ConfirmOrderDetails (COD) setzt Parameter URLSuccess/URLFailure mit einem Wert returnURL

Hinweis: Wie oben gezeigt, empfehlen wir den Aufruf SCO als einzelnen Schritt zum Festlegen und Bestätigen der Bestelldetails.

Option 3: MFA-Fehler

Hinweis: Wir empfehlen unseren Händlern, in diesen Fällen nur mit dem 1cs Online Bezahlsystem-Status oder 1cs Online Bezahlsystem-Antwortcode zu arbeiten.

Status => Aufgegeben:

Status => Fehler:

1.     Falls der Kunde die Challenge aufgibt oder daran scheitert, wird der Kunde zur URLFailure weitergeleitet.

2.     Abmelden des Benutzers.

3.     Abbrechen der Bestellung durch Aufruf von “Reverse.aspx”

Abbrechen der Bestellung durch Aufruf von “Reverse.aspx“

Um eine komplette Bestellung mit Amazon Pay mit der Funktion „CancelOrderReference“ zu stornieren, verwenden SIe bitte

https://www.computop-paygate.com/reverse.aspx

Weitere ausführliche Informationen dazu liefert die offizielle Online Bezahlsystem-Dokumentation hier: Amazon Pay Manual

Status

Wenn die MFA erfolgreich ist, erfolgt die Weiterleitung zu URLSuccess, Anderenfalls erfolgt die Weiterleitung zu URLFailure.

Hinweis: Die Amazon Authentisierungs-Antwort wird dem Shop über das 1cs Online Bezahlsystem im Antwortparameter amazonstatus zurückgegeben.

Beispiel: amazonstatus=Abandoned

Im Amazon SCA Handbuch Punkt 3 (Konsistenz des Betrags)

Der Wert AuthorizationAmount (im Schritt Autorisierung) muss immer zum Wert CaptureAmount (im Schritt Buchung) passen.

Falls nicht, wird die Antwort auf die Buchungs-Anfrage asynchron behandelt; der Wert State im Objekt Capture wird auf Pending gesetzt und kann nicht in Echtzeit verarbeitet werden, selbst wenn er innerhalb von sieben Tagen ab dem Aufruf der Autorisierung erfolgt!

4.3 Dynamische Rechnungs-Deskriptoren

Allgemeine Anforderungen

Das Element billingDescriptor dient zum Überschreiben des Händlernamens, der gegebenenfalls an die Bank des Karteninhabers gesendet wird.

Der Händlername ist der wichtigste Faktor für den Karteninhaber, um eine üblicherweise auf seinem Kontoauszug gedruckte Transaktion zu erkennen. Er sollte den üblichen Namen einer Firma (d.h. der Name ‘handelt als’ (DBA)) anstatt der juristischen Bezeichnung enthalten, woran der Karteninhaber den Händler erkennen würde, um Verwechslungen zu vermeiden und Anfragen nach Kopien zu minimieren.

Standardmäßig leitet Acquire den Händlernamen weiter, den sie im Händlerkonto hinterlegt haben. Beachten Sie bitte, dass die Kartenorganisationen strenge Regeln für Händlernamen auf Kontoauszügen festgelegt haben.

Es gibt jedoch eine Reihe spezifischer Ausnahmen, wo abhängig von Anwendungsfall und Branche (z.B. Fluglinien, Bahnlinien, Autovermietungen, Tankstellen usw.) ergänzende Daten zum DBA-Namen hinzugefügt werden können.

Formatierung des Händlernamens

Die Autorisierungs- und Clearing-Systeme der Kartenorganisationen bieten unterschiedlichen Größen für Händlernamen an. Der kleinste gemeinsame Nenner sind 22 Zeichen. Daher passen Händlernamen mit mehr als 22 Zeichen nicht in das Feld für den Händlernamen und müssen in einer Art und Weise abgekürzt werden, die für den Karteninhaber noch erkennbar bleibt.

Kauf von Waren oder Dienstleistungen

Für normale Käufe von Waren oder Dienstleistungen können zusätzliche Informationen hinter dem Händlernamen und einem Sternchen (*) eingefügt werden, um eine Bestellnummer, Referenznummer oder anderen Angaben zur Identifikation einer Transaktion anzugeben.

Für Autovermiter und Hotelhändler darf der Händlername nicht gekürzt werden, um ergänzende Informationen im Feld des Händlernamens unterzubringen.

No-Show-Transaktionen

Sie dürfen nach dem Händlernamen auch die Wörter “NO SHOW” enthalten.

Kauf eines Flug-Tickets (oder Passagier-Eisenbahnfahrkarte in Region USA)

Alle folgenden Dinge müssen enthalen sein:

• Ein abgekürzter Name der Fluglinie (oder US Eisenbahn) in den ersten 11 oder 12 Zeichen
• Gegebenenfalls ein Leerzeichen an Position 12
• Ab Position 13 eine Kennung für das Flug- (oder US Eisenbahn-) Ticket

4.4 Hinterlegte Zugangsdaten

Wann immer Karten-Zugangsdaten (d.h. Name des Karteninhabers, Kartennummer/Token und/oder Ablaufdatum) für eine zukünftige Verwendung gespeichert werden, ist eine vorherige Zustimmung durch den Karteninhaber erforderlich.

Während der Einrichtung eines solchen Mandats sollte der Karteninhaber über den genauen Grund für die Speicherung der Zugangsdaten beim Händler informiert werden. Das bedeutet, eine Autorisierungsanfrage zur Einrichtung eines Mandats für hinterlegte Zugangsdaten muss auch die Art der möglichen nachfolgenden Transaktionen angeben.

Diese nachfolgenden Transaktionen mit hinterlegten Zahlungsdaten, denen der Karteninhaber zugestimmt hat, werden ganz allgemein in vom Kunden ausgelöste Transaktionen (Customer Initiated Transactions / CITs) und vom Händler ausgelöste Transaktionen (Merchant Initiated Transactions / MITs) kategorisiert.

Hinweis: Der maßgebliche Unterschied zwischen CITs und MITs ist, dass Letztere außerhalb des Geltungsbereiches der RTS für die SCA sind. Das liegt daran, dass der Karteninhaber regelmäß nicht in einer Sitzung ist und daher praktisch für eine Authentisierung nicht zur Verfügung steht.

Es gibt verschiedene Anwendungsfälle für MITs, die allgemein in Transaktionen gemäß einer bestimmten Branchenpraxis sowie ständige Anweisungen eingeteilt werden können.

Im 1cs Online Bezahlsystem sind CITs und MITs für ständige Anweisungen durch das JSON-Objekt credentialOnFile markiert.

Hinweis: Beachten Sie bitte, dass alle außerplanmäßigen MIT-Transaktionen in 3DS 2.0 nicht unterstützt werden und daher direkt zur Autorisierung gesendet werden, ohne in die 1cs Online Bezahlsystem 3DS Sequenz zu gelangen.

Wiederkehrende MIT-Transaktionen werden jedoch über das 3DS 2.0 Protokoll zum Issuer gesendet, um bestmögliche Akzeptanzraten zu garantieren.

  Hinweis: Beachten Sie bitte, dass Sie mit jeder anfänglichen CIT, welche ein Mandat für nachfolgenden MITs einrichtet, eine schemeReferenceID erhalten, die bei nachfolgenden Transaktionen übergeben werden muss, um die Sequnz zu verknüpfen.

Nachdem die SCA am 14. September 2019 verpflichtend geworden ist, können durch Zustimmung vom Karteninhaber gedeckte MITs weiterhin ohne eine schemeReferenceID verarbeitet werden, wenn die Mandate dafür vor diesem Datum eingerichtet wurde (d.h. Bestandsschutz). Übergeben Sie bitte keine Platzhalterwerte. Das 1cs Online Bezahlsystem verwendet automatisch entsprechende Werte im Autorisierungs-Protokoll, um den sogenannten Bestandsschutz anzuzeigen.

Vom Karteninhaber ausgelöste Transaktion (Cardholder Initiated Transaction / CIT)
Eine vom Karteninhaber ausgelöste Transaktion ist jede Transaktion, an der der Karteninhaber aktiv teilnimmt. Das kann entweder an einem Terminal in einem Geschäft oder beim Bezahlvorgang online sein oder mit hinterlegten Zahlungsdaten, bei denen der Karteninhaber zuvor der Speicherung beim Händler zugestimmt hat.

Vom Händler ausgelöste Transaktion (Merchant Initiated Transaction / MIT)
Jede Transaktion, die sich auf eine vorherige vom Karteninhaber ausgelöste Transaktion bezieht, aber ohne aktive Teilnahme des Karteninhabers durchgeführt wird. Im Ergebnis kann der Händler keine Validierung durch den Karteninhaber ausführen. In allen Fällen muss sich eine vom Händler ausgelöste Transaktion auf die originale Interaktion mit dem Karteninhaber beziehen.

4.4.1 Echtzeit-Service über mobile App mit Zahlung nach Service-Abschluss

In vielen Szenarien der gemeinsamen Nutzung  wie Car-Sharing oder Bike-Sharing ist das Mobilgerät des Kunden ein entscheidender Bestandteil für die Dienstleistungserbringung und das Zahlungssystem. Kartenzugangsdaten werden für optimale Benutzererfahrung  häufig im Konto des Karteninhabers beim Dienstleister gespeichert.

Die Seqeunz der auszuführenden Schritte ist in den nachfolgenen Diagramm skizziert.

Hinzufügen der Karte als Teil einer nicht zahlungswirksamen Transaktion (NPA)

Hinweis: Falls das Hinzufügen der Karte (Card Add) NICHT Teil einer Zahlungstransaktion ist, muss obligatorisch eine Kontoverifizierung durchgeführt werden (siehe AccVerify).

Hinzufügen der Karte als Teil einer Zahlungstransaktion

Service-Bereitstellung

Hinweis: Außerplanmäßige MITs mit hinterlegten Zugangsdaten (UCOF) sind nicht für Szenarien anwendbar, wo der Karteninhaber zum Zeitpunkt des Service-Abschlusses in einer aktiven Sitzung und daher für eine Authentisierung verfügbar ist. Das ist beispielsweise regelmäßig der Fall bei Apps für Car-Sharing oder den Ruf einer Fahrt.

Hinweis: Falls der geschätzte Betrag geringer als der endgültige Betrag ist, ist es empfehlenswert, eine vollständige Stornierung des ursprünglich autorisierten Betrags auszuführen und eine neue Autorisierung für den endgültigen Betrag einzureichen.

Amount

Hinzufügen einer Karte (Card Add)

Ein Nullwert oder ein geschätzter Wert. Beachten Sie bitte, dass der Betrag normalerweise dem Karteninhaber während der Authentisierungs-Challange angezeigt wird und daher im Erwartungsbereich des Kunden liegen sollte.

Service-Bereitstellung

Der Betrag der Autorisierungsanfrage sollte ein Schätzwert für die Service-Bereitstellung sein und im Erwartungsbereich des Kunden liegen. Nach Bereitstellung der Dienstleistung können inkrementelle Autorisierungen erfolgen, bis der endgültige Betrag erfasst wurde.

credentialOnFile

Hinzufügen einer Karte (Card Add)

Das UCOF-Flag wird übermittelt, um ein Mandat zum Speichern von Zugangsdaten einzurichten und die anfängliche schemeReferenceID zu erhalten. Der Kartenherausgeber ist verpflichtet, währnd der Authentisierung eine Verstärkung auszuführen.

{     "type": {         "unscheduled": "CIT"     },     "initialPayment": true }

Service-Bereitstellung

Das CIT-Flag wird übermittelt, um UCOF-Transaktionen ohnen Kartenprüfnummer zu ermöglichen.

{     "type": {         "unscheduled": "CIT"     },     "initialPayment": false }

AccVerify

Alle Transaktionen zum Hinzufügen von Karten (Card Adds), die nicht Teil einer Zahlungstransaktion sind, erfordern eine Konto-Verifizierung.

4.4.2 Verzögerte Lieferung

In manchen Fällen kann ein Händler eine Bestellung von einem Kunden erhalten, die nicht innerhalb der Haltedauer einer Autorisierung von 7 (d.a. abschließende Autorisierung) beziehungsweise 30 Tagen (d.h. Vorautorisierung) lieferbar ist.

Das ist üblicherweise der Fall für:

• individuell konfigurierte Produkte wie Fahrräder, Computer-Server, Möbel oder anderer angefertigte Artikel außerhalb der Standardspezifikationen, die im Auftrag gebaut werden (BTO)
• Vorbestellungen kommender Produkte wie neuer Telefonmodelle
• ausverkaufte Artikel
  

Hinweis: Beachten Sie bitte, falls die Autorisierung deutlich später als die anfängliche Bestellung erfolgt, ist es eine gute Praxis, dem Karteninhaber ein paar Tage vor der Autorisierung eine Erinnerung zu schicken, um die Wahrscheinlichkeit zu erhöhen, dass die Gelder verfügbar sind.

Um eine mögliche Haftungsverschiebung der 3DS-Authentisierung zu erhalten, ist es empfehlenswert, zwei Schritte im Prozess zu befolgen:

1.     Anfängliches Hinzufügen der Karte als Teil einer nicht zahlungswirksamen Transaktion (NPA)

2.     Nachfolgende außerplanmäßige COF MIT mit Authentisierungsdaten aus dem Schritt 1 (UCOF MIT)

Anfängliches Hinzufügen der Karte als Teil einer nicht zahlungswirksamen Transaktion (NPA)

Um das Mandat für eine hinterlegte Karte einzurichten und den karteninhaber zu authentisieren, übermitteln Sie bitte eine Autorisierungsanfrage an das 1cs Online Bezahlsystem.

Betrag

Der angegebene Amount wird innerhalb des 3DS Authensierungsprozesses verwendet und dem Kunden bei der Challenge des Karteninhabers angezeigt. Es sollte der endgültige Betrag sein, der dem Kunden belastet wird, nachdem die Bestellung ausgeführt ist, da dies zugleich der Maximalbetrag für die Haftungsverscheibung ist.

COF

Die Challenge des Karteninhabers wird durch den Indikator credentialOnFile erzwungen, der die Transaktion als Einrichtung eines Mandats für nachfolgenden MITs kennzeichnet.

Konto-Verifizierung

Um eine sofortige Autorisierung des vollen Bestellbetrags auf dem Konto des Karteninhabers zu unterdrücken und die Regeln des Kartensystems für Transaktionen zum Hinzufügen einer Karte einzuhalten, ist es erforderlich, eine Konto-Verifizierung (alias eine Nullwert-Autorisierung) durchzuführen, indem der Parameter AccVerify mit dem Wert ‘Yes’ übermittelt wird.

Das JSON-Objekt threeDSData in der Antwort enthält zusammen mit dem bedingten (d.h. Challenge-Ablauf) JSON-Objekt resultsResponse die nötigen Authentisierungsdaten für die nachfolgende MIT Autorisierungsanfrage, sobald die Bestellung lieferbereit ist.

UCOF MIT

Sobald das Produkt oder die Dienstleistung verfügbar wird und lieferbereit ist oder zu jedem anderem Datum, dass eine Autorisierungsgenehmigung auf dem Konto des Karteninhabers ermöglicht, übermitteln Sie bitte eine als UCOF MIT markierte Autorisierungsanfrage in Kombination mit den Authentisierungsdaten, die Sie bei der anfänglichen Transaktion zur COF-Einrichtung erhalten haben.

COF

Die Markierung credentialOnFile der MIT hindert den Issuer daran, eine Challenge des Karteninhabers anzufordern und verknüpft die Transaktion mittels der schemeReferenceID mit der anfänglichen COF-Transaktion.

threeDSData

Die Haftungsabsicherung lässt such durch Übermitteln des Objekts threeDSData einrichten, dass die Authentisierungsdaten der anfänglichen COF CIT Transaktion enthält.

4.5 Konto-Verifizierung

Eine auch als Nullwert-Aotorisierung bekannte Konto-Verifizierung ist eine Anfrage zur Prüfung, ob ein Kartenkonto in gutem Ansehen ist (d.h. die Karte ist nicht gestohlen und das Kartenkonto kann für Zahlungen verwendet werden).

3DS und Konto-Verifizierung

Beachten Sie bitte, dass bei einer angefragten Konto-Verifizierung (d.h. AccVerify=Yes) in Kombination mit 3DS die Autorisierung stets mit einem Nullwert ausgeführt wird. Die Authentisierung wird hingegen mit dem Betrag ausgeführt, der dem im Feld Amount übermittelten Betrag entspricht. Wenn der übermittelte Amount Null ist, erfolgt die zugehörige Haftungsumkehr ebenfalls für einen Nullwert.

Hinterlegte Zugangsdaten

Beachten Sie bitte, dass nicht zahlungswirksame Transaktionen, die credentialOnFile (alias Card Add) hinterlegen, eine Konto-Verifizierung erfordern.

Unabhängige Konto-Verifizierung

Wenn Sie eine Konto-Verifizierung ohne Hinterlegung einer Karte anfordern, wird das Datenelement browserInfo optional für Server-2-Server und Silent Order Post Integrationen. Andere bedingte Datenelemente sind eventuell auch nicht anwendbar.

4.6 Mehrparteien-E-Commerce / Agenten-Modell

In manchen Szenarien werden Daten des Karteninhabers durch dritte Webseiten im Namen eines oder mehrerer Händler erfasst und verarbeitet (z.B. Authentisierung und Autorisierung). Der Betreiber der dritten Webseite wird normalerweise als ein Agent bezeichnet. Weil der Karteninhaber mit der Umgebung des Agenten interagiert, ist es die Pflicht des Agenten, die Zahlungs-Authentisierung durchzuführen.

Die Anforderungen für Modelle der Agenten-Verarbeitung sind in den folgenden Abschnitten beschrieben.

VISA

Händler im Reise- und Gastgewerbe

Szenario 1: Authentisierung erfolgt durch einen Reise-Agenten im Namen eines einzelnen Händlers

• Wenn der Reise-Agent die Authentisierung im Namen eines einzelnen Händlers zum Zeitpunkt der Buchung erleichtert, ist der Prozess folgender:
• Der Reise-Agent informiert den Karteninhaber über entsprechende AGB und befolgt andere Anforderungen  im Zusammenhang mit dem möglichen zukünftigen MIT-Typ, den der Händler möglicherweise verarbeiten muss
• Der Reise-Agent authentisiert die Transaktion über den gesamten Buchungsbetrag (Name zur Händlerbeschreibung = “Name des Reise-Agenten * Name des Händlers” )
• Der Reise-Agent kann optional eine Konto-Verifizierung durchführen, um die Gültigkeit der Karte zu prüfen, bevor er die Kartendetails zum Händler weiterleitet (Falls eine Konto-Verifizierung ausgeführt wird, darf sie nicht dden CAVV enthalten, da dies vom Endhändler gefordert wird. )
• Der Reise-Agent leitet die Authentisierungsdaten zum Händler weiter
• Der Händler übermittelt eine normale Autorisierungsanfrage an das 1cs Online Bezahlsystem einschließlich der erforderlichen Daten im JSON-Objekt threeDSData:request.

Falls der Händler die Zahlung später ausführen möchte, sollte er:

1.     innerhalb von 24 Stunden eine Konto-Verifizierung(d.h. AccVerify=Yes)mit den vom Agenten empfangenen Authentisierungsdaten durchführen.

2.     wenn der Betrag nachfolgend fällig ist, eine als MIT gekennzeichnete Autorisierung senden einschließlich der schemeReferenceID von der vorherigen Konto-Verifizierung.

Szenario 2: Authentisierung erfolgt durch einen Reise-Agenten im Namen mehrerer anderer Händler

Dieses Szenario betrifft den Fall, wenn eine Kunde online eine Reise-Reservierung über einen Reise-Agenten vornimmt, die Dienstleistungen von mehreren Händlern umfasst.

• Der Reise-Agent informiert den Karteninhaber über entsprechende AGB und befolgt andere Anforderungen  im Zusammenhang mit dem möglichen zukünftigen MIT-Typ, den der Händler möglicherweise verarbeiten muss
• Der Reise-Agent authentisiertdann die Transaktion über den gesamten Buchungsbetrag (Name zur Händlerbeschreibung = “Name des Reise-Agenten” )
• Eine zusätzliche 3DS 3RI Authentisierungsanfrageist erforderlich, um die CAVVs für jeden weiteren Händler bereitzustellen, der eine Autorisierung ausführen wird
• Der Reise-Agent übermittelt die Authentisierungsdaten an den Händler
• Der Händler übermittelt eine normale Autorosierungsanfrage an das 1cs Online Bezahlsystem einschließlich der erforderlichen Daten im JSON-Objekt threeDSData:request.

Falls der Händler die Zahlung später ausführen möchte, sollte er:

1.     innerhalb von 24 Stunden eine Nullwert Konto-Verifizierung mit den vom Agenten erhalten Authentisierungswerten durchführen

2.     wenn der Betrag nachfolgend fällig ist, eine als MIT gekennzeichnete Autorisierung senden einschließlich der schemeReferenceID von der vorherigen Konto-Verifizierung.

Andere Händler

Szenario 3: Authentisierte CIT vom Agenten und nachfolgende MIT-Transaktion vom Händler

Das ist der Fall, wenn der Agent die Authenrisierung ausführt und nachfolgend die VISA CAVV für seine eigene Autorisierung nutzt. In einem solchen Fall, wo eder Agent bereits die CAVV nutzt und möglicherweise nicht die Funktion 3DS/3RI nutzen kann (um eine neue CVV für den Händler zu haben), kann er dem Händler nur die schemeReferenceID der anfänglichen CIT zusammen mit der Nutzlast bereitstellen, sodass der Händler seine Autorisierungen gekennzeichnet als eine nachfolgende MIT (d.h UCOF, verzögerte Autoriserung) auslösen kann.

Nennenswerte Unterschiede zwischen VISA und Mastercard bei solchen Anwendungsfällen sind:

a) Authentisierungswert (CAVV/AAV)

Bei VISA muss der Agent, der die Authentisierung in Namen mehrerer Händler ausführt, durch die 3DS/3RI Anfrage (nur möglich mit Version EMV 3DS 2.2), um jedem Händler getrennt separate CAVV-Werter bereitzustellen.
Auf der anderen Seite sagt MasterCard, dass beim Agenten-Modell, wo eine einzige Authentisierung mit mehreren Autorisierungen verknüpft ist, der gleiche Authentisierungs-Code/AVV für mehrere Transaktionen verwendet werden kann.

b) schemeReferenceID

Im dritten Szenario kann der Agent dem Händler zumsammen mti der Nutzlast nur die ‘schemeReferenceID’ aus der anfänglichen CIT ohne Authentisierungsdaten derart bereitstellen, dass der Händler nachfolgende MIT-Transaktionen auslösen kann, die sich auf die anfängliche Einrichtung beziehen.
Für VISA wird die “schemeRefernceID” (transactionID) normalerweise als einzelner Antwort-Parameter bereitgestellt, währen die “schemeReferenceID” bei Mastercard eine Verknüpfung von Feldern ist wie: *(SettlementDate+FinancialNetworkCode& BanknetReference).

–   SettlementDate -> n..4
–   FinancialNetworkCode -> an..3
–   BanknetReference -> an..9

* Agenten, welche dieses Szenario (mit CIT/MIT) verwenden, wird empfohlen, ihren Händlern die erforderlichen MasterCard-Referenzdaten bereitzustellen, sodass der Händler diese nachfolgend bei MIT-Transaktionen als “schemeReferenceID” an das 1cs Online Bezahlsystem übermitteln kann.

Bitte beachten Sie auch, dass der obige Ansatz der Behandlung aller Szenarien nur als eine Empfehlung dient. Daher können Händler und Acquirer alternative Optionen wählen, die ihr Geschäftsmodell ergänzen, solange diese zu den Grundprinzipien der PSD2 SCA konform bleiben.

4.7 Nicht zahlungswirksame Authentisierungen für Card Add (Hinzufügen von Kartendaten)

Verwenden Sie bitte AccVerify, um eine Konto-Verifizierung anzufordern, wenn Sie ohne Zahlung eine Karte zu COF (Credential on file – hinterlegte Kartendaten) hinzufügen wollen.

Nicht zahlungswirksame Authentisierungen für Transaktionen zum Hinzufügen von Kartendaten (Card Add) erfordern immer eine verstärkte Authentisierung (d.h. Challenge).

Eine Bereitstellung wie Card Add ist allgemein zu betrachten als eine
Aktion über einen Remote-Kanal, die ein Risiko für Zahlungsbetrug oder anderen Missbrauch darstellen kann
gemäß Artikel 97(1)(C) PSD2. Für diese Aktionen sind keine Ausnahmen vorgesehen.

Wenn eine Karte zu COF hinzugefügt und gleichzeitig eine Zahlung angefordert wird, ist nur eine starke Kundenauthentifizierung (SCA) erforderlich.

4.8 Obligatorisch und bedingt erforderliche Datenelemente für EMV 3DS

Beachten SIe bitte, dass einige als bedingt erforderlichen Datenelemente in EMV 3DS weiter spezifiziert sind als:

Erforderlich, sofern nicht Markt- oder regionale Mandate das Senden dieser Informationen beschränken.

Das betrifft beispielsweise Datenelemente wie email, phone number oder billing address.

Unter Berücksichtigung des rechtlichen Umfelds und abhängig vom Issuer (oder exakter vom Anbieter des Access Control Servers (ACS) des Issuers) kann diese Spezifikation interpretiert werden als streng erforderlich im Europäischen Wirtschaftsraum (EEA).

Im Gegensatz zur EMV 3DS Protokoll-Spezifikation:

A.1 Fehlende erforderliche Felder

. . .

Sofern nicht ausrücklich angegeben, gibt die empfangenden Komponente einen Fehlermeldung zurück, wenn ein erforderliches Feld fehlt . . . Das trifft zu, gleichgültig ob das Feld immer Pflicht oder bedingt erforderlich ist.

haben die Kartensysteme verfügt, dass Issuer EMV 3DS-Nachrichten nicht ablehnen dürfen, wenn eines oder mehrere bedingte Felder fehlen. Die Kartensysteme schreiben aber auch vor, dass Händler bedingte Felder in EMV 3DS-Nachrichten gemäß der geltenden Datenschutzgesetze senden müssen.

Folgende Elemente gelten als zentral, und es wird dringend empfohlen, diese Daten anzugeben:

• Informationen zum Karteninhaber
• Name
• E-Mail-Adresse
• Telefonnummer
• Mobiltelefonnummer
• Rechnungsadresse
• Lieferadresse
• Browser-Informationen (je nach Integrationsart)
• IP-Adresse

Hinweis: Als allgemeine Regel ist es dringend empfohlen, bedingt erforderlich Datenelemente stets zu übermitteln, um unnötige Reibereien und Ablehnungen zu vermeiden.

4.9 schemeReferenceID

Hinweis:  Nutzen sie als Händler noch die von den Kartenmarken ausgegebenen dummy SchemereferenceIDs, müssen diese zum 01.11.2022 umgestellt / aktualisiert werden.

Das bedeutet für sie, dass ihre Kunden aufgefordert werden müssen ihre Kartendaten zu aktualisieren und zusätzlich ist eine 3DS Authentifizierung verpflichtend. Für diesen Prozess stehen ihnen die nachfolgenden Möglichkeiten zur Verfügung, welche Sie durch die Erstellung eines Payment Links an die Kunden geben können oder Kunden werden im Shop über eine separate Funktion dazu aufgefordert.

Transaktion inkl. Reservierung eines Rechnungsbetrag X
Möchten Sie die Aktualisierung/Umstellung auf eine gültige SchemereferenceID während eines regulären Payments durchführen, d.h. der Kunde soll über einen Betrag X auch belastet werden, nutzen Sie hierfür die Standard Kreditkartenschnittstellen (…payssl.aspx oder auch …paynow.aspx).

Wichtig hierbei ist, dass das JSON Objekt credentialOnFile als CIT + initial=true initialisiert werden muss. Dadurch ist eine 3DS-Challenge verpflichtend und die SchemereferenceID wird basierend darauf generiert und kann für weitere Folgeeinzüge als MIT verwendet werden.

Katenverifikation – 0.00€ Transaktion
Möchten Sie die Aktualisierung/Umstellung auf eine gültige SchemereferenceID als Account Verifikation (Prüfung der Kartendaten bei der Bank mit einer 0.00€ Transaktion) durchführen, nutzen Sie hierfür bitte auch die Standard Kreditkartenschnittstellen (…payssl.aspx oder auch …paynow.aspx).

Allgemeine Information
Auch hier ist es wichtig das die Transaktion mit dem JSON Objekt credentialOnFile als CIT + initial=true initialisiert wird. Dadurch ist eine 3DS-Challenge verpflichtend und die SchemereferenceID wird basierend darauf generiert und kann für weitere Folgeeinzüge als MIT verwendet werden.
Zusätzlich senden Sie in in diesem Fall bitte den weitere Key-Value-Parameter AccVerify mit, dadurch wird nachgelagert eine 0.00 Transaktion ausgelöst.Das ist eine eindeutige direkt von den Kartensystemen wie VISA und MC bereitgestellte Transaktions-ID, um eine Transaktion im gesamten Zahlungs-Ökosystem eindeutig zu referenzieren. Sie wurde anfänglich von VISA gemäß deren Framework-Spezifikationen wie COF (Credential On File) und MIT (Merchant Initiated Transactions) eingeführt und ist relevant für Anwendungsfälle mit Transaktionsarten wie Wiederkehrend, UCOF (MIT), Inkrementell, Verzögerte Autorisierung, Wiedervorlage usw.

Mit der Veröffentlichung der EMV 3DS-Spezifikationen entstand auch für MasterCard die Anforderung, eine derartige eindeutige ID zu verwenden, welche sie “traceID” oder “grandfathering ID” nannten. Die Logik dahinter ist, dass sich der Issuer auf diese ID verlassen kann, um die anfängliche Zahlung mit allen nachfolgenden zu verknüpfen, die sich in einem Dauerauftrag in in einem COF- oder MIT-Regime darauf beziehen. Das ermöglicht dem Issuer, für alle nachfolgenden Zahlungen abweichende Transakationsregeln anzuwenden (d.h. kein CVV/CVC, keine zusätzlichen Authentisierung in EMV 3DS).

In der derzeitigen Situation wurde den Händlern für Mastercard/Maestro-Transaktionen, bei denen die anfängliche Zahlung (Einrichtung einer Vereinbarung) vor dem Inkrafttreten der Regulierung erfolgt ist, in den Autorisierungsantworten keine “schemeReferenceID” bereitgestellt. Computop fordert von jenen Händlern, die diese Anwendungsfälle betreffen, sich bei diesem Parameter bei allen nachfolgenden (COF/MIT) Transaktionen mit ihrem Acquirer über die Verwendung des vom Kartenschemes genehmigten statischen Wertes “Grandfathering” abzustimmen.

Bei anfänglichen Zahlungen (Einrichtung einer Vereinbarung) nach dem 14. September 2019 müssen die Händler den in der Antwort als “schemeReferenceID” bereitgestellten Wert speichern und in allen nachfolgenden Zahlungen, die sich auf diese anfängliche Vereinbarung beziehen, an das 1cs Online Bezahlsystem übermitteln. Bei VISA ist die “schemeReferenceID” äquivalent zum vorherigen 1cs Online Bezahlsystem-Parameter “TransactionID”, den die Händler derzeit gemäß COF & MIT Frameworks übermitteln.

Hinweis: Sollten Ihnen ältere Kartentoken vorliegen, bei denen keine schemeReferenceID erfasst wurde, empfehlen wir die Verwendung der folgenden Platzhalter bei Folgetransaktionen:
VISA: 887001863998888
MasterCard: 1231_MCC999999

• Diese Werte sind gültig bis Oktober 2022 kombiniert mit der Deaktivierung von 3DSecure 1.0.
  

Sollte eine Folgetransaktion auch mit Platzhalter-schemeReferenceID fehlschlagen, muss erneut eine initiale Transaktion im Beisein des Kunden durchgeführt werden, um eine schemeReferenceID zu erhalten.

5 Test-Karten

Bis Sie die Programmierung des Zahlungsverkehrs abgeschlossen haben, befindet sich Ihre 1cs Online Bezahlsystem Kasse im Testmodus: Kreditkartenzahlungen werden autorisiert aber es fließt kein Geld, weil das 1cs Online Bezahlsystem keine Buchung ausführt.
Hinweis: Bitte nutzen Sie auch im Testmodus nur kleine Beträge zwischen 0,11 Euro und 2 Euro, denn die Kreditkartenautorisierungen sind auch im Test echt und reduzieren das Limit Ihrer Kreditkarte. Wenn Sie größere Beträge nutzen und das Kartenlimit erreichen, wird sonst Ihre Kreditkarte temporär nicht mehr funktionieren.

Kartennummern

Einmal-Passwörter (OTPs)

Hinweis:   Bitte bestätigen Sie das Einmal-Passwort im Falle einer Challenge per Mausklick und nicht mit der Eingabetaste, da sonst die Schaltfläche “Abbrechen” ausgewählt und die Authentifizierung abgebrochen wird.

transStatus

transStatusReason

6 Begriffe und Definitionen

Obligatorische und bedingte Datenelemente

Bedingungen in 3DS 2.0 sind oft beschrieben als

Erforderlich, sofern nicht Markt- oder regionale Mandate das Senden dieser Informationen beschränken.

Das betrifft zum Beispiel die E-Mail-Adresse des Karteninhabers. Beachten Sie bitte, dass einige Anbieter von ACS-Software sowie manche Issuer diese Datenelemente innerhalb des EWR als technische obligatorisch ansehen können, da derzeit keine Beschränkungen bekannt sind. Daher ist es dringend empfohlen, diese Datenelemente falls möglich zu übermitteln.

Bedingungs-Codes

Definitionen

7 Antwort-Codes

Allgemeine Hinweise zu Paygate-Fehlercodes

1cs Online Bezahlsystem-Fehlercodes haben im Allgemeinen 8 Ziffern und sind wie folgt codiert (d. h. Sie bestehen aus den Ziffern 0..9
und den Zeichen A..Z) in diesem Format:
AN8, (NNNNNNNN) z.B. 22060203 oder 2206014H.

Die Struktur der Fehlercodes ist immer wie folgt:

Ziffer 1: Statuscode oder Fehlercode

Digits 2..4: Common modules

Digits 2..4: Common modules


Kategotie (2-4)

Der Kategorie-Code ist ein 3-stelliger Wert, der den Zahlungs-Adapter oder das Zahlungs-Protokoll angibt. Für 3DS 2.0 liegen diese Kategorie-Codes abhängig vom Kartenverbinder im Bereich von 100 bis 299.

Detail (5-8)

8 3DS 2.0 Händler-Anwendungsfälle & Testen von 3D-Secure 2.0

Was Sie in diesem Kapitel erwarten können?
Wegen der verschiendenen Szenarien, die mit 3-D Secure 2.X auftreten können, untergliedern wir das Kapitel in drei thematische Bereiche:

1. Allgemeine technische Anpassungen (für alle Händler relevant)
2. Anwendungsfälle für Transaktionskennzeichnung (unterschiedliche Behandlung je nach Händler-Szenario)
3. Test von 3-D Secure 2.X via Computop

Allgemeine technische Anpassungen

Welche Anfragearten betrifft 3D-Secure 2.0/SCA?

• die betroffenen Anfragearten sind: Autorisierung und Verkauf
• Buchung und Gutschrift sind von den Änderungen ausgenommen

Wie wird die Datenübertragung an/von die First Cash Solution in Zukunft aussehen?

• ANFRAGE: Während der Implementierung von 3D Secure 2.0 und der nötigen Lieferung größerer Datenmengen empfehlen wir Ihnen, unserer Formulare via Form-POST Methode aufzurufen. Beachten Sie bitte, dass die Option iFrame weiterhin verfügbar ist. Der Hintergrund sind mögliche Browserbeschränkungen, die dazu führen können, dass der gesendete Datenstring abgeschnitten wird.

Beispiel:

• ANTWORT: Beachten Sie bitte auch die Änderung der abschließenden Weiterleitung zu URLSuccess | URLFailure.
  Diese wird im Fall von Transaktionen mit 3D Secure 2.0 als ein Body POST ausgeführt. Deshalb sollten Sie sowohl ein GET als auch eine POST Antwort an URLSuccess | URLFailure empfangen können.

Wie kann ich zwischen 3DS 1.0 und 2.0 wählen?

• WICHTIG: Um 3D Secure 1.0 oder 3D Secure 2.0 testen oder nutzen zu können, müssen wir 3D Secure an unserem 1cs Online Bezahlsystem in Ihrem Namen konfigurieren. Bitte wenden Sie sich an support@1cs.de, falls Sie diesen Prozess noch nicht begonnen haben.
• Standardmäßig erfolgt jede Zahlung gemäß dem Prozess von 3D Secure 1.0.
• Wenn Sie das Verfahren für 3D Secure 2.0 nutzen wollen, verwenden Sie bitte den Aufrufparameter MsgVer=2.0. Das gilt für Tests ebenso wie für die spätere produktive Nutzung.
• Parameter: MsgVer
  Wert: 2.0

Die Verwendung von JSON-Objekten wird Pflicht

• Beachten Sie bitte, dass mit der Implementierung von 3D Secure 2.0 eine obligatorische Erweiterung der vorhandenen Parameter verbunden ist. Aus diesem Grund erwartet und antwortet das 1cs Online Bezahlsystem mit relevanten zuzätzlichen Daten als JSON-Objekt.
  Das JSON-Objekt muss Base64-codiert sein und regulär zusammen mit allen anderen Parametern in den verschlüsselten Blowfish-Daten an des 1cs Online Bezahlsystem übertragen werden.
• Bitte übermitteln Sie nur JSON-Objekte mit Werten. Leere oder mit Null gefüllte Objekte/Parameter führen zu einer Ablehnung.

JSON Beispiel-Anfrage – verschlüsseltes “data”
BASEURL=https://www.computop-paygate.com/

{{BASEURL}}payssl.aspx?MerchantID=Generic3DSTest&len=1800&
data=CDC44E5A9D2C8A559CEDF1CCA97C9FBD3D90E046BFBF96F06ADA9A00FB0BC3494317E8D924FF44729671B93348B477F88054
1ACFF12C8E3A868CD55FEA95219C245CF7F4716FCF3462167A8B63D11424FA7BD30891504F8465C56805975115EB71C0A04E5D746
6D771495035749FFF94D3087529F578DEF518003EA1422F6DE7B7DFD78A0DD695550623A42BF41A422EC219012318FE26D2B757F12
BDFE046EA4CB8D35079ABAB6859691FEE1B03483471495035749FFF94D3087529F578DEF518003EA1422F6DE7D4E20259A484D23A9
EFC7F4ADB209DD67D8EDE5BD2AC0CB2682D7CF26A6624A54BCF4E93219ADD89ABA6214820D4BAA5A9A184DD7F8AF3E2BE98C5B63
113276B023B92DA5AADCCD7387B71B6651A0E7E4E42F8790122386AA9A184DD7F8AF3E23CFEC0086B59B6A9D98EB96DFDA496D97D
85706A4A810056FE48AB878EFC1E976DB7504D402F4B96778B45ADE1DF3E217EFFBA566359677AB73F514F1E75F11DBE3E15983BA53
0E7D5B13A87D1A2ED19A9A184DD7F8AF3E21D32D652A71B2A49A58F3A30256097DA11388C26E7CBEB12E65B31C485C94DE8179CEA
CDE9237EF4C426A05E594E28069E10B19AE173D25A93A546845C5D78C44112031D6D5DE9B4ABA6214820D4BAA5A9A184DD7F8AF3E
260C35EC59CD2FAA2435CD631BFC801AA7C72A1BAE39879C0BF733EDC45DD99F3A9A184DD7F8AF3E2DDA25A6458507ACE3B3CAAC
3A4B293A9C6177F7F00EBFB6924050D9DF661DE8EC204863D819ABF9564498E9F2D72BEFF2E040214C4961D8737821BA1F638BE05FB
01E1B382733FC42D6B04AB80D66218C75E691B9475C5F6CF13AD357057BC6B5864EE113DF2272EF6572101D5E45CB634F3E941FA7B3
EA7E636EAEF751C67C82F8E8D9B618E69826221B2A42D7F694D9E10B19AE173D25A6EB48BD63BFFE0FAFC78722BD9FFA39623B5D404
94B96D2A9E10B19AE173D25A188DA61C8E3401850C400A3144C3547808A0C82C7B8E9863D017852B02FBFE6D62983EBC372B1A8108D
832C13F92E88535C213D0FDA1B1A5C426A05E594E28069E10B19AE173D25A92AD74641E23F21D1D66F1B352AFCCD408B1727FACC240
5AA9A184DD7F8AF3E29B3106F31EE7D473A854D99576FDD5620141A96DEF638FCE4362F90866AED8044E42F8790122386AA9A184DD7
F8AF3E20F6BF2E070199426696A900FEEBC7848B6F72D445F2CB9F0ED160CC32B1A3C40C426A05E594E28069E10B19AE173D25A201E5
5FC81E8F7CD78FFD98E342897C11AB2BE505B3E8421C63E936DCCF29058C31D72A3697DA2C89EFC7F4ADB209DD67D8EDE5BD2AC0CB
2682D7CF26A6624A54BCF4E93219ADD89ABA6214820D4BAA5A9A184DD7F8AF3E2BE98C5B63113276B023B92DA5AADCCD7387B71B66
51A0E7E4E42F8790122386AA9A184DD7F8AF3E23CFEC0086B59B6A9D98EB96DFDA496D93F669AB8A34E11706F7B3F762241F749A9A1
84DD7F8AF3E286587E20CD9A354709F67B1501183CFC5D6FD3FD6E23B0D4FA9746B8925D4A4FA9A184DD7F8AF3E21D32D652A71B2A
49A58F3A30256097DA11388C26E7CBEB120758D07B77A47DB34E359C7AE383D69BC426A05E594E28069E10B19AE173D25A93A546845
C5D78C44112031D6D5DE9B4ABA6214820D4BAA5A9A184DD7F8AF3E260C35EC59CD2FAA2435CD631BFC801AA7C72A1BAE39879C0BF
733EDC45DD99F3A9A184DD7F8AF3E2DDA25A6458507ACE3B3CAAC3A4B293A9C6177F7F00EBFB6924050D9DF661DE8EC204863D819
ABF9564498E9F2D72BEFF2E040214C4961D8737821BA1F638BE05FB01E1B382733FC46AA58C2847221D78069144B06DE3755A6C88EA
DD3B3FCCD6F6572101D5E45CB634F3E941FA7B3EA7B08783F57D9AD1BAB2071FAB9B93B3C13FF102AD44B6A493B5C341FB37BF525B
0A0E4F490BE1D46A4C5B8F691A2020868119A0AEB9E9BCD4F9D783FEA316723E17976FBB4909040AE279D66AF13B8441582CB00BB30
835AB6401E5CDDF295F533AEE31D2677314D288F2C15BFB16837EF4A779C1E39E4AA1CEE13FABDB2B89D9A7A89ED81EC005BCD4163
30CFCE5CF716A316FDF29A9CFF3F25490656C800BCA582CB00BB30835ABABD19D247E68289A52F1387D978126C967F9BBB890618AF
5A0E5136C7DC2892D2460687217D2779B5836D3F1FFAE8F3B582CB00BB30835ABEE02C59E0AAF8C913339B61F9DDFB7DAC4FF24608
69E4876C5DFD5D39E79330D427654226D9E37E72D7A4C332F59563DF70B3A840877E2B1BF739A2347A73347F7DA9F100EEBC189ADE
92F98BE65BCBE29FE1A3DFE89E44EEEBF9C902BBAA7C2F68CBC48C724B889A53EA148988B56CC52D52743C045F57844F6607DDEA75
FE613EAC80E2C02BCEA89B71E52E64D7538DC9B82EB2740B82C698F43B6A62D770935233D5F10E593D0519511BAAD615B0035D7524
B097C29BA39EBEBEDB93425EB7824B9CCDB1397E716993ED326500615B4B1853A59F760A0E06373BDFE1CC6695A93B15851F56428&
template=ct_responsive_ch&language=en

JSON Beispiel-Anfrage – unverschlüsselte Request-Parameter

MerchantID=Generic3DSTest &MsgVer=2.0 &TransID=1234567890 &RefNr=20200124 &Amount=100 &Currency=EUR &URLNotify= https://www.computop.com &URLSuccess= https://www.computop.com &URLFailure= https://www.computop.com &billToCustomer=ew0KICAgICJjb25zdW1lciI6IHsNCiAgICAgICAgInNhbHV0YXRpb24iOiAiTXIiLA0KICAg
ICAgICAiZmlyc3ROYW1lIjogIk5hcG9sZW9uIiwNCiAgICAgICAgImxhc3ROYW1lIjogIkJvbmFwYXJ0ZSIsDQog
ICAgICAgICJiaXJ0aERhdGUiOiAiMTc2OS0wOC0xNSINCiAgICB9LA0KICAgICJtb2JpbGVQaG9uZSI6IHsNCiAg
ICAgICAgImNvdW50cnlDb2RlIjogIjMzIiwNCiAgICAgICAgInN1YnNjcmliZXJOdW1iZXIiIDogIjEyMzQ1Njc4
OTEwIg0KICAgIH0sDQogICAgImVtYWlsIjogIm5hcG9sZW9uLmJvbmFwYXJ0ZUBmcmFuY2UuY29tIg0KfQ== &billingAddress=ew0KICAgICJjaXR5IjogIkFqYWNjaW8iLA0KICAgICJjb3VudHJ5Ijogew0KICAgICAgICAi
Y291bnRyeUEzIjogIkZSQSINCiAgICB9LA0KICAgICJhZGRyZXNzTGluZTEiOiB7DQogICAgICAgICJzdHJlZXQi
OiAiRXhpbGVzdHJlZXQiLA0KICAgICAgICAic3RyZWV0TnVtYmVyIjogIjI3MCINCiAgICB9LA0KICAgICJwb3N0
YWxDb2RlIjogIjIwMTY3Ig0KfQ== &shipToCustomer=ew0KICAgICJjb25zdW1lciI6IHsNCiAgICAgICAgInNhbHV0YXRpb24iOiAiTXIiLA0KICAg
ICAgICAiZmlyc3ROYW1lIjogIkx1ZHdpZyIsDQogICAgICAgICJsYXN0TmFtZSI6ICJYVklJSSIsDQogICAgICAg
ICJiaXJ0aERhdGUiOiAiMTc1NS0xMS0xNyINCiAgICB9LA0KICAgICJtb2JpbGVQaG9uZSI6IHsNCiAgICAgICAg
ImNvdW50cnlDb2RlIjogIjMzIiwNCiAgICAgICAgInN1YnNjcmliZXJOdW1iZXIiIDogIjEyMzQ1Njc4OTEwIg0K
ICAgIH0sDQogICAgImVtYWlsIjogIkx1ZHdpZ0Byb3lhbC5mcmFuY2UuY29tIg0KfQ== &shippingAddress=ew0KICAgICJjaXR5IjogIlBhcmlzIiwNCiAgICAiY291bnRyeSI6IHsNCiAgICAgICAgImN
vdW50cnlBMyI6ICJGUkEiDQogICAgfSwNCiAgICAiYWRkcmVzc0xpbmUxIjogew0KICAgICAgICAic3RyZWV0Ijo
gIlBsYWNlIGRlIGxhIENvbmNvcmRlIiwNCiAgICAgICAgInN0cmVldE51bWJlciI6ICIxIg0KICAgIH0sDQogICA
gInBvc3RhbENvZGUiOiAiNzUwMDEiDQp9 &credentialOnFile=ew0KICAgICJ0eXBlIjogew0KICAgICAgICAidW5zY2hlZHVsZWQiOiAiQ0lUIg0KICAgIH
0sDQogICAgImluaXRpYWxQYXltZW50IjogdHJ1ZQ0KfQ== &OrderDesc=Test:000 billToCustomer=ew0KICAgICJjb25zdW1lciI6IHsNCiAgICAgICAgInNhbHV0YXRpb24iOiAiTXIiLA0KICAgICAgI
CAiZmlyc3ROYW1lIjogIk5hcG9sZW9uIiwNCiAgICAgICAgImxhc3ROYW1lIjogIkJvbmFwYXJ0ZSIsDQogICAgI
CAgICJiaXJ0aERhdGUiOiAiMTc2OS0wOC0xNSINCiAgICB9LA0KICAgICJtb2JpbGVQaG9uZSI6IHsNCiAgICAgI
CAgImNvdW50cnlDb2RlIjogIjMzIiwNCiAgICAgICAgInN1YnNjcmliZXJOdW1iZXIiIDogIjEyMzQ1Njc4OTEwI
g0KICAgIH0sDQogICAgImVtYWlsIjogIm5hcG9sZW9uLmJvbmFwYXJ0ZUBmcmFuY2UuY29tIg0KfQ== { "consumer": { "salutation": "Mr", "firstName": "Napoleon", "lastName": "Bonaparte", "birthDate": "1769-08-15" } , "mobilePhone": { "countryCode": "33", "subscriberNumber" : "12345678910" } , "email": "napoleon.bonaparte@france.com" } billingAddress=ew0KICAgICJjaXR5IjogIkFqYWNjaW8iLA0KICAgICJjb3VudHJ5Ijogew0KICAgICAgICAiY291b
nRyeUEzIjogIkZSQSINCiAgICB9LA0KICAgICJhZGRyZXNzTGluZTEiOiB7DQogICAgICAgICJzdHJlZXQiOiAiR
XhpbGVzdHJlZXQiLA0KICAgICAgICAic3RyZWV0TnVtYmVyIjogIjI3MCINCiAgICB9LA0KICAgICJwb3N0YWxDb
2RlIjogIjIwMTY3Ig0KfQ== { "city": "Ajaccio", "country": { "countryA3": "FRA" } , "addressLine1": { "street": "Exilestreet", "streetNumber": "270" } , "postalCode": "20167" } shipToCustomer=ew0KICAgICJjb25zdW1lciI6IHsNCiAgICAgICAgInNhbHV0YXRpb24iOiAiTXIiLA0KICAgICAgI
CAiZmlyc3ROYW1lIjogIkx1ZHdpZyIsDQogICAgICAgICJsYXN0TmFtZSI6ICJYVklJSSIsDQogICAgICAgICJia
XJ0aERhdGUiOiAiMTc1NS0xMS0xNyINCiAgICB9LA0KICAgICJtb2JpbGVQaG9uZSI6IHsNCiAgICAgICAgImNvd
W50cnlDb2RlIjogIjMzIiwNCiAgICAgICAgInN1YnNjcmliZXJOdW1iZXIiIDogIjEyMzQ1Njc4OTEwIg0KICAgI
H0sDQogICAgImVtYWlsIjogIkx1ZHdpZ0Byb3lhbC5mcmFuY2UuY29tIg0KfQ== { "consumer": { "salutation": "Mr", "firstName": "Ludwig", "lastName": "XVIII", "birthDate": "1755-11-17" } , "mobilePhone": { "countryCode": "33", "subscriberNumber" : "12345678910" } , "email": "Ludwig@royal.france.com" } shippingAddress=ew0KICAgICJjaXR5IjogIlBhcmlzIiwNCiAgICAiY291bnRyeSI6IHsNCiAgICAgICAgImNvdW50
cnlBMyI6ICJGUkEiDQogICAgfSwNCiAgICAiYWRkcmVzc0xpbmUxIjogew0KICAgICAgICAic3RyZWV0IjogIlBs
YWNlIGRlIGxhIENvbmNvcmRlIiwNCiAgICAgICAgInN0cmVldE51bWJlciI6ICIxIg0KICAgIH0sDQogICAgInBv
c3RhbENvZGUiOiAiNzUwMDEiDQp9 { "city": "Paris", "country": { "countryA3": "FRA" } , "addressLine1": { "street": "Place de la Concorde", "streetNumber": "1" } , "postalCode": "75001" } credentialOnFile=ew0KICAgICJ0eXBlIjogew0KICAgICAgICAidW5zY2hlZHVsZWQiOiAiQ0lUIg0KICAgIH0sDQo
gICAgImluaXRpYWxQYXltZW50IjogdHJ1ZQ0KfQ== { "type": { "unscheduled": "CIT" } , "initialPayment": true }

Schlüssel Parameter / Objekt

• Wenn Sie nicht Ihre eigene Vorlage verwenden, haben wir Ihre ersten Tests eine neue Vorlage. Sie müssen lediglich das “Template=ct_responsive_ch” zu den verschlüsselten Daten hinzufügen und der vom Kunden eingegebene cardholderName wird automatisch von der First Cash Solution für den Prozess 3D 2.0 übernommen. Für das geplante / kommende Rollout von 3DS-2.0 wird die First Cash Solution die Standardvorlagen  entsprechend anpassen und Ihnen zur Verfügung stellen.
• Wenn Sie Ihre eigene Händlervorlage verwenden und die Abfrage das Karteninhabers dort bisher nicht integriert ist, müssen Sie cardholderName selbst integrieren.
• Beispiel einer XSL-Datei:

<!-- Cardholdername -->     <div class="row ccholder">         <span class="label">             <xsl:value-of select="paygate/language/strCCHolder"/>         </span>         <div class="input">             <input type="text" value="" id="creditCardHolder" name="creditCardHolder">                 <xsl:attribute name="value"><xsl:value-of select="paygate/creditCardHolder"/></xsl:attribute>             </input>         </div>     </div>

• Beispiel einer XML-Datei:

For each language used:

<strCCHolder>Cardholdername</strCCHolder>

• Für PaySSL.aspx | PayNow.aspx ist der cardholderName ein Schlüssel-Wert-Paar.
• Für Direct.aspx ist der cardholderName ein JSON-Parameter des JSON-Objekts “Card“.

JSON-Objekt – browserInfo

• Für PaySSL.aspx | Paynow.aspx erfasst die First Cash Solution die Browserdaten für Sie und daher müssen Sie nichts unternehmen.
• Bei einer Server-zu-Server-verbindung per Direct.aspx müssen die individuellen zusätzlichen Anfragen im Shop implementiert werden. Wir empfehlen daher die Verwendung der Paynow.aspx. In diesem Fall gibt der Endkunde die Kartendaten direkt im shop-eigenen Formular ein. Nach dem Post der Daten erfolgt die automatisierte Verarbeitung im 1cs Online Bezahlsystem analog zur PaySSL.aspx.

JSON-Objekt – accountInfo

• Je mehr Daten Sie uns übermitteln, desto größer ist die Wahrscheinlichkeit, dass eine reibungslose Zahlungswbwicklung erfolgt.
  Sie sollten daher prüfen, welche Daten Sie bereits haben, und intern bestimmen, welche Daten Sie übertragen möchten.

JSON Objekt – customerInfo (billToCustomer | shipToCustomer)

• Beachten Sie bitte, dass die Übermittlung von Adressdaten für 3D Secure 2.0 obligatorisch ist.
  WICHTIG: Wenn Lieferadresse und Rechnungsadresse nicht übereinstimmen, müssen beide Adressen übermittelt werden! Bei digitalen Gütern ist die Rechnungsadresse ausreichend.

JSON-Objekt – merchantRiskIndicator

• Wir empfehlen dringend, den merchantRiskIndicator (Liefermethode) zu übermitteln.
  Die Lieferart wird im JSON-Objekt merchantRiskIndicator im JSON-Parameter shippingAddressIndicator übermittelt.
  Das kann eine positive Auswirkung für eine reibungslose Zahlungsabwicklung haben.

Anwendungsfälle für Transaktions-Kennzeichnung

Szenario 01 – Kreditkarten-Einmalzahlung

• Sie bieten Ihren Kunden die Zahlung per Kreditkarte an
• Jede Zahlung ist eine Einmalzahlung und deshalb immer eine neue ausgelöste Zahlung
• Sie verwenden keine Pseudokartennummer zur Speicherung und Wiederverwendung der Kartendaten

Anmeldedaten sind hinterlegt (CoF)

• Sie müssen 3D Secure verwenden
• Es sind keine weiteren Anpassungen nötig

Szenario 02 – Kreditkarten-Abonnements

• Sie bieten Ihren Kunden die Zahlung per Kreditkarte an
• Kunden schließen bei Ihnen ein Abonnement ab, dass IMMER denselben Betrag und das gleiche Zahlungsintervall hat
• Sie nutzen die Pseudokartennummer, um die Kartendaten zu speichern und wiederzuverwenden
• WICHTIG: Die folgende Anfangszahlung unterliegt der Haftungsverschiebung für Sie als Händler. Im Falle der nachfolgenden Zahlung verfällt diese jedoch, so dass es dort keine Haftungsverschiebung gibt.

Anmeldedaten sind hinterlegt (CoF) – Anfangszahlung des Abonnements

• Gilt für PaySSL.aspx + PayNow.aspx
• 3D Secure ist obligatorisch
• Nötige Anpassungen:
  • Beispiel:
    • JSON-Objekt credentialOnFile mit JSON-Parameter recurring (3 Schlüssel enthalten)
    • JSON-Objekt credentialOnFile mit JSON-Parameter initialPayment und dem Wert “true”
    • Beispiel für Anfangszahlung des Abonnements:

{     "type": {         "recurring": {             "recurringFrequency": 30,             "recurringStartDate": "2019-09-14",             "recurringExpiryDate": "2020-09-14"         }     },     "initialPayment": true }

Anmeldedaten sind hinterlegt (CoF) – Folgezahlung des Abonnements

• Gilt für Direct.aspx
• 3D Secure ist NICHT obligatorisch
• Nötige Anpassungen:
  • Beispiel:
    • Senden Sie bitte die schemereferenceID der Anfangszahlung mit, sodass nachfolgende Systeme die beiden Transaktionen entsprechend verknüpfen können.
    • JSON-Objekt credentialOnFile mit JSON-Parameter recurring (3 Schlüssel enthalten)
    • JSON-Objekt credentialOnFile mit JSON-Parameter initialPayment und dem Wert “false”
    • Beispiel für Folgezahlung des Abonnements:

{     "type": {         "recurring": {             "recurringFrequency": 30,             "recurringStartDate": "2019-09-14",             "recurringExpiryDate": "2020-09-14"         }     },     "initialPayment": false }

Szenario 03 – Kreditkarte Wiederkehrende Zahlung / Anzahlung / Schlusszahlung

• Sie bieten Ihren Kunden die Zahlung per Kreditkarte an
• Die Kunden kaufen wiederholt in ihrem Shop ein und verwenden dieselben Kreditkartendaten
• Sie nutzen die Pseudokartennummer, um die Kartendaten zu speichern und wiederzuverwenden
• WICHTIG: Die folgende Anfangszahlung unterliegt der Haftungsverschiebung für Sie als Händler. Im Falle der nachfolgenden Zahlung verfällt diese jedoch, so dass es dort keine Haftungsverschiebung gibt.

Anmeldedaten sind hinterlegt (CoF) – Anfängliche wiederkehrende Zahlung

• Gilt für PaySSL.aspx + PayNow.aspx
• 3D Secure ist obligatorisch
• Nötige Anpassungen:
  • Beispiel:
    • JSON-Objekt credentialOnFile mit JSON-Parameter unscheduled und dem Wert “CIT”
    • JSON-Objekt credentialOnFile mit JSON-Parameter initialPayment und dem Wert “true”
    • Beispiel einer anfänglichen wiederkehrenden Zahlung:

{

    "type": {

        "unscheduled": "CIT"

    },

    "initialPayment": true

}

Anmeldedaten sind hinterlegt (CoF) – Folgende wiederkehrende Zahlung

• Gilt für Direct.aspx
• 3D Secure ist NICHT obligatorisch
• Nötige Anpassungen:
  • Beispiel:
    • Senden Sie bitte die schemereferenceID der Anfangszahlung mit, sodass nachfolgende Systeme die beiden Transaktionen entsprechend verknüpfen können.
    • JSON-Objekt credentialOnFile mit JSON-Parameter unscheduled und dem Wert “MIT”
    • JSON-Objekt credentialOnFile mit JSON-Parameter initialPayment und dem Wert “false”
    • Beispiel für folgende wiederkehrende Zahlung:

{

    "type": {

        "unscheduled": "MIT"

    },

    "initialPayment": false

}

Szenario 04 – Kreditkarten-Kontoverifizierung

• Sie bieten Ihren Kunden die Zahlung per Kreditkarte an
• In diesem Szenario wollen Sie nur die Kreditkarte des Kunden validieren
• Sie verwenden die Pseudokartennummer, um die Kartendaten zu speichern und wiederzuverwenden
• WICHTIG: Derzeit und zukünftig wollen die Schemes/Kartenmarken die Händler daran hindern, die Validierung der Kartendaten mit einem Minimalbetrag durchzuführen (z.B. 1-Cent-Autosierung). Deshalb bieten Ihnen das 1cs Online Bezahlsystem die entsprechende “NullWertAuthentisierung” an. Dies erfolgt durch Übergabe des zusätzlichen Parameters “AccVerify” in den verschlüsselten Daten – für Details siehe Beispiel unten.
  Stellen Sie bitte sicher, dass Ihr Kreditkarten-Acquirer diese Funktion unterstützt.

Anmeldedaten sind hinterlegt (CoF) – Validation Request

• Gilt für PaySSL.aspx + PayNow.aspx
• 3D Secure ist obligatorisch
• Nötige Anpassungen:
  • Beispiel:
    • Senden Sie bitte den Parameter AccVerify=Yes in den verschlüsselten Daten mit (weitere Details finden Sie bitte in unserem Programmierhandbuch)
    • JSON-Objekt credentialOnFile mit JSON-Parameter unscheduled und dem Wert “CIT”
    • JSON-Objekt credentialOnFile mit JSON-Parameter initialPayment und dem Wert “true”
    • Beispiel der Kontoverifizierung:

{

    "type": {

        "unscheduled": "CIT"

    },

    "initialPayment": true

}

Szenario 05 – Kreditkarten Token speichern / Formular vorausfüllen

• Sie bieten Ihren Kunden die Zahlung per Kreditkarte an
• Kunden kaufen in Ihrem Shop ein und Sie speichern die Kreditkartendaten in Form einer Pseudokartennummer
• Wenn der Kunde wiederkommt, füllen Sie das Kreditkartenformular mit den gespeicherten Daten vor
• WICHTIG: Die folgende Anfangszahlung unterliegt der Haftungsverschiebung für Sie als Händler. Im Falle der nachfolgenden Zahlung verfällt diese jedoch, so dass es dort keine Haftungsverschiebung gibt.

Anmeldedaten sind hinterlegt (CoF) – Anfangszahlung für Token-Speicherung

• Gilt für PaySSL.aspx + PayNow.aspx
• 3D Secure ist obligatorisch
• Nötige Anpassungen:
  • Beispiel:
    • JSON-Objekt credentialOnFile mit JSON-Parameter unscheduled und dem Wert “CIT”.
    • JSON-Objekt credentialOnFile mit JSON-Parameter initialPayment und dem Wert “true”
    • Beispiel Anfangszahlung für Token-Speicherung:

Javascript
// Adds a Change-Event to the checkbox called 'cbPrefill'

$(“#cbPrefill”).change(function() {

 if ($(“#cbPrefill”).is(‘:checked’))

{   // Wenn die Checkbox aktiviert wurde, wird der Wert des Hiddenfields mit den Namen ‘prefill’ auf ‘on’ gesetzt   $(“input[type=’hidden’][name=’prefill’]”).val(‘on’);  }

else

{   // Wenn die Checkbox deaktiviert wurde, wird der Wert des Hiddenfields mit den Namen ‘prefill’ wieder geleert   $(“input[type=’hidden’][name=’prefill’]”).val(”);  }

});

// In case of retries (If form gets called a second time due to errors),

// the last status will be set

if ($(“input[type=’hidden’][name=’prefill’]”).val() == ‘on’) {

 $(“#cbPrefill”).attr(‘checked’, true);

}


XLS
<!– Hiddenfield, which tells Paygate that prefill function should get activated –>

<!– value=”on” means that Paygate will return ‘prefill=on’ in the response to merchant –>

<!– value=””  means that Paygate will not return ‘prefill=on’ in the response to merchant –>

<input type=”hidden” name=”prefill”><xsl:attribute name=”value”><xsl:value-of select=”paygate/prefill”/></xsl:attribute></input>

<!– Checkbox to (de)activate prefill function –>

 <div id=”div_cbPrefill” class=”div_cbPrefill”>

  <input type=”checkbox” name=”cbPrefill” id=”cbPrefill”></input>

  <span><xsl:value-of select=”paygate/language/strCCSaveData” disable-output-escaping=”yes”/></span>

  <div class=”row”></div>

 </div>

Anmeldedaten sind hinterlegt (CoF) – Folgezahlung für Token-Speicherung

• Gilt für PaySSL.aspx + PayNow.aspx
• 3D Secure ist obligatorisch
• Nötige Anpassungen:
  • Beispiel:
    • JSON-Objekt credentialOnFile mit JSON-Parameter unscheduled und dem Wert “CIT”
    • JSON-Objekt credentialOnFile mit JSON-Parameter initialPayment und dem Wert “false”
    • Senden Sie bitte die schemereferenceID der Anfangszahlung mit (COF-CIT-TRUE), sodass nachfolgende Systeme die beiden Transaktionen entsprechend verknüpfen können.
    • Beispiel Folgezahlung für Token-Speicherung:

{

    "type": {

        "unscheduled": "CIT"

    },

    "initialPayment": false

}

Szenario 06 – Kreditkarte wiederkehrende Zahlung inkl. Haftungsverschiebung (z.B. Reisebranche)

• WICHTIG: Das folgende Szenario gilt nur für PCI-zertifizierte Systeme
• Es gibt mehrere Szenarien für die Reisebranche, bei denen wiederkehrende Zahlungen auch der Haftungsverschiebung unterliegen
• Beispiel:
• Der Kunde bucht eine Hotelzimmer über eine Buchungsplattform, gibt seine Kartendaten ein und führt 3D Secure 2.0 aus. Das wird über einen separaten PSP verarbeitet. Diese Transaktion dient nur zur Validierung der Kartendaten -NullWertAuthentisierung-.
  Das führt zu einem Authentisierungsstatus = CAVV, den die zentrake Buchungsplattform dann dem Hotelbetreiber meldet (und jedem anderen Dienstleister wie einer Autovermietung, Versicherung usw.). Der Hotelbetreiber macht eine Zahlung OHNE 3DS 2.0 über das 1cs Online Bezahlsystem, fügt aber den CAVV und alle weiteren Daten hinzu. Die zweite Transaktion enthält auch die entsprechende Haftungsverschiebung.
• Grundlage dafür, dass das funktioniert und die Haftungsverschiebung erfolgt, ist die Übermittlung des Authentisierungsstatus (CAVV). Dieser wird über eine sogenannte “Externe 3DS Authentisierung” bestimmt. Zwei Schritt sind notwendig:

a.     Das externe Händlersystem, welches die erste Zahlung (AccVerify/NullWertAuthentisierung) ausgelöst hat, speichert den Authentisierungsstatus

b.     Nachfolgend kann eine wiederkehrende Zahlung über das 1cs Online Bezahlsystem erfolgen. In diesem Fall muss der Händler sowohl das JSON-Objekt threeDSData in den JSON-Daten als auch die originalen Kartendaten der anfänglichen Authentisierung (Card-JSON) einbeziehen. Die Kartendaten müssen deshalb zwecks PCI-Compliance in ihrer originalen Form von der Buchungsplattform an alle relevanten Dienstleister / Agenturen übermittelt werden.
Für diesen Zweck erklärt ein separater Abschnitt die nötigen Schritte.

• Alle nötigen technischen Informationen sind im Abschnitt Mehrparteien-E-Commerce / Agentur-Modell zu finden.

Szenario 07 – Kreditkarten-MoTo (MailOrder / TelephoneOrder) via PaySSL, Direct oder PayNow

• Sie bieten Ihren Kunden die Zahlung per Kreditkarte an, die telefonisch erfasst wird.
• Die Kreditkartendaten werden in einer separaten Callenter-Anwendung eingegeben, die eine Zahlung über das 1cs Online Bezahlsystem mittels PaySSL.aspx, Direct.aspx oder Paynow.aspx auslöst.
• Sie verwenden die Pseudokartennummer, um die Kartendaten zu speichern und wiederzuverwenden
• WICHTIG: MoTo-Zahlungen unterliegen nicht der Haftungsverschiebung, da 3D Secure nicht möglich ist. (Out of Scope)

Anmeldedaten sind hinterlegt (CoF) – Anfängliche MoTo-Zahlung

• Gilt für PaySSL.aspx, PayNow.aspx und Direct.aspx
• 3D Secure ist nicht möglich (Out of Scope)
• Nötige Anpassungen:
  • Beispiel:
    • JSON-Objekt credentialOnFile mit JSON-Parameter unscheduled und dem Wert “MIT”
    • JSON-Objekt credentialOnFile mit JSON-Parameter initialPayment und dem Wert “true”
    • Beispiel einer anfänglichen MoTo-Zahlung:

{

    "type": {

        "unscheduled": "MIT"

    },

    "initialPayment": true

}

Anmeldedaten sind hinterlegt (CoF) – Folgende MoTo-Zahlung

• Gilt für die automatisierte Zahlungsauslösung via Direct.aspx
• 3D Secure ist nicht möglich (Out of Scope)
• Nötige Anpassungen:
  • Beispiel:
    • Senden Sie bitte immer die schemereferenceID der Anfangszahlung mit, sodass nachfolgende Systeme die beiden Transaktionen entsprechend verknüpfen können
    • JSON-Objekt credentialOnFile mit JSON-Parameter unscheduled und dem Wert “MIT”
    • JSON-Objekt credentialOnFile mit JSON-Parameter initialPayment und dem Wert “false”
    • Beispiel einer folgenden MoTo-Zahlung:

{

    "type": {

        "unscheduled": "MIT"

    },

    "initialPayment": false

}

Szenario 08 – Kreditkarten MoTo (MailOrder / TelephoneOrder) über Virtuelles Terminal

• Sie bieten Ihren Kunden die Zahlung per Kreditkarte an, die telefonisch erfasst wird.
• Die Kreditkartendaten werden über ein virtuelles Terminal eingegeben.
• WICHTIG: MoTo-Zahlungen unterliegen nicht der Haftungsverschiebung, da 3D Secure nicht möglich ist. (Out of Scope)

Anmeldedaten sind hinterlegt (CoF)

• Durch die Verwendung des virtuellen Terminals sind keine weitere Anpassungen erforderlich.

Szenario 09 – Batch-Verarbeitung

Die Vorgabe zum korrekten Kennzeichnen von wiederkehrenden Transaktionen seitens der Kartenmarken ist schon eine ältere Anfordung, hierzu hatten wir im Januar 2019 entsprechend informiert. Im Zuge er PSD2-SCA Umsetzung wird diese vollumfänglich zur Pflicht, damit eben wiederkehrende Transaktionen eindeutig gekennzeichnet werden und somit die nachgelagerten Systeme erkennen, warum in diesen Fällen kein 3D Secure verarbeitet wurde, da in diesen Fällen kein Endkunde aktiv am Payment teilnimmt. Somit ist eine Umsetzung für alle Händler verpflichtend.
Nachfolgend finden Sie unsere Beschreibungen / Details dazu, d.h. im ersten Schritt muss die initiale Zahlung aus dem Shop heraus als CredentialOnFile gekennzeichnet werden und darauf basierend die wiederkehrenden Batch-Transaktionen.

***initiale Shop-Transaktion oder AccountVerification:
Auf unserer Anwendungseite ist das korrekte initiale Flagging (CredentialOnFile) für diverse Anwendungsfälle beschrieben und nachfolgendes Kapitel + Szenario kommt bei Ihnen zum tragen: 3DS 2.0 Händler-Anwendungsfälle & Testen von 3D-Secure 2.0

Kapitel: 2. Anwendungsfälle für Transaktions-Kennzeichnung
Szenario 03 – Kreditkarte Wiederkehrende Zahlung / Anzahlung / Schlusszahlung

***wiederkehrende Batch-Einreichung
Da aus dem initialen Shop Request die schemeReferenceID generiert und zurückgemeldet wurde, muss dieser eine initiale Wert für alle Batch-Nachreichungen verwendet werden + Angabe RTF=M (M=Merchant Initiated Transaction): Kreditkarten

Kapitel: Batch-Nutzung der Schnittstelle
betroffenes Batch Format / Action:
CC,Sale,<Amount>,<Currency>,<TransID>,(<RefNr>),<CCBrand>,<CCNr|PCNr>,<CCExpiry>,<OrderDesc>,<textfeld1>,<textfeld2>,<RTF>,<cardholder>,<transactionID>,
CC,Authorize,<Amount>,<Currency>,<TransID>,(<RefNr>),<CCBrand>,<CCNr|PCNr>,<CCExpiry>,<OrderDesc>,<textfeld1>,<textfeld2>,<RTF>,<cardholder>,<transactionID>,

Im Batch Request gibt es einmal das Feld “transactionID” + zusätzlich “schemeReferenceID” Feld quasi doppelt, bitte verwenden Sie für die Übergabe ausschließlich das Feld = transactionID.

Beispiele – Batchversion 1.2:
CC,Sale,<Amount>,<Currency>,<TransID>,(<RefNr>),<CCBrand>,<CCNr|PCNr>,<CCExpiry>,<OrderDesc>,<textfeld1>,<textfeld2>,<RTF>,<cardholder>,<1234567890>

Die Übergabe des Acquirer Identifier muss im Batchformat im Feld TransactionID erfolgen, d.h. auf die initial 3DS-2.X Transaktion erhalten Sie die schemeReferenceID (im Fall einer 3DS-1.0 Fallback Transaktion als TransactionID) zurück, und dieser Wert muss dann in das Batchformat mit einfließen, damit alle wiederkehrenden Payments korrekt gekennzeichnet werden. Das Feld cardHolder muss vorhanden sein, kann allerdings auch leer übergeben werden.

***PKN Mandat – SchemeReferenceID
Sie können versuchen, Payments ohne schemeReferenceID einzureichen, allerdings können wir Ablehnungen dahingehend nicht ausschließen.
Sollte es zu einer Ablehnung kommen, empfehlen wir eine separate Transaktion als Card Check (AccVerify=YES) Transaktion über unsere …PaySSL.aspx auszuführen, d.h. der Kunde erhält einen Payment Link, über welchen dieser eine initiale 3DS-2.X Transaktion prozessiert und darüber wird dann die schemeReferenceID gemeldet und kann in den Prozess der wiederkehrenden Zahlungen mit einfließen.

• Wegen der ständig nötigen Anpassungen im Bereich der Batch-Abläufe wenden Sie sich bei Fragen bitte an support@1cs.de.

Szenario 10 – Erweitertes Transaktions-Management (ETM)

• Bei Nutzung des ETMs kümmert sich das 1cs Online Bezahlsystem für Sie um die richtige Markierung der Transaktionen.

Test von 3D Secure 2.0 über die First Cash Solution

Nutzen Sie die Chance, jetzt 3D Secure 2.0 zu testen!

Während derzeit nicht alle nachgelagerten Systeme 3D Secure für Testzwecke anbieten, können Sie im 1cs Online Bezahlsystem eine Testsimulation durchführen. Das ermöglicht Ihnen die Durchführung von 3D Secure Authentisierungen mit verschiedenen Rückgabewerten.

Gehen Sie für Tests bitte folgendermaßen vor:

• Aktivieren Sie 3D Secure 2.0 für Ihre First Cash Solution MerchantID. Wenn Sie unsicher sind, ob das bereits aktiviert ist, wenden Sie sich bitte an support@1cs.de
• In der verschlüsselten Datenanfrage verwenden Sie den Standardparameter OrderDesc mit dem Wert “Test:0000”. Das gibt Ihnen eine entsprechend erfolgreiche Autorisierung nach einer erfolgreichen Authentisierung.
  WICHTIG: Im Simulationsmodus wird die schemereferenceID der anfänglichen Zahlung nicht zurückgegeben, weil diese ID von den nachgelagerten Systemen generiert wird. Diese Systeme sind bei der Simulation nicht beteiligt.
• Führen SIe die 3D Secure Authentisierung durch
• Verwenden SIe bitte NUR die verfügbaren Testkarten (Ablaufdatum immer in der Zulunft + CVV/CVC kann jeden Wert enthalten)
• Je nach gewünschtem Szenario (z.B. Browser 3D Secure 2.0 Challenge, reibungslose Browser-Authentisierung usw.) verwenden SIe bitte die entsprechenden Einmal-Passwörter.

9 ECI Codes

Der ECI-Wert wird vom Issuer ACS bereitgestellt. Es gibt die Authentifizierungsstufe an, die für die Transaktion durchgeführt wurde. Der von der Authentifizierung empfangene ECI-Wert wird in der Autorisierungsanforderung weitergeleitet und bestimmt auch, ob eine Transaktion eine Haftungsumkehr (Liability Shift) erhält.
Visa, American Express, Diners/Discover, JCB

Mastercard

10 transStatusReason Codes