➤ Limitations fonctionnelles

 Limitations de cette version de l'API  

  • Ne s'applique qu'aux comptes de dépôt applicables au segment particulier et professionnel (= entrepreneur individuel), en euros, actifs et accessibles 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)

  • Ne traite que les demandes d'initiation de paiement unitaire en euro (SCT CORE immédiat différé, et Instant Payment pour les PART), pas de remise de virement avec destinataires multiples et/ou montants, ni de paiement récurrent, ni de paiements internationaux
  • en sandox, seules 2 méthodes sont disponibles au 13 mars 2019 en environnement sandbox (GET, POST) sans annulation possible de l’opération via les API DSP2
  • en production :
    • Seules les méthodes POST /payment-requests et GET /payment-requests/{paymentRequestResourceId} sont disponibles, ainsi que la méthode PUT /payment-requests/{paymentRequestResourceId} pour gérer l’annulation d’un virement SCT différé initié avec l’API PISP
    • La méthode POST /payment-requests/{paymentRequestResourceId}/confirmation n’est pas supportée
  • Pas d'exemption de deuxième authentification forte (donnée scaHint ignoré)
  • Le champ chargeBearer est obligatoire pour la méthode POST /payment-requests(ainsi que pour les suivantes) et doit être valorisé à "SLEV"
  • Le champ categoryPurpose est obligatoire pour la méthode POST /payment-requests (ainsi que pour les suivantes)
  • Le champ creditorAccount est obligatoire pour la méthode POST /payment-requests (ainsi que pour les suivantes)
  • Le champ successfulReportUrl est obligatoire pour la méthode POST /payment-requests (ainsi que pour les suivantes)
  • L'annulation d'une opération peut aussi s'effectuer par le PSU sur l'accès direct
  • le BIC Creditor est nécessaire pour les opérations PIS hors zone SEPA
  • Des demandes PIS successives ayant les mêmes caractéristiques (montant, PSU, IBAN débiteur et créditeur, etc..) seront rejetées
  • Si aucune action de l'utilisateur n'est effectuée au bout de 30 mns (ou 04 minutes sur les écrans de redirection), c'est considéré comme une déconnexion sans redirection en retour vers le TPP

 

Limitations liées aux segments de clientèle

Est couvert le segment suivant : 

  • 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'est pas une personne morale bien qu'elle soit inscrite au répertoire des métiers ou au Registre du Commerce et des Sociétés (exemples : artisan ou profession libérale. Dans ce cas, l’EI est considéré comme un PART avec un abonnement dédié PRO). 

 

Limitations liées aux types de comptes accessibles

  • Les comptes accessibles via l’API PISP pour choisir le compte à débiter sont ceux éligibles à la DSP2 (le critère déterminant réside dans la faculté d’exécuter des opérations de paiement quotidiennes à partir d’un tel compte) à toutes fins d'initier un virement SEPA SCT ou instantané vers un bénéficiaire
  • Il est à noter qu'en adéquation avec la réglementation, l'ASPSP peut avoir mis des règles de gestion métiers (surveillance du découvert du compte, bénéficiaire externe enregistré ou non, etc ...) qui peuvent amener au rejet d'une initiation de paiement

 

Limitations liées aux moyens d’authentification forte

  • Client particulier (PART) : équipement avec Mot de Passe + SMS OTP   et     Sécur'Pass
  • Client professionnel (PRO/EI) :   Mot de Passe + SMS OTP   et/ou   lecteur CAP

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

NB 2 : Il y aura un rejet des virements avec categoryPurpose = « CASH » lorsque l’AF/SCA ne se fait pas avec le moyen Sécur’Pass et que l'IBAN bénéficiaire n’est pas enregistré par le PSU sur sa banque en ligne

 

 

➤ 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 les cas d'usage "Comment Tester l'API ?" et "Testez nos persona".

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 dimanche minuit au lundi matin à 06h00 est utilisée pour de la maintenance programmée d'infrastructures y compris celles des backends, et peut engendrer des requêtes en erreur le temps de ces interventions. 

Comme en mode test, le code établissement (voir 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.banquebcp.fr aligné sur le nom de domaine de l'accès direct www.banquebcp.fr). Une fois choisi, ce point d'accès doit être conservé pour toutes les requêtes sous-jacentes.

Codetab

Nom de l'établissement

 Nom abrégé 

12579

Banque BCP

BBCP