ShareChat, Moj, QuickTV · 2022–2026

One Tap Payment, Proven Once, Shipped Everywhere

RoleProduct Strategy, Design Direction
PlatformAndroid
Impact48% tap-to-success · Live across 5 products
A hand holding a phone showing the wallet recharge screen, with an abstract purple and gold sculptural form behind it

A payment screen isn't a browsing screen. One default, the friction gone before the user notices it was ever there.

The context

Payment intent is not browsing intent. The two need different rules.

  • At ShareChat and Moj, users never log in before they try the product. Tier 2 and tier 3 users need to explore and trust an app before they'll commit to an account.
  • Someone who's already tapped "recharge" or "buy coins" isn't browsing anymore. Optimising a payment screen for a non-login, explore-first experience solves a problem that isn't there.
  • The old payment screen put every method in one flat list: cards, Google Play, four separate wallets, then a "More Wallets" link. No default, no read on what the user actually had installed.

The solution

One tap. No form. No re-entering anything.

Turbo Checkout replaced that list with one default: whichever UPI app is already on the user's phone, pre-selected, one tap to pay. Enter a UPI ID only if none of the common apps are installed. Fewer choices, less cognitive load, scale the options later once real usage tells you which ones matter.

The path I rejected: wait, run a small test, prove the lift before touching the default for everyone. Swiggy and Zomato had already normalised one-tap UPI checkout years earlier. I didn't need our own product to re-prove something the category had already settled, so I shipped the default directly, no A/B test, on conviction plus that precedent.

First recharge wallet version: only 3 coin packs shown, PhonePe, Google Pay and Paytm as quick options below
The actual A/B test spec: with Turbo shows UPI UI then Call/Pay then opens UPI directly, without Turbo shows no payment mode, Call/Pay opens a generic webviewFour checkout states keyed on subscription-selected and last-payment-method-was-UPI signals

"Checkout being fast doesn't fix a weak offer earlier in the funnel. It just means once someone decides to pay, nothing gets in their way."

What else we tested

Recharge without leaving the call. Every surface after the first got a real test.

  • Once Turbo Checkout moved past the first surface, the team stopped shipping on conviction alone. Every new surface got a real A/B test, one arm with Turbo, one without.
  • The checkout sheet reads two signals before deciding what to show: whether a subscription pack is already selected, and whether the last payment was UPI. Auto-debit contexts get shown UPI-only, since cards can't auto-debit the same way.
Recharge overlay live during an audio or video call, 3, 10, and 20 minute options, PhonePe pre-selected, plus a welcome offer screen showing first 5 minutes at ₹1 instead of ₹20
7.7%Full funnel, sheet shown to paid
48%Tap to payment success
5Products now running Turbo Checkout

48% is the part Turbo Checkout owns directly. Once someone taps, nearly half complete it in one motion. 7.7% is the full funnel, sheet shown to paid. Fast checkout doesn't fix a weak offer upstream. It just means once someone decides to pay, the flow itself doesn't get in their way.

My role

Shipped once on conviction. Made permanent after.

The first version shipped on conviction, no A/B test. Once it held, I set it as the standing rule for every new product, not a one-off build for one surface. I'd make the same call again.