1. Home
2. Integrations- lösungen
3. Integrationen
4. Viveum e-Commerce

1. Einleitung

Diese e-Commerce Dokumentation umfasst die Integration von Viveum e-Commerce in Ihre Webseite.

Mit Viveum e-Commerce können Sie:

• die Zahlungsseite unserer abgesicherten und überwachten Plattform Viveum integrieren
• die Zahlungsseite im gleichen Look-and-Feel Ihrer Website anpassen
• auf Zertifikate verzichten und sind sind nicht für sensible Daten verantwortlich

2. Technische Informationen

In Ihrem Viveum Benutzerkonto, finden Sie die Technische Informationsseite über "Konfiguration" in der oberen Menüleiste.

Über Einstellungen sehen Sie ein "i"-Symbol, mit weiteren Informationen zu diesen Einstellungen.

• Die Anfrage-URL in der TESTUMGEBUNG lautet https://viveum.v-psp.com/ncol/test/orderstandard_utf8.asp
• Die Anfrage-URL in der PRODUKTIVUMGEBUNG lautet: https://viveum.v-psp.com/ncol/prod/orderstandard_utf8.asp

Für Transaktionen, die keine finanziellen Auswirkungen haben, nutzen Sie die URL der TESTUMGEBUNG. Die Transaktionen werden zu unserer Test-Umgebung und daher zu Ihrem Test-Konto gesendet werden. Für echte Transaktionen, die finanzielle Auswirkungen haben, nutzen Sie die URL der PRDUKTIVUMGEBUNG. Die Transaktionen werden zu unserer Produktiv-Umgebung und daher zu Ihrem Produktiv-Konto gesendet werden. Vergessen Sie nicht, zur PRODUKTIV-URL zu wechseln, sobald Sie Ihre Tests abgeschlossen haben.

3. Verkaufsprozess

Nachfolgender Screenshot zeigt einen Verkaufsprozess nach der basisch e-Commerce Integration auf Ihrer Webseite.

Dem Kunden wird auf Ihrer Webseite eine Übersicht mit seinen Auftragsdetails angezeigt. Er wird gebeten, diese Informationen zu bestätigen, bevor er mit der Transaktion fortfährt und einen sicheren Zahlungsvorgang initiiert.

Der Bestätigungs-Button ist der sichtbare Teil eines "HTML-Formulars", das verborgene Felder enthält. Die verborgenen Felder beinhalten Zahlungsdetails sowie eine Funktion, die den Kunden automatisch – unter Verwendung eines Sicherheitssystems – auf die Zahlungsseite des Viveum Servers umleitet.

Die verborgenen Felder werden in Link zwischen der Händler-Webseite und Der Viveum Zahlungsseite dieses Dokumentes beschrieben.

Auf der sicheren Viveum Zahlungsseite kann der Kunde eine der von Ihnen aufgesetzten Zahlungsmethoden wählen.

Erfolgt die Zahlung per Kreditkarte, wird der Kunde gebeten, seine Kartennummer etc. einzugeben. Der Kunde kann die Zahlungsanfrage bestätigen oder stornieren.

Nachdem die Zahlungsanfrage an das entsprechende Kreditinstitut gesendet wurde, zeigen wir dem Kunden eine Seite, mit dem Ergebnis seiner Zahlungstransaktion.

Falls die Zahlung abgelehnt wurde, ein Fehler aufgetreten ist oder der Kunde die Möglichkeit hat, die Transaktion erneut durchzuführen: kann er eine andere Zahlungsmethode wählen oder seine Angaben ändern.

Darüber hinaus kann dem Kunden auch eine spezielle Seite auf Ihrer Webseite angezeigt werden - abhängig von dem Transaktionsergebnis. Weitere Informationen dazu finden Sie in Umleitung gemäß Zahlungsergebnis.

4. Verknüpfen Sie Ihre Webseite zur Zahlungsseite

4.1 Wo erfolgt die Konfiguration

Der Link zwischen Ihrer Internetseite und unserer e-Commerce Zahlungsseite muss auf Ihrer Webseite – auf der letzten Seite des Warenkorbs – eingerichtet werden. Es handelt sich um die letzte Seite, die dem Käufer angezeigt wird.

Auf dieser Seite muss ein Formular mit verborgenen HTML-Feldern, welche die Auftragsdaten beinhalten, integriert werden. Der folgende Informationsblock ist auf der letzten Seite Ihres Warenkorbs einzufügen:

<form method="post" action="https://viveum.v-psp.com/ncol/test/orderstandard_utf8.asp" id=form1 name=form1> <!-- allgemeinen Parameter: siehe Formularfelder --> <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=""> <!-- Prüfung vor dem Bezahlvorgang: siehe Sicherheit: Prüfung vor dem Bezahlvorgang --> <input type="hidden" name="SHASIGN" value=""> <!-- Layout-Informationen: siehe Gestaltung und Aussehen der Zahlungsseite --> <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 Umleitung: siehe Rückmeldung an den Kunden --> <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>

4.2 Formularfelder

Zu den Pflichtparametern gehören PSPID, ORDERID, AMOUNT, CURRENCY und LANGUAGE. Darüber hinaus empfehlen wir Ihnen, das Senden des Kundennamens, der E-Mail-Adresse des Kunden, seiner vollständigen Adresse, Land und Telefonnummer. Diese Angaben können ein nützliches Instrument im Kampf gegen Betrug sein.

Nachfolgend ein Überblick über die verborgenen Felder, die zur Übermittlung der “allgemeinen Parameter” an unser System dienen (die anderen Felder werden in den nachfolgenden Kapiteln beschrieben):

Feld	Verwendung
PSPID	Ihr Name in unserem System.
ORDERID	Ihre Auftragsnummer (Händlerreferenz). Das System prüft, ob für denselben Auftrag eine Zahlungsanfrage doppelt erfolgt ist. Die ORDERID muss dynamisch vergeben werden. Der Parameter ORDERID wird verwendet, um zu prüfen, ob Anfragen unbeabsichtigt zweimal an unsere Plattform gesendet wurden Wenn zwei Transaktionen mit demselben Wert für ORDERID innerhalb von 45 Tagen gesendet werden, blockieren wir die zweite Transaktion. Diese Prüfung gilt nur, wenn die PAYIDSUB der ersten Transaktion einen der folgenden Statuse erreicht hat: 2 5 9 Konsequenterweise kann eine ORDERID nur einmal innerhalb von 45 Tagen verwendet werden. Nach diesem Zeitraum können bereits gesendete ORDERIDs erneut verwendet werden.
AMOUNT	Der zu zahlende Betrag MULTIPLIZIERT MIT 100. Das Betragsformat darf keine Dezimalstellen oder andere Trennzeichen aufweisen. Der AMOUNT muss dynamisch vergeben werden.
CURRENCY	Auftragswährung als ISO-Alpha-Code. Zum Beispiel: EUR, USD, GBP, … ISO alpha code, e.g. EUR, USD, GBP, etc.
LANGUAGE	Sprache des Kunden. Zum Beispiel: en_US, nl_NL, fr_FR, …
CN	Name des Kunden. Ist voreingestellt unter Kreditkartendetails im Feld Kundenname (kann jedoch editiert werden).
EMAIL	E-Mail-Adresse des Kunden. Wenn Sie 3DSv2.1 anfragen, sorgen Sie dafür, dass das Format der E-Mail-Adresse korrekt ist. Anderfalls wird der Authentifizierungsprozess über 3DSv1 ausgerollt werden.
OWNERADDRESS	Straße und Hausnummer des Kunden.
OWNERZIP	Postleitzahl des Kunden.
OWNERTOWN	Wohnort / Stadt des Kunden.
OWNERCTY	Land des Kunden.
OWNERTELNO	Telefonnummer des Kunden.

Einhaltung der Markenwahl Ihres Kunden für Co-Badge-Karten In einigen Fällen wird auch eine Kreditkarte eines internationalen Systems, also Visa oder MasterCard, für eine zweite lokale Zahlungsmethode ausgestellt. Solche Kreditkarten werden als Co-Badge-Karten bezeichnet Wenn Sie zusätzlich zu den internationalen Systemen lokale Zahlungsmethoden anbieten, müssen Ihre Kunden zwischen den Marken wählen können, für die eine Co-Badge-Karte ausgestellt wird. Stellen Sie dazu sicher, dass in Ihrem Back Office unter Konfiguration > Zahlungsmethode die lokale Zahlung verfügbar ist. Wenn Sie Visa/MasterCard über einen französischen Käufer anbieten, haben wir Card Bancaire (CB) bereits für Sie hinzugefügt. Unser Kundenbetreuungsteam hilft Ihnen gerne beim Hinzufügen weiterer Zahlungsmethoden. Ihre Kunden können in Ihrem Webshop zwischen den Marken wählen. Geben Sie die Wahl Ihres Kunden mit den Paramete (eine Liste aller verfügbaren Werte für diese Parameter finden Sie im Back Office). Wir werden das Zahlungsformular auf unserer sicheren Zahlungsseite entsprechend anpassen.

4.3 Formularaktion

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

Für die Zahlungsabwicklung im Rahmen des e-Commerce-Systems stehen folgende URLs zur Verfügung:

• Für die Testumgebung: https://viveum.v-psp.com/ncol/test/orderstandard_utf8.asp
• Für die Produktionsumgebung: https://viveum.v-psp.com/ncol/prod/orderstandard_utf8.asp

“test” durch “prod” ersetzen Wenn Sie von der Testumgebung in die Produktionsumgebung wechseln, müssen Sie “test” durch “prod” ersetzen. Sollten Sie diesen Schritt vergessen und mit realen Aufträgen in der Produktionsumgebung beginnen, werden Ihre Transaktionen an die Testumgebung gesendet - jedoch nicht an die Acquirer/Banken.

5. Sicherheit: Vor der Zahlung prüfen

5.1 SHA-IN-Signatur

Diese Technik basiert auf dem Prinzip, dass der Server des Händlers für jede Bestellung eine eindeutige Zeichenfolge erzeugt, aus der mittels SHA-Algorithmus ein Hashcode generiert wird. Dieser Hashcode wird in den verborgenen Feldern der Bestellseite des Händlers an uns gesendet. Unser System rekonstruiert die Signatur, um so die Datenintegrität der Bestellung zu überprüfen, die in den verborgenen Feldern an uns gesendet worden ist. SHA-IN wird vom System automatisch eine GUID zugeordnet. Der SHA-Standardalgorithmus für Ihre PSPID ist SHA-512. Bitte ändern Sie diese Konfiguration, wenn Ihr System den SHA-1- oder SHA-256-Algorithmus benötigt.

