Récupérer le statut d’une demande
d’initiation de paiement
➤ Cas d'usage
Cette méthode permet au PISP d'obtenir le statut d’une demande d’initiation de paiement précédemment envoyée à l’ASPSP, pour un PSU donné, via une requête de type POST/payment-requests.
➤ Prérequis
Pour procéder à cette requête il est nécessaire de remplir les prérequis d’éligibilité et d'avoir récupéré le jeton d'accès OAUTH2 (voir la rubrique "Récupérer un jeton").
Le TPP a déjà envoyé une requête qui a été enregistrée par l'ASPSP et à laquelle l'ASPSP a répondu avec un lien de localisation vers la demande d'initiation de paiement ou de virement sauvegardée.
➤ Requête GET
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'établissement | Nom 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 :
- GET https://www.13807.live.api.89c3.com/stet/psd2/v1.4.2/payment-requests/{paymentRequestResourceId} ou https://www.13807.live.api.banquepopulaire.fr/stet/psd2/v1.4.2/payment-requests/{paymentRequestResourceId} pour récupérer le statut d'un paiement pour un client de la BPGO en production
➤ Paramètres obligatoires ou facultatifs du body requis pour l'appel de ce service
Paramètre obligatoire paymentRequestResourceId : identifiant de la requête d'initiation de paiement pour laquelle on souhaite accéder au statut.
➤ Résultat retourné
A la soumission de la requête et si toutes les données sont correctement formatées, une réponse (HTPP 200) vous sera retournée.
Cette réponse contiendra les données de l'initiation de paiement enrichies du statut de la requête d'initiation et du paiement associé.
Les valeurs possibles pour le statut de la demande de paiement sont les suivantes (valeurs pour la version STET v1.4.2.17) :
Code | Description |
---|---|
ACCP | Profil Client Accepté (AcceptedCustomerProfile) : La vérification précédente de la validation technique a été réussie. La vérification du profil du client a également été réussie. |
ACSC | Règlement accepté terminé (AcceptedSettlementCompleted) : Le règlement sur le compte du débiteur est terminé. |
ACSP | Règlement accepté en cours (AcceptedSettlementInProcess) : Toutes les vérifications précédentes, telles que la validation technique et le profil du client, ont abouti. L’évaluation dynamique des risques est également un succès et la demande de paiement a donc été acceptée pour exécution. |
ACTC | Validation technique acceptée (AcceptedTechnicalValidation) : L'authentification et la validation syntaxique et sémantique ont réussi. |
ACWC | Accepté avec changement (AcceptedWithChange) : Les instructions sont acceptées mais une modification sera apportée, telle que la date ou le versement non envoyé. |
ACWP | Accepté sans écriture (AcceptedWithoutPosting) : Les instructions de paiement incluses dans le virement sont acceptées sans être enregistrées sur le compte du client créancier. |
CANC | Annulé (Cancelled) : l'initiation de paiement a été annulée après réception d'une requête d'annulation. |
PART | Partiellement accepté (PartiallyAccepted) : un certain nombre de transactions ont été acceptées, tandis qu'un autre nombre n'a pas encore atteint le statut «accepté». |
PATC | Partiellement accepté (PartiallyAcceptedTechnicalCorrect) : plusieurs authentifications sont nécessaires et certaines ont été effectuées, mais pas toutes. Les vérifications sémantiques et synthaxiques sont correctes |
RCVD | Reçu (Received) : le paiement a été initié par l'agent destinataire. |
PDNG | En attente (Pending) : Une demande de paiement ou une transaction individuelle incluse dans la demande de paiement est en attente. Des vérifications supplémentaires et une mise à jour du statut seront effectuées. |
RJCT | Rejeté (Rejected) : La demande de paiement a été rejetée. |
Le tableau suivant reprend les valeurs possibles pour le statut de l'initiation de paiement et de la transaction de paiement associée (valeurs pour la version STET v1.4.2.17) suite à une requête d'initiation de paiement :
Etape de traitement d'une initiation contenant un paiement | Résultat de l'étape | Valeur de paymentInformationStatus à l'issue de l'étape | Valeur de crediTransferTransaction / transactionStatus à l'issue de l'étape |
---|---|---|---|
Contrôle et enregistrement de la requête d'initiation (réception et réponse au paymentRequest de l'API DSP2) | OK | ACTC | - |
KO | RJCT | - | |
Consentement (début consommation de l'URL consentAproval | OK | ACCP | - |
KO | RJCT | - | |
Demande d'exécution du paiement (juste avant retour REDIRECT vers l'application du TPP) | OK | ACSP (ou PDNG uniquement en environnement sandbox) | PDNG si virement exécuté à J ACSP sinon (forcé à PDNG en environnement sandbox) |
KO | RJCT | RJCT | |
Si le PSU ne fait aucune action de consentement (validation ou refus) dans les 30 minutes qui suivent la requête d’initiation | RJCT (raison NOAS) | RJCT (raison NOAS) | |
Jour d'exécution de paiement avant mise à jour du statu la nuit | ACSP | ACSP | |
Jour d’exécution de paiement après mise à jour du statut la nuit (hors paiement permanent sauf le jour de sa dernière échéance) | OK | ACSC | ACSC |
KO | RJCT | RJCT | |
Jour d’exécution de paiement après mise à jour du statut la nuit (paiement permanent sauf le jour de sa dernière échéance) | OK | ACSP | ACSP |
KO | RJCT | RJCT |
Le tableau suivant reprend les valeurs possibles pour le statut de l'initiation de paiement et de la transaction de paiement associée (valeurs pour la version STET v1.4.2.17) suite à une requête d’annulation d’une initiation de paiement :
Etape de traitement d'une initiation contenant un paiement | Résultat de l'étape | Valeur de paymentInformationStatus à l'issue de l'étape | Valeur de crediTransferTransaction / transactionStatus à l'issue de l'étape |
---|---|---|---|
Avant réception de la demande d'annulation du paiement | ACTC/ACCP/ACSP | -/PDNG (si paymentInformationStatus = ACSP) | |
Contrôle et enregistrement de l’annulation de requête d'initiation Juste avant la réponse à la requête d’annulation | OK | RJCT/RJCT/ACSP | -/PDNG (si paymentInformationStatus = ACSP) |
KO | ACTC/ACCP/ACSP | -/PDNG (si paymentInformationStatus = ACSP) | |
Consentement | OK | ACSP | PDNG |
KO | ACSP | PDNG | |
Appel au service d’annulation du paiement Juste avant la redirection sur l’application du TPP | OK | CANC (DS02, DUPL, FRAD, TECH) | CANC (DS02, DUPL, FRAD, TECH) |
KO | ACSP | PDNG |
➤ Exemples d’évolution du statut du virement
Exemple 1 :
- Une demande d’initiation de paiement est effectuée un jour ouvré à 16h,
- Comme la demande arrive avant 17h, le virement est exécuté le même jour (même si la date de règlement est positionnée à J+1) => un SCT de type immédiat est demandé pour exécution à J,
- La donnée creditTransferTransaction / transactionStatus est positionnée à PDNG dès la validation de l’initialisation du paiement.
Exemple 2 :
- Une demande d’initiation de paiement est effectuée un jour ouvré à 18h,
- Comme la demande arrive après 17h, le virement n’est pas programmé pour être exécuté le même jour => il est transformé en SCT différé et programmé pour le jour ouvré suivant, i.e. à J+1,
- La donnée creditTransferTransaction / transactionStatus est positionnée à ACSP dès la validation de l’initialisation du paiement,
- Le batch journalier de mise à jour du statut des virements qui sont dans un état non terminal est exécuté à 20h00. Ce batch met à l’état PDNG les virements prévu le même jour donc on a :
- Le jour J de la demande d’initiation du paiement (de sa création à 24h00), le paiement reste à l’état ACSP puisqu’il est programmé pour le jour J+1,
- A J+1, la donnée creditTransferTransaction / transactionStatus reste à l’état ACSP jusqu’au passage du batch à 20h00. A cette heure-là, la transaction pourrait passer à l’état PDNG
- Mais comme entre-temps, le virement a été exécuté, il est possible (voire probable) qu’en fait le statut de la transaction soit directement passé de l’état ACSP à l’état ACSC.
Exemple 3 :
- Une demande d’initiation de paiement pour un paiement permanent mensuel est soumise le mercredi 26/02/2020 (2020-02-26T14:00:00.000+02:00) avec :
- Une requestedExecutionDate le mercredi 04/03/2020 (2020-03-04T14:00:00.000+02:00) ;
- Une endDate le lundi 04/05/2020 (2020-05-04T14:00:00.000+02:00) ;
- Un executionRule non alimenté
- Les différents statuts obtenus seraient par exemple
Date de l’interrogation du statut | Etape de traitement de l’initiation contenant un paiement | Valeur de requestedExecutionDate | Valeur de paymentInformationStatus et de crediTransferTransaction / transactionStatus à l'issue de l'étape |
---|---|---|---|
2020-02-26T14:00:00.000+02:00 | Demande d'exécution du paiement (juste avant retour REDIRECT vers l'application du TPP) | 2020-03-04T14:00:00.000+02:00 | ACSP / ACSP |
2020-02-27T14:00:00.000+02:00 | Avant jour 1ère échéance | 2020-03-04T14:00:00.000+02:00 | ACSP / ACSP |
2020-03-04T14:00:00.000+02:00 | Jour d'exécution de la 1ère échéance avant mise à jour du statut la nuit | 2020-03-04T14:00:00.000+02:00 | ACSP / ACSP |
2020-03-04T21:30:00.000+02:00 | Jour d'exécution de la 1ère échéance après mise à jour du statut la nuit | 2020-04-06T14:00:00.000+02:00 (date recalculée le premier jour ouvré, le lundi 6 avril, après l’échéance du 4 avril qui tombe un samedi) | ACSP / ACSP |
2020-03-29T14:00:00.000+02:00 | Avant jour 2ème échéance | 2020-04-06T14:00:00.000+02:00 | ACSP / ACSP |
2020-03-06T14:00:00.000+02:00 | Jour d'exécution de la 2ème échéance avant mise à jour du statut la nuit | 2020-04-06T14:00:00.000+02:00 | ACSP / ACSP |
2020-03-06T21:30:00.000+02:00 | Jour d'exécution de la 2ème échéance après mise à jour du statut la nuit | 2020-05-04T14:00:00.000+02:00 (date recalculée le lundi 4 mai) | ACSP / ACSP |
2020-04-02T14:00:00.000+02:00 | Avant jour 3ème et dernière échéance | 2020-05-04T14:00:00.000+02:00 | ACSP / ACSP |
020-04-04T14:00:00.000+02:0 | Jour d'exécution de la 3ème et dernière échéance avant mise à jour du statut la nuit | 2020-05-04T14:00:00.000+02:00 | ACSP / ACSP |
2020-04-04T21:30:00.000+02:00 | Jour d'exécution de la 3ème et dernière échéance après mise à jour du statut la nuit | 2020-05-04T14:00:00.000+02:00 | ACSC / ACSC |
Exemple 4 :
- Une demande d’initiation de paiement pour un SEPA Instant Payment est effectuée,
- La donnée creditTransferTransaction / transactionStatus est positionnée à ACSP dès la validation de l’initialisation du paiement,Dans les 10 secondes le virement est exécuté et le bénéficiaire est crédité sur son compte après soumission de la requête POST /paymentRequests/o-confirmation, la donnée creditTransferTransaction / transactionStatus passe à l’état ACSC dans les 20 secondes après la réponse du POST /paymentRequests/o-confirmation.
Exemple 5 :
- Pour les clients PRO et ENTREPRISE de la Banque Palatine qui utilisent la fonctionnalité du parapheur (Cyber ou mobile) pour valider leurs ordres, les virements SCT immédiats, permanents ou différés qui ont été soumis via une initiation de paiement, ne seront exécutés qu’une fois l’ordre correspondant validé dans le parapheur dans leur banque à distance.
- Après soumission de la requête POST /paymentRequests/o-confirmation, la donnée creditTransferTransaction / transactionStatus passe à « ACSP ».
➤ Restitution de l’IBAN du compte débité
Depuis fin octobre 2020, l’IBAN du compte débité est systématiquement retourné par cette requête, même si cette donnée n’était pas présente dans la requête initiale de demande d’initiation de paiement.
➤ Exemple
Requête :
GET /stet/psd2/v1.4.2/payment-requests/0000000386-155532845000030007970322
Résultat :
Status code : 200
Body
{ |
➤ Codes erreur
Type d'erreur | Code HTTP | Libellé | Motif |
---|---|---|---|
Mauvais access token, problème d'authentification | 403 | Forbidden | |
Request resource inconnu | 404 | Not Found | Ressource inconnue |
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 |