• 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 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 en €uro 
  • Donc pas d'initiation de virement en devise
  • Des virements unitaires SEPA SCT de type immédiat, permanent ou différé, ou des SEPA Instant Payment (SCTInst)
  • Des virements multiples SEPA SCT de type immédiat 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 :
  • CASH, SALA et DVPM sont possibles pour un virement unitaire ;
  • CASH et SALA sont possibles pour un virement multiple.

• Les méthodes suivantes sont disponibles :
  • POST /payment-requests et POST /payment-requests/{paymentRequestResourceId}/confirmation pour initier un paiement pour un virement unitaire ou un virement multiple 
  • GET /payment-requests/{paymentRequestResourceId} pour récupérer le statut d'une initiation de paiement pour un virement unitaire ou un virement multiple
  • La méthode PUT /payment-requests/{paymentRequestResourceId} n'est supportée que pour annuler une initiation de paiement pour un virement unitaire (virement SCT différé ou permanent) ou un virement multiple (SCT différé).

• La méthode POST /payment-requests/{paymentRequestResourceId}/o-confirmation n'est plus supportée en v1.6.2

• La méthode GET /payment-requests/{paymentRequestResourceId}/transactions 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 sur 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

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 à 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 aux moyens d'authentification forte 

• 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.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.