DEV Community: Mercur

CAC in eCommerce: Why Does Customer Acquisition Cost Rise as You Scale and How Does Marketplace Fix This?

Rigby — Thu, 20 Aug 2026 08:22:23 +0000

Customer acquisition cost, or CAC, is what you spend to win one new customer. In eCommerce, it usually goes up as the business grows, which is the opposite of what growing is supposed to do to a cost per customer.

That shows up in how companies spend their money. Gartner's 2026 CMO Spend Survey found that awareness and conversion now take 62.6% of total media spend, which is more than 10% higher than in 2024.

This article breaks down:

What is customer acquisition cost in eCommerce, and how do you work it out?
How does CAC relate to customer lifetime value?
Is there an average CAC worth comparing yourself against?
Why does eCommerce customer acquisition cost rise as a shop grows?
How does a marketplace model change the numbers?

Key takeaways

CAC is your total spend on winning customers divided by the number of new customers you won.
Published dollar averages for CAC eCommerce come almost entirely from platform vendors and agencies, and each one counts different costs, so they make a poor benchmark.
Gartner reports that spending on customer loyalty and retention fell 29% between 2024 and 2026, to under 15% of total media spend, while acquisition took the difference.
McKinsey put the rise in customer acquisition costs at 60% over the five years to 2022, and the reasons behind it have not gone away.
A marketplace changes who pays for growth. Sellers add products and bring their own buyers, so a bigger catalogue stops being something your marketing budget has to buy.

What is customer acquisition cost in eCommerce?

Customer acquisition cost tells you how much you spend to turn one stranger into one new customer. It answers a small question with big consequences: at what you spend today, does one more customer pay for the work of getting them?

The answer shapes decisions well beyond marketing. It sets how far you can push a budget, which channels earn their place, and whether a given order is worth having at all.

How do you calculate CAC?

Take everything you spent on winning customers in a period and divide it by the number of new customers you won in that period.

The American Marketing Association states it the same way: total acquisition spend divided by new customers in the same time period.

A shop that spent 50,000 in a month and won 700 new customers has a CAC of about 71.

Which costs belong in the CAC calculation?

This is where most CAC figures go wrong. A shop that adds up its ad spend and stops there ends up with a number that looks far better than reality.

Count everything you pay to make a new customer show up. Ads, agency fees, making the creative, the tests that never ran, affiliate and referral payouts, app and platform fees tied to selling, and the part of your team's time that goes into winning customers.

Keep money spent on customers you already have out of it. Retention emails, loyalty rewards, and win-back campaigns are a different job, and mixing them in hides which half of the budget is working.

Why should you measure CAC by channel and cohort?

One company-wide CAC hides the decisions worth making. It mixes a cheap channel with an expensive one and tells you nothing about which to fund next month.

Split the number two ways: by channel, and by the month a customer first bought. That second group is called a cohort. Channels show you where money converts, and cohorts show you whether the customers arriving now are as good as the ones who arrived a year ago.

Cohorts catch a problem that channels miss. Your analytics tools can report a steady overall CAC while each new group of customers spends less and leaves sooner, so the average looks calm while the business underneath it gets worse.

How does CAC relate to customer lifetime value?

CAC on its own says nothing about whether a shop is healthy. A CAC of 200 is comfortable for a brand whose customers spend 2,000 over five years and a disaster for one selling a single 40-item.

The two numbers only mean something together. Customer lifetime value, or customer LTV, is your estimate of the profit one customer brings over the whole time they buy from you. Put next to CAC, it answers whether a customer earns back more than they cost.

What is a good LTV to CAC ratio?

Forrester puts the healthy mark at 3:1, meaning more than three units of profit for every one you spend winning a customer.

Its scale runs further in both directions: a company at 1:1 is spending too much, one at 5:1 has a business that works, and one at 10:1 is probably spending too little and could afford to buy more customers.

Two things come with that number. Forrester published it in 2019, and it describes subscription businesses, so a shop selling one-off orders should read it as a reference point instead of a target.

Which way the ratio is moving tells you more than where it sits. A shop whose ratio falls quarter after quarter has a problem whatever the number says, and a shop at 2:1 and climbing may be in better shape than one at 4:1 and sliding.

A high CAC is fine when lifetime value is high enough to carry it. What is hard to defend is a high CAC next to a lifetime value nobody has measured, which is the usual situation when the ratio gets quoted from memory.

How does average order value change the CAC you can afford?

Average order value sets the ceiling on what winning a customer can cost. A shop with an average purchase value of 40 and a 50% gross margin earns 20 on a first order, so a CAC above 20 means the first sale loses money and the shop is betting on a second one.

Lifting average order value lifts the CAC you can afford without waiting for that second sale. Bundles, bigger sizes, and free-shipping thresholds move that number, and they move it for every order from then on.

The same sum explains why some shops live happily with costs that would kill others. A high order value with a healthy margin buys room that no amount of campaign tweaking can create in a low-price catalogue.

4 reasons why eCommerce customer acquisition cost rises with scale

Rising CAC in eCommerce business looks like a marketing problem and behaves like a model problem. The four reasons below stack on top of each other, which is why better campaigns slow the rise without stopping it.

1. Cheap attention runs out before demand does

Early growth runs on cheap ad space: small audiences, keywords nobody else wants, retargeting that costs almost nothing. There is a limited amount of it, and you buy it first.

Once the cheap space is used up, every extra customer comes from a more crowded auction. IAB's 2026 Outlook Study expects US ad spend to grow 9.5% year over year, which means more money chasing attention that is not growing as fast.

None of that means your marketing team got worse. Our comparison of marketplace versus eCommerce growth models describes the same wall from the revenue side.

2. Acquisition takes budget away from retention

Gartner's 2026 CMO Spend Survey, run between January and March 2026 among 401 marketing leaders in North America, the UK and Europe, found that awareness and conversion now take 62.6% of total media spend.

Over the same two years, spending on customer loyalty and retention fell 29%, to under 15% of total media spend. Money moved out of keeping customers and into buying them.

Gartner's own data points the other way for the companies doing best. The most AI-mature marketing teams in the survey put a bigger share of budget into loyalty and retention, which suggests the shift toward buying customers is a symptom of getting it wrong.

3. Privacy changes made targeting more expensive

Ten years of direct-to-consumer growth ran on precise ad targeting, and the targeting got worse. EMARKETER notes that after Apple's App Tracking Transparency, the targeted advertising that let D2C brands grow cheaply became far more expensive.

When the targeting data thins out, the same budget reaches people who are less likely to buy. The spend stays where it was, fewer of them convert, and CAC picks up the difference.

EMARKETER puts the result plainly: many digitally native brands never reached margins they could live on. The era of cheap money that paid for that growth ended at roughly the same time.

4. Every unit of growth has to be bought again

The first three reasons are conditions you operate in. This one is the model itself.

When you sell to one customer at a time, growth arrives one customer at a time, and you pay for each one separately. Winning the last customer does nothing to make the next one cheaper, so the cost of winning customers grows alongside sales instead of falling against them.

McKinsey measured that effect at 60% growth in customer acquisition costs over five years, in work published in November 2022. Everything behind that figure has gotten tighter since, which is the honest way to read a number that is a few years old.

How does a marketplace model change the CAC numbers?

Everything above treats CAC as a number to manage. A marketplace changes what the number is measuring, because somebody else starts paying for part of the growth.A marketplace works differently from a classic online shop, and the difference is who owns the products.

In a classic shop, you buy the stock, set the prices, handle the shipping, and pay to bring in every buyer.

You also carry whatever does not sell.

In a marketplace, other companies list their own products on your website, hold their own stock, set their own prices, ship their own orders, and you take a commission on each sale they make.

The stock and the risk of owning it sit with the seller, and your side of the deal is the commission you set on each sale.

That changes what your shop can hold. A marketplace can carry thousands of products you never bought, from sellers who have their own reasons to want them sold.

When should you add a marketplace layer to your eCommerce, and how to do it without a rebuild?

The time to look at the model is when CAC keeps climbing after the campaign work is already done. If conversion rate, order value, and channel mix have all been worked on and the cost per customer still rises every year, the cause sits in the model, and more tuning will not reach it.

Two other signs point the same way. Catalogue growth is limited by cash instead of by demand, and customers keep asking for products you cannot afford to stock.

The catalogue side of the same problem sits in our breakdown of why adding more SKUs stops increasing revenue. Our five signs an eCommerce is ready to become a marketplace go through that check properly.

Changing the model does not mean rebuilding the shop. A marketplace layer can run next to the store you already have, so your current shop keeps selling while sellers are set up around it.

What does change is the work around the catalogue, and our breakdown of what changes operationally when a retailer becomes a platform goes through it function by function.

Start narrow and widen later. One category and a handful of sellers is enough to see what the commission earns and what running it costs, and the decision to open the rest can wait until those two numbers are on the table.

How does Mercur add a marketplace layer to an existing store?

Mercur is an open-source marketplace platform that can run alongside your existing shop instead of replacing it. It comes with a storefront for buyers, a vendor panel, an admin console, and integrations – with enterprise-grade governance & control.

Around 80% of marketplace functionality is ready on day one, with the rest built as modules for your own rules.

Sellers hold their own stock, so every stock item and location belongs to the seller who owns it. Commission is set up as a rule you control, so you decide what each sale earns you as the number of sellers grows.

The code is available on GitHub if you want to see how it works, or you can explore a demo of the full stack.

Summary and the next step for teams facing rising CAC

Rising customer acquisition cost gets read as a campaign problem and treated with campaign work. The spending data says otherwise. Buying customers takes a bigger share of budgets every year, keeping them takes less, and attention keeps getting more expensive.

A shop that pays for every bit of growth separately will keep watching that cost climb, however good the marketing gets. Changing the number means changing who pays for the products and who brings the people who buy them.

If you are weighing up whether a marketplace layer fits your business, talk to a marketplace expert!

FAQ on customer acquisition cost in eCommerce

What is CAC in digital marketing?

CAC, or customer acquisition cost, is the total amount you spend to win one new customer. In digital marketing, that covers ads, agency fees, making the creative, and the tools you use to sell, divided by the number of new customers all of it brought in. Teams use it to judge whether a channel, a campaign, or the whole shop can afford the customers it is buying.

How do I calculate customer acquisition cost?

Take everything you spent on winning customers in a period and divide it by the new customers you won in the same period. Count every cost that exists to make a new customer show up, including agency fees, creative, affiliate payouts, and your team's time. Leave out people who had bought before, because you already paid to win them, and report blended CAC and paid CAC separately.

What is a reasonable customer acquisition cost?

A reasonable CAC is one your order value and margin can carry, which makes it specific to your shop and not to your industry. A shop earning 20 of profit on a first order cannot live with a CAC of 40 unless a second order reliably follows. Published industry averages are hard to use here, because they come mostly from vendors and agencies counting different costs.

What is a good CLV to CAC ratio?

Forrester sets the healthy mark at 3:1, meaning more than three units of profit for every one you spend winning a customer. Its wider scale reads 1:1 as spending too much, 5:1 as a business that works, and 10:1 as spending too little. Forrester published that benchmark in 2019 for subscription businesses, so a shop selling one-off orders should watch which way its own ratio moves as much as where it sits.

What is a good CAC percentage?

CAC is easier to judge as a share of what a customer brings in than as a figure on its own. Set against the profit on a first order, it tells you whether that first sale pays for itself. Set against lifetime value, it tells you whether the whole relationship does. Both are worth tracking, because a shop can pass the second test and still run out of cash, failing the first.

Sources

The Marketplace Platform Transition: From Experiment to Core Business

Rigby — Tue, 18 Aug 2026 12:04:40 +0000

Most retailers approach a marketplace platform decision as an experiment. The logic is sound: expand assortment without inventory risk, test which categories pull demand, avoid capital commitment before the market proves itself. The problem is that signing a multi-year vendor contract and integrating across PIM, logistics, payments, and customer service is not a test. That is a strategic commitment dressed in experimental language.

This article examines the transition from marketplace experiment to core business channel, drawing on practical observations from multiple years running large retail marketplace operations across major European retailers. Eight operational signals tell you when the transition has already happened - and what to do before it catches up with you.

The paradox: a test that commits you to everything but the inventory

The commercial logic of launching a marketplace as an experiment holds up. You test demand in new categories without stocking shelves. You learn what customers want without the capital exposure. You build the case for in-house expansion only after the data supports it.

The operational logic does not hold up. A practitioner with multiple years of experience running large marketplace operations across major European retailers described the pattern this way:

"The objective is usually phrased as 'let's test new categories without inventory risk.' And then this testing simply turns into a real new sales channel that pulls digital growth hard."

A marketplace decision is commercially experimental and operationally strategic at the same time. Most organizations treat it as one or the other. This misalignment creates predictable problems: budget shortfalls, organizational unpreparedness, deteriorating customer experience during launch, and internal commercial conflict between 1P and 3P teams.

Multi-year platform contracts typically run three to five years. Implementations take twelve to eighteen months. Legal, merchandising, finance, IT, and customer service are all reshaped before the first third-party transaction completes. By the time sales begin, the organization has been committed for well over a year.

Three realities that turn experiments into commitments

Every retailer approaching a marketplace launch encounters three realities that make the experiment framing unsustainable from day one.

Vendor contracts compound with success

