Testen SCHEMEUPDATE

Het volgende artikel geeft een overzicht van hoe u uw betalingsoplossing die gebruik maakt van SCHEMEUPDATE kunt testen.

Overzicht

SCHEMEUPDATE verzoeken worden ingediend bij de Trust Payments Gateway (TRU Connect) om bij de relevante kaartuitgever te controleren of de kaart van de klant die in een reeks terugkerende betalingen wordt gebruikt, nog steeds geldig en up-to-date is. Indien updates nodig zijn, zal Trust Payments automatisch zijn gegevens bijwerken zodat toekomstige betalingen in de reeks de bijgewerkte kaartgegevens gebruiken. Dit proces kan worden getest in onze testomgeving voordat het in de productieomgeving wordt ingezet, door de onderstaande instructies te volgen.

Vereisten:

U hebt toegang nodig tot uw testsite (voorafgegaan door "test_").
Voor uw testsite moet SCHEMEUPDATE ingeschakeld zijn op uw ECOM/MOTO account. Neem contact op met ons Support Team om dit aan te vragen.

Testen met terugkerende betalingen met onze Webservices API

Bij deze methode dient uw systeem op regelmatige tijdstippen een AUTH verzoek bij ons in, zoals afgesproken met de klant. Klik hier voor meer informatie.

Verwerk de bovengeschikte AUTH verzoek met test PAN 40000000000671.
Dit simuleert dat de klant een abonnement start met kaart 40000000000671.

{
  "payload":{
    "accounttypedescription":"ECOM",
    "baseamount":"1050",
    "currencyiso3a":"GBP",
    "sitereference":"test_site12345",
    "credentialsonfile":"1",
    "subscriptiontype":"RECURRING",
    "subscriptionnumber":"1",
    "requesttypedescriptions":["THREEDQUERY","AUTH"]
  },
  "iat":1559033849,
  "iss":"jwt.user"
}

Zorg ervoor dat het teruggestuurde AUTH antwoord errorcode 0, wat aangeeft dat het verzoek met succes is verwerkt.
Klik hier voor volledige documentatie.

Verwerk het SCHEMEUPDATE verzoek. Volgens de kaartsystemen moet dit verzoek 3 dagen voor de volgende terugkerende betaling worden ingediend.
Dit is om te controleren of de kaartgegevens van de klant niet zijn veranderd (d.w.z. PAN is nog steeds 40000000000671).

#!/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>

De SCHEMEUPDATE zal worden bijgewerkt tot settlestatus 100 binnen 3 dagen, en zal nieuwe pan 4000000000000051 hebben.
Dit simuleert dat de klant een nieuwe kaart 4000000000000051 krijgt.
Klik hier voor volledige documentatie.

Nieuwe teruggestuurde kaartgegevens kunnen ook een bijgewerkte expirydate.

Verwerk het ondergeschikt AUTH verzoek. Dit zal automatisch de door de SCHEMEUPDATE bijgewerkte kaartgegevens erven.
Dit simuleert dat de klant wordt gedebiteerd voor de tweede betaling, maar deze keer met de nieuwe kaart 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>

Zorg ervoor dat het teruggestuurde AUTH antwoord errorcode 0, wat aangeeft dat het verzoek met succes is verwerkt.
Klik hier voor volledige documentatie.

Vanaf hier zullen alle volgende aanvragen voor ondergeschikt AUTH verzoeken die worden ingediend bij Trust Payments en die de oorspronkelijke bovengeschikte verzoek gebruiken, de bijgewerkte PAN 4000000000000051 gebruiken.
Dit simuleert dat de klant wordt gedebiteerd voor volgende betalingen met de nieuwe kaart 4000000000000051.

Andere testgevallen

Door de gegeven PAN in de hierboven beschreven betalingsstroom te vervangen bij het verwerken van verzoeken in onze testomgeving, kunt u verschillende reacties van ons testsysteem ontlokken. Deze worden hieronder beschreven:

PAN ingediend in bovengeschikte AUTH verzoek	Resultaat in testomgeving
4000000000000671	Zodra de SCHEMEUPDATE is bijgewerkt tot settlestatus 100, zal de PAN worden bijgewerkt tot 4000000000000051 (dit kan 3 dagen duren), die zal worden gebruikt bij de volgende abonnementsbetalingen in de reeks. Dit simuleert dat de klant een nieuwe kaart krijgt, die bij toekomstige betalingen wordt gebruikt.
4000000000000051	Zodra de SCHEMEUPDATE is bijgewerkt tot settlestatus 100, zal de PAN worden bijgewerkt tot 4111110000000914 (dit kan 3 dagen duren), die zal worden gebruikt voor de volgende abonnementsbetalingen in de reeks. Dit simuleert dat de klant een nieuwe kaart krijgt, die bij toekomstige betalingen wordt gebruikt.
4111110000000914	De SCHEMEUPDATE zal updaten naar errorcode 70000 en settlestatus 3 (dit kan 3 dagen duren). Als een SCHEMEUPDATE op deze manier wordt geweigerd, raden wij u aan de acquirerresponsecode en acquirerresponsemessage om de reden voor de mislukte aanvraag te bepalen. Indien het kaartsysteem heeft verzocht toekomstige betalingen stop te zetten, mag uw systeem geen verdere betalingen in deze abonnementsreeks verwerken. Dit simuleert een situatie waarin het kaartsysteem een verzoek van de klant heeft gekregen om verdere terugkerende betalingen te stoppen. Vervolgens raden wij aan contact op te nemen met de klant voor opheldering van de situatie.

