Integrating Flutterwave Webhooks Into a Ghana Store in 2026

The verdict in three sentences

The Flutterwave API sends a charge.completed event carrying a secret hash in the verif-hash header that you must compare to your secret key before delivering. Without idempotency and a replay-safe endpoint, a dropped webhook on an unstable network leaves the order pending. This guide covers the tx_ref reference, secret hash verification and network recovery, with a comparison against MTN MoMo Collections in Cameroon.

Setup, secret hash and verification

The Flutterwave flow starts in the dashboard: you generate your secret key and set a secret hash used to sign webhooks. On checkout you initialize a transaction with the amount, currency GHS and a unique tx_ref (your order reference). When the customer pays, Flutterwave posts a charge.completed event to your webhook URL, with the verif-hash header set to your secret hash.

The critical point: compare the incoming verif-hash to your stored secret hash before trusting the event, and always re-verify the transaction via the API before fulfilling.

Always re-verify the amount and status via GET /transactions/:id/verify before delivering: the webhook is a trigger, not proof of payment on its own.

Network recovery and MTN MoMo comparison

On Ghana's mobile networks a webhook can be dropped. Flutterwave replays failed webhooks, so your endpoint must be idempotent: store the transaction id and respond 200 OK if already processed. Let's compare with MTN MoMo Collections in Cameroon, which uses polling instead of a signed webhook.

In Cameroon, MTN MoMo requires you to actively poll the RequestToPay status (PENDING then SUCCESSFUL), whereas Flutterwave pushes a signed webhook. One is push, the other is pull.

Mini case study

Kwame runs a phone-accessory store in Accra (Osu). With webhook handling but no idempotency, 5% of his 220 monthly orders were processed twice or left pending after network drops, i.e. 11 orders. By storing the transaction id, verifying the secret hash and re-verifying via the API, the error rate falls to 0.5%, about one order per month. On an average basket of GHS 220 equivalent, he recovers roughly 10 x 220 = GHS 2,200 of previously lost or duplicated collections each month.

FAQ

Why re-verify the transaction if the webhook already fired? Because the webhook is only a trigger. A GET /transactions/:id/verify confirms the real amount and status, blocking forged or tampered events.

What does the secret hash protect against? It ensures the charge.completed event genuinely comes from Flutterwave. If the verif-hash header doesn't match your stored secret hash, reject the event outright.

How do I handle a dropped webhook on a bad network? Flutterwave replays failed deliveries, so make your endpoint idempotent via the transaction id. A reconciliation cron every 15 minutes catches anything still missing.

What's the difference with MTN MoMo? MTN requires active polling of RequestToPay status using an UUID reference, while Flutterwave pushes a signed webhook. Push versus pull.

How much does a Flutterwave integration cost? 2026 ballpark: GHS 350,000 to 600,000 equivalent depending on complexity, excluding Flutterwave fees of ~1.4% per local transaction.

Let's talk about your project. We integrate Flutterwave, Wave and MTN MoMo with signed webhooks, idempotency and network recovery. WhatsApp +221 77 596 93 33.