How do you connect B2B ecommerce, ERP and PIM in a MACH architecture?

The safest model: ERP remains the system of record for finance, base price lists, credit limits and invoices; PIM owns product content; WMS owns physical stock and fulfilment; MedusaJS v2 handles cart, checkout, order, channel promotions and commerce APIs; and a NestJS/queue integration layer translates rules between systems.

MACH in B2B does not mean every process must become a microservice. It means domain boundaries are explicit: price, inventory, customer terms, approvals, order lifecycle, fulfilment and payments. Each boundary has an API contract, event, retry policy, dashboard and incident owner.

That keeps the B2B shop from becoming an ERP clone in the browser. It becomes a buying product that uses ERP, PIM and WMS where they are strong, without blocking customer experience on every slow legacy endpoint.

Wholesalers, manufacturers and distributors need multiple price lists, conditional rebates, credit limits, multi-step approvals, trade documents, individual payment terms and often split fulfilment across warehouses. These are not extras. They are revenue and financial-risk logic.

B2C platforms start to crack when a B2B buyer sees a price that depends on division, contract history, volume, currency, delivery threshold and current credit exposure. BigCommerce B2B guidance names personalised pricing, account management, ERP integration and scalability as core needs, which is a useful signal: the problem is operational, not only storefront design.

MACH lets you separate a policy layer from the Next.js storefront. Changing a credit threshold, manager approval rule or freight condition should not require a full site deployment or a manual workaround in ERP.

Base price and payment terms usually belong in ERP because accounting, limits, currencies, invoices and tax rules live there. MedusaJS v2 can calculate cart, channel promotions and checkout, but it must know when to call ERP synchronously and when to use cache or a snapshot.

Product ownership should be split. ERP knows SKU, unit of measure, costs and sellable status. PIM owns descriptions, media, technical attributes, translations and data completeness. WMS owns physical stock, reservations and fulfilment priority.

Order is the hardest domain: the storefront needs immediate confirmation, ERP needs a commercial document, WMS needs a picking task and finance needs an invoice or credit hold. That is why the order lifecycle should be a workflow with idempotency and a customer-service-visible status.

Do not connect the storefront directly to ERP. Put a Node.js/NestJS adapter layer in between, with OpenAPI contracts for synchronous calls and AsyncAPI/events for synchronisation, imports and statuses. OpenAPI formally describes an HTTP API surface and operation semantics; in B2B, that becomes a contract between commerce and back-office systems.

For asynchronous processes, use queues and idempotent workers: RabbitMQ, SQS or a similar mechanism. An ERP outage should not take the shop down. It should mark the order as "waiting for synchronisation", trigger retry and expose operational status to the team.

During DDT we document endpoints, events, retries, rate limits, ID mapping, dead-letter queues, alert ownership and conflict rules. That is more valuable than another category-page mockup because this is where budget usually disappears.

PIM makes sense when the catalogue has many technical attributes, languages, channels, variants, PDFs, images, certificates and approval workflows. Wikipedia defines PIM as managing the information needed to market and sell products through distribution channels; in B2B, that is often the difference between a scalable catalogue and spreadsheets emailed around.

Akeneo API documentation shows a mature integration pattern: REST API, events/webhooks and an OpenAPI specification. That is the direction headless B2B needs: PIM is not a "nice admin panel", but a data source that can feed storefront, mobile, marketplaces and sales collateral.

But PIM does not repair process. If the company lacks attribute owners, unit dictionaries, image-quality rules and approval workflow, integration only moves the mess faster. In GMI projects we map data and ownership first, then scale channels.

Card payment is often the easiest technical part of B2B and the least important business rule. The real rules are deferred terms, credit limit, hold after overdue invoices, cart value above approval threshold and orders placed by an employee on behalf of a division.

In MACH we model a separate credit-policy domain. It can call ERP synchronously at checkout for high risk, use cache for low risk and start an approval workflow for exceptions. commercetools documents Business Units, associate roles, approval rules, quote requests and quotes as separate B2B resources; that shows roles and approvals are a first-class domain, not a customer-account extra.

Compliance boundaries must be explicit: what Medusa stores, what ERP stores, what the payment provider stores, what enters logs and how long data is retained. PCI DSS, GDPR and pre-peak audit are part of architecture, not a document after launch.

Most failures are not dramatic. Price updates arrive 20 minutes late. PIM publishes copy without a certificate. WMS returns stock before reservation. ERP rejects an order after the buyer received confirmation. Sales changes a credit limit in a system the storefront cannot see.

Each case needs a product decision: do we block checkout or accept conditionally? Do we show "available now" or "we will confirm lead time"? Do we reserve stock in cart or after confirmation? Who receives the alert and how quickly must they react?

This is where MACH creates value. Separate domains, events, queues and observability let you degrade a service instead of shutting down the whole B2B channel. The buyer sees a controlled message and the team sees an exception queue.

GMI default model for mid-market B2B: Next.js storefront, MedusaJS v2 as commerce core, NestJS as integration/policy layer, PostgreSQL for transaction data, Redis for cache, queues for synchronisation, PIM for content, ERP for finance and documents, WMS for fulfilment and React Native when buyers need mobile or field ordering.

MedusaJS v2 fits because modules are central to customisation and integrations. Medusa documentation defines a module as a package of functionality related to one domain or integration; that lets us build credit policy, ERP adapter, custom pricing or approval logic without rewriting the commerce core.

This is not a "more technology wins" architecture. It is the smallest set of independent components that removes real constraints: contract pricing, integrations, multi-channel commerce, data ownership and room to grow without vendor lock-in.

Do not measure storefront uptime only. Measure click-to-invoice time, ERP order-sync latency, percentage of orders with manual correction, PIM-to-storefront publication time, oversell rate, pricing errors, webhook SLA, dead-letter queue resolution time and tickets saying "does not match ERP".

Good KPIs are financial and operational at the same time. If sales still retypes orders and finance still releases limits manually after launch, the project is unfinished even if Lighthouse looks good.

At GMI we put these metrics into DDT. That means fixed price after discovery covers not only screens, but integration risk and operating model. It protects the client from a project that "works in a demo" but does not reduce team workload.

Ask for a systems-of-record map: price, product, stock, customer, limit, order, invoice, shipment and return. Each area should have an owner, SLA and conflict rule.

Ask for an example OpenAPI contract for synchronous pricing/availability checks and AsyncAPI or event descriptions for product import, order status and stock updates.

Ask for a runbook: what happens when ERP is down, PIM sends an incomplete product, WMS rejects reservation, payment gateway returns a delayed callback or the dead-letter queue grows during peak season.

Ask for a cost model: discovery, development, data migration, integrations, performance testing, monitoring, maintenance and post-launch ownership. If the offer does not separate those items, risk is hiding in the backlog.

Medusa modules documentation: https://docs.medusajs.com/learn/fundamentals/modules

Medusa workflows documentation: https://docs.medusajs.com/learn/fundamentals/workflows

OpenAPI Specification: https://spec.openapis.org/oas/latest.html

AsyncAPI Specification: https://www.asyncapi.com/docs/reference/specification/v3.0.0

Akeneo API documentation: https://api.akeneo.com/

commercetools Business Units API: https://docs.commercetools.com/api/projects/business-units

BigCommerce B2B ecommerce guide: https://www.bigcommerce.com/articles/b2b-ecommerce/

Medusa B2B ecommerce guide: https://gmi.software/blog/medusa-b2b-ecommerce-guide

Composable commerce and OMS: https://gmi.software/blog/composable-commerce-oms-fulfilment