Test payments in sandbox

See our GitHub for libraries and SDKs to help you integrate the Payments API v3.

Collections

Our collections are sets of preconfigured requests that help you to test API requests as quickly as possible. For Payments, we use the Insomnia REST API client.

If you have Insomnia installed, download and install the TrueLayer collection.

The TrueLayer Insomnia plugin simplifies the process of signing your requests.

Sandbox

To enable the sandbox environment in Console, ensure that the Live toggle in the top-right corner is toggled off (it will be greyed out).

While live is toggled off, any changes you make in Console apply to sandbox, but not the live environment.

To test your API requests in the sandbox or live environments, use these base URLs:

To learn how to create test payments in our sandbox environment, see our quick start guide.

Mock providers

TrueLayer provides mock providers for each country with payments API v3 . You can use these to test your integration, regardless of whether you integrate with our web UI, mobile app UI or a direct API integration.

Based on how you create the payment, you see different banks available within the HPP or SDKs as you test. For a direct integration, you would observe this take effect in the list of providers you receive for provider_selection action.

Test authorisation flows in Sandbox

You can make test requests in our sandbox environment with our sandbox providers. This enables you to see what the payment authorisation flow is like for your customers.

To make the relevant providers visible during authorisation ensure that:

• provider_selection.type is set to user_selected
• provider_selection.filter.countries is either empty or filled with the ISO-3166-1 alpha-2 country code (eg GB, IE, DE)
• currency is set accordingly to the country code

When you initiate a payment using one of these providers, we return a URI that redirects your user to our mock provider authorisation page.

📘

Sandbox payment limit

You cannot make a payment with an amount_in_minor exceeding 5000000 to a merchant account in the sandbox environment..

Test the redirect payment flow

When you test the redirect authorisation flow for a UK bank, the user (you in this case):

1. Selects their bank.
   Select Mock UK Payments – Redirect Flow. This is the sandbox provider with the ID mock-payments-gb-redirect.
2. Reviews the payment.
   The wording on this page ensures that the user gives explicit consent for TrueLayer to initiate the payment.
3. Selects whether to pay with desktop or mobile.
   This page varies based on the device you're using. Select the method you want to test.
4. Signs into their online banking.
   Here, enter one of the usernames below. For example, test_executed.
5. Selects an account to pay from with their bank.
   Select any account. These are test accounts in the sandbox environment, so no money is moved.
   After this, you are redirected, like the user would be redirected back from their bank.

On the authorisation prompt page (step 4 above), different actions lead to different outcomes for the payment:

Using test_executed or test_execution_rejected enables the Execution delay selection, where you can select from different timings, from no delay to one day.

Using test_executed enables the Settlement delay selection, where you can select from different timings, from no delay up to one day.

When you log in with one of the previous usernames, the mock provider presents the account selection page.

When you provide the remitter account details in the payment initiation request, only the stated account can be selected on this screen.

Test the embedded payment flow

When you test the embedded authorisation flow, the user (you in this case):

1. Selects their country.
2. Selects their bank.
   Select Mock European Payments – Embedded Flow. This is the sandbox provider with the ID mock-payments-de-embedded.
3. Reviews the payment.
   The wording on this page ensures that the user gives explicit consent for TrueLayer to initiate the payment.
4. Enters the details requested by their bank.
   Use a valid IBAN (no payment is made), the user name test_username, and password test_password.
5. Selects a Strong Customer Authentication (SCA) method.
   Use PhotoTAN or SMS.
6. Enters the code returned by the SCA method.
   In this test, there is no real SCA method, so use test_executed, test_authorisation_failed, or test_execution_rejected.
   After this, you are redirected, like the user would be redirected back from their bank.

Test different payment scenarios

When you enter bank details in the sandbox authorisation page, you can enter different usernames to achieve different payment outcomes. In the example flows above, you enter these usernames at step 4 for the redirect flow, and step 6 for the embedded flow.

Additional test outcomes

When using a redirect flow, which doesn't require SCA, additional options to test sandbox payments with a delay display. You can see these options in the redirect example above.

If you use test_executed or test_execution_rejected as the username, it enables the Execution delay selection, where you can select from different timings, from no delay to one day.

If you use test_executed as the username, it enables the Settlement delay selection, where you can select from different timings, from no delay up to one day.

Typically, when you log in with one of the test usernames above, the mock provider presents the account selection page. However, if you provide the remitter account details in the payment initiation request, you can only select the account with the provided details. In the embedded example above, the IBAN is provided as part of the authorisation flow, which means you cannot select an account.