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.

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 resourceId 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 des paramètres <cdetab> et <banque> que celle utilisée pour le jeton d'accès.

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

Voici un extrait de cette liste :

Comme en mode test, le bon référentiel client est adressable via un "endpoint" au format www.<cdetab>.live.api.89c3.com ou www.<cdetab>.live.api.<banque>.fr

Pour exemple, nous avons donc comme URL de production :

• POST https://www.13807.live.api.89c3.com/stet/psd2/v1.4.2/payment-requests ou https://www.13807.live.api.banquepopulaire.fr/stet/psd2/v1.4.2/payment-requests pour initier un paiement pour un client de la BPGO 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

• La donnée numberOfTransactions doit être valorisée à "1" (puisque seules les initiations de paiement de virements unitaires sont supportées)

• La donnée remittanceInformation doit intégrer la balise "unstructured" soit par exemple "remittanceInformation" : { "unstructured" : [ "test " ] }.

• 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 virements SCT permanents, la première échéance ne peut être positionnée :
  • 30 jours et plus après la date du jour ;
  • Le jour même.

• La donnée executionRule est facultative et ignorée si présente pour les SCT immédiats et différés. Pour les virements SCT permanents, si elle est alimentée, elle ne peut être valorisée qu’avec la valeur « FWNG » (report au jour suivant). 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).

• La donnée frequency ne doit être alimentée que pour les virements SCT permanents, elle est obligatoire dans ce cas. Elle n’accepte que les valeurs MNTH (Monthly), QUTR (Quaterly) et YEAR (Annual). La donnée endDate (date de dernière échéance) ne doit être alimentée que pour les virements SCT permanents :
  • Si elle est renseignée, elle doit correspondre à une échéance valide et dans le futur :
    
    • requestedExecutionDate + n mois si frequency = MNTH;
    • requestedExecutionDate + n trimestres si frequency = QUTR;
    • requestedExecutionDate + n années si frequency = YEAR;
  • Si non renseignée, elle doit être calculée :
    •  requestedExecutionDate avec l'année qui vaut 2099

• La donnée localInstrument est à alimenter avec la valeur « INST » pour déclencher un SEPA Instant Payment (SCT Inst).
  • Ce type de virement occasionne des frais facturés au client en fonction des conditions tarifaires en vigueur applicables pour son segment de clientèle (IP PART ou IP B2B);
  • La banque du bénéficiaire doit être atteignable en IP;
  • Pour les clients professionnels et entreprises, les comptes émetteurs et les pays des bénéficiaires éligibles pour ce type de virement sont définis sur le contrat de flux IP B2B.

• La donnée localInstrument ne doit pas être présente pour les SCT immédiats, différés ou permanents.

• Seuls les IBAN complets 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.

• La donnée "successfulReportUrl" est obligatoire pour le mode d'authentification REDIRECT mis en œuvre et doit contenir :
  • la redirect URL
  • ainsi que le pkce : code_challenge = BASE64URL-ENCODE(SHA256(ASCII(code_verifier))) + code_challenge_method = S256
  • et le séparateur "&" ( /!\ pas de "?")

• Si la donnée "unsuccessfulReportUrl" est renseignée, elle peut contenir le séparateur "&" (pas de "?" ).

• Si la donnée "unsuccessfulReportUrl" 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'authentification forte 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.

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

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.

La banque du bénéficiaire doit être atteignable en Instant Payment.

Pour les Banques Populaires, un client qui s’identifie avec son identifiant ENTREPRISE doit avoir souscrit l’offre IP B2B pour émettre un SEPA Instant Payment. Par ailleurs, la liste des pays atteignables en IP est définie sur le contrat de flux IP B2B et les comptes éligibles au débit figurent doivent aussi être définis sur ce même contrat de flux.

Les SEPA Instant Payment ne sont pas reclassés en SCT immédiat lorsque l’une au moins de ces conditions n’est pas réunie => l’initiation de paiement est rejetée.

➤ Codes erreur