Initier un paiement

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

 

Code établissement <cdetab>Nom de l'établissementNom abrégé<banque>
13807 B.P Grand Ouest BPGO banquepopulaire
10548 Banque de Savoie BQSAV banque-de-savoie
40978 Banque Palatine BPAL palatine

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 :

 

Paramètres obligatoires ou facultatifs du body requis pour l'appel de ce service

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 requête doit contenir une demande d'initiation pour un seul paiement
  • La donnée numberOfTransactions doit être valorisée à "1"
  • 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ésentepour 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 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 "successfulReportUrl" est obligatoire pour le mode d'authentification REDIRECT mis en œuvre. Elle doit contenir la redirect URL ainsi que le pkce (code_challenge et 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'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
  • La donnée "state" est obligatoire pour le mode d'authentification REDIRECT mis en œuvre : elle est propagée durant tout le parcours PISP.
  • La donnée beneficiary.creditor.name est limitée 35 caractères.

 

Déclenchement des parcours fluides

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

 

Notion de cut-off – heure limite pour passer un virement SCT immédiat

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

Heure d’arrivée de la demande initialisation de paiement en heure locale française

Valeur de champ creationDateTime

Valeur du champ requestedExecutionDateRésultat de la prise en compte de la demande d’initiation de paiementDate d’exécutionDate de règlement
Avant 11h00 Jour J OK J J
Entre 11h00 et 17h00 Jour J OK J J+1
Après 17h00 Jour J OK J+1 J+1
Toute heure >= Jour J+1 ou plus tard OK requestedExecutionDate requestedExecutionDate

 

Sur le choix de rendre obligatoire certains champs facultatifs de la norme

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.

 

Contrôle sur le bénéficiaire

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.

 

Cas de rejet injustifié d’un SCT immédiat

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

Type d'erreur

Code HTTP
Libellé
Motif
Générique, mauvaise structure 400 Bad request error code : FF01
message : RJCT
Mauvais format du BIC 400 Bad request error code : FF01
message : RJCT
error : le champ creditorAgent.bicFi bicFi-Code allocated to a financial institution by the ISO 9362 Registration Authority as described in ISO 9362
Mauvais format du serviceLevel 400 Bad request error code : FF01
message : RJCT
error : value not one of declared Enum instance names: [SEPA, NURG]
Mauvais format, chargeBearer autre que SLEV 400 Bad request error code: FF01
message: RJCT
error: value not one of declared Enum instance names: [SLEV]
Mauvais format du schemeName 400 Bad request error code: FF01
message : RJCT
error : le champ creditor.privateId.schemeName schemeName-Possible values BANK,COID,SREN,DSRET,NIDN,OAUT,CPAN
Mauvais format du purpose 400 Bad request error code: FF01
message: RJCT
error: value not one of declared Enum instance names: [TRPT, CASH, CPKC, ACCT, COMC]
Mauvais format du categoryPurpose 400 Bad request error code: FF01
message: RJCT
error: value not one of declared Enum instance names: [CASH, DVPM]
Mauvais jeton d'accès, problème d'authentification 403 Forbidden  
Request resource inconnu 404 Not Found  
Mauvaise requête ou requête hors périmètre autorisé 405 Method not allowed  
Message générique 500 Internal server error  
Requête en doublon 500 Internal server error error : Problème d'insertion en base de donnée, clé unique dupliquée