Forward Customer's Consent

➤ 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, this GET /accounts method will not return the information requested but only the list of all current accounts included new ones (principle of "AISP mixed consent").

 

➤ Request 

Method "PUT /consents"

épingle See also STET specification 

 

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 and details (if available)

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

  • overdrafts : access to PSU accounts overdraft

Note : the following methods are NOT supported 

  • GET /trustedBeneficiaries : whatever value is used (True/False), it won't be taken into account
  • GET /owners whatever value is used, it won't be taken into account

The AISP forwards details of PSU consent to the ASPSP through this call.

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 accounts is transmitted with PUT /consents method, and if a consent was given previously for some accounts using this method, then it means that the customer is revoking all his accounts
  • If no accounts is granted, or if the customer has revoked all this consented accounts, the GET /accounts method allows to get all the accounts list (included new ones) but access to related data (balances, transactions) is NOT anymore possible
  • In order to get any new account, a PUT /consents with no data is necessary

 

➤ Example

You can find an example of this request in the section "Test our API" and then "Use our sandbox". The test data sets are described in the section "Test our API" and then "Test with persona". 

épingleSee also STET specification

 

 

➤ 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.

Test description Nature of the test Data set
 Add / upate the consent of a customer

=> HTTP code 201 is returned

Mandatory

Persona : 

LEA

 

IBANs :

FRxxx

FRxxx

 

Result : HTTP code 201 is returned

HTTP request with an access token which is not authorized to access to this resource (incorrect scope)

=> Access to the resource is not allowed (HTTP code 403)

Mandatory

Persona : 

LEA

 

Result : HTTP code 403 is returned

 

HTTP request using POST method

=>HTTP code 405 is returned

Mandatory

Persona : 

LEA

Result : HTTP code 403 is returned