➤ 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) ;
  • 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 ;

 

Limitations liées aux segments de clientèle

Sont couverts les segments suivants : 

  • Le particulier (PART) est une personne physique catégorisée comme « majeur capable » ;
  • Il 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 de personnalité 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 ;

 

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 au moyen d’authentification forte en fonction du segment de clientèle

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

NB : 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 réelles, une demande de GO Live via le portail est nécessaire après avoir testé votre app en Try-it et en Assemblage sandbox :

test to live FR

cf. textes DSP2/RTS Art. 30 (5).  Les prestataires de services de paiement gestionnaires de comptes mettent à disposition un dispositif d'essai, comprenant une assistance et permettant des tests de connexion et de fonctionnement, afin que les prestataires agréés de services d'initiation de paiement, de services d'information sur les comptes et de services de paiement qui émettent des instruments de paiement liés à une carte ou les prestataires de services de paiement qui ont demandé l'agrément nécessaire puissent tester les logiciels et applications qu'ils utilisent pour proposer un service de paiement aux utilisateurs..

Une seule app consommatrice peut être déclarée à ce jour par le TPP (même OID = client_Id) sachant qu'il y a possibilité de  gérer :

  • les modèles de partenariat en marque blanche et en tiers-utilisateur.
  • plusieurs certificats par app consommatrice / client_Id TPP et plusieurs URL de redirection.

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