Après le paiement : transformer chaque encaissement en service rendu
Le paiement est reçu, mais le client attend
Un client paie 100 USDT pour un abonnement. La page de paiement confirme le règlement, mais l’accès reste inactif. L’interruption peut se situer dans la notification, le rapprochement de la commande ou l’activation des droits.
Suivez trois résultats distincts : paiement confirmé, notification reçue de façon fiable et service livré. Ces traces aident le support à expliquer l’avancement et le système à reprendre une tâche interrompue.
Séparer paiement et livraison
L’état du paiement décrit l’encaissement. L’état de livraison décrit le crédit d’un compte, l’activation d’un abonnement ou la remise d’un produit numérique. Conservez des états et des horodatages indépendants.
Si l’activation échoue après confirmation, affichez « Payé, activation en cours ». Conservez le paiement confirmé et la tâche à reprendre. Ne remettez pas la commande en attente de paiement et ne demandez pas un second règlement.
Recevoir durablement avant de livrer
Vérifiez la signature selon la documentation UUGate, puis l’appartenance de la commande, l’actif, le réseau, le montant et l’état. Une redirection du navigateur ou une capture de transfert ne remplace pas la vérification côté serveur.
Enregistrez durablement l’événement validé et la tâche avant de répondre selon la documentation. Une livraison longue peut être traitée ensuite. Un événement conservé uniquement en mémoire peut disparaître au redémarrage.
Une commande, un seul résultat métier
Les notifications peuvent être répétées. Utilisez une contrainte unique associant marchand et commande, avec des transactions ou des mises à jour conditionnelles, pour éviter crédits, livraisons ou prolongations en double.
Pour un service externe, réutilisez une clé d’idempotence stable et conservez sa réponse. Un délai dépassé ne prouve pas un échec : consultez le résultat précédent ou utilisez l’idempotence du service avant de recommencer.
Prévoir une suite pour chaque exception
Gardez une liste consultable des commandes payées mais non livrées, avec dernière erreur, date de tentative et résultat. Distinguez incidents temporaires et incohérences de commande ou de montant nécessitant un contrôle.
Reliez numéro de commande plateforme, référence marchand, hash de transaction et preuve de livraison. Une reprise manuelle doit suivre la même déduplication et la même piste d’audit. Rapprochez séparément le solde réel sur la blockchain et le compte de frais ; les livraisons ne déterminent pas le solde.
Tester les interruptions avant le lancement
- Un paiement normal livre le service une seule fois.
- Les notifications répétées ne doublent ni crédit ni livraison.
- Les tâches enregistrées survivent à un redémarrage.
- Un délai externe dépassé peut être résolu sans double livraison.
- Un paiement confirmé avec livraison échouée affiche un traitement en cours et un moyen de suivre l’avancement.
UUGate fournit paiement et notification ; l’application du marchand transforme le résultat vérifié en service. La recette doit aller jusqu’à la réception effective par le client.
Documentation UUGate · Reprise des webhooks
Référence générale : Documentation des webhooks Stripe. Pour les signatures, champs et réponses UUGate, suivez la documentation UUGate.