Test Signup+ in sandbox

Learn how to test different scenarios using our sandbox environment.

📘

Using the sandbox environment

To ensure you make requests to the sandbox environment, use the sandbox base URL before any requests. This is:

https://api.truelayer-sandbox.com/

Test payments with UK providers

Before you can test the Signup+ payments flow in sandbox, you must have a payment with a status of settled. After that, you can use the payment id to make a request to the Signup+ /signup-plus/payments endpoint.

Create a payment

See our documentation about how to create a payment. Additionally, our payments quickstart guide and Insomnia collection for Payments V3 may be useful.

The first step is to create a payment in the sandbox environment. Include the following values:

Use the signupplus scope when authenticating the payment, so that you can use the same token with the /signup-plus/payments endpoint later.

📘

Set beneficiary to merchant_account

Signup+ does not support open-loop payments.

The sandbox payment authorisation flow redirects you to a mock UI provider where you authorise the payment. After authorisation, the payment usually settles within a few seconds. After this, you should have a payment_id with a status of settled available to use. We recommend that you wait for the payment_settled webhook.

If needed, call the /payments/{id} endpoint to check the current status of the payment.

Test different payments flow responses

Adjust the amount of the payment (amount_in_minor field) to test different scenarios with Signup+:

📘

Amount in minor notation

Make sure to convert the above amounts to minor notation when invoking our Payments API. For example, 250 GBP is 25000 in minor notation.

Make a payments request to Signup+

At this point, you should have a payment id for a settled payment, which was authorised with the signupplus scope enabled.

Make a GET request to the /signup-plus/payments endpoint. The Signup+ API reference and Insomnia collection can help you make this request. Include the id in the request.

Test payments with Finnish providers

When integrating with Finnish banks, there are 3 test scenarios that you can trigger in our sandbox environment:

• Successful authentication at the identity provider and subsequent user data lookup
• Aborted authentication at the identity provider
• Failed authentication at the identity provider

Follow this guide to create a payment, generate an authorisation link and finally retrieve the payment's remitter identity.

Success authentication and subsequent identity lookup

To test the happy path, create a payment with an amount up to 250 EUR.

Then, to mimic a successful authorization on the identity provider, refer to this test users table.

OP and Aktia are usually the easiest providers to test with, as they have auto-filled user credentials on their test login pages.

Once the authorisation process is completed, validate that the outcome query parameter is set to success. You can then use the id of the payment and the received authorization_reference to lookup the user's identity.

Failed authentication of the identity provider

This test is very similar to the successful one. You must use a payment with an amount above 250 EUR.

At the end of the authentication process, validate that the received outcome query parameter is set to error.

Aborted authentication of the identity provider

To test this scenario, cancel the authentication process with any of the test providers on the identity provider selection screen. Aktia or Nordea are usually good candidates for testing this flow.

At the end of this flow, validate that the outcome query parameter is set to abort.

Test the data only flow

Before you test the Signup+ data only flow, you must have one or more accounts already linked to a bearer token. After that, use the account_id to make a request to the /signup-plus/accounts endpoint.

The first step is to generate an authorisation link in the sandbox environment. Include these values:

Ensure you have access to the return URI (you can set this in Console).

Then, after opening the authorisation link into a browser, enter some test credentials. Using john/doe will return 3 accounts, 1 for each scenario.

After you successfully authorise the account connection, you're redirected to your return URI, which displays a code query parameter to grab.

Make a data request to Signup+

With the code you received in the previous step, make a request to the /signup-plus/accounts endpoint either with or without providing the account_id query parameter.

Test the variable recurring payments flow

Before you test the Signup+ recurring payments flow, you need an authorised mandate. After that, use the mandate id to make a request to the /signup-plus/mandates endpoint.

Create a variable recurring payment mandate

See our documentation about how to create a mandate. Additionally, our Insomnia collection for Payments V3 may be useful.

The first step is to create a mandate in the sandbox environment. When you do so, supply the following fields:

📘

Set beneficiary to merchant_account

Signup+ does not support open-loop payments.

Use the signupplus scope when authenticating the mandate, so that you can use the same token with the /signup-plus/mandates endpoint later.

Test different variable recurring payments flow responses

Adjust the value of the constraints.maximum_individual_amount in your sandbox payment (regardless of currency) to test different scenarios with Signup+:

📘

Amount in minor notation

Convert the above amounts to minor notation when invoking our Payments API. For example, 1000 EUR is 100000 in minor notation.

Make a variable recurring payments request to Signup+

At this point, you have a mandate id for a mandate with a status of authorized, which was authorised with the signupplus scope enabled. It is recommended to wait for the mandate_authorized webhook.

This means you can make a GET request to the /signup-plus/mandates endpoint.

The Signup+ API reference and Insomnia collection can help you make this request.