Handle MoMo callback timeouts in Lagos without losing orders in 2026

The verdict in three sentences

A timeout is not a failure: in 2026, 6% of mobile money payments confirm *after* the HTTP connection expires. If you cancel the order at the timeout, you destroy up to 5.4% of your revenue in orders that were actually paid. The right response: a grace period of 30 min during which you query the real status before any cancellation.

Timeout vs failure: the distinction that saves revenue

When you initiate a payment, the customer enters their PIN on their phone. That human gesture can take longer than your HTTP timeout. The connection drops, but the transaction completes on the operator's side a few seconds later.

Canceling on the timeout alone treats the first 3 rows like row 3. Result: 6% false negatives, of which 5.4% are truly collected payments — money received on a canceled order, a reconciliation nightmare.

Active polling: respect the rate limit

The fix is to query the mobile money "status query" endpoint. But it is limited to 1 request every 5s: aggressive polling gets blocked. You need backoff.

On each attempt, if the status is SUCCESS you confirm (idempotent processing); if FAILED you cancel; if PENDING you continue. Past the 30-min reconciliation window without confirmation, you cancel cleanly and notify the customer. This scheme respects the 1 req/5s limit while recovering most of the 6% late confirmations.

Mini case study

Fatoumata runs a cooperative's online store in Lagos, ~200 mobile money payments/day. Her old system canceled at the HTTP timeout (8s). She lost 6% of payments as false negatives, i.e. 12 orders/day, of which ~10.8 were actually paid (5.4%). Each ghost order (paid but canceled) triggered a support ticket at 12,000 FCFA handling cost: ~10.8 × 12,000 = 129,600 FCFA/day of friction, not counting lost revenue from customers who never came back.

After setting up polling with backoff and a 30-min grace period, 95% of these late confirmations are recovered automatically. Ghost orders drop from 10.8 to ~0.5/day: friction saving ~123,600 FCFA/day and secured revenue.

FAQ

Why not just extend the HTTP timeout to 60s? Because you would block a thread/server for 60s per payment, saturating your resources at peak hours. Better to time out fast (8-10s) and switch to asynchronous polling that ties up nothing.

Does the customer have to wait on screen during polling? No. Show "payment being verified" and confirm by notification/email as soon as the status flips. Polling runs server-side, independent of the customer's session.

What do I do if the status stays PENDING after 30 min? Cancel the order cleanly and tell the customer they can retry. In parallel, keep the transaction in your daily reconciliation queue: if the operator confirms it later, you will catch the orphan collection.

Does the 1 req/5s limit apply per transaction or globally? Usually per merchant account. With 200 potentially simultaneous payments, put a queue with controlled throughput on the worker side so you do not exceed the global quota and avoid throttling.

How do I become a Kolonell referral partner? Introduce us to a merchant losing orders on timeouts: on signature you earn 12% e-commerce, 10% marketplace, 8% institutional and 15% + 5% recurring on a showcase site. A 3,000,000 FCFA project earns you 360,000 FCFA.

Let's talk about your project. We secure your mobile money callbacks and recover your ghost orders. WhatsApp +221 77 596 93 33.