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 3D-Secure 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.

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.

ETV	Kartenbasierte Zahlungen
EUR 500	1 bps
EUR 250	6 bps
EUR 100	13 bps

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

Key	Format	Bedingung	Beschreibung
MID	ans..30	M	HändlerID, die von der First Cash Solution vergeben wird
MsgVer	ans..5	M	Message-Version. Zulässiger 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.
PayID	ans32	M	Von der First Cash Solution vergebene ID für die Zahlung; z.B. zur Referenzierung in Batch-Dateien sowie im Capture- oder Credit-Request.
XID	ans64	M	Vom 1cs Online Bezahlsystem vergebene ID für die einzelnen Operationen, die zu einer Zahlung durchgeführt werden
TransID	ans..64	M	Ihre eigene Transaktions-ID, die für jede Zahlung eindeutig sein muss
schemeReferenceID	ans..64	C	Spezifische Transaktions-ID des Kartenschemas, die für nachfolgende Zahlungen mit gespeicherten Zugangsdaten, verzögerte Autorisierungen und Wiedereinreichungen erforderlich ist. Pflicht: CredentialOnFile – initial false – unschedule MIT / recurring schemeReferenceID wird bei 3DS2-Zahlungsvorgängen zurückgegeben. Bei einem Fallback auf 3DS1 prüfen Sie bitte zusätzlich auf TransactionId. Die SchemeReferenceID ist eine eindeutige Kennung, die von den Kartenmarken generiert wird. In der Regel können 1cs-Händler die SchemeReferenceIDs für Abonnements übergreifend verwenden, welche unter Verwendung eines anderen PSP / separater 1cs-OBS-MerchantID / separater Acquirer ContractID / Acquirer erstellt wurden.
refnr		O	Referenznummer vom Request
Status	a..20	M	Status der Transaction. Zulässige Werte: `Authorized` `OK` (Sale) `FAILED` Im Fall von nur-Authentisierung ist der Status entweder `OK` oder `FAILED`.
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!
Code	n8	M	Fehlercode gemäß 1cs Online Bezahlsystem Antwort Codes (Fehlercodes)
card	JSON	M	Objekt der Kartendaten
ipInfo	JSON	C	Objekt mit IP-Informationen. Das Vorhandensein hängt von der Konfiguration des Händlers ab.
threeDSData	JSON	M	Objekt der Authentisierungsdaten
resultsResponse	JSON	C	Falls der Authentisierungsprozess eine Aufforderung für den Karteninhaber enthalten hat, werden zusätzliche Informationen über das Ergebnis der Aufforderung bereitgestellt
externalPaymentData	JSON	O	Optionale Daten des Acquirers/Issuers/externen Dienstleisters für eine Autorisierung
TimeStamp	Date/Time	O	Zeitstempel dieser Aktion, wenn von der 1cs aktiviert, z.B. 30.05.2023 08:47:57 oder 30.05.2023 10:03:01.633
CardHolder	ans..50	O	Name des Karteninhabers, wenn von der 1cs aktiviert, z.B. Max Mustermann
bin	n..6	O	BIN der Kreditkarte, wenn von der 1cs aktiviert, z.B. 40001
maskedpan	an..19	O	Maskierte Kreditkartennummer, wenn von der 1cs aktiviert, z.B.400001XXXXXX8323
cardinfo	JSON	O	JSON-Struktur, welche Informationen zur Kreditkarte bzw. dem Issuer enthält, wenn vom der 1cs aktiviert, z.B. {“BIN”:”400001″,”Brand”:”VISA”,”Product”:””,”Source”:”CREDIT”,”Type”:””,”Country”:{“A3″:”USA”,”N3″:”840″},”Issuer”:””}
CCBrand	an..20	O	Brand/ Karten-Scheme der Kreditkarte, z.B. VISA
CCExpiry	n6	O	In Verbindung mit PCNr: Ablaufdatum der Kreditkarte im Format YYYYMM (202207).
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 Computop Paygate ist, ist dieser vor Manipulationen geschützt.
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 Computop Paygate Aufruf. Dadurch ist der Wert gegen Manipulation geschützt. Der Custom-Wert wird dann in Klartext an die Computop Paygate-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.
userData	ans..1024	C	Wenn beim Aufruf angegeben, übergibt das 1cs Online Bezahlsystem die Parameter mit dem Zahlungsergebnis an den Shop.
MAC	an64	M	Hash Message Authentication Code (HMAC) mit SHA-256-Algorithmus. Details finden Sie hier: HMAC-Authentisierung (Anfrage) HMAC-Authentisierung (Notify)

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:

Key	Format	Bedingung	Beschreibung
TxType	ans..20	M	Übergeben Sie „Order“, um eine Zahlung zu initialisieren und diese später über die Schnittstelle authorize.aspx zu autorisieren. Bitte beachten Sie, dass in Verbindung mit dem genutzten 3-D Secure-Verfahren eine separate Einstellung notwendig ist. Bitte wenden Sie sich hierzu direkt an 1cs.

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:

Key	Format	Bedingung	Beschreibung
MerchantID	ans..30	M	HändlerID, die von der First Cash Solution vergeben wird. Dieser Parameter ist zusätzlich auch unverschlüsselt zu übergeben.
PayID	an32	M	Von dem 1cs Online Bezahlsystem vergebene ID für die Zahlung; z.B. zur Referenzierung in Batch-Dateien sowie im Capture- oder Credit-Request.
TransID	ans..64	M	Ihre eigene TrasaktionsID, die für jede Zahlung eindeutig sein muss.
Amount	n..10	M	Betrag in der kleinsten Währungseinheit (z.B. EUR Cent). Bitte wenden Sie sich an die 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
OrderDesc	ans..768	O	Beschreibung der gekauften Waren, Einzelpreise etc.
MAC	an64	M	Hash Message Authentication Code (HMAC) mit SHA-256-Algorithmus. Details finden Sie hier: HMAC-Authentisierung (Anfrage) HMAC-Authentisierung (Notify)
Capture	an..6	OM	Bestimmt Art und Zeitpunkt der Buchung (engl. Capture). Buchungsarten AUTO Buchung sofort nach Autorisierung (Standardwert). MANUAL Buchung erfolgt 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).

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 (Fehler codes)
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.

