Ressources · 47
Paiement incertain : reprendre le parcours sans commande en double
Traiter délai réseau, retour navigateur, notifications et état métier comme des signaux à rapprocher.
· 3 min
Ce que ce guide permet
- Distinguer tentative, paiement et commande
- Gérer les retours retardés ou absents
- Dédupliquer notifications et demandes
- Expliquer l’incertitude sans faire repayer
Contrôle express
- Quelle source confirme le paiement ?
- La fermeture du navigateur change-t-elle l’état métier ?
- Une notification répétée prépare-t-elle deux commandes ?
- Les signatures des événements sont-elles vérifiées ?
- Comment le support retrouve-t-il une opération incertaine ?
Méthode pas à pas
- 01
Définir les états
Séparez panier, tentative, autorisation, paiement confirmé, commande et remboursement. Écrivez transitions, source faisant foi et actions permises. Le modèle doit suivre le fournisseur et les moyens de paiement réellement utilisés ; tous ne confirment pas immédiatement.
Livrable : diagramme d’états et contrat métier.
- 02
Identifier l’opération
Reliez une tentative à une commande et aux identifiants du fournisseur. Utilisez la règle d’idempotence documentée pour une répétition de la même opération. Un nouveau besoin ou des paramètres différents nécessitent une décision explicite, pas la réutilisation aveugle d’une clé.
Livrable : identité stable et règles de reprise.
- 03
Traiter le retour navigateur
Affichez l’état obtenu par une vérification serveur adaptée au fournisseur. N’utilisez pas le seul retour vers une page de succès comme preuve de paiement. Prévoyez navigateur fermé, retour absent, authentification interrompue et réseau lent.
Livrable : parcours de retour et messages par état.
- 04
Vérifier les notifications
Vérifiez authenticité selon la documentation du fournisseur, enregistrez l’identifiant d’événement et traitez les répétitions sans effet doublé. Les événements peuvent arriver tard ou dans un autre ordre. Si nécessaire, relisez l’objet de référence avant une transition irréversible.
Livrable : gestionnaire testé et traces sans données bancaires.
- 05
Rapprocher les écarts
Comparez opérations du fournisseur, commandes et préparation. Isolez les cas payé sans commande, commande sans confirmation, double traitement et remboursement non propagé. Donnez à chaque écart un propriétaire et une procédure ; ne relancez pas automatiquement un débit incertain.
Livrable : file de rapprochement et décisions.
- 06
Tester la reprise complète
Dans le mode de test du fournisseur, rejouez timeout, doublon, événement retardé, ordre inversé et retour absent. Vérifiez une seule transition métier, la bonne information au client et la visibilité au support. Les détails d’idempotence diffèrent entre fournisseurs.
Livrable : preuves de non-duplication et critères de mise en service.
Exemple d’application
Situation illustrative
Situation illustrative : le paiement réussit, mais la connexion du client coupe avant la page de confirmation et deux notifications arrivent ensuite.
Décision et preuve attendue
Une seule commande est confirmée. La reprise affiche son état vérifié ; le support peut rapprocher la référence sans demander les données bancaires.
Distinguer les mécanismes
| Mécanisme | Utilité | Point de vigilance |
|---|---|---|
| Retour navigateur | Informer et reprendre l’interface | Peut être absent ou interrompu |
| Webhook vérifié | Recevoir un changement du fournisseur | Peut être répété, retardé ou désordonné |
| Rapprochement serveur | Comparer état du paiement et commande | Nécessite une règle de résolution des écarts |
Indicateurs de pilotage
| Indicateur | Ce qu’il mesure | Première action |
|---|---|---|
| États incertains | Opérations non résolues dans le délai prévu | Vérifier l’état de référence |
| Effets dupliqués | Commandes ou traitements en double | Corriger la déduplication métier |
| Écarts clos | Cas rapprochés avec décision et preuve | Traiter les plus anciens et critiques |
Erreurs fréquentes
- Confirmer depuis une URL de succès seule
- Transformer un timeout en paiement échoué
- Supposer que les événements arrivent dans l’ordre
- Recommencer un débit avant vérification
Questions fréquentes
Un timeout signifie-t-il un échec ?
Non. Il signifie que la réponse n’a pas été reçue dans le délai. Vérifiez l’état de l’opération avant d’en créer une nouvelle.
L’idempotence du fournisseur suffit-elle ?
Non. Votre création de commande, préparation et notification doivent aussi supporter un traitement répété sans effet métier doublé.
Que dire à l’utilisateur ?
Expliquez que la vérification est en cours, donnez une référence sûre et un moyen de retrouver l’état. Évitez une demande de nouveau paiement tant que le précédent reste incertain.
Références officielles
Pour aller plus loin
