FAQs

Trust Payments offers a number of different tools to reduce the risk of fraud:

• 3-D Secure is performed on transactions made by credit/debit cards. The card issuer will perform a series of checks to verify the customer’s identity. Not only does this greatly reduce the likelihood of fraudulent transactions from being completed, the card issuer will usually take financial responsibility for the chargeback in the event a dispute does occur (conditions apply).

• Our fraud checks system can be enabled to perform a wide suite of checks against transactions processed on your account, automatically suspending payments that exhibit suspicious characteristics.

• Protect Plus is our premium counter-fraud service that performs additional checks, such as verifying the customer’s name against the UK electoral roll and BT databases.

3-D Secure is a protocol designed to reduce fraud and chargebacks during e-commerce transactions. It allows card issuers to provide an extra level of protection, by authenticating cardholders at the point of sale (e.g. with a secret password or biometrics) if the payment is deemed high risk. In the event of a dispute with the transaction at a later date, the card issuer will take financial responsibility for the chargeback in most instances.

Click here to learn more.

All businesses within the EEA (European Economic Area) are mandated to use 3-D Secure when processing e-commerce transactions, as part of the PSD2 mandate. In addition, ECOM (e-Commerce) Maestro transactions already require the implementation of 3-D Secure in order to be processed successfully. Exemptions apply for MOTO (Mail or Telephone Order) transactions and/or MIT (Merchant Initiated Transactions), for which 3-D Secure cannot be performed.

The enrolled field will inform you if the customer’s card is enrolled in 3-D Secure:

The status field will inform you if the customer was successfully authenticated during the 3-D Secure process:

Refunds are processed through MyST. Sign in to MyST, and find the transaction you would like to refund, either by using the search bar at the top of the page, or navigating to the Transaction search page. When viewing a transaction, click the “Refund” button shown at the bottom of the page.

Click here to learn more.

Re-authorisations are processed through MyST. Sign in to MyST, and find the transaction for which you would like to perform a re-authorisation, either by using the search bar at the top of the page, or navigating to the Transaction search page. When viewing a transaction, click the “Re-auth” button shown at the bottom of the page.

Click here to learn more.

We refer to authorisations, where no funds are reserved on the customer’s bank account, as “Account Checks”. These can be processed using MyST. Sign in to MyST, and find the transaction for which you would like to perform an Account Check, either by using the search bar at the top of the page, or navigating to the Transaction search page. When viewing a transaction, click the “Account check” button shown at the bottom of the page.

Click here to learn more.

An Account Check is a type of request that performs a zero-authorisation, during which checks on the customer’s address and security code are performed. No funds are reserved on the customer’s bank account as part of this process. When enabled, Account Checks are performed immediately prior to each standard authorisation on your account. This allows you to use the results returned to prevent authorisations from being processed, in cases where the aforementioned checks have shown there to be inconsistencies between the values entered by the customer and those being held on record by the issuing bank.

Click here to learn more.

• Payments processed as “pre-authorisations” can be deferred up to 31 days.
• Payments processed as “final authorisations” (default behaviour) can be deferred up to 4 days.

Click here to learn more about pre and final authorisations.

There are two ways in which a payment can be deferred until a later time.

1. You can include a settleduedate in your request. Funds will be reserved on the customer’s account, but won’t leave their account until the date specified.
2. You can suspend a transaction, by submitting settlestatus=2 in your request. Funds will be reserved on the customer’s account, but won’t leave their account until the transaction is updated to settlestatus=1.

Click here to learn more about the settlement process.

There are a number of reasons a transaction may have been suspended.

• If the payment and billing details fail to satisfy the security policy requirements on your account, the transaction is automatically suspended. By default, this occurs when the security code entered by the customer fails to meet the value on the back of their card. Click here to learn more.
• A member of your team may have manually opted to manually suspend a transaction following authorisation. This can occur when processing the payment (by including settlestatus 2 in the request), or at a later time prior to settlement, by updating the settlestatus to 2 using MyST or a TRANSACTIONUPDATE.
• If you are using our internal fraud check system or Protect Plus (there are disabled by default), you may have rules configured on your account to suspend transactions when checks have shown there is an increased risk of fraud occurring, allowing for manual investigation.
• If you are using the Enhanced tier of TruFraudCheck, transactions are suspended when there’s a moderate risk of fraud occurring, allowing for manual investigation.
• If your account has duplicate checks enabled (this is disabled by default), transactions are suspended when they are processed with same amount, payment and billing details and from within a pre-determined time-frame after the original transaction was processed.
• You may have a rule configured on your account that automatically suspends transactions when certain conditions have been met. Click here to learn more.

There are two methods to suspend a payment:

