• 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é (appel de la méthode o-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 unitaire en euro (pas d'initiation de virement en devise) :
  • virement SEPA SCT CORE de type immédiat ou différé ou permanent pour les segments de clients PART/EI 
  • virement SCT Instant Payment pour les segments de clients PART/EI/PRO/ENT 

• Le BIC Creditor n'est PAS obligatoire SAUF pour les opérations PIS effectuées hors zone SEPA (toujours en euro)

• Les méthodes suivantes sont disponibles :
  • POST /payment-requests et POST /payment-requests/{paymentRequestRessourceId}/o-confirmation pour initier un paiement
  • GET /payment-requests/{paymentRequestRessourceId} pour récupérer le statut d'une initiation de paiement 

         NB : Les méthodes suivantes ne sont pas supportées : 

POST /payment-requests/{paymentRequestRessourceId}/confirmation et PUT /payment-requests/{paymentRequestRessourceId} (annulation de virement SCT différé initié via API)

• L'annulation d'une demande de virement via API PIS peut être effectuée par le PSU via son accès direct (et non via API)

• Les demandes PIS de type "CASH" 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 executée préalablement (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 (ou 04 mns sur les écrans de redirection), c'est considéré comme une déconnexion sans redirection en retour vers le TPP

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

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 types de comptes accessibles

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

• Il est à noter qu'en adéquation avec la réglementation, l'ASPSP peut avoir mis en place des règles de gestion métiers (lutte contre la fraude, etc...) qui peuvent amener à rejeter l'exécution du virement liée à une initiation de paiement

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 Try-it et Assemblage 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, il est nécessaire d'utiliser notre API d'auto-enrôlement "API Register" (voir la fiche produit dédiée).

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 SI central, les passerelles, etc...) et peut engendrer des requêtes API en erreur ou des indisponibilités sur ce créneau horaire.

Comme en mode test, 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.<codetab>.live.api.89c3.com ou www.<codetab>.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.