The verdict in three sentences
Most merchants think they lose sales because of the operator, when in fact 9 out of 10 "lost" payments actually succeeded on the customer side but were never confirmed on the site because the webhook was never replayed. In 2026, with a 30-second operator timeout and a missed-webhook rate around 5%, the gap between a reliable checkout and a bleeding one comes down to three building blocks: idempotency key, exponential retry, and reconciliation by polling. Done right, they recover on average 4.5% of transactions every month — money already paid that you simply need to go collect.
Why webhooks get lost
A webhook is a plain HTTP call the operator sends to your server to say "this payment is confirmed." It fails for mundane reasons: your server responds in over 30 seconds, it returns a transient 500 error, a deployment cuts the connection, or the operator itself queues the notification. Without a catch-up mechanism, the order stays stuck as "pending" even though the customer genuinely paid.
| Webhook failure cause | Estimated 2026 frequency | Technical fix |
|---|---|---|
| Server timeout (> 30 s) | 35% | Return 200 in < 2 s, process asynchronously |
| Transient 500 error | 25% | Exponential retry operator-side and yours |
| Deployment / restart | 15% | Queue + idempotent endpoint |
| Duplicate notification | 15% | Mandatory idempotency key |
| Notification never sent | 10% | Reconciliation polling every 60 s |
The golden rule: your webhook endpoint must return 200 immediately, store the raw event, then process the business logic in the background. A webhook that calculates stock or sends an email before responding is a webhook that will time out.
The retry + polling strategy that recovers 4.5%
Two safety nets complement each other. Retry replays the notification when it fails; polling queries the operator when no notification arrives. You do not choose — you use both.
| Parameter | Recommended 2026 value | Effect |
|---|---|---|
| Number of retry attempts | 5 | Covers 98% of transient failures |
| Exponential backoff | 30 s, 1 min, 2 min, 5 min, 15 min | Avoids hammering an already loaded server |
| Total retry window | 15 min | Beyond that, switch to polling |
| Polling frequency | every 60 s | Catches never-sent notifications |
| Polling duration per order | 20 min | Covers slow USSD confirmations |
| Idempotency key | 1 per transaction | Prevents double order validation |
The idempotency key is non-negotiable: it is a unique identifier per transaction that guarantees that if the webhook arrives twice (retry + normal notification), the order is validated only once and the customer is never charged or credited twice.
Mini case study
Mariama runs a cosmetics shop in Dakar with 900 orders per month, average basket 12,000 FCFA. Previously, 5% of her webhooks were lost: 45 orders per month stayed "pending," or 540,000 FCFA in sales paid but never fulfilled — angry customers and manual refunds to boot. After adding exponential retry + 60 s polling + idempotency key, her missed-webhook rate drops to 0.5%. She recovers 40 orders per month, i.e. 480,000 FCFA recovered every month, for a development cost paid back in under three weeks.
Need a professional website?
Kolonell builds websites that attract clients, optimized for the Sénégalese market. Free quote in 2 minutes.
FAQ
How long should I keep an order "pending" before cancelling it?
At least 20 minutes. Slow USSD confirmations and operator retries can take up to 15 minutes; cancelling too early destroys already-paid sales.
Is the idempotency key really mandatory?
Yes. Without it, a legitimate retry can validate the same order twice, double a decremented stock, or trigger a duplicate shipment. It is the cheapest and most profitable building block.
Won't polling overload the operator's API?
No, if you limit it to one request every 60 s per pending order and stop after 20 minutes. Most operators tolerate this pace without rate limiting.
What real gain can I expect?
2026 order of magnitude: between 3 and 5% of transactions recovered depending on the quality of your network and servers. On a volume of 1,000 orders, that is 30 to 50 saved sales per month.
Can I earn money by recommending Kolonell to other merchants?
Yes. Our referral program pays 12% on every e-commerce project signed thanks to you, plus 5% recurring on maintenance. A 2,000,000 FCFA e-commerce site earns you 240,000 FCFA.
Let's talk about your project. We audit your checkout and plug your webhook leaks in one week. WhatsApp +221 77 596 93 33.
Mohamed Bah
Fondateur, Kolonell
Passionate about digital and entrepreneurship in Africa, Mohamed has been helping Sénégalese businesses with their digital transformation since 2020. Founder of Kolonell, he believes every SME deserves a professional and accessible online présence.
