The verdict in three sentences
A non-idempotent webhook is a time bomb: it doubles orders when the operator resends the event, or loses them when your server is momentarily unavailable. Reliability doesn't depend on luck but on two mechanics: verify the signature of every event and process each reference exactly once, with a queue that retries 5 times over 24 h. In Nairobi, these invisible details separate a store losing 1-3 % of orders from a store at 99.9 % reliability.
Polling vs signed webhook: the real match
Many stores poll the provider API in a loop to learn whether a payment went through. It's simple but slow and costly. The signed webhook with a queue is more robust. Here is the 2026 comparison.
| Metric | API polling | Signed webhook + queue |
|---|---|---|
| Confirmation delay | 30 s - 5 min | 2-30 s |
| Server load | High (repeated calls) | Low (single event) |
| Rate-limit risk | High | None |
| Order loss | 2-5 % | < 0.3 % |
| Duplicate order | Frequent without lock | None if idempotent |
| Infra cost / month (est.) | 15,000-40,000 FCFA | 5,000-15,000 FCFA |
| Achievable SLA | ~99 % | 99.9 % |
The signed webhook wins on almost every axis: faster, cheaper, more reliable. The only prerequisite is to build it correctly from the start.
The rules of a webhook that loses nothing
A reliable webhook in 2026 follows a few non-negotiable rules. First, it verifies the HMAC signature of every request: without it, anyone can fake a "payment confirmed". Then, it stores each transaction reference and refuses to process it twice (idempotency). It responds 200 immediately then processes asynchronously via a queue, so the operator never treats the event as failed. Finally, it tolerates retries: the operator resends the event several times, and your code must stay consistent.
| Rule | Why | Impact if missing |
|---|---|---|
| HMAC signature check | Security | Fake payments injected |
| Idempotency by reference | Anti-duplicate | Duplicated orders 1-3 % |
| Fast 200 response (< 5 s) | Avoid useless retry | Events replayed in loop |
| Asynchronous queue | Absorb spikes | Timeouts, lost events |
| 5 retries over 24 h | Catch outages | Orders lost during downtime |
| Full logging | Audit / reconciliation | Untraceable disputes |
Mini case study
Wanjiru, founder of an online grocery in Nairobi, handles 700 orders/month, average basket 25,000 FCFA, i.e. 17,500,000 FCFA revenue. With her old polling system, she lost 2.5 % of orders (event missed during a server restart): 17-18 orders/month, i.e. about 437,500 FCFA lost. Worse, 1.5 % were duplicated, generating customer disputes and refunds. After migrating to an idempotent signed webhook with a queue and 5 retries, loss drops to 0.3 % (2 orders, ~52,500 FCFA) and duplicates disappear. Net gain: around 385,000 FCFA/month plus the end of disputes, on infrastructure half as expensive.
FAQ
Need a professional website?
Kolonell builds websites that attract clients, optimized for the Sénégalese market. Free quote in 2 minutes.
What is idempotency, concretely?
It guarantees that the same event processed several times produces the same result as processing it once. In practice: you store the transaction reference and, if it returns, you ignore the duplicate. Without it, 1 to 3 % of orders duplicate.
Why verify the webhook signature?
Because an unprotected public endpoint can receive fake "payment confirmed" events and trigger deliveries without a real payment. HMAC verification guarantees the event truly comes from the operator. It is non-negotiable in 2026.
How many times should a failed webhook be retried?
The recommended practice is 5 attempts spread over 24 h with exponential backoff. This covers short outages (restart, deployment) without hammering a permanently dead endpoint. Beyond that, a manual alert takes over.
Polling or webhook if I'm starting out?
Start with the signed webhook: it's more reliable and cheaper to run. Keep polling as a safety net to reconcile the rare lost events, not as the main mechanism.
How much does webhook downtime cost?
Enormous: during a payment-processing outage, 100 % of your sales fail to confirm. That's precisely why the queue with retries is indispensable: it catches orders as soon as the service returns.
Let's talk about your project. We audit your payment webhook and make it idempotent, signed and resilient so you never lose an order again. 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.