Platform pricing is typically a base subscription plus a percentage of GMV. This creates an asymmetric dynamic: you pay whether the marketplace performs or not, and you pay more proportionally as it performs better. In the words of the practitioner we interviewed: "Costs are so high that to reach break-even on a marketplace project, several years are often needed. Once you achieve it, it still weighs on you - it's a never-ending story. The more turnover you do, the more you pay. There's no escape from that."

Exit is not realistic once integration investment is in place. The "experiment" cannot easily be ended.

Implementation scope touches every function before revenue begins

Between contract signing and the first live transaction, retailers build: PIM integration, courier broker integration, payment provider integration, seller-side integrator connections (Base.com, Apilo), custom dashboards, settlement systems, and returns flows. Each requires sustained engineering investment and coordination across multiple teams.

By the time sales begin, the organization has been committed to marketplace operations for well over a year, with dozens of people reshaped across legal, UX, IT, merchandising, and customer service.

First-party teams inherit a competitor in their own categories

Marketplace operations do not simply add a channel - they impose a new operating logic on existing functions. Merchandisers who manage category P&L face competition from third-party sellers in the same categories. Customer service handles inquiries about products the retailer has never stocked. Legal teams designed for vendor contracts must learn seller agreements and platform-wide compliance - including, for example, European Union requirements such as Omnibus pricing transparency, GPSR product safety, and CRA obligations. These are not adjustments. They require redesign.

Eight signals you've already crossed the threshold

The shift from experiment to core business channel rarely arrives with a formal announcement. It accumulates through operational signals that compound quietly.

Marketplace GMV exceeds 5% of total revenue

At single-digit GMV share, marketplace decisions are affecting the consolidated P&L in ways that need C-suite attention. Decathlon launched its marketplace in Belgium in December 2020 with two stated objectives: to offer a wider sports product choice and to "become sports users' favourite platform in the world." Five years later, the business had become a strategic pillar, operating across 14 European and 6 Asian countries with €500M in annual turnover. Any retailer tracking their marketplace at that scale is not running a pilot.

Third-party GMV growth is outpacing first-party

According to Flywheel Digital's global ecommerce marketplace research, third-party ecommerce is forecast to outpace first-party by approximately 5 percentage points of CAGR globally between 2023 and 2028 (11.7% vs. 6.6%). Amazon's third-party seller share hit 62% of paid units in Q4 2024, the highest level recorded. When your own data shows two or more consecutive quarters of 3P outgrowing 1P, the marketplace has become the engine of incremental growth.

Customer service receives inquiries they cannot answer

The practitioner observed this directly across multiple deployments: "You're touching the work of customer service staff whose work suddenly changes. Not to mention store employees, who suddenly get questions about marketplace products they know nothing about." When customers cannot distinguish 1P from 3P products but the customer-facing organization is structured around 1P knowledge only, service quality degrades. This signal typically precedes formal recognition of marketplace as core business by months.

Engineering teams are building custom capabilities around the platform

Mature marketplace operations consistently develop capabilities outside their current platform: custom BuyBox algorithms, settlement systems, seller CRM tooling, and advanced dashboards. Even less-customized implementations end up building Power BI or Tableau reporting that sits outside the platform's native analytics. When custom development consumes significant engineering investment, the marketplace has become a strategic platform requiring ongoing build.

The product catalog is accumulating a backlog of broken entries

Marketplace catalogs degrade over time without active intervention. Sellers add products that fail validation and do not return to fix them. Onboarders move to new sellers without cleaning up the previous batch. One experienced operator described reaching "almost 100,000 products that were never published because something went wrong in onboarding and no one returned to them." This debt compounds faster with scale and never cleans itself up.

Finance teams are escalating settlement and reconciliation issues

Multi-party revenue flows - commissions, take rates, refunds, multi-currency settlement, cross-border tax compliance - create accounting complexity that retail finance teams are not typically set up to handle. When settlement reconciliation issues escalate repeatedly from finance to operations, the underlying infrastructure is no longer keeping pace with the business.

First-party and third-party commercial teams are fighting over KPIs

Possibly the most under-discussed signal: internal commercial conflict. The practitioner framed it directly: "When mixed offers appear, there's real commercial friction, because both sides pull in their own direction when it comes to hitting the plan." A category buyer responsible for 1P performance is in competition with the marketplace operator growing 3P in the same categories. Without explicit governance, this tension compounds and can stall marketplace growth from the inside.

Customers cannot tell whether they are buying from the retailer or a seller

The retailer's brand extends to every product on the platform, regardless of who fulfills it. Poor experiences from third-party sellers are attributed to the platform owner. The practitioner observed this pattern across multiple marketplace environments: "When you launch a marketplace, you're risking that NPS, that customer service quality, drops. Conversion also drops. This is what often isn't easily understood by companies starting a marketplace."

The organizational readiness gap

Ten functional areas show predictable gaps when retailers approach marketplace as an experiment rather than a strategic channel.

Legal must handle seller agreements, platform-wide T&Cs, and regulation-specific policies - including EU requirements such as Omnibus, GPSR, and CRA - that standard retail legal teams are not configured for. PIM teams designed around 1P quality standards face thousands of seller-submitted descriptions with no incentive to match those standards - the practitioner described PIM as "the largest challenge always, everywhere." Finance inherits multi-party revenue recognition, commission accounting, and cross-border tax compliance. Marketing must reconcile product feeds for Google Shopping and Meta across mixed 1P/3P catalogs. Customer service, merchandising, store operations, and IT architecture all require redesign when 3P operations reach significant scale.

"Experiment" framing typically engages two or three of these functions. "Strategic commitment" framing engages all ten - with allocated resources and leadership accountability.

The cost of engaging all ten functions from the start is far lower than retrofitting organizational capability after problems emerge at scale. If you want a framework for evaluating your current readiness, 5 Signs Your eCommerce Is Ready to Become a Marketplace covers the organizational and commercial signals worth checking before you launch.

What marketplace platform decisions look like at strategic scale

Platform selection during the experiment phase typically prioritizes speed of launch and out-of-box feature coverage. At strategic scale, the relevant questions shift: how well does the platform support the custom capabilities you will inevitably build? How does the vendor roadmap address market-specific regulatory requirements? What does the cost curve look like as GMV compounds year over year?

The evidence from retailers that have committed fully to marketplace is clear. Best Buy relaunched its marketplace in 2024 after shutting down an earlier attempt in 2011. By Q1 FY2027, the results were measurable: "the higher gross profit rate included growth in Marketplace and Best Buy Ads." A marketplace that starts as a strategic initiative becomes a P&L driver - but only when the organization commits to it as one from the start.

Retailers that reach strategic scale typically discover their platform was selected for a narrower set of requirements than the business now demands. Understanding this gap early is cheaper than addressing it after two years of compound customization.

Mercur - an open-source marketplace platform built for the customization reality

Mercur is an open-source multi-vendor marketplace platform built on Medusa.js. It ships 73% of marketplace features out-of-box (265 of 365), with an MIT license - no per-transaction fees, no licensing costs, full IP ownership.

Unlike proprietary SaaS platforms with GMV-based pricing escalation and roadmap priorities set at the global level, Mercur is designed for the customization reality of mature marketplace operations. Open architecture, full source code access, and no commercial lock-in mean retailers can build the BuyBox logic, settlement systems, and seller tooling their operations need - without paying a growing percentage of GMV to do it. The platform has supported $6B+ in client trade volume across industrial procurement, consumer goods, and specialty retail.

For retailers approaching the signals described in this article, Mercur removes the pricing escalation that makes platform exit impossible and the closed architecture that makes customization prohibitively expensive.

Five things retail leaders should do this quarter

If any of the eight signals in this article describe your marketplace today, five actions are worth prioritizing now.

Reframe internally. If the marketplace is at significant GMV share or shows the maturation signals described above, treating it as an experiment is creating organizational risk. A formal internal repositioning - marketplace as a strategic channel, not a test - changes budget allocation, role definition, and cross-functional accountability in ways that compound over time.

Model cannibalization explicitly. Include estimated 1P cannibalization in the marketplace financial plan from the start - even when you expect net-positive results overall. Retailers who avoid the question tend to be caught off guard when it materializes at scale.

Audit organizational readiness across all functions. The ten functional areas above are interdependent. Customer service quality depends on legal documentation of seller obligations. PIM data quality affects marketing performance and conversion rates. A readiness audit that examines all functions systematically finds the weakest link before it breaks under scale.

Define transition milestones. Without explicit milestones, the shift from experiment to core business happens through drift. A starting framework: at 3% GMV, assign a dedicated C-suite sponsor; at 5% GMV, establish formal cross-functional governance with monthly executive reviews; at 10% GMV, review whether marketplace should operate as a standalone business unit.

Invest in the Marketplace Manager role. This role requires technical fluency with the platform, commercial acumen for seller economics, operational understanding of cross-functional integration, and the political skill to manage 1P/3P tensions. The talent pool is limited, and internal context matters as much as external experience. Building succession depth for this role is a strategic investment.

The transition from marketplace experiment to core business channel happens to nearly every retailer that launches and sustains a marketplace for several years. The global data on third-party growth makes it near-inevitable. The question is not whether the transition happens - it is whether the organization recognizes it when it does.

Retailers that recognize it early invest proportionally in capability, plan for cannibalization from the start, and select platform infrastructure built for the scale they will eventually reach. As the practitioner whose observations informed this article put it: the testing simply turns into a real new sales channel. The work of retail leadership is to have the organization ready when it does.

Marketplace Data Security: The Multi-Vendor Open Secret

Rigby — Mon, 17 Aug 2026 12:03:47 +0000

Here's a question almost no one asks before buying a marketplace platform: what happens when your marketplace manager leaves and exports the entire seller database on the way out?

Marketplace data security is the part of platform evaluation that gets skipped - until an incident forces it onto the agenda. Teams scrutinize uptime, transaction throughput, and commission logic. The audit trail, the permission model, and the export controls rarely make the shortlist.

This guide covers what marketplace data security actually requires, where most platforms fall short, and the questions a CTO or CISO should ask before committing to one.

Why marketplace data security is different

A single-vendor store protects one company's data: your products, your customers, your orders. A marketplace holds something more sensitive - the commercial relationships between you, your sellers, and your buyers.

That includes seller contact details, commission rates per vendor, sales performance by seller, buyer purchase history across vendors, and payout account information. This data is the marketplace's core asset - the thing a competitor or a departing employee would most want to walk away with.

The risk profile is wider than a normal store. You have internal staff, external vendors logging into their own dashboards, and admin users with broad reach. Every one of those access paths is a potential leak.

The export problem nobody tests

The most common gap is also the simplest: uncontrolled data export.

On many platforms, anyone with admin or marketplace-manager access can export the full seller list, complete with contact details and commission terms, in a single click. No approval step, no log of who exported what, no alert.

If you can't answer "who exported the seller base last month," you have a data security gap, not a feature gap. A seller list is a recruitment target list for any competing marketplace. It walks out the door with one CSV download.

Test this directly. Ask your platform vendor: can a marketplace manager export all seller records? Is that export logged? Can you restrict it by role? On most SaaS marketplace platforms, the honest answers are yes, no, and no.

What proper marketplace data security requires

A marketplace platform needs four controls that single-vendor commerce systems rarely ship with. Each one closes a specific exposure.

Granular role-based access control

Basic RBAC gives you admin, vendor, and customer. That is not enough for a marketplace handling real commercial data.

You need roles scoped to function: a support agent who can see orders but not commission rates, a category manager who sees their vendors but not the full base, a finance user who sees payouts but cannot edit catalog. The principle is least privilege - every user sees only the data their job requires.

Without granular RBAC, every internal user is effectively a super-admin, and your exposure equals the access of your least careful employee.

Audit logging on sensitive actions

An audit log records who did what, when. For a marketplace, the actions that matter are data exports, commission changes, vendor account access, payout edits, and bulk operations.

The log has to be tamper-resistant and queryable. "We have logs somewhere in the server" is not an audit trail. You need to answer a security question in minutes, not reconstruct it from raw infrastructure logs after the fact.

Vendor data isolation

Each vendor should see only their own data: their products, their orders, their payouts. That sounds obvious, but multi-vendor plugins bolted onto single-vendor platforms frequently leak data across the boundary - one vendor seeing another's sales figures through an unfiltered API endpoint.

Proper isolation is enforced at the data-model level, not patched at the UI layer. If the separation lives only in the frontend, the API is one crafted request away from exposing everything.

Control over where data lives

For regulated industries and EU operations, data residency and ownership matter. On a closed SaaS platform, your marketplace data sits in the vendor's infrastructure under the vendor's terms.

You cannot fully audit it, you cannot always choose its region, and you cannot extract it cleanly if you leave. Code and data ownership is a security control, not just a commercial preference.

Why SaaS marketplace platforms struggle here

SaaS marketplace platforms optimize for fast onboarding and managed convenience. That model creates structural limits on data security.

You inherit the vendor's permission model - if their RBAC stops at three roles, so does yours. You inherit their logging - if exports aren't logged, you have no way to add it. And you cannot inspect the code that handles your most sensitive data, so you are trusting a black box with your seller relationships.

On a closed platform, your data security ceiling is whatever the vendor decided to build - and you find the limits during an incident, not during evaluation.

How Open Core changes the security equation

