DEV Community: Rigby

Marketplace vs eCommerce: Why Classic eCommerce Stops Scaling Around 10-50$M GMV?

Rigby — Wed, 02 Sep 2026 12:03:49 +0000

If you run an eCommerce business, growth usually feels predictable at the beginning.

You add products, improve conversion, and increase ad spend. GMV goes up. The team grows. Each new channel looks like another lever you can pull.

Then, somewhere between 10-50$M in GMV, the pattern starts to change. This is a critical stage, and about 73% of brands fail to successfully move past it and scale to an enterprise level.

Not because your product suddenly got worse. Not because your marketing team forgot how to run campaigns. But because the economics of a “classic” eCommerce model change with scale:

Your cheapest acquisition channels saturate, and CAC starts rising faster than revenue.
Inventory becomes a bigger bet, tying up cash and increasing risk.
Operations get more complex in ways that don’t show up in a neat dashboard.
Growth becomes increasingly linear – every extra unit of GMV costs disproportionately more effort, capital, and coordination.

At that point, the question stops being “How do we grow faster?” and becomes “What needs to change in our model so growth doesn’t get more expensive every year?”

This article breaks down that moment. You’ll see why it happens, how to recognize it early, how marketplace vs eCommerce model compares, and how the best players respond once classic eCommerce stops being a growth engine.

Key takeaways

The scaling wall is not defined by a GMV number, but by when growth starts getting more expensive with each step.
The organizations that successfully scale past the $50 million ceiling are those that transition from being a "store" to becoming a "platform".
Rising CAC, inventory pressure, and operational complexity are symptoms of a business model reaching its limits.
The next phase of growth doesn’t come from pushing the same engine harder. It comes from changing how growth is generated in the first place.
Marketplaces don’t replace eCommerce. They extend it by shifting risk, effort, and growth inputs outside the core business.
Adding a marketplace layer doesn’t require replatforming. It can sit next to your existing stack, regardless of whether you run Shopify, Magento, or a custom setup.
The strongest teams start narrow, prove the economics, and evolve the model over time instead of betting on a full transformation.

What “X million GMV” really means (and why it’s not the same number for everyone)

A classic eCommerce business often grows very fast at first, and then suddenly slows down. At some point, it hits a wall where growth becomes much harder. This is often called the “Scaling Wall.”

Research on DTC brands shows that this point usually appears between $10M and $50M in annual revenue. Below this level, companies usually grow efficiently. Founders are closely involved, decisions are fast, and brands can win by serving small or underserved niches.

Once a business passes $10M in GMV, those same early strategies often start to break down. Manual fulfillment, improvised marketing, and centralized decision-making no longer scale and begin to slow growth instead of supporting it.

The table below shows how growth efficiency changes as revenue increases and explains why the $10M–$50M range is where many eCommerce businesses hit the scaling wall.

For founders and leaders, the key question is: where is that breaking point? In other words, at what revenue or GMV level does the limits of a single-merchant, inventory-based model start to block further growth?

Here are the factors that decide where “X” shows up for you:

Purchase frequency: If customers buy weekly, you can tolerate a higher CAC and still win. If they buy once every 3 years, the margin for error is tiny.
Gross margin: High margins give you room to acquire customers and absorb operational complexity. Low margins force you to be ruthlessly efficient.
Assortment depth and expansion pressure: The broader you go, the more inventory, content, and operational overhead you create, unless your model changes.
Dependence on paid acquisition: The more your growth relies on buying traffic, the faster you collide with rising CAC and channel saturation.
Inventory intensity and lead times: Long lead times and large MOQs (Minimum Order Quantity) turn growth into a cash flow problem, not a demand problem.
Operational complexity: Returns, split shipments, customer service edge cases, and supplier variability – these scale non-linearly.

So instead of asking, “Are we above X million GMV yet?” a better question is, “Are we starting to pay more for each additional unit of growth than we did last year?”

If the answer is yes, you’re approaching the wall, regardless of the GMV number on your dashboard.

Classic eCommerce model: How growth actually works

In a classic eCommerce setup, growth comes from two main levers: demand and supply.

On the demand side, you grow by acquiring customers. That usually means paid channels, SEO, email, and retention loops. Early on, these compounds. Cheap traffic exists. Audiences are underexposed. Small improvements in conversion create visible lifts in GMV.

As you scale, that dynamic changes. You exhaust the cheapest demand first. Each next cohort costs more to acquire, while conversion gains get harder to find. Growth continues, but the slope flattens.

On the supply side, you grow by expanding assortment. More SKUs mean more chances to match demand. In a classic model, that expansion is funded by your balance sheet. You buy inventory, hold it, forecast demand, and absorb the risk.

This creates the "Inventory Spiral": more SKUs lead to higher forecasting errors, which result in simultaneous overstocks and stockouts. Approximately 42% of small-to-mid-market businesses struggle with overstocking, which ties up cash flow and necessitates heavy discounting to clear obsolete stock.

The financial drain of inventory distortion – the combined loss from missed sales and holding costs – is estimated to account for 11.7% of total revenue for retailers. For a brand at $50 million GMV, this represents nearly $6 million in annual lost value, a "tax" that limits the capital available for marketing or technological innovation.

What matters here is that both levers scale linearly. To grow demand, you spend more. To grow supply, you commit more capital.

There are no built-in loops where growth reduces its own cost. Every additional unit of GMV requires proportional effort, coordination, and risk. When execution is strong, this model can take you far. When scale introduces friction, the cost curve turns.

This is why many teams feel stuck even while GMV is still growing. You’re doing the same things that worked before, just at a higher volume, with thinner margins and less room for error.

Once growth behaves this way, optimization helps at the edges, but it doesn’t change the underlying math. That’s when the limits of classic eCommerce start to show up in practice.

When classic eCommerce starts breaking down: 6 scaling barriers

GMV can keep growing for a long time after the scaling wall appears. What changes first is the quality of that growth. Revenue increases, but profit stops following. Margins flatten, contribution weakens, and more of each quarter’s result depends on discounts, higher acquisition spend, or inventory bets with longer payback periods.

At the same time, operations begin to matter in a different way. Returns, split shipments, customer support edge cases, supplier delays, and fulfillment exceptions take up more attention. Teams spend more time keeping the system stable and less time pushing it forward. Growth is still there, but it starts to feel heavier.

Once growth slows, the symptoms don’t appear all at once. You usually notice them in fragments: one quarter CAC jumps, another quarter cash feels tighter, then operations start absorbing more time than expected. Each issue looks manageable on its own.

The problem is that they rarely come alone. In a classic eCommerce model, scale introduces a set of structural pressures that reinforce each other. Fixing one area often pushes cost or complexity into another. Over time, growth feels heavier, even when GMV is still going up.If you recognize two or three of the patterns described below, it’s a sign you’re facing a business model problem. The barriers below show up across categories and markets. The order may differ, but the pattern is consistent.

1) CAC starts rising faster than GMV

Early on, growth often comes from underpriced attention: niche audiences, low-competition keywords, cheap retargeting pools, and organic lift. At scale, those channels saturate. You’re forced into more expensive auctions, broader audiences, and lower-intent traffic.

How it shows up:

ROAS (Return on Ad Spend) declines even when creative and targeting improve.
You rely more on discounts to keep conversion stable.
Revenue grows, but contribution margin doesn’t.

What top players do:

Invest in demand creation, not just demand capture (content, community, partnerships).
Build retention and repeat purchase loops so LTV (Customer Lifetime Value) can keep up with CAC.
Expand the value proposition beyond “products” (services, bundles, subscriptions).

2) Inventory becomes a growth tax

To keep GMV growing, you expand the assortment. In a classic model, that often means buying more stock, across more SKUs, with more uncertainty. The result: capital gets locked, forecasting becomes harder, and you start paying for growth with cash flow risk.

How it shows up:

“We’re growing, but always tight on cash."
Stockouts and overstocks increase at the same time.
End-of-season markdowns become a strategy, not an exception.

What top players do:

Shift selection growth away from owned inventory (dropship, vendor-managed inventory, 3P).
Use data to enforce assortment discipline (kill SKUs faster, test before scaling buys).
Negotiate supply terms that reduce risk (consignment, better payment terms, shorter lead times).

3) Operations scale non-linearly

At a small scale, a strong team can “hero” through complexity. At a larger scale, exceptions become the norm: split shipments, delayed suppliers, returns, fraud, missing items, address issues, warranty claims, and customer impatience. The business starts absorbing costs that aren’t visible in the GMV chart.

How it shows up:

Cost per order doesn’t go down, it creeps up.
Customer service tickets per order increase.
NPS declines even though the product is still great.

What top players do:

Standardize processes and policies early (returns, disputes, SLAs).
Build tooling that reduces manual handling (automation, clear exception flows).
Move complexity to where it belongs (e.g., vendors handle fulfillment in 3P models).

4) Assortment expansion hits a discovery ceiling

More products are not automatically more valuable. At some point, “more SKUs” creates confusion, content debt, and a worse shopping experience, unless discovery and merchandising mature accordingly.

How it shows up:

SEO growth plateaus because content can’t keep up.
On-site search becomes a constant problem.
Merchandising becomes subjective (“We need better recommendations”).

What top players do:

Treat discovery as a product (search, filters, ranking, personalization).
Use suppliers and vendors as content engines (feeds, enriched data, standards).
Expand selection without expanding internal content workload proportionally.

5) Growth remains linear because you have no network effects

Classic eCommerce is fundamentally linear: you either buy demand (marketing) or buy supply (inventory). Each incremental step up requires proportional effort. That’s fine until the cost curve turns against you.

How it shows up:

Every additional +1M GMV costs more than the previous +1M.
Scaling feels like adding people, tools, and budget – not building leverage.
Competitors can copy your playbook because it’s the same set of levers.

What top players do:

Shift from a “store” to a “platform” mindset where others contribute value.
Build ecosystems: vendors, partners, creators, service providers.
Create compounding loops (more selection → better conversion → more suppliers → better economics).

6) Promotions and discounts stop working

As acquisition gets more expensive and assortment grows, discounts become a way to compensate for friction elsewhere in the system. They start filling gaps created by high CAC, poor discovery, or inventory pressure.

Over time, customers anchor on the discounted price. Full-price demand weakens. Promotions shift from a tactical tool to a structural dependency. When promotions stop moving the needle, it’s usually a signal that the model itself needs to change, not the offer.

How it shows up:

You need discounts more often to maintain baseline conversion.
Promo periods stop outperforming “normal” weeks by a wide margin.
Margin erosion accelerates faster than volume growth.

What top players do:

Reduce reliance on blanket discounts and tighten promo scope.
Shift incentives toward bundles, services, and non-price benefits.
Focus on improving conversion drivers that don’t compress margin.

What to change in your business model? Decision framework for CEOs

At this stage, the problem is no longer eCommerce but the growth engine.

Your growth starts getting expensive because the current engine stops producing leverage at scale. The issue sits deeper than campaigns, tooling, or execution. It comes from how demand, supply, and operations are structured in the model.

The main task now is to identify what currently limits your growth. In most scaled eCommerce businesses, the constraint sits in one of five areas: demand, margin, cash flow, operations, or differentiation. One of them usually dominates and shapes the rest of the system.

Use the questions below as a lightweight diagnostic. The goal is to notice a dominant pattern that explains why growth has started to slow and costs more to sustain.

Step 1: Identify your primary bottleneck

If you answer “yes” to most questions in a block, that’s likely your current constraint.

A) Demand is getting expensive.

Paid channels are saturated, and CAC has climbed for 2+ quarters.
You need promotions more often to maintain conversion.
Growth feels like “spend more” rather than “compound more.”

B) Cash flow and inventory are the choke points.

You’re often tight on cash despite growing GMV.
You carry a meaningful amount of slow-moving stock.
Expanding assortment means bigger buys, bigger risk, longer payback.

C) Operations are dragging growth down.

Support tickets per order are rising.
Returns, exceptions, and disputes take too much manual work.
Customer experience is becoming inconsistent across the journey.

D) Differentiation is weakening.

Competitors can match your selection and price easily.
You’re increasingly dependent on ad auctions for growth.
Your brand story is not enough to defend the margin.

Step 2: Match the bottleneck to the archetype

Now, map your bottleneck to the move that most directly changes the cost curve.

If demand is expensive (A): Prioritize ecosystem/services and partner distribution. Create reasons to choose you that aren’t bought in an ad auction.
If cash flow/inventory is the choke point (B): Prioritize 3P/dropship/marketplace. Expand selection while shifting inventory risk away from your balance sheet.
If operations are the drag (C): Prioritize standardization + a narrow 3P model only if you can enforce SLAs. Reduce exceptions, move complexity to structured flows, and avoid “chaos at scale.”
If differentiation is weak (D): Prioritize services/ecosystem and the B2B layer. Deepen value delivered and increase repeat frequency so you’re not competing on price.

Most businesses end up combining two moves: one to unlock selection or cash flow, and one to build defensibility.

Step 3: Choose a “first version” you can ship in 60-90 days

The fastest way to get it right is to pick an initial scope that produces a measurable signal:

One category, curated supply, strict rules,
One service, one partner, one workflow
One B2B segment, a minimal account experience,
One partner channel, clear incentives, clear tracking.

A good first version answers one question: “Can we change the economics of growth without breaking the customer experience?”

What the best players do with this problem: 4 proven moves beyond classic eCommerce

Once you accept that the scaling wall is structural, you can double down on what already works, fix the bottlenecks that slow growth, or stop an idea before it starts consuming time and capital. The point is to let the growth model evolve along with the business.

Pushing the same engine harder rarely changes the outcome. Scale introduces constraints that can’t be removed with better execution alone. Growth needs to come from a different structure, one that creates leverage instead of adding weight. The organizations that successfully scale past the $50 million ceiling are those that transition from being a "store" to becoming a "platform".

The best players don’t treat this moment as a failure of eCommerce. They treat it as a signal to adjust the model behind it and move into one (or a combination) of these four archetypes.

1) They expand selection without owning the inventory (3P/dropship/marketplace)

Instead of funding assortment growth with their own balance sheet, they let partners carry more of the inventory risk. This unlocks breadth and long-tail coverage without turning cash flow into the bottleneck.

Why it works:

More selection without proportional working capital.
Faster category expansion and testing.
Better availability and lower stock risk.

Where it can fail:

If you don’t control quality standards, SLAs, and customer experience.
If vendor operations are inconsistent, you end up absorbing the complexity anyway.

The “first version” (low-risk):

Start with a single category where you already have demand, invite a small set of curated suppliers, and define strict rules for listings, shipping times, and returns. Keep it narrow, and learn fast.

2) They turn the category into an ecosystem (services, financing, installation, warranties)

Top players stop thinking in “products shipped” and start thinking in outcomes delivered. They add complementary services that increase AOV, boost conversion, and create differentiation that competitors can’t copy with a price match.

Why it works:

Higher gross profit per customer without just raising prices.
Stronger retention and repeat loops.
More reasons to choose you beyond product selection.

Where it can fail:

If services are bolted on without operational ownership.
If it becomes a margin leak due to refunds, disputes, or poor partner execution.

The “first version” (low-risk):

Pick one service that solves a painful post-purchase problem (e.g., installation, pickup/returns, extended warranty) and build it with one trusted partner before scaling.

3) They add a B2B layer to stabilize demand and increase repeat purchase frequency

Many categories have a natural B2B adjacent market: small businesses, professionals, resellers, and institutions. The best players build a dedicated B2B motion with pricing, invoicing, assortment rules, and account workflows, not just “a discount code for companies.”

Why it works:

Higher frequency and predictable volume.
Lower marketing volatility vs consumer-only growth.
Stronger lifetime value driven by relationships, not ads.

Where it can fail:

If you treat B2B like B2C with different prices.
If operational requirements (credit, terms, support) aren’t in place.

The “first version” (low-risk):

Start with your existing customers who buy repeatedly, offer account-based pricing and invoicing, and build minimal workflows for repeat ordering and approval.

4) They federate growth through partners (multi-brand, affiliates, resellers, co-selling)

Instead of relying purely on internal acquisition, top players build distribution leverage. They enable others to sell, refer, or bring supply into the ecosystem - and make that channel structurally attractive.

Why it works:

Customer acquisition becomes partially “outsourced.”
Better reach into niches and communities you can’t buy efficiently.
Compounding referrals and partner loops.

Where it can fail:

If incentives are unclear or economics don’t work for partners.
If attribution and payouts create friction.

The “first version” (low-risk):

Choose one partner type (e.g., agencies, consultants, category influencers, or B2B resellers), define a simple offer and tracking, and run a 30-day pilot with 5-10 partners.

The important point is that these moves are structural shifts that change the cost curve of growth. They don’t require a full reset of the business. In practice, the strongest teams extend the one they already have.

That’s why marketplaces usually show up as an addition to existing eCommerce, not a replacement. Core assortment, owned inventory, and direct operations continue to exist. The marketplace layer sits next to them, taking on the parts of growth that no longer scale well inside a classic model.

Selection can expand without tying up more capital.
New categories can be tested without large inventory bets.
Growth can involve suppliers and partners, not just internal teams.

Most teams don’t commit to this all at once. They start narrow, prove the economics, and layer additional archetypes only after the first one works. The result is an evolved model, not a replatforming project.

To understand how this shift can improve your growth, look at how marketplaces and classic eCommerce differ at the model level. See why that difference shows up directly in the cost curve of growth.

Marketplace vs eCommerce platform comparison: How the business model changes the cost curve

Once growth stops compounding inside a classic eCommerce setup, improving the cost curve requires more than optimization. It requires a model that creates leverage as scale increases.

Marketplace models change how growth is funded, how risk is distributed, and how effort translates into GMV. That’s why they often appear as the next step once classic eCommerce reaches its limits.

Learn how to evaluate if evolving your eCommerce growth strategy toward a marketplace model makes sense for your business in our other article.

Why an eCommerce platform is optimized for owned inventory

Most eCommerce platforms are designed around a single merchant owning the transaction. Pricing, fulfillment, returns, tax logic, and customer support assume centralized control.

This works well for classic eCommerce, but it limits how far the model can stretch. Adding vendors on top of this structure often means manual work, edge cases, and operational friction.

What a marketplace platform needs to handle instead

A marketplace is built around coordination rather than ownership. It needs to handle multiple sellers, separate payouts, different fulfillment paths, shared customer experience rules, and enforcement of standards.

The focus shifts from executing every step internally to orchestrating how others participate in the system while keeping quality and trust consistent.

Why “adding vendors” is not the same as running a marketplace

Adding vendors to an eCommerce setup often looks simple at first. Products appear. Orders come in.

The complexity shows up later: split carts, partial shipments, disputes, returns, SLAs, payouts, and accountability when something goes wrong. Without a model designed for this, the platform absorbs the cost instead of reducing it.

A real marketplace works because the model, not the team, carries that complexity. Rules, incentives, and workflows replace manual coordination. That’s what allows growth to scale without turning into operational drag.

Ecommerce vs marketplace economics

The fundamental economic difference between classic eCommerce and a marketplace is the shift from capturing the full product margin to earning a "take rate" or commission on 3P sales.

While the per-unit revenue is lower in a commission model, the operational cost and financial risk are drastically reduced. Typical marketplace commission rates range from 10% to 30%, depending on the category and level of service provided by the platform.

In classic eCommerce, growth is funded internally. You acquire demand, buy inventory, hold risk, and capture margin. Every increase in GMV depends on your ability to spend more on acquisition and commit more capital to stock.

In an online marketplace model, part of that burden shifts outward. Suppliers fund inventory. Marketplace sellers expand selection. GMV grows through participation, not just internal investment. The economics change because growth no longer depends entirely on your balance sheet.

Inventory risk vs supply aggregation

Classic eCommerce grows by owning more inventory. That works until assortment depth and forecasting error start locking up cash and slowing decisions.

Marketplace models grow by aggregating supply. Inventory risk sits with suppliers, not the platform. This allows selection to expand without proportional increases in working capital, and it lowers the cost of testing new categories or long-tail demand.

Linear growth vs compounding loops

In a store model, growth is linear. More GMV requires more spending, more inventory, and more operational capacity. Each step up costs at least as much as the previous one.

The marketplace model introduces compounding loops. More supply improves selection. Better selection improves conversion. Higher conversion attracts more suppliers. Growth starts reinforcing itself instead of adding weight at each step.

How to add a marketplace to your existing eCommerce?

Adding a marketplace layer is often discussed as a big platform change. In practice, most teams struggle not because the idea is wrong, but because the execution path is unclear.

Without a structured way to add a marketplace layer:

growth experiments become expensive and slow,
Inventory risk concentrates further inside the business,
Operational complexity increases instead of moving outward.

In many cases, “adding vendors” ends up increasing internal workload instead of reducing it. The cost curve gets worse, not better. One of the biggest risks in marketplace projects is unclear ownership of logic. A successful integration starts with a clean separation of responsibilities.

