Protect Plus ist ein hochentwickelter Dienst zur Betrugsbekämpfung, der Ihre Website mit einer zusätzlichen Sicherheitsebene gegen betrügerische Transaktionen ausstattet. Er nutzt die größte Negativdatenbank der Branche, um eine umfassende Reihe von Betrugsbewertungen durchzuführen, einschließlich Identitätsprüfungen mit dem britischen Wählerverzeichnis und BT-Datenbanken.
Registrieren Sie sich für Protect Plus
Bevor Sie loslegen können, müssen Sie unser Vertriebsteam kontaktieren und Protect Plus für Ihr Konto aktivieren.
Welche Kontrollen werden durchgeführt?
Wir analysieren die Rechnungs-, Liefer- und Zahlungsdaten des Kunden mithilfe eines regelbasierten Systems, um verdächtige Muster in den Nutzeraktivitäten zu erkennen. Unser System unterstützt Sie bei der Entscheidung, ob die Transaktion eines Kunden auf der Grundlage des wahrgenommenen Risikos bearbeitet werden soll. Zu den durchgeführten Überprüfungen gehören:
- Die größte Negativdatenbank der Branche.
- Neural-basierte Betrugsbewertungen.
- Tumbling oder Swapping, wenn es ein ungewöhnliches Nutzungsmuster bei der Kartennummer, dem Ablaufdatum oder den Kundendaten im Zusammenhang mit einer Transaktion gibt.
Protect Plus bietet keine Garantie gegen Betrug
Sie sollten alle Daten zu einer Transaktion berücksichtigen, bevor Sie die Zahlung akzeptieren.
Was geschieht nach der Durchführung der Kontrollen?
Das System Protect Plus analysiert die Transaktionsdetails und gibt eine der folgenden Optionen aus fraudcontrolshieldstatuscode Werte:
"ACCEPT" | Die Angaben werden nicht als verdächtig angesehen. |
"CHALLENGE" | Weitere Untersuchungen werden empfohlen. |
"DENY" | Die Angaben sind verdächtig und eine Transaktion sollte nicht durchgeführt werden. |
"NOSCORE" | Die Transaktion wurde vom Erwerber abgelehnt, bevor eine Prüfung durchgeführt wurde. |
Reihenfolge der Anträge
Protect Plus Prüfungen werden durchgeführt, wenn eine RISKDEC Anfrage an unser System übermittelt wird. Es gibt zwei Methoden, mit denen Sie Ihr System so konfigurieren können, dass es RISKDEC Anfragen über unser Mobile SDK verarbeitet:
- RISKDEC dann AUTH - Führen Sie zuerst die Überprüfungen durch und suchen Sie dann Autorisierung für die Zahlung. Standardmäßig setzen wir verdächtige Zahlungen aus, damit Sie sie prüfen können, bevor Sie fortfahren.
- AUTH dann RISKDEC - Suchen Sie zuerst Autorisierung für die Zahlung und führen Sie dann die Kontrollen durch. Die durchgeführten Überprüfungen sind genauer, weil sie die Ergebnisse von AVSSicherheitscode-Prüfungen und 3-D Secure berücksichtigen.
Konfiguration der Anfrage
Überblick über den Prozess
- Wenn der Kunde auf "Pay" auf Ihrer Kasse, sendet der Drop-In View Controller eine Anfrage an Trust Payments.
- Trust Payments prüft die Zahlungsdaten und erstellt eine shield status code.
- Der Kunde ist mit 3-D Secure authentifiziert.
- Trust Payments setzt sich mit der erwerbenden Bank in Verbindung, um die Zahlung zu bearbeiten.
- Trust Payments gibt die Antwort JWT an Ihr System zurück. Sie müssen die Antwort interpretieren.
Wenn Sie sich für die Durchführung der RISKDEC vor der AUTH, setzen wir genehmigte Transaktionen automatisch aus, wenn die fraudcontrolshieldstatuscode ist "CHALLENGE" oder "DENY". So können Sie weitere Nachforschungen anstellen und eine fundiertere Entscheidung treffen, ob Sie eine verdächtige Transaktion genehmigen oder nicht. Dieses Verhalten kann geändert werden. Bitte Kontakt mit dem Support-Team für weitere Informationen.
Aktualisieren Sie das JWT payload
Sie müssen die JWT payload um unser Mobile SDK anzuweisen, eine RISKDEC zu verarbeiten, bevor eine Standardtransaktion durchgeführt wird. Dies geschieht durch Übermittlung von requesttypedescriptions gemäß der nachstehend aufgeführten Spezifikation:
Feldspezifikation
Feld | Format | Beschreibung | |
requesttypedescriptions | Liste | Diese muss auf [“RISKDEC”,”THREEDQUERY”,”AUTH”]. |
Payload Beispiel
{
"payload":{
"accounttypedescription":"ECOM",
"baseamount":"1050",
"currencyiso3a":"GBP",
"sitereference":"test_site12345",
"termurl":"https:\/\/payments.securetrading.net\/process\/payments\/mobilesdklistener",
"requesttypedescriptions":["RISKDEC","THREEDQUERY","AUTH"]
},
"iat":1559033849,
"iss":"jwt.user"
}
Umgang mit der Antwort
Nachdem der Kunde den Zahlungsvorgang abgeschlossen hat, erhalten Sie eine einzige JWT-Antwort, die aus den Antworten RISKDEC, THREEDQUERY und AUTH besteht.
Jedes vom SDK zurückgegebene JWT sollte überprüft werden, bevor Sie fortfahren. Wir bieten ein Parsing-Dienstprogramm an, das die Umwandlung des JWT in ein Transaktionsantwortobjekt erleichtert. Klicken Sie hier, um ein Beispiel für die Verwendung dieses Dienstprogramms zu sehen.
Die wichtigste zu prüfende Reaktion ist die AUTH, der Prozess, bei dem die Transaktion von der ausstellenden Bank autorisiert wird. Ihr System muss sicherstellen, dass die errorcode Der für AUTH zurückgegebene Wert ist "0", was einen Erfolg anzeigt. Wenn die AUTH fehlgeschlagen ist, wird die Zahlung nicht erfolgreich sein. Zusätzlich zur Überprüfung des errorcode, sollte Ihr System auch die im Abschnitt "Erste Schritte" empfohlenen Prüfungen durchführen.
Die folgenden Felder werden in der Antwort RISKDEC zurückgegeben:
Feld | Format | Beschreibung | |
fraudcontrolreference | Alphanumerisch (255) | Eindeutige Referenz zur Identifizierung der durchgeführten Risikoentscheidung Prüfung. | |
fraudcontrolresponsecode | Numerisch (4) | Ein numerischer Code, dem weitere Informationen über die Ergebnisse der durchgeführten Risikoentscheidung Prüfungen zugeordnet sind. | |
fraudcontrolshieldstatuscode | Alpha (10) |
Einer der folgenden Werte:
|
|
rulecategoryflag | Alphanumerisch (255) |
Referenz, die zur Identifizierung einer Bedingung verwendet wird, die erfüllt wurde, um die DENY oder CHALLENGE fraudcontrolshieldstatuscode. Wird nur zurückgegeben, wenn die Prüfungen erfolgreich durchgeführt wurden. |
|
rulecategorymessage | Nicht definiert |
Bedingung, die erfüllt wurde, um die DENY zurückzugeben oder CHALLENGE fraudcontrolshieldstatuscode. Wird nur zurückgegeben, wenn die Prüfungen erfolgreich durchgeführt wurden. |
Überblick über den Prozess
- Wenn der Kunde auf "Pay" auf Ihrer Kasse, sendet der Drop-In View Controller eine Anfrage an Trust Payments.
- Der Kunde ist mit 3-D Secure authentifiziert.
- Trust Payments setzt sich mit der erwerbenden Bank in Verbindung, um die Zahlung zu bearbeiten.
- Trust Payments prüft die Zahlungsdaten und erstellt eine shield status code.
- Trust Payments gibt die Antwort JWT an Ihr System zurück. Sie müssen die Antwort interpretieren.
Wenn die shield status code "CHALLENGE" oder "DENY" lautet, empfiehlt Trust Payments , dass Sie die AUTH in einen ausgesetzten Zustand (Abrechnungsstatus "2") aktualisieren. So können Sie die Transaktion überprüfen und entweder fortfahren, indem Sie Abrechnungsstatus auf AUTH auf "1" aktualisieren, oder sie abbrechen, indem Sie Abrechnungsstatus auf "3" aktualisieren.
Aktualisieren Sie das JWT payload
Sie müssen die JWT payload um unser Mobile SDK anzuweisen, eine RISKDEC im Anschluss an eine Standardtransaktion zu verarbeiten. Dies geschieht durch Übermittlung von requesttypedescriptions gemäß der nachstehend aufgeführten Spezifikation:
Feldspezifikation
Feld | Format | Beschreibung | |
requesttypedescriptions | Liste | Diese muss auf [“THREEDQUERY”,”AUTH”,”RISKDEC”] |
Payload Beispiel
{
"payload":{
"accounttypedescription":"ECOM",
"baseamount":"1050",
"currencyiso3a":"GBP",
"sitereference":"test_site12345",
"termurl":"https:\/\/payments.securetrading.net\/process\/payments\/mobilesdklistener",
"requesttypedescriptions":["THREEDQUERY","AUTH","RISKDEC"]
},
"iat":1559033849,
"iss":"jwt.user"
}
Umgang mit der Antwort
Nachdem der Kunde den Zahlungsvorgang abgeschlossen hat, erhalten Sie eine einzige JWT-Antwort, die aus den Antworten THREEDQUERY, AUTH und RISKDEC besteht.
Jedes vom SDK zurückgegebene JWT sollte überprüft werden, bevor Sie fortfahren. Wir bieten ein Parsing-Dienstprogramm an, das die Umwandlung des JWT in ein Transaktionsantwortobjekt erleichtert. Klicken Sie hier, um ein Beispiel für die Verwendung dieses Dienstprogramms zu sehen.
-
Bei der Überprüfung der Antworten THREEDQUERY und AUTH :
- Wir empfehlen, die auf dieser Seite beschriebenen Kontrollen durchzuführen.
-
Bei der Überprüfung der Antwort RISKDEC :
- Es ist wichtig, dass diese Anfrage erfolgreich ist (prüfen Sie die errorcode ist "0").
- Prüfen Sie die fraudcontrolshieldstatuscode - Wir empfehlen, die Fälle zu untersuchen, in denen "CHALLENGE" und "DENY" zurückgegeben werden.
- Es gibt zusätzliche Felder, die spezifisch für Protect Plus sind und die Ihr System überprüfen muss. Diese sind in der nachstehenden Tabelle beschrieben.
Feld | Format | Beschreibung | |
fraudcontrolreference | Alphanumerisch (255) | Eindeutige Referenz zur Identifizierung der durchgeführten Risikoentscheidung Prüfung. | |
fraudcontrolresponsecode | Numerisch (4) | Ein numerischer Code, dem weitere Informationen über die Ergebnisse der durchgeführten Risikoentscheidung Prüfungen zugeordnet sind. | |
fraudcontrolshieldstatuscode | Alpha (10) |
Einer der folgenden Werte:
|
|
rulecategoryflag | Alphanumerisch (255) |
Referenz, die zur Identifizierung einer Bedingung verwendet wird, die erfüllt wurde, um die DENY oder CHALLENGE fraudcontrolshieldstatuscode. Wird nur zurückgegeben, wenn die Prüfungen erfolgreich durchgeführt wurden. |
|
rulecategorymessage | Nicht definiert |
Bedingung, die erfüllt wurde, um die DENY zurückzugeben oder CHALLENGE fraudcontrolshieldstatuscode. Wird nur zurückgegeben, wenn die Prüfungen erfolgreich durchgeführt wurden. |
Prüfung
Wir empfehlen Ihnen, Ihre Lösung gründlich zu testen, bevor Sie sie auf Ihrem Live-Website-Referenz aktivieren.
Klicken Sie hier für Details, die Sie einreichen können, um verschiedene RISKDEC Antworten auf unserem Testsystem zu simulieren.