1. Modify the request – You can specify for transactions to suspended immediately after they are authorised by the issuing bank. This is achieved by specifying settlestatus 2 on the request. When using the MyST Virtual terminal or Pay by Link, there is a drop-down box where this can be specified. When processing through Payment Pages or through our API, the field settlestatus can be included with value 2.
2. Update a transaction – Following authorisation but prior to settlement, you can update a previously-processed transaction to settlestatus This can be achieved by using MyST or by submitting a TRANSACTIONUPDATE request through our API.

Suspended transactions are shown in MyST in yellow with the label “Suspended”, and can be identified with settlestatus 2. There are three possible outcomes:

1. Accept – You can update a suspended transaction to settlestatus 1, which allows the payment to be settled in the next batch (typically within 24 hours). This can be achieved by using MyST or by submitting a TRANSACTIONUPDATE request through our API.
2. Cancel – You can update a suspended transaction to settlestatus 3, which prevents the payment from being settled (this cannot be undone). This can be achieved by using MyST or by submitting a TRANSACTIONUPDATE request through our API.
3. Ignore – It is not compulsory to action your suspended transactions. If action is not taken on suspended transactions, our system will automatically cancel them 7 days after they are initially processed.

Cancelled transactions are not allowed to be settled. Cancellation is a permanent action that cannot be undone. To accept payment from the customer, you will need to submit a new payment for authorisation.

There are a number of reasons a transaction cannot be refunded:

• Is the transaction settled? – Only settled transactions can be refunded. Settled transactions are shown in MyST as green with the label “Settled”, and can be identified with settlestatus If a transaction is pending settlement (settlestatus 0 or 1), you would instead need to cancel the payment by updating the settlestatus to 3, either by using MyST or by submitting a TRANSACTIONUPDATE request through our API. Cancelling a transaction will prevent the funds from being settled, and will request the funds reserved on the customer’s account are reversed.
• The payment method – While in the vast majority of situations, both full and partial refunds are supported for customers using credit or debit cards for payment, this is sometimes not the case Alternative Payment Methods (APM). To check if refunds are supported for the customer’s chosen payment method, please refer to the relevant documentation (Payment Pages, API).
• Settle status 10 – If a transaction is in settlestatus 10, this means that the funds are currently in the process of being settled into your account. You will need to wait for this process to be completed (after which the settlestatus would be 100) before you can submit a refund request.
• The request type – Only AUTH requests can be submitted for refund.

Once a transaction has been authorised by the issuing bank, the funds are then reserved against the customer’s account. The instruction to transfer the funds is scheduled daily when we submit a batch of all pending transactions to your acquirer. We call this process settlement. Click here to learn more.

Payment Pages support a wide array of different payment brands. Click here for a full list, along with instructions on how to configure them.

Yes. Apple Pay is a popular digital wallet service that can be seamlessly integrated into your checkout to provide a streamlined purchasing experience for your customers.

Click here to learn more.

You will need to sign in to your PayPal account and perform steps to allow it to connect to Trust Payments. Then you will need to contact our Support Team to ensure PayPal is enabled on your Trust Payments account.

Click here to learn more.

For a full list of payment types supported by Payment Pages, click here.

Providing you have a recurring merchant account, you can schedule subscriptions in our Subscription Engine. This means that following the customer’s first transaction, Trust Payments will automatically process repeat payments at regular intervals defined in the request.

Click here to learn more.

Yes, providing your acquiring bank accepts the currencies needed and your Trust Payments account has been configured to do so. You can specify the currency for the payment in each POST to Payment Pages. You can even configure and enable currency conversion, allowing your customer to pay in the local currency of their choosing.

Our Payment Pages can easily be translated into different languages by updating your request.

Click here to learn more.

Yes. Custom logos can be uploaded using the MyST File manager and displayed on the Payment Pages.

Click here to learn more.

Yes. Click here for a full list.

Yes, although certain payment methods, such as Apple Pay and PayPal, do not currently support iframe integration. Click here to learn more.

There are two methods to configure redirects following transactions.

1. Configure rule in MyST Rule manager

1. Sign in to MyST.
2. Search for your sitereference using the search box found at the top of the page.
3. When viewing your site details, click “Rule manager“.

4. Select the action type “Payment pages redirect” from the drop-down and your browser will be redirected.

5. Create a new redirect rule:
   • (A) Click “Add new condition” and specify the circumstances in which the customer’s browser is to be redirected following a transaction.
   • (B) Click “Add new action” and specify the endpoint for the redirect.
   • (C) Using the drop-down boxes, assign the condition to the action and click “Create rule“.