An Open Core marketplace platform gives you something SaaS cannot: the ability to inspect, extend, and control the code handling your data.

Mercur

Mercur is an enterprise-grade Open Core marketplace platform - zero license fees, zero GMV fees, full code ownership.

Because the core is open, your security team can audit exactly how access control, data isolation, and exports work - rather than trusting a vendor's marketing claims. You run it on your own infrastructure, in your own region, under your own compliance regime.

The platform ships with role-based access control, vendor data isolation enforced at the data-model level, and an extensible foundation where you can add the audit logging and export controls your security policy requires. You own the code, so your data security ceiling is set by your team, not a vendor's roadmap.

Mercur is deployed across 30+ enterprise commerce projects with $6B+ in client trade volume. See Mercur Enterprise for security and compliance detail, and the marketplace software comparison for how platform types differ on control.

The questions to ask before you commit

Before signing with any marketplace platform, put these to the vendor and require concrete answers.

Can a marketplace manager export the full seller base, and is that export logged? How many distinct roles does the permission model support, and can I scope them by data type? Is vendor data isolation enforced in the data model or only in the UI? Where does my data physically live, and can I extract all of it if I leave? Can my security team audit the access-control code?

If the vendor cannot answer these clearly, that is the answer. Marketplace data security is decided at platform selection - retrofitting it after an incident costs far more than checking for it now.

Frequently asked questions

What is the biggest data security risk in a marketplace?

Uncontrolled export of the seller base. On many platforms any admin user can download all seller contact details and commission terms with no logging and no approval step - a ready-made target list for a competing marketplace.

What is RBAC in a marketplace context?

Role-based access control assigns permissions by job function so each user sees only the data they need. A marketplace needs more than admin/vendor/customer - support, finance, and category roles each require a different, scoped slice of data.

Why does an audit log matter for a marketplace?

It lets you answer who accessed, changed, or exported sensitive data and when. Without it, investigating an incident means reconstructing events from raw infrastructure logs, if they exist at all.

Is an open-source platform less secure than SaaS?

No. Open Core lets your security team audit the actual code handling your data, run it on your own infrastructure, and add controls a closed SaaS platform won't expose. Transparency is a security advantage, not a liability.

Best Multi-Vendor Marketplace Software in 2026: An Architecture-First Comparison

Rigby — Mon, 17 Aug 2026 07:39:41 +0000

Choosing the right marketplace software is a decision that usually locks you in for at least 3-5 years. Most comparison articles list features and pricing tiers - but the real difference between platforms sits one layer deeper: architecture. Whether you pick a SaaS overlay, a self-hosted license or, an open core platform like Mercur it defines changes your cost structure, customization ceiling, and exit options for years. This comparison groups 12 multi-vendor marketplace platforms by how they work - not just what they promise - with cost data and operator insights from teams running these platforms at scale.

What this article covers

Marketplace software is not one category - it is five architecture models with fundamentally different cost curves, customization limits, and scaling characteristics.
SaaS overlay platforms like Mirakl start at $90,000/year plus a ~2% GMV fee - and require a second ecommerce platform underneath, doubling real cost.
Open-source platforms like Mercur eliminate license fees and GMV taxes entirely - your cost stays flat as your marketplace grows.
Plugin-based approaches (Dokan, Webkul) offer the cheapest entry point but hit a ceiling fast for any marketplace beyond basic multi-vendor commerce.

How to think about marketplace software categories

Before comparing individual platforms, understand that "marketplace software" is not one market. It is five fundamentally different architecture models. Each one carries different cost curves, customization limits, and scaling characteristics. Picking the wrong model costs more than picking the wrong vendor within a model.

SaaS marketplace overlays

Platforms like Mirakl and Marketplacer provide marketplace logic - vendor management, order routing, commissions - as a hosted service. They do not handle the storefront, checkout, or payments. You need a separate ecommerce platform underneath (Salesforce, Adobe, SAP).

Trade-off: fastest enterprise deployment, but double-platform cost, GMV-based fees that scale with your success, and architectural lock-in.

Full-stack marketplace SaaS

Platforms like Sharetribe, VTEX, and Nautical Commerce handle both the marketplace logic and the commerce layer in one hosted platform. No second platform needed.

Trade-off: simpler stack, but limited customization, vendor-controlled roadmap, and data lives in their cloud.

Self-hosted and license-based

Platforms like CS-Cart Multi-Vendor, YolKart, and Magento with marketplace extensions. You buy a license, host it yourself, and own the deployment.

Trade-off: more control than SaaS, one-time or annual license cost, but aging tech stacks, heavy maintenance burden, and you need your own DevOps.

Open-source marketplace platforms

Platforms like Mercur (built on Medusa.js) and Bagisto (built on Laravel). No license fee, full code ownership, MIT or similar licensing.

Trade-off: zero licensing cost, unlimited customization, full data ownership - but requires a technical team to deploy and maintain.

Plugin and extension model

Dokan (on WordPress/WooCommerce), Webkul (on Shopify/Magento), MultiMerch (on OpenCart). These add multi-vendor capability to an existing ecommerce CMS.

Trade-off: cheapest starting point, but low ceiling for scale and marketplace logic is an afterthought bolted onto a single-store architecture.

12 multi-vendor marketplace platforms compared

Below is a deeper look at each platform, organized by architecture category. For each one: what it does, who it fits, what it costs (where data is available), and what to consider before committing.

SaaS marketplace overlays

These platforms sit on top of your existing commerce infrastructure. They handle the marketplace layer - vendor management, order splitting, commission management - but leave everything else to a separate system.

Mirakl

The largest enterprise marketplace overlay by market share. Mirakl handles vendor onboarding, order routing, and catalog management as a hosted service. It requires Salesforce Commerce Cloud, Adobe Commerce, or SAP Commerce Cloud underneath.

Base license starts at roughly $90,000 per year. On top of that, Mirakl charges approximately 2% of all marketplace GMV as a transaction fee. For a marketplace processing $25M in annual GMV, the 3-year total cost of ownership exceeds $2.5 million - before add-on modules or customization.

Operators at major European retailers report 3-5 year lock-in contracts with exit penalties, near-zero customization ability, and a sales process that targets executive sign-off before the technical team completes a full evaluation. For the complete cost breakdown, see our Mirakl pricing analysis.

Marketplacer

Australian-based SaaS marketplace platform positioning itself as more flexible and less corporate than Mirakl. Handles both B2C and B2B marketplace models in a single platform.

SaaS pricing - not publicly disclosed, but the entry point sits significantly lower than Mirakl. Stronger for mid-market deals and retailers adding a marketplace channel. Less proven in complex enterprise B2B deployments with heavy integration requirements.

Full-stack marketplace SaaS

These platforms combine the marketplace layer and the commerce engine in one hosted product. No second platform needed - but you trade that simplicity for less control.

Sharetribe

No-code marketplace builder targeting founders and small teams. Sharetribe handles both marketplace logic and the storefront - you can launch in days without writing code.

Plans start at $99 per month. Transaction fees apply on higher tiers. The platform covers rental, service, and product marketplace models out of the box.

Limited customization beyond configuration options. There is a ceiling for complex B2B use cases or marketplaces that need deep integration with external systems. But for speed to market and brand recognition in the "marketplace software" category, Sharetribe leads.

VTEX

Commerce platform with marketplace capabilities built in. VTEX has the strongest presence in Latin America and is expanding into EU and US markets.

Enterprise pricing - not publicly disclosed. Mixed technical reviews from enterprise evaluators outside LATAM. The marketplace module is part of a broader commerce suite, not a standalone product.

Nautical Commerce

Multi-vendor marketplace platform targeting mid-market operators. Full-stack approach that handles commerce and marketplace logic in a single product.

Free tier available for testing. Paid plans scale with usage. Positioning as an alternative to both Sharetribe (more technical) and Mirakl (more accessible and lower cost).

Self-hosted and license-based

You buy a license, host on your own servers, and own the deployment. This gives you more control than SaaS - at the cost of maintaining the infrastructure yourself.

CS-Cart Multi-Vendor

Established self-hosted marketplace platform with a one-time license option. PHP-based, strong vendor management tools, runs on your servers.

License starts at approximately $1,650 one-time for the Multi-Vendor edition. Annual support fees apply after the first year. The UI and codebase feel dated compared to modern headless platforms - but CS-Cart is proven and stable for traditional retail marketplace use cases.

YolKart

Purpose-built marketplace software designed from the ground up for multi-vendor commerce - not retrofitted from a single-store platform. Self-hosted, license-based.

Mid-range pricing sits between plugin-level entry costs and enterprise SaaS. Smaller community and integration options compared to CS-Cart. Strongest for mid-size marketplaces that need marketplace-native features without enterprise overhead.

Magento / Adobe Commerce with marketplace extensions

Enterprise-grade ecommerce platform with marketplace functionality added through extensions like Webkul. Extremely flexible and customizable. Handles complex B2B and B2C commerce.

The challenge: marketplace features are not native to Magento. They are bolted on through third-party extensions, which creates maintenance complexity, upgrade friction, and dependency on extension vendors. Development and maintenance costs are high. For a detailed breakdown of these limitations, see why you should not create a multi-vendor marketplace in Magento.

Open-source marketplace platforms

No license fees, full code ownership, and the freedom to modify anything. Open-source marketplace platforms trade vendor-managed convenience for complete control over your stack, data, and roadmap.

Mercur

Mercur is an enterprise-grade Open Core marketplace platform - zero license fees, zero GMV fees, full code ownership. Built on Medusa.js (MIT), it covers vendor onboarding, commission management, order splitting, split payments, and product catalog natively - no second commerce platform needed.

80% of marketplace functionality ships out-of-the-box. The remaining 20% is customizable for your specific business model - your business logic, your vendor workflows, your data model - without API workarounds or vendor roadmap dependencies.

Deployed across 30+ enterprise commerce projects with $6B+ in client trade volume. Named clients include Bestway (UK) and Marcura/ShipServ. Best fit for companies with technical capacity building B2B or B2C marketplaces who want full ownership and no transaction tax on growth. See Mercur features and Mercur enterprise.

Bagisto

Open-source marketplace built on Laravel (PHP). Developer-friendly for teams already working in the Laravel stack. Community-driven with a growing extension marketplace.

Smaller feature set and community compared to Medusa-based alternatives. Requires significant technical expertise to deploy and maintain at scale. Strongest for PHP teams building custom marketplace experiences within a familiar framework.

Plugin and extension model

These solutions add multi-vendor functionality to an existing ecommerce CMS. The cheapest way to test the marketplace model - but marketplace logic is a layer on top, not the foundation.

Dokan (WordPress/WooCommerce)

Multi-vendor marketplace plugin for WooCommerce. Turns any WordPress site into a marketplace with vendor dashboards, commission management, and order splitting.

Pricing starts at approximately $149-499 per year. The WordPress and WooCommerce plugin library provides a massive extension library for payments, shipping, and marketing. Performance degrades with large vendor counts. Security depends on WordPress core and plugin maintenance discipline.

Webkul (Shopify/Magento/BigCommerce)

Multi-vendor extensions for existing ecommerce platforms. Webkul adds marketplace logic on top of Shopify, Magento, or BigCommerce through dedicated modules.

Quick to deploy for teams already running one of these platforms. But limited by the host platform's architecture and data model. For the full analysis, see why the Webkul multi-vendor marketplace was never built to run your business.

WooCommerce with multi-vendor plugins

Open-source ecommerce on WordPress with various marketplace plugins beyond Dokan - including WC Vendors, WCFM, and YITH. Familiar territory for WordPress teams.

Multi-vendor logic is always an add-on, never core architecture. This means vendor management, order splitting, and commission handling depend on third-party plugin quality and compatibility. Viable for MVPs and testing the marketplace model. Not built for scale.

What marketplace software costs in practice

Pricing pages tell one story. The total cost of ownership over three years tells another. The gap between the two is where most procurement decisions go wrong - evaluating the entry price without modeling how costs scale with marketplace growth.

The cost trajectory matters more than the starting price. SaaS overlay platforms get more expensive as your marketplace grows because GMV-based fees scale with revenue. Open-source and self-hosted platforms carry a flat cost curve - infrastructure cost does not increase proportionally with transaction volume.

For a concrete example of how these layers compound: a mid-size enterprise running $25M in annual GMV through Mirakl pays $2.5 million or more over three years - base license plus GMV fee plus the underlying commerce platform plus implementation. An open-source deployment of the same marketplace carries fixed infrastructure and maintenance costs regardless of how much GMV flows through the system. Full cost analysis: Mirakl pricing in 2026.

How to evaluate marketplace software for your business

Before committing to any platform, run through this framework. It covers the blind spots that marketplace operators wish they had caught before signing multi-year contracts.

Start with architecture, not features. Does the platform handle commerce natively or need a separate engine underneath? This single question changes your total cost by 2-3x and determines how many systems your team maintains.
Model cost at your growth rate. What do you pay at 2x, 5x, and 10x your current GMV? If the answer breaks your unit economics at scale, the platform is not viable long-term - regardless of how attractive the entry price looks.
Check the customization ceiling on your use case. Not the demo. Not the slide deck. Your actual business logic, your category structure, your vendor workflows. Ask: how many custom fields can I add to an order? What happens when I need a vendor flow the platform does not support natively?
Assess data ownership and portability. Can you export seller records, transaction history, catalog data, and customer information? Or does it stay locked in the vendor's cloud with no migration path?
Read the contract terms line by line. Length, exit clauses, auto-renewal conditions, and renewal pricing escalation. A 5-year lock-in with exit penalties is a fundamentally different commitment than a flexible annual agreement.
Test vendor onboarding end-to-end. Marketplace success depends on supply-side adoption. If onboarding is friction-heavy - manual approvals, limited self-service, poor documentation - your growth bottleneck is the platform, not the market.

