The verdict in three sentences
An untested webhook is a time bomb: it works in demo, then in production it misses an event and the customer pays without the order confirming. The 2026 target is clear: under 0.1% lost events and an alert in under 5 minutes on any unprocessed event. You reach it with a test plan covering replay, failure, signature and monitoring, from sandbox to production.
The 12 test cases before going live
A payment webhook must survive the unexpected: an event received twice, out of order, with an invalid signature, or while your server restarts. Each case has a precise expected result.
| # | Test scenario | Expected result |
|---|---|---|
| 1 | Standard SUCCESS event | Order confirmed |
| 2 | Same event received twice (duplicate) | Processed once (idempotency) |
| 3 | Invalid signature | Rejected, 401, alert |
| 4 | FAILED event | Order marked failed |
| 5 | Event received out of order | Coherent final state |
| 6 | Server down during delivery | Automatic replay succeeds |
| 7 | Malformed payload | Cleanly rejected, logged |
| 8 | Event for unknown order | Queued / reconciliation |
| 9 | Latency > 10s server-side | No loss, operator retry |
| 10 | Refund (REFUND) | Status updated |
| 11 | Volume: 100 events in a burst | None lost |
| 12 | Sandbox to prod switch | Correct keys and URLs |
Alert SLA and tolerated lost-event rate
In production what matters is knowing fast when an event wasn't processed. Passive monitoring isn't enough; you need an active alert and a reconciliation dashboard.
| Indicator | 2026 target | Consequence if exceeded |
|---|---|---|
| Lost events | < 0.1% | Paid orders unconfirmed |
| Alert delay on unprocessed event | < 5 min | Customer without confirmation, dispute |
| Mishandled duplicate rate | 0% | Double confirmation / double stock |
| Legitimate signatures rejected | 0% | Real payments blocked |
| Reconciliation delay | < 24h | Cash / order mismatch |
A daily reconciliation job compares your orders to aggregator transactions: any gap becomes a task to handle, not a silent loss.
Mini case study
David launches a store in Lagos, 600 orders/month. Without idempotency, 1.5% of events arrived duplicated and confirmed the order twice: 9 orders/month in stock disputes, ~45,000 FCFA in lost margin and support time. After the 12-test plan and adding idempotency, the rate drops to 0% duplicates and < 0.1% lost events. Cost: ~150,000 FCFA of dev one-off, against a recurring source of disputes eliminated.
FAQ
Need a professional website?
Kolonell builds websites that attract clients, optimized for the Sénégalese market. Free quote in 2 minutes.
Why does a webhook that works in sandbox fail in production?
Because production adds volume, network latency and real duplicate or out-of-order events. Edge cases that never show in demo become daily in production.
What is idempotency and why is it critical?
It's processing the same event only once, even if received multiple times. Without it, a duplicate confirms the order twice; the target is 0% mishandled duplicates.
How do I know an event was lost?
With a daily reconciliation job comparing orders and aggregator transactions, plus an alert in under 5 minutes on any unprocessed event.
Should I verify the signature of every webhook?
Yes, systematically: an invalid signature must return 401 and trigger an alert. It's the first defence against injected fake events.
What lost-event rate is acceptable?
Under 0.1%, and every missing event must be caught by reconciliation within 24h. Zero silent loss is the goal.
Let's talk about your project. We build your webhooks with idempotency, signature verification, replay and alert monitoring under 5 min. 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.
