Transmettre des comptes consentis

Ce service obligatoire (via le "consentement mixte AISP" imposé) vous permet de transmettre à la banque (ASPSP) les comptes pour lesquels son détenteur (PSU) vous a consenti à consulter en détail les soldes et / ou les transactions. 

 

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

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

Cependant, si vous connaissez déjà le ou les IBAN des comptes de paiements du client, vous pouvez nous les transmettre directement via la méthode PUT /consents.

 

ATTENTION : tant que vous n'aurez 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 courants (principe du "consentement mixte AISP").  



➤ Requête

Requête "PUT /consents"

book picto Voir aussi la spécification de place STET V1.4.2.17 / Part II / section 4.4 / page 15 

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

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

  • "transactions" => accès à l'historique des transactions d’un ou de plusieurs comptes : les transactions des comptes sont accessibles via la méthode GET /accounts/transactions pour les comptes consentis uniquement

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

  • "trustedBeneficiaries" => accès à la liste des bénéficiaires de confiance : cette fonctionnalité n'est pas gérée dans la banque en ligne (quelque soit la valeur de ce champs true ou false, elle n'est donc pas prise en compte)

 

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

Le consentement enregistré du client est vérifié à chaque requête passée pour les méthodes GET /accounts, GET /accounts/balances et GET /accounts/transactions.

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 les soldes 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 au solde et à l’historique des transactions n'est pas/plus possible
  • La résultante est que, pour récupérer des nouveaux comptes, il faut envoyer un PUT /consents à vide au préalable



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

  • balances : tableau obligatoire mais qui peut être vide : liste des comptes accessibles pour la fonctionnalité "soldes"
    ⇒ iban - obligatoire : Numéro de compte bancaire international (IBAN)
  • transactions : tableau obligatoire mais qui peut être vide : liste des comptes accessibles pour la fonctionnalité "transactions"
    ⇒ iban - obligatoire : Numéro de compte bancaire international (IBAN)
  • trustedBeneficiaries : obligatoire : valeur (true ou false) indiquant si l'accès à la liste des bénéficiaires de confiance est autorisé pour l'AISP par le client
  • psuIdentity : obligatoire : valeur (true ou false) indiquant si l'accès à l'identité du client (prénom, nom) est autorisé pour l'AISP par le client
  • Paramètre facultatif : PSU-IP-ADDRESS => à alimenter si le client est connecté



➤ Résultat retourné

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

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

book picto Voir aussi la spécification de place STET V1.4.0.47 / Part III / section 5.3 / page 7 



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

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

Le scope OAuth2 = aisp sauf indication contraire.

 

Description du testJeu de données et Résultat attendu
Enregistrement de données de consentement d'un client

Persona : LEA

Prérequis : scope OAuth2 = aisp

Résultat : message d'erreur HTTP 201 => OK, consentement enregistré
Passage d'une requête HTTP avec un jeton d'accès non autorisé pour la ressource (scope erroné)

Persona : LEA

Prérequis : scope OAuth2 <> aisp

Résultat : message d'erreur HTTP 403 => accès à la ressource refusé
Passage d'une requête HTTP POST

Persona : LEA

Prérequis : scope OAuth2 = aisp

Résultat : message d'erreur HTTP 405 => méthode non autorisée