The transition to a marketplace requires a technological architecture that can handle multi-vendor logic without destabilizing the core commerce engine. Attempting to "bolt-on" marketplace features to a standard eCommerce monolith often leads to failure. Instead, modern architectures utilize a decoupled, API-first approach.

The most effective approach is to extend your existing eCommerce model with a marketplace layer that is designed for coordination. For businesses already operating on established platforms like Magento (Adobe Commerce) or Shopify, the scaling wall often appears as a performance or maintenance ceiling.

The Mercur marketplace engine allows these organizations to extend their existing storefront into a multi-vendor platform without a "big-bang" replatforming. Mercur is a multi-vendor marketplace platform that can be integrated with any eCommerce, ERP-driven, or custom-built platform – adding multiple vendor workflows and marketplace functionality, while your core commerce engine stays untouched.

This separation of concerns ensures that the marketplace logic is isolated and extensible, allowing for the independent scaling of vendors and workflows without slowing down the core performance.

No migration, no replatforming, no vendor lock-in.
No need to pause current eCommerce development.
Works with custom and legacy platforms.
Clear separation between commerce and marketplace logic.
API-first, event-driven integration.

This allows teams to:

Add marketplace sellers without breaking existing flows,
Keep total control over customer experience rules,
Avoid long migration projects and platform lock-in,
Start narrow and expand only after the economics work.

The focus is not on launching a full marketplace on day one. It’s about introducing a structural change to the growth model without disrupting the business you already run.

Before building anything, it’s worth validating how a multi-vendor marketplace should live in your ecosystem. A short architecture conversation can save months of development and years of technical debt. Book a marketplace consultation!

Summary: The scaling wall is a model problem, and that’s good news.

When classic eCommerce stops scaling after X million in GMV, it rarely points to weak execution. Most teams reach this stage by doing many things right. What shows up instead are structural limits built into the model:

CAC rises as cheap demand saturates.
Inventory turns into a growth tax.
Operations become nonlinear and harder to control.
Assortment expansion hits discovery and content ceilings.
Growth stays linear because there are no compounding loops.

At that point, optimization still matters, but it stops changing the cost curve. Better campaigns, better tools, and tighter processes improve outcomes at the edges, not the structure underneath.

The companies that move through this phase successfully don’t abandon eCommerce. They evolve the growth engine behind it.

They reduce their dependence on owned inventory.
They let partners, suppliers, or services carry part of the growth load.
They add layers that create compounding effects instead of linear effort.

Often, this happens through a marketplace layer added to an existing eCommerce business – not as a replatforming project, but as an extension of the model.

If there’s one takeaway from this article, it’s this:

The next phase of growth doesn’t come from pushing the same engine harder. It comes from changing how growth is generated in the first place.

If you’re considering the marketplace as your growth engine shift, we can help you define a safe MVP scope for your category – what to build first, what to postpone, and which guardrails to set so you don’t damage the core business. Talk to a marketplace expert!

FAQ on eCommerce platform vs marketplace

What is the difference between a marketplace and eCommerce?

The main differences between eCommerce vs marketplace come down to the business model, control, and how sales scale.

In a classic eCommerce setup, you run your own website and sell products directly to consumers. You manage inventory, prices, quality, and the entire supply chain. This model gives you total control, but growth depends on your ability to acquire new customers, fund inventory, and manage operations across online sales channels.

A marketplace, on the other hand, connects buyers and sellers on one platform. Products come from marketplace sellers or third parties, not from the platform itself. The marketplace focuses on access, discovery, transactions, and rules, while sellers handle inventory and fulfillment. In practice:

eCommerce scales through owned inventory and direct sales.
Online marketplaces scale by aggregating supply from many sellers.
Marketplaces trade total control for reach, brand exposure, and access to more customers.

That’s why many companies move toward a hybrid model, combining an ecommerce platform with a marketplace layer.

What is a marketplace in eCommerce?

A marketplace in eCommerce is a platform where multiple merchants or retailers sell products through a shared shopping experience.

Instead of one company selling from its own inventory, the marketplace allows new sellers, small businesses, or established retailers to list products across different product categories. Buyers can compare prices, quality, and delivery options from multiple sellers in one place.

Common marketplace models include:

business to consumer (B2C),
consumer to consumer (C2C), such as vintage items or craft supplies,
business-focused marketplaces serving multiple markets.

This model works well for expanding into other markets, testing new categories, and reaching potential customers without owning all the inventory.

What is an online marketplace?

An online marketplace is a digital platform that enables transactions between buyers and sellers across one or many markets.

Global marketplaces often operate across regions such as East Asia, Latin America, or Greater China, supporting cross-border selling and access to new markets. Well-known examples include Amazon, eBay, Mercado Libre, and platforms within the Alibaba Group ecosystem.

Compared to online stores, online marketplaces:

Attract more customers through shared demand,
Enable sellers to reach global ecommerce audiences faster,
Lower time constraints for entering new markets.

They are commonly used by small businesses and companies looking to sell online without building traffic from scratch.

Can you use both an eCommerce platform and a marketplace?

Yes, many companies use both the marketplace and their own ecommerce platform at the same time. In this setup:

The eCommerce focuses on brand control, margins, and direct relationships.
Marketplaces act as sales channels for customer acquisition and brand exposure.

This approach helps reach new customers, test other markets, and drive revenue without relying on a single channel. It’s especially common for businesses expanding into global marketplaces or multiple markets.

Is a marketplace better than eCommerce for selling products?

The right choice depends on your focus, resources, and growth goals.

Marketplaces are often better for:

reaching more customers quickly,
expanding into new markets,
Selling across multiple product categories.

Ecommerce platforms are better for:

maintaining total control over pricing and quality,
managing a custom production process,
building a direct relationship with consumers.

Many businesses start with eCommerce, then add a marketplace layer once inventory pressure, competition, or scaling limits appear.

Ecommerce Growth Strategy: 5 Signs Your eCommerce Is Ready to Become a Marketplace

Rigby — Tue, 01 Sep 2026 12:42:42 +0000

There’s a moment when eCommerce stops scaling even when everything is “done right”. Your eCommerce site still functions well, but growth no longer compounds the way it once did.

What makes this phase particularly challenging is the absence of a clear problem to solve. There is no single process or metric that would obviously explain what went wrong.

As a result, most teams respond by doubling down on optimization. They refine user experience, launch additional marketing initiatives, expand product categories, or invest in new features.

These are rational decisions - often the same ones that previously drove growth. But over time, the impact of each new initiative becomes smaller.

This moment is rarely about poor execution. More often, it signals that the current eCommerce model is approaching its natural limits of scalability.

For many businesses, this is where an eCommerce marketplace strategy becomes relevant. Rather than tying revenue growth only to products you source and stock yourself, a marketplace introduces third-party sellers into your ecosystem and expands product categories without increasing inventory exposure.

In this article, you will learn how to recognize the signals that indicate this shift and how to evaluate if evolving your eCommerce growth strategy toward a marketplace model makes sense for your business.

Key insights

Slowing revenue growth in eCommerce is often a structural issue, not an execution problem.
When optimization improves metrics but does not accelerate scale, your eCommerce growth strategy may be reaching its limits.
Inventory exposure, rising customer acquisition cost, and growing operational complexity are common signals of model constraints.
A marketplace changes how growth works by adding third-party sellers and reducing dependence on owned inventory.
Marketplace expansion only makes sense when demand, brand strength, and operational readiness are already in place.
Extending your existing eCommerce with a marketplace layer can shift your growth model without requiring full replatforming.

Why is the slow growth in an eCommerce store rarely an execution problem

When growth slows in your eCommerce store, the first reaction is usually operational. You review marketing performance, analyze the conversion funnel, revisit pricing, audit UX, and look for inefficiencies across the customer journey. These actions make sense – execution problems are common, measurable, and usually fixable.

In the early and mid stages of an eCommerce business, this approach works:

Improving campaigns lowers customer acquisition cost.
Optimizing checkout increases average order value.
Refining retention strategies improves customer lifetime value.
Performance improvements translate directly into revenue growth.

At a more mature stage, the dynamic changes.

You can still improve metrics, but the overall impact on growth becomes limited. Each new initiative requires more coordination and budget, yet the increase in revenue becomes incremental.

At this point, the issue is often misinterpreted. The assumption is that the team has not optimized enough, or that another round of adjustments will unlock the next phase of growth.

In reality, execution operates within the boundaries of the underlying model. If your eCommerce growth strategy depends entirely on selling products you own, stock, and promote, then scale is tied to internal resources. Optimization can stretch that model, but it cannot remove its structural limits.

Recognizing this distinction is uncomfortable. It challenges the belief that better performance is always the answer. Yet in practice, this moment often signals that the eCommerce model itself is becoming the limiting factor.

Before looking for new solutions, it is worth asking a different question: “What exactly is limiting our ability to scale?”

With this perspective in mind, the next step is to look for concrete signals that indicate when an eCommerce business has reached this point.

5 signs your eCommerce has reached its structural limits and is ready to become a marketplace

The shift from execution-driven growth to model-limited growth rarely happens overnight. It is usually a gradual process, visible only when looking at multiple areas of the business at once.

Individual issues may seem manageable in isolation. But when similar patterns appear across growth, operations, and resource allocation, they often point to a deeper structural constraint.

The following signals are not problems to fix. They help you assess whether your current eCommerce growth strategy is still built for scale.

Seeing one of them does not automatically mean your eCommerce needs to change its model. Seeing several at the same time, however, usually means the business has entered a new phase of maturity.

Sign #1: Growth slows down, even though optimization is working

Earlier in your journey, performance improvements translated directly into revenue growth:

Lowering customer acquisition cost increases profitability.
Improving conversion rates raises revenue.
Optimizing retention lifts customer lifetime value.

In a mature eCommerce, this relationship weakens. You can still improve these metrics, but the impact on total growth becomes limited.

This is often misinterpreted as a need for even more optimization. In reality, it is a sign that the core growth engine is operating close to its maximum efficiency.

Additional improvements no longer unlock proportional scale, because the limiting factor is no longer execution, but the structure of the model itself.

At this point, growth slows not because the business is underperforming, but because it is performing as well as the model allows.

Sign #2: Adding new categories brings complexity, not scale

Expanding into new categories is one of the most common growth strategies in eCommerce. It feels intuitive: more products should mean more opportunities to capture demand.

In practice, each new category adds operational weight:

Sourcing becomes more fragmented.
Inventory planning becomes less predictable.
Marketing efforts spread across more segments.
Coordination costs rise.

Revenue may increase, but margins tighten, and internal workload grows. The problem is not the number of categories themselves, but the fact that every new category must be fully owned by the business.

The organization spends more time managing complexity than generating leverage. If every new category must be owned, stocked, and financed by you, scale becomes expensive.

When category expansion adds complexity faster than it adds leverage, it often signals that the existing eCommerce model is reaching its structural limits.

Sign #3: Inventory becomes the main growth bottleneck

In many eCommerce businesses, inventory is initially a growth enabler. Having products in stock allows the company to respond quickly to demand, control customer experience, and scale revenue with confidence.

As you scale, inventory planning becomes a strategic constraint. Growth becomes increasingly dependent on how much stock the company can afford to purchase, store, and manage. Capital gets tied up long before revenue materializes, and forecasting mistakes become more expensive with scale.

Demand may exist, but your ability to meet it depends on how much risk you are willing to take upfront.

This dynamic slows growth in subtle ways: expansion decisions are delayed, assortment changes become conservative, and innovation is constrained by inventory exposure.

When inventory availability and inventory risk begin to dictate the pace of growth more than market demand, it is a strong signal that the eCommerce model is approaching its natural limits.

Sign #4: The team is busy, but impact is shrinking

Full roadmaps and active teams can create the impression of progress. However, the tangible impact of each new initiative becomes harder to see.

Projects are delivered on time, improvements are shipped, and KPIs move – but rarely in ways that meaningfully affect overall growth.

If each initiative requires significant coordination but produces limited strategic impact, your organization may be maintaining complexity rather than creating scale. Over time, internal effort increases while external growth slows.

A consistently busy team with declining marginal impact is often a signal that the eCommerce model itself has become operationally heavy and difficult to scale further.

Sign #5: Growth depends almost entirely on internal resources

At early stages, relying on internal resources is a strength. Owning products, inventory, pricing, and operations gives eCommerce businesses control and speed.

As scale increases, that structure creates linear growth, meaning revenue expands in proportion to internal investment.

When growth depends entirely on what the company can buy, build, stock, and operate on its own, expansion is inherently constrained. Every new initiative requires upfront investment, additional operational capacity, and increased risk exposure.

Ask yourself, can your business continue to grow without fundamentally changing how value is created and distributed?

When internal capacity defines the ceiling of growth, the limitations of the traditional eCommerce model become difficult to ignore.

What these signals have in common

Individually, each of these signals can be explained away:

Slower growth can be attributed to market conditions.
Operational complexity can be seen as a temporary phase.
Team overload may feel like a normal side effect of scale.

Taken together, however, they often point to the same conclusion: your eCommerce is no longer constrained by execution quality, but by the structure of its growth model.

Recognizing this doesn't mean you must become a marketplace, but you need clarity about where the real constraint lies.

Some business owners decide to continue to grow successfully within a classic eCommerce setup, especially when market conditions, margins, or operational advantages support it. Optimizing execution can still be the right path forward.

In other cases, adjusting the eCommerce growth strategy requires reconsidering how revenue is generated and how scale is achieved.

Before exploring alternatives such as an eCommerce marketplace strategy, use these signals to assess your current position.

When the marketplace makes strategic sense

If you recognized several of the five signs described earlier, it does not automatically mean you should have eCommerce and marketplace.

Those signs show that your current eCommerce growth strategy may be reaching its limits. They point to pressure in areas like revenue growth, inventory exposure, or internal capacity. But spotting slower growth is only the first step.

Before changing your model, you need to check whether your business is ready for it. Demand, brand strength, operational readiness, and platform capability matter just as much as slower growth.

A marketplace makes sense only when two things are true: your current model shows structural limits, and your business has the foundation to support a multi-vendor setup.

Strong and stable customer demand

If your eCommerce site consistently attracts customers, generates repeat purchases, and keeps customer acquisition cost under control, you already have a stable base.

A marketplace works best when you have steady traffic, strong customer relationships, and a clear target audience.

Recognizable brand and clear target audience

Sellers join platforms that give them access to a defined customer segment. If your brand image is strong, your customer testimonials build trust, and your audience is well understood, a marketplace can build on that position.

In this case, your existing customer base becomes attractive not only to new customers but also to sellers.

Growth limited by internal resources

If revenue growth depends mainly on how much inventory you can buy and manage, your model is capital-heavy. Expanding product categories requires more stock, more cash, and more operational work.

A marketplace can reduce that pressure by allowing third-party sellers to expand the assortment without increasing your inventory risk.

Operational readiness and platform capability

You need clear rules for sellers, control over the entire customer journey, and a payment process that supports multiple vendors.

Your eCommerce platform must handle marketplace integration without damaging the on-site experience. Without the right setup, a marketplace creates confusion instead of scale.

Need to diversify revenue sources

If your eCommerce growth strategy depends only on selling products you own, your revenue is tied directly to sourcing and stock.

A marketplace adds another revenue stream through commissions or transaction fees. It does not replace your eCommerce store. It adds a second growth engine alongside it.

How the marketplace changes your eCommerce growth strategy

Having an eCommerce and marketplace changes how growth works. Instead of relying only on what you own, stock, and promote, you create a structure where customers and third-party sellers both contribute to scale.

Below are the main ways a marketplace reshapes your eCommerce growth strategy, with practical use cases.

Expanding product categories without owning inventory

In a traditional eCommerce business, adding new product categories requires sourcing, forecasting demand, and investing in stock. Growth is limited by working capital and operational capacity.

With a marketplace model, third-party sellers list products on your platform. You expand the assortment without increasing inventory exposure. This changes your eCommerce growth strategy from inventory-led expansion to ecosystem-led expansion.

Use case: Your eCommerce store sells sports equipment and has strong traffic in the running category. Instead of buying new inventory in adjacent categories like nutrition or wearable accessories, you onboard specialized sellers. Customers see a broader offer, average order value increases, and you avoid additional stock risk.

Creating a scalable ecosystem instead of a linear operation

In a classic model, growth is linear. To increase revenue, you need more inventory, more staff, and more marketing spend.

In a marketplace, growth becomes less dependent on internal resources. Sellers expand their assortment, while customers generate demand. Your role shifts toward platform governance, eCommerce marketplace management, and quality control.

Use case: Instead of planning expansion only around how much stock you can finance next quarter, you plan around which new seller categories fit your brand and customer segment. Growth planning moves from capital allocation to ecosystem design.

Turning customer relationships into a growth asset

In a classic setup, you improve the customer journey, run a loyalty program, and offer exclusive discounts to increase customer lifetime value.

In a marketplace model, your existing customer base becomes attractive to sellers. Customer relationships are no longer only about retaining buyers. They also help attract supply.

Use case: Your eCommerce site has strong brand recognition and a defined target audience. Instead of pushing traffic to a third-party platform, you invite external brands to sell within your ecosystem. Sellers gain access to your customers, while you keep control over the entire customer journey and maintain direct communication.

Adding a second revenue stream

In a traditional growth strategy for eCommerce, revenue comes from selling products you own. Increasing revenue requires more inventory, more marketing campaigns, and higher operational capacity.

A marketplace introduces commission-based income. This allows revenue growth without proportional increases in inventory investment.

Use case: Your platform processes 100,000 monthly visits. In a classic model, revenue depends on your own product margins. In a marketplace structure, every transaction from third-party sellers generates commission revenue. Even if you do not own the product, you participate in the transaction.

Reducing dependence on customer acquisition cost

In many eCommerce businesses, customer acquisition cost increases over time. Paid channels become more competitive, and marketing efforts require larger budgets to reach new customers.

A marketplace can reduce pressure on acquisition in two ways. First, a broader assortment attracts more potential customers organically. Second, sellers may bring their own traffic. Your growth strategy for eCommerce shifts from fully paid growth to partially network-driven growth.Use case: You onboard niche brands with strong social media communities. They promote their products and link back to your platform. Your sales channels expand beyond your own marketing campaigns, and customer acquisition becomes partially shared.

Using data and customer behavior on a broader scale

An eCommerce store collects data mainly about customer behavior and product performance.

In a marketplace model, this data expands across more product categories and sellers. Marketplace structure allows you to use valuable insights from your existing customer base to shape supply more dynamically.Use case: You identify that a specific customer segment frequently purchases eco-friendly products. Instead of developing your own line, you onboard third-party sellers that match this demand. You respond faster to customer expectations without investing in product development.

Rethink your eCommerce growth strategy and add a marketplace layer without disrupting your core

If, after reading this article, you identify that your eCommerce growth strategy is reaching structural limits, do not abandon what already works. In most cases, the stronger approach is to extend your current eCommerce with a marketplace layer that changes how scale is generated.

For many businesses running on Shopify, Magento (Adobe Commerce), or custom ERP-driven systems, the ceiling appears as rising maintenance costs, performance constraints, or growing complexity. Replatforming feels risky and expensive. Yet staying within the same structure limits future revenue growth.

Mercur is designed to solve that tension. Instead of replacing your core eCommerce platform, Mercur adds multi-vendor marketplace capabilities on top of it,

Your existing commerce engine continues to handle products, checkout, and customer experiences.
Marketplace logic – vendor onboarding, commission rules, seller workflows, and transaction orchestration – operates as a separate layer.

This ecommerce marketplace solution allows you to introduce third-party sellers without disrupting your current eCommerce store. There is no need for a full migration, no pause in development, and no forced platform lock-in. You can start with a narrow marketplace scope, validate the economics, and expand only when the model proves itself.

A short architectural discussion can clarify how a multi-vendor model should fit into your current ecosystem and prevent long-term technical debt and unnecessary rework.

To explore how a marketplace layer could extend your eCommerce growth strategy, book a marketplace consultation with the Mercur team.

FAQ on eCommerce marketplace strategy

What is the growth strategy of eCommerce?

An eCommerce growth strategy defines how your eCommerce business plans to increase revenue over time. At the beginning, growth usually depends on customer acquisition, marketing campaigns, and expanding product categories. You focus on reaching potential customers through social media channels, influencer partnerships, and paid marketing efforts in order to attract shoppers and maximize sales.

As your eCommerce store matures, the strategy shifts. Instead of focusing only on new customers, you work on retention strategies, repeat purchases, and increasing customer lifetime value. You analyze customer behavior, gather customer feedback, and optimize the entire customer journey to create exceptional customer experiences.

What is an eCommerce marketplace?

An eCommerce marketplace is a platform where third-party sellers offer products alongside your own eCommerce store. Instead of only selling products you own, you allow external vendors to list their product categories and reach customers within your ecosystem.

