Envoyer une demande d'initiation de paiement 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 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".

Pour exemple, nous avons donc comme URL pour initier en production un paiement pour un client de la BTP banque :

• POST https://www.30258.live.api.89c3.com/stet/psd2/v1.4.2/payment-requests 

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ée à SEPA

• La donnée amount doit être renseignée avec une valeur conforme aux montants min/max tels qu'appliqués sur la banque en ligne et qui peuvent être différents par ASPSP et/ou par type d'opération demandée (SCT CORE ou INST) et/ou par segment client

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

• Seuls les IBAN sont supportés pour les données Iban, debtorAccount et creditorAccount

• La donnée numberOfTransactions doit être valorisée à "1" (puisque seuls les initiations de paiement de virements unitaires sont supportés y compris pour chaque occurence des virements récurrents)

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

• La donnée successfullReportUrl 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 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'authentification forte ne sont pas possibles

• La donnée state est obligatoire pour le mode d'authentification REDIRECT mis en œuvre : elle est propagée durant tout le parcours PISP

• Le champ endToEndId ne doit pas être vide

• Le champ requestedExecutionDate doit avoir une date supérieure à la date de demande d’initiation de paiement creationDateTime 

• Le champ creationDateTime ne doit pas être vide, et rempli comme le précédent avec une des trois expressions régulières autorisées au format ISO8601 : 

                   YYYY-MM-DDTHH:MM:SS.SSS+HH:MM

                  YYYY-MM-DDTHH:MM:SS.SSS+HHMM

                  YYYY-MM-DDTHH:MM:SS.SSS

                NB : 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

Il est possible de déclencher un parcours fluide (avec deux variations) lorsque la requête contient des informations plus précises sur le débiteur :

• Si seul l'IBAN débiteur (debtorAccount) est fourni : déclenchement de l'identification du PSU avant une authentification forte unique en fin de parcours pour sceller le paiement

• Si l'IBAN débiteur (debtorAccount) et l'identifiant du PSU (privateId) sont fournis : 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 CUT-OFF des différents systèmes de compensation interbancaires, 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 à celle demandée par le donneur d’ordre. Il n’est pas permis de reporter cette date de règlement sauf lorsque l'heure de CUT-OFF est dépassée, l’exécution étant reportée à la date suivante possible (non fériée). Les dates d’exécution et de règlement sont donc fonction de l’heure d’arrivée de la demande d'initiation de paiement.

Pour cet ASPSP, le CUT-OFF pour demander un virement SCT à J avec une date de règlement à J est fixé à 13h30 heure locale française.

Pour rappel, l’heure locale française est égale à :

• GMT+2 pendant l’été
• GMT+1 pendant l’hiver

La date d'exécution (donnée requestedExecutionDate) d'un virement différé (ou de la première échéance d'un virement permanent) doit être positionnée au-delà de J + 72 heures, sinon la demande sera rejetée. 

Pour le SCT permanent, les fréquences (donnée frequency) possibles sont : 

• hebdomadaire
• bi-mensuelle
• mensuelle
• trimestrielle
• semestrielle
• annuelle

La date de dernière échéance (donnée endDate) doit aussi être renseignée et doit correspondre à une échéance valide dans le futur.

Le champ chargeBearer est obligatoire pour la méthode POST /payment-requests, et il doit avoir la valeur "SLEV".

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 niveau du moyen d'authentification utilisé par le client n'est pas assez élévé pour effectuer cette opération (hors Secur'pass): ce champ est nécessaire pour savoir si le paiement est un paiement "à la volée" ou non, et est obligatoire pour la méthode POST /payment-requests.

Il doit avoir la valeur "CASH" (opération de compte à compte) ou "DVPM" (opération e-commerce) générant des règles de gestion différentes (voir ci-dessous).

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

➤ Codes erreur