Medusa.js vs Magento 2: Which to Choose and When

Magento 2 is an e-commerce platform that can run an entire store: products, checkout, customer accounts and admin. The free version is called Magento Open Source; the commercial package is Adobe Commerce. For wholesale, Adobe Commerce has a separate module: company accounts, price lists, quotes and approvals. This exists only in Adobe Commerce and requires a separate license. Magento Open Source does not include the Adobe module. Wholesale can be added to it with a third-party module, for example from Amasty.

Medusa.js is an open-source e-commerce platform. The installation comes with a commerce engine and an admin panel. For the storefront, there is an official starter: products, account, cart, checkout and orders. You can use it as-is or rebuild it to match your brand. Your sales rules are developed on top.

If your wholesale buyer needs to see a contract price, approve an order with two people and enter product codes, the first question is not the platform name. The question is whether that purchase journey already exists in the platform or whether you have to build it yourself. Three things depend on this: how much ready-made functionality you get, how much you have to write yourself, and who maintains it afterwards.

Write down on paper how your customers actually buy. Every point that exists in the Adobe wholesale module speaks for Magento, if you buy that license. Every point that is not there is work you do on either platform.

Two different products

The market talks about two themes.

The first is a ready-made platform. Research firm Gartner still compares e-commerce platforms as ready-made solutions. Adobe states that Adobe Commerce was named a Leader for the ninth consecutive year in the 2025 assessment. Gartner evaluates Adobe Commerce, not Magento Open Source. The leaderboard position only says that the ready-made package has not disappeared from the market. It does not tell you which store suits you.

The second is a composable store. MACH Alliance describes an architecture where checkout, content, search and storefront pages can be separate systems that talk to each other. A new channel — an app, a wholesale portal or an AI agent — can then be connected to the same engine without building a new store.

These two themes are not choices you must decide between. The choice is your purchase journey.

What is the difference between Magento and Medusa wholesale capabilities

The last row is the point of the entire article. If your sales process is that row, neither ready-made list covers your journey. Then the question is which engine you build your store on. Below we look at both products more closely.

Magento 2, when the purchase journey is a ready-made product

Magento 2, specifically Adobe Commerce with the wholesale module, is strong where wholesale is standard. Not because Magento is an "enterprise platform" but because those journeys are written in the product and Adobe maintains them.

The module does not come with every Magento 2 installation. Magento Open Source does not include it. When the Adobe Commerce license and wholesale module are in place, the merchant gets company accounts, different price lists for different companies, quick order by product codes, negotiable quotes, purchase order approvals and requisition lists. Wholesale here means an organisation that buys, not just a second price tier with VAT.

Company accounts put all buyers from the same company under one account. The administrator builds departments, roles and permissions. The hierarchy is designed for approvals: buyer adds to cart, manager approves. Shared catalog means that different companies see different products and different prices. The catalog is attached to the account, not a filter on the store page.

Quotes are not an email with a PDF but a negotiation inside the store: line items, quantities, discounts, statuses. Requisition lists hold line items that are bought again and again. Quick order is a list of product codes or a file, not a category tree.

In real Magento wholesale projects, this exact set is the reason the platform is chosen. The client comes from accounting or warehouse software, the price is agreed in a contract, the buyer knows the article number and the department head gives approval. Magento holds the store side: catalog, account, price and purchase journey. The correct number for stock, invoices and credit often lives elsewhere. Where that boundary runs is not decided by Magento but by the integration.

Magento's second advantage is the ecosystem. Adobe Commerce Marketplace has thousands of extensions and templates. There are more integrators, developers and predictable hourly rates than with Medusa. Your existing team will not tell you which platform is better, but they will tell you fairly precisely what you can actually deliver in the next year. The extension marketplace means ready-made pieces that someone else maintains.

Magento can also be built so that the storefront is separate from the admin, for example using Zaproo Box, and queries data from Magento. In a classic installation, this is not the default state. By default, Magento 2 is a whole — a monolith: storefront, admin, store, wholesale journeys and extensions live together.

Adobe itself is moving in the other direction. Adobe Commerce as a Cloud Service is a cloud service whose components talk to each other through interfaces. This does not change the choice between classic Magento 2 and Medusa. But it is no longer the whole truth in 2026 that Magento is monolithic and Medusa is headless.

The boundary is reached when your rule does not fit inside company accounts, shared catalog and quotes. Then a custom solution is written into Magento. This is doable, and at the same time the point where the store starts becoming expensive over time. Every "small exception" in checkout is code that someone must maintain, and every Magento version upgrade is a project. Adobe lifecycle policy gives the dates: 2.4.7 standard support ends May 31, 2027, 2.4.8 standard support May 31, 2028 and 2.4.9 standard support May 31, 2029. 2.4.7 extended support runs until May 31, 2028. Extended support is paid breathing room, not a solution. When exceptions accumulate more than ready-made features, the fault is not in Magento. The fault is in the assumption that you bought a ready-made solution you would not need to touch.