In this model, you manage the eCommerce platform, the payment process, customer segment, and the on-site experience, while sellers manage their own inventory. Revenue can come from commissions or service fees rather than only from selling products directly.

An eCommerce marketplace can expand your assortment without increasing inventory exposure. It can also help attract new customers and strengthen brand recognition. For businesses with a strong customer base and established brand image, a marketplace can become an additional growth engine rather than a replacement for their own eCommerce.

What is marketplace integration?

Marketplace integration is the process of connecting marketplace functionality with your existing e-commerce business. It allows third-party sellers to operate within your ecosystem while you maintain control over the entire customer journey.

Strong eCommerce marketplace integration ensures that adding a marketplace layer does not disrupt customer relationships or customer expectations. Instead, it expands product categories and sales channels while keeping control within your own eCommerce business rather than pushing customers to a third-party platform.

How to create an eCommerce marketplace?

To create an eCommerce marketplace, start by deciding how to build it. You can extend your existing online business with eCommerce marketplace integration, add a dedicated marketplace extension, or adopt a specialized multi-vendor ecommerce marketplace solution designed for multi-vendor operations.

The right choice depends on your technical resources, long-term e-commerce growth strategy, and how much control you want over eCommerce marketplace management and the payment process.

What is the difference between eCommerce platform and marketplace?

An eCommerce is a platform where you control inventory, pricing, and product selection. Growth depends on how effectively you execute your eCommerce strategy, optimize key performance indicators, retain customers, and convert potential customers into repeat customers.

A marketplace allows third-party sellers to operate within your platform, while you manage the infrastructure, payment process, and customer experiences. Instead of relying only on selling products you own, you facilitate transactions between customers and vendors.

Excess Inventory: Why It's Killing Your Growth (and How Marketplaces Solve It)

Rigby — Tue, 01 Sep 2026 07:46:56 +0000

Your warehouse might be slowing your growth more than your competition. According to McKinsey, companies allocate about $300 billion each year to warehouse operations.

Surplus inventory often looks like a valuable asset in financial statements. In practice, it creates unnecessary expenses and financial losses.

Nearly $1.5 trillion worth of merchandise sits in an overstocked state globally every year, generating lost revenue instead of contributing to sales.

When excess inventory builds up, you deal with tied-up capital, limited cash flow, rising storage costs, and valuable warehouse space filled with slow-moving items instead of products that match actual customer demand.

Slow-selling items and excess products continue to accumulate because your model depends on predicting future customer demand in advance.

More warehouse space doesn’t fix that structure.

Owning excess inventory storage means you take on the risk when market trends shift. When demand drops, unsold items remain in storage and tie up cash that could support growth in other areas of your business.

In this article, you will learn what excess inventory is, how it happens, how to identify and calculate it, and how a marketplace business model helps you reduce excess inventory without expanding your warehouse space.

Key takeaways

If your inventory levels consistently exceed actual customer demand, you are likely dealing with excess inventory that ties up capital and limits your ability to invest in growth.
Holding surplus stock increases storage costs, carrying costs, and reduces profit margins as unsold inventoryremains in your warehouse for an extended period.
Calculating how much capital is tied up in excess products helps you understand the direct impact of unsold stock on your cash flow and business operations.
A marketplace model allows you to expand your product offering without increasing inventory levels, which reduces dependence on owned stock and warehouse space.
Extending your eCommerce with a marketplace layer allows external suppliers to fulfill part of the customer demand that would otherwise require you to purchase and store extra inventory.

What is excess inventory, and how does it happen? (4 common scenarios)

Excess inventory refers to stock that goes beyond actual demand within a given period. It includes unsold items, slow-moving items, and products that stay in storage long after their expected sales cycle.

You planned to sell them. Customer demand didn’t follow your sales forecasts.

This often starts with inaccurate demand forecasting based on historical data that no longer reflects current market trends.

Your inventory management process assumes stable demand, while customer demand changes due to price sensitivity, seasonal trends, or new competitors offering similar products at competitive prices.

Here are 4 common scenarios where excess stock builds up:

1. Overestimated demand

Your sales team expects increased demand for a product line based on last year’s sales data. You increase stock levels to prepare for the upcoming quarter. Then:

customer demand shifts to newer alternatives,
a competitor launches similar products at a slightly lower price,
market demand drops due to macroeconomic changes.

You now hold surplus stock that doesn’t move. Inventory levels stay high, and unsold inventory occupies valuable storage space.

2. Supply chain disruptions

You increase safety stock to protect your supply chain from delays. Later: suppliers stabilize deliveries, logistics timelines improve, and your inventory needs decrease.

Yet extra inventory already sits in your warehouse. What was meant to protect business operations becomes too muchstock, which increases storage costs and carrying costs over time.

3. Seasonal products that miss the window

You prepare inventory for a seasonal trend such as winter apparel. Customer demand peaks for a short period. After the season ends, slow-selling items remain as surplus inventory.

You now manage excess inventory that requires selling online at a discounted price, running a flash sale, or offering bundles at a slightly lower price.

All of these actions reduce profit margins and increase financial losses.

4. Bulk purchasing incentives

Suppliers offer better pricing when you order large quantities. You align supply with expected demand to reduce unit costs.

However, actual demand stays lower than projected, and unsold stock accumulates.

Lower purchase cost per unit leads to increased costs in storage space and unnecessary expenses related to inventory tracking and storage.

Excess inventory management ties up capital that could support marketing, product development, or expansion into new sales channels. Instead, it sits in storage, generating carrying costs and limiting your ability to react to demandchanges.

What are the consequences of excess inventory?

When excess inventory builds up, the impact goes far beyond warehouse operations.

Unsold inventory starts to affect your cash flow, storage space, financial statements, and your ability to respond tocustomer demand.

96% of businesses fail to recover even 75% of what they paid for surplus stock, and in most cases, they lose half of the product’s cost or more when trying to clear unsold inventory.

Over time, surplus stock becomes a source of increased costs that slows down growth across multiple areas of your business.

Reduced cash flow

When too much inventory sits in storage, your working capital stays locked in unsold stock instead of funding daily business operations.

Tied-up capital limits your ability to react to changes in customer demand or shifting market trends.

Increased storage costs

As inventory levels grow beyond actual demand, you may need to expand your warehouse space, rent external storage, or reorganize valuable storage space.

This leads to increased costs related to rent, utilities, inventory tracking systems, insurance, and warehouse operations.

Higher carrying costs

Managing excess inventory comes with ongoing carrying costs, such as handling, packaging, depreciation, and insurance.

Even when products don’t sell, they continue to generate unnecessary expenses across your supply chain.

Reduced profit margins

To sell excess products, you often lower prices through flash sales, bundles, or clearance campaigns.

Selling online at a slightly lower price helps move inventory quickly, but it also reduces profit margins and may impact perceived product quality over time.

Occupied warehouse space

Too much stock limits your ability to introduce new product lines, increase stock levels for bestsellers, or adapt inventory needs to seasonal trends.

How to identify excess inventory? Checklist for Operations Leaders

You usually see the first signals of excess inventory challenges in cash flow, storage space, or financial statements before anyone flags it inside inventory management reports.

As an operations leader, you don’t need to review every SKU to understand when surplus inventory starts to build up. You can spot excess stock by asking a few business-level questions across sales, finance, and supply chain teams.

Use this checklist to identify when unsold inventory begins to affect growth.

1. Your cash flow is tightening while inventory levels increase

If revenue stays stable but tied-up capital grows in financial statements, you may already be holding extra stock that doesn’t match actual demand.

2. Your warehouse space fills up without a rise in sales

If storage space utilization increases but customer demand remains unchanged, slow-moving items or unsold stock may be accumulating across product categories.

3. Your carrying costs increase quarter over quarter

If storage costs, insurance, handling, and inventory tracking expenses continue to grow, managing excess inventorymay already be affecting your margins.

4. You rely on sales forecasts that don’t match real-time data

If demand forecasting is based on historical data instead of real-time sales data, inaccurate forecasting may lead to too much inventory across multiple SKUs.

5. Your sales team frequently requests discounted price campaigns

If teams regularly ask for flash sales or clearance campaigns to sell excess products, this often signals a mismatch between stock levels and customer demand.

6. You increase safety stock due to supply chain uncertainty

Supply chain disruptions often lead to higher safety stock. If supply stabilizes but inventory needs remain unchanged, surplus stock may stay in storage for an extended period.

7. You delay new product launches due to a lack of storage space

If unsold inventory occupies valuable storage space that could support new product lines, excess inventory may already limit business operations.

8. You notice growing write-offs in financial statements

If unsold items require tax write-off or tax deduction decisions more often than before, excess and obsolete inventorymay already be generating financial losses.

9. Your inventory turnover rate declines across product lines

If products take longer to sell despite stable market demand, inventory levels may exceed actual demand.

If you answer yes to several of these questions, you may already be managing excess inventory that affects cash flow, profit margins, and your ability to align supply with customer demand.

How do you calculate excess inventory cost?

Once you’ve identified that you’re dealing with excess inventory, the next step is to understand its financial impact on your business operations.

To manage excess inventory properly, you need to calculate how much of your inventory goes beyond actual demand within a given period.

Start with a simple comparison between your current stock levels and your forecasted demand.

Step 1: Define your expected demand.

Use your sales data and recent sales forecasts to estimate how many units of a product you expect to sell within a specific timeframe. This could be:

30 days,
60 days,
one sales quarter,
a full season for seasonal products.

This number reflects expected customer demand based on your demand forecasting models.

Step 2: Review your current inventory levels.

Check how many units of the same product you currently hold in storage.

Your inventory tracking system should provide real-time inventory tracking data for each SKU.

Step 3: Apply the excess inventory formula.

You can calculate excess inventory using the following formula:

Excess Inventory = Current Inventory - Forecasted Demand

If you currently hold 5,000 units of a product but expect to sell only 3,000 units within the next quarter, your excess stock equals 2,000 units.

These 2,000 units represent:

tied up capital,
additional carrying costs,
increased storage costs,
and unsold items that may require discounted price campaigns later.

Step 4: Calculate financial exposure.

To understand how excess inventory affects cash flow, multiply the number of excess products by the cost per unit.

Excess Inventory Cost = Excess Units × Cost per Unit

If your 2,000 excess units cost $50 each, you now hold $100,000 in tied-up capital that doesn’t generate revenue.

This $100,000 reflects unnecessary expenses in storage space and capital that could support marketing or expansion!

Now that you know excess inventory exists in your business and how much it costs you, it’s time to solve the problem.

How to reduce excess inventory with the marketplace business model?

Don't worry, there are many excess inventory solutions that will prevent your cash flow and storage space. Most of them focus on clearing unsold stock after the problem already exists.

Each of these methods helps you sell excess items and manage inventory. None of them changes how excess stock builds up in the first place.

Instead of focusing on excess inventory management after it appears, you can change how your eCommerce growth engine works. A marketplace business model allows you to grow your product offering and revenue without increasing your inventory needs or storage costs.

Check out this 5 signs to see if your eCommerce is ready do become a marketplace!

What is a marketplace, and how does it reduce excess inventory?

A marketplace is an eCommerce platform that allows you to sell products from third-party sellers without owning the inventory yourself.

Instead of purchasing stock in advance and storing it in your warehouse, you give external vendors access to your sales channel. Sellers list their products in your store, manage their own inventory levels, and handle fulfillment when an order is placed.

Because sellers manage their own inventory and shipping, you minimize financial losses and reduce the need to maintain high inventory levels. You expand your catalog with new product categories without increasing storage space.

Your warehouse holds only the products you decide to own strategically. Everything else can be offered through vendor inventory, which reduces tied-up capital and the risk of excess and obsolete inventory.

Instead of forecasting demand months in advance, you sell products that already exist in vendor warehouses.

In a marketplace model, your role changes from inventory owner to platform operator. You onboard and manage third-party sellers, commission rules for transactions, product approval workflows, catalog quality across multiple sellers, and payouts.

As a result, your growth becomes less dependent on how much inventory you can store and more dependent on how much demand your platform can capture.

Financial benefits of the marketplace model

Once you reduce your dependence on owned inventory, the financial impact becomes visible across your operating costs and cash flow.

A marketplace model changes how capital is used in your business. Instead of investing in stock that may remain unsold, you invest in customer acquisition, vendor relationships, or expanding your product offering.

Explore how the business model changes the cost curve in marketplace vs eCommerce!

Reduced operational costs

When you reduce ownership of physical inventory, you also reduce storage costs related to warehouse space, handling, packaging, and insurance.

You no longer need to maintain extra stock to cover demand fluctuations or supply chain disruptions. Carrying costs drop because fewer products remain in storage for an extended period.

Improved cash flow

When you shift part of your catalog to marketplace supply, fewer funds stay locked in unsold items, and inventory purchases decrease.

Working capital becomes available for growth initiatives, such as customer acquisition or expanding into new product categories.

You move from inventory-based growth to commission-based growth.

Additional revenue streams

Marketplace models allow you to generate revenue through commission on each transaction, listing fees, vendor subscriptions, or promotional placements for sellers.

You increase sales without increasing inventory needs or expanding warehouse space.

How to extend your eCommerce with a marketplace layer

At this stage, you already know that excess inventory exists in your business and how much tied-up capital sits in unsold stock. The next step is to change how inventory enters your sales channel.

This is achievable through dedicated marketplace platforms or integrations that allow you to connect third-party sellers directly to your eCommerce.

One of these platforms is Mercur, which can integrate with your existing Shopify, Magento, or any custom eCommerce system. Mercur allows you to introduce multi-vendor marketplace capabilities without replacing your current eCommerce platform or interrupting daily business operations:

Your existing commerce engine continues to handle owned inventory, checkout, and customer experience as before.
Marketplace logic (vendor onboarding, commission rules, seller workflows, and transaction orchestration) operates as a separate layer that connects external supplier inventory to your platform.
Your eCommerce store continues to operate, while the marketplace supply absorbs part of the customer demand that would otherwise require you to increase inventory levels.

This separation of concerns ensures that the marketplace logic is isolated and extensible, allowing for the independent scaling of vendors and workflows without slowing down the core performance.

No migration, no replatforming, no vendor lock-in.
No need to pause current eCommerce development.
Works with custom and legacy platforms.
Clear separation between commerce and marketplace logic.
API-first, event-driven integration.

If you’re considering the marketplace as your growth engine shift, don’t start with development!

Before building anything, it’s worth validating how a multi-vendor marketplace should live in your ecosystem. A short architecture conversation can save months of development and years of technical debt. Book a marketplace consultation!

Summary: Your warehouse and excess stock doesn’t have to define your growth

Excess inventory ties up cash, increases storage costs, and limits your ability to respond to real customer demand.

After reading this article, you’ve seen how surplus stock builds up. You’ve calculated how much capital sits in unsold inventory. You understand how carrying costs and storage space quietly reduce your profit margins.

The core issue is structural. When your growth depends on purchasing stock in advance, you take on forecasting risk, supply chain risk, and obsolescence risk.

The more you scale, the more inventory you need. The more inventory you need, the more capital stays locked in your warehouse.

A marketplace model changes that structure. You expand your catalog without increasing stock levels.

If you want to explore how a marketplace layer could reduce excess inventory in your specific category, we can help you define a safe MVP scope. You’ll clarify what to build first, what to postpone, and which guardrails to set so you don’t damage your core business. Talk to a marketplace expert!

FAQ on managing excess inventory

What is inventory excess?

Inventory excess refers to stock levels that exceed actual customer demand within a given period. It includes unsold inventory, slow-moving items, and surplus stock that remains in storage longer than expected based on your sales forecasts.

This often happens when demand forecasting relies on outdated historical data or when market trends shift faster than your inventory planning cycle. As a result, you hold too much inventory that ties up cash and occupies valuable warehouse space.

What is excess inventory management?

Excess inventory management is the process of identifying, tracking, and reducing surplus inventory before it leads to financial losses.

It involves monitoring inventory levels using real-time inventory tracking, comparing stock levels with actual demand, and adjusting purchasing decisions based on updated sales data.

The goal is to minimize carrying costs, reduce storage costs, and prevent tied-up capital from accumulating in unsold stock.

What to do with excess inventory?

When excess products build up, companies often try to sell excess inventory through flash sales, bundles, or clearance campaigns. Some businesses move surplus inventory through liquidation partners or sell online at a slightly lower price to recover part of their investment.

Other options include bulk sales to resellers, donations to charitable organizations for potential tax deductions, or recycling programs for excess and obsolete inventory that can no longer be sold.

In some cases, companies also introduce third-party sellers to help increase sales without increasing inventory needs in the future.

What is a best practice for managing excess or expiring inventory?

One common approach for managing excess or expiring inventory is to monitor slow-selling items early using real-time sales data and inventory tracking tools.

Reviewing stock levels regularly helps you identify unsold items before they become excess and obsolete inventory.

You can also adjust safety stock levels based on seasonal trends and recent customer demand rather than relying only on historical data.

Many companies also align supply with actual demand by reducing bulk purchases and introducing flexible supply through vendor networks or marketplace models.

Why is holding excess inventory bad?

Holding too much inventory increases storage costs, insurance, and handling expenses over an extended period.

Surplus stock ties up capital that could otherwise support marketing, hiring, or expansion into new product categories. It may also reduce profit margins if you need to sell excess products at a discounted price.

Over time, excess inventory limits your ability to react to changes in customer demand and slows down business growth.

Why You Shouldn't Create a Multi-Vendor Marketplace in Magento: 14 Reasons, Costs & 2026 Data

Rigby — Wed, 26 Aug 2026 12:03:48 +0000

Many commerce teams still consider using Magento as the foundation for a marketplace. Mainly because it is powering around 8% of eCommerce sites worldwide.

Often the reasoning also goes like this: they already have a Magento store, and they know Magento developers – so why not build on top of what they already have?

Meanwhile, Magento stores declined 10% year-over-year in Q4 2025, and "what they already have" is a platform with no native support for multi-vendor marketplace architecture.

If you are considering building a marketplace in Magento, you will face a structural problem from day one. The platform does not support multiple sellers, split payments, vendor onboarding, seller dashboards, or commission management.

Every one of these capabilities must be added through third-party extensions or paid add-ons.

What you end up with is a system of plugins where marketplace logic sits on top of a monolith that was never designed for it.

In this article, you will see why Magento is the wrong foundation for a multi-vendor marketplace – the architectural limitations, the extension risks, and the operational friction that compounds over time. You will also find out what a purpose-built online marketplace platform should actually provide.

Key takeaways

Magento has zero native marketplace functionality. Every marketplace capability must come from third-party extensions.
The most common path (Webkul + add-ons) means assembling 5–15 paid plugins on top of a monolith that was designed for single-seller commerce. Each add-on adds upgrade risk, performance overhead, and a new dependency you do not control.
Adobe Commerce licensing runs $22K–$125K/yr depending on GMV. Add extensions ($1,500–$3,000+), hosting, and specialist PHP development – your total cost of ownership is unpredictable and compounds with every new feature.
PHP usage among developers dropped from ~30% (2021) to 19% (2025). Fewer engineers are entering the Magento ecosystem, making hiring slower and more expensive as your marketplace grows.
The right marketplace platform should have multi-vendor logic in its core architecture, a predictable cost model, a technology stack you can hire for, and an API-first design that does not punish change.
If you are starting a new marketplace, there is no architectural reason to choose Magento over platforms built for multi-vendor commerce from the ground up. If you already run a Magento store and want to add marketplace capabilities – plan the migration early, before the extension stack becomes too deep to unwind.

What is a marketplace, and what features does it need to provide?

A standard e-commerce store has one seller. You own the inventory, you set the prices, you fulfill the orders, and every transaction flows through a single business entity.

Magento, Shopify, WooCommerce – most eCommerce platforms were built for exactly this model.

A multi-vendor marketplace is a different architecture altogether. You operate the platform, but you are not the only seller.

Multiple independent vendors list products, manage their own inventory, set their own pricing, and fulfill their own orders – all within a single system that your buyers experience as one cohesive shop. Think Amazon, Etsy, or Airbnb.

The marketplace operator controls the rules, takes a commission, and orchestrates the experience. The vendors run their own businesses within that framework.

When you evaluate whether a platform can support a marketplace, you need to look at a specific set of capabilities. Here is what a multi-vendor marketplace requires at the platform level.

8 must-have features marketplace needs to provide

Below, you will find a closer look at each of these capabilities and why they matter.

Seller onboarding and approval

Your marketplace needs a structured process for bringing new vendors onto the platform.

That means the seller's transaction details, registration forms, identity verification (KYC), document collection, approval workflows, and configurable criteria for who gets accepted. You also need the seller approval functionality to reject, suspend, or tier sellers based on performance or compliance.

If onboarding is manual and admin-driven, your operations team becomes a bottleneck from day one.

Separate seller dashboard

Each vendor needs their own workspace independent from your admin panel and isolated from other sellers.

A marketplace seller dashboard should let vendors manage products, track orders, view their earnings, handle returns, and communicate with buyers. The quality of this interactive vendor dashboard directly affects seller adoption.

