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

• ANFRAGE: Während der Implementierung von 3D Secure 2.0 und der nötigen Lieferung größerer Datenmengen empfehlen wir Ihnen, unserer Formulare via Form-POST Methode aufzurufen. Beachten Sie bitte, dass die Option iFrame weiterhin verfügbar ist. Der Hintergrund sind mögliche Browserbeschränkungen, die dazu führen können, dass der gesendete Datenstring abgeschnitten wird.
  Beispiel:

  Multiexcerpt include
  SpaceWithExcerpt EN MultiExcerptName payssl-request PageWithExcerpt EN:3DS 2.0 Merchant Use-Cases & Testing of 3D-Secure 2.0 EN

• 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 Paygate unserem 

  Multiexcerpt include
  SpaceWithExcerpt DE MultiExcerptName Platform-Kurz PageWithExcerpt Wording

  in Ihrem Namen konfigurieren. Bitte wenden Sie sich an helpdesk@computop.com

  Multiexcerpt include
  SpaceWithExcerpt DE MultiExcerptName Helpdesk-Name PageWithExcerpt Wording

  , falls Sie diesen Prozess noch nicht begonnen haben.

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

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

  • Parameter: MsgVer
    Wert: 2.0

Die Verwendung von JSON-Objekten wird Pflicht

• Beachten Sie bitte, dass mit der Implementierung von 3D Secure 2.0 eine obligatorische Erweiterung der vorhandenen Parameter verbunden ist. Aus diesem Grund erwartet und antwortet das Paygate das 

  Multiexcerpt include
  SpaceWithExcerpt DE MultiExcerptName Platform-Kurz PageWithExcerpt Wording

  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 Computop Paygate des 

  Multiexcerpt include
  SpaceWithExcerpt DE MultiExcerptName Platform-Name PageWithExcerpt Wording

  ü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 Computop

  Multiexcerpt include
  SpaceWithExcerpt DE MultiExcerptName Partner-Name PageWithExcerpt Wording

  für den Prozess 3D 2.0 übernommen. Für das geplante / kommende Rollout von 3DS-2.0 wird Computop wird 

  Multiexcerpt include
  SpaceWithExcerpt DE MultiExcerptName Partner-Name PageWithExcerpt Wording

  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 Computop erfasst 

  Multiexcerpt include
  SpaceWithExcerpt DE MultiExcerptName Partner-Name PageWithExcerpt Wording

  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 3D Secure 2.0 obligatorisch ist.
  WICHTIG: Wenn Lieferadresse und Rechnungsadresse nicht übereinstimmen, müssen beide Adressen übermittelt werden! Bei digitalen Gütern ist die Rechnungsadresse ausreichend.

JSON-Objekt – merchantRiskIndicator

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

Anwendungsfälle für Transaktions-Kennzeichnung

Szenario 01 – Kreditkarten-Einmalzahlung

• Sie bieten Ihren Kunden die Zahlung per Kreditkarte an

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

• Sie verwenden keine Pseudokartennummer zur Speicherung und Wiederverwendung der Kartendaten

Anmeldedaten sind hinterlegt (CoF)

• Sie müssen 3D Secure verwenden

• Es sind keine weiteren Anpassungen nötig

Szenario 02 – Kreditkarten-Abonnements

• Sie bieten Ihren Kunden die Zahlung per Kreditkarte an

• Kunden schließen bei Ihnen ein Abonnement ab, dass IMMER denselben Betrag und das gleiche Zahlungsintervall hat

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

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

Anmeldedaten sind hinterlegt (CoF) – Anfangszahlung des Abonnements

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

• 3D Secure ist obligatorisch

• Nötige Anpassungen:

  • Beispiel:

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

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

    • 
      

    • Beispiel für Anfangszahlung des Abonnements:

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

Anmeldedaten sind hinterlegt (CoF) – Folgezahlung des Abonnements

• Gilt für Direct.aspx

• 3D Secure ist NICHT obligatorisch

• Nötige Anpassungen:

  • Beispiel:

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

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

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

    • Beispiel für Folgezahlung des Abonnements:

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

Szenario 03 – Kreditkarte Wiederkehrende Zahlung / Anzahlung / Schlusszahlung

• Sie bieten Ihren Kunden die Zahlung per Kreditkarte an

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

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

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

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

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

