1. Home
2. Integrations- lösungen
3. Integrationen
4. Gehostete Zahlungsseite

1. Einleitung

Unsere Gehostete Zahlungsseite ist die ideale Lösung, damit Sie Ihren Kunden Online-Zahlungen in Ihrem Online-Shop anbieten können. Sie ist eine Mischung aus hoher Vielseitigkeit und Mindestanforderungen:

• Es ist sicher: Wenn Sie den Umgang mit sensiblen Daten an unsere Plattform auslagern, bleibt Ihr PCI-Profil niedrig.
• Es ist flexibel: Gestalten Sie die Zahlungsseite mit den unzähligen Möglichkeiten für die visuelle Anpassung.
• Es ist kundenfreundlich: Bieten Sie Ihren Kunden jede beliebige Zahlungsmöglichkeit an, die von unserer Plattform unterstützt wird.

Diese Grafik bietet Ihnen einen umfassenden Überblick über die beteiligten Parteien und ihre Aufgaben im Zahlungsprozess.

Bevor Sie Live-Transaktionen verarbeiten, sollten Sie zuerst unsere Testumgebung nutzen, um sich ohne irgendwelche Kosten oder Verpflichtungen mehr mit unserer Lösung vertraut zu machen. Sobald Sie loslegen möchten, lesen Sie hier, wie Sie ein Produktionskonto erhalten oder kontaktieren Sie uns.

2. Erste Schritte

Damit Sie auf unserer Plattform mit der Gehostete Zahlungsseite Transaktionen verarbeiten können:

• Benötigen Sie ein auf unserer Plattform Produktionskonto
• Müssen Sie die vorgeschriebenen PCI-Anforderungen erfüllen.
• Muss mindestens eine Zahlungsmethode in Ihrem Konto aktiviert sein (Sie können das unter Configuration > Payment methods überprüfen).
• Ihr Online-Shop wird auf einem Server gehostet, der die Benachrichtigung über HTML-Formulare ermöglicht. Wenn Sie nicht selbst eine Software entwickeln möchten, sehen Sie sich Plugins und Erweiterungen Mit jeder dieser Komplettlösungen können Sie sofort loslegen!

3. Mit Gehostete Zahlungsseite integrieren

Über unseren Gehostete Zahlungsseite Kanal können Sie Transaktionen für alle von uns angebotenen Zahlungsmöglichkeiten verarbeiten. Weitere Informationen dazu, wie es funktioniert und was Sie tun müssen, finden Sie hier.

Den Zahlungsfluss nachvollziehen

In der Grafik werden alle Schritte einer typischen Transaktion auf der Gehostete Zahlungsseite erläutert:

1. Ihr Kunde besucht Ihre Checkout-Seiten und schließt den Kauf auf Ihrer Checkout-Seite ab.
2. Sie senden die Zahlungsanforderung ohne Kreditkartendaten an unsere Endpunkt-URL für die Gehostete Zahlungsseite. Die URL besteht aus einer Reihe von obligatorischen/empfohlenen/optionalen Parametern. Dadurch wird Ihr Kunde ebenfalls zu unserer Gehostete Zahlungsseite weitergeleitet.

• (Optional) Wir rufen die Vorlage ab, um das Erscheinungsbild der Gehostete Zahlungsseite anzupassen.

3. Ihr Kunde gibt seine Kreditkartendaten auf unserer sicheren Gehostete Zahlungsseite

• (Optional) Wir führen dank unserer Tools für Betrugsangebote eine Betrugsprüfung durch.

4. Wir leiten den Kunden zur 3-D Secure-Authentifizierung an seine Emissionsbank weiter.
5. Die Karteninhaber identifizieren sich. Unser System erhält das Ergebnis vom Emittenten.
6. Abhängig vom Ergebnis sind jetzt zwei Szenarien möglich:

• Wenn die Identifizierung nicht erfolgreich war, leiten wir den Karteninhaber an „DECLINEURL“ weiter und beenden den Fluss. Sie erhalten das Ergebnis über Feedback-Kanäle im E-Commerce-Modus.
• Wenn die Identifizierung erfolgreich war, übermitteln wir die tatsächliche Finanztransaktion an den Acquirer, um die Transaktion zu verarbeiten.

7. Wir geben Ihnen das Zahlungsergebnis aus. Abhängig vom Ergebnis des Acquirers leiten wir den Karteninhaber entweder an „ACCEPTURL“, „DECLINEURL“ oder „EXCEPTIONURL“ weiter. Sie erhalten das Ergebnis über Feedback-Kanäle im E-Commerce-Modus.
8. Wenn die Transaktion erfolgreich war, können Sie die Waren/Dienstleistungen liefern.

Zielendpunkt-URLs in Test/Live

Dank unserer Plattform können Sie Anfragen für neue Transaktionen entweder an unsere Testumgebung oder Produktivumgebung senden.

Endpunkt-URL TEST	https://ogone.test.v-psp.com/ncol/test/orderstandard_utf8.asp
Endpunkt-URL LIVE	https://secure.ogone.com/ncol/prod/orderstandard_utf8.asp

Benutzen Sie für Test-Transaktionen ohne finanzielle Auswirkungen die TEST-URL. Die Transaktionen werden an die Testumgebung und damit gleichzeitig an das Testkonto gesendet. Benutzen Sie für echte Transaktionen mit finanziellen Auswirkungen die PRODUKTIONS-URL. Die Transaktionen werden an die Live-Umgebung und damit gleichzeitig an das Live-Konto gesendet. Achten Sie darauf, dass Sie zur LIVE-URL wechseln, sobald Sie die Tests abgeschlossen haben.

Transaktionsanfrage senden

Sobald Ihr Kunde den Kauf auf Ihrer Checkout-Seite für die tatsächliche Zahlung abgeschlossen hat, sendet der Server eine HTTP-POST--Anfrage.

Senden Sie die Anfrage mit einigen obligatorischen/empfohlenen/optionalen Informationen an die Endpunkt-URL der Gehostete Zahlungsseite. Leiten Sie gleichzeitig Ihren Kunden an diese URL weiter.

Eine typische Anfrage sieht so aus:

<form method="post" action="https://ogone.test.v-psp.com/ncol/test/orderstandard_utf8.asp" id=form1 name=form1>

<!-- general parameters: see Form parameters -->
<input type="hidden" name="PSPID" value="">
<input type="hidden" name="ORDERID" value="">
<input type="hidden" name="AMOUNT" value="">
<input type="hidden" name="CURRENCY" value="">
<input type="hidden" name="LANGUAGE" value="">
<input type="hidden" name="CN" value="">
<input type="hidden" name="EMAIL" value="">
<input type="hidden" name="OWNERZIP" value="">
<input type="hidden" name="OWNERADDRESS" value="">
<input type="hidden" name="OWNERCTY" value="">
<input type="hidden" name="OWNERTOWN" value="">
<input type="hidden" name="OWNERTELNO" value="">

<!-- check before the payment: see Security: Check before the payment -->
<input type="hidden" name="SHASIGN" value="">
<!-- layout information: see Look and feel of the payment page -->
<input type="hidden" name="TITLE" value="">
<input type="hidden" name="BGCOLOR" value="">
<input type="hidden" name="TXTCOLOR" value="">
<input type="hidden" name="TBLBGCOLOR" value="">
<input type="hidden" name="TBLTXTCOLOR" value="">
<input type="hidden" name="BUTTONBGCOLOR" value="">
<input type="hidden" name="BUTTONTXTCOLOR" value="">
<input type="hidden" name="LOGO" value="">
<input type="hidden" name="FONTTYPE" value="">

<!-- post payment redirection: see Transaction feedback to the customer -->
<input type="hidden" name="ACCEPTURL" value="">
<input type="hidden" name="DECLINEURL" value="">
<input type="hidden" name="EXCEPTIONURL" value="">
<input type="hidden" name="CANCELURL" value="">
<input type="submit" value="" id=submit2 name=submit2>

</form>
    

Obligatorische/empfohlene/optionale Parameter senden

Sie müssen für jede Transaktion einige Parameter angeben. Weitere detaillierte Informationen zu jedem Parameter, inklusive einer kurzen Beschreibung, der maximalen Länge und vielem mehr, finden Sie in unserem Parameter Cookbook.

Sehen Sie sich für eine typische Transaktionsanforderung die obligatorischen, empfohlenen und optionalen Parameter an:

Obligatorisch

