Every morning, lakhs of Meesho sellers open their payment tab looking for one simple thing: confirmation that the orders they fulfilled have translated into money they can trust.
For a seller, a payout is not just a bank transfer. It is a working capital. It is confidence to procure more inventory. It is the signal that yesterday’s effort has been recognized correctly, transparently, and on time.
Sellers are one of the most important pillars of Meesho. Not in an abstract or mission-statement kind of way but in a very literal & very operational way. These sellers come from every corner of Bharat from the textile hubs of Surat and Jaipur to the wholesale markets of Delhi, and from hundreds of smaller towns and cities that rarely make it to an e-commerce headline.
Today, Meesho enables payouts for around 1.4 lakh+ sellers on a daily basis, while also continuously checking beyond this active payout base to identify any other seller whose net payable position has turned positive. The goal is clear: no seller should remain unpaid simply because they did not fall into the most obvious daily payout cohort.
And the one thing that keeps them showing up, dispatching, and growing on Meesho instead of walking away to a competitor? Getting paid correctly. Getting paid on time. And actually understanding what they got paid.
Meesho operates on a 0% commission model, which means sellers keep what they earn. But payments aren't just about the product price. Logistics fees for third-party delivery partners, tax deductions, and charges for seller services like ads or influencer marketing all of these are deducted from a seller's payout. The amounts were always justified. The problem was that sellers couldn't always see why.
The Problem Nobody Talks About Until It Breaks
On the surface, a seller payout sounds simple: an order is delivered, the seller earns money, Meesho transfers the amount. In reality, it is a complex financial ledger problem.
A seller's daily payout is not just the sum of delivered order values. It may include or adjust for:
- Delivered order payouts
- Logistics charges
- Tax deductions
- Ads spends
- Influencer marketing charges
- Program recoveries and compensations
- Return protection charges
- Loan EMI deductions
- Referral bonuses
- Other platform-led seller services
Each of these inputs originates from a different system, follows a different business rule, and becomes payable or recoverable at a different point in time.
Behind every payout is a large-scale aggregation engine that pulls financial events from multiple upstream systems, nets off all recoveries and fees at a seller level, identifies every seller with a positive payable balance, and routes the transaction through the most reliable payment partner available. For sellers, all of this complexity collapses into one question: how much am I getting paid, and why?
That is the real challenge Meesho had to solve.
Reliability: When One Gateway Isn't Enough
Until about a year and a half ago, all of Meesho's seller payouts went through a single payment gateway partner. For the most part, it worked. But once or twice a year, it didn't. Bank downtimes or technical issues on the partner's end would delay payments for thousands of sellers for the day. The team would send communications. Sellers would wait. And every time that happened, a small but real question formed in a seller's mind: can I always count on this?
The team saw the problem clearly. A single gateway was the only route through which all seller payments moved with no alternative path. If it went down, payments didn't reroute. They just stopped.
The answer was to onboard a second payment gateway partner so that if one route ran into trouble, the other would keep payments moving without interruption. A seller should never have to wonder whether their money is stuck because of something entirely beyond their control.
Onboarding a new partner, however, isn't the same as stabilising one. The business and tech teams worked together through the initial integration challenges, identifying and resolving layered failure modes:
- Seller bank accounts not being whitelisted correctly
- Retry logic not triggering as expected
- Transactions are being marked successful on the partner's end, while Meesho's internal systems showed them as failed
A seller would receive an SMS confirming their transfer, open the app, and see a failure notification. Neither reading was wrong, but together they created confusion that shook confidence in the system.
One by one, each failure reason was identified, mapped, and fixed.
The results were measurable.
Payment failure rates dropped from 3% to sub-1%, stabilising between 0.9% and 1.2%. Processing time for the last 10% of payments (P90) came down from 35–40 hours to around 25 hours.
Correctness: Moving Toward First-Time-Right Payouts
Fixing the infrastructure was one problem. The other problem was quieter, more frustrating, and in many ways more damaging to seller trust.
Sellers were calling in confused. They had dispatched 200 orders and expected a certain amount to show up in their payment tab. What showed up was sometimes significantly less and the panel offered no explanation beyond a single line: Total Outstanding Balance. That number was a black box. It mixed together orders just dispatched with orders already in transit. It didn't tell sellers when they'd get paid, what had been deducted, or why.
One thing we realise is that Speed alone is not enough. A fast, incorrect payout is still a bad payout.
That is why Meesho tracks payout quality through FTRP - First Time Right Payouts. FTRP measures whether a seller was paid the correct amount in the first transaction itself, without requiring later corrections, claw-backs, or compensatory adjustments. Meesho's FTRP today stands at over 95%, meaning the overwhelming majority of sellers receive exactly the right amount on the first attempt.
To get there, Meesho made an important governance shift: all programs that affect a seller's payout ads, influencer marketing, return protection, and others are now expected to send their recoveries and compensations before the delivered order payout is processed. The number a seller sees is closer to the final truth, not a preliminary figure that gets quietly corrected later.
But FTRP alone didn't solve the comprehension problem. When the team dug into seller conversations and support tickets, they found a governance gap: sellers were being enrolled in programs over phone calls and WhatsApp messages they didn't always remember. Weeks later, a deduction would appear with no explanation. Sellers weren't just confused, they felt cheated.
The response happened on two levels.
First, the team started adding explicit recovery reasons directly on the order breakdown so if a deduction was for influencer marketing, the seller could see exactly what it was for. This was reactive, but it surfaced a deeper problem that different program teams then had to fix: making sure sellers were properly consenting to these programs in the first place. Enrollments moved from phone calls sellers often forgot to a clear opt-in flow on the seller panel itself. No more surprises. No more "I never signed up for this."
Second, the payment panel itself was redesigned. The old single-balance view was replaced with a structured breakdown. Outstanding balance is now split into Unscheduled Payments orders dispatched today, amounts not yet confirmed and Scheduled Payments delivered orders awaiting payment after the user's 7-day return window expires.
Sellers can now trace their effort directly to a monetary outcome: dispatch 100 orders, see that contribution appear in unscheduled payments, watch it shift to scheduled as orders are delivered, and get paid on D+8 meaning the 8th day after the order is delivered to the customer. Why the 8th day? Because Meesho gives users a 7-day return window from the date of delivery. Once that window closes without a return, the seller receives their payout the next day. It's a cycle built around fairness to both sides.
The payment tab now gives sellers a clear view of:
- What has already been paid
- What is scheduled for the upcoming payout
- What is still unscheduled
- Which deductions were applied
- Which compensations were credited
- How program costs were recovered
- How loan EMI deductions affected the final amount
For sellers who had taken business loans through Meesho's lending partners, the improvement went even further. Previously, EMI deductions would appear in their daily payouts with no visibility into why sellers had to log into separate lender websites to piece it together. Now, loan EMI details are integrated directly into the Meesho payment tab. The full picture of a seller's finances lives in one place.
Automation That Actually Respects the Seller's Time
Correctness and comprehension solved two dimensions of the problem. The third was timing.
Beyond standard order payouts, Meesho charges sellers fees for services they opt into ads, influencer marketing, return protection, live commerce. These fees should ideally be recovered close to when the service is rendered. The reality was very different.
Meesho envisioned an automated way to onboard any program that sellers choose to participate in, ensuring that the moment a service is used, the corresponding fee is recovered at exactly the right time, with full visibility for the seller.
Meesho built Program Automation to solve this structurally a self-serve platform that allows any internal team to onboard their service, define their recovery logic, and send financial events into the payout system in a governed way. Influencer marketing team? Plug in. Return protection team? Plug in. Warehouse services? Plug in. Once onboarded, recoveries happen automatically, aligned to the actual logic of each program, not whenever someone got around to uploading a file.
The impact was significant. Before Program Automation, virtually none of these recoveries were happening on time. After launch, over 98% happen on the correct day. Seller dispute tickets related to unexplained deductions dropped significantly. The experience became predictable, and predictability is what trust is built on.
Downloadable Reports: Scaling Transparency Through Data
For most sellers, the redesigned payment panel covers everything they need to see on a given day. But for larger sellers managing thousands of orders, multiple ad campaigns, service fees, and loan deductions, a dashboard summary is not enough.
These sellers need detailed, downloadable transaction-level reports statements they can reconcile against their own business records, share with accountants, and use to verify that every deduction and payout is accounted for. Meesho provides exactly that: detailed Excel reports that allow sellers to:
- Reconcile order-level payouts
- Track deductions and recoveries
- Understand program-level charges
- Map compensations against specific events
- Verify loan EMI deductions
- Share records with accountants or internal teams
Generating these reports at Meesho's scale is itself a technical challenge converting complex ledger data from millions of daily transactions into clean, usable files for lakhs of sellers. For many of them, these reports are the bridge between what the app shows and what their business accounts need to reflect.
What Comes Next
The team isn't done. The next frontier is payment accuracy, not just timing, but making sure every rupee goes to exactly the right place for exactly the right reason.
Here's the challenge. An order passes through many hands and systems before it is considered closed. Different teams operate different rules to govern order outcomes and ensuring these rules are consistent and standardized across the board is an active area of work. The goal is to eliminate edge cases where the same order generates conflicting outcomes for different stakeholders, creating confusion for the seller.
The work underway is to create one clear, system-governed standard for how every order's outcome is decided, so that by the time a payment is triggered, everyone is working from the same truth. Once that's in place, the plan is to tie accuracy directly to timeliness: the order payout and any associated service fees all resolved, calculated, and processed on the same day.
What This Actually Means
Meesho's sellers are not passive participants. They are the engine. And the people working on seller payments understand that not as a talking point, but as the reason every infrastructure improvement, every panel redesign, and every automation initiative actually matters.
The problems solved here weren't glamorous. They were systematic, patient, and deeply operational, finding that retry mechanisms weren't working, realising sellers couldn't connect their dispatched orders to the numbers on their payment tab, understanding that a 20-day recovery delay was creating disputes that had nothing to do with bad intent and everything to do with bad timing.
Step back and look at what was built: high-volume order aggregation, dynamic seller-level net payable computation, multi-partner payment routing, failure detection and retries, partner reconciliation, program recovery automation, FTRP governance, loan deduction visibility, and downloadable seller reports and it becomes clear that this is not a payout pipeline. It is a financial operating system for sellers.
And solving it one problem at a time, with data, with seller conversations, and with infrastructure that now serves not just sellers but also Valmo's last-mile delivery partners, first-mile operations, and truck fleets, to power all Valmo payout use cases, is what building for the backbone actually looks like.
The number that shows up in a seller's payment tab every morning isn't just a payout. It's a promise kept.
