Limitations

 

➤ Limitations fonctionnelles

Limitations de cette API DSP2 en version 1.4.2

  • S'applique à la Banque de Savoie.
  • 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) ;
  • 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é
  • 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/{paymentRequestResourceId}/o-confirmation pour initier un paiement ;
    • GET /payment-requests/{paymentRequestResourceId} pour récupérer le statut d'une initiation de paiement ;
    • PUT /payment-requests/{paymentRequestResourceId} pour gérer l’annulation d’un virement SCT différé initié avec l’API PISP L’annulation d’un virement SCT permanent devrait être disponible en novembre 2021.
  • La méthode POST /payment-requests/{paymentRequestResourceId}/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.
  • Pas d'exemption d'authentification forte (donnée scaHint ignoré)

 

Limitations liées aux segments de clientèle

  • 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'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.
  • 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 que, en adéquation avec la réglementation, l'ASPSP (Banque de Savoie) peut avoir mis des garde-fous (surveillance de client ou de compte etc.) qui peuvent amener à rejeter une initiation de paiement. 

 

Limitations liées au moyen d’authentification forte en fonction du segment de clientèle

  • Client particulier (PART) : équipement avec SMS OTP et/ou Sécur'pass. Sécur’pass est déclenché en priorité le cas échéant.
  • Client professionnel (PRO) : équipement avec SMS OTP et/ou Sécur'pass. Sécur’pass est déclenché en priorité le cas échéant.
  • Client entreprise (ENT) : équipement avec SMS OTP.

➤ 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 réelles, une demande de GO Live via le portail est nécessaire après avoir testé votre application 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.

Si l’enregistrement du TPP a été réalisé au travers du processus de "GoLive" via notre portail 89C3 API.Si l’enregistrement du TPP a été réalisé au travers du processus de "GoLive" via notre portail 89C3 API.

Une seule app consommatrice peut être déclarée 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.

Ou si l’enregistrement du TPP a été réalisé via l’API register

Plusieurs app consommatrices peuvent être déclarées par le TPP pour lui ou son/ses agents. Pour chacune, plusieurs certificats par app consommatrice / client_Id TPP et plusieurs URL de redirection peuvent être gérés.

La plage hebdomadaire du lundi 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.10548.live.api.89c3.com ou www.10548.live.api.banque-de-savoie.fr aligné sur le nom de domaine de l'accès direct www.banque-de-savoie.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
10548 Banque de SAVoie BQSAV   Oui

Carte France BP 20190107