B2B Commerce Platform Architecture: How the Pieces Fit Together
How to architect a B2B commerce platform: storefront, accounts, catalogs, pricing, quotes, approvals, ERP, CRM, OMS, payments, search, APIs, identity and channels.
Quick answer
A B2B commerce platform combines buyer-facing channels (storefront and portal, rep portal, punchout, APIs and EDI) with commerce services for accounts, catalogs, pricing, quotes, approvals and orders, back-office systems (ERP, CRM, OMS or WMS, payments and credit) and shared services (identity, search, events, monitoring). Resolve entitlements (who can see and buy what, at which price) in one place, give each data type one owner, connect systems by APIs and events, and choose platform and custom components by fit rather than defaulting to one vendor.
Where This Fits
The B2B build guide is B2B ecommerce development. Deep dives: accounts, customer catalogs, approvals, rep portals and punchout. Integration guides include ERP, CRM and APIs.
The Architecture at a Glance
Channels
| Channel | Users | Key requirements |
|---|---|---|
| Buyer storefront and portal | Customer buyers, approvers, finance | Entitlements, quick order, approvals, invoices |
| Sales rep portal | Supplier reps | Act on behalf, quotes, CRM context |
| Punchout | Procurement-system buyers | cXML or OCI, cart return, PO intake |
| EDI and APIs | Large customers' systems | Orders, acknowledgements, ship notices, invoices |
| Customer service tools | Supplier staff | Order lookup, changes, returns |
Commerce Services
These services hold B2B logic: accounts and roles, catalogs and entitlements, pricing (contract, tiered, volume), quotes, approvals, carts and orders. They may come from the commerce platform's B2B features, custom services, or both. The essential rule is that every channel calls the same services.
Back-Office Systems
| System | Typical ownership |
|---|---|
| ERP | Item master, customer terms and credit, inventory, orders after submission, invoices |
| CRM | Accounts and contacts, opportunities, activities |
| OMS / WMS | Fulfilment, shipments, returns |
| PIM | Product content and technical attributes |
| Payments and credit | Card payments, invoices, credit checks |
Identity
B2B identity has three groups: customer users (within organizations, with roles), supplier staff (service, reps, admins) and system clients (punchout, EDI, APIs). Support SSO for large customers, strong authentication for administrators, audited access for staff acting on customer accounts and scoped credentials for integrations.
Planning or replacing a B2B commerce platform?
ZSpace can map your channels, systems of record and B2B rules and recommend an architecture, without a default platform answer.
Search
B2B search must handle part numbers, cross-references and technical attributes, and must respect entitlements and show customer prices. Either index per catalog or filter by entitlement at query time, and fetch customer prices at render. See B2B search.
APIs and Events
Expose commerce services through APIs for channels and customer integrations, and publish events (order submitted, quote accepted, invoice issued) for back-office systems. Use queues for reliability, version APIs used by customers and partners, and monitor every integration. See event-driven architecture and microservices architecture.
Platform Options
| Approach | Suits | Trade-offs |
|---|---|---|
| SaaS commerce platform with B2B features | Standard B2B needs, smaller teams | Fast; limits on complex pricing or workflows |
| B2B-focused commerce suite | Complex catalogs, pricing and channels | Licence and implementation cost |
| Headless platform plus custom services | Unique workflows, many channels | Engineering and operating responsibility |
| ERP-native web store | ERP-centric businesses with simple needs | Limited buyer experience |
Phasing
| Phase | Focus |
|---|---|
| 1 | Accounts, catalogs, pricing and storefront for a pilot customer group |
| 2 | Quick order, reordering, approvals and invoices |
| 3 | Rep portal and CRM integration |
| 4 | Punchout and EDI for procurement-led customers |
| 5 | Optimization, analytics and further channels |
Worked Example
An illustrative scenario, not a client case: a manufacturer runs a B2B storefront, a separate quoting tool for reps and EDI for large customers, each with its own price calculations. Customers receive different prices depending on how they order. The team centralizes pricing and entitlements in one service that all three channels call, keeps the ERP as owner of contract terms, and publishes order events to the ERP and CRM. Price discrepancies between channels disappear.
Decision Framework
- How complex are pricing and entitlements?
- Which channels must be supported in the next two years?
- What does the ERP own, and how good are its APIs?
- What engineering capacity exists to run custom services?
- Which platform B2B features fit without customization?
- What is the cost of getting pricing wrong?
Common Mistakes
- Separate pricing logic per channel
- Choosing a platform before mapping customer workflows
- ERP ownership unclear
- Search that ignores entitlements
- Unversioned APIs used by customers
- Launching every channel at once
Ready to architect your B2B platform?
Talk to ZSpace about B2B platform engineering, Shopify B2B and ERP and workflow automation.
Conclusion
B2B platform architecture works when every channel shares the same commerce services and entitlements, systems of record are clear, integrations are event-driven and monitored, and delivery is phased. Related: event-driven architecture, microservices architecture and punchout.
Common questions
The design of the systems and integrations behind B2B online selling: buyer-facing channels, commerce services for accounts, catalogs, pricing, quotes, approvals and orders, back-office systems such as ERP and CRM, and shared services such as identity, search and events.