Le verdict en trois phrases
Un webhook Orange Money n'est jamais garanti unique ni ponctuel : il peut arriver deux fois, en retard de plusieurs minutes, ou se perdre. Votre code doit donc etre idempotent (le meme event traite deux fois ne change rien), patient (retry a backoff exponentiel) et couvert (polling de rattrapage pour les events perdus). Sur 10 000 events par mois, environ 2 % arrivent en double et 0,3 % se perdent sans filet de secours — soit 30 paiements qui disparaissent si vous n'avez pas de polling.
Les trois defaillances a couvrir
Un systeme de webhook fiable ne suppose jamais le meilleur cas. Il part du principe que chaque event peut echouer de trois manieres, et il traite chacune.
Le doublon : l'operateur rejoue un event parce que votre 200 est arrive trop tard, et vous recevez la meme confirmation deux fois. Sans idempotence, vous creditez deux fois la commande. Le retard : un pic de trafic cote operateur decale la livraison de plusieurs minutes ; votre systeme ne doit pas conclure a un echec trop vite. La perte : l'event n'arrive jamais (panne reseau des deux cotes) ; seul un polling de secours le rattrape.
| Type de defaillance | Frequence estimee 2026 | Parade |
|---|---|---|
| Doublon | Environ 2 % des events | Cle d'idempotence transaction_id |
| Retard (> 1 min) | Environ 5 % des events | Statut "en attente", pas d'echec |
| Perte totale | Environ 0,3 % des events | Polling toutes les 15 min |
| Ordre inverse | Environ 1 % | Traiter par timestamp, pas par arrivee |
| Signature invalide | Rare mais critique | Rejet immediat, log securite |
Ces chiffres sont un ordre de grandeur 2026 : ils varient selon l'operateur et la qualite reseau, mais l'architecture doit tenir dans le pire des cas.
La strategie de retry et le fallback polling
Quand votre serveur ne repond pas, l'operateur rejoue selon un backoff exponentiel : les intervalles s'allongent pour ne pas noyer un serveur deja en difficulte. De votre cote, si vous devez rejouer un traitement interne (mise en file), appliquez la meme logique.
| Tentative | Delai apres echec | Cumul ecoule |
|---|---|---|
| 1re | 1 s | 1 s |
| 2e | 5 s | 6 s |
| 3e | 30 s | 36 s |
| 4e | 5 min | Environ 5 min |
| 5e | 30 min | Environ 35 min |
| Fallback | Polling toutes les 15 min | En continu |
Le backoff a lui seul ne suffit pas : si l'event est definitivement perdu, aucun retry ne le fera revenir. C'est pourquoi le polling de rattrapage est indispensable. Toutes les 15 min, un job liste les commandes en statut "en attente" depuis plus de X minutes et interroge directement l'API de statut de l'operateur. Cette double couverture — retry pousse par l'operateur, polling tire par vous — ramene le taux de perte reel de 0,3 % a quasiment zero.
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.
Mini cas pratique
Fatou gere une plateforme de reservation a Dakar avec paiement Orange Money. En avril 2026, elle traite 10 000 events. Sans filet, elle aurait perdu environ 30 paiements (0,3 %) et double-credite environ 200 commandes (2 %).
Apres mise en place de l'idempotence par transaction_id et du polling toutes les 15 min, le bilan change : les 200 doublons sont absorbes sans effet (meme cle = ignore), et sur les 30 events perdus, le polling en rattrape 28 en moins de 15 min chacun. Les 2 restants sont traites a la reconciliation quotidienne. Resultat : zero double credit, deux commandes rattrapees a la main au lieu de trente perdues. Le temps passe sur les incidents de paiement tombe de 4 h a 20 min par semaine.
FAQ
Comment garantir l'idempotence ? Stockez le transaction_id de chaque event traite dans une table avec contrainte d'unicite. Avant tout traitement, verifiez sa presence : s'il existe deja, renvoyez 200 sans rien faire. Cela neutralise les 2 % de doublons.
Quel intervalle de polling choisir ? Toutes les 15 min pour les commandes en attente depuis plus de 5 min offre un bon compromis entre fraicheur et charge. Un polling plus frequent alourdit l'API operateur sans gain reel.
Combien de retries avant d'abandonner ? Cote operateur, jusqu'a 5 tentatives sur environ 35 min. Au-dela, ne comptez que sur le polling : un event non arrive apres 5 tentatives est probablement perdu.
Faut-il traiter les events dans l'ordre d'arrivee ? Non : traitez par timestamp de l'event, pas par ordre de reception. Environ 1 % des events arrivent dans le desordre, et se fier a l'arrivee cree des incoherences de statut.
Que faire d'un event a signature invalide ? Rejet immediat et log de securite. Une signature invalide signale soit un bug de configuration, soit une tentative de falsification : ne traitez jamais un tel event.
Discutons de votre projet. On construit votre gestion de webhooks Orange Money avec idempotence, retry et polling pour ne perdre aucun 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.
