Search for how to build a multi-vendor marketplace and you get the same article twenty times: a table of plugins and platforms, a column of prices, a column of features, and a recommendation that correlates suspiciously well with who published it. I've read a lot of them. They are not wrong about the prices. They are just answering a question that stops mattering in about week three.
I work on a multi-vendor commerce platform — the backend behind products, vendor onboarding, orders and store configuration, plus the admin dashboard on top of it. What follows is the set of things that actually determine whether this is a three-month project or a two-year one. None of them appear in the comparison tables, and all of them are decided by the architecture rather than by a settings page.
1. You are holding money that isn't yours
This is the one that changes what kind of system you're building, and it is worth sitting with before you choose anything.
In a normal shop, a customer pays you for a thing you sell. In a marketplace, a customer pays you for a thing someone else sells. Between the payment landing and the vendor being paid, you are sitting on funds that belong to a third party. That is not a feature. Depending on where you operate and how you've structured it, it can be a regulated activity, and "we'll just collect it in the company account and pay everyone on the first of the month" is the version that gets expensive to unwind later.
The architecture that avoids most of this is splitting at the gateway: the payment processor divides the charge between you and the vendor at the moment it is taken, and the vendor's share never lands in your account at all. Stripe Connect and its equivalents exist for exactly this, and the reason marketplace platforms advertise which connected-account models they support is that this is the load-bearing decision, not a payment detail.
Then ask the awkward follow-up, because it's where the design gets tested: a customer buys from three vendors in one cart and returns one item. Whose money is being refunded — yours, or the vendor's, from a payout that has already gone out? What if that vendor's balance is now zero? Your answer to that question is a real piece of system design, and it is much easier to build for at the start than to retrofit onto a payout table you've been appending to for a year.
2. Shipping stops being one parcel
Single-vendor shipping is a solved problem: a cart, an address, a rate, a parcel. Every platform does it and the plugins are mature.
Marketplace shipping is a different problem wearing the same word. One order becomes several shipments from several origins. Each vendor has their own carrier account, their own rates, their own handling time, possibly their own free-shipping threshold — and the customer, entirely reasonably, expects to be quoted one number at checkout and to track their order in one place.
So you need per-vendor rate calculation aggregated into a single displayed cost, an order model where fulfilment is per-vendor while payment is per-order, and a status model that can express "two of your three items have shipped" without either lying or showing the customer three orders they didn't place. Then delivery estimates, which are now the maximum across vendors rather than a single carrier's number.
Marketplace plugins do handle split shipping. The question to ask a candidate stack is not whether it supports it but what its order object looks like underneath — because if fulfilment state is stored per order rather than per vendor line group, you will be fighting that model on every feature you build for the next two years.
3. Vendor onboarding is a product, not a form
Every build I've seen underestimates this, and I understand why: from the outside it looks like a signup form with extra fields.
It isn't. A vendor applies, and someone has to review that application. There is business verification, tax details, bank details for payouts, agreement to terms that need a record of when and which version. There is a rejected state, and an appeal after rejection, and a suspended state for vendors who are already selling. All of that is a workflow with real states and real transitions, and it needs an admin interface for the humans running it — which is a second product, with its own permissions, built for staff rather than for customers.
Then the part everyone forgets: a vendor who is almost onboarded. They've been approved and listed products but haven't completed payout details. Can they sell? If yes, where does the money go? If no, what does the customer see on a product page that already exists? Every marketplace ends up with a partially-onboarded state, and the ones that handle it well decided on it deliberately.
4. Vendors need permissions, which means real access control
Single-vendor commerce has roughly two kinds of user: a customer and a member of staff. WordPress roles are fine for that.
A marketplace has a customer, a vendor, that vendor's staff, your support team, your finance team and your admins — and the rule that matters is that a vendor must never see another vendor's data. Not their orders, not their customers' addresses, not their sales figures. That has to hold on every endpoint, every report, every export and every search, forever, including the ones you add next year in a hurry.
The way you get this wrong is by filtering in the view layer: the query fetches everything and the template shows the current vendor's rows. It looks right. Then someone adds an API endpoint, or a CSV export, or a sort parameter, and the filter isn't there. Scoping belongs in the data access layer, where forgetting it is impossible rather than merely unlikely — and this is one of the strongest arguments for a platform built for multi-vendor from the start over a single-vendor system taught to be one.
5. Commission is arithmetic until it isn't
A flat percentage is easy. Nobody stays on a flat percentage.
It becomes per-category, then per-vendor as you negotiate with the big ones, then promotional periods, then tiers by volume. Meanwhile: is commission taken before or after tax? Who absorbs the payment processing fee? Who pays for shipping when it's free to the customer? What happens to commission on a partial refund, or on an item returned after the vendor has been paid?
The pattern that survives is treating every commission calculation as a stored record on the order line, not a runtime computation. Work out the split when the order is placed and write down what it was and which rule produced it. Recomputing later means historical orders quietly change when someone edits a rate — and a vendor with a spreadsheet will notice the month you did that.
So which stack?
The honest answer is that it depends on which of the five above you can afford to defer, and I'd choose on those rather than on features. A rough shape:
- A hosted marketplace SaaS if you're testing whether the business exists. It handles payouts and onboarding for you, which are the two hardest things here, and you give up control of the data model. For validation that's a good trade — you are trying to learn something, not to own a platform.
- WooCommerce with a marketplace plugin if the vendor model is conventional and the catalogue is the interesting part. The ecosystem is enormous, hiring is easy, and it's genuinely fine. Watch the order query load as vendor count grows — the admin gets slow before the storefront does, which is a WooCommerce property rather than a marketplace one, and is the same failure I've written about at length.
- A dedicated multi-vendor platform when vendor management is the product — many vendors, real onboarding workflow, per-vendor commercial terms. You're buying a data model that already knows what a vendor is, which is worth more than any feature list, and paying for it in a smaller ecosystem and more of your own operations.
- Custom only when something structural rules the others out. It is always more work than the estimate, and the estimate is usually made before anyone has thought carefully about refunds against paid-out balances.
The test I'd apply
Before committing, write down what happens in this scenario: a customer orders from three vendors, one ships immediately, one is out of stock and cancels, the third ships late and the customer returns it after your payout run.
Then work out what your candidate stack does at every step — what the customer sees, what each vendor sees, where the money is, and what your finance team has to do manually. It takes an afternoon, it costs nothing, and it will tell you more than every comparison table on the internet, mine included.