Using the sandbox for testing
Using the sandbox for testing
For each registered TPP system generates two sets of accounts.
Stateful accounts which are isolated for each TPP and maintain state. All changes on these accounts are preserved. Sandbox simulator will simulate the execution of the transactions posted and will update the account balances. At any time, these accounts can be reset to the starting point using the reset sandbox command in the Sandbox users section.
The following list enumerates the stateful accounts provided for testing:
Accounts for organizations
- Single currency transactional EUR account
- Multicurrency EUR and GPB transactional account
- Credit card
Accounts for individuals
- Single currency EUR transactional account with overdraft and one debit card
- Multicurrency EUR and GPB transactional account
- Gyro EUR account
- JOINT ownership EUR transactional account with overdraft and debit card
- Savings EUR account
Corporate and individual users
- Two organizations as customers each with two authorized users
- Two individual customers with own accounts where the other user is authorized person. Joint account is owned by both retail customers.
The other set is a number of stateless accounts which are special accounts used only for automated sandbox testing and for specific cases. These accounts are not isolated and they will not change their state when you use them. Payments posted to these accounts will not change their balance and posted payment won’t be visible in the queries.
The last two digits in the account number will be reserved for recognizing the kind of the account, stateful or stateless.
- 000000000000100 - stateful account
- 0000000000001XX – stateless account
The following table enumerates the special account
| ID | Type | Sandbox data associated to this account | Sandbox behavior |
|---|---|---|---|
| Establishing consents | |||
| XX | ibanConsentSuccessfulWithSca | Account with one transaction (an account opening transaction | The consents are generated and authorized as resources as well. In addition, the generated consents then are also used for testing the account access. For this account consent authorization will always pass assuming the use of correctPassword where applicable and correctOTP in the embedded SCA approach, within the multi-level SCA approach. Response code: HTTP 200 |
| XX | ibanConsentSuccessfulWithScaMulti | Account with one transaction (an account opening transaction | For this account consent authorization will always pass assuming the use of correctPassword where applicable and correctOTP in the embedded SCA approach, within the multi-level SCA approach. Response code: HTTP 200 |
| 06 | ibanScaInvalid | Account with one transaction (an account opening transaction). | All consents addressing at least one account which is provided under this tag will not be successful due to invalid SCA in a non-embedded SCA approach. Response code: HTTP 400 |
| XX | ibanServiceBlocked | Account with one transaction (an account opening transaction). | No consent generation will be successful on this account. Message code is SERVICE_BLOCKED. This service is not reachable for the addressed PSU due to a channel independent blocking by the ASPSP. Response code: HTTP 400 |
| XX | ibanScaInvalidMulti | Account with one transaction (an account opening transaction). | All consents addressing at least one account which is provided under this tag will not be successful due to invalid SCA in a non-embedded multilevel SCA approach. Response code: HTTP 400 |
| Accounts for payment Initiation | |||
| 01 | ibanPaymentSuccessfulWithSca | Account with one transaction (an account opening transaction). | All payment initiations will be successful for this account, assuming the use of correctPassword where applicable and correctOTP in the embedded SCA approach, where applicable. The cancellation of this payment is possible if supported in online banking. The reaction on the “DELETE" command will be as in the production environment. If a SCA is needed for cancellation, it will be successful for this account number using the correctPassword where applicable and correctOTP in the embedded SCA approach. All other endpoints for this account will work as well but will only return the test data. Response code: HTTP 200 |
| 02 | ibanPaymentUnsuccessfulScaCancellation | Account with one transaction (an account opening transaction). | All payment initiations will fail for this account. All other endpoints for this account will work as well but will only return the test data. Response code: HTTP 400 |
| 03 | ibanPaymentSuccessfulScaExemption | Account with one transaction (an account opening transaction). | All payments under 500 Euro submitted on this account will be performed successfully with SCA exemption. All other endpoints for this account will work as well but will only return the test data. Response code: HTTP 200 |
| 04 | ibanPaymentPendingNoFunds | Account with one transaction (an account opening transaction). | All payment initiations will be successful for this account, assuming the use of correctPassword where applicable and correctOTP in the embedded SCA approach, where applicable. The transaction status will be the final transaction code, with potentially fundsAvailable=false. All other endpoints for this account will work as well but will only return the test data. Response code: HTTP 200 |
| 05 | ibanPaymentFailedWithScaSuccessful | Account with one transaction (an account opening transaction). | For all payment initiations the SCA process will be processed successfully assuming the use of correctPassword in a non-embedded SCA approach, but the payment as such will not be performed due to e.g. daily limit reasons. In this case transactionStatus=RJCT. All other endpoints for this account will work as well but will only return the test data. Response code: HTTP 200 |
| 06 | ibanScaInvalid | Account with one transaction (an account opening transaction). | Payments initiated on this account will always require SCA, SCA will always fail All other endpoints for this account will work as well but will only return the test data. Response code: HTTP 400 |
| 07 | ibanExecutionDateInvalid | Account with one transaction (an account opening transaction). | Payments initiated on this account will always fail. Message code is: EXECUTION_DATE_INVALID. Independent of business rules, the execution date delivered in this test request will not be accepted by the sandbox. Response code: HTTP 400 |
| XX | ibanPaymentSuccessfulWithScaMulti | Account with one transaction (an account opening transaction). | All payment initiations will be successful for this account, assuming the use of correctPassword where applicable and correctOTP in the embedded SCA approach, within the multi-level SCA approach. The cancellation of payments is possible if also supported in online banking. The reaction on the "DELETE" command will be as in the production environment assuming the use of correctPassword where applicable and correctOTP in the embedded SCA approach, within the multi-level SCA approach. Response code: HTTP 200 |
| XX | ibanPaymentUnsuccessfulScaCancellationMulti | Account with one transaction (an account opening transaction | All payment initiations will fail. The cancellation of this payment is possible if also supported in online banking. The reaction on the "DELETE" command will be as in the production environment. SCA for the cancellation authorization will always fail for this account number. Response code: HTTP 400 |
| XX | ibanPaymentSuccess-fulScaExemptionMulti | Account with one transaction (an account opening transaction | All payments under 500 Euro submitted on this account will be performed successfully with SCA exemption. The reaction of the system regarding a multilevel authentication (e.g.) by a first factor is as in the production environment assuming the use of correctPassword where applicable and correctOTP in the embedded SCA approach, within the multi-level SCA approach. Response code: HTTP 200 |
| XX | ibanPaymentFailedWithScaSuccessfulMulti | Account with one transaction (an account opening transaction | The SCA process will be processed successfully in a non-embedded multilevel SCA approach, but the payment as such will not be performed due to e.g. daily limit reasons. In this case transactionStatus=RJCT. Response code: HTTP 200 |
| XX | ibanScaInvalidMulti | Account with one transaction (an account opening transaction | Payments initiated on this account will always re-quire SCA, SCA will always fail in an non embedded multilevel SCA approach. Response code: HTTP 400 |
| Account Access | |||
| XX | ibanWIthHighVolumesMulti | Account with 10 thousand-transaction approximately. Transaction are generated using the same template. | Same as ibanWithHighVolumes, but where a multilevel SCA is needed for authorising the con-sent. Response code: HTTP 200 |
| 08 | ibanWithHighVolumes | Account with 10 thousand-transaction approximately. Transaction are generated using the same template. | The indicated account is a specific account providing a lot of transactions. If a valid consent is used, the response for the transaction history endpoint will return a download option in the links section of the response. When the request header contains Download-Link = off parameter, the endpoint will return the transaction list with pagination Response code: HTTP 400 |
| XX | ibanServiceBlocked | Account with one transaction (an account opening transaction | Message code equals SERVICE_BLOCKED. This service is not reachable for the addressed PSU due to a channel independent blocking by the ASPSP for all consents. Response code: HTTP 400 |
| Stateless accounts for confirmation of funds test scenarios | |||
| 09 | ibanNoFundsAvailable | Account with one transaction (an account opening transaction). | Funds available request will always result in fundsAvailable:false Response code: HTTP 200 |
| 10 | ibanFundsAvailable | Account with one transaction (an account opening transaction). | Funds available request will always result in fundsAvailable:true Response code: HTTP 200 |
| 11 | ibanCardInvalid | Account with one transaction (an account opening transaction). | Funds available request will always result with CARD_INVALID Response code: HTTP 400 |
| 12 | ibanNotExisting | Account with one transaction (an account opening transaction). | Funds available request will always result with SERIVCE_INVALID Response code: HTTP 400 |
| 13 | ibanTppNotActivated | Account with one transaction (an account opening transaction). | Funds available request will always result with NO_PIIS_ACTIVATION Response code: HTTP 400 |
Access to the test data is provided through the sandbox users menu item.
Continuing with the process, users need to add an application to get the access credentials for the API.
TPP sandbox users
Provide access to the generated test users in order to obtain the credentials to get the user consent for access.
How to access
The access to TPP sandbox click on the Profile -> Sandbox users menu item.
Overview
The page will show all the customers created in the test environment.
Details about the specific user can be seen by clicking on a sandbox user from existing list as it’s shown below.
For every user the system will generate the same password which should be used in testing scenarios instead of correctPassword. For two factor authentication scenarios the correctOTP value is 12345.
Try API call
Only users with registered TPPs can test APIs using try API call functionality.
How to access
The access to try API call is allowed by clicking the APIs application top menu item and by selecting any of the available API from dropdown list. A new screen will be shown with all available documentation for that specific API, then by clicking Try link from API documentation header the user will be redirected to try API call.
Overview
The try API call screen is shown below. Follow these few steps to test try API call functionality:
Chose an Api, Api Version and an Api method from dropdown lists. Request URL will be generated automatically.
Enter the Client Id and the Client Secret, these values have been provided during application creation process (see chapter TPP applications).
Select a Grant Type:
- Client Credentials;
- Password Credentials.
- Certificate
If Password Credentials Grant Type is chosen two new fields will appear, Username and Password. Enter these values.
If Certificate Grant is chosen. Add the header with certificate field with the content of the Authentication Certificate file.
Fill in the mandatory header parameters Key and Value
Add request Body (if necessary).
Finally, click on button Send Request.
Client Id - The client identifier issued to the client during the Application registration process.
Client Secret - The client secret issued to the client during the Application registration process.
For certificate grant add the header parameter TPP-Authentication-Certificate and in the value paste the contents of the certificate with the content of the Authentication Certificate file.
Testing API using external tools
Use the sandbox environment to test the banks API.
What you need?
Created and active application for the TPP. On how to create the application please consult section two, chapter APP registration. Sandbox users. Created and active certificate for the TPP.
How to access
In order to test the API with the external in this manual we will use Postman (https://www.getpostman.com/) but any tool free for testing you can use any tool.
Overview
- Steps to test the application are following:
- Get the authorization token and provide consent for accessing the accounts
- Call the API with the token
The first step is to configure the postman tool to acquire the access token. Access token can be acquired using different flows in this example we are using Implicit flow.
In order to start the process, use the edit collection option from postman
Next step is to select the Authorization tab and select the Get New Access Token option. This will launch the dialog for filling in the parameters for getting a new access token.
Once you get to the get new access token dialog fill in the following fields with the proper data:
- Token Name: Token Name
- Grant Type: Implicit
- Callback URL: Put the https://www.getpostman.com/oauth2/callback
- Auth URL: Put the URL of the authorization endpoint. The format of this URL is /IAM/Connect/authorize.
- Client ID: Copy and paste the Client ID of your test application.
- Scope: Put AssescoSEE.PSD2
- Client Authentication: Send as basic header
After you have filled in the parameters request the new token. The flow will take you to the IAM login page where you will have to login on behalf of one of the Sandbox users. You can choose any Sandbox user and input the username and password
After login in as one of the customers using the provided username and password the system will ask you provide the consent for the user’s accounts. The simplest approach is select All accounts but you can tailor the consents based on your preference and test cases.
Once the consent is confirmed new access token will be issued.
After getting the token is to call the API and test.
Final step for sending the requests to Sandbox is to add the Authentication certificate to the request by copying the value from the AuthenticationCertificate.cer file to TPP-Authentication-Certificate header of the request.
The following example shows a call to get the list of accounts for the customer. List of APIs with required parameters and responses you can find on the portal under the section APIs.
