Envoyer une demande d'initiation de paiement unique en € !

➤ Contexte

Cet appel permet d'envoyer à la banque (ASPSP) d'un client une demande d'initiation de paiement venant débiter son compte. S’il s’agit d’une initiation de paiement initiée par un e-commerçant (pas par le client final), le paiement va créditer celui de l'usager du service de paiement (PSU) pour lequel le Prestataire de service de paiement (PISP) a été mandaté, à savoir le e-commerçant.

Dans un premier temps, seule l'initiation de paiement unique en euros est acceptée dans nos traitements.

A la soumission de la requête, et si toutes les données sont correctement formatées, une réponse (HTPP 201) vous sera retournée.

Cette réponse contiendra le ressourceId de l'initiation de paiement, ainsi que le mode d'authentification SCA Redirect (seul mode disponible), l'URL de consentement en fonction de la banque du payeur (urlconsent_approval_URL) et le non rejeu.

➤ Prérequis

Pour procéder à cette requête il est nécessaire de remplir les prérequis d’éligibilité pour le rôle TPP "PISP" (voir la rubrique "Eligibilité"), et d'avoir récupéré le jeton d'accès OAUTH2 (voir la rubrique "Vue d'ensemble" > "Récupérer un jeton").

➤ Requête POST

Le point d'entrée dépendra du code établissement.

Vous devez insérer la même valeur du paramètre <cdetab> que celle utilisée pour le jeton d'accès.

Pour rappel, la liste de nos établissements et les valeurs possibles des <cdetab> sont précisées dans la rubrique "Limitations".

Voici un extrait de cette liste :

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 un "endpoint" au format www.<cdetab>.live.api.89c3.com

Pour exemple, nous avons donc comme URL de production :

• POST https://www.13807.live.api.89c3.com/stet/psd2/v1/payment-requests  pour initier un paiement pour un client de la BPGO en production

• POST https://www.17515.live.api.89c3.com/stet/psd2/v1/payment-requests  pour initier un paiement pour un client de la CEIDF en production

La structure du body et les champs obligatoires sont décrits dans la norme STET.

Les informations suivantes doivent être valorisées dans la requête comme suit :

• La donnée serviceLevel doit être renseigné à SEPA

• La donnée currency doit être renseignée à EUR => les virements internationaux en devise ne sont pas disponibles

• La donnée requestedExecutionDate doit être égale ou supérieure à la date du jour

• Seuls les virements unitaires sont supportés sur cette version (pour les virements récurrents, il faut utiliser la version STET V1.4.2)

• Pour les Banques Populaires, la donnée requestedExecutionDate ne peut pas être un week-end ou un jour target 2 pour les SCT. Sinon, une erreur est générée et le paiement est rejeté. Cette limitation ne s'applique pas pour les SCT immédiats uniquement si requestedExecutionDate est le jour même de la demande ; dans ce cas, le paiement sera transformé en un SCT différé programmé pour le jour ouvré suivant.

• Pour les Banques Populaires, la donnée executionRule est facultative et ignorée si présente. L'ASPSP ne modifie pas la date d'exécution de sa propre initiative; celle positionnée par le TPP doit être une date acceptable pour la banque (cf. remarques sur donnée requestedExecutionDate).

• Pour les Banques Populaires, la donnée localInstrument ne doit pas être valorisée, seuls les SCT étant acceptés pour le moment => la fonctionnalité d'instant payment devrait être disponible en novembre 2021.

• Seuls les IBAN sont supportés pour les données "Iban", "debtorAccount" et "creditorAccount"
  • La présence de lettre minuscules dans les IBAN (et spécialement pour la donnée creditorAccount) est acceptée pour la prise en compte d’une demande d’initiation de paiement. Cependant, pour ce qui concerne les Banques Populaires, la Banque de Savoie et la Banque Palatine, bien que le parcours client va se dérouler normalement jusqu’à la validation du virement par le PSU avec authentification forte, le virement sera in fine refusé par le SI des Banques Populaires qui ne supporte pas les IBAN possédant des lettres en minuscules. Un message d’erreur sera affiché au PSU sur le dernier écran de son parcours indiquant que son virement ne sera pas exécuté.

• Si présente, la donnée debtor.privateId.identification donne l’identifiant client Banque à Distance saisi par le PSU et fourni au TPP, en vue de faire son authentification auprès de l’ASPSP ; cela évite par conséquent un écran côté IHM ASPSP.
  • Pour les Banques Populaires, la Banque Palatine et la Banque Palatine, il est nécessaire de forcer cette donnée en majuscules.

