Limitations

 

➤ Limitations fonctionnelles

Limitations de cette API DSP2 en version 1.4.2

  • Ne s'applique qu'aux comptes de paiements en euros actifs et accessibles en ligne (cf. texte de la Directive DSP2) => seuls les comptes à vue seront restitués
  • N'utilise que le mode d’authentification REDIRECT (Authentification Forte du PSU demandée et gérée via la banque)
  • Implémente le mode de consentement mixte AISP, mais n'implémente pas le mode de consentement full AISP :
    • par défaut, lorsqu'aucun consentement n'a été transmis, tous les comptes à vue sont accessibles
    • mais le détail des soldes et transactions des comptes à vue ainsi que les encours carte et facturettes n'est accessible que pour les comptes à vue dont le consentement a été transmis
  • Limite à 4 accès batch par jour calendaire pour chacune des méthodes de cette API (cf. cas d'usage pour chacune des méthodes pour voir les détails), mais ne fixe pas de limite lorsque c'est le PSU connecté qui interroge ses comptes à vue
  • Ne permet pas de récupérer la liste des bénéficiaires de confiance d'un PSU : la notion de bénéficiaire de confiance n'existe pas pour les Banques Populaires (<=> un bénéficiaire enregistré et validé par une authentification forte et pour lequel il n'est plus demandé par la suite d'authentification forte pour valider un paiement).
  • Le mode "aisp extended_transaction_history" n'est pas supporté : la profondeur d'historique des transactions est à l'identique de celle de la banque en ligne internet fixe ;
  • Ne permet l'accès au compte que via l'IBAN du compte de paiement
  • Seules les méthodes GET /accounts, PUT /consents, GET /balances, GET /transactions et GET /end-user-identity sont disponibles.

Limitations liées aux segments de clientèle

  • Le particulier (PART) est une personne physique catégorisée comme "majeur capable". Le PART peut aussi avoir des activités dans le cadre d’une entreprise individuelle (EI) = une entreprise dirigée par une seule personne, et qui n'a pas de personnalité morale, bien qu'elle soit inscrite au répertoire des métiers ou au Registre du Commerce et des Sociétés (RCS). Exemples : artisan ou profession libérale. Dans ce cas, l’EI est considéré comme un PART.
  • Les catégories "professionnel" (PRO) et "entreprise" (ENT) couvrent les personnes morales.

Limitations liées aux types de comptes accessibles

  • Les comptes accessibles via l’API AISP sont ceux disponibles sur la banque à distance, à savoir :
    • majeur capable
    • compte joint Mr et Mme
    • compte joint Mr ou Mme
    • entrepreneur individuel
    • entreprise
    • mineur rattaché
    • mineur émancipé
  • Le compte suivant n’étant pas accessible sur la banque à distance, il ne l’est pas non plus via l’API AISP :
    • majeur sous tutelle 

Limitations liées au moyen d’authentification forte en fonction du segment de clientèle

  • Client particulier (PART) : équipement avec SMS OTP et/ou Sécur'pass. Sécur’pass est déclenché en priorité le cas échéant.
  • Client professionnel (PRO) : équipement avec SMS OTP et/ou Sécur'pass. Sécur’pass est déclenché en priorité le cas échéant.
  • Client entreprise (ENT) : équipement avec SMS OTP.

 

Le tableau ci-dessous résume les limitations par méthode pour cette API (les noms des champs sont donnés en italique) :

Récupération de la liste de comptes à vue et des cartes à débit différé adossées à ces comptes (méthode "GET /accounts")Récupération des soldes des comptes à vue et des encours des cartes à débit différé adossées à ces comptes (méthode "GET /accounts/balances")Récupération des transactions des comptes à vue et des facturettes des cartes à débit différé adossées à ces comptes (méthode GET /accounts/transactions)
  • En euros uniquement [currency]
  • IBAN ou PAN chiffré [iban]
  • Solde comptable [balanceType] "CLBD"
  • Solde en valeur [balanceType] "VALU"
  • Solde TP [balanceType] "OTHR"
  • IBAN ou PAN chiffré [iban]
  • Historique de 90 jours maximum
  • IBAN ou PAN chiffré [iban]

Pagination des résultats affichés :

Deux paramètres sont disponibles pour personnaliser la pagination des résultats affichés à l'écran :

  • le premier concerne le nombre de comptes / cartes par pages lors d'une requête de type GET /accounts. La valeur par défaut est fixée à 100.
  • le deuxième concerne le nombre de transactions par pages lors d'une requête de type GET /accounts/transactions. La valeur par défaut est fixée à 200.

 

➤ Accès aux données de production

Conformément à la réglementation, les modes de test Try-it et Assemblage n'utilisent que des données fictives. Ces données de tests sont décrites dans la rubrique "Comment tester l'API ?".

Pour accéder aux données réelles, après avoir testé votre app en Try-it et en Assemblage sandbox, vous devez vous enregistrer en tant que TPP consommateur de nos API, 

  • soit lors du processus de "GO Live" via notre portail 89c3 API (ancienne procédure) ;
  • soit via l’API register (procédure actuelle) :

test to live FR

cf. textes DSP2/RTS Art. 30 (5). Les prestataires de services de paiement gestionnaires de comptes mettent à disposition un dispositif d'essai, comprenant une assistance et permettant des tests de connexion et de fonctionnement, afin que les prestataires agréés de services d'initiation de paiement, de services d'information sur les comptes et de services de paiement qui émettent des instruments de paiement liés à une carte ou les prestataires de services de paiement qui ont demandé l'agrément nécessaire puissent tester les logiciels et applications qu'ils utilisent pour proposer un service de paiement aux utilisateurs.

 

Si l’enregistrement du TPP a été réalisé au travers du processus de "GO Live" via notre portail 89C3 API (ancienne procédure)

  • Une seule app consommatrice peut être déclarée par le TPP (même OID = client_Id) sachant qu'il y a possibilité de gérer :
    • les modèles de partenariat en marque blanche et en tiers-utilisateur;
    • plusieurs certificats par app consommatrice / client_Id TPP et plusieurs URL de redirection.

Ou si l’enregistrement du TPP a été réalisé via l’API register (procédure actuelle)

  • Plusieurs app consommatrices peuvent être déclarées par le TPP pour lui ou son/ses agents. Pour chacune, plusieurs certificats par app consommatrice / client_Id TPP et plusieurs URL de redirection peuvent être gérés.

 

La plage hebdomadaire du lundi matin de 2h à 6h est utilisée si besoin pour la maintenance des backends / des gateways et peut engendrer des requêtes KO le temps que les serveurs concernés aient tous été mis à jour pour l’établissement concerné.

 

Comme en mode test, le code établissement (voir ci-dessous) vous permettra d'adresser le bon référentiel client via le "endpoint" www.<codetab>.live.api.89c3.com ou www.<codetab>.live.api.banquepopulaire.fr aligné sur le nom de domaine de l'accès direct www.banquepopulaire.fr

Une fois choisi, ce point d'accès doit être conservé pour toutes les requêtes sous-jacentes.

Code établissementNom de l'établissementNom abrégéDisponible en Try-it et AssemblageDisponible en Production
10807 B.P Bourgogne Franche Comté BPBFC   Oui
16807 B.P AUvergne et Rhône-Alpes BPAURA   Oui
10207 B.P RIves de Paris + BICS BPRI   Oui
18707 B.P Val de France BPVF   Oui
13507 B.P du Nord BPN       Oui
16607 B.P Sud BPS   Oui
10907 B.P Aquitaine Centre Atlantique BPACA   Oui
10907 CMM Littoral du Sud OUest CMSOU   Oui
14707 B.P Alsace Lorraine Champagne BPALC   Oui
17807 B.P OCcitane BPOC   Oui
13807 B.P Grand Ouest BPGO Oui Oui
13807 CMM Grand Ouest CMMGO Oui Oui
14607 B.P MEDiterranée BPMED   Oui

 Carte France BP 20190107