This site contains the documentation that is relevant to older WSO2 product versions and offerings.
For the latest WSO2 documentation, visit https://wso2.com/documentation/.
Accounts Information Service Provider Flow v1.3.6
This document explains the flow of events related to the Account Information Service that an Account Information Service Provider (AISP) tries. For the Berlin specific solution, the Account Information Service is exposed as an API resource in NextGenPSD2XS2AFramework of WSO2 Open Banking. In the Account Information Service, an AISP can access and retrieve account information of a Payment Services User (PSU) and the PSU authorises the AISPs to access and retrieve their account, transactions, and balances information.
Before you begin,
You need to deploy the NextGenPSD2XS2A API v1.3.6.
You can try out the Account Information Service flow in WSO2 Open Banking using the following steps:
- Step 1 - Sign up as a TPP
- Step 2 - Sign in to the Developer Portal as the TPP
- Step 3 - Create an application
- Step 4 - Subscribe to API
- Step 5 - Create and upload certificates
- Step 6 - Generate keys
- Step 7 - Generate application access token
- Step 8 - Initiate account consents
- Step 9 - Initiate an authorisation flow for an account consent
- Step 12 - Generate user access token
- Step 13 - Invoke Account Information Service APIs
Step 1 - Sign up as a TPP
In this step, the TPP registers its TPP application in the WSO2 Open Banking Developer portal.
Step 2 - Sign in to the Developer Portal as the TPP
Users can sign in to WSO2 Open Banking Developer portal with the authentication details created during sign up.
Step 3 - Create an application
The TPP with a CBPII application needs to create an application using WSO2 Open Banking Developer portal. The application created via the Developer portal allows to observe statistics of APIs, subscribe to APIs, and access the subscribed APIs.
Step 4 - Subscribe to API
The TPP user needs to subscribe to the NextGen PSD2 XS2A Framework API in order to access the API resources. Once subscribed, the users can access all the supported services of the API resources.
Step 5 - Create and upload certificates
The TPP user needs to create certificates to validate whether the TPP is registered in a governing entity. It is verified in the TPP Onboarding process. eIDAS root certificates obtained from the Qualified Trust Service Providers must be added to the client trust stores of the WSO2 Open Banking Identity and Access Management and WSO2 Open Banking API Management modules. For testing purposes, create a self-signed root certificate following the instructions given below:
Once you create a self-signed root certificate, upload it to the client trust stores of WSO2 OB APIM and WSO2 OB IAM.
- Locate the client trust stores in WSO2 OB APIM and WSO2 OB IAM in the following directory paths:
<WSO2_OB_APIM_HOME>/repository/resources/security/client-truststore.jks
<WSO2_OB_IAM_HOME>/repository/resources/security/client-truststore.jks
Use the following command to upload the self-signed certificate:
keytool -import -alias <alias> -keystore cacerts -file <PEMFileName>.pem
Step 6 - Generate keys
The TPP user requires a Client ID (Consumer Key) to access the subscribed APIs.
Step 7 - Generate application access token
When invoking APIs in the NextGenPSD2XS2A framework, application access tokens must be generated using the client credential grant type. The generated application access token is used to invoke the API.
Step 8 - Initiate account consents
In this step, the TPP creates a request to get the consent of the PSU to access the accounts and its information from the bank. The Bank sends the request to the PSU stating the accounts and information that the TPP wishes to access. Upon the user approving or denying the account consent, the TPP is now eligible to access the user's account details.
Step 9 - Initiate an authorisation flow for an account consent
WSO2 Open Banking for Berlin Implementation supports both implicit and explicit authorization flows for account authorization. In both cases, TPP generates the authorization URL using the well-known configuration that is received from the ASPSP as scaOAuth
link in the response.
Implicit authorisation
In this approach,
- ASPSP creates authorization sub-resources after the account consent is received
- ASPSP replies with the well-known configuration of the Identity and Access Management module in the links section of the response
- TPP generates the authorization URL using the well-known URL
- PSU goes through the authorisation flow with that authorisation URL
Explicit authorisation
In this approach,
- TPP initiates the authorization flow by invoking the
POST /consents/{consentId}/authorisations
API resource - At this point, the ASPSP creates authorization sub-resources and reply with the well-known configuration of the Identity and Access Management module in the links section of the response
- TPP has to generate the authorization URL, which the PSU uses to go through the authorization flow later
Authorisation URL
Step 12 - Generate user access token
The TPP must obtain a user access token to invoke the APIs mentioned under Invoke Account Information Service APIs section.
Step 13 - Invoke Account Information Service APIs
Following are the API functionalities available for the Account Information Service in 1.3:
- GET /accounts - Read account lists
- GET /accounts/{account-id} - Read account details
- GET /accounts/{account-id}/balances - Read balances
- GET /accounts/{account-id}/transactions - Read transaction list of an account
- GET /accounts/{account-id}/transactions/{transactionId} - Read transaction details
- GET /card-accounts - Read a list of card accounts
- GET /card-accounts/{account-id} - Read details of a card account
- GET /card-accounts/{account-id}/balances - Read balances of card accounts
GET /accounts - Read account lists
The user can retrieve a list of accounts (bulk accounts) of a PSU. Following are the sample request and the response to call Get /accounts API resource.
GET /accounts/{account-id} - Read account details
The user can retrieve details of an account that consent is already granted by the PSU and stored in the ASPSP system. Use the sample request to generate a sample response as given below.
GET /accounts/{account-id}/balances - Read balances
The user can retrieve account data for a consent-granted account. Use the sample request to generate a sample response as follows:
The account addressed by the account-id is constant until the consent granted to that specific account expires.
GET /accounts/{account-id}/transactions - Read transaction list of an account
The user can retrieve transaction reports and transaction lists for a consent-granted account using the sample request given below. Users can choose the type of transaction using the booking status
parameter. For a given account, a user can specify dateFrom
and dateTo
parameters.
The allowed values for the booking status parameter are booked, pending, both and information.
- The value both is to request transaction reports where the booking status is either booked or pending.
- Currently, booking status information only covers standing orders.
GET /accounts/{account-id}/transactions/{transactionId} - Read transaction details
The user can retrieve transaction information for a specific transaction.
This call generates responses for the transactions that are reported in the JSON
format.
Use the sample request and generate a response as follows:
GET /card-accounts - Read a list of card accounts
The TPP can retrieve a list of card accounts. You can specify PSU ID to check the card-accounts that the PSU have consented. Additionally, you can retrieve balances of card accounts in the response. See below for a sample request and response.
GET /card-accounts/{account-id} - Read details of a card account
Retrieves information of a specific card account that the PSU has consented. See below for sample request and response information:
GET /card-accounts/{account-id}/balances - Read balances of card accounts
The TPP can retrieve balance information for a specific account by calling this API resource.