Ce service obligatoire (via le "consentement mixte AISP" imposé) permet au TPP de transmettre à la banque (ASPSP) les comptes pour lesquels son détenteur (PSU) a consenti la consultation en détails d'un certain nombre d'informations (soldes et / ou des transactions et / ou identité et/ou découvert autorisé). 

➤ Prérequis

Il est nécessaire de remplir les prérequis d’éligibilité et d'avoir récupéré le jeton d'accès OAUTH2 (voir la rubrique "Vue d'ensemble" > "Récupérer votre jeton").

Le TPP peut récupérer la liste des comptes de paiements éligibles DSP2 du client après avoir appelé une première fois la requête GET /accounts : l'IBAN associé à chaque compte, c'est à dire "accountId": {"iban":"" }, y sera inclus.

Cependant, si le TPP connait déjà le ou les IBAN des comptes de paiements du client, il peut les transmettre directement à l'ASPSP via la méthode PUT /consents.

ATTENTION : tant que le TPP n'aura pas communiqué au teneur de compte (ASPSP) au moins un compte consenti avec la méthode PUT /consents, ou si aucun compte n'est consenti, la méthode GET /accounts ne restituera pas les informations demandées, mais uniquement la liste de tous les comptes éligibles DSP2 (principe du "consentement mixte AISP").  

➤ Requête

Requête "PUT /consents"

 Voir aussi la spécification de place STET 

Cet appel nous permettra d’enregistrer les comptes que notre client a consenti au TPP ayant le rôle « AISP ». Le client peut vous consentir 4 types d'accès :

• "balances" => accès aux soldes d’un ou plusieurs comptes : le solde est accessible via la méthode GET /balances pour les comptes consentis uniquement

• "transactions" => accès à l'historique des transactions d’un ou de plusieurs comptes : les transactions sont accessibles via la méthode GET /transactions pour les comptes consentis uniquement, ainsi que le détail si disponible (lien URI inclus)

• "psuIdentity" => accès à l’identité du client connecté (nom et prénom pour un client de type "particulier", ou la raison sociale pour une personne morale)
  

• "overdrafts" => accès au découvert client autorisé sur son compte

• "trustedBeneficiaries" : cette fonctionnalité n'est pas gérée (quelque soit la valeur de ce champs, elle n'est pas prise en compte)

• "owners " : cette fonctionnalité n'est pas gérée (quelque soit la valeur de ce champs, elle n'est pas prise en compte)

Il est possible d'appeler plusieurs fois la méthode PUT /consents si le client a modifié son consentement via le TPP : chaque nouvel appel de la méthode PUT /consents remplace les consentements précédents.

Par ailleurs, à la demande du client, le consentement pourra être modifié ultérieurement par type d'opération : par exemple, le consentement pour l'accès à l'historique des transactions peut être révoqué alors que le consentement pour le solde reste actif.

ATTENTION :

• Si vous ne transmettez aucun compte via la méthode PUT /consents, alors que des comptes avaient été consentis via le dernier appel à cette méthode, cela signifie que le client a révoqué tous les comptes consentis

• Si aucun compte n'est consenti ou si le client a révoqué tous les comptes consentis, la méthode GET /accounts vous permet de récupérer la liste de tous les comptes, mais l'accès aux données (par exemple solde et à l’historique des transactions) n'est pas/plus possible.

➤ Paramètres obligatoires ou facultatifs du body requis pour l'appel de ce service

• balances : tableau obligatoire (qui peut être vide, ou avec un/des Numéro de compte bancaire international IBAN) pour obtenir la liste des comptes accessibles pour la fonctionnalité "soldes"
  

• transactions : tableau obligatoire (qui peut être vide, ou avec un/des Numéro de compte bancaire international IBAN) pour obtenir la liste des comptes accessibles pour la fonctionnalité "transactions"

• overdrafts : tableau obligatoire (qui peut être vide, ou avec un/des Numéro de compte bancaire international IBAN) pour la fonctionnalité "découvert"

• psuIdentity : champs obligatoire, la valeur (true ou false) indiquant si l'accès à l'identité du client (prénom, nom) est autorisé pour l'AISP par le client

• trustedBeneficiaries : champs obligatoire, quelque soit la valeur de ce champs (true ou false), elle n'est pas prise en compte

• owners : champs obligatoire, quelque soit la valeur de ce champs (true ou false), elle n'est pas prise en compte

• PSU-IP-ADDRESS : paramètre facultatif à alimenter que si le client est connecté

➤ Résultat retourné

Status code "201 - Created" lors de l'enregistrement du consentement

Status code "204 - No Content" méthode non supportée 

Status code "403 - Forbidden" en cas d'échec de l'enregistrement

➤ Exemple

Un exemple de requête est fourni dans la rubrique "Comment tester l'API ?" > "Assemblage Sandbox".

Les jeux de données de tests sont décrits dans la rubrique "Comment tester l'API ?" > "Tester nos personas".

 Voir aussi la spécification de place STET 

➤ Tests d'acceptance

Ces cas de tests ont pour objectif de vous permettre d'effectuer un minimum de tests afin de prendre en main cette API et d'y accéder depuis l'application du TPP. 

Ils devront être validés avant tout déploiement applicatif en production.

Le scope OAuth2 = aisp sauf indication contraire.