Multi-Vendor Marketplace Development: What It Adds Beyond a Store, and What It Costs

A multi-vendor marketplace is a store plus a payments company, and the second half is the part nobody quotes. The marketplace work adds 800 to 1,880 hours on top of a storefront, which puts a store-plus-marketplace build at roughly 1,500 to 3,280 hours, about $97,500 to $213,000 at a $65 blended rate.

The storefront half is well understood and priced everywhere: catalogue and search, checkout, tax, order management. What changes when a second seller appears is not the shopping experience. It is that money now arrives belonging to someone else, and your software becomes responsible for knowing who is owed what, when, and what happens when the customer wants it back.

Most marketplace projects are scoped as "a store, but with sellers". That framing survives until the first cross-seller return, at which point the team discovers that refunds, commission, settlement and the ledger all assumed a single owner of the money.

The ordinary failure is not technical. It is a seller emailing to ask why their payout is short, and nobody being able to reconstruct the answer because commission, a return and a settlement adjustment all landed in the same period against the same order, and the system stored a balance rather than the entries that produced it.

What it costs, added up

The storefront modules are published individually: catalogue, PIM and search at 220 to 520 hours, storefront, checkout, payments and tax at 160 to 360, order management at 250 to 600, and discovery and integration contracts at 80 to 180. A straightforward D2C launch comes to 700 to 1,400 hours.

The marketplace work is published as a single row of 800 to 1,880 hours, and honesty requires a caveat here: that row covers B2B, marketplace and the customer mobile app together, so it is an envelope rather than a marketplace-only figure. Narrow your scope in discovery and you will land inside it rather than at its top.

On top of either, every build carries the same cross-cutting lines: admin, CMS, reporting, consent and analytics at 90 to 200 hours, accounts, loyalty and wallet at 80 to 200, data migration at 60 to 260, peak load hardening at 60 to 160, DevOps and CI/CD at 60 to 160, and QA, UAT and hypercare at 20 to 25 percent of build. That last one is a multiplier, not a line, and leaving it out is the most common way a marketplace quote comes in low.

Who actually needs one

Before the cost, a filter, because it removes a good share of projects that arrive calling themselves marketplaces.

A marketplace earns its complexity when supply is fragmented and you cannot hold it yourself — too many sellers, too much variety, inventory you would never want on your own balance sheet. The whole payments-company half of the build exists to solve the consequence of that: money arriving that belongs to someone else.

The two questions that settle it are whether sellers set their own prices, and whether sellers own their customer relationship. If both are yes, you are building a marketplace and the rest of this post applies. If both are no, you are building a store with a complicated supply chain, and the honest scope is a storefront at 700 to 1,400 hours with purchasing behind it, not the figure above. If the answers split, you are usually building a managed marketplace, which carries the ledger and payout work but not the full seller-autonomy surface.

Getting this wrong in either direction is expensive. Scoping a store as a marketplace buys a payments architecture nobody needs. Scoping a marketplace as a store defers the ledger until sellers are already waiting to be paid.

Seller onboarding is a compliance project

The signup form is a week. The thing behind it is not.

Onboarding a seller means collecting and verifying identity, a bank account that payouts can reach, and tax status that determines what you withhold and what you report. It means handling the seller who fails verification, the one who passes and later changes their bank details, and the one who disappears owing refunds. Each of those is a state your system has to hold, and none of them appears in a wireframe.

The payment providers will do the verification, which is the single biggest saving available. Stripe lists risk-based KYC checks as included with Connect at no separate charge. That is worth taking: building identity verification yourself is a regulated activity you almost certainly do not want to own.

What you cannot outsource is the state machine around it — a seller who is onboarded but not yet verified can list but not be paid, and your catalogue, your checkout and your payout job all need to agree on that.

There is a commercial trap inside the compliance one. Verification friction is where marketplaces lose supply. Every field you add to onboarding costs you sellers, and the ones you lose are disproportionately the small sellers whose long tail makes a marketplace worth using. The resolution is almost always progressive: let a seller list with minimal information, require full verification only before the first payout, and make the point at which more is demanded coincide with the point at which the seller has money waiting. That sequencing is a build decision, and it is much harder to introduce after the onboarding flow exists.

Split payouts: two fee models, and why the headline rate misleads

Both major options in this market charge for payouts, and they charge in structurally different shapes. Read on 14 October 2026, from each provider's own page, with regional pricing displayed from India:

Stripe Connect charges ₹150 per monthly active account — active meaning any month payouts are sent to that account — plus 0.25% + ₹20 per payout. Risk-based KYC is included. There is also a model where Stripe sets the pricing and bills connected accounts directly, in which case the platform pays nothing for accounts, payouts, onboarding or funds routing.

Razorpay Route charges 0.25% per transfer, currently discounted to 0.1% as a limited-time offer on the Standard plan. Underlying payment gateway fees apply on top, and the page lists no separate settlement or linked-account charge.

The headline percentages are the same, so the percentage is not the decision. The difference is the fixed components. Stripe's per-account monthly fee and per-payout flat fee punish a marketplace with many small sellers paid frequently; a platform with 500 sellers paid monthly carries ₹75,000 in account fees before a single transfer. A percentage-only model is indifferent to seller count and punishes large transfer values instead.

So the question that decides your provider is not "what is the rate" but how many sellers, paid how often, at what average value. Work that out before you choose, because migrating a payout integration after sellers are onboarded means re-verifying every one of them.

The seller ledger is the real system

