The verdict in three sentences
Payment providers deliberately resend the same webhook (3 to 6 occurrences) to guarantee delivery, which exposes any naive integration to double-counting. The fix isn't trusting arrival order but placing an idempotency key and a deduplication table with a TTL. In 2026, 4-9% of events are duplicates — at an average ticket of 12,000-45,000 FCFA, every avoided double-credit is real money saved.
Webhook behavior by provider (2026)
2026 ballpark figures to size your processing queue.
| Provider | Same-event resends | Retry window | Signature | Duplicate rate |
|---|---|---|---|---|
| Paystack | 3-5 | 24-48 h | HMAC | 4-7 % |
| Flutterwave | 3-6 | 48-72 h | HMAC/hash | 5-9 % |
| MTN MoMo | 3-6 | 24-72 h | HMAC | 4-8 % |
| Wave | 3-5 | 24-48 h | HMAC | 4-7 % |
| Aggregator PSP | 2-4 | 24 h | HMAC | 3-5 % |
Remember: verifying the HMAC signature must take under 200 ms, and the retry window demands a dedup table whose TTL covers 30-90 days to absorb late retries.
Key by event_id or by order reference?
The idempotency key choice determines robustness. 2026 comparison.
| Criterion | Key by event_id | Key by order reference |
|---|---|---|
| Blocks identical retries | yes | yes |
| Blocks distinct events of same order | no | yes (beware legit ones) |
| Partial refund handling | easy | tricky |
| False-positive risk | low | medium |
| Dedup table TTL | 30-90 days | 30-90 days |
| Recommended for | payment status | stock reservation |
The 2026 best practice: key by event_id for raw webhook deduplication, complemented by a logical lock on the order reference for the business effect (credit, ship). Never conflate the two roles.
Mini case study
David runs an online store in Accra: 400 orders/day, average ticket 300 GHS. Flutterwave resends each webhook ~4 times, with 7% duplicates unfiltered at the start. Without idempotency, ~28 orders/day risked a double-credit or double-shipment, exposing ~8,400 GHS/day of value. After deploying a dedup table (event_id key, 60-day TTL) and a per-reference lock, the double-processing rate drops to zero. Cost of the incident avoided over a month: substantial dispute and wrongly-shipped stock losses.
Need a professional website?
Kolonell builds websites that attract clients, optimized for the Sénégalese market. Free quote in 2 minutes.
FAQ
Why do providers resend the same webhook?
To guarantee "at least once" delivery: if your server doesn't return 200 fast enough, they replay the event 3-6 times over 24-72 hours. It's normal behavior to absorb, not a bug.
Which idempotency key should I choose?
An event_id key for webhook deduplication, plus an order-reference lock for the business effect. This separation avoids both technical duplicates and double-credits.
How long should I keep the dedup table?
A TTL of 30-90 days covers the latest retries. Below 30 days, a late Flutterwave/MoMo retry (window up to 72 h plus exceptional replays) can slip through.
Must I verify the HMAC signature every time?
Yes, always, in under 200 ms. An unsigned or invalid-signature webhook must be rejected before it even enters the dedup queue.
How do I handle a partial refund without breaking idempotency?
Treat the refund as a distinct event with its own event_id, and apply the business effect through the order-reference lock. Never reuse the original payment's key.
Let's talk about your project. We design your Paystack, Flutterwave and MoMo webhooks with guaranteed idempotency and zero double-credit. 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.