• 3D Secure ist obligatorisch

• Nötige Anpassungen:

  • Beispiel:

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

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

    • Beispiel einer anfänglichen wiederkehrenden Zahlung:

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

Anmeldedaten sind hinterlegt (CoF) – Folgende wiederkehrende Zahlung

• Gilt für Direct.aspx

• 3D Secure ist NICHT obligatorisch

• Nötige Anpassungen:

  • Beispiel:

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

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

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

    • Beispiel für folgende wiederkehrende Zahlung:

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

Szenario 04 – Kreditkarten-Kontoverifizierung

• Sie bieten Ihren Kunden die Zahlung per Kreditkarte an

• In diesem Szenario wollen Sie nur die Kreditkarte des Kunden validieren

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

• WICHTIG: Derzeit und zukünftig wollen die Schemes/Kartenmarken die Händler daran hindern, die Validierung der Kartendaten mit einem Minimalbetrag durchzuführen (z.B. 1-Cent-Autorisierung). Deshalb bietet Ihnen das Computop Paygate das 

  Multiexcerpt include
  SpaceWithExcerpt DE MultiExcerptName Platform-Name PageWithExcerpt Wording

  die entsprechende "NullWertAuthentisierung" an. Dies erfolgt durch Übergabe des zusätzlichen Parameters "AccVerify" in den verschlüsselten Daten – für Details siehe Beispiel unten.
  Stellen Sie bitte sicher, dass Ihr Kreditkarten-Acquirer diese Funktion unterstützt.

Anmeldedaten sind hinterlegt (CoF) – Validation Request

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

• 3D Secure ist obligatorisch

• Nötige Anpassungen:

  • Beispiel:

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

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

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

    • Beispiel der Kontoverifizierung:

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

Szenario 05 – Kreditkarten Token speichern / Formular vorausfüllen

• Sie bieten Ihren Kunden die Zahlung per Kreditkarte an

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

• Wenn der Kunde wiederkommt, füllen Sie das Kreditkartenformular mit den gespeicherten Daten vor

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

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

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

• 3D Secure ist obligatorisch

• Nötige Anpassungen:

  • Beispiel:

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

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

    • Beispiel Folgezahlung für Token-Speicherung:

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

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

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

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

• Beispiel:

  • Der Kunde bucht ein 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 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 Paygate

    Multiexcerpt include
    SpaceWithExcerpt DE MultiExcerptName Platform-Kurz PageWithExcerpt Wording

    , 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 Computop Paygate erfolgen. In diesem Fall muss der Händler sowohl das JSON-Objekt das 

     Multiexcerpt include
     SpaceWithExcerpt DE MultiExcerptName Platform-Name PageWithExcerpt Wording

     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 Computop Paygate das 

  Multiexcerpt include
  SpaceWithExcerpt DE MultiExcerptName Platform-Name PageWithExcerpt Wording

  mittels PaySSL.aspx, Direct.aspx oder Paynow.aspx auslöst.

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

• WICHTIG: MoTo-Zahlungen unterliegen nicht der Haftungsverschiebung, da 3D Secure nicht möglich ist. (Out of Scope)

Anmeldedaten sind hinterlegt (CoF) – Anfängliche MoTo-Zahlung

• Gilt für PaySSL.aspx, PayNow.aspx und Direct.aspx

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

• Nötige Anpassungen:

  • Beispiel:

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

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

    • Beispiel einer anfänglichen MoTo-Zahlung:

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

Anmeldedaten sind hinterlegt (CoF) – Folgende MoTo-Zahlung

• Gilt für die automatisierte Zahlungsauslösung via Direct.aspx

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

• Nötige Anpassungen:

  • Beispiel:

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

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

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

    • Beispiel einer folgenden MoTo-Zahlung:

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

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

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

• Die Kreditkartendaten werden über ein virtuelles Terminal eingegeben.

• WICHTIG: MoTo-Zahlungen unterliegen nicht der Haftungsverschiebung, da 3D Secure nicht möglich ist. (Out of Scope)

Anmeldedaten sind hinterlegt (CoF)

• Durch die Verwendung des virtuellen Terminals sind keine weitere Anpassungen erforderlich.

Szenario 09 – Batch-Verarbeitung

