Contents

Best practices

 

This section assumes you have already read our Getting started documentation and understand how to submit a basic request to us. If you haven’t already, we recommend reading this before you continue.

 

When receiving our response, your system will need to perform the following checks on the values returned (where applicable) to ensure the request was processed successfully.

 

Error code

The errorcode is a fundamentally important field as it displays the outcome of the submitted request. It is returned in every response from Trust Payments.

Status good

If the errorcode is “0”, this indicates the request was processed successfully.

 

It is imperative that you have a process in place to check the final status of the processed request, by looking at the values of the other fields returned. 

Status attention

If the errorcode is “30000”, this indicates a field error.

If you look at the errordata field returned, this typically contains the name of the field that was deemed invalid. You will need to retry the request, ensuring all required fields have been submitted, and that all submitted field values follow our specification.

Status attention

If the errorcode is “70000”, this indicates a payment was declined by your bank.

We recommend that you show an error message to the customer and allow them to try a different method of payment.

Status bad

If the errorcode is “60010”, “60034” or “99999”, there has been a problem processing the request and the final status is not known.

 

This can be due to a communication problem with a bank or third party. In such cases, we recommend informing the customer of the problem and to contact you to query the issue. You will need to contact our Support team, providing a copy of the entire request submitted and response returned, and we will contact the relevant parties to establish the status of the request. In the interest of security, ensure you omit or mask sensitive field values, such as card details.

If the errorcode is not listed above, please refer to our full list of errorcodes for assistance. If you need further help, please contact our Support team.

 

Settle status

It is important to check the value of the settlestatus when processing an AUTH or REFUND request, as this indicates if Settlement will be performed. Here are the basics:

Status good

If the settlestatus is “0”, “1” or “10”, you do not need to take any further actions.

The transaction is currently scheduled to settle.

Status good

If the settlestatus is “100”, the transaction has been settled.

You cannot perform any further updates to the transaction.

Status attention

If the settlestatus is “2”, the transaction has been suspended.

Funds will not be settled without your intervention. Please refer to our settlement documentation for further information.

Status bad

If the settlestatus is “3”, the transaction has been cancelled.

Funds will not be settled and you will need to investigate the problem and try again. In this scenario, it is useful to look at the accompanying errorcode as this will often inform you of the reason behind the transaction failing.

If you haven’t already, we recommend you read our settlement documentation for further detail on how settlement is performed.

 

Security response

If the AVS and Security Code Checks are performed as part of the request (as is the case for most AUTH and ACCOUNTCHECKs), you will need to check the three security response fields returned, which are defined as follows:

Status good

If the value is “2”, the customer entered the correct details.

If all values are “2”, there is no reason here to prevent the transaction from settling.

Status attention

If the value is “1”, the bank was unable to check the customer’s details.

This may be because the customer has a card issued by a foreign country, and your bank was therefore unable to check their address. You may need to consider suspending transactions that fall into this category to allow you to investigate before proceeding with the payment.

Status attention

If the value is “0”, the customer’s details were not sent to the bank.

This is because the customer didn’t enter any of the details at all, or that these details were not submitted in your request. You may need to consider suspending transactions that fall into this category to allow you to investigate before proceeding with the payment.

Status bad

If the value is “4”, the customer entered incorrect details.

By default, we will suspend transactions where the security code entered by the customer fails to match the value on their card. Depending on your preferences, you may also prefer to suspend transactions where the address details do not match (disabled by default).

You can request that Trust Payments automatically cancels transactions when the security response fields have a certain value. As mentioned above, we suspend all transactions where the security code entered by the customer fails to match the value on their card. You can specify the circumstances under which transactions are suspended to match your own preferences (you can even disable such checks entirely). This is achieved by modifying your Security Policy. To discuss changes to your account’s security policy, please contact our Support team.

 

Request type description

Each response will contain a requesttypedescription. The value of this field returned in the response should always match the value submitted in the request.

e.g. If you are sending an “AUTH” request, ensure the requesttypedescription returned is “AUTH”.

If you receive requesttypedescription with value “ERROR”, the request may not have been processed successfully and you will need to investigate.

 

Live status

Check the live status value returned is “0” while testing and “1” when processing live payments.

 

Amount & currency

When submitting an amount and currency, check that the same values are returned in the response.

 

Response site security

If you are processing transactions using our Payment Pages interface, and have configured URL notifications or redirects to be triggered upon transaction completion, you will need to re-calculate the site security hash using the fields returned and check it matches the corresponding hash returned from Trust Payments. This is to ensure the content returned hasn’t been modified by an unauthorised party. Click here to learn more.

 

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