Follow these instructions when using Account Checks to verify the customer’s details prior to processing a payment.
- 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.
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”.
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.
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.
|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”].|
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
The contents of the response is dependent on whether the customer was subject to more stringent authentication (referred to as step up authentication).
If the transaction is subject to step up authentication
After the customer has completed the payment session, you will receive a single response JWT that contains the response to the AUTH request, 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 the checks recommended in the Getting started section.
If the transaction is subject to frictionless authentication
After the customer has completed the payment session, you will receive a single response JWT consisting of the ACCOUNTCHECK, THREEDQUERY and AUTH responses. 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 the checks recommended on the Process your first transaction page.