How to Build a Multi-Vendor Marketplace: The Complete Guide

Someone has usually done the arithmetic before they call us: charge 15% commission, get 200 sellers, each doing ₹2 lakh a month, and the numbers look wonderful. The part that arithmetic hides is that a marketplace is two businesses stapled together, and the hard one is not the software.

This guide covers what multi vendor marketplace development actually involves — the architecture decisions that are expensive to reverse, the money flow that regulation constrains, realistic costs and timelines, and the specific reasons most marketplace projects stall. It also covers when you should not build one at all.

Be honest about the chicken-and-egg problem first

A marketplace with no sellers is useless to buyers. A marketplace with no buyers is useless to sellers. Every marketplace has to break that loop, and the platform is not what breaks it.

The approaches that work are all unglamorous:

• Go narrow. Not "furniture marketplace" — "solid wood furniture from Jodhpur workshops". Twenty sellers makes a narrow category look full and makes zero difference to a broad one.
• Subsidise one side. Zero commission for the first six months. You are buying supply; treat it as a marketing cost, not lost revenue.
• Be the first seller. Sell your own inventory alongside third parties until third-party supply is real. Almost every large marketplace did this.
• Solve one operational pain. If your sellers currently take orders over WhatsApp and track them in a notebook, the seller dashboard is the reason they join, not your traffic.

If you have no answer to "why will the first fifty sellers join before you have buyers", build the answer before you build the platform. We have seen well-executed marketplaces sit empty for a year because this question was deferred.

Marketplace models and what each demands of you

Listing-only

Sellers list, buyers browse, the transaction happens off-platform. Cheapest to build, no payment complexity, no regulatory burden. The problem is that you cannot see the transaction, so you cannot charge commission on it — revenue has to come from listing fees or subscriptions, and sellers stop paying once they have the buyer's number.

Managed marketplace

Transactions run through your platform. You collect payment, take commission, and settle to sellers. This is what most people mean by a marketplace, and it is where the real complexity sits: escrow-like fund handling, settlement cycles, refund logic, and dispute resolution.

Managed with fulfilment

You also handle logistics — either a central warehouse taking seller inventory, or a courier integration where you book shipments on sellers' behalf. Much more control over customer experience, much more operational cost. Only take this on if inconsistent delivery is genuinely killing your category.

These are ranges for custom builds in the Indian market. A SaaS or open-source starting point changes the numbers substantially, which is the next decision.

Build from scratch, or start from something existing

The honest recommendation for most first marketplaces

Start with an existing platform. Not because custom is bad, but because your first eighteen months will be spent discovering that your model is wrong in ways you cannot predict, and it is much cheaper to discover that on a platform you did not pay to build.

Realistic options in India:

• WooCommerce plus a multi-vendor extension (Dokan, WCFM). Cheapest path, roughly ₹1.5L–₹4L including customisation and a decent theme. Fine to about 100 sellers and a few thousand SKUs. Beyond that, WooCommerce's data model starts to hurt — product queries across large catalogues get slow and the fixes get increasingly hacky.
• Shopify with a marketplace app. Fast, reliable, hosted, but genuinely constrained on split payments and seller-specific logic. Good for curated marketplaces with a small vetted seller list. Ongoing cost matters: platform fee plus app subscriptions plus transaction fees compound.
• Medusa, Saleor, or Bagisto as a base. Open-source, modern, built for extension. More engineering required than WooCommerce, far less than greenfield. This is the sweet spot for a serious marketplace that wants custom logic without a two-year build.
• Full custom (Laravel, Node, Django). Justified when your model genuinely does not fit e-commerce assumptions — services with scheduling, rentals with availability calendars, bidding, or complex multi-party splits.

The migration path from WooCommerce to custom later is painful but survivable. The path from "spent ₹20L building the wrong marketplace" is not. Prefer the reversible mistake.

The money flow, and what Indian regulation requires

This is the part that surprises founders most, and getting it wrong late is expensive.

You cannot simply hold sellers' money

When a buyer pays ₹1,000 for a seller's product, that money is not yours. Holding it in your own current account and paying out later makes you an unlicensed payment intermediary. RBI's Payment Aggregator framework requires that funds settled to merchants pass through an escrow account operated by a licensed PA.

In practice you do not solve this yourself. You use a licensed aggregator's marketplace product:

• Razorpay Route — split a payment across multiple linked accounts at capture, or hold and transfer later.
• Cashfree Easy Split — similar model, with vendor onboarding and settlement scheduling.
• PayU, Easebuzz and others offer comparable split-settlement products.

Your platform records who is owed what; the gateway moves the money. Design for this from the start. Retrofitting split settlements onto a system built around a single merchant account is a rewrite of your order and payments layer.

Seller onboarding and KYC

Each seller needs to be onboarded as a linked account with the aggregator, which means collecting PAN, bank account details, GSTIN where applicable, and business proof. Budget real engineering time for this flow — it is multi-step, it fails in a dozen ways, and sellers will abandon it if it is not clear. Build a status dashboard showing exactly what is pending.

GST, TCS and invoicing

Marketplace operators must collect TCS at 1% on the net value of taxable supplies made through the platform and file GSTR-8. Invoices go from seller to buyer, not from you to buyer — your invoice to the seller is for commission. Your system must generate both, with correct GSTINs and HSN codes.

Do not improvise this. Talk to a CA before you finalise the data model, because the fields you need to store are determined by what you must eventually file.

