Payment Resolution (2026)
One resolution case for stuck payments in Nigeria and India, so the customer, payments ops and support all see the same truth about where the money is.
Client
Self-initiated concept
Role
Product designer, solo: research, PRD, Figma, prototype, testing
Timeline
5-day sprint
Platform
Mobile app · Ops console · Support inbox
TL;DR
When a transfer fails, the money leaves your account and the app just says "Pending": people can't tell whether it arrived, whether it's coming back, or whether to pay again. I designed one resolution case behind three views: a customer tracker that answers "should I pay again?", an ops console that won't reverse a payment that already landed, and a support inbox that reads the same facts. In testing, 8 of 10 customers chose to wait rather than pay again, and the one who would have paid twice is the first thing I'd fix.
“How am I supposed to know whether I should pay again?”
Paytm user, 1-star Google Play review
The Challenge
What needed solving.
That review is the whole problem. Across Google Play reviews from six storefronts, the same patterns kept coming up: transfers stuck on "Pending" for days, disputes that went quiet for almost a month, and support agents who could only reply with templates because they couldn't see the case.
The rules make it urgent. In India, a failed UPI payment must be reversed by T+1, then ₹100 a day is owed automatically. In Nigeria, banks face a ₦10,000 sanction per failed NIP transfer not reversed in 24h (a secondary source; I mark it that way in the product too).
The Approach
How I solved it.
The institution usually knows more than the customer. It's re-querying the rail, reconciling settlement, preparing a reversal. None of that reaches the customer or the support agent, and that gap is what makes people pay twice, contact support again and again, and push for refunds that can go wrong.
So instead of a support ticket, every ambiguous debit opens one resolution case, and each person reads the part they need.
Key Insights
What I found.
01 — Finding
Customers need a decision, not a status
The reviews weren't asking "what stage is this?" They were asking "what should I do?"
What I did about it
Unknown is a state, not a failure. Most apps flatten uncertainty into "Failed" or leave it as "Pending". I made "we don't know yet" its own state. The customer sees "Checking with their bank", when the next update is due, and the latest time the money comes back if it didn't go through.
"Should I pay again?" is its own decision. The easy option was to read the advice off the progress step. I didn't, because the two can disagree: the tracker can say "Returning your money" while paying again would still send the money twice, until the ledger confirms the return. So the advice is decided separately, and "Safe to pay again" only appears once the money is back, with a push notification to say so. In prioritization it scored as a Quick Win, so I built the simplest form: a card of its own above the tracker.
The rules show up on the screen. For UPI payments in India, the RBI rule becomes a line the customer can read: compensation owed so far, ₹100 for each day past the deadline, paid automatically with no claim needed. That turns a compliance footnote into a reason not to chase support.
02 — From the payment rules
The dangerous moment is a late credit
This one didn't come from the reviews. It came from how failed transfers resolve: if a payment marked failed actually lands, an automatic reversal pays the money twice.
What I did about it
Safety beats automation. I designed the queue around deadline risk and the case panel around evidence. Before any reversal, a final check looks for a late credit. If the recipient was credited after all, the reversal is blocked, and the analyst gets two safe options: mark it delivered, or send it to manual review.
Reversals of 500,000 naira or 40,000 rupees and above need a second person, and the person who prepared one can't approve it.
03 — Finding
Support is a dead end because it's blind
The template replies in the reviews come from agents with nothing to look at.
What I did about it
Support reads from the same case. Agents see the facts ops sees, and a reply template fills from them, so it can't promise anything the case doesn't support.
I chose state-based templates over AI drafting, because the reviews showed people already distrust AI support replies.
Process
How I worked through it.
01
Evidence from real complaints
First-hand 1-star Google Play reviews, read in each app's home storefront, plus the regulator rules that set the clocks. I noted the gaps too: I aimed for 10 voices beyond Nigeria and found 6 that fit.
02
PRD, state table and hard cuts
I wrote the PRD and a canonical state machine, then scored every candidate feature. The UK scam workflow was parked as a different problem outside the MVP markets, and AI reply drafting was swapped for state-based templates.
03
Figma, critique and a second pass
I designed the customer screens, then reworked them into a v2 after a design critique. The ops console got 11 frames, including the empty, loading and error states.
04
Designed in Figma, built with code
I designed every screen in Figma, then built one coded prototype that all three views share. Reviewing the build, I caught that whoever prepared a reversal could also approve it, and restricted approval to the checker. When the tracker's fill line crossed the check icons, I split it to stop at each step.
Selected Screens
A closer look.
Outcomes
What testing showed.
8 of 10
said wait instead of paying again (target: everyone)
4 of 5
Lagos customers understood the case (target 4 of 5)
1 of 10
would still contact support (target 1 in 5 or fewer)
On Day 4 I ran an unmoderated study in Maze with 10 customers on their own phones, 5 in Lagos and 5 in India, using the Figma prototype. They looked at the case for a timed moment, then answered from memory. I also ran moderated sessions with 5 customer support agents on the ops console and the support inbox.
What didn't land
The miss that matters most. One person would have paid again while the bank was still checking, the exact double payment this design exists to prevent, and one more wasn't sure. The advice card already warns that paying again would send the money twice, so the warning was on screen but didn't land for them. An unmoderated test can't tell me why, so the first thing I'd test next is stronger wording and placement for that card.
Certainty is the other gap. The one person who would still call support wanted to be certain. The payment reference that proves it sits behind the Details tab, so next I'd bring it onto the Updates view.
What held
The safety check held. On PD-1020, the final check blocked the reversal for every tester, and each chose a safe option. Nobody paid ₦150,000 twice.
Everything else met its target. Testers found the oldest breached case and read the India rule correctly, support replied to Tunde from the case facts with no invented dates, and 4 of 5 customers sent proof directly, the fifth by another route, in about 20 seconds.
The honest limits. Ten customers is a small sample, India comprehension wasn't scored separately, and the test used the Figma design, so motion wasn't tested. My ops testers were support agents, not payments-ops analysts, so the queue results carry less weight than the support results.
What changed after testing: apart from the pay-again miss, nothing blocked people, so I didn't change the design yet. The miss and the certainty gap are the two changes I'd test first.
Reflection
What I'd do differently.
I'd talk to payments ops before designing the console. My research came from customers' reviews, and my testers were support agents, so the ops queue is the part of this design with the least first-hand evidence behind it.
The safety check held in testing, but I don't yet know whether a real analyst would sort the queue the way I did, or trust the final check enough to stop double-checking it by hand. Next time, I'd sit with one or two analysts during a shift before drawing the queue.
Now you know.
You've seen the work. Let's build your next success story.
If you've read this far, you already know whether we're a fit. Currently taking two projects. Tell me what you're building — I'll tell you if I'm right for it.
Next Project
Troski (2026)
Designed a multimodal transit companion for Accra commuters — turning queue guesswork into live visibility, and cash fares into a tap-to-pay wallet.