Le verdict en trois phrases
Un webhook perdu signifie une commande payee par le client mais jamais confirmee dans votre systeme : le pire scenario e-commerce. La solution n'est pas d'esperer que Wave livre parfaitement, mais de combiner signature HMAC, retries programmes et reconciliation active via l'API getStatus. Avec ce triptyque, on passe d'un taux de perte de 2-4 % a une couverture proche de 100 %.
Pourquoi un webhook seul ne suffit jamais
Un webhook est une requete HTTP que Wave envoie a votre serveur quand un paiement change d'etat. Le probleme : cette requete peut echouer pour mille raisons (serveur momentanement indisponible, timeout reseau, deploiement en cours, pic de charge). Sans strategie de secours, chaque echec est un paiement orphelin.
Voici les ordres de grandeur observes en 2026 sur des integrations mobile money ouest-africaines :
| Metrique | Valeur (estimation 2026) | Consequence |
|---|---|---|
| Webhooks perdus sans retry | 2 a 4 % | Commandes payees non confirmees |
| Delai moyen de livraison webhook | 3 a 8 s | Ne pas afficher "echec" trop tot |
| Fenetre de reconciliation recommandee | T+1 (24 h) | Rattrapage quotidien des ecarts |
| Faux statut "pending" persistant | 1,5 % | Verification API obligatoire |
| Retries operateur avant abandon | 3 a 5 | Idempotence indispensable |
La lecon : le webhook est le canal rapide, mais il doit toujours avoir une doublure.
La signature HMAC : refuser tout ce qui n'est pas Wave
Avant de traiter un webhook, verifiez sa signature. Wave signe chaque payload avec un secret partage (HMAC-SHA256). Vous recalculez la signature de votre cote et comparez : si ca ne correspond pas, vous rejetez la requete avec un code 401. Cela bloque les tentatives de faux paiements injectes par un attaquant qui devinerait votre URL.
Regle d'or : ne jamais faire confiance au montant present dans le webhook seul. Recroisez toujours avec la commande cote base de donnees (montant, reference marchande, devise) avant de marquer la commande comme payee.
Retries et fallback polling : la ceinture et les bretelles
Deux mecanismes complementaires securisent l'encaissement :
| Mecanisme | Declenchement | Rythme | Role |
|---|---|---|---|
| Retry webhook interne | Echec de traitement | 5 min, 15 min, 60 min | Rejouer un webhook echoue |
| Polling API getStatus | Commande "pending" > 10 min | Toutes les 10 min, 6 fois max | Rattraper un webhook jamais recu |
| Reconciliation quotidienne | Batch nocturne | 1 fois/jour a T+1 | Croiser releve Wave et commandes |
| Alerte manuelle | Ecart non resolu | Immediate | Intervention humaine |
Concretement : si un webhook n'est jamais arrive au bout de 10 minutes, votre serveur interroge lui-meme l'API Wave pour connaitre l'etat reel de la transaction. C'est le filet de securite qui rattrape les 2-4 % de webhooks perdus.
Mini cas pratique
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.
Awa gere une boutique de cosmetiques a Dakar qui traite 900 commandes par mois a un panier moyen de 18 000 FCFA, soit 16 200 000 FCFA de chiffre d'affaires mensuel. Sans retry ni polling, elle perd en moyenne 3 % de confirmations, soit 27 commandes non confirmees automatiquement chaque mois.
Ces 27 commandes representent 486 000 FCFA qui restent bloquees en "pending" : clients relances par erreur, temps du service client, parfois remboursements a tort. En activant le polling getStatus toutes les 10 minutes et la reconciliation T+1, Awa ramene les commandes non confirmees a moins de 1 par mois. Gain net : environ 470 000 FCFA de CA securise chaque mois et 6 heures de service client economisees.
FAQ
Combien de webhooks se perdent vraiment sans retry ?
Entre 2 % et 4 % selon nos observations 2026 sur mobile money ouest-africain. Sur 1 000 commandes, cela represente 20 a 40 paiements orphelins par mois, largement suffisant pour justifier un fallback.
A quelle frequence dois-je faire le polling API ?
Toutes les 10 minutes, avec un maximum de 6 tentatives (soit une fenetre de 1 heure). Au-dela, la transaction bascule en reconciliation quotidienne T+1 plutot que d'epuiser inutilement l'API.
La signature HMAC ralentit-elle le traitement ?
Non. Le calcul HMAC-SHA256 prend moins de 1 ms. C'est negligeable face aux 3 a 8 secondes de latence reseau du webhook lui-meme, et le gain en securite est enorme.
Que faire d'un statut "pending" qui ne change jamais ?
Environ 1,5 % des transactions restent en faux "pending". La regle : au-dela de 60 minutes, considerer le paiement comme echoue apres une derniere verification getStatus, et liberer le stock reserve.
La reconciliation quotidienne est-elle vraiment necessaire si j'ai deja le polling ?
Oui. Le polling rattrape l'immediat, la reconciliation T+1 attrape les cas residuels (frais, remboursements, ecarts de montant) et vous donne une piste d'audit comptable propre.
Discutons de votre projet. Nous integrons Wave avec signature HMAC, retries et reconciliation active pour que vous ne perdiez plus jamais un paiement. 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.