Obwohl wir die Hashing-Methoden SHA-1 / SHA-256 / SHA-512 unterstützen, empfehlen wir Ihnen, SHA-256 oder SHA-512 zu nutzen. Damit können wir maximale Sicherheit gewährleisten.

5.1.1 Generierung einer Zeichenkette

Das Erstellen der Zeichenkette erfolgt durch das Verknüpfen des Inhalts der mit dem Auftrag gesendeten Feldinhalte (alphabetisch sortiert, im Format ‚Parameter=Wert‘), gefolgt durch eine Passphrase. Die Passphrase ist in der Technischen Information des Händlers im Register „Data and Origin Verification“, Abschnitt „Checks for eCommerce“ definiert. Eine vollständige Liste der Parameter, die in den SHA Digest einfließen, finden Sie hier. Bitte achten Sie vor der Hash-Codierung beim Verknüpfen der Werte auf Groß- und Kleinschreibung!

Wichtig Alle Parameter, die Sie senden (und die in der Liste der in die SHA-IN-Berechnung einfließenden Parameter), werden in die Zeichenfolge für das Hashing einbezogen. Alle Parameternamen sollten in GROSSSCHREIBUNG stehen (um Verwirrung durch Groß-/Kleinschreibung vorzubeugen). Alle Parameter müssen in alphabetischer Reihenfolge eingegeben werden. Parameter, die nicht mit einem Wert belegt sind, sollten auch NICHT in die Zeichenfolge für das Hashing einbezogen werden. Bitte beachten Sie, dass einige Sortieralgorithmen Umlaute als Erstes im Alphabet darstellen, und andere als Letztes. Im Zweifel halten Sie sich bitte an die Reihenfolge der SHA Liste. Für zusätzliche Sicherheit bitten wir Sie, in Test- und regulärem Betrieb unterschiedliche SHA-Passwörter zu verwenden.

Bei der Hash-Codierung unter Anwendung des SHA-Algorithmus wird ein hexadezimaler Digest zurückgesandt. Die Länge des SHA Digest beträgt bei SHA-1 40 Zeichen, bei SHA-256 64 Zeichen und bei SHA-512 128 Zeichen. Dieses Ergebnis muss im Rahmen der verborgenen Auftragsfelder mit Hilfe des Datenfeldes “SHASIGN” an das Viveum System weitergeleitet werden.

Unser System rekonstruiert die SHA-Zeichenfolge auf Grundlage der empfangenen Parameter und vergleicht den Digest des Händlers mit dem von uns generierten Digest. Ist das Ergebnis nicht identisch, wird der Auftrag abgelehnt. Dieses Prüfverfahren gewährleistet die Richtigkeit und Integrität der Auftragsdaten.

Sie können Ihren SHASign-Wert hier testen.

Beispiel einer grundlegenden-SHA-1-IN-Berechnung Parameter (in alphabetischer Folge): AMOUNT: 15.00 -> 1500 CURRENCY: EUR LANGUAGE: en_US ORDERID: 1234 PSPID: MyPSPID SHA-IN passphrase (in technischer Information): Mysecretsig1875!? Gesamte Zeichenkette für die Hash-Codierung: AMOUNT=1500Mysecretsig1875!?CURRENCY=EURMysecretsig1875!?LANGUAGE=en_USMysecretsig1875!? ORDERID=1234Mysecretsig1875!?PSPID=MyPSPIDMysecretsig1875!? Resultierender Digest (SHA-1): F4CC376CD7A834D997B91598FA747825A238BE0A

Stimmt der SHASIGN-Wert, der in den verborgenen HTML-Feldern mit der Transaktion gesendet wird, nicht mit dem Wert überein, der von uns anhand der Auftragsdetails und der zusätzlichen Zeichenkette (Passwort/Pass-Phrase – s. Bereich „Daten- und Ursprungsüberprüfung“, Abschnitt „Überprüfungen für e-Commerce“, Feld „SHA-IN Signatur“ der Technische Informationen) ermittelt wurde, dann erhalten Sie die Fehlermeldung “unknown order/1/s“.

Enthält das verborgene HTML-Feld “SHASIGN" keine Daten, obwohl im Bereich „Daten- und Ursprungsüberprüfung“, Abschnitt „Überprüfungen für e-Commerce“, Feld „SHA-IN Signatur“ der technischen Informationen eine zusätzliche Zeichenkette (Passwort/Pass-Phrase) eingegeben wurde – die anzeigt, dass Sie mit jeder Transaktion eine SHA-Signatur verwenden möchten – dann erhalten Sie die Fehlermeldung “unknown order/0/s“.

Nachfolgend das verborgene Feld, das zur Übermittlung der SHA-Signatur an unser System verwendet wird:

Feld	Anwendung
SHASIGN	Einmalige Zeichenkette zur Prüfung der Auftragsdaten. Die Zeichenkette, die unter Verwendung des SHA-1-Algorithmus verschlüsselt wird, ist immer 40-stellig.

6. Look & Feel der Zahlungsseite

Erscheinungsbild: Bauen Sie die Zahlungsseite so auf, dass sie zu Ihrer Marke passt und dem Bedarf Ihrer Kunden zum Zeitpunkt vor der Zahlung entspricht, um ein stimmiges Einkaufserlebnis zu bieten und damit Ihre Konversionsrate zu erhöhen.

Auf der gehosteten Zahlungsseite gibt es zwei Arten von Information:

• Statische Informationen (z.B. Ihr Logo)
• Detaillierte Zahlungsinformationen (z.B. Bestellnummer, Felder, in die der Kunde seine Kartendaten eingibt, usw.)

Die statischen Informationen stammen aus dem gängigen Layout unseres Systems oder der Seitenvorlage eines bestimmten Händlers. Unser System fügt die Zahlungsdaten für jede Transaktion dynamisch hinzu. Sie können Ihre Zahlungsseite anpassen, bis hin zur Anwendung von benutzerdefiniertem HTML und CSS auf Ihre Inhalte. Sie brauchen uns lediglich zu sagen, wo die „PAYMENT ZONE“ eingefügt werden soll, die die Zahlung auf Ihrer Seite übernimmt.

SICHERES HOSTING: Viveum bietet Ihnen sicheres Hosting für den Template Ihrer Zahlungsseite, sodass Sie PCI-konform bleiben können.

Hinweis: Den folgenden Abschnitt über die Anpassung des Demo-Template können Sie überspringen, wenn Sie nicht vorhaben, Ihre Zahlungsseite anzupassen.

6.1 Responsive Payment Page von Viveum

Unsere vollständige Responsive Payment Page-Vorlage ist die perfekte und einfachste Lösung für ein Online-Einkaufserlebnis mit mehreren Bildschirmen für Ihre Kunden. Es gewährleistet Ihnen eine optimierte Konvertierung sowohl auf Desktop- als auch auf mobilen Geräten.

• Um die Viveum Responsive Payment Page-Vorlage im Viveum Back Office zu aktivieren, gehen Sie zu Konfiguration> Vorlage> Vorlagenauswahl und klicken Sie auf „Die Responsive Payment Page aktivieren“.
• Um die Vorlage mit Ihrem Logo zu personalisieren, gehen Sie zu Konfiguration> Vorlage> Dateimanager und laden Sie Ihr Logo namens „logo.png“ hoch.

6.2 Passen Sie Ihre eigene angepasste Vorlage an und laden Sie sie hoch

Laden Sie zunächst die Quellenvorlage für die Responsive Payment Page von Viveum herunter, um sie an Ihre spezifischen Markenbedürfnisse anzupassen. Sie können Ihre eigene Vorlagenseite vollständig selbst gestalten, sodass nur ein Bereich auf dieser Seite von unserem System ausgefüllt wird. Sie können Ihre Vorlagenseite und Dateien auch in unserer sicheren Umgebung hosten, die wir als „statische Vorlage“ bezeichnen.

Laden Sie unsere Demo-Vorlage für e-Commerce-Zahlungsseiten herunter

Probieren Sie unsere Demo-Vorlagen für Desktop- und mobile Browser aus. Sie können sie als solche verwenden oder sie auf Ihre Zwecke hin anpassen.

Passen Sie einfach den anderen Wert mit den CSS-Dateien an, um die von Ihnen gewünschte Seite zu erhalten.

Neben der Anpassung der bereitgestellten CSS-Dateien können Sie den HTML-Code auch durch Hinzufügen eigener Kopf- und Fußzeileninformationen vervollständigen. Weitere Informationen finden Sie in Kapitel 5.2.2. Wenden Sie aus Sicherheitsgründen keine unautorisierten externen Daten/Dateien an. Alle Dateien und Daten müssen in den Dateimanager hochgeladen werden, damit sie verwendet werden können. Sobald vervollständigt, Befolgen Sie diese Schritte, um die Vorlagen kostenlos herunterzuladen und anzuwenden:

1. Download der zip-Datei
2. Gehen Sie dazu vom Back Office auf Konfiguration > Vorlage > Erweiterte Konfiguration > Nutzung der dynamischer Vorlage erlauben > Ja zur Aktivierung der dynamischer Vorlagen.
3. Gehen Sie zum Menüpunkt Konfiguration > Vorlage > Dateimanager, um die in der zip-Datei (kein Ordner) enthaltenen Dateien hochzuladen.
4. Gehen Sie auf Konfiguration > Vorlage > Vorlagen-Auswahl, um Ihre bevorzugte „Standard-Händler-Vorlage“ für e-Commerce auszuwählen.

WICHTIG:

