Architecture documentation provides a comprehensive architectural overview of the system, using a number of different architectural views to depict different aspects of the system. It is intended to capture and convey the significant architectural decisions which have been made on the system.
This document describes implementation details of XS2A Interface for Account Information Service, Payment Initiation Service, Payment Instrument Issuing Service, SCA Methods. Include Use-cases diagrams.
SPI Developer Guide provides instructions for implementing the Interfaces on the SPI level, describes special modes e.g. configuring Event-Service, Logging etc.
Version Policy describes the main rules of Versioning, Release numbering, and Support policy.
Roadmap contains brief information about upcoming features and bugfixes. May be changed without a note.
For the versions available, see the tags on this repository and Release notes for each version.
Release notes contain information about changes included into releases. Might contain also important migration information for the developers, how to migrate to a new version and how to use it.
This document contains a summary of how to report an issue to XS2A Team.
During request of Transaction List, in case when transaction report has a huge size, ASPSP can provide Download Link in Read Transaction List Response, it enables to download transaction report.
According to BG Specification every country can have their local requirements for information included in the Payment Request. Payment validation on XS2A side can support different countries.It is up to ASPSP to decide for which countries payment validation will be performed.
Service enables TPP to ask for additional account information during the consent creation process.ASPSP can provide service with explicit consent from the client and can deliver the account owner name with related account information.
OAuth Redirect SCA Approach The XS2A supports OAuth2 mode in two ways: as a Pre-step for PSU authentication and as Integrated OAuth SCA approach for the authorisation of payment/ consent/ payment cancellation.
It is up to ASPSP to decide the way of TPP’s role validation. Since the pasportisation process in place acts without changing the TPP’s certificate, XS2A can’t rely entirely on the roles from TPP’s certificate. TPP access to XS2A resources may be verified based on incoming Header, which can be set between ASPSP’s gateway by standalone service or be validated according to certificate data on XS2A side.
XS2A supports flows for multicurrency accounts.A multicurrency account is an account that is a collection of different sub-accounts which are all addressed by the same account identifier like an IBAN by e.g. payment initiating parties.The sub-accounts are legally different accounts and they all differ in their currency, balances, and transactions.An account identifier like an IBAN together with the currency always addresses a sub-account of a multicurrency account uniquely.
This service is offering a list of all standing orders related to a dedicated payment account.It can be provided during Read Transaction List Request/Response.
In case PSU decides to close an account in the bank - ASPSP enables to revoke all AIS and PIIS consents of account in one step.
A new feature enables to present Transaction List for the period dateFrom and dateTo, or all transactions after the transaction with identification "entryReference" and get all transactions after the last report access for this PSU (“deltalist”).
The new feature enables TPP to implicitly subscribe (registering implicitly an URI) for Resource Status Notification Service for the Payment Initiation Request, the Establish Account Information Request or the Signing Basket Request though XS2A interface.
Resource Notification Push Service will be implemented in the future and will allow TPP to receive push notifications about every change of Transaction/Consent/SCA statuses.
ASPSP can require the TPP to send a digital signature during initiation PIS or AIS requests. Digital signature can be validated in XS2A validator module, which contains validators for signature and digest Headers.A keyID check is also added.
For counteraction of the fraud attacks in the Redirect Approach, there is additional step for confirmation of Authorisation (Payment Initiation, Establish AIS Consent, Payment Cancellation process). TPP should provide confirmation Code during Confirmation of Authorisation Call.The verification of the Confirmation Code can be performed by XS2A or by ASPSP.
In accordance with new requirements of BG, usage of redirection URI in domains that are secured by the TPP QWAC is Optional (strong recommendation). Resulting from this the note was removed that ASPSPs may reject transactions if this requirement is not fulfilled. It is up to ASPSP to decide whether to validate TPP’s URIs for compliance or not.
Functionality allows ASPSP to deliver Card accounts related information through XS2A interface (details, transactions, balances, etc.). This endpoint is not directly related to credit cards as such, but the financial account behind the related cards.
Functionality allows PSU to Establish Funds Confirmation Consent to TPP through XS2A interface.