➤ Introduction

This service is mandatory as required by Caisse d'Epargne ASPSP as part of the "Mixed" model.

➤ Prerequisites

It is necessary to fulfill the eligibility prerequisites and to have retrieved the OAUTH2 access token (see the "Overview"> "Recover your token" section). 

You can retrieve the list of the customer's eligible payment accounts after calling the GET / accounts request for the first time: you will find the IBAN associated with each account, ie "accountId": {"iban": " "}.

However, if you already know the IBAN (s) for the customer's payment accounts, you can send them to us directly via the PUT / consents method.

WARNING: as long as you have not communicated to the account keeper (ASPSP) at least one account authorized with the PUT / consents method, or if no account is authorized, the GET / accounts method will not return the information requested but only the list of all current accounts (principle of "AISP mixed consent").

➤ Request 

Method "PUT /consents"

 See also STET specification V1.4.2.17 / Part II / section 4.4. / page 15.

The PSU specifies to the AISP which of his/her accounts will be granted and which data should be available : it gives his consent and included four access types (or operation types) :

• balances : access to one or many PSU accounts balance report

• transactions : access to one or many PSU accounts transactions history

• psuIdentity : access to PSU identity (name & surname for retail customer, ot corporate ID for a company)

• trustedBeneficiaries : access to the trusted beneficiaries list that have been set by the PSU => this feature is not supported by the ASPSP online banking. So whatever value is used (True/False), it won't be used.

The AISP forwards details of PSU consent to the ASPSP through this call. The consent is recorded by the ASPSP for one given PSU, one given AISP, one given operation and one given account (except for the psuIdentity and the trustedBeneficiairies access types).

Each new API request calls the ASPSP consent service, for one given PSU, replaces any prior consent that was previously sent by the AISP.

Furthermore, upon the PSU's request, the consent may be updated subsequently for an operation type : for example, access to transactions can be revoked while access to balances stay active.

• If no account is transmitted with the PUT /consents method and that consent was given for some accounts with a previous call to this method, then it means that the customer is revoking all his accounts.

• If no account is consented, or if the customer has revoked all this consented accounts, the GET /accounts method allows to get all the accounts list but access to related data (balances, transactions) is NOT possible anymore.

• In order to get any new account, a PUT /consents with no data is necessary. 

➤ Example

See also STET specification V1.4.0.47 / Part III / section 5.3 / page 7 

➤ Acceptance tests

The purpose of these tests is to ensure that the API complies with the STET standard. They should be validated before any application deployment.