Medusa.js, when the rule must be written yourself

Medusa comes in three parts. The commerce engine holds inventory, cart, payment and orders. The admin panel is for the merchant. The storefront is a separate application: it is deployed, built and hosted independently from the engine. On installation, you can choose a starter store that you can use as-is or customise to your business.

The difference from Magento is not whether a storefront exists. Magento by default has admin and store in one piece. Medusa by default has engine and admin in one piece and the storefront alongside. This becomes important when you want a second storefront, an app or an agent on the same engine.

For wholesale, the documentation must be read precisely. The Medusa B2B guide lists ready-made parts: sales channel, customer group and price list. For company accounts, it points to a separate module. The official B2B starter goes further: company management, employee roles, spending limits, approval flows, quotes with messaging and adding multiple variants to cart at once.

The list is close to Adobe's. The difference is not in the list. The difference is ownership. The Adobe wholesale module is a licensed product: Adobe maintains it, Adobe updates it, you get it with version upgrades. The Medusa starter is a template that you copy into your codebase. From that moment, it is your code. You update it when Medusa changes. You carry the risk if you do not update. Medusa is also a younger project: breaking changes happen and the talent market is smaller than Magento's. This must be accounted for in budget and timeline.

This is not a minus if your purchase rule does not fit a ready-made list anyway. You write code regardless and the template gives you a start. It becomes a minus when you expected to buy a maintained product.

Price is not a footnote

Magento wholesale journeys exist only with an Adobe Commerce license. Magento Open Source does not include them. Adobe does not publish a price list. The price depends on revenue and starts in the tens of thousands of euros per year, with the wholesale module separate. The Medusa core license is zero, but the purchase journey is development hours and your maintenance from the starter onwards. On top comes server, updates and monitoring. These do not disappear because the license is free.

The question is not which is cheaper. The question is whether you pay for a license that covers your journey, or for development, hosting and maintenance that writes a journey the license does not cover.

Case study: three rules that are not in the ready-made package

REVIMIT Energy Labs OÜ previously sold on WordPress and WooCommerce: one country at a time, invoices by hand, wholesale by email, content and store in separate systems.

The manufacturer wanted three things: sell worldwide, serve wholesale buyers without a human, and be readable to AI agents who, in their assessment, would start shopping. The old store could do none of these. The project's starting point was defined before the platform was discussed.

Zaproo built a new store from June 2026 where the storefront, commerce engine and content management are separate. The commerce engine is Medusa. Content, product data and contract-based pricing live in Payload. The storefront is its own application, not a Magento theme or the Medusa starter as-is. The site is live at www.revimit.com. Purchasing is currently on public pause because the product is being updated. The following describes what was built. This is not a sales number.

One rule carried the entire project: price, VAT and permission are decided by the store, not by the page on screen. The page does not calculate any sum it did not ask the store for. Otherwise the visitor sees a wholesale price, checkout shows the wrong VAT or an invoice opens without a contract.

Three sales rules carried the rest. Each of them can be found in both worlds as something similar when looked at one at a time. Together they do not come from either ready-made package.

First: price is unlocked by a signed contract, not by an account. Creating a company account itself unlocks nothing. The buyer fills in company details, the VAT number is checked against the European registry, the contract text comes from the content management system and is signed inside the store. The database retains evidence of which contract version was shown when. The wholesale price is unlocked only after administrator approval. A cancelled contract closes the price the same way and remains in the archive.

Magento's company account lets a company build structure after account approval. Here the approval object is a document, not an account. The difference sounds small. In practice it is different logic.

Second: discount is calculated across all cart units, across line items and variants. Not by line item total and not per variant. Retail and wholesale tiers have different logic. A tier excludes certain shipping discounts: wholesale price and free shipping do not combine. All of this must apply at once, in the same calculation. Otherwise carts appear where two discounts stack.

Both platforms know cart rules. Neither ships with this combination where a unit-based tier switches off another discount and simultaneously depends on contract status.

Third: payment method is locked to the contract. Invoice ordering is only for logged-in wholesale buyers with a valid signed contract. The check happens at checkout on the store side, not on the page. A guest who tries to order by invoice gets a rejection. If the condition is not met, the order does not go through.

In the Magento wholesale module, payment terms and credit limits are properties of the company account. Here they are properties of the signed document. When the contract is cancelled, the payment method closes itself without anyone touching the account.

The rest followed from the same rule. Orders can be placed to over 200 destinations. The VAT regime — destination country rate, export at zero rate or reverse charge with a valid VAT number — is decided by the store based on the delivery address, not the account profile. The shelf price is the same everywhere. Only the portion of the price that is VAT changes. Shipping limits, parcel locker selection and customs data come the same way from the store. The invoice goes to accounting in one step, with the same number in both systems and without double entry.

