A founder with Mercur, Spree Commerce, Dokan and CS-Cart open in separate tabs is usually asking the same few questions: how orders split across sellers, how sellers get paid, what commission rules are possible, and how much can change later. Searching for a multi vendor marketplace open source option is really a search for the answer to one question: which of those jobs arrive already built, and which ones the team still has to build.
An open source multi vendor marketplace is a codebase you host yourself, where many independent sellers sell through one storefront and the operator owns the code and the data. Owning the code does not remove the work. Seller onboarding rules, commission logic, payout flows, refunds and tax still need to be designed, and someone has to run the servers.
This article compares the options by what each one hands over and what it leaves for the team. Every capability claim links to the product’s own website, documentation or repository, so the comparison can be checked rather than taken on trust. Where an official page does not say something, the article says it is not documented instead of guessing.
What an open source multi vendor marketplace stack contains
Marketplace software has two layers, whether or not the code shows the seam. The underlying software is the ecommerce platform: it handles products, pricing, stock, carts, orders, payments, fulfilment and promotions. Some options ship marketplace functionality natively, while others need plugins or extensions to add sellers, offers or listings, commissions, order splitting, seller payouts, seller dashboards and moderation.
Some products ship both layers as one monolith. Others separate them, and that separation decides how much of the commerce engine you inherit and how much of the marketplace logic you can replace without touching it.
Mercur and Medusa show the separated model clearly. Medusa is an open-source commerce platform. According to the Mercur architecture documentation, Medusa is the commerce engine (products, pricing, carts, orders, payments, fulfilment, promotions, plus the module, workflow and event system), and Mercur adds the marketplace layer on top: sellers and members, offers, commissions, payouts and the seller-facing API. Mercur is open source, MIT-licensed and built on Medusa.
The same documentation states that Mercur adds a plugin and providers to the Medusa server and does not replace or fork the framework. That matters on upgrade day. A marketplace layer that patches the commerce core turns every core release into a merge exercise; one that sits beside it through hooks and links usually does not.
Mixing marketplace rules into the commerce core, for example by calculating commission inside a checkout controller, is the failure mode that makes upgrades slow later. Keeping commission, payout and seller logic in their own modules means the marketplace rules can change without rewriting the checkout.
Open source, licensed self-hosted and rented platforms
Teams usually look at three kinds of option. Open source projects publish their code under an open licence. Licensed self-hosted products give you the code to run on your own servers under a commercial licence. Rented SaaS platforms run the software for you and expose only what their admin and APIs allow.
The names in this space are often grouped together, but their licences differ:
- Mercur is published under the MIT licence.
- Spree Commerce is published under the BSD 3-Clause licence.
- Dokan (the free plugin) is a WordPress plugin for WooCommerce, listed on WordPress.org under GPLv2 or later.
- CS-Cart Multi-Vendor is a commercial product. Its official page describes self-hosted infrastructure and full source code ownership. Hosting is also available through a partner, Scalesta.
- Yo!Kart is a commercial product. Its official site describes a lifetime licence, customisable source code and hosting on a server of your choice.
CS-Cart Multi-Vendor and Yo!Kart are licensed self-hosted software, not open source. They belong in the comparison because the trade-off they offer is similar: you get the code and you run it, but the licence terms come from the vendor rather than an open licence.
The underlying trade-off is the same across all of them. Open source and self-hosted code reduce platform lock-in, and in return the team takes on uptime, backups, monitoring, security patches and payment provider compliance. A rented platform takes those jobs away and gives back less control over commission, refund and payout logic.
What each option hands over and what the team still builds
The table below compares five products against the jobs a marketplace has to do. Every cell is based on the product’s official site, documentation or repository, linked in the cell. Where the official page does not state the capability, the cell says “Not documented”. The feature may still exist; the official pages reviewed for this article do not confirm it.
Read the table as a list of starting points. Even where a cell says a capability exists, the team still decides the rules: which documents a seller must provide, when a commission is calculated, when a payout is released, and who absorbs a return.
Mercur on Medusa
Mercur’s checkout uses a workflow that groups the cart’s items by seller, creates one order per seller under an order group and refreshes each order’s commission lines. If a step fails, the workflow rolls back and the cart stays open. Payouts sit behind a provider interface: the Stripe Connect plugin creates a connected account per seller, returns onboarding links and transfers each seller’s share, and a different payout provider can be registered instead.
The same pattern applies to search, fulfilment, notifications and files. The architecture page lists Algolia and Meilisearch as search options and Stripe as the payment option, with room for your own providers. The repository lists Node.js, PostgreSQL and Redis as prerequisites.
What the team still builds: the commission rules themselves, the seller vetting process, refund and clawback handling after a payout, and anything regional. The provider model keeps a payment or search swap out of the marketplace code, but every swap still needs its own reconciliation tests.
Spree Commerce
Spree’s marketplace page says the marketplace starter ships in the open source Community Edition, and the Enterprise Edition adds automated Shopify and WooCommerce sync. The same page describes commission rates per vendor, category or product, vendor sign-up approval and suspension, and order splitting with Stripe Connect or Adyen for Platforms. According to the FAQ on the same page, Stripe Connect payouts, commission rules and the seller earnings ledger ship in the free Community Edition.
The Spree site describes a REST API, a TypeScript SDK and a Next.js storefront. Spree is a single commerce platform with marketplace features on top, so the commerce engine and the marketplace layer come from the same project.
What the team still builds: whatever sits outside the starter.
Dokan
Dokan turns a WooCommerce site into a multivendor marketplace. Its WordPress.org listing describes a vendor dashboard on the storefront where sellers manage products, orders, and earnings, along with admin control over vendor registration and product publishing, vendor and product-based commissions, and vendor withdrawals with optional automatic disbursement by amount or time period. Stripe Connect appears among the premium modules listed on the Dokan site. Core marketplace features depend on the plugin, while some advanced features sit in paid modules.
The commerce engine underneath is WooCommerce on WordPress. That means the team inherits WordPress hosting, plugin updates and plugin compatibility as part of the platform. Dokan adds marketplace functionality to WooCommerce rather than acting as a standalone open source marketplace platform. How Dokan splits a multi-seller order is not documented on the pages reviewed for this article.
What the team still builds: anything outside the plugin’s settings, and a process for testing plugin updates together, because a marketplace on WordPress is only as stable as the least maintained plugin it depends on.
CS-Cart Multi-Vendor
The CS-Cart Multi-Vendor page lists a multi vendor ecommerce platform with vendor onboarding and approval workflows, vendor management through seller dashboards, commission management, vendor payouts, split payments, Stripe Connect and PayPal Commerce Platform integration, an open API, and self-hosted infrastructure with full source code ownership. The page also describes hosting through a partner, Scalesta.
It is a monolith: catalogue structure, admin, vendor panel and marketplace rules come as one product. That saves decisions when the business model matches the product’s assumptions. When it does not, custom changes to a commercial codebase can drift from the vendor’s main line and make later updates harder.
What the team still builds: workflows outside what the admin configures, integrations to internal systems, and an upgrade plan for any customised code.
Yo!Kart
The Yo!Kart site describes a multi vendor online marketplace product with a lifetime licence, customisable source code, and self-hosting on a server of your choice, but it is not an open source platform on that basis alone. It also describes a product catalogue maintained by the admin, with seller-added products approved by the admin as part of the vendor rules, commission among the revenue sources, and Stripe Connect among the payment options. How it handles seller onboarding, order splitting and seller payouts is not documented on that page.
What the team still builds: depends on how far the business model is from the product’s defaults, and that has to be established against the product itself rather than its marketing pages.
The marketplace jobs that never come fully built
Whatever the starting point, a few jobs need decisions only the operator can make. These are where open source projects tend to accumulate workarounds.
Seller onboarding and governance
Onboarding covers registration, business document capture, approval or rejection, roles and permissions inside a seller account, and suspension. Products can provide the screens, but someone still has to define the rules: marketplace operators decide which documents are required, who reviews them, and what happens when a seller’s details change after approval.
Strict vetting improves buyer trust and reduces fraud, and it also increases the workflow the team has to build and maintain. Automated document checks and approval chains are real engineering work that a settings page does not cover.
Catalogue and offers across sellers
There are two catalogue models. In the first, the marketplace owns a master catalogue and sellers make offers against shared products. In the second, every seller owns its own products and SKUs. Mercur lets multiple sellers list offers against the same product, which keeps the catalogue under the operator’s control.
If every seller can create free-form attributes, categories and brands, search and filtering degrade quickly. One seller writes “Color”, another writes “colour”, a third creates a duplicate brand, and filters stop working. No search engine fixes a catalogue without a governance model.
Commission logic and seller payouts
Commission can be flat, category-based, tiered, or a fixed fee plus a percentage. It can be set per seller, per category or per product. Some marketplaces charge sellers a subscription instead of, or as well as, a commission.
Payout timing is a business decision with engineering consequences: on shipment, on delivery, weekly or monthly. Automated payouts help, but they need guardrails. Reconciliation is the hard part. If payouts happen before returns are processed, the system needs balance adjustments or clawback logic, and this is where spreadsheets start appearing in operations teams that were promised automation.
Changing commission rules part-way through a year without migration scripts can break historical reporting. Commission logic belongs in the codebase as something that will change, with tests that pin down how old orders are calculated.
Order splitting, shipping and returns
When a cart contains items from several sellers, the system has to split it into per-seller orders, each with its own status, fulfilment tracking and ledger entries. Shipping can be run by the marketplace on the sellers’ behalf, or each seller can manage its own carriers and tracking.
Returns and partial cancellations across split orders are the hardest part to get right in both code and accounting. A buyer orders from three sellers, two parcels arrive, one item comes back. Support now has to work out which seller absorbs return shipping, how to adjust the payout, whether the commission is reversed, and how tax changes. If the platform does not model adjustments per seller clearly, support resorts to a spreadsheet, and the spreadsheet quietly becomes the real system of record.
Storefront and search
Buyers expect one cart, consistent search across all sellers, and a clear view of which seller fulfils each line. A headless setup separates the storefront from the marketplace API and lets the frontend team release on its own schedule, at the price of another deployable to run.
Filtering by seller, region and availability produces expensive queries. A dedicated search engine usually becomes necessary well before the catalogue feels large, and running one means keeping its index in step with prices and stock from multiple vendors.
Integrations and reporting
A production marketplace connects to payment providers that support split payments, to shipping services for labels and tracking, to accounting or ERP systems, and to analytics. Provider interfaces let the team swap a payment or search service without rewriting business logic, but each integration still carries its own configuration and failure handling.
Finance and operations almost always need reports the marketplace admin does not ship with, so data exports or a reporting pipeline usually end up being built alongside the marketplace itself.
Where marketplaces break in production
These failure modes appear once there are live sellers, real money moving through the system and a non-technical operations team handling disputes.
Commission and payout rules that do not match reality
Finance asks for category-specific commission and wants payouts delayed until the chargeback window has passed. One vendor agreement or one legacy commission rule can force special-case logic into a live system. The system supports one global rate and immediate payouts. Retrofitting category tiers or delayed payouts into a running system needs migration scripts and new workflows, and it often introduces errors into historical reports. Designing the commission model early, even a simple one, is less painful than redesigning it around live seller data.
Performance under real load
Typical bottlenecks are heavy joins in multi-seller order reporting, commission calculated per request with N+1 queries, and seller dashboards querying unindexed tables. Scale problems usually appear once an ecommerce business has both more sellers and more buyers than the first version assumed. Moving commission calculation from request time to event-driven settlement stabilises response times, but it adds background jobs that need proper observability, or failures go unnoticed until a seller asks where their money is.
Drift between the code and the operations playbook
Operations teams build manual workarounds that never reach the system design: “special” sellers handled only in a spreadsheet, payments made outside the platform. With self-hosted code nobody forces an upgrade, so it is easy to end up on a fork whose behaviour nobody remembers how to change.
The trade-offs, stated plainly
No option removes the need for design decisions. Open source mainly decides who controls the code and the hosting. How sellers onboard, how commission works and how refunds flow still have to be decided by the operator.
Control versus operational responsibility
Self-hosting gives the team full control over infrastructure and code, so it can inspect and change anything from commission logic to the seller panel, and upgrade the runtime and database on its own schedule. That reduces dependence on one vendor, but it shifts hosting, backups, monitoring, incident response, compliance and security patches inside the team. Nobody sends a reminder when a dependency needs patching.
Prebuilt marketplace logic versus a composable stack
A monolithic marketplace product arrives with many decisions already made: catalogue structure, admin, seller panel and marketplace rules. That helps when the business model fits its assumptions and constrains when it does not, for example with unusual commission structures, regional fulfilment or payouts in several currencies.
A composable stack such as Medusa with Mercur lets the team assemble commerce, marketplace, content and frontend separately. Medusa’s site describes multiple currencies, local tax rules and region-specific settings, and multi-warehouse inventory. The composable route gives more room for unusual rules and demands stronger architecture discipline, automated tests and CI from the first week.
Flexibility versus delivery speed
Open code makes unusual flows possible: quote workflows, approval chains, regional tax rules. Even a “simple” commission rule that also affects historical reports, refunds and seller statements is rarely a one-sprint change once testing and reporting alignment are included.
Less lock-in versus more internal knowledge to keep
Open source reduces vendor lock-in: the team can fork, move hosts or swap components. The cost is internal knowledge. Documentation, developer onboarding and an architecture people can still explain a year later are part of the system and need the same upkeep as the code. This matters most when the business does not want one vendor to control future integrations, data movement, or payment changes.
Two marketplaces built on this stack
A network marketplace in Dubai that KVY built on Medusa and still runs is live, with multi-seller commerce in production. A multi-tenant digital-goods marketplace for African markets is built and pre-launch on Medusa v2 and Mercur, with a branded storefront per reseller and Stripe Connect payout batches that pass in test mode. The first shows multi-seller commerce on Medusa holding up in production; the second shows Mercur in practice, and that payouts are the part that needs the most testing before a real seller is paid. Both came out of our custom ecommerce development and Medusa.js development work.
If you are weighing this for your own business, start with a plan. In two to three weeks we map how the system would connect to your ERP, warehouse, payments and sales channels, set out the build in phases with the cost to run it over three years, and give a fixed quote for the first phase. You keep the plan whatever you decide.