Wir nutzen Cookies zu unterschiedlichen Zwecken, unter anderem zur Analyse und für personalisierte Marketing-Mitteilungen. In unseren Cookie-Richtlinien erfahren Sie, wie wir Cookies verwenden.Datenschutzhinweise Impressum
Notwendig
Statistik
Notwendig Technisch notwendige Funktionen, wie das speichern Ihrer Cookie-Einstellungen für diese Website.
Statistik Statistik- und Marketing-Tools betreiben zu können um zu verstehen, wie Seitenbesucher die Website benutzen und um Optimierungen für Sie umsetzen zu können.
Details zu den Cookies
Notwendig
Name
Anbieter
Zweck
Ablauf
cookie_status
www.firstcashsolution.de
Speichert Ihren Zustimmungsstatus für Cookies auf der aktuellen Domäne.
1 Jahr
pll_language
www.firstcashsolution.de
Speichert Ihre Spracheinstellungen.
1 Jahr
PHPSESSID
www.firstcashsolution.de
In diesem Cookie wird die Session-ID, also eine zufällig generierte Identifikationsnummer für Ihre Sitzung, gespeichert. Dieser Cookie wird – abhängig von Ihrer Browser-Einstellung – beim Schließen eines Tabs oder Fensters, das diesen Cookie gesetzt hat, gelöscht. Dadurch ist es zum Beispiel möglich, zuvor bereits ausgefüllte Felder eines Formulars vom Browser automatisch eintragen zu lassen.
Session
wordpress_test_cookie
www.firstcashsolution.de
Prüft ob Cookies gesetzt werden können
1 Jahr
pum-*
www.firstcashsolution.de
Speichert die Information welches PopUp geschlossen wurde
1 Monat
Statistik
Name
Anbieter
Zweck
Ablauf
{individuelle_nummer}
etracker.com
Speichert eine anonymisierte ID um nachzuverfolgen, welche Seiten angesehen wurden.
Die Europäische Bankenaufsichtsbehörde (EBA) hat angeordnet, dass alle Zahler, die online auf ihr Zahlungskonto zugreifen und elektronische Zahlungstransaktionen über einen Remote-Kanal auslösen, beginnend ab 14. September 2019 stark authentisiert werden müssen (alias Strong Customer Authentication (SCA)). Die Kartenorganisationen haben diese Möglichkeit ergriffen, um das etablierte Protokoll 3D-Secure für die Karteninhaber-Authentisierung zu überarbeiten und mehrere Probleme anzugehen, welche die Annahme im Markt gebremst haben.
1.1.2 3D-Secure 2.0
Bisher hatten Internethändler die Wahl, dem Karteninhaber eine Challenge (z.B. TAN / Passwort) zu präsentieren oder 3DS gänzlich zu übergehen. Einige haben einen dynamischen Ansatz basierend auf dem PSP oder der eigenen Risikobewertung gewählt, aber viele Händler schätzten einen reibungslosen Kassenvorgang und hohe Konversionsraten mehr als die möglichen Vorteile einer Haftungsverschiebung. Die Gesamtstrategie der Kartenorganisationen für 3DS 2.0 ist es, Reibereien durch eine verbesserte Erfahrung der Karteninhaber (Geräte-Bewusstsein) zu verringern und Ausnahmen von der SCA basierend auf einer robusten Transaktionsrisikoanalyse (TRA) auszunutzen mit dem obersten Ziel, optimale Autorisierungsleistung und Konversionsraten zu erreichen. Daher ist die TRA entscheidend für reibungslose Zahlungsabläufe für Remote-Transaktionen mit geringem Risiko. Deshalb hat das Protokoll 3DS 2.0 eine Unmenge zusätzlicher Datenpunkte eingeführt, die dem Kartenherausgeber zur Unterstützung der Transaktionsrisikoanalyse und für die Anwendung von Ausnahmen der SCA übermittelt werden können.
SCA wird erforderlich, wenn:
die Transaktion nicht außerhalb des Geltungsbereichs der PSD2 RTS ist
keine Ausnahme der PSD2 SCA für eine Zahlungstransaktion zutrifft
eine Karte zu einer Händler-Datenbank hinzugefügt wird (hinterlegte Karte)
eine Vereinbarung für wiederkehrende Zahlungen über feste oder variable Beträge beginnt, einschließlich der Festlegung des anfänglichen Mandats für vom Händler ausgelöste Transaktionen (MIT)
eine Vereinbarung für wiederkehrende Zahlungen zu einem höheren Betrag geändert wird (beispielsweise ein Premium-Angebot)
ein White-Listing eingerichtet wird (oder zum Ansehen/Ändern von White-Lists)
ein Gerät mit einem Karteninhaber verknüpft wird
1.1.3 Haftungsverschiebung
Als Daumenregel gilt, wenn die Authentisierung des Karteninhabers über 3-D Secure erfolgt ist, sind Händler normalerweise vor Streitigkeiten bezüglich Betruges im E-Commerce geschützt und die Haftung verschiebt sich vom Händler / Acquirer zum Kartenherausgeber. Es gibt jedoch Ausnahmen vom Schutz des Händlers vor Streitigkeiten. Im Kontext von 3DS 2.0 sind Händler regelmäßig nicht geschützt, falls gewährte Ausnahmen gemäß PSD2 RTS aktiv vom Händler / Acquirer angefragt worden sind.
Das folgende Diagramm zeigt Optionen und Haftungen unter den Anforderungen von PSD2 RTS gemäß MasterCard.
1.1.4 3DS 2.0 und Compliance mit der DSGVO
Karteninhabern müssen ausführliche Informationen darüber gegeben werden, wie ihre Daten erfasst, verarbeitet und verwendet werden. Das kann über eine Datenschutzerklärung erreicht werden, die mindestens die Arten der verarbeiteten Daten, den Zeck ihrer Verarbeitung, die verwendeten Daten usw. enthält. Kartenorganisationen und Kartenherausgeber verwenden die EMV 3DS Daten für keinen anderen Zwecke als Betrugsprävention und Authentisierung. Das schließt die Verwendung persönlicher Daten für andere Zwecke wie Verkauf, Marketing und Data-Mining (außer zur Betrugsprävention) aus.
1.1.5 Ausnahmen und Ausklammerungen der PSD2 SCA
Gemäß den technischen Regulierungsstandards (RTS) gibt es einige wichtige Ausnahmen der SCA, die unter verschiedenen Bedingungen gelten können, welche im folgenden Diagramm dargestellt sind.
1.2 Das 1cs Online Bezahlsystem
1.2.1 Authentisierungs-Optionen
Einem Acquirer kann erlaubt sein, infolge geringer Betrugsraten und TRA die SCA nicht anzuwenden. Für diese Ausnahmen gibt es verschiedene Optionen zur Verarbeitung, die im folgenden Diagramm dargestellt sind.
Hinweis: Standardmäßig schlägt die First Cash Solution anwendbare Ausnahmen (sofern unterstützt) im EMV 3DS Authentisierungsablauf dem Kartenherausgeber vor, um die bestmöglichen Zustimmungsraten der Autorisierung zu erreichen.
EBA-Op-2018-04, Paragraph 47 – Klarstellung zu PSP (Acquirer-Betrugsraten)
Die Betrugsrate ist im Anhang A der RTS definiert und wird für alle Überweisungs-Transaktionen und alle Kartenzahlungen berechnet und kann nicht pro einzelnem Zahlungsempfänger (z.B. Händler) oder pro Kanal (entweder App oder Web-Schnittstelle) definiert werden. Die Betrugsrate, die bestimmt, ob sich ein PSP für die SCA-Ausnahme qualifiziert oder nicht, kann nicht nur für bestimmte Händler berechnet werden, d.h. wenn der Zahler eine Zahlung an einen bestimmten Händler leisten möchte und dieser bestimmte Händler eine Betrugsrate unter dem Grenzwert hat. Während der PSP (Acquirer) des Zahlungsempfängers vertraglich vereinbaren kann, die Überwachung seiner Transaktionsrisikoanalyse an einen gegebenen Händler ‘outzusourcen’ oder nur bestimmten vordefinierten Händlern erlauben kann, von den Vorteilen von dieser PSP-Ausnahme zu profitieren (basierend auf einer vertraglich vereinbarten geringen Betrugsrate), muss die Betrugsrate, welche einen bestimmten PSP für eine Ausnahme gemäß Artikel 18 geeignet macht, dennoch auf Basis der ausgeführten oder akquirierten Transaktionen vom PSP des Zahlungsempfängers berechnet werden und nicht ausgehend von den Transaktionen des Händlers.
1.2.2 Message Version 2
Um die Menge der zusätzlichen zahlungsfremden Daten zu handhaben und die Abwärtskompatibilität soweit wie möglich zu erhalten, hat sich die First Cash Solution dafür entschieden, seine 1cs OBS-Kartenschnittstelle über den zusätzlichen Parameter MsgVer zu versionieren. Die aktualisierte API basiert weiterhin auf Schlüssel-Wert-Paaren, aber setzt stark auf Base64-codierte JSON-Objekte zur Unterstützung der Lesbarkeit und Skript-Nutzung auf der Client-Seite.
Händler können weiterhin unsere klassische Schnittstelle für Anfragen auch mit 3DS 2.0 verwenden, aber es gibt ein paar Einschränkungen:
Viele zusätzliche Datenpunkte für die Risikoanalyse des Kartenherausgebers sind nicht verfügbar und daher kann die Quote der reibungslosen Transaktionen geringer sein
Antworten und Benachrichtigungen der API enthalten neue JSON-Objekte, um für die Spezifikationen des Protokolls 3DS 2.0 zu sorgen und erfordern eine Modifikation vorhandener Händler-Integrationen
Aus diesen Gründen ist es sehr empfohlen, auf die Version 2 zu aktualisieren.
1.2.3 Handhabung von Soft decline
Falls eine Transaktion keine SCA hat, können Kartenherausgeber mit einem sogenannten Soft decline reagieren. Das bedeutet, die Autorisierung der Transaktion wird vom Kartenherausgeber angelehnt, dieselbe Transaktion kann jedoch erneut initialisiert werden. Der Hauptgrund für Soft declines im Kontext von 3D Secure ist, dass Kartenherausgeber die vom Händler angefragten SCA-Ausnahmen nicht akzeptieren, wenn diese direkt zur Autorisierung gesendet werden oder wenn der eine Zahlung ohne zuvor durchgeführte Authentisierung anfordert. Die beste Methode ist es dann, die Zahlung mit 3DS neu zu starten.
Mit der Automatischen Handhabung von Soft Decline reagiert das 1cs OBS je nach Konfiguration auf eine Soft decline Antwort mit einem automatischen Neustart der Zahlung mit erzwungener SCA. Das 1cs OBS erzeugt dann automatisch eine neue Zahlung im Namen des Händlers und integriert den 3DS-Ablauf.
WICHTIG:
– Aus Sicht des Kunden bemerkt dieser keinen Unterschied und muss seine Kreditkartendaten nicht erneut eingeben. Der gesamte Prozess wird vom 1cs Online-Bezahlsystem gesteuert.
– Beachten Sie bitte, dass diese Lösung für Server-zu-Server Verbindungen nicht verfügbar ist, weil das 1cs Online-Bezahlsystem den Client (Browser) nicht zum Start des 3DS-Ablaufes steuern kann. Für Server-zu-Server-Verbindungen muss der Händler die Zahlung mit 3DS-Ablauf neu auslösen und vor allem die SCA-Challenge über den angegebenen Parameter JSON threeDSPolicy (challengePreference = mandateChallenge) erzwingen.
1.2.3.1 Whitelisting von vertrauenswürdigen Begünstigten
Ein Karteninhaber kann dafür optieren, einen Händler zu einer Liste vertrauenswürdiger Begünstigter hinzuzufügen, die beim Kartenherausgeber geführt wird, um diesen speziellen Händler bei zukünftigen Zahlungen von der SCA auszunehmen. Das passiert normalerweise während einer Challenge des Karteninhabers, aber Karteninhaber können beispielsweise auch über ihre Banking-App eine Liste vertrauenswürdiger Begünstigter verwalten.
Händler können von einer Whitelist-Ausnahme profitieren, wenn diese angefragt ist und wenn nicht anderweitig eine Challenge des Karteninhabers gefordert ist.
Beachten Sie bitte, dass die Whitelist-Funktion ab 3DS Version 2.2 und höher verfügbar ist. Derzeit unterstützten die Kartenherausgeber meistens 3DS 2.1.
1.2.3.3 Transaktionen mit geringem Wert
Kartenherausgeber können Transaktionen von der SCA ausnehmen, sofern die folgenden Bedingungen erfüllt sind:
der Zahlungsbetrag übersteigt nicht 30 Euro,
der kumulierte Betrag vorheriger Zahlungstransaktionen ohne SCA übersteigt nicht 100 Euro,
die Anzahl der vorherigen Zahlungstransaktionen ohne SCA übersteigt nicht fünf aufeinanderfolgende Zahlungstransaktionen.
Beachten Sie bitte, dass die Ausnahmen für geringen Wert angefragt werden müssen, um für einen reibungslosen Authentisierungs-Ablauf berücksichtigt zu werden.
1.2.3.4 Transaktionsrisikoanalyse
Acquirer und Kartenherausgeber dürfen auf die SCA verzichten, sofern die gesamte Betrugsrate nicht höher als die Referenz-Betrugsrate für den Ausnahmengrenzwert (ETV) ist, der in folgender Tabelle angegeben ist und wobei die risikobasierte Beurteilung jeder einzelnen Transaktion als geringes Risiko angesehen werden kann.
ETV
Kartenbasierte Zahlungen
EUR 500
1 bps
EUR 250
6 bps
EUR 100
13 bps
1.2.3.5 One-Leg-Out-Transaktionen
One-Leg-Out-Transaktionen sind solche Transaktionen, wo sich entweder der Zahlungsdienstleister des Zahlers oder der Zahlungsdienstleister des Empfängers außerhalb der Europäischen Union befindet.
Zahlungsdienstleister im Kontext kartenbasierter Transaktionen und im Geiste der PSD2 sind regelmäßig Acquirer und Issuer.
Daher sind weder die Nationalität des Karteninhabers noch der Geschäftsort des Händlers für die Beurteilung relevant, ob eine Transaktion infolge der Regel ‘one-leg-out’ außerhalb des Geltungsbereiches liegt.
2 Integrationsmethoden
2.1 Hosted Payment Pages (paySSL)
Bei Kartenzahlunen über bei der First Cash Solution gehostete Formulare wird die Komplexität von 3-D Secure vollständig bei der Implementierung beim Händler entfernt.
Aus Sicht des Händlers unterscheidet sich die Sequenz nicht zwischen Zahlungen, die mit 3DS authentisiert sind, sowie nicht mit 3DS authentisierten Zahlungen, welche die Berücksichtigung zusätzlicher Parameter in Aufruf und Antwort erfordern.
Hinweis zum Cookie-/Session Handling: Bitte beachten Sie, dass einige Browser beim Rücksprung zu Ihrem Shop erforderliche Cookies blockieren könnten. Hier finden Sie weitere Informationen und verschiedene Lösungsansätze.
Zahlungsanfrage
Zum Abruf eines First Cash Solution-Formulars für Kartenzahlungen übermitteln Sie bitte folgende Parameter über einen HTTP POST Aufruf an
Hinweis Aus Sicherheitsgründen lehnt das Paygate alle Zahlungsanfragen mit Formatfehlern ab. Bitte übergeben Sie deshalb bei jedem Parameter den korrekten Datentyp.
Die folgende Tabelle beschreibt die verschlüsselten Übergabeparameter:
Key
Format
Bedingnung
Beschreibung
MerchantID
ans..30
M
HändlerID, die von der First Cash Solution vergeben wird
MsgVer
ans..5
M
Message-Version.Wert: 2.0 Mit 3-D Secure 2.x wurde eine Vielzahl zusätzlicher Daten (Browser-Information, Rechnungs-/Versand-Adresse, …) erforderlich, um den Authentifizierungs-Prozess zu optimieren. Um diese Informationen zu handhaben, wurden die JSON-Objekte eingeführt. Der Parameter MsgVer zeigt an, dass diese Daten verwendet werden.
TransID
ans..64
M
Ihre eigene TransaktionsID, die für jede Zahlung eindeutig sein muss
ReqId
ans..32
O
Um Doppelzahlungen (z.B. durch ETM) zu vermeiden, übergeben Sie einen alphanumerischen Wert, der Ihre Transaktion oder Aktion identifiziert und nur einmal vergeben werden darf. Falls die Transaktion oder Aktion mit derselben ReqID erneut eingereicht wird, führt das 1cs OBS keine Zahlung oder weitere Aktion aus, sondern gibt nur den Status der ursprünglichen Transaktion oder Aktion zurück. Bitte beachten Sie, dass das 1cs OBS für die erste initiale Aktion einen abgeschlossenen Transaktionsstatus haben muss. Einreichungen mit identischer ReqID auf einen offenen Status werden regulär verarbeitet. Bitte beachten Sie, dass eine ReqID nur 12 Monate gültig ist, danach wird sie vom 1cs OBS gelöscht.
RefNr
ans..30
O
Eindeutige Referenznummer des Händlers, welche als Auszahlungsreferenz in der entsprechenden Acquirer EPA-Datei angegeben wird. Bitte beachten Sie, ohne die Übergabe einer eigenen Auszahlungsreferenz können Sie die EPA-Transaktionen nicht zuordnen, zusätzlich kann das Computop Settlement File (CTSF) auch nicht zusätzlich angereichert werden. Informationen zum unterstützten Format finden Sie weiter unten in der zahlartspezifischen Beschreibung.
Betrag in der kleinsten Währungseinheit (z.B. EUR Cent) Bitte wenden Sie sich an First Cash Solution, wenn Sie Beträge < 100 (kleinste Währungseinheit) buchen möchten.
Currency
a3
M
Währung, drei Zeichen DIN / ISO 4217, z.B. EUR, USD, GBP. Hier eine Übersicht: Währungstabelle
Capture
ans..6
O
Bestimmt Art und Zeit der Buchung (engl. Capture). AUTO= Buchung sofort nach der Autorisierung (Standardwert) MANUAL = Buchung durch den Händler -in der Regel die Buchung zum Zeitpunkt der Warenauslieferung bzw. Leistungserbringung. <Zahl> = Verzögerung in Stunden bis zur Buchung (ganze Zahl; 1 bis 696).
PayTypes
ans..256
O
Mit diesem Parameter können Sie die akzeptierten Schemes übersteuern, d.h. Sie können innerhalb dieses Parameters durch Pipe getrennt entscheiden, welche der verfügbaren Kreditkartenschemes angezeigt werden. Das Template muss diese Funktion unterstützen wie zum Beispiel das “Cards_v1”. Beispiel: PayTypes=VISA|MasterCard
Eine Bezeichnung, die auf dem Kontoauszug des Karteninhbaers gedruckt wird. Beachten Sie bitte auch die zusätzliche Hinweise an anderer Stelle für weitere Informationen über Regeln und Vorschriften.
OrderDesc
ans..768
O
Beschreibung der gekauften Waren, Einzelpreise etc.
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
Das Objekt Prior Transaction Authentication Information enthält optionale Informationen über eine Authentisierung eines 3DS-Karteninhabers, die vor der aktuellen Transaktion erfolgt ist.
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.
Rechnungsadresse. For EMV 3DS erforderlich (falls verfügbar), sofern nicht Markt- oder Regionalmandate die Übermittlung dieser Infomrationen beschränken.
Lieferadresse. Falls von billingAddress abweichend; für EMV 3DS erforderlich (falls verfügbar), sofern nicht Markt- oder Regionalmandate die Übermittlung dieser Infomrationen beschränken.
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.
Der Händler-Risikoindikator enthält optionale Informationen über den bestimmten Einkauf des Kunden.Falls shippingAddress nicht vorhanden ist, ist es dringend empfohlen, das Merkmal shippingAddressIndicator mit einem entsprechenden Wert wie shipToBillingAddress, digitalGoods oder noShipment auszufüllen.
subMerchantPF
JSON
O
Objekt, das die Details des SubMerchant (Payment Facilitator) angibt. Wird ausschließlich von SafeCharge unterstützt.
URLSuccess
ans..256
M
Vollständige URL, die das 1cs Online Bezahlsystem aufruft, wenn die Zahlung gescheitert ist. Die URL darf nur über Port 443 aufgerufen werden. Die URL darf nur über Port 443 aufgerufen werden. Diese URL darf keine Parameter enthalten: Um Parameter durchzureichen, nutzen Sie stattdessen den Parameter UserData.
Allgemeine Hinweise: Wir empfehlen, den Parameter “response=encrypt” zu verwenden, um eine verschlüsselte Antwort vom 1cs OBS zu erhalten Betrüger könnten das verschlüsselte DATA-Element kopieren, welches an URLFailure gesendet wurde, und betrügerisch dasselbe DATA an URLSuccess senden. Überprüfen Sie daher unbedingt den “code”-Wert des DATA-Elements. Nur eine Antwort mit “code=00000000” sollte als erfolgreich angesehen werden.
URLFailure
ans..256
M
Vollständige URL, die das 1cs Online Bezahlsystem aufruft, wenn die Zahlung gescheitert ist. Die URL darf nur über Port 443 aufgerufen werden. Diese URL darf keine Parameter enthalten: Um Parameter durchzureichen, nutzen Sie stattdessen den Parameter UserData. Allgemeine Hinweise: Wir empfehlen, den Parameter “response=encrypt” zu verwenden, um eine verschlüsselte Antwort vom 1cs OBS zu erhalten Betrüger könnten das verschlüsselte DATA-Element kopieren, welches an URLFailure gesendet wurde, und betrügerisch dasselbe DATA an URLSuccess/URLNotify senden. Überprüfen Sie daher unbedingt den “code”-Wert des DATA-Elements. Nur eine Antwort mit “code=00000000” sollte als erfolgreich angesehen werden.
URLBack
ans..256
O
Vollständige URL, die das 1cs Online Bezahlsystem aufruft, wenn der Kunde auf Abbruch klickt. Der Parameter “URLBack” kann sowohl unverschlüsselt ans Paygate übermittelt werden (Kompabilitätsmodus) als auch in den verschlüsselten Übergabeparametern (bevorzugte Variante) Wenn Sie Parameter/Werte in der URLBack übergeben möchten, so können Sie folgende Methode verwenden: URLBack=https://your.shop.com/back.php?param1%3Dvalue1%26param2%3Dvalue3%26status%3Dcancelled Wenn der Kunde auf Abbruch klickt, so wird die URL genauso aufgerufen, so dass Sie URL Decode verwenden können, um Parameter und Werte zu extrahieren.
Response
a7
O
Die Status-Rückmeldung, die das 1cs Online Bezahlsystem an URLSuccess und URLFailure sendet, sollte verschlüsselt werden. Dazu übergeben Sie den Parameter Response=encrypt.
URLNotify
an..256
M
Vollständige URL, die das 1cs Onlinebezahlsystem aufruft, um den Shop zu benachrichtigen. Die URL darf nur über Port 443 aufgerufen werden. Sie darf keine Parameter enthalten: Nutzen Sie stattdessen den Parameter UserData. Allgemeine Hinweise: Wir empfehlen, den Parameter “response=encrypt” zu verwenden, um eine verschlüsselte Antwort von dem 1cs OBS zu erhalten Betrüger könnten das verschlüsselte DATA-Element kopieren, welches an URLFailure gesendet wurde, und betrügerisch dasselbe DATA an URLSuccess/URLNotify senden. Überprüfen Sie daher unbedingt den “code”-Wert des DATA-Elements. Nur eine Antwort mit “code=00000000” sollte als erfolgreich angesehen werden.
userData
ans..1024
O
Wenn beim Aufruf angegeben, übergibt das 1cs Online Bezahlsystem die Parameter mit dem Zahlungsergebnis an den Shop.
Custom
ans..1024
O
Der “Custom”-Parameter wird vor der Verschlüsselung an den Aufruf angehängt und ist Teil des verschlüsselten “Data” im 1cs OBS Aufruf. Dadurch ist der Wert gegen Manipulation geschützt. Der Custom-Wert wird dann in Klartext an die 1cs-OBS-Antwort angehängt und dabei wird “|” durch “&” ersetzt. Dadurch können Sie einen Custom-Wert übergeben und bekommen mehrere Key-Value-Paare zu Ihrer eigenen Verwendung in der Antwort zurück.
Plain
ans..50
O
Ein einzelner Wert, der von Ihnen gesetzt werden kann, um Informationen wieder unverschlüsselt in der Antwort bzw. im Notify zurückzugeben, z.B. die MID. Da der “Plain”-Parameter Teil des verschlüsselten “Data” im 1cs OBS ist, ist dieser vor Manipulationen geschützt.
expirationTime
ans..19
O
Zeitstempel für den Endzeitpunkt der Transaktionsverarbeitung, Angabe in UTC. Format: YYYY-MM-ddTHH:mm:ss
Das 1cs Online Bezahlsystem gibt in der Antwort ein HTML-Dokument zurück, welches das angeforderte Kartenzahlungsformular darstellt. Das Formular kann in die Checkout-Seite des Händlers integriert oder als selbständige Seite verwendet werden, auf die der Karteninhaber weitergeleitet wird.
Die Authentisierung des Karteninhabers sowie die Zahlungsautorisierung erfolgen, nachdem der Karteninhaber aller erforderlichen Kartendetails eingegeben und das Formular an das 1cs Online Bezahlsystem übermittelt hat.
Hinweis: Falls Sie ein eigenes Zahlungsformular verwenden (Corporate Payment Page), achten Sie darauf, dass der Name des Karteninhabers auf dem Formular enthalten ist. Der Name das Karteninhabers wird auf den Paygate API-Parameter “CreditCardHolder” abgebildet. Das Feld Cardholder name darf keine Sonderzeichen enthalten und muss eine Mindestlänge von 2 Zeichen und eine Maximallänge von 45 Zeichen haben.
Wenn die Zahlung abgeschlossen ist, sendet das 1cs Online Bezahlsystem eine Benachrichtigung an den Server des Händlers (d.h. URLNotify) und leitet den Browser an URLSuccess beziehungsweise URLFailure weiter.
Die per Blowfish verschlüsselten Parameter laut folgender Tabelle werden per HTTP POST an URLNotify und URLSuccess/URLFailure übertragen.
Hinweis: Bitte beachten Sie, dass der Aufruf der URLSuccess oder URLFailure bei einem Fallback zu 3-D Secure 1.0 mit GET stattfindet. Ihre Systeme sollten daher Parameter sowohl per GET als auch per POST entgegennehmen können.
HTTP POST an URLSuccess / URLFailure / URLNotify
Die folgende Tabelle beschreibt die Ergebnis-Parameter, die das 1cs Online Bezahlsystem an Ihre URLSuccess,URLFailure und URLNotify übergibt. Wenn Sie den Parameter Response=encrypt angegeben haben, werden die folgenden Parameter mit Blowfish verschlüsselt an Ihr System übergeben:
es können jederzeit neue Parameter hinzugefügt bzw. die Reihenfolge geändert werden
die Parameter (z.B. MerchantId, RefNr) sollten nicht auf Groß-/Kleinschreibung geprüft werden
Key
Format
Bedingung
Beschreibung
MID
ans..30
M
HändlerID, die von der First Cash Solution vergeben wird
MsgVer
ans..5
M
Message-Version. Zulässiger Wert: 2.0 Mit 3-D Secure 2.x wurde eine Vielzahl zusätzlicher Daten (Browser-Information, Rechnungs-/Versand-Adresse, …) erforderlich, um den Authentifizierungs-Prozess zu optimieren. Um diese Informationen zu handhaben, wurden die JSON-Objekte eingeführt. Der Parameter MsgVer zeigt an, dass diese Daten verwendet werden.
PayID
ans32
M
Von der First Cash Solution vergebene ID für die Zahlung; z.B. zur Referenzierung in Batch-Dateien sowie im Capture- oder Credit-Request.
XID
ans64
M
Vom 1cs Online Bezahlsystem vergebene ID für die einzelnen Operationen, die zu einer Zahlung durchgeführt werden
TransID
ans..64
M
Ihre eigene Transaktions-ID, die für jede Zahlung eindeutig sein muss
schemeReferenceID
ans..64
C
Spezifische Transaktions-ID des Kartenschemas, die für nachfolgende Zahlungen mit gespeicherten Zugangsdaten, verzögerte Autorisierungen und Wiedereinreichungen erforderlich ist. Pflicht: CredentialOnFile – initial false – unschedule MIT / recurring schemeReferenceID wird bei 3DS2-Zahlungsvorgängen zurückgegeben. Bei einem Fallback auf 3DS1 prüfen Sie bitte zusätzlich auf TransactionId. Die SchemeReferenceID ist eine eindeutige Kennung, die von den Kartenmarken generiert wird. In der Regel können 1cs-Händler die SchemeReferenceIDs für Abonnements übergreifend verwenden, welche unter Verwendung eines anderen PSP / separater 1cs-OBS-MerchantID / separater Acquirer ContractID / Acquirer erstellt wurden.
refnr
O
Referenznummer vom Request
Status
a..20
M
Status der Transaction. Zulässige Werte: AuthorizedOK (Sale) FAILED Im Fall von nur-Authentisierung ist der Status entweder OK oder FAILED.
Description
ans..1024
M
Nähere Beschreibung bei Ablehnung der Zahlung. Bitte nutzen Sie nicht den Parameter Description,sondernCode für die Auswertung des Transaktionsstatus!
Falls der Authentisierungsprozess eine Aufforderung für den Karteninhaber enthalten hat, werden zusätzliche Informationen über das Ergebnis der Aufforderung bereitgestellt
externalPaymentData
JSON
O
Optionale Daten des Acquirers/Issuers/externen Dienstleisters für eine Autorisierung
TimeStamp
Date/Time
O
Zeitstempel dieser Aktion, wenn von der 1cs aktiviert, z.B. 30.05.2023 08:47:57 oder 30.05.2023 10:03:01.633
CardHolder
ans..50
O
Name des Karteninhabers, wenn von der 1cs aktiviert, z.B. Max Mustermann
bin
n..6
O
BIN der Kreditkarte, wenn von der 1cs aktiviert, z.B. 40001
maskedpan
an..19
O
Maskierte Kreditkartennummer, wenn von der 1cs aktiviert, z.B.400001XXXXXX8323
cardinfo
JSON
O
JSON-Struktur, welche Informationen zur Kreditkarte bzw. dem Issuer enthält, wenn vom der 1cs aktiviert, z.B. {“BIN”:”400001″,”Brand”:”VISA”,”Product”:””,”Source”:”CREDIT”,”Type”:””,”Country”:{“A3″:”USA”,”N3″:”840″},”Issuer”:””}
CCBrand
an..20
O
Brand/ Karten-Scheme der Kreditkarte, z.B. VISA
CCExpiry
n6
O
In Verbindung mit PCNr: Ablaufdatum der Kreditkarte im Format YYYYMM (202207).
Plain
ans..50
O
Ein einzelner Wert, der von Ihnen gesetzt werden kann, um Informationen wieder unverschlüsselt in der Antwort bzw. im Notify zurückzugeben, z.B. die MID. Da der “Plain”-Parameter Teil des verschlüsselten “Data” im Computop Paygate ist, ist dieser vor Manipulationen geschützt.
Custom
ans..1024
O
Der “Custom”-Parameter wird vor der Verschlüsselung an den Aufruf angehängt und ist Teil des verschlüsselten “Data” im Computop Paygate Aufruf. Dadurch ist der Wert gegen Manipulation geschützt. Der Custom-Wert wird dann in Klartext an die Computop Paygate-Antwort angehängt und dabei wird “|” durch “&” ersetzt. Dadurch können Sie einen Custom-Wert übergeben und bekommen mehrere Key-Value-Paare zu Ihrer eigenen Verwendung in der Antwort zurück.
userData
ans..1024
C
Wenn beim Aufruf angegeben, übergibt das 1cs Online Bezahlsystem die Parameter mit dem Zahlungsergebnis an den Shop.
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:
Die folgende Tabelle beschreibt die verschlüsselten Übergabeparameter:
Key
Format
Bedingung
Beschreibung
TxType
ans..20
M
Übergeben Sie „Order“, um eine Zahlung zu initialisieren und diese später über die Schnittstelle authorize.aspx zu autorisieren. Bitte beachten Sie, dass in Verbindung mit dem genutzten 3-D Secure-Verfahren eine separate Einstellung notwendig ist. Bitte wenden Sie sich hierzu direkt an 1cs.
Zusatzparameter für Kreditkartenzahlung mit separater Autorisierung
Um eine zuvor mit TxType=Order initialisierte SSL-Kreditkartenzahlung zu autorisieren, rufen Sie folgende URL auf:
Hinweis: Bitte beachten Sie, dass bei einer initialen Order keine KPN/CVC/CVV-Prüfung erfolgen kann. Für die folgende Reservierungsanfrage kann diese ID auch nicht weitergegeben werden.
Hinweis: Aus Sicherheitsgründen lehnt das Paygate alle Zahlungsanfragen mit Formatfehlern ab. Bitte übergeben Sie deshalb bei jedem Parameter den korrekten Datentyp.
Die folgende Tabelle beschreibt die verschlüsselten Übergabeparameter:
Key
Format
Bedingung
Beschreibung
MerchantID
ans..30
M
HändlerID, die von der First Cash Solution vergeben wird. Dieser Parameter ist zusätzlich auch unverschlüsselt zu übergeben.
PayID
an32
M
Von dem 1cs Online Bezahlsystem vergebene ID für die Zahlung; z.B. zur Referenzierung in Batch-Dateien sowie im Capture- oder Credit-Request.
TransID
ans..64
M
Ihre eigene TrasaktionsID, die für jede Zahlung eindeutig sein muss.
Amount
n..10
M
Betrag in der kleinsten Währungseinheit (z.B. EUR Cent). Bitte wenden Sie sich an die First Cash Solution, wenn Sie Beträge < 100 (kleinste Währungseinheit) buchen möchten.
Currency
a3
M
Währung, drei Zeichen DIN / ISO 4217, z.B. EUR, USD, GBP. Hier eine Übersicht: Währungstabelle
OrderDesc
ans..768
O
Beschreibung der gekauften Waren, Einzelpreise etc.
Bestimmt Art und Zeitpunkt der Buchung (engl. Capture). Buchungsarten AUTO Buchung sofort nach Autorisierung (Standardwert). MANUAL Buchung erfolgt durch den Händler – in der Regel die Buchung zum Zeitpunkt der Warenauslieferung bzw. Leistungserbringung. <Zahl>Verzögerung in Stunden bis zur Buchung (ganze Zahl; 1 bis 696).
Parameter für Kreditkartenzahlungen über authorize.aspx
Folgende Tabelle beschreibt die Ergebnis-Parameter, die das 1cs Online Bezahlsystem als Antwort zurückgibt:
Hinweis: es können jederzeit neue Parameter hinzugefügt bzw. die Reihenfolge geändert werden
Hinweis: die Parameter (z.B. MerchantId, RefNr) sollten nicht auf Groß-/Kleinschreibung geprüft werden
Key
Format
Bedingung
Beschreibung
MID
ans..30
M
HändlerID, die von der First Cash Solution vergeben wird
PayID
ans32
M
Vom 1cs Online Bezahlsystem vergebene ID für die Zahlung; z.B. zur Referenzierung in Batch-Dateien sowie im Capture- oder Credit-Request.
XID
an32
M
Vom 1cs Online Bezahlsystem vergebene ID für die einzelnen Operationen, die zu einer Zahlung durchgeführt werden
Nähere Beschreibung bei Ablehnung der Zahlung. Bitte nutzen Sie nicht den Parameter Description,sondern Code für die Auswertung des Transaktionsstatus!
TransID
ans..64
M
Ihre eigene TransaktionsID, die für jede Zahlung eindeutig sein muss
Status
a..50
M
OK oder FAILED
RefNr
O
Eindeutige Referenznummer des Händlers, welche als Auszahlungsreferenz in der entsprechenden Acquirer EPA-Datei angegeben wird. Bitte beachten Sie, ohne die Übergabe einer eigenen Auszahlungsreferenz können Sie die EPA-Transaktionen nicht zuordnen, zusätzlich kann das Computop Settlement File (CTSF) auch nicht zusätzlich angereichert werden. Informationen zum unterstützten Format finden Sie weiter unten in der zahlartspezifischen Beschreibung. Es sind ausschließlich ASCII-Zeichen erlaubt. Sonderzeichen wie (“Umlaute”, …) sind nicht erlaubt und müssen ggf. durch ASCII-Zeichen ersetzt werden (z.B. ü → ue, é → e, …).
Ergebnis-Parameter für Kreditkartenzahlungen über authorize.aspx
Erweitertes Sequenz-Diagramm
2.2 Server-2-Server Integration
Eine 3DS 2.0 Zahlungssequenz kann aus den folgenden verschiedenen Aktivitäten bestehen:
Versionierung
Anfrage von ACS- und DS-Protokol-Version(en), die mit dem Kartenkontenbereich korrespondieren sowie einer optionalen 3DS Method URL
3DS Methode
Verbindet den Browser des Karteninhabers mit dem ACS des Issuers, um zusätzliche Browserdaten zu erhalten
Authensierung
Übermittlung der Authentisierungs-Anfrage an den ACS des Issuers
Challenge
Challenge des Karteninhabers, falls angeordnet
Autorisierung
Autorisierung der authentisierten Transaktion beim Acquirer
Hinweis: Beachten Sie bitte, dass die Kommunikation zwischen Client und Access Control Server (ACS) über iFrames implementiert ist. Daher kommen die Antworten in einem HTML-Subdokument an und Sie können entsprechende Event-Listener in Ihrem Root-Dokument einrichten. Alternativ könnten Sie alleinig auf die asynchronen Benachrichtigungen an ihr Backend vertrauen. In jenen Fällen müssen Sie eventuell Methoden wie Long Polling, SSE oder Websockets zum Update des Clients in Betracht ziehen.
Initiierung der Zahlung
Die anfängliche Anfrage an das 1cs Online Bezahlsystem ist unabhängig vom zugrundeliegenden 3DS-Protokoll gleich.
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).
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.
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
Das Objekt Prior Transaction Authentication Information enthält optionale Informationen über eine 3DS-Authentisierung eines Karteninhabers, die vor der aktuellen Transaktion erfolgt ist
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.
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.
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.
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.
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.
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
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.
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.)
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.
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.
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';
Hinweis: Beachten SIe bitte, dass die threeDSMethodNotificationURL wie sie in den Base64-codierten threeDSMethodData eingebettet ist, auf das 1cs Online Bezahlsystem weist und nicht verändert werden darf. Die Händler-Benachrichtigung wird an die URLNotify geliefert, wie sie in der Originalanfrage übermittelt oder für die MerchantID im 1cs Online Bezahlsystem konfiguriert ist.
Authentisierung
Wenn 3DS Methode vom ACS des Issuers unterstützt wird und vom Händler aufgerufen wurde, setzt das 1cs Online Bezahlsystem automatisch mit der Authentisierungsanfrage fort, nachdem die 3DS Methode abgeschlossen ist (d.h. 3DS Methoden-Benachrichtigung).
Das Ergebnis der Authentisierung wird per HTTP POST an die URLNotify übertragen. Es kann anzeigen, dass der Karteninhaber authentisiert worden ist oder dass eine weitere Interaktion des Karteninhabers (d.h. Challenge) für den Abschluss der Authentisierung erforderlich ist.
Falls für den Karteninhaber eine Challenge angeordnet ist, überträgt das 1cs Online Bezahlsystem ein JSON-Objekt im Body der HTTP Browser-Antwort mit den Elementen acsChallengeMandated, challengeRequest, base64EncodedChallengeRequest und acsURL. Anderenfalls setzt das 1cs Online Bezahlsystem in einem reibungslosen Ablauf automatisch fort und antwortet dem Browser des Karteninhabers, sobald die Autorisierung abgeschlossen ist.
Karteninhaber-Challenge: Browser-Antwort
Browser Challenge-Antwort
Datenelemente
Key
Format
Bedingung
Beschreibung
acsChallengeMandated
boolean
M
Zeigt an, on eine Challenge für die Autorisierung einer Transaktion wegen lokaler/regionaler Vorschriften oder anderer Variablen nötig ist: true → Challenge ist obligatorisch wegen lokaler/regional Vorschriften false → Challenge ist nicht obligatorisch wegen lokaler/regional Vorschriften, wird aber von ACS als nötig angesehen
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.
Sie können die Operationen init3DSChallengeRequest oder createIFrameAndInit3DSChallengeRequest aus dem nca3DSWebSDK verwenden, um die Challenge-Nachricht an den Browser des Karteninhabers zu übermitteln.
Sobald die Challenge des Karteninhabers abgeschlossen, abgebrochen oder per Zeitüberschreitung beendet ist, weist der ACS den Browser an, die Ergebnisse per Post an die in der Challenge-Anfrage angegebene Benachrichtigungs-URL zu senden und eine Ergebnis-Anfrage (RReq) über den Directory Server an den 3DS Server zu senden.
Hinweis: Beachten Sie bitte, dass die in der Challenge-Anfrage übergebene Benachrichtigungs-URL auf das 1cs Online Bezahlsystem zeigt und nicht verändert werden darf.
Autorisierung
Nachdem die erfolgreiche Authentisierung des Karteninhabers oder der Nachweis der versuchten Authentisierung/Verifizierung bereitgestellt ist, setzt das 1cs Online Bezahlsystem die Zahlungsautorisierung automatisch fort.
Falls die Authentisierung des Karteninhabers nicht erfolgreich war oder der Nachweise der versuchten Authentisierung/Verifizierung nicht bereitgestellt werden kann, setzt das 1cs Online Bezahlsystem nicht mit einer Autorisierungsanfrage fort.
In beiden Fällen liefert das 1cs Online Bezahlsystem eine endgültige Benachrichtigung an die vom Händler angegebene URLNotify mit den Datenelementen gemäß nachstehender Tabelle.
Zahlungs-Benachrichtigung
Key
Format
Bedingung
Beschreibung
MID
ans..30
M
HändlerID, die von der First Cash Solution vergeben wird
MsgVer
ans..5
M
Message-Version. Zulässige Werte: 2.0: Mit 3-D Secure 2.x wurde eine Vielzahl zusätzlicher Daten (Browser-Information, Rechnungs-/Versand-Adresse, …) erforderlich, um den Authentifizierungs-Prozess zu optimieren. Um diese Informationen zu handhaben, wurden die JSON-Objekte eingeführt. Der Parameter MsgVer zeigt an, dass diese Daten verwendet werden.
PayID
ans32
M
Vom 1cs Online Bezahlsystem vergebene ID für die Zahlung; z.B. zur Referenzierung in Batch-Dateien sowie im Capture- oder Credit-Request.
XID
an32
M
Vom 1cs Online Bezahlsystem vergebene ID für alle einzelnen Transaktionen (Autorisierung, Buchung, Gutschrift), die für eine Zahlung durchgeführt werden
TransID
ans..64
M
Ihre eigene TransaktionsID, die für jede Zahlung eindeutig sein muss
schemeReferenceID
ans..64
C
Kartensystemspezifische Transaktions-ID, die für nachfolgende Zahlungen mit hinterlegten Daten, verzögerte Autorisierungen und Wiedereinreichungen erforderlich ist
TrxTime
an21
M
Transaction time stamp in format DD.MM.YYYY HH:mm:ssff.
Status
a..20
M
Status der Transaktion. Zulässige Werte: AuthorizedOK (Sale) PENDINGFAILED 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,sondernCode für die Auswertung des Transaktionsstatus!
Falls der Authentisierungsprozess eine Challenge des Karteninhabers enthalten hat, werden zusätzliche Informationen über das Ergebnis der Challenge bereitgestellt
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
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
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:
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.
Sobald die Authentisierung abgeschlossen oder vom Karteninhaber abgebrochen worden ist, leitet der ACS den Karteninhaber über seinen Browser zur TermURL weiter, wie sie bei der anfänglichen Zahlungsanfrage angegeben ist.
Hinweis: Die Zahler-Authentisierungs-Antwort (PaRes) wird mittels HTTP POST Methode übertragen, während MID, PayID und TransID im HTTP-Anfrage-String gesendet werden (d.h. HTTP GET).
Zur TermURL übertragene Datenelemente
Key
Format
Bedingung
Beschreibung
MID
ans..30
M
HändlerID, die von der First Cash Solution vergeben wird
PayID
ans32
M
Vom 1cs Online Bezahlsystem vergebene ID für die Zahlung, z.B. zur Referenzierung in Batch-Dateien sowie im Capture- oder Credit-Request.
TransID
ans..64
M
Ihre eigene TransaktionsID, die für jede Zahlung eindeutig sein muss
PARes
—
M
Die vom ACS gesendete PARes-Nachricht (Payer Authentication Response) in Reaktion auf die PAReq ungeachtet dessen, ob die Authentisierung erfolgreich ist
Autorisierung
Um eine mit 3DS 1.0 authentisierte Zahlung zu autorisieren, müssen die Parameter der nachfolgenden Tabelle unverschlüsselt per POST an
ü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: AuthorizedOK(Sale) FAILED
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.11.0.2
Acquirer Bank Identification Number (BIN)
M
Dieses Feld muss zur verwendeten Acquirer-BIN bei der Verify Enrollment Request passen
Merchant Identifier (ID) Number
M
Dieses Feld muss zur verwendeten Merchant ID bei der Verify Enrollment Request passen. Dieses Feld muss auch zur vom Acquirer verwendeten Merchant ID gegenüber dem Kartennetzwerk für Autorisierungen und Abrechnung passen.
Merchant Name
M
Dieses Feld muss den Namen des Online-Händlers enthalten, bei dem der Karteninhaber einkauft. Die Maximallänge beträgt 25 Zeichen. Der Händlername muss dem eingereichten Namen für Autorisierung und Abrechnung entsprechen.
Merchant Country Code
M
Dieses Feld muss den dreistelligen Ländercode gemäß ISO 3166 enthalten
Merchant URL
M
Dieses Feld muss die vollständige URL der Händler-Webseite enthalten
Transaction Identifier
M
Eindeutige Transaktionsnummer des Händlers. Enthält einen 20 Byte großen statistischen eindeutigen Wert, der Base64-codiert ist und zu einem Ergebnis mit 28 Byte führt.
Purchase Date & Time
M
Datum und Uhrzeit des Kaufs in GMT im folgenden Format: JJJJMMTT HH:MM:SS.
Purchase Amount
M
Dieses Feld muss den Wert des Kaufs vom Karteninhaber enthalten. Es ist ein Wert mit bis zu 12 Stellen und ohne Nachkommastellen.
Purchase Currency
M
Der entsprechende dreistellige Währungscode gemäß ISO 4217 für die Transaktionswährung zwischen Karteninhaber und Händler muss verwendet werden.
Currency Exponent
M
Die kleinste Währungseinheit gemäß ISO 4217
Order Description
O
Kurze Beschreibung der gekauften Artikel durch den Händler. Die Maximalgröße beträgt 125 Zeichen, aber der Händler sollte beim Anlegen dieses Feldes die Eigenschaften vom Gerät des Karteninhabers berücksichtigen.
Recurring Payment Data
C
Ein Element Recur muss angegeben werden, wenn Händler und Karteninhaber wiederkehrende Zahlungen vereinbart haben
Installment Payment Data
C
Eine Ganzzahl größer als eins gibt die Maximalanzahl der erlaubten Autorisierungen für Ratenzahlungen an. Sie muss angegeben werden, wenn Händler und Karteninhaber Ratenzahlungen vereinbart haben.
Account Identifier
M
Der Inhalt dieses Feldes ist ein für den ACS nützlicher Daten-String; er darf die PAN nicht offenlagen und mit einem Algorithmus erzeugt werden, der glaubhaft eindeutige Werte erzeugt, selbst wenn dieselbe PAN präsentiert wird.
Card Expiry Date
M
Vom Karteninhaber an den Händler übermitteltes Ablaufdatum (JJMM)
Message Extension
O
Alle nötigen Daten zur Unterstützung der Anforderungen, die nicht anderweitig in der PAReq-Nachricht definiert sind, müssen in einer Nachrichten-Erweiterung transportiert werden
Zusätzliche Parameter bei wiederkehrenden Transaktionen
Recurring Frequency
M
Ganzzahl, welche die Mindestanzahl von Tagen zwischen Autorisierungen angibt
Recurring Expiry
M
Datum, nach dem keine weiteren Autorisierungen mehr erfolgen sollen im Format JJJJMMTT.
2.3 Stille Auftragserteilung (PayNow)
Überblick Eine Stille Auftragserteilung oder Direkte Erteilung ist eine Übertragunsmethode, bei der Formulardaten von einer Händler-Webseite direkt an einen Server eines Dritten abgeschickt werden. Das wird üblicherweise durch das Attribut formaction erreicht, welches die URL angibt, wohin die Daten zu senden sind.
Hinweis: Sensible Daten wie Kartendetails können innerhalb der Händler-Webseite erfasst werden, ohne dass diese vom Server des Händlers verarbeitet werden, da der POST still übermittelt wird. Die URL im 1cs Online Bezahlsystem für den Empfang von Anfragen der Stillen Auftragserteilung wird als PayNow bezeichnet.
<form action="../payNow.aspx" method="post">
Dieser Ansatz ist sehr ähnlich zu den von der First Cash Solution gehosteteten Zahlungsformularen und lässt dem Händler die volle Kontrolle über den Bezahlvorgang, da alle Elemente der Webseite vom Server des Händlers bereitgestellt werden.
Hinweis: Händler, die Kartentransaktionen mit dem Modell der stillen Erteilung verarbeiten, müssen den Fragebogen PCI DSS Self-Assessment Questionnaire (SAQ) A-EP einreichen. Dieser SAQ ist umfangreicher und kann daher mehr Zeit und Ressourcen erfordern als der SAQ A für Händler, die gehostete Zahlungsseiten verwenden. Händler sollten sich jedoch immer mit ihrem Acquirer beraten, um das Maß der erforderlichen Compliance zu beurteilen und dabei die PCI DSS Richtlinien beachten. Das wirkt sich nicht auf die Verwendung von Pseudokartennummern aus, was ohne Einreichung des SAQ Fragebogens möglich ist.
Hinweis zum Cookie-/Session Handling: Bitte beachten Sie, dass einige Browser beim Rücksprung zu Ihrem Shop erforderliche Cookies blockieren könnten. Hier finden Sie weitere Informationen und verschiedene Lösungsansätze.
Sequenzdiagramm
Zahlungsanfrage
Bitte übermitteln Sie die folgenden Parameter für Kartenzahlungen über einen HTTP POST Aufruf an:
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)
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.
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
Das Objekt Prior Transaction Authentication Information enthält optionale Informationen über eine 3DS-Authentisierung eines Karteninhabers, die vor der aktuellen Transaktion erfolgt ist.
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.
Lieferadresse. Falls abweichend von billingAddress, erforderlich (falls verfügbar), sofern nicht Markt- oder regionale Mandate das Senden dieser Informationen beschränken.
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.
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.
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.
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.
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.
Wenn die Zahlung abgeschlossen ist, sendet das 1cs Online Bezahlsystem eine Benachrichtigung an den Händler-Server (d.h. URLNotify) und leitet den Browser dementsprechend an URLSuccess oder URLFailure weiter.
Die in der folgenden Tabelle genannten per Blowfish verschlüsselten Datenelemente werden vom 1cs Online Bezahlsystem per HTTP POST Anfragemethode an URLNotify und URLSuccess/URLFailure übertragen.
Hinweis: Bitte beachten Sie, dass der Aufruf der URLSuccess oder URLFailure bei einem Fallback zu 3-D Secure 1.0 mit GET stattfindet. Ihre Systeme sollten daher Parameter sowohl per GET als auch per POST entgegennehmen können.
HTTP POST an URLSuccess / URLFailure / URLNotify
Key
Format
Bedingung
Beschreibung
MID
ans..30
M
HändlerID, die von der First Cash Solution vergeben wird
MsgVer
ans..5
M
Message-Version. Zulässige Werte: 2.0: Mit 3-D Secure 2.x wurde eine Vielzahl zusätzlicher Daten (Browser-Information, Rechnungs-/Versand-Adresse, …) erforderlich, um den Authentifizierungs-Prozess zu optimieren. Um diese Informationen zu handhaben, wurden die JSON-Objekte eingeführt. Der Parameter MsgVer zeigt an, dass diese Daten verwendet werden.
PayID
ans32
M
Vom 1cs Online Bezahlsystem vergebene ID für die Zahlung; z.B. zur Referenzierung in Batch-Dateien sowie im Capture- oder Credit-Request.
XID
ans64
M
Vom 1cs Online Bezahlsystem vergebene ID für alle einzelnen Transaktionen (Autorisierung, Buchung, Gutschrift), die für eine Zahlung durchgeführt werden
TransID
ans..64
M
Ihre eigene TransaktionsID, die für jede Zahlung eindeutig sein muss
refnr
O
Referenznummer vom Request.
schemeReferenceID
ans..64
C
Kartensystemspezifische Transaktions-ID, die für nachfolgende Zahlungen mit hinterlegten Daten, verzögerte Autorisierungen und Wiedereinreichungen erforderlich ist
Status
a..20
M
Status der Transaktion. Zulässige Werte: AuthorizedOK (Sale) FAILED Im Falle von nur Authentisierung ist der Status entweder OK oder FAILED.
Description
ans..1024
M
Nähere Beschreibung bei Ablehnung der Zahlung. Bitte nutzen Sie nicht den Parameter Description,sondern Code für die Auswertung des Transaktionsstatus!
Falls der Authentisierungsprozess eine Challenge des Karteninhabers enthalten hat, werden zusätzliche Informationen über das Ergebnis der Challenge bereitgestellt
Wichtig: Beachten Sie bitte, dass alle JSON-Objekte Base64-codiert sein müssen.
Das 1cs Online Bezahlsystem validiert JSON-Objekte bei allen Requests, die den Parameter “MsgVer=2.0” enthalten. Dies passiert unabhängig davon, ob auch wirklich 3DSecure2 auf Ihrer MerchantID aktiv ist.
Bitte stellen Sie sicher, dass keine leeren Parameter oder Objekte gesendet werden. Das 1cs Online Bezahlsystem geht in solchen Fällen von einem Fehler aus und lehnt die Transaktion ab.
Das 1cs Online Bezahlsystem unterstützt auch Szenarien, in denen Händler den 3DS Server (3DS 2.0) beziehungsweise 3DS MPI (3DS 1.0) der First Cash Solution als eine gehostete Lösung verwenden wollen und die Transaktion nachfolgend über eine Integration mit einer Drittpartei autorisieren wollen.
Hinweis: Bitte wenden Sie sich an den First Cash Solution Support und bitten um die nötigen Konfigurationsänderungen an Ihrer Merchant ID.
Authentication Hosting alleine wird unterstützt für
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:
Um zur PSD2 konform zu sein, führt Amazon Pay die SCA für seine Transaktionen ein.
Das SCA-Upgrade führt einen “Bestätigungs-Ablauf” ein, um die Multi-Faktor-Authentisierung (MFA) durchzuführen, wenn diese erforderlich ist.
Wenn eine MFA erforderlich ist, zeigt der Bestätigungs-Ablauf dem Käufer die MFA-Challenge des Kreditkartenherausgebers. Nachdem der Käufder mit dem Bestätigungs-Ablauf (beispielsweise die MFA-Challange abgeschlossen hat) interagiert hat, wird der Käufer auf die Seite des Händlers zurückgeleitet (beispeilsweise die Seite der Bestellbestätiung).
Aktualisieren Sie bite den AmazonPay-Kassenablauf, nachdem der Käufer seinen Bestellabschluss ausgelöst hat und bevor Sie die Autorisierung aufrufen.
Änderungen
Neue JavaScript-Funktion confirmationFlow()
Gemäß MFA ist es nach der erfolgreichen Bestätigung einer Bestellung notwendig, einen neuen Aufruf zu beginnen, den Bestätigungs-Ablauf (ConfirmationFlow).
Zum Start des Arbeitsablaufes
führen Sie bitte eine Bestätigung für die Bestellung am 1cs Online Bezahlsystem aus, nachdem Sie ein Ergebnis erhalten haben
starten Sie den Bestätigungsablauf im Falle eines Erfolgs mit “confirmationFlow.success()”
im Falle eins Fehlers beendet “confirmationFlow.error()” den Prozess.
Die Implementierung des neuen Javascript-Aufrufs ist nachstehend gezeigt. Dieser wurde für unsere Händler optimiert.
Hinweis: Diese Aktion sollte durch einen Klick auf die Schaltfläche “Jetzt kaufen” (“Buy Now”) ausgelöst werden!
function confirmationFlow()
{ // resultCode vom 1cs-Aufruf AmazonAPA.aspx, EventToken: COD erhalten var resultCode_Computop = Paygate call to get the ResultCode from the Confirm, AP call COD or SCO. // Ihre AmoazonSellerID / AmazonMerchantID var amazonSellerId = 'Your_SellerID'; // Vom Adress-Widget erzeugte Amazon Bestellreferenz var orderReferenceId = 'Your_Order_Reference'; //Bestätigungs-Ablauf initiieren OffAmazonPayments.initConfirmationFlow(amazonSellerId, orderReferenceId, function (confirmationFlow) { if(resultCode_Computop = '00000000') { confirmationFlow.success(); } else { confirmationFlow.error(); } } ); }
Der Händler sollte die Weiterleitung von der First Cash Solution (URLSuccess / URLFailure) mit der Ergebnis der MFA-Challenge handhaben können.
URLSuccess / URLFailure für Aufrufe ConfirmOrderDetails (COD) und SetOrderDetails und ConfirmOrder (SCO)
Key
Format
Bedingung
Beschreibung
URLSuccess
ans..256
M
Der Käufer wird zu dieser URL weitergeleitet, wenn die MFA erfolgreich ist
URLFailure
ans..256
O
Der Käufer wird zu dieser URL weitergeleitet, wenn die MFA nicht erfolgreich ist
AuthorizationAmount
n..10
O
Der während des MFA-Abschlusses zu authentisierende Betrag. Verwenden Sie diesen Parameter, wenn Sie einen Zahlungsbertrag festlegen wollen, der vom Wert OrderTotal im Aufruf SetOrderReferenceDetails abweicht. Wenn dieser Parameter nicht gesetzt ist, wird der während MFA authentisierte Betrag gleich dem in OrderTotal im Aufruf SetOrderReferenceDetails angegebenen Betrag.
Bei “Order Now” muss der Händler die URLSuccess und URLFailure in den Aufrufen (EventToken=SCO | COD) senden, weil die Weiterleistung nach der MFA-Challange ausgeführt wird.
Nach “Order Now” wird Confirm (EventToken=SCO | COD) für die Zahlung ausgeführt und dann erfolgt die Weiterleitung zur Challenge mit dem oben gezeigten JavaScript-Code.
AmazonAPA.aspx
Die folgenden Ereignisaufrufe am 1cs Online Bezahlsystem sind von den Ädnerungen betroffen. Achten Sie bitte darauf, die neue Parameter mit einzubeziehen.
EventToken
Action
Beschreibung
SOD
SetOrderDetails
Übertragung des zahlbaren Betrags und weiterer Informationen – steuert auch die für eine Bestellung bei Amazon wählbaren Zahlungsmethoden
GOD
GetOrderDetails
Anfrage von Bestellinformationen, d.h. zum Erhalt von Informationen über eine neue gewählte Lieferadresse. Nach einem Aufruf mit Eventtoken COD oder SCO, gibt GOD auch die Rechnungsadresse des Kunden zurück Beim Scope “payments:shipping_address” und “payments:billing_address” erhalten Sie die volle Liefer- und Versandadresse nach der Anzeige des Adress-Widgets. Bitte übertragen Sie beim Aufruf die OrderReferenceId.
SCO
SetOrderDetailsAndCon-firmOrder
Bestellbestätigung wieder mit Übertragung des zahlbaren Betrags und weiterer Informationen – mit diesem Eventtoken ist die Bestellung abgeschlossen. Nach erfolgreiche Bestätigung können sofrot Autorisierungen an Amazon übermittelt werden.
COD
ConfirmOrderDetails
Optional, wenn der zahlbare Betrag und weitere Informationen nicht nochmal zur Bestellbestätigung übertragen werden sollen (die First Cash Solution empfiehlt die Verwendung des Eventtoken SCO zur Bestellbestätigung.)
COR
CloseOrderReference
Schließen einer Amazon-Bestellung. Buchungen für offene Autorisierungen sowie Gutschriften sind weiterhin möglich.
Benutzer-Ablauf und Sequenzen
Ablauf
1. Klick auf die Schaltfläche AmazonPay zum Anmelden
2. wählt eine Adresse im Widget
3. wählt die Zahlungsmethode im Widget
4. bestätigt die Bestellung
Option 1: SCO
Das ist die empfohlene Option.
Option 2: SOD und COD
1. Der erste Aufruf dient dem Bestätigungs-Ablauf – damit kann AmazonPay die MFA handhaben, falls erforderlich. Hier ist confirmationFlow Fehler/Erfolg zu setzen. Referenz zur Datei Amazon Pay Widgets.js, die bereits für andere Widgets verwendet wird.
3. Aufruf ConfirmOrderDetails (COD) setzt Parameter URLSuccess/URLFailure mit einem Wert returnURL
Hinweis: Wie oben gezeigt, empfehlen wir den Aufruf SCO als einzelnen Schritt zum Festlegen und Bestätigen der Bestelldetails.
Option 3: MFA-Fehler
Hinweis: Wir empfehlen unseren Händlern, in diesen Fällen nur mit dem 1cs Online Bezahlsystem-Status oder 1cs Online Bezahlsystem-Antwortcode zu arbeiten.
Status => Aufgegeben:
Status => Fehler:
1. Falls der Kunde die Challenge aufgibt oder daran scheitert, wird der Kunde zur URLFailure weitergeleitet.
2. Abmelden des Benutzers.
3. Abbrechen der Bestellung durch Aufruf von “Reverse.aspx”
Abbrechen der Bestellung durch Aufruf von “Reverse.aspx“
Um eine komplette Bestellung mit Amazon Pay mit der Funktion „CancelOrderReference“ zu stornieren, verwenden Sie bitte
Weitere ausführliche Informationen dazu liefert die offizielle Online Bezahlsystem-Dokumentation hier: Amazon Pay Manual
Status
Wenn die MFA erfolgreich ist, erfolgt die Weiterleitung zu URLSuccess, Anderenfalls erfolgt die Weiterleitung zu URLFailure.
Wert Authentisierungs-Status
Beschreibung
Empfohlene Maßnahme
Success
Erfolgreich / nicht nötig
Keine Aktion nötig
Failure
Gescheitert
Weiterleitung zur FailureURL oder zur Seite, um eine andere Zahlungsmethode als Amazon zu verwenden
Abandoned
Gescheitert
Weiterleitung zur FailureURL oder zur Seiten, um die Bestellung mittels Amazon Pay zu ersetzen und die MFA-Challenge abzuschließen
Hinweis: Die Amazon Authentisierungs-Antwort wird dem Shop über das 1cs Online Bezahlsystem im Antwortparameter amazonstatus zurückgegeben.
Beispiel: amazonstatus=Abandoned
Im Amazon SCA Handbuch Punkt 3 (Konsistenz des Betrags)
Der Wert AuthorizationAmount (im Schritt Autorisierung) muss immer zum Wert CaptureAmount (im Schritt Buchung) passen.
Falls nicht, wird die Antwort auf die Buchungs-Anfrage asynchron behandelt; der Wert State im Objekt Capture wird auf Pending gesetzt und kann nicht in Echtzeit verarbeitet werden, selbst wenn er innerhalb von sieben Tagen ab dem Aufruf der Autorisierung erfolgt!
4.3 Dynamische Rechnungs-Deskriptoren
Allgemeine Anforderungen
Das Element billingDescriptor dient zum Überschreiben des Händlernamens, der gegebenenfalls an die Bank des Karteninhabers gesendet wird.
Der Händlername ist der wichtigste Faktor für den Karteninhaber, um eine üblicherweise auf seinem Kontoauszug gedruckte Transaktion zu erkennen. Er sollte den üblichen Namen einer Firma (d.h. der Name ‘handelt als’ (DBA)) anstatt der juristischen Bezeichnung enthalten, woran der Karteninhaber den Händler erkennen würde, um Verwechslungen zu vermeiden und Anfragen nach Kopien zu minimieren.
Standardmäßig leitet Acquire den Händlernamen weiter, den sie im Händlerkonto hinterlegt haben. Beachten Sie bitte, dass die Kartenorganisationen strenge Regeln für Händlernamen auf Kontoauszügen festgelegt haben.
Es gibt jedoch eine Reihe spezifischer Ausnahmen, wo abhängig von Anwendungsfall und Branche (z.B. Fluglinien, Bahnlinien, Autovermietungen, Tankstellen usw.) ergänzende Daten zum DBA-Namen hinzugefügt werden können.
Formatierung des Händlernamens
Die Autorisierungs- und Clearing-Systeme der Kartenorganisationen bieten unterschiedlichen Größen für Händlernamen an. Der kleinste gemeinsame Nenner sind 22 Zeichen. Daher passen Händlernamen mit mehr als 22 Zeichen nicht in das Feld für den Händlernamen und müssen in einer Art und Weise abgekürzt werden, die für den Karteninhaber noch erkennbar bleibt.
Kauf von Waren oder Dienstleistungen
Für normale Käufe von Waren oder Dienstleistungen können zusätzliche Informationen hinter dem Händlernamen und einem Sternchen (*) eingefügt werden, um eine Bestellnummer, Referenznummer oder anderen Angaben zur Identifikation einer Transaktion anzugeben.
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
G
R
E
A
T
B
R
A
N
D
L
T
D
*
0
8
1
5
3
7
Für Autovermiter und Hotelhändler darf der Händlername nicht gekürzt werden, um ergänzende Informationen im Feld des Händlernamens unterzubringen.
No-Show-Transaktionen
Sie dürfen nach dem Händlernamen auch die Wörter “NO SHOW” enthalten.
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
H
.
C
A
L
I
F
O
R
N
I
A
N
O
S
H
O
W
Kauf eines Flug-Tickets (oder Passagier-Eisenbahnfahrkarte in Region USA)
Alle folgenden Dinge müssen enthalen sein:
Ein abgekürzter Name der Fluglinie (oder US Eisenbahn) in den ersten 11 oder 12 Zeichen
Gegebenenfalls ein Leerzeichen an Position 12
Ab Position 13 eine Kennung für das Flug- (oder US Eisenbahn-) Ticket
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
F
L
Y
L
O
W
P
L
C
1
2
3
4
5
6
7
8
9
0
4.4 Hinterlegte Zugangsdaten
Wann immer Karten-Zugangsdaten (d.h. Name des Karteninhabers, Kartennummer/Token und/oder Ablaufdatum) für eine zukünftige Verwendung gespeichert werden, ist eine vorherige Zustimmung durch den Karteninhaber erforderlich.
Während der Einrichtung eines solchen Mandats sollte der Karteninhaber über den genauen Grund für die Speicherung der Zugangsdaten beim Händler informiert werden. Das bedeutet, eine Autorisierungsanfrage zur Einrichtung eines Mandats für hinterlegte Zugangsdaten muss auch die Art der möglichen nachfolgenden Transaktionen angeben.
Diese nachfolgenden Transaktionen mit hinterlegten Zahlungsdaten, denen der Karteninhaber zugestimmt hat, werden ganz allgemein in vom Kunden ausgelöste Transaktionen (Customer Initiated Transactions / CITs) und vom Händler ausgelöste Transaktionen (Merchant Initiated Transactions / MITs) kategorisiert.
Hinweis: Der maßgebliche Unterschied zwischen CITs und MITs ist, dass Letztere außerhalb des Geltungsbereiches der RTS für die SCA sind. Das liegt daran, dass der Karteninhaber regelmäß nicht in einer Sitzung ist und daher praktisch für eine Authentisierung nicht zur Verfügung steht.
Es gibt verschiedene Anwendungsfälle für MITs, die allgemein in Transaktionen gemäß einer bestimmten Branchenpraxis sowie ständige Anweisungen eingeteilt werden können.
Im 1cs Online Bezahlsystem sind CITs und MITs für ständige Anweisungen durch das JSON-Objekt credentialOnFile markiert.
Hinweis: Beachten Sie bitte, dass alle außerplanmäßigen MIT-Transaktionen in 3DS 2.0 nicht unterstützt werden und daher direkt zur Autorisierung gesendet werden, ohne in die 1cs Online Bezahlsystem 3DS Sequenz zu gelangen.
Wiederkehrende MIT-Transaktionen werden jedoch über das 3DS 2.0 Protokoll zum Issuer gesendet, um bestmögliche Akzeptanzraten zu garantieren.
Hinweis: Beachten Sie bitte, dass Sie mit jeder anfänglichen CIT, welche ein Mandat für nachfolgenden MITs einrichtet, eine schemeReferenceID erhalten, die bei nachfolgenden Transaktionen übergeben werden muss, um die Sequnz zu verknüpfen.
Nachdem die SCA am 14. September 2019 verpflichtend geworden ist, können durch Zustimmung vom Karteninhaber gedeckte MITs weiterhin ohne eine schemeReferenceID verarbeitet werden, wenn die Mandate dafür vor diesem Datum eingerichtet wurde (d.h. Bestandsschutz). Übergeben Sie bitte keine Platzhalterwerte. Das 1cs Online Bezahlsystem verwendet automatisch entsprechende Werte im Autorisierungs-Protokoll, um den sogenannten Bestandsschutz anzuzeigen.
Vom Karteninhaber ausgelöste Transaktion (Cardholder Initiated Transaction / CIT) Eine vom Karteninhaber ausgelöste Transaktion ist jede Transaktion, an der der Karteninhaber aktiv teilnimmt. Das kann entweder an einem Terminal in einem Geschäft oder beim Bezahlvorgang online sein oder mit hinterlegten Zahlungsdaten, bei denen der Karteninhaber zuvor der Speicherung beim Händler zugestimmt hat.
Vom Händler ausgelöste Transaktion (Merchant Initiated Transaction / MIT) Jede Transaktion, die sich auf eine vorherige vom Karteninhaber ausgelöste Transaktion bezieht, aber ohne aktive Teilnahme des Karteninhabers durchgeführt wird. Im Ergebnis kann der Händler keine Validierung durch den Karteninhaber ausführen. In allen Fällen muss sich eine vom Händler ausgelöste Transaktion auf die originale Interaktion mit dem Karteninhaber beziehen.
4.4.1 Echtzeit-Service über mobile App mit Zahlung nach Service-Abschluss
In vielen Szenarien der gemeinsamen Nutzung wie Car-Sharing oder Bike-Sharing ist das Mobilgerät des Kunden ein entscheidender Bestandteil für die Dienstleistungserbringung und das Zahlungssystem. Kartenzugangsdaten werden für optimale Benutzererfahrung häufig im Konto des Karteninhabers beim Dienstleister gespeichert.
Die Seqeunz der auszuführenden Schritte ist in den nachfolgenen Diagramm skizziert.
Hinzufügen der Karte als Teil einer nicht zahlungswirksamen Transaktion (NPA)
Hinweis: Falls das Hinzufügen der Karte (Card Add) NICHT Teil einer Zahlungstransaktion ist, muss obligatorisch eine Kontoverifizierung durchgeführt werden (siehe AccVerify).
Hinzufügen der Karte als Teil einer Zahlungstransaktion
Service-Bereitstellung
Hinweis: Außerplanmäßige MITs mit hinterlegten Zugangsdaten (UCOF) sind nicht für Szenarien anwendbar, wo der Karteninhaber zum Zeitpunkt des Service-Abschlusses in einer aktiven Sitzung und daher für eine Authentisierung verfügbar ist. Das ist beispielsweise regelmäßig der Fall bei Apps für Car-Sharing oder den Ruf einer Fahrt.
Hinweis: Falls der geschätzte Betrag geringer als der endgültige Betrag ist, ist es empfehlenswert, eine vollständige Stornierung des ursprünglich autorisierten Betrags auszuführen und eine neue Autorisierung für den endgültigen Betrag einzureichen.
Amount
Hinzufügen einer Karte (Card Add)
Ein Nullwert oder ein geschätzter Wert. Beachten Sie bitte, dass der Betrag normalerweise dem Karteninhaber während der Authentisierungs-Challange angezeigt wird und daher im Erwartungsbereich des Kunden liegen sollte.
Service-Bereitstellung
Der Betrag der Autorisierungsanfrage sollte ein Schätzwert für die Service-Bereitstellung sein und im Erwartungsbereich des Kunden liegen. Nach Bereitstellung der Dienstleistung können inkrementelle Autorisierungen erfolgen, bis der endgültige Betrag erfasst wurde.
credentialOnFile
Hinzufügen einer Karte (Card Add)
Das UCOF-Flag wird übermittelt, um ein Mandat zum Speichern von Zugangsdaten einzurichten und die anfängliche schemeReferenceID zu erhalten. Der Kartenherausgeber ist verpflichtet, währnd der Authentisierung eine Verstärkung auszuführen.
Alle Transaktionen zum Hinzufügen von Karten (Card Adds), die nicht Teil einer Zahlungstransaktion sind, erfordern eine Konto-Verifizierung.
4.4.2 Verzögerte Lieferung
In manchen Fällen kann ein Händler eine Bestellung von einem Kunden erhalten, die nicht innerhalb der Haltedauer einer Autorisierung von 7 (d.a. abschließende Autorisierung) beziehungsweise 30 Tagen (d.h. Vorautorisierung) lieferbar ist.
Das ist üblicherweise der Fall für:
individuell konfigurierte Produkte wie Fahrräder, Computer-Server, Möbel oder anderer angefertigte Artikel außerhalb der Standardspezifikationen, die im Auftrag gebaut werden(BTO)
Vorbestellungen kommender Produkte wie neuer Telefonmodelle
ausverkaufte Artikel
Hinweis: Beachten Sie bitte, falls die Autorisierung deutlich später als die anfängliche Bestellung erfolgt, ist es eine gute Praxis, dem Karteninhaber ein paar Tage vor der Autorisierung eine Erinnerung zu schicken, um die Wahrscheinlichkeit zu erhöhen, dass die Gelder verfügbar sind.
Um eine mögliche Haftungsverschiebung der 3DS-Authentisierung zu erhalten, ist es empfehlenswert, zwei Schritte im Prozess zu befolgen:
1. Anfängliches Hinzufügen der Karte als Teil einer nicht zahlungswirksamen Transaktion (NPA)
2. Nachfolgende außerplanmäßige COF MIT mit Authentisierungsdaten aus dem Schritt 1 (UCOF MIT)
Anfängliches Hinzufügen der Karte als Teil einer nicht zahlungswirksamen Transaktion (NPA)
Um das Mandat für eine hinterlegte Karte einzurichten und den karteninhaber zu authentisieren, übermitteln Sie bitte eine Autorisierungsanfrage an das 1cs Online Bezahlsystem.
Betrag
Der angegebene Amount wird innerhalb des 3DS Authensierungsprozesses verwendet und dem Kunden bei der Challenge des Karteninhabers angezeigt. Es sollte der endgültige Betrag sein, der dem Kunden belastet wird, nachdem die Bestellung ausgeführt ist, da dies zugleich der Maximalbetrag für die Haftungsverscheibung ist.
COF
Die Challenge des Karteninhabers wird durch den Indikator credentialOnFile erzwungen, der die Transaktion als Einrichtung eines Mandats für nachfolgenden MITs kennzeichnet.
Konto-Verifizierung
Um eine sofortige Autorisierung des vollen Bestellbetrags auf dem Konto des Karteninhabers zu unterdrücken und die Regeln des Kartensystems für Transaktionen zum Hinzufügen einer Karte einzuhalten, ist es erforderlich, eine Konto-Verifizierung (alias eine Nullwert-Autorisierung) durchzuführen, indem der Parameter AccVerify mit dem Wert ‘Yes’ übermittelt wird.
Das JSON-Objekt threeDSData in der Antwort enthält zusammen mit dem bedingten (d.h. Challenge-Ablauf) JSON-Objekt resultsResponse die nötigen Authentisierungsdaten für die nachfolgende MIT Autorisierungsanfrage, sobald die Bestellung lieferbereit ist.
UCOF MIT
Sobald das Produkt oder die Dienstleistung verfügbar wird und lieferbereit ist oder zu jedem anderem Datum, dass eine Autorisierungsgenehmigung auf dem Konto des Karteninhabers ermöglicht, übermitteln Sie bitte eine als UCOF MIT markierte Autorisierungsanfrage in Kombination mit den Authentisierungsdaten, die Sie bei der anfänglichen Transaktion zur COF-Einrichtung erhalten haben.
COF
Die Markierung credentialOnFile der MIT hindert den Issuer daran, eine Challenge des Karteninhabers anzufordern und verknüpft die Transaktion mittels der schemeReferenceID mit der anfänglichen COF-Transaktion.
threeDSData
Die Haftungsabsicherung lässt such durch Übermitteln des Objekts threeDSData einrichten, dass die Authentisierungsdaten der anfänglichen COF CIT Transaktion enthält.
4.5 Konto-Verifizierung
Eine auch als Nullwert-Aotorisierung bekannte Konto-Verifizierung ist eine Anfrage zur Prüfung, ob ein Kartenkonto in gutem Ansehen ist (d.h. die Karte ist nicht gestohlen und das Kartenkonto kann für Zahlungen verwendet werden).
3DS und Konto-Verifizierung
Beachten Sie bitte, dass bei einer angefragten Konto-Verifizierung (d.h. AccVerify=Yes) in Kombination mit 3DS die Autorisierung stets mit einem Nullwert ausgeführt wird. Die Authentisierung wird hingegen mit dem Betrag ausgeführt, der dem im Feld Amount übermittelten Betrag entspricht. Wenn der übermittelte Amount Null ist, erfolgt die zugehörige Haftungsumkehr ebenfalls für einen Nullwert.
Hinterlegte Zugangsdaten
Beachten Sie bitte, dass nicht zahlungswirksame Transaktionen, die credentialOnFile (alias Card Add) hinterlegen, eine Konto-Verifizierung erfordern.
Unabhängige Konto-Verifizierung
Wenn Sie eine Konto-Verifizierung ohne Hinterlegung einer Karte anfordern, wird das Datenelement browserInfo optional für Server-2-Server und Silent Order Post Integrationen. Andere bedingte Datenelemente sind eventuell auch nicht anwendbar.
4.6 Mehrparteien-E-Commerce / Agenten-Modell
In manchen Szenarien werden Daten des Karteninhabers durch dritte Webseiten im Namen eines oder mehrerer Händler erfasst und verarbeitet (z.B. Authentisierung und Autorisierung). Der Betreiber der dritten Webseite wird normalerweise als ein Agent bezeichnet. Weil der Karteninhaber mit der Umgebung des Agenten interagiert, ist es die Pflicht des Agenten, die Zahlungs-Authentisierung durchzuführen.
Die Anforderungen für Modelle der Agenten-Verarbeitung sind in den folgenden Abschnitten beschrieben.
VISA
Händler im Reise- und Gastgewerbe
Szenario 1: Authentisierung erfolgt durch einen Reise-Agenten im Namen eines einzelnen Händlers
Wenn der Reise-Agent die Authentisierung im Namen eines einzelnen Händlers zum Zeitpunkt der Buchung erleichtert, ist der Prozess folgender:
Der Reise-Agent informiert den Karteninhaber über entsprechende AGB und befolgt andere Anforderungen im Zusammenhang mit dem möglichen zukünftigen MIT-Typ, den der Händler möglicherweise verarbeiten muss
Der Reise-Agent authentisiert die Transaktion über den gesamten Buchungsbetrag (Name zur Händlerbeschreibung = “Name des Reise-Agenten * Name des Händlers” )
Der Reise-Agent kann optional eine Konto-Verifizierung durchführen, um die Gültigkeit der Karte zu prüfen, bevor er die Kartendetails zum Händler weiterleitet (Falls eine Konto-Verifizierung ausgeführt wird, darf sie nicht dden CAVV enthalten, da dies vom Endhändler gefordert wird. )
Der Reise-Agent leitet die Authentisierungsdaten zum Händler weiter
Der Händler übermittelt eine normale Autorisierungsanfrage an das 1cs Online Bezahlsystem einschließlich der erforderlichen Daten im JSON-Objekt threeDSData:request.
Falls der Händler die Zahlung später ausführen möchte, sollte er:
1. innerhalb von 24 Stunden eine Konto-Verifizierung(d.h. AccVerify=Yes)mit den vom Agenten empfangenen Authentisierungsdaten durchführen.
2. wenn der Betrag nachfolgend fällig ist, eine als MIT gekennzeichnete Autorisierung senden einschließlich der schemeReferenceID von der vorherigen Konto-Verifizierung.
Szenario 2: Authentisierung erfolgt durch einen Reise-Agenten im Namen mehrerer anderer Händler
Dieses Szenario betrifft den Fall, wenn eine Kunde online eine Reise-Reservierung über einen Reise-Agenten vornimmt, die Dienstleistungen von mehreren Händlern umfasst.
Der Reise-Agent informiert den Karteninhaber über entsprechende AGB und befolgt andere Anforderungen im Zusammenhang mit dem möglichen zukünftigen MIT-Typ, den der Händler möglicherweise verarbeiten muss
Der Reise-Agent authentisiertdann die Transaktion über den gesamten Buchungsbetrag (Name zur Händlerbeschreibung = “Name des Reise-Agenten” )
Eine zusätzliche 3DS 3RI Authentisierungsanfrageist erforderlich, um die CAVVs für jeden weiteren Händler bereitzustellen, der eine Autorisierung ausführen wird
Der Reise-Agent übermittelt die Authentisierungsdaten an den Händler
Der Händler übermittelt eine normale Autorosierungsanfrage an das 1cs Online Bezahlsystem einschließlich der erforderlichen Daten im JSON-Objekt threeDSData:request.
Falls der Händler die Zahlung später ausführen möchte, sollte er:
1. innerhalb von 24 Stunden eine Nullwert Konto-Verifizierung mit den vom Agenten erhalten Authentisierungswerten durchführen
2. wenn der Betrag nachfolgend fällig ist, eine als MIT gekennzeichnete Autorisierung senden einschließlich der schemeReferenceID von der vorherigen Konto-Verifizierung.
Andere Händler
Szenario 3: Authentisierte CIT vom Agenten und nachfolgende MIT-Transaktion vom Händler
Das ist der Fall, wenn der Agent die Authenrisierung ausführt und nachfolgend die VISA CAVV für seine eigene Autorisierung nutzt. In einem solchen Fall, wo eder Agent bereits die CAVV nutzt und möglicherweise nicht die Funktion 3DS/3RI nutzen kann (um eine neue CVV für den Händler zu haben), kann er dem Händler nur die schemeReferenceID der anfänglichen CIT zusammen mit der Nutzlast bereitstellen, sodass der Händler seine Autorisierungen gekennzeichnet als eine nachfolgende MIT (d.h UCOF, verzögerte Autoriserung) auslösen kann.
Nennenswerte Unterschiede zwischen VISA und Mastercard bei solchen Anwendungsfällen sind:
a) Authentisierungswert (CAVV/AAV)
Bei VISA muss der Agent, der die Authentisierung in Namen mehrerer Händler ausführt, durch die 3DS/3RI Anfrage (nur möglich mit Version EMV 3DS 2.2), um jedem Händler getrennt separate CAVV-Werter bereitzustellen. Auf der anderen Seite sagt MasterCard, dass beim Agenten-Modell, wo eine einzige Authentisierung mit mehreren Autorisierungen verknüpft ist, der gleiche Authentisierungs-Code/AVV für mehrere Transaktionen verwendet werden kann.
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).
* Agenten, welche dieses Szenario (mit CIT/MIT) verwenden, wird empfohlen, ihren Händlern die erforderlichen MasterCard-Referenzdaten bereitzustellen, sodass der Händler diese nachfolgend bei MIT-Transaktionen als “schemeReferenceID” an das 1cs Online Bezahlsystem übermitteln kann.
Bitte beachten Sie auch, dass der obige Ansatz der Behandlung aller Szenarien nur als eine Empfehlung dient. Daher können Händler und Acquirer alternative Optionen wählen, die ihr Geschäftsmodell ergänzen, solange diese zu den Grundprinzipien der PSD2 SCA konform bleiben.
4.7 Nicht zahlungswirksame Authentisierungen für Card Add (Hinzufügen von Kartendaten)
Verwenden Sie bitte AccVerify, um eine Konto-Verifizierung anzufordern, wenn Sie ohne Zahlung eine Karte zu COF (Credential on file – hinterlegte Kartendaten) hinzufügen wollen.
Nicht zahlungswirksame Authentisierungen für Transaktionen zum Hinzufügen von Kartendaten (Card Add) erfordern immer eine verstärkte Authentisierung (d.h. Challenge).
Eine Bereitstellung wie Card Add ist allgemein zu betrachten als eine Aktion über einen Remote-Kanal, die ein Risiko für Zahlungsbetrug oder anderen Missbrauch darstellen kann gemäß Artikel 97(1)(C) PSD2. Für diese Aktionen sind keine Ausnahmen vorgesehen.
Wenn eine Karte zu COF hinzugefügt und gleichzeitig eine Zahlung angefordert wird, ist nur eine starke Kundenauthentifizierung (SCA) erforderlich.
Anwendungsfall
Flags
COF hinzufügen ohne Zahlung
AccVerifycredentialOnFile
COF hinzufügen als Teil einer Zahlung
credentialOnFile
4.8 Obligatorisch und bedingt erforderliche Datenelemente für EMV 3DS
Beachten SIe bitte, dass einige als bedingt erforderlichen Datenelemente in EMV 3DS weiter spezifiziert sind als:
Erforderlich, sofern nicht Markt- oder regionale Mandate das Senden dieser Informationen beschränken.
Das betrifft beispielsweise Datenelemente wie email, phonenumber oder billing address.
Unter Berücksichtigung des rechtlichen Umfelds und abhängig vom Issuer (oder exakter vom Anbieter des Access Control Servers (ACS) des Issuers) kann diese Spezifikation interpretiert werden als streng erforderlich im Europäischen Wirtschaftsraum (EEA).
Im Gegensatz zur EMV 3DS Protokoll-Spezifikation:
A.1 Fehlende erforderliche Felder
. . .
Sofern nicht ausrücklich angegeben, gibt die empfangenden Komponente einen Fehlermeldung zurück, wenn ein erforderliches Feld fehlt . . . Das trifft zu, gleichgültig ob das Feld immer Pflicht oder bedingt erforderlich ist.
haben die Kartensysteme verfügt, dass Issuer EMV 3DS-Nachrichten nicht ablehnen dürfen, wenn eines oder mehrere bedingte Felder fehlen. Die Kartensysteme schreiben aber auch vor, dass Händler bedingte Felder in EMV 3DS-Nachrichten gemäß der geltenden Datenschutzgesetze senden müssen.
Folgende Elemente gelten als zentral, und es wird dringend empfohlen, diese Daten anzugeben:
Informationen zum Karteninhaber
Name
E-Mail-Adresse
Telefonnummer
Mobiltelefonnummer
Rechnungsadresse
Lieferadresse
Browser-Informationen (je nach Integrationsart)
IP-Adresse
Hinweis: Als allgemeine Regel ist es dringend empfohlen, bedingt erforderlich Datenelemente stets zu übermitteln, um unnötige Reibereien und Ablehnungen zu vermeiden.
4.9 schemeReferenceID
Hinweis: Nutzen sie als Händler noch die von den Kartenmarken ausgegebenen dummy SchemereferenceIDs, müssen diese zum 01.11.2022 umgestellt / aktualisiert werden.
Das bedeutet für sie, dass ihre Kunden aufgefordert werden müssen ihre Kartendaten zu aktualisieren und zusätzlich ist eine 3DS Authentifizierung verpflichtend. Für diesen Prozess stehen ihnen die nachfolgenden Möglichkeiten zur Verfügung, welche Sie durch die Erstellung eines Payment Links an die Kunden geben können oder Kunden werden im Shop über eine separate Funktion dazu aufgefordert.
Transaktion inkl. Reservierung eines Rechnungsbetrag X Möchten Sie die Aktualisierung/Umstellung auf eine gültige SchemereferenceID während eines regulären Payments durchführen, d.h. der Kunde soll über einen Betrag X auch belastet werden, nutzen Sie hierfür die Standard Kreditkartenschnittstellen (…payssl.aspx oder auch …paynow.aspx).
Wichtig hierbei ist, dass das JSON Objekt credentialOnFile als CIT + initial=true initialisiert werden muss. Dadurch ist eine 3DS-Challenge verpflichtend und die SchemereferenceID wird basierend darauf generiert und kann für weitere Folgeeinzüge als MIT verwendet werden.
Katenverifikation – 0.00€ Transaktion Möchten Sie die Aktualisierung/Umstellung auf eine gültige SchemereferenceID als Account Verifikation (Prüfung der Kartendaten bei der Bank mit einer 0.00€ Transaktion) durchführen, nutzen Sie hierfür bitte auch die Standard Kreditkartenschnittstellen (…payssl.aspx oder auch …paynow.aspx).
Allgemeine Information Auch hier ist es wichtig das die Transaktion mit dem JSON Objekt credentialOnFile als CIT + initial=true initialisiert wird. Dadurch ist eine 3DS-Challenge verpflichtend und die SchemereferenceID wird basierend darauf generiert und kann für weitere Folgeeinzüge als MIT verwendet werden. Zusätzlich senden Sie in in diesem Fall bitte den weitere Key-Value-Parameter AccVerify mit, dadurch wird nachgelagert eine 0.00 Transaktion ausgelöst.Das ist eine eindeutige direkt von den Kartensystemen wie VISA und MC bereitgestellte Transaktions-ID, um eine Transaktion im gesamten Zahlungs-Ökosystem eindeutig zu referenzieren. Sie wurde anfänglich von VISA gemäß deren Framework-Spezifikationen wie COF (Credential On File) und MIT (Merchant Initiated Transactions) eingeführt und ist relevant für Anwendungsfälle mit Transaktionsarten wie Wiederkehrend, UCOF (MIT), Inkrementell, Verzögerte Autorisierung, Wiedervorlage usw.
Mit der Veröffentlichung der EMV 3DS-Spezifikationen entstand auch für MasterCard die Anforderung, eine derartige eindeutige ID zu verwenden, welche sie “traceID” oder “grandfathering ID” nannten. Die Logik dahinter ist, dass sich der Issuer auf diese ID verlassen kann, um die anfängliche Zahlung mit allen nachfolgenden zu verknüpfen, die sich in einem Dauerauftrag in in einem COF- oder MIT-Regime darauf beziehen. Das ermöglicht dem Issuer, für alle nachfolgenden Zahlungen abweichende Transakationsregeln anzuwenden (d.h. kein CVV/CVC, keine zusätzlichen Authentisierung in EMV 3DS).
In der derzeitigen Situation wurde den Händlern für Mastercard/Maestro-Transaktionen, bei denen die anfängliche Zahlung (Einrichtung einer Vereinbarung) vor dem Inkrafttreten der Regulierung erfolgt ist, in den Autorisierungsantworten keine “schemeReferenceID” bereitgestellt. Computop fordert von jenen Händlern, die diese Anwendungsfälle betreffen, sich bei diesem Parameter bei allen nachfolgenden (COF/MIT) Transaktionen mit ihrem Acquirer über die Verwendung des vom Kartenschemes genehmigten statischen Wertes “Grandfathering” abzustimmen.
Bei anfänglichen Zahlungen (Einrichtung einer Vereinbarung) nach dem 14. September 2019 müssen die Händler den in der Antwort als “schemeReferenceID” bereitgestellten Wert speichern und in allen nachfolgenden Zahlungen, die sich auf diese anfängliche Vereinbarung beziehen, an das 1cs Online Bezahlsystem übermitteln. Bei VISA ist die “schemeReferenceID” äquivalent zum vorherigen 1cs Online Bezahlsystem-Parameter “TransactionID”, den die Händler derzeit gemäß COF & MIT Frameworks übermitteln.
Hinweis: Sollten Ihnen ältere Kartentoken vorliegen, bei denen keine schemeReferenceID erfasst wurde, empfehlen wir die Verwendung der folgenden Platzhalter bei Folgetransaktionen: VISA: 887001863998888 MasterCard: 1231_MCC999999
Diese Werte sind gültig bis Oktober 2022 kombiniert mit der Deaktivierung von 3DSecure 1.0.
Sollte eine Folgetransaktion auch mit Platzhalter-schemeReferenceID fehlschlagen, muss erneut eine initiale Transaktion im Beisein des Kunden durchgeführt werden, um eine schemeReferenceID zu erhalten.
5 Test-Karten
Bis Sie die Programmierung des Zahlungsverkehrs abgeschlossen haben, befindet sich Ihre 1cs Online Bezahlsystem Kasse im Testmodus: Kreditkartenzahlungen werden autorisiert aber es fließt kein Geld, weil das 1cs Online Bezahlsystem keine Buchung ausführt. Hinweis: Bitte nutzen Sie auch im Testmodus nur kleine Beträge zwischen 0,11 Euro und 2 Euro, denn die Kreditkartenautorisierungen sind auch im Test echt und reduzieren das Limit Ihrer Kreditkarte. Wenn Sie größere Beträge nutzen und das Kartenlimit erreichen, wird sonst Ihre Kreditkarte temporär nicht mehr funktionieren.
Hinweis: Bitte bestätigen Sie das Einmal-Passwort im Falle einer Challenge per Mausklick und nicht mit der Eingabetaste, da sonst die Schaltfläche “Abbrechen” ausgewählt und die Authentifizierung abgebrochen wird.
otpValue
transStatus
transStatusReason
ECI
authenticationValue
1234
Y
01
JAmi21makAifmwqo2120cjq1AAA=
1111
N
01
01
2222
R
01
01
3333
U
01
01
6666
Y
01
01
7777
A
01
JAmi21makAifmwqo2120cjq1AAA=
8888
N
10
9999
N
08
0001
N
01
0002
N
02
0003
N
03
0004
N
04
0005
N
05
0006
N
06
0007
N
07
0009
N
09
0010
N
10
0011
N
11
transStatus
transStatus
Beschreibung
Y
Authentisierungs-Verifizierung erfolgreich
N
Nicht authentisiert /Konto nicht verifiziert; Transaktion abgelehnt
U
Authentisierung/ Konto-Verifizierung konnte nicht ausgeführt werden; technisches oder anderes Problem, wie in ARes oder RReq angegeben
A
Verarbeitung der Versuche ausgeführt; Nicht authentisiert/verifiziert, aber Nachweis der versuchten Authentisierung/Verfizierung ist bereitgestellt
C
Challenge erfoderlich; zusätzliche Authentisierung mittels CReq/CRes ist erforderlich
Der entkoppelten Authentifizierung wurde nicht genügend Zeit zur Verfügung gestellt, um den Karteninhaber zu authentifizieren. ACS wird keinen Versuch unternehmen
26
All
Die Authentifizierung wurde versucht, aber vom Karteninhaber nicht durchgeführt
80
Visa
Fehler beim Verbinden zum ACS
80
Mastercard
Wird bei allen Nur-Daten-Authentifizierungen zurückgegeben
80
American Express
Safekey ist für diesen Kartentyp nicht verfügbar
81
Visa
ACS-Zeitüberschreitung
81
Mastercard
Herausforderungsbefreiung akzeptiert
82
Visa
Ungültige Antwort vom ACS
82
Mastercard
Challenge-Mandat angefordert, konnte aber nicht ausgeführt werden.
83
Visa
Systemfehlerantwort vom ACS
83
Mastercard
DS hat den von DS erhaltenen ReasonCode gelöscht
84
Visa
Interner Fehler beim Generieren von CAVV
84
Mastercard
ChallengeCancel wurde gesetzt, daher wird nicht Smart Authentication Stand-In (Trifft Authentifizierungsentscheidung, wenn ACS nicht verfügbar ist) weitergeleitet.
85
Visa
VMID ist für das angeforderte Programm nicht geeignet
86
Visa
Protokollversion, die nicht vom ACS unterstützt wird
87
Visa
Die Transaktion ist von der Verarbeitung von Versuchen ausgeschlossen (einschließlich nicht wiederaufladbarer Prepaid-Karten und Nichtzahlungen (NPA))
88
Visa
Angefordertes Programm wird von ACS nicht unterstützt
6 Begriffe und Definitionen
Obligatorische und bedingte Datenelemente
Bedingungen in 3DS 2.0 sind oft beschrieben als
Erforderlich, sofern nicht Markt- oder regionale Mandate das Senden dieser Informationen beschränken.
Das betrifft zum Beispiel die E-Mail-Adresse des Karteninhabers. Beachten Sie bitte, dass einige Anbieter von ACS-Software sowie manche Issuer diese Datenelemente innerhalb des EWR als technische obligatorisch ansehen können, da derzeit keine Beschränkungen bekannt sind. Daher ist es dringend empfohlen, diese Datenelemente falls möglich zu übermitteln.
Bedingungs-Codes
Code
Bedingung
M
Obligatorisch. Bedeutet, dass das Datenelement in der Nachricht enthalten sein soll.
O
Optional. Das Datenelement kann oder kann nicht in einer Nachricht enthalten sein.
C
Conditional. Das Datenelement soll enthalten sein (d.h. obligatorisch), wenn angegebene Bedingungen erfüllt sind.
Definitionen
Begriff
Definition
Autorisierung
Eine Autorisierung ist eine Genehmigung oder Garantie von Geldmitteln durch den Kartenaussteller an den Acquirer.
Autorisierungs-Avis
Der Acquirer informiert den Kartenaussteller über eine bereits gegebene Autorisierung (z.B. Stimmenautorisierung).
Buchung
Buchung ist der Prozess des Verbindes von genehmigtem Betrag und Autorisierungs-Code einer Transaktion zur Umwandlung in einen abrechenbaren Transaktions-Datensatz. Im Wesentlichen ist es die Anweisung, die Geldmittel vom Konto des Schuldners abzuziehen. Der Acquirer übermittelt nromalerweise eine Buchungsdatei an das Kartennetzwerk (duales Nachrichtensystem). In Systemen mit Host-Buchung sendet der Händler normalerweise eine Nachricht Buchungs-Avis an den annehmenden Host. Bei Systemen mit Terminal-Buchung übermittelt entweder der Kartenakzeptant (z.B. Händler) eine Buchungsdatei (am gebräuchlichsten) zum Acquirer oder führt einen Batch-Upload aus. Die vom Kartenakzeptanten übermittelten Buchungsdatensätze werden üblicherweise beim annehmenden Host validiert und dann zur Buchungsdatei des Acquirers für das entsprechenden Kartennetzwerk hinzugefügt.
Verkauf
Ein Verkauf ist eine Anweisung vom Händler an den Acquirer, in einer einzelnen Nachricht eine Autorisierung sowie eine Buchung der am Verkaufspunkt abgeschlossenen Transaktion anzufordern. Das bedeutet, eine erfolgreiche Autorisierung wird automatisch ohne weitere Anweisungen oder Abschlussnachrichten zur Buchungsdatei des Acquirers hinzugefügt. Einige Systeme mit Terminal-Buchung können jedoch erfordern, dass Verkaufs-Transaktionen in die Buchungsdatei oder in den Bacth-Upload einbezogen werden.
Terminal-Buchung
Terminal-Buchung bedeutet, dass das Terminal Autorisierungen, Verkäufe und Stornierungen den ganzen Tag über an den Host übermittelt. Das Terminal speichert alle diese Transaktionen ebenso wie alle lokal (offline) ausgeführten Transaktionen, so dass das Terminal am Ende des Verarbeitungstages vom Händler eine Batch-Übermittlung ausführen kann. Verarbeitung per Terminal-Buchung gibt dem Händler die Möglichkeit, Offline-Transaktionen auszuführen, die nur im Batch enthalten sind. Offline-Transaktionen umfassen zum Beispiel Rückgaben, Zwischenverkäufe und Trinkgeldkorrekturen.
Host-Buchung
Bei der Verarbeitung mit Host-Buchung werden die Transaktions-Batches vom annehmenden Host verwaltet. Händler übermitteln die Transaktionen so zum Host, wie sie am Verkaufspunkt erfolgen, und der Host zeichnet die Transaktionen in einer Batch-Datei auf. In Nachrichtenprotokollen auf Basis von ISO 8583 wird das oft als Buchungs-Avis bezeichnet. Die Batchdatei wird dann entweder auf Anforderung vom Händlersystem (manuelle Batch-Freigabe) oder jeden Tag zu einer geplanten Zeit geschlossen (Host Auto-close). Die Option Auto-close ist am gebräuchlichsten.
Wiederkehrend
Wiederkehrende Transaktionen sind eine Reihe von Transaktionen, die nach einer Vereinbarung zwischen dem Karteninhaber und einem Händler verarbeitet werden, wobei der Karteninhaber über einen Zeitraum Waren oder Dienstleistungen in einer Reihe separater Transaktionen erwirbt.
Ratenzahlung
Ratenzahlungs-Transaktionen sind ein einzelner Kauf von Waren oder Dienstleistungen, die dem Konto des Karteninhabers in mehreren Teilen über einen Zeitraum berechnet werden, der zwischen dem Karteninhaber und einem Händler vereinbart worden ist.
7 Antwort-Codes
Allgemeine Hinweise zu Paygate-Fehlercodes
1cs Online Bezahlsystem-Fehlercodes haben im Allgemeinen 8 Ziffern und sind wie folgt codiert (d. h. Sie bestehen aus den Ziffern 0..9 und den Zeichen A..Z) in diesem Format: AN8, (NNNNNNNN) z.B. 22060203 oder 2206014H.
Die Struktur der Fehlercodes ist immer wie folgt:
Position
Bedeutung
Beispiel
Digit 1
Zeigt den Statuscode / Fehlercode an
2
Digit 2 .. 4
Zeigt das betroffene Modul an
206
Position 5 .. 8
Zeigt den betroffenen Parameter an, der den Fehler verursacht
0203 or 014H
Ziffer 1: Statuscode oder Fehlercode
Digit 1
Bedeutung
Beschreibung
0
Ok
Operation erfolgreiche abgeschlossen
2
Fehler
Operation gescheitert
4
Fataler Fehler
Operation gescheitert und verarbeitete Daten möglicherweise verloren
6
Temporärer Status
Operation ist nicht abgeschloissen. Der endgültige Status wird asynchron übertragen.
7
EMV 3DS Info
Zwischenzustände in der EMV 3DS Sequenz
Digits 2..4: Common modules
Digit 2..4
Beschreibung
001
Paygate-Kryptographie (Ver- und Entschlüsselung)
010
Paramater fehlt
011
Parameter Formatfehler
012
Parameter ist nicht erlaubt
013
Parameter ist zu kurz
014
Parameter ist zu lang
015
Parameter Wert fehlt
016
Parameter Wert unbekannt oder nicht erlaubt
017
Parameter ist bereits angegeben
018
Parameter ist abgelaufen oder nicht mehr gültig
019
Parameter ist nicht erlaubt für aktuelle Message-Version
020 – 0FF
Paygate intern
100 – FFF
Betroffenes Modul
Digits 2..4: Common modules
Kategotie (2-4)
Der Kategorie-Code ist ein 3-stelliger Wert, der den Zahlungs-Adapter oder das Zahlungs-Protokoll angibt. Für 3DS 2.0 liegen diese Kategorie-Codes abhängig vom Kartenverbinder im Bereich von 100 bis 299.
Detail (5-8)
Status
Kategorie
Detail
Beschreibung
2
xxx
0101
Empfangene Nachricht ungültig
2
xxx
0102
Nachrichten-Versionsnummer nicht unterstützt
2
xxx
0103
Limit gesendete Nachrichten erreicht. Nur für PReq verwendet
2
xxx
0201
Erforderliches Element fehlt
2
xxx
0202
Critical message extension not recognized
2
xxx
0203
Format bei einem oder mehreren Elementen ist gemäß Spezifikationen ungültig
2
xxx
0204
Doppeltes Datenelement
2
xxx
0301
Transaktions-ID nicht erkannt
2
xxx
0302
Fehler der Datenentschlüsselung
2
xxx
0303
Zugriff verweigert, ungültiger Endpunt
2
xxx
0304
ISO-Code ungültig
2
xxx
0305
Transaktionsdaten ungültig
2
xxx
0306
Händler-Kategoriecode ist für das Zahlungssystem ungültig
2
xxx
0307
Seriennummer ungültig
2
xxx
0402
Zeitüberschreitung der Transaktion
2
xxx
0403
Kurzzeitiger Systemausfall
2
xxx
0404
Permanenter Systemausfall
2
xxx
0405
Systemverbindungsfehler
2
xxx
0911
Spezifischer Fehlercode von UnionPay. Vorhanden, wenn die Datenfelder-Relevanzprüfung scheitert (ECI-Wert und AV-Erscheinungsbild sind inkonsistent mit dem Transaktionsstatus).
2
xxx
0912
Spezifischer Fehlercode von UnionPay. Vorhanden bei duplizierter Transaktions-ID (Die Transaktions-ID sollte für alle AReq-Anfragen eindeutig sein).
2
xxx
0985
3DS 2.0 wird von der Karte nicht unterstützt. Der Händler muss dem Fallback-Prozess folgen.
8 3DS 2.0 Händler-Anwendungsfälle & Testen von 3D-Secure 2.0
Was Sie in diesem Kapitel erwarten können? Wegen der verschiendenen Szenarien, die mit 3-D Secure 2.X auftreten können, untergliedern wir das Kapitel in drei thematische Bereiche:
Allgemeine technische Anpassungen (für alle Händler relevant)
Anwendungsfälle für Transaktionskennzeichnung (unterschiedliche Behandlung je nach Händler-Szenario)
Test von 3-D Secure 2.X via Computop
Allgemeine technische Anpassungen
Welche Anfragearten betrifft 3D-Secure 2.0/SCA?
die betroffenen Anfragearten sind: Autorisierung und Verkauf
Buchung und Gutschrift sind von den Änderungen ausgenommen
Wie wird die Datenübertragung an/von die First Cash Solution in Zukunft aussehen?
ANFRAGE: Während der Implementierung von 3D Secure 2.0 und der nötigen Lieferung größerer Datenmengen empfehlen wir Ihnen, unserer Formulare via Form-POST Methode aufzurufen. Beachten Sie bitte, dass die Option iFrame weiterhin verfügbar ist. Der Hintergrund sind mögliche Browserbeschränkungen, die dazu führen können, dass der gesendete Datenstring abgeschnitten wird.
Beispiel:
ANTWORT: Beachten Sie bitte auch die Änderung der abschließenden Weiterleitung zu URLSuccess | URLFailure. Diese wird im Fall von Transaktionen mit 3D Secure 2.0 als ein Body POST ausgeführt. Deshalb sollten Sie sowohl ein GET als auch eine POST Antwort an URLSuccess | URLFailure empfangen können.
Wie kann ich zwischen 3DS 1.0 und 2.0 wählen?
WICHTIG: Um 3D Secure 1.0 oder 3D Secure 2.0 testen oder nutzen zu können, müssen wir 3D Secure an unserem 1cs Online Bezahlsystem in Ihrem Namen konfigurieren. Bitte wenden Sie sich an support@1cs.de, falls Sie diesen Prozess noch nicht begonnen haben.
Standardmäßig erfolgt jede Zahlung gemäß dem Prozess von 3D Secure 1.0.
Wenn Sie das Verfahren für 3D Secure 2.0 nutzen wollen, verwenden Sie bitte den Aufrufparameter MsgVer=2.0. Das gilt für Tests ebenso wie für die spätere produktive Nutzung.
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.
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.
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.
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.
Wir empfehlen dringend, den merchantRiskIndicator (Liefermethode) zu übermitteln. Die Lieferart wird im JSON-Objekt merchantRiskIndicator im JSON-Parameter shippingAddressIndicator übermittelt. Das kann eine positive Auswirkung für eine reibungslose Zahlungsabwicklung haben.
Anwendungsfälle für Transaktions-Kennzeichnung
Szenario 01 – Kreditkarten-Einmalzahlung
Sie bieten Ihren Kunden die Zahlung per Kreditkarte an
Jede Zahlung ist eine Einmalzahlung und deshalb immer eine neue ausgelöste Zahlung
Sie verwenden keine Pseudokartennummer zur Speicherung und Wiederverwendung der Kartendaten
Anmeldedaten sind hinterlegt (CoF)
Sie müssen 3D Secure verwenden
Es sind keine weiteren Anpassungen nötig
Szenario 02 – Kreditkarten-Abonnements
Sie bieten Ihren Kunden die Zahlung per Kreditkarte an
Kunden schließen bei Ihnen ein Abonnement ab, dass IMMER denselben Betrag und das gleiche Zahlungsintervall hat
Sie nutzen die Pseudokartennummer, um die Kartendaten zu speichern und wiederzuverwenden
WICHTIG: Die folgende Anfangszahlung unterliegt der Haftungsverschiebung für Sie als Händler. Im Falle der nachfolgenden Zahlung verfällt diese jedoch, so dass es dort keine Haftungsverschiebung gibt.
Anmeldedaten sind hinterlegt (CoF) – Anfangszahlung des Abonnements
Gilt für PaySSL.aspx + PayNow.aspx
3D Secure ist obligatorisch
Nötige Anpassungen:
Beispiel:
JSON-Objekt credentialOnFile mit JSON-Parameter recurring (3 Schlüssel enthalten)
JSON-Objekt credentialOnFile mit JSON-Parameter initialPayment und dem Wert “true”
Sie bieten Ihren Kunden die Zahlung per Kreditkarte an
Die Kunden kaufen wiederholt in ihrem Shop ein und verwenden dieselben Kreditkartendaten
Sie nutzen die Pseudokartennummer, um die Kartendaten zu speichern und wiederzuverwenden
WICHTIG: Die folgende Anfangszahlung unterliegt der Haftungsverschiebung für Sie als Händler. Im Falle der nachfolgenden Zahlung verfällt diese jedoch, so dass es dort keine Haftungsverschiebung gibt.
Anmeldedaten sind hinterlegt (CoF) – Anfängliche wiederkehrende Zahlung
Gilt für PaySSL.aspx + PayNow.aspx
3D Secure ist obligatorisch
Nötige Anpassungen:
Beispiel:
JSON-Objekt credentialOnFile mit JSON-Parameter unscheduled und dem Wert “CIT”
JSON-Objekt credentialOnFile mit JSON-Parameter initialPayment und dem Wert “true”
Beispiel einer anfänglichen wiederkehrenden Zahlung:
{
"type": {
"unscheduled": "CIT"
},
"initialPayment": true
}
Anmeldedaten sind hinterlegt (CoF) – Folgende wiederkehrende Zahlung
Gilt für Direct.aspx
3D Secure ist NICHT obligatorisch
Nötige Anpassungen:
Beispiel:
Senden Sie bitte die schemereferenceID der Anfangszahlung mit, sodass nachfolgende Systeme die beiden Transaktionen entsprechend verknüpfen können.
JSON-Objekt credentialOnFile mit JSON-Parameter unscheduled und dem Wert “MIT”
JSON-Objekt credentialOnFile mit JSON-Parameter initialPayment und dem Wert “false”
Beispiel für folgende wiederkehrende Zahlung:
{
"type": {
"unscheduled": "MIT"
},
"initialPayment": false
}
Szenario 04 – Kreditkarten-Kontoverifizierung
Sie bieten Ihren Kunden die Zahlung per Kreditkarte an
In diesem Szenario wollen Sie nur die Kreditkarte des Kunden validieren
Sie verwenden die Pseudokartennummer, um die Kartendaten zu speichern und wiederzuverwenden
WICHTIG: Derzeit und zukünftig wollen die Schemes/Kartenmarken die Händler daran hindern, die Validierung der Kartendaten mit einem Minimalbetrag durchzuführen (z.B. 1-Cent-Autosierung). Deshalb bieten Ihnen das 1cs Online Bezahlsystem die entsprechende “NullWertAuthentisierung” an. Dies erfolgt durch Übergabe des zusätzlichen Parameters “AccVerify” in den verschlüsselten Daten – für Details siehe Beispiel unten. Stellen Sie bitte sicher, dass Ihr Kreditkarten-Acquirer diese Funktion unterstützt.
Anmeldedaten sind hinterlegt (CoF) – Validation Request
Gilt für PaySSL.aspx + PayNow.aspx
3D Secure ist obligatorisch
Nötige Anpassungen:
Beispiel:
Senden Sie bitte den Parameter AccVerify=Yes in den verschlüsselten Daten mit (weitere Details finden Sie bitte in unserem Programmierhandbuch)
JSON-Objekt credentialOnFile mit JSON-Parameter unscheduled und dem Wert “CIT”
JSON-Objekt credentialOnFile mit JSON-Parameter initialPayment und dem Wert “true”
Sie bieten Ihren Kunden die Zahlung per Kreditkarte an
Kunden kaufen in Ihrem Shop ein und Sie speichern die Kreditkartendaten in Form einer Pseudokartennummer
Wenn der Kunde wiederkommt, füllen Sie das Kreditkartenformular mit den gespeicherten Daten vor
WICHTIG: Die folgende Anfangszahlung unterliegt der Haftungsverschiebung für Sie als Händler. Im Falle der nachfolgenden Zahlung verfällt diese jedoch, so dass es dort keine Haftungsverschiebung gibt.
Anmeldedaten sind hinterlegt (CoF) – Anfangszahlung für Token-Speicherung
Gilt für PaySSL.aspx + PayNow.aspx
3D Secure ist obligatorisch
Nötige Anpassungen:
Beispiel:
JSON-Objekt credentialOnFile mit JSON-Parameter unscheduled und dem Wert “CIT”.
JSON-Objekt credentialOnFile mit JSON-Parameter initialPayment und dem Wert “true”
Beispiel Anfangszahlung für Token-Speicherung:
Javascript // Adds a Change-Event to the checkbox called 'cbPrefill'
$(“#cbPrefill”).change(function() {
if ($(“#cbPrefill”).is(‘:checked’))
{ // Wenn die Checkbox aktiviert wurde, wird der Wert des Hiddenfields mit den Namen ‘prefill’ auf ‘on’ gesetzt $(“input[type=’hidden’][name=’prefill’]”).val(‘on’); }
else
{ // Wenn die Checkbox deaktiviert wurde, wird der Wert des Hiddenfields mit den Namen ‘prefill’ wieder geleert $(“input[type=’hidden’][name=’prefill’]”).val(”); }
});
// In case of retries (If form gets called a second time due to errors),
// the last status will be set
if ($(“input[type=’hidden’][name=’prefill’]”).val() == ‘on’) {
$(“#cbPrefill”).attr(‘checked’, true);
}
XLS <!– Hiddenfield, which tells Paygate that prefill function should get activated –>
<!– value=”on” means that Paygate will return ‘prefill=on’ in the response to merchant –>
<!– value=”” means that Paygate will not return ‘prefill=on’ in the response to merchant –>
Anmeldedaten sind hinterlegt (CoF) – Folgezahlung für Token-Speicherung
Gilt für PaySSL.aspx + PayNow.aspx
3D Secure ist obligatorisch
Nötige Anpassungen:
Beispiel:
JSON-Objekt credentialOnFile mit JSON-Parameter unscheduled und dem Wert “CIT”
JSON-Objekt credentialOnFile mit JSON-Parameter initialPayment und dem Wert “false”
Senden Sie bitte die schemereferenceID der Anfangszahlung mit (COF-CIT-TRUE), sodass nachfolgende Systeme die beiden Transaktionen entsprechend verknüpfen können.
WICHTIG: Das folgende Szenario gilt nur für PCI-zertifizierte Systeme
Es gibt mehrere Szenarien für die Reisebranche, bei denen wiederkehrende Zahlungen auch der Haftungsverschiebung unterliegen
Beispiel:
Der Kunde bucht eine Hotelzimmer über eine Buchungsplattform, gibt seine Kartendaten ein und führt 3D Secure 2.0 aus. Das wird über einen separaten PSP verarbeitet. Diese Transaktion dient nur zur Validierung der Kartendaten -NullWertAuthentisierung-. Das führt zu einem Authentisierungsstatus = CAVV, den die zentrake Buchungsplattform dann dem Hotelbetreiber meldet (und jedem anderen Dienstleister wie einer Autovermietung, Versicherung usw.). Der Hotelbetreiber macht eine Zahlung OHNE 3DS 2.0 über das 1cs Online Bezahlsystem, fügt aber den CAVV und alle weiteren Daten hinzu. Die zweite Transaktion enthält auch die entsprechende Haftungsverschiebung.
Grundlage dafür, dass das funktioniert und die Haftungsverschiebung erfolgt, ist die Übermittlung des Authentisierungsstatus (CAVV). Dieser wird über eine sogenannte “Externe 3DS Authentisierung” bestimmt. Zwei Schritt sind notwendig:
a. Das externe Händlersystem, welches die erste Zahlung (AccVerify/NullWertAuthentisierung) ausgelöst hat, speichert den Authentisierungsstatus
b. Nachfolgend kann eine wiederkehrende Zahlung über das 1cs Online Bezahlsystem erfolgen. In diesem Fall muss der Händler sowohl das JSON-Objekt threeDSData in den JSON-Daten als auch die originalen Kartendaten der anfänglichen Authentisierung (Card-JSON) einbeziehen. Die Kartendaten müssen deshalb zwecks PCI-Compliance in ihrer originalen Form von der Buchungsplattform an alle relevanten Dienstleister / Agenturen übermittelt werden. Für diesen Zweck erklärt ein separater Abschnitt die nötigen Schritte.
Alle nötigen technischen Informationen sind im Abschnitt Mehrparteien-E-Commerce / Agentur-Modell zu finden.
Szenario 07 – Kreditkarten-MoTo (MailOrder / TelephoneOrder) via PaySSL, Direct oder PayNow
Sie bieten Ihren Kunden die Zahlung per Kreditkarte an, die telefonisch erfasst wird.
Die Kreditkartendaten werden in einer separaten Callenter-Anwendung eingegeben, die eine Zahlung über das 1cs Online Bezahlsystem mittels PaySSL.aspx, Direct.aspx oder Paynow.aspx auslöst.
Sie verwenden die Pseudokartennummer, um die Kartendaten zu speichern und wiederzuverwenden
WICHTIG: MoTo-Zahlungen unterliegen nicht der Haftungsverschiebung, da 3D Secure nicht möglich ist. (Out of Scope)
Anmeldedaten sind hinterlegt (CoF) – Anfängliche MoTo-Zahlung
Gilt für PaySSL.aspx, PayNow.aspx und Direct.aspx
3D Secure ist nicht möglich (Out of Scope)
Nötige Anpassungen:
Beispiel:
JSON-Objekt credentialOnFile mit JSON-Parameter unscheduled und dem Wert “MIT”
JSON-Objekt credentialOnFile mit JSON-Parameter initialPayment und dem Wert “true”
Beispiel einer anfänglichen MoTo-Zahlung:
{
"type": {
"unscheduled": "MIT"
},
"initialPayment": true
}
Anmeldedaten sind hinterlegt (CoF) – Folgende MoTo-Zahlung
Gilt für die automatisierte Zahlungsauslösung via Direct.aspx
3D Secure ist nicht möglich (Out of Scope)
Nötige Anpassungen:
Beispiel:
Senden Sie bitte immer die schemereferenceID der Anfangszahlung mit, sodass nachfolgende Systeme die beiden Transaktionen entsprechend verknüpfen können
JSON-Objekt credentialOnFile mit JSON-Parameter unscheduled und dem Wert “MIT”
JSON-Objekt credentialOnFile mit JSON-Parameter initialPayment und dem Wert “false”
Sie bieten Ihren Kunden die Zahlung per Kreditkarte an, die telefonisch erfasst wird.
Die Kreditkartendaten werden über ein virtuelles Terminal eingegeben.
WICHTIG: MoTo-Zahlungen unterliegen nicht der Haftungsverschiebung, da 3D Secure nicht möglich ist. (Out of Scope)
Anmeldedaten sind hinterlegt (CoF)
Durch die Verwendung des virtuellen Terminals sind keine weitere Anpassungen erforderlich.
Szenario 09 – Batch-Verarbeitung
Die Vorgabe zum korrekten Kennzeichnen von wiederkehrenden Transaktionen seitens der Kartenmarken ist schon eine ältere Anfordung, hierzu hatten wir im Januar 2019 entsprechend informiert. Im Zuge er PSD2-SCA Umsetzung wird diese vollumfänglich zur Pflicht, damit eben wiederkehrende Transaktionen eindeutig gekennzeichnet werden und somit die nachgelagerten Systeme erkennen, warum in diesen Fällen kein 3D Secure verarbeitet wurde, da in diesen Fällen kein Endkunde aktiv am Payment teilnimmt. Somit ist eine Umsetzung für alle Händler verpflichtend. Nachfolgend finden Sie unsere Beschreibungen / Details dazu, d.h. im ersten Schritt muss die initiale Zahlung aus dem Shop heraus als CredentialOnFile gekennzeichnet werden und darauf basierend die wiederkehrenden Batch-Transaktionen.
***initiale Shop-Transaktion oder AccountVerification: Auf unserer Anwendungseite ist das korrekte initiale Flagging (CredentialOnFile) für diverse Anwendungsfälle beschrieben und nachfolgendes Kapitel + Szenario kommt bei Ihnen zum tragen: 3DS 2.0 Händler-Anwendungsfälle & Testen von 3D-Secure 2.0
***wiederkehrende Batch-Einreichung Da aus dem initialen Shop Request die schemeReferenceID generiert und zurückgemeldet wurde, muss dieser eine initiale Wert für alle Batch-Nachreichungen verwendet werden + Angabe RTF=M (M=Merchant Initiated Transaction): Kreditkarten
Kapitel: Batch-Nutzung der Schnittstelle betroffenes Batch Format / Action: CC,Sale,<Amount>,<Currency>,<TransID>,(<RefNr>),<CCBrand>,<CCNr|PCNr>,<CCExpiry>,<OrderDesc>,<textfeld1>,<textfeld2>,<RTF>,<cardholder>,<transactionID>, CC,Authorize,<Amount>,<Currency>,<TransID>,(<RefNr>),<CCBrand>,<CCNr|PCNr>,<CCExpiry>,<OrderDesc>,<textfeld1>,<textfeld2>,<RTF>,<cardholder>,<transactionID>,
Im Batch Request gibt es einmal das Feld “transactionID” + zusätzlich “schemeReferenceID” Feld quasi doppelt, bitte verwenden Sie für die Übergabe ausschließlich das Feld = transactionID.
Die Übergabe des Acquirer Identifier muss im Batchformat im Feld TransactionID erfolgen, d.h. auf die initial 3DS-2.X Transaktion erhalten Sie die schemeReferenceID (im Fall einer 3DS-1.0 Fallback Transaktion als TransactionID) zurück, und dieser Wert muss dann in das Batchformat mit einfließen, damit alle wiederkehrenden Payments korrekt gekennzeichnet werden. Das Feld cardHolder muss vorhanden sein, kann allerdings auch leer übergeben werden.
***PKN Mandat – SchemeReferenceID Sie können versuchen, Payments ohne schemeReferenceID einzureichen, allerdings können wir Ablehnungen dahingehend nicht ausschließen. Sollte es zu einer Ablehnung kommen, empfehlen wir eine separate Transaktion als Card Check (AccVerify=YES) Transaktion über unsere …PaySSL.aspx auszuführen, d.h. der Kunde erhält einen Payment Link, über welchen dieser eine initiale 3DS-2.X Transaktion prozessiert und darüber wird dann die schemeReferenceID gemeldet und kann in den Prozess der wiederkehrenden Zahlungen mit einfließen.
Wegen der ständig nötigen Anpassungen im Bereich der Batch-Abläufe wenden Sie sich bei Fragen bitte an support@1cs.de.
Bei Nutzung des ETMs kümmert sich das 1cs Online Bezahlsystem für Sie um die richtige Markierung der Transaktionen.
Test von 3D Secure 2.0 über die First Cash Solution
Nutzen Sie die Chance, jetzt 3D Secure 2.0 zu testen!
Während derzeit nicht alle nachgelagerten Systeme 3D Secure für Testzwecke anbieten, können Sie im 1cs Online Bezahlsystem eine Testsimulation durchführen. Das ermöglicht Ihnen die Durchführung von 3D Secure Authentisierungen mit verschiedenen Rückgabewerten.
Gehen Sie für Tests bitte folgendermaßen vor:
Aktivieren Sie 3D Secure 2.0 für Ihre First Cash Solution MerchantID. Wenn Sie unsicher sind, ob das bereits aktiviert ist, wenden Sie sich bitte an support@1cs.de
In der verschlüsselten Datenanfrage verwenden Sie den Standardparameter OrderDesc mit dem Wert “Test:0000”. Das gibt Ihnen eine entsprechend erfolgreiche Autorisierung nach einer erfolgreichen Authentisierung. WICHTIG: Im Simulationsmodus wird die schemereferenceID der anfänglichen Zahlung nicht zurückgegeben, weil diese ID von den nachgelagerten Systemen generiert wird. Diese Systeme sind bei der Simulation nicht beteiligt.
Führen SIe die 3D Secure Authentisierung durch
Verwenden SIe bitte NUR die verfügbaren Testkarten (Ablaufdatum immer in der Zulunft + CVV/CVC kann jeden Wert enthalten)
Je nach gewünschtem Szenario (z.B. Browser 3D Secure 2.0 Challenge, reibungslose Browser-Authentisierung usw.) verwenden SIe bitte die entsprechenden Einmal-Passwörter.
9 ECI Codes
Der ECI-Wert wird vom Issuer ACS bereitgestellt. Es gibt die Authentifizierungsstufe an, die für die Transaktion durchgeführt wurde. Der von der Authentifizierung empfangene ECI-Wert wird in der Autorisierungsanforderung weitergeleitet und bestimmt auch, ob eine Transaktion eine Haftungsumkehr (Liability Shift) erhält. Visa, American Express, Diners/Discover, JCB
ECI
Beschreibung
3DS Version(s)
Merchant Liability Shift
05
Karteninhaber-Authentifizierung erfolgreich (dies schließt eine erfolgreiche Authentifizierung mit risikobasierter Authentifizierung und / oder einem dynamischen Kennwort ein)
3DS 1.0 EMV 3DS (2.0)
Yes
06
Der Händler hat versucht, den Karteninhaber zu authentifizieren Für 3DS 1.0.2 kann der ECI Wert 06 nach Ermessen des Issuers als Authentifizierungsantwort vom Issuer-ACS verwendet werden. Beispielsweise können Issuer, die eine risikobasierte Authentifizierung verwenden, einen ECI = 06 für eine Transaktion bereitstellen, für die keine Karteninhaber-Authentifizierung erforderlich ist. Dies wird auch als “frictionless” Authentifizierung bezeichnet. Diese Issuer können einen ECI = 05 für Transaktionen vorsehen, die erfolgreich zur Authentifizierung aufgefordert wurden. Bei 3DS 2.0 kann der ECI 06-Wert nur verwendet werden, um anzuzeigen, dass ein Händler versucht hat, den Karteninhaber zu authentifizieren.
3DS 1.0 EMV 3DS (2.0)
Yes
07
Nicht authentifizierte E-Commerce-Transaktion technische Probleme Konfigurationsfehler Kreditkarte und kartenausgebende Bank nehmen nicht an 3-D Secure teil.
3DS 1.0 EMV 3DS (2.0)
No
Mastercard
ECI
Beschreibung
3DS Version(s)
Merchant Liability Shift
00
Nicht authentifizierte E-Commerce-Transaktion technische Probleme Konfigurationsfehler Kreditkarte und kartenausgebende Bank nehmen nicht an 3-D Secure teil.
3DS 1.0 EMV 3DS (2.0)
No
01
Der Händler hat versucht, den Karteninhaber zu authentifizieren und hat einen Authentifizierungswert (Accountholder Authentication Value (AVV)) erhalten.
3DS 1.0 EMV 3DS (2.0)
Yes
02
Karteninhaber-Authentifizierung erfolgreich (dies schließt eine erfolgreiche Authentifizierung mit risikobasierter Authentifizierung und / oder einem dynamischen Kennwort ein)
3DS 1.0 EMV 3DS (2.0)
Yes
04
Nur Datenaustausch: Nicht authentifizierte E-Commerce-Transaktion, aber der Händler hat beschlossen, Daten über den 3DS-Fluss mit dem Issuer zu teilen, um die Genehmigungsrate für die Autorisierung zu verbessern
EMV 3DS (2.0)
No
06
Acquirer Ausnahme
EMV 3DS (2.0)
No
07
Wiederkehrende Zahlungen können für die erste oder nachfolgende Transaktion gelten Wenn dieser Wert bei der initialen wiederkehrenden Zahlungen eingeht, hat der Händler eine Haftungsumkehr Nachfolgende Transaktionen gelten als MIT und die Haftung verbleibt beim Händler
EMV 3DS (2.0)
Yes
10 transStatusReason Codes
Code
Scheme
Beschreibung
01
All
Kartenauthentisierung fehlgeschlagen
02
All
Unbekanntes Gerät
03
All
Nicht unterstütztes Gerät
04
All
Überschreitet das Authentifizierungshäufigkeitslimit
05
All
Abgelaufene Karte
06
All
Ungültige Kartennummer
07
All
Ungültige Transaktion
08
All
Kein Karteneintrag
09
All
Sicherheitsfehler
10
All
Gestohlene Karte
11
All
Betrugsverdacht
12
All
Transaktion für Karteninhaber nicht erlaubt
13
All
Karteninhaber ist nicht im Dienst registriert
14
All
Zeitüberschreitung der Transaktion beim ACS
15
All
Geringes Vertrauen
16
All
Mittleres Vertrauen
17
All
Hohes Vertrauen
18
All
Sehr hohes Vertrauen
19
All
Übertrifft die maximalen ACS-Challenges
20
All
Nichtzahlungstransaktion wird nicht unterstützt
21
All
3RI-Transaktion wird nicht unterstützt
22
All
Technisches Problem beim ACS
23
All
Entkoppelte Authentifizierung von ACS erforderlich, aber nicht von 3DS Requestor angefordert
Der entkoppelten Authentifizierung wurde nicht genügend Zeit zur Verfügung gestellt, um den Karteninhaber zu authentifizieren. ACS wird keinen Versuch unternehmen
26
All
Die Authentifizierung wurde versucht, aber vom Karteninhaber nicht durchgeführt
80
Visa
Fehler beim Verbinden zum ACS
80
Mastercard
Wird bei allen Nur-Daten-Authentifizierungen zurückgegeben
80
American Express
Safekey ist für diesen Kartentyp nicht verfügbar
81
Visa
ACS-Zeitüberschreitung
81
Mastercard
Herausforderungsbefreiung akzeptiert
82
Visa
Ungültige Antwort vom ACS
82
Mastercard
Challenge-Mandat angefordert, konnte aber nicht ausgeführt werden.
83
Visa
Systemfehlerantwort vom ACS
83
Mastercard
DS hat den von DS erhaltenen ReasonCode gelöscht
84
Visa
Interner Fehler beim Generieren von CAVV
84
Mastercard
ChallengeCancel wurde gesetzt, daher wird nicht Smart Authentication Stand-In (Trifft Authentifizierungsentscheidung, wenn ACS nicht verfügbar ist) weitergeleitet.
85
Visa
VMID ist für das angeforderte Programm nicht geeignet
86
Visa
Protokollversion, die nicht vom ACS unterstützt wird
87
Visa
Die Transaktion ist von der Verarbeitung von Versuchen ausgeschlossen (einschließlich nicht wiederaufladbarer Prepaid-Karten und Nichtzahlungen (NPA))
88
Visa
Angefordertes Programm wird von ACS nicht unterstützt
“Als eine der bekanntesten Opernhäuser der Welt steht die Semperoper Dresden für herausragende Kultur und Qualität.
Im Bereich der Zahlungs-abwicklung setzen wir deshalb auf die 1cs – für uns die perfekte Kombination aus persönlicher Betreuung und individuelle Beratung auf höchstem Niveau.”
Doris Schneider, Leiterin Vertrieb und Service
“Wir setzen bei Fahrrad XXL auf den verlässlichen Service der First Cash Solution und fühlen uns hier bestens aufgehoben!”
Peter Hürter, Fahrrad XXL
“Die First Cash Solution ist stets zuverlässig und bietet einen super Service durch ständige Bereitschaft uns zu helfen sowie schnelle und kompetente Antworten auf all unsere Fragen.”
Thomas Quindt, Projektleiter SOCCERBEAT GmbH
Gebühr der Kartenorganisationen:
Werden von den Kreditkartenorganisationen wie Visa oder Mastercard erhoben, sie werden auch Card Scheme Fees (CSF) genannt.
Bearbeitungsgebühr:
Wird von Deinem Zahlungsanbieter/Acquirer berechnet, in Deinem Fall von uns (1cs). Sie wird auch Acquirer Service Fee (ASF) genannt.
Interchange-Gebühr:
Wird von der kartenherausgebenden Bank bzw. Issuer in Rechnung gestellt. Sie wird auch Interchange Fee (ICF) genannt.
“Hier wird uns bei jedem Anliegen kompetent, unkompliziert und schnell geholfen! Daher können wir die First Cash Solution nur empfehlen.”
Sandra von Bargen, Hachez CHOCOVERSUM GmbH
„Die unkomplizierte schnelle Betreuung passt 100% zu uns und unserem Abrechnungssystem.“