XS2A Server TPP-Developer's Guide step by step

01. Getting Started

About the Service

XS2A is an interface that allows your application to communicate with payment and account services of various banks under PSD2 regulations.

The finAPI XS2A API is 100% compliant with the Berlin Group Standard. 

This documentation is about a so called Sandbox service that provides the possibility to test the access to bank data via the XS2A interface using test data.

 

How to Register

For XS2A Sandbox, no client registration is required.

 

XS2A API Access

In order to access XS2A API, several prerequisites must be met first, which are provided and authorised by third parties.

1. You must be registered as a PSP at NCA of your country (Bafin in Germany, FMA in Austria)
2. You must obtain a valid PSD2 compliant client certificate to authenticate your application to the XS2A API (see for example here https://www.bundesdruckerei.de/en/Service-Support/Service/Certificates-PSD2 on how to obtain a valid certificate)

 

02. Supported Authentication Methods

General information

XS2A interface offers embedded and decoupled SCA approaches with selection of SCA methods as mechanisms of payments and consents authorisation.

Within the embedded approach the communication between PSU and ASPSP is done through XS2A and TPP interfaces where

• ASPSP validates PSU credentials and the 2nd factor;
• XS2A provides TPP with authorisation instructions and error information;
• TPP provides PSU with authorisation instructions and error information.

The step when PSU receives the 2nd factor from ASPSP is handled directly between PSU and ASPSP - outside of the embedded SCA flow.

Within the decoupled approach the communication between PSU and ASPSP is done through XS2A and TPP interfaces where

• ASPSP validates PSU credentials and the 2nd factor;
• XS2A provides TPP with authorisation instructions and error information;
• TPP provides PSU with authorisation instructions and error information.

The steps when PSU receives the 2nd factor from ASPSP and provides it back to ASPSP for the validation are handled directly between PSU and ASPSP - outside of the decoupled SCA flow.

Flow diagrams

The diagrams below gives high-level overview of the embedded SCA message flow during payments and consent authorisation.

Consent authorisation with embedded SCA

Consent authorisation with decoupled SCA

Payment authorisation with embedded SCA

Payment authorisation with decoupled SCA

More details about payment authorisation are available at 3 How to initiate and authorise a payment.

More details about consent authorisation are available at 4 How to create and authorise a consent.

Supported SCA methods

Currently supported SCA methods

• CHIP_OTP - triggers embedded SCA
• SMS_OTP - triggers embedded SCA
• PUSH_OTP - triggers decoupled SCA

More information about SCA methods can be found in 09. Sandbox Test Accounts and Test Data.