Account checks
An ACCOUNTCHECK request allows a card to be validated by checking the cardholder’s first line of address, the cardholder’s postcode and the security code, to ensure the details entered by the customer are valid. Click here to learn more about the checks performed.
Requirements
- Account checks are only available for certain acquiring banks. Before you begin, please contact our Support Team and ensure your acquiring bank supports this functionality.
- Account checks can only be performed for card-based payment methods.

Failure to submit these fields will result in a “60025” (Invalid request) error being returned in the response.
Update your payment form
You can update your payment form to instruct our JavaScript library to process an Account check prior to performing a standard transaction. This is done by specifying custom requestTypes, as shown in the example below:
<html> <head> </head> <body> <div id="st-notification-frame"></div> <form id="st-form" action="https://www.example.com" method="POST"> <div id="st-card-number" class="st-card-number"></div> <div id="st-expiration-date" class="st-expiration-date"></div> <div id="st-security-code" class="st-security-code"></div> <button type="submit" id="st-form__submit" class="st-form__submit"> Pay securely </button> </form> <script src=<DOMAIN>/js/v2/st.js></script> <script> (function() { var st = SecureTrading({ jwt: 'INSERT YOUR JWT HERE' }); st.Components({"requestTypes":["ACCOUNTCHECK","THREEDQUERY","AUTH"]}); })(); </script> </body> </html>
Replace <DOMAIN> with a supported domain. Click here for a full list.
Testing
Use the credentials provided on this page to test your solution.
When you sign up, you will be provided with a “live” account and a “test” account (the latter is prefixed with “test_”).
When testing, ensure requests submitted to Trust Payments reference your test sitereference.

Before you begin testing…
Please be aware of the following notes:
- Most fields submitted to our test system will be accepted. Any data breaching its defined specification will return an error message.
- Any test data that generates a successful response when submitted while a merchant is in test mode, will produce a declined response when a merchant is switched into live mode. In some cases, the test data may return an error response.
- Our test system attempts to simulate responses in a similar fashion to the live system. However, depending on your acquirer you may find some responses differ slightly from those given by the test system.
- In the interest of security, we recommend against using real payment details when using your test account.
- We recommend specifying the main amount “10.50” when testing. Other amounts can be used but may return unexpected responses.
- For those using Payment Pages, if you’re unsure where to start with your testing, you may find this resource helpful.
Test card details
The table below lists test card numbers and customer information that can be submitted to our test bank, along with the responses that should be expected in return.


