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

• ANFRAGE: Während der Implementierung von 3-D 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 3-D 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 3-D Secure 1.0 oder 3-D Secure 2.0 testen oder nutzen zu können, müssen wir 3-D Secure an unserem  in Ihrem Namen konfigurieren. Bitte wenden Sie sich an , falls Sie diesen Prozess noch nicht begonnen haben.

• Standardmäßig erfolgt jede Zahlung gemäß dem Prozess von 3-D Secure 1.0.

• Wenn Sie das Verfahren für 3-D Secure 2.0 nutzen wollen, verwenden Sie bitte den Aufrufparameter MsgVer=2.0. Das gilt für Tests ebenso wie für die spätere produktive Nutzung.

  • Parameter: MsgVer
    Wert: 2.0

Die Verwendung von JSON-Objekten wird Pflicht

• Beachten Sie bitte, dass mit der Implementierung von 3-D Secure 2.0 eine obligatorische Erweiterung der vorhandenen Parameter verbunden ist. Aus diesem Grund erwartet und antwortet das  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  übertragen werden.

• Bitte übermitteln Sie nur JSON-Objekte mit Werten. Leere oder mit Null gefüllte Objekte/Parameter führen zu einer Ablehnung.

JSON Beispiel-Anfrage - verschlüsseltes "data"

BASEURL=

JSON Beispiel-Anfrage - unverschlüsselte Request-Parameter

Schlüssel Parameter / Objekt

• Wenn Sie nicht Ihre eigene Vorlage verwenden, haben wir Ihre ersten Tests eine neue Vorlage. Sie müssen lediglich das "Template=ct_responsive_ch" zu den verschlüsselten Daten hinzufügen und der vom Kunden eingegebene cardholderName wird automatisch von für den Prozess 3D 2.0 übernommen. Für das geplante / kommende Rollout von 3DS-2.0 wird  die Standardvorlagen  entsprechend anpassen und Ihnen zur Verfügung stellen.

• Wenn Sie Ihre eigene Händlervorlage verwenden und die Abfrage das Karteninhabers dort bisher nicht integriert ist, müssen Sie cardholderName selbst integrieren.

• Beispiel einer XSL-Datei:

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

• Beispiel einer XML-Datei:

For each language used:

<strCCHolder>Cardholdername</strCCHolder>

• Für PaySSL.aspx | PayNow.aspx ist der cardholderName ein Schlüssel-Wert-Paar.

• Für Direct.aspx ist der cardholderName ein JSON-Parameter des JSON-Objekts "Card".

JSON-Objekt – browserInfo

• Für PaySSL.aspx erfasst  die Browserdaten für Sie und daher müssen Sie nichts unternehmen.

• Bei einer Server-zu-Server-verbindung per Direct.aspx oder der Verwendung von PayNow.aspx müssen die individuellen zusätzlichen Anfragen im Shop implementiert werden.

JSON-Objekt – accountInfo

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

JSON Objekt – customerInfo (billToCustomer | shipToCustomer)

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

JSON-Objekt – merchantRiskIndicator

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

Anwendungsfälle für Transaktions-Kennzeichnung

Szenario 01 – Kreditkarten-Einmalzahlung

• Sie bieten Ihren Kunden die Zahlung per Kreditkarte an

• Jede Zahlung ist eine Einmalzahlung und deshalb immer eine neue ausgelöste Zahlung

• Sie verwenden keine Pseudokartennummer zur Speicherung und Wiederverwendung der Kartendaten

Anmeldedaten sind hinterlegt (CoF)

• Sie müssen 3-D 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

• 3-D Secure ist obligatorisch

• Nötige Anpassungen:

  • Beispiel:

    • JSON-Objekt credentialOnFile mit JSON-Parameter recurring (3 Schlüssel enthalten)

    • JSON-Objekt credentialOnFile mit JSON-Parameter initialPayment und dem Wert "true"

    • 
      

    • Beispiel für Anfangszahlung des Abonnements:

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

Anmeldedaten sind hinterlegt (CoF) – Folgezahlung des Abonnements

• Gilt für Direct.aspx

• 3-D Secure ist NICHT obligatorisch

• Nötige Anpassungen:

  • Beispiel:

    • Senden Sie bitte die schemereferenceID der Anfangszahlung mit, sodass nachfolgende Systeme die beiden Transaktionen entsprechend verknüpfen können.

    • JSON-Objekt credentialOnFile mit JSON-Parameter recurring (3 Schlüssel enthalten)

    • JSON-Objekt credentialOnFile mit JSON-Parameter initialPayment und dem Wert "false"

    • Beispiel für Folgezahlung des Abonnements:

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

Szenario 03 – Kreditkarte Wiederkehrende Zahlung / Anzahlung / Schlusszahlung

• Sie bieten Ihren Kunden die Zahlung per Kreditkarte an

• Die Kunden kaufen wiederholt in ihrem Shop ein und verwenden dieselben Kreditkartendaten

• Sie nutzen die Pseudokartennummer, um die Kartendaten zu speichern und wiederzuverwenden