The store's speed is measured and good. No platform argument can be made from this: speed is decided by the build, not the platform name.

The Magento wholesale package would have given Revimit company accounts and different price lists. What was needed was something else: contract before price, discount on cart units and payment method tied to contract. If these rules are written into Magento, what remains is the Magento package plus the same work. If they are written into Medusa, what remains is the commerce engine plus the same work. The choice was which engine the work attaches to. The choice was not whether there would be work.

When the buyer is an agent

Revimit's requirement to be readable to purchasing agents sounded in early 2026 like a cautious wish. Meanwhile, OpenAI, Stripe and Google have started writing down how a machine buys on behalf of a human. One protocol describes the purchase itself, another asks how a merchant proves that a real authorisation stood behind the agent's order.

Neither of these is a ready-made feature in Magento or Medusa today. Neither platform sells you agent-readiness. Building a product on a beta-stage standard is not sensible.

Three things are useful even if no standard wins. A catalog that a machine can read. A checkout that does not only work by clicking. And the rule that price, VAT and permission are decided by the store, not the page on screen. If the sum comes from a page the store did not confirm, the agent's purchase is not trustworthy.

Revimit had the same rule before agents: a guest must not see the wholesale price. When the store itself decides the price, adding an agent is the next channel, not a new store. Magento can give the catalog and checkout to a machine today. With Medusa, the storefront is separate anyway, so adding a new channel is less work. The agent's own validation you write yourself in both cases. The difference is in the starting position, not the end result.

Six questions before the platform name

Answer all six before anyone says a platform name. The answers are your brief, regardless of which engine you choose.

• Write your purchase rules on one page, without a platform: company account, role, contract price, quote, requisition list, approval, product code line. If this is your sales process, the Adobe wholesale module is a ready-made product for you. If every line is an exception, a ready-made package will not help.

• Where is the correct number. If price, credit, stock and invoice live in accounting or warehouse software, the e-commerce store is a store, not the whole company. Magento is mature in this role and Medusa does the same. The question is not whether to integrate but how much logic may live in the store.

• How many surfaces must use the same commerce engine. Magento can run multiple stores and themes from one installation. A separate app, wholesale portal or agent still needs an interface. Medusa is built for this because the storefront is a separate application that queries the engine. One storefront and a machine-readable order was enough reason for Revimit to keep the engine separate. This is not yet a reason to buy a composable architecture you do not use.

• Is your purchase rule your advantage or standard wholesale. Standard belongs in a ready-made package, advantage must be written yourself. Unlocking the wholesale price only after a signed contract was Revimit's advantage, not a wholesale standard feature.

• What you already have. An existing Magento catalog, extensions and people with Magento skills speak for Magento. A blank slate and a modern web team speak for Medusa. The extension marketplace speaks for Magento. Your own rule that does not exist on the market speaks for Medusa.

• Who maintains this code in five years. Magento's answer is a custom solution inside the platform that you replay with every upgrade. Medusa's answer is a custom solution inside a framework that you carry yourself at version changes. The difference is whether you fight the platform's assumptions or write the assumption yourself, and whether someone else maintains the ready-made part.

When to choose which

Choose Magento 2 when your wholesale is a ready-made package: you genuinely need company accounts, different price lists, quotes, requisition lists, approvals and quick order by product code. Retail and wholesale live in the same catalog and the correct number is in accounting or warehouse. Your people know Magento admin, you do not want to assemble a wholesale store from pieces and you are ready to pay for the Adobe license because it covers the journey.

Choose Medusa.js when you build your own purchase journey: the storefront is your face and the purchase rule is your rule. Wholesale for you means contract, approval and only then price. VAT, shipping and checkout are your real boundaries, not a demo. You accept that from the starter onwards the code is yours.

Do not choose Medusa because Magento seems old, or Magento because someone said "enterprise." Gartner's leaderboard position does not build your approval rule. Composable architecture does not add a requisition list to your store.

An Estonian wholesaler whose customers order by article number and contract price wastes a year building the Adobe wholesale package from a Medusa template. A manufacturer whose rule is a signed contract, global VAT and a machine-readable catalog wastes a year dragging the Magento wholesale module into a company-account structure they do not have.

Conclusion

Zaproo builds both. Revimit shows what a Medusa-based decision looks like. Magento wholesale stores show a different pattern. Neither proves that one engine is better than the other. Custom development here means a platform decision: the system remains yours, the boundaries between commerce engine, content and storefront are written down, and the store decides price and permission.

If you want to know before choosing how much of your purchase journey is ready-made and how much must be built, a 30-minute conversation is enough. Without sales slides.