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.
- If you’re unsure where to start with your testing, you may find these resources 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):
| Test case | Visa | Mastercard | American Express |
| Success frictionless | 4000000000001026 | 5200000000001005 | 340000000001007 |
| Success step-up | 4000000000001091 | 5200000000001096 | 340000000001098 |
| Failed frictionless | 4000000000001018 | 5200000000001013 | 340000000001015 |
| Failed step-up | 4000000000001109 | 5200000000001104 | 340000000001106 |
| Declined | 4242424242424242 | 5100000000000412 | 300000000000512 |
3-D Secure v1
The following payment credentials can be used for testing 3-D Secure v1 (a form of SCA):
Visa-branded cards
| Visa |
|||||
| Credit | Debit | V Pay | Electron | Purchasing | |
| Enrolled (Y) | 4111110000000211 | 4006260000002473 | 4370000000000111 | 4245190000000311 | 4484000000000411 |
| Not enrolled (N) | 4111110000000021 | 4006260000002481 | 4370000000000921 | 4245190000000121 | 4484000000000221 |
| Unknown enrollment (U) | 4111110000000401 | 4006260000002408 | 4370000000002307 | 4245190000000501 | 4484000000000601 |
Mastercard-branded cards
| Test case | Mastercard |
|||
| Credit | Debit | Maestro (Intl.) | Maestro (UK) | |
| Enrolled (Y) | 5100000000000511
2221000000000611 |
5124990000000911 | 5000000000000611 | 6759000000000711 |
| Not enrolled (N) | 5100000000000321
2221000000000991 |
5124990000000721 | 5000000000000421 | 6759000000000521 |
| Unknown enrollment (U) | 5100000000000701
2221000000000801 |
5124990000000101 | 5000000000000801 | 6759000000000901 |
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.
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:
Non 3-D Secure
The following card types are not currently processed using 3-D Secure (a form of SCA):
| Card type | Authorisation | Decline | Expiry date | Security code |
| DINERS | 3000000000000111 | 3000000000000012 | 12/2030 | 123 |
| DISCOVER | 6011000000000301 | 6011000000000202 | 12/2030 | 123 |
| JCB | 3528000000000411 | 3528000000000312 | 12/2030 | 123 |
After the payment has been processed, the error code and status values stored with the processed AUTH are used to convey the final outcome.
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 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
If you haven’t already, please read our Protect Plus document before testing:
Link to Payment Pages docs / Link to API docs
Use the following baseamount values in RISKDEC requests to simulate the different possible responses from the Protect Plus checks:
| baseamount | Possible fraudcontrolresponsecode returned | fraudcontrolshieldstatuscode returned |
| 1011, 2011, 3011 | 0100, 0150 | “ACCEPT” |
| 1033, 2033, 3033 | 0300, 0330, 0500 | “CHALLENGE” |
| 1044, 2044, 3044 | 0250, 0400, 0600, 0700, 0800, 1300 | “DENY” |
Testing DCC
If you haven’t already, please read our DCC document before testing:
Link to Payment Pages docs / Link to API docs
The card numbers listed in this test section are associated with specific local currencies. During your integration, you can use the following international test card details in order to test your system for successful and declined DCC transactions.
Successful authorisations
| Country code | Currency code | Visa Credit | Mastercard Credit |
| DE | EUR | 4500000000000007 | 5500000000000004 |
| GB | GBP | 4300000000002211 | 5311110000001511 |
| JP | JPY | 4900400000000005 | 5590410000000006 |
| US | USD | 4900460000000009 | 5590470000000018 |
Declined authorisations
| Country code | Currency code | Visa Credit | Mastercard Credit |
| DE | EUR | 4500000000002482 | 5500000000002422 |
| GB | GBP | 4300000000002492 | 5311110000002402 |
| JP | JPY | 4900400000002472 | 5590410000002432 |
| US | USD | 4900460000002492 | 5590470000002402 |
Best practices
When receiving our response, your system will need to perform the following checks on the values returned (where applicable) to ensure the request was processed successfully.
Error code
The errorcode is a fundamentally important field as it displays the outcome of the submitted request. It is returned in every response from Trust Payments.
If the errorcode is “0”, this indicates the request was processed successfully.
It is imperative that you have a process in place to check the final status of the processed request, by looking at the values of the other fields returned.
If the errorcode is “30000”, this indicates a field error.
If you look at the errordata field returned, this typically contains the name of the field that was deemed invalid. You will need to retry the request, ensuring all required fields have been submitted, and that all submitted field values follow our specification.
If the errorcode is “70000”, this indicates a payment was declined by your bank.
We recommend that you show an error message to the customer and allow them to try a different method of payment.
If the errorcode is “60010”, “60034” or “99999”, there has been a problem processing the request and the final status is not known.
This can be due to a communication problem with a bank or third party. In such cases, we recommend informing the customer of the problem and to contact you to query the issue. You will need to contact our Support team, providing a copy of the entire request submitted and response returned, and we will contact the relevant parties to establish the status of the request. In the interest of security, ensure you omit or mask sensitive field values, such as card details.
If the errorcode is not listed above, please refer to our full list of errorcodes for assistance. If you need further help, please contact our Support team.
Settle status
It is important to check the value of the settlestatus when processing an AUTH or REFUND request, as this indicates if Settlement will be performed. Here are the basics:
If the settlestatus is “0”, “1” or “10”, you do not need to take any further actions.
The transaction is currently scheduled to settle.
If the settlestatus is “100”, the transaction has been settled.
You cannot perform any further updates to the transaction.
If the settlestatus is “2”, the transaction has been suspended.
Funds will not be settled without your intervention. Please refer to our settlement documentation for further information.
If the settlestatus is “3”, the transaction has been cancelled.
Funds will not be settled and you will need to investigate the problem and try again. In this scenario, it is useful to look at the accompanying errorcode as this will often inform you of the reason behind the transaction failing.
If you haven’t already, we recommend you read our settlement documentation for further detail on how settlement is performed.
Security response
If the AVS and Security Code Checks are performed as part of the request (as is the case for most AUTH and ACCOUNTCHECKs), you will need to check the three security response fields returned, which are defined as follows:
- securityresponseaddress – Does the first line of the billing address entered by the customer match that found on their bank account?
- securityresponsepostcode – Does the billing postcode entered by the customer match that found on their bank account?
- securityresponsesecuritycode – Does the security code entered by the customer match the value found on the back of their card?
If the value is “2”, the customer entered the correct details.
If all values are “2”, there is no reason here to prevent the transaction from settling.
If the value is “1”, the bank was unable to check the customer’s details.
This may be because the customer has a card issued by a foreign country, and your bank was therefore unable to check their address. You may need to consider suspending transactions that fall into this category to allow you to investigate before proceeding with the payment.
If the value is “0”, the customer’s details were not sent to the bank.
This is because the customer didn’t enter any of the details at all, or that these details were not submitted in your request. You may need to consider suspending transactions that fall into this category to allow you to investigate before proceeding with the payment.
If the value is “4”, the customer entered incorrect details.
By default, we will suspend transactions where the security code entered by the customer fails to match the value on their card. Depending on your preferences, you may also prefer to suspend transactions where the address details do not match (disabled by default).
You can request that Trust Payments automatically cancels transactions when the security response fields have a certain value. As mentioned above, we suspend all transactions where the security code entered by the customer fails to match the value on their card. You can specify the circumstances under which transactions are suspended to match your own preferences (you can even disable such checks entirely). This is achieved by modifying your Security Policy. To discuss changes to your account’s security policy, please contact our Support team.
Request type description
Each response will contain a requesttypedescription. The value of this field returned in the response should always match the value submitted in the request.
e.g. If you are sending an “AUTH” request, ensure the requesttypedescription returned is “AUTH”.
If you receive requesttypedescription with value “ERROR”, the request may not have been processed successfully and you will need to investigate.
Live status
Check the live status value returned is “0” while testing and “1” when processing live payments.
Amount & currency
When submitting an amount and currency, check that the same values are returned in the response.
Response site security
If you are processing transactions using our Payment Pages interface, and have configured URL notifications or redirects to be triggered upon transaction completion, you will need to re-calculate the site security hash using the fields returned and check it matches the corresponding hash returned from Trust Payments. This is to ensure the content returned hasn’t been modified by an unauthorised party. Click here to learn more.
Account checks (API)
If you are unsure, please contact our Support Team for assistance.
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.
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.
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” errorcode being returned in the response.
ACCOUNTCHECK request
The fields required in an ACCOUNTCHECK request are the same as a standard AUTH request. The difference is that the baseamount can be “0”. You can also submit any field that you can submit in an AUTH request and these will be inherited by any subsequent child requests.
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": "ECOM", "pan": "4111111111111111", "expirydate": "12/2020", "securitycode": "123", "billingpremise": "789", "billingpostcode": "TE45 6ST" } 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' => 'ECOM',
'pan' => '4111111111111111',
'expirydate' => '12/2020',
'securitycode' => '123',
'billingpremise' => '789',
'billingpostcode' => 'TE45 6ST'
);
$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": "ECOM", "pan": "4111111111111111", "expirydate": "12/2020", "securitycode": "123", "billingpremise": "789", "billingpostcode": "TE45 6ST" }]}'
{"alias":"[email protected]","version":"1.00","request":[{"currencyiso3a":"GBP","requesttypedescriptions":["ACCOUNTCHECK"],"sitereference":"test_site12345","baseamount":"0","orderreference":"My_Order_123","accounttypedescription":"ECOM","pan":"4111111111111111","expirydate":"12\/2020","securitycode":"123","billingpremise":"789","billingpostcode":"TE45 6ST"}]}
<?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>ECOM</accounttypedescription> <sitereference>test_site12345</sitereference> </operation> </request> </requestblock>
Replace <DOMAIN> with a supported domain. Click here for a full list.
ACCOUNTCHECK response
The ACCOUNTCHECK response has the same structure as a standard AUTH response, except for the requesttypedescription value returned being “ACCOUNTCHECK”.
Inheritance
It is possible to take the value of the transactionreference field returned in the ACCOUNTCHECK response and submit this in the parenttransactionreference field of a new request, such as an AUTH. The new request will inherit billing and delivery details from the ACCOUNTCHECK (including the card details required for the payment), which means you are not required to submit this information again.
{
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 'ECOM',
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'
}]
}
array(3) {
["requestreference"] => string(9) "A4cenptwx"
["version"] => string(4) "1.00"
["response"] => array(1) {
[0] => array(27) {
["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) "ECOM"
["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"
}
}
}
{"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":"ECOM","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"}],"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>ECOM</accounttypedescription>
</operation>
</response>
<secrand>bByuPvGz9Hcm</secrand>
</responseblock>
The results of account checks are returned in the securityresponseaddress, securityresponsepostcode and securityresponsesecuritycode fields. The specification of these fields are outlined in the table 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) |
AVS and security code checks
The Address Verification System and security code checks provide you with a further level of security to a transaction, allowing additional checks regarding the validity of the address and security code information supplied by the customer.
Introduction to AVS
A customer’s address is checked against the address that the card issuer holds for that card. The issuing bank will indicate to the acquiring bank whether there is a match between the entered address and the registered card address. The checks performed are focused on the house number and postcode provided by the customer.
Introduction to security code checks
The security code is a three or four digit number printed on credit and debit cards. It is not stored by Trust Payments, and also must never be stored by merchants.
The number is often printed on the back of the card, on the signature strip.
Alternatively, on American Express cards the security code can be found on the front of the card, on the right–hand side, above the embossed card number.
Process overview
Here is how the AVS and security code checks fit into the standard payment process:
Depending on your account configuration, Trust Payments may perform certain actions on the transaction if the results of the AVS and security code checks do not meet a required standard. This behaviour is configured as part of your security policy (scroll down for further information on the security policy).
Requirements
Supported cards and banks
The availability of the AVS and security code check facility is dependent on the acquiring bank and card issuer, although it should be noted that most cards support this functionality.
The ability to conduct address checks is dependent on the location of your acquiring bank in relation to the location of the issuing bank of the card being presented. Most acquirers do support the process but only on locally issued cards. All UK cards and a number of US cards are address checked by all UK acquirers.
Security code checks are performed on all Visa, Mastercard and American Express branded cards worldwide and the results are checked internationally by all acquirers.
Please contact our Support team for further information on supported acquirers and card types.
Required fields
For checks to be successfully performed on the customer’s details, the customer will need to provide their billing postcode, billing premise and their card’s security code.
If this information is not present in the request to Trust Payments, we will return a “Not given” response.
Response codes
There are four different possible responses following AVS and security code checks. Each response is assigned a distinct code, as shown in the following table:
| Code | Description | Comment |
| 0 | “Not given” | Your acquirer was not provided with the information required to perform this check. |
| 1 | “Not checked” | Your acquirer was unable to perform checks on the information provided. |
| 2 | “Matched” | The information provided by the customer matches that on the card issuer’s records. |
| 4 | “Not matched” | The information provided by the customer does NOT match that on the card issuer’s records. |
Together, the AVS and security code checks consist of three total checks, and we assign a response code for each:
- Card security code
- Billing postcode
- Billing premise
Security policy
Your account’s security policy consists of preferences on how we respond to instances where the address (premise & postcode) and security code entered by the customer does not directly match those found on the card issuer’s records. We can automatically suspend transactions that return certain response codes:
To discuss or make changes to your security policy, please contact the Support team.
You can perform AVS and security code checks without debiting the customer. This is achieved by performing an Account Check. Click here to learn more about Account Checks.
Testing
We recommend that you thoroughly test your solution before processing live payments.
Click here for test card details that you can submit when testing.