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
This document explains the flow of events related to the Account Information Service (AIS) that an Accounts Information Service Provider (AISP) tries. For the Berlin specific solution, AIS is exposed as an API resource in NextGenPSD2XS2AFramework - 1.3.4
of WSO2 Open Banking. In the Account Information Service;
TPP can access/retrieve account information of PSUs (Payment Servicing Users).
PSUs can authorise the TPPs to access/retrieve their account, transactions, and balances information.
Before you begin,
You need to deploy the Account Information API in the <WSO2_OB_APIM_HOME>/repository/resources/finance/apis/berlin-group.org/PSD2API_1.3.3/psd2-api_1.3.3_20190412.yaml
file. Click here to see how to deploy APIs for WSO2 Open Banking Berlin.
Users can test the Account Information Service in WSO2 Open Banking using the following steps that are described below.
- Step 1 - Sign up as a TPP
- Step 2 - Approve the TPP
- Step 3 - Sign in to the API store as the TPP
- Step 4 - Create an application
- Step 5 - Subscribe to API
- Step 6 - Create and upload certificates
- Step 7 - Generate keys
- Step 8 - Approve Production Key generation
- Step 9 - Generate application access token
- Step 10 - Initiate account consents
- Step 11 - 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 WSO2 API store.
Step 2 - Approve the TPP
Now that you have signed up as a TPP, an admin who overlooks all TPP sign-up forms must approve it.
It is not mandatory to include the approval step for approving the TPP. In order to add this step, you need to configure workflows in the WSO2 Open Banking solution. For more information on configuring workflows, see /wiki/spaces/OB150/pages/27919307.
Step 3 - Sign in to the API store as the TPP
Users can sign in to the API store and proceed with the steps mentioned below.
Step 4 - Create an application
The TPP needs to create an application in WSO2 API store that represents its TPP application. The application created via WSO2 API store allows to observe statistics of APIs, subscribe to APIs, and generate keys for the subscribed APIs.
Step 5 - Subscribe to API
The TPP user needs to subscribe to the
NextGenPSD2XS2AFramework - 1.3.3
API in order to access API resources. Once subscribed to the
NextGenPSD2XS2AFramework - 1.3.3
API, the users are subscribing to all the supported services of Accounts, Payments and Confirmation of Funds API resources.
Step 6 - Create and upload certificates
The TPP user needs to obtain an eIDAS certificate from a Qualified Trust Service Provider (QTSP) that validates whether the TPP is registered in a governing entity. It is verified in the TPP Onboarding process.
For testing purposes, WSO2 Open Banking provides a sample eIDAS certificate. To download the sample eIDAS certificate, click here.
Upload the downloaded sample eIDAS certificate to the client trust stores of WSO2 OB APIM and WSO2 OB KM.
- Locate the client trust stores in WSO2 OB APIM and WSO2 OB KM in the following directory paths:
<WSO2_OB_APIM>/repository/resources/security/client-truststore.jks
<WSO2_OB_KM>/repository/resources/security/client-truststore.jks
Use the following command to upload the certificate:
keytool -import -trustcacerts -alias <<alias>> -file <<path_to_sample_eIDAS_cert>> -keystore <<path_to_truststore>> -storepass wso2carbon -noprompt
Step 7 - Generate keys
The TPP user requests client ID and client secret to access the subscribed APIs.
Step 8 - Approve Production Key generation
This step includes instructions to an Approver user to review and approve a request to generate production keys for an application.
It is not mandatory to include the approval step for the Production Key generation. In order to add this step, you need to configure workflows in the WSO2 Open Banking solution. For more information on configuring workflows, see /wiki/spaces/OB150/pages/27919307.
Step 9 - Generate application access token
When invoking APIs, application access tokens must be generated using the client credential grant type. The generated application access token is used to invoke the NextGenPSD2XS2AFramework-1.3.3
API.
Step 10 - 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 11 - 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
- The TPP invokes the
POST /consents/{consentId}/authorisations
API resource to authorise a particular account - The TPP generates the authorisation URL using the well-known URL under
scaOAuth
link in the response
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.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 /card-accounts/{account-id}/transactions - Read transaction list of a card account
GET /accounts - Read account lists
The user can retrieve a list of 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.
GET /accounts/{account-id}/transactions/{transactionId} - Read transaction details
The user can retrieve transaction information for a specific transaction. The path of xxx is denoted under _links
subfield in the response generated by calling the G
ET /
accounts/{account-id}/balances
API resource.
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.
GET /card-accounts/{account-id}/transactions - Read transaction list of a card account
The TPP can retrieve a list of transactions of a card account that the PSU has consented. Sample request and response look as follows: