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. Show
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.  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.
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. 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 folgende Tabelle enthält die Anfrageparameter für das Senden einer neuen Bestellung: Format: AN=alphanumerisch / N=numerisch, die maximal erlaubte Anzahl der Zeichen
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 folgenden Parameter sind in neuen Bestellungen obligatorisch:
3.3 TestseiteEin Beispiel für eine Bestellanfrage (eine Testseite) finden Sie unter https://e-payment.postfinance.ch/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:
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.
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!).
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.
Unser Server sendet als Rückmeldung zur Anfrage eine XML-Antwort:
Die folgende Tabelle enthält eine Attributliste zum ncresponse-tag:
5. Direkte Datenpflege: Pflege bestehender BestellungsdatenEine direkte Datenpflegeanfrage von ihrer Applikation aus ermöglicht Ihnen:
5.1 Datenpflege-Anfrage
Die folgende Tabelle enthält die obligatorische Aufforderung Parameter zur Durchführung einer Wartungsarbeit:
5.1.3 TestseiteEin Beispiel für eine direkte Datenpflegeanfrage (eine Testseite) finden Sie unter: https://e-payment.postfinance.ch/ncol/test/testdm.asp 5.2 Datenpflege-Antwort
Die folgende Tabelle enthält eine Attributliste zum ncresponse-tag:
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 folgende Tabelle enthält die obligatorischen Anfrageparameter für die Durchführung eines Direktabrufs:
6.1.3 TestseiteEin Beispiel für eine Direktabruf-Anfrage (eine Testseite) finden Sie unter: https://e-payment.postfinance.ch/ncol/test/testdq.asp. Unser Server sendet als Rückmeldung zur Anfrage eine XML-Antwort:
Die folgende Tabelle enthält eine Attributliste des ncresponse-tags:
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 e-Commerce verarbeitet wurde, erhalten Sie die folgenden zusätzlichen Attribute (vorausgesetzt, Sie haben mit der ursprünglichen e-Commerce Transaktion diese Felder gesendet).
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:
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:
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://e-payment.postfinance.ch/ncol/test/privacy-policy.asp • Die URL-Anforderung in der PRODUKTIONS-Umgebung ist https://e-payment.postfinance.ch/ncol/prod/privacy-policy.asp„Test“ in "Prod“ ändernErsetzen 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:
7.1.3 TestseiteSie können direkte Query-Anforderungen hier testen: https://e-payment.postfinance.ch/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.
Wird Ihnen Response.Status=Error ausgegeben, beziehen Sie sich bitte auf den Response.Errors.Error, um den Fehler zu beheben.
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> 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:
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 sendenSie 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 nachvollziehenPSD2 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:
Antwort der Plattform verarbeitenWenn 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:
Wenn die Identifizierung nicht erfolgreich war, leiten wir den Karteninhaber an „DECLINEURL“ weiter und beenden den Fluss. Sie erhalten das Ergebnis über Feedback-Kanäle im e-Commerce-Modus. Wenn die Identifizierung erfolgreich war, übermitteln wir die tatsächliche Finanztransaktion an den Acquirer. Abhängig vom Ergebnis des Acquirers leiten wir den Karteninhaber entweder an „ACCEPTURL“, „DECLINEURL“ oder „EXCEPTIONURL“ weiter. Sie erhalten das Ergebnis über Feedback-Kanäle im e-Commerce-Modus. 8.3 TestkartenMit den folgenden Testkarten können Sie eine registrierte 3-D Secure-Karte in unserer Testumgebung simulieren:
8.4 Ausschlüsse von der 3DSv2-RegelEinige 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:
Authentifizierung im Hintergrund / Aktive AuthentifizierungWenn 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.
Sie können sogar die Wahrscheinlichkeit eines reibungslosen Flusses und einer höheren Konversionsrate durch das Senden von mehr optionalen Parameter erhöhen. Soft DeclineEin typischer Ablauf einer solchen „soft declined“-Transaktion sieht folgendermaßen aus:
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
8.5 Von 3-D Secure 2.1 zu 2.2 wechselnDie kommende neue Version von 3-D Secure (Version 2.2) bietet Ihnen noch mehr Möglichkeiten, Ihre Integration zu optimieren.
Zusätzlich zu dem Parameter BROWSERJAVASCRIPTENABLED bietet 3-D Secure 2.2 erweiterte/neue Parameter, damit Ihre Transaktionen noch sicherer werden: 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.
Nach dem Senden dieser Parameter wird unsere Plattform Ihre Anfrage bearbeiten und Ihnen antworten. Antwort der Plattform verarbeitenWenn 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:
Wenn die Identifizierung nicht erfolgreich war, leiten wir den Karteninhaber an „DECLINEURL“ weiter und beenden den Fluss. Sie erhalten das Ergebnis über Feedback-Kanäle im e-Commerce-Modus. Wenn die Identifizierung erfolgreich war, übermitteln wir die tatsächliche Finanztransaktion an den Acquirer. Abhängig vom Ergebnis des Acquirers leiten wir den Karteninhaber entweder an „ACCEPTURL“, „DECLINEURL“ oder „EXCEPTIONURL“ weiter. Sie erhalten das Ergebnis über Feedback-Kanäle im e-Commerce-Modus. TestkartenMit den folgenden Testkarten können Sie eine registrierte 3-D Secure-Karte in unserer Testumgebung simulieren:
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
(* 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
(* 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
(*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. 9.2 PM nur mit Datenpflege möglich über DirectLinkBei 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.
|
Wo finde ich den swift code postfinance
Pos Terkait
Copyright © 2024 ketiadaan Inc.