If your sellers cannot self-serve – add products, check their transaction details, or update their seller profile – your support team absorbs that workload instead.

Multi-vendor product and catalog management

Multiple vendors may sell the same product. You need product approval workflows, attribute normalization, duplicate detection, and category mapping across sellers.

The store admin needs to control which products go live, enforce quality standards, and manage a shared catalog without giving individual sellers the ability to break it.

A seller collection page, a seller shop with its own branding, and product-level attribution ("sold by Vendor X") all need to work natively.

Commission engine and split payments

Your revenue model depends on commission logic, and that logic needs to be flexible.

You may charge a flat percentage, a category-based rate, a tiered commission that changes with volume, or a per-vendor custom deal. The platform needs to calculate commissions automatically, generate payout reports, and split payments at the transaction level.

When a buyer places an order with products from different sellers, the payment must be divided correctly between the marketplace operator and each vendor.

Multi-vendor order management

A single order on your marketplace can contain products from multiple sellers. Each seller needs to fulfill their own portion independently with their own shipping methods, tracking numbers, and delivery timelines.

Your order management system must support order splitting, per-vendor fulfillment tracking, seller-specific SLAs, and partial refunds.

The buyer sees one order. Behind the scenes, the system routes each item to the responsible vendor and tracks it separately.

Marketplace analytics and reporting

You operate at two levels: the marketplace as a whole and each individual vendor. Your reporting needs to reflect both.

You need aggregated GMV, take rate, active sellers, order volume, and dispute rates at the platform level.
Each vendor needs access to their own sales reports, traffic to their seller profile page, top selling categories, and payout history.
Finance teams need reconciliation reports that match commissions, payouts, refunds, and fees.

A single-seller analytics setup does not cover this, you need marketplace-native reporting from the start.

Ratings, reviews, and trust systems

Buyers on a marketplace are purchasing from vendors they may not know. You need seller-level ratings and reviews (separate from product reviews) to build trust.

A seller's reputation score, response time, fulfillment rate, and return rate all feed into how prominently they appear in search results and whether they retain their selling privileges.

Your platform should support seller reviews, product reviews with seller attribution, and moderation tools for the store admin.

Dispute resolution and return handling

When something goes wrong on a marketplace, the question of responsibility is more complex than in a single-seller store. Was the item shipped late by the vendor? Was it damaged in transit? Did the product match the listing?

Your platform needs a dispute workflow that involves the buyer, the vendor, and the marketplace operator. Return policies may vary by seller. Refunds may need to be partially funded by the vendor's commission balance.

None of this works if your system treats every transaction as a simple two-party exchange between "the store" and "the customer."

Now that you know what a multi-vendor marketplace actually requires, let's see how Magento attempts to deliver it (and where that attempt falls apart).

How Magento "supports" the marketplace business model: Magento marketplace extensions

Magento – both the open-source version and Adobe Commerce – ships with zero marketplace functionality.

There is no seller registration, no vendor dashboard, no commission engine, no split payment logic, and no multi-vendor order management anywhere in the core platform.

The Adobe Commerce Marketplace (the official extension store) lists over 3,000 extensions across all categories, but none of them are first-party marketplace modules from Adobe itself.

If you want to run a multi-vendor marketplace on Magento, your only path is through third-party marketplace extensions.

The ecosystem here is narrow. A handful of vendors offer Magento marketplace modules, and in practice, most implementations you will encounter rely on one dominant player.

Webkul Multi Vendor Marketplace

Webkul is the de facto standard for building a marketplace in Magento. Their Multi Vendor Marketplace module is the most widely deployed marketplace extension in the Magento ecosystem.

The base module costs $349 for Magento Open Source with an additional $349 if you run your store on Adobe Commerce.

It provides the foundational layer: a separate vendor dashboard, seller profile pages, basic commission management, and store admin management.

On paper, this covers the basics. In practice, the base module alone will not give you a fully functional marketplace. You will need paid add-ons – and Webkul has built over 100 of them for Magento 2 alone.

Split payments? Separate add-on (Stripe Connect, PayPal, Mangopay – each a different module).
Seller-specific shipping (FedEx, UPS, USPS, table rate)? Separate add-ons.
RMA and return management? Add-on.
Seller-level advanced reporting to display sales reports? Add-on.
Mass product upload for sellers? Add-on. Marketplace landing page customization? Add-on.
Buyer-seller communication? Add-on.

Each module carries its own license cost, its own update cycle, and its own compatibility constraints with both the Webkul base module and Magento core. You are assembling your marketplace feature set one paid plugin at a time.

Other Magento marketplace extensions

A few other vendors offer Magento 2 multi-vendor marketplace extensions, though with smaller install bases and narrower ecosystems:

CedCommerce is the second most recognized name in the Magento marketplace extension space. Their Magento 2 Multi Vendor Marketplace module offers a similar feature set to Webkul with a stronger focus on B2B capabilities.
Apptha provides a multi-vendor module priced at $999 with around 56 add-ons, fewer than Webkul but still following the same modular approach.
CreativeMinds offers a marketplace extension oriented toward vendor reviews and SEO optimization for seller pages, targeting a lighter marketplace setup.
MagenestandMagetop round out the field with lower-priced alternatives that cover core vendor management and product approval functionality, though with smaller support teams and less frequent update cycles.

What every option has in common

Regardless of which Magento marketplace extension you choose, the architecture remains the same: you are layering third-party plugin code on top of a platform that was designed for single-seller commerce.

The marketplace logic lives entirely in extension code, not in Magento's core data model or API layer.

For a small pilot with a few vendors selling simple products, this can work.

Where it starts to break is at scale – when you have dozens of sellers, thousands of SKUs, complex commission rules, and a Magento admin panel that has to coordinate with five or ten interdependent extensions on every order.

That is where we go next. In the following section, you will see exactly why this extension-based approach hits a wall and what specific limitations you will run into when you try to run a real multi-vendor marketplace on Magento.

The limitations listed below come from our own technical analyses, conversations with eCommerce teams who have built (or attempted to build) marketplaces on Magento, discussions across developer communities, and publicly available data from industry reports.

Why Magento breaks for multi-vendor marketplaces: 14 Magento marketplace limitations

The previous section covered what is available. This section covers what happens when you actually try to run a multi-vendor marketplace on Magento.

Each limitation below is a structural problem, not a configuration issue you can fix with better hosting or another plugin.

1. No native marketplace support

This is the root of every other problem on this list. Magento was architected as a single-seller eCommerce platform. Its data model, API layer, admin panel, and order management system all assume one merchant owns the entire catalog.

There is no concept of a "seller" in Magento's core schema. No vendor entity, no seller-level permissions, no commission logic, no multi-party transaction model.

When you install a marketplace extension like Webkul, you are adding seller management on top of a system that has no native awareness of multiple sellers.

The extension creates its own database tables, its own admin interfaces, and its own API endpoints – all running in parallel with Magento's core, not integrated into it. Any update to one extension can break others. A Magento core patch can break all of them simultaneously.

The more modules in your stack, the larger the surface area for conflicts, the longer the QA cycle for every release, and the higher the risk of production incidents.

What this means for your business: You are not running a marketplace platform. You are running a single-seller eCommerce store with a multi-vendor layer bolted on top. Your marketplace's stability is only as strong as the weakest extension in your stack. You do not control the release schedules, code quality, or compatibility testing of these third-party modules.

2. High total cost of ownership

The costs of a Magento marketplace stack up from multiple directions.

If you go with Adobe Commerce, licensing alone starts at $22,000/year and can exceed $125,000/year depending on your GMV/AOV. If you use Magento Open Source, you avoid the license fee, but you also lose access to Adobe's B2B modules, cloud hosting, and dedicated support.

On top of the platform cost, you are paying for marketplace extensions. A baseline Webkul setup – base module, split payments, seller shipping, RMA, and advanced reporting – can easily reach $1,500–$3,000 in license fees before any customization. Each add-on carries its own annual renewal or support cost.

Then add hosting, specialist PHP development, and the ongoing cost of managing extension compatibility across every upgrade. Full implementation costs for Adobe Commerce commonly exceed $150,000–$200,000.

What this means for your business: Your total cost of ownership is unpredictable and compounds over time. Every new marketplace feature requires evaluating extension costs, dev hours, and compatibility risk before you write a single line of business logic.

3. PHP technology declining

Magento is built on PHP. The Stack Overflow Developer Survey 2025 showed that only 19.1% of professional developers use PHP – down from around 30% in 2021. Among developers learning to code, just 14.5% chose PHP.

In "desired" language rankings, only about 9% of developers want to try PHP, and fewer than half of current PHP developers want to continue using it.

The practical consequence: Magento developers are harder to find and more expensive to hire. Fewer junior developers are entering the PHP ecosystem. The agencies that specialize in Magento are shrinking along with the platform's market share.

What this means for your business: You are building on a technology stack with a contracting talent pool. As your marketplace grows and you need to hire or scale your engineering team, you will compete for a shrinking supply of specialists at premium rates.

4. Adobe neglects the open-source version

Magento Open Source still receives security patches and bug fixes. However, Adobe no longer introduces new features or functionalities to the open-source edition.

All recent and future feature development for Adobe Commerce is delivered as SaaS-based add-ons with no open-source code.

The community has noticed. Mage-OS, an independent fork of Magento Open Source, was created specifically because the community sees a lack of focus on Magento Open Source development from Adobe's side.

BuiltWith shows that the absolute number of live sites is still significant, but the trend line is consistently downward and Adobe Commerce is losing net customers to composable and SaaS alternatives.

What this means for your business: If you build your marketplace on Magento Open Source to avoid licensing costs, you are betting on a platform whose owner has deprioritized it. If you pay for Adobe Commerce, you are paying premium prices for a platform that is losing market share. Neither path offers long-term confidence.

5. Poor performance and scalability

Magento is a resource-intensive platform even in single-seller mode.

Add marketplace extensions, and the performance picture degrades further. Each module works independently, re-requesting data that other modules have already fetched. The more add-ons in your stack, the more database queries, the more observer events, and the slower your admin panel and storefront become.

Our API performance tests showed that Magento is up to 6.5× slower than Medusa. When we ran a product fetch for 15 items across 50 concurrent users over 30 seconds, Magento averaged a 20,330 ms response time. Medusa handled the same scenario in 2,900 ms – seven times faster.What this means for your business: Your operations team will feel this first. The admin panel slows down with every extension you add – product management, order processing, and inventory updates take longer. Your buyers will feel it next: slow checkout, slow search, and slow category pages. Both translate directly to lost revenue and higher operational costs.

6. Monolithic architecture with limited headless capability

Magento uses a monolithic PHP architecture with tightly coupled frontend, backend, and database layers.

In a monolithic system, changing one layer risks breaking others. If you modify the checkout flow for marketplace-specific logic (split payments, per-vendor shipping selection), you are touching the same codebase that handles single-seller checkout, cart calculations, and tax rules.

Extension conflicts compound this: a Webkul checkout modification can collide with a payment gateway extension, a tax module, or Magento's own checkout updates in the next patch.

True headless commerce – where you build a custom frontend and communicate with the backend purely through APIs – is technically possible with Magento, but it requires significant engineering investment, and you will encounter API gaps for marketplace-specific operations that do not exist natively.

What this means for your business: Your development velocity is limited by the platform's architecture. Frontend and backend teams cannot work independently. Every release carries regression risk.

7. Complex and expensive customization

A multi-vendor marketplace is not a standard eCommerce store with a few tweaks. You need custom onboarding flows, dynamic commission models, seller-specific promotions, marketplace-level analytics, and buyer-facing features.

Every nonstandard feature requires specialist development or an add-on. But adding one new module can destabilize others, especially during Magento version upgrades when extension compatibility is not guaranteed.

What this means for your business: Your development costs grow non-linearly. The first marketplace feature is expensive. The tenth is even more expensive, because every addition must be tested against a growing stack of interdependent extensions and customizations.

8. Constant painful upgrades

Magento releases new versions roughly every quarter. For a Magento marketplace with a ton of extensions from multiple vendors, every upgrade is a project.

You need to verify that every marketplace extension is compatible with the new Magento version. Webkul, CedCommerce, and other vendors release their own updates on their own timelines.

If one extension is not yet compatible, you either wait (and run an outdated Magento version with known vulnerabilities) or proceed without that extension (and lose marketplace functionality).

Security patches are especially painful. They cannot wait, but they routinely break custom code and extension functionality. Instead of one developer managing the store, you end up with a team dedicated to understanding and resolving conflicts across the entire extension stack.

What this means for your business: Upgrades become a recurring cost center. Each major update requires regression testing across your entire marketplace stack. Delays in upgrading expose you to security vulnerabilities. The more extensions you have, the longer upgrades take and the higher the risk of breaking production functionality.

9. Security vulnerabilities

Magento's security track record has been consistently problematic, and the pace of critical vulnerabilities has not slowed.

In 2024, Magento sites accounted for 0.71% of all eCommerce attacks – a disproportionate share given its declining market position.
In June 2024, the CosmicSting vulnerability (CVE-2024-34102, CVSS 9.8/10) allowed unauthenticated attackers to read any file on the server, steal encryption keys, and gain full admin API access. Seven attacker groups exploited it, injecting payment skimmers into over 4,000 stores.
In October 2025, another critical vulnerability (CVE-2025-54236, CVSS 9.1) was actively exploited in the wild. Attackers used the flaw to upload PHP webshells and hijack customer accounts through the REST API.

For a marketplace operator, the stakes are higher than for a single-seller store. A security breach exposes not just your data but also your vendors' data, your buyers' payment information, and your entire commission and payout infrastructure.

What this means for your business: You are responsible for the security of every vendor and buyer on your platform. Magento's patch cadence, combined with the difficulty of upgrading extension-heavy installations, creates a window of exposure after every disclosure. The marketplace model amplifies the damage of any breach.

10. Limited analytics and tracking

Magento's built-in reporting is designed for a single store owner. It gives you aggregated revenue, order counts, and basic product performance. It does not give you marketplace-level analytics.

Marketplace-specific reporting (e.g., seller-level sales reports, commission reconciliation, payout summaries, vendor dispute rates) requires add-ons or custom development.

For your finance team, this means manual reconciliation between Magento order data, extension-generated commission reports, and your actual payment provider payouts. For your marketplace operators, it means limited visibility into seller health, catalog quality, and buyer satisfaction metrics.

What this means for your business: You cannot run a marketplace without marketplace analytics. Magento does not provide them natively, and the extension-based alternatives are limited in depth and reliability. You will spend development hours building custom reporting or accept that your operational visibility is incomplete.

11. Integration problems

A marketplace sits at the center of multiple business systems: ERP for financials and inventory, PIM for product data, CRM for seller and buyer relationships, shipping providers for fulfillment, and payment platforms for multi-party transactions.

For example, connecting your ERP to a Magento marketplace means syncing data across three layers: Magento core, the marketplace extension, and whatever additional add-ons you use (shipping, payments, RMA).

Each layer has its own data model and update cadence. Handling external data from ERP, CRM, PIM, and shipping is painful, and complex dependencies across systems make integrations a maintenance nightmare.What this means for your business: Every integration you build against a Magento marketplace is fragile. Extension updates can break API contracts. Magento upgrades can change core behavior. You will spend significant engineering time maintaining integrations rather than building new marketplace capabilities.

12. Slow admin panel

This is the operational reality of running a Magento marketplace day-to-day. The Magento admin panel was not fast to begin with, it is a server-rendered PHP interface that makes full-page requests for most actions.

After adding extensions, the store management panel becomes painfully slow due to additional data.

Product saves take longer because marketplace observers fire on every save event.
Order grids are slower because they pull vendor data alongside order data.
Configuration pages become cluttered with extension-specific settings.

Your operations team works in this panel every day. Every additional second of load time on admin pages compounds into hours of lost productivity per week.

What this means for your business: A slow admin panel directly affects how fast your team can onboard sellers, approve products, resolve disputes, and process orders. In a marketplace where operational speed determines seller satisfaction and buyer experience, a sluggish backend is a competitive disadvantage.

13. No dedicated business support

Direct support from Magento is limited or inaccessible for smaller merchants.

Your only resources are community forums, Stack Overflow, and whatever documentation Adobe maintains. There is no SLA, no account manager, no guaranteed response time.

Adobe Commerce includes 24/7 technical support and a dedicated account manager, but at the $22,000–$125,000/year license cost mentioned earlier. Even then, Adobe's support covers the platform, not your marketplace extensions.

When a Webkul module conflicts with a Magento patch, neither Adobe nor Webkul may take ownership of the resolution. You are left coordinating between vendors, and the resolution timeline is outside your control.

What this means for your business: When your marketplace goes down at 2 AM, you need to know who to call. With Magento Open Source, the answer is your own team. With Adobe Commerce, the answer is Adobe for core issues and "figure it out" for extension conflicts. Neither scenario gives you the support reliability a marketplace operator needs.

14. PHP incompatible with AI-assisted development

This limitation is becoming increasingly relevant as AI coding tools reshape how software gets built. Magento's PHP codebase is increasingly difficult to develop with using modern AI/LLM tooling (like GitHub Copilot, Cursor, and Claude).

AI models are trained predominantly on JavaScript and Python codebases. PHP receives weaker code suggestions, less accurate completions, and slower iteration in AI-assisted development environments.

As teams across the industry accelerate their development velocity with AI tooling, Magento developers are left with tools that work less reliably for their stack.

What this means for your business: Your competitors building on JavaScript-based or Python-based stacks can iterate faster using AI-assisted development. Your Magento development team faces lower AI tool quality, which means slower feature delivery and higher per-feature development costs – a gap that will widen as AI coding tools continue to improve.

What the right online marketplace platform should give you

You already know what marketplace features to look for. The harder question is whether the platform's architecture, cost model, and ecosystem will still work for you in two years.

Below are the business-level factors that separate a platform you can scale on from one you will eventually need to migrate away from.

Marketplace logic in the core, not in plugins

The single biggest lesson from the Magento section above: If marketplace functionality is bolted on through extensions, you inherit every limitation of that approach – upgrade fragility, extension conflicts, performance degradation, and a support model where no single vendor owns the full stack.

The right platform should treat multi-vendor commerce as a first-class architectural concept. Sellers, commissions, split payments, and per-vendor order routing should exist in the platform's data model and API layer from the start.

You should not need a third-party module to create a seller or split an order.

Predictable and transparent total cost of ownership

Your CFO should be able to model the cost of running your marketplace over three years without spreadsheet acrobatics.

That means no GMV-based licensing surprises, no extension stacking where each new capability adds another annual fee, and no hidden cost of "specialist developers" because the platform runs on a niche technology.

Look for platforms where the core marketplace functionality ships without per-feature licensing and where development and hosting costs are proportional to your actual usage, not to your revenue tier.

A technology stack your team can hire for

Your marketplace will need engineers for as long as it exists. The platform's language, framework, and tooling should align with where the developer market is heading.

JavaScript and TypeScript dominate modern web development. Python leads in AI/ML and data engineering. Both have deep talent pools, active open-source ecosystems, and strong compatibility with AI-assisted development tools (Copilot, Cursor, Claude).

If your platform runs on a stack that junior developers are actively learning and senior developers want to work with, you will hire faster, onboard cheaper, and retain longer.

Modular architecture that does not punish change

A marketplace roadmap is never finished. You will add new commission models, new buyer-facing features, and new integrations with ERPs and payment providers. Every one of those changes should be possible without risking the stability of everything else.

That requires a modular or composable architecture, where you can modify the checkout without breaking the catalog, update the commission engine without redeploying the storefront, and add a new payment provider without regression-testing the entire admin panel.

If every change requires a full-stack deployment and cross-extension QA, your iteration speed will decrease as your marketplace grows.

API-first design for integrations and frontend flexibility

The platform's API layer needs to be complete, consistent, and stable across versions.

Every marketplace operation should be available through the API with the same reliability as the admin interface.

If you need to work around API gaps with direct database access or custom middleware, your integration costs will compound with every connected system.

Fast time-to-market with iterative deployment

Marketplace success depends on how quickly you can get to market, test assumptions with real sellers and buyers, and iterate based on what you learn.

If your platform requires a six-month implementation before you can onboard your first vendor, you are burning runway before you have validated your model.

The right platform should let you launch an MVP marketplace in weeks. From there, you should be able to layer on advanced features (dynamic commissions, custom analytics, and seller tiers) incrementally, without re-architecting what you already shipped.

Security as a platform responsibility, not an ops burden

Your platform should have a clear, responsive patch cadence and an architecture where applying updates does not require coordinating compatibility across a stack of third-party modules.

Look for platforms with a small, auditable dependency surface, proactive vulnerability disclosure, and an upgrade path that does not force you to choose between "apply the security patch" and "keep your marketplace features working."

A community and ecosystem that is growing, not contracting

Platform health is visible in the trajectory of its community.