- A baseamount of 70000 (£700.00) will always return a declined response from the test bank.
- A baseamount of 60010 (£600.10) will always return a bank system error from the test bank.
- Using baseamount 1050 (£10.50) will not generate an error.
3-D Secure v2
The following payment credentials can be used for testing 3-D Secure v2 (a form of SCA):
(3DSv2) Test Case 1: Successful Frictionless 3-D Secure Authentication & Successful Authorisation |
||
Card type | PAN | Handling the response |
AMEX | 340000000001007 | THREEDQUERY Enrolled: Y Status: Y AUTH Error code: 0 – Ok |
DINERS / DISCOVER | 6011000000001002 | |
JCB | 3337000000000008 | |
MASTERCARD | 5200000000001005 | |
VISA (3-D Secure v2.1.0) | 4000000000001000 | |
VISA (3-D Secure v2.2.0) | 4000000000002701 |
(3DSv2) Test Case 2: Failed Frictionless 3-D Secure Authentication & Failed Authorisation |
||
Card type | PAN | Handling the response |
AMEX | 340000000001015 | THREEDQUERY Enrolled: Y Status: N AUTH Error code: 60022 – Unauthenticated |
DINERS / DISCOVER | 6011000000001010 | |
JCB | 3337000000000990 | |
MASTERCARD | 5200000000001013 | |
VISA (3-D Secure v2.1.0) | 4000000000001018 | |
VISA (3-D Secure v2.2.0) | 4000000000002925 |
(3DSv2) Test Case 3: Attempts Stand-In Frictionless 3-D Secure Authentication & Successful Authorisation |
||
Card type | PAN | Handling the response |
AMEX | 340000000001023 | THREEDQUERY Enrolled: Y Status: A AUTH Error code: 0 -Ok |
DINERS / DISCOVER | 6011000000001028 | |
JCB | 3337000000007045 | |
MASTERCARD | 5200000000001021 | |
VISA (3-D Secure v2.1.0) | 4000000000001026 | |
VISA (3-D Secure v2.2.0) | 4000000000002719 |
(3DSv2) Test Case 4: Unavailable Frictionless 3-D Secure Authentication from the Issuer & Successful Authorisation |
||
Card type | PAN | Handling the response |
AMEX | 340000000001031 | THREEDQUERY Enrolled: Y Status: U AUTH Error code: 0 – Ok |
DINERS / DISCOVER | 6011000000001036 | |
JCB | 3337000000000735 | |
MASTERCARD | 5200000000001039 | |
VISA (3-D Secure v2.1.0) | 4000000000001034 | |
VISA (3-D Secure v2.2.0) | 4000000000002313 |
(3DSv2) Test Case 5: Rejected Frictionless 3-D Secure Authentication by the Issuer & Failed Authorisation |
||
Card type | PAN | Handling the response |
AMEX | 340000000001049 | THREEDQUERY Enrolled: Y Status: R AUTH Error code: 60022 – Unauthenticated |
DINERS / DISCOVER | 6011000000001044 | |
JCB | 3337000000000321 | |
MASTERCARD | 5200000000001047 | |
VISA (3-D Secure v2.1.0) | 4000000000001042 | |
VISA (3-D Secure v2.2.0) | 4000000000002537 |
(3DSv2) Test Case 6: 3-D Secure Authentication Not Available on Lookup & Successful Authorisation |
||
Card type | PAN | Handling the response |
AMEX | 340000000001056 | THREEDQUERY Enrolled: U Status: None AUTH Error code: 0 – Ok |
DINERS / DISCOVER | 6011000000001051 | |
JCB | 3337000000006765 | |
MASTERCARD | 5200000000001054 | |
VISA (3-D Secure v2.1.0) | 4000000000001059 | |
VISA (3-D Secure v2.2.0) | 4000000000002990 |
(3DSv2) Test Case 7: Error on Lookup & Successful Authorisation |
||
Card type | PAN | Handling the response |
AMEX | 340000000001064 | THREEDQUERY Enrolled: U Status: None AUTH Error code: 0 – Ok |
DINERS / DISCOVER | 6011000000001069 | |
JCB | 3337000000000016 | |
MASTERCARD | 5200000000001062 | |
VISA (3-D Secure v2.1.0) | 4000000000001067 | |
VISA (3-D Secure v2.2.0) | 4000000000002446 |
(3DSv2) Test Case 8: Timeout on cmpi_lookup Transaction & Successful Authorisation |
||
Card type | PAN | Handling the response |
AMEX | 340000000001072 | THREEDQUERY Enrolled: U Status: None AUTH Error code: 0 – Ok |
DINERS / DISCOVER | 6011000000001077 | |
JCB | 3337000000000081 | |
MASTERCARD | 5200000000001070 | |
VISA (3-D Secure v2.1.0) | 4000000000001075 | |
VISA (3-D Secure v2.2.0) | 4000000000002354 |
(3DSv2) Test Case 9: Successful Step Up 3-D Secure Authentication & Successful Authorisation |
||
Card type | PAN | Handling the response |
AMEX | 340000000001098 | THREEDQUERY Enrolled: Y Status: C AUTH Error code: 0 – Ok |
DINERS / DISCOVER | 6011000000001093 | |
JCB | 3337000000200004 | |
MASTERCARD | 5200000000001096 | |
VISA (3-D Secure v2.1.0) | 4000000000001091 | |
VISA (3-D Secure v2.2.0) | 4000000000002503 |
(3DSv2) Test Case 10: Failed Step Up 3-D Secure Authentication & No Authorisation |
||
Card type | PAN | Handling the response |
AMEX | 340000000001106 | THREEDQUERY Enrolled: Y Status: C AUTH Not performed |
DINERS / DISCOVER | 6011000000001101 | |
JCB | 3337000000200087 | |
MASTERCARD | 5200000000001104 | |
VISA (3-D Secure v2.1.0) | 4000000000001109 | |
VISA (3-D Secure v2.2.0) | 4000000000002370 |
(3DSv2) Test Case 11: Step Up 3-D Secure Authentication is Unavailable & Successful Authorisation |
||
Card type | PAN | Handling the response |
AMEX | 340000000001114 | THREEDQUERY Enrolled: Y Status: C AUTH Error code: 0 – Ok |
DINERS / DISCOVER | 6011000000001119 | |
JCB | 3337000000200079 | |
MASTERCARD | 5200000000001112 | |
VISA (3-D Secure v2.1.0) | 4000000000001117 | |
VISA (3-D Secure v2.2.0) | 4000000000002420 |
(3DSv2) Test Case 12: Error on 3-D Secure Authentication & No Authorisation |
||
Card type | PAN | Handling the response |
AMEX | 340000000001122 | THREEDQUERY Enrolled: Y Status: C AUTH Not performed |
DINERS / DISCOVER | 6011000000001127 | |
JCB | 3337000000200046 | |
MASTERCARD | 5200000000001120 | |
VISA (3-D Secure v2.1.0) | 4000000000001125 | |
VISA (3-D Secure v2.2.0) | 4000000000002644 |
(3DSv2) Test Case 13: Bypassed 3-D Secure Authentication & Successful Authorisation |
||
Card type | PAN | Handling the response |
AMEX | 340000000001080 | THREEDQUERY Enrolled: B Status: None AUTH Error code: 0 – Ok |
DINERS / DISCOVER | 6011000000001085 | |
JCB | 3337000000000537 | |
MASTERCARD | 5200000000001088 | |
VISA (3-D Secure v2.1.0) | 4000000000001083 | |
VISA (3-D Secure v2.2.0) | 4000000000002560 |
3-D Secure v1
The following payment credentials can be used for testing 3-D Secure v1 (a form of SCA):
(3DSv1) Test Case 1: Successful 3-D Secure Authentication & Successful Authorisation |
||
Card type | PAN | Handling the response |
AMEX | 340000000003961 | THREEDQUERY Enrolled: Y Status: None AUTH Error code: 0 – Ok |
DINERS | 3005000000006246 | |
DISCOVER | 6011000000000004 | |
JCB | 3520000000000922 | |
MASTERCARD | 5200000000000007 | |
VISA | 4000000000000002 |
(3DSv1) Test Case 2: Failed Signature & No Authorisation |
||
Card type | PAN | Handling the response |
AMEX | 340000000006022 | THREEDQUERY Enrolled: Y Status: None AUTH Not performed |
DINERS | 3005000000004373 | |
DISCOVER | 6011000000000012 | |
JCB | 3520000000002811 | |
MASTERCARD | 5200000000000015 | |
VISA | 4000000000000010 |
(3DSv1) Test Case 3: Failed Authentication & No Authorisation |
||
Card type | PAN | Handling the response |
AMEX | 340000000000033 | THREEDQUERY Enrolled: Y Status: None AUTH Not performed |
DINERS | 3005000000005925 | |
DISCOVER | 6011000000000020 | |
JCB | 3520000000009931 | |
MASTERCARD | 5200000000000023 | |
VISA | 4000000000000028 |
(3DSv1) Test Case 4: Attempts/Non-Participating & Successful Authorisation |
||
Card type | PAN | Handling the response |
AMEX | 340000000003391 | THREEDQUERY Enrolled: Y Status: A AUTH Error code: 0 – Ok |
DINERS | 3005000000005271 | |
DISCOVER | 6011000000000038 | |
JCB | 3520000000004767 | |
MASTERCARD | 5200000000000908 | |
VISA | 4000000000000101 |
(3DSv1) Test Case 6: Not Enrolled & Successful Authorisation |
||
Card type | PAN | Handling the response |
AMEX | 340000000008135 | THREEDQUERY Enrolled: N Status: None AUTH Error code: 0 – Ok |
DINERS | 3005000000007269 | |
DISCOVER | 6011000000000053 | |
JCB | 3520000000006903 | |
MASTERCARD | 5200000000000056 | |
VISA | 4000000000000051 |
(3DSv1) Test Case 7: Unavailable & Successful Authorisation |
||
Card type | PAN | Handling the response |
AMEX | 340000000007780 | THREEDQUERY Enrolled: U Status: None AUTH Error code: 0 – Ok |
DINERS | 3005000000006030 | |
DISCOVER | 6011000000000061 | |
JCB | 3520000000002423 | |
MASTERCARD | 5200000000000064 | |
VISA | 4000000000000069 |
(3DSv1) Test Case 8: Merchant Not Active & Successful Authorisation |
||
Card type | PAN | Handling the response |
AMEX | 340000000008416 | THREEDQUERY Enrolled: U Status: None AUTH Error code: 0 – Ok |
DINERS | 3005000000004837 | |
DISCOVER | 6011000000000079 | |
JCB | 3520000000006549 | |
MASTERCARD | 5200000000000072 | |
VISA | 4000000000000077 |
(3DSv1) Test Case 9: cmpi_lookup error & Successful Authorisation |
||
Card type | PAN | Handling the response |
AMEX | 340000000006337 | THREEDQUERY Enrolled: U Status: None AUTH Error code: 0 – Ok |
DINERS | 3005000000009877 | |
DISCOVER | 6011000000000087 | |
JCB | 3520000000002175 | |
MASTERCARD | 5200000000000080 | |
VISA | 4000000000000085 |
(3DSv1) Test Case 10: cmpi_authenticate error & No Authorisation |
||
Card type | PAN | Handling the response |
AMEX | 340000000009299 | THREEDQUERY Enrolled: Y Status: None AUTH Not performed |
DINERS | 3005000000005602 | |
DISCOVER | 6011000000000095 | |
JCB | 3520000000006861 | |
MASTERCARD | 5200000000000098 | |
VISA | 4000000000000093 |
(3DSv1) Test Case 11: Authentication Unavailable & Successful Authorisation |
||
Card type | PAN | Handling the response |
AMEX | 340000000000116 | THREEDQUERY Enrolled: Y Status: None AUTH Error code: 0 – Ok |
DINERS | 3005000000007376 | |
DISCOVER | 6011000000000103 | |
JCB | 3520000000005780 | |
MASTERCARD | 5200000000000031 | |
VISA | 4000000000000036 |
(3DSv1) Test Case 12: Bypassed Authentication & Successful Authorisation |
||
Card type | PAN | Handling the response |
AMEX | 340099000000001 | THREEDQUERY Enrolled: B Status: None AUTH Error code: 0 – Ok |
DINERS | 3000990000000006 | |
DISCOVER | 6011990000000006 | |
JCB | 3500990000000001 | |
MASTERCARD | 5200990000000009 | |
VISA | 4000990000000004 |
3-D Secure status testing
To test for different 3-D Secure status values, follow the instructions displayed in the authentication prompt shown on the page (an example is shown below). In the textbox provided, you can enter different PIN values to test for different cases.

