Sie benötigen ein Benutzerkonto mit der Rolle "Webservices JWT", um das Token zu erstellen. Das Token sollte auf Ihrem Server erstellt und signiert werden.
Wenn dieses Benutzerkonto noch nicht vorhanden ist, fordern Sie es bitte bei unserem Support-Team für Ihre Website(s) an.
Die jwt Das in das Formular eingegebene Feld muss in Form eines JSON Web Token (JWT) vorliegen, das aus verschlüsselten Daten besteht.
JSON Web Tokens sind eine offene, dem Industriestandard RFC 7519 entsprechende Methode zur sicheren Übertragung von Daten zwischen zwei Parteien.
Wir empfehlen die Verwendung der Bibliotheken, die Sie unter https://jwt.io finden, um das JWT zu erzeugen.
Die JWT-Erstellung muss auf Ihrem Backend-Server erfolgen, um zu vermeiden, dass sensible Details (z. B. das JWT-Signierungsgeheimnis) offengelegt werden.
In seiner kompakten Form besteht JWT aus drei Teilen, die durch Punkte (".") getrennt sind, nämlich:
<header>.<payload>.<signature>
Generierung der header
Die header besteht aus zwei Teilen:
- alg - Der verwendete Signieralgorithmus (wir unterstützen "HS256", "HS384" und "HS512").
- typ - Der Typ des Tokens, d. h. "JWT".
Diese müssen mit Base64URL kodiert sein, um den ersten Teil des JWT zu bilden. Beispiel:
- Header - {“alg”:”HS256″,”typ”:”JWT”}
- Encoded - eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
Wichtig: Die übermittelten Daten müssen mit Base64Url kodiert sein, nicht mit dem Standard Base64.
Generierung der payload
Bitte beachten Sie bei der Eingabe von Feldern in die payload die folgenden Empfehlungen:
- Die payload sollte enthalten alle Felder die Sie dem Kunden nicht erlauben wollen zu ändern (z.B. den Transaktionsbetrag).
- Die payload sollte nicht alle Felder enthalten, die der Kunde während der Kaufabwicklung ändern darf (z. B. seine Adresse oder Kontaktdaten).
Diese Felder werden dann mit Base64URL kodiert und bilden den zweiten Teil des JWT. Beispiel:
{
"payload":{
"accounttypedescription":"ECOM",
"baseamount":"1050",
"currencyiso3a":"GBP",
"sitereference":"test_site12345",
"termurl":"https://payments.securetrading.net/process/payments/mobilesdklistener",
"requesttypedescriptions":["THREEDQUERY","AUTH"]
},
"iat":1559033849,
"iss":"jwt.user"
}
eyJwYXlsb2FkIjp7ImFjY291bnR0eXBlZGVzY3JpcHRpb24iOiJFQ09NIiwiYmFzZWFtb3VudCI6IjEwNTAiLCJjdXJyZW5jeWlzbzNhIjoiR0JQIiwic2l0ZXJlZmVyZW5jZSI6InRlc3Rfc2l0ZTEyMzQ1IiwidGVybXVybCI6Imh0dHBzOi8vcGF5bWVudHMuc2VjdXJldHJhZGluZy5uZXQvcHJvY2Vzcy9wYXltZW50cy9tb2JpbGVzZGtsaXN0ZW5lciIsInJlcXVlc3R0eXBlZGVzY3JpcHRpb25zIjpbIlRIUkVFRFFVRVJZIiwiQVVUSCJdfSwiaWF0IjoxNTU5MDMzODQ5LCJpc3MiOiJqd3QudXNlciJ9
Die baseamount Feld in der Tabelle payload Das obige Beispiel enthält einen Wert, der in Basiseinheiten angegeben wurde. Das bedeutet, dass der Wert ohne Dezimalpunkt angegeben wird, d.h. £10,50 würden als "1050" angegeben werden.
Wir ermöglichen Ihnen stattdessen die Übermittlung der mainamount hier, falls gewünscht. In diesem Fall wird der Wert in Haupteinheiten angegeben (£10,50 würde als "10.50" angegeben - beachten Sie das Dezimalkomma).
Generierung der signature
Der letzte Teil des Tokens ist die signature. Die signature wird verwendet, um sicherzustellen, dass das Token nicht vom Kunden geändert wurde, bevor das abgeschickte Formular Trust Payments erreicht.
Die signature wird erstellt, indem die verschlüsselte header, die verschlüsselte payload, a "secret" und dem in der Option Algorithmus angegebenen Algorithmus header, und sie dann zu unterschreiben.
Die "secret" ist eine geheime Passphrase (im String-Format), die Sie zum Signieren des JWT verwenden müssen. Dies muss sein mit unserem Support-Team vereinbart vor der Bearbeitung von Anfragen an unser System.
Bei der Speicherung des Wertes des Feldes "secret" auf Ihrem System zu installieren, müssen Sie sicherstellen, dass Sie dies auf sichere Weise tun.
Der Wert der "secret" darf nicht im Klartext in der App selbst gespeichert werden.
Beispiel - Wenn Sie den HMAC SHA256-Algorithmus verwenden möchten, muss die signature würde auf folgende Weise erstellt werden:
HMACSHA256(
base64UrlEncode(header) + "." +
base64UrlEncode(payload),
secret)
Der letzte Schritt ist die Sicherstellung der signature ist Base64URL-kodiert.
Das Signieren von Token mit einem privaten Schlüssel wird nicht unterstützt.
Vollständiges JWT-Beispiel
Das Ergebnis sind drei durch Punkte (".") getrennte Base64URL-Strings:
Wenn wir die header, die payload und die signature aus den obigen Beispielen würden Sie folgende JWT erhalten:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJqd3QudXNlciIsImlhdCI6MTU5NDY0NzI2OCwicGF5bG9hZCI6eyJiYXNlYW1vdW50IjoxMDUwLCJjdXJyZW5jeWlzbzNhIjoiR0JQIiwic2l0ZXJlZmVyZW5jZSI6InRlc3Rfc2l0ZTEyMzQ1IiwiYWNjb3VudHR5cGVkZXNjcmlwdGlvbiI6IkVDT00ifX0.A6gAnUq2NCSlIiLOcDyzhuo4E8Bm5oPWSKbkjOKKHhc
Das vollständige Token kann dann bei der Initialisierung der Bibliothek angegeben werden.
Überprüfung der JWT-Signatur der Antwort
Das Ergebnis der verarbeiteten Anfrage wird in Form eines neuen JWTs zurückgegeben. Es folgt ein Beispiel für eine Antwort, die von Trust Payments zurückgegeben wird:
(Antwort JWT)
"jwt":"eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpYXQiOjE1OTQ2NDcyNjgsInBheWxvYWQiOnsicmVxdWVzdHJlZmVyZW5jZSI6Ilc1Ni11YWN3bTU0ayIsInZlcnNpb24iOiIxLjAwIiwiand0IjoiZXlKaGJHY2lPaUpJVXpJMU5pSXNJblI1Y0NJNklrcFhWQ0o5LmV5SnBjM01pT2lKcWQzUXVkWE5sY2lJc0ltbGhkQ0k2TVRVNU5EWTBOekkyT0N3aWNHRjViRzloWkNJNmV5SmlZWE5sWVcxdmRXNTBJam94TURVd0xDSmpkWEp5Wlc1amVXbHpiek5oSWpvaVIwSlFJaXdpYzJsMFpYSmxabVZ5Wlc1alpTSTZJblJsYzNSZmMybDBaVEV5TXpRMUlpd2lZV05qYjNWdWRIUjVjR1ZrWlhOamNtbHdkR2x2YmlJNklrVkRUMDBpZlgwLkE2Z0FuVXEyTkNTbElpTE9jRHl6aHVvNEU4Qm01b1BXU0tia2pPS0tIaGMiLCJyZXNwb25zZSI6W3siYXV0aG1ldGhvZCI6IkZJTkFMIiwidHJhbnNhY3Rpb25zdGFydGVkdGltZXN0YW1wIjoiMjAyMC0wNy0xMyAxMzozNDoyOCIsImN1c3RvbWVyb3V0cHV0IjoiUkVTVUxUIiwibGl2ZXN0YXR1cyI6IjAiLCJtZXJjaGFudG5hbWUiOiJNZXJjaGFudCBuYW1lIiwic3BsaXRmaW5hbG51bWJlciI6IjEiLCJkY2NlbmFibGVkIjoiMCIsInNldHRsZWR1ZWRhdGUiOiIyMDIwLTA3LTEzIiwiZXJyb3Jjb2RlIjoiMCIsImNhdnYiOiJZMkZ5WkdsdVlXeGpiMjF0WlhKalpXRjFkR2c9IiwibWVyY2hhbnRudW1iZXIiOiIwMDAwMDAwMCIsIm1lcmNoYW50Y291bnRyeWlzbzJhIjoiR0IiLCJzdGF0dXMiOiJZIiwidHJhbnNhY3Rpb25yZWZlcmVuY2UiOiIxLTItMzQ1Njc5IiwidGhyZWVkdmVyc2lvbiI6IjIuMS4wIiwicGF5bWVudHR5cGVkZXNjcmlwdGlvbiI6Ik1BU1RFUkNBUkQiLCJiYXNlYW1vdW50IjoiMTA1MCIsImVjaSI6IjAyIiwiYWNjb3VudHR5cGVkZXNjcmlwdGlvbiI6IkVDT00iLCJ0aWQiOiIyNzg4Mjc4OCIsImFjcXVpcmVycmVzcG9uc2Vjb2RlIjoiMDAiLCJyZXF1ZXN0dHlwZWRlc2NyaXB0aW9uIjoiQVVUSCIsInNlY3VyaXR5cmVzcG9uc2VzZWN1cml0eWNvZGUiOiIyIiwiY3VycmVuY3lpc28zYSI6IkdCUCIsImF1dGhjb2RlIjoiVEVTVDk1IiwiZXJyb3JtZXNzYWdlIjoiT2siLCJpc3N1ZXJjb3VudHJ5aXNvMmEiOiJaWiIsIm1hc2tlZHBhbiI6IjUyMDAwMCMjIyMjIzEwMDUiLCJzZWN1cml0eXJlc3BvbnNlcG9zdGNvZGUiOiIwIiwiZW5yb2xsZWQiOiJZIiwic2VjdXJpdHlyZXNwb25zZWFkZHJlc3MiOiIwIiwib3BlcmF0b3JuYW1lIjoiand0LnVzZXIiLCJzZXR0bGVzdGF0dXMiOiIwIn1dLCJzZWNyYW5kIjoiZGdjNlFKOEk1In0sImF1ZCI6Imp3dC51c2VyIn0.XE-vjH2RWS7KLItZx6fa0G_A6mcmBAgxdMylP7IAt9w"
Wenn ein Fehler aufgetreten ist, kann es sein, dass wir die Antwort nicht kodieren können und dass die Antwort daher nur eine errorcode und errormessage.
In diesem Fall empfehlen wir, den Kunden aufzufordern, die Zahlung erneut zu versuchen.
z.B.. errorcode 50000, errormessage "Timeout".
Um die vollständige Antwort anzuzeigen, müssen Sie das zurückgegebene JWT entschlüsseln.
Wir empfehlen die Verwendung der Bibliotheken unter https://jwt.io zur Dekodierung des JWT.
Der Antwort-JWT besteht aus drei Teilen, die durch Punkte (".") getrennt sind, im folgenden Format:
Header.Payload.Signature
Bevor Sie der Antwort vertrauen können, müssen Sie die signature der zurückgegebene Wert mit dem erwarteten Wert übereinstimmt. Ist dies nicht der Fall, wurde er möglicherweise von einer unbefugten Partei geändert.
Die signature wird mit SHA-256 gehasht und kann daher nicht entschlüsselt werden. Dies bedeutet, dass zur Überprüfung der signature korrekt ist, muss Ihr System ihn mit Hilfe der header und payload zurückgegeben.
Vorausgesetzt, Sie verwenden die gleiche secret Während dieses Prozesses werden die neu berechneten signature sollte mit dem in der Antwort zurückgegebenen JWT übereinstimmen. Zusammengefasst:
- Base64URL dekodiert JWT-Header
- Base64URL dekodiert JWT payload
- Generieren Sie die Signatur neu, indem Sie die header, die payload und signieren sie mit Ihrem secret.
(wie oben erläutert)
Parsen Sie die payload
Wir stellen ein Parsing-Dienstprogramm zur Verfügung, um die Daten des Feldes payload als Teil der Überprüfung der Zahlungsantwortfelder zu extrahieren:
(Kotlin)
val response: PaymentTransactionManager.Response = paymentTransactionManager.executeSession(paymentSession)
//Every JWT returned from the SDK should be verified before further usage.
for (jwt in response.responseJwtList) {
if (!verifyJwtIntegrity(jwt)) {
throw SecurityException("JWT verification failed!")
}
}
val parsedResponse = ResponseParser.parse(response.responseJwtList)
//process parsed response
Antwortfelder
Nachdem Sie die Antwort erhalten haben, empfehlen wir Ihnen, die nachstehenden Informationen zu beachten, wenn Sie die Zahlungssession des Kunden bearbeiten:
Transaktionsnummer
Die transactionreference ist ein eindeutiger Bezeichner für die Transaktion. Sie müssen diese Referenz aufzeichnen, um zu einem späteren Zeitpunkt Abfragen oder andere Aktionen zu dieser Transaktion durchführen zu können.
Auftragsnummer
Die orderreference ist ein benutzerdefinierter Bezeichner für die Transaktion, den Sie am besten in der JWT payload jeder Transaktion. Wenn Ihr System so konfiguriert wurde, dass es orderreference Werte zu Ihren Transaktionen hinzufügen, können Sie diese verwenden, um sicherzustellen, dass Sie die richtige Antwort nach einer Zahlung prüfen.
Anforderungstyp
Sie müssen die requesttypedescription in der Antwort zurückgegeben. Nur Werte von "AUTH" zeigen die Autorisierung einer Zahlung an. Klicken Sie hier, um eine vollständige Liste der verschiedenen Anfragetypen zu erhalten, die von Trust Payments unterstützt werden.
Fehlercode
Sie müssen die errorcode zurück, um das Ergebnis der Transaktion zu ermitteln:
| Fehlercode | Beschreibung | Erforderliche Maßnahmen |
| 0 | Erfolgreiche Transaktion. | Keine. |
| 30000 | Zeigt an, dass ungültige Daten innerhalb der payload des JWT. | Überprüfen Sie die Felder, die in der payload des JWTs unserer Spezifikation entsprechen. |
| 60010 60034 99999 |
Dies kann auf ein Kommunikationsproblem mit einer Bank oder einer dritten Partei zurückzuführen sein. | Wir empfehlen, den Kunden über das Problem zu informieren und ihn zu bitten, sich mit Ihnen in Verbindung zu setzen, um das Problem zu klären. Sie müssen sich mit unserem Support-Team in Verbindung setzen und eine Kopie der gesamten Anfrage und der zurückgesandten Antwort vorlegen. Wir werden uns dann mit den entsprechenden Parteien in Verbindung setzen, um den Status der Anfrage zu ermitteln. Stellen Sie im Interesse der Sicherheit sicher, dass Sie sensible Feldwerte, wie z. B. Kartendaten, auslassen oder maskieren. |
| 60022 | Der Kunde wurde aufgefordert, sich zu authentifizieren, konnte diesen Teil des Vorgangs jedoch nicht durchführen, so dass die Transaktion nicht autorisiert wurde. | Bieten Sie dem Kunden eine alternative Zahlungsmethode an und ermöglichen Sie ihm, es erneut zu versuchen. |
| 70000 | Autorisierung für die Zahlung versucht wurde, aber von der ausstellenden Bank abgelehnt wurde. | |
| Andere | Klicken Sie hier für eine vollständige Liste von errorcode Werte, die zurückgegeben werden können. | Abhängig von der errorcode zurückgegeben. |
Abrechnungsstatus (settlestatus)
Sie müssen die settlestatus in der Antwort zurückgegeben:
| Abrechnungsstatus (settlestatus) | Beschreibung | Erforderliche Maßnahmen |
| 0 | Anstehende automatische Abrechnung. | Keine. |
| 1 | Ausstehende manuelle Abrechnung (übersteuert Betrugs- / Doppelprüfungen, falls aktiviert). | |
| 2 | Die Zahlung wurde genehmigt, aber im System Trust Payments ausgesetzt. | Untersuchen Sie die Transaktion manuell, um den Grund für die Aussetzung der Zahlung zu ermitteln. Wenn Sie damit einverstanden sind, können Sie die Transaktion aktualisieren, um Abrechnung zu ermöglichen. |
| 3 | Zahlung annulliert. | Sehen Sie sich die errorcode um den Grund zu ermitteln, warum die Zahlung nicht abgeschlossen wurde. |
3-D eingeschrieben
Die enrolled Das Feld informiert Sie darüber, ob die Karte des Kunden bei 3-D Secure angemeldet ist:
| 3-D eingeschrieben | Beschreibung | Erforderliche Maßnahmen |
| Y | Die Karte des Kunden ist registriert. | Wird durch das Mobile SDK verwaltet. |
| N | Die Karte des Kunden ist nicht registriert. | |
| U | Es kann nicht festgestellt werden, ob die Karte registriert ist. | |
| B | Die Authentifizierungsregel des Händlers wird ausgelöst, um die Authentifizierung in diesem Anwendungsfall zu umgehen. |
3-D-Status
Die status Feld informiert Sie, ob der Kunde während des 3-D Secure Prozesses erfolgreich authentifiziert wurde:
| 3-D-Status | Beschreibung | Erforderliche Maßnahmen |
| Y | Der Kunde wurde erfolgreich authentifiziert. | Keine. Das Mobile SDK wird diese Fälle automatisch behandeln. |
| A | Authentifizierung wurde versucht, aber nicht abgeschlossen. | |
| U | Die Authentifizierung konnte nicht durchgeführt werden. | |
| C | Herausforderung für die Authentifizierung erforderlich. | |
| N | Der Kunde wurde nicht authentifiziert. Die Zahlung wird nicht bearbeitet werden. |
|
| R | Die Authentifizierung wurde abgelehnt. Die Zahlung wird nicht bearbeitet werden. |
3-D-Version
Die version gibt die für die Zahlung verwendete Version von 3-D Secure an. Der Wert beginnt entweder mit "1.x.x", um 3-D Secure v1 zu bezeichnen, oder mit "2.x.x", um 3-D Secure v2 zu bezeichnen.
JWT-Feld-Spezifikation
| Feld | Format | Beschreibung | ||
| JWT Payload |
|
|||
| iat | Numerisch (17) |
Zeit in Sekunden seit Unix epoch (generiert mit UTC). Klicken Sie hier für weitere Informationen. Der JWT ist für 1 Stunde ab dem Zeitpunkt der Übermittlung im iat. |
||
| iss | Alphanumerisch (255) | Ihr JWT-Benutzername. | ||
| Payload Object | ||||
| accounttypedescription | Alphanumerisch (20) | Der übermittelte Wert ist "ECOM" (entspricht einer E-Commerce-Transaktion). | ||
| authmethod | Alphanumerisch (5) |
Unterstützte Werte sind: Der Inhalt von authmethod haben keinen Einfluss auf den Abrechnung Status der Transaktion. Abrechnung Status kann über settlestatus und settleduedate. Klicken Sie hier, um mehr über den Prozess Abrechnung zu erfahren. |
||
| billingprefixname | Alphanumerisch (25) | Das Präfix des Rechnungsnamens, aus der folgenden Liste: Herr, Frau, Dr., Prof., Hochwürden, Sir, Lord, Lady, Dame & Mx. | ||
| billingfirstname | Alphanumerisch (127) |
Die Rechnungsvorname. Erforderlich für Visa Secure Data Field Mandate. Erforderlich für Glücksspielanbieter. |
||
| billingmiddlename | Alphanumerisch (127) | Der mittlere Name der Rechnung. | ||
| billinglastname | Alphanumerisch (127) |
Die Rechnungsnachname. Erforderlich für Visa Secure Data Field Mandate. Erforderlich für Glücksspielanbieter. |
||
| billingsuffixname | Alphanumerisch (25) | Der Name des Rechnungssuffixes. | ||
| billingpremise | Alphanumerisch (25) |
Die Hausnummer oder die erste Zeile der Rechnungsadresse. |
||
| billingstreet | Alphanumerisch (127) |
Die Hausnummer oder die erste Zeile der Rechnungsadresse. |
||
| billingtown | Alphanumerisch (127) |
Die für die Rechnungsadresse eingegebene Stadt. |
||
| billingcounty | Alphanumerisch (127) |
Abrechnungsbezirk.
Hinweis: Falls eingereicht, billingcountryiso2a erforderlich ist. |
||
| billingpostcode | Alphanumerisch (25) |
Die Rechnungspostleitzahl oder die Postleitzahl muss für den billingcountryiso2a vorgelegt. |
||
|
|
billingcountryiso2a | iso2a |
Rechnungsland im iso2a-Format.
Erforderlich wenn billingcounty vorgelegt wird. Andernfalls ist dies fakultativ. |
|
| billingemail | E-Mail (255) |
Rechnungs-E-Mail Adresse. Erforderlich für Visa Secure Data Field Mandate, wenn billingtelephone nicht angegeben ist. |
||
| billingtelephone |
Alphanumerisch einschließlich Symbole (20) |
Telefonnummer für die Rechnungsstellung. Gültige Zeichen:
Erforderlich für Visa Secure Data Field Mandate, wenn billingemail nicht angegeben ist. |
||
| billingtelephonetype | Saibling (1) |
Typ der Telefonnummer für die Rechnungsstellung:
|
||
| credentialsonfile | Numerisch (1) |
Die folgenden Werte können übermittelt werden:
Dies ist erforderlich für Visa und Mastercard Transaktionen, bei denen der Händler die Funktion CoF nutzt. Wenn die Transaktion nicht für CoF in Frage kommt oder Sie die Anmeldeinformationen nicht für zukünftige Transaktionen verwenden möchten, können Sie dieses Feld auslassen. Visa und Mastercard haben vorgeschrieben, dass Sie die Zustimmung des Karteninhabers einholen müssen, bevor Sie Kartendaten für die zukünftige Verwendung speichern.
|
||
| customerprefixname | Alphanumerisch (25) | Name der Lieferung. | ||
| customerfirstname | Alphanumerisch (127) | |||
| customermiddlename | Alphanumerisch (127) | |||
| customerlastname | Alphanumerisch (127) | |||
| customersuffixname | Alphanumerisch (25) | |||
| customerpremise | Alphanumerisch (25) |
Lieferadresse. Die Zustellpostleitzahl oder der ZIP-Code muss für den Empfänger gültig sein. customercountryiso2a vorgelegt. |
||
| customerstreet | Alphanumerisch (127) | |||
| customertown | Alphanumerisch (127) | |||
| customercounty | Alphanumerisch (127) | |||
| customercountryiso2a | iso2a | |||
| customerpostcode | Alphanumerisch (25) | |||
| customeremail | E-Mail (255) | Liefer-E-Mail-Adresse. | ||
| customertelephone |
Alphanumerisch einschließlich Symbole (20) |
Telefonnummer für die Zustellung. Gültige Zeichen:
|
||
| customertelephonetype | Saibling (1) |
Art der Telefonnummer für die Lieferung:
|
||
| customfield1 | Alphanumerisch (100) |
Diese Felder ermöglichen die Übermittlung und Speicherung von benutzerdefinierten Daten in Trust Payments' Datensätzen. Diese Daten können später durch Ausführen einer CSV Transaktionsdownload.
Beispiel für einen Anwendungsfall: Für die Abstimmung kann es nützlich sein, den Sales Amount Verkaufsbetrag) und das Trinkgeld getrennt in zwei dieser benutzerdefinierten Felder zu erfassen, da baseamount/mainamount sind die Summe beider Felder. |
||
| customfield2 | ||||
| customfield3 | ||||
| customfield4 | ||||
| customfield5 | ||||
| currencyiso3a | iso3a |
Die Währung, in der die Transaktion verarbeitet wurde. |
||
| baseamount | Numerisch (13) |
Entweder baseamount oder mainamount muss enthalten sein (nicht beides).
Der Betrag der Transaktion in Basiseinheiten (ohne ohne Dezimalstellen). z.B. €10,50 würde als "1050" übermittelt werden |
||
| mainamount | Numerisch (14) |
Entweder baseamount oder mainamount muss enthalten sein (nicht beides).
Der Betrag der Transaktion in Haupteinheiten. |
||
|
|
initiationreason | Saibling (1) |
Dies ist erforderlich, wenn Sie eine vom Händler initiierte Transaktion verarbeiten (MIT). Ermöglicht es Ihnen, einen Grund für die Transaktion anzugeben. Nicht einreichen, wenn eine kundeninitiierte Transaktion verarbeitet wird (CIT). Die zulässigen Werte für dieses Feld sind "A", "C", "D", "S" und "X".
Weitere Informationen entnehmen Sie bitte der Dokumentation von Visa. |
|
| locale | Unbestimmt |
Standardmäßig werden das Kassenformular und alle angezeigten Fehlermeldungen in britischem Englisch wiedergegeben. Dieses Verhalten kann jedoch durch die folgende Eingabe außer Kraft gesetzt werden locale Werte in der payload:
|
||
| operatorname | Alphanumerisch (255) | Der Wert dieses Feldes enthält den Namen des Benutzers, der die Anfrage bearbeitet hat. Dies ist optional. Wird es weggelassen, wird stattdessen der Wert des Alias aufgezeichnet, der je nach Ihrer Konfiguration entweder Ihr Website-Referenz oder Ihr Web Services-Benutzername ist. | ||
| orderreference |
Alphanumerisch (25)
Siehe Beschreibung rechts für weitere Details |
Ihre eindeutige Auftragsnummer, die im System Trust Payments gespeichert werden kann. Wir empfehlen Ihnen dringend, eine orderreference für jede Transaktion. Empfohlene Länge 25 Zeichen oder weniger (genaue Länge abhängig von der erwerbenden Bank). Die Nichteinhaltung dieser Anforderung kann dazu führen, dass der Text in der Transaktion abgeschnitten wird. |
||
| parenttransactionreference | Alphanumerisch einschließlich Bindestriche (25) | Ermöglicht Ihnen die Angabe der transactionreference einer früheren Anfrage. Die wichtigsten Details werden von diesem Antrag übernommen. | ||
| requesttypedescriptions | Liste |
Die zu bearbeitenden Anfragetypen. Wichtig: Sie müssen sicherstellen, dass bei der Durchführung von Transaktionen in dieser Liste "THREEDQUERY" angegeben wird, damit 3-D Secure bearbeitet werden kann. Dies ist durch das MandatPSD2 vorgeschrieben. Um mehr über die unterstützten Antragsarten zu erfahren, klicken Sie hier. |
||
|
|
scaexemptionindicator | Numerisch (1) |
Wird verwendet, um die Art der 3-D Secure Authentifizierung in Szenarien, in denen dies zulässig ist, zu beeinflussen. Hinweis: Wird nur von bestimmten Acquiring-Banken unterstützt. Kontaktieren Sie das Support-Team für weitere Informationen. Geben Sie einen der folgenden Werte an, wenn Sie die Transaktion von der Authentifizierung ausnehmen:
Wenden Sie sich bitte an Ihren Anwerber, um zu prüfen, ob Sie Ausnahmen beantragen dürfen, bevor Sie dies tun. Alternativ können Sie auch einen der folgenden Werte eingeben, um eine Authentifizierung nach oben (Challenge) anzufordern:
|
|
| settleduedate | Datum JJJJ-MM-TT |
Hier können Sie den Tag in der Zukunft angeben, an dem Ihre Transaktion abgerechnet werden soll. Die Angabe muss im Format erfolgen: JJJJ-MM-TT. |
||
| settlestatus | Numerisch (3) |
Ein numerischer Wert, der zur Definition der Anweisung Abrechnung verwendet wird.
|
||
| sitereference | Alphanumerisch (50) | Eindeutige Referenz, die Ihre Website Trust Payments identifiziert. | ||
| subscriptionbegindate | Datum JJJJ-MM-TT |
Optional bei der Terminierung von Abonnements. Dieses Feld bezieht sich auf den Zeitpunkt der ersten automatisiert Die Zahlung wird bearbeitet. Von da an verwenden wir die Daten, die im Formular subscriptionunit und subscriptionfrequency Felder für die automatische Verarbeitung der Abonnementzahlungen in regelmäßigen Abständen, z. B. wenn ein Abonnementantrag am 5. Januar 2018 eingereicht wird das Intervall ist 1 MONTH (subscriptionfrequency = 1 und subscriptionunit = MONTH) und subscriptionbegindate ist 2018-01-08, die erste automatische Zahlung wird am 8. Januar 2018 verarbeitet, alle weiteren Zahlungen werden am 8. eines jeden Monats verarbeitet. Wenn Sie den Antrag nicht einreichen subscriptionbegindate, werden wir die subscriptionunit und subscriptionfrequency um automatisch die erste automatische Zahlung zu planen. |
||
| subscriptionfinalnumber | Numerisch (5) |
Erforderlich bei der Terminierung von Abonnements. Hier wird die Anzahl der Zahlungen festgelegt, die während der Laufzeit des Abonnements verarbeitet werden sollen:
Hinweis: Wenn der Wert "0" ist, plant Abonnementmodul die Zahlungen auf unbestimmte Zeit, bis der Benutzer das Abonnement manuell auf "Inaktiv" setzt. |
||
| subscriptionfrequency | Numerisch (11) |
Erforderlich bei der Terminierung von Abonnements. In Kombination mit der Einheit legt die Häufigkeit fest, wie häufig Zahlungen verarbeitet werden, z. B. für eine Zahlung alle 7 Tage: subscriptionfrequency = 7 und subscriptionunit = DAY z.B. für eine Zahlung alle 2 Monate: subscriptionfrequency = 2 und subscriptionunit = MONTH |
||
| subscriptionnumber | Numerisch (5) |
Optional bei der Terminierung von Abonnements. Wenn nicht anders angegeben, beginnen die Abonnements mit subscriptionnumber = 1 standardmäßig. Die Website subscriptionnumber wird bei jeder weiteren Abonnementzahlung automatisch erhöht, bis er den Wert des subscriptionfinalnumber Feld, wenn keine weiteren Zahlungen mehr versucht werden. Ein abgeschlossenes Abonnement wird durch ein subscriptionnumber der höher ist als der entsprechende subscriptionfinalnumber. |
||
| subscriptiontype | Alpha (11) |
Erforderlich bei der Terminierung von Abonnements. Dieses Feld gibt die Art des zu bearbeitenden Abonnements an. Ihr System kann diese beiden Werte übermitteln:
*Installationen werden von Händlern mit einem Trust Payments Acquiring-Konto unterstützt. Wenn Sie eine andere Acquiring-Bank verwenden, müssen Sie unser Support-Team kontaktieren, um zu prüfen, ob diese Funktion unterstützt wird, bevor Sie fortfahren. |
||
| subscriptionunit | Alpha (5) |
Erforderlich bei der Terminierung von Abonnements. Dieses Feld gibt die Zeiteinheit zwischen den einzelnen Abonnements an. Dies kann entweder "DAY" oder "MONTH". Anmerkung: Dieses Feld muss unbedingt in GROSSBUCHSTABEN an das Gateway übermittelt werden ("DAY" oder "MONTH"). |
||
| threedbypasspaymenttypes | Liste | Um die Anforderungen von PSD2 zu erfüllen, müssen Sie bei allen unterstützten kartenbasierten E-Commerce-Transaktionen eine 3-D Secure Authentifizierung durchführen. Dies wird erreicht, indem Sie sicherstellen, dass THREEDQUERY in der requesttypedescriptions Liste im JWT payload. Es kann jedoch vorkommen, dass 3-D Secure von Ihrer Bank nicht verlangt oder unterstützt wird. Durch die Angabe von Zahlungsarten in der threedbypasspaymenttypes Liste, wird die Authentifizierung 3-D Secure für die oben genannten Zahlungsarten nicht durchgeführt. | ||
| transactionactive | Numerisch (1) |
Optional bei der Terminierung von Abonnements. Der Abonnementstatus. "0" - Inaktiv: Setzt zukünftige Zahlungen aus, bis sie manuell überschrieben werden. "1" - Aktiv: Plant Abonnementzahlungen sofort und umgeht Betrug und doppelte Prüfungen (falls aktiviert). "2" - Ausstehend (Standard): plant Abonnementzahlungen, nachdem die AUTH abgerechnet wurde (settlestatus "100"). |
||
| termurl | URL (1024) |
Erforderlich für 3-D Secure Authentifizierung. Diese URL wird verwendet, um dem Kartenaussteller mitzuteilen, wohin er den Browser des Kunden senden soll, nachdem er sich am ACS des Kartenausstellers authentifiziert hat. Sie müssen die folgende URL in dieses Feld eingeben, wenn Sie 3-D Secure ausführen: https://payments.securetrading.net/process/payments/mobilesdklistener |
||
| walletsource | Alpha (9) |
Erforderlich für Google Pay Transaktionen. Muss mit "GOOGLEPAY" eingereicht werden. |
||
| wallettoken | JSON-kodierte Zeichenfolge |
Erforderlich für Google Pay Transaktionen. Einzigartiges Token, das von Google bereitgestellt wird, um die Kartendaten des Kunden darzustellen. |
||
