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

Code établissement <cdetab>Nom de l'établissementNom abrégé
13807 B.P Grand Ouest BPGO
17515 CE Ile de France  CEIDF

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

 

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.

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

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

 

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.

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
Jour de semaine        
Avant 13h30 Jour J OK J

J si non férie, sinon jour suivant non férié

Entre 13h30 (compris) et 23h59:59:999 Jour J OK J

J+1 si non férie, sinon jour suivant non férié

Samedi (ou dimanche ou jour férié)        
Avant 13h30 Jour J OK J
Jour J OK J

Lundi si non férie, sinon jour suivant non férié

Entre 13h30 (compris) et 23h59:59:999  Jour J OK J

Lundi si non férie, sinon jour suivant non férié

 

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