Are new developers joining? Are agencies building practices around it? Is the open-source contribution rate increasing or declining? Are merchants adopting or migrating away?

A growing ecosystem means more shared knowledge, more available integrations, faster bug resolution, and a stronger hiring pipeline.

Modern foundations to consider

The marketplace platform market has shifted. A new generation of open-source, API-first platforms now offers the architectural depth that used to require enterprise licensing, without locking you into a monolithic stack or a SaaS vendor's roadmap.

The strongest options combine modular architecture with full infrastructure ownership. You control the backend, the data, and the deployment model. You extend the platform through code, not through plugin stacking.

Mercur is one example. It is an open-source marketplace platform built for companies that have outgrown extension-based setups. It ships with native multi-vendor functionality – admin panel, vendor panel, storefront, commission engine, and order splitting – on a modular architecture designed for custom workflows.

You own the code, you own the data, and you can adapt every layer to your specific market without waiting for a third-party vendor to release a compatible add-on.

If you are evaluating marketplace platforms and want a structured comparison, our free guide – Top 11 Multi-Vendor Marketplace Platforms for eCommerce – compares leading technologies (including Mercur) across 11 criteria: pricing, deployment model, customization depth, native marketplace features, and more.

It is a practical starting point for narrowing down which foundation fits your business.

[

]()

And if you are still early in the process – validating a marketplace idea, planning the architecture, or deciding whether to migrate from an existing platform – reach out to our team.

We work with companies building multi-vendor marketplaces, B2B marketplaces, B2C marketplaces, and MVP marketplace launches. We will help you map the right technology to your specific model.

Conclusion: Should you create a marketplace in Magento?

At this point, you have seen the full picture – what a multi-vendor marketplace requires, how Magento attempts to deliver it through third-party extensions, and the 14 structural limitations that make that approach fragile, expensive, and difficult to scale.

Here is what it comes down to.

Magento is a capable single-seller eCommerce platform. For a standard online store with one merchant, one inventory, and one checkout flow, it can work.

A multi-vendor marketplace is a fundamentally different system. It needs native seller management, split payments, per-vendor order routing, commission logic, and multi-party data isolation – at the platform level, not in a stack of plugins.

Magento does not provide any of this natively, and the extension-based workarounds introduce compounding risk across performance, security, upgrades, and operational complexity.

If you already run a Magento store and are exploring the idea of adding a marketplace layer, the honest assessment is you can make it work for a small pilot with a few vendors and simple products.

You will struggle the moment you need to scale: more sellers, more SKUs, complex commissions, real-time split payments, and the operational tooling that a growing marketplace demands.

If you are starting a new marketplace project from scratch, there is no architectural reason to choose Magento over platforms that were built for multi-vendor commerce from the ground up.

The marketplace platform market has matured. Open-source, API-first, modular platforms now exist that give you the flexibility of self-hosted infrastructure with native marketplace architecture.

If you are evaluating whether to build, migrate, or scale a marketplace – schedule an honest technical conversation with our marketplace experts! We will help you find the right foundation for your specific business model.

FAQ on marketplace in Magento

Is Magento a marketplace?

No, Magento is a single-seller eCommerce platform, not a marketplace. Its core architecture supports one merchant managing one product catalog, one checkout, and one order flow. There is no native concept of multiple sellers, vendor dashboards, commission engines, or split payments in Magento's data model.

To turn a Magento store into a multi-vendor marketplace, you need to install third-party marketplace extensions like Webkul Multi Vendor Marketplace or CedCommerce. The result is a marketplace built through plugins, not a platform designed for multi-vendor commerce from the ground up.

What is the difference between a website and a marketplace?

A standard eCommerce website is operated by a single seller. You own the products, set the prices, fulfill the orders, and handle all customer interactions. One business entity controls the entire experience from catalog to checkout to delivery.

A marketplace is a platform where multiple independent sellers list and sell their products through a single storefront. The marketplace operator manages the platform, sets the rules, and takes a commission on transactions. Each seller manages their own inventory, pricing, and fulfillment through a seller dashboard. Buyers see one cohesive shopping experience, while behind the scenes, orders are split and routed to the responsible vendors.

How to build a marketplace website in Magento?

Building a marketplace in Magento requires installing a third-party multi-vendor marketplace extension on top of your Magento store. The extension-based architecture introduces structural limitations around performance, upgrade complexity, security, and scalability that become increasingly painful as your marketplace grows. For new marketplace projects, purpose-built marketplace platforms offer a more sustainable foundation.

What is the Magento Marketplace?

The term "Magento Marketplace" can refer to two different things, which often causes confusion.

Adobe Commerce Marketplace is Adobe's official extension store, a directory of third-party extensions, themes, and connectors that you can install on your Magento store.

A marketplace built on Magento refers to using Magento as the underlying platform for a multi-vendor eCommerce marketplace, where multiple sellers list products and sell through a shared storefront. This requires installing third-party Magento marketplace extensions (like Webkul or CedCommerce) because Magento does not include native multi-vendor marketplace functionality.

Marketplace Business Models 2026 Guide: Types, How They Work & Which One to Choose

Rigby — Wed, 26 Aug 2026 08:05:33 +0000

Most retailers reach a point where the next step of growth costs more than the last one. Every new product line means more stock to buy, more warehouse space, and more people to run it.

The marketplace business model breaks that link. Someone else owns the stock, someone else ships it, and you earn a share of every sale you make possible.

That sounds simple until you have to choose a version of the model and commit to it. There are four main types, six common ways to charge for the service, and a set of trade-offs that decide whether the model works in your category or quietly drains money for two years.

This guide walks through all of them and ends with the questions that settle the choice.

Key insights

A marketplace business model connects buyers with independent sellers and earns money from the transactions it makes possible. The operator builds the platform and sets the rules, but does not own the goods.
4 types of marketplace business model are: B2B, B2C, C2C, and C2B. The type follows from who sells and who buys, and that single choice shapes your pricing, operations, and legal duties.
6 marketplace revenue models are in common use: commission, subscription, listing fee, lead fee, freemium, and mixed. Most platforms end up mixing two or three once volume arrives.
Growth compounds because more sellers bring more selection, more selection brings more buyers, and more buyers bring more sellers. Classic retail has no equivalent loop, which is why it slows down as it grows.

What is a marketplace business model, and how does it work?

A marketplace business model is a way of running an online business where a marketplace platform brings buyers and independent sellers together and takes a share of the value it creates.

The online marketplace model treats the transaction itself as the product. The digital platform handles discovery, trust, payment, and the rules of engagement, and it serves two distinct user groups at the same time. The sellers handle their own stock, pricing, and shipping.

The defining feature is that the operator sits between the two sides without buying the goods. The platform operator earns by facilitating transactions, so revenue tracks volume. It no longer tracks purchasing decisions made months earlier.

A classic retailer buys stock, holds it, and hopes it sells. A marketplace operator never takes that bet.

That difference changes what the business spends money on. Instead of working capital tied up in inventory, the spend goes into technology, seller acquisition, and the trust layer that makes strangers comfortable transacting.

If the model is new to you, our guide to what an online marketplace is covers the ground floor before the business model questions start.

Marketplace vs eCommerce: How does the online marketplace business model differ from traditional retail?

In classic eCommerce, you buy stock, you own it, and managing inventory is your job as well as your risk. Growth means buying more, which means more capital and more warehouse space.

In a marketplace, sellers carry that risk, and your growth comes from adding sellers instead of adding stock. The cost of one more product line drops close to zero.

Marketplaces need far less physical infrastructure, so they can open a new category or a new country without a warehouse and recruit sellers globally from the start. That is the main reason the model spreads quickly once a team has run it successfully once.

An eCommerce platform runs out of capital and warehouse capacity, while a marketplace platform runs out of demand or seller quality.

Our comparison of marketplace vs eCommerce models goes through the six points where classic retail stops scaling, and our write-up of inventory risk covers what owning stock does to a growing business.

What does the marketplace owner do and what do the sellers do?

The split of duties between the marketplace owner and the sellers is the part most teams underestimate. Writing it down early prevents arguments later, because every unclear duty ends up on the operator's desk by default.

The platform operator builds and runs the online platform: the storefront, search, seller onboarding, payment flow, dispute handling, and the policies that govern who may sell what.

The operator also owns the buyer relationship, which means the operator absorbs the complaints even when the fault sits with a seller.

Operators set a standard and then discover that enforcing it across hundreds of sellers is a job in itself, which is the subject of our guide to marketplace catalog management.

Sellers own their products. They set prices, manage their own stock levels, write their listings, pack the orders, and handle returns for the goods they sold.

This is why sellers keep control of their fulfillment process, and why they can join a marketplace without rebuilding how they operate. For most sellers, that freedom is the reason they join at all.

What are the four types of marketplace business models?

There are 4 different marketplace models, and these types come from a single question: is each side a business or an individual?

That gives you business-to-business (B2B), business-to-consumer (B2C), consumer-to-consumer (C2C), and consumer-to-business (C2B).

1) What is a B2B marketplace business model?

A B2B marketplace connects businesses that sell with businesses that buy, and no consumers take part. Wholesale, industrial supply, and procurement platforms all sit here.

B2B changes the shape of the product in ways that surprise teams coming from consumer retail. Buyers expect account-specific pricing, credit terms, purchase orders, approval flows, and repeat ordering.

A single customer may negotiate its own price list, which means the platform has to support prices that differ per buyer instead of one public price per product. Order values are high, and purchases repeat on a schedule, so a small number of accounts can carry a large share of revenue.

That concentration cuts both ways: winning one account moves the numbers, and losing one hurts. Our guide to building a B2B marketplace covers the flows that consumer platforms do not need.

2) What is a B2C marketplace business model?

A B2C marketplace lets businesses sell directly to consumers through one platform. This is the type most people picture when they hear the word marketplace, and it is the most common starting point for retailers adding third-party sellers.

The buyer expects the experience of a single shop even though many companies are selling. That expectation puts weight on consistent product data, predictable delivery promises, and one place to ask for help.

Sellers gain access to a broad range of buyers they could not reach alone, and a well-run platform gives them global reach without a single new warehouse.

Revenue almost always starts with commission because it scales with volume and asks nothing of a seller before their first sale. Consumer platforms also tend to add an ads model and promoted placement later, once there are enough sellers competing for attention to make the auction worth entering.

3) What is a C2C marketplace business model?

A C2C marketplace lets individuals sell to other consumers, which is why the type is often described as peer-to-peer commerce. Second-hand goods, collectibles, tickets, and local sales are the classic categories.

The economics are different because sellers are casual. They list one item, they may never list again, and they will not tolerate onboarding that takes an afternoon.

Everything has to be effortless: photograph, price, publish.
Payment protection matters more here than anywhere else, because neither side has a reputation to protect outside the platform.
Low order values mean a commission on a single sale rarely covers the cost of handling a dispute about that sale.

C2C platforms therefore lean on volume, on paid visibility, and on optional services such as authentication or shipping labels.

4) What is a C2B marketplace business model?

A C2B marketplace turns the usual direction around: individuals offer something, and businesses buy it. Freelance work, stock photography, licensed content, and influencer services all run this way.

The platform's job becomes assessment, and logistics disappears from it. Buyers need a way to judge quality before committing, because the services sold here cannot be inspected in advance, which is why ratings, portfolios, and test tasks carry so much weight.

Payment is often held until work is accepted, which turns the platform into a guarantor. That role brings duties. Once you hold money between two parties, you are responsible for what happens when they disagree.

Which marketplace models exist beyond the four main types?

The four types describe who trades with whom. Several other patterns describe how the trade is organised, and they apply on top of any of the four without replacing them.

A B2B marketplace can be vertical and direct. A B2C marketplace can be hybrid and horizontal.

1) What is a hybrid marketplace model?

In a hybrid marketplace model, the operator keeps selling its own products while third-party sellers list theirs on the same platform. Most large retailers that opened a marketplace run this way, because giving up an existing catalogue was never on the table.

The commercial logic is strong. Your own products anchor quality and margin, and third-party sellers extend the range without extra stock. Buyers see one wide catalogue and rarely care who ships what.

The difficulty is internal, and technology has little to do with it. A category buyer with a target for own-stock sales now competes with the sellers on the same platform, and both sides pull toward their own plan, a friction covered in our write-up of a real marketplace transition.

When multiple sellers offer the same product, competitive pricing decides who wins the sale, so you also need a rule for which offer gets shown, and our guide to the marketplace buy box covers what that rule has to do.

2) What is a service marketplace?

A service marketplace matches people who need work done with people who can do it. Home repair, cleaning, tutoring, logistics, and professional consulting are typical.

Instead of tracking parcels, it has to help buyers judge quality, agree on scope, and settle disputes about work that was delivered in person.
Scheduling and location matter more than stock levels.
Pricing is harder than in goods marketplaces because every job is slightly different.

Platforms respond either by standardising the offer into fixed packages or by moving to a lead fee model, where the platform charges for the introduction and steps back from the transaction itself.

3) What is a rental or subscription marketplace?

A rental or subscription marketplace sells access instead of ownership. Equipment hire, fashion rental, holiday lets, and machinery sharing all work this way.

The model suits items that are expensive to buy and used occasionally, because renting spreads one asset across many users. Revenue per item is much higher over time than a single sale would be, which is the appeal for sellers.

The costs sit in the parts of the journey that a normal sale does not have: deposits, damage assessment, cleaning, and getting the item back. Every one of those steps needs a policy, and every policy needs someone to apply it. Teams that underprice this work discover the gap in the first busy season.

4) What is the difference between a direct and an indirect marketplace model?

In a direct model, the transaction completes on the platform. The buyer pays there, the platform takes its share, and the seller receives the rest.

In an indirect model, the platform hands over a qualified lead and the two parties settle between themselves.

Direct gives you data, control, and a reliable link between value delivered and revenue earned. You know what sold, at what price, and whether the buyer came back. It also gives you responsibility for payment, refunds, and everything that follows.

Indirect is cheaper to run and easier to launch, and it fits categories where the price cannot be fixed in advance, such as construction or bespoke manufacturing. The cost is blindness: you cannot see whether the deal happened, so you charge for the introduction and lose the ability to earn from repeat business.

5) What is the difference between a vertical and a horizontal marketplace?

A vertical marketplace covers one category in depth, and niche marketplaces are the narrowest version of that idea. A horizontal marketplace covers a broad range of categories with less depth in each.

Vertical marketplaces win on relevance, because the value proposition is obvious to both sides. You can build product data that fits the category properly, attract sellers who recognise themselves in the positioning, and rank for the searches that matter. The ceiling is the size of the category itself, so a narrow market caps how large the business can get.

Horizontal wins on total demand and on the chance that one buyer visit turns into several purchases. The price is that everything has to be generic enough to work everywhere, which usually means product data, search, and seller rules that suit nothing perfectly.

Most successful platforms started vertical and widened once one category worked. Widening is a decision you can make later, while narrowing after launching broad means telling existing sellers they no longer fit.

How do marketplace business models make money? 6 revenue models

Choosing a type tells you who trades on your platform. It does not tell you how you get paid.

Six revenue models cover almost all of the market. They differ in when the money arrives, in how marketplace fees are presented to sellers, and in how much risk a seller takes before seeing value.

Revenue generation comes from transaction fees, from access, or from visibility, and most platforms end up using more than one of the three.

1) How does the commission model work?

In the commission revenue model, the platform takes a percentage of each completed sale. Nothing is charged before a seller earns something, which is why this is the most common model and the easiest one to recruit against.

The rate has to reflect the value you provide, and the structure has to fit your category, which can be a percentage or flat fee, a rate per category, or a rate per seller.

Our guide to commission structures covers how the commission engine itself has to be built.

2) How does the subscription model work?

In the subscription revenue model, sellers pay a fixed monthly fee, or a yearly one, for access to the platform, and the platform takes little or nothing per transaction. Payment processing fees still apply on top, so the seller feels both.

Subscription fees make revenue predictable, which makes planning easier and rewards your best sellers by letting them keep the upside of a strong month. A monthly subscription fee also tells a seller exactly what the platform costs them.

The trade-off is at the other end of the range. A new seller with no sales still pays, so the model pushes away exactly the long tail that gives a young marketplace its selection.

3) How does the listing fee model work?

In the listing fee model, sellers pay for each item they publish, whether it sells or not, and listing fees are often paired with additional selling fees at the point of sale.

The fee acts as a filter. Sellers think before listing, which keeps obvious junk out and suits categories where items are valuable or scarce.

In categories where sellers carry thousands of items, the same fee reads as a tax on having a wide catalogue, and those sellers list only their best guesses.

That narrows your selection, which is the one thing a young marketplace cannot afford.

4) How does the lead fee model work?

In the lead fee model, the platform charges a referral fee for a qualified introduction instead of taking a share of a completed sale. Common in services, construction, and any category where the final price is agreed between the two parties.

It works when the transaction genuinely cannot happen on the platform. The weakness is that revenue stops tracking value: you get paid the same whether the lead turned into a large contract or went nowhere. Sellers notice the mismatch quickly, and the ones who convert poorly complain loudest.

5) How does the freemium model work?

In the freemium model, basic services are free, and the platform charges for premium services such as better visibility, analytics, more listings, or advanced tools.

Free access removes every reason not to join, so supply builds fast. That is valuable at the start, when selection matters more than revenue.

The risk is that the free tier is good enough for most sellers forever, so conversion stays low, and the premium features have to be worth buying on their own merit, and artificial limits on the free plan will show through.

Offering premium services works only when the paid services solve a problem a growing seller really has.

6) How does a mixed revenue model work?

A mixed revenue model combines several revenue strategies: a commission plus a subscription for larger sellers, or a commission plus paid placement.

Nearly every marketplace platform at scale ends up here, because no single way to generate revenue fits every seller and no single stream survives price pressure forever.

The discipline required is to keep the whole thing explainable. A pricing page that needs a spreadsheet to understand costs will lose you sellers who would otherwise have joined.

Why does the marketplace model scale better than owning inventory?

The four types and six revenue models describe the mechanics. The reason the model attracts so much investment is a growth pattern that classic retail cannot copy.

In a traditional business model, each new product costs money and each new customer costs money, and both costs keep rising as you grow.

In a marketplace, sellers add products at no cost to you, and those products attract buyers who then attract more sellers.

Growth stops being something you buy and becomes something the platform produces.

What is the marketplace flywheel and how do network effects build it?

A network effect means the platform gets more valuable to each user as more users join. On a marketplace platform, it works in both directions at once, so buyers and sellers alike gain from every new participant. A seller who used to chase one customer at a time reaches multiple buyers from a single listing.

Chained together, those two effects form what people call the flywheel. More sellers mean more selection, more selection attracts more buyers, more buyers make the platform more attractive to sellers, and the loop turns again with less push each time.

The payoff shows up in acquisition cost. In classic retail, you buy demand again for every stage of growth, and the price of that demand rises as the cheap channels saturate, which is the subject of our breakdown of why customer acquisition cost rises as you scale.

In a marketplace, part of your growth comes from selection and word of mouth that you did not pay for directly.

What are the main challenges of the marketplace business model and how to overcome them?

The online marketplace business model has real advantages, but it also has 4 failure patterns that show up again and again.

1) How to build trust between buyers and sellers?

Verify sellers before they can list anything. Check the company registration, confirm that the bank account belongs to that company, and get a named contact person. In the EU, this stopped being a choice: under the Digital Services Act, online marketplaces have to obtain and verify identifying information from traders before those traders can sell, display seller contact details to buyers, and make reasonable efforts to check the products on offer.

Hold the buyer's money until delivery is confirmed. The buyer's exposure then lasts only from payment to delivery, and a seller who disappears cannot take the payment with them.

Show seller performance on the offer itself. Rating, dispatch time, and how often orders end in a dispute, visible where the buyer decides and not buried in a profile page. Sellers who see their own numbers beside their competitors' improve without being asked.

Decide disputes yourself, against a deadline. A buyer who has to negotiate with a stranger will not come back, whatever the outcome. Set thresholds for dispute rate and late dispatch, and remove the sellers who cross them, because a rule you do not enforce costs you the trust of everyone who kept it.

Sellers hand you commercial information, and buyers hand you personal information, so where both are stored becomes part of the same question. Our write-up on marketplace data security covers what that obligation looks like in practice.

2) What makes a marketplace hard for a competitor to copy?

Three things take time to build and cannot be bought quickly.

Seller relationships are the slowest to copy and the most durable. A seller who has built their listings, their pricing rules, and their fulfillment process around your platform pays a real cost to move, and the sellers you helped grow recruit the next ones for you.

Depth of product data in one category beats breadth across ten. Attributes that fit the category, filters that match how buyers shop it, and complete specifications take months of work per category, and they are what make a buyer choose you over a general catalogue.

Repeat purchase. A buyer who comes back without a paid click costs almost nothing to serve again.