• Für unser Responsive Payment Page Vorlage müssen Sie die Zahlungsmethoden in vertikal anordnen. Dies erreichen Sie, indem Sie den Parameter PMLISTTYPE=2 mit jeder Transaktion zusätzlich mitsenden.
• Wenn Sie Ihre e-Commerce-Seite nicht anpassen möchten, können Sie hier unterbrechen. Mehr Informationen, wie Sie Ihre e-Commerce-Seite mit unseren Demo-Vorlagen personalisieren können, finden Sie im nächsten Abschnitt.
• Die Plattform unterstützt mehrere Vorlagen. Sie können die Standardvorlage für beliebige Transaktionen verwerfen und mithilfe des “TP”-Parameters in Ihrer POST-Anforderung eine spezielle Vorlage aussuchen (TP=<vollständiger Name der HTML-Datei einschließlich Erweiterung>).
• Wir empfehlen, dass Sie die Größe Ihrer Logos für Breite und Höhe auf 300 Pixel begrenzen. Dadurch wird sichergestellt, dass die Ladezeit auf Smartphones auf ein Minimum beschränkt wird.

Umfangreiche Anpassung: Gestalten Sie Ihre eigene Zahlungsseite

Neben der Personalisierung der vorhandenen css-Dateien können Sie auch das HTML mit Ihrer eigenen Header- und Footer-Informationen ausfüllen. Mehr Informationen dazu finden Sie in Kapitel 5.2.2 Aus Sicherheitsgründen verwenden Sie bitte keine unautorisierten externen Daten/Dateien; alle Dateien und Daten müssen zur Nutzung auf den Dateimanager hochgeladen werden.

6.2.1 Verborgene Felder

Das folgende verborgene Feld dient zur Übermittlung der URL Ihrer Vorlagenseite:

<input type="hidden" name="TP" value="">

Feld	Nutzung
TP	Dateiname der Vorlage, die von Viveum gehostet wird.

6.2.2 Zahlungszone (Payment zone)

Die dynamische Vorlagenseite können Sie ganz nach Ihrem Geschmack gestalten. Die einzige Anforderung besteht darin, dass sie die Zeichenfolge "$$$PAYMENT ZONE$$$"enthält. Sie zeigt an, an welcher Stelle unser e-Commerce Modul seine Felder dynamisch einfügen kann. Der Mindesteintrag muss also lauten:

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

Wichtig Verwenden Sie keine BASE Tags, Frames oder FORM Tags, um die Zeichenfolge $$$PAYMENT ZONE$$$ zu verkapseln.

6.3 Dynamische Vorlage

Mit der dynamischen Vorlagenseite können Sie das Design der Zahlungsseiten umfänglicher individuell anpassen als mit der statischen Vorlage.

Wenn Sie eine dynamische Vorlagenseite verwenden, gestalten Sie Ihre eigene Vorlagenseite komplett und lassen nur einen Bereich dieser Seite durch unser System ausfüllen. Für jede Transaktion muss die URL Ihrer Vorlagenseite in den verborgenen Feldern an uns geschickt werden.

Denken Sie bitte daran, dass die Verwendung einer dynamischen Vorlagenseite die zusätzliche Anforderung an unser System beinhaltet, Ihre Vorlagenseite zu suchen. Das erhöht die Zeit, die für den Bezahlvorgang benötigt wird.

Wichtig Um dem aktuellsten PCI-DSS zu entsprechen, müssen Sie Ihre Vorlage (und die zugehörigen Dateien) in einer Umgebung hosten, die über die höchste PCI-Zertifizierung verfügt.

6.3.1 Verborgene Felder

Das folgende verborgene Feld dient zur Übermittlung der URL Ihrer Vorlagenseite:

<input type="hidden" name="TP" value="">

Feld	Nutzung
TP	URL der dynamischen Vorlagenseite des Händlers (die Seite muss vom Händler gehostet werden). Die URL muss absolut angegeben werden (also mit dem vollständigen Zugriffspfad). Geben Sie in der URL keine Ports an, denn wir akzeptieren nur die Ports 443 und 80. Jede in der Vorlagenseite enthaltene Komponente muss ebenfalls über eine absolute URL verfügen.

6.3.2 Zahlungszone (Payment zone)

Die dynamische Vorlagenseite können Sie ganz nach Ihrem Geschmack gestalten. Die einzige Anforderung besteht darin, dass sie die Zeichenfolge "$$$PAYMENT ZONE$$$"enthält. Sie zeigt an, an welcher Stelle unser e-Commerce Modul seine Felder dynamisch einfügen kann. Der Mindesteintrag muss also lauten:

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

Wichtig Verwenden Sie keine BASE Tags, Frames oder FORM Tags, um die Zeichenfolge $$$PAYMENT ZONE$$$ zu verkapseln.

6.3.3 Dynamisches Verhalten

Für alle Bestellungen kann die gleiche Vorlagenseite verwendet werden. Alternativ lässt sie sich gemäß den Parametern der Bestellung auch dynamisch von der Applikation des Händlers erzeugen.

Um die Vorlagenseite dynamisch zu erzeugen, kann der Händler wahlweise eine für die Bestellung spezifische Seite erstellen, deren URL in den verborgenen Feldern übertragen wird, oder eine feste URL benutzen, dabei aber ein von der Bestellnummer abgeleitetes Ergebnis übergeben. Um dies zu ermöglichen, fügt unser System die wichtigen Zahlungsdaten einschließlich Bestellnummer des Händlers (siehe Verarbeitung nach erfolgter Zahlung) hinzu, wenn es die Vorlagenseite abruft:

HTTP request = url_page_template ?orderID=...&amount=...¤cy=…

6.3.4 Formatvorlagen

Sie können das Look & Feel Ihrer Zahlungsseite personalisieren, indem Sie der Vorlagenseite Formatvorlagen hinzufügen.

Wir haben eine Klasse für die verschiedenen Typen von Tabellen und Zellen innerhalb unserer Tabellen sowie eine Klasse für die Schaltflächen zum Absenden definiert. Fügen Sie den folgenden Codeblock zwischen die Tags <head></head> ein und ändern Sie die Eigenschaften dieser Klassen gemäß dem Look & Feel Ihrer Webseite (siehe auch das Beispiel auf der oben genannten Vorlagenseite):

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

Bei der Eingabe eigener Layoutanweisungen müssen Sie der Syntax kaskadierender Formatvorlagen folgen. Wir empfehlen dringend, das Layout in verschiedenen Browsern zu testen, da die Browser Styles auf sehr unterschiedliche Weise handhaben.

6.3.5 Leistungsverhalten

Unser System ist mit einer Zeitüberschreitungsgrenze von 5 Sekunden für die Anfrage zum Abruf der dynamischen Vorlagenseite beim Händler konfiguriert.

Verstreicht diese Zeit, verwendet unser System stattdessen die statische Vorlage des Händlers.

Ist keine statische Vorlage konfiguriert, verwendet unser System als letzte Möglichkeit die statische Vorlage Viveum.

Dieses HTTPTimeOut Feld wirkt sich sowohl auf Anfragen dynamischer Vorlagen als auch auf Post-Sale-Anfragen aus (siehe Direktes Feedback über HTTP-Server-zu-Server-Anfrage). Daraus folgt, dass wenn der Händler diesen Wert beispielsweise auf 15 Sekunden ändern lässt, sich auch der Timeout-Wert für Post-Sale-Anfragen auf 15 Sekunden verlängert.

Für jede Bestellung führt unser System eine Anfrage durch, um Ihre dynamische Vorlagenseite abzurufen. Wenn Sie ein hohes Transaktionsaufkommen oder eine umfangreiche Vorlagenseite haben (z. B. wenn Ihre dynamische Vorlagenseite eine große Zahl von Bildern enthält), können diese HTTP-Anfragen viel Zeit in Anspruch nehmen. Wenden Sie sich wegen einer Lösung für hohe Transaktionsvolumen bitte an unser Vertriebsteam.

6.4 Mobilgeräte-Vorlage

Sie können die Anzeige der Zahlungsseite auf Mobilgeräten (Smartphones, Tablets usw.) optimieren, indem Sie eine Vorlagenseite anwenden, die mit Formatvorlagen angereichert ist (s. die nachfolgenden Kapitel).

6.5 Vorlagen-Dateimanager

Mit dem Vorlagen-Dateimanager können Sie Ihre Vorlagen und die unterschiedlichen damit in Zusammenhang stehenden Dateien einfach verwalten.

Um den Dateimanager zu verwenden, melden Sie sich bei Ihrem Viveum-Konto an und gehen Sie zu „Konfiguration“ > „Vorlage“ > „Dateimanager“.

Wichtig Es ist nicht möglich, in Ihrer Integration Dateien, die zuvor von Viveum hochgeladen wurden, und Dateien, die mit dem Dateimanager hochgeladen wurden, zu verwenden. Wenn Sie Dateien haben, die in der Vergangenheit von Viveum hochgeladen wurden, vergewissern Sie sich bitte, dass diese Dateien erneut von Ihnen über den Dateimanager hochgeladen werden.

6.5.1 Vorlagendateien hochladen

Unter „Vorlagendateien hochladen“ wählen Sie die Schaltfläche „Dateien...“ aus, um nach den Dateien zu suchen, die Sie hochladen möchten. Sie können JavaScripts sowie HTML-, CSS- und Bilddateien (.css, .jpg, .jpeg, .gif, .png, .html, .js) mit einer Größe von höchstens 7 MB pro Datei bzw. 10 MB insgesamt hochladen.

Treffen Sie Ihre Auswahl, und bestätigen Sie diese anschließend.

6.5.2 Hochgeladene Dateien prüfen und verwalten

Sobald der Upload abgeschlossen ist, sehen Sie Ihre hochgeladenen Dateien auf der gleichen Seite im Abschnitt „Hochgeladene Dateien“.

Die Dateien werden zunächst den Status „Wird geprüft“ aufweisen, in dem die erforderlichen Sicherheits-/Virenprüfungen durchgeführt werden.

Sie können die Dateien verwenden, sobald sich deren Status zu „Bestätigt“ geändert hat.

Klicken Sie auf die Schaltfläche „Aktualisieren“ , um den aktuellen Status der Dateien zu prüfen bzw. auf die Schaltfläche „Löschen“ , um die Datei dauerhaft zu löschen.

Eine Datei wechselt in den Status „Abgelehnt“, wenn sie die Sicherheitsprüfung nicht bestanden hat. Das kann beispielsweise auf einen Virus oder eine falsche Dateierweiterung zurückzuführen sein.

6.5.3 Default merchant template

6.5.4 Integration

Weisen Sie Ihren hochgeladenen Dateien in Ihren Vorlagen einen Code in diesem Format zu: $$$TP RESOURCES URL$$$/[Name Ihrer Datei].