For Payment Pages:
With 3-D Secure enabled on your site reference, process a payment using one of the card numbers listed above and your browser will display an authentication prompt with instructions.
For JavaScript Library implementations:
After your payment form has been updated to reference our JavaScript library, process a payment using one of the card numbers listed above and your browser will display an authentication prompt with instructions.
For Mobile SDK implementations:
After your Android or iOS app has been updated to utilise our Mobile SDK, process a payment using one of the card numbers listed above and your app will display an authentication prompt with instructions.
The authentication prompt will only be displayed for non-frictionless test card details.
Frictionless cards will bypass authentication. In this case, the payment will be processed immediately (without being prompted by the browser for information).
Follow the instructions displayed within the authentication prompt to complete the payment:

Testing AVS and security code checks
If you haven’t already, please read our AVS and Security code documentation before testing:
Link to Payment Pages docs / Link to API docs
The following tables list test details that can be submitted to obtain different responses from the AVS and Security Code Checks. These details can be used with most major payment types.

Premise
Billing premise | Security response | Security response caption |
No 789 | 2 | Matched |
No 123 | 4 | Not Matched |
No 333 | 1 | Not Checked |
Leave blank | 0 | Not Given |
Postcode / ZIP code
Billing postcode | Security response | Security response caption | |
UK | US | ||
TE45 6ST | 55555 | 2 | Matched |
TE12 3ST | 12345 | 4 | Not Matched |
TE33 3ST | 33333 | 1 | Not Checked |
Leave blank | Leave blank | 0 | Not Given |
Security code
Security code | AMEX security code | Security response | Security response |
123 | 1234 | 2 | Matched |
214 | 2144 | 4 | Not Matched |
333 | 3333 | 1 | Not Checked |
Leave blank | Leave blank | 0 | Not Given |
Testing non-card payment methods

