How Meesho Improved Payment Conversions: Inside the Screen That Moved India Off Cash on Delivery

TL;DR

• Cash on delivery built Meesho's user base and threatened to break its unit economics at the same time. 72% of shipped orders on the platform were fulfilled through COD as of FY25, and COD orders carry nearly 3 times higher return-to-origin rates than prepaid ones.
• Meesho's answer was not a discount campaign. It was a payments screen redesign built around one principle articulated by their own product leadership: a failed online payment is a worse trust event than a sold-out product.
• This article breaks down the in-app UPI mechanic currently live in the Meesho app that eliminates payment failure and app-switching.
• It covers how the same screen onboards first-time users to UPI itself, rather than just accepting payment from an existing instrument.
• It covers the framing that shifted users away from COD without penalising them for choosing it.
• It covers why competitors including Zepto have converged on the same architecture within a year.
• Sourcing note: All statistics and direct quotes are attributed to their sources throughout, and every mechanic described reflects a currently active capability, not a discontinued or historical feature.

Cash on delivery is not a feature. It is a trust workaround. COD brought millions of first-time shoppers from Tier 2 and Tier 3 cities online, people who did not yet trust cards, wallets, or UPI, and for a platform like Meesho, whose entire growth thesis was built on reaching exactly this user base, COD was not optional. It was the only payment method a huge share of the addressable market would accept when they first opened the app.

The problem is that the same mechanic that got users in the door became the platform's biggest structural cost. COD orders carry nearly 3 times higher return-to-origin rates than prepaid orders, with every failed delivery producing double logistics cost and zero revenue. At Meesho's scale, 1.83 billion orders placed in FY25 alone, a 72% COD share is not a minor operational inconvenience. It is a structural drag on margin that compounds with every order.

Meesho could not remove COD. Removing it would have cut off the exact user base the platform was built to serve. What they built instead was a payments screen designed to make the online-payment alternative so much better than COD that users would choose it on its own merits, not because they were forced to.

The Real Problem Wasn't Preference. It Was Trust.

The instinct in most product teams facing a COD-heavy user base is to treat it as a preference problem: users like cash, so incentivise them away from it with discounts or friction on the COD option. Meesho's own product leadership rejected that framing. Aditya Vikram, Senior Director of Product at Meesho, described payment reliability as the entire foundation of the strategy: "a failed payment is a big trust break," and specifically noted that "a failed payment is worse than a sold-out item. A sold-out item is a disappointment, but a failed payment shatters the fragile trust you're trying to build".

That distinction matters more than it first appears to. A sold-out item is a disappointment about the product. A failed payment is a violation of the user's trust in the platform's basic competence with their money, and for a first-time digital payment user, that violation does not just cost the current transaction. It's always a high-anxiety moment for a first-time user making an online transaction, and a failed attempt at that exact moment confirms the anxiety rather than resolving it, likely pushing the user back to COD permanently and telling their network to do the same.

This reframing changed what the product team optimised for. The goal was not "reduce COD usage." The goal was "make the online payment experience so reliable that failure becomes statistically negligible," because reliability, not incentive, is what a first-time digital payment user actually needs to overcome their anxiety.

The Specific Constraints of the Target User

Meesho's users outside Tier 1 India face a specific set of constraints: low internet connectivity, and limited experience with digital financial tools, both of which increase anxiety around online payments. This is a materially different design brief than optimising a payment screen for an urban, digitally fluent user. A complex, multi-step process is a non-starter for this user base. The solution has to be simple and resilient to on-the-ground realities, which rules out a large share of conventional e-commerce payment UX patterns that assume stable connectivity and payment app fluency.

A standard UPI payment flow in most Indian apps requires leaving the app, opening a separate UPI application (Google Pay, PhonePe, Paytm), authorising the payment there, and returning to the original app to confirm. Every one of these steps is a potential failure point: the app switch can fail on low bandwidth, the redirect can time out, the user can get confused about which app to return to, and each additional step compounds the odds that something breaks before the transaction completes. For a digitally fluent user, an occasional redirect failure is an annoyance. For a first-time user whose trust in the entire digital payment system is still forming, it can be the single event that ends their relationship with online payments altogether.

Turbo UPI: Removing the Redirect Entirely

Meesho's core technical answer was to eliminate the app-switch step completely. Meesho partnered with Razorpay to implement Turbo UPI, powered by the BHIM Vega tech stack from NPCI, offering an inbuilt, one-click UPI experience directly within the Meesho app, with no redirects and no app-switching.