• Le BIC Creditor est aussi nécessaire (en sus de l’IBAN) lors de vos demandes pour les opérations PISP (y compris pour celles effectuées en zone SEPA, donc aussi par exemple pour des IBAN FR)

• La donnée "successfullReportUrl" est obligatoire pour le mode d'authentification REDIRECT mis en œuvre

• Si la donnée "unsuccessfullReportUrl" n'est pas renseignée, c'est la donnée valorisée au niveau de "successfullReportUrl" qui sera utilisée

• La donnée supplementaryData doit être alimentée avec la valeur "REDIRECT"

• La donnée scaHint est ignorée pour l'instant => les exemptions d'AF ne sont pas possibles

• Le format autorisé pour la donnée creationDateTime est le format ISO8601.
  • Les trois expressions régulières autorisées sont :
  • YYYY-MM-DDTHH:MM:SS.SSS+HH:MM
  • YYYY-MM-DDTHH:MM:SS.SSS+HHMM
  • YYYY-MM-DDTHH:MM:SS.SSS
  • Z en fin de format signifie que l'heure est en UTC
  • Exemples :
    • 2019-11-12T00:00:00.000+02:00
    • 2019-11-12T00:00:00.000+0200
    • 2019-11-12T00:00:00.000

Par défaut, il est demandé au PSU de s'authentifier fortement à deux reprises pour déclencher une demande de paiement. Il est possible de déclencher deux parcours fluides lorsque la requête contient des informations plus précises sur le compte débiteur :

• L'IBAN débiteur (debtorAccount) uniquement : déclenchement de l'identification du PSU avant une authentification forte unique en fin de parcours pour sceller le paiement
• L'IBAN débiteur (debtorAccount) et l'identifiant du PSU (privateId) : déclenchement d'une authentification forte unique en fin de parcours pour sceller le paiement

Le CUT-OFF correspond à l’heure limite à laquelle un établissement peut exécuter un virement. Cette heure limite prend en compte :

• Les délais de traitement interne
• Les CUTOFF des différents systèmes de compensation, eux-mêmes assujettis au CUT-OFF des différents systèmes de règlement (généralement TARGET2)

Dans le cas des SEPA CREDIT TRANSFER (SCT), l’exécution doit être effectuée au plus tard dans la date de règlement correspondant à la celle demandée par le donneur d’ordre. Il n’est pas permis de reporter cette date de règlement.

En conséquence, lorsque l’heure de CUT-OFF est dépassée, l’exécution est reportée à la date suivante possible. Les dates d’exécution et de règlement sont donc fonction de l’heure d’arrivée de la demande.

Pour les Banques Populaires,

• l’heure de cut-off pour demander un virement SCT à J avec une date de règlement à J est fixé à 11h00 heure locale française,
• l’heure limite pour demander l’exécution d’un virement SCT à J avec une date de règlement à J+1 est fixé à 17h00 heure locale française

Pour rappel, l’heure locale française :

• Egale à GMT +2 pendant l’été,
• Egale à GMT +1 pendant l’hiver

Pour les Caisses d'Epargne, Banque BCP, Crédit Coopératif et BTP Banque, l’heure de cut-off pour demander un virement SCT à J avec une date de règlement à J est fixé à 13h30 heure locale française.

Le champ categoryPurpose permet d’empêcher les virements non-marchands vers des bénéficiaires inconnus (non-enregistrés sur la banque en ligne du client) lorsque le moyen d'authentification n'est pas assez fort (hors Secur'pass) : ce champ est nécessaire pour savoir si le paiement est un paiement "à la volée" ou non.

Le champ ChargeBearer est obligatoire pour les paiements internationaux (i.e. en devise hors EUR) => les virements internationaux en devise ne sont pas disponibles.

Un contrôle additionnel est en place depuis le 7 décembre 2020 afin de rejeter la demande d’initiation de paiement :

• si le bénéficiaire est absent de la liste des bénéficiaires enregistrés par le client dans sa banque en ligne ;
• et si le champ categoryPurpose = "CASH" ;
• et si le moyen d'authentification forte utilisé n’est pas Secur'Pass.

Jusqu’à présent, pour les banques populaires, une demande d’initiation de paiement pour faire un SCT immédiat (virement pour le jour même) était rejeté les jours non ouvrés (samedi, dimanche, jours fériés, jour fermé au sens TARGET2).

A partir de fin octobre 2020, ces demandes ne seront plus rejetées (pour ce motif du moins) et seront transformé en SCT différé pour le jour ouvré suivant.

➤ Codes erreur