Getting started
How to register
Register to get access to test environment. Registered users can create a test TPP profile and download a testing certificate which is used to access the system and have a dedicated test data for testing the bank exposed API’s.
What do you need?
Access to any valid e-mail address or valid GitHub account.
How to start?
The access to the register form is allowed by clicking the Register menu item.
Overview
In order to get the full access to the test environment and obtain the test credentials and dedicated test data TPP must go through the following process.
- Creating a developer account to access the system
- Registering a TPP
- Creating one test application
- Download test certificates to access the system
To launch the process click on the Register button in the main menu. As a first step of the process the registration form is presented to enter user information.
New users must fill in the following fields:
- First name Required, first name of the user
- Last name Required, last name of the user
- Email address Required, unique and valid email address which will be used as a username to access the system
- Company name Optional, Name of the company the user is working for
- Password Required, masked, must satisfy password complexity
- Password confirmation
Required, must match the password field
After clicking on the register button, the user will get the message that an email confirmation is required in order to continue the process.
Clicking on the provided link, the user will be redirected to the final screen that shows the confirmation message. With this final step of the registration process the user account is created.
Users who try to use the system before completing the email confirmation will be presented with a message that email confirmation is required.
Registering using existing and valid GitHub account
Users that have valid GitHub account can easily register by associating the GitHub login with the portal user account. To launch the process of registration using the GitHub account users can click on the GitHub option on the login page. After logging to GitHub new users will have to give permission to access the public data of their profile.
After the authorization is provided users will have to complete the registration by associating the user account of the portal to the GitHub login.
In order to do this, new users must provide the following information:
- First name Required, first name of the user
- Last name Required, last name of the user
- Email address Required, unique and valid email address which will be used as a username to access the system
Clicking on the register button the process is complete. Next time users can log in with the GitHub account and they will be allowed to use the portal. After completing the user registration process users can continue with the TPP registration process.
Without completing the next steps registered users have access to view and download the API definitions.
Third party provider registration
According to PSD2 regulation only registered legal entities can access the banks API. The registration and verification of the entity is the responsibility of the accredited national authorities which provides the TPP certificate for them. To simulate this, in test environment users must provide the organization information to be registered as third party providers. Each user can register only one third party provider. If there is a need to test various profiles like AISP or PISP use the application section to add applications with different roles.
How to access
The access to the TPP registration one clicks on the Registration menu item under the TPP Information menu.
Overview
To complete the registration as a TPP provider users must complete the TPP registration form.
TPP registration
- Name Required, full name of the organization
- Phone number Required, phone number for the purpose of contacting the organization
- Email address Required, unique and valid business email address for the purpose of contacting the organization
- Country
Required, country where the organization is registered
Clicking on Register button and completing the TPP registration process. The system will automatically seed the test data for the registered TPP.
For each registered TPP system generates two sets of test accounts.
Stateful accounts which are isolated for each TPP and maintain state. All changes posted on these accounts are preserved. Sandbox simulator will simulate the execution of the transactions 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
- Multi-currency EUR and GPB transactional account
- Credit card
Accounts for individuals
- Single currency EUR transactional account with overdraft and one debit card
- Multi-currency 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.
- 0000000000001OO- stateful account
- 0000000000001XX– stateless account
The following table lists 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 applications
Applications allow registered TPPs to select the specific PSD2 API capabilities they want to test. Every app gets a unique set API client credentials. Application also provide the users with the needed OAUTH2 client credentials to access and test the API in the API test console.
How to access
The access to TPP applications is accessed by clicking the Profile -> Applications menu item in the menu
Overview
Applications overview page shows all the created applications. When there are no plications users can click on the create new button.
When the new application is created users have to provide the following information:
- Client name Required, name of the application helps the user to identify it
After clicking on the Create button the system will store the information and create a new application. The newly created application will be shown with the Client Id and Client Secret. The user has to copy these data right after the application has been created if he wants to use them for Try API Call functionality otherwise, he will have to generate a new the next time he opens the application details this page.
Creating applications – Created application with client id and client secret generated
- Client Id
The public identifier for application. Clicking on the Copy button place this information on the clipboard - Client Secret
The secret known only to the application and the authorization server. Clicking on the Copy button place this information on the clipboard
Number of applications is not limited and each created application will be shown inside list of applications. The possibility to enable/disable an application by clicking on Enable or Disable buttons provides the possibility to test different scenarios.
TPP certificate
TPP Certificates are self-signed QWASP certificates issued by the bank for the purpose of testing the programmable access to API. In order to obtain the certificate users must fill in the certificate parameters presented on the screen. The system can issue one certificate per registration.
How to access
The access to TPP certificate is allowed by clicking the Profile -> Certificate menu item on the application menu.
Overview
TO create the certificate users must fill in the certificate request form
TPP certificate request
- Name Required, Certificate holders name
- Company name Required, company name
- State or Province name Optional,
- Locality name Optional,
- Organization name Optional
- Common name Required
- Email address Optional
- Domain Required, must match the domain from where the calls to the API will be made
- NCA ID Optional, National registry identity
- NACA Name Optional, Name of the national registry
- Has AI role Optional, selected when the TPP will be acting as account information service provider (AISP)
- Has PI role Optional, selected when the TPP will be acting as payment initiation provider (PISP)
- Has AS role Optional, selected when the TPP will be acting as Account servicing provider (ASP)
- Has IC role Optional, selected when the TPP will be issuing card-based payment instruments (CISP)
After filling in the required fields the system will generate two certificates which can be used for testing purposes. Once created the certificate can’t be changed but they can be deleted and you can generate new ones with additional roles.
Clicking on the Download button will start the download of Zip archive with the two certificates. When you open the ZIP file you will find the authentication certificate and signature certificate.
This step completes the process of registration as TPP.