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

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 virements SEPA SCT de type immédiat, permanent ou différé, ou SEPA instant Payment (SCT Inst)

• 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 PUT /payment-requests/{paymentRequestRessourceId} 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 (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 (accès aux comptes et dynamic linking)

• Client particulier (PART) :                                  [Sécur'Pass]                [certificat matériel]                [lecteur CAP]               [Mot de Passe + OTP SMS]

• Client professionnel (PRO) et entreprise (ENT) :  [Sécur'Pass]                [certificat matériel]                [lecteur CAP]               [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.