Le verdict en trois phrases
Wave rejoue les webhooks tant qu'il n'a pas reçu de réponse 200, ce qui, sans protection, crée des commandes en double et des paiements comptés deux fois. Sans garde-fou, on observe un taux d'incidents de l'ordre de 0,3 % — invisible à petite échelle, coûteux à grande. Trois mesures suffisent : clé d'idempotence, vérification de signature et table de transactions dédupliquée.
Pourquoi un webhook arrive deux fois
Un webhook n'est pas une garantie de livraison unique. Si votre serveur répond lentement, renvoie une erreur 500 ou dépasse le timeout, Wave considère l'événement non livré et le rejoue. Votre code reçoit alors deux fois le même paiement.
| Cause du doublon | Fréquence relative | Parade |
|---|---|---|
| Retry après timeout serveur | Élevée | Répondre 200 vite + traiter en asynchrone |
| Retry après erreur 5xx | Moyenne | Idempotence sur transaction_id |
| Double clic client au checkout | Moyenne | Clé d'idempotence côté requête |
| Rejeu malveillant | Faible | Vérification de signature |
| Race condition concurrente | Faible | Verrou/contrainte unique en base |
La règle d'or : traitez chaque transaction_id une seule fois, quelle que soit le nombre de fois où l'événement arrive.
Trois gardes-fous et leur coût de dev
| Mesure | Rôle | Effort dev (ordre 2026) |
|---|---|---|
| Vérification de signature | Rejeter les webhooks falsifiés | 1–2 h |
| Clé d'idempotence | Ignorer un événement déjà vu | 2–3 h |
| Table dédupliquée (unique) | Bloquer l'insertion en doublon | 1–2 h |
| Réponse 200 rapide + queue | Éviter le retry par timeout | 1–2 h |
| Journal des incidents | Auditer et rejouer proprement | 1 h |
Au total, un endpoint Wave robuste se construit en 4 à 8 heures de développement. C'est dérisoire face au coût d'un litige : une commande fantôme non détectée entraîne en moyenne une perte de l'ordre de 12 000 FCFA entre remboursement, temps de traitement et érosion de confiance.
Mini cas pratique
Moussa vend des billets d'événements en ligne à Dakar, avec 1 500 paiements/mois. Sans idempotence, à un taux d'incident de 0,3 %, il subit environ 4 à 5 doublons par mois : clients débités deux fois, e-mails de réclamation, remboursements manuels. À 12 000 FCFA de perte moyenne par incident, cela représente ~54 000 FCFA/mois et une réputation abîmée. Après avoir ajouté une clé d'idempotence et une contrainte unique sur transaction_id (6 heures de dev), son taux de doublon tombe à zéro.
Besoin d'un site web professionnel ?
Kolonell crée des sites web qui attirent des clients, optimisés pour le marché sénégalais. Devis gratuit en 2 minutes.
FAQ
Qu'est-ce qu'une clé d'idempotence concrètement ?
C'est un identifiant unique attaché à une opération de paiement. Si votre serveur reçoit deux fois la même clé, il traite la première et ignore la seconde, garantissant un seul encaissement.
Pourquoi vérifier la signature du webhook ?
Elle prouve que l'appel vient bien de Wave et non d'un attaquant qui simulerait un paiement réussi. C'est la première ligne de défense, codée en 1 à 2 heures.
Une contrainte unique en base suffit-elle ?
Elle bloque l'insertion d'un doublon au niveau base, filet de sécurité robuste. Combinée à la clé d'idempotence côté application, elle couvre les race conditions.
Combien de temps Wave rejoue-t-il un webhook ?
Wave réessaie selon une fenêtre de retry tant qu'il n'obtient pas de réponse 200. D'où l'importance de répondre 200 rapidement et de traiter la logique métier en asynchrone.
Discutons de votre projet. On sécurise votre intégration Wave contre les doubles encaissements. WhatsApp +221 77 596 93 33.
Mohamed Bah
Fondateur, Kolonell
Passionné par le digital et l'entrepreneuriat en Afrique, Mohamed accompagne les entreprises sénégalaises dans leur transformation digitale depuis 2020. Fondateur de Kolonell, il croit que chaque PME mérite une présence en ligne professionnelle et accessible.
