• Ne s'applique qu'aux comptes de paiements en euros actifs accessibles en ligne (cf. texte de la Directive PSD2), et aux opérations entre comptes n'appartenant pas au même PSU ID et même ASPSP

• 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 (SAUF pour les CE Ile de France et CE Auvergne Limousin : que pour les PART/EI)

• 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/{paymentRequestResourceId}/confirmation pour initier une demande  
  • GET /payment-requests/{paymentRequestResourceId} pour récupérer le statut d'une initiation de paiement
  • PUT /payment-requests/{paymentRequestResourceId} n'est supportée que pour annuler un virement unitaire (virement SCT différé ou permanent, non applicable pou run virement multiple)

              NB : Les méthodes suivantes ne sont PAS supportées : POST /payment-requests/{paymentRequestResourceId}/o-confirmation et GET /payment-requests/{paymentRequestResourceId}/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 DSP2 pour initier un virement SEPA vers un bénéficiaire externe

• Il est à noter qu'en adéquation avec la réglementation, l'ASPSP applique 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

Ne sont couverts par l'API que les segments clients suivants (qui sont les seuls gérés par BTP Banque) : 

• Client "entreprise" (personnes morales) ayant un accès direct à la banque en ligne "BTP NET" avec un abonnement autorisant les virements unitaires, et un compte commençant par 08. 

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 : 

• Accès aux comptes :                                 (certificat matériel) ou (Sécur'Pass) ou (lecteur CAP) ou (Mot de Passe + OTP SMS)

• Opération sensible / Dynamic linking (DL) : (certificat matériel) ou (Sécur'Pass) ou (lecteur CAP) ou (Mot de Passe + OTP SMS)

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

NB 2 : 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 3 : 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.btp-banque.fr aligné sur le nom de domaine de l'accès direct www.btp-banque.fr). 

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