Link to Payment Pages docs / Link to Webservices API docs
Testing recurring payments
Testing for the acquirer advice code
When processing recurring payments, some acquirers may return an acquirer advice code in the response. The acquirer advice code is a numeric value used to indicate if further recurring payments can be processed for the given card.
Code | Description | Action |
0 | N/A | No action required |
1 | New account information available (Mastercard only) | Query customer for updated payment details |
2 | Cannot approve at this time | Try again later. If you are continuing to have difficulties, please contact your acquiring bank |
4 | Do not try again | Do not process further recurring transactions |
8 | Payment blocked by card scheme |
Where to find the acquirer advice code
- This code is returned in your daily subscription email report.
- It’s viewable within MyST by selecting the additional field to be displayed on the transaction search page. It can also be viewed on the single transaction view.
- Additionally, for those who have processed a recurring AUTH transaction using the API, the code is returned in the acquireradvicecode field in the response.
How to test for different acquirer advice codes
You can test that your system responds appropriately to different acquirer advice codes by processing transactions with the following attributes:
Visa | ||
Acquirer advice code returned | Card number | Base amount |
0 | 4111111111111111 | 1050 |
2 | 4000000000000671 | 1002 |
4 | 4000000000000671 | 1004 |
8 | 4000000000000671 | 1008 |