Summary

Marketplace software is not one category. It is five architecture models - SaaS overlay, full-stack SaaS, self-hosted, open-source, and plugin-based - each with fundamentally different cost structures, customization limits, and scaling characteristics.

Enterprise SaaS overlays like Mirakl give you brand credibility and fast deployment, but extract a growing share of your revenue through GMV fees and require a second commerce platform underneath. Full-stack SaaS platforms like Sharetribe offer the fastest launch for founders, but carry customization ceilings. Self-hosted solutions like CS-Cart give you control with an aging tech stack. Plugin approaches offer the cheapest entry but hit limits fast.

Open-source platforms like Mercur take a different approach entirely - zero license fees, zero GMV fees, and full code ownership. Your cost stays flat as your marketplace scales. The trade-off is that you need technical capacity or an implementation partner to deploy and maintain it.

The right choice depends on where you sit: your team's technical capacity, your growth trajectory, your integration requirements, and how much of your marketplace economics you want to own.

Frequently asked questions

What is the best multi-vendor marketplace software?

It depends on your architecture needs and growth model. For enterprise B2B/B2C at scale, Mirakl leads on brand recognition but costs $2.5M+ over three years. For founders and MVPs, Sharetribe offers the fastest launch. For teams wanting full ownership with no license or transaction fees, Mercur provides 80% of marketplace features out-of-the-box as open-source software built on Medusa.js.

How much does marketplace software cost?

The range spans from $149 per year (Dokan plugin) to $500,000+ per year (Mirakl enterprise). The real cost depends on architecture model. SaaS overlays require a second commerce platform underneath, adding $50,000-200,000 per year. Open-source platforms like Mercur have zero license fees - cost is implementation and hosting only.

What is the difference between a marketplace platform and ecommerce software?

Ecommerce software manages one seller's catalog, checkout, and fulfillment. Marketplace software adds multi-vendor management on top: commission structures, order splitting across sellers, split payments, and vendor onboarding. Some platforms (Mercur, Sharetribe) handle both natively. Others (Mirakl) only provide the marketplace layer and require a separate ecommerce engine underneath.

Can I add marketplace functionality to my existing ecommerce site?

Yes - through plugins (Dokan for WooCommerce, Webkul for Shopify) or overlays (Mirakl on top of Salesforce/Adobe). But bolt-on marketplace logic hits a ceiling. For complex multi-vendor operations with custom commission models, vendor-specific workflows, and deep integrations, purpose-built marketplace software gives you more control and scalability.

Is open-source marketplace software enterprise-ready?

Yes. Mercur is deployed across 30+ enterprise commerce projects handling $6B+ in trade volume. Open-source means you own the code, database, and roadmap - not that the software is unsupported. The trade-off is that you need a technical team or implementation partner to deploy, customize, and maintain it.

Retail Digital Transformation: What Changes Operationally When Going From Retailer to Platform

Rigby — Thu, 13 Aug 2026 10:05:43 +0000

Retail digital transformation changes how a retail business operates, and software is only one part of that. Most programmes are budgeted as technology and then discover that the harder half is operational.

The transformation that changes a retailer's economics most is also the one least likely to appear in an IT roadmap. It happens when you stop selling only your own stock and start hosting other sellers alongside it.

That move turns a retailer into a platform. It also creates a set of processes, roles, and numbers that nobody in the organization owned before.

In this article, you will learn:

What is retail digital transformation, and which areas do retailers fund first?
Which change in the retail model shifts who funds your inventory?
What is marketplace operations?
Which 6 functions change when a retailer becomes a platform?

Key takeaways

Retail digital transformation is usually funded as a technology programme, while the returns depend on an operating model change.
Adding third-party sellers is the transformation that moves the economics, because it changes who funds the assortment.
Marketplace operations is the discipline that appears once sellers are inside your catalog, and most retail organizations have no owner for it on day one.
Six functions change materially: category management, catalog governance, customer service and disputes, fulfilment coordination, finance and payouts, and seller performance.

What is retail digital transformation?

Retail digital transformation is the redesign of how a retailer sells, serves, and sources, using digital systems as the means rather than the goal. It covers customer-facing channels, the data underneath them, the automation of manual work, and the replacement of systems that block change.

The label is broad enough to describe almost any project, which is part of the problem. Two retailers can both be “in transformation” while one is replatforming a website and the other is rebuilding how its categories are bought.

Digital transformation trends in retail come and go, but across the retail sector most digital transformation initiatives start from the same pressure: changing customer expectations that retail stores built for a pre-digital age were never designed to meet. A digital transformation strategy usually answers that by integrating digital technologies into existing processes, one function at a time.

Embracing digital transformation at the level of tooling leaves the retail business model untouched, which is why retail management can complete a long programme and still face the same ceiling.

Which 4 areas do retailers start their digital transformation with?

Four areas absorb most of the early budget, and Deloitte's survey of 330 retail executives shows where the attention sits.

Omnichannel experience

Unifying the store, app, and web journey is the most common starting point, named by 46% of retail executives in Deloitte's 2026 outlook. The work is visible, the benefit is easy to explain internally, and the buyer notices it.

This is where most digital technologies land first. Mobile apps and mobile devices in the aisle, modern POS systems that can see an online order, collection points between physical stores and the website, and augmented reality for products people want to picture before buying.

The goal is one customer experience across online and offline channels, so customer journeys survive a switch between multiple channels.

Loyalty and personalisation

Loyalty programs came second at 36% in the same survey. Both this and omnichannel are ways to get more from the customers you already have.

The engine underneath is customer data. Customer data platforms pull purchase history, browsing, and customer interactions into one profile, and data analytics turns that into personalized shopping experiences and targeted marketing campaigns.

Done well, it lifts customer loyalty, customer retention, and customer satisfaction at the same time. Reading customer behavior accurately is what separates a relevant offer from an irritating one, and consumer behavior moves faster than most segmentation models get rebuilt.

Data architecture and legacy replacement

Almost half of retailers say their legacy systems are slowing down innovation. Replacing them is expensive, invisible to customers, and usually the precondition for everything else.

The blocker is rarely a missing report. It is data silos: the ERP, the webshop, the loyalty database, and the warehouse system each holding a version of the same fact.

Connected architecture is what turns raw records into actionable insights, and what lets data-driven decision-making replace opinion in a buying meeting. Digital tools built on top of siloed data produce confident answers from incomplete inputs.

Automation of manual operations

The fourth area is taking repetitive work out of buying, planning, and support. Bain estimates that 70% to 90% of administrative buying activities can be automated, which frees merchants for judgement calls rather than data entry.

Artificial intelligence and machine learning do most of the work here. Predictive analytics reads market trends and sales history to forecast demand; demand forecasting feeds inventory management systems that act on it, and dynamic pricing adjusts to competitor moves without a person in the loop.

The same technologies reach across supply chain processes and store operations, and the business case is usually built on operational efficiency and cost savings. New technologies of this kind pay back fastest where the work was repetitive, and the rules were already written down. Emerging technologies with less defined rules take longer to earn their place.

Why do omnichannel, data, and automation work rarely raise the growth ceiling?

Each of those four areas makes an existing model run better. None of them changes what the model is.

A retailer that finishes all four still grows the same way: buy stock, attract demand, sell the stock, repeat. The improvements lower friction and cost per transaction, and that is worth having, but the ceiling stays where it was.

The evidence on technology-led programmes is sobering. In BCG's 2025 study of more than 1,250 companies, only 5% were achieving returns at scale, and 60% reported no material gain at all despite substantial investment. That study covers AI transformation rather than platform transformation specifically, so read it as a signal about technology programmes in general.

BCG's own diagnosis of the failures points away from tooling. The binding constraint it names first is leadership commitment, which is an operating question rather than a technical one.

Digital transformation equips retailers with better instruments for the model they already run. A successful digital transformation measured on delivery can still leave retail strategy exactly where it was, because digital strategies and retail businesses get judged on different horizons.

Better digital technology produces data-driven insights and improved customer service, and both are worth having. Neither changes who funds the assortment, so customer expectations keep rising against a cost base that rises with them.

What does retail digital transformation change?

The transformations that move a retailer's economics change one of three things: who pays for the inventory, who does the work, or who the customer buys from.

Only one of those is available without either a large capital commitment or a headcount reduction.

Which change in the retail model shifts who funds your inventory?

Opening your catalog to third-party sellers changes who carries the stock. The seller buys it, stores it, and absorbs the loss when it does not sell, while the product still appears on your site and the demand is still captured on your domain.

This is the change our comparison of marketplace vs eCommerce growth models describes at the level of the growth curve. And the related mechanics sit in our breakdowns of the seven types of inventory risk and of why adding more SKUs stops increasing revenue.

The channel is no longer unusual. BCG puts marketplaces at 67% of global eCommerce sales, up from 40% a decade earlier, and Eurostat found that 45% of EU enterprises selling online already use a marketplace in its 2024 reference year.

Why is becoming a platform an operating model change?

A retailer is built around decisions it makes itself. Buyers choose the assortment, the warehouse holds it, service answers for it, and finance recognises revenue on it.

A platform coordinates decisions other people make. You set the rules, monitor whether sellers follow them, and answer to the buyer for outcomes you did not directly produce.

That difference shows up in which numbers somebody is accountable for. Our article on the marketplace platform transition covers how to recognise that the shift has already happened. The rest of this article covers what you run once it has.

What are the benefits of digital transformation in the retail industry?

The operational case for adding third-party supply is about what stops scaling with your catalog.

Your assortment grows without new working capital

Every product a seller lists is a product you did not buy. The listing appears in your catalog, the stock sits in the seller's warehouse, and your purchasing budget is untouched.

BCG describes marketplaces as requiring a small capital investment to launch while contributing an EBITDA margin of 7% to 9%. The mechanism is simple: you earn a commission on a transaction you did not fund.

Operational cost stays flat as the catalog grows

In a retail model, more products means more forecasts, more purchase orders, more receiving, and more stock to count. Those costs rise roughly in step with the catalog.

In a marketplace model, adding a seller adds onboarding effort once, and that seller then carries their own forecasting and handling. Your cost curve flattens because the work that scales with product count moved to the party holding the product.

Coordination, monitoring, and dispute handling grow instead, and those are the functions the rest of this article describes.

Inventory management and supply chain planning shrink in proportion to how much of the catalog you stop owning. The work does not disappear from the market; it moves to the party that holds the goods.

Testing a new category costs onboarding instead of inventory

A retailer testing a category has to buy into it. The test costs a purchase order, a forecast, and several months before the answer arrives.

A platform testing a category onboards two or three sellers who already stock it. The cost of being wrong falls to the effort of removing them again, which changes how often you are willing to try.

What is marketplace operations and what does it cover?

Marketplace operations is the discipline of running a catalog and an order flow that you do not fully control, to a standard the buyer holds you to. It covers the rules sellers work within, the monitoring that checks they do, and the resolution of everything that falls between you and them.

In a small operation, one person holds it alongside another job, and in a large one it becomes a department with its own reporting line.

Six areas make up the working scope, and each maps to a function that already exists in a retail business but now has a second version.

Seller lifecycle covers onboarding, verification, activation, and offboarding.
Catalog governance covers the standards listings must meet and the enforcement behind it.
Order operations covers routing, exception handling, and the cases where one basket splits across several fulfilment paths.
Service and disputes covers who answers the buyer and how a disagreement between buyer and seller ends.
Commercial operations covers commission configuration, fee changes, and the payout run.
Performance management covers the numbers each seller is held to and what happens when they miss.

6 functions that change when a retailer becomes a platform

None of these functions disappears. Each gains a second version that runs on different inputs and answers to different numbers.

1. Category management and assortment

A buyer used to control the range by choosing what to purchase. On a platform, the same person controls the range by choosing who may sell in it.

The job shifts from selecting products to setting entry criteria and curating a seller mix. That includes deciding where third-party supply complements your own range and where it competes with it.

Bain's estimate that most administrative buying work can be automated matters here, because the time released is exactly the time this new work requires.

2. Catalog and product data governance

Seller-submitted product data arrives inconsistently, because the seller optimises for speed of listing rather than for your content standard. Left alone, the catalog degrades in searchability and raises returns from products that arrive different from their description.

The controls are a published standard, validation at the point of listing, and a completeness score each seller can see.

Our breakdown of marketplace catalog management covers the tooling side of this in detail.

3. Customer service, returns, and disputes

A buyer who has a problem contacts you, whichever party sold the item. The resolution often sits with the seller, and the gap between those two facts is where service quality is lost.

Three things have to be defined before volume arrives: who replies first, how long the seller has to resolve, and what happens when they do not. A dispute with no time limit becomes a dispute with no resolution.

Returns need the same treatment, because your own policy and each seller's policy will differ unless you set a floor that applies to everyone.