6. Ensure the rule is active (this is shown with a tick under the Active column). Once enabled, the rule will be applied to all Payment Pages sessions for the given sitereference, and the redirect will be triggered whenever the condition specified is met.

All new rules should be created on your test sitereference and tested to ensure they work as expected before being added to your live sitereference.

2. Specify URL in the POST to Payment Pages

You will need to include the fields ruleidentifier and either successfulurlredirect, declinedurlredirect or errorurlredirect in your POST to Payment Pages, as shown in the following examples:

Important: The field values will need to be included when generating the site security hash.

<!--Enables rule that redirects the customer following a successful transaction-->
<input type=hidden name="ruleidentifier" value="STR-6">
 
<!--Update the below with the URL for the redirect-->
<input type=hidden name="successfulurlredirect" value="http://yourwebsite.com/successful">

<!--Enables rule that redirects the customer following a declined transaction-->
<input type=hidden name="ruleidentifier" value="STR-7">
 
<!--Update the below with the URL for the redirect-->
<input type=hidden name="declinedurlredirect" value="http://yourwebsite.com/declined">

<!--Enables rule that redirects the customer following an error-->
<input type=hidden name="ruleidentifier" value="STR-13">
 
<!--Update the below with the URL for the redirect-->
<input type=hidden name="errorurlredirect" value="http://yourwebsite.com/error">

Click here for full documentation.

There are two methods to configure URL notifications following transactions.

1. Configure rule in MyST Rule manager

1. Sign in to MyST.
2. Search for your sitereference using the search box found at the top of the page.
3. When viewing your site details, click “Rule manager“.

4. Select the action type “URL notification” from the drop-down and your browser will be redirected.

5. Create a new URL notification rule:
   • (A) Click “Add new condition” and specify the circumstances in which the URL notification is to be triggered following a transaction.
   • (B) Click “Add new action” and specify the endpoint for the URL notification.
   • (C) Using the drop-down boxes, assign the condition to the action and click “Create rule“.

6. Ensure the rule is active (this is shown with a tick under the Active column). Once enabled, the rule will be applied to all Payment Pages sessions for the given sitereference, and the URL notification will be triggered whenever the condition specified is met.

All new rules should be created on your test sitereference and tested to ensure they work as expected before being added to your live sitereference.

7. You must configure your system to respond to all URL notifications received from Trust Payments with an HTTP 200 OK response. For example: “HTTP/1.0 200 OK”.Your system must reply within 8 seconds of receiving a notification.

Click here for full documentation.

2. Specify URL in the POST to Payment Pages

You will need to include the fields ruleidentifier and either successfulurlnotification, declinedurlnotification or allurlnotification in your POST to Payment Pages, as shown in the following examples:

Important: The field values will need to be included when generating the site security hash.

<!--This enables the successful URL notification rule-->
<input type=hidden name="ruleidentifier" value="STR-8">
 
<!--Successful URL notification destination-->
<input type=hidden name="successfulurlnotification" value="http://yourwebsite.com/successful">

<!--This enables the declined URL notification rule-->
<input type=hidden name="ruleidentifier" value="STR-9">
 
<!--Declined URL notification destination-->
<input type=hidden name="declinedurlnotification" value="http://yourwebsite.com/declined">

<!--This enables the all URL notification rule-->
<input type=hidden name="ruleidentifier" value="STR-10">
 
<!--All URL notification destination-->
<input type=hidden name="allurlnotification" value="http://yourwebsite.com/all">

Click here for full documentation.

There are two methods to configure email notifications to customers following transactions.

1. Configure rule in MyST Rule manager

1. Sign in to MyST.
2. Search for your sitereference using the search box found at the top of the page.
3. When viewing your site details, click “Rule manager“.

4. Tick the box under the Active column for rule STR-2 to enable emails following successful transactions and/or STR-3 to enable emails following declines. Emails are sent to the billingemail in the Payment Pages session.
5. Click “Save” at the bottom of the page to save your changes.

6. Ensure the rule(s) is active (this is shown with a tick under the Active column). Once enabled, the rule(s) will be applied to all Payment Pages sessions for the given sitereference, and the email notification will be triggered whenever the condition specified is met.

All new rules should be created on your test sitereference and tested to ensure they work as expected before being added to your live sitereference.

2. Update POST to Payment Pages

You will need to include the field ruleidentifier in your POST to Payment Pages, as shown in the following example. Emails are sent to the billingemail in the Payment Pages session.

Important: The ruleidentifier values will need to be included when generating the site security hash.

<!--Sends email confirmation to the customer, following successful transaction:-->
<input type=hidden name="ruleidentifier" value="STR-2">
 