Mastercard | ||
Acquirer advice code returned | Card number | Base amount |
0 | 5100000000000511 | 1050 |
1 | 5100000000000271 | 1001 |
2 | 5100000000000271 | 1002 |
4 | 5100000000000271 | 1004 |
8 | 5100000000000271 | 1008 |
Testing Protect Plus
Please refer to the following resources when testing Protect Plus:
- Testing Protect Plus using Payment Pages
- Testing Protect Plus using JavaScript Library
- Testing Protect Plus using iOS SDK
Testing DCC
Please refer to the following resources when testing DCC:
Using Account Check to verify customer’s details
Follow these instructions when using Account Checks to verify the customer’s details prior to processing a payment.

Prerequisites

If you are unsure, please contact our Support Team for assistance.

To process an e-commerce Account Check that is authenticated with 3-D Secure, you will need to utilise our JavaScript Library instead of the solution described below. Click here to get started.
The following content should only be utilised by merchants processing Account Checks that are Mail or Telephone Order (MOTO), Merchant Initiated Transactions (MIT), or using other workflows that are exempt from the PSD2 mandate.

Failure to submit these fields will result in a “60025” (Invalid request) error being returned in the response. Click here for further information.

- Account checks are only available for certain acquiring banks. Before you begin, please contact our Support Team and ensure your acquiring bank supports this functionality.
- Account checks can only be performed for card-based payment methods.
Mandate considerations
Visa and Mastercard have mandated that you must obtain cardholder consent if storing card details for future use, and that these must be flagged at the time of the first authorisation, by submitting the credentialsonfile field in your requests. To do so, you will need to ensure the ACCOUNTCHECK request submitted includes the additional field credentialsonfile, with value set to “1”.
You must also flag any subsequent payments that are utilising previously-stored credentials, by including the credentialsonfile field in these requests with value set to “2”.
Click here to learn more about Credentials on File.
Checks performed
All Account Checks processed will perform checks on the cardholder’s first line of address, the cardholder’s postcode and the security code, to ensure the details entered by the customer are valid.
Click here to learn more about these checks.
Process overview
-
- Merchant submits ACCOUNTCHECK request.
- Trust Payments validates the request and contacts the bank.
- The acquiring bank will contact the card issuer to perform AVS and security code checks.
- Trust Payments receives results of the request and passes this back to the merchant.
- Merchant receives and interprets this response.

