Reducing payment hesitation at SonyLIV's most critical screen

SonyLIV had 350M+ users and a growing catalogue. Subscription revenue was the business model. The checkout screen sat at the end of the entire funnel: every marketing campaign, every content investment, every recommendation led here.

The business goal was straightforward: more people completing subscriptions, fewer falling out at payment. The design challenge was more specific: a screen that supported India's fragmented payment landscape without that fragmentation costing conversions.

India's payment ecosystem is genuinely complex. UPI, cards, net banking, wallets, and operator billing all have meaningful user bases. Removing any of them was not an option.

The existing payment backend and gateway integrations were fixed scope. Any changes had to work with the current ranking and routing logic, not replace it.

The fix had to ship within a two-month window, which ruled out anything requiring backend restructuring. That constraint was actually clarifying: it confirmed this was a hierarchy and hierarchy problem, not an infrastructure problem.

Low-end Android devices accounted for a significant share of SonyLIV's user base. Any redesign had to perform consistently across device tiers, not just on flagships.

I started with a heuristic evaluation of the existing checkout flow, mapping every point where a user might pause, doubt, or abandon. That gave me a rough diagnosis before talking to anyone.

I then benchmarked against Prime Video, Hotstar, PhonePe, and Paytm to understand how the market had already solved payment hierarchy and failure states for Indian users. The pattern was consistent across the better performers: one method led, others followed.

I also reviewed Play Store reviews and internal customer support patterns to find recurring complaints. The themes that kept surfacing were not about missing features. They were about confusion: which method to pick, whether a discount had actually applied, and what to do after a payment failed.

The picture that emerged was not that checkout was broken. It was that it treated a decision that most users had already made as if they still needed to evaluate everything from scratch.

I went in expecting the problem to be about payment method support or technical failures. The research redirected that completely.

Users were not failing because the payment options were wrong or the backend was unreliable. They were stalling because the screen gave them no signal about what to do next. Every option looked equally valid, which made choosing feel like a decision that could go wrong.

That shifted the design brief from adding capability to removing uncertainty. The question was not what else to support but what to lead with.

My initial assumption was that the checkout drop-off was a trust problem: users were not confident enough in SonyLIV's payment security, so they were abandoning. I expected the solution to involve clearer security signals, trust badges, and better error messaging around card details.

The heuristic evaluation and competitor benchmarking contradicted that. Users were not dropping off because they distrusted the platform. They were dropping off because the screen gave them no signal about what to do. Security was not the bottleneck. Decision-making was.

That meant the highest-leverage fix was not adding more reassurance but removing the requirement to evaluate everything. Leading with UPI was the clearest expression of that reframe: it made the decision for most users without taking the decision away from anyone.

The default-plus-hierarchy pattern that came out of this project is not specific to payment methods. It applies anywhere SonyLIV adds a new offer type, a new subscription tier, or a new payment rail.

Rather than re-litigating the layout each time something is added, the principle holds: one path leads, others remain accessible. That made the pattern reusable across Android, iOS, and tablet surfaces without redesigning from scratch each time.

The most useful thing I learned from this project was about where to look for friction. I went in assuming the problem was visible: a broken step, a confusing label, a missing feature. The research showed the problem was structural: a screen that treated a near-certain decision as an open question.

The fix with the single highest measured impact, leading with UPI, was also the simplest to ship. That is a pattern worth carrying forward: when the bottleneck is decision architecture rather than missing capability, the solution is often subtraction, not addition.

If I were doing this again, I would involve engineering earlier in the constraints conversation. Understanding the backend limitations from day one would have let me scope alternatives more accurately at the start, rather than discovering some were off the table partway through exploration.