Settlement cycle and refunds

Decide your hold period explicitly. Paying a seller on delivery day is generous and exposes you to return-window refunds you have already paid out. A common structure is T+2 after the return window closes, with faster settlement as a benefit for high-rated sellers. Refunds must be able to claw back from a seller's future settlement, which means your ledger needs to handle negative balances.

What the platform actually needs to contain

The seller side

This is where first-time builders under-invest and it is the reason sellers churn. A seller dashboard needs, at minimum:

• Product creation with bulk CSV upload and image handling. Sellers with 300 SKUs will not add them one at a time.
• Inventory management, with low-stock alerts.
• Order queue with clear statuses and a way to mark dispatched with a tracking number.
• An earnings ledger — gross sales, commission deducted, refunds, TCS, net payable, and settlement history. Sellers will not trust a number without a breakdown.
• Their own performance metrics: cancellation rate, return rate, dispatch time, rating.

Build this mobile-friendly. A large share of Indian sellers will manage their store from a phone, not a desktop.

The admin side

• Seller approval queue with document review.
• Product moderation — at minimum for new sellers and flagged categories.
• Commission configuration by category and by seller, since you will negotiate.
• Dispute and return management with a clear decision trail.
• Payout runs, with a preview before money moves.

The buyer side

Standard e-commerce, with a few marketplace-specific complications:

• Multi-seller carts. Decide early whether a cart can span sellers. If yes, one payment splits into several orders, each shipping separately, each returnable separately. This ripples through the entire order model.
• Shipping calculated per seller, since packages originate from different pincodes.
• Seller visibility. Show who is selling, with rating and dispatch location. Buyers use this to decide.

Technical decisions that are expensive to reverse

The order model

Model a payment as one thing and an order as another, with orders belonging to sellers and a payment covering many orders. Teams that model "one order = one payment = one seller" and then add multi-seller carts later end up rewriting fulfilment, refunds, and reporting.

The ledger

Keep a proper double-entry-style ledger of every money movement: sale, commission, shipping charge, refund, adjustment, payout. Do not compute seller balances by summing orders at read time. When a seller disputes a payout — and they will — you need an immutable line-by-line history.

Search and catalogue scale

Marketplaces accumulate SKUs quickly and unevenly, since every seller lists the same popular item slightly differently. Plan for a real search index (Meilisearch or Typesense are inexpensive and fast; Elasticsearch if you have the operations capability) rather than database LIKE queries. Also plan for product matching — deciding whether two sellers' listings are the same product — because without it your category pages become forty near-identical rows.

Image handling

Sellers upload 8MB phone photos. Process on upload: resize to a set of widths, convert to WebP, strip metadata, store on object storage, serve via CDN. Skipping this is how a marketplace ends up with a 40GB uploads folder and four-second product pages.

Realistic phasing

The version-one scope that actually ships:

1. Weeks 1–3. Seller onboarding with KYC, admin approval, gateway linked-account creation.
2. Weeks 4–7. Catalogue — product model, seller product management, bulk upload, moderation, categories, search.
3. Weeks 8–12. Buyer flow — browse, cart, checkout with split payment, order creation per seller.
4. Weeks 13–16. Fulfilment and money — seller order management, courier integration, ledger, settlement runs, returns and refunds.
5. Weeks 17–20. Invoicing and GST/TCS reporting, seller analytics, hardening, load testing.

Things to explicitly defer past launch: seller subscription tiers, promoted listings, buyer wallets, loyalty, native apps, seller chat, and any recommendation engine. Each is a real feature; none of them matter before you have liquidity on both sides.

Operations: the cost nobody budgets for

The platform is maybe 40% of the effort. The rest is ongoing and human:

• Seller acquisition and onboarding support. Expect to hand-hold the first hundred sellers through listing and KYC. This is a full role.
• Quality control. One seller shipping counterfeit or damaged goods damages trust in your brand, not theirs. You need a review process and the willingness to remove sellers.
• Dispute resolution. Buyer says not delivered, seller says delivered. Someone decides, and needs a policy to decide by.
• Finance operations. Reconciling gateway settlements against your ledger, monthly. Errors here are the fastest way to lose seller trust.

Budget ₹1.5L–₹4L per month for a small operations team from launch. A marketplace running on the founder's personal WhatsApp works to about fifty sellers and then breaks.

When you should not build a marketplace

Some straightforward cases where the answer is no:

• You have under twenty potential sellers. Build a normal e-commerce store and stock their products yourself. Simpler, and you control quality.
• Your category has huge incumbents and no differentiation. A general marketplace competing on the same terms as national players will lose on price and delivery.
• You cannot fund eighteen months. Marketplaces have long ramps. Commission on early volume will not cover operations.
• Buyers and sellers can easily transact directly. If it is a high-value, low-frequency service where both sides just want a phone number, they will leave after the first match.

Conclusion

If you are committed to a marketplace, the sequence that works is: pick a narrow category, secure your first fifty sellers before writing serious code, launch a managed marketplace on an existing base such as Medusa, Saleor, or WooCommerce with a vendor extension, and design the payments layer around a licensed aggregator's split-settlement product from day one.

Spend on the seller dashboard and the ledger, defer everything that sounds like growth tooling, and staff operations from launch. Custom multi vendor marketplace development is the right call once you have proven liquidity and are hitting real limits — not before. The marketplaces that fail rarely fail because the software was not sophisticated enough.