<!--Sends email confirmation to the customer, following declined transaction:-->
<input type=hidden name="ruleidentifier" value="STR-3">

Click here for full documentation.

You can be notified by email of transactions processed, by following one of the two methods provided below:

1. Configure rule in MyST Rule manager

1. Sign in to MyST.
2. Search for your sitereference using the search box found at the top of the page.
3. When viewing your site details, click “Rule manager“.

4. Select the action type “Payment pages merchant email” from the drop-down and your browser will be redirected.

5. Create a new email notification rule:
   • (A) Click “Add new condition” and specify the circumstances in which the email notification is to be triggered following a transaction.
   • (B) Click “Add new action” and specify the address for the email notification.
   • (C) Using the drop-down boxes, assign the condition to the action and click “Create rule“.

6. Ensure the rule is active (this is shown with a tick under the Active column). Once enabled, the rule will be applied to all Payment Pages sessions for the given sitereference, and the email notification will be triggered whenever the condition specified is met.

All new rules should be created on your test sitereference and tested to ensure they work as expected before being added to your live sitereference.

2. Update POST to Payment Pages

You will need to include the fields ruleidentifier and merchantemail in your POST to Payment Pages, as shown in the following example. Emails are sent to the merchantemail in the Payment Pages session.

Important: The ruleidentifier values will need to be included when generating the site security hash.

<!--Sends email confirmation to the merchant, following successful transaction:-->
<input type=hidden name="ruleidentifier" value="STR-4">
 
<!--Sends email confirmation to the merchant, following declined transaction:-->
<input type=hidden name="ruleidentifier" value="STR-5">
 
<!--IMPORTANT: You also need to include the merchant’s email address for merchant emails to work-->
<input type=hidden name="merchantemail" value="[email protected]">

Click here for full documentation.

Yes. You can customise the appearance and layout of your checkout, and even have multiple versions of the pages that can be shown at different times, depending on context. This is achieved by uploading custom markup to the MyST File manager, and assigning new values to the field stprofile in the request.

Click here to learn more.

Yes. Click here to learn how.

When you sign up, you will be provided with a “test” site reference and a “live” site reference:

Test site references are prefixed with “test_”: e.g. “test_site12345”
All requests from your test site reference are processed within our sandboxed test environment, meaning no funds change hands. We recommend thoroughly testing your solution using your test site reference prior to going live.
Click here for further information on how to perform tests.

Live site references are not prefixed with “test_”: e.g. “site12346”.
When processing live transactions, you must use your live site reference, otherwise you will not receive funds. You can only process transactions in the live environment after you have completed your testing and followed the steps described in our Going live documentation.
Click here for information on Going live.

We provide a list of card numbers on this page. These can be used to simulate different transaction outcomes.

You will need to follow the steps provided on this page to begin processing live payments.

There are no supported payment methods enabled on your account for your chosen currency. You will either need to correct the currency posted to be one supported by your account, or contact our Support Team to discuss enabling payment methods for additional currencies.

Please follow these three steps:

1. Please check transactions are definitely being processed through your live sitereference. If the sitereference posted in your request is prefixed with “test_”, payments are being processed on the test environment and you will never receive funds.
2. Check your transactions are being “settled”. Once transactions are authorised by the issuing bank, funds are reserved on the customer’s account (normally for up to 24 hours) before finally being transferred to your bank account in a process called “Settlement“. Settled transactions are indicated as such on the Transaction search page in MyST (the settlestatus value should also be “100”). If your transactions are not settling as expected, you will need to investigate why this is.
3. If you have confirmed transactions are being processed through your live sitereference and have been settled, there may be an issue with your bank account. We recommend contacting your acquiring bank for assistance.

Once transactions are authorised by the issuing bank, funds are reserved on the customer’s account (normally for up to 24 hours) before finally being transferred to your bank account in a process called “Settlement”. Settled transactions are indicated as such on the Transaction search page in MyST (the settlestatus value should also be “100”).

Click here to learn more about the settlement process.

There are two reasons why this may be occurring:

1. The missing payment methods may not support the processing of transactions in this currency. Please refer to the documentation for the payment methods in question.
2. The missing payment methods may not have been enabled on your account for the chosen currency. Contact our Support Team for assistance.

When processing payments and handling transaction data, you need to ensure your solution is fully compliant with the Payment Card Industry Data Security Standard (PCI DSS).

PCI DSS aims to protect customer data from unauthorised access and ultimately to reduce the risk of fraud when processing payments online. It establishes requirements and best practices that all merchants must follow when handling sensitive payment credentials. The standard is administered by the Payment Card Industry Security Standards Council, a group that currently consists of Visa, Mastercard, American Express, Discover and JCB.

Click here to learn more.