Most teams design the moment money is sent, and the moment it arrives. Almost nobody designs the gap in between. That gap, the pending state, is where trust in a payment product is actually won or lost.
Think about what a person is doing while a transfer sits on “pending.” They are not browsing. They have just parted with money that may represent a meaningful share of what they have, and they are waiting to find out whether it worked. Every second without a clear answer is a second of quiet anxiety. Did it go through? Did it fail and take my money with it? Should I try again, or will that send it twice? The interface has stopped talking, exactly when the person most needs it to.
This is the design failure hiding in plain sight. We pour attention into the confirmation screen, the celebratory tick, the receipt. Those are the easy, pleasant moments. The pending state is unglamorous, uncertain and often owned by nobody on the team, so it gets a spinner and a shrug. But the spinner is a decision. It says: we have nothing to tell you, and we are not going to pretend otherwise. For a person watching their money, that silence reads as the system not being in control.
In African markets the stakes are sharper, because the pending state is rarely short and rarely simple. A transfer can cross networks, wallets, agents and banks before it settles. Connectivity drops halfway through. A confirmation SMS arrives ten minutes late, or never. The “pending” is not a technical formality that resolves in two seconds; it can be a genuine period of not knowing, sometimes long enough for a person to give up, call support, or send the money a second time out of fear the first one vanished. Every one of those outcomes is more expensive than the design work that would have prevented it.
So what does a good pending state actually do? It answers three questions, continuously, without being asked. What is happening right now. Whether my money is safe while it happens. And what I should do, including the reassurance that doing nothing is safe.
The sentence that removes the fear
“Payment sent, waiting for the recipient’s bank to confirm, this can take up to two minutes, your money is secure and you do not need to try again” is not hard to write. It is just rarely treated as something worth writing. That single, specific sentence removes the exact fears driving the double-payment and the panicked support call.
A good pending state also has honest edges. It tells the truth about time, a real estimate, not an optimistic one, and it says what happens when that time is exceeded. It distinguishes between “still processing” and “we have lost contact and are checking,” because those are different situations and collapsing them into one spinner is how people end up stranded. And it never leaves the person without a next step: a way to check status, a way to reach a human with the transaction already in context, a clear statement of where the money sits right now.
None of this is exotic engineering. It is mostly copy, state design and the discipline to treat the in-between as a real part of the journey rather than dead air between the parts that felt worth designing. The teams that get it right are not the ones with the fanciest confirmation animation. They are the ones who decided that the two minutes a person spends not knowing were worth designing at all.
If your product moves money, look at your pending state the way your users do: as the moment they find out whether they can trust you. Then ask whether it is currently saying anything at all.
The spinner is a decision. It says: we have nothing to tell you. For a person watching their money, that silence reads as the system not being in control.
AfriUX designs and builds complex digital systems for African markets, with a focus on the moments where trust is won, lost or repaired. If money movement is one of your high-stakes journeys, a Trust Audit is a good place to start.