Parameter	Description / Possible values / category
PSPID	The name of your account on our platform to which you send the transaction request.
ORDERID	A unique order number for each request. The parameter ORDERID is used to check whether requests are accidentally sent twice to our platform. If two transactions with the same value for ORDERID are sent within 45 days, we will block the second transaction. This check applies only if the first transaction’s PAYIDSUB has reached one of the following statuses: 2 5 9  Consequentially, an ORDERID can be used only once within 45 days. After that period, ORDERIDs already sent can be re-used
AMOUNT	Amount to be paid by your customer Multiply the amount by 100 as this parameter must not contain any decimals or other separators Example: If the order is 12,34 €, you need to send AMOUNT=1234
CURRENCY	Currency of the amount in ISO 4217 format (ie EUR, GBP etc.)
LANGUAGE	The language our Gehostete Zahlungsseite is displayed to your customer. The value is a combination of ISO 639-1 (language) and ISO 3166-1 (country) Examples: en_US fr_FR Find a full list of all language we support in our Parameter Cookbook.
SHASIGN	Unique character string for order data validation. It is used to make sure that the transaction request is indeed from your server and has not been manipulated by an unauthorised third party.   Learn here to learn how to construct it.

Empfohlen

EMAIL	Your customer’s address / contact data
OWNERADDRESS
OWNERZIP
OWNERTOWN
OWNERCTY
OWNERTELNO
TP PMLISTTYPE	Modify the look and feel of the Gehostete Zahlungsseite Learn here how to do it

Optional

COMPLUS	Fields to send any additional data you would like to receive in the transaction feedback Learn here to learn how to use them
PARAMPLUS
PM	Make specific payment methods (un)available on the Gehostete Zahlungsseite or redirect your customers directly to third-party payment method services (ie. Paypal, iDEAL etc.) Learn here how to use them
BRAND
PMLIST
EXCLPMLIST
CREDITDEBIT
OPERATION	Override the default operation code in your Back Office for each transaction  Learn here how to use it
USERID	Link transactions to a specific user in your data bases Learn here how to use it
ACCEPTURL DECLINEURL  EXCEPTIONURL CANCELURL HOMEURL  CATALOGURL  BACKURL	URLs to receive transaction feedback and to redirect your customers depending on the outcome Learn here to learn how to use them

SHASIGN-Wert berechnen

Ein wesentlicher Bestandteil des Transaktionsflusses ist, zu gewährleisten, dass an unsere Plattform gesendete Transaktionen legitim sind.

Damit keine unbefugte Drittpartei Ihre Transaktionsanfrage manipulieren kann, benutzen wir eine für Sie sichere und einfach zu implementierende Methode: das Senden des Parameters SHASIGN. SHASIGN ist eine eindeutige Zeichenfolge, die nur von zwei Parteien erstellt werden kann: von Ihnen und der Worldline.

Die Zeichenfolge basiert auf Daten, die zusammen mit den Transaktions- und Sicherheitseinstellungen im Back Office gesendet wurden.Diese Einstellungen sind nur für Sie und die Worldline zugänglich. Für jede Transaktion rekonstruiert unser System die in SHASIGN gesendete Zeichenfolge. Wenn beide Zeichenfolgen übereinstimmen, prüft unsere Plattform die legale Transaktion und verarbeitet sie.

Erstellen Sie den Wert für SHASIGN nach diesen Regeln:

1. Verketten Sie alle Parameter/Werte gemäß dieser Formel zu einer Zeichenfolge:

Parametername + = + Parameterwert + SHA-IN-Passphrase

Achten Sie darauf, dass

• Benutzen Sie die SHA-IN-Passphrase, die Sie im Back Office unter Configuration > Technical Information > Checks for e-Commerce & Alias Gateway > SHA-IN pass phrase definiert haben.
• Schließen Sie alle Parameter (und nur diese) ein, die unser System prüft. Ordnen Sie sie alphabetisch wie in dieser Liste definiert.
• Normalisieren Sie die Daten (entfernen Sie führende/nachstehende Leerzeichen).

Beispiel (nur mit obligatorischen Parametern):

Parameter aus der Transaktionsanfrage

_{AMOUNT=1500 (15.00 x100)
CURRENCY=EUR
LANGUAGE=en_US
ORDERID=1234
PSPID=MyPSPID}

SHA-IN-Passphrase wie in Back Office definiert

_{Mysecretsig1875!?}

Verkettete Zeichenfolge:

_{AMOUNT=1500Mysecretsig1875!?CURRENCY=EURMysecretsig1875!?LANGUAGE=en_USMysecretsig1875!?
ORDERID=1234Mysecretsig1875!?PSPID=MyPSPIDMysecretsig1875!?}

2. Hashen Sie die verkettete Zeichenfolge gemäß des ausgewählten Hash-Verfahren im Back Office unter Configuration > Technical Information > Global security parameters > Hash algorithm.

Digest (für das SHA-1-Verfahren):

_{F4CC376CD7A834D997B91598FA747825A238BE0A}

3. Senden Sie Ihre Transaktionsanfrage einschließlich des Digests im Parameter SHASIGN:

Parameter aus der Transaktionsanfrage:

_{AMOUNT=1500 (15.00 x100)
CURRENCY=EUR
LANGUAGE=en_US
ORDERID=1234
PSPID=MyPSPID}

_{SHASIGN=F4CC376CD7A834D997B91598FA747825A238BE0A}

Sobald wir eine Transaktionsanfrage erhalten, berechnen wir die Zeichenfolge anhand der von Ihnen gesendeten Parameter und der im Back Office definierten SHA-IN-Passphrase bzw. Hash-Verfahren neu.

Wenn wir denselben Wert erhalten, den Sie gesendet haben, leiten wir den Kunden auf unsere Gehostete Zahlungsseite weiter,  sodass Ihr Kunde seine Kreditkartendaten eingeben kann.

Bei nicht übereinstimmenden Werten leiten wir den Kunden auf eine Fehlerseite weiter und brechen die Transaktion ab.

Weitere Informationen zur Fehlerbehebung bei Transaktionen dieser Art finden Sie im Back Office unter Configuration > Error. Dort werden diese Transaktionen als „unbekannte Bestellung“ protokolliert. Im System wird dort das von Ihnen gesendete SHASIGN und das vom System erstellte angezeigt. Dadurch können Sie die SHASIGN-Berechnung anpassen. In unserem Leitfaden für Fehlerbehebung finden Sie weitere Informationen zur Lösung dieses Problems.  

Fügen Sie keine leeren Parameter in die verkettete Zeichenfolge ein. Benutzen Sie Großbuchstaben für die Parameter  URL-dekodieren Sie die Zeichenkette, die Sie verhashen möchten  Alle Zeichen in der verketteten Zeichenfolge müssen in Großbuchstaben geschrieben werden. Obwohl wir die Hashing-Methoden SHA-1/SHA-256/SHA-512 unterstützen, empfehlen wir SHA-256 oder SHA-512. Sie bieten maximale Sicherheit für den Verifizierungsprozess. Als zusätzliche Sicherheit sollten Sie verschiedene SHA-Passphrasen in unseren Testumgebung and Produktivumgebung

Back-Office-Einstellungen definieren

Damit Sie Transaktionen erfolgreich verarbeiten können, müssen Sie im Back Office auch einige Einstellungen definieren. Sie finden Sie unter Configuration > Technical information unter verschiedenen Registerkarten.  

Hier finden Sie eine Übersicht über die obligatorischen, empfohlenen und optionalen Einstellungen:

Obligatorisch

Back Office-modul	Beschreibung/Funktion
Global Security parameters > Hashing method > Hash algorithm	Definieren Sie das Hash-Verfahren für die verkettete Zeichenfolge, um den SHASIGN-Wert zu berechnen.
Data and origin verification > Checks for e-Commerce & Alias Gateway > SHA-IN pass phrase	Definieren Sie die SHA-IN-Passphrase, die der verketteten Zeichenfolge hinzugefügt wird, um den SHASIGN-Wert zu berechnen.

Empfohlen

