← All case studies Conversion · Payments · SpeakX · 2025

UPI-first checkout: turning India's default payment habit into a 3× conversion lever

Overall checkout converted at ~5%. UPI users converted at 12–14%. The data was telling us our checkout was punishing the most common payment habit in India by treating it as one option among many. I rebuilt the flow around UPI as the default: a short product video sitting over the price, and two taps to a paid order: open UPI app, or change UPI app.

Role Product Designer, end-to-end ownership
Team 1 PM (Ayush Badukal) · 3 Engineers · 1 Data Analyst
Platform Android (UPI App intents)
My contribution Funnel analysis, payment-method research, flow design, video brief, copy, handoff
Outcome ~3× conversion on UPI cohort · SR +~10 points · 99% checkout-load reach
Business Context

Checkout was where a profitable funnel quietly leaked.

SpeakX runs a low-priced trial → paid subscription model with multiple price points (₹99 to ₹5,000) and processes payments through five gateways: PAYTM, PHONEPE, Razorpay, RZP_S2S and Juspay. By Q3 2025, acquisition was working: ~180K paid MAU at peak, daily install volumes in the tens of thousands.

What wasn't working was the conversion at the bottom of the funnel. Across the previous 14 days of the install-to-paid funnel, only ~0.7% of installs reached Premium CTR, and overall D0 conversion sat at ~5%. The dashboard had a clear segment-level signal everyone had walked past: the small group of users who paid via UPI app intents converted at 12–14% and reached checkout-load in ~99% of attempts. That cohort was telling us something the average wasn't.

The Problem, Quantified

UPI users were converting ~3× higher than everyone else. The checkout treated them like everyone else.

Overall conversion (login → order)
~5%
UPI-cohort conversion
12–14%

The pre-redesign checkout was a generic gateway-led screen: a list of payment methods (cards, netbanking, wallets, UPI) and a "Pay" CTA. UPI sat as one option among five. Users had to choose UPI, then choose which UPI app, then go through the gateway's UPI handler, then come back. Every additional decision was a chance to drop.

Three things from the data made the problem unambiguous: UPI cohort hit checkout-load at 99.4% (vs ~45% overall), payment success rate sat at 44–47% on UPI-only cohorts (vs ~28–36% overall), and Premium CTR collapsed by ~10× between Premium Load and the order step. The middle of the checkout, not the top, was eating the funnel.

Constraints

We could not break the long tail. We could re-default to the head.

  • UPI app intents only on Android. The deep-linked "open UPI app" flow is Android-specific. iOS users would still see a fallback card/UPI-collect path, so the design had to gracefully degrade.
  • Five gateways already in production. We could not reduce the gateway count or remove cards/netbanking. Long-tail users (older, higher-value, less UPI-native) still needed them. The redesign had to default UPI without removing other rails.
  • Trust gap on a low-price trial. At ₹99–₹299 trial pricing, users hesitated at the moment of payment despite the small amount. Whatever sat on the checkout had to do trust work, not just transaction work.
  • SR was bottlenecked by gateway, not by us. We couldn't make the payment itself faster, but we could remove decisions before the payment started.
Research & The One Insight

In India, UPI is not a payment method. It is the payment habit.

I pulled the 14-day funnel and segmented it three ways: UPI app users, UPI-collect users, and card/netbanking users. UPI app users were converting at 11–14% across every day in the window. The other two segments sat at 3–6%. The shape of the loss was identical regardless of price point. This was a flow problem, not a pricing problem.

I watched [X] session recordings of users who reached Premium Load and didn't convert. The pattern: users would land on the checkout, scan the payment options, hesitate at the "which to pick" decision, and either back-button out or drop after one failed attempt. There was no story being told, just a list.

"I just use the GPay one. Why is it asking me all this?"

Trial user, ₹149 plan, Tier-2 city, watching her own session replay

The reframe. Stop treating checkout as a payment-method picker. Treat it as a UPI confirmation screen with an escape hatch for everything else. Two questions for the user: open which UPI app? and not UPI?. Everything else gets out of the way.

The Decision

Two taps to paid. Everything else hidden behind one link.

The shipped flow was deliberately small:

  • A short looping product video sitting over the price block, no audio required, captioned. The video framed what the user got (lessons, AI practice, live sessions) in the language of outcome, not feature.
  • A primary CTA that fired a UPI deep-link intent directly to the user's chosen app. No gateway picker. No method picker. The OS handled the handoff.
  • A "Change UPI app" link that opened the OS app chooser, scoped to UPI handlers only, so the second tap wasn't punished with irrelevant options.
  • A single, low-emphasis "Other payment options" expander for users who genuinely needed cards or netbanking. It still worked. It just stopped competing for attention.

The trade-off I accepted explicitly: we were betting the long tail would still find their way to cards via the expander, and if they didn't, we'd lose some absolute revenue from that segment. The bet was that the conversion lift on the head would more than compensate. The data after launch confirmed it.

Shipping Reality

What shipped, what got cut, and what made it to v2.

What shipped in v1. The video-led checkout, UPI app deep-link intent, "Change UPI app" link, and the consolidated "Other payment options" expander on Android. iOS users got a parallel design without the deep-link intent: UPI-collect via the gateway as default, with the same video-led trust framing.

What didn't. Personalised video copy by intent (job-interview vs. school vs. travel) was descoped to v2. The data pipeline for serving the right video by user-declared learning reason wasn't ready in time. The card-on-file express flow for repeat purchasers also slipped to v2.

v2 targets. Intent-personalised video, card-on-file express checkout, and a "remember UPI app" preference so the second-time experience is one tap, not two.

Impact

Numbers measured on the cohort that hit the new checkout.

~3×
Conversion lift on UPI cohort (12–14% vs ~5% overall)
+~10 points
Payment success rate (44–47% vs 28–36%)
~99%
Checkout-load reach (UPI cohort, 14-day window)
2 taps
From price screen to paid order

"The checkout had become the bottleneck nobody was looking at. Defaulting around the actual habit, not the gateway, moved conversion enough to change the unit economics conversation."

Ayush Badukal · Product Manager, SpeakX
Reflection

What I'd do differently. What I'll carry forward.

What I'd do differently. I'd have pushed for the "remember UPI app" preference in v1. The second tap is a small cost on first purchase, but for repeat purchasers it's an obvious friction we accepted because it was easy to defer. Repeat-revenue dominates SpeakX's economics by ~25–30× over new revenue. Leaving any friction on the renewal flow was a missed compounding lever.

What I underestimated. How much trust work the video did. In testing I'd treated it as a "nice to have", assumed the simplification alone would carry the conversion. The post-launch lift was bigger than the simplification could explain on its own. The video bought users a moment to remember what they were buying, at the exact second they were deciding whether to.

What I'll carry forward. Defaults are a design decision, not a configuration. When a clear segment in your data is converting at 3× the average, the question isn't "how do we get the rest to look like them?". It's "why is our default not built around them?".