Pre-requisites
- 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 POST 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
There are two main methods to include Account Checks in your payment solution.
- Precede a payment with an Account Check – Rules can be configured on your account to prevent the subsequent payment from being processed if discrepancies are found between the values of the cardholder’s first line of address, the cardholder’s postcode and the security code entered by the customer and those found on the account held by the issuing bank.
- Perform Account Check without payment – This allows you to perform your own back office operations after the Account Check. The subsequent payment would be processed by interfacing with our API.
1. Precede a payment with an Account Check
To enable this behaviour, you will need to contact our Support Team and request the following changes to your account:
- Account Checks needs to be enabled on your site reference(s).
- Enable a rule that acts on the results of the checks (either suspend/cancel the payment).
Each Account Check is assigned a unique transaction reference and you can use this to view details of the request in MyST. If you already know the unique transaction reference, you can type this into the universal search found at the top of the page. Otherwise, you can use our Transaction search utility and filter request types by “ACCOUNTCHECK” to search over requests.
2. Perform Account Check without payment
To enable this behaviour, you will need to contact our Support Team and request the following changes to your account:
- Account Checks needs to be enabled on your site reference(s).
- Enhanced Post to be enabled on these site reference(s).
Once your account has been updated as described above, you will now need to configure your POST to Trust Payments to include the following additional fields:
Field specification
| Field | Format | Description | |
| credentialsonfile | Numeric (1) |
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. To perform a subsequent payment using stored payment credentials, you will need to submit an AUTH request to Trust Payments using our API. |
|
| requesttypedescriptions | Alpha (20) | This must be set to “ACCOUNTCHECK”. |
<html>
<head>
</head>
<body>
<!--YOUR HTML-->
<form method="POST" action="<DOMAIN>/process/payments/choice">
<input type="hidden" name="sitereference" value="test_site12345">
<input type="hidden" name="stprofile" value="default">
<input type="hidden" name="currencyiso3a" value="USD">
<input type="hidden" name="mainamount" value="100.00">
<input type="hidden" name="version" value="2">
<input type="hidden" name="orderreference" value="myorder12345">
<input type="hidden" name="sitesecurity" value="hee879a9ab97753b3a768925d50842f10e19fea03fef0b820026b6df92d415866">
<input type="hidden" name="sitesecuritytimestamp" value="2019-05-28 14:22:37">
<input type="hidden" name="requesttypedescriptions" value="ACCOUNTCHECK">
<input type="hidden" name="credentialsonfile" value="1">
<input type="submit" value="Pay">
</form>
</body>
</html>
Handling the response
Checks are performed 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. For each check, a numerical code is returned:
| 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. |
We recommend two different methods of viewing the results:
- The results of these checks can be viewed manually by signing in to MyST, and searching for the Account Checks that have been processed on your site reference(s). Click here to learn more.
- You can also configure URL notifications to include the additional fields securityresponseaddress, securityresponsepostcode and securityresponsesecuritycode. These will contain the numeric values listed above. Click here to learn more.