4. Fulfilment coordination across 1P and 3P

Your own stock ships on your SLA from your warehouse. Third-party items ship on each seller's schedule from their location, so one order can carry three delivery dates while the buyer expects one.

The work is coordination rather than logistics. Order routing, partial cancellation, and tracking aggregation all need rules that hold without a person deciding each case.

Our article on the split basket problem sets out the ten places where 1P and 3P diverge on a single order.

5. Finance, commissions, and payout runs

Retail finance recognises revenue on goods it owns. Platform finance recognises a commission on a transaction between two other parties, splits the money, and schedules a payout.

The payout run becomes a recurring operational process with its own calendar and reconciliation, rather than an accounting entry. Refunds, partial refunds, and cross-border tax each need a defined path through it.

Commission rates sit in the same territory. BCG reports operators typically earn 8% to 15% on transactions.

6. Seller performance management

Supplier management ran on periodic reviews because supply was slow-moving and contractual. Seller performance runs continuously, because a seller can degrade the buyer experience this week.

Published thresholds do the work. For example, Walmart requires sellers to hold an order defect rate below 2% and to answer customer emails within 24 hours, both written into the seller service-level agreement.

A threshold a seller can read is a threshold you can enforce without a negotiation. Acquisition and retention of sellers is a separate motion, covered in our guide to vendor hunting and farming.

5 best practices for running a marketplace alongside your own retail

1. Encode every rule once in the platform

Shipping windows, return policies, cancellation rights, and dispute deadlines each need one place where they are defined. A rule that lives in a policy document gets applied differently by every person who reads it.

2. Give marketplace operations one accountable owner

Name the owner before launch rather than after the first reconciliation problem. The role needs authority over the rules and access to the numbers, and it needs a seat where category, service, and finance decisions are made.

3. Publish seller thresholds before you scale seller count

Thresholds are easy to set with ten sellers and hard to introduce with two hundred. Publish them in the seller agreement, report against them, and apply the same consequence to everyone.

4. Measure the catalog standard rather than describing it

A completeness score per seller, visible to that seller, moves listing quality without a conversation. Sellers respond to a number attached to their own account far faster than to a guideline.

5. Separate 1P and 3P targets

A category buyer measured on first-party revenue will treat third-party supply in the same category as a threat. Give the two sides different targets, or the range you built will be undermined by the people running it.

How does Mercur handle the operational load of a marketplace?

Mercur is a marketplace platform under an MIT license that comes with a storefront for buyers, a vendor panel, an admin console, and integrations – with enterprise-grade governance & control.

It can run alongside your existing commerce stack rather than replacing it, so the retail operation you already have keeps working while the marketplace layer is added next to it.

Ownership is built into the data model. Every inventory item, stock location, and shipping profile is linked to a specific seller, so the stock records sit with the party holding the goods.

A single customer basket splits into one order per seller, each with its own shipping method, with commission calculated per line. That covers the coordination described in section 4 and the commission handling in section 5 as platform behaviour rather than as manual work.

Around 80% of marketplace functionality is ready on day one, with the remaining share built as modules for your own rules. The code is available on GitHub if you want to review how the seller scoping works, or you can explore a demo of the full stack.

Summary: What changes when you stop being only a retailer?

Retail digital transformation is usually planned as a technology programme and judged on whether the systems shipped. The programmes that change the growth curve are the ones that change the operating model underneath.

Adding third-party sellers is the change with the largest economic effect. Marketplace moves the funding of your assortment off your balance sheet and creates a discipline your organization has never staffed.

If you are planning that shift and want to work through which functions in your organization change first, talk to a marketplace expert.

FAQ on retail digital transformation and marketplace operations

What are the key benefits of digital transformation?

The benefits of digital transformation are an assortment that grows without new working capital, a cost curve that stops rising with product count, and category tests that cost onboarding rather than inventory. Customer-facing benefits such as omnichannel convenience and personalisation improve an existing model. Model-level benefits change what the business is able to do at all.

What do marketplace operations do?

Marketplace operations keep a catalog and an order flow you do not fully control running to a standard the buyer holds you to. Day to day, that means onboarding and verifying sellers, enforcing the catalog standard, routing orders that split across several sellers, resolving disputes between buyer and seller, configuring commission and running payouts, and holding every seller to published performance thresholds. The function exists from the first third-party order, whether or not anyone has been given the job.

What is a marketplace and how does it work?

A marketplace is a store where third-party sellers list and fulfil their own products alongside, or instead of, the operator's own stock. The operator owns the demand, the customer relationship, and the rules, while the seller owns the inventory, the pricing, and the shipment. When a buyer orders, the basket splits into one order per seller, each ships on its own terms, and the operator earns a commission on the transaction rather than a margin on goods it bought. That is how a marketplace expands assortment without consuming the operator's working capital.

What are the 4 main areas of digital transformation?

In retail, the four areas that absorb most of the early budget are omnichannel experience, loyalty and personalisation, data architecture and legacy replacement, and the automation of manual operations. Deloitte's 2026 survey of 330 retail executives puts omnichannel at 46% and loyalty programs at 36%, while 44% say legacy systems are slowing innovation. All four make an existing model run better, and none of them changes what the model is.

What is retail transformation?

Retail transformation is a change to how a retail business operates or earns, whether or not technology is the driver. Digital transformation is the subset where digital systems are the means, and it is the version most programmes fund. The transformations that move a retailer's economics change one of three things: who pays for the inventory, who does the work, or who the customer buys from.

Sources

What Is an Online Marketplace? A Guide for B2B Teams

Rigby — Wed, 12 Aug 2026 12:13:10 +0000

Someone at the board meeting said "we should launch a marketplace." Now you need to understand what that actually means - fast.

An online marketplace is a platform where multiple third-party sellers offer products or services to buyers, while the platform operator manages infrastructure, payments, and rules. Think Amazon or Allegro at the B2C end. At the B2B end: procurement hubs, wholesale platforms, industry-specific supply networks.

This guide explains what an online marketplace is, how it differs from a standard eCommerce store, and - critically - what it means for your tech stack if you're a B2B team considering the model.

What is an online marketplace

A marketplace connects buyers and sellers on a single platform. The operator doesn't own the inventory - it creates conditions for transactions and takes a cut: a commission, a subscription fee, or both.

Three parties are always involved: the platform operator, the seller (vendor), and the buyer. That three-sided model is what separates a marketplace from a regular online store, where a single business owns and sells its own inventory.

The operator sets the rules. Who can sell, what commission structure applies, how disputes are handled, how payments get distributed. The seller manages their own catalog and fulfillment. The buyer sees a unified storefront.

Types of online marketplaces

The marketplace model covers a wide range of formats. The structure varies by who's buying, what's being sold, and how the platform earns.

B2C marketplace

The most familiar format. A single storefront with multiple third-party sellers - Amazon, Allegro, Zalando. Buyers don't always know (or care) which seller they're buying from. Volume and selection drive the model.

B2B marketplace

A procurement or supply platform where businesses buy from other businesses. Examples include industrial supply networks, wholesale platforms, and distributor hubs. The dynamics differ from B2C: longer purchase cycles, invoice-based payments, net-30/60 terms, and approval workflows before orders are placed.

For B2B companies with existing supplier networks, the marketplace model offers a structural shift: you become the hub rather than one of many buyers.

Service marketplace

Platforms connecting buyers with service providers - logistics contractors, maintenance teams, freelancers. The "product" is time or capacity, not a physical SKU. Settlement happens after service delivery, which creates different payment and dispute mechanics than product-based marketplaces.

Hybrid marketplace (1P + 3P)

Retailers like Decathlon or MediaMarkt run both first-party (1P) inventory and third-party (3P) sellers on the same storefront. This creates operational complexity: different return policies, different delivery timelines, different seller quality standards - all visible to the same buyer in a single checkout.

Marketplace vs eCommerce: what's actually different

An online store and a marketplace look similar to the buyer. Under the hood, they're different systems serving different business models.

Revenue model. In a standard eCommerce store, you buy inventory and sell it at a margin. In a marketplace, you earn commission on transactions you never stocked. The financial risk shifts - you don't own the inventory, but you do own the platform and its rules.

Operations. Running a marketplace means running vendor operations: onboarding sellers, auditing catalog quality, managing disputes, splitting orders across multiple fulfillment streams, and distributing payments to multiple parties. None of these processes exist in single-vendor eCommerce.

Architecture. A traditional eCommerce platform is built around one seller, one catalog, one checkout flow. A marketplace requires a multi-tenant data model - every vendor has their own product catalog, their own order stream, their own payout account. That's a fundamentally different architecture, not an extension of what single-vendor platforms do.

When does a marketplace model make sense for B2B?

The marketplace model isn't the right fit for every B2B company. It fits when specific conditions are present.

You have an existing supplier network. If you already work with 20+ suppliers and manage procurement manually, a marketplace platform structures those relationships and automates the operational layer: catalog sync, orders, invoicing, settlement.

Your catalog is too wide to own. Carrying inventory for a 100,000+ SKU assortment means warehouse risk, working capital tied up in stock, and logistics complexity that scales faster than revenue. A marketplace lets you extend assortment without owning it.

You want to become the hub. A B2B marketplace positions you as the central point in your supply chain - the place where your industry transacts. That platform positioning is harder to replicate than product margin.

Your buyer expects a consolidated experience. If enterprise buyers are sourcing from 8 different suppliers, a marketplace gives them a single PO, a single invoice, and a single support contact. That purchasing convenience builds retention.

Why standard eCommerce platforms aren't built for marketplaces

B2B teams typically hit the same wall: the assumption is that existing Shopify or Magento infrastructure can be extended for marketplace functionality. It can't - not without building a second platform alongside the first.

Shopify

Shopify is architected around a single merchant selling their own inventory. Multi-vendor plugins exist, but they're add-ons to a single-merchant foundation. What you get is a workaround:

No native vendor onboarding with KYC and approval workflows
No commission engine (percentage splits, tiered structures, category-specific rates)
No native order splitting - one order from two vendors creates one fulfillment stream, not two separate vendor streams
No vendor-specific dashboards with order management and payout history
No settlement layer that distributes payments to multiple parties after a split

The moment multi-vendor operations at scale are needed, you're building custom infrastructure on a platform not designed for it.

Magento

Magento gives you more flexibility than Shopify - open source, extensible, customizable. But building marketplace functionality on Magento means 12-18 months of custom development: a custom vendor portal, custom commission logic, custom settlement, custom catalog isolation per vendor.

Every module you build is technical debt you maintain. Magento doesn't have a concept of "vendor" - you're teaching it. When Magento releases updates, your custom marketplace layer breaks first.

We cover the full breakdown in Why You Shouldn't Build a Marketplace in Magento.

Shopify and Magento were designed for one seller, one catalog, one payout. Adapting them for multi-vendor means building a second platform on top of the first.

What marketplace-specific functionality actually requires

A proper marketplace stack needs capabilities that standard eCommerce platforms don't ship with.

Vendor onboarding and KYC. Sellers don't appear automatically - they register, get verified, and go through an approval flow. That process (identity checks, tax data, bank account verification, contract acceptance) needs to be native to the platform, not bolted on through integrations.

Commission engine. Every marketplace has a revenue model. Whether it's a flat percentage, category-specific rates, tiered structures based on GMV, or subscription-based listing fees - the platform needs to calculate, track, and reconcile commissions across all transactions in real time.

Order splitting. When a buyer orders from three different vendors in one cart, that creates three separate fulfillment streams. The platform needs to split the order, route each part to the right vendor, and track fulfillment independently - while presenting a unified status to the buyer.

Split payments and settlement. Revenue from a single transaction gets distributed between the platform operator and the seller. That requires a settlement layer: holding funds, calculating the split, applying commission, and paying out vendors on a defined schedule.

Dual-interface architecture. A marketplace needs two separate product experiences: a buyer-facing storefront and a vendor-facing dashboard. The vendor dashboard covers product uploads, order management, payout tracking, and performance metrics. These aren't variations of the same UI - they serve completely different workflows.

Marketplace platforms built for this

Standard eCommerce platforms require heavy customization to support marketplace operations. Purpose-built marketplace platforms start from the right architecture. The trade-off is between control, speed, and cost. See the full comparison of multi-vendor marketplace software for a detailed architecture-first breakdown.

SaaS marketplace platforms (Mirakl, Sharetribe)

Fast to deploy, managed infrastructure, no hosting overhead. The cost: enterprise license fees starting around $90,000/year, GMV-based pricing that scales with your transaction volume, and limited ability to customize vendor workflows or business logic outside what the vendor's roadmap allows.

Open Core: Mercur

Mercur is an enterprise-grade Open Core marketplace platform - zero license fees, zero GMV fees, full code ownership.

It ships with the full marketplace stack out-of-the-box: vendor onboarding, commission management, order splitting, split payments, and product catalog per vendor. 80% of marketplace functionality is production-ready from day one. The remaining 20% is customizable for your specific business model - your vendor workflows, your commission structures, your data model - without working around platform constraints.

Deployed across 30+ enterprise commerce projects with $6B+ in client trade volume.

For B2B teams evaluating the architecture: Mercur features and Mercur Enterprise.

Frequently asked questions

What is the difference between an online marketplace and an eCommerce store?