Key	Format	Bedingnung	Beschreibung
MerchantID	ans..30	M	HändlerID, die von der First Cash Solution vergeben wird. Dieser Parameter ist zusätzlich auch unverschlüsselt zu übergeben.
MsgVer	ans..5	M	Message-Version. Zulässige Werte: `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 OBSkeine 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		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.
schemeReferenceID	ans..64	C	Kartensystemspezifische Transaktions-ID, die für nachfolgende Zahlungen mit hinterlegten Daten, verzögerte Autorisierungen und Wiedereinreichungen erforderlich ist. Pflicht: CredentialOnFile – initial false – unschedule MIT / recurring schemeReferenceID wird bei 3DS2-Zahlungsvorgängen zurückgegeben. Bei einem Fallback auf 3DS1 prüfen Sie bitte zusätzlich auf TransactionId. Die SchemeReferenceID ist eine eindeutige Kennung, die von den Kartenmarken generiert wird. In der Regel können Computop-Händler die SchemeReferenceIDs für Abonnements übergreifend verwenden, welche unter Verwendung eines anderen PSP / separater Paygate-MerchantID / separater Acquirer ContractID / Acquirer erstellt wurden.
industrySpecificTxType	ans..20	C	Dieser Parameter ist erforderlich, wenn eine branchenspezifische Transaktion entsprechend dem Kartenmarken MIT-Framework (Merchant Initiated Transactions) verarbeitet wird. Zulässige Werte: – Resubmission: Ein Händler führt eine erneute Einreichung durch, wenn er eine Autorisierung angefordert hat, diese aber aufgrund unzureichender Mittel abgelehnt wurde; die Waren oder Dienstleistungen wurden jedoch bereits an den Karteninhaber geliefert. In solchen Szenarien können Händler den Antrag auf Beitreibung ausstehender Forderungen von Karteninhabern erneut einreichen. – Reauthorization: Ein Händler leitet eine erneute Autorisierung ein, wenn Abschluss oder Erfüllung der ursprünglichen Bestellung oder Dienstleistung die von Visa festgelegte Gültigkeitsdauer der Autorisierung überschreitet. Es gibt zwei gängige Szenarien für die erneute Autorisierung: • *Geteilte oder verzögerte Lieferung* be E-Commerce-Händlern. Eine Teillieferung liegt vor, wenn zum Zeitpunkt des Kaufs nicht alle bestellten Waren versandbereit sind. Erfolgt die Lieferung der Ware nach der von Visa festgelegten Gültigkeitsdauer der Autorisierung, führen E-Commerce-Händler eine separate Autorisierung durch, um sicherzustellen, dass Kundengelder verfügbar sind. • Verlängerte Hotelaufenthaltens, Autovermietungen und Keuzfahrten. Eine erneute Autorisierung wird für Aufenthalte, Reisen und/oder Anmietungen verwendet, die über die von Visa festgelegte Gültigkeitsdauer der Autorisierung hinausgehen. – DelayedCharges: Verzögerte Gebühren dienen dazu, um eine zusätzliche Kontogebühr zu verarbeiten, nachdem die ursprünglichen Dienstleistungen erbracht und die entsprechende Zahlung verarbeitet wurde. – NoShow: Karteninhaber können mit ihren Visa-Karten eine garantierte Reservierung bei bestimmten Händlersegmenten vornehmen. Eine garantierte Reservierung stellt sicher, dass die Reservierung berücksichtigt wird und ermöglicht es einem Händler, eine No-Show-Transaktion durchzuführen, um dem Karteninhaber eine Strafe gemäß den Stornierungsbedingungen des Händlers zu berechnen. Hinweis: Für Händler, die tokenbasierte Zahlungsinformationen akzeptieren, um eine Reservierung zu garantieren, ist es zum Zeitpunkt der Reservierung erforderlich, einen CIT (Kontoverifizierungsservice) durchzuführen, um später eine No-Show-Transaktion durchführen zu können. Hinweis: Das wird immer zusammen mit dem Parameter “schemeReferenceID” übermittelt. Bezüglich unterstützer Acquirer und Kartenmarken wenden Sie sich bitte an den support@1cs.de.
Amount	n..10	M	Betrag in der kleinsten Währungseinheit (z.B. EUR Cent). Bitte wenden Sie sich an den support@1cs.de 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: A1 W ährungstabelle
card	JSON	M	Kartendaten
Capture	ans..6		Bestimmt Art und Zeitpunkt der Buchung (engl. Capture). Zulässige Werte: `AUTO` = Abschluss sofort nach der Autorisierung (Standardwert) `MANUAL` = Buchung erfolgt 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).
billingDescriptor	ans..22	O	Ein auf dem Kontoauszug des Karteninhabers zu druckender Beschreiber. Beachten Sie bitte auch die andernorts gemachten zusätzlichen Hinweise für weitere Informationen über Regeln und Vorschriften.
OrderDesc	ans..768	O	Beschreibung der Bestellung
AccVerify	a3	O	Indikator zur Anforderung einer Konto-Verifizierung (alias Nullwert-Autorisierung). Wenn eine Konto-Verifizierung angefordert wird, ist der übermittelte Betrag optional und wird für die tatsächliche Zahlungstransaktion (d.h. Autorisierung) ignoriert. Zulässige Werte: `Yes`
threeDSPolicy	JSON	O	Objekt, dass die Authentisierungs-Richtlinien und Strategien zur Behandlung von Ausnahmen angibt
threeDSData	JSON	C	Objekt mit Details der Authentisierungsdaten, falls die Authentisierung durch Dritte oder durch den Händler durchgeführt wurde
priorAuthenticationInfo	JSON	O	Das Objekt Prior Transaction Authentication Information enthält optionale Informationen über eine 3DS-Authentisierung eines Karteninhabers, die vor der aktuellen Transaktion erfolgt ist
browserInfo	JSON	C	Exeakte Browserinformationen sind nötig, um eine optimierte Nutzererfahrung zu liefern. Erforderlich für 3DS 2.0 Transaktionen.
accountInfo	JSON	O	Die Kontoinformationen enthalten optionale Informationen über das Kundenkonto beim Händler
billToCustomer	JSON	C	Der Kunde, dem die Waren und / oder Dienstleistungen in Rechnung gestellt werden. Erforderlich, sofern nicht Markt- oder regionale Mandate das Senden dieser Informationen beschränken.
shipToCustomer	JSON	C	Der Kunde, an den die Waren und / oder Dienstleistungen gesendet werden. Erforderlich (falls verfügbar und von billToCustomer abweichend), sofern nicht Markt- oder regionale Mandate das Senden dieser Informationen beschränken.
billingAddress	JSON	C	Rechnungsadresse. Erforderlich für 3DS 2.0 (falls verfügbar), sofern nicht Markt- oder regionale Mandate das Senden dieser Informationen beschränken.
shippingAddress	JSON	C	Lieferadresse. Falls abweichend von billingAddress, erforderlich für 3DS 2.0 (falls verfügbar), sofern nicht Markt- oder regionale Mandate das Senden dieser Informationen beschränken.
credentialOnFile	JSON	C	Objekt, dass Art und Reihe der Transaktionen angibt, die unter Verwendung von beim Händler hinterlegten Zahlungsdaten (z.B. Kontonummer oder Zahlungs-Token) zur Verarbeitung künftiger Käufe eines Kunden erfolgen. Erforderlich, falls zutreffend.
merchantRiskIndicator	JSON	O	Der Händler-Risikoindikator enthält optionale Informationen über den bestimmten Einkauf des Kunden
subMerchantPF	JSON	O	Objekt, das die Details des SubMerchant (Payment Facilitator) angibt, wird ausschließlich von SafeCharge unterstützt.
TermURL	ans..256	M	Nur bei 3-D Secure: URL des Shops, die vom Access Control Server (ACS) der Bank aufgerufen wird, um das Ergebnis der Authentisierung zu übermitteln. Dabei übergibt die Bank per GET die Parameter PayID, TransID, MerchantID und per POST den Parameter PAResponse an die TermURL.
URLNotify	an..256	M	Vollständige URL, die das 1cs OBS 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 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.
userData	ans..1024	O	Wenn beim Aufruf angegeben, übergibt das 1cs Online Bezahlsystem die Parameter mit dem Zahlungsergebnis an den Shop.
MAC	an64	M	Hash Message Authentication Code (HMAC) mit SHA-256-Algorithmus. Details finden Sie hier: HMAC-Authentisierung (Anfrage) HMAC-Authentisierung (Notify)

Antwort-Elemente

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

Key	Format	Bedingung	Beschreibung
MID	ans..30	M	HändlerID, die von der First Cash Solution vergeben wird
PayID	ans32	M	Von der First Cash Solution vergebene ID für die Zahlung/Transaktion. Z.B. zur Referenzierung in Batch-Dateien sowie im Capture- oder Credit-Request.
XID	ans64	M	Vom 1cs Online Bezahlsystem vergebene ID für alle einzelnen Transaktionen (Autorisierung, Buchung, Gutschrift), die für eine Zahlung durchgeführt werden.
TransID	ans..64	M	Ihre eigene TransaktionsID, die für jede Zahlung eindeutig sein muss
refnr		O	Referenznummer wie im Request angegeben
Code	n8	M	Fehlercode gemäß 1cs Online Bezahlsystem Antwort Codes (Fehlercode s)
Status	a..20	M	Status der Transaktion. Zulässige Werte: `AUTHENTICATION_REQUEST` `PENDING` `FAILED`
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!
versioningData	JSON	M	Das Datenelement Card Range Data enthält Informationen, welche die jüngste vom ACS, der den Kartenbereich hostet, unterstützte EMV 3-D Secure-Version angeben. Es kan optional auch die ACS URL für die 3DS Methode enthalten, falls vom ACS unterstützt, sowie die DS Start- und End-Protokoll-Versionen, die den Kartenbereich unterstützen.
card	JSON	M	Kartendaten
threeDSLegacy	JSON	M	Objekt, dass die erforderlichen Datenelemente für die Konstruktion der Anfrage zur Zahler-Authentisierung im Falle eines Fallbacks auf 3DS 1.0 enthält.
userData	ans..1024	C	Wenn beim Aufruf angegeben, übergibt das 1cs Online Bezahlsystem die Parameter mit dem Zahlungsergebnis an den Shop.

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

Key	Format	Bedingung	Beschreibung
acsChallengeMandated	boolean	M	Zeigt an, on eine Challenge für die Autorisierung einer Transaktion wegen lokaler/regionaler Vorschriften oder anderer Variablen nötig ist: true → Challenge ist obligatorisch wegen lokaler/regional Vorschriften false → Challenge ist nicht obligatorisch wegen lokaler/regional Vorschriften, wird aber von ACS als nötig angesehen
challengeRequest	object	M	Objekt Challenge-Anfrage
base64EncodedChallengeRequest	string	M	Base64-codiertes Objekt Challenge-Anfrage
acsURL	string	M	Vollständige URL des ACS, die für das Posten der Challenge-Anfrage verwendet werden soll

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.

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.
TransID	ans..64	M	Ihre eigene TransaktionsID, die für jede Zahlung eindeutig sein muss
Code	n8	M	Fehlercode gemäß 1cs Online Bezahlsystem Antwort Codes (Fehlercode s)
MAC	an64	M	Hash Message Authentication Code (HMAC) mit SHA-256-Algorithmus. Details finden Sie hier: HMAC-Authentisierung (Anfrage) HMAC-Authentisierung (Notify)
authenticationResponse	JSON	M	Antwort-Objekt als Rückgabe zur Authentisierungs-Anfrage beim ACS

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">

</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>  <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

Key	Format	Bedingung	Beschreibung
MID	ans..30	M	HändlerID, die von der First Cash Solution vergeben wird
MsgVer	ans..5	M	Message-Version. Zulässige Werte: 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.
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 alle einzelnen Transaktionen (Autorisierung, Buchung, Gutschrift), die für eine Zahlung durchgeführt werden
TransID	ans..64	M	Ihre eigene TransaktionsID, die für jede Zahlung eindeutig sein muss
schemeReferenceID	ans..64	C	Kartensystemspezifische Transaktions-ID, die für nachfolgende Zahlungen mit hinterlegten Daten, verzögerte Autorisierungen und Wiedereinreichungen erforderlich ist
TrxTime	an21	M	Transaction time stamp in format DD.MM.YYYY HH:mm:ssff.
Status	a..20	M	Status der Transaktion. Zulässige Werte: `Authorized` `OK` (Sale) `PENDING` `FAILED` Im Falle von nur Authentisierung ist der Status entweder `OK` oder `FAILED`.
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!
Code	n8	M	Fehlercode gemäß 1cs Online Bezahlsystem Antwort Codes (Fehlercodes)
MAC	an64	M	Hash Message Authentication Code (HMAC) mit SHA-256-Algorithmus. Details finden Sie hier: HMAC-Authentisierung (Anfrage) HMAC-Authentisierung (Notify)
card	JSON	M	Kartendaten
ipInfo	JSON	O	Objekt mit IP-Informationen
threeDSData	JSON	M	Authentisierungsdaten
resultsResponse	JSON	C	Falls der Authentisierungsprozess eine Challenge des Karteninhabers enthalten hat, werden zusätzliche Informationen über das Ergebnis der Challenge bereitgestellt
externalPaymentData	JSON	O	Optionale Daten des Acquirers/Issuers/externen Dienstleisters für eine Autorisierung
PCNr	n16	O	Pseudo Card Number: Vom Computop Paygate generierte Zufallszahl, die eine reale Kreditkartennummer repräsentiert. Die Pseudokartennummer (PKN) beginnt mit 0, und die letzten 3 Stellen entsprechen denen der realen Kartennummer. Die PKN kann wie eine Kreditkartennummer für Autorisierung, Buchung und Gutschriften verwendet werden. PCNr ist ein Antwortwert von Computop Paygate und kann ebenfalls als CCNr im Request oder als Teil von card-JSON verwendet werden.

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

Key	Format	Bedingung	Beschreibung
MID	ans..30	M	HändlerID, die von der First Cash Solution vergeben wird
Len	integer	M	Länge des unverschlüsselten Strings `Data`
Data	string	M	Blowfish-verschlüsselter String, der ein JSON-Objekt mit `MID`, `PayID` und `TransID` enthält

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

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.
TransID	ans..64	M	Ihre eigene TransaktionsID, die für jede Zahlung eindeutig sein muss

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:

Formularelement	Beschreibung
PAReq	Ein konstruiertes, Base64-codiertes und komprimiertes Feld mit den Feldern der Payer Authentication Request Message. Der verwendete Kompressionsalgorithmus ist eine Kombination von LZ77- und Huffman-Codierung gemäß RFC 1951.
TermURL	Die Händler-URL, wohin der ACS den Karteninhaber nach Abschluss der Authentisierung weiterleitet. Beachten Sie, dass das 1cs Online Bezahlsystem die Felder PayID, TransID und MID im Anfrage-String zur Basis-URL hinzufügt. Bitte ändern Sie die TermURL nicht!
MD	Das Feld MD (d.h. Händlerdaten) kann beliebige Daten transportieren, die der Händler fpr die Fortsetzung der Sitzung benötigt. Beachten Sie bitte, dass dieses Feld im Formular vorhanden sein muss, auch wenn es nicht verwendet wird.

<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

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.
TransID	ans..64	M	Ihre eigene TransaktionsID, die für jede Zahlung eindeutig sein muss
PARes	—	M	Die vom ACS gesendete PARes-Nachricht (Payer Authentication Response) in Reaktion auf die PAReq ungeachtet dessen, ob die Authentisierung erfolgreich ist

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

Key	Format	Bedingung	Beschreibung
MerchantID	ans..30	M	HändlerID, die von 1cs Online Bezahlsystem vergeben wird. Dieser Parameter ist zusätzlich auch unverschlüsselt zu übergeben.
PayID	an32	M	Vom 1cs Online Bezahlsystem vergebene ID für die Zahlung, z.B. zur Referenzierung in Batch-Dateien sowie im Capture- oder Credit-Request.
TransID	ans..64	M	Ihre eigene TransaktionsID, die für jede Zahlung eindeutig sein muss
PAResponse	—	M	Die vom ACS gesendete PARes-Nachricht (Payer Authentication Response)

Antwort-Elemente

Parameter	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	ans64	M	Vom 1cs Online Bezahlsystem vergebene ID für alle einzelnen Transaktionen (Autorisierung, Buchung, Gutschrift), die für eine Zahlung durchgeführt werden
TransID	ans..64	M	Ihre eigene TransaktionsID, die für jede Zahlung eindeutig sein muss
Status	a..20	M	Status der Transaktion. Zulässige Werte: `Authorized` `OK`(Sale) `FAILED`
Description	ans..1024	M	Textliche Beschreibung des Codes
Code	n8	M	Fehlercode gemäß Excel-Datei 1cs Online Bezahlsystem Antwort Codes
card	JSON	C	Kartendaten
ipInfo	JSON	O	Objekt mit IP-Informationen
threeDSData	JSON	M	Authentisierungsdaten

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

Datenelement	CND	Beschreibung
Message Version Number	M	Message-Versionsnummer, wie sie in der Verify Enrollment Response (VERes) erhalten wurde. Zulässige Werte: `1.0.1` `1.0.2`
Acquirer Bank Identification Number (BIN)	M	Dieses Feld muss zur verwendeten Acquirer-BIN bei der Verify Enrollment Request passen
Merchant Identifier (ID) Number	M	Dieses Feld muss zur verwendeten Merchant ID bei der Verify Enrollment Request passen. Dieses Feld muss auch zur vom Acquirer verwendeten Merchant ID gegenüber dem Kartennetzwerk für Autorisierungen und Abrechnung passen.
Merchant Name	M	Dieses Feld muss den Namen des Online-Händlers enthalten, bei dem der Karteninhaber einkauft. Die Maximallänge beträgt 25 Zeichen. Der Händlername muss dem eingereichten Namen für Autorisierung und Abrechnung entsprechen.
Merchant Country Code	M	Dieses Feld muss den dreistelligen Ländercode gemäß ISO 3166 enthalten
Merchant URL	M	Dieses Feld muss die vollständige URL der Händler-Webseite enthalten
Transaction Identifier	M	Eindeutige Transaktionsnummer des Händlers. Enthält einen 20 Byte großen statistischen eindeutigen Wert, der Base64-codiert ist und zu einem Ergebnis mit 28 Byte führt.
Purchase Date & Time	M	Datum und Uhrzeit des Kaufs in GMT im folgenden Format: JJJJMMTT HH:MM:SS.
Purchase Amount	M	Dieses Feld muss den Wert des Kaufs vom Karteninhaber enthalten. Es ist ein Wert mit bis zu 12 Stellen und ohne Nachkommastellen.
Purchase Currency	M	Der entsprechende dreistellige Währungscode gemäß ISO 4217 für die Transaktionswährung zwischen Karteninhaber und Händler muss verwendet werden.
Currency Exponent	M	Die kleinste Währungseinheit gemäß ISO 4217
Order Description	O	Kurze Beschreibung der gekauften Artikel durch den Händler. Die Maximalgröße beträgt 125 Zeichen, aber der Händler sollte beim Anlegen dieses Feldes die Eigenschaften vom Gerät des Karteninhabers berücksichtigen.
Recurring Payment Data	C	Ein Element Recur muss angegeben werden, wenn Händler und Karteninhaber wiederkehrende Zahlungen vereinbart haben
Installment Payment Data	C	Eine Ganzzahl größer als eins gibt die Maximalanzahl der erlaubten Autorisierungen für Ratenzahlungen an. Sie muss angegeben werden, wenn Händler und Karteninhaber Ratenzahlungen vereinbart haben.
Account Identifier	M	Der Inhalt dieses Feldes ist ein für den ACS nützlicher Daten-String; er darf die PAN nicht offenlagen und mit einem Algorithmus erzeugt werden, der glaubhaft eindeutige Werte erzeugt, selbst wenn dieselbe PAN präsentiert wird.
Card Expiry Date	M	Vom Karteninhaber an den Händler übermitteltes Ablaufdatum (JJMM)
Message Extension	O	Alle nötigen Daten zur Unterstützung der Anforderungen, die nicht anderweitig in der PAReq-Nachricht definiert sind, müssen in einer Nachrichten-Erweiterung transportiert werden
Zusätzliche Parameter bei wiederkehrenden Transaktionen
Recurring Frequency	M	Ganzzahl, welche die Mindestanzahl von Tagen zwischen Autorisierungen angibt
Recurring Expiry	M	Datum, nach dem keine weiteren Autorisierungen mehr erfolgen sollen im Format JJJJMMTT.

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.

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

Datenelemente	Altes Element	Beschreibung
MerchantID	—	HändlerID, die von der First Cash Solution vergeben wird
Len	—	Die Länge des Originals verschlüsselt mit Blowfish
Data	—	Per Blowfish verschlüsselte Daten
number	CCNr	Kartennummer
securityCode	CCCVC	Kartenprüfnummer
expiryDate	CCExpiry	Kartenablaufdatum im Format JJJJMM
brand	CCBrand	Kartensystem
cardholder	CreditCardHolder	Name des Karteninhabers, wie er auf der Karte gedruckt ist Hinweis: Alphanumerische Sonderzeichen gemäß EMV Book 4, „Anhang B“. Sonderzeichen wurden mit EMV 3DS Version 2.3 hinzugefügt, aber nicht alle Teilnehmer (Banken) unterstützen diesen Standard bereits.

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

Daten

Key	Format	Bedingung	Beschreibung
MerchantID	ans..30	M	HändlerID, die von der First Cash Solution vergeben wird. Dieser Parameter ist zusätzlich auch unverschlüsselt zu übergeben.
TransID	ans..64	M	Ihre eigene TransaktionsID, die für jede Zahlung eindeutig sein muss
MsgVer	ans..5	M	Message-Version. Zulässige Werte: `2.0`
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.
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	OM	Bestimmt Art und Zeitpunkt der Buchung (engl. Capture). `AUTO` = Abschluss sofort nach der Autorisierung (Standardwert) `MANUAL` = Abschluss erfolgt durch den Händler `<Zahl>` = Verzögerung in Stunden bis zum Abschluss (ganze Zahl; 1 bis 696)
billingDescriptor	ans..22	O	Ein auf dem Kontoauszug des Karteninhabers zu druckender Beschreiber. Beachten Sie bitte auch die andernorts gemachten zusätzlichen Hinweise für weitere Informationen über Regeln und Vorschriften.
OrderDesc	ans..768	O	Beschreibung der Bestellung
AccVerify	a3	O	Indikator zur Anforderung einer Konto-Verifizierung (alias Nullwert-Autorisierung). Wenn eine Konto-Verifizierung angefordert wird, ist der übermittelte Betrag optional und wird für die tatsächliche Zahlungstransaktion (d.h. Autorisierung) ignoriert. Zulässige Werte: `Yes`
threeDSPolicy	JSON	O	Objekt, dass die Authentisierungs-Richtlinien und Strategien zur Behandlung von Ausnahmen angibt.
priorAuthenticationInfo	JSON	O	Das Objekt Prior Transaction Authentication Information enthält optionale Informationen über eine 3DS-Authentisierung eines Karteninhabers, die vor der aktuellen Transaktion erfolgt ist.
browserInfo	JSON	M	Exakte Browserinformationen sind nötig, um eine optimierte Nutzererfahrung zu liefern. Erforderlich für 3DS 2.0 Transaktionen.
accountInfo	JSON	O	Die Kontoinformationen enthalten optionale Informationen über das Kundenkonto beim Händler
billToCustomer	JSON	C	Der Kunde, dem die Waren und / oder Dienstleistungen in Rechnung gestellt werden. Erforderlich, sofern nicht Markt- oder regionale Mandate das Senden dieser Informationen 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. Erforderlich (falls verfügbar), sofern nicht Markt- oder regionale Mandate das Senden dieser Informationen beschränken.
shippingAddress	JSON	C	Lieferadresse. Falls abweichend von billingAddress, erforderlich (falls verfügbar), sofern nicht Markt- oder regionale Mandate das Senden dieser Informationen beschränken.
credentialOnFile	JSON	C	Objekt, dass Art und Reihe der Transaktionen angibt, die unter Verwendung von beim Händler hinterlegten Zahlungsdaten (z.B. Kontonummer oder Zahlungs-Token) zur Verarbeitung künftiger Käufe eines Kunden erfolgen. Erforderlich, falls zutreffend.
merchantRiskIndicator	JSON	O	Der Händler-Risikoindikator enthält optionale Informationen über den bestimmten Einkauf des Kunden. Falls keine `shippingAddress` vorhanden ist, ist es dringend empfohlen, die Eigenschaft `shippingAddressIndicator` mit einem entsprechenden Wert wie `shipToBillingAddress`, `digitalGoods` oder `noShipment` auszufüllen.
URLSuccess	ans..256	M	Vollständige URL, die das 1cs Online Bezahlsystem aufruft, wenn die Zahlung erfolgreich war. 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=encrypted” zu verwenden, um eine verschlüsselte Antwort von Paygate 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=encrypted” zu verwenden, um eine verschlüsselte Antwort von Paygate 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.
URLNotify	ans..256	M	Vollständige URL, die das 1cs Online Bezahlsystem 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=encrypted” zu verwenden, um eine verschlüsselte Antwort von Paygate 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.
MAC	an64	M	Hash Message Authentication Code (HMAC) mit SHA-256-Algorithmus. Details finden Sie hier: HMAC-Authentisierung (Anfrage) HMAC-Authentisierung (Notify)
userData	ans..1024	O	Wenn beim Aufruf angegeben, übergibt das 1cs Online Bezahlsystem die Parameter mit dem Zahlungsergebnis an den Shop.

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.

HTTP POST an URLSuccess / URLFailure / URLNotify

Key	Format	Bedingung	Beschreibung
MID	ans..30	M	HändlerID, die von der First Cash Solution vergeben wird
MsgVer	ans..5	M	Message-Version. Zulässige Werte: 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.
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	ans64	M	Vom 1cs Online Bezahlsystem vergebene ID für alle einzelnen Transaktionen (Autorisierung, Buchung, Gutschrift), die für eine Zahlung durchgeführt werden
TransID	ans..64	M	Ihre eigene TransaktionsID, die für jede Zahlung eindeutig sein muss
refnr		O	Referenznummer vom Request.
schemeReferenceID	ans..64	C	Kartensystemspezifische Transaktions-ID, die für nachfolgende Zahlungen mit hinterlegten Daten, verzögerte Autorisierungen und Wiedereinreichungen erforderlich ist
Status	a..20	M	Status der Transaktion. Zulässige Werte: `Authorized` `OK` (Sale) `FAILED` Im Falle von nur Authentisierung ist der Status entweder `OK` oder `FAILED`.
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!
Code	n8	M	Fehlercode gemäß Excel-Datei 1cs Online Bezahlsystem Antwort Codes
card	JSON	M	Kartenantwortdaten
ipInfo	JSON	C	Objekt mit IP-Informationen. Das Vorhandensein hängt von der Konfiguration des Händlers ab.
threeDSData	JSON	M	Authentisierungsdaten
resultsResponse	JSON	C	Falls der Authentisierungsprozess eine Challenge des Karteninhabers enthalten hat, werden zusätzliche Informationen über das Ergebnis der Challenge bereitgestellt
externalPaymentData	JSON	O	Optionale Daten des Acquirers/Issuers/externen Dienstleisters für eine Autorisierung
userData	ans..1024	C	Wenn beim Aufruf angegeben, übergibt das 1cs Online Bezahlsystem die Parameter mit dem Zahlungsergebnis an den Shop.
MAC	an64	M	Hash Message Authentication Code (HMAC) mit SHA-256-Algorithmus. Details finden Sie hier: HMAC-Authentisierung (Anfrage) HMAC-Authentisierung (Notify)

3 JSON Objekte

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

Das 1cs Online Bezahlsystem 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 1cs Online Bezahlsystem geht in solchen Fällen von einem Fehler aus und lehnt die Transaktion ab.

Grundlagen der Base 64-Codierung	subMerchantPF
accountInfo	externalPaymentData
acsRenderingType	ipInfo
address	merchantRiskIndicator
authenticationResponse	phone
browserInfo	priorAuthenticationInfo
card:request	resultsResponse
card:response	threeDSData:request
challengeRequest	threeDSData:response
country	threeDSLegacy
credentialOnFile	threeDSPolicy
customerInfo	versioningData

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)

Key	Format	Bedingung	Beschreibung
URLSuccess	ans..256	M	Der Käufer wird zu dieser URL weitergeleitet, wenn die MFA erfolgreich ist
URLFailure	ans..256	O	Der Käufer wird zu dieser URL weitergeleitet, wenn die MFA nicht erfolgreich ist
AuthorizationAmount	n..10	O	Der während des MFA-Abschlusses zu authentisierende Betrag. Verwenden Sie diesen Parameter, wenn Sie einen Zahlungsbertrag festlegen wollen, der vom Wert OrderTotal im Aufruf SetOrderReferenceDetails abweicht. Wenn dieser Parameter nicht gesetzt ist, wird der während MFA authentisierte Betrag gleich dem in OrderTotal im Aufruf SetOrderReferenceDetails angegebenen Betrag.

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.

EventToken	Action	Beschreibung
SOD	SetOrderDetails	Übertragung des zahlbaren Betrags und weiterer Informationen – steuert auch die für eine Bestellung bei Amazon wählbaren Zahlungsmethoden
GOD	GetOrderDetails	Anfrage von Bestellinformationen, d.h. zum Erhalt von Informationen über eine neue gewählte Lieferadresse. Nach einem Aufruf mit Eventtoken COD oder SCO, gibt GOD auch die Rechnungsadresse des Kunden zurück Beim Scope “payments:shipping_address” und “payments:billing_address” erhalten Sie die volle Liefer- und Versandadresse nach der Anzeige des Adress-Widgets. Bitte übertragen Sie beim Aufruf die OrderReferenceId.
SCO	SetOrderDetailsAndCon-firmOrder	Bestellbestätigung wieder mit Übertragung des zahlbaren Betrags und weiterer Informationen – mit diesem Eventtoken ist die Bestellung abgeschlossen. Nach erfolgreiche Bestätigung können sofrot Autorisierungen an Amazon übermittelt werden.
COD	ConfirmOrderDetails	Optional, wenn der zahlbare Betrag und weitere Informationen nicht nochmal zur Bestellbestätigung übertragen werden sollen (die First Cash Solution empfiehlt die Verwendung des Eventtoken SCO zur Bestellbestätigung.)
COR	CloseOrderReference	Schließen einer Amazon-Bestellung. Buchungen für offene Autorisierungen sowie Gutschriften sind weiterhin möglich.

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.

Wert Authentisierungs-Status	Beschreibung	Empfohlene Maßnahme
Success	Erfolgreich / nicht nötig	Keine Aktion nötig
Failure	Gescheitert	Weiterleitung zur FailureURL oder zur Seite, um eine andere Zahlungsmethode als Amazon zu verwenden
Abandoned	Gescheitert	Weiterleitung zur FailureURL oder zur Seiten, um die Bestellung mittels Amazon Pay zu ersetzen und die MFA-Challenge abzuschließen

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.

01	02	03	04	05	06	07	08	09	10	11	12	13	14	15	16	17	18	19	20	21	22
G	R	E	A	T		B	R	A	N	D		L	T	D	*	0	8	1	5	3	7

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.

01	02	03	04	05	06	07	08	09	10	11	12	13	14	15	16	17	18	19	20	21	22
H	.	C	A	L	I	F	O	R	N	I	A		N	O		S	H	O	W

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

01	02	03	04	05	06	07	08	09	10	11	12	13	14	15	16	17	18	19	20	21	22
F	L	Y		L	O	W		P	L	C		1	2	3	4	5	6	7	8	9	0

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.

Anwendungsfall	Flags
COF hinzufügen ohne Zahlung	`AccVerify` `credentialOnFile`
COF hinzufügen als Teil einer Zahlung	`credentialOnFile`

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

Visa	MasterCard	Maestro	Amex	Test Scenario
4000012892688323	5232125125401459	6759649826438453	371449635398431	Browser-Challenge
4000016435940133	5232122189301469		378282246310005	Browser-Challenge
4000012699048523	5232127264637786			Browser reibungslos; fehlende DS Transaktions-ID
4000011744135012	5232122741507017			Nicht authentisierter Browser reibungslos
4000019966199434	5232122422543299	6799990100000000019	375000000000007	Authentisierter Browser reibungslos
4000015573198637	5232128083944791			Browser-Challenge fehlende ACS URL
4000017873485953	5232122596907270			Authentisierungs-Protokollfehler
4000014730366880	5232124106987982			Browser-Challenge; authentisierte Transaktion; fehlender Authentisierungswert

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.

otpValue	transStatus	transStatusReason	ECI	authenticationValue
1234	Y		01	JAmi21makAifmwqo2120cjq1AAA=
1111	N	01	01
2222	R	01	01
3333	U	01	01
6666	Y	01	01
7777	A		01	JAmi21makAifmwqo2120cjq1AAA=
8888	N	10
9999	N	08
0001	N	01
0002	N	02
0003	N	03
0004	N	04
0005	N	05
0006	N	06
0007	N	07
0009	N	09
0010	N	10
0011	N	11

transStatus

transStatus	Beschreibung
Y	Authentisierungs-Verifizierung erfolgreich
N	Nicht authentisiert /Konto nicht verifiziert; Transaktion abgelehnt
U	Authentisierung/ Konto-Verifizierung konnte nicht ausgeführt werden; technisches oder anderes Problem, wie in ARes oder RReq angegeben
A	Verarbeitung der Versuche ausgeführt; Nicht authentisiert/verifiziert, aber Nachweis der versuchten Authentisierung/Verfizierung ist bereitgestellt
C	Challenge erfoderlich; zusätzliche Authentisierung mittels CReq/CRes ist erforderlich
D	Challenge erfoderlich; entkoppelte Authentisierung bestätigt
R	Authentisierung/ Kontoverifizierung abgelehnt; Issuer lehnt Authentisierung/Verifizierung ab und fordert, dass keine Autorisierung versucht wird
I	Nur zur Information; 3DS Requestor Challenge-Präferenz anerkannt

transStatusReason

Code	Scheme	Beschreibung
01	All	Kartenauthentisierung fehlgeschlagen
02	All	Unbekanntes Gerät
03	All	Nicht unterstütztes Gerät
04	All	Überschreitet das Authentifizierungshäufigkeitslimit
05	All	Abgelaufene Karte
06	All	Ungültige Kartennummer
07	All	Ungültige Transaktion
08	All	Kein Karteneintrag
09	All	Sicherheitsfehler
10	All	Gestohlene Karte
11	All	Betrugsverdacht
12	All	Transaktion für Karteninhaber nicht erlaubt
13	All	Karteninhaber ist nicht im Dienst registriert
14	All	Zeitüberschreitung der Transaktion beim ACS
15	All	Geringes Vertrauen
16	All	Mittleres Vertrauen
17	All	Hohes Vertrauen
18	All	Sehr hohes Vertrauen
19	All	Übertrifft die maximalen ACS-Challenges
20	All	Nichtzahlungstransaktion wird nicht unterstützt
21	All	3RI-Transaktion wird nicht unterstützt
22	All	Technisches Problem beim ACS
23	All	Entkoppelte Authentifizierung von ACS erforderlich, aber nicht von 3DS Requestor angefordert
24	All	3DS Requestor entkoppelte maximale Ablaufzeit überschritten
25	All	Der entkoppelten Authentifizierung wurde nicht genügend Zeit zur Verfügung gestellt, um den Karteninhaber zu authentifizieren. ACS wird keinen Versuch unternehmen
26	All	Die Authentifizierung wurde versucht, aber vom Karteninhaber nicht durchgeführt
80	Visa	Fehler beim Verbinden zum ACS
80	Mastercard	Wird bei allen Nur-Daten-Authentifizierungen zurückgegeben
80	American Express	Safekey ist für diesen Kartentyp nicht verfügbar
81	Visa	ACS-Zeitüberschreitung
81	Mastercard	Herausforderungsbefreiung akzeptiert
82	Visa	Ungültige Antwort vom ACS
82	Mastercard	Challenge-Mandat angefordert, konnte aber nicht ausgeführt werden.
83	Visa	Systemfehlerantwort vom ACS
83	Mastercard	DS hat den von DS erhaltenen ReasonCode gelöscht
84	Visa	Interner Fehler beim Generieren von CAVV
84	Mastercard	ChallengeCancel wurde gesetzt, daher wird nicht Smart Authentication Stand-In (Trifft Authentifizierungsentscheidung, wenn ACS nicht verfügbar ist) weitergeleitet.
85	Visa	VMID ist für das angeforderte Programm nicht geeignet
86	Visa	Protokollversion, die nicht vom ACS unterstützt wird
87	Visa	Die Transaktion ist von der Verarbeitung von Versuchen ausgeschlossen (einschließlich nicht wiederaufladbarer Prepaid-Karten und Nichtzahlungen (NPA))
88	Visa	Angefordertes Programm wird von ACS nicht unterstützt

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

Code	Bedingung
M	Obligatorisch. Bedeutet, dass das Datenelement in der Nachricht enthalten sein soll.
O	Optional. Das Datenelement kann oder kann nicht in einer Nachricht enthalten sein.
C	Conditional. Das Datenelement soll enthalten sein (d.h. obligatorisch), wenn angegebene Bedingungen erfüllt sind.

Definitionen

Begriff	Definition
Autorisierung	Eine Autorisierung ist eine Genehmigung oder Garantie von Geldmitteln durch den Kartenaussteller an den Acquirer.
Autorisierungs-Avis	Der Acquirer informiert den Kartenaussteller über eine bereits gegebene Autorisierung (z.B. Stimmenautorisierung).
Buchung	Buchung ist der Prozess des Verbindes von genehmigtem Betrag und Autorisierungs-Code einer Transaktion zur Umwandlung in einen abrechenbaren Transaktions-Datensatz. Im Wesentlichen ist es die Anweisung, die Geldmittel vom Konto des Schuldners abzuziehen. Der Acquirer übermittelt nromalerweise eine Buchungsdatei an das Kartennetzwerk (duales Nachrichtensystem). In Systemen mit Host-Buchung sendet der Händler normalerweise eine Nachricht Buchungs-Avis an den annehmenden Host. Bei Systemen mit Terminal-Buchung übermittelt entweder der Kartenakzeptant (z.B. Händler) eine Buchungsdatei (am gebräuchlichsten) zum Acquirer oder führt einen Batch-Upload aus. Die vom Kartenakzeptanten übermittelten Buchungsdatensätze werden üblicherweise beim annehmenden Host validiert und dann zur Buchungsdatei des Acquirers für das entsprechenden Kartennetzwerk hinzugefügt.
Verkauf	Ein Verkauf ist eine Anweisung vom Händler an den Acquirer, in einer einzelnen Nachricht eine Autorisierung sowie eine Buchung der am Verkaufspunkt abgeschlossenen Transaktion anzufordern. Das bedeutet, eine erfolgreiche Autorisierung wird automatisch ohne weitere Anweisungen oder Abschlussnachrichten zur Buchungsdatei des Acquirers hinzugefügt. Einige Systeme mit Terminal-Buchung können jedoch erfordern, dass Verkaufs-Transaktionen in die Buchungsdatei oder in den Bacth-Upload einbezogen werden.
Terminal-Buchung	Terminal-Buchung bedeutet, dass das Terminal Autorisierungen, Verkäufe und Stornierungen den ganzen Tag über an den Host übermittelt. Das Terminal speichert alle diese Transaktionen ebenso wie alle lokal (offline) ausgeführten Transaktionen, so dass das Terminal am Ende des Verarbeitungstages vom Händler eine Batch-Übermittlung ausführen kann. Verarbeitung per Terminal-Buchung gibt dem Händler die Möglichkeit, Offline-Transaktionen auszuführen, die nur im Batch enthalten sind. Offline-Transaktionen umfassen zum Beispiel Rückgaben, Zwischenverkäufe und Trinkgeldkorrekturen.
Host-Buchung	Bei der Verarbeitung mit Host-Buchung werden die Transaktions-Batches vom annehmenden Host verwaltet. Händler übermitteln die Transaktionen so zum Host, wie sie am Verkaufspunkt erfolgen, und der Host zeichnet die Transaktionen in einer Batch-Datei auf. In Nachrichtenprotokollen auf Basis von ISO 8583 wird das oft als Buchungs-Avis bezeichnet. Die Batchdatei wird dann entweder auf Anforderung vom Händlersystem (manuelle Batch-Freigabe) oder jeden Tag zu einer geplanten Zeit geschlossen (Host Auto-close). Die Option Auto-close ist am gebräuchlichsten.
Wiederkehrend	Wiederkehrende Transaktionen sind eine Reihe von Transaktionen, die nach einer Vereinbarung zwischen dem Karteninhaber und einem Händler verarbeitet werden, wobei der Karteninhaber über einen Zeitraum Waren oder Dienstleistungen in einer Reihe separater Transaktionen erwirbt.
Ratenzahlung	Ratenzahlungs-Transaktionen sind ein einzelner Kauf von Waren oder Dienstleistungen, die dem Konto des Karteninhabers in mehreren Teilen über einen Zeitraum berechnet werden, der zwischen dem Karteninhaber und einem Händler vereinbart worden ist.

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:

Position	Bedeutung	Beispiel
Digit 1	Zeigt den Statuscode / Fehlercode an	`2`
Digit 2 .. 4	Zeigt das betroffene Modul an	`206`
Position 5 .. 8	Zeigt den betroffenen Parameter an, der den Fehler verursacht	`0203 or 014H`

Ziffer 1: Statuscode oder Fehlercode

Digit 1	Bedeutung	Beschreibung
0	Ok	Operation erfolgreiche abgeschlossen
2	Fehler	Operation gescheitert
4	Fataler Fehler	Operation gescheitert und verarbeitete Daten möglicherweise verloren
6	Temporärer Status	Operation ist nicht abgeschloissen. Der endgültige Status wird asynchron übertragen.
7	EMV 3DS Info	Zwischenzustände in der EMV 3DS Sequenz

Digits 2..4: Common modules

Digit 2..4	Beschreibung
001	Paygate-Kryptographie (Ver- und Entschlüsselung)
010	Paramater fehlt
011	Parameter Formatfehler
012	Parameter ist nicht erlaubt
013	Parameter ist zu kurz
014	Parameter ist zu lang
015	Parameter Wert fehlt
016	Parameter Wert unbekannt oder nicht erlaubt
017	Parameter ist bereits angegeben
018	Parameter ist abgelaufen oder nicht mehr gültig
019	Parameter ist nicht erlaubt für aktuelle Message-Version
020 – 0FF	Paygate intern
100 – FFF	Betroffenes Modul

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)

Status	Kategorie	Detail	Beschreibung
2	xxx	0101	Empfangene Nachricht ungültig
2	xxx	0102	Nachrichten-Versionsnummer nicht unterstützt
2	xxx	0103	Limit gesendete Nachrichten erreicht. Nur für PReq verwendet
2	xxx	0201	Erforderliches Element fehlt
2	xxx	0202	Critical message extension not recognized
2	xxx	0203	Format bei einem oder mehreren Elementen ist gemäß Spezifikationen ungültig
2	xxx	0204	Doppeltes Datenelement
2	xxx	0301	Transaktions-ID nicht erkannt
2	xxx	0302	Fehler der Datenentschlüsselung
2	xxx	0303	Zugriff verweigert, ungültiger Endpunt
2	xxx	0304	ISO-Code ungültig
2	xxx	0305	Transaktionsdaten ungültig
2	xxx	0306	Händler-Kategoriecode ist für das Zahlungssystem ungültig
2	xxx	0307	Seriennummer ungültig
2	xxx	0402	Zeitüberschreitung der Transaktion
2	xxx	0403	Kurzzeitiger Systemausfall
2	xxx	0404	Permanenter Systemausfall
2	xxx	0405	Systemverbindungsfehler
2	xxx	0911	Spezifischer Fehlercode von UnionPay. Vorhanden, wenn die Datenfelder-Relevanzprüfung scheitert (ECI-Wert und AV-Erscheinungsbild sind inkonsistent mit dem Transaktionsstatus).
2	xxx	0912	Spezifischer Fehlercode von UnionPay. Vorhanden bei duplizierter Transaktions-ID (Die Transaktions-ID sollte für alle AReq-Anfragen eindeutig sein).
2	xxx	0985	3DS 2.0 wird von der Karte nicht unterstützt. Der Händler muss dem Fallback-Prozess folgen.
2	xxx	3002	Ungültiger Parameter BROWSERINFO
2	xxx	3006	Ungültiger Parameter BILLINGADDRESS
7	000	0000	3DS 2.0 Versionierung erfolgreich
7	000	0001	Authentisierungs-Antwort –> Challenge vorgeschrieben

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:

Allgemeine technische Anpassungen (für alle Händler relevant)
Anwendungsfälle für Transaktionskennzeichnung (unterschiedliche Behandlung je nach Händler-Szenario)
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:

 <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 –>

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

</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

ECI	Beschreibung	3DS Version(s)	Merchant Liability Shift
05	Karteninhaber-Authentifizierung erfolgreich (dies schließt eine erfolgreiche Authentifizierung mit risikobasierter Authentifizierung und / oder einem dynamischen Kennwort ein)	3DS 1.0 EMV 3DS (2.0)	Yes
06	Der Händler hat versucht, den Karteninhaber zu authentifizieren Für 3DS 1.0.2 kann der ECI Wert 06 nach Ermessen des Issuers als Authentifizierungsantwort vom Issuer-ACS verwendet werden. Beispielsweise können Issuer, die eine risikobasierte Authentifizierung verwenden, einen ECI = 06 für eine Transaktion bereitstellen, für die keine Karteninhaber-Authentifizierung erforderlich ist. Dies wird auch als “frictionless” Authentifizierung bezeichnet. Diese Issuer können einen ECI = 05 für Transaktionen vorsehen, die erfolgreich zur Authentifizierung aufgefordert wurden. Bei 3DS 2.0 kann der ECI 06-Wert nur verwendet werden, um anzuzeigen, dass ein Händler versucht hat, den Karteninhaber zu authentifizieren.	3DS 1.0 EMV 3DS (2.0)	Yes
07	Nicht authentifizierte E-Commerce-Transaktion technische Probleme Konfigurationsfehler Kreditkarte und kartenausgebende Bank nehmen nicht an 3-D Secure teil.	3DS 1.0 EMV 3DS (2.0)	No

Mastercard

ECI	Beschreibung	3DS Version(s)	Merchant Liability Shift
00	Nicht authentifizierte E-Commerce-Transaktion technische Probleme Konfigurationsfehler Kreditkarte und kartenausgebende Bank nehmen nicht an 3-D Secure teil.	3DS 1.0 EMV 3DS (2.0)	No
01	Der Händler hat versucht, den Karteninhaber zu authentifizieren und hat einen Authentifizierungswert (Accountholder Authentication Value (AVV)) erhalten.	3DS 1.0 EMV 3DS (2.0)	Yes
02	Karteninhaber-Authentifizierung erfolgreich (dies schließt eine erfolgreiche Authentifizierung mit risikobasierter Authentifizierung und / oder einem dynamischen Kennwort ein)	3DS 1.0 EMV 3DS (2.0)	Yes
04	Nur Datenaustausch: Nicht authentifizierte E-Commerce-Transaktion, aber der Händler hat beschlossen, Daten über den 3DS-Fluss mit dem Issuer zu teilen, um die Genehmigungsrate für die Autorisierung zu verbessern	EMV 3DS (2.0)	No
06	Acquirer Ausnahme	EMV 3DS (2.0)	No
07	Wiederkehrende Zahlungen können für die erste oder nachfolgende Transaktion gelten Wenn dieser Wert bei der initialen wiederkehrenden Zahlungen eingeht, hat der Händler eine Haftungsumkehr Nachfolgende Transaktionen gelten als MIT und die Haftung verbleibt beim Händler	EMV 3DS (2.0)	Yes

10 transStatusReason Codes

Code	Scheme	Beschreibung
01	All	Kartenauthentisierung fehlgeschlagen
02	All	Unbekanntes Gerät
03	All	Nicht unterstütztes Gerät
04	All	Überschreitet das Authentifizierungshäufigkeitslimit
05	All	Abgelaufene Karte
06	All	Ungültige Kartennummer
07	All	Ungültige Transaktion
08	All	Kein Karteneintrag
09	All	Sicherheitsfehler
10	All	Gestohlene Karte
11	All	Betrugsverdacht
12	All	Transaktion für Karteninhaber nicht erlaubt
13	All	Karteninhaber ist nicht im Dienst registriert
14	All	Zeitüberschreitung der Transaktion beim ACS
15	All	Geringes Vertrauen
16	All	Mittleres Vertrauen
17	All	Hohes Vertrauen
18	All	Sehr hohes Vertrauen
19	All	Übertrifft die maximalen ACS-Challenges
20	All	Nichtzahlungstransaktion wird nicht unterstützt
21	All	3RI-Transaktion wird nicht unterstützt
22	All	Technisches Problem beim ACS
23	All	Entkoppelte Authentifizierung von ACS erforderlich, aber nicht von 3DS Requestor angefordert
24	All	3DS Requestor entkoppelte maximale Ablaufzeit überschritten
25	All	Der entkoppelten Authentifizierung wurde nicht genügend Zeit zur Verfügung gestellt, um den Karteninhaber zu authentifizieren. ACS wird keinen Versuch unternehmen
26	All	Die Authentifizierung wurde versucht, aber vom Karteninhaber nicht durchgeführt
80	Visa	Fehler beim Verbinden zum ACS
80	Mastercard	Wird bei allen Nur-Daten-Authentifizierungen zurückgegeben
80	American Express	Safekey ist für diesen Kartentyp nicht verfügbar
81	Visa	ACS-Zeitüberschreitung
81	Mastercard	Herausforderungsbefreiung akzeptiert
82	Visa	Ungültige Antwort vom ACS
82	Mastercard	Challenge-Mandat angefordert, konnte aber nicht ausgeführt werden.
83	Visa	Systemfehlerantwort vom ACS
83	Mastercard	DS hat den von DS erhaltenen ReasonCode gelöscht
84	Visa	Interner Fehler beim Generieren von CAVV
84	Mastercard	ChallengeCancel wurde gesetzt, daher wird nicht Smart Authentication Stand-In (Trifft Authentifizierungsentscheidung, wenn ACS nicht verfügbar ist) weitergeleitet.
85	Visa	VMID ist für das angeforderte Programm nicht geeignet
86	Visa	Protokollversion, die nicht vom ACS unterstützt wird
87	Visa	Die Transaktion ist von der Verarbeitung von Versuchen ausgeschlossen (einschließlich nicht wiederaufladbarer Prepaid-Karten und Nichtzahlungen (NPA))
88	Visa	Angefordertes Programm wird von ACS nicht unterstützt

Name	Anbieter	Zweck	Ablauf
cookie_status	www.firstcashsolution.de	Speichert Ihren Zustimmungsstatus für Cookies auf der aktuellen Domäne.	1 Jahr
pll_language	www.firstcashsolution.de	Speichert Ihre Spracheinstellungen.	1 Jahr
PHPSESSID	www.firstcashsolution.de	In diesem Cookie wird die Session-ID, also eine zufällig generierte Identifikationsnummer für Ihre Sitzung, gespeichert. Dieser Cookie wird – abhängig von Ihrer Browser-Einstellung – beim Schließen eines Tabs oder Fensters, das diesen Cookie gesetzt hat, gelöscht. Dadurch ist es zum Beispiel möglich, zuvor bereits ausgefüllte Felder eines Formulars vom Browser automatisch eintragen zu lassen.	Session
wordpress_test_cookie	www.firstcashsolution.de	Prüft ob Cookies gesetzt werden können	1 Jahr
pum-*	www.firstcashsolution.de	Speichert die Information welches PopUp geschlossen wurde	1 Monat

01	02	03	04	05	06	07	08	09	10	11	12	13	14	15	16	17	18	19	20	21	22
G	R	E	A	T		B	R	A	N	D		L	T	D	*	0	8	1	5	3	7

01	02	03	04	05	06	07	08	09	10	11	12	13	14	15	16	17	18	19	20	21	22
H	.	C	A	L	I	F	O	R	N	I	A		N	O		S	H	O	W

01	02	03	04	05	06	07	08	09	10	11	12	13	14	15	16	17	18	19	20	21	22
F	L	Y		L	O	W		P	L	C		1	2	3	4	5	6	7	8	9	0

01	02	03	04	05	06	07	08	09	10	11	12	13	14	15	16	17	18	19	20	21	22
G	R	E	A	T		B	R	A	N	D		L	T	D	*	0	8	1	5	3	7

01	02	03	04	05	06	07	08	09	10	11	12	13	14	15	16	17	18	19	20	21	22
H	.	C	A	L	I	F	O	R	N	I	A		N	O		S	H	O	W

01	02	03	04	05	06	07	08	09	10	11	12	13	14	15	16	17	18	19	20	21	22
F	L	Y		L	O	W		P	L	C		1	2	3	4	5	6	7	8	9	0

EMV 3D-Secure

1 EMV 3-D Secure

1.1 Regulatorische Anforderungen

1.1.1 EBA Mandat

1.1.2 3D-Secure 2.0

1.1.3 Haftungsverschiebung

1.1.4 3DS 2.0 und Compliance mit der DSGVO

1.1.5 Ausnahmen und Ausklammerungen der PSD2 SCA

1.2 Das 1cs Online Bezahlsystem

1.2.1 Authentisierungs-Optionen

1.2.2 Message Version 2

1.2.3 Handhabung von Soft decline

1.2.3.1 Whitelisting von vertrauenswürdigen Begünstigten

1.2.3.3 Transaktionen mit geringem Wert

1.2.3.4 Transaktionsrisikoanalyse

1.2.3.5 One-Leg-Out-Transaktionen

2 Integrationsmethoden

2.1 Hosted Payment Pages (paySSL)

Zahlungsanfrage

Kreditkartenzahlung mit separater Autorisierung

2.2 Server-2-Server Integration

2.2.1 3DS 1.0 Fallback

2.3 Stille Auftragserteilung (PayNow)

3 JSON Objekte

4 Wichtige Hinweise

4.1 3DS Authentication Hosting

4.2 Amazon Payments MFA

Überblick

Änderungen

Neue JavaScript-Funktion confirmationFlow()

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

AmazonAPA.aspx

Benutzer-Ablauf und Sequenzen

Ablauf

4.3 Dynamische Rechnungs-Deskriptoren

Formatierung des Händlernamens

Kauf von Waren oder Dienstleistungen

4.4 Hinterlegte Zugangsdaten

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

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

Amount

credentialOnFile

AccVerify

4.4.2 Verzögerte Lieferung

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

UCOF MIT

4.5 Konto-Verifizierung

3DS und Konto-Verifizierung

Hinterlegte Zugangsdaten

Unabhängige Konto-Verifizierung

4.6 Mehrparteien-E-Commerce / Agenten-Modell

VISA

Händler im Reise- und Gastgewerbe

Andere Händler

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

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

4.9 schemeReferenceID

5 Test-Karten

Einmal-Passwörter (OTPs)

transStatus

transStatusReason

6 Begriffe und Definitionen

Obligatorische und bedingte Datenelemente

Bedingungs-Codes

Definitionen

7 Antwort-Codes

Allgemeine Hinweise zu Paygate-Fehlercodes

Digits 2..4: Common modules

Digits 2..4: Common modulesKategotie (2-4)

Detail (5-8)

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

Allgemeine technische Anpassungen

Welche Anfragearten betrifft 3D-Secure 2.0/SCA?

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

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

Die Verwendung von JSON-Objekten wird Pflicht

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

Schlüssel Parameter / Objekt

Anwendungsfälle für Transaktions-Kennzeichnung

Szenario 01 – Kreditkarten-Einmalzahlung

Digits 2..4: Common modules

Kategotie (2-4)

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

01	02	03	04	05	06	07	08	09	10	11	12	13	14	15	16	17	18	19	20	21	22
G	R	E	A	T		B	R	A	N	D		L	T	D	*	0	8	1	5	3	7

01	02	03	04	05	06	07	08	09	10	11	12	13	14	15	16	17	18	19	20	21	22
H	.	C	A	L	I	F	O	R	N	I	A		N	O		S	H	O	W

01	02	03	04	05	06	07	08	09	10	11	12	13	14	15	16	17	18	19	20	21	22
F	L	Y		L	O	W		P	L	C		1	2	3	4	5	6	7	8	9	0