When enabled on your account, the fraud check service analyses authorised transactions for attributes that may be considered suspicious, prior to settlement being performed. This allows you to manually inspect and manage suspicious transactions processed on your account. These checks are performed at pre-defined times throughout the day.
Trust Payments cannot guarantee to identify all fraudulent transactions.
Fraud checks are disabled by default on all new site references.
To enable fraud checks on your account, please contact our Support Team.
Fraud rating
The fraud check analyses all transactions processed on your account and assigns a numerical fraud rating, which indicates the level of risk based on a number of pre-defined criteria.
- Before the fraud checks have been processed, the fraud rating will be “-1”.
- Following the processing of the fraud checks, a fraud rating of “0” indicates that no suspicious characteristics were detected.
- Every suspicious attribute found by the fraud checks will increment the fraud rating. A higher fraud rating indicates a higher likelihood of fraud.
- All transactions with a fraud rating of “2” or higher are collated into a daily email notification sent to the email address associated with your account.
- By default, we will suspend all transactions with a fraud rating of “5” of higher.
You can configure the thresholds that trigger these actions (e.g. in order to reduce the occurrences of false-positives) by contacting our Support Team.
Reason codes
Trust Payments performs the following checks on authorised transactions in settle status “0” against records for the previous 7 days. If any of the following criteria are met, the fraud rating for the transaction will be incremented. A higher fraud rating indicates a greater chance of fraud, and as such transactions with high fraud ratings may be suspended in line with your Security Policy.
If matched, these criteria will raise the fraud rating:
The following increment the rating by 1:
- X – Same card number has been declined before with different expiry dates.
- E – Email address has been used with different declined card(s) or expiry date(s).
- N – Cardholder name has been used with different declined card(s) or expiry date(s).
- C – Card details are associated with a very high number of successful transactions.
- V – Cardholder name believed to be randomly-generated (e.g. “ghghghghg”).
- P – Postcode entered did not match that on the customer’s bank’s records.
The following increment the rating by 2:
- S – Security code entered did not match that on the customer’s card.
The following increment the rating by 10:
- G – Card number or billing address has been found in our Negative Database
When looking at the above, the character on the left represents the fraud reason code. After the fraud checks have been performed, you can view which of the specific checks failed (if any), by matching the reason codes returned to the values listed above. For each criteria met, we increment the fraud rating as shown above.
Viewing fraud rating and reason codes in MyST
You can view the fraud rating and reason codes (if any) for each transaction in MyST.
Transaction search
Select “Fraud rating” and “Fraud reason” in the optional “Fields” tab when performing a search on the “Transaction Search” page.
This allows you to compare fraud ratings/reasons of multiple transactions that meet your search criteria.
Single transaction view
The fraud rating and reason(s) are also visible in the single transaction view, as shown below.
Updating affected transactions
By using MyST
Sign in to MyST, search for the transaction and click “Update”.
Modify the settle status of the transaction and click “Update”. (See below for information on the different settle status values that can be selected)
By using our Webservices API
You can also update the settlestatus by submitting a TRANSACTIONUPDATE request using our Webservices API.
The following is an example request that updates specified transaction to allow settlement:
#!/usr/bin/python
import securetrading
stconfig = securetrading.Config()
stconfig.username = "webservices@example.com"
stconfig.password = "Password1^"
st = securetrading.Api(stconfig)
update = {
"requesttypedescriptions": ["TRANSACTIONUPDATE"],
"filter":{
"sitereference": [{"value":"test_site12345"}],
"transactionreference": [{"value":"1-2-3"}]
},
"updates":{"settlestatus":"1"}
}
strequest = securetrading.Request()
strequest.update(update)
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' => 'webservices@example.com',
'password' => 'Password1^',
);
$requestData = array(
'requesttypedescriptions' => array('TRANSACTIONUPDATE'),
'filter' => array(
'sitereference' => array(array('value' => 'test_site12345')),
'transactionreference' => array(array('value' => '1-2-3'))
),
'updates' => array('settlestatus' => '1')
);
$api = \Securetrading\api($configData);
$response = $api->process($requestData);
var_dump($response->toArray());
?>
curl --user webservices@example.com:Password1^ <DOMAIN>/json/ -H "Content-type: application/json" -H "Accept: application/json" -X POST -d '{
"alias": "webservices@example.com",
"version": "1.00",
"request": [{
"requesttypedescriptions": ["TRANSACTIONUPDATE"],
"filter":{
"sitereference": [{"value":"test_site12345"}],
"transactionreference": [{"value":"1-2-3"}]
},
"updates":{"settlestatus":"1"}
}]}'
{"alias":"webservices@example.com","version":"1.00","request":[{"requesttypedescriptions":["TRANSACTIONUPDATE"],"filter":{"sitereference":[{"value":"test_site12345"}],"transactionreference":[{"value":"1-2-3"}]},"updates":{"settlestatus":"1"}}]}
<?xml version="1.0" encoding="utf-8"?>
<requestblock version="3.67">
<alias>webservices@example.com</alias>
<request type="TRANSACTIONUPDATE">
<filter>
<sitereference>test_site12345</sitereference>
<transactionreference>1-2-3</transactionreference>
</filter>
<updates>
<settlement>
<settlestatus>1</settlestatus>
</settlement>
</updates>
</request>
</requestblock>
Replace <DOMAIN> with a supported domain. Click here for a full list.
Allowing transactions to settle
If you have manually investigated a transaction that has been flagged with a particular fraud rating and would like to instruct us to settle the transaction, you can manually override a transaction by updating the settle status to “1”. Settlement is performed once a day and all transactions with settle status “1” are settled regardless of their fraud rating.
Transactions with settle status “1” may still be deferred for other reasons, e.g. because a custom settle due date may have been submitted in the original request.
Suspending transactions
If you believe a transaction to be suspicious but it has not been automatically suspended, you can manually suspend a transaction by updating the settle status to “2”. Suspended transactions can later be re-enabled for settlement by updating the settle status to “1” (as described above). They can also be permanently cancelled by updating the settle status to “3”.
- All pre-authorisation transactions not settled within 31 days of the authorisation date will be cancelled.
- All final authorisation transactions not settled within 7 days of the authorisation date will be cancelled.
Cancelling transactions
If you have manually investigated a suspended transaction and would like to cancel the payment, you can manually cancel a transaction by updating the settle status to “3”.
Cancelling a transaction is a permanent action
Cancelled transactions can never be settled by Trust Payments.
Negative database
Our internal negative database is a record of card numbers and billing email addresses previously associated with suspicious transactions.
When any transaction receives a fraud rating of “10” or higher, we will automatically add the card number and billing email address to the database.
When you process a transaction that includes a card number and/or billing email address that has been stored in the negative database, the fraud rating is increased by “10”, which immediately suspends the transaction under default configuration. (This requires fraud checks to be enabled on your account) If a transaction is suspended due to an entry in the negative database, it is shown with the reason code “G” in MyST.
If you would like to remove a customer’s details from our negative database, please contact our Support Team to discuss.
Bypassing fraud checks
Payment Pages integrations
You can manually flag transactions to bypass the results of fraud checks by including a settle status of “1” in the POST to Payment Pages:
<html>
<body>
<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="settlestatus" value="1">
<input type="hidden" name="version" value="2">
<input type="submit" value="Pay">
</form>
</body>
</html>
Replace <DOMAIN> with a supported domain. Click here for a full list.
Fraud checks are still performed on these transactions and you will be able to view the fraud rating and associated reason codes, as described above. The difference is, your security policy will not suspend transactions flagged in this way, allowing them to be settled without further intervention.
JavaScript Library / Mobile SDK integrations
You can manually flag transactions to bypass the results of fraud checks by including a settlestatus of “1” in the payload submitted within your JWT.
{"payload":{"accounttypedescription":"ECOM","baseamount":"1050","currencyiso3a":"GBP","sitereference":"test_site12345","settlestatus":"1","requesttypedescriptions":["THREEDQUERY","AUTH"]},"iat":1559033849,"iss":"jwt.user"}