Contents

Fraud checks (API)

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.

 

Warning
Trust Payments cannot guarantee to identify all fraudulent transactions.

 

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.

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 settlestatus “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.

Info

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 cards or expiry dates.
  • N – Cardholder name has been used with different declined cards or expiry dates.
  • 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

The character on the left represents what we call the reason code. Following fraud checks, you can view which of the checks failed (if any), by matching the resulting reason codes with the list above. If any of the criteria are met, we will increment the fraud rating by the number 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

Sign in to MyST, search for the transaction and click “Update”. Modify the settlestatus of the transaction and click “Update”.

You can also update the settlestatus by submitting a TRANSACTIONUPDATE request.

 

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 settlestatus to “1”. Settlement is performed once a day and all transactions with settlestatus “1” are settled regardless of their fraud rating.

Info
Transactions with settlestatus “1” may still be deferred for other reasons, e.g. because a custom settleduedate 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 settlestatus to “2”. Suspended transactions can later be re-enabled for settlement by updating the settlestatus to “1” (as described above). They can also be permanently cancelled by updating the settlestatus to “3”.

Calendar
All payments 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 settlestatus to “3”.

Warning
Cancelling a transaction is a permanent action.

Cancelled transactions can never be settled by Trust Payments.

 

Negative database

Trust Payments’s 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.

Life ring
If you would like to remove a customer’s details from our negative database, please contact our Support Team to discuss.

 

 


 

Bypassing fraud checks

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.

Info
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.

 

Going live

After you have finished configuring your site and have tested thoroughly, follow the final steps below to begin processing live payments.

 

Warning

Before you continue…

 

Most acquiring banks mandate that 3-D Secure is performed prior to AUTH requests.
If 3-D Secure is not implemented, you could be liable for fines from the card schemes.
Ensure you have contacted your acquiring bank and have configured 3-D Secure, if required.

 

You must ensure your servers are PCI compliant before processing live payments.
For further information, we recommend contacting your acquiring bank.

 

It is crucial that you have read and understood the practices outlined in our best practices and testing documents.
You will need to ensure your system can submit requests using your test sitereference (starts with “test_”) and handle both successful and failure responses before processing live payments.

 

Rules for live site reference

When you are ready to switch your account live, you will need to consider any Rules that may have been configured on your test Site Reference, as these will need to be re-configured on your live site reference to ensure they update your system as expected. Click here for our Rule documentation.

 

Styling for Payment Pages

If you are processing payments using our Payment Pages interface and have applied custom styling to your test site reference using HTML, CSS and/or JavaScript, these changes will also need to be applied to your live site reference.

 

Get in touch

Once you have tested your system and you are ready to go live, please send an email to [email protected] with your live site reference and request to go live. You will receive a response when your live site reference is ready to begin processing payments.

 

Make changes to your requests

Your requests will need to be updated to use your live site reference. This is achieved by modifying the sitereference field submitted to Trust Payments. When your live site reference is submitted in a request, it will be processed as a live request.

Warning
If you have developed your solution using our JavaScript Library, you will need to ensure you update your payment form to submit the field “livestatus”, with value 1.

 

Click here to view an example of a form configured in this way

 


<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',
    livestatus: 1
    });  
   st.Components(); 
  })(); 
 </script>
</body>
</html>

Warning
If you have developed your solution using our Mobile SDK, you will need to ensure your instance is configured in the production environment, rather than staging.

 

Click here to view an example of this configuration

 


TrustPayments.instance.configure(username: username_from_trustpayments,
                                 gateway: .eu,
                                 environment: .production,
                                 translationsForOverride: nil
)

 

Live testing

Once you have switched to your live site reference, we recommend that you test this by performing a transaction using a live card, to ensure it is processed successfully. You can sign in to MyST to manage your transactions. Therefore you can cancel transactions processed on live cards.

Warning
You should not use the same live card too many times, as the requests may still be authorised, and could cause the issuer to suspect fraud or the cardholder could exceed their limit.

 

Thumbs up
You’re all set!

Remember to sign in to MyST and to check your transactions regularly to ensure payments are being processed successfully.
If you need assistance, please contact our Support team.

investors in people logo   pci - security standards council logo

TRUST Payments LTD, No.1 Royal Exchange, London, EC3V 3DG.
A company registered in England and Wales with Company Number 04591066. VAT Number 756265116