Test Signup+ in sandbox

Learn how to test different scenarios using our sandbox environment.

You can test Signup+ payments to UK and Finnish banks, as well as the data only flow.

📘

Use sandbox URLs

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

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-plus/payments endpoint.

Create and authorise a mock payment

Create a payment by calling the /payments endpoint. See our payments quickstart guide and Insomnia collection for Payments V3 for more information.

Include the following values:

FieldValue
provider_idmock-payments-gb-redirect
payment_methodbank_transfer
beneficiarymerchant_account
amount_in_minorValue for the scenario you want to test (see below)

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. The payment usually settles within a few seconds.

After this, you receive a response including a payment_id with a status of settled. We recommend that you wait for the payment_settled webhook.

To check the current status of the payment, call the /payments/{id} endpoint.

Test different responses

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

AmountSignup+ response
<10000Success: Identity data found
10000–25000 (inclusive)Error: Joint accounts not supported
>25000Error: User data not found

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 API reference and Insomnia collection can help you make this request. Include the id in the request.

Test age verification in a UK payment

As part of a payment into your merchant account, you can enable age verification. You have to contact us to enable this for you, in both the sandbox and live environments. This feature routes a payment through an intermediary TrueLayer account, checks the user is over 18 then either forwards the payment to you, or refunds it to the user. Verification can also check names, but you can't test this in sandbox with Signup+.

Included verification for your payments

If you've contacted us to enable verification for your client_id in sandbox, you can test it as part of a Signup+ payment in sandbox.

To test verification, ensure that you included payment_method.beneficiary.verification parameter in your closed-loop payment request to the /payments endpoint.

The verification parameter should have a value of true for the verification.date_of_birth, as you can only verify age in combination with Signup+.

Test Signup+ with age verification

Once verification is enabled and included in your request, using these values for the amount_in_minor parameter to test different possible outcomes:

AmountSignup+ response
<1800Error: Age not legal
1800-10000Success: Identity data found
10000-25000Error: Joint accounts not supported
>25000Error: User data not found

Test payments with Finnish providers

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
  • Failed authentication

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

Successful authentication and subsequent identity lookup

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

Then, to mimic a successful authorization with 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

This test is similar to the successful one, except that you must use a payment above 250 EUR.

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

Aborted authentication

To test this scenario, cancel the authentication process with any of the test providers on the identity provider selection screen. We recommend that you test with Aktia or Nordea.

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:

FieldValue
response_typecode
provider_idmock
scopesignupplus

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.

AccountScenario
25226660Success: Identity data found
18917060Error: Joint accounts not supported
00002724Error: User data not found

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:

FieldValue
provider_idob-natwest-vrp-sandbox
mandate.typesweeping
beneficiarymerchant_account
provider_idSuccess: identity data found
constraints.maximum_individual_amountValue for the scenario you want to test (see below)

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+:

AmountScenario
<100000Success: Identity data found
100000–250000 (inclusive)Error: Joint accounts not supported
>250000Error: User data not found

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 API reference and Insomnia collection can help you make this request.