An eCommerce store sells products owned by a single merchant. A marketplace hosts multiple third-party sellers, takes a commission on transactions, and doesn't own the inventory. The platform operator manages the rules, payments, and infrastructure.

Can Shopify be used as a marketplace platform?

Shopify is architected for single-merchant retail. Multi-vendor plugins exist but lack native commission engines, order splitting, and vendor settlement. For production marketplace operations at scale, purpose-built platforms are more practical.

What does a B2B marketplace need that B2C doesn't?

Invoice-based payments (net-30/60), approval workflows for purchase orders, contract pricing per buyer, and more complex onboarding (company verification, tax IDs, credit terms). The B2B buyer journey involves multiple stakeholders and a longer decision cycle.

How long does it take to build a marketplace?

With a purpose-built platform like Mercur (80% out-of-the-box), an MVP marketplace can go live in 4-6 months. Building on top of a general-purpose eCommerce platform typically takes 12-18 months of custom development.

What is an Open Core marketplace platform?

Open Core means the core platform is open source - free to use, modify, and deploy - while enterprise features (advanced integrations, SLA-backed support, hosted infrastructure) are available commercially. Mercur operates on this model: no license fees on the core, commercial options for enterprise requirements.

Vendor Hunting and Farming: Acquire and Retain Sellers

Rigby — Wed, 12 Aug 2026 12:11:59 +0000

You launched the marketplace. You have 20 vendors. And now you're stuck - acquisition stalled, onboarding takes three weeks per seller, and your best vendors are going quiet.

Acquiring and retaining marketplace sellers needs a repeatable system, not ad-hoc hustle. The teams that scale treat seller growth as two distinct disciplines: hunting (acquiring new sellers) and farming (growing and retaining the ones you have). They run on different motions, different metrics, and different owners.

This guide breaks down both, plus the marketplace seller onboarding flow that connects them - the step where most marketplaces quietly lose the sellers they worked hard to win.

Hunting and farming are two different jobs

Most marketplaces treat seller growth as one undifferentiated activity: get more sellers. That framing is why they stall.

Hunting is outbound acquisition - finding, pitching, and signing new sellers. It rewards volume, persistence, and a sharp value proposition. Farming is account management - activating, growing, and retaining existing sellers. It rewards relationships, data, and operational support.

The skills barely overlap, and trying to run both from the same playbook caps you early. A hunter chasing logos has no time to nurture a top seller's catalog. A farmer optimizing existing accounts isn't filling the top of the funnel.

Hunting: how to find marketplace sellers

Seller acquisition follows the same logic as B2B sales. You need a target list, a reason to join, and a low-friction path to yes.

Build a target seller list

Start with the sellers your buyers already want. Look at search queries on your platform with no results, categories with thin supply, and the vendors your competitors feature.

Segment the list by value. A seller with broad catalog depth and reliable fulfillment is worth more than ten hobby sellers. Acquisition effort should follow expected GMV contribution, not seller count.

Sharpen the seller value proposition

A seller's first question is "what's in it for me?" The answer has to beat their alternative - their own store, Amazon, or a competing marketplace.

The strongest pitches lead with buyer demand the seller can't reach alone, lower effort than running their own channel, and transparent economics. If your only pitch is "list with us," you're competing on commission rate alone - a race you lose to platforms with deeper pockets.

Lower the cost of saying yes

Every step between "interested" and "first product live" loses sellers. The biggest lever in hunting is not the pitch - it's how fast a seller can go from signup to selling.

This is where hunting hands off to onboarding, and where most acquisition gains leak away.

Marketplace seller onboarding: the make-or-break step

Onboarding is where acquired sellers become active sellers - or churn before they ever list a product. A three-week onboarding is a leak in the funnel, not a formality.

Registration and verification

Sellers verify identity, provide business and tax details, and link a payout account. This step has to be thorough enough for compliance and fast enough that sellers don't abandon it.

The balance depends on your risk profile. A high-trust B2B network can streamline verification; an open consumer marketplace needs stricter KYC. Match verification depth to actual risk - over-verifying low-risk sellers is a silent churn driver.

Product import without friction

The first real action a seller takes is listing products. If that means manual entry of 500 SKUs one by one, most sellers stop.

Offer bulk import, a clear template, and validation that catches errors before they become support tickets. Design the flow for your least technical seller - the one with a spreadsheet and no developer.

Time to first sale

The metric that predicts seller retention is time to first sale. A seller who sells in week one stays; a seller who waits a month for activation drifts away.

Compress that window. Pre-approve onboarding-ready sellers, surface their products in relevant search and category pages quickly, and remove every avoidable delay between listing and visibility.

Farming: growing and retaining sellers

Acquiring a seller is expensive. Losing them after one quarter wastes the entire investment. Farming protects and compounds it.

Segment your seller base

Not all sellers deserve equal attention. Segment by contribution - a common model is diamond, gold, and silver tiers based on GMV, reliability, and growth potential.

Your top tier gets proactive account management: performance reviews, promotional placement, early access to features. A small share of sellers drives most of your GMV - protect them like the top accounts they are.

Give sellers the tools to self-serve

Top sellers want to manage their own business: update inventory, adjust prices, track orders, and see payouts without raising a ticket. A capable vendor dashboard is the difference between a scalable marketplace and a support bottleneck.

Every action a seller can complete themselves is one your team doesn't handle. As seller count grows, self-service is what keeps operations flat instead of linear.

Track seller health

Farming runs on data. Watch leading indicators - listing activity, fulfillment SLA, response time, and sales trend - and intervene before a seller goes dormant.

A seller whose listings haven't changed in 60 days is a churn signal. Reach out before they leave, not after they've gone.

The platform underneath both motions

Hunting and farming are operational disciplines, but they run on platform capability. Slow onboarding, weak vendor dashboards, and no seller analytics will cap even a great team.

Mercur

Mercur is an enterprise-grade Open Core marketplace platform - zero license fees, zero GMV fees, full code ownership.

It ships with the seller-side stack out-of-the-box: vendor onboarding with verification, bulk product import, and a vendor dashboard covering product management, orders, and payout history. 80% of marketplace functionality is ready on day one, so your team spends time on seller relationships, not on building the tooling that supports them.

Because it's Open Core, you can extend the onboarding flow and seller analytics to fit your acquisition and retention model - tiered seller experiences, custom health metrics, automated activation nudges. Mercur is deployed across 30+ enterprise commerce projects with $6B+ in client trade volume. See Mercur features and the marketplace development guide.

Frequently asked questions

What is the difference between vendor hunting and farming?

Hunting is outbound acquisition of new sellers - building a target list, pitching, and signing them. Farming is account management of existing sellers - activating, growing, and retaining them. They use different skills, metrics, and owners.

How do you find sellers for a marketplace?

Start with demand your buyers already show - zero-result searches, thin categories, and vendors your competitors feature. Segment by expected GMV contribution and prioritize the sellers who add the most catalog depth and reliability.

Why do marketplaces lose sellers during onboarding?

Friction. Slow verification, manual product entry, and long time-to-first-sale cause sellers to abandon before they ever list. Compressing the path from signup to first sale is the single biggest retention lever.

How do you retain top marketplace sellers?

Segment the base by contribution, give top sellers proactive account management and promotional support, equip all sellers with self-service tools, and track health metrics to intervene before a seller goes dormant.

How to Develop a Custom Marketplace: Step-by-Step Guide

Rigby — Wed, 12 Aug 2026 12:03:56 +0000

You have the buy-in. The board approved the initiative, someone owns it as a product, and now the question is: where do you actually start?

Custom marketplace development is not adding a vendor tab to an existing store. It's a distinct system with its own data model, its own operational flows, and its own set of integrations. Most teams underestimate this - and end up either over-scoping the MVP or picking the wrong tech stack for the model they're building.

This guide covers six steps from decision to launch: how to define your model, choose your stack, scope an MVP, plan integrations, build vendor onboarding, and get to market fast.

What "custom marketplace" actually means

"Custom marketplace" doesn't mean building everything from scratch. It means choosing a foundation that fits your model - and building the 20% that's specific to your business on top of it. The alternative is a SaaS platform where you configure within fixed limits and pay per transaction regardless of margin.

The defining characteristic of a custom marketplace is ownership. Your codebase, your data, your vendor relationships, your commission logic. You're not renting infrastructure - you're building a platform asset.

Step 1: Define your marketplace model

Before choosing any technology, define three things.

Who sells and who buys. B2B (businesses buying from businesses), B2C (consumers buying from businesses), or hybrid. This determines your onboarding complexity, payment flows, and catalog requirements.

How you earn. Commission on GMV, subscription fee per seller, listing fees, promoted placement, or a hybrid. Each model has different settlement mechanics - you need to know this before picking your payment infrastructure.

What "vendor" means in your context. A supplier you already have contracts with, a third-party merchant you're recruiting, or a professional offering services. The complexity of your vendor onboarding is directly proportional to how much you need to verify about each seller before they go live.

Step 2: Choose your tech stack

The wrong tech stack is the most common and most expensive mistake in marketplace builds. It creates months of rework after MVP.

What to evaluate

Four dimensions determine whether a stack fits your marketplace:

Multi-vendor data model - does the platform natively support multiple sellers with isolated catalog, orders, and payouts?
Commission and settlement - does it ship with a configurable commission engine and payout logic, or is that custom work?
Vendor-facing interfaces - is there a seller dashboard out-of-the-box, or do you build it from scratch?
Extensibility - can you add custom business logic without fighting the framework?

The headless marketplace approach

The architecture that consistently delivers fast marketplace MVPs is a headless stack: a marketplace backend handling all multi-vendor logic (vendor management, commission, order splitting, settlement) exposed via API, with a custom frontend consuming it.

Mercur is built for this model. It ships with the full marketplace stack out-of-the-box: vendor onboarding, commission engine, order splitting, split payments, catalog per vendor, and both a buyer storefront and a vendor dashboard. 80% of marketplace functionality is ready on day one. You build the 20% specific to your business model - not the marketplace infrastructure itself.

What to avoid

General-purpose eCommerce platforms (Shopify, Magento, WooCommerce) were designed for single-vendor retail. Adding marketplace functionality on top means building a second platform: custom vendor portal, custom commission logic, custom settlement, custom catalog isolation per vendor. The full breakdown is in Why You Shouldn't Build a Marketplace in Magento - the same logic applies to Shopify.

Step 3: Scope your MVP

Most marketplace MVPs fail because teams try to launch with everything. The right question is not "what features do we want?" but "what's the minimum that lets us get sellers live and buyers transacting?"

What goes in the MVP

Five components are non-negotiable for a marketplace MVP:

Vendor onboarding - the flow from registration to first product live (manual steps are acceptable initially)
Product catalog - per-vendor, with basic attributes and images
Checkout and payments - including split payments to vendor accounts
Order management - buyer orders, vendor fulfillment, order status tracking
Vendor dashboard - minimum viable: product management, order list, payout history

What can wait

Reviews and ratings, promotions and discount engine, analytics dashboards, advanced search and filtering, returns automation, multi-currency. These matter at scale - not at launch.

The discipline of MVP scoping saves weeks of dev time. Every feature deferred from MVP is a feature you can build based on real seller and buyer feedback instead of assumptions.

Timeline reality

With a purpose-built stack and modern delivery approach, a standard marketplace MVP goes from kickoff to production in 6-10 weeks. Complex projects - heavy custom integrations, multiple buyer/seller personas, ERP dependencies - run 3-4 months.

The biggest variable isn't the platform. It's integration complexity and how quickly decisions on scope get made.

Step 4: Plan your integrations

Integrations are where marketplace timelines slip. The platform itself is rarely the bottleneck.

Payment gateway and split payments. You need a provider that supports marketplace payouts (Stripe Connect, Adyen Marketplaces, or similar). Standard payment gateways don't split funds between platform and seller - you need the marketplace-specific tier.

PIM or catalog source. If you have an existing PIM, define how vendor catalogs sync with it. If you don't, the vendor dashboard's product management becomes your de facto PIM for seller-submitted products. Decide this early - it shapes your data model.

Shipping and logistics. Define whether you're providing a shipping layer, vendors manage their own fulfillment, or you integrate a logistics aggregator. Order splitting means each vendor stream needs its own fulfillment tracking.

ERP. Unless your operations team can't function without it, defer ERP integration to iteration 1. Build the integration contract (data model, sync frequency, error handling) in MVP - implement it after launch.

Step 5: Build vendor onboarding

Vendor onboarding is the most underestimated component in every marketplace build. It's also the one that makes or breaks seller activation rates.

Registration and KYC. Sellers need to verify identity, provide business documents, and link a payout account. At minimum: email verification, tax ID, bank account. The level of verification depends on your regulatory environment and risk appetite.

Product import. The first thing a seller does after registration is add products. Product import is where most marketplaces lose sellers - if the flow is too complex, sellers don't complete it. Design for the least technical seller you'll have.

Approval and go-live. Decide whether you review sellers and products before they go live, or use post-publication moderation. Pre-approval is safer but slower. The right answer depends on your quality requirements.

Ongoing seller operations. After launch, sellers need to manage inventory, update prices, see their orders, and track payouts. The vendor dashboard is their primary interface - invest in it. A seller who can't self-serve becomes a support ticket at scale.

Step 6: Launch and iterate

