Pourquoi les paiements en stablecoins ont besoin de confirmations et d'expiration
L'apparition d'une transaction sur la blockchain ne signifie pas que la commande doit être finalisée immédiatement. La passerelle doit encore gérer les confirmations, l'expiration, les notifications répétées et les transferts envoyés après la fermeture du checkout.
Les confirmations gèrent la certitude on-chain
Lorsqu'un nœud observe une transaction, elle est généralement encore en attente. Une profondeur adaptée réduit les risques liés aux forks temporaires, aux différences entre nœuds ou aux changements d'état. Le nombre requis dépend du réseau, du montant et de la vitesse de livraison.
L'expiration gère la cohérence métier
La durée de validité limite la fenêtre d'un devis, d'une réservation ou d'une recharge, mais ne peut pas empêcher un transfert. Si le client paie en retard, le système doit détecter le mouvement et l'envoyer vers un flux de paiement tardif ou d'exception.
Séparez clairement les états
- `pending`: commande créée sans transfert valide
- `confirming`: transfert détecté en attente de confirmations
- `paid`: montant et confirmations satisfaits
- `expired`: délai terminé avant la détection du paiement
- `exception`: montant, token, réseau ou horaire à vérifier
Les callbacks doivent être idempotents
Les nouvelles tentatives peuvent livrer plusieurs fois le même événement. Le marchand doit dédupliquer par commande et événement; la passerelle doit conserver résultats, tentatives et dernière réponse pour empêcher tout crédit en double.
Un modèle d'implémentation plus sûr
Fixez token, réseau, montant et expiration à la création. Enregistrez le hash dès la détection et marquez la commande payée uniquement après les confirmations. Les sous-paiements, surpaiements, mauvais tokens et paiements tardifs doivent disposer d'une revue séparée.