Wenn Sie ein neuer Händler sind, werfen Sie einen Blick auf die neue Benutzeroberfläche für diesen Integrationsmodus.

Sehen Sie sich dazu im entsprechenden Leitfaden die Funktionen und Anwendungsmöglichkeiten an.

DirectLink ermöglicht die Einrichtung speziell angepasster Verbindungen zwischen Ihren eigenen Applikationen und unserem System, so als wäre unser System einfach ein lokaler Server. Es bietet einen Programm-zu-Programm (Server-zu-Server) -Zugriff der Händlersoftware auf unsere Plattform für Zahlungen und Administration. Das Programm des Händlers interagiert dabei direkt und ohne menschlichen Eingriff mit unserer Remote-API.

Bei Verwendung von DirectLink gibt es keinen Kontakt zwischen unserem System und dem Kunden des Händlers. Der Händler sendet alle für die Zahlung erforderlichen Informationen in einer HTTPS Posting-Anfrage direkt an unser System. Unser System fragt die Finanztransaktion (synchron oder asynchron) beim betreffenden Akzeptanzpartner an und sendet dessen Antwort im XML-Format an den Händler zurück. Das Programm des Händlers liest die Antwort und setzt seine Verarbeitung fort.

Der Händler ist darum für die Sammlung und Speicherung sensibler Zahlungsdaten seiner Kunden verantwortlich. Er muss die Vertraulichkeit und Sicherheit dieser Daten durch verschlüsselte Web-Kommunikation und Sicherung seines Servers gewährleisten. Wenn der Händler keine sensiblen Daten wie beispielsweise Kartennummern speichern möchte, empfehlen wir die Nutzung der Alias-Option innerhalb seines Kontos (weitere Informationen hierzu finden Sie im Alias-Manager Integrationsleitfaden).

Der Händler kann neue Bestellungen verarbeiten, die Daten bestehender Bestellungen pflegen und den Status einer Bestellung mit DirectLink abfragen.

Auch wenn der Händler Anfragen mit DirectLink automatisiert hat, kann er die Historie einer Transaktion manuell im Back-Office einsehen. Hierzu kann er seinen Web-Browser verwenden oder einen Bericht herunterladen. Lesen Sie Informationen zur Konfiguration und Funktionalität des Administrator-Standortes bitte im Back-Office Anwenderhandbuch nach.

Die folgenden allgemeinen Vorgehensweisen und Sicherheitskontrollen gelten für alle DirectLink-Anfragen: neue Bestellanfragen, Datenpflegeanfragen und Direktabrufe.

Die oben stehende Grafik zeigt die einzelnen Schritte einer solchen Transaktion mit DirectLink.

Ein API (Application Program Interface)-Benutzer wird benötigt, an den DirectLink-Anfragen gerichtet werden können.

Im Allgemeinen handelt es sich dabei um einen speziell erstellten Benutzer, der von einer Anwendung verwendet wird, um automatische Anfragen an die Zahlungsplattform zu richten.

Sie können in Ihrem Ingenico-Konto über „Konfiguration" > „Benutzer" einen API-Benutzer erstellen. Wählen Sie „Neuer Benutzer" und füllen Sie die Pflichtfelder aus.

Um den neuen Benutzer zu einem API-Benutzer zu machen, vergewissern Sie sich, dass Sie das Kästchen „Sonderbenutzer für API (Kein Zugriff auf Administration)" abhaken.

Creation of an API user

Wenn für einen API-Benutzer auch die verschiedenen Benutzerprofile zur Verfügung stehen, empfehlen wir Ihnen dringend, diesen Benutzer mit dem „Admin"-Profil zu konfigurieren.
Wenn Sie die Rechte für die Pflege von Transaktionen (Erstattungen, Abbruch, usw.) einschränken möchten, können Sie das Benutzerprofil noch zu z.B. „Kodierer“ ändern.

Wenn Sie nicht sicher sind, empfehlen wir Ihnen, das „Admin"-Profil zu wählen; oder wechseln Sie zu den Benutzerprofilen (Benutzermanager) für mehr Informationen.

Das Passwort eines API-Benutzers muss nicht regelmäßig geändert werden. Das ist praktischer, wenn das Passwort fest in Ihrer Anwendung hinterlegt werden muss. Jedoch empfehlen wir, das Passwort von Zeit zu Zeit zu ändern.

Mehr Informationen über Benutzertypen und wie das Passwort des API-Benutzers geändert wird, finden Sie unter "Benutzertypen" (Benutzermanager).

Für neue Bestellanfragen, Datenpflegeanfragen und Direktabrufe muss der Händler die Anfragen mit bestimmten Parametern an bestimmte URLs senden. Die Parameter für Zahlung/Datenpflege/Abruf müssen in einer Posting-Anfrage wie folgt gesendet werden:

PSPID=value1&USERID=value2&PSWD=value3&…

Der Type/Subtyp zur Anzeige des Medientyps im Content-Type Entity-Header Feld der POST-Anfrage muss „application/x-www-form-urlencoded" lauten.

DirectLink arbeitet im Modus „eine Anfrage - eine Antwort". Jede Zahlung wird einzeln verarbeitet. Unser System handhabt individuelle Anfragen via DirectLink und kann synchron arbeiten (wenn diese Option technisch unterstützt wird). D. h. wir warten auf die Antwort der Bank, ehe wir eine XML-Antwort auf die Anfrage zurücksenden.

Wenn wir auf unseren Servern eine Anfrage empfangen, prüfen wir das Verschlüsselungsniveau und die IP-Adresse, von der die Anfrage stammt.

DirectLink baut auf einem robusten und sicheren Kommunikationsprotokoll auf. Die API ist ein Instruktionsbestand, der über normale HTTPS Posting-Anfragen übermittelt wird. Wir erlauben dem Händler eine Verbindungsaufnahme mit uns nur im sicheren HTTPS-Modus.
Ein clientseitiges TLS-Zertifikat ist nicht notwendig.

Für jede Bestellung erzeugt der Server des Händlers eine eindeutige Zeichenfolge, aus der mittels SHA1-, SHA-256- oder SHA-512-Algorithmus ein Hashcode generiert wird. Das Resultat dieses Hashvorgangs wird in der Bestellanfrage des Händlers an uns gesendet. Unser System rekonstruiert diesen Hashcode, um so die Datenintegrität der Bestellinformationen zu überprüfen, die an uns gesendet worden sind.

Für jede Anfrage prüft unser System die IP-Adresse, von der die Anfrage kam, um sicherzustellen, dass die Anfragen wirklich vom Server des Händlers stammen. Im IP-Adressenfeld des Bereichs „Daten- und Ursprungsüberprüfung", Abschnitt „Überprüfungen für DirectLink" der Seite „Technische Informationen" Ihres Kontos müssen Sie die IP-Adressen oder IP-Adressbereiche der Server eintragen, die Ihre Anfragen an uns senden.

Wenn die IP-Adresse, von der die Anfrage stammt, im IP-Adressenfeld des Bereichs „Daten- und Ursprungsüberprüfung", Abschnitt „Überprüfungen für DirectLink", Seite „Technische Informationen" Ihres Kontos nicht angegeben ist, erhalten Sie die Fehlermeldung „unknown order/1/i". Die IP-Adresse, von der die Anfrage gesendet wurde, wird ebenfalls in dieser Fehlermeldung angezeigt.

Wir reagieren mit einer XML-Antwort auf Ihre Anfrage. Bitte sorgen Sie dafür, dass Ihre Systeme diese XML-Antwort mit größtmöglicher Toleranz auswerten (parsen). Vermeiden Sie beispielsweise Attributnamen, bei denen die Unterscheidung von Groß- und Kleinschreibung notwendig ist, schreiben Sie keine spezifische Reihenfolge für die in Antworten zurückgelieferten Attribute vor, sorgen Sie dafür, dass neue Attribute in der Antwort nicht zu Problemen führen, usw.

  • Die Anfrage-URL in der TESTUMGEBUNG lautet https://ogone.test.v-psp.com/ncol/test/orderdirect.asp.
  • Die Anfrage-URL in der PRODUKTIVUMGEBUNG lautet https://secure.ogone.com/ncol/prod/orderdirect.asp.
Wichtig