"Launch" for a marketplace doesn't mean opening to all buyers and all sellers on day one. It means getting your first sellers live and your first transactions processed.

Soft launch with beta sellers. Start with 5-10 sellers you've pre-qualified. A soft launch lets you stress-test the onboarding flow, catch edge cases in order management, and validate your payout logic before it runs at scale.

Define seller activation metrics. A seller is "active" when they have X products live and have fulfilled Y orders. Track this from day one. If sellers register but don't activate, something in your onboarding or dashboard is blocking them.

Iteration 1 priorities. After soft launch you have real data. Common iteration 1 additions: seller performance dashboards, returns flow, promotional tools for top sellers, search and filtering improvements. Build what sellers and buyers are actually asking for.

Starting with Mercur

Mercur is an enterprise-grade Open Core marketplace platform built for this use case: teams with technical capacity who need to go from decision to live marketplace in weeks, not years.

80% of what you need ships out-of-the-box: vendor onboarding, commission engine, order splitting, split payments, catalog per vendor, buyer storefront, and vendor dashboard. The remaining 20% - your commission structures, your vendor workflow, your business rules - is built on a clean, extensible codebase you own entirely.

Zero license fees. Zero GMV fees. Full code ownership. Deployed across 30+ enterprise commerce projects with $6B+ in client trade volume.

See Mercur features and Mercur Enterprise.

Frequently asked questions

What is custom marketplace development?
Building a multi-vendor platform on a foundation you own and control - choosing your tech stack, data model, and business logic - rather than configuring within a SaaS platform's fixed limits.

Can I build a marketplace on Shopify?
Shopify is architected for single-vendor retail. Building a production marketplace on Shopify means building a second platform on top of the first - and significantly more time than a purpose-built stack requires.

How many vendors do I need to launch?
3-5 is enough. The goal of soft launch is to validate your onboarding flow and order management before opening to a wider seller base. Don't wait to recruit 50 vendors before you have a working platform.

What's the difference between a marketplace platform and custom marketplace development?
A marketplace platform (Mirakl, Sharetribe) gives you a pre-built system you configure within fixed parameters. Custom marketplace development means choosing an Open Core foundation (like Mercur) and building the specific logic your business model requires - more flexibility, no per-transaction fees, full ownership.

The Split Basket Problem: Where 1P and 3P Diverge

Rigby — Tue, 11 Aug 2026 12:03:13 +0000

A buyer adds three items to one cart: one you sell directly (1P), two from different third-party sellers (3P). One has free 14-day returns, another has 30-day returns via the seller's courier, the third ships from a separate warehouse. Same checkout, three different sets of rules.

The split basket problem is not a UX glitch - it is ten separate operational problems wearing one cart. Hybrid retailers running first-party inventory alongside a marketplace hit it the moment a buyer combines 1P and 3P items in a single order.

This guide maps the ten areas where 1P and 3P diverge inside a shared basket, and why solving it needs platform architecture, not per-ticket workarounds.

What the split basket problem is

In a pure 1P store, one company owns every item, so returns, shipping, payment, and support follow one consistent policy. In a hybrid marketplace, a single cart can contain items from you and from multiple independent sellers, each with their own terms.

The buyer sees one cart and expects one coherent experience. Behind it sit multiple fulfillment streams, multiple return policies, and multiple payout flows. The gap between the unified front-end and the fragmented back-end is where operations break.

Patch it per ticket and your support team improvises a different answer every time. Solve it in the platform and the rules are consistent by design.

The ten areas where 1P and 3P diverge

Each of these is a place where buyer expectation collides with seller reality. Treated individually they look like edge cases; together they define hybrid marketplace operations.

1. Shipping and delivery times

Your 1P items ship from your warehouse on your SLA. 3P items ship on each seller's schedule from their location. One order can have three delivery dates - and the buyer wants one promise.

2. Returns policy

1P returns follow your policy. Each 3P seller may set their own window, method, and conditions. A buyer who returns the whole order shouldn't need three different processes.

3. Payment and settlement

Money for 1P items is yours immediately. Money for 3P items must be split between you and the seller, with commission deducted and payout scheduled. One transaction, multiple downstream flows.

4. Customer support ownership

When a 3P item arrives damaged, who answers - you or the seller? The buyer contacts you, but the resolution sits with the seller. Unclear ownership turns into slow resolution and falling NPS.

5. Invoicing and tax

1P sales put you as merchant of record. 3P sales may make the seller the merchant of record, changing who issues the invoice and how tax applies. A mixed cart can need multiple invoices.

6. Inventory and availability

You control 1P stock accuracy. 3P availability depends on each seller's feed, which may lag. Overselling a 3P item creates a cancellation the buyer blames on you.

7. Pricing and promotions

A storewide promotion is simple on 1P. On 3P, you can't discount a seller's margin without their agreement. Promotions that silently exclude 3P items confuse buyers at checkout.

8. Order modification and cancellation

Cancelling part of an order means cancelling across separate fulfillment streams. A buyer cancelling one 3P item shouldn't void the 1P shipment or the other seller's line.

9. Fulfillment tracking

One order, multiple tracking numbers from multiple carriers. The buyer wants a single status view; the system has to aggregate independent shipments into one coherent timeline.

10. Quality and content standards

Your 1P listings meet your catalog standard. 3P listings vary by seller. Inconsistent product data in the same cart undermines trust and conversion - covered in depth in our piece on marketplace catalog quality.

Why per-ticket fixes fail

Faced with these divergences, most teams respond case by case: a support macro here, a manual refund there, a spreadsheet to reconcile payouts. It works at low volume and collapses as 3P share grows.

The reason is structural. Each divergence is a rule that has to be encoded once, in the platform, not re-decided by a human on every order. Manual handling doesn't scale, it isn't consistent, and it pushes the cost of complexity onto your support team.

A hybrid marketplace needs a platform that models 1P and 3P as first-class, distinct fulfillment and settlement paths inside a single order - not a 1P store with marketplace items bolted on.

Solving the split basket at the platform level

The split basket is solvable when order splitting, per-seller policy, and settlement are native platform behavior rather than custom patches.

Mercur

Mercur is an enterprise-grade Open Core marketplace platform - zero license fees, zero GMV fees, full code ownership.

It handles order splitting natively: one buyer order is divided into separate vendor sub-orders, each with its own fulfillment, tracking, and settlement, while the buyer sees a single coherent order. Split payments distribute funds between operator and seller with commission applied automatically. The divergences become configured rules, not manual decisions on every mixed cart.

Because Mercur supports both 1P and 3P in one system and is Open Core, you can model your exact return, support, and invoicing logic per channel without working around platform limits. It's deployed across 30+ enterprise commerce projects with $6B+ in client trade volume. See Mercur features and Mercur Enterprise.

Frequently asked questions

What is the split basket problem?

It's when a single cart contains items from different sources - your own 1P inventory and multiple third-party sellers - each with different shipping, returns, payment, and support rules. The buyer expects one experience while the back-end runs several.

What is a hybrid marketplace?

A retailer that sells its own first-party (1P) inventory alongside third-party (3P) sellers on the same storefront. Examples include large retailers that opened their catalog to outside sellers while keeping their core range.

Why can't you handle 1P and 3P with the same rules?

Because ownership differs. For 1P you control stock, shipping, returns, and are merchant of record. For 3P each seller sets their own terms and may be merchant of record, so policies, settlement, and support ownership diverge.

How do you solve order splitting technically?

With a platform that natively divides one buyer order into per-seller sub-orders, each carrying its own fulfillment, tracking, and settlement, while presenting a unified status to the buyer. Mercur handles this out-of-the-box.

Marketplace Catalog Management: Fixing 3P Data Quality

Rigby — Fri, 07 Aug 2026 12:03:26 +0000

Your third-party catalog will always look worse than your first-party catalog. Minimal attributes, thin descriptions, inconsistent images, missing specs. Every marketplace manager knows it, and conversion on 3P product pages proves it - often well below 1P.

Poor 3P catalog quality is a structural problem, not a problem of lazy sellers. Your 1P team is paid to produce clean product data. Your 3P sellers are paid to sell - good data is a cost they avoid unless the platform makes it the path of least resistance.

This guide covers why marketplace catalog management breaks at the 1P/3P boundary, and the three controls that fix it: templates, validation, and enrichment.

Why 3P catalog quality is structurally worse

The gap between 1P and 3P data quality comes down to incentives and tooling, not seller character.

Your 1P catalog runs through a PIM, a content team, and a defined standard. Every product gets the same treatment: full attributes, consistent imagery, complete specs. The 3P seller has none of that - they upload from a spreadsheet, in a hurry, with whatever fields they bothered to fill.

The seller has no direct incentive to enrich data, because the cost is theirs and the benefit - higher marketplace conversion - feels like yours. Until the platform changes that math, quality drifts to the minimum the system accepts.

What poor catalog quality actually costs

Bad 3P data is not cosmetic. It shows up directly in the numbers that matter.

Conversion drops, because buyers won't purchase what they can't evaluate - missing dimensions, no material, one blurry photo. On-site search fails, because products with thin attributes don't match filters, so buyers never find them. And returns rise, because under-described products arrive "not as expected."

It also leaks into SEO and ad spend. Thin product pages rank poorly and convert paid traffic worse, so you pay the same to acquire a click that earns less. Catalog quality is a revenue lever disguised as a data-hygiene chore.

Three controls that fix marketplace catalog management

You can't rely on goodwill to raise 3P quality. You raise it by changing what the platform requires, checks, and assists. Three controls do the work.

Templates that make good data the default

Per-category templates tell sellers exactly what a complete listing needs: required attributes, image count and format, description length, spec fields. A seller filling a structured template produces usable data without thinking about it.

The template encodes your catalog standard so the seller doesn't have to learn it. Good data should be the easiest data to enter, not an extra step the seller chooses to take.

Validation that blocks bad listings at the source

Validation checks a listing before it goes live: are required fields present, is the image above minimum resolution, does the description meet length, are values in allowed ranges? A listing that fails is sent back with specific fixes.

This moves quality control to the point of entry, where it's cheap, instead of after publication, where it's a manual cleanup project. The seller fixes their own listing because the platform won't accept it otherwise.

AI enrichment that closes the remaining gap

Templates and validation set a floor. Enrichment raises the ceiling. AI can generate missing descriptions from attributes, suggest category and tags, normalize inconsistent values, and flag low-quality images for replacement.

Enrichment scales in a way a manual PIM team cannot - it works across thousands of seller listings without adding headcount. The seller submits the minimum; the platform brings it up to standard automatically.

Governance: who owns 3P catalog quality

Tooling needs an owner. Decide whether catalog quality sits with the marketplace operations team, with category managers, or with the sellers under enforced standards.

The workable model is shared: the platform enforces a floor through templates and validation, category managers own standards for their area, and sellers are accountable for meeting them. Quality you can't measure is quality you can't manage - track a catalog completeness score per seller and make it visible to them.

A visible score changes seller behavior. A seller who sees their listings rated against a standard, and sees the conversion difference, starts to care about the data they used to skip.

The platform layer that makes this possible

Templates, validation, and enrichment are platform capabilities. A marketplace built on single-vendor foundations rarely supports per-vendor catalog rules, so quality control stays manual.

Mercur

Mercur is an enterprise-grade Open Core marketplace platform - zero license fees, zero GMV fees, full code ownership.

It models a product catalog per vendor with structured attributes, so each seller's listings live in a system that can enforce a standard rather than accept raw uploads. 80% of marketplace functionality is ready on day one, including the catalog and vendor-management foundation these controls build on.

Because Mercur is Open Core, you can implement category templates, validation rules, and AI enrichment against your own catalog standard - and extend them as your assortment grows - without fighting a closed platform's limits. It's deployed across 30+ enterprise commerce projects with $6B+ in client trade volume. See Mercur features and the related read on the split basket problem in hybrid marketplaces.

Frequently asked questions

Why is third-party catalog quality worse than first-party?

Incentives and tooling. Your 1P catalog runs through a PIM and a content team against a standard. 3P sellers upload from spreadsheets with no direct incentive to enrich data, so quality falls to the minimum the platform accepts.

How does poor catalog quality affect revenue?

