Bulletproof Paystack Webhooks: Payment Reconciliation in Nigeria 2026

The verdict in three sentences

A lost webhook means an order the customer paid for but that your system never confirmed: the worst e-commerce scenario. The fix is not to hope the provider delivers perfectly, but to combine an HMAC signature, scheduled retries and active reconciliation via the status API. With that trio, you move from a 2-4% loss rate to near-100% coverage.

Why a webhook alone is never enough

A webhook is an HTTP request the payment provider sends to your server when a payment changes state. The problem: that request can fail for a thousand reasons (server briefly down, network timeout, deployment in progress, load spike). Without a backup strategy, every failure is an orphaned payment.

Here are the orders of magnitude observed in 2026 on West African mobile money integrations:

The lesson: the webhook is the fast channel, but it must always have a backup.

The HMAC signature: reject anything not from the provider

Before processing a webhook, verify its signature. The provider signs each payload with a shared secret (HMAC-SHA256). You recompute the signature on your side and compare: if it does not match, you reject the request with a 401. This blocks fake-payment attempts injected by an attacker who guessed your URL.

Golden rule: never trust the amount in the webhook alone. Always cross-check against the order in your database (amount, merchant reference, currency) before marking the order as paid.

Retries and fallback polling: belt and braces

Two complementary mechanisms secure collection:

In practice: if a webhook never arrived after 10 minutes, your server itself queries the provider API to learn the real transaction state. This is the safety net that catches the 2-4% of lost webhooks.

Mini case study

Awa runs a cosmetics shop in Lagos that processes 900 orders per month at an average basket of 18,000 FCFA (about 27,000 NGN), roughly 16,200,000 FCFA in monthly revenue. Without retry or polling, she loses on average 3% of confirmations, meaning 27 orders that are not confirmed automatically each month.

Those 27 orders represent about 486,000 FCFA stuck in "pending": customers wrongly chased, support time burned, sometimes refunds issued in error. By enabling status polling every 10 minutes and T+1 reconciliation, Awa cuts unconfirmed orders to fewer than 1 per month. Net gain: about 470,000 FCFA of secured revenue every month and 6 hours of support time saved.

FAQ

How many webhooks are really lost without retries?

Between 2% and 4% based on our 2026 observations on West African mobile money. On 1,000 orders that is 20 to 40 orphaned payments per month, more than enough to justify a fallback.

How often should I poll the API?

Every 10 minutes, with a maximum of 6 attempts (a 1-hour window). Beyond that, the transaction moves to daily T+1 reconciliation rather than needlessly exhausting the API.

Does the HMAC signature slow down processing?

No. The HMAC-SHA256 computation takes under 1 ms. It is negligible next to the 3 to 8 seconds of network latency of the webhook itself, and the security gain is huge.

What do I do with a "pending" status that never changes?

About 1.5% of transactions stay stuck in false "pending". The rule: after 60 minutes, treat the payment as failed following one last status check, and release the reserved stock.

Is daily reconciliation really needed if I already poll?

Yes. Polling catches the immediate cases, T+1 reconciliation catches the residual ones (fees, refunds, amount mismatches) and gives you a clean accounting audit trail.

Let's talk about your project. We integrate payments with HMAC signature verification, retries and active reconciliation so you never lose a payment again. WhatsApp +221 77 596 93 33.