The distinction between this and a conventional UPI integration is structural, not cosmetic. By connecting directly to the core UPI infrastructure rather than routing through a third-party app, the flow is both faster and, critically, more reliable, because it removes the specific failure points that app-switching introduces. Every redirect a payment flow requires is an opportunity for the transaction to break on a low-bandwidth connection, and Meesho's user base is disproportionately likely to be transacting on exactly that kind of connection. Removing the redirect does not just make the flow faster for users with good connectivity. It removes the single most common failure mode for the users the platform most needs to convert.

This pattern, native in-app UPI without an app-switch, has become the industry default within roughly a year of adoption. Swiggy introduced Swiggy UPI using the same NPCI UPI Plug-in framework in 2024, explicitly citing reduced payment failures and lower checkout time as the goal. Zomato rolled out a comparable capability through a partnership with ICICI Bank that issues users a Zomato-linked UPI ID, a slightly different architecture aimed at the same outcome. Zepto rolled out its own in-app UPI payments feature in late 2025, allowing users to complete transactions without being redirected to Google Pay, PhonePe, or Paytm, explicitly following the pattern Swiggy and Zomato had already established. The consistent thread across every one of these rollouts is the same underlying bet Meesho made first with Turbo UPI: large delivery and commerce platforms are increasingly internalising payments to streamline checkout and reduce reliance on third-party UPI providers, because even small improvements in checkout speed or payment reliability produce a measurable lift in order completion, particularly during high-volume periods when third-party app performance is least predictable.

Onboarding to UPI Inside the App Itself, Not Just Paying Inside It

The friction Turbo UPI removes is not limited to the payment step. For a large share of Meesho's user base, the barrier appears earlier: many first-time users do not yet have a UPI app set up at all. Downloading a separate UPI app, registering, and linking a bank account can feel cumbersome, or even intimidating for first-time digital users. Turbo UPI helps bypass that hurdle by letting users onboard to UPI directly within the Meesho app itself, rather than requiring them to leave Meesho, set up a separate payment app from scratch, and return to complete a purchase they may have lost momentum on by that point.

This distinction matters for exactly the user Meesho is trying to convert. A user who already has Google Pay or PhonePe installed and linked only needs the redirect removed. A user who has never set up any UPI instrument needs the entire onboarding sequence, account creation, bank linking, and PIN setup, collapsed into the same in-app moment as their first purchase, or that purchase does not happen. A lot of Meesho's user base sits outside Tier 1 India, with low internet access or limited access to financial instruments, and ensuring a great experience by reducing friction at checkout is a critical goal for exactly this reason: the checkout screen is, for a meaningful share of users, also the first UPI setup screen they will ever see.

Once a user has linked an account through this flow, it is remembered for future purchases, so the customer does not have to repeat the process, letting them pay directly with the linked account on every subsequent order. This is the mechanical foundation for the repeat-preference effect described later in this article: the one-time cost of onboarding is paid once, at the point of highest motivation, the first purchase, after which every subsequent transaction inherits the same one-click convenience without asking the user to authenticate a new instrument each time.

Reframing COD, Not Penalising It

The second half of Meesho's strategy is not technical. It is a positioning decision about how the checkout screen presents the choice between COD and online payment, without making COD feel like a punished or degraded option.

The framing Meesho's product team has articulated is explicit about the goal: the long-term aim is not to force a change but to win users over by offering something demonstrably better than the status quo of cash. Success is a future where paying digitally is an afterthought because the trust and convenience are simply a given. This is a meaningfully different posture than the common e-commerce pattern of adding a COD convenience fee or highlighting a discount specifically for prepaid orders as a way of penalising the cash choice. A punitive COD fee tells a first-time user the platform does not trust them. A genuinely superior online payment experience, positioned as the smarter and faster option rather than the mandatory one, lets the user arrive at the preference on their own terms.

This distinction connects directly to the trust principle covered earlier. A user who feels penalised for choosing COD is a user whose relationship with the platform starts from a position of friction. A user who tries online payment once, has it work flawlessly, and notices it was faster than cash on their next order is a user whose preference shift is genuinely earned rather than coerced, which is the difference between a behaviour that reverts the moment the incentive disappears and a habit that sticks.

The Compounding Effect: Why the First Transaction Matters More Than the Discount

The measured outcome of this strategy is not a one-time conversion bump. It is a compounding behavioural shift that Meesho's product team has explicitly tracked.

When the prepaid experience is smooth, users adopt it and stick with it, producing two distinct shifts: increased user stickiness, where new users who have a positive first transaction, both the checkout and any potential refund being smooth, develop a preference for paying online next time, and a higher repeat rate, where onboarded users are more likely to make future purchases because the convenience of a one-click, in-app checkout becomes a strong driver for loyalty.