It lowers conversion (buyers won't purchase what they can't evaluate), breaks on-site search (thin attributes don't match filters), raises returns (under-described products disappoint), and wastes ad spend on pages that convert poorly.

What is product data validation in a marketplace?

Automated checks that a listing meets your standard before it goes live - required attributes present, images above minimum resolution, descriptions of sufficient length. Failing listings are returned to the seller with specific fixes.

Can AI improve marketplace catalog quality?

Yes. AI enrichment generates missing descriptions from attributes, suggests categories and tags, normalizes inconsistent values, and flags weak images - across thousands of listings without adding PIM headcount.

Marketplace Monetization Models: Beyond Transaction Fees

Rigby — Thu, 06 Aug 2026 12:03:52 +0000

You picked a commission model - a percentage of GMV - because that's what everyone does. It's how Mirakl prices, it's how most SaaS marketplaces work, it's the default. And the more your marketplace grows, the more you pay.

Commission on GMV is one marketplace monetization model, not the only one - and it's the most expensive at scale. Subscriptions, listing fees, promoted placement, and hybrids each fit a different business. Picking the wrong one caps growth or pushes your best sellers away.

This guide covers five marketplace monetization models, where each fits, and the trap of letting your platform's pricing dictate your business model.

Why the monetization model matters more than it looks

The revenue model decides who pays, when, and how much - and that shapes seller behavior, margin, and growth ceiling.

A model that's cheap to start can become a tax on success. A model that's simple for you can be a deterrent for sellers. The monetization model is a strategic decision, not a billing setting - it determines whether scale works for you or against you.

It also interacts with your platform. If your platform charges you a GMV fee, that cost flows straight into whatever you charge sellers, compounding at scale.

Five marketplace monetization models

Each model earns differently and suits a different stage and seller type. Most mature marketplaces end up combining several.

Commission on GMV

You take a percentage of each transaction. It's the default because it aligns your revenue with seller success and asks nothing of sellers upfront - they pay only when they sell.

The downside is scale. As GMV grows, your absolute take grows with it, and high-volume sellers start resenting a fee that no longer matches the value you add. Commission is the easiest model to start and the most expensive to sustain for high-volume sellers.

Subscription fees

Sellers pay a recurring fee for access, regardless of sales. It gives you predictable revenue and rewards your highest-volume sellers, who pay a flat rate instead of a rising percentage.

The risk is the barrier to entry. New or low-volume sellers hesitate to pay before they've earned, so a pure subscription model can starve the top of your seller funnel.

Listing fees

Sellers pay per listing or per batch of listings. It suits high-volume, low-price catalogs and marketplaces where listing supply itself has value.

It's rare as a sole model because it charges sellers before any sale, but it works as a component - particularly to discourage low-quality bulk listings that clog the catalog.

Promoted placement and ads

Sellers pay for visibility - featured slots, sponsored search results, category placement. This is how the largest marketplaces earn their highest-margin revenue, on top of commission.

It needs scale to work: enough buyer traffic that placement is worth paying for, and enough sellers competing for it. Early-stage marketplaces rarely have the demand to make ads worth running.

Hybrid models

Most marketplaces at scale combine models: a modest commission, optional subscriptions for high-volume sellers, and promoted placement for visibility. Each revenue stream offsets the weakness of the others.

The hybrid lets you keep entry low (small or no commission), reward scale (subscriptions), and capture high-margin upside (ads) - without leaning entirely on a GMV fee that punishes your biggest sellers.

How to match a monetization model to your stage

The right model changes as the marketplace matures. What works at launch starves you at scale, and what works at scale blocks you at launch. Read the model against where you are now.

Launch: remove every reason not to join

At launch your scarcest resource is sellers. Liquidity comes first, revenue second. A low or zero commission and no upfront fees take cost off the table so sellers test you with no risk.

Charging sellers before you've proven you can drive sales is the fastest way to stall a young marketplace. Optimize for the number of active sellers and time to first sale, not for take rate.

Growth: introduce a take rate that tracks value

Once buyers are converting, a modest commission is fair - you're delivering demand the seller couldn't reach alone. This is where most marketplaces settle into a single-digit to low-double-digit commission tied to the value of the traffic they provide.

The discipline here is to keep the rate defensible. A seller should be able to look at what you charge and see what they get for it.

Scale: diversify before the GMV fee bites

At scale your highest-volume sellers feel a flat percentage as a large absolute cost. This is the moment to add subscription tiers and promoted placement, so your revenue no longer rides entirely on a fee that grows against your best accounts. Diversify your revenue model before your top sellers start pricing a move to a cheaper channel.

What a fair take rate looks like

Marketplace take rates vary widely by category - low-margin, high-volume goods support only a few percent, while high-margin services tolerate more. Across consumer marketplaces, take rates commonly sit in the mid-to-high single digits, with some software and services marketplaces going well above that.

The number that matters is not the headline rate but what the seller nets after your fee plus their cost of fulfillment. If your take rate pushes a seller's margin below what their own channel returns, they will eventually leave - the rate has to leave the seller better off for selling through you.

This is where a platform GMV fee does quiet damage. If your platform takes a percentage before you've charged the seller anything, your floor take rate is already raised, narrowing the band where both you and the seller win.

The transaction-fee trap at scale

The hidden problem with a GMV-only model is that it grows fastest exactly where it hurts most - on your highest-volume sellers, the ones a competitor most wants to poach.

A seller doing low volume barely notices a percentage fee. A seller doing high volume pays you a large absolute sum each month and starts asking what they get for it. A pure GMV fee creates a growing incentive for your best sellers to leave - the more they sell, the more reason they have to find a cheaper channel.

Make it concrete. At a 10% commission, a seller doing $5,000 a month pays you $500 - barely worth their attention. A seller doing $200,000 a month pays you $20,000 for the same platform, the same listing tools, the same checkout. Your cost to serve the two sellers is nearly identical; the fee is 40x apart. The high-volume seller does the math and starts shopping for a flat-fee or owned alternative - and they are exactly the seller you cannot afford to lose.

This compounds when your platform also charges you a GMV fee. SaaS marketplace platforms commonly layer a percentage of GMV on top of their license, as broken down in our Mirakl pricing analysis. That cost has to be recovered from sellers, so a platform GMV fee quietly forces a higher seller commission than your economics actually need.

Choosing a model your platform doesn't dictate

The right monetization model depends on your sellers, your stage, and your margin - not on what your platform makes easy to bill. A platform that hard-codes GMV pricing pushes you toward a GMV model whether or not it fits.

Mercur

Mercur is an enterprise-grade Open Core marketplace platform - zero license fees, zero GMV fees, full code ownership.

Because Mercur takes no percentage of your GMV, the platform cost doesn't force your seller pricing upward - you keep the full take rate you charge. The commission engine supports flat rates, category-specific rates, and tiered structures out-of-the-box, so you can run commission, subscription, listing, or hybrid models as your business requires. Your monetization model is a business decision, not a constraint inherited from platform pricing.

Mercur is deployed across 30+ enterprise commerce projects with $6B+ in client trade volume. See Mercur features and the marketplace software comparison for how platform pricing models differ.

Frequently asked questions

What is the most common marketplace monetization model?

Commission on GMV - a percentage of each transaction. It's popular because sellers pay only when they sell and your revenue tracks their success, but it becomes expensive for high-volume sellers as the marketplace scales.

Why do transaction fees hurt growth?

A GMV percentage grows fastest on your highest-volume sellers, who pay large absolute sums and start questioning the value. That creates a rising incentive for your best sellers to move to a cheaper channel.

What's the best monetization model for a new marketplace?

Usually a low or modest commission to keep seller entry frictionless, evolving into a hybrid as you scale - adding subscriptions for high-volume sellers and promoted placement once buyer traffic supports it.

How does platform pricing affect my monetization model?

If your platform charges a GMV fee, that cost flows into your seller commission, forcing it higher than your economics need. A platform with zero GMV fees, like Mercur, lets you set seller pricing on your terms.

Sharetribe Alternatives in 2026: Marketplace Platforms Compared

Rigby — Thu, 06 Aug 2026 08:26:47 +0000

Sharetribe got you live fast. It was the right call to validate the idea. Now you're hitting the wall every Sharetribe marketplace eventually hits: the customization you need isn't possible, and the GMV fee grows every month.

Looking for Sharetribe alternatives usually means you've outgrown a starter platform, not that you chose wrong. Sharetribe is built for speed-to-launch, which is exactly what early marketplaces need - and exactly what becomes a constraint once you have traction and a roadmap.

This guide covers when teams outgrow Sharetribe, what to look for in an alternative, and how the main options compare for a marketplace that has moved past validation.

What Sharetribe is good at

Sharetribe earns its place. It lets a non-technical founder launch a working marketplace in weeks, with vendor accounts, listings, and payments handled out-of-the-box.

For idea validation and early traction, that speed is the right trade. You're testing whether the marketplace works at all, and you don't want to spend six months building before you know. Sharetribe is a strong place to start and a predictable place to outgrow.

When teams outgrow Sharetribe

The signals that you've hit Sharetribe's ceiling are consistent across marketplaces. Three show up most often.

Customization hits a wall

Sharetribe works within defined extension points. When your roadmap needs flows the platform doesn't anticipate - custom pricing logic, a specific negotiation or RFQ flow, deep integration with your ERP or PIM - you reach limits you can't engineer around.

A real example: a B2B marketplace needing per-buyer pricing, size-linked variant pricing, and an RFQ negotiation flow finds these either impossible or heavily worked-around on a starter platform. The platform that made launch fast now makes the next feature impossible.

The GMV fee scales against you

Sharetribe's pricing includes a fee tied to your transaction volume. Early on it's negligible. As GMV grows, you're paying an increasing amount for infrastructure whose cost to run hasn't changed.

At scale, a percentage of GMV becomes one of your largest platform costs - money that buys no additional capability. You end up paying more precisely because you succeeded, with nothing extra to show for it.

You don't own the code

On a hosted starter platform, you don't own or fully control the codebase. You can't audit how your data is handled, you can't run it on your own infrastructure, and migrating off later is a full rebuild.

For a marketplace that's now a real business, that lack of ownership is a strategic risk, not just a technical inconvenience.

What to look for in a Sharetribe alternative

The right alternative depends on why you're moving. Match the platform to the constraint you've hit.

If your constraint is customization, you need a platform you can extend without fighting it - ideally one whose code you control. If your constraint is the GMV fee, you need pricing that doesn't tax your growth. If your constraint is ownership, you need full code and data control. Most teams leaving Sharetribe are hitting all three at once.

Be honest about your technical capacity, too. A more powerful platform needs a development team or a delivery partner. The trade for removing limits is taking on more build responsibility.

The main Sharetribe alternatives

The alternatives fall into three groups, each resolving a different subset of Sharetribe's limits.

Other SaaS marketplace platforms

Platforms like Mirakl sit at the enterprise SaaS end - more capable than Sharetribe, but with their own license and GMV-based costs and their own customization ceiling. You trade up in capability while keeping the SaaS constraints: limited code control and pricing that scales with volume. The detail is in our Mirakl pricing breakdown.

Building from scratch

A fully custom build removes every limit and takes on every cost. You get exactly what you want and you maintain all of it. For most teams this is slower and riskier than it needs to be, because marketplace infrastructure - vendor management, commission, order splitting, settlement - is solved work you'd be rebuilding.

Open Core: Mercur

Mercur is an enterprise-grade Open Core marketplace platform - zero license fees, zero GMV fees, full code ownership.

It resolves all three Sharetribe constraints at once: no GMV fee, so growth doesn't tax you; full code ownership, so you can audit and control your data; and an extensible codebase, so the customization Sharetribe blocks becomes possible. 80% of marketplace functionality is ready on day one - vendor onboarding, commission engine, order splitting, split payments, catalog per vendor - so you're not rebuilding infrastructure, only the 20% specific to your business.

It's the migration target for teams that validated on a starter platform and now need a foundation that scales with them. Mercur is deployed across 30+ enterprise commerce projects with $6B+ in client trade volume. See the full platform comparison and the marketplace development guide for migration planning.

How to plan a migration off Sharetribe

Because you don't own the Sharetribe codebase, leaving is a rebuild rather than a lift-and-shift. The work is manageable when you treat it as four distinct stages rather than one large jump.

Map what you actually use

List the flows your marketplace runs today - onboarding, listing, checkout, payouts - and mark which are standard and which are custom. The standard flows are mostly out-of-the-box on a purpose-built platform; the custom ones are where your migration effort concentrates.

This map also surfaces the workarounds you built to get around Sharetribe's limits. Many of those disappear on an extensible platform, which shrinks the rebuild rather than recreating it.

Export and model your data

Pull your sellers, listings, orders, and payout history out of Sharetribe early. Data export is also a test of ownership: how cleanly you can extract everything tells you how locked in you were, and how locked in you'd be on the next platform.

Model that data against the new platform's structure before you build, so you catch mismatches in catalog or commission structure while they're cheap to fix.

Rebuild the custom 20%

With marketplace infrastructure already provided, your build focuses on the logic specific to your business - the pricing rules, negotiation flows, or integrations Sharetribe couldn't support. This is where you finally ship the roadmap the starter platform blocked.

The migration is worth doing precisely when the features you couldn't build on Sharetribe are the ones now driving your growth.

Run in parallel, then cut over

Run the new platform alongside Sharetribe with a subset of sellers before full cutover. A staged switch lets you validate onboarding, checkout, and payouts with real transactions before you move your whole seller base.

Frequently asked questions

Why do marketplaces move off Sharetribe?

Three reasons, usually together: customization limits they can't engineer around, a GMV fee that grows with success, and lack of code ownership. Sharetribe is built for fast launch, so teams outgrow it once they have traction and a roadmap.

Is Sharetribe a good platform?

Yes, for what it's designed for - launching a marketplace fast to validate the idea, especially for non-technical founders. It becomes a constraint later, when you need deep customization or your GMV makes the transaction fee significant.

What is the best Sharetribe alternative?

It depends on your constraint. For teams hitting customization limits, a GMV fee, and ownership concerns at once, an Open Core platform like Mercur resolves all three. For staying fully managed, enterprise SaaS like Mirakl is an option with its own cost trade-offs.

How hard is it to migrate off Sharetribe?

It's a rebuild, since you don't own the Sharetribe code. With a platform that ships 80% of marketplace functionality out-of-the-box, like Mercur, the migration focuses on your custom logic and data, not on rebuilding core marketplace infrastructure.