Wenn Sie jedoch eine Ressource in einer CSS-Datei nutzen möchten, sollten Sie den folgenden Code referenzieren: "./[Name Ihrer Datei]

Beispiel:

Um Ihre hochgeladene Vorlage in Ihrer e-Commerce-Integration zuzuweisen, senden Sie den Namen der Vorlagendatei mit dem Parameter „TP“.

Beispiel: TP=mytemplatefile.html

Wenn Sie über eine grundlegende e-Commerce-Integration mit einem Logo im oberen Bereich der Seite verfügen, müssen Sie das hochgeladene Logo zuweisen, indem Sie den Dateinamen sowie den Parameter „LOGO“ senden.

Beispiel: LOGO=mycompanylogo.png

6.6 Vorlage Sicherheitskontrolle

Um die Kunden des Händlers vor betrügerischen Aktivitäten zu schützen, beispielsweise vor der Manipulation sensibler Kartendaten (Kartennummer, CVC), sind verschiedene Sicherheitsprüfungen für die Händler-Vorlage bereitgestellt worden.

Auf der Seite Technische Informationen des Händlers, Register "Globale Sicherheitsparameter", Bereich "Template", können folgende Einstellungen konfiguriert werden:

• Enable Javascript check on template (Prüfung auf Javascript im Template aktivieren)
  Diese Funktion können Sie aktivieren, um die Verwendung von Javascript auf der Template-Seite zu erkennen. Wenn Javascript erkannt wird, wird der Template gesperrt und stattdessen der Standard-Template verwendet.

• Allow usage of dynamic template (Nutzung dynamischer Vorlage erlauben)
  Der Händler kann auswählen, welche Vorlagentypen zur Initiierung einer Transaktion auf unserer Plattform zulässig sind: Es können sowohl statische als auch dynamische Vorlagen konfiguriert werden.
  
  
  • Wenn der Händler die Option Nutzung statischer Vorlage erlauben aktiviert hat, muss der Name der vertrauenswürdigen statischen Vorlage angegeben werden. Diese Liste wird dann zum Abgleich der Informationen genutzt, die während des Zahlungsprozesses von Viveum empfangen werden. Es können hier einer oder mehrere, durch Semikolon getrennte Werte eingegeben werden.

• Wenn der Händler die Option Nutzung dynamischer Vorlage erlauben aktiviert hat, muss der Hostname der vertrauenswürdigen Website angegeben werden, die als Host dieser dynamischen Vorlage dient. Dieses Feld kann mehrere Web-Hosts, getrennt durch Semikolon, enthalten. Es sollte aber immer die komplette URL angegeben werden, z. B. http://www.website.com/. Die Unterverzeichnisse können wegfallen. Wenn die URL der dynamischen Vorlage http://www.website.com/templates/nl/template1.htm lautet, reicht als Angabe für den vertrauenswürdigen Web-Host http://www.website.com aus.
  
  Zusätzlich kann der Händler wahlweise eine oder mehrere URLs absolut vertrauenswürdiger dynamischer Vorlagen, getrennt durch Semikolon, konfigurieren.

Wird mit einer Transaktion eine dynamische Vorlage übermittelt, aber dynamische Vorlagen sind nicht erlaubt, wird die Vorlage gesperrt und unser System verwendet stattdessen die statische Vorlage. Wenn keine statische Vorlage konfiguriert ist oder, wird die Standardvorlage Viveum verwendet. In der Voreinstellung sind bei Händlern die Optionen JavaScript-Prüfung der Vorlage.

6.7 Schloss-Symbol für sichere Umgebungen

Die für die Verbindung des Kunden mit unserer Plattform verwendete URL nutzt ein sicheres Protokoll (HTTPS). Sämtliche Kommunikation zwischen unserer e-Commerce-Plattform und dem Kunden ist sicher verschlüsselt.

Das kleine Vorhängeschloss, das im Browser zur Anzeige einer sicheren Webseite verwendet wird, erscheint jedoch unter Umständen nicht, wenn einige Elemente (z. B. Bilder) in der Vorlagenseite nicht auf einem sicheren Server hinterlegt sind oder wenn einige Frames der angezeigten Webseite nicht von sicheren Webseiten stammen.

Auch wenn die Kommunikation für die Zahlungsverarbeitung verschlüsselt ist, erkennen die meisten Browser eine sichere Verbindung nur dann, wenn alle Elemente auf dem Bildschirm einschließlich Bildern, Tönen usw. von sicheren Webseiten kommen.

Händler, die nicht über eine sichere Webseite verfügen, sollten folgende Regeln beachten:

1. Verwenden Sie für Zahlungsseiten keine Frames. Sie können die gesamte Bildschirmanzeige mit einer Vorlagenseite aktualisieren, die so aussieht, als würden Sie Frames verwenden, oder die Verarbeitung der Zahlung in einem neuen Browser-Fenster erlauben.
2. Verknüpfen Sie keine Dateien mit der Vorlagenseite (<link> Tag), die Sie für die Zahlungsseite benutzen. Verwenden Sie stattdessen die Tags <style> und <script>, um Formatvorlagen und Skripts in die Vorlagenseite einzubinden.
3. Sorgen Sie dafür, dass die Bilder in Ihrer Vorlagenseite auf einem sicheren Server gespeichert sind (die Vorlagenseite selbst kann auf einem nicht sicheren Server hinterlegt sein, die Bilder müssen es jedoch sein). Wir können das Hosting für diese Elemente übernehmen (siehe Optionen für Bilderhosting in Ihrem Konto).

6.8 Zahlungsseite in einem iFrame

iFrames werden immer beliebter. Sie erlauben dem Händler, eine externe Webseite (beispielsweise die Zahlungsseite) in seine Website zu integrieren und dabei seine eigene URL im Browser zu erhalten.

iFrames weisen jedoch im aktuellen Kontext auch wesentliche Nachteile auf:

• Da es sich bei der URL um die des Händlers handelt, könnte es eine einfache http (nicht https) sein und damit würde das Vorhängeschloss-Symbol nicht im Browser erscheinen. Dies könnte bei potenziellen Kunden Zweifel an der Sicherheit des Webshops wecken.
• Einige Zahlungsmethoden (wie Giropay, Sofortüberweisung, iDEAL, Bancontact/Mister Cash, PayPal...) verwenden Weiterleitungen, die zu einem unbefriedigenden Erscheinungsbild bzw. Problemen bei der Navigation führen können.

Aus diesen Gründen werden iFrames von Viveum nicht empfohlen und ihre Verwendung erfolgt auf alleinige Verantwortung des Händlers. Viveum rät stattdessen dringend zur Verwendung einer dynamischen Vorlage.

Falls Sie die Integration von iFrames planen, möchten wir Ihnen folgende Empfehlungen geben:

• Verwenden Sie iFrames ausschließlich auf der Seite für die Auswahl der Zahlungsmethode (und den nachfolgenden Seiten).
• Verwenden Sie wo immer möglich Pop-ups für externe Zahlungsmethoden, um die korrekte Darstellung der Web-Applikationen Dritter sicherzustellen.

7. Transaction feedback

Die Rückmeldung an den Händler und dessen Kunden, nachdem die Zahlung akzeptiert wurde, der Kunde den Zahlungsvorgang abgebrochen hat oder der Akzeptanzpartner die Zahlung häufiger als die maximale Anzahl von Zahlungsversuchen verweigert hat, ist von den vom Händler definierten Parametern abhängig.

Best practice Umleitung mit Parametern an accept-/exception-/cancel-/declineurl (siehe Option für Datenbankaktualisierung) mit zeitlich versetzter Post-Sale-Anfrage als Absicherung (siehe Direktes Feedback über HTTP-Server-zu-Server-Anfrage). In Ihrem Viveum Konto, gehen Sie auf "Konfiguration" > "Technischen Informationen" > "Transaktions-Feedback". Konfigurieren Sie die Einstellungen wie unten beschrieben: HTTP redirection in the browser ("Ich wünsche die Transaktionsfeedbackparameter auf die zur Umleitung angegebenen URLs zu erhalten.") Direktes Feedback über HTTP-Server-zu-Server-Anfrage : Always deferred ("Immer zeitversetzt (deferred, nicht unmittelbar nach der Zahlung).")

7.1 Standard-Rückmeldung

Wenn der Händler keine spezifische Rückmeldung vorgegeben hat, zeigt unser System dem Kunden die Standardmeldung an: "Ihre Bestellung wurde akzeptiert" oder "Die Transaktion wurde abgebrochen. Bezahlungwurde verweigert". Diese Meldung wird in die Vorlagenseite eingefügt.

In diese Seite fügen wir außerdem eine Verknüpfung zur Webseite bzw. zum Katalog des Händlers ein. Hierbei finden die URLs (homeurl und catalogurl) Verwendung, die in den verborgenen Feldern des Bestellformulars übermittelt wurden. Sind diese URLs nicht in den verborgenen Feldern definiert, verwendet unser System die im Management-Modul Ihres Kontos angegebene URL (Konto > Schritt 1).

<input type="hidden" name="CATALOGURL" value="">
<input type="hidden" name="HOMEURL" value="">

Feld	Nutzung
CATALOGURL	(Absolute) URL Ihres Katalogs. Wenn die Transaktion verarbeitet wurde, wird Ihr Kunde aufgefordert, durch Anklicken einer Schaltfläche zu dieser URL zurückzukehren.
HOMEURL	(Absolute) URL Ihrer Homepage. Wenn die Transaktion verarbeitet wurde, wird Ihr Kunde aufgefordert, durch Anklicken einer Schaltfläche zu dieser URL zurückzukehren. Wenn Sie den Wert „NONE“ senden, wird die Schaltfläche, die zur Händler-Webseite zurückführt, ausgeblendet.

7.2 Umleitung gemäß Zahlungsergebnis

In den verborgenen Feldern seines Bestellformulars kann der Händler vier URLs (ACCEPTURL, EXCEPTIONURL, CANCELURL und DECLINEURL) übermitteln, an die unser System den Kunden je nach Ergebnis des Zahlungsvorgangs weiterleitet.

Der Händler kann diese URLs auch im Bereich „Transaktionsfeedback“, Abschnitt „Standardwerte für die HTTP-Umleitungen nach der Zahlung“ auf der Seite „Technische Informationen“ konfigurieren.

Die folgenden verborgenen Felder dienen zur Übermittlung der URLs:

