
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'établissement | Nom abrégé |
---|---|---|
13807 | B.P Grand Ouest | BPGO |
17515 | CE Ile de France | CEIDF |
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
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.
- 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 champ creationDateTime ne doit pas être vide, avoir une date supérieure ou égale à la date de la demande d'initiation de paiement et être au 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
Il est possible de déclencher un parcours fluide (avec deux variations) lorsque la requête contient des informations plus précises du 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 requestedExecutionDate | Résultat de la prise en compte de la demande d’initiation de paiement | Date d’exécution | Date 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 requestedExecutionDate | Résultat de la prise en compte de la demande d’initiation de paiement | Date d’exécution | Date 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 |