Discovery is moving as well. Forrester expects a third of retail marketplace projects to be abandoned as answer engines take traffic, because AI assistants reach the assortments of the largest platforms more easily than those of independent ones. That points the same way: a general catalogue competes with everyone, while a defined category gives buyers a reason to come to you specifically.

3) How do you run operations for buyers and sellers at the same time?

Buyers want fast delivery, easy returns, and one place to complain. Sellers want low fees, quick payment, and few rules. Serving both means settling four things before launch instead of during your first busy week.

Write down who owns each failure before you sign your first seller. A late shipment is the seller's fault and your problem, so the agreement has to say who refunds the buyer, who pays the return postage, and how long the seller has to respond.

Calculate the delivery promise from each seller's own dispatch time. One promise per offer, generated from data you already hold, so a buyer never sees a date the seller cannot meet.

Split the order at checkout. One basket containing three sellers becomes three orders, three shipments, and three return paths, which is the mechanism our write-up on the split basket problem works through.

Keep one support queue facing the buyer, with a response deadline for sellers behind it. The buyer talks to you and never to a stranger, and the seller's obligation becomes measurable.

The load grows with combinations instead of with sales, so automate the work that scales with seller count, which means onboarding and catalogue validation, and keep people on disputes. Our guide to retail digital transformation covers what that reorganisation looks like operationally.

4) Why does the cost of running a marketplace grow faster than its revenue?

Revenue grows with sales, and running costs grow with the number of sellers, whether those sellers sell anything or not.

Building is the smaller and more predictable half. Seller onboarding, catalogue rules, offer handling, commission logic, payment splitting, and a seller-facing panel all exist in marketplace software already, so the question is how much you configure and how much you write.

Running the platform is the half that never stops, and it scales with seller count. Every seller has to be onboarded, have their catalogue checked, have their data quality chased, and have their disputes handled. A seller who lists 400 products and sells three costs you money every month.

The number to watch is cost per active seller against revenue per active seller. When the gap closes, you have two levers: automate the work that repeats for every seller, or remove the sellers who do not trade.

Most business plans model neither, which is why ongoing cost is the line they underestimate. Our guide to custom marketplace development breaks down the build side, and creating your own marketplace covers costs by approach, along with the hidden items most teams miss.

How to choose the right marketplace business model?

To choose your marketplace business model, answer these 5 questions.

Work through them with the people who will run the platform as well as the people funding it. The operational answers change the commercial ones.

1) Who are your buyers and who are your sellers?

Your target audience decides the type, and the type decides most of what follows.

Businesses buying from businesses need account pricing and purchase orders.
Consumers buying from businesses need a single, consistent shop experience.
Individuals selling to individuals need a listing to take a minute.

Be specific about the seller as well as the buyer.

2) Should you start niche or broad?

Start with the narrowest category that still contains enough demand to matter. Depth is what makes a young platform visibly better than a general one, and it makes seller recruitment easier because your pitch describes the seller's own market.

Our own research points the same way: a quarter of the operators and consultants we surveyed expect competitive advantage to shift toward specialisation and deeper vertical focus.

Widening later is a normal path. Narrowing later means asking sellers to leave.

3) Which is harder for you to get, sellers or buyers?

Every marketplace has two groups to recruit. Sellers supply the products, and buyers pay for them.

One of the two is always harder to win, and that group is where your launch budget and your founders' time have to go.

Three questions tell you which group is harder in your case.

How much work does joining cost each group? A buyer spends two minutes creating an account. A seller may have to export a catalogue, agree commercial terms, and change how they pack orders. The group that has to do more work is usually the harder one to recruit.

How many possible participants exist on each side? If your category has 300 potential sellers and 300,000 potential buyers, then sellers are the scarce group, and every single one of them matters.

What does each group lose by saying no? A buyer who declines shops somewhere else and loses nothing. A seller who declines gives up a sales channel, which means a seller can be persuaded with numbers.

In most retail categories, the answer is sellers. Retailers have a head start here, because they already have the buyers.

If buyers turn out to be the harder group, the whole plan inverts. You recruit sellers by offering exclusivity or better terms than they get elsewhere, and you spend your budget on reaching buyers.

Getting this the wrong way round is the most expensive mistake at launch, because you pay to acquire one group and it leaves before the other one arrives.

4) Which revenue streams fit your cost structure?

Match the model to how sellers experience risk.

If your sellers are small and cautious, a commission asks nothing upfront and gets you selection. If they are large and steady, a subscription gives them predictable costs and gives you predictable revenue.

Then check the arithmetic against your own costs. If handling one dispute costs more than the revenue on the order that caused it, the model needs a second stream.

Our guide to marketplace monetization models covers how the mix should change between launch, growth, and scale.

5) Which technology can carry the model you picked?

The platform decision comes last, once you know what it has to support, because the reverse order forces the business model to fit the software. Ask whether the marketplace platform can express your commission rules, your onboarding flow, and your product data standard without a rebuild.

Almost every marketplace changes its revenue model within two years, and platforms that hard-code pricing rules make that change expensive.

Our comparison of marketplace software works through the options by architecture, and our guide to eCommerce growth strategy covers the signs that tell you the moment has arrived.

How do you move from an eCommerce model to a marketplace model without a full migration?

Retailers reading this material usually have a working shop, a real audience, and no appetite for replacing everything. The good news is that the marketplace model does not require replacing everything.

The workable path is to add a marketplace layer beside what you already run. Your existing storefront keeps serving customers, and third-party offers appear alongside your own catalogue as sellers come on board. You learn which categories work with borrowed stock before committing to more.

Start with the parts that will not change. Seller onboarding, offer handling, and commission rules are needed in every version of the model, so building them first gives you something to test with real sellers while the commercial questions are still open.

Mercur

Mercur is an open-source marketplace platform you fully own. It provides a storefront for buyers, a vendor panel, an admin console, and integrations into your stack – with enterprise-grade security.

Around 80% of marketplace functionality is ready on day one. That covers seller onboarding and the seller lifecycle, seller teams and roles, an offer model that separates the master product from individual seller offers, and configurable commission rules.

It sits beside an existing storefront instead of replacing it, and it is extensible by design: capabilities arrive as modules. Talk to our marketplace expert about scope, constraints, and a walkthrough.

What is changing in marketplace business models in 2026?

The mechanics of the model are stable. Where operators are putting their money is not, and the direction has shifted noticeably in the last two years.

The future trends below are the four changes worth planning around. The first draws on our own research with marketplace operators and consultants. Download the whole report here!

1) Which trends are marketplace operators investing in for 2026?

We asked more than thirty marketplace operators and consultants what they are struggling with and where their budgets are going. The answers cluster tightly around the supply side.

The pattern behind those numbers is a move away from short-term expansion and toward retention, repeat purchase, and control over core workflows. Teams are being more selective about technology and are judging it on measurable impact.

The full picture, including regional differences and the framework we built for designing seller onboarding, is in the Marketplace Trends 2026 report. It runs to 43 pages and is free to download.

2) Why are vertical and niche models gaining ground?

Two forces push in the same direction. Niche marketplaces get better results for buyers because the platform understands one category properly, and operators find it easier to build product data, search, and seller rules for a single market.

The second force is competitive. As general discovery moves toward AI assistants that favour the largest catalogues, being one more broad platform is a weaker position than it was. A defined category gives both buyers and sellers a reason to choose you.

3) How is AI changing the way marketplaces run?

Two changes are underway at once, and they affect different parts of the business.

On the buying side, AI agents are starting to research, compare, and place orders on behalf of people and companies. Deloitte reports that nearly 40% of B2B buyers already use agentic AI for purchasing tasks while only 24% of suppliers use agents in sales, with 67% planning to. Forrester expects a fifth of B2B sellers to face agent-led quote negotiations.

What both point to is that machines are becoming a customer type, and machines read structured product data instead of persuasive copy. Marketplaces with clean attributes and reliable availability data are the ones agents will be able to buy from.

On the operating side, the same technology is being used for catalogue work: filling in missing attributes, mapping seller feeds to a platform's own template, and categorising products automatically.

That work has always been the least glamorous part of running a marketplace and the most damaging when neglected. Worth keeping in perspective: Deloitte also found that only 11% of enterprises had agents running in production, so most of this is early.

4) What are API and data marketplaces?

Not everything traded on a marketplace is a physical product. Two variants have grown into categories of their own.

An API marketplace lets providers publish programmable services and lets developers subscribe to them, with the platform handling authentication, usage metering, and billing. A data marketplace does the same for datasets, adding licensing terms and delivery.

Both follow the models described earlier, usually a commission on usage or a subscription. What differs is the unit being sold. Usage is measured, nothing is shipped, and that pushes the platform's technical work toward metering and rights management.

Frequently asked questions

How does a marketplace make money?

A marketplace makes money by charging for the transactions and the visibility it provides, most often as a commission on each completed sale. Other common streams are seller subscriptions, listing fees for each published item, lead fees for qualified introductions, and paid placement. Platforms at scale usually run two or three of these together, because no single stream suits every seller.

What are the 4 types of marketplace?

The four types are B2B, B2C, C2C, and C2B, and the difference between them is whether each side of the transaction is a business or an individual. B2B connects businesses with business buyers, B2C lets businesses sell to consumers, C2C connects individuals with other individuals, and C2B lets individuals sell to businesses. Patterns such as hybrid, vertical, or service marketplaces apply on top of these four without forming a fifth type.

What is a commission-based business model?

In a commission-based business model, the platform takes an agreed percentage of each completed sale and charges nothing before a seller earns something. That makes it easy for sellers to join, and it ties the platform's revenue directly to the volume it helps create. The rate has to reflect what the platform genuinely provides, and it can be set flat, per category, or per seller, which our guide to commission structures covers in detail.

What is the difference between a marketplace model and a platform model?

A marketplace is one kind of platform: the kind where the transaction between two sides is the product. Platform is the wider term and covers any business whose value comes from connecting groups of users, including app stores, payment networks, and social media platforms where no purchase takes place. If money changes hands between a buyer and a seller and the operator takes a share, you are looking at a marketplace.

What is an example of a marketplace business?

Amazon is the most widely recognised example, because most of what it sells comes from third-party sellers instead of its own stock. Other clear examples across the four types are Faire and Ankorstore in B2B wholesale, Zalando in B2C fashion, eBay and Vinted in C2C resale, and Upwork in C2B services. Each one earns money from the transactions it makes possible, never from goods it buys and owns.

Why the Webkul Multi Vendor Marketplace Was Never Built to Run Your Business: 11 Reasons, Hidden Costs & Alternative

Rigby — Tue, 25 Aug 2026 12:03:06 +0000

Webkul's homepage calls it the "Best B2B/B2C Online Marketplace Platform." Their LinkedIn describes the company as "one of the largest self-created open-source marketplaces in the world." The marketing language says platform. The architecture says extension.

So, what actually is Webkul? That gap between positioning and reality matters when you're making infrastructure decisions.

Webkul grafts multi-vendor logic onto platforms that were built for single-seller commerce – Magento, Shopify, WooCommerce – and inherits every architectural limitation of the host.

The base module gives you a vendor dashboard, seller profiles, product approval, and commission rules. Everything beyond that is a separate paid add-on, with its own license, its own update cycle, and its own compatibility risk.

A proof of concept can run on an extension. A marketplace that needs to scale seller operations, handle split payments across regions, and maintain catalog quality across hundreds of vendors cannot.

See where the Webkul Multi Vendor Marketplace hits its limits – on Magento, on Shopify, and structurally – and what a purpose-built alternative looks like.

Key insights

Webkul is an extension, not a platform. It inherits every limitation of its host: Magento's monolith, Shopify's single-seller checkout, WooCommerce's performance ceiling.
The module covers the bare minimum. Basic marketplace features, like split payments, RMA, reporting, and buyer-seller messaging, are separate paid add-ons with their own update cycle and compatibility risk.
On Shopify, data syncs one way only. Vendors must manually update inventory in Webkul. Per-vendor shipping in a single cart is not possible. Fulfillment is entirely manual.
On Magento, Webkul multiplies the monolith tax. Every upgrade risks breaking the extension chain. Customization costs spiral across three code layers.
Purpose-built marketplace platforms, like Mercur, treat multi-vendor logic as the core of your business with native split payments, seller lifecycle management, and catalog governance.

What is Webkul, and how much does it cost?

Webkul is an Indian software company that, among other services, builds extensions for eCommerce platforms. Their flagship product is the Multi Vendor Marketplace module, available for Magento, Shopify, WooCommerce, BigCommerce, SAP Commerce Cloud, and several others.

The appeal is straightforward: you already run a store on one of these platforms, your team knows the stack, and you don't want to migrate.

Webkul lets you add a vendor layer on top of what you have. Sellers get a dashboard, a profile page, and basic commission management. The store admin gets controls for product approval and vendor oversight.

For many teams, this feels like the path of least resistance. No replatforming, no new infrastructure, no retraining. You install a module and start onboarding sellers on the same platform you've been running for years.

That logic holds until you look at what the module actually covers, what it doesn't, and what the full cost looks like when you add everything a real marketplace needs.

Webkul costs across eCommerce platforms + what the pricing page doesn't show

The base module price looks manageable. The total cost of running a functional marketplace on Webkul does not.

These are module license fees alone, which don't include the costs that actually dominate the budget.

To sum up, a marketplace running ten Webkul add-ons on Magento Open Source can exceed $2,000–3,000 in module licensing before any development work begins.

Add implementation, a single ERP integration, and a security audit, and the first-year cost easily reaches $50,000–100,000 for an extension layer that still inherits every limitation of the host platform.

According to Digital Commerce 360's 2024 B2B marketplace report, the median B2B marketplace now handles over 200 SKUs per vendor and processes multi-party transactions with at least two fulfillment nodes. That operational complexity cannot be managed through a stack of loosely coupled add-ons, no matter how many you buy.

Why the extension + add-ons don't make a marketplace?

The core issue with Webkul is structural. It is an extension layer, not a platform.

Every feature it provides sits on top of host platform architecture that was never designed for multi-vendor commerce. This means Webkul cannot do anything the host platform doesn't allow.

On Shopify, it can't override checkout behavior. On Magento, it can't escape the monolithic deployment model. On WooCommerce, it can't fix WordPress performance ceilings.

Each module has its own license cost, its own update cycle, and its own compatibility dependencies with both the Webkul base module and the host platform's core.

You're assembling a marketplace feature set one paid plugin at a time, and every plugin is a new maintenance surface.

The risk compounds with scale:

10 modules mean 10 compatibility checks after every host platform update.
15 modules mean 15 potential failure points in your checkout, catalog, and order management flows.

These aren't hypothetical scenarios. Marketplace founders and operators we've spoken with, as well as reviews on Shopify App Store, Quora, G2, and Trustpilot, consistently describe the same pattern: things work at launch, then break as complexity grows.

The section below breaks down how this plays out on the most popular eCommerce platforms Webkul supports.

How does Webkul perform on different eCommerce platforms?

Webkul's limitations aren't identical across platforms. Each host introduces its own constraints, and Webkul inherits all of them.

The result is a different flavor of the same problem: multi-vendor logic forced into a single-seller architecture.

Based on my personal experience, I cannot recommend this app under any circumstances. The amount of time, frustration, and operational damage it caused far outweighed any potential benefits. If you are considering this solution, I strongly suggest testing it very deeply before committing to it, especially if your business depends on stable marketplace integration. For me, this app ultimately became a major setback rather than a tool for growth. - Marketplace operator review, Shopify App Store.

Webkul + Magento – complexity layered on complexity

Webkul's deepest roots are in Magento 2. The Multi Vendor Marketplace extension is the most widely deployed marketplace module in the Magento ecosystem.

For years, it was the only option for Magento merchants who wanted multi-vendor capabilities without a ground-up rebuild.

That first-mover status earned Webkul a large install base, but it also locked thousands of merchants into an architecture that compounds problems as it grows.

The Magento module did not work out of the box and required some tinkering. BUYER BEWARE $200 module also required minor customisation charge to be $600 (why this standard feature is not in the module I do not know). Dumped the module and went to another supplier. - Marketplace operator review, Quora.

Here's where things break down.

The monolith tax

Magento is a monolithic PHP application. Every extension shares the same codebase, the same deployment pipeline, and the same database.

When you layer Webkul's marketplace module (plus five, ten, or fifteen add-ons) on top of that monolith, you multiply the surface area for conflicts.

Magento upgrades already carry risk. Add a marketplace extension with its own dependency tree and the upgrade path becomes a project in itself.

Teams report weeks of regression testing after minor Magento version bumps, because Webkul modules touch core areas like checkout, catalog, and order management.

The Adobe Commerce question

Adobe Commerce adds its own layer of licensing complexity. Webkul charges separately for Adobe Commerce compatibility.

If you're running B2B-specific Adobe modules, like shared catalogs, company accounts, and negotiable quotes, the interaction surface between Webkul and Adobe's own multi-buyer logic creates unpredictable behavior.

Adobe's own roadmap has shifted toward composable commerce and API-first architecture. Building deeper into a monolithic extension model runs counter to where the platform vendor itself is heading.

Customization spirals

The real cost of Webkul on Magento is not the license fees but the development time.

Teams that start with the base module inevitably need customization – adjusting commission logic, modifying seller onboarding flows, connecting with an ERP or PIM system.

Every customization touches Webkul's code, which sits between your business logic and Magento core.

When Webkul releases an update, your customizations may break.

When Magento releases a security patch, Webkul compatibility isn't guaranteed on day one.

You're maintaining three layers of code simultaneously: Magento core, Webkul modules, and your own modifications.

For a deeper look at why Magento as a marketplace foundation hits its limits, see our analysis of building a marketplace in Magento.

Webkul + Shopify – a multi-vendor app built on single-vendor DNA

Shopify is a single-tenant, single-seller platform by design. Its architecture, checkout flow, and data model all assume one merchant selling to many buyers.

Webkul's Shopify multi vendor marketplace app tries to graft multi-vendor logic onto that single-seller foundation.

In my personal experience, this has been one of the worst apps I have ever worked with on Shopify. I installed it with the expectation that it would provide stable integrations and reliable marketplace sync, but from the beginning I encountered constant technical issues, glitches, and inconsistent behavior across multiple features.

Over time, these problems created real operational difficulties for my store. Basic actions failed, errors kept returning, and important parts of the app did not function as advertised for me. One of the biggest issues I faced was the marketplace integration (for example with Etsy), which continuously produced errors, failed syncs, and incomplete data transfers. This alone caused massive disruption to my workflow, leading to delays, incorrect listings, and lost time trying to manually fix things that the app was supposed to handle. - Marketplace operator review, Shopify App Store.

The plan escalation trap

Running Webkul on Shopify requires upgrading to a higher-tier Shopify plan to access the checkout integrations and shipping options a marketplace needs. The Growth plan is the minimum to activate cart-level integrations and shipping configuration.

Merchants who choose this path expecting a low entry cost find themselves on an elevated Shopify plan before the marketplace is even functional + monthly fees for each Webkul feature module, ranging from $5 to $50 per plugin. The initial budget estimate rarely survives contact with the real requirements.

One-way data sync

Webkul on Shopify synchronizes data in one direction only. Shopify pulls data from Webkul, but Webkul does not push updates back to Shopify.

In practice, multiple vendors must manually add and update inventory levels inside Webkul. For a seller managing stock across multiple channels, like their own site, Amazon, a wholesale portal, this creates a parallel data entry burden.

There is no automated two-way sync. Stock levels drift. Overselling happens.

For larger brands with warehouse management systems and multichannel inventory tools, this is a dealbreaker. They cannot allocate inventory to your marketplace programmatically. Every stock update is a manual task.

No per-vendor shipping in a single cart

Shopify's checkout assumes a single fulfillment source. Webkul can split orders across vendors after purchase, notifying each brand of their portion and summing shipping costs. But it cannot present different shipping methods from different vendors within one cart.

Customers purchasing from three sellers see one shipping option, not three. There's no way to let Vendor A offer express shipping while Vendor B offers freight.

The checkout abstraction that makes Shopify simple for single-seller stores makes it rigid for multi-vendor scenarios.

Manual fulfillment, no logistics integration

Fulfillment on the Webkul-Shopify stack is entirely manual. Vendors track orders themselves and organize shipping outside the platform. There is no native integration with third-party logistics providers or vendor warehouse systems.

Inventory updates are manual. Each vendor must carve out dedicated stock for the marketplace, separate from their other channels.

For brands selling across multiple platforms with external warehouses, this is both a logistical and financial bottleneck.

B2B marketplaces lose transactions when any part of the workflow forces participants off-platform. If a vendor needs to step outside to manage shipping, arrange insurance, or handle escrow, the entire deal often migrates with them.

Keeping the full transaction lifecycle on-platform is a documented retention mechanism for marketplace operators, and it's exactly what a bolted-on extension layer can't provide.

For a deeper look at why Shopify as a marketplace foundation is a bad idea, see our analysis of building a marketplace in Shopify.

