The Payment Succeeded. The User Panicked Anyway.
How a 30-second threshold reduced payment support tickets by 27% during peak UPI traffic
Client
Bureau ID
Product
Blaze Checkout
Year
2022
Timeline
2 weeks
Role
Sole Product Designer
Team
1 Product Manager 2 Engineers (FE+BE)
Outcome
27.41% fewer payment support tickets
across 12 merchants during peak sales
Same complaint. Different merchants. A pattern was emerging.
"UPI app says paid. Checkout says processing."
With 11 merchants, the issue existed but stayed hidden. Then we onboarded 12 more in early January. At 23, scale exposed it.
Blaze Checkout was Bureau's network checkout for D2C brands on Shopify and WooCommerce in India. I owned the checkout experience end to end.
Bureau's network checkout for D2C brands
The Funnel Looked Fine
Payments were completing. Nothing in the data suggested a problem.
But support tickets told a different story.
The payments went through. The funnel confirmed it. So why were users panicking?
I started digging.
Here's What Was Actually Happening
UPI payments are instant. The webhook callback? Not always.
When you pay via PhonePe or any other UPI app, your money moves in seconds. The callback to our server usually followed within seconds. During the Republic Day rush, it didn't.
And that gap, however small, was enough.
UPI success ≠ merchant confirmation
Our checkout didn't account for this. Users would complete payment in their UPI app, see "Payment Successful," then return to Blaze. But our screen was still spinning. No confirmation. No update. Just... waiting.
To users, the screen looked broken. They'd paid. Their money was gone. And the screen hadn't caught up.
Two screens, two different stories
I looked at our callback logs. The payments were succeeding. The confirmations were just late.
During peak hours, about 3–5% of transactions experienced delayed confirmations.
A small percentage. But a disproportionate share of support tickets.
97% of our users were first-time buyers. For someone on an unfamiliar brand, money gone, screen frozen, that delay meant only one thing.
"Did I just get scammed?"
They couldn't see what was happening behind the screen. They saw a brand that took their money and went silent.
The Core Insight
I couldn't make the webhooks faster. That's infrastructure I didn't control. But I could design for time.
Most UPI callbacks arrived within 20–25 seconds. 30 seconds was NPCI's standard processing window. Beyond that, something was likely off.
The logic was simple: change the UI based on how long the user had been waiting.
Instead of treating payment confirmation as binary (processing vs success), the interface needed to respond to elapsed time.
UI states mapped to wait time
The UI had to acknowledge what users already felt. Something was taking longer than expected.
What I Ruled Out
I tried a couple of quick explorations.
Text-only updates
The simplest and most obvious fix was to communicate the delay with copy. I mocked all three states to test the feel. The problem? Without reading the copy, all three states looked identical.
At a glance, nothing changed
Spot illustrations
Next I tried spot illustrations along with the copy. An hourglass icon felt like a step up from copy alone. But it wasn't enough. For a user mid-panic, it was easy to miss.
Better than text, still easy to miss
The requirement was clear:
Something that changed visibly with time.
Something users could feel without reading.
Something that made waiting visible.
Icons were still a digital solution to a digital problem.
I needed to look at how this moment played out in the real world.
UPI payments via QR are everywhere in India, from kirana stores to chai stalls. When you pay and the money leaves your account but hasn't reached the shopkeeper yet, you both do the same thing: stare at your phones, waiting together. The shopkeeper doesn't pretend everything's fine. They check alongside you. And when it lands, they smile and thank you.
That was the interaction I wanted to bring to the screen.
The Solution: Designing for Uncertainty
The state model defined what needed to change. The next challenge was how to make those changes immediately visible without users having to read.
The kirana observation gave me the direction: a merchant character whose expression changed with the state. Checking his phone. Waiting with you.
I called this emotional mirroring. Seeing your concern reflected tells you you're not being ignored. His expression shifted with the wait and the outcome.
Character mirrors user anxiety as wait time increases
When users should be concerned, he looked concerned too. Not panicked. Just honest.
The Pushback
The PM pushed back: "Won't showing concern make users more anxious?"
It was a fair risk. We could amplify panic instead of reducing it.
I prototyped the full flow and walked the PM through the kirana analogy. He wasn't fully sold at first, but the prototype walkthrough shifted his thinking. We shipped it.
Bringing It All Together
The character lived in the confirmation screen. As time passed, his expression shifted: confident at first, then concerned, then worried.
The shopkeeper waits with you
But waiting states were only half the story.
In a physical store, when payment finally goes through, the shopkeeper's face changes. Relief. A smile. A small nod. That moment of shared acknowledgment was missing from digital checkout.
Payment confirmed, shopkeeper smiles
So when payment confirmed, he smiled too. A simple shift, but it closed the loop. Users didn't just get a success message. They got acknowledgment.
Most users saw confirmation within 30 seconds. But for the 3–5% stuck waiting, these states were everything.
What Happened Next
The fix shipped January 25th, right in the middle of the Republic Day rush. Discovery, design, and ship happened in a single sprint.
The confirmation screen now responds to wait time
12 of our 23 merchants shared their categorized support data. The rest either didn't track support categories or didn't respond to our request. Comparing the week before launch to the week after, during the same sale period.
27.41% fewer
Payment-related support tickets across 12 of 23 merchants
Those delayed confirmations, just 3–5% of transactions, had been flooding support with "payment stuck" complaints. After the fix shipped, the confirmation screen no longer looked frozen. Users could see the system was still working, with the shopkeeper reflecting the payment state. Fewer users panicked. Fewer called.
Fewer panicked users meant fewer refund requests and duplicate payments, direct cost savings for merchants.
What I'd Do Differently
Talk to users directly. I designed based on merchant feedback and product intuition. A few interviews with users mid-checkout would have validated the approach. Or challenged it.
Track refresh behavior. We warned users not to reload, but didn't track how many did. That data would have strengthened the case for state design.
A/B test the character. I believe the shopkeeper added something text couldn't. But I can't prove it. A simple test would have answered whether emotional mirroring required illustration or just honest copy.
The Takeaway
Waiting isn't binary. Interfaces shouldn't be either.
Acknowledge uncertainty. Users can handle waiting if you show them you're still there.
Design for the slow path. A character showing subtle concern at 30 seconds said more than endless calm ever could.