• WICHTIG: Die folgende Anfangszahlung unterliegt der Haftungsverschiebung für Sie als Händler. Im Falle der nachfolgenden Zahlung verfällt diese jedoch, so dass es dort keine Haftungsverschiebung gibt.

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

• Gilt für PaySSL.aspx + PayNow.aspx

• 3-D 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

• 3-D 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-Autorisierung). Deshalb bietet Ihnen das  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

• 3-D Secure ist obligatorisch

• Nötige Anpassungen:

  • Beispiel:

    • Senden Sie bitte den Parameter AccVerify=Yes in den verschlüsselten Daten mit (weitere Details finden Sie bitte in unserem Programmierhandbuch)

    • JSON-Objekt credentialOnFile mit JSON-Parameter unscheduled und dem Wert "CIT"

    • JSON-Objekt credentialOnFile mit JSON-Parameter initialPayment und dem Wert "true"

    • Beispiel der Kontoverifizierung:

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

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

• Sie bieten Ihren Kunden die Zahlung per Kreditkarte an

• Kunden kaufen in Ihrem Shop ein und Sie speichern die Kreditkartendaten in Form einer Pseudokartennummer

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

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

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

• Gilt für PayNow.aspx

• 3-D 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:

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

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

• Gilt für PayNow.aspx

• 3-D Secure ist obligatorisch

• Nötige Anpassungen:

  • Beispiel:

    • JSON-Objekt credentialOnFile mit JSON-Parameter unscheduled und dem Wert "CIT"

    • JSON-Objekt credentialOnFile mit JSON-Parameter initialPayment und dem Wert "false"

    • Senden Sie bitte die schemereferenceID der Anfangszahlung mit (COF-CIT-TRUE), sodass nachfolgende Systeme die beiden Transaktionen entsprechend verknüpfen können.

    • Beispiel Folgezahlung für Token-Speicherung:

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

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

Bitte beachten Sie die nachfolgenden Vorraussetzungen im Bezug auf händlereigene oder Standard-Templates (ct_responsive, Cards_v1).

• Gilt für PaySSL.aspx

• 3-D Secure ist obligatorisch

• Die Haftungsumkehr unterliegt der Haftungsverschiebung für Sie als Händler

• Nötige Anpassungen (händlereigenes Template):

  • Bitte integrieren Sie eine Prefill-Checkbox anhand des im weiteren Verlauf gelieferten Code-Snippets
  • Bitte aktivieren (einkommentieren) Sie den im XSL-File enthaltenen Code zur Vorbelegung der Pseudokartennummer
  • Entscheidet sich der Kunde, die Kartendaten zu speichern (klickt die Checkbox), bekommt das Händlersystem den zusätzlichen, verschlüsselten Response-Parameter "prefill=on" übermittelt. Wird die Checkbox nicht ausgewählt, gibt es keine zusätzliche Benachrichtung über den prefill Parameter.
  • Möchten Sie nun zum registrierten Kunden das Formular mit den Kartendaten vorausgefüllt darstellen, übergeben Sie bitte im verschlüsselten Data das Card JSON Objekt und übermitteln die vorliegende Pseudokartennummer (Token), Ablaufdatum, Kartenmarke und den Kreditkarteninhaber via JSON.
  • Bitte übergeben Sie für den initialen Request als auch zur weiteren vorausgefüllten Zahlung KEIN Credential On File flagging.
• Nötige Anpassungen (-Standardformular):
  • Damit die Prefill-Checkbox auf dem -Formular dargestellt wird, geben Sie uns bitte über den Bescheid. Dann konfigurieren wir die komplette Funktion (Checkbox + COF-Steuerung) für Sie.
  • Bitte übergeben Sie für den initialen Request als auch zur weiteren vorausgefüllten Zahlung KEIN Credential On File flagging.
  • Entscheidet sich der Kunde, die Kartendaten zu speichern (klickt die Checkbox), bekommt das Händlersystem den zusätzlichen, verschlüsselten Response-Parameter "prefill=on" übermittelt. Wird die Checkbox nicht ausgewählt, gibt es keine zusätzliche Benachrichtung über den prefill Parameter.
  • Möchten Sie nun zum registrierten Kunden das Formular mit den Kartendaten vorausgefüllt darstellen, übergeben Sie bitte im verschlüsselten Data das Card JSON Objekt und übermitteln die vorliegende Pseudokartennummer (Token), Ablaufdatum, Kartenmarke und den Kreditkarteninhaber via JSON

// 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);
}

<!-- Hiddenfield, which tells Paygate that prefill function should get activated -->
<!-- value="on" means that Paygate will return 'prefill=on' in the response to merchant -->
<!-- value=""  means that Paygate will not return 'prefill=on' in the response to merchant -->
<input type="hidden" name="prefill"><xsl:attribute name="value"><xsl:value-of select="paygate/prefill"/></xsl:attribute></input>

