➤ Limitations fonctionnelles

Limitations de cette API DSP2 

• Ne s'applique qu'aux comptes de paiements (le critère déterminant réside dans la faculté d’exécuter des opérations de paiement quotidiennes à partir d’un tel compte géré par le système d’information central "backend", source des informations remontées par les API), en euros et éligibles (compte de paiements actif - non bloqué ni sous séquestre-, et accessible en ligne, cf. texte de la Directive DSP2)

• N'utilise que le mode d’authentification par redirection (Authentification Forte du client demandée et gérée via la banque teneur de compte du client utilisateur du service de paiement)

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)

• N'implémente que le mode de consentement "mixte AISP" via la méthode PUT /consents qui est obligatoire :
  • par défaut, lorsqu'aucun consentement n'a été transmis, tous les comptes de paiements sont listés
  • le détail des soldes et transactions exécutées n'est accessible que pour les comptes de paiements dont le consentement a été transmis par le PSU via le TPP

• Ne fixe pas de limite d'accès (rate limit) lorsque c'est le PSU connecté qui interroge ses comptes de paiements (PSU-IP-ADDRESS fourni), sinon limité à 4 accès à l’initiative du TPP (cf. texte de la Directive DSP2) :

  • par jour calendaire (00h00 - 23h59:59:999)
  • par TPP OID
  • par ASPSP / point d'accès
  • par PSU ID
  • par IBAN
  • par méthode API AIS (/!\ méthode /transactions avec ou sans dateFrom / dateTo = considérée une seule et même méthode)

• 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 :
  • 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, soit un maximum de 62 jours pour les PART (pas de pagination gérée par l’API), et 90 jours pour les ENT (limitation à 500 comptes, sans pagination gérée par l’API)
  • Ne permet pas de récupérer la liste des bénéficiaires de confiance d'un client (cette notion n'existe pas pour les établissements listés ci-dessous)

• La donnée optionnelle "entryReference" ne s'applique qu'aux opérations des clients PART (voir le périmètre fonctionnel exact dans le cas d'usage "Obtenir les transactions")

NB : comme cette donnée est générée à la volée via API, la recherche par les paramètres "entryReferenceFrom" et/ou "entryReferenceto" n'est pas supportée

Limitations liées aux segments de clientèle 

Sont couverts par l'API les segments clients suivants :

• Client "particulier" (y compris compte joint et mineur rattaché) ayant un accès direct à la banque en ligne "COOP@ACCESS" et un compte commençant par 04
  

NB 1 : 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 le statut de "persone 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

NB 2 : est non compris à ce jour le tutuer de personnes protégées/sous tutelle

• Client "entreprise" et "association" ayant un accès direct à la banque en ligne "COOP@CCESS" et un compte commençant par 08

NB 3 : les catégories "entreprise" (ENT) et "association" (ASSOC) couvrent les personnes morales. 

Limitations liées au moyen d’authentification forte (pour l’accès banque en ligne et les API) en fonction du segment client

• PART : équipement avec Mot de Passe + OTP SMS et/ou lecteur CAP et/ou Sécur'Pass

• ENT ou ASSOC : équipement certificat TurboSign et/ou Mot de Passe + lecteur CAP et/ou certificat matériel TurboSign

NB : le moyen certificat ne s'applique pas si le client utilise son téléphone portable / mobile

➤ 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 de production, l'utilisation de l'API REGISTER est un prérequis (voir la fiche www.api.89c3.com/fr/component/bpceportal/products/522/usecases/523).

NB : La plage hebdomadaire du lundi matin de minuit à 06h00 est utilisée pour la maintenance des infrastructures des systèmes d'information (tous composants, y compris le système central/backend, les passerelles, etc...) et peut engendrer des requêtes API en erreur ou des indisponibilités le temps des interventions (de même pour des traitements bancaires programmés en début et fin de journée/mois/trimestre/année).

Le code établissement (voir ci-dessous) permettra d'adresser le bon backend via le "endpoint" www.<cdetab>.live.api.89c3.com (ou www.<cdetab>.live.api.credit-cooperatif.coop aligné sur le nom de domaine de l'accès direct www.credit-cooperatif.coop). Une fois choisi, ce point d'accès doit être conservé pour toutes les requêtes sous-jacentes.

(*) Cet ASPSP étant sur le même backend que les Caisses d'Epargne (CE), le format des données retournées via API sera identique. Vous pouvez donc utiliser les données CE en sandbox tel que décrit dans le cas d'usage "Comment tester l'API ?".