Back Office-modul	Beschreibung/Funktion
Global transaction parameters > Payment retry	Versuche pro Transaktionsanfrage, die Sie Ihren Kunden gewähren, damit sie ihre Zahlung erfolgreich abschließen können. Wenn der letzte Versuch fehlschlägt, erreicht die Transaktion den Status 2.
Global transaction parameters > Processing for individual transactions	Unsere Plattform bietet Ihnen drei Möglichkeiten, um die Zahlungsanforderungen, die wir an unsere Acquirer senden, zeitlich zu steuern. Wählen Sie die am besten zu Ihrem Geschäftsmodell passende aus: Always online (Immediate): Wir senden die Transaktion direkt nach dem Erhalt Ihrer Anfrage. Wenn der Acquirer nicht verfügbar ist, erreicht die Transaktion den Status 2. Diese Möglichkeit eignet sich für Waren/Dienstleistungen, die Sie sofort nach Erhalt der Bestellung liefern müssen. Online but switch to offline when the online acquiring system is unavailable: ): Wir senden die Transaktion direkt nach dem Erhalt Ihrer Anfrage. Wenn der Acquirer nicht verfügbar ist, versuchen wir, die Anfrage zu einem späteren Zeitpunkt noch einmal zu senden. Diese Möglichkeit eignet sich für Waren/Dienstleistungen, bei der der Versand nicht direkt nach der Bestellung erfolgen muss. Always offline (Scheduled): Wir senden die Transaktion zu bestimmten Annahmeschlusszeiten (ca. vier Stunden nach dem Versand). Da Ihr Kunde nicht auf das Echtzeitergebnis warten muss, ist die Bestellung schneller abgeschlossen als bei den anderen Möglichkeiten. Folglich erhalten sowohl Sie als auch Ihr Kunde einen endgültigen Transaktionsstatus mit einer Verzögerung von mehreren Stunden. Diese Möglichkeit eignet sich für Waren/Dienstleistungen, bei der der Versand nicht direkt nach der Bestellung erfolgen muss.
Transaction feedback > eCommerce > HTTP redirection in the browser	Definieren Sie die URLs, zu denen Ihre Kunden abhängig vom Ergebnis weitergeleitet werden. Weitere Informationen erhalten Sie im entsprechenden Kapitel.
Transaction feedback > eCommerce > Direct HTTP server-to-server request	Legen Sie die URLs und den Zeitpunkt fest, zu dem Sie das Transaktionsfeedback erhalten möchten. Weitere Informationen erhalten Sie im entsprechenden Kapitel.
Transaction feedback > eCommerce > Dynamic e-Commerce parameters	Wählen Sie die Parameter aus, die im Transaktionsfeedback enthalten sein sollen. Weitere Informationen erhalten Sie im entsprechenden Kapitel.
Transaction feedback > eCommerce > All transaction submission modes > Security for request parameters	Definieren Sie eine SHA-OUT pass phrase, um den Ursprung des Transaktionsfeedbacks zu überprüfen. Weitere Informationen erhalten Sie im entsprechenden Kapitel.
Transaction feedback > eCommerce > All transaction submission modes > HTTP request for status changes	Legen Sie die URL und den Zeitpunkt fest, zu dem Sie nach der ersten Bestellung Feedback zu Änderungen des Transaktionsstatus erhalten möchten. Weitere Informationen erhalten Sie im entsprechenden Kapitel.

Optional

Back Office-modul	Beschreibung/Funktion
Global transaction parameters > Default operation code	Legen Sie fest, ob unsere Plattform Ihre Transaktionen zum Zeitpunkt der Anfrage als Autorisierungen (Status 5) oder Direktverkauf (Status 9) verarbeiten soll. Weitere Informationen erhalten Sie im entsprechenden Kapitel.
Global transaction parameters > Default data capture (payment) procedure	Legen Sie das Verfahren und den Zeitpunkt fest, zu dem Transaktionen mit dem Status 5 erfasst werden sollen. Weitere Informationen erhalten Sie im entsprechenden Kapitel.
Payment page > Cancel button	Blenden Sie auf der Gehostete Zahlungsseite eine Schaltfläche ein bzw. aus, mit der Ihre Kunden die Transaktion abbrechen können.
Payment page > Back button redirection	Legen Sie die URL fest, an die Ihre Kunden weitergeleitet werden, wenn sie auf der Gehostete Zahlungsseite auf die Schaltfläche „Zurück“ klicken.
Payment page > General terms and conditions	Binden Sie auf der Gehostete Zahlungsseite einen Link zu den Allgemeinen Geschäftsbedingungen ein.
Transaction e-mails > E-Mails to the merchant	Legen Sie fest, ob Sie für verarbeitete Transaktionen E-Mails vom System erhalten möchten. Weitere Informationen erhalten Sie im entsprechenden Kapitel.
Transaction e-mails > E-mails to the customer	Legen Sie fest, ob Ihre Kunden für verarbeitete Bestellungen E-Mails vom System erhalten sollen. Weitere Informationen erhalten Sie im entsprechenden Kapitel.

4. Erscheinungsbild der Zahlungsseite selbst anpassen

Mit unserer Plattform können Sie das Erscheinungsbild der Gehostete Zahlungsseite größtenteils selbst anpassen. Wenn Sie die Zahlungsseite an Ihre Corporate Identity anpassen, schließen Ihre Kunden die Bestellung eher ab, wenn sie auf die Gehostete Zahlungsseite weitergeleitet wurden.

Werfen Sie einen Blick auf unserer Empfehlungen für die Zahlungsseite um Ihre Konversionsrate zu optimalisieren!

Hier finden Sie weitere Informationen dazu, wie Sie diese Funktion und die vielfältigen Möglichkeiten nutzen, um das Zahlungserlebnis Ihrer Kunden zu verbessern.

Wenn Sie die Vorlagen mit unserer Plattform hosten, ändert sich Ihre PCI-Stufe nicht. Wenn Sie die Vorlagen selbst hosten möchten, müssen Sie möglicherweise eine höhere PCI-Stufe erfüllen. Detaillierte Informationen erhalten Sie von Ihrem Acquirer.

Die Vorlage „Responsive Zahlungsseite“ von Worldline benutzen

Am einfachsten können Sie die Gehostete Zahlungsseite mit der Vorlage „Responsive Zahlungsseite“ (RZS) anpassen. Die Vorlage ist perfekt für ein Online-Einkaufserlebnis mit mehreren Bildschirmen für Ihre Kunden. Sie gewährleistet eine optimierte Konvertierung sowohl auf Desktop- als auch auf mobilen Geräten.

Damit wir Ihnen den Einstieg erleichtern und Sie sich mit allen Möglichkeiten vertraut machen können, stellen wir Ihnen eine vollständige Demo-Vorlage zur Verfügung. So können Sie sie aktivieren:

1. Laden Sie die ZIP-Datei
2. Melden Sie sich im Back Office Gehen Sie zu Configuration > Template > Template selection > eCommerce payment page und klicken Sie auf „ACTIVATE“.
3. Gehen Sie zu Configuration > Template > File Manager > Upload Template Files. Laden Sie den gesamten Inhalt der ZIP-Datei hoch. Nach ein paar Minuten hat das System die Dateien überprüft (unter „Uploaded Files“ werden sie in der Spalte „Status“ mit dem Wert „Validated“ angezeigt). Sie sind jetzt auf der Gehostete Zahlungsseite verfügbar.
4. Gehen Sie zu Configuration > Template > Template selection > eCommerce payment page. Wählen Sie im Drop-Down-Menü „Default merchant template“ die HTML-Datei „IngenicoResponsivePaymentPageTemplate_index.html“ aus.
   

Für die Vorlage „Responsive Zahlungsseite“ müssen Sie die Zahlungsmöglichkeiten senkrecht anordnen. Senden Sie dazu für jede Transaktion den zusätzlichen Parameter PMLISTTYPE = 2. Wir empfehlen, die Breite und Höhe Ihrer Logos auf eine Größe von 300 Pixel zu begrenzen. Dadurch wird die Ladezeit auf Smartphones auf ein Minimum reduziert.

Eigene Vorlagen für „Responsive Zahlungsseiten“ erstellen

Dank unserer Plattform können Sie auch die Demo-Datei vollständig nach Ihren Vorstellungen anpassen. Dadurch können Sie selbst Vorlagen von Grund auf neu erstellen und bestimmten Anlässe wie Black Friday, Silvester, usw. entsprechend einrichten und benutzen.

Fügen Sie dazu diese Elementen hinzu:

• HTML-Datei: Die Grundlage für jede Vorlage (so wie „IngenicoResponsivePaymentPageTemplate_index.html“ aus der Demo-Datei)
  Die Vorlagenseite kann ganz nach Ihren Wünschen gestaltet werden. Sie müssen nur die Platzhalterzeichenfolge „$$$PAYMENT ZONE$$$“ unbedingt einfügen:

<html>$$$PAYMENT ZONE$$$</html>

Dieser Platzhalter ist für die Felder bestimmt, in die Ihre Kunden ihre Kreditkartendaten eingeben. In diesem Bereich können Sie können die Elemente mit einer CSS-Datei ändern.
Sie können diese Dateitypen in die Vorlage einfügen: .css, .jpg, .jpeg, .gif, .png, .html, .js.
Mit „$$$TP RESOURCES URL$$$/[Ihr Dateiname]“ können Sie in der Datei auf sie verweisen.

<html><head>        <link rel=”stylesheet” type=”text/css” href=”$$$TP RESOURCES URL$$$/yourFile.css”>        <script scr=”$$$TP RESOURCES URL$$$/test.js”></script></head><body><div>$$$PAYMENT ZONE$$$</div></body></html>

Achten Sie darauf, dass Sie alle Referenzdateien im Back Office unter Configuration > Template > File Manager > Upload Template Files hochladen.

Klammern Sie die Zeichenfolge „$$$PAYMENT ZONE$$$“ nicht mit BASE-Tags, Frames oder FORM-Tags ein.

CSS-Datei: Mithilfe von Stylesheets können Sie sowohl die Elemente in der HTML-Datei als auch den Bereich für die Felder anpassen, in die Ihre Kunden ihre Kreditkartendaten eingeben. Dafür haben wir eine Klasse für die verschiedenen Elemente in diesem Bereich definiert. Sie müssen diesen Codeblock zwischen den Tags <head></head> einfügen und die Eigenschaften dieser Klassen so ändern, dass sie zum Erscheinungsbild Ihrer Seite passen:

