• Ne s'applique qu'aux comptes de paiements en euros actifs accessibles en ligne (cf. texte de la Directive PSD2), et aux virements externes entre comptes

• N'utilise que le mode d’authentification REDIRECT renforcé avec confirmation (appel de la méthode confirmation pour que le TPP confirme le paiement après Authentification Forte du PSU demandée et gérée via la banque : l'ASPSP transmet un code d'authorisation OAUTH2 au TPP qui doit le renvoyer à l'ASPSP pour confirmer le 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)

• Ne traite que les demandes d'initiation de paiement en euro (PAS d'initiation de virement en devise)
  • SCT Core unitaire de type immédiat ou différé ou permanent pour les segments de clients PART/EI/PRO/ENT
  • SCT Core multiple de type immédiat (PAS de multi-dates) pour les segments de clients PRO/ENT d'un compte débiteur vers N créditeurs résultant en N opérations avec différents montants possibles, et que pour les types de categoryPurpose = "CASH" et "SALA"
  • SCT INST pour les segments de clients PART/EI/PRO/ENT 
    

• Le BIC Creditor n'est pas nécessaire SAUF pour les opérations PIS hors zone SEPA (toujours en euro)

• Les méthodes suivantes sont disponibles :
  •  POST /payment-requests et POST /payment-requests/{paymentRequestRessourceId}/confirmation pour initier une demande  
  • GET /payment-requests/{paymentRequestRessourceId} pour récupérer le statut d'une initiation de paiement
  • PUT /payment-requests/{paymentRequestRessourceId} n'est supportée que pour annuler un virement unitaire (virement SCT différé ou permanent, non applicable pour un virement multiple)

              NB : Les méthodes suivantes ne sont PAS supportées : POST /payment-requests/{paymentRequestRessourceId}/o-confirmation et GET /payment-requests/{paymentRequestRessourceId}/transactions

• L'annulation d'une demande de virement unitaire (hors SCT Inst et virement multiple) via API PIS peut être effectuée : 
  • par le PSU via son accès direct avant une heure limite
  • par le TPP via API avant une heure limite

• Les demandes PIS de type "CASH" et "SALA" seront rejetés si le PSU n'utilise pas un moyen d'authentification forte ayant un niveau suffisemment sécuritaire (Secur'Pass ou le certificat sur clé physique pour les PRO & ENT), et si l'IBAN bénéficiaire n'est pas enregistré au préalable sur son accès direct 

• Différentes demandes PIS ayant les mêmes caractéristiques qu'une préalablement executée (même jour, même IBAN debiteur et créditeur, même montant, etc...) sont rejetées (fonctionnement identique à la banque en ligne)

• Si aucune action de l'utilisateur n'est effectuée au bout de 30 mns (04 mns sur les écrans de redirection), c'est considéré comme une déconnexion sans redirection en retour vers le TPP

• Si le PSU a plusieurs IBAN liés à un même abonnement, le nombre maximum de comptes de paiements éligibles DSP2 affichés lors du parcours classique est limité à 10 lignes 

• La longueur du champs creditor.name est limitée à 32 caractères

Limitations liées aux types de comptes accessibles

• Les comptes accessibles via l’API PISP sont ceux disponibles sur la banque à distance éligibles DPS2 pour initier un virement SEPA vers un bénéficiaire externe

• Il est à noter qu'en adéquation avec la réglementation, l'ASPSP peut appliquer des processus métiers (lutte anti-fraude, etc...) qui peuvent amener à rejeter l'exécution d'une initiation de paiement 

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 abonnement à la banque en ligne "Coop@ccess" 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 tuteur de personne protégée/sous tutelle ou curatelle utilisant la solution Web Protexion 

• Client "gros professionnel", "entreprise" et "association" ayant un abonnement à la banque en ligne "Coop@ccess" et un compte commençant par 08 autorisant les virements unitaires

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

Limitations liées aux moyens d’authentification forte

Il est de la responsabilité de l'ASPSP d'équiper ses clients avec un ou des moyens d'authentification forte : 

• PART :       Accès aux comptes PART et Opération sensible / Dynamic linking (DL) :                                  (Sécur'Pass) ou (lecteur CAP) ou (Mot de Passe + OTP SMS)

• PRO/ENT : Accès aux comptes PART et Opération sensible / Dynamic linking (DL) : (certificat matériel) ou (Sécur'Pass) ou (lecteur CAP) ou (Mot de Passe + OTP SMS)

      NB 4 : il n'y a pas d'exemption de la seconde authentification forte AF/SCA dynamic linking (donnée scaHint ignorée)

NB 5 : il y aura un rejet des virements avec categoryPurpose = « CASH » ou « SALA » lorsque l’AF/SCA DL ne se fait pas avec le moyen principal et que l'IBAN bénéficiaire n’est pas enregistré par le PSU sur sa banque en ligne

NB 6 : le certificat matériel n'est pas proposé aux client sur mobile/smartphone 

➤ Accès aux données de production

Conformément à la réglementation, les modes de test d'assemblage (sandbox) n'utilisent que des données fictives qui sont décrites dans le cas d'usage "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).

Le code établissement (voir la liste des établissements bancaires accessibles ci-dessous) vous permettra d'adresser le bon référentiel client 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.

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

 (*) Cet ASPSP étant sur le même système d'information 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 ?".