EMV 3D-Secure

1.1 Regulatorische Anforderungen

1.1.1 EBA Mandat

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

1.1.2 3D-Secure 2.x

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.x 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.x 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.x 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.x und Compliance zur 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.x 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.x 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.

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

2.1.1 Vereinfachtes Sequenz Diagramm

2.1.2 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 1cs OBS alle Zahlungsanfragen mit Formatfehlern ab. Bitte übergeben Sie deshalb bei jedem Parameter den korrekten Datentyp.

Die folgende Tabelle beschreibt die verschlüsselten Übergabeparameter:

Key	REST		Format	Bedingnung	Beschreibung
MerchantID	BasicAuth.Username		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	„transactionId“: „…“		ans..64	M	Ihre eigene TransaktionsID, die für jede Zahlung eindeutig sein muss
ReqId	„requestId“: „…“		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	„referenceNumber“: „…“		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	„amount“: { „value“: …}		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	„amount“: { „currency“: „…“}		a3	M	Währung, drei Zeichen DIN / ISO 4217, z.B. EUR, USD, GBP. Hier eine Übersicht: Währungstabelle
Capture	„capture“: {„auto“: „Yes“} „capture“: {„manual“: „Yes“} „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	„payment“: {„cardForm“: { „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	„billing“: {„addressInfo“: { „descriptor“: „…“ }}		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	„order“: {„description“: „…“}		ans..768	O	Beschreibung der gekauften Waren, Einzelpreise etc.
AccVerify	„payment“: {„card“: { „accountVerification“: „…“ }}		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	„payment“: {„card“: { „threeDsPolicy“: JSON }}		JSON	O	Objekt, das Authentisierungs-Richtlinien und Vorgaben für die Ausnahmenbehandlung festlegt.
priorAuthenticationInfo	„payment“: {„card“: { „priorAuthenticationInfo“: JSON }}		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	„accountInfo“: JSON		JSON	O	Das Objekt Kontoinformationen enthält optionale Informationen über das Kundenkonto beim Händler.
billToCustomer	„billing“: JSON		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	„shipping“: JSON		JSON	C	Der Kunde, an den die Waren und / oder Dienstleistungen gesendet werden. Erforderlich, falls von billToCustomer abweichend.
billingAddress	„billing“: {„addressInfo“: JSON}		JSON	C	Rechnungsadresse. For EMV 3DS erforderlich (falls verfügbar), sofern nicht Markt- oder Regionalmandate die Übermittlung dieser Infomrationen beschränken.
shippingAddress	„shipping“: {„addressInfo“: JSON}		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	„credentialOnFile“: JSON		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	„riskIndicator“: JSON		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	„subMerchantPaymentFacilitator“: JSON		JSON	O	Objekt, das die Details des SubMerchant (Payment Facilitator) angibt. Wird ausschließlich von SafeCharge unterstützt.
URLSuccess	„urls“: {„success“: „…“}		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	„urls“: {„failure“: „…“}		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	„urls“: {„cancel“: „…“}		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	„urls“: {„notify“: „…“}		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	„metadata[userData]“: „…“		ans..1024	O	Wenn beim Aufruf angegeben, übergibt das 1cs Online Bezahlsystem die Parameter mit dem Zahlungsergebnis an den Shop.
Custom	„metadata“: „…“		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	„metadata[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	„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.

Das Kreditkarten-Formular kann mittels eines eigenen Templates sehr stark angepasst werden. 

Details hierzu finden Sie hier: Corporate PayPage und Templates

2.1.3 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

2.1.4 Kreditkartenzahlung mit separater Autorisierung

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

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

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

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

Die folgende Tabelle beschreibt die verschlüsselten Übergabeparameter:

Zusatzparameter für Kreditkartenzahlung mit separater Autorisierung

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

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

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

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

Die folgende Tabelle beschreibt die verschlüsselten Übergabeparameter:

Parameter für Kreditkartenzahlungen über authorize.aspx


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

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

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

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

2.1.5 Erweitertes Sequenz-Diagramm

2.2 Server-2-Server Integration

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

Server-2-Server Sequenzdiagramm

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 (Fehlercodes)
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.

Netcetera 3DS Web SDK
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>

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 (Fehlercodes)
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">

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

</form>

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

3DS Challenge-Anfrage initialisieren – Beispiel

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

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

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.

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
WIederkehrende Zahlungsdaten
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)

2.3.1 Ü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.

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

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

Sequenzdiagramm

2.3.2 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.

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.

2.3.3. HTTP POST an URLSuccess / URLFailure / URLNotify

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.

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

4.2.1 Ü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.

4.2.2 Ä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.

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.

4.2.3. 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

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

Option 3: MFA-Fehler

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.

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

No-Show-Transaktionen

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

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

Alle folgenden Dinge müssen enthalen sein:

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

4.4 Hinterlegte Zugangsdaten

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

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

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

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.

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.

Beachten Sie bitte, dass Sie mit jeder anfänglichen CIT, welche ein Mandat für nachfolgende MITs einrichtet, eine schemeReferenceID erhalten, die bei nachfolgenden Transaktionen übergeben werden muss, um die Sequenz 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 wurden (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)

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

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.5 Konto-Verifizierung

Eine auch als Nullwert-Autorisierung 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 für die Integrationen Server-2-Server und Silent Order Post optional. Andere bedingte Datenelemente sind eventuell auch nicht anwendbar.

4.6 Mehrparteien-E-Commerce / Agenten-Modell

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

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

VISA

Händler im Reise- und Gastgewerbe

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

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

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

1. innerhalb von 24 Stunden eine Konto-Verifizierung(d.h. AccVerify=Yes)mit den vom Agenten empfangenen Authentisierungsdaten durchführen.
2. wenn der Betrag nachfolgend fällig ist, eine als MIT gekennzeichnete Autorisierung senden einschließlich der schemeReferenceID von der vorherigen Konto-Verifizierung.

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

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

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

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

1. innerhalb von 24 Stunden eine Nullwert Konto-Verifizierung mit den vom Agenten erhalten Authentisierungswerten durchführen
2. wenn der Betrag nachfolgend fällig ist, eine als MIT gekennzeichnete Autorisierung senden einschließlich der schemeReferenceID von der vorherigen Konto-Verifizierung.

Andere Händler

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

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

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

a) Authentisierungswert (CAVV/AAV)

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

b) schemeReferenceID

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Im Gegensatz zur EMV 3DS Protokoll-Spezifikation:

