Mit unserem Mobile SDK können Sie es wiederkehrenden Kunden ermöglichen, Zahlungen über Ihre App abzuwickeln, ohne dass sie ihre Kartendaten erneut eingeben müssen. Dies führt nicht nur zu schnelleren und einfacheren Zahlungen für Ihre Kunden, sondern Ihr Unternehmen profitiert auch davon, dass Sie keine sensiblen Kartennummern speichern müssen (dies kann Ihren PCI-Akkreditierungsprozess vereinfachen).
Dieser Vorgang wird Tokenisierung genannt.
In diesem Dokument wird erklärt, wie eine Account check Anfrage verwendet werden kann, um die Zahlungsdaten des Kunden für Tokenisierung zu speichern. Account check Anfragen belasten das Bankkonto des Kunden nicht.
Falls gewünscht, kann Tokenisierung aber auch für frühere Autorisierung Anfragen, die dem Kunden in Rechnung gestellt wurden, durchgeführt werden, sofern die Anforderungen der Daten Hinterlegt Mandat erfüllt sind. Hierfür benötigen Sie die transactionreference der Zahlung, die Sie wiederholen möchten, und fahren Sie dann mit der Konfiguration für tokenisierte Zahlung Abschnitt dieses Dokuments, der weiter unten zu finden ist.
Voraussetzungen
- Account Checks 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.
- Account Checks kann nur bei kartenbasierten Zahlungsmitteln durchgeführt werden.
Um Betrug zu verhindern, hat Visa angeordnet, dass alle Händler mit einer Kunden Categorie Nummer (MCC) von 6012 zusätzliche Felder in AUTH und ACCOUNTCHECK Anfragen senden müssen. Klicken Sie hier für weitere Informationen.
Überblick über den Prozess
- Jede Transaktion lässt sich anhand ihrer transactionreference, eine eindeutige Kennung, die von Trust Payments zugewiesen wird. Wenn ein neuer Kunde über Ihre App bestellt, müssen Sie sicherstellen, dass Ihr eigenes System einen Datensatz über den transactionreference zurückgegeben.
- Ihr Zahlungsantrag kann folgende Angaben enthalten transactionreference aus dem letzten Kauf des Kunden - oder Account check -, um die Kartennummer und das Ablaufdatum für einen neuen Kauf zu übernehmen (wir erklären, wie das geht, weiter unten).
- Der Kunde wird aufgefordert, den Sicherheitscode einzugeben, der sich normalerweise auf der Rückseite seiner Karte befindet (da wir diesen Wert aus Sicherheitsgründen nicht in unseren Unterlagen speichern können). Der Kunde muss diesen Code eingeben, damit zusätzliche Sicherheitsüberprüfungen durch den Kartenaussteller durchgeführt werden können.
- Wir werden dann die tokenisierte Zahlung verarbeiten. Stellen Sie sicher, dass Ihr System den Antwort-JWT überprüft, um zu bestätigen, dass die neue Zahlung erfolgreich verarbeitet wurde.
Konfiguration für die Speicherung von Zahlungsnachweisen
Um die Zahlungsdaten des Kunden auf dem System Trust Payments zu speichern und eine Referenz für die Verwendung bei zukünftigen Einkäufen zu erhalten, kann Ihr System eine Account check mit unserem Mobile SDK verarbeiten.
Konfigurieren Sie das JWT
Sie müssen sicherstellen, dass Ihre JWT payload umfasst die folgenden Felder:
Feldspezifikation
Feld | Format | Beschreibung | |
credentialsonfile | Numerisch (1) | Dies muss auf "1" gesetzt werden, um anzuzeigen, dass der Kunde damit einverstanden ist, dass die Zahlungsdaten für zukünftige Transaktionen gespeichert werden. Siehe unten für weitere Informationen. | |
requesttypedescriptions | Liste | Diese muss auf [“THREEDQUERY”,“ACCOUNTCHECK”]. |
Wenn die credentialsonfile Feld in der Anfrage übermittelt wurde und vom Acquirer, der die Transaktion bearbeitet, unterstützt wird, wird es in der Antwort JWT zurückgegeben.
Wenn die übergeordnete Antwort angibt, dass ein Fehler aufgetreten ist (errorcode nicht "0" ist), kann der Berechtigungsnachweis nicht als gespeicherter Berechtigungsnachweis betrachtet werden, und Sie dürfen diese Kartendaten nicht für weitere Zahlungen verwenden.
{
"payload":{
"accounttypedescription":"ECOM",
"baseamount":"1050",
"currencyiso3a":"GBP",
"sitereference":"test_site12345",
"credentialsonfile":"1",
"requesttypedescriptions":["THREEDQUERY","ACCOUNTCHECK"]
},
"iat":1559033849,
"iss":"jwt.user"
}
Über Daten Hinterlegt
Ein gespeicherter Berechtigungsnachweis ist eine Information (einschließlich, aber nicht beschränkt auf eine Kontonummer oder ein Zahlungs-Token), die gespeichert wird, um zukünftige Transaktionen zu verarbeiten.
Der Prozess der Speicherung von Anmeldeinformationen für die künftige Verwendung ist bekannt als Daten Hinterlegt (CoF).
Visa und Mastercard haben angeordnet, dass Sie muss die Zustimmung des Karteninhabers einholen vor der Speicherung von Kartendaten für die künftige Verwendung, und dass diese muss zum Zeitpunkt der ersten Meldung gekennzeichnet werden Genehmigung, durch Übermittlung der credentialsonfile Feld in Ihren Anfragen. Sie müssen auch alle nachfolgenden Zahlungen kennzeichnen, bei denen zuvor gespeicherte Anmeldeinformationen verwendet werden, indem Sie das Feld credentialsonfile Feld in diesen Anfragen.
Die Identifizierung von Transaktionen unter CoF bietet folgende Vorteile:
- Erhöht die Wahrscheinlichkeit einer Transaktion Autorisierung und Abrechnung.
- Größere Transparenz und bessere Erfahrungen aus der Sicht des Kunden.
- Es ist weniger wahrscheinlich, dass Emittenten das Fehlen eines Sicherheitscodes als Grund für die Ablehnung einer Transaktion angeben.
Umgang mit der Antwort
Nachdem die Anfrage verarbeitet wurde, erhalten Sie ein einzelnes Antwort-JWT, das die Antwort auf die Anfrage ACCOUNTCHECK enthält:
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.
- Stellen Sie sicher, dass die errorcode Der zurückgegebene Wert ist "0", was den Erfolg anzeigt. (Sie dürfen keine Anmeldedaten speichern, wenn ein Fehler aufgetreten ist)
- Prüfen Sie die Werte, die in der securityresponseaddress, securityresponsepostcode und securityresponsesecuritycode Felder. Klicken Sie hier für weitere Informationen zu diesen Kontrollen und nur fortfahren, wenn die geschäftlichen Anforderungen erfüllt sind.
Nach erfolgreicher Tokenisierung können Sie die transactionreference in Ihren Unterlagen. Diese werden später benötigt, um eine neue Zahlung mit den gespeicherten Zahlungsdaten zu verarbeiten. Sie können auch die letzten vier Ziffern der maskedpan und paymenttypedescription um sie wiederkehrenden Kunden bei der Wahl der Zahlungsmethode für ihren nächsten Einkauf anzuzeigen.
Konfiguration für tokenisierte Zahlung
Aktualisieren Sie Ihr Zahlungsformular
Für die tokenisierte Zahlung müssen Sie zunächst sicherstellen, dass Sie die Drop-In Payment View in Ihr Layout eingefügt haben:
(XML)
<?xml version="1.0" encoding="utf-8"?>
<ScrollView xmlns:android="http://schemas.android.com/apk/res/android"
android:layout_width="match_parent"
android:layout_height="match_parent"
android:fillViewport="true">
<com.trustpayments.mobile.ui.dropin.DropInPaymentView
android:id="@+id/dropInPaymentView"
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:padding="20dp" />
</ScrollView>
Hier ist ein Beispiel für einen Drop-In Payment View Controller, bei dem nur das Feld für den Sicherheitscode sichtbar ist, um eine Transaktion auf der Grundlage eines gespeicherten transactionreference für Zahlungsnachweise:
(Beispiel)
class SampleActivity : AppCompatActivity(R.layout.activity_sample),
DropInPaymentView.DropInPaymentViewListener {
private var paymentSession: PaymentSession
private val paymentTransactionManager =
PaymentTransactionManager(
context = this,
gatewayType = TrustPaymentsGatewayType.EU,
isCardinalLive = false,
merchantUsername = BuildConfig.MERCHANT_USERNAME
cardinalStyleManager = null,
isLocationDataConsentGiven = false
)
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
dropInPaymentView.dropInPaymentViewListener = this
dropInPaymentView.setupForTokenizedPayment(setOf(PaymentInputType.CVV), CardType.Visa)
paymentSession = paymentTransactionManager.createSession({jwtToken})
}
// notify about the payment form data changes, this time we're only interested in CVV
override fun onInputValid(paymentInputType: PaymentInputType, input: String) {
when (paymentInputType) {
PaymentInputType.CVV -> paymentSession.cardSecurityCode = input
}
}
// notify about the Pay Button click event
override fun onPayButtonClicked() {
val result: PaymentSessionResponse = paymentTransactionManager.executeSession(paymentSession)
// process the result
}
}
Wenn das Feld für den Sicherheitscode angefordert wird, muss auch der Kartentyp angegeben werden (die Eingabelänge des Sicherheitscodes wird anhand seines Wertes bestimmt).
Die Drop-In Payment View kann so konfiguriert werden, dass eine beliebige Kombination von Eingabefeldern angezeigt wird:
(Beispiel)
PaymentInputType {
PAN,
ExpiryDate,
CVV
}
Konfigurieren Sie das JWT
Zusätzlich zu den Feldern, die im JWT angegeben werden müssen (wie unter diese Seite), die payload müssen die parenttransactionreference Feld, dessen Wert in der Datei transactionreference Feld des Account check Antwort. Sie muss außerdem das Feld credentialsonfile mit dem Wert "2", um anzuzeigen, dass die neue Transaktion zuvor gespeicherte Anmeldedaten verwendet.
(Payload)
{
"payload":{
"accounttypedescription":"ECOM",
"baseamount":"1050",
"currencyiso3a":"GBP",
"sitereference":"test_site12345",
"parenttransactionreference":"1-2-345",
"credentialsonfile":"2",
"termurl":"https:\/\/payments.securetrading.net\/process\/payments\/mobilesdklistener",
"requesttypedescriptions":["THREEDQUERY","AUTH"]
},
"iat":1559033849,
"iss":"jwt.user"
}
Feldspezifikation
Feld | Format | Beschreibung | |
credentialsonfile | Numerisch (1) | Dies muss auf "2" gesetzt werden, um anzuzeigen, dass die neue Transaktion zuvor gespeicherte Anmeldeinformationen verwendet. | |
parenttransactionreference |
Alphanumerisch & Bindestriche (25) |
Geben Sie die Transaktionsnummer des vorherigen Antrags ein, von dem die Kartendaten übernommen werden sollen. | |
requesttypedescriptions | Liste |
Diese muss mindestens die folgenden Anfragearten enthalten: |