The verdict in three sentences
In mobile money payments the webhook is the truth of your order — and it is fallible. Without an idempotency key, a replayed event creates a double order; without signature verification, you accept fake payments; without a polling fallback, a lost webhook makes you miss a sale that was actually paid. Reliability rests on three pillars: idempotency, signature, reconciliation.
Naive handler or idempotent processing: what's the difference?
A naive handler processes the event inline, trusts the payload and has no replay protection. Robust processing verifies, queues, and makes the operation replay-safe with no side effects.
| Criterion | Naive handler | Idempotent processing |
|---|---|---|
| Signature verification | absent | mandatory |
| Duplicates | ~1.2% of orders | ~0% |
| Provider retries | ignored | 5 attempts, exponential backoff |
| Lost events | missed sale | recovered via 60s polling |
| Processing budget | unbounded | 5s max, else 200 + async |
| Persistent failures | lost | dead-letter queue |
The golden rule: reply 200 immediately, queue the event, then process asynchronously and idempotently. A provider that doesn't get its 200 within seconds retries — hence the duplicates.
What figures should you target in 2026?
These orders of magnitude guide the sizing of a reliable webhook pipeline for Wave, Paystack and M-Pesa.
| Metric | 2026 target / value |
|---|---|
| Webhook retry rate | 3-8% of events |
| Duplicates without idempotency key | ~1.2% |
| Backoff attempts | 5 (e.g. 1s, 2s, 4s, 8s, 16s) |
| Polling fallback frequency | every 60s |
| Processing budget per event | 5s |
| Order confirmation | only on verified event |
| Dead-letter queue | after 5 failures |
The order is confirmed only on a verified event (valid signature + success status), never on the customer's browser redirect alone, which is trivially spoofed.
Mini case study
Moussa, a developer for a Nairobi shop, was seeing 1.2% double orders: on 5,000 payments a month that meant 60 phantom orders to clean up by hand, about 5 hours of support. He adds an idempotency key based on the provider transaction ID and a queue with a dead-letter queue. Duplicates drop to zero. Polling every 60s also recovers the 4% of lost webhooks — roughly 200 sales a month previously confirmed late, now closed automatically.
Need a professional website?
Kolonell builds websites that attract clients, optimized for the Sénégalese market. Free quote in 2 minutes.
FAQ
What is an idempotency key in practice?
A unique identifier (often the provider transaction ID) you store before processing. If the same one arrives twice, you ignore the second: zero double orders, even on replay.
Why verify the webhook signature?
Because without it, anyone can post a fake "payment succeeded" event and trigger an unpaid delivery. Signature verification is non-negotiable in 2026.
Does polling replace webhooks?
No, it complements them. The webhook gives the instant signal; polling every 60s recovers the 3-8% of lost or delayed events. Together they deliver reliability.
What do you do with an event that fails 5 times?
You send it to a dead-letter queue for manual inspection rather than retrying forever. That isolates pathological cases without blocking the normal flow.
Become a Kolonell referral partner. Know an online merchant losing payments for lack of reliable webhooks? Refer them: the referral commission is 12% on e-commerce, 15% + 5% recurring on a showcase site, 10% on a marketplace and 8% on institutional work.
Let's talk about your project. We build an idempotent, signed and reconciled webhook pipeline, tested with real payments. 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.
