MedusaJS · eCommerce B2B convertible
MedusaJS for eCommerce B2B: The engine is half the project
Riding the commerce engine is the part that everyone presupposes. The hard half - that the price your client sees is the price your ERP bills- it's the one nobody's told you yet. That's ours.
15 +
years in eCommerce B2B and integration
100 +
ERP in production
middleware
own synchronization and rates
The platform
Why MedusaJS for complex B2B operations
MedusaJS is an open source trading engine over Node.js, modular and API-first. For a B2B business with consolidated ERP, this translates into six concrete advantages.
Open code, total control
No use licenses or black box. The engine is yours, it runs in your infrastructure and it evolves at your pace.
Modular architecture
Each domain - prices, inventory, orders - is a replacement module. Ideal for injecting B2B logic without forks.
API-first real
The entire operation exposed by API. The front, the ERP and the channels consume the same contract, without hidden shortcuts.
Prices per order line
The mechanism to inject a custom price on each line exists as a standard. The right basis for negotiated rates.
Multi-warehouse and multi-market
Inventory by location, currency and rules by region. Designed for distributors that sell in several countries.
Frontent unconnected
The purchase experience is built apart, with the technology your team decides. The engine does not condition the design.
Our positioning
The layer that the comportable commerce does not carry as a standard
Any agency can deploy a headless engine. What does not come in any documentation is the integration with your ERP and the B2B rate engine: the part that decides whether the project bills well or causes incidents.
The commerce engine is your choice. We take care of that the price your client sees is the price your ERP bills.
The six technical blocks
Which separates having integrated from having read about integrating
These six blocks appear in every serious B2B project on MedusaJS. None of them are factory-solved. We've all built them.
01 · The two price architectures
Repeated rate against calculated rate. When to choose each and why the replica is broken at 18 months as soon as contracts per client appear. It is the first decision of the draft and the most expensive to rectify.
02 · Custom price per order line
The mechanism exists in modern engines. What does not come is the cache, the latency contract and the degradation plan when the ERP does not respond. That's what you have to design and what no one presupposes.
03 · The tariff matrix
Customer typologies on one axis, product categories on the other; the intersection defines the price group. It is its own method, it is explained in two minutes and is the deliverable of the first workshop.
04 · Synchronization with compensation and idempower
What happens when the order enters the ERP and fails the next step. Reattempts, undoing, duplicate orders. Here it is separated who has integrated into production from who has read about integration.
05 · Real source and PIM
What data lives in the ERP, which in the PIM and which in the CMS. The rule: no data in the ERP enters the CMS. The count of documents and the cost per seat punish those who fail to do so.
06 · Standard data as a requirement for agents
An IA agent - or MCP server - on a dirty catalogue does not respond. The standardization of the data is previous work, not guinda. Without it, any IA initiative about your catalog is born dead.
For whom
Who are we talking to?
This approach is designed for IT and technology addresses that already know what a bad synchronized data costs.
Industrial or multi-brand distributor
With a wide catalogue, several product families and sales to professionals as the core of the business.
Consolidated ERP
SAP, Business Central, Odoo, Sage or A3 as a spine. The ERP is not touched: the commerce is adapted to it.
Rates negotiated by customer
Prices by contract, volume or typology. The flat rate was small years ago.
Evaluating leaving PrestaShop or Magento
Several countries, several channels, and a monolithic platform that starts to stop. The jump to comfy is on the table.
Software, non-slide
Anyone generates a presentation in minutes. We teach software working
The proof that we have been inside is not this text: it is a reference connector between our middleware and MedusaJS, with operational demonstration store and real data.
ΟReal-time resolved customer group rates
ΟPrice calculated on an ERP and served to the checkout
ΟPrice injection per order line
ΟCaché with measured latency contract
ΟDegradation plan when ERP does not respond
ΟSynchronization of orders with compensation
/ / price per line: the ERP decides, the engine servescont price = wait pricing.solve({ custodier _ group: "distributor-a", sku: "VLV-2040-INOX", qty: 240, fallback: "cached _ tier" / / degradation if ERP does not respond});
Why us
Criterion earned in production, not in brochures
Ο Over 15 years integrating eCommerce with ERP into industrial and distribution environments.
Ο More than 100 ERP integrations in production: SAP, Business Central, Odoo, Sage, A3.
Ο Own Middleware synchronization, rates and data orchestration between systems.
Ο Allies of implementing agenciesnot their competition: they ride the engine, we drive the connector.
Ο Support and continuous evolution: integration is not delivered and abandoned; it is operated.
Frequently asked questions
What they ask us before we start
MedusaJS fits my B2B business?
If you have negotiated rates, multi-warehouse and need to control the code, it is a serious candidate. If your operation is standard and without ERP by means, a SaaS platform will probably solve you first. We'll tell you in the first conversation, either way.
Can I connect Medusa to my ERP?
Yeah. We work with SAP, Microsoft Business Central, Odoo, Sage and A3, among others. The connection covers catalog, stock, rates, customers and orders, with real-time synchronization where the business requires it and by lots where it does not provide.
Repeated rate or calculated rate: which is good for me?
It depends on the number of contracts per customer and the discount logic of your ERP. The replicate is simpler and sufficient for rates per group; the calculated one is mandatory when the price depends on conditions only the ERP knows. Choosing bad here is what breaks the projects at 18 months.
What if the ERP does not respond when a customer consults prices?
A degradation plan is designed: price cache with defined validity, group backup price and clear rules on what can be shown and what not. The client never sees a mistake or an invented price. This design is part of the project from the first day, not a later patch.
Can I migrate from PrestaShop or Magento progressively?
Yeah, and that's what's recommended. The composite architecture allows to live together: the catalogue or the checkout can migrate in phases while the current platform continues to operate. The total cut in one night is a risk you don't have to take.
What data is in the ERP, which is in the PIM and which is in the CMS?
General rule: the ERP rules price, stock and customer; the PIM rules the enriched product sheet; the CMS rules editorial content. And no data in the ERP is duplicated in the CMS: the counting of documents and the cost per seat end up punishing those who fail to comply with this rule.
Is this ready for IA agents?
Only if the data is standardized. An agent or MCP server on a dirty catalogue does not respond reliably. That is why standardisation is part of the integration project: it is the prerequisite for any layer of IA you want to mount later.
Let's talk about the hard half of your MedusaJS project.
Tell us what ERP you have and what your rates are like. In a working session we tell you what price architecture you have and what it means to integrate it.
Integrated · Automated · Residential