Create new digital services
using Open Banking APIs
by Cooperative Bank of Epirus
according to PSD Directive

Learn more about PSD2
apis mouse

How to move to Production



1. Intro

The following guide demonstrates how to use the PSD2 Open Banking APIs of Cooperative Bank of Epirus in the production environment, for certified 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 familiarised yourself with the Sandbox APIs, please visit the Sandbox Documentation page to learn more about the API calls and the AISP/PISP/PIISP scenarios.

A Postman collection for the production environment is also available here

You can check the available PSD2 Production API calls from the Swagger UI:



https://api.psd2.epirusbank.com/swagger-ui.html#/



2. TPP Identification

The first 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 were produced for the test application, and were 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) 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 Client ID and Client Secret in your call headers, you need to:

  • provide your eIDAS certificate in the tpp-qwac-certificate header parameter.

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.




Note: On your first interaction with the API as a certified TPP, you might have to wait a few seconds to receive a response, in order for the regulatory checks to be performed. Once the eIDAS certificate validation is complete, subsequent calls will be performed faster.

If the certificate provided in the tpp-qwac-certificate is invalid (e.g the PSD2 roles required to perform the requested action do not exist), then you will get a “Certificate invalid” response with 400 error code as demonstrated in the picture below





3. SCA Workflow

According to the PSD2 Directive, Strong Customer Authentication (SCA) practices need to be implemented so that PSUs can authorise consents and provide TPPs with access to their accounts. Amongst the available approaches, the Bank’s implementation supports the SCA Redirect flow, with added OTP functionality.

More specifically, whenever a consent request is created by the TPP:

  1. a redirect link is created by the XS2A interface (scaRedirect)
  2. PSU is redirected to a secure environment provided by the Bank’s infrastructure
  3. PSU authenticates himself by providing his web banking credentials along with a one-time password (OTP) that is automatically sent to his/her phone
  4. PSU can then provide his consent so that the TPP can access his account information
  5. once the consent is authorised, PSU is redirected back to the TPP application

In the Sandbox flow, this procedure was simulated by the Sandbox server, and PSU data was mocked for testing purposes.

To manage consents, as well as the authorisation of PSUs in a secure environment, the Bank has developed a Consent management application that has the same look & feel as the one available in the Sandbox version, although it is connected to the Bank’s secure identity server.

In order to complete the Redirect SCA flow, you have to follow the steps above and provide the scaRedirect link to the PSU, who can authenticate by using his/her web banking credentials in the Bank’s safe environment.





4. General notes

Some things to consider:

  • As an AISP, the SCA process has to be followed once. Each account access consent has a validity of 90 days by default (unless explicitly requested for less). For this duration, you can implement the rest of the API calls for access to accounts as in the Sandbox case, with a maximum frequency of 4 invocations per day.
  • As a PISP, the SCA process has to be followed for every payment initiation. Once the user has given consent for a specific payment initiation, the payment is forwarded to the Bank’s system for processing. You can use the rest of the calls regarding a specific payment (such as check its status) as in the Sandbox case.
  • As a PIISP, you cannot invoke the Confirmation of Funds call immediately, as in the Sandbox case, where it is allowed for testing purposes. According to PSD2, the consent model for the Confirmation of Funds API differs from the Payments API and the Accounts API, as the consent is held between the PSU and the ASPSP, rather than between the PSU and the TPP.. In order to be able to perform a funds confirmation check, the TPP has to contact the ASPSP in order to get access to the service, by providing his eIDAS certificate for identification.




5. Conclusion

The guide was focused on demonstrating on how to move your application from the sandbox testing environment, to the production environment. For more detailed information on how to use the PSD2 APIs of Cooperative Bank of Epirus and implement basic scenarios, please visit the Sandbox Developers Portal and follow the instructions in the Documentation page.

Useful links: