Der folgende Artikel gibt einen Überblick darüber, wie Sie Ihre Zahlungslösung, die SCHEMEUPDATE verwendet, testen können.
Zusammenfassung
SCHEMEUPDATE werden Anfragen an das Trust Payments Gateway (TRU Connect) gerichtet, um bei dem jeweiligen Kartenaussteller zu überprüfen, ob die in einer wiederkehrenden Zahlungsfolge verwendete Kundenkarte noch gültig und aktuell ist. Falls Aktualisierungen erforderlich sind, aktualisiert Trust Payments automatisch seine Datensätze, so dass künftige Zahlungen in der Sequenz die aktualisierten Kartendaten verwenden. Sie können diesen Prozess in unserer Testumgebung testen, bevor Sie ihn in der Produktionsumgebung einsetzen, indem Sie die unten stehenden Anweisungen befolgen.
Anforderungen:
- Sie benötigen Zugang zu Ihrer Test-Site (mit dem Präfix "test_").
- Für Ihre Testseite muss SCHEMEUPDATE in Ihrem ECOM/MOTO Konto aktiviert sein. Bitte kontaktieren Sie unser Support-Team, um dies zu beantragen.
Testen mit wiederkehrenden Zahlungen mit unserer Webservices API
Bei dieser Methode würde Ihr System in regelmäßigen, mit dem Kunden vereinbarten Abständen eine AUTH Anfrage an uns senden. Klicken Sie hier, um mehr zu erfahren.
-
Verarbeiten Sie die übergeordnete Seite AUTH mit dem Test PAN 4000000000000671.
Damit wird simuliert, dass der Kunde ein Abonnement mit der Karte 4000000000000671 beginnt.{
"payload":{
"accounttypedescription":"ECOM",
"baseamount":"1050",
"currencyiso3a":"GBP",
"sitereference":"test_site12345",
"credentialsonfile":"1",
"subscriptiontype":"RECURRING",
"subscriptionnumber":"1",
"requesttypedescriptions":["THREEDQUERY","AUTH"]
},
"iat":1559033849,
"iss":"jwt.user"
}Stellen Sie sicher, dass die zurückgegebene Antwort AUTH errorcode 0, was bedeutet, dass die Anfrage erfolgreich verarbeitet wurde.
Klicken Sie hier für die vollständige Dokumentation. -
Bearbeiten Sie den Antrag SCHEMEUPDATE . Die Kartensysteme geben an, dass dieser Antrag 3 Tage vor dem Fälligkeitsdatum der nächsten wiederkehrenden Zahlung eingereicht werden muss.
Damit wird überprüft, ob sich die Kartendaten des Kunden nicht geändert haben (d.h. PAN ist immer noch 4000000000000671).#!/usr/bin/python
import securetrading
stconfig = securetrading.Config()
stconfig.username = "webservices@example.com"
stconfig.password = "Password1^"
st = securetrading.Api(stconfig)
schemeupdate = {
"sitereference": "test_site12345",
"requesttypedescriptions": ["SCHEMEUPDATE"],
"parenttransactionreference": "23-9-80000"
}
strequest = securetrading.Request()
strequest.update(schemeupdate)
stresponse = st.process(strequest) #stresponse contains the transaction response<?php
if (!($autoload = realpath(__DIR__ . '/../../../autoload.php')) && !($autoload = realpath(__DIR__ . '/../vendor/autoload.php'))) {
throw new Exception('Composer autoloader file could not be found.');
}
require_once($autoload);
$configData = array(
'username' => 'webservices@example.com',
'password' => 'Password1^',
);
$requestData = array(
'sitereference' => 'test_site12345',
'requesttypedescriptions' => array('SCHEMEUPDATE'),
'parenttransactionreference' => '12-3-4567'
);
$api = \Securetrading\api($configData);
$response = $api->process($requestData);
var_dump($response->toArray());
?>curl --user webservices@example.com:Password1^ <DOMAIN>/json/ -H "Content-type: application/json" -H "Accept: application/json" -X POST -d '{
"alias":"webservices@example.com",
"version": "1.00",
"request": [{
"sitereference": "test_site12345",
"requesttypedescriptions": ["SCHEMEUPDATE"],
"parenttransactionreference": "12-3-4567"
}]
}'{
"alias":"webservices@example.com",
"version":"1.00",
"request":[{
"sitereference":"test_site12345",
"requesttypedescriptions":["SCHEMEUPDATE"],
"parenttransactionreference":"12-3-4567"
}]
}<requestblock version="3.67">
<alias>webservices@example.com</alias>
<request type="SCHEMEUPDATE">
<operation>
<parenttransactionreference>12-3-4567</parenttransactionreference>
<sitereference>test_site12345</sitereference>
</operation>
</request>
</requestblock>Die Website SCHEMEUPDATE wird innerhalb von 3 Tagen auf settlestatus 100 innerhalb von 3 Tagen aktualisiert, und es werden neue pan 4000000000000051 aufgezeichnet.
Dies simuliert, dass der Kunde eine neue Karte 4000000000000051 erhält.
Klicken Sie hier für die vollständige Dokumentation.Die zurückgesandten neuen Kartendaten können auch eine aktualisierte expirydate. -
Verarbeiten Sie das untergeordneten AUTH. Dabei werden automatisch die von SCHEMEUPDATE aktualisierten Kartendaten übernommen.
Damit wird simuliert, dass der Kunde für die zweite Zahlung belastet wird, diesmal aber mit der neuen Karte 4000000000000051.#!/usr/bin/python
import securetrading
stconfig = securetrading.Config()
stconfig.username = "webservices@example.com"
stconfig.password = "Password1^"
st = securetrading.Api(stconfig)
auth = {
"sitereference": "test_site12345",
"requesttypedescriptions": ["AUTH"],
"accounttypedescription": "RECUR",
"parenttransactionreference": "12-3-4567",
"baseamount": "1050",
"subscriptiontype": "RECURRING",
"subscriptionnumber": "2",
"credentialsonfile": "2"
}
strequest = securetrading.Request()
strequest.update(auth)
stresponse = st.process(strequest) #stresponse contains the transaction response<?php
if (!($autoload = realpath(__DIR__ . '/../../../autoload.php')) && !($autoload = realpath(__DIR__ . '/../vendor/autoload.php'))) {
throw new Exception('Composer autoloader file could not be found.');
}
require_once($autoload);
$configData = array(
'username' => 'webservices@example.com',
'password' => 'Password1^',
);
$requestData = array(
'sitereference": "test_site12345',
'requesttypedescriptions' => array('AUTH'),
'accounttypedescription' => 'RECUR',
'parenttransactionreference' => '12-3-4567',
'baseamount' => '1050',
'subscriptiontype' => 'RECURRING',
'subscriptionnumber' => '2',
'credentialsonfile' => '2'
);
$api = \Securetrading\api($configData);
$response = $api->process($requestData);
var_dump($response->toArray());
?>curl --user webservices@example.com:Password1^ <DOMAIN>/json/ -H "Content-type: application/json" -H "Accept: application/json" -X POST -d '{
"alias":"webservices@example.com",
"version": "1.00",
"request": [{
"sitereference": "test_site12345",
"requesttypedescriptions": ["AUTH"],
"accounttypedescription": "RECUR",
"parenttransactionreference": "12-3-4567",
"baseamount": "1050",
"subscriptiontype": "RECURRING",
"subscriptionnumber": "2",
"credentialsonfile": "2"
}]}'{
"alias":"webservices@example.com",
"version":"1.00",
"request":[{
"sitereference":"test_site12345",
"requesttypedescriptions":["AUTH"],
"accounttypedescription":"RECUR",
"parenttransactionreference":"12-3-4567",
"baseamount":"1050",
"subscriptiontype":"RECURRING",
"subscriptionnumber":"2",
"credentialsonfile":"2"
}]
}<requestblock version="3.67">
<alias>webservices@example.com</alias>
<request type="AUTH">
<operation>
<sitereference>test_site12345</sitereference>
<accounttypedescription>RECUR</accounttypedescription>
<parenttransactionreference>12-3-4567</parenttransactionreference>
<credentialsonfile>2</credentialsonfile>
</operation>
<billing>
<amount>1050</amount>
<subscription type="RECURRING">
<number>2</number>
</subscription>
</billing>
</request>
</requestblock>Stellen Sie sicher, dass die zurückgegebene Antwort AUTH errorcode 0, was bedeutet, dass die Anfrage erfolgreich verarbeitet wurde.
Klicken Sie hier für die vollständige Dokumentation. -
Von diesem Zeitpunkt an verwenden alle nachfolgenden untergeordneten AUTH Anfragen, die an Trust Payments gesendet werden und die ursprüngliche übergeordnete Karte verwenden, die aktualisierte PAN 4000000000000051.
Dadurch wird simuliert, dass der Kunde für nachfolgende Zahlungen mit der neuen Karte 4000000000000051 belastet wird.
Andere Testfälle
Wenn Sie bei der Verarbeitung von Anfragen in unserer Testumgebung die angegebene PAN im oben beschriebenen Zahlungsfluss ersetzen, können Sie unserem Testsystem unterschiedliche Antworten entlocken. Diese sind im Folgenden beschrieben:
| PAN eingereicht im Anfrage der übergeordnete AUTH | Ergebnis in der Testumgebung |
| 4000000000000671 |
Sobald die SCHEMEUPDATE auf 100 aktualisiert ist, wird die auf settlestatus 100 aktualisiert wird, wird PAN auf 4000000000000051 aktualisiert (dies kann bis zu 3 Tage dauern), was für die nachfolgenden Abonnementzahlungen in der Folge verwendet wird. Damit wird simuliert, dass der Kunde eine neue Karte erhält, die bei künftigen Zahlungen verwendet wird. |
| 4000000000000051 |
Sobald die SCHEMEUPDATE auf settlestatus 100 aktualisiert wird, wird die PAN auf 4111110000000914 aktualisiert (dies kann bis zu 3 Tage dauern), die für die nachfolgenden Abonnementzahlungen in der Folge verwendet wird. Damit wird simuliert, dass der Kunde eine neue Karte erhält, die bei künftigen Zahlungen verwendet wird. |
| 4111110000000914 |
Die Website SCHEMEUPDATE wird aktualisiert und zeigt nun errorcode 70000 und settlestatus 3 (dies kann bis zu 3 Tage dauern). Wenn eine SCHEMEUPDATE auf diese Weise abgelehnt wird, empfehlen wir Ihnen, die acquirerresponsecode und acquirerresponsemessage um den Grund für die erfolglose Anfrage zu ermitteln. Wenn das Kartensystem verlangt hat, dass künftige Zahlungen gestoppt werden müssen, darf Ihr System keine weiteren Zahlungen in dieser Abonnementfolge verarbeiten. Dies simuliert eine Situation, in der das Kartensystem eine Anfrage des Kunden erhalten hat, weitere wiederkehrende Zahlungen einzustellen. In diesem Fall empfehlen wir, den Kunden zu kontaktieren, um die Situation zu klären. |
Testen mit Abonnements mit unserem Payment Pages
Mit unserer Lösung Payment Pages können Sie Zahlungen planen, die automatisch von Trust Payments Abonnementmodul in dem in der Anfrage angegebenen Intervall verarbeitet werden. Klicken Sie hier, um mehr über Abonnements zu erfahren.
-
Die Anfrage (POST) an Payment Pages muss abonnementspezifische Felder enthalten, die das Intervall des Abonnements definieren. Führen Sie auf Ihrer Testseite eine Transaktion mit Payment Pages unter Verwendung des Tests PAN 4000000000000051 durch.
Damit wird simuliert, dass der Kunde ein Abonnement mit der Karte 4000000000000051 beginnt.
Für Testzwecke empfehlen wir, ein Intervall von 1 MONTH festzulegen, wie im folgenden Beispiel gezeigt:<html>
<head>
</head>
<body>
<form method="POST" action="<DOMAIN>/process/payments/choice">
<input type="hidden" name="sitereference" value="test_site12345">
<input type="hidden" name="currencyiso3a" value="GBP">
<input type="hidden" name="mainamount" value="10.00">
<input type="hidden" name="stprofile" value="default">
<input type="hidden" name="version" value="2">
<input type="hidden" name="subscriptionunit" value="MONTH">
<input type="hidden" name="subscriptionfrequency" value="1">
<input type="hidden" name="subscriptionnumber" value="1">
<input type="hidden" name="subscriptionfinalnumber" value="12">
<input type="hidden" name="subscriptiontype" value="RECURRING">
<input type="hidden" name="credentialsonfile" value="1">
<input type="submit" value="Pay">
</form>
</body>
</html> -
Hinter den Kulissen wird 3 Tage vor der Verarbeitung einer automatischen Abonnementzahlung automatisch eine SCHEMEUPDATE -Anfrage ausgelöst. Daraufhin sollte eine neue PAN 4111110000000914 abgerufen und im Datensatz SCHEMEUPDATE gespeichert werden, und die maskierte Version davon ist in Portal sichtbar (dies kann bis zu 3 Tage dauern). Wenn die nächste Abonnementzahlung in der Sequenz verarbeitet wird, wird die neue 4111110000000914 PAN verwendet.
Damit soll sichergestellt werden, dass sich die Kartendaten des Kunden nicht geändert haben (d. h. PAN war noch 4000000000000051) und unsere Datensätze anschließend aktualisiert wurden, um 4111110000000914 für künftige Abonnementzahlungen zu verwenden, da dem Kunden eine neue Karte ausgestellt wurde. -
3 Tage vor der Abwicklung der dritten Abo-Zahlung wird automatisch eine weitere SCHEMEUPDATE ausgelöst. Die SCHEMEUPDATE wird aktualisiert und zeigt errorcode 70000 und settlestatus 3 (dies kann bis zu 3 Tage dauern). Wenn eine SCHEMEUPDATE auf diese Weise abgelehnt wird, empfehlen wir Ihnen, die acquirerresponsecode und acquirerresponsemessage zu überprüfen, um den Grund für die erfolglose Anfrage zu ermitteln. Wenn das Kartensystem verlangt hat, dass künftige Zahlungen gestoppt werden müssen, wird Abonnementmodul keine weiteren Zahlungen in dieser Abonnementreihenfolge verarbeiten.
Dies simuliert eine Situation, in der das Kartensystem eine Aufforderung des Kunden erhalten hat, weitere wiederkehrende Zahlungen zu stoppen. In diesem Fall empfehlen wir, sich mit dem Kunden in Verbindung zu setzen, um die Situation zu klären.
Testen mit Abonnements mit unserem JavaScript Library
Mit unserer Lösung JavaScript Library können Sie Zahlungen planen, die automatisch von Trust Payments Abonnementmodul in dem in der Anfrage angegebenen Intervall verarbeitet werden. Klicken Sie hier, um mehr über Abonnements zu erfahren.
-
Verarbeiten Sie eine kombinierte Anfrage THREEDQUERY, AUTH und SUBSCRIPTION mit dem Test PAN 4000000000000051.
Damit wird simuliert, dass der Kunde ein Abonnement mit der Karte 4000000000000051 beginnt.{
"payload":{
"accounttypedescription":"ECOM",
"baseamount":"1050",
"currencycode":"GBP",
"sitereference":"test_site12345",
"subscriptiontype":"RECURRING",
"subscriptionunit":"MONTH",
"subscriptionfrequency":"1",
"subscriptionnumber":"1",
"subscriptionfinalnumber":"12",
"subscriptionbegindate":"2022-01-01",
"credentialsonfile":"1",
"requesttypedescriptions":["THREEDQUERY","AUTH","SUBSCRIPTION"]
},
"iat":"1567701632",
"iss":"jwt.user"
}Stellen Sie sicher, dass die zurückgegebene Antwort AUTH errorcode 0, was bedeutet, dass die Anfrage erfolgreich verarbeitet wurde.
Klicken Sie hier für die vollständige Dokumentation. -
Hinter den Kulissen wird 3 Tage vor der Verarbeitung einer automatischen Abonnementzahlung automatisch eine SCHEMEUPDATE -Anfrage ausgelöst. Daraufhin sollte eine neue PAN 4111110000000914 abgerufen und im Datensatz SCHEMEUPDATE gespeichert werden, und die maskierte Version davon ist in Portal sichtbar (dies kann bis zu 3 Tage dauern). Wenn die nächste Abonnementzahlung in der Sequenz verarbeitet wird, wird die neue 4111110000000914 PAN verwendet.
Damit soll sichergestellt werden, dass sich die Kartendaten des Kunden nicht geändert haben (d. h. PAN war noch 4000000000000051) und unsere Datensätze anschließend aktualisiert wurden, um 4111110000000914 für künftige Abonnementzahlungen zu verwenden, da dem Kunden eine neue Karte ausgestellt wurde. -
3 Tage vor der Abwicklung der dritten Abo-Zahlung wird automatisch eine weitere SCHEMEUPDATE ausgelöst. Die SCHEMEUPDATE wird aktualisiert und zeigt errorcode 70000 und settlestatus 3 (dies kann bis zu 3 Tage dauern). Wenn eine SCHEMEUPDATE auf diese Weise abgelehnt wird, empfehlen wir Ihnen, die acquirerresponsecode und acquirerresponsemessage zu überprüfen, um den Grund für die erfolglose Anfrage zu ermitteln. Wenn das Kartensystem verlangt hat, dass künftige Zahlungen gestoppt werden müssen, wird Abonnementmodul keine weiteren Zahlungen in dieser Abonnementreihenfolge verarbeiten.
Dies simuliert eine Situation, in der das Kartensystem eine Aufforderung des Kunden erhalten hat, weitere wiederkehrende Zahlungen zu stoppen. In diesem Fall empfehlen wir, sich mit dem Kunden in Verbindung zu setzen, um die Situation zu klären.