Vergessen Sie nicht, in der Anfrage-URL die Zeichenfolge „test" durch „prod" zu ersetzen, wenn Sie auf Ihr reguläres Produktivkonto umstellen. Wenn Sie vergessen, die Anfrage-URL zu ändern und den regulären Betrieb mit realen Bestellungen aufnehmen, laufen Ihre Transaktionen weiter in die Testumgebung und werden nicht an die Akzeptanzpartner bzw. Banken gesendet.

    Die folgende Tabelle enthält die Anfrageparameter für das Senden einer neuen Bestellung:

    Format: AN=alphanumerisch / N=numerisch, die maximal erlaubte Anzahl der Zeichen

    Feld Nutzung
    PSPID

    Name Ihres Händlerkontos in unserem System.

    Format: AN, 30

    Obligatorisch

    ORDERID

    Ihre eindeutige Bestellnummer (Händlerreferenz).

    Format: AN, 40

    Obligatorisch

    USERID

    Name Ihres applikationsgebundenen (API-) Anwenders. Wie Sie einen API-Anwender anlegen, ist in der Benutzer ManagerDokumentation beschrieben.

    Format: AN, 20 (min2)

    Obligatorisch

    PSWD

    Passwort des API-Anwenders (USERID).

    Format: AN

    Obligatorisch

    AMOUNT

    Zu zahlender Betrag, MULTIPLIZIERT MIT 100, da die Betragsangabe keine Dezimalstellen oder andere Trennzeichen enthalten darf.

    Format: N, 15

    Obligatorisch

    CURRENCY

    Alphanumerischer Währungswert nach ISO, beispielsweise: EUR, USD, GBP, CHF, …

    Format: AN, 3

    Obligatorisch

    CARDNO

    Karten-/Kontonummer.

    Format: AN, 21

    Obligatorisch

    ED

    Ablaufdatum

    Format: MM/YY oder MMYY

    Obligatorisch

    COM

    Beschreibung der Bestellung

    CN

    Name des Kunden

    Format: AN, 35

    Obligatorisch

    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.

    SHASIGN

    Signatur (gehashte Zeichenfolge) zur Authentifizierung der Daten (siehe SHA-Signatur).

    CVC

    Kartenverifikationscode. Je nach Kartenmarke entspricht der Verifikationscode einer 3- oder 4-stelligen Ziffernfolge auf der Vorder- oder Rückseite der Karte, einer Ausgabenummer, einem Beginndatum oder einem Geburtsdatum.

    Format: N, 5

    Obligatorisch

    ECOM_PAYMENT_
    CARD_VERIFICATION

    Identisch mit CVC

    Format: N, 5

    Optional

    OWNERADDRESS

    Straße und Hausnummer des Kunden.

    Format: AN, 50

    Optional

    OWNERZIP

    PLZ des Kunden

    Format: AN, 10

    Optional

    OWNERTOWN

    Ortsname des Kunden

    Format: AN, 40

    Optional

    OWNERCTY

    Land des Kunden, z. B. AT, DE, CH,

    Format: AN, 2

    Optional

    OWNERTELNO

    Telefonnummer des Kunden.

    Format: AN, 30

    Optional

    OPERATION

    Bestimmt den Typ der angefragten Transaktion.

    Sie können eine Standardoperation (Zahlungsprozedur) im Bereich „Globale Transaktionsparameter", Abschnitt „Standardoperationswert", auf der Seite „Technische Informationen" konfigurieren. Wenn Sie einen expliziten Operationswert in der Anfrage mitsenden, erhält dieser Vorrang vor dem Standardwert. Mögliche Werte:

    • RES: Anfrage für Autorisierung (Reservierung).
    • SAL: Anfrage für Direktbuchung (Verkauf).
    • RFD: Gutschrift ohne Verknüpfung mit einer vorhergehenden Zahlung, darum keine Datenpflegeoperation an einer bestehenden Transaktion (diese Funktionalität können Sie nur mit besonderer Erlaubnis Ihres Akzeptanzpartners nutzen).
    • 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 Ingenico ePayments-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.

    Format: A, 3

    Obligatorisch

    WITHROOT

    Fügt ein Root-Element in Ihre XML-Antwort ein. Mögliche Werte: ‘Y’ oder leer.

    Format: Y or<emtpy>

    Optional

    REMOTE_ADDR

    IP-Adresse des Kunden (nur für Betrugserkennungsmodul). Wenn für die IP-Adresse keine Prüfung des Absenderlandes erforderlich ist, senden Sie 'NONE'.

    Format: AN

    Optional

    RTIMEOUT

    Zeitüberschreitung für die Transaktion (in Sekunden, Wert zwischen 30 und 90).

    Wichtig: Der hier angegebene Wert muss kleiner als der Zeitüberschreitungswert in Ihrem System sein!

    Format: N, 2

    Optional

    ECI

    Electronic Commerce Indicator.

    Sie können einen ECI-Standardwert im Bereich „Globale Transaktionsparameter", Abschnitt „Standard-ECI-Wert" der Seite „Technische Informationen" festlegen. Wenn Sie in der Anfrage einen ECI-Wert senden, erhält dieser Vorrang vor dem ECI-Standardwert.

    Zulässige (numerische) Werte:

    0 - Karte durch Lesegerät gezogen

    1 - Manuelle Eingabe: Post-/ Telefon- Bestellung (MOTO) (ohne Vorlage der Karte)

    2 - Wiederkehrende Zahlungen, von MOTO stammend

    3 - Ratenzahlungen

    4 - Manuelle Eingabe, Karte hat vorgelegen

    7 - E-Commerce mit SSL-Verschlüsselung

    9 - Wiederkehrend nach erster E-Commerce-Transaktion

    Format: AN, 21

    Optional

    Weitere informationen zu diesen Feldern finden Sie in Ihrem Ingenico ePayments konto. Melden Sie sich einfach an und gehen Sie zu : Support > Integrations & Benutzerhandbucher > Technische Handbucher > Paramater Cookbook.

    Wenn Sie wiederkehrende Zahlungen abwickeln, müssen Sie in Ihrer Anfrage Credentials-on-file (COF)-Parameter hinzufügen.

    Im Alias Manager-Leitfaden erhalten Sie weitere Informationen zur Abwicklung von COF-Transaktionen.


    Die Liste der für die Sendung zulässigen Parameter kann für Händler länger sein, die in ihren Konten bestimmte Optionen aktiviert haben. Bitte lesen Sie in der betreffenden Dokumentation weitere Informationen über zusätzliche Parameter nach, die mit diesen Optionen verbunden sind.

    Die folgenden Parameter sind in neuen Bestellungen obligatorisch:

    • PSPID und USERID
    • PSWD
    • ORDERID
    • AMOUNT (x100)
    • CURRENCY
    • CARDNO
    • ED
    • CVC
    • OPERATION (der Operationscode ist nicht streng obligatorisch, aber dringend empfohlen).


    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


    Ein Beispiel für eine Bestellanfrage (eine Testseite) finden Sie unter https://ogone.test.v-psp.com/ncol/test/testodl.asp.

    Wenn Sie verhindern möchten, dass ein Kunde bestimmte Zahlungsverfahren nutzt, können Sie dazu einen bestimmten Parameter nutzen.

    Dies ist insbesondere bei Unter-Marken nützlich, wenn Sie eine Marke (z. B. MasterCard) akzeptieren möchten, nicht aber eine ihrer Unter-Marken (z. B. Maestro).

    Der Parameter ist wie folgt zu verwenden:

    Feld Verwendung
    EXCLPMLIST Liste der Zahlungsverfahren bzw. Kreditkartenmarken, getrennt durch Semikolon (;), die NICHT verwendet werden sollen.

    Versucht ein Kunde, mit einer Karte zu bezahlen, die mit einem bestimmten Zahlungsverfahren bzw. einer (Unter-)Marke verknüpft ist, aber von Ihnen mittels Parameter EXCLPMLIST vom Gebrauch ausgeschlossen wurde, wird im Feld NCERRORPLUS die Fehlermeldung „Card number incorrect or incompatible“ („Falsche Kartennummer oder nicht zulässig“) zurückgesendet.

    Unser System unterstützt die Nutzung von 3-D Secure über DirectLink. Weitere Informationen zu diesem Feature finden Sie im Integrationsleitfaden für DirectLink mit 3-D Secure.

    Wichtig

    • Wenn Sie 3-D Secure mit DirectLink nutzen möchten, müssen Sie in Ihrem Konto die Option D3D aktiviert haben.
    • Manche Acquirerbanken verlangen die Nutzung von 3-D Secure. Bitte klären Sie mit Ihrem Acquirer, ob dies bei Ihnen der Fall ist.

    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 DirectLink zu nutzen, müssen Sie den Parameter CREDITDEBIT in die verborgenen Felder aufnehmen, die Sie an die Seite orderdirect.asp 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 XML-Rückmeldung zurückgegeben bzw. kann mit einem Direct Query angefordert werden. 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 Ingenico ePayments-Konto pro Zahlungsverfahren aktiviert und konfiguriert werden. Weitere Informationen finden Sie unter Split Credit/Debit Cards.


    Im Alias Manager-Leitfaden erhalten Sie weitere Informationen zur Abwicklung von COF-Transaktionen.

    Unser Server sendet als Rückmeldung zur Anfrage eine XML-Antwort:

    Beispiel einer XML-Antwort auf eine Bestellanfrag

    <?xml version="1.0"?>

    <ncresponse orderID="99999" PAYID="1111111" NCSTATUS="0" NCERROR="" NCERRORPLUS="" ACCEPTANCE="12345" STATUS="5" ECI="7" amount="125" currency="EUR" PM="CreditCard" BRAND="VISA"/>

    Die folgende Tabelle enthält eine Attributliste zum ncresponse-tag:

    FeldNutzung
    ACCEPTANCE

    Vom Akzeptanzpartner zurückgesendeter Akzeptanzwert.

    amount

    Betrag der Bestellung (nicht mit 100 multipliziert)

    BRAND

    Kartenmarke oder vergleichbare Informationen für andere Zahlungsmethoden.

    currency

    Währung der Bestellung.

    ECI Electronic Commerce Indicator.
    NCERROR

    Fehlerwert.

    NCERRORPLUS

    Erklärung des Fehlercodes.

    NCSTATUS

    Transaktionsstatus.

    orderID

    Ihre Bestellnummer.

    PAYID

    Bezahlungs-ID als Referenz in unserem System.

    PM

    Zahlungsmethode.

    STATUS

    Transaktionsstatus.

    Die Attributliste kann bei Händlern länger sein, die in ihren Konten bestimmte Optionen (z. B. Betrugserkennungsmodul) aktiviert haben. Bitte lesen Sie in der betreffenden Dokumentation weitere Informationen über zusätzliche Rückmeldungsattribute nach, die mit dieser Option verbunden sind.

    If you request processing for an already existing (and correctly processed) orderID, our XML response will contain the PAYID corresponding to the existing orderID, the ACCEPTANCE given by the acquirer in the previous processing, STATUS “0” and NCERROR “50001113”.

    Eine direkte Datenpflegeanfrage von ihrer Applikation aus ermöglicht Ihnen:

    • Eine Kontobelastung (Zahlung) einer autorisierten
    • Bestellung automatisch vorzunehmen (anstatt manuell im Back-Office)
    • Autorisierung einer Bestellung zu stornieren
    • Autorisierung einer Bestellung zu erneuern oder eine bezahlte Bestellung wieder gutzuschreiben.
    • Die Anfrage-URL in der TESTUMGEBUNG lautet https://ogone.test.v-psp.com/ncol/test/maintenancedirect.asp.
    • Die Anfrage-URL in der PRODUKTIVUMGEBUNG lautet https://secure.ogone.com/ncol/prod/maintenancedirect.asp.

    Wichtig

    Vergessen Sie nicht, in der Anfrage-URL die Zeichenfolge „test" durch „prod" zu ersetzen, wenn Sie auf Ihr reguläres PRODUKTIVKONTO umstellen. Wenn Sie vergessen, die Anfrage-URL zu ändern und den regulären Betrieb mit realen Bestellungen aufnehmen, laufen Ihre Datenpflege-Transaktionen weiter in die Testumgebung und werden nicht an die Akzeptanzpartner bzw. Banken gesendet.

    Die folgende Tabelle enthält die obligatorische Aufforderung Parameter zur Durchführung einer Wartungsarbeit:

    Feld
    Nutzung
    AMOUNT

    Betrag der Bestellung, mit 100 multipliziert. Nur obligatorisch, wenn der Betrag in der Datenpflegeanfrage sich von dem in der Originalautorisierung unterscheidet. Wir empfehlen jedoch, den Betrag immer anzugeben.

    Unser System prüft, ob der Betrag in der Datenpflegeanfrage nicht zu hoch im Vergleich zum Betrag in der Originalautorisierung bzw. -zahlung ist.

    OPERATION

    Mögliche Werte:

    • REN: Erneuerung der Autorisierung, wenn die Originalautorisierung nicht mehr gültig ist.
    • DEL: Löschung der Autorisierung. Die Transaktion bleibt dabei für mögliche nachfolgende Datenpflegeoperationen geöffnet.
    • DES: Löschung der Autorisierung. Die Transaktion wird nach diesem Vorgang geschlossen.
    • SAL: Teilweise Kontobelastung (Zahlung). Die Transaktion bleibt für eine mögliche weitere Kontobelastung geöffnet.
    • SAS: (Letzte) teilweise oder vollständige Kontobelastung (Zahlung). Nach dieser Kontobelastung wird die Transaktion für weitere Kontobelastungen geschlossen.
    • RFD: Teilweise Gutschrift (einer bezahlten Bestellung). Die Transaktion bleibt für mögliche weitere Gutschriften geöffnet.
    • RFS: (Letzte) teilweise oder vollständige Gutschrift (einer bezahlten Bestellung). Nach dieser Gutschrift wird die Transaktion geschlossen.

    Bitte beachten Sie bei DEL und DES, dass nicht alle Akzeptanzpartner das Löschen einer Autorisierung unterstützen. Wenn Ihr Akzeptanzpartner DEL/DES nicht unterstützt, können wir dennoch die Löschung der Autorisierung im Back-Office simulieren.

    ORDERID

    Sie können die PAYID oder die orderID zur Identifikation der Originalbestellung senden. Wir empfehlen die Verwendung der PAYID.

    PAYID
    PSPID

    Anmeldedaten: PSPID und (API) USERID mit dem zur USERID gehörenden Passwort

    PSWD
    USERID
    SHASIGN Mit dem Secure Hash Algorithmus gehashte Zeichenfolge (siehe SHA-IN-Signatur)

    Ein Beispiel für eine direkte Datenpflegeanfrage (eine Testseite) finden Sie unter: https://ogone.test.v-psp.com/ncol/test/testdm.asp

    Beispiel einer XML-Antwort auf eine direkte Datenpflegeanfrage:

    <?xml version="1.0"?>

    <ncresponse orderID="99999" PAYID="1111111" PAYIDSUB="3" NCSTATUS="0" NCERROR="" NCERRORPLUS="" ACCEPTANCE="12345" STATUS="91" amount="125" currency="EUR"/>

    Die folgende Tabelle enthält eine Attributliste zum ncresponse-tag:

    Feld Nutzung
    ACCEPTANCE

    Vom Akzeptanzpartner zurückgesendeter Akzeptanzwert.

    AMOUNT

    Betrag der Bestellung (nicht mit 100 multipliziert).

    CURRENCY

    Währung der Bestellung.

    NCERROR

    Fehlerwert.

    NCERRORPLUS

    Erklärung des Fehlercodes.

    NCSTATUS

    Erste Ziffer von NCERROR.

    ORDERID

    Ihre Bestellnummer

    PAYID

    Bezahlungs-ID als Referenz in unserem System.

    PAYIDSUB

    Die PAYID der angewendeten Datenpflegeoperation auf Historien-Ebene

    STATUS

    Transaktionsstatus.

    Weitere technische Einzelheiten zu diesen Feldern finden Sie im Parameter Cookbook.

    Die Standardattribute des ncresponse-tags sind identisch mit denen der XML-Antwort auf eine neue Bestellung mit Ausnahme des zusätzlichen Attributs PAYIDSUB.

    Geht eine Datenpflegeanfrage für die gleiche Bestellung zweimal ein, wird die zweite theoretisch mit der Fehlermeldung „50001127" (Bestellung nicht autorisiert) abgelehnt, weil die erste erfolgreiche Transaktion den Bestellstatus geändert hat.

    Eine Direktabruf-Abfrage von Ihrer Applikation ermöglicht Ihnen, den Status einer Bestellung automatisch abzurufen (anstatt manuell im Back-Office). Sie können immer nur eine Zahlung gleichzeitig abrufen und erhalten nur in begrenztem Umfang Informationen über die Bestellung.

    Wenn Sie weitere Details über die Bestellung benötigen, können Sie die Transaktion im Back-Office aufrufen oder einem manuellen bzw. automatischen Dateidownload vornehmen (siehe hierzu Transaktionen Ansehen und Advanced Batch Integrationsleitfaden).

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

    Wichtig

    Vergessen Sie nicht, in der Anfrage-URL die Zeichenfolge „test" durch „prod" zu ersetzen, wenn Sie auf Ihr reguläres PRODUKTIVKONTO umstellen.

    Die folgende Tabelle enthält die obligatorischen Anfrageparameter für die Durchführung eines Direktabrufs:

    Feld
    Nutzung
    ORDERID

    Sie können die PAYID oder die ORDERID zur Identifikation der Originalbestellung senden. Wir empfehlen die Verwendung der PAYID.

    PAYID
    PAYIDSUB

    Sie können die ID der Historien-Ebene angeben, wenn Sie die PAYID zur Identifikation der Originalbestellung verwenden (optional).

    PSPID

    Anmeldedaten: PSPID und (API) USERID mit dem zur USERID gehörenden Passwort


    PSWD
    USERID

    Ein Beispiel für eine Direktabruf-Anfrage (eine Testseite) finden Sie unter: https://ogone.test.v-psp.com/ncol/test/testdq.asp.

    Unser Server sendet als Rückmeldung zur Anfrage eine XML-Antwort:

    Beispiel einer XML-Antwort auf eine Direktabruf-Anfrage:

    <?xml version=”1.0”?>
    <ncresponse orderID=”99999” PAYID=”1111111” PAYIDSUB=”3” NCSTATUS=”0” NCERROR=”” NCERRORPLUS=”” ACCEPTANCE=”12345” STATUS="9" ECI=”7” amount="125" currency="EUR" PM="CreditCard" BRAND="VISA" CARDNO="XXXXXXXXXXXX1111" IP="212.33.102.55"/>

    Die folgende Tabelle enthält eine Attributliste des ncresponse-tags:

    Feld
    Nutzung
    ACCEPTANCE Vom Akzeptanzpartner zurückgesendeter Akzeptanzwert.
    amount Betrag der Bestellung (nicht mit 100 multipliziert).
    BRAND Kartenmarke oder vergleichbare Informationen für andere Zahlungsmethoden.
    CARDNO Maskierte Kartennummer.
    currency Währung der Bestellung.
    ECI Electronic Commerce Indicator.
    IP IP-Adresse des Kunden, wie von unserem System in einer 3-Ebenen-Integration ermittelt oder uns vom Händler in einer 2-Ebenen-Integration gesendet.
    NCERROR Fehlerwert.
    NCERRORPLUS Erklärung des Fehlercodes.
    NCSTATUS Erste Ziffer von NCERROR.
    orderID Ihre Bestellnummer.
    PAYID Zahlungsreferenz in unserem System.
    PAYIDSUB Die PAYID der angewendeten Datenpflegeoperation auf Historien-Ebene.
    PM Zahlungsmethode.
    STATUS Transaktionsstatus

    Die Standardattribute des ncresponse-tags sind identisch mit denen für die XML-Antwort auf eine neue Bestellung mit Ausnahme der zusätzlichen Attribute PAYIDSUB, CARDNO und IP.

    Die Attributliste kann bei Händlern länger sein, die in ihren Konten bestimmte Optionen (z. B. das Betrugserkennungsmodul) aktiviert haben. Bitte lesen Sie in der Dokumentation der betreffenden Option weitere Informationen über zusätzliche Antwortattribute nach, die mit dieser Option verbunden sind.

    Wenn die Transaktion, deren Status Sie abrufen möchten, mit Gehostete Zahlungsseite verarbeitet wurde, erhalten Sie die folgenden zusätzlichen Attribute (vorausgesetzt, Sie haben mit der ursprünglichen Gehostete Zahlungsseite Transaktion diese Felder gesendet).

    Feld
    Nutzung
    COMPLUS
    Ein Wert, den Sie in der Antwort zurückgesendet bekommen wollten.
    (paramplus Inhalt)
    The parameters and their values you wanted to have returned

    Beispiel einer XML-Antwort auf den Direktabruf bezüglich einer Gehostete Zahlungsseite-Transaktion:

    <ncresponse orderID=”99999” PAYID=”1111111” PAYIDSUB=”3” NCSTATUS=”0” NCERROR=”” NCERRORPLUS=”” ACCEPTANCE=”12345” STATUS="9" amount="125" currency="EUR" PM="CreditCard" BRAND="VISA" CARDNO="XXXXXXXXXXXX1111" IP="212.33.102.55" COMPLUS="123456789123456789123456789" SessionID="126548354" ShopperID="73541312"/>

    Das Feld STATUS enthält den Status der Transaktion. Eine vollständige Liste der möglichen Statuszustände finden Sie im Back-Office: Support > Integrations & Benutzerhandbücher > Benutzerhandbücher > Liste der Status- und Fehlermeldungen.

    Nur der folgende Status bezieht sich speziell auf den Abruf selbst:

    StatusNCERRORNCSTATUS Description
    88

    Der Abruf an querydirect.asp ist fehlgeschlagen.

    Die Antwortzeit für die Anfrage bezüglich einer DirectLink Transaktion beträgt generell nur wenige Sekunden. Einige Akzeptanzpartner haben jedoch möglicherweise längere Antwortzeiten.

    Wenn Sie innerhalb von 30 Sekunden keine Antwort von unserem System erhalten haben, können Sie eine Anfrage an querydirect.asp senden, die den Status der gerade an orderdirect.asp gesendeten Transaktion abruft. Wenn Sie eine sofortige Antwort erhalten, die für die Transaktion einen noch nicht abgeschlossenen Status meldet, liegen eventuell Probleme auf Akzeptanzpartnerseite vor.

    Wenn Sie nach 10 Sekunden noch keine Antwort auf den Direktabruf erhalten haben, liegen eventuell Probleme auf unserer Seite vor. Sie können diese Anfrage an querydirect.asp alle 30 Sekunden wiederholen, bis Sie feststellen, dass eine Antwort innerhalb von 10 Sekunden bei Ihnen eintrifft.

    Bitte beachten Sie:

    1. Dieses Prüfsystem kann nur dann Probleme auf unserer Seite anzeigen, wenn gleichzeitig eine Prüfung auf Ihrer Seite sicherstellt, dass die Anfragen Ihre Server korrekt verlassen.
    2. Ein Problem auf unserer Seite ist nicht notwendigerweise durch einen Systemausfall begründet, sondern kann auch das Ergebnis langer Antwortzeiten aufgrund von Datenbankproblemen sein.
    3. Bitte nutzen Sie diese Prüfmöglichkeiten mit Zurückhaltung, um ein Dauerbelastung unserer Server mit derartigen Anfragen zu vermeiden. Andernfalls sind wir eventuell gezwungen, Ihren Zugriff auf die Seite querydirect.asp zu sperren.

    Wichtig

    Um unser System vor unnötiger Überlastung zu schützen, unterbinden wir Prüfungen der Systemverfügbarkeit, die mit dem Senden vorgetäuschter Transaktionen oder systematischer Anfragen sowie mit systematischen Anfragen verbunden sind, die für jede Transaktion eine Transaktionsrückmeldung erfordern.

    Nach Artikel 12, 13 und 14 DSGVO ist der Datenverantwortliche verpflichtet, seine Endkunden über die zukünftige Verarbeitung ihrer persönlichen Daten zu informieren. Diese Informationen sollten auf der Grundlage der Art der für eine bestimmte Transaktion einzugebenden persönlichen Daten (z.B.: gewählte Zahlungsmethode, Controller/Verarbeiter, Acquirer, Betrug) spezifiziert werden. Das Ergebnis sollte zum Zeitpunkt der Datenerhebung verfügbar und sichtbar sein und dem Karteninhaber mit einer druckbaren und herunterladbaren Version angeboten werden. Gemäß der Datenschutz-Grundverordnung (DSGVO) müssen Sie Ihren Kunden vor deren Transaktionsbestätigung diese Informationen darlegen. Diese Informationen sind idealerweise auf derselben Seite anzuzeigen, auf der Ihre Kunden ihre Kreditkarten-/Kontoangaben eingeben.
    Mit der folgenden Anfrage nach der Datenschutzrichtlinie erhalten Sie alle Informationen, die Sie Ihren Kunden für die Einhaltung der Datenschutz-Grundverordnung (DSGVO) über unsere Dienstleistungen anzeigen müssen.

    • Die URL-Anforderung in der TEST-Umgebung ist https://secure.ogone.com/ncol/test/privacy-policy.asp

    • Die URL-Anforderung in der PRODUKTIONS-Umgebung ist https://secure.ogone.com/ncol/prod/privacy-policy.asp
    „Test“ in "Prod“ ändern
    Ersetzen Sie „Test“ durch „Prod“ in der URL-Anforderung, wenn Sie zu Ihre Produktivkonto wechseln.

    In der folgenden Tabelle sind die obligatorischen Anforderungsparameter aufgelistet, die Ihren Kunden hinsichtlich der Nutzung ihrer Datenschutzinformationen übermittelt werden:

    Feld Format
    Beschreibung
    USERID Zeichenfolge Ihr API-Benutzer
    PSWD Zeichenfolge
    Ihr API-Benutzer-Password
    PSPID
    Zeichenfolge
    Ihre Konto-PSPID
    BRAND String (e.g. Visa) Optional: Zahlungsmethode Marke
    Sie können dieses Feld mehrmals übermitteln, um das Ergebnis mehrerer Marken zugleich zu erhalten.
    • Wird keine Marke übermittelt entspricht dies der Übermittlung aller Ihrer aktiven Marken
    • Leere/fehlerhaft formatierte Marken werden ignoriert
    LANGUAGE ISO 639-1: Zwei-Buchstaben-Codes (z.B. FR) Optional: Die Sprache, in der Sie den Text erhalten möchten.
    Wenn nicht angegeben, wird der Text in der ursprünglich eingestellten Sprache des Händlers angezeigt.

    Sie können direkte Query-Anforderungen hier testen: https://secure.ogone.com/ncol/test/privacy-policy.asp

    Im Folgenden finden Sie ein Verzeichnis von XML-Elementen und die zurückübermittelten XML-Antwortbeispiele für verschiedene Ergebnisse.

    Name Format Beschreibung
    Response Complex Root node, always present
    Response.Status String, possible values : Success, SuccessWithWarnings, Error Always present
    Response.Body Complex Present only when Response.Status = Success or SuccessWithWarnings
    Response.Body.Html String / html Empty if Response.Status = SuccessWithWarnings & Response.Warnings.Warning.Code = NoContent
    Response.Errors Complex Present only when Response.Status = Error
    Response.Errors.Error Complex Can occur multiple times inside an <Errors> node
    Response.Warnings Complex Present only when Response.Status = SuccessWithWarnings or Error
    Response.Warnings.Warning Complex Occurs multiple times inside a <Warnings> node
    Response.Errors.Error.Code
    Response.Warnings.Warning.Code
    String, possible values :
    •Inside an <Error> node : Unauthorized, InternalServerError
    •Inside a <Warning> node : NoContent

    Always present in an <Error> or <Warning> node
    Response.Errors.Error.Message
    Response.Warnings.Warning.Message
    String Optional

    Wird Ihnen Response.Status=Error ausgegeben, beziehen Sie sich bitte auf den Response.Errors.Error, um den Fehler zu beheben.
    Im Folgenden zwei erfolgreiche Beispiele:

    1. Beispiel einer XML-Antwort für einen Erfolg mit Warnungen. Wird zurückgegeben, wenn keine Datenschutzinformationen dem Kunden offengelegt werden müssen.

    <Response>
    <Status>SuccessWithWarnings</Status>
    <Warnings>
    <Warning>
    <Code>NoContent</Code>
    </Warning>
    </Warnings>
    <Body>
    <Html/>
    </Body>
    </Response>


    2. Beispiel einer XML-Antwort für einen Erfolg mit Inhalt. Das Beispiel zeigt eine in 2 Bereiche aufgeteilte Anzeige.

    <?xml version="1.0" encoding="utf-8"?>
    <Response>
    <Status>Success</Status>
    <Body>
    <Html><![CDATA[<ul><li><h2>Title 1</h2><p>Content 1</p></li><li><h2>Title 2 (VISA, American Express)</h2><p>Content 2</p></li></ul>]]></Html>
    </Body>
    </Response>

    Bei bestimmten Zahlungsmethoden weichen die Parameterwerte von den Kreditkarten-Standardwerten ab.

    Die folgende Tabelle enthält die spezifischen Parameterwerte, die eine Übertragung von Direct Debits AT Transaktionen via DirectLink erlauben.

    Format: AN=alphanumerisch / N=numerisch, die maximal erlaubte Anzahl der Zeichen
    Feld
    Beschreibung
    Format/Wert
    CARDNO

    Bankkontonummer

    AN, 21

    Format: XXXXXXXXXXXBLZYYYYY

    XXXXXXXXXXX: Kontonummer, numerisch, 11 Stellen.
    YYYYY: Bankleitzahl, 5 Stellen.
    CN Name des Karteninhabers AN, 35
    ED
    Verfallsdatum
    „99/99“ oder „9999“
    OPERATION

    Operationscode (Auszuführende Aktion)

    A, 3

    Mögliche Werte:

    • RES: Autorisierung (Reservierung)
    • SAL/SAS: Geld vom Bankkonto abbuchen
    • RFD/RFS: Gutschrift auf das Bankkonto (*)
    OWNERADDRESS Anschrift des Kontoinhabers AN, 50
    OWNERTOWN Wohnort des Bankkontoinhabers AN, 40
    OWNERZIP Kontoinhabers Postleitzahl AN, 10
    PM Zahlungsmethode AN, 25

    “Direct Debits AT”

    (* Falls die Gutschrift Option verfügbar und aktiv ist, und DTAUS-Gutschrift verfügbar ist)

    (* Falls die Gutschrift Option verfügbar und aktiv ist, und DTAUS-Gutschrift verfügbar ist)

    Die folgende Tabelle enthält die spezifischen Parameterwerte, welche die Übertragung von ELV-Transaktionen über DirectLink (not Wirecard/Billpay).

    Format: AN=alphanumerisch / N=numerisch, die maximal erlaubte Anzahl der Zeichen
    Feld
    Beschreibung Format/Wert
    Obligatorisch
    CARDNO
    Bankkontonummer

    IBAN: alphanumerische Zeichen

    ODER

    Bankkontonummer + BLZ. Format: XXXXXXXXXBLZYYYYYYYY
    XXXXXXXXXX: Kontonummer, numerisch, 1 bis 10 Stellen.
    YYYYYYYY: Bankleitzahl), 8 Stellen.
    J
    CN
    Name des Bankkontoinhabers
    AN, 35
    J
    ED
    Verfallsdatum
    „99/99“ oder „9999“ J
    MANDATEID
    Eindeutige Auftragsreferenz.
    Telego:
    Ohne Angabe übernimmt die Plattform die ORDERID oder PAYID
    Note: Ohne Angabe erstellt easycash einen Wert.

    Telego: AN, 35 / Zeichensatz: “A-Z a-z 0-9 Leerzeichen /-?:().,'+”
    Ohne Angabe übernimmt die Plattform die ORDERID oder PAYID

    Easycash: Format: AN, 27 / Zeichensatz: “A-Z a-z 0-9 Leerzeichen /-?:().,'+”
    Note: Ohne Angabe erstellt easycash einen Wert.

    N
    OPERATION
    Operationscode (Auszuführende Aktion)

    A, 3

    Mögliche Werte:

    • RES: Autorisierung
    • SAL/SAS: Einzug von Geld vom Bankkonto
    • RFD/RFS: Erstattung von Geld (*)
    N
    OWNERADDRESS
    Adresse des Kontoinhabers
    AN, 50 J
    OWNERTOWN
    Stadt/Ort des Kontoinhabers
    AN, 40 J
    OWNERZIP
    Postleitzahl des Kontoinhabers
    AN, 10 J
    PM
    Zahlungsmethode

    AN, 25

    "Direct Debits DE”

    J

    Note: Diese Felder können in der DirectLink XML-Antwort zurückgegeben werden und müssen in die SHA-IN-Berechnung eingeschlossen werden (optional auch SHA-OUT).

    (* Falls die Gutschrift Option verfügbar und aktiv ist, und DTAUS-Gutschrift verfügbar ist)

    Die folgende Tabelle enthält die spezifischen Parameterwerte, welche die Übertragung von Bankeinzug NL-Transaktionen (Direct Debits NL) über DirectLink ermöglichen.

    Format: AN=alphanumerisch / N=numerisch, die maximal erlaubte Anzahl der Zeichen
    Feld
    Beschreibung
    Format/Wert
    CARDNO
    Bankkontonummer
    Reguläre holländische Kontonummer: max. 10 alphanumerische Zeichen (falls weniger, links mit Nullen auffüllen).

    ODER

    IBAN-Kontonummer: max. 35 alphanumerische Zeichen (SEPA)

    CN
    Name des Bankkontoinhabers
    AN, 35
    ED
    Verfallsdatum
    „99/99“ oder „9999“
    OPERATION

    Operationscode (Auszuführende Aktion)

    A, 3

    Mögliche Werte:

    • SAL or SAS: Einzug von Geld vom Bankkonto
    • RFD or RFS: Gutschrift von Geld auf das Bankkonto (Erstattung)
    OWNERTOWN
    Stadt des Bankkontoinhabers
    AN, 40
    PM Zahlungsmethode

    AN, 25

    “Direct Debits NL”

    Nur relevant für SEPA-Transaktionen (*):
    BIC
    Bankidentifikationscode.
    AN, 11
    MANDATEID

    Eindeutige Auftragsreferenz.

    Note: Ohne Angabe wird die ORDERID verwendet.

    AN, 35

    Keine Leerzeichen; darf nicht mit einem Schrägstrich "/" beginnen oder enden, und darf keine zwei aufeinanderfolgende Schrägstriche enthalten.

    SEQUENCETYPE

    Typs der Bankeinzugstransaktion

    Note: Ohne Angabe wird die Transaktion als einmalig („OOFF“) betrachtet.

    Mögliche Werte zur Angabe des Typs der Bankeinzugstransaktion (AN, 4):
    • "FRST": Erste Sammlung einer Reihe von Bankeinzugsanweisungen
    • "RCUR": Bankeinzugsanweisungen, wobei die Autorisierung des Debitors für reguläre, vom Kreditor eingeleitete Bankeinzugstransaktionen verwendet wird
    • "FNAL": Letzte Sammlung einer Serie von Bankeinzugsansweisungen (danach kann dieselbe MandateID nicht mehr verwendet werden)
    • "OOFF": Bankeinzugsanweisung, wobei die Autorisierung des Debitors zur Einleitung einer einzelnen Bankeinzugstransaktion verwendet wird
    SIGNDATE

    Datum, an dem der Auftrag vom Kunden unterschrieben wurde.

    Note: Ohne Angabe wird das Transaktionsdatum verwendet

    JJJJMMTT

    (*SEPA: Single Euro Payments Area)

    Hinweis: Diese Felder können in der DirectLink XML-Antwort zurückgegeben werden und müssen in die SHA-IN-Berechnung (optional auch SHA-OUT) eingeschlossen werden.

    Bei bestimmten (nicht mit Kreditkarten verbundenen) Zahlungsmethoden können Sie keine neuen Transaktionen via DirectLink senden. Sie haben jedoch die Möglichkeit, bestimmte Datenpflegeanfragen via DirectLink zu senden. Dies ist der Fall bei: PostFinance Card, PostFinance e-finance, PayPal Express Checkout und TUNZ. Beim Senden einer Datenpflegeanfrage müssen PM/BRAND/CARDNO/ED nicht angegeben werden. Damit ist es auch nicht erforderlich, bestimmte Werte für diese Zahlungsmethoden zu senden.

    Allgemeine Informationen zu 3-D Secure v2 finden Sie in unserer Anleitung zu PSD2.

    Erfahren Sie hier, wie Sie 3-D Secure sicher in den Zahlungsprozess integrieren.

    Der Transaktionsfluss umfasst die folgenden Schritte:

    1. Ihr Kunde geht zu Ihren Checkout-Seiten und schließt den Einkauf auf der Zahlungsseite ab.
    2. Sie senden uns die Bestellinformationen und Zahlungsdetails über eine DirectLink-Anfrage zusammen mit einer Reihe zusätzlicher Parameter.
      • (2’) Optional: Wir führen eine Betrugsprüfung durch.
    3. Sie erhalten von unserer Plattform eine XML-Antwort. Jetzt sind zwei Szenarien möglich:
      • Wenn die Transaktion reibungslos verläuft, enthält die Antwort die Standardparameter  mit der endgültigen Transaktionsrückmeldung. Damit ist der Fluss beendet.
      • Wenn die Transaktion über den problematischen Fluss erfolgt, enthält die Antwort das zusätzliche Feld „HTML_ANSWER“ und einen bestimmten Zahlungsstatus (STATUS = 46). Das Feld „HTML_ANSWER“ enthält einen BASE-64-codierten Codeblock.
    4. Fügen Sie den entschlüsselten Codeblock zum Browser der Karteninhaber hinzu. Die Karteninhaber werden zur Authentifizierung automatisch an ihre emittierende Bank weitergeleitet.
    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 Gehostete Zahlungsseite -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 Gehostete Zahlungsseite-Modus.
    8. Wenn die Transaktion erfolgreich war, können Sie die Waren/Dienstleistungen versenden.

    DirectLink with 3-D Secure v2 transaction flowThis graph describes the DIRECTLINK (DPR/D3D) + Fraud transaction flow

    Ob die Haftungsumkehr gilt, hängt von Ihrem Acquirer-Vertrag ab. Daher empfehlen wir Ihnen, die Allgemeinen Geschäftsbedingungen Ihres Acquirers zu prüfen.

    Senden Sie für die Verarbeitung von Transaktionen mit 3-D Secure eine Reihe obligatorischer, empfohlener und optionaler Parameter an unsere Plattform.

    Diese Parameter müssen in die SHA-Berechnung einbezogen werden.

    Parameter erfassen und senden

    Sie müssen die 3DS-spezifischen obligatorischen, empfohlenen und optionalen Parameter auf der Zahlungsseite erfassen.

    Hier finden Sie einen Javascript-Codeblock, mit dem Sie die Browserinformationen erfassen können.

    <script type="text/javascript" language="javascript">
    function createHiddenInput(form, name, value)
    {
    var input = document.createElement("input");
    input.setAttribute("type", "hidden");
    input.setAttribute("name", name);
    input.setAttribute("value", value);
    form.appendChild(input);
    }

    var myCCForms = document.getElementsByName("MyForm");
    if (myCCForms != null && myCCForms.length > 0)
    {
    var myCCForm = myCCForms[0];
    createHiddenInput(myCCForm, "browserColorDepth", screen.colorDepth);
    createHiddenInput(myCCForm, "browserJavaEnabled", navigator.javaEnabled());
    createHiddenInput(myCCForm, "browserLanguage", navigator.language);
    createHiddenInput(myCCForm, "browserScreenHeight", screen.height);
    createHiddenInput(myCCForm, "browserScreenWidth", screen.width);
    createHiddenInput(myCCForm, "browserTimeZone", new Date().getTimezoneOffset());
    }
    </script>

    Senden Sie diese 3-D Secure-spezifischen Parameter zusammen mit den anderen obligatorischen DirectLink-Parametern. Unsere Plattform wird Ihre Anfrage bearbeiten und Ihnen antworten.

    Abgelehnte Transaktionen nachvollziehen

    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. This information might also help you to recover the transaction using our Soft Decline feature.

    Damit Sie CH_AUTHENTICATION_INFO sowohl in der XML-Antwort als auch 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 und DirectLink > Dynamische parameter aus. Dadurch wird außerdem sichergestellt, dass diese Informationen in der Transaktionsübersicht unter Vorgänge > Transaktionsansicht / Finanzielle Historie sichtbar sind.

    Verwenden Sie CH_AUTHENTICATION_INFO für die folgenden Szenarien:

    • Wenn die Transaktion über den reibungslosen Fluss verarbeitet wird, enthält unsere XML-Antwort diesen Parameter. Fügen Sie die Informationen entsprechend zu Ihrer Transaktionsergebnisseite hinzu.
    • Wenn die Transaktion über den problematischen Fluss verarbeitet wird, erhalten Sie diesen Parameter über die Feedbackkanäle des Modus Gehostete Zahlungsseite. 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 Ingenico ePayments 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.

    Beachten Sie, dass nicht alle Emittenten Informationen darüber freigeben, warum sie Transaktionen ablehnen. Deshalb ist CH_AUTHENTICATION_INFO in manchen Fällen leer.

    Simulieren Sie in unserer Testumgebung mit diesen Kartennummern eine Emittentenantwort:
    Amex: 349586710563469
    MasterCard: 5111823134937549
    Visa: 4010759044222272

    Antwort der Plattform verarbeiten

    Wenn die Transaktion reibungslos verläuft, enthält die Antwort die Standardparameter  mit der endgültigen Transaktionsrückmeldung. Damit ist der Fluss beendet.

    Wenn die Transaktion über den problematischen Fluss erfolgt, enthält die Antwort zusätzliche Parameter. Um die Authentifizierung für Ihre Kunden bereitzustellen, müssen Sie die zusätzlichen Daten wie hier beschrieben verarbeiten:

    Feld Beschreibung
    STATUS Neuer Wert: „46“ (wartet auf Identifizierung)
    HTML_ANSWER

    Ein BASE64-codierter HTML-Code, der auf der an den Kunden zurückgegebenen HTML-Seite hinzugefügt werden soll.

    Dieses Tag wird als untergeordnetes Element des globalen XML-Tags <ncresponse> hinzugefügt. Das Feld „HTML_Answer“ enthält HTML-Code, der auf der HTML-Seite hinzugefügt werden muss und an den Browser des Kunden zurückgegeben wird.

    Dieser Code lädt abhängig vom WIN3DS-Parameterwert automatisch die Identifikationsseite der Emittentenbank in ein Pop-up im Hauptfenster.

    Um Interferenzen zwischen den im Inhalt des Tags „HTML_ANSWER-XML“ enthaltenen HTML-Tags zu vermeiden und den Rest des XML als Antwort auf die DirectLink-Anforderung zurückzugeben, wird der HTML_ANSWER-Inhalt von unserem System BASE64-codiert, bevor die Antwort zurückgegeben wird. Folglich muss dies BASE64 DEcodiert sein, bevor es in die an den Karteninhaber gesendete HTML-Seite aufgenommen wird.

    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 Gehostete Zahlungsseite-Modus.

    Wenn die Identifizierung erfolgreich war, übermitteln wir die tatsächliche Finanztransaktion an den Acquirer.

    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 Gehostete Zahlungsseite-Modus.

    9.3 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

    9.4 Ausschlüsse von der 3DSv2-Regel

    Einige Transaktionen sind von PSD2 ausgeschlossen. Wenn eine Ihrer Transaktionen dazu gehört, wird 3-D Secure nicht ausgeführt. Dies gilt auch für wiederkehrende Transaktionen, die Sie initiieren. Um diese sogenannten vom Händler initiierten Transaktionen (MIT) als solche zu kennzeichnen, müssen Sie zusätzliche Parameter an unsere Plattform senden.

    Sie können das Auslassen von 3-D Secure bei einem der beiden Schritte anfragen


    Wählen Sie immer nur eine dieser Optionen, wenn Sie Transaktionen erstellen, da sich beide Optionen gegenseitig ausschließen.

    Reibungsloser/problematischer Fluss und Angabe des bevorzugten Flusses

    Sie können die Wahrscheinlichkeit, dass SCA übersprungen wird (was zu einem reibungslosen Fluss führt), durch das Senden von diesem Parameter erhöhen.

    Abhängig von Ihrer Einschätzung des Betrugsrisikos können Sie bestimmte Werte senden (also für eine Bewertung mit geringem Risiko: 02, für ein erhöhtes Betrugsrisiko: 03.

    Obligatorisch (falls ein Flow bevorzugt wird)

    Parameter
    Werte
    Mpi.threeDSRequestorChallengeIndicator

    Länge: 2 Zeichen
    Datentyp: String
    Gültige Werte:

    • 01 = Keine Präferenz
    • 02 = Keine Abfrage angefordert
      03 = Abfrage angefordert; Händlerpräferenz
    • 04 = Abfrage angefordert; Mandat
    • 05 = Keine Abfrage angefordert [Transaktionsrisikoanalyse wird bereits durchgeführt]
    • 06 = Keine Abfrage angefordert [nur Datenfreigabe]
    • 07 = Keine Abfrage angefordert [SCA wird bereits durchgeführt]
    • 80-99 = Reserviert für DS-Nutzung

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

    Ausnahmen von 3DS

    Senden Sie diese Parameter, um die 3D-Sicherheit insgesamt zu überspringen:

    Parameter
    Werte
    FLAG3D N = Überspringen des 3DS-Authentifizierungsprozesses
    3DS_EXEMPTION_INDICATOR

    Angabe einer Begründung für das Überspringen von 3DS. Die numerischen Werte können je nach Transaktion zutreffend sein

    03 = Herausgeber TRA*
    04 = Ausnahme für einen geringen Betrag
    05 = Händler/Erwerber TRA*
    06 = Auf die weiße Liste setzen
    07 = Unternehmen
    08 = Verspäteter Versand
    09 = Delegierte Authentifizierung (zertifiziertes Wallet)

    * Transaction risk analysis

    * Analyse des Transaktionsrisikos

    Es bleibt jedoch dem Herausgeber überlassen, ob ein Authentifizierungsprozess stattfinden muss. Falls der Herausgeber auf 3DS besteht, wird die Transaktion abgelehnt.

    Wichtig

    Transaktionen, für die 3-D Secure übersprungen werden soll, können nur als Berechtigungen verarbeitet werden (die bei Erfolg den Status 5 erhalten). Um die Mittel für diese Transaktionen zu erhalten, müssen Sie sie zu einem späteren Zeitpunkt erfassen. Die erfolgreich erfasste Transaktion erreicht den Status 9.

    Soft Decline

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

    1. Bei Ihrer ersten Anfrage senden Sie nur FLAG3D=N und keine 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 parameters, wie sie in Ihrer ersten Anfrage als neue e-Commerce- oder DirectLink-Bestellung gesendet wurden
      2. FLAG3D=Y, um anzuzeigen, dass 3-D Secure eingeführt werden muss
      3. Die 3DSv2-Authentifizierungsparameter as described here
      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.

    9.5 Von 3-D Secure 2.1 zu 2.2 wechseln

    Die kommende neue Version von 3-D Secure (Version 2.2) bietet Ihnen noch mehr Möglichkeiten, Ihre Integration zu optimieren.

    Für das aktuelle 3D-Secure 2.1 ist dieser Parameter noch optional. Sobald Version 2.2 verfügbar ist, ist er jedoch obligatorisch. Wenn Sie den Parameter bereits jetzt implementieren, ist ein reibungsloser Wechsel von Version 2.1 zu Version 2.2 garantiert.

    Parameter Werte

    BROWSERJAVASCRIPTENABLED

    Dieser Boolesche Wert gibt an, ob Ihre Kunden bei einer Bestellung in ihren Browsern JavaScript aktiviert haben.

    Abhängig vom Wert des Parameters trifft folgendes zu:

    • TRUE: Diese Parameter bleiben obligatorisch:

      BROWSERJAVAENABLED
      BROWSERSCREENHEIGHT
      BROWSERSCREENWIDTH
      BROWSERTIMEZONE
      BROWSERACCEPTHEADER
      BROWSERUSERAGENT
      BROWSERLANGUAGE

    • FALSE: Diese Parameter sind nicht mehr obligatorisch:
      BROWSERCOLORDEPTH
      BROWSERJAVAENABLED
      BROWSERSCREENHEIGHT
      BROWSERSCREENWIDTH
      BROWSERTIMEZONE

      Diese Parameter bleiben obligatorisch:

      BROWSERACCEPTHEADER
      BROWSERUSERAGENT
      BROWSERLANGUAGE

    Datentyp: Boolean

    Gültige Werte:
    • TRUE
    • FALSE

    Wenn Sie diesen Parameter nicht senden, wird dieser Wert abhängig von den anderen verfügbaren Parametern vorab ausgefüllt.

    Zusätzlich zu dem Parameter BROWSERJAVASCRIPTENABLED bietet 3-D Secure 2.2 erweiterte/neue Parameter, damit Ihre Transaktionen noch sicherer werden:

    3DSv1 ist das erste dreidimensionale Sicherheitsprotokoll der Kartenschemata, das durch v2 ersetzt wurde. Wenn Sie v2 implementiert haben, gilt dieser Abschnitt nicht für Sie.

    Wir empfehlen Ihnen dringend, Ihre Implementierung an die Anforderungen von v2 anzupassen. Wenn Sie jedoch noch nicht bereit sind, finden Sie hier die Anweisungen zur Implementierung von v1

    DirectLink 3-D Secure v1-Transaktionsfluss

    Der Transaktionsfluss umfasst diese Schritte:

    1. Ihr Kunde geht zu Ihren Checkout-Seiten und schließt den Einkauf auf der Zahlungsseite ab.
    2. Sie senden uns die Bestellinformationen und Zahlungsdetails über eine DirectLink-Anfrage zusammen mit einer Reihe zusätzlicher Parameter.
      • (2’) Optional: Wir führen eine Betrugsprüfung durch.
    3. Sie erhalten von unserer Plattform eine XML-Antwort.
      • Wenn die Karte Ihres Kunden nicht für 3-D Secure registriert ist, enthält die Antwort die Standardparameter mit der endgültigen Transaktionsrückmeldung.
      • Wenn die Karte Ihres Kunden für 3-D Secure registriert ist, enthält die Antwort das zusätzliche Feld „HTML_ANSWER“ und einen bestimmten Zahlungsstatus (STATUS = 46). Das Feld „HTML_ANSWER“ enthält einen BASE-64-codierten Codeblock.
    4. Fügen Sie den entschlüsselten Codeblock zum Browser der Karteninhaber hinzu. Die Karteninhaber werden zur Authentifizierung automatisch an ihre emittierende Bank weitergeleitet.
    5. Die Karteninhaber identifizieren sich. Unser System erhält das Ergebnis vom Emittenten.
    6. Two scenarios are possible
      • 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 Gehostete Zahlungsseite-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 leiten wir den Karteninhaber entweder an „ACCEPTURL“, „DECLINEURL“ oder „EXCEPTIONURL“ weiter. Sie erhalten das Ergebnis über Feedback-Kanäle im Gehostete Zahlungsseite-Modus.
    8. Wenn die Transaktion erfolgreich war, können Sie die Waren/Dienstleistungen versenden.
    Ob die Haftungsumkehr gilt, hängt von Ihrem Acquirer-Vertrag ab. Daher empfehlen wir Ihnen, die Allgemeinen Geschäftsbedingungen Ihres Acquirers zu prüfen.

    3-D Secure v1-Anfrage senden

    Senden Sie für die Verarbeitung von Transaktionen mit 3-D Secure eine Reihe obligatorischer und optionaler Parameter an unsere Plattform.

    Die Tabelle gibt Ihnen einen Überblick über die verschiedenen Parameter und deren Zweck für den Authentifizierungsprozess.

    Diese Parameter müssen in die SHA-Berechnung einbezogen werden.

    Parameter category Parameter Name / Beschreibung
    Pflichtparameter.

    FLAG3D

    Fester Wert: "Y"

    Weist unser System an, bei Bedarf 3-D Secure-Identifikation auszuführen.

    HTTP_ACCEPT*

    Das Feld „Accept request header“ im Browser des Karteninhabers, mit dem angegeben wird, welche Medientypen für die Antwort angenommen werden können. Mit diesem Wert kontrolliert der Aussteller, ob der Browser des Karteninhabers mit dem Identifikationssystem des Ausstellers kompatibel ist. *
    Zum Beispiel:
    Accept: */*

    HTTP_USER_AGENT*

    Dieser Parameter wurde ersetzt durch browserUserAgent. Senden Sie diesen nicht, wenn Sei bereits browserUserAgent.

    Das Feld „User-Agent request-header“ im Browser des Karteninhabers mit Informationen über den User Agent, von dem die Anfrage ausgeht. Mit diesem Wert kontrolliert der Aussteller, ob der Browser des Karteninhabers mit dem Identifikationssystem des Ausstellers kompatibel ist. *
    Zum Beispiel: User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0).

    ACCEPTURL

    URL der Webseite, die dem Kunden angezeigt wird, wenn die Zahlung autorisiert ist.

    DECLINEURL

    URL, an die der Kunde weitergeleitet wird, wenn die maximale Anzahl an fehlgeschlagenen Autorisierungsversuchen erreicht ist (Standardwert 10, er kann aber auf der Seite „Technische Informationen“, Registerkarte „Globale Transaktionsparameter“, Abschnitt „Zahlungswiederholungsversuche“ geändert werden).

    EXCEPTIONURL

    URL der Webseite, die dem Kunden angezeigt wird, wenn das Zahlungsergebnis unsicher ist.

    LANGUAGE

    Sprache des Kunden, zum Beispiel: "en_US"

    Optionale

    TP

    Um das Layout der "order_A3DS"-Seite zu ändern, können Sie eine(n) Templatenamen/-URL mit diesem Parameter senden.
    e-Commerce: Dynamische Vorlage).

    PARAMPLUS

    Field to submit the miscellaneous parameters and their values that you wish to be returned in the post-sale request or final redirection.

    COMPLUS

    Field to submit a value you wish to be returned in the post-sale request or output.

    WIN3DS

    Möglichkeit, dem Kunden die Identifikationsseite anzuzeigen. Mögliche Werte:

    • MAINW: Die Identifikationsseite im Hauptfenster anzeigen (Standardwert).
    • POPUP: Die Identifikationsseite in einem Popup-Fenster anzeigen und am Ende zum Hauptfenster zurückkehren.
    • POPIX: Die Identifikationsseite in einem Popup-Fenster anzeigen und im Popup-Fenster bleiben.

    Nach dem Senden dieser Parameter wird unsere Plattform Ihre Anfrage bearbeiten und Ihnen antworten.

    Antwort der Plattform verarbeiten

    Wenn die Karte Ihres Kunden nicht für 3-D Secure registriert ist, enthält die Antwort die Standardparameter  mit der endgültigen Transaktionsrückmeldung. Damit ist der Fluss beendet.

    Wenn die Karte Ihres Kunden für 3-D Secure registriert ist, enthält die Antwort zusätzliche Parameter. Um die Authentifizierung für Ihre Kunden bereitzustellen, müssen Sie die zusätzlichen Daten wie hier beschrieben verarbeiten:

    Field Beschreibung
    STATUS Neuer Wert: "46" (Warten auf Identifikation)
    HTML_ANSWER

    BASE64-codierter HTML-Code zum Einfügen auf der HTML-Seite, die an den Kunden zurückgegeben wird.

    Dieser Tag wird als untergeordnetes Element des globalen XML-Tags <ncresponse> hinzugefügt. Das Feld HTML_ANSWER enthält HTML-Code, der in die HTML-Seite, die an den Kunden zurückgegeben wird, eingefügt werden muss.

    Dieser Code lädt automatisch die Identifikationsseite der ausstellenden Bank in einem Pop-up im Hauptfenster in Abhängigkeit vom Parameterwert WIN3DS.

    Damit es nicht zu Wechselwirkungen zwischen HTML-Tags im Inhalt des XML-Tags HTML_ANSWER mit dem übrigen XML-Code kommt, der als Antwort auf die DirectLink-Anfrage ausgegeben wird, wird der Inhalt von HTML_ANSWER vor Ausgabe der Antwort BASE64-codiert. Deshalb muss dieser Inhalt BASE64-decodiert werden, bevor er in die HTML-Seite, die an den Karteninhaber gesendet wird, eingefügt wird.

    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 Gehostete Zahlungsseite-Modus.

    Wenn die Identifizierung erfolgreich war, übermitteln wir die tatsächliche Finanztransaktion an den Acquirer.

    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 Gehostete Zahlungsseite-Modus.

    Testkarten

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

    Marke Kartenummer Ablaufdatum Passwort
    VISA 4000000000000002 Beliebiges Datum in der Zukunft 1111
    MasterCard 5300000000000006 Beliebiges Datum in der Zukunft 11111
    American Express 371449635311004 Beliebiges Datum in der Zukunft 11111

    More test cards numbers can be downloaded here.

    If a transaction is blocked due to incorrect identification, the transaction result will be:

    STATUS = 2

    NCERROR = 40001134

    9.7 Ü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.

    Häufig gestellte Fragen

    In Ihrem Ingenico ePayments-Konto können Sie Ihre Transaktionen ganz einfach nachschlagen. Dazu wählen Sie „Vorgänge“ und klicken dann je nach Art der gesuchten Transaktionsergebnisse entweder auf „Transaktionsansicht“ oder „Finanzielle Historie“ klicken.

    Weitere Informationen finden Sie unter „Transaktionen Ansehen“ einsehen.


    Standardmäßig können Sie Waren abschicken oder Dienstleistungen erbringen, sobald eine Transaktion den Status „5 – Authorised“ (Autorisiert) oder „9 – Payment requested“ (Zahlung angefordert) erreicht hat. Auch wenn Status 5 eine Erfolgsmeldung darstellt, meldet er nur die vorübergehende Reservierung eines Geldbetrags auf der Karte des Kunden. Eine Transaktion mit Status 5 muss noch bestätigt werden (manuell oder automatisch), um in den Status 9 zu gelangen, der für die meisten Zahlungsverfahren der finale Erfolgsstatus ist.


    Unter Status der Transaktionen finden Sie weitergehende Informationen.





    Mit der Schaltfläche „Rückerstattung“ in der Auftragsübersicht einer Transaktion (unter „Transaktionsansicht“) können Sie eine Zahlung ganz einfach rückerstatten. Wenn Ihr Konto es unterstützt, können Sie auch Rückerstattungen mit einer DirectLink-Anfrage oder durch Hochladen einer Batchdatei (für mehrere Transaktionen)) durchführen. .
    Bitte beachten Sie, dass die Option „Rückerstattungen“ in Ihrem Konto aktiviert sein muss. 

    Weitere Informationen finden Sie unter Ihre Transaktionen verwalten.



    Falls Sie bestimmte Details eines Auftrags bzw. einer Transaktion überprüfen oder Transaktionen verwalten möchten, sollten Sie „Transaktionsansicht“ verwenden. Mit Hilfe von „Finanzielle Historie“ lassen sich ein- und ausgehende Gelder am bequemsten regelmäßig überprüfen. 
    Weitere Informationen finden Sie unter Transaktionsansicht vs- Finanzielle Historie

     

    Rückerstattungen können Sie nur für Transaktionen durchführen, bei denen Sie den Status 9 seit mindestens 24 Stunden haben. Eine Stornierung oder Löschung kann innerhalb ca. 24 Stunden erfolgen nachdem die Transaktion den Status 5 oder 9 hat. 
    Wenn Sie den Annahmeschluss des Akzeptanzpartner erfahren möchten, empfehlen wir Ihnen, dass Sie sich direkt an unseren Kundendienst wenden.