<input type="hidden" name="ACCEPTURL" value="">
<input type="hidden" name="DECLINEURL" value="">
<input type="hidden" name="EXCEPTIONURL" value="">
<input type="hidden" name="CANCELURL" value="">

Feld	Nutzung
ACCEPTURL	URL der Webseite, die dem Kunden angezeigt werden soll, wenn die Zahlung autorisiert (Status 5), gespeichert (Status 4) oder akzeptiert (Status 9) wurde oder auf die Annahme wartet (abwartend, Status 41, 51 oder 91).
DECLINEURL	URL der Webseite, die dem Kunden angezeigt werden soll, wenn der Akzeptanzpartner die Autorisierung häufiger als maximal zulässig verweigert hat (Status 2 oder 93).
EXCEPTIONURL	URL der Webseite, die dem Kunden angezeigt werden soll, wenn das Ergebnis des Zahlungsvorgangs unsicher ist (Status 52 und 92). Wenn dieses Feld leer ist, bekommt der Kunde stattdessen die accepturl angezeigt.
CANCELURL	URL der Webseite, die dem Kunden angezeigt werden soll, wenn er den Zahlungsvorgang abbricht (Status 1). Wenn dieses Feld leer ist, bekommt der Kunde stattdessen die declineurl angezeigt.