<style type="text/css"><!--td.ncolh1 {background-color : #006600; color : yellow; font-family : verdana}td.ncoltxtl {background-color : #ffffcc; color : black; text-align : right; font-weight : bold}td.ncoltxtl2 {background-color : #ffffcc; color : black; text-align : right; font-weight : bold}td.ncoltxtr {background-color : #ffffcc; color : black; text-align : left; font-weight : bold}td.ncoltxtc {background-color : #ffffcc; color : black; text-align : center; font-weight : bold}td.ncolinput {background-color : #ffffcc; color : black}td.ncolline1 {background-color : #ffffff; color : black}td.ncolline2 {background-color : #ffffcc; color : black}
input.ncol {background-color : #006600; color : white}td.ncollogoc {background-color : #ffffcc; color : black; text-align : center; font-weight : bold}table.ncoltable1 { background-color: #ffffcc; }table.ncoltable2 { background-color: #ffffcc; border-width : medium; border-color : green; }table.ncoltable3 { background-color: #ffffcc; }--></style>

Diese Screenshots vom Fenster mit der Auswahl der Zahlungsmöglichkeiten, vom Zahlungsformular und von der Ergebnisseite stellen dar, von welchen Elemente genau Sie die Eigenschaften ändern können. 

Wie in der HTML-Datei können Sie auf Dateien im CSS verweisen. Geben Sie statt „$$$TP RESOURCES URL$$$/[Ihr Dateiname]“ einfach „./[Ihr Dateiname]“ ein.

Achten Sie darauf, dass Sie die festgelegte Cascading Style Sheet-Syntax einhalten. Testen Sie das CSS in verschiedenen Browsern, da jeder den Style anders wiedergeben kann.

Vorlagen für Mobiltelefone erstellen

Obwohl die Vorlage „Responsive Zahlungsseite“ für alle Geräte geeignet ist, bieten wir Ihnen auch spezielle Dateien an, um das Zahlungserlebnis auf Mobiltelefonen zu verbessern. Vergleichen Sie die Markenversion und die „Grundversion“. Sie können beide hier herunterladen.

Die Basis für beide Versionen ist eine HTM-Datei namens „StandardMobileTemplate“ bzw. „StandardMobileTemplate_Generic“.  Im Gegensatz zur Standardvorlage für „Responsive Zahlungsseiten“ handelt es sich bei dieser Datei um eine Kombination aus einer HTML- und einer CSS-Datei. Die CSS-Eigenschaften finden Sie hier:

Beispielscreenshot	Eigenschaften
Die Kopfzeile der Zahlungsseite:	.securedBG{background: #797979;}.secured{padding: 8px 20px 0px 40px;color: #ffffff;width: 235px;margin: 0 auto;background: url("lock.png") 5px no-repeat #797979; height: 30px; }- Order Summarytable.ncoltable1{width: 100%;margin: 0 auto;min-width: 300px !important;}td.ncoltxtl{font-family: open-sans ,Verdana,sans-serif;font-size: 14px;background-color:#ffffff;text-align : left !important;font-weight : bold !important;vertical-align:bottom;}td.ncoltxtr{text-align: left;font-weight: normal;font-family: open-sans ,Verdana,sans-serif;font-size: 14px;background-color:#ffffff;}
Im Bereich „Zahlungsdetails“, in dem die Kunden ihre Kreditkartendaten eingeben:	td.ncolinput{text-align: left;font-weight: normal;font-size: 14px;font-family: open-sans ,Verdana,sans-serif; display: block;box-shadow: none !important;}input.ncol{background-color: #ffffff;height: 40px;font-size: 14px;text-align: center;padding: 0px;font-family: open-sans ,Verdana,sans-serif;margin: 0 35px 20px;border-bottom: 1px solid #999999;border-radius: 0px;-webkit-appearance: none !important;-webkit-border-radius: 0 !important;}td.ncoltxtl2{text-align: left;font-family: open-sans ,Verdana,sans-serif;white-space: nowrap;display: block; font-size: 14px;background-color:#ffffff;}
Die Fußzeile der Zahlungsseite:	td.ncollogoc{text-align: center;font-weight: normal;font-size: 14px;padding: 2px;vertical-align: top !important;}td.ncollogoc IMG{width: 90px;height: 55px;margin-right: 4px;}.ncollogoc td .ncol{width: auto;padding-right: 10px;padding-left: 10px;cursor:pointer;}.ncollogoc input.ncol{margin-top:10px !important;-webkit-appearance: none !important;-webkit-border-radius: 0 !important;}
Die Zahlungsstatusseite, zu der die Kunden nach der Überprüfung der Kreditkartendaten weitergeleitet werden:	td.ncoltxtc{background-color:#ffffff;color:#999999;padding: 0px;text-align: left;font-weight: normal;font-size: 14px;border-top: 0px solid #ffffff;font-family: open-sans ,Verdana,sans-serif;}td.ncoltxtc h3</code{text-align: center;font-weight: normal !important;padding: 5px;font-family: open-sans ,Verdana,sans-serif;}td.ncoltxtmessage{background-color: #ffffff;color: #999999;text-align: left;font-weight: normal;}

Mehrere Vorlagen benutzen

Sie können mehrere Vorlagen in das Back Office hochladen und für Transaktionen einzeln auf sie verweisen.

Standardmäßig wird für jede Transaktion die Vorlage benutzt, die im Back Office unter Configuration > Template > Template selection > eCommerce payment page > aus dem Drop-down-Menü „Default merchant template“ ausgewählt wurde. Sie können diese Einstellung jedoch überschreiben. Senden Sie dazu mit Ihrer Transaktionsanfrage einen zusätzlichen Parameter.

Parameter	Beschreibung/Mögliche Werte
TP	By sending the file name of any of your HTML files uploaded in the Back Office (Configuration > Template > File Manager > Uploaded files), you can select a specific template for the transaction Example: “myTemplate.html”

Dynamische Vorlagen benutzen

Auf unserer Plattform können Sie die Gehostete Zahlungsseite auch so anpassen, indem Sie eine Vorlage auf Ihrem eigenen Server hosten.

Dabei erstellen Sie eine HTML-/CSS-Datei genauso wie im vorigen Kapitel beschrieben. Da Sie die Vorlage jedoch nicht im Back Office hochladen, sondern selbst hosten, gibt es einige Unterschiede:

• Damit das System die Vorlage von Ihrem Server lädt, müssen Sie mit allen Transaktionsanfragen einen zusätzlichen Parameter senden:

Parameter	Description / Possible values
TP	The URL of the dynamic template page The URL must be absolute (contain the full path) and cannot be relative. Do not specify any ports in your URL, we only accept ports 443 and 80. Any component included in the template page must also have an absolute URL.

• Obwohl Sie für alle Bestellungen dieselbe Vorlagenseite benutzen können (oder sie mithilfe des Parameters TP wechseln können), kann die Anwendung sie dynamisch gemäß den Bestellparametern generieren. Benutzen Sie dazu eine feste Vorlagen-URL, die ein aus der Bestellnummer abgeleitetes Ergebnis zurückgibt. Das System fügt die Hauptzahlungsdaten einschließlich der Bestellnummer des Händlers hinzu, wenn es die Vorlagenseite abruft:

HTTP-Anfrage = url_page_template?ORDERID=...&AMOUNT=...&CURRENCY=…

Wenn Sie die Vorlagen selbst hosten möchten, müssen Sie möglicherweise eine höhere PCI-Stufe erfüllen. Detaillierte Informationen erhalten Sie von Ihrem Acquirer. Da das Laden der Vorlage von Ihrem Server länger dauert, dauert der gesamte Zahlungsvorgang länger. Unser System ist mit einer Zeitüberschreitung von fünf Sekunden für die Anfrage zum Abrufen der dynamischen Vorlage konfiguriert. Wenden Sie sich für eine Verlängerung der Zeitüberschreitungsdauer an unser Support-Team. Wenn eines der auf der Seite mit dynamischen Vorlagen benutzten Elemente nicht auf einem sicheren Server gehostet wird, wird die Verbindung zu unserer Plattform von den meisten Browsern als nicht sicher eingestuft. Deshalb empfehlen dringend, alle Dateien auf einem sicheren Server zu hosten.

Die Sicherheitskontrolle für Vorlagen aktivieren

Damit Ihre Kunden vor Betrug geschützt werden, haben wir mehrere Sicherheitskontrollen für die Vorlage eingerichtet.

Melden Sie sich im Back Office an und gehen Sie zu Configuration > Template > Advanced configuration. Sie können diese Einstellungen anpassen:

• Global > Enable JavaScript check on template
  Wenn diese Einstellung aktiviert ist, prüft unsere Plattform, ob auf der Vorlagenseite JavaScript verwendet wird. Wenn JavaScript erkannt wird, blockieren wir die Vorlage und aktivieren stattdessen eine Standardvorlage.
• Dynamic template

Wenn Sie unter „Allow usage of dynamic template“ „Yes“ auswählen, müssen Sie einen oder mehrere vertrauenswürdige Website-Namen konfigurieren, auf denen die dynamische Vorlage gehostet wird. Wenn Sie mehrere eingeben, trennen Sie diese durch einen Strichpunkt („;“). Achten Sie darauf, dass Sie den gesamten URL-Domänenpfad hinzufügen (Unterverzeichnisse, in denen die Vorlage abgelegt ist, können weggelassen werden).
Für jede Transaktion vergleicht unser System den im Parameter TP gesendeten Wert mit den im Back Office konfigurierten Website-Namen. Wenn die Werte nicht übereinstimmen, blockieren wir die dynamische Vorlage und laden stattdessen eine Vorlage, die Sie in das Back Office hochgeladen haben. Wenn Sie keine Vorlage hochgeladen haben, lädt unser System stattdessen eine Standardvorlage. 

5. Kunden nach der Bestellung weiterleiten

Nachdem Ihr Kunde seine Kreditkartendaten eingegeben hat, senden wir die Daten zur Überprüfung an den Acquirer. Sobald wir das Ergebnis erhalten haben, leiten wir Ihren Kunden auf eine von Ihnen gewählte Seite weiter.

Sie können für jedes Szenario eine andere URL definieren. SHASIGN-Wert berechnen

Sie können diese URLs mit diesen zwei Optionen festlegen:

1. Über das Back Office: Gehen Sie zu Configuration > Technical Information > Transaction feedback > eCommerce > HTTP redirection in the browser.  Geben Sie im Feld eine URL für das jeweilige Szenario ein:

Feld	Beschreibung
Accepturl	Erfolgreiche Transaktionen (status 5, 41 or 9)
Declineurl	Abgelehnte Transaktionen (status 2)
Exceptionurl	Abgebrochene Transaktionen (status 1)
Cancelurl	Transaktionen mit unklarem Ergebnis (status 51 or 92)

2. Senden Sie für jede Transaktionsanfrage diese zusätzlichen Parameter:

Parameter	Beschreibung/Mögliche Werte
ACCEPTURL	Erfolgreiche Transaktionen (status 5, 41 or 9)
DECLINEURL	Abgelehnte Transaktionen (status 2)
CANCELURL	Abgebrochene Transaktionen (status 1)
EXCEPTIONURL	Transaktionen mit unklarem Ergebnis (status 51 or 92)

Wenn Sie URLs wie in Option 1 beschrieben festgelegt haben und auch Werte für die Parameter wie in Option 2 beschrieben senden, werden die URLs im Back Office durch die Parameterwerte überschrieben. Wenn eine der URLs nicht mit dem HTTPS-Protokoll, sondern nur mit dem HTTP-Protokoll übereinstimmt, wird Ihrem Kunde möglicherweise eine Warnung vom Browser zum Betreten einer nicht sicheren Umgebung angezeigt. In solchen Fällen können wir Ihren Kunden unmittelbar vor der Weiterleitung eine Benachrichtigung einblenden. Aktivieren Sie diese Möglichkeit im Back Office unter Configuration > Technical Information > Transaction feedback > eCommerce > HTTP redirection in the browser und markieren Sie: „I would like Worldline to display a short text to the customer on the secure payment page if a redirection to my website is detected immediately after the payment process.“

Wenn Sie keine der Optionen wählen, leiten wir Ihre Kunden stattdessen auf eine unserer allgemeinen Ergebnisseiten weiter. Auf den Seiten wird das Ergebnis in der jeweiligen Sprache angezeigt, die Sie mit dem Parameter LANGUAGE gesendet haben ( „Autorisiert“ für Status 5).

Sie können auf unserer Ergebnisseite einen Katalog und/oder eine Startseiten-URL hinzufügen, zu der Sie den Kunden weiterleiten können.  Dazu müssen Sie diese Parameter zusammen mit der Transaktionsanfrage senden

Parameter	Beschreibung/Mögliche Werte
CATALOGURL	URL of your catalogue   If sent, a “Back to our catalouge” button will be visible on our generic result page
HOMEURL	URL of your home page   If sent, a “Back to merchant site” button will be visible on our generic result page   Can also be defined in the Back Office via Configuration > Technical Information > Payment page > Back button redirection, but will be overwritten if you send this parameter If you send the value "NONE", the button is not displayed

6. Get transaction feedback

Damit Sie die Transaktionsergebnisse verfolgen können, gibt es auf der Plattform mehrere Möglichkeiten, um Feedback an Ihren Server zu senden. Sie können mit diesen Informationen zu einem späteren Zeitpunkt auf die Transaktion zugreifen und Wartungsmaßnahmen (also eine Rückerstattung) durchführen.

Feedbackparameter auswählen

Je nach Anforderungen Ihrer Datenbank können Sie genau definieren, welche Art von Informationen Sie erhalten möchten. Da wir das Feedback einzelnen Parametern entsprechend senden, können Sie diese im Back Office wunschgemäß auswählen:

• Gehen Sie zu Configuration > Technical Information > Transaction feedback > eCommerce > Dynamic e-Commerce parameters.
• Verschieben Sie die Parameter, die Sie in der Rückmeldung erhalten möchten, vom Feld „Available“ in das Feld „Selected“. Diese Parameter sind immer im Feedback und können nicht deaktiviert werden:

NCERROR

PAYID

ORDERID

STATUS

SHASIGN-Wert für Feedbackanfragen berechnen

Genauso wie wir Anfragen von Ihrem Server überprüfen, können Sie auch den Ursprung unseres Feedbacks überprüfen.

Damit Sie sicherstellen können, dass das erhaltene Feedback legal ist und nicht von Drittparteien, bieten wir Ihnen an, einen Digest anhand der Parameter im Feedback zu senden. Indem Sie diesen Digest anhand dieser Parameter selbst neu berechnen, können Sie die Legitimität des Feedbacks leicht überprüfen.

Die Berechnung dieses Digests folgt dem gleichen Prinzip wie in diesem Kapitel. Da es dennoch einige Unterschiede gibt, lesen Sie sich diese Zusammenfassung aller Schritte durch:

1. Das Feedback, das Ihr Server erhält, enthält den Parameter SHASIGN mit dem Digest.

Damit Sie den Digest neu berechnen können, verketten Sie alle Parameter/Werte gemäß dieser Formel zu einer Zeichenfolge:

Parameter name + = + Parameterwert + SHA-OUT Passphrase

Achten Sie darauf, dass

• Sie die im Back Office unter Configuration > Technical Information > Transaction feedback > All transaction submission modes > SHA-OUT pass phrase definierte SHA-OUT-Passphrase benutzen;
• Sie alle Parameter (und nur diese) einschließen, die unser System berücksichtigt, und Sie sie wie in dieser separaten SHA-OUT-Parameterliste definiert alphabetisch sortieren.

2. Hashen Sie die verkettete Zeichenfolge gemäß des ausgewählten Hash-Verfahren im Back Office unter Configuration > Technical Information > Global security parameters > Hash algorithm.
   
   
3. Vergleichen Sie Ihren Digest mit unserem. Wenn sie übereinstimmen, ist das die Bestätigung, dass das erhaltene Feedback legitim ist.

Diese Funktion ist optional, da die Serveranfrage ein geschlossener Regelkreis mit zusätzlichen Sicherheitsebenen ist (TLS-/HTTPS-/IP-Filter auf Ihrem Server, siehe Firewall-Dokumentation). Wenn Sie diese Funktion dennoch benutzen möchten, müssen Sie eine SHA-OUT-Passphrase konfigurieren. Andernfalls senden wir das Feedback ohne ein Digest.

Feedback erhalten

Nachdem Sie die Feedbackparameter ausgewählt und einen SHA-OUT definiert haben, können Sie Feedback erhalten. Auf unserer Plattform bieten wir Ihnen dafür zwei Möglichkeiten:

1. Feedback zu Weiterleitungs-URLs erhalten: Sobald Ihre Kunden bei einer dieser URLs landen, senden wir eine entsprechende GET-Anfrage. Damit Sie diese Option benutzen können, aktivieren Sie unter Configuration > Technical Information > Transaction feedback > eCommerce > HTTP redirection in the browser dieses Flag:

Diese Option funktioniert nur, wenn Ihre Kunden den Browser nach der Weiterleitung schließen. Damit Sie nicht vom Verhalten Ihrer Kunden abhängen müssen, bieten wir eine zweite Option wie nachfolgend beschrieben an.

 2. Server-zu-Server-Feedback erhalten: Sie können separate URLs festlegen und einen Zeitpunkt für den Erhalt des Feedbacks wählen. Gehen Sie für diese Option zu Configuration > Technical Information > Transaction feedback > eCommerce > Direct HTTP server-to-server request. Legen Sie Folgendes fest:

Timing of the request Always deferred (not immediately after the payment). Online Online but switch to a deferred request when the online requests fail.	Feedback erhalten 10 Minuten nach der Bestellung Direkt nach der Bestellung Direkt nach der Bestellung oder 10 Minuten nach der Bestellung, falls die erste Feedbackübertragung fehlschlägt
If the payment's status is "accepted", "on hold" or "uncertain".	Feedback zu Transaktionen erhalten, die im Status 5/9 oder 51/91 auf einer gewünschten URL landen
If the payment's status is "cancelled by the client" or "too many rejections by the acquirer".	Feedback zu Transaktionen erhalten, die im Status 1 oder 2 auf einer gewünschten URL landen
Request method	Feedback als GET oder POST erhalten

 

Damit Ihr Server unser Feedback tatsächlich akzeptiert, achten Sie darauf, dass die Firewall ordnungsgemäß eingerichtet ist. Für die Timing-Optionen „Always deferred“ und „Online but switch to a deferred request […]“ versucht unsere Plattform viermal, Ihnen das Feedback zu senden, falls wir das Feedback überhaupt nicht senden können. Aus Sicherheitsgründen empfehlen wir POST statt GET.

Feedback für nachfolgende Statusänderungen erhalten

In einigen Fällen ändert sich der Status Ihrer Transaktionen nach der ersten Bestellung zu einem späteren Zeitpunkt. Damit Sie für diese sog. „offline“-Statusänderungen Feedback erhalten, gehen Sie zu Configuration > Technical Information > Transaction feedback > All transaction submission modes > HTTP request for status change. Legen Sie Folgendes fest:

Timing of the request Only at the time of the order authorisation request For each offline status change (payment, cancellation, etc.).	Feedback erhalten Für Transaktionen mit den Ausgangsstatus 5 oder 51/52 Für Transaktionen mit einem dieser Ausgangsstatus: 5/51/52 91/92 61/62 81/82 91/92
URL on which the merchant wishes to receive a deferred HTTP request, should the status of a transaction change offline.	Feedback zu einer gewünschten URL erhalten

Feedback noch einmal senden

In einigen Fällen wird eine Weiterleitungs-/Feedbackanfrage nicht ordnungsgemäß ausgeführt. Das kann passieren, wenn Ihre Kunden in ihrem Browser auf die Schaltfläche „Zurück“ klicken. Damit Sie Verwirrung auf Kundenseite vermeiden und sicherstellen, dass Sie das Feedback erhalten, gehen Sie zu Configuration > Technical Information > Transaction feedback > General und markieren Sie „I would like Worldline to re-launch the "end of transaction" (post-payment request/redirection) process if required“. Dadurch wird sichergestellt, dass

• Ihre Kunden nach der Bestellung auf der richtigen Weiterleitungs-URL landen;
• Sie Feedback zu Ihren URLs erhalten. 

7. Sicher bezahlen mit 3-D Secure

Ein wichtiger Bestandteil des Transaktionsverarbeitungsablaufs für Ihren Kunden ist 3-D Secure (3DS). Sie müssen nichts weiter tun als sicherzustellen, dass 3DS für alle Ihre Kartenzahlungsmethoden aktiviert ist und wir kümmern uns um alles Notwendige.

Nach der Einführung von 3DSv2 gelten neue Regeln. Obwohl wir während des Zahlungsvorgangs alle relevanten Daten für Sie erfassen, können Sie den 3DSv2-Ansatz zur Risikobewertung dennoch effektiver gestalten. Dafür können Sie beispielsweise zusätzliche Parameter zusammen mit der Transaktion senden.

Werfen Sie einen Blick auf die empfohlenen und optionalen Parameter. Diese müssen in der SHA-Kalkulation miteinbezogen werden.

PSD2 erhöht die Transparenz des Zahlungsprozesses für Sie und Ihre Kunden. Dies ist besonders hilfreich bei Transaktionen mit dem Status 2.
Durch das Feedbackparameter CH_AUTHENTICATION_INFO erhalten Sie genauere Informationen von den Emittenten, wenn diese die Transaktionen Ihrer Kunden ablehnen.
Leiten Sie diese Informationen an Ihre Kunden weiter, damit sie nachvollziehen können, warum ihre Bank die Transaktion abgelehnt hat.

Damit Sie CH_AUTHENTICATION_INFO in Ihren Weiterleitungs-URLs, erhalten können, wählen Sie diesen Parameter im Back Office unter Konfiguration > Technische Informationen > Transaktions-Feedback > Dynamische e-Commerce parameter. Dadurch wird außerdem sichergestellt, dass diese Informationen in der Transaktionsübersicht unter Vorgänge > Transaktionsansicht / Finanzielle Historie sichtbar sind. 
Da Sie die Informationen nicht früh genug erhalten, um Ihre Weiterleitungs-URLs nach Abschluss einer Transaktion entsprechend zu ändern, empfehlen wir, im Back Office "Bei der Umleitung auf eine der URLs soll auf der Bezahlseite ein Hinweis zur Umleitung durch Worldline ausgegeben werden." via Konfiguration > Technische Informationen > Transaktions-Feedback > eCommerce >Standardwerte für die HTTP-Umleitungen nach der Zahlung zu markieren. Unsere Plattform leitet Ihre Kunden dann auf unsere Zwischenergebnisseite mit den Informationen weiter, bevor sie schließlich auf Ihren Weiterleitungs-URLs landen.

7.1 Ausschlüsse von der 3DSv2-Regel

Einige Transaktionen sind von der SCA (starke Kundenauthentifizierung) ausgenommen. Wenn eine Ihrer Transaktionen davon betroffen ist, wird 3-D Secure nicht ausgeführt. Weitere Informationen zur Art der Transaktion finden Sie hier im entsprechenden Leitfaden. 

Sie können anfragen, 3-D Secure auf zwei Arten wegzulassen:

1. Authentifizierung durch Auswahl der entsprechenden Werte für Mpi.threeDSRequestorChallengeIndicator und 3DS_EXEMPTION_INDICATOR
   

   Parameter	Werte
   Mpi.threeDSRequestorChallengeIndicator	Länge: 2 Zeichen Datentyp: String Gültige Werte: 01 = Keine Präferenz 02 = Keine Abfrage angefordert; diesen Wert für Transaktionen mit geringem Betrag verwenden (weniger als 30 Euro) 03 = Abfrage angefordert: Händlerpräferenz 04 = Abfrage angefordert: Mandat; diesen Wert beim Einrichten von wiederkehrenden Transaktionen mit Ihren Kunden oder beim Wiederholen der Transaktion nach einer „weichen Ablehnung“ verwenden 05 = Keine Abfrage angefordert [Transaktionsrisikoanalyse wird bereits durchgeführt]; diesen Wert verwenden, wenn Ihr Akzeptanzpartner TRA-Ausnahmen mit Ihnen vereinbart hat 07 = Keine Abfrage angefordert [SCA wird bereits durchgeführt]; diesen Wert verwenden, wenn Sie den SCA auf Ihrer Seite durchführen; muss vom Akzeptanzpartner genehmigt werden
   3DS_EXEMPTION_INDICATOR	Länge: 2 Zeichen Datentyp: String Gültige Werte: 03 = Herausgeber TRA* 04 = Ausnahme für einen geringen Betrag (weniger als 30 Euro) 05 = Händler/Erwerber TRA* 06 = Auf die weiße Liste setzen 07 = Unternehmen 08 = Verspäteter Versand 09 = Delegierte Authentifizierung (zertifiziertes Wallet) * Analyse des Transaktionsrisikos

   Sehen Sie sich im Back Office Authentifizierungsprotokoll an. Suchen Sie nach „TransStatus = I“, um zu sehen, ob der Kreditkartenherausgeber die Ausnahme gewährt hat. Im Falle einer betrügerischen Transaktion verlieren Sie jedoch die Haftungsumkehr

2. Autorisierung durch Auswahl des entsprechenden Wertes für 3DS_EXEMPTION_INDICATOR und FLAG3D
   
   Senden Sie diese Parameter, um die 3D-Sicherheit insgesamt zu überspringen:
   
   

   Parameter	Werte
   FLAG3D	N = Überspringen des 3DS-Authentifizierungsprozesses
   3DS_EXEMPTION_INDICATOR	Länge: 2 Zeichen Datentyp: String Gültige Werte: 03 = Herausgeber TRA* 04 = Ausnahme für einen geringen Betrag (weniger als 30 Euro) 05 = Händler/Erwerber TRA* 06 = Auf die weiße Liste setzen 07 = Unternehmen 08 = Verspäteter Versand 09 = Delegierte Authentifizierung (zertifiziertes Wallet) * Analyse des Transaktionsrisikos

   
   Es bleibt jedoch dem Kreditkartenherausgeber überlassen, ob ein Authentifizierungsprozess stattfinden muss. Falls der Kreditkartenherausgeber auf 3DS besteht, wird die Transaktion mit dem Fehlercode 40001139.
   Wird eine Transaktion ohne 3-D Secure akzeptiert, verlieren Sie den Haftungsschutz.
   
   
   Wenn Kunden bei Ihnen eine neue  wiederkehrende Zahlung  einrichten, muss die erste Transaktion gemäß den PSD2-Regeln immer stark authentifiziert werden. Senden Sie alle relevanten 3DS-Parameter und COF-Parameter zusammen mit Mpi.threeDSRequestorChallengeIndicator=04

Authentifizierung im Hintergrund / Aktive Authentifizierung

Wenn Sie keine Ausnahme beantragen möchten, sondern sich auf eine Authentifizierung der Kreditkartenherausgeber im Hintergrund verlassen und den Haftungsschutz beibehalten möchten, senden Sie weitere Parameter.
Das Senden dieser Parameter für diese Systeme erhöht die Chance auf eine Authentifizierung im Hintergrund:

• Carte Bancaire (wenn Sie an einem Händlerprogramm mit geringem Risiko teilnehmen, sind diese dringend erforderlich)
  ECOM_BILLTO_POSTAL_CITY
  ECOM_BILLTO_POSTAL_COUNTRYCODE
  ECOM_BILLTO_POSTAL_STREET_LINE1
  ECOM_BILLTO_POSTAL_POSTALCODE
  EMAIL
  OWNERTELNO
  Mpi.shippingIndicator
  REMOTE_ADDR
  
  
• MasterCard
  ECOM_BILLTO_POSTAL_CITY
  ECOM_BILLTO_POSTAL_COUNTRYCODE
  ECOM_BILLTO_POSTAL_STREET_LINE1
  ECOM_BILLTO_POSTAL_POSTALCODE
  EMAIL
  OWNERTELNO
  ADDMATCH
  REMOTE_ADDR

Sie können sogar die Wahrscheinlichkeit eines reibungslosen Flusses und einer höheren Konversionsrate durch das Senden von mehr optionalen Parameter erhöhen.

Soft Decline

Ein typischer Ablauf einer solchen „soft declined“-Transaktion sieht folgendermaßen aus:

1. Bei Ihrer ersten Anfrage senden Sie FLAG3D=N und den Parameter 3DS_EXEMPTION_INDICATOR mit dem geeigneten Wert ohne weiteren Authentifizierungsparameter. Dadurch geben Sie an, dass Sie 3-D Secure überspringen möchten. Die Transaktion könnte jetzt schon akzeptiert werden.
   Wenn sie von der Bank Ihres Kunden abgelehnt wird, weil diese auf 3-D Secure besteht, geben wir dies im Feedback-Parameter an, indem wir NCERROR=40001139 senden. Die Transaktion wird auf Status 2 gesetzt
2. Um diese abgelehnte Transaktion wiederherzustellen, reichen Sie die Transaktion erneut ein, indem Sie die folgenden Parameter an unsere Plattform senden: 
   
   1. Die Parameter der Standardanfrage Gehostete Zahlungsseite / DirectLink, wie sie in Ihrer ersten Anfrage gesendet werden
   2. FLAG3D=Y, um anzuzeigen, dass 3-D Secure eingeführt werden muss
   3. Die 3DSv2-Authentifizierungsparameter wie hier beschrieben
   4. Mpi.threeDSRequestorChallengeIndicator=04, um anzuzeigen, dass die Bank Ihres Kunden nach dem Soft Decline auf 3-D Secure besteht

Ihr Kunde muss bei dieser zweiten Anfrage die 3-D Secure-Authentifizierung durchlaufen. Schließlich erreicht die Transaktion entweder Status 2 oder 9. Dies hängt sowohl davon ab, ob Ihr Kunde die Authentifizierung durchlaufen hat, als auch davon, ob die Zahlung sowohl von Ihrer Bank als auch von der Bank Ihres Kunden akzeptiert wird

Soft Decline ist derzeit für die Zahlungsmethoden Visa, MasterCard, American Express und Carte Bancaire verfügbar.

7.2 Test cards

You can use the following test card to simulate a 3-D Secure registered card in our test environment:

Frictionless Flow
Brand	Card number	Expiry date
VISA	4186455175836497	Any date in the future
Mastercard	5137009801943438	Any date in the future
American Express	375418081197346	Any date in the future
Carte Bancaire	4150557357382737	Any date in the future

Challenge Flow
Brand	Card number	Expiry date
VISA	4874970686672022	Any date in the future
Mastercard	5130257474533310	Any date in the future
American Express	379764422997381	Any date in the future
Carte Bancaire	4150550997933993	Any date in the future

More test cards numbers can be downloaded here.

7.3 Übersicht über Transaktionen mit 3-D Secure

Damit Sie die Transaktionen und deren 3-D Secure-Ergebnisse im Auge behalten können, haben Sie die Möglichkeit, über das Backoffice den 3DS-Bericht abzurufen.

In diesem Video erfahren Sie, wie Sie den Bericht schnell und einfach einrichten können.

8. Zusätzliche Möglichkeiten

Unsere Gehostete Zahlungsseite bietet viele weitere Funktionen. Sie machen diese Lösung noch anpassungsfähiger an Ihre individuellen Bedürfnisse und bieten Ihnen zusätzliche Möglichkeiten, um Ihr Unternehmen weiter auszubauen.

Transaktionen über den Alias Manager verarbeiten

Wie bei allen anderen Lösungen können Sie mit dem Alias Manager Kartendaten mit der Gehostete Zahlungsseite erstellen, speichern und aktualisieren. Lesen Sie das entsprechende Kapitel, um die Customer Journey noch komfortabler und nahtloser zu gestalten.

E-Mails für Bestellungen senden und empfangen

Unser System kann Ihnen und Ihren Kunden Auftragsbestätigungs-E-Mails senden, sobald eine Zahlung abgeschlossen ist. Gehen Sie für diese Option zu Configuration > Technical Information > Transaction e-mails > E-mails to the merchant / E-mails to the customer. Wählen Sie Folgendes aus:

• E-mails to the merchant

E-mail address(es) for transaction-related e-mails	Die E-Mail-Adresse(n), an die die E-Mails gesendet werden sollen
Receive transaction confirmation e-mails Yes, but only for e-Commerce transactions. Yes, for all transaction submission modes.	Ob Sie E-Mails für Transaktionen erhalten, die Sie unter Gehostete Zahlungsseite oder unter einer anderen Lösung verarbeiten
Receive e-mails in the event of offline transaction status changes Yes, but only at the time of the order authorisation request. Yes, for each offline status change (payment, cancellation, etc.).	Ob Sie E-Mails für Transaktionen mit den Ausgangsstatus 5 oder 51/52 erhalten oder für Transaktionen mit einem dieser Ausgangsstatus: 5/51/52 91/92 61/62 81/82 91/92

 

• E-mails to the customer

Support E-mail address to include in transaction-related e-mails	Ob Sie Ihre E-Mail-Adresse in die E-Mail einfügen wollen
Support Phone number to include in transaction-related e-mails	Ob Sie Ihre Telefonnummer in die E-Mail einfügen wollen
I would like Worldline to send a transaction confirmation e-mail to the customer. I would like Worldline to send a transaction confirmation e-mail to the customer at the time of the capture. I would like Worldline to send a transaction confirmation e-mail to the customer at the time of the refund.	Ob Ihre Kunden E-Mails für Transaktionen erhalten, die nach ihrer Bestellung den Status 5 oder 9 erhalten; nach einer Erfassungsanfrage (Status 91) den Status 9 erhalten; nach einer Erstattungsanfrage (Status 81) den Status 8 erhalten.

Zahlungslink per E-Mail senden

Anstatt Ihre Kunden in Echtzeit auf unsere Zahlungsseite weiterzuleiten, können Sie Ihren Kunden die Möglichkeit bieten, ihre Kreditkartendaten jederzeit eingeben zu können.
Bieten Sie diese Möglichkeit an, indem Sie Ihren Kunden eine E-Mail schicken, die eine der beiden folgenden Anforderungen enthält:

• POST: ein HTML-Formular mit versteckten HTML-Feldern, mit dem die erforderlichen Parameter an uns übermittelt werden können
  Dieses HTML-Formular funktioniert genauso wie in unserem Beispiel für Ihre Kaufabwicklungsseite Ihres Online-Shops
  
  
• GET: ein Link bestehend aus dem Endpunkt und den erforderlichen Parametern, die dem genannten Endpunkt hinzugefügt werden:
  https://ogone.test.v-psp.com/ncol/test/orderstandard.asp / orderstandard_utf8.asp?PSPID=TESTSTD&OrderID=order123&amount=12500¤cy=EUR&SHASIGN=8DDF4795640EB9FE9B367315C48E47338129A4F5& …

In beiden Fällen landen Ihre Kunden auf unserer sicheren Zahlungsseite. Dieser Vorgang wird in Schritt 2 in unserer Übersicht über den Zahlungsfluss beschrieben. An diesem Punkt beginnt der Zahlungsfluss
.

Die auf der Gehostete Zahlungsseite verfügbaren Zahlungsmöglichkeiten auswählen

Standardmäßig zeigt unsere Plattform alle Zahlungsmöglichkeiten auf der Gehostete Zahlungsseite an, die unter Back Office (Configuration > Payment methods) aktiviert sind. Durch das Senden eines oder mehrerer dieser Parameter zusammen mit Ihren Transaktionsanfragen wird die Liste der verfügbaren Zahlungsmöglichkeiten im Fenster mit der Auswahl der Zahlungsmöglichkeiten definiert.

Weitere detaillierte Informationen zu jedem Parameter, inklusive einer kurzen Beschreibung, der maximalen Länge und vielem mehr, finden Sie in unserem Parameter Cookbook.

Parameter	Beschreibung/Mögliche Werte
PM	Payment method (ie. Visa) or payment method group (ie. credit cards) To display only one specific payment method on the Gehostete Zahlungsseite, send this parameter together with the according value for BRAND: PM=CreditCard BRAND=VISA If the payment method belongs to a third-party payment method services (ie. Paypal, iDEAL etc.), we will redirect your customer directly to the respective homepage, omitting a redirection to our Gehostete Zahlungsseite To display a payment method group (ie. credit cards), send only this parameter: PM=CreditCard Find a list of all accepted values.
BRAND	Specifies the payment method brand (ie. VISA) from the payment method group (ie. credit cards) as defined by PM Find a list of all accepted values.
PMLIST	Define a list of available payment methods on the Gehostete Zahlungsseite. Combine multiple values of parameter PM (separate them by  a “;” (semicolon)): PMLIST=VISA;iDEAL Find a list of all accepted values for parameter PM.
EXCLPMLIST	Define a list of payment methods that should not be available on Gehostete Zahlungsseite Combine multiple values of parameter PM (separate them by  a “;” (semicolon)) EXCLPMLIST= VISA;iDEAL Find a list of all accepted values for parameter PM.
CREDITDEBIT	Split payment methods Visa and MasterCard as separate credit and debit payment methods. This allows your customers to choose either of them by sending it along PM / BRAND: C: offer payment method as credit card D: offer payment method as debit card PM=CreditCard BRAND=VISA CREDITDEBIT=C

OGM-VCS für ORDERID verwenden

Für die Zahlungsmöglichkeiten KBC/CBC Online, ING Homepay und Belfius DirectNet kann eine strukturierte Kommunikation (Gestructureerde mededeling) gemäß dem  OGM-VCS-Standard in den Acquiring-Auszahlungsberichte erfasst werden.

Diese strukturierte Kommunikation wird im Back Office für einzelne Transaktionen unter Operations > View transactions angezeigt oder ist als Parameter STRUCT über unser elektronisches Reporting-Tool verfügbar.

Dazu müssen Sie den Wert von Parameter ORDERID senden, der nur Ziffern enthalten darf.

Je nach Länge von ORDERID gilt der folgende Inhalt für die strukturierte Kommunikation:

Länger der ORDERID	Ergebnis
>12	PAYID + two check digits (as Modulo 97) will be used for structured communication
12 (einschließlich Prüfsumme Modulo 97)	ORDERID will be used for structured communication. The same applies if this value is sent with parameter COM
11	PAYID + two check digits (as Modulo 97) will be used for structured communication
10 (ohne Prüfsumme Modulo 97)	ORDERID will be used for structured communication + two check digits (as Modulo 97) will be added by our system
Zwischen 1 und 9	ORDERID + leading zeros + two check digits (as Modulo 97) will be used for structured communication. Depending on the length of the ORDERID, the amount of leading zeros will vary to get a length of 12 digits in total

Stimmen Sie sich mit Ihrem Acquirer ab, um die strukturierte Kommunikation auf Ihren Auszahlungsberichten auszudrucken. Beachten Sie, dass dies eine Änderung Ihres Acquirer-Vertrags erfordern könnte.

Der Service ist für diese Zahlungsmöglichkeiten nicht verfügbar, wenn er über Full Service angeboten wird. Wir senden stattdessen die PAYID als strukturierte Kommunikation.

Gehostete Zahlungsseite in iframe darstellen

Mit iframes können Sie die Gehostete Zahlungsseite in Ihre Website integrieren und dabei Ihre eigene URL im Browser beibehalten. Dadurch denken Ihre Kunden, sie sind während des gesamten Zahlungsvorgangs in Ihrer Umgebung.

Aufgrund der Einschränkungen wird diese Funktion jedoch aus verschiedenen Gründen nicht empfohlen:

• Wenn Ihre URL nur mit dem HTTP-Protokoll funktioniert, wird das Schlosssymbol nicht im Browser Ihres Kunden angezeigt. Dies kann dazu führen, dass Ihre Kunden die Sicherheit der Zahlungsseite anzweifeln.
• Zahlungsmöglichkeiten von Drittanbietern, z. B. Paypal, iDEAL usw., funktionieren nicht besonders gut mit iframes. Das führt zu schlechten Layoutergebnissen während des Zahlungsvorgangs.

Statt iframes empfehlen wir die etablierten Möglichkeiten, um das Erscheinungsbild der Gehostete Zahlungsseite anzupassen oder über FlexCheckout zu integrieren.

Wenn Sie dennoch iframes benutzen möchten, stellen Sie sicher, dass

• Sie sie nur auf dem Fenster zur Auswahl der Zahlungsmöglichkeit benutzen;
• nach Möglichkeit Pop-ups für externe Zahlungsmöglichkeiten benutzen, um die Sichtbarkeit von Webanwendungen von Drittanbietern sicherzustellen.

Zusätzliche Daten im Transaktionsfeedback erhalten

Zusätzlich zu den Feedbackparametern, die Sie in Back Office wählen können, können Sie eigene Parameter definieren, die im Feedback enthalten sein sollen. Das sind Passthroughparameter, die Sie in der Transaktionsanfrage senden und im Feedback identisch gesendet werden. Wenden Sie diese Funktion mit diesen Parametern an:

Parameter	Beschreibung/Mögliche Werte
COMPLUS	Pass a value within this parameter you would like to receive in the feedback Sending COMPLUS=1234 would be sent in the feedback like this: https://www.yourwebsite.com/acceptpage.asp?[…standard.parameters…]&COMPLUS=1234 […standard.parameters…]
PARAMPLUS	Pass both parameter names and values you would like to receive in the feedback Sending PARAMPLUS=SessionID=126548354&ShopperID=73541312 would be sent in the feedback like this: https://www.yourwebsite.com/acceptpage.asp?[…standard.parameters…]& SessionID=126548354&ShopperID=73541312

Variable Transaktionsfeedback-URLs benutzen

Wenn Sie mehrere Shops haben, können Sie die Feedback-URL im Back Office für jede Transaktion einzeln anpassen.

Achten Sie dabei auf Folgendes:

• Gehen Sie im Back Office zu Configuration > Technical Information > Transaction feedback > eCommerce > Direct HTTP server-to-server request. Fügen Sie den Platzhalter „<Paramvar>“ für den Teil der URL hinzu, den Sie auf Transaktionsebene ändern möchten.

Beispiel:
https://www.yourwebsite.com/<PARAMVAR>/yourpage.asp

• Senden Sie in der Transaktionsanfrage für den Parameter PARAMVAR den Wert, der für den Platzhalter „<Paramvar>“ eingefügt werden soll.
  
  Beispiel:
  Für PARAMVAR = shop1 wird das Feedback für diese Transaktion an
  https://www.yourwebsite.com/shop1/yourpage.asp gesendet.

Operationscode pro Transaktion definieren

Standardmäßig verarbeitet unsere Plattform jede Transaktionsanfrage als Autorisierung (Status 5) oder Direktverkauf (Status 9). Sie können diesen Default operation code für jede Transaktion einzeln mit dem zusätzlichen Parameter OPERATION überschreiben. Dadurch können Sie von Fall zu Fall entscheiden, ob Sie eine Autorisierung oder einen Direktverkauf anfragen möchten:

Parameter	Beschreibung/Mögliche Werte
OPERATION	Send for each transaction to override the Back Office configuration Accepted values: RES = authorisation (status 5) SAL= direct sale (status 9)

 

Transaktionen Benutzern zuordnen

Wenn mehrere Mitarbeiter mit Ihrem Back Office und Online-Shop arbeiten, möchten Sie möglicherweise Transaktionen registrieren, die einem bestimmten Benutzer zugeordnet sind, wenn also z. B. Angestellte eines Callcenters Transaktionen über die Zahlungslinkfunktion erstellen. Senden Sie dazu diese Parameter:

Parameter	Beschreibung/Mögliche Werte
USERID	The name of the user as defined in your Back Office (Configuration > Users) In the transaction overview (Operations > View transactions / Financial History), the creator of the transaction is named by the formula “UserID/PSPID/User type”. If the USERID does not exist, we will replace it by the default USERID of the account (your PSPID)