Where Webkul breaks down on all platforms – 4 areas

Beyond the platform-specific problems, Webkul has structural limitations that surface as a marketplace grows – regardless of whether it runs on Magento, Shopify, or anything else.

1. Seller onboarding and lifecycle management

Webkul provides a registration form and an approval toggle. That's not seller lifecycle management.

There's no staged onboarding workflow, no automated document verification, no progressive access controls.

For B2B marketplaces where seller onboarding often involves tax document validation, compliance checks, contract signing, and tiered commission structures – the gap between what Webkul offers and what operators need is wide.

Teams fill it with manual processes, spreadsheets, and workarounds.

2. Catalog governance

Multi-vendor catalogs are inherently messy. Duplicate products, inconsistent attributes, conflicting category mappings – these are table stakes problems that need automated tooling.

Webkul's product approval flow is binary: approve or reject. There's no attribute-level validation, no duplicate detection, no catalog mapping rules.

As the vendor count grows, catalog quality degrades unless the operator invests heavily in manual curation.

3. Payment splitting and PSP flexibility

B2B marketplaces often operate globally. Suppliers are often in emerging markets where Stripe doesn't process payouts or where local payment methods are required.

Webkul's payment splitting depends on which add-on you purchased: Stripe Connect, PayPal, or Mangopay – each a separate module.

If your marketplace needs to support multiple payment service providers across different regions, you're licensing and maintaining multiple payment modules, each with its own integration logic.

A marketplace platform should be PSP-agnostic by design. That's not an add-on, it's an architectural decision that needs to be made at the foundation.

4. Localization and admin UX

Translating the Webkul admin and vendor panels is a manual, file-by-file process. There is no language selector. Operators must export CSV files for each panel section, translate them externally, and re-import them.

For marketplaces operating across multiple countries, this alone can consume weeks of operational effort.

The admin UX itself draws consistent criticism: long configuration paths, unclear documentation, and slow support response times. When your marketplace operations team spends hours configuring basic settings, the platform is working against you, not for you.

What a purpose-built marketplace platform looks like & what are alternatives for Webkul?

The pattern across every Webkul limitation is the same: an extension layer cannot compensate for a host platform that wasn't architected for multi-vendor commerce.

The checkout, data model, fulfillment logic, and payment infrastructure all need to be designed for marketplaces from the ground up.

Architecture that starts with multi-vendor logic

A purpose-built marketplace platform doesn't bolt vendor management onto a single-seller data model.

Multi-vendor logic lives at the core: the order model supports multiple fulfillment sources natively, the catalog schema handles shared and vendor-specific attributes, and the payment layer splits transactions without a third-party plugin.

This eliminates the extension dependency chain.

No compatibility matrices between a base module, fifteen add-ons, and the host platform. No three-layer code maintenance. No upgrade roulette.

PSP-agnostic by design

Global B2B marketplaces need payment flexibility. A supplier in Indonesia requires a different payout mechanism than a supplier in Germany.

Locking into a single PSP, or maintaining separate plugins per provider, creates operational friction and limits geographic reach.

A purpose-built platform treats PSP flexibility as an architectural decision, not a feature add-on. Multiple payment providers run concurrently, with routing logic that matches each seller's region and requirements.

Headless architecture, no monolith tax

Decoupling the frontend from the commerce engine means independent deployments, independent scaling, and no cascade failures when one layer changes. You should build any storefront without touching the commerce backend.

There are no add-on compatibility matrices. No regression testing after a CMS plugin update broke the checkout. Each service has a clear boundary and a defined API contract.

Code ownership and cost predictability

With an extension-based stack, you're paying for someone else's code that you can't fully control. License fees recur. Customizations break on update. And every new feature means another vendor dependency with its own pricing roadmap.

An open-source marketplace platform flips that model. You own the codebase. You choose where to host it. Your team extends it without waiting for a plugin vendor to ship a module or approve a modification.

There are no per-feature licensing fees and no per-PSP add-on costs. The total cost of ownership becomes predictable and driven by your development capacity, not by a growing stack of third-party subscriptions.

Own the full transaction lifecycle

The strongest marketplaces keep every step of the transaction on-platform: discovery, negotiation, payment, fulfillment, and post-sale support.

When any step forces a participant off-platform, disintermediation follows.

The operators who treat marketplace infrastructure as a core competency will be the ones who capture that growth.

Mercur – the marketplace platform built for this problem

Mercur is a limitless marketplace platform built on Medusa, an open-source headless commerce engine. It was designed from the start for multi-vendor commerce, not adapted from a single-seller tool.

Where Webkul requires you to assemble a marketplace from dozens of plugins, Mercur ships it as a unified system.

Seller onboarding, commission management, split payments, catalog governance, and order routing are native capabilities in Mercur, not paid add-ons with separate update cycles.

The seller dashboard, product approval workflows, and vendor-level analytics are part of the same codebase as the rest of the platform.

You own the code, host it where you want, and extend it without permission from a plugin vendor. The PSP layer is agnostic by design, so you can process payouts to sellers in any region using whichever provider fits. No separate payment module per PSP. No licensing per feature.

For teams evaluating a move away from Webkul or planning a marketplace that Webkul would never scale to support, Mercur eliminates the extension tax entirely. Schedule a demo call!

We work with companies building multi-vendor marketplaces, B2B marketplaces, B2C marketplaces, and MVP marketplace launches. We will help you map the right technology to your specific model.

Your marketplace deserves its own foundation

Webkul serves a purpose at the starting line. If you need a quick proof of concept and a way to test if a multi-vendor model works for your business, a $349 module on Magento or a Shopify app can get you there.

But proof of concept and production marketplace are different problems. The extension model breaks down when you need: split payments across regions, automated seller onboarding, catalog governance at scale, two-way inventory sync, or per-vendor fulfillment logic.

If you're running into Webkul's ceiling, or planning a marketplace that will hit it within the first year – talk to the Mercur Marketplace Experts.

And if you are evaluating marketplace platforms and want a structured comparison, our free guide – Top 11 Multi-Vendor Marketplace Platforms for eCommerce – compares leading technologies (including Mercur) across 11 criteria.

[

]()

FAQ on Webkul multivendor marketplace

What's the alternative to Webkul for building a marketplace?

Purpose-built marketplace platforms like Mercur start with multi-vendor logic as the core architecture, not a bolt-on. Native split payments, seller lifecycle management, catalog governance, and headless architecture for diverse marketplace models eliminate the extension dependency that defines the Webkul approach.

Is Webkul enough to run a B2B marketplace?

No, Webkul provides basic multi-vendor features: a seller dashboard, product approval, and commission rules. For B2B use cases you'll need multiple paid add-ons, heavy customization, and workarounds for features the extension layer simply can't support. Most B2B operators outgrow it.

What does Webkul cost in total on Magento?

The base module is $349 for Magento Open Source, $698 if you add Adobe Commerce compatibility. Each additional feature – split payments, seller shipping, RMA, and reporting – is a separate licensed module.

A marketplace with ten add-ons can easily exceed $2,000–$3,000 in licensing alone before development or customization costs. Add implementation, integrations, and security audits and the first-year total reaches $50,000–100,000.

Why is Webkul on Shopify limiting for multi-vendor operations?

Shopify was built for single-seller commerce. Webkul grafts multi-vendor logic on top of that model but can't override Shopify's checkout, shipping, or data sync architecture.

Data flows one way (Shopify pulls from Webkul, not the reverse), per-vendor shipping options aren't available in a single cart, and fulfillment is entirely manual. These constraints compound as vendor count and order volume grow.

Can Webkul handle multiple payment providers for a global marketplace?

Only through separate add-on modules, one per PSP. Stripe Connect, PayPal, and Mangopay are each different plugins with their own license and update schedule.Running multiple PSPs simultaneously means maintaining multiple payment modules, which adds cost and complexity. A PSP-agnostic architecture, like Mercur's, treats this as a foundational design choice rather than a plugin dependency.

