The verdict in three sentences
A phantom order — paid but never confirmed, or confirmed twice — almost always comes from a mishandled webhook. The right 2026 architecture rests on three pillars: HMAC signature verification, a mandatory idempotency key, and an HTTP 200 response in under 10 seconds. Polling should only be a safety net, never the primary mechanism.
Polling vs signed webhook
Polling queries the Wave API at regular intervals to learn a payment's status. Simple to write, but slow, call-heavy and fragile under load. The signed webhook is pushed by Wave the moment state changes: faster, more reliable, but it demands real security and deduplication discipline.
| Criterion | Polling | Signed webhook |
|---|---|---|
| Confirmation latency | 5 – 60 s | < 3 s |
| Server load | High (repeated calls) | Low (push) |
| Duplicate risk | Low | 2 – 4% to deduplicate |
| Security | API token | HMAC signature |
| Failure resilience | Resumes on wake | Retries up to 24 h |
| 2026 recommendation | Safety net | Primary mechanism |
In practice you combine both: webhook for responsiveness, hourly reconciliation polling to catch missed events.
The non-negotiable reliability rules
Wave resends a webhook until it receives a 200. Without idempotency, one payment can therefore trigger business logic several times — double dispatch, double stock decrement. An idempotency key (often the event_id) stored in your database blocks these replays.
| Reliability parameter | 2026 value |
|---|---|
| Retry duration | Up to 24 hours |
| Recommended response timeout | 10 seconds |
| Duplicate webhook rate | 2% to 4% |
| Signature verification | HMAC required |
| Log retention | 90 days |
| Expected success code | HTTP 200 |
Golden rule: return 200 immediately after recording the event, then run heavy logic in the background. A slow synchronous handler causes a timeout, hence a retry, hence a duplicate.
Mini case study
Ibrahim, a restaurateur in Dakar, takes 400 Wave orders a month. At a 3% duplicate rate, that is 12 duplicated events monthly. Without idempotency, 12 customers risked a logical double charge or double preparation. By storing the event_id and rejecting replays, he reaches zero phantom orders and saves the support time he valued at 2 hours a week.
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 I receive the same webhook several times?
Because Wave resends the event until it gets an HTTP 200, and sometimes through network redundancy. In 2026, expect 2 to 4% duplicates: an idempotency key on the event_id neutralizes them.
How long does Wave retry?
Retries spread over up to 24 hours with a growing interval. Your endpoint must therefore stay idempotent over that whole window, not just a few minutes.
Must I verify the webhook signature?
Yes, every time. HMAC verification guarantees the request truly comes from Wave and not an attacker faking a successful payment. An unsigned or badly signed webhook must be rejected.
What timeout should I set?
Respond in under 10 seconds. Record the event, return 200, then process asynchronously: a slow synchronous handler triggers a timeout and thus a duplicate.
How long should I keep logs?
At least 90 days. That covers disputes, reconciliation and payment audits without overloading your storage.
Let's talk about your project. We harden your Wave webhooks — signature, idempotency, reconciliation — for zero phantom orders. 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.
