Testing

Use the credentials provided on this page to test your solution.

When you sign up, you will be provided with a “live” account and a “test” account (the latter is prefixed with “test_”).
When testing, ensure requests submitted to Trust Payments reference your test sitereference.

It is important to thoroughly test your integration using your test sitereference before processing live payments.

Before you begin testing…

Please be aware of the following notes:

 

• Most fields submitted to our test system will be accepted. Any data breaching its defined specification will return an error message.

• Any test data that generates a successful response when submitted while a merchant is in test mode, will produce a declined response when a merchant is switched into live mode. In some cases, the test data may return an error response.

• Our test system attempts to simulate responses in a similar fashion to the live system. However, depending on your acquirer you may find some responses differ slightly from those given by the test system.

• In the interest of security, we recommend against using real payment details when using your test account.

• We recommend specifying the main amount “10.50” when testing. Other amounts can be used but may return unexpected responses.

• For those using Payment Pages, if you’re unsure where to start with your testing, you may find this resource helpful.

Test card details

The table below lists test card numbers and customer information that can be submitted to our test bank, along with the responses that should be expected in return.

Do not use these credentials when processing transactions on your live site reference.

While testing, all card types are supported, but when using your live account, you will receive an error if you do not have a valid merchant number for the payment type submitted.

• A baseamount of 70000 (£700.00) will always return a declined response from the test bank.
• A baseamount of 60010 (£600.10) will always return a bank system error from the test bank.
• Using baseamount 1050 (£10.50) will not generate an error.

3-D Secure v2

The following payment credentials can be used for testing 3-D Secure v2 (a form of SCA):

3-D Secure v1

The following payment credentials can be used for testing 3-D Secure v1 (a form of SCA):

3-D Secure status testing

To test for different 3-D Secure status values, follow the instructions displayed in the authentication prompt shown on the page (an example is shown below). In the textbox provided, you can enter different PIN values to test for different cases.

Displaying the test ACS page

 

For Payment Pages:

With 3-D Secure enabled on your site reference, process a payment using one of the card numbers listed above and your browser will display an authentication prompt with instructions.

 

For JavaScript Library implementations:

After your payment form has been updated to reference our JavaScript library, process a payment using one of the card numbers listed above and your browser will display an authentication prompt with instructions.

 

For Mobile SDK implementations:

After your Android or iOS app has been updated to utilise our Mobile SDK, process a payment using one of the card numbers listed above and your app will display an authentication prompt with instructions.

 

The authentication prompt will only be displayed for non-frictionless test card details.

Frictionless cards will bypass authentication. In this case, the payment will be processed immediately (without being prompted by the browser for information).

 

---

 

Follow the instructions displayed within the authentication prompt to complete the payment:

 

 

When the status is “N”, indicating the customer failed authentication, the errorcode “60022” will be returned.

Testing AVS and security code checks

If you haven’t already, please read our AVS and Security code documentation before testing:
Link to Payment Pages docs / Link to API docs

The following tables list test details that can be submitted to obtain different responses from the AVS and Security Code Checks. These details can be used with most major payment types.

Only the billing premise, billing postcode and security code field values dictate the outcome of the AVS and security code checks performed. As such, entering any details into the other address fields will not affect the outcome of these checks.

Premise

Postcode / ZIP code

Security code

Testing non-card payment methods

The procedure to follow when testing non-card payment methods will vary. For the most relevant testing information, please refer to the documentation provided for the specific payment method:
Link to Payment Pages docs / Link to Webservices API docs

Testing recurring payments

Testing for the acquirer advice code

When processing recurring payments, some acquirers may return an acquirer advice code in the response. The acquirer advice code is a numeric value used to indicate if further recurring payments can be processed for the given card.

Where to find the acquirer advice code

• This code is returned in your daily subscription email report.
• It’s viewable within MyST by selecting the additional field to be displayed on the transaction search page. It can also be viewed on the single transaction view.
• Additionally, for those who have processed a recurring AUTH transaction using the API, the code is returned in the acquireradvicecode field in the response.

How to test for different acquirer advice codes

You can test that your system responds appropriately to different acquirer advice codes by processing transactions with the following attributes:

Acquirer advice code ‘1’ can only be returned for recurring Mastercard transactions.

Testing Protect Plus

Please refer to the following resources when testing Protect Plus:

• Testing Protect Plus using Payment Pages
• Testing Protect Plus using JavaScript Library
• Testing Protect Plus using iOS SDK

Testing DCC

Please refer to the following resources when testing DCC:

• Testing DCC using Payment Pages
• Testing DCC using our API