<!-- Checkbox to (de)activate prefill function -->
 <div id="div_cbPrefill" class="div_cbPrefill">
  <input type="checkbox" name="cbPrefill" id="cbPrefill"></input>
  <span><xsl:value-of select="paygate/language/strCCSaveData" disable-output-escaping="yes"/></span>
  <div class="row"></div>
 </div>

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

• WICHTIG: Das folgende Szenario gilt nur für PCI-zertifizierte Systeme

• Es gibt mehrere Szenarien für die Reisebranche, bei denen wiederkehrende Zahlungen auch der Haftungsverschiebung unterliegen

• Beispiel:

  • Der Kunde bucht ein Hotelzimmer über eine Buchungsplattform, gibt seine Kartendaten ein und führt 3-D 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 zentrale 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 , 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 Schritte sind notwendig:

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

  2. Nachfolgend kann eine wiederkehrende Zahlung über das  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 Callcenter-Anwendung eingegeben, die eine Zahlung über das  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 3-D 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

• 3-D 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

• 3-D Secure ist nicht möglich (Out of Scope)

• Nötige Anpassungen:

  • Beispiel:

    • Senden Sie bitte immer die schemereferenceID der Anfangszahlung mit, sodass nachfolgende Systeme die beiden Transaktionen entsprechend verknüpfen können

    • JSON-Objekt credentialOnFile mit JSON-Parameter unscheduled und dem Wert "MIT"

    • JSON-Objekt credentialOnFile mit JSON-Parameter initialPayment und dem Wert "false"

    • Beispiel einer folgenden MoTo-Zahlung:

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

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

• Sie bieten Ihren Kunden die Zahlung per Kreditkarte an, die telefonisch erfasst wird.

• Die Kreditkartendaten werden über ein virtuelles Terminal eingegeben.

• WICHTIG: MoTo-Zahlungen unterliegen nicht der Haftungsverschiebung, da 3-D 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 3-D Secure verarbeitet wurde, da in diesen Fällen kein Endkunde aktiv am Payment teilnimmt. Somit ist eine Umsetzung für alle Händler verpflichtend.
Nachfolgend finden Sie unsere Beschreibungen / Details dazu, d.h. im ersten Schritt muss die initiale Zahlung aus dem Shop heraus als CredentialOnFile gekennzeichnet werden und darauf basierend die wiederkehrenden Batch-Transaktionen.

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

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

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

Kapitel: Batch-Nutzung der Schnittstelle

betroffenes Batch Format / Action:

CC,Sale,<Amount>,<Currency>,<TransID>,(<RefNr>),<CCBrand>,<CCNr|PCNr>,<CCExpiry>,<OrderDesc>,<textfeld1>,<textfeld2>,<RTF>,<cardholder>,<transactionID>,<schemeReferenceID>
CC,Authorize,<Amount>,<Currency>,<TransID>,(<RefNr>),<CCBrand>,<CCNr|PCNr>,<CCExpiry>,<OrderDesc>,<textfeld1>,<textfeld2>,<RTF>,<cardholder>,<transactionID>,<schemeReferenceID>

Im Batch Request gibt es einmal das Feld "transactionID" + zusätzlich "schemeReferenceID" und in einem der beiden Felden können Sie die initiale schemeReferenceID für wiederkehrende Zahlungen anliefern. Wir empfehlen das Feld=schemeReferenceID zu verwenden.

Beispiele ‒ Batchversion 1.2 ‒ Übergabe der ID im Feld schemeReferenceID:
CC,Sale,<Amount>,<Currency>,<TransID>,(<RefNr>),<CCBrand>,<CCNr|PCNr>,<CCExpiry>,<OrderDesc>,<textfeld1>,<textfeld2>,<RTF>,<cardholder>,<transactionID>,<1234567890>

Die Übergabe des Scheme Identifiers kann im Batchformat im Feld TransactionID / schemeReferenceID erfolgen, d.h. auf die initiale 3DS-2.X Transaktion erhalten Sie die schemeReferenceID / transactionID zurück und dieser Wert muss dann in das Batchformat mit einfließen, damit alle wiederkehrenden Payments korrekt gekennzeichnet sind. Das Feld cardHolder muss vorhanden sein, kann allerdings auch leer übergeben werden. Durch unsere Empfehlung, den Scheme Identifier auch im Feld schemeReferenceID zu übergeben, bleibt das Feld transactionID somit auch leer.

Beispiel:
CC,Sale,999,EUR,987456321,123456789,<VISA>,<0123456789123456>,<052029>,<mein Warenkorb>,,,M,,,<1234567890>

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

Szenario 10 – Erweitertes Transaktions-Management (ETM)

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

Test von 3-D Secure 2.x

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

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

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

• Aktivieren Sie 3-D Secure 2.0 für Ihre  MerchantID. Wenn Sie unsicher sind, ob das bereits aktiviert ist, wenden Sie sich bitte an

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

• Führen SIe die 3-D 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 3-D Secure 2.0 Challenge, reibungslose Browser-Authentisierung usw.) verwenden SIe bitte die entsprechenden Einmal-Passwörter