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

NB : le TPP n'a pas la possibilité de fournir à l'ASPSP les données de sécurité personnalisées du client à des fins d'authentification, et donc, seuls les écrans de redirection et d'authentification forte (SCA) de l'ASPSP doivent être utilisés (l'encapsulage de ces écrans par le TPP est interdit au regard des articles PSD2 #97.5 et RTS #31)

• 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 la Banque Palatine (<=> 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

• Ne remonte que les cartes à débit différée actives et qui ont servi (présence de facturette CB sur le compte support de la carte) au moins une fois dans les deux derniers mois

Limitations liées aux segments de clientèle

• Le particulier (PART) est une personne physique catégorisée comme "majeur capable"

• 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) :

➤ 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) :

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.40978.live.api.89c3.com ou www.40978.live.api.palatine.fr aligné sur le nom de domaine de l'accès direct www.palatine.fr

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