A.1 Fehlende erforderliche Felder

. . .

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

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

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

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

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

4.9 schemeReferenceID

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.

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

10.1 Allgemeine technische Anpassungen

Welche Anfragearten betrifft 3D-Secure 2.x/SCA?

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

Wie sieht die Datenübertragung mit 3-D Secure 2.x aus?

• 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.x wählen?

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

Die Verwendung von JSON-Objekten wird Pflicht

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

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

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

JSON Beispiel-Anfrage – unverschlüsselte Request-Parameter

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

Schlüssel Parameter / Objekt

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

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

• Beispiel einer XML-Datei:

For each language used:

<strCCHolder>Cardholdername</strCCHolder>

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

JSON-Objekt – browserInfo

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

JSON-Objekt – accountInfo

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

JSON Objekt – customerInfo (billToCustomer | shipToCustomer)

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

JSON-Objekt – merchantRiskIndicator

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

10.2 Anwendungsfälle für Transaktions-Kennzeichnung

Szenario 05 – Kreditkarten Token speichern / Formular vorausfüllen – PayNow Schnittstelle

Die im folgenden Verlauf beschriebenen Abläufe unterliegen der Haftungsverschiebung für Sie als Händler.

• Sie bieten Ihren Kunden die Zahlung per Kreditkarte an
• Kunden kaufen in Ihrem Shop ein und Sie speichern die Kreditkartendaten in Form einer Pseudokartennummer

A: Wenn der Kunde wiederkommt, füllen Sie das Kreditkartenformular mit den gespeicherten Daten vor. Im Falle von CIT mit initial=false wird das Flagging verwendet, wenn der Händler die Pseudokartennummer über eine Template-Prefill-Option dem Kunden vorbelegt.

B: Wenn der Kunde wiederkommt, füllen Sie das Kreditkartenformular mit den gespeicherten Daten vor. Falls der Kunde die bestehende Kartennummer löscht und eine neue hinterlegt oder ggfs. eine weitere Karte hinzufügt, dann muss das Flagging für CIT erneut verwendet werden (initial=true), sofern der Kunde diese Karte auch vorbelegt haben möchte.

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

• Gilt für 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:

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

• Gilt für 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

}

XSL
<!-- Hiddenfield, which tells Paygate that prefill function should get activated -->
<!-- value="on" means that Paygate will return 'prefill=on' in the response to merchant -->
<!-- value=""  means that Paygate will not return 'prefill=on' in the response to merchant -->
<input type="hidden" name="prefill"><xsl:attribute name="value"><xsl:value-of select="paygate/prefill"/></xsl:attribute></input>
 
<!-- Checkbox to (de)activate prefill function -->
 <div id="div_cbPrefill" class="div_cbPrefill">
  <input type="checkbox" name="cbPrefill" id="cbPrefill"></input>
  <span><xsl:value-of select="paygate/language/strCCSaveData" disable-output-escaping="yes"/></span>
  <div class="row"></div>
 </div>

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.X

Nutzen Sie die Chance, jetzt 3D Secure 2.x 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.