A transaction should never stay pending

Ask anyone who has sold airtime in Nigeria what they hate most about their provider, and they will not say the price. They will say pending. A customer pays, the dashboard says pending, and nobody can tell them whether the credit landed. The vendor refunds to keep the peace, the network delivers an hour later, and the vendor has now paid twice for one top-up.

Pending is not really a state. It is the absence of an answer, dressed up as one. So the question is not how to display it nicely. It is how to stop it lasting.

Three things have to be true

• Every request has a deadline. A channel that has not answered by then is not waiting, it has failed, and the next channel gets the request inside the same call.
• Every unresolved transaction is actively chased. A reconciliation job queries the channel for a final state on a schedule that gets slower but never stops.
• Money is never in limbo. The wallet hold stays until there is an answer, so an unresolved transaction is money you have not spent rather than money you have lost.

The third one is what makes the first two safe. Because a hold is not a debit, we can afford to wait for the truth instead of guessing at it. Nothing settles until a channel confirms delivery, and nothing is released until a channel confirms failure.

What a vendor sees

A transaction that is still being chased shows exactly that, with the number of attempts and when the next one runs. It is not called pending, because pending tells you nothing. Anything reconciliation genuinely cannot settle goes to manual review with the hold intact, and we work it ourselves rather than waiting for a complaint.

You should never be charged for an outcome nobody can establish.

That is the whole rule. Everything above is just the machinery that makes it true.