Failed Mobile Money Transaction Retry Logic in Accra: Idempotency & States (2026)

The verdict in three sentences

Retry is essential, but done wrong it is worse than the failure: without an idempotency key, every retry risks charging the customer a second time. The right architecture rests on three pillars: an idempotency key per payment intent, an explicit state machine, and status polling before any retry. Implemented correctly, it drops double-charges from 2.1% to 0.05% without losing slow payments.

The idempotency key, first reflex

An idempotency key is a unique identifier attached to the customer's payment intent (not to the attempt). Every retry of the same payment carries the same key. The operator and your server can then recognise it as the same transaction and not replay it.

Without this key, a customer who reloads the page or whose network resends the request gets charged twice. With it, the second request simply returns the result of the first.

The state machine

Each payment follows a strict lifecycle. You never retry a payment already in a final state (success or reversed). You only poll intermediate states.

This discipline prevents 90% of incidents: most double-charges come from a retry launched while the payment was still pending.

Timeout window and polling frequency per operator

Each operator has its own confirmation window. Polling too early or retrying before timeout creates duplicates; waiting too long hurts the customer experience. Here are the 2026 orders of magnitude.

Rule: never retry before exceeding the operator's timeout window and confirming via polling that the state is genuinely failed.

Mini case study

Ama runs a meal-delivery service in Accra, 2,500 transactions/month via MTN MoMo and a second rail. Before, her double-charge rate reached 2.1%, about 52 customers a month charged twice, each claiming a refund of GHS 25 on average: roughly GHS 1,300 to refund and a swamped support desk. After adding the idempotency key, the state machine and 5-second polling, the rate drops to 0.05%, or 1 to 2 cases a month. She saves about GHS 1,250/month and, more importantly, protects the reputation that hinged on these incidents.

FAQ

Where should the idempotency key be generated?

When the customer confirms their intent to pay, not on each attempt. Every retry of that payment reuses the same key, client-side and server-side.

When can I safely retry a payment?

Only after exceeding the operator's timeout window (60 to 120 s depending on the case) and confirming via polling that the state is failed. Never on a pending state.

Isn't polling every 5 seconds too much?

No, it is the standard frequency and stays lightweight. The key is to stop polling as soon as the state is final so you do not load the system needlessly.

What about a payment stuck pending too long?

Beyond the operator's window, mark it failed and offer the customer a fresh payment with a new key, after verifying no charge occurred.

Does idempotency also apply to refunds?

Yes, exactly the same way: a unique key per refund prevents refunding twice when the payout operation is retried.

Let's talk about your project. We design your retry logic with idempotency and a state machine to eliminate double-charges. WhatsApp +221 77 596 93 33.