Limitations

 

➤ Limitations fonctionnelles

Limitations de cette API DSP2 en version 1.4.2

  • S'applique à toutes les Banques Populaires
  • Ne s'applique qu'aux comptes de paiements en euros actifs et accessibles en ligne (cf. texte de la Directive PSD2)
  • 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 €uro (SCT) 
    • Donc pas d'initiation de virement en devise
    • Uniquement des virement SEPA SCT de type immédiat, permanent ou différé, ou des SEPA Instant Payment (SCTInst)
  • Le champ chargeBearer est obligatoire pour la méthode POST /payment-requests et doit valoir SLEV, pour les paiements internationaux (i.e. en devise hors EUR) => les virements internationaux en devise ne sont pas disponibles
  • Le champ categoryPurpose est obligatoire pour la méthode POST /payment-requests
  • 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 
    • La méthode PUT /payment-requests/{paymentRequestRessourceId} n'est supportée que pour annuler un virement SCT différé ou permanent 
  • La méthode POST /payment-requests/{paymentRequestRessourceId}/confirmation n'est pas supportée
  • Identifiant de banque à distance du client de la banque pris en compte (via la donnée debtor/privateId/identification ) pour déclencher un parcours PISP fluide (une seule authentification forte) si le debtorAccount est aussi renseigné dans la requête
  • Un virement initié via l'API d'initiation de paiement, ne peut être annulé par le PSU via son accès direct
  • Si aucune action de l'utilisateur n'est effectuée au bout de 30 mns (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

  • Le particulier (PART) est une personne physique catégorisée comme "majeur capable"
  • Les catégories "professionnel" (PRO) et "entreprise" (ENT) couvrent les personnes morales 

 

Limitations liées aux types de comptes accessibles

  • Les comptes accessibles via l’API PISP pour choisir le compte à débiter sont ceux disponibles sur la banque à distance 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 au moyen d’authentification forte en fonction du segment de clientèle

  • Client particulier (PART) : équipement avec Mot de passe + SMS OTP et/ou Sécur'pass (déclenché en priorité le cas échéant)
  • Client professionnel (PRO) et entreprise (ENT) : équipement Certificat et/ou Sécur'Pass et/ou lecteur CAP et/ou Mot de passe + OTP SMS

 NB : Il n'y a pas d'exemption d'authentification forte (donnée scaHint ignorée)

 

 

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

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 matin de 2h à 6h est utilisée si besoin pour la maintenance des backends / des gateways et peut engendrer des requêtes KO le temps que les serveurs concernés aient tous été mis à jour pour l’établissement concerné.

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.banquepopulaire.fr aligné sur le nom de domaine de l'accès direct www.banquepopulaire.fr.

Une fois choisi, ce point d'accès doit être conservé pour toutes les requêtes sous-jacentes.

Code établissementNom de l'établissementNom abrégéDisponible en Try-it et AssemblageDisponible en Production
10807 B.P Bourgogne Franche Comté BPBFC   Oui
16807 B.P AUvergne et Rhône-Alpes BPAURA   Oui
10207 B.P RIves de Paris + BICS BPRI   Oui
18707 B.P Val de France BPVF   Oui
13507 B.P du Nord BPN       Oui
16607 B.P Sud BPS   Oui
10907 B.P Aquitaine Centre Atlantique BPACA   Oui
10907 CMM Littoral du Sud OUest CMSOU   Oui
14707 B.P Alsace Lorraine Champagne BPALC   Oui
17807 B.P OCcitane BPOC   Oui
13807 B.P Grand Ouest BPGO Oui Oui
13807 CMM Grand Ouest CMMGO Oui Oui
14607 B.P MEDiterranée BPMED   Oui

Carte France BP 20190107