Consommer l'API

La description des services proposés ci-après n’est que purement fonctionnelle. Les aspects techniques sont répertoriés dans les sections "Cas d’usage" qui sont plus détaillées.

Vous devez aussi être familier avec la terminologie DSP2 et les abrévations utilisées. Vous pouvez également utiliser la foire aux questions (FAQ), l'assistant virtuel ou le glossaire.



➤ Prérequis

En tant que TPP, vous devez être accrédité par l'autorité de contrôle prudentiel et de résolution (ACPR) pour le rôle d'initiateur de paiement ("PISP").

Pour accéder aux services de l’API d’initiation de paiement, vous devez récupérer un jeton d'accès OAUTH2 délivré par l'établissement bancaire du PSU en l’interrogeant avec vos credentials.

A ce titre, vous devez vous authentifier mutuellement avec le teneur de compte (ASPSP) par échange de certificats eIDAS QWAC.

Vous présenterez ensuite votre jeton d'accès OAUTH2 pour pouvoir consommer les services de l'API d'initiation de paiement.

 

➤ Initier un paiement

Il existe deux cas d'utilisation de l'API d'initiation de paiement :

1) Le PISP fait une demande de paiement pour le compte d'un commerçant : le client PSU achète des biens ou des services sur un site e-commerce (cf. haut du schéma ci-après).

Il existe un contrat entre le e-commerçant et le PISP.

Le e-commerçant transmet les caractéristiques du paiement demandées au PISP et redirige le client PSU vers le portail du PISP.

Le PISP interroge le client PSU pour connaître l’établissement bancaire à partir duquel il souhaite débiter son compte. Puis il prépare la demande de paiement et l'envoie à l'établissement bancaire du client.

Le bénéficiaire (= le e-commerçant) est indiqué dans le paiement.

 

2) Le PISP fait une demande de virement pour le compte du client PSU titulaire du compte. Le PSU fournit au PISP les informations nécessaires au transfert (cf. bas du schéma ci-après).

Le PISP interroge le client PSU afin de connaître l’établissement bancaire à partir duquel il souhaite débiter son compte. Puis il prépare la demande de paiement et l'envoie à l'établissement bancaire du PSU.

 épingle voir les spécifications STET V1.4.2 / Part I / section 3.4.5.4 page 44 (nb : le schéma est repris de la v1.5 / Part I / section 3.5.5.5 page 47 avec utilisation de la méthode "o-confirmation")

Redirect PISP renforcé

 

Vous transmettez la requête d'initiation de paiement via la méthode POST /payment-requests (cf. rubrique "Cas d'usage" > "Initier un paiement").

La méthode d'authentification supportée par l'établissement bancaire est le mode REDIRECT renforcé :

1) Le PSU est redirigé vers un écran d'identification proposé par son établissement bancaire et dans lequel il saisira son identifiant de banque à distance.

2) Le PSU est redirigé vers un premier écran d'authentification forte proposé par son établissement bancaire pour valider son identité.

La cinématique de cette étape dépend de la méthode d'authentification forte mise à disposition du PSU par l'établissement bancaire (SMS OTP, secur'pass, etc.).

Elle dépend aussi de l'équipement du PSU sur lequel tourne l'application du PISP utilisée par le PSU (PC ou mobile/tablette).

3) Le PSU est redirigé vers un écran de sélection de son compte à débiter proposé par son établissement bancaire.

4) Le PSU sélectionne et valide le compte à débiter.

5) Le PSU est redirigé vers un second écran d'authentification forte proposé par son établissement pour valider son paiement.

La cinématique de cette étape dépend de la méthode d'authentification forte mise à disposition du PSU par l'établissement bancaire (SMS OTP, secur'pass, etc.).

Elle dépend aussi de l'équipement bancaire du PSU sur lequel tourne l'application du PSU (PC ou mobile/tablette).

6) Le PSU est redirigé vers un écran de confirmation de l'opération proposé par son établissement bancaire.

7) Le PSU est redirigé vers l'application du PISP.

8) Vous transmettez la requête de confirmation de l'initiation du paiement via la méthode POST /payment-requests/{paymentRequestResourceId}/o-confirmation (cf. rubrique "Cas d'usage" > "Confirmer une initiation de paiement"), ce qui déclenche la prise en compte du paiement par l'établissement bancaire.

 

Si le PISP fournit l'IBAN du PSU à débiter dans sa requête, le parcours client est simplifié (« parcours PISP fluide ») :

