Flutterwave webhook retry & timeout: build a resilient queue (Accra, 2026)

The verdict in three sentences

A slow mobile money payment is not a lost payment: USSD sessions can hang for tens of seconds, and at peak hours the transient failure rate climbs to 4-8%. The answer is not to retry instantly — it is an exponential backoff (5s, 15s, 45s) paired with a dead-letter queue for unrecoverable cases. Every retry must stay idempotent so you never double-charge.

Distinguish transient from permanent failures

A transient failure (network, saturated operator, USSD timeout) can be replayed. A permanent failure (insufficient balance, wrong PIN, limit exceeded) must never be replayed — you would waste time and risk duplicates. Classify first, retry second.

Exponential backoff in practice

Instead of hammering the API, space attempts by 2^n. This gives the operator time to recover and avoids getting rate-limited.

After 4 to 5 failed attempts, the event moves to a dead-letter queue for manual or deferred handling. Nothing is lost silently.

Queue and idempotency

A queue (SQS or equivalent) decouples receipt from processing: acknowledge fast, then replay at your own pace. Each message carries an idempotency key (via the idempotency-key header and verified verif-hash signature), so even if a payment finally succeeds after three retries, it is credited only once.

Mini case study

Kwame, who runs an online grocery in Accra, processes 1,100 Flutterwave payments a month. At peak (6pm-9pm), 6% fail transiently — that is 66 payments. Without retries he loses those sales: at a GHS 95 average basket, that is GHS 6,270 a month. With an exponential backoff recovering 80% of transient failures, he saves GHS 5,016 a month, roughly GHS 60,000 a year. The queue took 1.5 dev days.

FAQ

Why not retry a failed payment immediately?

An instant retry usually hits the same saturation and can get you rate-limited. Exponential backoff (5s, 15s, 45s) lets the system recover and raises the success rate of later attempts.

What is a dead-letter queue?

A secondary queue where payments land after 4-5 failures. They are kept there for analysis or manual handling instead of being lost silently.

How do I verify a Flutterwave webhook?

Check the verif-hash header against your secret before processing, and reject anything that does not match. Combine that with an idempotency key so retries stay safe.

Can retries double-charge the customer?

Not if each attempt carries an idempotency key and you check a dedup table before crediting. That is the essential condition for replaying safely.

Let's talk about your project. We design payment queues with backoff, a dead-letter queue and tested idempotency. WhatsApp +221 77 596 93 33.