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 API de paiement 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 valideconfirming: transfert détecté en attente de confirmationspaid: montant et confirmations satisfaitsexpired: délai terminé avant la détection du paiementexception: 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; l'API de paiement 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.