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 Paygate einschließlich der erforderlichen Daten im JSON-Objekt threeDSData [Request].
Falls der Händler die Zahlung später ausführen möchte, sollte er:
innerhalb von 24 Stunden eine Konto-Verifizierung (d.h. AccVerify=Yes) mit den vom Agenten empfangenen Authentisierungsdaten durchführen.
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 authentisiert dann die Transaktion über den gesamten Buchungsbetrag (Name zur Händlerbeschreibung = “Name des Reise-Agenten” )
Eine zusätzliche 3DS 3RI Authentisierungsanfrage ist 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 Paygate einschließlich der erforderlichen Daten im JSON-Objekt threeDSData [Request].
Falls der Händler die Zahlung später ausführen möchte, sollte er:
innerhalb von 24 Stunden eine Nullwert Konto-Verifizierung mit den vom Agenten erhalten Authentisierungswerten durchführen
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 MC bei solchen Anwendungsfällen sind:
a) Authentisierungswert (CAVV/AAV)
Bei VISA muss der Agent, der die Authentisierung in Namen mehrerer Händler ausführt, durch die 3DS/3RI Anfrage (nur möglich mit Version EMV 3DS 2.2), um jedem Händler getrennt separate CAVV-Werter bereitzustellen.
Auf der anderen Seite sagt MasterCard, dass beim Agenten-Modell, wo eine einzige Authentisierung mit mehreren Autorisierungen verknüpft ist, der gleiche Authentisierungs-Code/AVV für mehrere Transaktionen verwendet werden kann.
b) schemeReferenceID
Im dritten Szenario kann der Agent dem Händler zumsammen mti der Nutzlast nur die ‘schemeReferenceID’ aus der anfänglichen CIT ohne Authentisierungsdaten derart bereitstellen, dass der Händler nachfolgende MIT-Transaktionen auslösen kann, die sich auf die anfängliche Einrichtung beziehen.
Für VISA wird die “schemeRefernceID” (transactionID) normalerweise als einzelner Antwort-Parameter bereitgestellt, währen die “schemeReferenceID” bei Mastercard eine Verknüpfung von Feldern ist wie: *(SettlementDate+FinancialNetworkCode& BanknetReference).
-SettlementDate -> n..4
-FinancialNetworkCode -> an..3
-BanknetReference -> an..9
* Agenten, welche dieses Szenario (mit CIT/MIT) verwenden, wird empfohlen, ihren Händlern die erforderlichen MasterCard-Referenzdaten bereitzustellen, sodass der Händler diese nachfolgend bei MIT-Transaktionen als “schemeReferenceID” an das Paygate ü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.