How to test the APIs using the sandbox

The sandbox is available at domain.

Mutual TLS

Every API you call on is protected by mutual TLS, exactly as in the Production environment.

You can find the guide about mutual TLS here.

In the sandbox environment you don't have to generate your own client certificate, you can simply use our predefined set of certificates here.

HTTP Signature

We tried to make the sandbox enviromnent as similar as possibile to Production. Therefore, you have to sign every HTTP request with a QSEAL certificate even in sandbox; the signature will be actually validated.

You can find the complete guide about how to sign an HTTP request here.

You don't have to generate your own QSEAL certificate, you can simply use our predefined set of certificates here.

Sandbox certificates

See Security requirements for Sandbox environment

WARNING: these certificates are temporary and subject to change in the next few months

Obtain OAuth access token

You can obtain a sandbox valid access token only if you have requested a test Application. Once you have your client_id and client_secret, you can start the OAuth authentication flow as usual.

In the sandbox domain you can test a complete OAuth authorization_code flow. The given access token will be valid only for sandbox APIs.

Here's the schema for sandbox OAuth flow

OAuth 2.0 Sandbox flow

Test data

In the sandbox enviroment you can call all the APIs involved in the PSD2. The responses format is the same as our Production APIs; however, the returned data is completely fake, in order to avoid exposing customer data.

Please note that the OAuth access token is required and will be validated to be able to call sandbox APIs successfully.

At the moment, only one mock case is available for each API; in the future we will expand the dataset with more cases (new customers, new products, ...)

Workflow with Strong Customer Authentication

Some operations, in production environment, will need a Strong Customer Authentication to be performed. In order to make the sandbox as much complete as possible, we implemented a SCA "simulation" in the sandbox environment. Practically, when you want to test an operation which requires a SCA (e.g. bank transfer), you'll have to follow the workflow defined here also in the sandbox. The difference from the production environment is that the /private/auth/security/sca/{resourceId}/approach will return a "fake" authorization page, in which you'll be able to choose to authorize (or not) the operation without inserting the real credentials.

The advantage of this process is that you can test the complete redirect flow in your application: your application will perform a redirect to our authorization page, and the authorization page will redirect the user again to your application (using the chosen callback URL).

Here's the complete schema of the workflow (the example is based on the money transfer operation) SCA Sandbox flow

Force PSD2_SCA_REQUIRED error for inquiry APIs

In order to test the SCA workflow for inquiry APIs that expose sensitive data (see here), you can force the PSD2_SCA_REQUIRED error for inquiry APIs (e.g. _/private/customers/{customerId}/products/{productId}/transactions/retrieve) by adding the header force-sca-request: true to the request.