Paystack webhooks: reliable payment confirmation in 2026

The verdict in three sentences

A customer can close the tab, lose signal, or return to your page without having paid: the browser redirect is never proof of payment. The single source of truth is the signed webhook sent by Wave or Paystack straight to your server, verified with an HMAC-SHA256 signature. Accept the webhook into a queue, return 200 in under 5 seconds, then process the order asynchronously.

Why the browser redirect lies

The redirect_url is for user experience, not accounting. Three scenarios break client-side validation: the customer pays but never returns (3G drop), the customer returns without having paid (back button), or a bot replays the success URL. The webhook, in contrast, travels from the payment server to yours, independent of the browser.

The webhook + queue architecture

The winning pattern in 2026 is five steps: receive, verify the signature, deduplicate by event_id, return 200 immediately, process in the background. If processing fails, Wave and Paystack replay the event — hence the need for idempotency.

Golden rule: compute the signature over the raw request body, not the re-parsed JSON object — a single space or a different key order invalidates the hash.

Mini case study

Awa, who runs a cosmetics shop in Dakar, handled 320 orders/month via Wave and confirmed on the browser redirect. The result: 11 phantom orders/month (customers gone before paying) and 4 disputes. After switching to signed webhook + queue, she drops to 0 phantom orders. On an average basket of 18,000 FCFA, she regains certainty over 320 × 18,000 = 5,760,000 FCFA/month of flow, never again shipping an unpaid order.

FAQ

Must I verify the signature on every webhook? Yes, without exception. An unsigned webhook or one with an invalid signature must be rejected with a 401 and never processed. It is the only barrier against an attacker faking a charge.success.

What if my server is slow? Return 200 in under 5 seconds after merely enqueuing the event. Do no heavy work (email, stock update) before the 200, or the provider treats the call as failed and replays up to 5 times.

What about a duplicate event? Deduplicate by event_id with a 72 h TTL: if the ID was already processed, return 200 and do nothing. Roughly 0.5 to 2 % of webhooks are legitimate replays.

Can the webhook arrive before the browser redirect? Yes, very often. Your success page must query the real order state, not assume it is paid because the user came back.

How do I test locally? Use a tunnel (like ngrok) and the Paystack/Wave dashboard replay tool to resend a real charge.success, then verify the signature with your test key.

Let's talk about your project. We wire your Wave and Paystack webhooks with verified signatures, a queue and idempotency, tested end to end. WhatsApp +221 77 596 93 33.