Mirakl Pricing in 2026: What It Actually Costs (And What They Don't Tell You)

Rigby — Mon, 24 Aug 2026 12:03:08 +0000

Mirakl pricing starts at roughly $90,000 per year for the base platform license, plus an estimated 2% fee on every transaction processed through the marketplace. But that number hides the full picture. Mirakl is a marketplace overlay, not a standalone commerce platform - operators need a separate ecommerce engine underneath (Salesforce, Adobe, SAP), which doubles or triples total infrastructure cost. This breakdown covers every cost layer, with insights from marketplace operators who have run Mirakl at scale.

What this article covers

Base license fees start at $90,000 annually and scale rapidly with company size - enterprise contracts reach $500,000+.
The GMV fee penalizes growth: a 2% transaction tax means a $25M marketplace pays $500,000 per year in software fees alone.
Mirakl requires a separate ecommerce platform underneath - Salesforce, Adobe, or SAP - adding $50,000-$200,000+ per year to the real cost.
Operators report 3-5 year lock-in contracts with exit penalties, near-zero customization, and paid add-on modules for features most platforms include by default.

How Mirakl pricing works

Mirakl does not publish pricing. There is no self-serve tier, no pricing page, and no public rate card. Every deal is quote-based, shaped by your company size, projected GMV, and the modules you need. Everything below comes from vendor intelligence, operator conversations, and published third-party benchmarks.

Base platform license

The annual platform license is your first expense. Based on Vendr marketplace data and operator feedback, the minimum sits around $90,000 per year (roughly EUR 85,000). Enterprise clients pay between EUR 180,000 and EUR 325,000 annually. High-end enterprise deployments with custom SLAs can exceed $500,000 per year.

This fee covers the marketplace backend only - seller onboarding, order routing, and basic catalog tools. It does not include the ecommerce storefront, implementation services, or any add-on modules.

GMV transaction fee - the marketplace tax

The most significant long-term expense is the percentage-based transaction fee. Mirakl charges approximately 2% of all marketplace GMV processed through the platform. For context, this rate was 4.5% in 2015 before Mirakl shifted toward enterprise SaaS positioning and reduced it to attract larger operators.

This fee scales directly with your success - the more your marketplace grows, the more you pay for the software running it. At $10 million in annual GMV, the transaction fee costs $200,000 per year. At $25 million, it hits $500,000. At $50 million, you are paying $1,000,000 annually just for the right to process transactions through Mirakl's system.

Over a 3-year contract, a marketplace doing $25M in annual GMV pays $1.5 million in transaction fees alone - before the base license, before the underlying platform, before implementation.

The hidden layer - you need a second commerce platform

This is the cost most evaluators miss entirely. Mirakl does not handle product catalog display, checkout, payments, tax calculation, or shipping. It is a marketplace overlay that sits on top of a separate ecommerce engine. Operators must license and maintain one of these platforms alongside Mirakl:

Salesforce Commerce Cloud
Adobe Commerce (Magento)
SAP Commerce Cloud

A CTO evaluating Mirakl at $90,000 per year discovers the real number is $90,000 + GMV fee + $50,000-$200,000+ per year for the platform underneath. Over three years, the underlying platform alone adds $150,000 to $600,000+ to total cost.

Add-on modules not included in the base license

Several capabilities that most marketplace platforms bundle by default are separately priced in Mirakl. Each module requires its own contract negotiation, and operators report that pricing for these modules is not disclosed until you are deep into the sales process.

The modules include MCM (Catalog Manager) for product deduplication and AI recategorization, Mirakl Payout for escrow and PSD2-compliant fund holding, MPS (Platform Services) for services marketplace capability, Mirakl Ads for retail media and sponsored listings, Mirakl Insights for advanced analytics with 50+ dashboard charts, and MQC (Quality Control) for automated seller quality rules.

For operators who need catalog management and payout handling - which is most marketplace operators - the add-on costs can add tens of thousands to the annual bill on top of the base license.

Implementation cost

A standard Mirakl deployment costs between EUR 500,000 and EUR 2,000,000 for complex enterprise environments. The technical build typically takes around four months. But operators report the real bottleneck is not engineering - it is legal review, KYC compliance, and internal stakeholder alignment, which can stretch the pre-sales cycle to 6-12 months.

This estimate does not include ongoing managed services, customization work, or middleware maintenance between Mirakl and the underlying commerce platform.

What does Mirakl pricing add up to over 3 years?

Individual line items look manageable in isolation. The total cost of ownership tells a different story when you stack every layer together - base license, GMV fee, underlying platform, and implementation. Most enterprise procurement teams evaluate the base license alone, which dramatically underestimates the real commitment.

Consider a mid-size enterprise running $25M in annual marketplace GMV. The base license costs $270,000 over three years (at $90K/year). The GMV fee adds $1,500,000. The underlying commerce platform contributes another $300,000-$600,000. Implementation runs $500,000+. Total: $2.5 million or more - and that is before a single add-on module or customization request.

These estimates include base license, GMV fee, underlying ecommerce platform, and implementation. They exclude add-on modules, ongoing customization, and managed services. The trajectory is clear - the more successful your marketplace becomes, the more you pay for the infrastructure running it.

What marketplace operators say about Mirakl pricing

Cost tables tell part of the story. The operational reality behind those numbers - contract structure, customization limits, and switching costs - matters just as much. These insights come from operators running Mirakl across major European retailers.

Lock-in and contract structure

Operators at three major European retail chains report 3-5 year contracts with built-in exit penalties. One marketplace manager described it bluntly: the only realistic window to switch is six months before contract expiration. Miss that window, and you auto-renew under the existing terms with no room to renegotiate.

The financial commitment is front-loaded - CEO and CFO sign before the technical team completes a full evaluation. Mirakl's sales process deliberately targets executive decision-makers early, often before the CTO or engineering team has scoped the technical requirements. This creates organizational commitment before the full cost picture is visible.

Once marketplace data, seller records, and transaction history live in Mirakl's SaaS cloud, the switching cost becomes prohibitive regardless of contract terms. You cannot export your operational history to a competing system without significant data migration work.

Customization limits vs cost

Operators running Mirakl at scale describe near-zero customization ability. One operator noted that the platform allows a single custom field in orders - and nothing beyond that without API workarounds. Need a second custom field? You build middleware around the limitation.

Dashboards and business intelligence are paid extras through the Mirakl Insights module. Most operators skip it and build their own reporting layer in Power BI or Tableau instead, adding yet another parallel system to maintain.

The returns and claims module was described as rudimentary by teams processing thousands of transactions daily. Any functionality beyond the standard configuration requires submitting feature requests to Mirakl's product roadmap - and waiting for a release cycle that you do not control.

The market reality

Multiple operators expressed the same tension: dissatisfaction with the platform combined with an inability to leave. The lock-in is not just contractual - it is architectural. Mirakl's brand positioning works similarly to hiring a large consultancy. Nobody gets fired for choosing the market leader, even when the costs are hard to justify internally.

Independent marketplace consultants describe the dynamic as a trust premium. Organizations choose Mirakl because the brand reduces perceived risk at the board level, not because the total cost of ownership is competitive. For enterprises operating across 10+ countries, switching away from Mirakl mid-contract requires rebuilding integrations with every localized payment provider, logistics partner, and tax engine simultaneously.

Mirakl competitors and alternatives in 2026

Given the cost structure above, what are the realistic alternatives for teams evaluating marketplace platforms? The category has matured, and several paths exist depending on your technical capacity and growth model.

Proprietary alternatives like Marketplacer, VTEX, and Spryker each take a different approach to marketplace architecture - some eliminate the dual-platform requirement, others focus on flexibility for smaller deals. Each comes with its own trade-offs in pricing, customization, and regional strength. For a detailed side-by-side breakdown, see our full comparison of top multi-vendor marketplace platforms.

One alternative stands apart from proprietary options entirely.

Mercur - open-source marketplace platform

Mercur is an open-source marketplace platform built on Medusa.js. No base license fee, no GMV tax, no separate ecommerce platform required. The entire codebase is MIT-licensed - you own the code, the PostgreSQL database, and the hosting environment.

Around 80% of marketplace functionality works out-of-the-box, with the remaining 20% built as custom modules for your specific business logic. For teams evaluating enterprise-scale deployments, Mercur offers a dedicated enterprise license with priority support and no transaction fees at any volume.

How to evaluate marketplace platform costs before you sign

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

Calculate total 3-year cost including all layers. Platform license + marketplace overlay + implementation + add-on modules + ongoing customization. Never evaluate the overlay price alone.
Model GMV-based fees at your projected growth rate. What do you pay at 2x, 5x, and 10x your current transaction volume? If the answer breaks your unit economics, the platform is not viable long-term.
Ask about the underlying platform requirement. Does the marketplace solution handle product catalog, checkout, payments, and shipping natively - or does it need a separate commerce engine underneath?
Check contract terms in detail. Length, exit clauses, auto-renewal conditions, and renewal pricing escalation. A 5-year contract with exit penalties is a different commitment than a flexible annual agreement.
Assess data portability. Can you export and fully own your marketplace data - seller records, transaction history, catalog data, customer information? Or does it stay locked in the vendor's cloud?
Test customization limits on your specific use case. Not the demo, not the slide deck - your actual business logic, your category structure, your seller workflows.

Summary

Mirakl pricing starts at $90,000 per year, but the real 3-year cost for a mid-size enterprise exceeds $2.5 million. The GMV fee, underlying platform requirement, implementation expense, and add-on modules compound quickly. Operators report contractual lock-in, limited customization, and a cost structure that penalizes marketplace growth.

Open-source alternatives like Mercur eliminate the license fee, GMV tax, and platform dependency entirely. With no percentage-based transaction costs and full code ownership, the cost of running your marketplace becomes a fixed infrastructure expense rather than a variable tax on growth. The choice comes down to whether you want to rent your marketplace infrastructure on someone else's terms - or own it outright.

Frequently asked questions

How much does Mirakl cost per year?

The base platform license starts at roughly $90,000 per year. Enterprise contracts range from EUR 180,000 to $500,000+. Add the 2% GMV fee and the cost of the underlying ecommerce platform for the real annual number.

Does Mirakl charge a transaction fee?

Yes. Mirakl takes approximately 2% of all marketplace GMV processed through the platform. This fee scales with your marketplace volume - at $25M annual GMV, that translates to $500,000 per year in transaction fees alone.

What ecommerce platform do you need with Mirakl?

Mirakl is a marketplace overlay - it requires a separate commerce engine for product catalog, checkout, payments, and shipping. Most operators run it alongside Salesforce Commerce Cloud, Adobe Commerce, or SAP Commerce Cloud.

Are there open-source alternatives to Mirakl?

Yes. Mercur is an MIT-licensed open-source marketplace platform built on Medusa.js. No license fee, no GMV fee, no separate ecommerce platform required. Full code and data ownership from day one.

How long is a typical Mirakl contract?

Contracts are typically 3-5 years with exit penalties. Operators report that the only realistic switching window is six months before contract expiration. Missing that window triggers automatic renewal under the existing terms.

How to Create Your Own Marketplace in 2026: A Step-by-Step Guide

Rigby — Mon, 24 Aug 2026 07:27:21 +0000

If you want to create your own marketplace, the gap between idea and live platform is smaller than most guides suggest - but the decisions you make in the first 60 days determine your cost structure, vendor experience, and scalability for years. This guide walks through every step of building a multi-vendor marketplace from scratch: choosing a business model, selecting your technology stack, scoping an MVP, and launching with your first vendors.

The steps below come from building 30+ marketplace projects across B2B, B2C, services, and rental models. Where most guides list abstract advice, this one includes the cost data, timeline benchmarks, and architectural trade-offs that teams need before committing budget.

What this guide covers

A marketplace is not an ecommerce store with more sellers - it is a fundamentally different business model with different unit economics, technology requirements, and growth dynamics.
The six steps to creating a marketplace: define your model, choose your revenue structure, map vendor and buyer flows, select your tech stack, build an MVP, and launch with your first vendors.
Development costs range from $5,000 (plugin on WordPress) to $500,000+ (custom enterprise build). The architecture you choose in step four determines where you land on that spectrum.
Open-source marketplace platforms like Mercur eliminate license fees entirely - your cost is implementation and hosting, and it stays flat as your marketplace scales.

What is a marketplace and how is it different from ecommerce

A marketplace connects multiple independent sellers with buyers on a single platform. The marketplace operator does not own the inventory - sellers do. The operator provides the infrastructure: product catalog, search, checkout, payments, and fulfillment coordination.

This is fundamentally different from a standard ecommerce store. An ecommerce store sells its own products through its own checkout. A marketplace manages transactions between third-party sellers and buyers, taking a commission or fee on each sale.

The distinction matters because marketplace software needs capabilities that ecommerce platforms do not have natively: vendor onboarding, commission management, order splitting across sellers, split payments, and seller-level analytics.

For a deeper comparison of these two models and when each one fits, see our marketplace vs ecommerce breakdown.

How to create a marketplace step by step

Building a marketplace is a sequence of six decisions, each one constraining the next. Skip a step or make it in the wrong order, and you end up rebuilding later. Here is the sequence that works - based on patterns from 30+ marketplace launches.

Define your marketplace model

Before writing a line of code or evaluating platforms, decide what type of marketplace you are building. The model determines your vendor relationships, transaction flow, and regulatory requirements.

Product marketplaces (B2C or B2B) connect sellers of physical or digital goods with buyers. Think Amazon, Faire, or a vertical B2B parts marketplace. Revenue comes from commissions on each transaction, usually 10-25% depending on category.

Service marketplaces connect service providers with clients. Think Upwork, Thumbtack, or a vertical staffing platform. These require scheduling, availability management, and often location-based matching.

Rental and booking marketplaces handle time-based inventory - equipment, spaces, vehicles. They need availability calendars, deposit management, and return workflows.

Get the model wrong and you will fight your own platform for years. A product marketplace built on rental software (or vice versa) creates friction in every vendor interaction.

Choose your revenue model

Your revenue model defines how the marketplace makes money. This is not a decision you can easily change after launch - it is baked into your payment flows, vendor contracts, and unit economics.

Commission-based is the most common model. The marketplace takes a percentage of each transaction. Simple to explain to vendors, aligns incentives (you earn when they earn), but requires enough volume to generate real revenue.

Subscription-based charges vendors a monthly fee for access. Predictable revenue for the operator, but harder to onboard sellers who have not yet proven the channel works for them.

Hybrid models combine commission with subscription tiers, listing fees, or promoted placement. Most mature marketplaces evolve toward hybrid over time.

Whatever model you choose, your platform needs to support it natively. Mercur, for example, ships with a configurable commission engine that handles percentage-based, flat-fee, and tiered commission structures out of the box - so you can test different models without rebuilding payment logic.

Map your vendor and buyer flows

Before selecting technology, document the exact workflows your vendors and buyers will follow. This step prevents the most expensive mistake in marketplace development: building features your users do not need while missing flows they require on day one.

Vendor flow: how does a seller sign up, get approved, list products, receive orders, fulfill them, and get paid? Map every step. Identify which ones need manual review (approval, catalog quality checks) and which can be automated.

Buyer flow: how does a buyer discover products, compare across vendors, check out (potentially from multiple sellers in one cart), track delivery, and handle returns? Multi-vendor checkout and order splitting are the two flows that separate marketplace software from standard ecommerce.

A well-scoped marketplace covers 15-25 vendor-side and buyer-side workflows at launch. Mercur ships with 80% of these workflows pre-built - vendor onboarding, product approval, order splitting, split payments, and commission calculation - which means your team focuses on the 20% that is specific to your business model.

Select your technology stack

This is the decision with the longest tail. Your technology choice locks you in for 3-5 years and determines your cost trajectory, customization ceiling, and vendor dependency.

You have three paths:

Path 1: SaaS marketplace platform. Platforms like Sharetribe or Nautical Commerce give you a hosted, ready-to-use marketplace with minimal setup. Fastest to launch (days to weeks). Trade-off: limited customization, vendor-controlled roadmap, and recurring fees that grow with usage.

Path 2: open-source marketplace platform. Platforms like Mercur (built on Medusa.js) give you full source code, zero license fees, and unlimited customization. You host it on your own infrastructure. Trade-off: requires a technical team to deploy and maintain, but you own the code, the data, and the roadmap.

Path 3: custom build from scratch. Your development team builds every component. Maximum flexibility, but 6-18 months to MVP and $200K-500K+ in development cost before a single vendor signs up.

For most teams, the choice comes down to SaaS vs open-source. SaaS wins on speed to first launch. Open-source wins on long-term cost and customization. Custom build is rarely justified unless your marketplace model is fundamentally unlike anything that exists.

For a detailed comparison of 12 platforms across all three paths, see our best marketplace software comparison. For a broader list with feature breakdowns, see the 11 multi-vendor marketplace platforms guide on Rigby.

Build your MVP marketplace

Your MVP is not a scaled-down version of the full marketplace. It is the minimum set of workflows that lets real vendors list products and real buyers complete transactions. Everything else waits.

A typical marketplace MVP includes: vendor registration and approval, product listing with basic attributes, search and category browsing, multi-vendor cart and checkout, split payment processing, and order management with status tracking. That is it for version one.

Timeline depends on your technology choice. On a SaaS platform like Sharetribe, you can launch an MVP in 1-2 weeks. On an open-source platform like Mercur, expect 4-8 weeks for a customized MVP with your specific vendor flows. A custom build takes 4-6 months minimum for a comparable feature set.

The goal of the MVP is not to impress - it is to test supply-side acquisition. Can you onboard 10 vendors who list real products and fulfill real orders? If yes, you have a marketplace. If not, no amount of features will fix the problem.

Launch and onboard your first vendors

Marketplace launches fail more often on the supply side than the demand side. Your first 10-20 vendors determine whether the marketplace has enough selection to attract buyers.

Start with manual outreach to vendors you know personally or through your network. Do not wait for organic vendor sign-ups. Offer onboarding support: help them list their first 10-20 products, configure shipping, and set pricing.

Reduce onboarding friction to the absolute minimum. Every extra form field, every manual approval step, every unclear instruction loses vendors. The best marketplace platforms provide self-service vendor dashboards with guided onboarding flows.

Track three metrics from day one: vendor sign-up to first listing time, listing to first sale time, and vendor churn rate after 90 days. These three numbers tell you whether your marketplace has a supply-side engine or a supply-side problem.

How much does it cost to create a marketplace

Marketplace development costs vary by an order of magnitude depending on the technology path you choose.

Development cost by approach

SaaS platforms carry the lowest upfront cost. Sharetribe starts at $99 per month. Nautical Commerce offers a free tier. But transaction fees and usage-based pricing mean your cost grows as your marketplace grows.

Open-source platforms like Mercur have zero license fees. Your cost is implementation (configuring and customizing the platform for your business model) and hosting. A typical Mercur implementation for a mid-complexity marketplace runs $15,000-60,000 depending on customization scope, with monthly hosting at $200-1,000.

Custom builds are the most expensive path. A team of 3-5 developers working for 6-12 months costs $200,000-500,000+ before launch. This path only makes sense if your marketplace model requires capabilities that no existing platform provides.

Ongoing operational costs

After launch, ongoing costs include hosting, payment processing fees (typically 2.9% + $0.30 per transaction via Stripe), customer support, and platform maintenance. Budget 15-25% of your Year 1 development cost annually for maintenance and feature iteration.

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

Hidden costs most teams miss

Payment provider setup and compliance (PCI DSS, KYC for sellers) is a cost most teams underestimate. Split payment infrastructure - routing funds from buyers to multiple sellers minus your commission - requires either a payment partner with marketplace support (Stripe Connect, Adyen for Platforms) or custom payment orchestration.

Vendor onboarding tooling, catalog management overhead, and dispute resolution processes all carry cost. Budget for these from day one - they are not optional features, they are operational requirements.

Common mistakes when creating a marketplace

After building 30+ marketplace projects, these are the mistakes we see most often. Each one has cost teams months of development time or six figures in wasted budget.

Building a marketplace when a storefront would work. Not every multi-seller scenario needs marketplace architecture. If you control the supply side (own inventory, curated sellers under contract), a standard ecommerce platform with supplier management may be simpler and cheaper. Marketplace architecture adds complexity that only pays off when you need independent vendor self-service at scale.

Starting with features instead of vendors. Teams spend months building advanced search, recommendation engines, and analytics dashboards - then launch to an empty marketplace. No vendor supply means no buyer demand, regardless of how polished the platform is. Get 10 vendors listing real products before building anything beyond the MVP.

Choosing technology based on launch speed alone. A SaaS platform gets you live in two weeks, but if your business model needs custom vendor workflows, unique commission structures, or deep ERP integrations within 12 months, you will hit the customization ceiling and face a costly re-platform.

Ignoring the payment split problem. Multi-vendor checkout requires splitting a single buyer payment across multiple sellers minus your commission. This is not a feature you add later - it is core infrastructure that affects your payment provider choice, regulatory compliance, and vendor trust.

Underinvesting in vendor onboarding. The marketplace with the smoothest vendor onboarding wins. If it takes a seller 45 minutes and three emails to list their first product, your supply-side growth will stall regardless of buyer traffic.

Summary

Creating your own marketplace is a six-step process: define your model, choose your revenue structure, map vendor and buyer flows, select your technology, build an MVP, and launch with real vendors. The order matters - each decision constrains the next.

The biggest variable is technology choice. SaaS platforms offer the fastest launch but limit customization and charge growing fees. Custom builds offer maximum control but cost $200K+ and take 6-18 months. Open-source platforms like Mercur sit in between - zero license fees, full code ownership, and 80% of marketplace workflows pre-built, with a 4-8 week timeline to a customized MVP.

The right approach depends on your team's technical capacity, your budget, and how unique your marketplace model is. For most teams with development resources, open-source gives you the best combination of speed, cost, and long-term control.

Explore Mercur features or contact the Mercur team to discuss your marketplace project.

Frequently asked questions

How much does it cost to create your own marketplace?

Development costs range from $5,000 (plugin-based on WordPress) to $500,000+ (custom enterprise build). An open-source marketplace platform like Mercur eliminates license fees - your cost is implementation ($15K-60K) and hosting ($200-1,000/month). SaaS platforms start lower but add transaction fees that grow with your GMV.

How long does it take to build a marketplace?

On a SaaS platform, 1-2 weeks to a basic live marketplace. On an open-source platform like Mercur, 4-8 weeks for a customized MVP. Custom builds take 4-6 months minimum. The timeline depends on how much of the vendor and buyer flow you need to customize beyond what the platform provides natively.

What is the best technology to build a marketplace?

It depends on your team and growth plan. SaaS platforms (Sharetribe, Nautical) are fastest for non-technical founders. Open-source platforms (Mercur on Medusa.js, Bagisto on Laravel) give full code ownership with no license fees. For a full comparison of 12 platforms, see our best marketplace software guide.

Can I turn my ecommerce store into a marketplace?

Yes - through marketplace plugins (Dokan for WooCommerce, Webkul for Shopify) or a full re-platform to marketplace-native software. Plugins add multi-vendor features quickly but hit a ceiling for complex operations. For marketplaces beyond basic multi-seller checkout, purpose-built marketplace platforms give you more control.

Do I need developers to create a marketplace?

Not for a basic launch. No-code platforms like Sharetribe let you launch without writing code. But for custom vendor workflows, unique commission structures, or integrations with your existing systems, you need a development team. Open-source platforms like Mercur are built for teams with technical capacity who want full ownership of their marketplace.

Can You Sell Vapes on Shopify in 2026? The Ban, Platform Alternatives, Timeline & Payment Risks

Rigby — Fri, 21 Aug 2026 09:06:24 +0000

You cannot sell vapes on Shopify in 2026. In late June the platform told merchants selling Electronic Nicotine Delivery Systems, or ENDS, to remove those products, and the deadline passed on 8 July 2026.

The notice covered hardware, e-liquids, pods, disposables, coils, and accessories. It applied whether or not a product carried FDA authorisation, and whether or not the store had traded lawfully for years.

This article breaks down:

What did Shopify ban, and when?
Why did Shopify end e-cigarette products sales instead of policing listings?
Does the ban reach merchants outside the United States?
Which payment processor can you use to sell vapes?
Which platforms are alternatives to Shopify for your online store?
How do you migrate a vape store from Shopify to Medusa?

Key insights

Shopify sent removal notices on 24 June 2026 and set a deadline of 7 to 8 July 2026, covering every ENDS product regardless of FDA authorisation.
A spokesperson for the California Attorney General told Reuters that the decision applies globally, so lawful retailers outside the United States lost listings as well.
Peer-reviewed research in BMC Public Health found that Shopify served 50% of the online e-cigarette stores sampled, and 90% of those stores appeared to breach at least one federal rule.
Shopify's published Acceptable Use Policy does not name vaping products, so silence in a hosted platform's policy is no guarantee of anything.
The same coalition of attorneys general wrote to nine payment companies in April 2026, which makes the payment processor a second dependency for any store in this category.
Card processors treat vape products as regulated rather than forbidden: Stripe lists tobacco, including e-cigarettes, as a restricted business requiring extra due diligence.

What exactly did Shopify ban and when?

Shopify withdrew an entire vape product category from its platform rather than policing individual listings.Affected merchants received notices on 24 June 2026 and had roughly two weeks to clear their catalogues.

Reuters reported the notices, and Shopify confirmed to the news agency that they were authentic while declining to comment further.

Which vape products did Shopify remove from the platform?

The category was drawn widely. Devices, refills, and consumables went at the same time as the accessories that support them, which left mixed-inventory retailers cutting far more than a single product line.

Federal authorisation made no difference to the outcome. A product with FDA marketing authorisation came off the store alongside one without it, so compliance work already done by a merchant bought nothing.

That outcome is less surprising once the size of the authorised market is clear. The FDA lists 45 e-cigarette products authorised for sale, and those are the only ENDS products that may lawfully be sold in the United States.

Filtering a catalogue by federal authorisation would have emptied almost all of it anyway. A tobacco product with an authorisation is the rare exception in this category.

Does the Shopify vape ban apply outside the United States?

Yes, a spokesperson for California Attorney General Rob Bonta told Reuters that Shopify's decision applies globally, which took an American enforcement matter and turned it into a worldwide catalogue restriction.

Single-use vapes have been illegal to sell in England since 1 June 2025 under the Environmental Protection (Single-use Vapes) (England) Regulations 2024, and reusable devices stayed lawful.

A British retailer selling only reusable devices was therefore fully compliant with British law and still lost its listings. That catalogue was closed by a software supplier's policy, and no regulator asked for it.

Selling vapes online in the United Kingdom remains lawful under its own local regulations. The age of sale is 18, and products must appear on the MHRA notified list before they can be supplied.

Why did Shopify ban e-cigarette sales instead of filtering listings?

The pressure arrived in stages. In November 2025, a bipartisan coalition of 25 attorneys general, joined by the City of New York, wrote to Shopify about illegal tobacco sales on the platform, and by 24 June 2026, offices including Illinois and Connecticut were publishing statements welcoming a full ban.

Research published in 2026 explains why per-listing vetting was never going to settle the matter. A study in BMC Public Health sampled 58 online e-cigarette stores and found that 51 of them, or 88%, appeared to violate at least one federal rule under the Prevent All Cigarette Trafficking Act.

The most common breach was shipping through a restricted carrier, found at 45 stores. Age verification and adult signature on delivery accounted for the rest.

Shopify was the most used platform in that sample, serving 29 of the 58 stores, and 26 of those 29 appeared to breach at least one rule. The same study noted that 16 of the 18 platforms it reviewed already required clients to obey local and federal law, so a compliance clause on paper was doing very little.

Most of the failures sat in how stores shipped and verified buyers, which no amount of catalogue review would have caught. That is why the platform removed the category instead of reviewing it.

Which payment processor can you use to sell vapes?

Card processors treat this category as regulated and not as forbidden, and that distinction decides how much paperwork a merchant faces. Stripe's restricted businesses list, updated on 13 May 2026, places tobacco products including e-cigarettes, cigars and e-liquid under regulated industries, which means extra due diligence before an account is approved.

Shopify Payments is not a route for these products at all, because the listings themselves are now prohibited on the platform.

Pressure reached this layer in the same campaign. On 28 April 2026, the coalition of 25 attorneys general, again with the City of New York, wrote to nine payment companies including Visa, Mastercard, PayPal and Stripe, urging stronger action against unlawful tobacco and nicotine sales, and asked each for a response within 15 days.

Expect underwriting instead of a signup form. A provider serving high-risk categories asks for licences, age verification, shipping policy, and supplier documentation before it approves an account, and it can still decline, which is why the payment conversation belongs at the start of a replatforming project and not at the checkout build.

Top 3 eCommerce software alternatives to Shopify after the vape ban

1. Self-hosted headless framework on Medusa

Medusa is an open-source flexible commerce framework. The storefront is decoupled from the backend, so the storefront, the admin, and the data model are shaped through an API instead of inside one application.

Our Medusa B2C starter shows what that looks like in practice for a direct-to-consumer catalogue.

No supplier can decide that your products have to go, and the MIT-licensed core costs nothing to licence. What the route does ask for is development capacity.

For a shop whose whole catalogue can be pulled by somebody else's policy update, that removes the risk that matters most.

The platform work sits in migration to Medusa, and our Medusa Experts team can handle this process for you.

2. Self-hosted monolith

Self-hosting means you decide what the shop sells, because no supplier sits between the shop and its catalogue. WooCommerce is a WordPress plugin in which the shop front and the selling logic run as one application.

Our comparison of WooCommerce, Shopify and Medusa sets out the trade-offs across architecture, scalability and maintenance.

The core plugin costs nothing to licence, and the cost turns into work instead. Hosting, updates, security patches, and site speed become your job, which suits a team with developers and strains a team without them.

A monolith answers the policy question and leaves a harder one open. Most of what a vape shop needs beyond a plain catalogue arrives as third-party plugins, so age checks, shipping rules per market, and subscription logic each become somebody else's code that you have to keep updated and working.

The storefront and the selling logic also live in one application. Changing how the checkout behaves for a regulated category means working inside the same codebase that renders the pages, which slows down the changes this category needs most often, and our comparison linked above sets out how that plays out on scalability and maintenance.

3. Hosted SaaS

The route with the least technical work is to rebuild on a different hosted service, such as Adobe Commerce (Magento) or Commerce (BigCommerce). Each carries its own licence or subscription, and neither is a small line in a budget.

A licence on these platforms is a running cost that grows with your sales. Adobe Commerce licensing starts at about $22,000 a year for the smallest stores and reaches $150,000 to $200,000 and above at higher revenue tiers, because the price is tied to how much you sell. Commerce sits lower, with an Enterprise plan around $1,000 to $2,000 a month depending on volume and a B2B add-on charged on top.

Those are licence fees alone. Our comparison of what the leading B2B platforms cost puts hosting, development, and maintenance next to them.

There is also a catch worth reading twice. We checked both published policies: the Shopify Acceptable Use Policy does not mention vaping products anywhere, and neither does the Commerce Acceptable Use Policy, last updated on 31 July 2025, which instead asks merchants to warrant that their products comply with applicable law.

Shopify's own policy was equally silent right up to the week it removed the category. A policy that says nothing today can still change next quarter, so this route hands the same risk to a different company.

Paying a licence buys you a platform and not a say in what you may sell. The fee grows with your revenue, and the decision about your catalogue stays with the platform company.

What is the next step for merchants leaving Shopify?

The vape ban was a category decision made by a supplier under regulatory pressure, delivered in two weeks and absent from the policy document merchants had been reading. Every retailer in a regulated category now has evidence of how quickly hosted terms can move.

Merchants asking whether you can sell vapes on Shopify now have a documented answer, and the question worth asking next is who should hold the policy risk.

Another hosted platform keeps the operating burden light and leaves the policy risk with a vendor, while an owned stack takes on the infrastructure and removes the veto.

If your catalogue sits in a category that a platform could reclassify, talk to us about a migration to Medusa.

FAQ on selling vapes after the Shopify ban

Does Shopify allow vapes?

No, Shopify prohibits the sale of ENDS products on its platform following removal notices issued on 24 June 2026 with a deadline of 7 to 8 July 2026. The restriction covers devices, e-liquids, pods, disposable vapes, coils and accessories. Products with FDA marketing authorisation received no exemption.

Why did Shopify ban vape sales?

Shopify acted after a bipartisan coalition of 25 attorneys general and the City of New York pressed the company over illegal tobacco sales on its platform. Research published in BMC Public Health in 2026 found that 88% of the online e-cigarette stores sampled appeared to violate at least one federal rule, most often by shipping through a restricted carrier. Those failures lay in how stores shipped and verified buyers, so reviewing listings individually would not have resolved them.

Can you use Shopify Payments for vape products?

No, because Shopify prohibits the listings themselves, which removes the question of how they would be paid for. On other platforms, the constraint is different: Stripe lists tobacco, including e-cigarettes, as a restricted business requiring additional due diligence rather than as a prohibited one. A merchant in this category should expect underwriting, documentation, and the possibility of a decline.

Where can I sell my vapes online?

The options are another hosted platform, a self-hosted store, or an owned stack on an open-source framework such as Medusa – the best alternative to Shopify.

Set against a hosted platform, it takes away the thing that closed these shops: no supplier can decide that your products have to go, and the MIT-licensed core costs nothing to license.

Set against a self-hosted monolith, it gives you an API-first build, so age checks, shipping rules and a checkout that suits this category are designed to fit instead of bent around a plugin stack.

What items can you not sell on Shopify?

Shopify's Acceptable Use Policy names no product categories and instead requires that merchants use the service lawfully, so the prohibited list is not a single published catalogue. Alongside it, Shopify publishes compliance guidance for restricted categories such as alcohol and hemp, and ENDS products are now prohibited outright. The vape ban shows that a category can move from permitted to prohibited without the policy text changing first.

Sources

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.