• S'applique à la Banque Palatine

• 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 (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 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 (ou 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 que, en adéquation avec la réglementation, l'ASPSP (Banque Palatine) 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 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.40978.live.api.89c3.com (ou www.40978.live.api.palatine.fr aligné sur le nom de domaine de l'accès direct www.palatine.fr). Une fois choisi, ce point d'accès doit être conservé pour toutes les requêtes sous-jacentes.