Mitteilung zu Browser-Warnung Wenn ein Kunde von einer unserer sicheren Zahlungsseiten zur Webseite des Händlers zurückkehrt, erhält er möglicherweise eine Warnung seines Browsers, dass er in eine nicht sichere Umgebung gelangt (wegen des Wechsels von einer https:// Umgebung in eine http:// Umgebung) Wenn wir eine Umleitung zur Webseite des Händlers feststellen, können wir eine Meldung an den Kunden erscheinen lassen, die ihn über die Möglichkeit einer solchen Sicherheitswarnung informiert (siehe erster Screenshot in Umleitung gemäß Zahlungsergebnis). Dies vermeidet unnötige Beunruhigung des Kunden bezüglich einer solchen Warnung. Der Händler kann diese Option “Bei der Umleitung auf eine der URLs soll auf der Bezahlseite ein Hinweis zur Umleitung durch Viveum ausgegeben werden” aktivieren im Bereich "Transaktionsfeedback", Abschnitt "Standardwerte für die HTTP-Umleitungen nach der Zahlung" auf der Seite “Technische Informationen”.

7.3 Umleitung mit Datenbankaktualisierung

Der Händler kann diese Umleitung zur ACCEPT-/EXCEPTION-/CANCEL-/DECLINEURL dazu nutzen, automatisierte Back-Office-Aufgaben wie Datenbankaktualisierungen anzustoßen. Wenn eine Zahlung ausgeführt wird, können wir die Transaktionsparameter an die accept-/exception-/cancel-/declineurl des Händlers senden.

Der Händler kann diese Option aktivieren im Bereich "Transaktionsfeedback", Abschnitt "Standardwerte für die HTTP-Umleitungen nach der Zahlung" auf der Seite “Technische Informationen”:

• “Ich wünsche die Transaktionsfeedbackparameter auf die zur Umleitung angegebenen URLs zu erhalten”.

7.3.1 SHA-OUT

Der Umleitungsvorgang ist sichtbar, denn er erfolgt über den Browser des Kunden. Folglich muss der Händler eine SHA-OUT-Signatur nutzen, um den Inhalt der Anfrage zu verifizieren und zu verhindern, dass Kunden die Daten im URL-Feld manipulieren, was zu betrügerischen Datenbankaktualisierungen führen kann.

Wenn der Händler keine SHA-OUT-Signatur konfiguriert, senden wir keinerlei Parameter an seine ACCEPT-/EXCECPTION-/CANCELURL-/DECLINEURL.

Das Erstellen der Zeichenkette erfolgt durch das Verknüpfen des Inhalts der mit dem Auftrag gesendeten Feldinhalte (alphabetisch sortiert, im Format ‚PARAMETER=Wert‘), getrennt durch eine Passphrase. Die Passphrase ist in der Technischen Information des Händlers im Register „Transaction Feedback“, Abschnitt „All transaction Submission modes“ definiert.

Eine vollständige Liste der Parameter, die in den SHA Digest einfließen, finden Sie hier. Bitte achten Sie bei diesen Werten auf die Groß- und Kleinschreibung!

Wichtig Alle Parameter, die Sie senden (und die in der Liste im Liste der in die SHA-Berechnung einfließenden Parameter erscheinen), werden in die Zeichenfolge für das Hashing einbezogen. Alle Parameter müssen in alphabetischer Reihenfolge eingegeben werden. Parameter, die nicht mit einem Wert belegt sind, sollten auch NICHT in die Zeichenfolge für das Hashing einbezogen werden. Auch wenn manche Parameter (teilweise) in Kleinbuchstaben von unserem System geliefert werden, müssen Sie diese für die SHA-OUT-Berechnung in Großbuchstaben setzen Wenn Sie Ihr Testkonto mit Hilfe des Links im Back-Office in ein Produktivkonto überführen, wird automatisch eine zufällig erzeugte SHA-OUT-Signatur in Ihrem Produktivkonto konfiguriert. Für zusätzliche Sicherheit bitten wir Sie, in Test- und regulärem Betrieb unterschiedliche SHA-Passwörter zu verwenden. Bitte beachten Sie, dass bei Gleichheit der Passwörter unser System Ihr TEST-Passwort ändert (worüber Sie natürlich informiert werden).

In gleicher Weise, in der wir den Digest wieder generieren, um den Input der Transaktion mit dem SHA-IN zu validieren, müssen Sie den Hash rekonstruieren. Dies geschieht mit Ihrer SHA-OUT Passphrase und den von unserem System empfangenen Parametern.

Liegt keine Übereinstimmung vor, wurden die Anfrageparameter möglicherweise manipuliert. Diese Überprüfung gewährleistet die Richtigkeit und Integrität der Parameterwerte, die in der Anfrage gesendet wurden.

Beispiel einer grundlegenden SHA-1-OUT-Berechnung Parameter (in alphabetischer Folge, wie durch Viveum zurück gesendet): ACCEPTANCE: 1234 amount: 15 BRAND: VISA CARDNO: XXXXXXXXXXXX1111 currency: EUR NCERROR: 0 orderID: 12 PAYID: 32100123 PM: CreditCard STATUS: 9 Zusätzliche Zeichenkette (SHA-OUT Passphrase): Mysecretsig1875!? Vollständige Zeichenkette für Hash-Codierung (Alle Parameter-Namen in Großbuchstaben): ACCEPTANCE=1234Mysecretsig1875!?AMOUNT=15Mysecretsig1875!?BRAND=VISAMysecretsig1875!? CARDNO=XXXXXXXXXXXX1111Mysecretsig1875!?CURRENCY=EURMysecretsig1875!?NCERROR=0 Mysecretsig1875!?ORDERID=12Mysecretsig1875!?PAYID=32100123Mysecretsig1875!?PM=CreditCard Mysecretsig1875!?STATUS=9Mysecretsig1875!? Resultierender Digest (SHA-1): 209113288F93A9AB8E474EA78D899AFDBB874355

7.4 Direktes Feedback über HTTP-Server-zu-Server-Anfrage

Nach erfolgter Zahlung kann unser System eine HTTP-Anfrage an eine vom Händler vorgegebene URL senden und dorthin die Transaktionsdaten übertragen.

Dieser Vorgang erlaubt dem Händler unter anderem, seine Datenbank hinsichtlich Bestellstatus zu aktualisieren und die Bestellung abzuschließen (sofern dies nicht bereits als Resultat einer Umleitung geschehen ist). Diese Methode bietet auch eine alternative Möglichkeit, dem Kunden im Falle spezifischer Bedürfnisse eine personalisierte Rückmeldung zukommen zu lassen (sofern dies nicht bereits als Resultat einer Umleitung geschehen ist).

7.4.1 Post-payment-URLs

Zur Automatisierung Ihrer Back-Office-Aufgaben können Sie im Bereich “Transaktionsfeedback“, Abschnitt “Direktes Feedback über HTTP-Server-zu-Server-Anfrage“ (Felder „URL“) auf der Seite “Technische Informationen” die URLs von zwei ausführbaren Seiten auf Ihrer Webseite festlegen.

• Eine dieser Angaben kann die URL sein, über die Sie die Parameter in einer Anfrage empfangen, wenn der Zahlungsstatus „beantragt“, „abwartend“ oder „unsicher“ lautet.
• Bei der anderen URL kann es sich um die Adresse handeln, unter der Sie die Parameter in einer Anfrage empfangen wollen, wenn die Transaktion vom Kunden „abgebrochen“ oder vom Akzeptanzpartner häufiger abgelehnt wurde, als dies im Bereich “Globale Transaktionsparameter“, Abschnitt “Maximale Anzahl Zahlungsversuche“ der Seite Technische Informationen festgelegt ist.

Diese beiden URLs können unterschiedlich oder identisch sein.Sie können auch nur für den ersten Fall eine URL eingeben und keine zweite.

Geben Sie in der URL jedoch keine Ports an, da wir nur die Ports 443 und 80 akzeptieren.

Variable Post-Sale-URLs für multiple Shop-Systeme Wenn Sie auf der Seite Technische Informationen Ihres Kontos eine Post-Sale-URL konfiguriert haben, jedoch mehrere Webshops haben, von denen jeder mit einem spezifischen Verzeichnis für den Empfang der Post-Sale-Rückmeldungen in Verbindung steht, können Sie einen Teil Ihrer Post-Sale-URL variabel gestalten. Dieser variable Teil kann beispielsweise auch dazu verwendet werden, die Post-Sale-Anfrage so anzupassen, dass sie Session-Daten enthält, die dann als Teil der URL und nicht als zusätzlicher Parameter übertragen werden. Dies ist bei Intershop-Plattformen oder Servlets-Systemen der Fall. Hierzu müssen Sie das folgende verborgene Feld verwenden: <input type="hidden" name="PARAMVAR" value=""> Beispiel: Post-Sale-URL in der Seite Technische Informationen des Händlers: https://www.yourwebsite.com/<PARAMVAR>/yourpage.asp Nachfolgend das zusätzliche verborgene Feld, das vom Händler gesendet wird: <input type="hidden" name="PARAMVAR" value="shop1"> Dies führt zu folgender Post-Sale-URL für die Transaktion: https://www.yourwebsite.com/shop1/yourpage.asp Wichtig: Bitte benutzen Sie keine Sonderzeichen im Parameter PARAMVAR, da diese URL kodiert werden, und dies ungültige URL's erzeugen könnte.

7.4.2 Post-Sale-Anfragetyp

Im Bereich “Transaktionsfeedback“, Abschnitt “Direktes Feedback über HTTP-Server-zu-Server-Anfrage“ auf der Seite “Technische Informationen”Ihres Kontos können Sie einen der folgenden Anfragetypen für die HTTP-Server-zu-Server-Anfrage auswählen:

• Keine Anfrage
  
  In diesem Fall sendet unser System keine Post-Sale-Anfrage. Diese Option erlaubt Ihnen, fü Wartungsarbeiten oder bei Problemen mit Ihrem Server Ihre Post-Sale-URLs zu deaktivieren.

• Immer zeitversetzt (deferred, nicht unmittelbar nach der Zahlung):
  
  Die Post-Sale-Anfrage wird kurz nach Abschluss des Zahlungsprozesses gesendet. Die Post-Sale-Anfrage wird im Hintergrund ausgeführt und kann nicht dazu genutzt werden, eine personalisierte Rückmeldung an den Kunden auf der Webseite des Händlers zu senden.
  
  Wenn der Händler keine Post-Sale-Seite nutzt, eine Rückmeldung an seine Kunden zu personalisieren, kann er die Post-Sale-Anfrage im Hintergrund und zeitverzögert empfangen.

• Immer online (direkt nach der Zahlung, um die Möglichkeit zu haben die für den Kunden sichtbare Antwort anzupassen):
  
  Die Post-Sale-Anfrage wird "online" zu einem Zeitpunkt zwischen dem Eingang der Antwort des Akzeptanzpartners bei uns und dem Zeitpunkt gesendet, an dem unser System den Kunden über das Resultat des Zahlungsvorgangs informiert.
  
  In diesem Fall kann der Zahlungsprozess für den Kunden länger dauern, doch der Händler hat die Möglichkeit, eine personalisierte Antwort an den Kunden zu schicken.
  
  Der Nachteil des Online-Post-Sale-Prozesses liegt darin, dass das System des Händlers möglicherweise in nachteiliger Weise betroffen ist, wenn zu viele Anfragen auf seiner Post-Sale-Seite auflaufen (z. B. bei hohem Transaktionsvolumen pro Minute). Dies könnte zu langen Antwortzeiten führen, bis der Kunde seine Rückmeldung am Bildschirm sieht.

• Online, aber Wechsel zu zeitlich versetzter Anfrage (deferred Request), wenn die Online-Anfrage fehlschlägt:
  
  Diese Option eröffnet Händlern, die eine Rückmeldung nach erfolgter Zahlung benötigen (um die Anzeige für den Kunden entsprechend anzupassen) eine Rückkehrmöglichkeit, sollte die Online-Anfrage auf seiner Post-Payment-Seite fehlschlagen. In diesem Fall werden wir maximal 4 Mal im Abstand von zehn Minuten (im Hintergrund und mit Zeitverzögerung) die Post-Sale-Anfrage wiederholen. So verpasst der Händler keine Transaktionsrückmeldung, wenn die Online-Post-Sale-Anfrage wegen vorübergehender Probleme mit dem Server an seinem Ende einmal fehlschlagen sollte. Der Kunde bekommt dann die Standard-Transaktionsrückmeldung von unserem System angezeigt (siehe Standard-Rückmeldung).

7.4.3 Antwort an den Kunden

Wir verwenden eine mögliche Antwort von Ihrer Post-Sale-Seite zur Anzeige einer Rückmeldung (Seite zum Abschluss der Transaktion) für Ihren Kunden.

Wenn Ihre Post-Sale-Seite wie folgt antwortet: mit einer HTML-Seite (die ein <html> Tag enthält) oder mit einer Umleitung (HTTP 302 Object Moved), sendet unser System diese HTML-Seite ohne Änderungen an den Client-Browser oder veranlasst die Umleitung, anstatt Ihren Kunden am Ende Ihres Post-Sale-Prozesses zu einer der vier URLs umzuleiten, die Sie möglicherweise in den verborgenen Feldern gesendet haben (ACCEPTURL, EXCEPTION, CANCELURL und DECLINEURL, wie in Kapitel Umleitung gemäß Zahlungsergebnis beschrieben).

Wenn Sie keine der oben genannten Rückmeldungsmethoden für Ihren Kunden benutzen, können Sie alternativ Ihre Post-Sale-Seite dazu veranlassen, mit einigen Textzeilen zu antworten (kein <html> Tag), die wir dann in unsere Standardantwort übernehmen. Andernfalls bekommt der Kunde nur unsere Standardantwort angezeigt (wie in Kapitel Standard-Rückmeldung)

Das Diagramm unten zeigt den Ablauf am Ende einer Transaktion für den Fall, dass die Zahlung autorisiert oder akzeptiert wird, mit einer Online-Anfrage nach erfolgter Zahlung. (Wenn der Zahlungsvorgang abgebrochen oder verweigert wird oder wenn er unsicher ist, ist der Ablauf ähnlich, nur dass stattdessen die Seiten "CANCELURL" / "DECLINEURL" / "EXCEPTIONURL" oder "cancellation/rejection" genutzt werden.)

7.4.4 HTTP-Anfrage für Statusänderungen

Wenn Sie auch eine zeitverzögerte HTTP-Anfrage erhalten wollen, wenn sich der Status einer Transaktion ändert, können Sie auf der Seite Technische Informationen im Bereich “Transaktionsfeedback“, Abschnitt “HTTP-Anfrage für Statusänderungen“ eine zusätzliche URL definieren.

Sie ist mit der Post-Sale-URL vergleichbar mit dem Unterschied, dass diese URL für mögliche Hintergrundprozesse relevant ist.

Sie können hier dieselbe URL wie im Abschnitt „Direktes Feedback über HTTP-Server-zu-Server-Anfrage“ angeben, doch beachten Sie, dass es in diesem (Hintergrund-) Fall keinen Sinn ergibt, sie zur Erzeugung einer personalisierten Antwort an den Kunden zu nutzen.

7.5 Parameter der Rückmeldung

Wenn eine Zahlung ausgeführt wird, können wir die folgende Parameterliste senden.

Feld	Wert
ACCEPTANCE	Vom Akzeptanzpartner zurückgesendeter Akzeptanzwert
amount	Betrag der Bestellung (nicht mit 100 multipliziert)
BRAND	Kartenmarke (unser System leitet sie von der Kartennummer ab)
CARDNO	Maskierte Kartennummer
CN	Name von Karteninhaber bzw. Kunde
CURRENCY	Währung der Bestellung
ED	Kartenverfallsdatum
NCERROR	Fehlerwert
ORDERID	Ihre Bestellnummer
PAYID	Bezahlungs ID als Referenz in unserem System
PM	Zahlungsmethode
SHASIGN	Von unserem System berechneter SHA-Ausgangscode (wenn SHA-OUT konfiguriert ist)
STATUS	Transaktionsstatus (siehe Kurze Statusübersicht)
TRXDATE	Transaktionsdatum

Beispiel (GET request)

https://www.yourwebsite.com/acceptpage.asp?ORDERID=ref12345&CURRENCY=EUR&AMOUNT=25&PM=CreditCard&ACCEPTANCE=test123&STATUS=5&CARDNO=XXXXXXXXXXXX1111&PAYID=1136745&NCERROR=0&BRAND=VISA&ED=0514&TRXDATE=12/25/08&CN=John Doe

Für Händler, die in ihrem Konto bestimmte Optionen wie beispielsweise das Betrugserkennungsmodul aktiviert haben, kann die Parameterliste umfangreicher sein. Bitte entnehmen Sie der entsprechenden Dokumentation weitere Informationen über zusätzliche Rückmeldungsparameter, die mit dieser Option verbunden sind.

7.5.1 Dynamische feedback parameter

Sie können auch auswählen, welche Parameter mit der Post-Sale-Anforderung gesendet werden. Dazu gehen Sie auf Ihrer Seite Technical Information zum Register "Transaktions-Feedback". Dort finden Sie eine Liste von Feldern, die bereits "ausgewählt" oder noch "verfügbar" sind. Nur die Felder mit dem Vermerk "ausgewählt" werden Bestandteile der Post-Sale-Anforderungen.

Um Parameter in die Post-Sale-Anforderung aufzunehmen oder daraus zu entfernen, klicken Sie die betreffenden Parameternamen an und dann, je nach gewünschter Aktion, auf den entsprechenden Pfeil.

Vergessen Sie nach dem Hinzufügen bzw. Entfernen von Parametern nicht, Ihre SHA-OUT Signatur entsprechend zu aktualisieren. Hier nicht ausgewählte Parameter fließen NICHT in die SHA-OUT Berechnung ein.

7.5.2 Variable Rückmeldungsparameter

In den verborgenen Feldern des Bestellformulars kann uns der Händler zwei zusätzliche Parameter zusenden, um diese nach der Zahlung als Parameter der Rückmeldung wieder zu empfangen. Es sind dies die beiden folgenden verborgenen Felder:

<input type="hidden" name="COMPLUS" value="">
<input type="hidden" name="PARAMPLUS" value="">

Feld	Nutzung
COMPLUS	Feld für die Einreichung eines Wertes, den Sie in der Post-Sale-Anfrage zurückgesendet haben möchten.
PARAMPLUS	Feld für die Einreichung einiger Parameter und deren Werte, die Sie in der Post-Sale-Anfrage zurückgesendet haben möchten. Das Feld paramplus ist als solches nicht Bestandteil der Parameter in der Rückmeldung. Stattdessen werden die Parameter bzw. Werte, die Sie in diesem Feld senden, analysiert und die sich daraus ergebenden Parameter werden der HTTP-Anfrage beigefügt.

Beispiel Nachfolgend die zusätzlichen verborgenen Felder, die vom Händler gesendet werden: <input type="hidden" name="COMPLUS" value="123456789123456789123456789"> <input type="hidden" name="PARAMPLUS" value="SessionID=126548354&ShopperID=73541312"> Diese führen zu einer Umleitung mit folgenden Rückmeldungsparametern: https://www.yourwebsite.com/acceptpage.asp?[…standard.parameters…] &COMPLUS=123456789123456789123456789&SessionID=126548354&ShopperID=73541312

7.6 Feedback-Reinitialisierung

Falls eine Weiterleitungs-/Feedback-Anfrage aufgrund einer Sperre durch den Kunden (z. B. durch Klicken auf die Zurück-Taste im Browser) auf unseren sicheren Zahlungsseiten nicht durchgeführt wurde, können wir die Anfrage nach der Zahlung und/oder die Weiterleitung reinitialisieren, sodass Ihr Kunde zu jener Seite weitergeleitet wird, die Sie anzeigen möchten, und Ihre Datenbanken aktualisiert werden können.

Um diese Funktion in Ihrem Konto zu aktivieren, wählen Sie Konfiguration > Technischen Informationen > Transaktions-Feedback > Allgemein und markieren das Kästchen " Ich wünsche, dass Viveum bei Bedarf den Transaktionsabschlussprozess (HTTP-Umleitung/Zahlungsabschlussanfrage) erneut anstößt."

Es ist jedoch möglich, dass Sie für dieselbe Bestellnummer mehrere Anfragen nach der Zahlung erhalten, da die Weiterleitungs-/Feedback-Anfrage erneut gesendet wird, wenn der Kunde zu unseren sicheren Zahlungsseiten zurückkehrt, indem der die Zurück-Schaltfläche verwendet, nachdem er zu Ihrer Website weitergeleitet wurde.

Bitte vergewissern Sie sich, Ihr Post-URL-Script so zu konfigurieren, dass es diese „Ausnahmen“ bearbeiten kann. Beispielsweise könnten Sie Ihr Post-URL-Script so konfigurieren, dass für jeden Transaktionsstatus, der zurückgemeldet wird, eine Zeile in Ihrer Datenbank erstellt wird und/oder um eine E-Mail, die den Händler über eine „Ausnahme“ von den „erwarteten“ Schritten im Transaktionsprozess informiert.

Es wird empfohlen, die erste Nachricht zum Transaktionsstatus, die Sie erhalten, nicht mit etwaigen weiteren Nachrichten für dieselbe Bestellnummer zu überschreiben. Idealerweise sollten Sie alle Rückmeldungen auf eine Bestellung speichern und einen Prozess aufrufen, womit diese angemessen untersucht und bearbeitet werden können.

Wenn Sie das Kästchen nicht auswählen, wird dem Kunden – wenn er auf die Schaltfläche Zurück klickt, um zu den sicheren Zahlungsseiten zurückzukehren – eine Nachricht angezeigt, aus der hervorgeht, dass die Zahlung bereits verarbeitet wurde.

7.7 E-Mail-Bestätigungen

7.7.1 E-Mails an den Händler

Unser System kann Ihnen für jede Transaktion eine E-Mail als Zahlungsbestätigung senden (die entsprechende Option wird im Bereich “E-Mails zu Transaktionen“, Abschnitt “E-Mails an den Händler“ auf der Seite “Technische Informationen” konfiguriert).

Sie können ebenfalls E-Mails empfangen, die Sie über die Änderungen des Transaktionsstatus informieren.

7.7.2 E-Mails an den Kunden

Unser System kann automatisch eine E-Mail an Ihren Kunden senden, um ihn über die Erfassung der Transaktion zu benachrichtigen. Es handelt sich dabei um einen Standardtext, der nicht geändert werden kann. Sie können diese Option im Bereich “E-Mails zu Transaktionen”, Abschnitt „E-Mails an Ihre Kunden“, auf der Seite „Technische Informationen“ aktivieren.

Sie haben auch die Möglichkeit, eine E-Mail an Ihren Kunden zu senden, sobald die Transaktion bestätigt wurde (Buchung) und wenn eine Transaktion gutgeschrieben worden ist. Wählen Sie dazu die entsprechenden Kontrollkästchen aus. Als E-Mail-Adresse des Absender („From“) für diese E-Mails können Sie den Eintrag unter „Support-E-Mail-Adresse zur Verwendung in transaktionsbezogenen E-Mails“ konfigurieren. Wenn Sie hier keine E-Mail-Adresse eingeben, verwenden wir die erste unter „E-Mail-Adresse(n) für transaktionsbezogene E-Mails“ im Abschnitt „E-Mails an den Händler“ angegebene Adresse.

Damit Sie die bestätigenden E-Mails verschicken können, müssen Sie die E-Mail-Adresse des Kunden im verborgenen Feld übermitteln:

<input type="hidden" name="EMAIL" value="">

Feld	Verwendung
EMAIL	E-Mail-Adresse des Kunden. Wenn Sie 3DSv2.1 anfragen, sorgen Sie dafür, dass das Format der E-Mail-Adresse korrekt ist. Anderfalls wird der Authentifizierungsprozess über 3DSv1 ausgerollt werden.

8. e-Commerce via E-mail

Sie können Ihren Kunden eine Zahlungsaufforderung per E-Mail zukommen lassen und hierzu den Kunden über eine Schaltfläche oder einen Link in der E-Mail auf unsere sichere Zahlungsseite umleiten.

Wenn die E-Mail HTML-Format hat, können Sie ein Formular mit verborgenen HTML-Feldern verwenden, um uns die nötigen Parameter im POST-Format zu senden.

Wenn die E-Mail reines Textformat hat, können Sie die nötigen Parameter im GET-Format der URL beifügen. (Beispiel: https://viveum.v-psp.com/ncol/test/orderstandard.asp / orderstandard_utf8.asp?PSPID=TESTSTD&ORDERID=order123&AMOUNT=12500&CURRENCY=EUR&SHASIGN=8DDF4795640EB9FE9B367315C48E47338129A4F5& …)

Weitere Informationen finden Sie in Verknüpfen Sie Ihre Webseite zur Zahlungsseite.

Damit e-Commerce via E-Mail funktioniert, müssen Sie vor der Zahlung die mit der Verifikation zusammenhängenden Aspekte im Blick behalten: Wenn Sie diese Funktionalität in einer GET-Anfrage verwenden wollen, stellen Sie sicher, dass keine persönlichen Daten übertragen werden (wie z.B. E-Mail-Adressen oder Telefonnummern) Sie müssen das Feld URL im Bereich “Daten- und Ursprungsüberprüfung“, Abschnitt “Überprüfungen für e-Commerce“ auf der Seite Technische Informationen Ihres Kontos leer lassen, um Fehlermeldungen des Typs unknown order/1/r/ zu vermeiden. Sie müssen eine SHA Signatur als Verifizierungsmethode für die Bestelldaten verwenden. Weitere Informationen zur SHA-IN-Signatur finden Sie in SHA-IN-Signatur.

9. Zahlungsmethode Auswahlmöglichkeiten

9.1 Auswahl der Zahlungsmethode auf der Händler-Webseite

9.1.1 Anzeige einer spezifischen Zahlungsmethode

Wenn ein Kunde unsere sichere Zahlungsseite angezeigt bekommt, sieht er einen Überblick der möglichen Zahlungsmethoden, die der Händler in seinem Konto aktiviert hat. Soll der Kunde die Zahlungsmethode nicht auf unserer Zahlungsseite sondern auf der Webseite des Händlers auswählen, kann der Händler uns in den verborgenen Feldern Name und Marke der Zahlungsmethode senden (nur wenn die Zahlungsmethode “CreditCard” heißt), damit wir nur diese spezifische Zahlungsmethode auf unserer Zahlungsseite anzeigen und nur Zahlungen mit dieser Zahlungsmethode zulassen.

Die verborgenen Felder sind:

<input type="hidden" name="PM" value="">
<input type="hidden" name="BRAND" value="">

Feld	Nutzung
PM	Zahlungsmethode / Zahlungsmethode Gruppe (z.B. CreditCard)
BRAND	Zahlungsmethode Marke (z.B. VISA)

Beispiele Verborgene Felder, wenn Ihr Kunde auf Ihrer Webseite VISA ausgewählt hat: <input type="hidden" name="PM" value="CreditCard "> <input type="hidden" name="BRAND" value="VISA"> Verborgene Felder, wenn Sie möchten, dass der Kunde ausschließlich per Kreditkarte zahlt (beispielsweise wenn Sie über weitere Zahlungsmethoden verfügen, diese aber nicht anbieten wollen): <input type="hidden" name="PM" value="CreditCard "> <input type="hidden" name="BRAND" value=""> Verborgene Felder, wenn Ihr Kunde auf Ihrer Site iDEAL ausgewählt hat: <input type="hidden" name="PM" value="iDEAL"> <input type="hidden" name="BRAND" value=""> ODER <input type="hidden" name="PM" value=""> <input type="hidden" name="BRAND" value="iDEAL">

9.1.2 Erlaubt dem Kunden die Auswahl einer anderen Zahlungsmethode: BACKURL

Wenn der Kunde die Zahlungsmethode auf der Website des Händlers wählt, zeigen wir auf unser Zahlungsseite nur die ausgewählte Zahlungsmethode an.

Wenn die Zahlung mit dieser Methode nicht erfolgreich war und der Kunde eine andere Zahlungsmethode versuchen möchte, bekommt er auf unseren sicheren Zahlungsseiten keine Liste der vom Händler unterstützten Zahlungsmethoden angezeigt, weil die Auswahl der Zahlungsmethode auf der Website des Händlers und nicht auf unseren sicheren Zahlungsseiten erfolgt ist.

In diesem Fall kann der Händler die „backurl“ dazu verwenden, den Kunden zu einer URL auf der Händler-Website umzuleiten und ihm dort die Möglichkeit geben, eine andere Zahlungsmethode auszuwählen. Wenn der Kunde die Schaltfläche „Zurück“ auf unserer sicheren Zahlungsseite anklickt, nachdem eine Autorisierung abgelehnt wurde oder nach einem Abbruch von dritter Seite oder einer Bank-Website, leiten wir den Kunden zu der URL um, die der Händler als „BACKURL“ angegeben hat.

Anmerkung: Die in diesem Abschnitt beschriebene Zurück-Schaltfläche ist die Zurück-Schaltfläche auf unseren sicheren Zahlungsseiten und NICHT die Zurück-Schaltfläche in Ihrem Browser.

Sie können die „BACKURL“ im Register „Payment page layout“ der Seite „Technical Information“ Ihres Kontos eingeben.

Alternativ senden Sie uns eine spezifische „BACKURL“ in den verborgenen Feldern der Transaktion, sofern Sie es vorziehen, nicht die gleiche „BACKURL“ wie im Register „Payment page layout“ der Seite „Technical Information“ Ihres Kontos eingeben zu verwenden.

Die „backurl“, die Sie uns in den verborgenen Feldern senden, erhält Vorrang vor der „BACKURL“, wie im Register „Payment page layout“ der Seite „Technical Information“ Ihres Kontos eingegeben. Die „BACKURL“ senden Sie uns im folgenden verborgenen Feld:

<input type="hidden" name="BACKURL" value="">

Feld	Verwendung
BACKURL	URL der Webseite, die dem Kunden angezeigt werden soll, wenn er auf unserer sicheren Zahlungsseite die Zurück-Schaltfläche anklickt.

Wenn der Kunde seine Zahlungsmethode auf unseren sicheren Zahlungsseiten auswählt und nicht auf der Website des Händlers, bleibt die „backurl“ unberücksichtigt. Klickt ein Kunde auf unserer sicheren Zahlungsseite auf die Schaltfläche „Zurück“, wird er einfach auf unsere sichere Seite zur Auswahl der Zahlungsmethode umgeleitet, die eine Liste der vom Händler unterstützten Zahlungsmethoden enthält.

9.2 Spezifische Liste von Zahlungsmethoden anzeigen

Soll der Kunde die Zahlungsmethode aus einer bestimmten Liste auf unserer Zahlungsseite auswählen, kann der Händler uns in den verborgenen Feldern die Liste der Zahlungsmethoden senden, damit wir nur diese spezifischen Zahlungsmethoden auf unserer Zahlungsseite anzeigen.

Das verborgene Feld ist dann:

<input type="hidden" name="PMLIST" value="">

Field	Nutting
PMLIST	Liste der ausgewählten Zahlungsmethoden bzw. Kreditkartenmarken, getrennt durch Semikolon (;).

Beispiele

Verborgenes Feld, wenn Sie möchten, dass der Kunde auf unserer Zahlungsseite zwischen VISA und iDEAL wählt (beispielsweise wenn Sie über weitere Zahlungsmethoden verfügen, diese aber nicht anbieten wollen):

<input type="hidden" name="PMLIST" value="VISA;iDEAL">

9.3 Ausschluss spezifischer Zahlungsmethoden

Wenn der Händler dem Karteninhaber eine bestimmte Marke nicht anbieten möchte, kann er dazu ein verborgenes Feld verwenden.

Dies ist insbesondere nützlich für Unter-Marken, wenn ein Händler eine Marke (z. B. MasterCard), nicht aber deren Unter-Marken (z. B. Maestro) akzeptieren möchte.

Das verborgene Feld ist dann:

<input type="hidden" name="EXCLPMLIST" value="">

Feld	Verwendung
EXCLPMLIST	Liste der Zahlungsmethoden bzw. Kreditkartenmarken, die NICHT gezeigt werden sollen. Getrennt durch ein Semikolon „;“.

9.4 Layout der Zahlungsmethoden

Mit dem folgenden verborgenen Feld können Sie das Layout bzw. die Liste der Zahlungsmethoden auf unserer Zahlungsseite gestalten:

<input type="hidden" name="PMLISTTYPE" value="">

Feld	Mögliche Werte
PMLISTTYPE	Zulässige Werte sind 0, 1 und 2: 0: Horizontal gruppierte Logos mit dem Gruppennamen links davon (Voreinstellung) 1: Horizontal gruppierte Logos ohne Gruppennamen 2: Vertikale Liste von Logos mit Name der spezifischen Zahlungsmethode oder Markenname

9.5 Aufteilung Kredit/Debit

Die Funktionalität zur Aufteilung von VISA und MasterCard in ein Debit- und ein Kreditkarten-Zahlungsverfahren erlaubt es Ihnen, Ihren Kunden diese Programme als zwei unterschiedliche Zahlungsverfahren anzubieten (z. B. VISA Debit und VISA Kredit). Sie können auch entscheiden, nur eines der Teilverfahren für beide Marken zu akzeptieren.

Um die Aufteilung von Kredit- und Debit-Karten via e-Commerce zu nutzen, müssen Sie den Parameter CREDITDEBIT in die verborgenen Felder aufnehmen, die Sie an die Zahlungsseite senden (und daher auch in die SHA-IN-Berechnung einschließen!).

Feld	Format
CREDITDEBIT	"C": credit card (Kreditkarte) "D": debit card (Debitkarte)

Zugehörige Fehlermeldung: Wenn ein Käufer das Debitkarten-Zahlungsverfahren auswählt, aber die Nummer einer Kreditkarte eingibt, wird ein Fehler zurückgemeldet: „Wrong brand/Payment method was chosen“ (Falsche Marke/falsches Zahlungsverfahren ausgewählt).

Wenn die Zahlung mit dem Parameter CREDITDEBIT erfolgreich verarbeitet worden ist, wird der gleiche Parameter auch in der Post-Sale-Rückmeldung zurückgegeben. Lauten die eingereichten Parameterwerte C bzw. D, ist der zurückgemeldete Wert "CREDIT" bzw. "DEBIT".

Sie finden diese Rückmeldungswerte in der Transaktionsübersicht über „View transactions“ (Transaktionen anzeigen) und „Financial history“ (Zahlungshistorie) sowie in den Berichten, die Sie nachfolgend herunterladen.

Konfiguration in Ihrem Konto Die Aufteilungsfunktion kann auch in Ihrem Viveum-Konto pro Zahlungsverfahren aktiviert und konfiguriert werden. Weitere Informationen finden Sie unter Split Credit/Debit Cards.

10. Weitere optionale verborgene Felder

10.1 Standardoperationswert

Wichtig Die Möglichkeit, in zwei Schritte vorzugehen (Autorisierung und Datenerfassung), ist abhängig von den Zahlungsmethoden, die Sie verwenden möchten (siehe Überblick Payment Methods Processing/Procedures).

Sie können uns einen spezifischen Standardoperationswert für eine spezifische Transaktion senden, wenn Sie es vorziehen, nicht den im Bereich “Globale Transaktionsparameter“, Abschnitt “Standardoperationswert“, auf der Seite „Technische Informationen“ Ihres Kontos angegebenen Standardoperationswert zu verwenden.

Der Operationswert, den Sie uns in den verborgenen Feldern senden, setzt den allgemeinen, im Bereich “Globale Transaktionsparameter“, Abschnitt “Standardoperationswert“, auf der Seite „Technische Informationen“ Ihres Kontos angegebenen Standardoperationswert außer Kraft. Den Operationswert senden Sie uns im folgenden verborgenen Feld:

<input type="hidden" name="OPERATION" value="">

Feld

Nutzung

OPERATION

Standardoperationswert für die Transaktion. Mögliche Werte für neue Bestellungen: RES: Anfrage für Autorisierung (Reservierung) SAL: Anfrage für Direktbuchung (Verkauf) PAU: Vorautorisierungsanfrage In Absprache mit Ihrem Acquirer können Sie diesen Operationskode verwenden, um zeitweise Beträge auf der Karte eines Kunden zu reservieren. Momentan (10/2015) steht Vorautorisierung allein für MasterCard-Transaktionen zur Verfügung und wird nur durch ausgewählte Acquirer unterstützt. Dieser Operationskode kann nicht als Standarteinstellung in Ihrem Viveum-Konto ausgewählt werden. Sollten Sie versuchen, Vorautorisierungen für Transaktionen vorzunehmen, bei denen der Acquirer oder die Kartenmarke solche Vorautorisierung nicht unterstützt, werden diese Transaktionen nicht blockiert sondern wie normale Autorisierungen (=RES) ausgeführt.

Damit unser System diesen Parameter berücksichtigt, muss er in die SHA-Berechnung für die Transaktion einbezogen werden. Weitere Informationen zu SHA finden Sie in SHA-IN-Signatur.

10.2 Benutzer-Identifikationsfeld

Wenn es in Ihrem Konto mehrere Benutzer gibt und Sie wollen die mit einem spezifischen Nutzer zusammenhängenden Transaktionen registrieren (z. B. für einzelne Mitarbeiter in einem Callcenter die Transaktionen via e-Commerce protokollieren), können Sie in folgendem verborgenen Feld die USERID senden:

<input type="hidden" name="USERID" value="">

Feld	Nutzung
USERID	Die auf der Seite Benutzermanagement des Händler-Kontos angegebene User-ID.

Bei diesem Feld handelt es sich um ein rein informatives Feld, das dazu dient, einer spezifischen Transaktion eine UserID zuzuweisen. Wir führen auf unserer Seite keine Prüfung durch um beispielsweise festzustellen, ob es für diesen Anwender fehlerhafte Passworteingaben gegeben hat. Wir prüfen lediglich, ob die UserID gültig ist. Wenn die UserID nicht existiert, ersetzen wir sie durch die Standard-UserID des Kontos (PSPID).

11. 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 Viveum 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.

11.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 e-Commerce / 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.

11.2 Testkarten

Mit den folgenden Testkarten können Sie eine registrierte 3-D Secure-Karte in unserer Testumgebung simulieren:

Reibungsloser Fluss
Marke	Kartenummer	Ablaufdatum
VISA	4186455175836497	Beliebiges Datum in der Zukunft
Mastercard	5137009801943438	Beliebiges Datum in der Zukunft
American Express	375418081197346	Beliebiges Datum in der Zukunft
Carte Bancaire	4150557357382737	Beliebiges Datum in der Zukunft

Problematischer Fluss
Marke	Kartenummer	Ablaufdatum
VISA	4874970686672022	Beliebiges Datum in der Zukunft
Mastercard	5130257474533310	Beliebiges Datum in der Zukunft
American Express	379764422997381	Beliebiges Datum in der Zukunft
Carte Bancaire	4150550997933993	Beliebiges Datum in der Zukunft

Hinweis: Weitere Testkartennummern können hier heruntergeladen werden Wenn eine Transaktion wegen einer fehlerhaften Identifikation blockiert ist, hat die Transaktion das Ergebnis: STATUS = 2 NCERROR = 40001134