The following guide demonstrates how to use the PSD2 Open Banking APIs in the production environment, for PISP TPPs. If you have tested your application scenarios with the Sandbox APIs, there are only a few changes you need to make in order to go live.
If you haven’t familiarize yourself with the Sandbox APIs, please visit the Sandbox Guide Developer’s example page to learn more about the API calls and the PISP scenario.
According to the PSD2 Directive, Strong Customer Authentication (SCA) practices need to be implemented so that TPPs can initiate payments on behalf of the PSU. Amongst the available approaches, the Bank’s implementation supports both the SCA Redirect flow and SCA Embedded approach, with added OTP functionality.
SCA Redirect flow is used for PSU Authentication (OAuth):
SCA Embedded Approach is used whenever a payment initiation request is created by the TPP:
In the Sandbox flow, this procedure was simulated by using the one time password “123456”, and PSU data was mocked for testing purposes.
One more area that needs to be covered while moving into the production APIs, is the identification of TPPs. In the Sandbox Developers portal, Client ID and Client Secret parameters where produced for the test application, and where used in the API calls as an identification method for the TPP.
According to PSD2, only certified TPPs are allowed to access the Bank’s dedicated interface. TPPs need to carry a valid PSD2 eIDAS certificate (QWAC & QSealC) to identify themselves and use the APIs via a secured channel. The PSD2 eIDAS certificates are issued by Qualified Trusted Service Providers (QTSPs). The European Banking Authority (EBA) provides a list of the trusted QTSPs here.
So in order to use the production Open Banking APIs, instead of attaching only Client ID and Client Secret in your call headers, you also need to:
The XS2A interface will check the validity of the certificate against known formats, and also check the regulatory status of the TPP by referring to the TPP register provided by the EBA here.
We will cover a basic scenario, where an PISP TPP initiates a payment on behalf of the PSU.
NOTE: Once the consent is authorised by the PSU, the rest of the API calls regarding PISP services are identical to the Sandbox environment.
Flow
The API calls have been tested with the Postman application.
Payment Initiation
The required Header parameters:
The request Body:
This is a sample request Body, with staging data to demonstrate functionality. Here you would fill all the necessary data to execute a bank transfer.
Response (OTP is generated for secure authentication)
Authorise Payment (PSU provides the one-time password sent to his phone, to complete the authentication process)
The required Header parameters:
The Request Boby Format:
Response (Payment authorized):
You can now get the payment details via the “Get payment information” GET call, as well as check the payment status
TPP fetching payment details. After PSU has authorised the payment, transactionStatus has been changed to AcceptedSettlementCompleted
The above steps cover a basic PISP scenario using the production APIs. The guide was focused on demonstrating the SCA process and consent management. As a PISP, the above process has to be followed for every payment initiation.