1) Le PSU est redirigé vers un écran de confirmation du virement dans lequel seul le compte correspondant à l’IBAN du PSU est proposé au PSU.

3) Le PSU valide l'opération.

4) Le PSU est redirigé vers un écran d'identification et d'authentification forte proposé par son établissement pour valider son paiement.

La cinématique de cette étape dépend de la méthode d'authentification forte mise à disposition du PSU par l'établissement bancaire (SMS OTP, secur'pass, etc.).

Elle dépend aussi de l'équipement bancaire du PSU sur lequel tourne l'application du PSU (PC ou mobile/tablette).

5) Le PSU est redirigé vers un écran de confirmation de l'opération proposé par son établissement bancaire.

6) Le PSU est redirigé vers l'application du PISP.

7) Vous transmettez la requête de confirmation de l'initiation du paiement via la méthode POST /payment-requests/{paymentRequestResourceId}/o-confirmation (cf. rubrique "Cas d'usage" > "Confirmer une initiation de paiement"), ce qui déclenche la prise en compte du paiement par l'établissement bancaire.

   

Le PISP fournit lors de sa demande d'initiation une ou deux URL call back :

  • La première sera appelée par l'établissement bancaire dans le cas où la demande d'initiation est traitée et si le PSU a donné son consentement pour le paiement.
  • La seconde URL call back sera utilisée par l'établissement bancaire en cas de refus du consentement. Cette seconde URL est facultative : la première URL de call back sera utilisée si la seconde n'est pas renseignée.

 

Le PISP peut renseigner un indicateur lui permettant d'indiquer qu'il considère la demande de paiement comme étant un cas d'exemption de SCA. La décision finale d'appliquer ou non une SCA reste à l'ASPSP : à ce jour aucune exemption n’est acceptée parmi les cas de dérogations à l'obligation d'authentification forte du PSU, si les exigences générales en matière d'authentification sont remplies, telles que décrits dans l'article 2 des RTS de la DSP2.

  

 

Récupérer le statut d'une initiation du paiement

Vous récupérez le statut d'une initiation de paiement via la méthode GET /payment-requests/{paymentRequestResourceId} (cf. rubrique "Cas d'usage" > "Récupérer le statut d'une initiation de paiement").

Cet appel vous permet de récupérer l'ensemble des données de l'initiation de paiement enrichies du ressourceId et des statuts de l'initiation et du paiement qu'elle contient.

Les données sont accessibles pendant 35 jours.

 

Annuler une initiation de Paiement

Pour un virement SCT différé qui n'a pas encore été exécuté ou pour un virement SCT permanent dont la dernière échéance n’a pas été atteinte, vous annulez une initiation de paiement via la méthode PUT /payment-requests/{paymentRequestResourceId} (cf. rubrique "Cas d'usage" > "Annuler une initiation de paiement")

La méthode d'authentification supportée par l'établissement bancaire est le mode REDIRECT :

1) Le PSU est redirigé vers un écran d'identification proposé par son établissement bancaire et dans lequel il saisira son identifiant de banque à distance.

2) Le PSU est redirigé vers un écran d'authentification forte proposé par son établissement bancaire pour valider son identité.

3) Le PSU est redirigé vers un écran récapitulatif de l'opération en cours d'annulation proposé par son établissement bancaire.

4) Le PSU valide l’annulation du virement.

5) Le PSU est redirigé vers un écran de confirmation de l'opération proposé par son établissement bancaire.

6) Le PSU est redirigé vers l'application du TPP PISP. 

Le PISP fournit lors de sa demande d'annulation une ou deux URL de call back :

La première sera appelée par l'établissement bancaire dans le cas où la demande d'annulation est traitée et si le PSU a donné son consentement pour cette annulation d'opération.

La seconde URL sera utilisée par l'établissement bancaire en cas de refus du consentement ou de problème. Cette seconde URL est facultative : la première URL call back sera utilisée si la seconde n'est pas renseignée.

 

Confirmer une initiation de paiement

Vous confirmez une initiation de paiement via la méthode POST /payment-requests/{paymentRequestResourceId}/o-confirmation, approche REDIRECT renforcé (voir la rubrique "Cas d'usage" >  "Confirmer une initiation de paiement").

Par contre, le service de confirmation d’une annulation de demande de paiement ne sera pas supporté. L’annulation sera effective dès l’acceptation de la demande.