Consume the API

The features are described hereafter only from a functional standpoint. The technical aspects are included in the section « use cases ». You also need to be familiar with PSD2 terminology. You may also use the Frequently Asked Questions (FAQ) or our the virtual assistant .

The STET standard proposes two consent management models : the full-AISP model and the mixed model. The mixed model only was implemented.

Description of the services provided

• Introduction - AISP mixed consent vs AISP full consent
  

The STET standard proposes two consent management models : the full-AISP model and the mixed model. The mixed model only was implemented.

The following process describes the implementation of this model, and especially the use of the PUT /consents request which allows the AISP to forward the details of the PSU consent.

This process summarizes the sequence of the AISP API requests calls from different methods of AISP API and token retrieval, to the accounts, delayed debit cards and their balances / transactions / outstandings and slips retrieval, as well as the customer identity retrieval.

• Prerequisite

As TPP you have to be accredited by a national competent authority for this Account Information Service Provider ("AISP") role. 

To access payment initiation API methods, you have to get an OAUTH2 access token provided by customer's banking institution, obtained with your credentials.

You and the customer's banking institution have successfully processed a mutual check and authentication (exchange of eIDAS QWAC certificates).

Then, you present your OAUTH2 access token to consume the account information API's methods.

• Aggregate data

API account information use case :

The AISP asks the customer (PSU) in which banking institution (ASPSP) is(are) located his account(s).

The authentication method supported by the institution is the REDIRECT approach :

Authorization access as AISP granted by the connected PSU - retrieval of the initial access token valid for 90 days and the refresh token

1) The customer is redirected to identification screen proposed by his banking institution and he will enter his online banking identifier.

If the AISP provides client's online banking identifier directly in this request, this step will be skipped.

2) The customer is redirected to a an authentication screen proposed by his banking institution to validate its identity.

The process for this step depends on SCA method provided to the customer by his bank (OTP SMS, Secur'pass, etc.).

It also depends on PSU's device (PC, mobile, smartphone, tablet).

3) The customer is redirected to AISP's APP.

The AISP provides a "call-back" URL (redirection) when he asks for an access_token : it we be called by customer's bank. 

First access to get the customer accounts list

To get the customer's accounts list with a first access to the GET /accounts method by providing your access token for this customer (see use case "Get accounts list").

You don't have access to following informations:

accounts balances;

URT to GET /accounts/balances method;

URI to GET /accounts/transactions method;

URI to GET /trustedBeneficiaries method => this feature will not be available in 2020.

Customer name and given name.

As long as you don't transmit the customer by using PUT /consents method:

You can always retrieve the customer accounts list with GET /accounts method, but you won't have more information than the first access with this method;

if you try to use the GET /accounts/transactions method, the request will be rejected;

if you try to use the GET /accounts/balances method, the request will be rejected;

if you try to use the GET /trustedBeneficiaries method, the request will be rejected => this feature is not available for Banques Populaires : error code HTTP 501.

The customer select the accounts he consents to give you your application access

You ask the customer to select the accounts the possible operations on his accounts (balances retrieval, transactions retrieval, …).

Consent transmission

You send us the accounts list the customer consented to you with the PUT /consents method by providing your access token for this customer (see use case "Forward customer's consent"). The code http 201 : created is returned.

You specify the accounts list (IBAN) the customer has consented to transmit the balances and / or transactions

You specify whether the customer has consented to the trusted beneficiaries retrieval and to his name and given name retrieval

If you already transmitted the customer accounts with the PUT /consents method, and then the customer changes his consent, you send a new consented accounts list with the PUT /consents method, it will cancel and replace the previous consent.

If you send an empty list of consented accounts for the balances and the transactions, and psuIdentity field and trustedBeneficiaries field with FALSE value, then it means there isn't any consented account.

You can send a consented accounts list without using first the GET /accounts method, in the case for example where the customer gave you directly his accounts IBAN.

Second access for a customer accounts list retrieval

You can retrieve the customer accounts list with all details by doing a second access à to the GET /accounts method byt providing your access token for this customer (see use case "Get accounts list").

You get the following informations :

the consented accounts

the delayed debit cards linked to consented accounts

the consented accounts balances;

URI to the GET /accounts/balances method for the consented accounts

URI to the GET /accounts/transactions method for the consented accounts

The customer name and given name depending on the value if the flag "psuIdentity" = TRUE has been transmitted with the PUT /consents method

You dont get the following informations  :

URI to the GET /trustedBeneficiaries method => this feature will not be available in 2020.

Consented accounts balances and transactions retrieval, delayed debit cards outstandings and slips retrieval for the cards linked to consented accounts

For every consented account, you retrieve the accounts balances with an access to the GET /accounts/balances method by providing your access token for this customer (see use case "Get accounting balance") and by using the URI previously transmitted by the GET /accounts method for the "_links" "balances"

For every consented account delayed debit card, you retrieve the card outstandings with an access to the GET /accounts/balances method by providing your access token for this customer (see use case "Get accounting balance") and by using the URI previously transmitted by the GET /accounts method for the "_links" "balances" 

For every consented account, you retrieve the account transactions with an access to the GET /accounts/transactions method by providing your access token for this customer (see use case "Get transactions history") and by using the URI previously transmitted by the GET /accounts method for the "_links" "transactions"

For every consented account delayed debit card, you retrieve the accounts slips with an access to the GET /accounts/transactions method by providing your access token for this customer (see use case "Get transactions history") and by using the URI previously transmitted by the GET /accounts method for the "_links" "transactions"

If you try to use the GET /accounts/transactions method for a non consented account ou for a non consented account linked delayed debit card, the request will be rejected

If you try to use the GET /accounts/balances method for a non consented account or for a non consented account linked delayed debit card, the request will be rejected

Accounts informations refresh in batch mode

For every customer and for every consented account or delayed debit card linked to an account of this customer, you can refresh the customer data (same as step "Second access for a customer accounts list retrieval" and "Consented accounts balances and transactions retrieval")

The maximum limit of batch calls to GET /accounts method is up to 4 per day for one customer/account per access page

The maximum limit of batch calls to GET /balances method is up to 4 per day for one customer/account

The maximum limit of batch calls to GET /transactions method is up to 4 per day for one customer/account per access page

The maximum limit of batch calls to GET /balances method is up to 4 per day for one customer/card

The maximum limit of batch calls to GET /transactions method is up to 4 per day for one customer/card per access page

Accounts informations refresh on customer request from his mobile phone, for the customer and for every customer consented account

For every customer and every consented account or delayed debit card linked to a customer account, our customer can ask to refresh his data from your application (same as step "Second access for a customer accounts list retrieval" and "Consented accounts balances and transactions retrieval")

No access limit for this case on contrary to the batch accesses

If the 90 days token has expired, you must do a token refresh demand for the customer

1) With our connected customer on your application, you submit a token refresh request for this customer (see use case "Refresh your access token")

2) The customer is redirected to identification screen proposed by his banking institution and he will enter his online banking identifier.

If the AISP provides client's online banking identifier directly in this request, this step will be skipped.

3) The customer is redirected to a an authentication screen proposed by his banking institution to validate its identity.

The process for this step depends on SCA method provided to the customer by his bank (OTP SMS, Secur'pass, etc.).

It also depends on PSU's device (PC, mobile, smartphone, tablet).

4) The customer is redirected to AISP's APP.

The AISP provides a "call-back" URL (redirection) when he asks for an access_token : it we be called by customer's bank. 

5) You get the refresh token for this customer and you will be able to access customer data for 90 days again with the methods of this API