This is the direct mechanical payoff of the trust-first framing covered earlier. A discount only changes behaviour for the transaction it applies to. A first transaction that works flawlessly, including the refund path if something needs to be returned, changes the user's underlying model of whether the platform can be trusted with their money at all, which is the belief that actually determines their payment choice on every subsequent order, discount or no discount. The specific mention of refund smoothness is notable: for a first-time digital payment user, the return and refund journey is arguably a higher-anxiety moment than the initial payment, because it tests whether money that has already left their account will genuinely come back. A platform that gets this part wrong undoes the trust the smooth checkout built.

The Business Case Behind the Investment

The economic argument for this level of payments investment is direct once the RTO data is laid out. COD's near-3x higher return-to-origin rate means every failed delivery produces double logistics cost, since the item has to be shipped out and then shipped back with zero revenue collected, a brutal hit to margins at scale. At 1.83 billion orders in FY25 alone, even a modest percentage-point shift from COD to prepaid, achieved through genuine trust rather than a temporary discount, represents a substantial reduction in RTO-driven logistics waste.

For context on what a well-executed COD reduction strategy can achieve, brands that implemented balanced RTO-reduction approaches, combining AI-based risk scoring, address validation, pre-dispatch confirmation calls, and delivery-time flexibility, reported a 42 to 48% drop in RTO rates while retaining approximately 89% of COD conversion volume, improving contribution margins by ₹3.2 to ₹4.1 per order within 90 to 120 days. Meesho's payments-screen strategy operates on the demand side of this same problem: rather than reducing RTO within the COD channel through operational tooling, it reduces the volume of orders that need COD-specific risk management in the first place by making the prepaid alternative genuinely preferable.

The average number of days for a new seller on Meesho to receive their first order after listing decreased from 32 days in FY23 to 26 in FY24 to 16 in FY25, a velocity improvement that reflects the platform's broader operational maturation, of which payments reliability is one contributing layer among several, alongside logistics and catalogue discovery improvements.

The Transferable Principle

The design discipline underlying Meesho's payments strategy generalises to any product operating in a market where digital trust cannot be assumed as a starting condition.

Treat payment failure as a trust event, not a transaction event. Most product teams measure payment failure rate as an operational metric to be minimised for efficiency reasons. Meesho's framing treats it as a trust-destroying event with consequences that extend well beyond the single failed transaction, which changes the investment priority: reliability engineering for the payment path deserves the same urgency as security, not the priority level typically assigned to checkout conversion optimisation.

Remove structural failure points before adding incentives. A discount cannot fix a payment flow that fails on poor connectivity. Meesho's sequencing, first eliminate the app-switch and redirect failure points through Turbo UPI, then reposition COD versus online payment through framing rather than penalty, reflects the correct order of operations: fix the reliability problem before attempting to change the preference, because no amount of incentive design overcomes a checkout flow that genuinely does not work for a meaningful share of the target user base.

Treat instrument setup as part of the checkout flow, not a prerequisite to it. For any product where a meaningful share of the user base does not yet have the payment instrument the checkout assumes, requiring users to leave the app, set that instrument up elsewhere, and return is a drop-off point that no amount of in-app polish can fix. Collapsing account setup and first payment into a single in-app session, as Meesho's Turbo UPI onboarding does, converts a two-session journey with a large abandonment gap in the middle into a single session with one continuous motivation curve.

Measure the first transaction's downstream effect, not just its immediate conversion rate. The real payoff of Meesho's reliability investment shows up in the second and third transaction, not the first. Product teams optimising payment screens purely for immediate conversion rate risk missing the larger compounding value: a flawless first experience, including the refund path, is what earns the repeat preference that no single-transaction discount can replicate.

Topics Not in the Brief That Teams Should Know

Routing-level redundancy as an invisible layer of the same reliability story. Turbo UPI's underlying BHIM Vega infrastructure optimises payment routing so that if one bank partner in the chain fails, the transaction can still be completed through an alternate path, rather than surfacing a failure to the user. This routing layer is invisible in the product but is what makes the "no redirect, no failure" experience described earlier actually hold up in production, since a single point of bank-side failure would otherwise still produce the exact trust-breaking event Meesho is trying to eliminate.

COD's role as a legitimate permanent channel, not a problem to be eliminated entirely. COD will likely remain a meaningful share of Meesho's order mix indefinitely, because for some users, especially those without any household member holding a digital payment instrument, it remains the only viable option. The strategic goal articulated by Meesho's own team is a preference shift for users who have a genuine choice, not a forced elimination of the channel for users who do not.