The customer’s account is not debited when an ACCOUNTCHECK request is performed.

ACCOUNTCHECK request
The fields required in an ACCOUNTCHECK request are the same as a standard AUTH request, except with the following differences:
- The baseamount can be “0”. A non-zero amount can be submitted – this will be inherited in any subsequent requests that reference this Account check as its parent, unless overridden with a new amount.
- Additional field credentialsonfile must be submitted with value “1”. (See below)
Field specification
Field | Format | Description | |
![]() |
credentialsonfile XPath: /operation/credentialsonfile |
Numeric (1) | This must be set to “1”, to indicate the customer agreed for the payment credentials to be stored for future transactions. See below for further information. |
You can submit any field that you can submit in an AUTH request and these will be inherited by any subsequent child requests. Click here to learn more.
The following is an example of an ACCOUNTCHECK request:
#!/usr/bin/python import securetrading stconfig = securetrading.Config() stconfig.username = "[email protected]" stconfig.password = "Password1^" st = securetrading.Api(stconfig) accountcheck= { "currencyiso3a": "GBP", "requesttypedescriptions": ["ACCOUNTCHECK"], "sitereference": "test_site12345", "baseamount": "0", "orderreference": "My_Order_123", "accounttypedescription": "MOTO", "pan": "4111111111111111", "expirydate": "12/2020", "securitycode": "123", "billingpremise": "789", "billingpostcode": "TE45 6ST", "credentialsonfile": "1" } strequest = securetrading.Request() strequest.update(accountcheck) 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' => '[email protected]', 'password' => 'Password1^', ); $requestData = array( 'currencyiso3a' => 'GBP', 'requesttypedescriptions' => array('ACCOUNTCHECK'), 'sitereference' => 'test_site12345', 'baseamount' => '0', 'orderreference' => 'My_Order_123', 'accounttypedescription' => 'MOTO', 'pan' => '4111111111111111', 'expirydate' => '12/2020', 'securitycode' => '123', 'billingpremise' => '789', 'billingpostcode' => 'TE45 6ST', 'credentialsonfile' => '1' ); $api = \Securetrading\api($configData); $response = $api->process($requestData); var_dump($response->toArray()); ?>
curl --user [email protected]:Password1^ <DOMAIN>/json/ -H "Content-type: application/json" -H "Accept: application/json" -X POST -d '{ "alias": "[email protected]", "version": "1.00", "request": [{ "currencyiso3a": "GBP", "requesttypedescriptions": ["ACCOUNTCHECK"], "sitereference": "test_site12345", "baseamount": "0", "orderreference": "My_Order_123", "accounttypedescription": "MOTO", "pan": "4111111111111111", "expirydate": "12/2020", "securitycode": "123", "billingpremise": "789", "billingpostcode": "TE45 6ST", "credentialsonfile": "1" }]}'
{"alias":"[email protected]","version":"1.00","request":[{"currencyiso3a":"GBP","requesttypedescriptions":["ACCOUNTCHECK"],"sitereference":"test_site12345","baseamount":"0","orderreference":"My_Order_123","accounttypedescription":"MOTO","pan":"4111111111111111","expirydate":"12\/2020","securitycode":"123","billingpremise":"789","billingpostcode":"TE45 6ST","credentialsonfile":"1"}]}
<?xml version='1.0' encoding='utf-8'?> <requestblock version="3.67"> <alias>[email protected]</alias> <request type="ACCOUNTCHECK"> <merchant> <orderreference>My_Order_123</orderreference> </merchant> <billing> <amount currencycode="GBP">0</amount> <postcode>TE45 6ST</postcode> <premise>789</premise> <payment> <pan>4111111111111111</pan> <securitycode>123</securitycode> <expirydate>12/2020</expirydate> </payment> </billing> <operation> <accounttypedescription>MOTO</accounttypedescription> <sitereference>test_site12345</sitereference> <credentialsonfile>1</credentialsonfile> </operation> </request> </requestblock>
Replace <DOMAIN> with a supported domain. Click here for a full list.
ACCOUNTCHECK response
After the request has been processed, you will receive a single response that contains the response to the ACCOUNTCHECK request:
{ u 'requestreference': u 'Ar2xj1hjr', u 'version': u '1.00', u 'response': [{ u 'transactionstartedtimestamp': u '2016-12-07 16:12:00', u 'livestatus': u '0', u 'issuer': u 'SecureTrading Test Issuer1', u 'dccenabled': u '0', u 'settleduedate': u '2016-12-07', u 'errorcode': u '0', u 'orderreference': u 'My_Order_123', u 'tid': u '27882788', u 'merchantnumber': u '00000000', u 'merchantcountryiso2a': u 'GB', u 'transactionreference': u '23-9-80023', u 'merchantname': u 'Test Merchant', u 'paymenttypedescription': u 'VISA', u 'baseamount': u '0', u 'accounttypedescription': u 'MOTO', u 'acquirerresponsecode': u '00', u 'requesttypedescription': u 'ACCOUNTCHECK', u 'securityresponsesecuritycode': u '2', u 'currencyiso3a': u 'GBP', u 'authcode': u 'TEST46', u 'errormessage': u 'Ok', u 'operatorname': u '[email protected]', u 'securityresponsepostcode': u '2', u 'maskedpan': u '411111######1111', u 'securityresponseaddress': u '2', u 'issuercountryiso2a': u 'US', u 'settlestatus': u '0', u 'credentialsonfile': u '1' }] }
array(3) { ["requestreference"] => string(9) "A4cenptwx" ["version"] => string(4) "1.00" ["response"] => array(1) { [0] => array(28) { ["transactionstartedtimestamp"] => string(19) "2016-12-09 11:04:29" ["livestatus"] => string(1) "0" ["issuer"] => string(26) "SecureTrading Test Issuer1" ["dccenabled"] => string(1) "0" ["settleduedate"] => string(10) "2016-12-09" ["errorcode"] => string(1) "0" ["baseamount"] => string(1) "0" ["tid"] => string(8) "27882788" ["merchantnumber"] => string(8) "00000000" ["securityresponsepostcode"] => string(1) "2" ["transactionreference"] => string(10) "72-9-80018" ["merchantname"] => string(13) "Test Merchant" ["paymenttypedescription"] => string(4) "VISA" ["orderreference"] => string(12) "My_Order_123" ["accounttypedescription"] => string(4) "MOTO" ["acquirerresponsecode"] => string(2) "00" ["requesttypedescription"] => string(12) "ACCOUNTCHECK" ["securityresponsesecuritycode"] => string(1)"2" ["currencyiso3a"] => string(3) "GBP" ["authcode"] => string(6) "TEST39" ["errormessage"] => string(2) "Ok" ["operatorname"] => string(23) "[email protected]" ["merchantcountryiso2a"] => string(2) "GB" ["maskedpan"] => string(16) "411111######1111" ["securityresponseaddress"] => string(1) "2" ["issuercountryiso2a"] => string(2) "US" ["settlestatus"] => string(1) "0" ["credentialsonfile"] => string(1) "1" } } }
{"requestreference":"W23-q3wa45ge","version":"1.00","response":[{"transactionstartedtimestamp":"2016-12-07 16:16:39","livestatus":"0","issuer":"SecureTrading Test Issuer1","dccenabled":"0","settleduedate":"2016-12-07","errorcode":"0","baseamount":"0","tid":"27882788","merchantnumber":"00000000","securityresponsepostcode":"2","transactionreference":"23-9-80024","merchantname":"Test Merchant","paymenttypedescription":"VISA","orderreference":"My_Order_123","accounttypedescription":"MOTO","acquirerresponsecode":"00","requesttypedescription":"ACCOUNTCHECK","securityresponsesecuritycode":"2","currencyiso3a":"GBP","authcode":"TEST53","errormessage":"Ok","operatorname":"[email protected]","merchantcountryiso2a":"GB","maskedpan":"411111######1111","securityresponseaddress":"2","issuercountryiso2a":"US","settlestatus":"0","credentialsonfile":"1"}],"secrand":"NunVEQ"}
<?xml version='1.0' encoding='utf-8'?> <responseblock version="3.67"> <requestreference>X575647667</requestreference> <response type="ACCOUNTCHECK"> <merchant> <merchantname>Test Merchant</merchantname> <orderreference>My_Order_123</orderreference> <tid>27882788</tid> <merchantnumber>00000000</merchantnumber> <merchantcountryiso2a>GB</merchantcountryiso2a> <operatorname>[email protected]</operatorname> </merchant> <transactionreference>16-9-1</transactionreference> <billing> <amount currencycode="GBP">0</amount> <payment type="VISA"> <issuer>SecureTrading Test Issuer1</issuer> <issuercountry>US</issuercountry> <pan>411111######1111</pan> </payment> <dcc enabled="0"/> </billing> <authcode>TEST53</authcode> <live>0</live> <error> <message>Ok</message> <code>0</code> </error> <timestamp>2013-01-16 10:48:17</timestamp> <acquirerresponsecode>00</acquirerresponsecode> <security> <address>2</address> <postcode>2</postcode> <securitycode>2</securitycode> </security> <settlement> <settleduedate>2013-01-16</settleduedate> <settlestatus>0</settlestatus> </settlement> <operation> <accounttypedescription>MOTO</accounttypedescription> <credentialsonfile>1</credentialsonfile> </operation> </response> <secrand>bByuPvGz9Hcm</secrand> </responseblock>
Handling the response
- Ensure that the errorcode value returned is “0”, indicating success. (You must not store credentials if an error has occurred)
- Check the values returned in the securityresponseaddress, securityresponsepostcode and securityresponsesecuritycode fields and only proceed if business requirements have been satisfied. (More info provided below)

Field | Format | Description | |
![]() |
securityresponseaddress XPath: /security/address |
Numeric (1) | “0” Not given – Your system did not provide the acquiring bank the information required to perform this check.
“1” Not checked – The acquiring bank did not perform this check on the information you provided in the request. “2” Matched – The information you provided in the request matches the information obtained by the acquiring bank, from the customer’s payment issuer. “4” Not matched – The information you provided in the request does not match the information obtained by the acquiring bank, from the customer’s payment issuer. |
![]() |
securityresponsepostcode XPath: /security/postcode |
Numeric (1) | |
![]() |
securityresponsesecuritycode XPath: /security/securitycode |
Numeric (1) |