Die Vorgabe zum korrekten Kennzeichnen von wiederkehrenden Transaktionen seitens der Kartenmarken ist schon eine ältere Anfordung, hierzu hatten wir im Januar 2019 entsprechend informiert. Im Zuge er PSD2-SCA Umsetzung wird diese vollumfänglich zur Pflicht, damit eben wiederkehrende Transaktionen eindeutig gekennzeichnet werden und somit die nachgelagerten Systeme erkennen, warum in diesen Fällen kein 3D Secure verarbeitet wurde, da in diesen Fällen kein Endkunde aktiv am Payment teilnimmt. Somit ist eine Umsetzung für alle Händler verpflichtend.
Nachfolgend finden Sie unsere Beschreibungen / Details dazu, d.h. im ersten Schritt muss die initiale Zahlung aus dem Shop heraus als CredentialOnFile gekennzeichnet werden und darauf basierend die wiederkehrenden Batch-Transaktionen.

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

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

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

Kapitel: Batch-Nutzung der Schnittstelle
betroffenes Batch Format / Action:
CC,Sale,<Amount>,<Currency>,<TransID>,(<RefNr>),<CCBrand>,<CCNr|PCNr>,<CCExpiry>,<OrderDesc>,<textfeld1>,<textfeld2>,<RTF>,<cardholder>,<transactionID>,
CC,Authorize,<Amount>,<Currency>,<TransID>,(<RefNr>),<CCBrand>,<CCNr|PCNr>,<CCExpiry>,<OrderDesc>,<textfeld1>,<textfeld2>,<RTF>,<cardholder>,<transactionID>,

Im Batch Request gibt es einmal das Feld "transactionID" + zusätzlich "schemeReferenceID" Feld quasi doppelt, bitte verwenden Sie für die Übergabe ausschließlich das Feld = transactionID.

Beispiele - Batchversion 1.2:
CC,Sale,<Amount>,<Currency>,<TransID>,(<RefNr>),<CCBrand>,<CCNr|PCNr>,<CCExpiry>,<OrderDesc>,<textfeld1>,<textfeld2>,<RTF>,<cardholder>,<1234567890>

Die Übergabe des Acquirer Identifier muss im Batchformat im Feld TransactionID erfolgen, d.h. auf die initial 3DS-2.X Transaktion erhalten Sie die schemeReferenceID (im Fall einer 3DS-1.0 Fallback Transaktion als TransactionID) zurück, und dieser Wert muss dann in das Batchformat mit einfließen, damit alle wiederkehrenden Payments korrekt gekennzeichnet werden. Das Feld cardHolder muss vorhanden sein, kann allerdings auch leer übergeben werden.

***PKN Mandat - SchemeReferenceID
Sie können versuchen, Payments ohne schemeReferenceID einzureichen, allerdings können wir Ablehnungen dahingehend nicht ausschließen.
Sollte es zu einer Ablehnung kommen, empfehlen wir eine separate Transaktion als Card Check (AccVerify=YES) Transaktion über unsere ...PaySSL.aspx auszuführen, d.h. der Kunde erhält einen Payment Link, über welchen dieser eine initiale 3DS-2.X Transaktion prozessiert und darüber wird dann die schemeReferenceID gemeldet und kann in den Prozess der wiederkehrenden Zahlungen mit einfließen.

Szenario 10 – Erweitertes Transaktions-Management (ETM)

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

  Multiexcerpt include
  SpaceWithExcerpt DE MultiExcerptName Partner-Name PageWithExcerpt Wording

  ETMs kümmert sich das 

  Multiexcerpt include
  SpaceWithExcerpt DE MultiExcerptName Platform-Kurz PageWithExcerpt Wording

  für Sie um die richtige Markierung der Transaktionen.

Test von 3-D Secure 2.x

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 Computop Paygate im 

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

• Aktivieren Sie 3D Secure 2.0 für Ihre Computop Ihre 

  Multiexcerpt include
  SpaceWithExcerpt DE MultiExcerptName Partner-Name PageWithExcerpt Wording

  MerchantID. Wenn Sie unsicher sind, ob das bereits aktiviert ist, wenden Sie sich bitten an helpdesk@computop.combitte an

  Multiexcerpt include
  SpaceWithExcerpt DE MultiExcerptName Helpdesk-Name PageWithExcerpt Wording

• 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