The refund and return experience as an underweighted trust surface. The Razorpay interview specifically calls out refund smoothness alongside checkout smoothness as a determinant of repeat online payment behaviour. Most product teams invest heavily in checkout UX and comparatively little in the refund journey, despite the refund moment being, for a first-time digital payment user, arguably a higher-stakes trust test than the original payment.

Payment reliability metrics that should sit alongside conversion rate. Payment success rate segmented by connectivity quality, redirect failure rate specifically (isolated from other failure causes), and time-to-refund-completion are three metrics that most e-commerce dashboards do not track with the same rigor as checkout conversion rate, despite being the specific levers that drove Meesho's strategy.

Key Takeaways

Cash on delivery built Meesho's user base and simultaneously threatened its unit economics, with COD orders carrying nearly 3 times the return-to-origin rate of prepaid orders at a platform processing 1.83 billion orders annually.

The strategic reframing that shaped Meesho's approach: a failed online payment is a worse trust event than a sold-out product, because it confirms rather than resolves a first-time digital payment user's underlying anxiety about the platform's competence with their money.

Turbo UPI, built with Razorpay on NPCI's BHIM Vega infrastructure, eliminated the app-switch and redirect steps that were the primary failure point for users on unreliable connectivity, delivering a one-click in-app UPI experience with no third-party app hand-off.

The same in-app flow that removes the payment redirect also removes the UPI onboarding barrier: a first-time user with no existing UPI account can set one up and complete their first purchase in a single session, with the linked account remembered for every subsequent order, so the onboarding cost is paid once at the point of highest motivation rather than repeated on every visit.

Meesho's positioning of online payment versus COD is incentive-driven rather than penalty-driven: the goal is a genuinely superior experience that earns preference, not a punitive fee that coerces it.

The compounding payoff shows up in the second and third transaction, not the first: users whose first prepaid transaction and refund experience are smooth develop a lasting preference for online payment that outlasts any single discount.

Within roughly a year of Meesho's Turbo UPI rollout, Swiggy, Zomato, and Zepto have all built comparable in-app UPI capabilities, converging on the same architecture of removing redirect friction as the industry default for high-volume Indian consumer apps.

Further Reading

From Digia Engage:

• How Zepto's Onboarding Gets Users to Their First Order in Under 3 Minutes — friction removal principles in the same quick commerce category now adopting in-app UPI
• Urban Company's Post-Order Screen: A Deep Teardown of How It Turns Waiting Into a Second Booking — trust-building architecture applied to a different post-transaction moment
• Mobile App Retention Rate: What It Is and What's Pulling It Down — the retention context for why a smooth first transaction compounds into repeat behaviour
• Digia Engage Widgets — inline trust and framing components configurable for payment-moment messaging without engineering tickets

External Sources:

• Cracking the COD Code: How Meesho and Razorpay Are Solving Payments for the Next Billion Bharat Users — Razorpay, interview with Aditya Vikram, Senior Director of Product at Meesho (the trust-first framing, Turbo UPI and BHIM Vega architecture, user stickiness and repeat rate results)
• Inside Meesho's Playbook: How Razorpay Is Helping Solve Payments for the Next Billion Bharat Users — YourStory (in-app UPI onboarding for first-time users with no existing UPI account; low-spec device and patchy internet context)
• Is Cash on Delivery Quietly Costing You More? — Upstox (COD's 3x RTO rate; BePragma RTO-reduction benchmark data; ET Prime and GoKwik COD volume statistics)
• IPO Review: Meesho Ltd. (MEELIM) — ICICI Direct (72% FY25 COD share; seller time-to-first-order improvement from 32 to 16 days)
• Meesho IPO Subscribed 79x, Check Allotment Status — Kotak Neo (1.83 billion FY25 orders; 198.77 million annual transacting users)
• Zepto Introduces In-App UPI Payments as Delivery Platforms Internalise Checkout — Storyboard18 (Zepto, Swiggy, and Zomato's respective in-app UPI architectures, current as of January 2026)
• Zepto Introduces In-App UPI Payments to Streamline Checkout — Aura Tech Insights (Zepto rollout details and industry context)
• Razorpay Launches Turbo UPI Plugin to Revolutionise Digital Payments — The Founder Media (BHIM Vega routing redundancy; Axis Bank partnership details)
• Turbo UPI Documentation — Razorpay Docs (current live product specification, confirming the feature remains active and supported)

The payment-moment framing and trust messaging described in this article are configurable in Digia Engage as inline widgets and contextual nudges, triggered on checkout and post-transaction events without engineering tickets after initial SDK integration. Book a demo to see how a trust-first payment experience can be configured for a marketplace or quick commerce checkout flow, or explore the widgets product page for the full component specification.