Underneath the payout provider sits the thing you cannot buy: a ledger that knows what each seller is owed.

It is not a balance. A balance is the output, and storing the output is how you end up unable to answer the email. What you need is entries: the sale, the commission, the refund, the chargeback, the settlement adjustment, the promotional contribution — each immutable, each dated, each attributable to an order and a seller. The balance at any moment is a replay of those entries, and a disputed payout becomes a query rather than an investigation.

Corrections are reversing entries, never edits. The moment a row can be amended, the ledger stops being evidence, and a marketplace whose ledger is not evidence cannot win an argument with a seller or a regulator.

This is the same discipline as a client money ledger in property management, and the reason is identical: the money is not yours, and the system's job is to prove where it went.

One practical consequence shapes the schema. A payout is not one entry, it is a batch of them, and the seller's question is almost never about the payout total. It is about one order inside it. So the ledger has to let you walk from a bank transfer down to the individual entries that composed it, and back up from any order to the payout that eventually carried it. Systems that model payouts as a number and orders as a separate list cannot make that walk, and every dispute becomes a manual reconstruction from two sources that were never designed to meet.

Returns across sellers break the refund assumption

A single store refunds its own money. A marketplace refunds money it has often already paid out.

One basket with three sellers is three refund paths. If the payout for seller A has already settled and the customer returns A's item, you are recovering from a seller rather than reversing your own charge — a different operation with a different failure mode, because the seller may have no balance to recover from. If the basket had a platform-funded discount across it, the refund has to apportion that discount across three sellers who did not agree it individually.

The design decision that avoids most of this is payout timing. Holding payouts until a return window closes makes refunds a reversal rather than a recovery, at the cost of sellers waiting longer for money. Paying out fast wins sellers and creates a recovery problem. There is no third option, and picking one is a business decision that the architecture then encodes.

A partial middle exists and is worth knowing about: hold a rolling reserve rather than the whole payout. A percentage of each seller's earnings stays with the platform against future returns, released on a schedule. It costs sellers less than a full hold and covers most recoveries, and it is the mechanism payment providers themselves use on merchants they consider risky. It also needs modelling in the ledger from the start, because a reserve is a liability you hold rather than revenue you earned, and the two must never be summed.

Settlement data restates itself

Here is a lesson from the other side of the same relationship. Building Stylebank, which pulls marketplace orders into one place for four apparel businesses, the recurring difficulty was that channel data restates itself.

An order cancels after picking. A return lands weeks after the sale. Settlement follows on its own cycle, with commission attached. The same order arrives three times saying different things, and none of the arrivals is wrong.

Channels do not share vocabulary either: a return to origin is not a customer return, although both reduce the same figure. Ingest that stream as an append and you will double count. The pattern that works is to upsert on the channel's own identifier and carry a snapshot date, so the record is the latest known state with its history intact.

Running a marketplace means being the channel that other people's systems have to reconcile against. The vocabulary you choose and the stability of your identifiers become somebody else's integration problem, which is a reason to decide both deliberately rather than letting them emerge.

Three decisions that change the architecture

Settle these before anyone writes code, because each one reaches into the ledger, the checkout and the payout job at the same time.

Who is merchant of record? If it is you, you take the payment, you own the tax position, and sellers are your suppliers. If it is the seller, the money is theirs from the start and you are a facilitator. This decides your tax obligations, your chargeback exposure and which of the two payout models above even applies.

When does a seller get paid? On order, on dispatch, on delivery, or after the return window. Each choice moves risk between you and the seller, and it determines whether a refund is a reversal or a recovery.

Who refunds a cross-seller basket? The platform, immediately, recovering later; or each seller, separately, at their own pace. The first is better for customers and worse for your working capital, and the second is the reverse. There is no neutral answer, only a chosen one.

When a marketplace is the wrong model

Worth asking before spending any of the above.

A marketplace earns its complexity when supply is genuinely fragmented and you cannot hold the inventory yourself. If you can hold it, a straightforward store is a fraction of the cost and avoids the entire payments-company half of the problem. Many businesses that describe themselves as marketplaces are really stores with drop-ship suppliers, and drop-ship is a purchasing arrangement rather than a marketplace: you remain the merchant, the money is yours, and none of the ledger, payout or cross-seller returns work applies.

The honest test is whether sellers set their own prices and own their own customer relationship. If they do not, you have a store with a complicated supply chain, and you should price it as one.

Where marketplace builds fail

Not on the storefront, which is the part everyone budgets for.

They fail when the ledger stored balances instead of entries, so the first disputed payout cannot be reconstructed. They fail when payouts were made fast to attract sellers and the first wave of returns arrives against sellers with no balance left to recover from. They fail when merchant of record was never decided, and the tax position turns out to be different from what the checkout assumed. And they fail quietly on unit economics, when per-account and per-payout fixed fees on a long tail of small sellers turn out to exceed the commission those sellers generate.

That last one is worth modelling before launch rather than after. A seller who transacts once a quarter can cost more in account fees than they return in commission, and a marketplace that has not worked out its minimum viable seller is accumulating customers it loses money on.

A fifth failure is slower and harder to reverse: identifier instability. Other people's systems reconcile against your order ids, seller ids and settlement references, and once they do, those identifiers are a contract in exactly the way an API is. Renaming or re-issuing them after sellers have integrated means breaking their reconciliation, which they will experience as your platform losing their money. Decide the identifier scheme deliberately, make it stable, and treat a change to it as a versioned migration rather than a refactor.