Testen met abonnementen met behulp van onze Payment Pages

Met onze oplossing Payment Pages kunt u betalingen plannen die automatisch worden verwerkt door de Trust Payments Abonnementsmodule op het in de aanvraag vermelde interval. Klik hier voor meer informatie over abonnementen.

Het verzoek (POST) naar Payment Pages moet abonnement-specifieke velden bevatten die het interval van het abonnement definiëren. Voltooi op uw testsite een transactie met Payment Pages met test PAN 4000000000000051.
Dit simuleert dat de klant een abonnement start met kaart 4000000000000051.

Voor testdoeleinden wordt aanbevolen een interval van 1 MONTH in te stellen, zoals in het onderstaande voorbeeld:

<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>

Klik hier voor de volledige documentatie.

Achter de schermen wordt 3 dagen voor de verwerking van een automatische abonnementsbetaling automatisch een SCHEMEUPDATE verzoek getriggerd. Vervolgens moet een nieuwe PAN 4111110000000914 worden opgehaald en opgeslagen in het SCHEMEUPDATE record en is de gemaskeerde versie hiervan zichtbaar in MyST (laat dit 3 dagen op zich wachten). Wanneer de volgende abonnementsbetaling in de reeks wordt verwerkt, wordt de nieuwe 4111110000000914 PAN gebruikt.
Dit is om te controleren of de kaartgegevens van de klant niet zijn veranderd (d.w.z. PAN was nog steeds 4000000000000051), en onze records werden vervolgens bijgewerkt om 4111110000000914 te gebruiken voor abonnementsbetalingen in de toekomst, omdat de klant een nieuwe kaart kreeg.
3 dagen voordat de derde abonnementsbetaling wordt verwerkt, wordt automatisch nog een SCHEMEUPDATE geactiveerd. De SCHEMEUPDATE wordt bijgewerkt tot errorcode 70000 en settlestatus 3 (dit kan 3 dagen duren). Als een SCHEMEUPDATE op deze manier wordt geweigerd, raden wij u aan de acquirerresponsecode en acquirerresponsemessage om de reden van de mislukte aanvraag te bepalen. Indien het kaartsysteem heeft verzocht toekomstige betalingen stop te zetten, zal de Abonnementsmodule geen verdere betalingen in deze abonnementsreeks verwerken.
Dit simuleert een situatie waarin het kaartsysteem een verzoek van de klant heeft gehad om verdere terugkerende betalingen te stoppen. Vervolgens raden wij aan contact op te nemen met de klant voor opheldering van de situatie.

Testen met abonnementen met behulp van onze JavaScript Library

Met onze oplossing JavaScript Library kunt u betalingen plannen die automatisch worden verwerkt door Trust Payments Abonnementsmodule op het in de aanvraag vermelde interval. Klik hier voor meer informatie over abonnementen.

Verwerk een gecombineerd THREEDQUERY, AUTH en SUBSCRIPTION verzoek met test PAN 4000000000000051.
Dit simuleert dat de klant een abonnement start met kaart 4000000000000051.

{
  "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"
}

Zorg ervoor dat het teruggestuurde AUTH antwoord errorcode 0, wat aangeeft dat het verzoek met succes is verwerkt.
Klik hier voor volledige documentatie.

Achter de schermen wordt 3 dagen voor de verwerking van een automatische abonnementsbetaling automatisch een SCHEMEUPDATE verzoek getriggerd. Vervolgens moet een nieuwe PAN 4111110000000914 worden opgehaald en opgeslagen in het SCHEMEUPDATE record en is de gemaskeerde versie hiervan zichtbaar in MyST (laat dit 3 dagen op zich wachten). Wanneer de volgende abonnementsbetaling in de reeks wordt verwerkt, wordt de nieuwe 4111110000000914 PAN gebruikt.
Dit is om te controleren of de kaartgegevens van de klant niet zijn veranderd (d.w.z. PAN was nog steeds 4000000000000051), en onze records werden vervolgens bijgewerkt om 4111110000000914 te gebruiken voor abonnementsbetalingen in de toekomst, omdat de klant een nieuwe kaart kreeg.
3 dagen voordat de derde abonnementsbetaling wordt verwerkt, wordt automatisch nog een SCHEMEUPDATE geactiveerd. De SCHEMEUPDATE wordt bijgewerkt tot errorcode 70000 en settlestatus 3 (dit kan 3 dagen duren). Als een SCHEMEUPDATE op deze manier wordt geweigerd, raden wij u aan de acquirerresponsecode en acquirerresponsemessage om de reden van de mislukte aanvraag te bepalen. Indien het kaartsysteem heeft verzocht toekomstige betalingen stop te zetten, zal de Abonnementsmodule geen verdere betalingen in deze abonnementsreeks verwerken.
Dit simuleert een situatie waarin het kaartsysteem een verzoek van de klant heeft gehad om verdere terugkerende betalingen te stoppen. Vervolgens raden wij aan contact op te nemen met de klant voor opheldering van de situatie.

Meer lezen over dit onderwerp