Follow these instructions when using Account Checks to verify the customer’s details prior to processing a payment.
Prerequisites
- Account Checks are supported for merchants with a Trust Payments acquiring account. If you are using a different acquiring bank, you will need to contact our Support Team to check this feature is supported before proceeding.
- Account Checks can only be performed for card-based payment methods.
In order to reduce fraud, Visa has mandated that all merchants with a Merchant Category Code (MCC) of 6012 are required to send additional fields in AUTH and ACCOUNTCHECK requests. Click here for further information.
Failure to submit these fields will result in a “60025” (Invalid request) error being returned in the response.
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 update your payload submitted within your JWT to include 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”.
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.
Configuration
Configure the JWT
You can update the JWT payload to precede the payment with an Account Check, by ensuring the following fields are submitted (in addition to the fields normally submitted in the payload, as described on this page):
Although the Account Check does not reserve funds on the customer’s bank account, it is important to understand that the subsequent AUTH request specified in this example will debit the customer’s bank account, if the payment is authorised by the issuing bank.
Field specification
| Field | Format | Description | |
| credentialsonfile | Numeric (1) | As explained above, this must be set to “1” if payment credentials are to be stored for future transactions, in order to indicate permission was granted by the customer. | |
| requesttypedescriptions | List | This must be set to [“ACCOUNTCHECK”,”THREEDQUERY”,”AUTH”]. |
Payload example
{
"payload":{
"accounttypedescription":"ECOM",
"baseamount":"1050",
"currencyiso3a":"GBP",
"sitereference":"test_site12345",
"credentialsonfile":"1",
"requesttypedescriptions":["ACCOUNTCHECK","THREEDQUERY","AUTH"]
},
"iat":1559033849,
"iss":"jwt.user"
}
Rule manager
You will need to contact our Support Team to configure a rule that prevents the payment from being authorised if the checks performed show discrepancies between the address and security code data entered by the customer and those corresponding values stored on their bank’s records.
Handling the response
After the customer has completed the payment session, you will receive a single response JWT consisting of the ACCOUNTCHECK, THREEDQUERY and AUTH responses.
Every JWT returned from the SDK should be verified before continuing. We provide a parsing utility that makes it easier to convert the JWT to a transaction response object. Click here for an example on how to use this.
The most important response to check is that of the AUTH, the process in which the transaction is authorised by the issuing bank. Your system will need to ensure that the errorcode value returned for the AUTH is “0”, indicating success. If the AUTH has failed, the payment will be unsuccessful. In addition to checking the errorcode, your system should also perform these additional checks.
