HyperUPI: Solving for Scale, Speed, and 90% Conversion
OVERVIEW
This case study showcases my work on Hyper UPI, a seamless 1-click UPI payment experience designed and developed at Juspay.
As the primary designer on the project, I led the design process from concept to implementation, focusing on delivering an intuitive & seamless experience for users. Let's have a look -
WHAT IS HYPER UPI?
Hyper UPI is a seamless UPI payment experience designed to complete UPI payments within the merchant app without redirection to any other third party payment app (TPAP) like google pay, phonepe, paytm etc.
***just about 3 steps, less than 5 seconds-
DO WE EVEN NEED THIS?
It’s no surprise that UPI revolutionized India's digital payments landscape. Its success catalyzed a surge in digital transactions, transforming India into a cashless economy hub that it is today.
With an experience that is already so seamless, is there really even a problem to solve?
well, yes-
Working with merchants, we saw that the current UPI peer to merchant (P2M) flow for online merchants isn’t as robust as the UPI QR flow is for offline merchants everywhere. While the widespread adoption of QR has made the experience almost frictionless, it’s not really the case for paying a merchant online.
Despite being the most popular form of payment today, even the most efficient peer to merchant UPI flow consists of multiple steps, app redirections, lack of uniformity, a learning curve for the non-tech savvy and a lot more which leaves both the user and the merchant with a fragmented experience.
Let's have a closer look at—
THE PAIN POINTS
The flow you see below is called UPI Intent. Integrating UPI Intent is the go to for online merchants today for their peer to merchant experience.
1
User selects a UPI app on the payment page
2
A redirection takes them to the chosen app
3
User enters security code to access the app
4
User checks details (& can change bank acc)
5
The UPI PIN page by NPCI opens up
6
User enters UPI PIN to initiate payment
7
Juspay processes the transaction
8
UPI app confirms transaction success
9
User redirects to merchant for final page
You experience flow this every single day to pay for food, groceries, travel, shopping and practically any app with a payment page. Not only do you experience it but also see almost everyone around you experience it and honestly, it works fine. So where's the trouble?
//APP REDIRECTION
When users make a payment, they are redirected to a UPI app. For some users this redirection can be ambiguous. The transition back isn’t always seamless, users can feel “lost in transition” ; different UPI apps offer different return paths (sometimes automatic, sometimes manual), creating inconsistency and confusion.
For merchants, this disrupts their brand experience. This break in continuity can impact the overall brand perception. It can be a drawback for businesses that emphasize a cohesive brand journey.
//LACK OF UNIFORMITY
UPI apps aren’t fully standardized in their intent flows, users experience different layouts, button placements, and confirmation screens in different apps. This lack of uniformity makes it hard for users to gauge transaction progress reliably.
For merchants, this lack of uniformity across apps makes it hard to standardize the checkout process.
DIFFERENT PAYMENT SCREENS ACROSS UPI APPS
APP 1
Google Pay
APP 2
PhonePe
APP 3
Paytm
//UNCLEAR STATUS & ERROR HANDLING
Users may see “pending” or generic success/failure messages that don’t explain what’s happening behind the scenes. It can make them uncertain about the completion of a payment, and in case of failure, error messages provide little to no guidance on what went wrong or how to resolve it. For example- did a transaction fail due to network issues or backend issues?
Merchants need to handle these edge cases (cancellations, timeouts, or partial transaction data) because the UPI Intent flow can behave unpredictably across different scenarios.
ONE OF MANY EDGE CASES BY THE MERCHANT (SWIGGY)
FOR HANDLING A UPI INTENT FAILURE
UPI APP
Google Pay
MERCHANT APP
PhonePe
//PERFORMANCE & RESPONSIVENESS
Delays during redirection or within the UPI app itself can make users anxious. In some cases, slow responses lead to repeated attempts, or drop offs, further complicating the payment process.
Merchants are left wondering whether a transaction is truly successful, pending, or failed. This ambiguity can delay order processing or force them to take additional steps (like manual reconciliation) before fulfilling an order.
//SECURITY CONCERNS
The abrupt jump from one app to another, without consistent security cues can leave the non tech savvy or new users questioning the safety of their personal and financial data.
For merchants, users’ doubts around the safety of their personal and financial data during the checkout process can create an association of this doubt with their brand too.
Ultimately, these problems cause enough friction that lead to a poor customer experience for certain groups of users, leaving the merchants to deal with more drop offs, and as a result lower conversions.
UNDERSTANDING THE AFFECTED USERS
UPI’s user base is massive. While these issues hit everyone, some groups feel the heat a lot more intensely, let's have a look at who these problems affect the most—
//HIGH FREQUENCY SPENDERS
Use UPI daily for everything (food, transport, shopping, etc). Impatient, get irritated if it happens repeatedly.
Urban, mobile-first users aged 18–35, working professionals/students.
//CONVENIENCE DRIVEN USERS
Value convenience over everything. Extremely impatient. Hate delays, would drop off if a transaction takes too long.
Urban, mobile-first users aged 18–35, working professionals/students.
//HIGH SPEND USERS
Make high value transactions. Rely on high success rates because any friction is costly, delays/failures cause anxiety/frustration/panic until resolved.
Affluent, users aged 25–40— traders, gamers, other high-income users.
//NON-TECH SAVVY USERS
Are not confident, they will not only drop off due to confusion but will do so scared and confused, also feel helpless in cases like duplicate payments.
Aged 40-50, from semi-urban or rural areas, less digitally urbans.
//USERS WITH LIMITED RESOURCES
Users with less money. Delays/failures cause anxiety/panic until resolved. Can even experience shame/embarrassment, may not have enough balance for retries.
Aged 25-45, including students, daily wage workers, lower/middle income individuals in urban pockets or tier 1/3 cities.
SOLUTION
Before we started started working on a flow, we focused on an already existing framework— the QR UPI flow.
GOOGLE PAY'S QR FLOW
1
Scan QR
2
Click on Pay
3
Transaction Complete
This QR flow allows the user to scan a code, enter the amount (if required to), enter their UPI PIN and complete the payment which means less friction.
We also observed that users feel they have more agency and trust since they have the choice to pick their preferred UPI app from their phone as opposed to choosing from the options available within a merchant app—some users always choose a bank UPI app as opposed to the popular ones.
This flow also helps merchants since they do not have to do an extensive app integration (unlike online merchants). This especially separates the merchant (and their brand) from a direct association to any other UPI app—so a delay/failure in payment isn't on them.
Now, in reality the QR flow is actually not that short, there's almost as many steps as there are in the intent flow, but it still feels really quick.
Our aim was to borrow this 'feeling' of ease that the QR flow carries.
HOW IMPORTANT IS TRUST?
Whenever we're working on a payment feature, one thing we almost always keep at centre stage is 'trust'.
For thousands of years, before any form of exchange even existed (cash, card, online), the most reliable currency has been trust. So everytime a payment is delayed, failed or left hanging in the air, a little bit of that trust gets eroded. While we can't completely eliminate these cases from existing (yet), we can always work on keeping the trust intact.
The most natural form of payment is a simple cash payment. You hand over cash, you see the exchange happen, and it’s done. It’s direct, visible, and builds trust— as opposed to any digital flow.
Cards, wallets, BPNL companies and all other forms of digital payments (while having started with more complex experiences) have strived to reach the simplicity of a simple cash exchange. With 60+ years in the making we have now reached a point where a user can make CVV less transactions with cards, which is essentially a 1 click/tap payment experience.
Keeping all the factors in mind, we believed the simplest form of a peer to merchant payment should look something like this—
//PAY
Essentially a 1click/tap experience where the user can directly make the payment within the app. This brings the flow down to a mere 3 steps and takes less than 5 seconds.
Let's have a closer look at what's happening here—
1
User selects the merchant's hyper UPI for payment
2
The UPI PIN page by NPCI opens up within the app
3
User enters their UPI PIN to initiate payment
4
Juspay processes the transaction
5
User receives payment confirmation within the app
what does this solve?
Well, almost everything.
There is no app direction, this removes any ambiguity and leaves no scope for any other app's branding to disrupt the flow which creates a sense of uniformity.
No redirection cuts the flow down to just 3 steps, which leaves less room for any payment failure or delays. The flow operating within the merchant app also gives them agency to create tailored error handling for their users that ensures that their users do not feel lost/anxious.
For non tech savvy or new users, it removes the potential feelings of doubt around the safety of their data. The trust they have for the merchant/brand automatically transfers to this flow, it is especially helpful in edge cases as this extends the users' patience bar.
//ONBOARDING
Now, let's talk about onboarding. Naturally, before the user can use the feature, they need to onboard. What you see below is the ideal version of what we believe(ed) the onboarding should look like.
Again, let's have a closer look—
1
User selects the merchant's hyper UPI for payment
2
Onboarding starts with mobile number verification
3
Bank account is verified next based on the previous step
4
After bank verification we start initiating the payment
5
The UPI PIN page by NPCI opens up within the app
6
User enters their UPI PIN to initiate payment
7
Juspay processes the transaction
8
User receives payment confirmation within the app
what we believed it solved—
—the lengthy sign up process that comes with creating a new UPI ID anywhere.
When we define hyper UPI, we say 1click/tap so to keep true to the essence of the feature, we wanted the user to experience the fastness of the 1 tap effect from the moment they decide to sign up. Since the flow ends with them completing the payment, the user experiences the 1 click/tap feature for the first time and to ensure that they don't create an association of a lengthy tedious onboarding with this really fast payment feature, we believed that it should hold the essence of that fastness and ease.
Unfortunately, this did NOT WORK :(
WHAT WENT WRONG?
While the idea seemed great to some merchants, our observations of a small cohort told a different story.
While the users were able to see value of a quick payment when using the pay feature, the same quickness/fastness when experienced during onboarding created confusion, security concerns and a lack of agency.
Some common reactions were—
"Wait what just happened?"
"Which mobile number did it verify?"
"Which account did it verify?"
"I don't want to use this number/bank account."
"How did it get access to my account?"
"I want to delete this, how do I go back?"
This is in turn also made merchants feel that the trust they've built with their users can get corroded if they begin to feel doubts around the security of their data and money, and in cases where the user does not want to sign up, they will be bombarded with queries to fix the issue.
Keeping this in mind, we worked on an onboarding flow which acknowledged these problems and came up with the following—
1
User selects the merchant's hyper UPI for payment
2
Merchant introduces Hyper UPI as a payment option
3 (a) Single SIM
User agrees to send message to verify mobile number
3 (b) Dual SIM
User selects SIM to verify mobile number
4
User sends the automated message
5
User's mobile number verification starts
6
We start fetching bank accounts liked to their number
7
User selects bank account(s) they wish to link with the UPI
8
We start linking users' preferred bank account(s)
9
User reads the list of mandatory checkpoints by NPCI
10 (a) 1 Bank Acc
User lands on the page where they can complete the payment
10 (b) Multiple Bank Acc
User selects bank account to complete payment
11
The UPI PIN page by NPCI opens up within the app
12
User enters their UPI PIN to initiate payment
13
Juspay processes the transaction
14
User receives payment confirmation within the app
does this solve the problem?
Yes.
Introduction to the feature gives the user autonomy to sign up only if they wish to.
Screens asking to proceed with users' mobile number/bank account give them autonomy to be informed of their data being used along with giving them the autonomy to select the right one.
While the process becomes slightly longer, we largely observed that there were no feelings of confusion, doubt around security or a lack of agency.
LIVE MERCHANTS & IMPACT
The feature display's a 90%> success rate. With zero dependance on any third party app, there is complete elimination of any technical failure that is caused on the app’s end. It is currently live for -
//SWIGGY
The food delivery giant launched 'Swiggy UPI,' powered by Juspay's HyperUPI Plugin, reducing the payment process from five steps to just one and decreasing transaction time from over 15 seconds to approximately 5 seconds.
STILLS FROM THE SWIGGY APP
//GULLAK
A leading fintech app, Gullak, was among the first to implement HyperUPI, achieving a success rate improvement to 92%, up from 80% with the previous UPI intent flow.
MORE
While this case study focused on the core Intent-to-in-app transition, there’s more— from UPI Lite integrations to dynamic settings flows— but in the spirit of keeping this a case study and not a thesis, I’ve focused on the core experience we rebuilt.
If you're curious about the rest of the features, I’d be happy to talk!
