How to Build a B2B E-Commerce Platform From Scratch in 2026

Most teams underestimate how different B2B ecommerce is from consumer commerce. The surface looks similar: products, a cart, checkout. Underneath, the requirements are completely different, and platforms built for B2C will fight you the entire way.

In B2C, every customer sees the same price. In B2B, a customer who buys 500 units per month negotiates a different price than one who buys 50. Your platform needs to store, apply, and display custom price lists, volume tiers, and contract-specific rates at the account level, not just the product level.

In B2C, anyone can check out immediately. In B2B, large orders often require internal approval. A purchasing manager may submit a $40,000 order that needs sign-off from a VP before it converts to a real purchase order. Your platform needs approval workflow logic, not just a checkout button.

In B2C, payment happens at checkout via card. In B2B, a long-standing customer with a $200K annual contract expects net 30 or net 60 payment terms and pays via ACH, wire, or check. Your platform needs to support credit lines, invoicing, and terms-based payment without forcing every buyer through Stripe's card-present flow.

These differences are not edge cases. They are core to how B2B purchasing works, and they affect your data model, your API design, and your frontend UX from day one. Plan for them before you write a line of code.

Your first major decision is whether to build on a headless commerce engine, use an all-in-one platform like Shopify Plus B2B, or build a fully custom solution. Each path has real tradeoffs, and the right choice depends on your timeline, team, and requirements complexity.

Shopify Plus B2B

Shopify Plus now has a dedicated B2B surface: company accounts, customer-specific price lists, draft orders, and basic payment terms. If your requirements are relatively straightforward and you want to move fast, Shopify Plus B2B is a legitimate starting point. The platform fee starts around $2,300/month, and you get a managed frontend, checkout, and payments out of the box. The ceiling is low: complex approval workflows, deep ERP sync, and highly custom pricing logic will push against Shopify's limitations quickly.

Medusa (Open Source Headless Commerce)

Medusa is the best open source headless commerce engine for B2B in 2026. It runs on Node.js, uses PostgreSQL, and exposes a complete REST and event-based API. Critically, it supports multi-region, custom pricing, and a plugin system that lets you extend the core without forking it. You pair Medusa with a Next.js storefront and own the full stack. Expect 3 to 4 months to a production-ready v1 with a small team. Medusa Cloud is available for managed infrastructure if you want to avoid running your own servers.

Saleor (Python/Django Headless Commerce)

Saleor is a mature headless commerce platform built on Django and GraphQL. It has strong B2B primitives including channels (separate storefronts with independent pricing), discount and voucher engines, and a well-designed permission system. If your team is Python-native or you prefer GraphQL over REST, Saleor is worth evaluating. Saleor Cloud handles hosting. Custom development in Saleor requires comfort with Django and the GraphQL schema, which has more friction than Medusa's REST-first approach.

Fully Custom (Node.js or Python API)

Building your own commerce engine from scratch is the right call when your requirements are genuinely unique: dynamic pricing that changes by real-time market data, complex manufacturing-to-order workflows, or a platform where commerce is deeply embedded in a proprietary process. Budget 6 to 12 months and a team of at least 3 engineers. Most teams that choose fully custom underestimate the surface area: tax handling, shipping rate logic, returns, refunds, and payment reconciliation alone can consume months.

Our recommendation for most teams: start with Medusa or Saleor, extend aggressively, and only move to fully custom if you have exhausted the platform's extension model. The headless approach gives you a custom storefront (built in Next.js) with a proven, maintained backend handling the hard commerce logic.

The B2B data model is fundamentally account-centric, not user-centric. In B2C, a user is the buyer. In B2B, an account (a company) is the buyer, and multiple users (contacts) within that company can place orders on the account's behalf with different permission levels.

The Account Hierarchy

Your core data model needs: an Account entity (the company), Contact entities linked to the account (the individual buyers), Role assignments (who can browse only, who can create orders, who can approve them), and Address Book entries at the account level (shipping locations, billing addresses, warehouse docks).

Large enterprise accounts often have subsidiaries or regional divisions that need separate credit lines, separate price lists, or separate approval hierarchies but should roll up to a parent account for reporting. Model this as a parent-child account relationship from day one. Retrofitting it later is painful.

Price Lists and Tier Pricing

The pricing engine is where most B2B builds get complicated. You need to support:

• Account-specific price lists: Acme Corp sees $18.50/unit for SKU-1234, while Beta Industries sees $21.00/unit for the same SKU based on their contract.
• Volume tier pricing: 1-99 units at $21.00, 100-499 units at $19.50, 500+ units at $17.00. Tiers can be per-order or cumulative over a period.
• Category-level discounts: A 10% discount applied to all products in the "Industrial Fasteners" category for a specific account.
• Promotional pricing: Time-limited prices that override contract rates or layer on top of them as additional discounts.

In Medusa, price lists handle most of this. You define a price list, assign it to a customer group or specific customers, and set product-level prices within it. Volume pricing requires a custom plugin or price selection strategy. In a fully custom build, the price resolution function needs to evaluate all applicable price lists in priority order and return the lowest valid price for the buyer's context.

Product Catalog with Account Visibility

Not every product should be visible to every account. A manufacturer may offer certain SKUs only to distributors who have signed specific agreements, while a restricted product line is only visible after a buyer has been credentialed. Build catalog visibility rules into your permission system at the account level, not just as product status flags.

The quote-to-order workflow is one of the most important differentiators in B2B ecommerce, and most commerce platforms have weak or no support for it. A buyer browses, adds items, but instead of checking out immediately, they submit a quote request. Your sales team reviews it, adjusts pricing, adds line items, and sends back a formal quote. The buyer approves it and it converts to a confirmed order.

Building the Quote Flow

Implement quotes as a separate entity from orders. A quote has: a buyer contact, an account, a list of line items with proposed prices, a status (draft, submitted, under review, approved, rejected, expired), an expiration date, and a thread for back-and-forth comments. When a quote is approved, it triggers order creation with the agreed-upon prices locked in.

The storefront UX needs a "Request Quote" button alongside or instead of "Add to Cart" for products that require it. Buyers should see a quote dashboard showing all open, pending, and historical quotes with status indicators. Your admin panel needs a quote management interface where your sales team can view incoming requests, edit line items, apply negotiated discounts, add internal notes, and send the quote back to the buyer.

Internal Approval Workflows

On the buyer side, large enterprises need internal approval before a purchase order is issued. A purchasing agent creates an order, but orders above $10,000 require a manager to approve before they are released. Your platform needs to model approval rules at the account level: approval thresholds, approver assignments, escalation paths when an approver is unavailable, and notifications at each stage.

Build this as a state machine. An order is in one of: draft, pending approval, approved, rejected, or cancelled. Transitions between states fire events. Those events send email or webhook notifications to the relevant parties. The admin panel shows the state of every order in the approval pipeline so your team can follow up when orders are stalled.

For complex approval chains, a rules engine (even a simple one you build yourself with a conditions array stored in JSON) is more maintainable than hardcoded logic. Store the rule as: "if order total exceeds $X and account tier is Y, require approval from role Z." Evaluate rules at order submission time and assign approvers dynamically.

A B2B ecommerce platform that does not talk to your ERP is a toy. The moment a buyer places an order, your inventory must decrease, your accounting system must create an invoice, and your fulfillment team must receive a pick-list. Doing this manually at any meaningful order volume is unsustainable.

Common ERP Integrations

The ERP landscape for mid-market B2B companies is dominated by: NetSuite (most common for growing companies, has a REST API and SuiteScript for custom logic), SAP Business One or SAP S/4HANA (larger enterprises, complex API surface, often requires an iPaaS layer), Microsoft Dynamics 365 (common in enterprise, REST API via Dataverse), and QuickBooks Enterprise or Xero (SMB-tier, simpler integration). Your commerce platform needs to push orders to the ERP and pull inventory levels, customer data, and invoice status back.

Integration Architecture

Do not build direct point-to-point API calls between your commerce platform and the ERP if you can avoid it. The ERP will have rate limits, maintenance windows, and API changes. Instead, use an event-driven architecture: when an order is placed in your commerce platform, emit an event to a message queue (AWS SQS, Google Pub/Sub, or RabbitMQ). A separate integration service consumes the event, transforms the order data to the ERP's format, and pushes it. If the ERP is unavailable, the message stays in the queue and retries. This decoupling makes your commerce platform resilient to ERP outages and makes the integration easier to debug.

For inventory, run a scheduled sync job that pulls current stock levels from the ERP every 15 to 30 minutes and updates your commerce platform's inventory records. For real-time inventory accuracy on high-velocity SKUs, consider a webhook-based push from the ERP when stock changes. Most ERPs support outbound webhooks or can be configured to call an external endpoint on record changes.

Multi-Warehouse Fulfillment

B2B orders often ship from multiple warehouses based on buyer location, stock availability, or product type. Your order management system needs to split an order into shipments, route each shipment to the correct warehouse, and track fulfillment status independently. When a buyer orders 300 units of a product and 200 are in your Chicago warehouse while 100 are in Los Angeles, you need logic to decide whether to split the shipment, wait for consolidation, or backorder the shortfall.

Build fulfillment routing as a configurable rule: route to the warehouse closest to the buyer's shipping address if stock is available, fall back to the secondary warehouse, and flag the order for manual review if stock is insufficient. Expose the routing configuration in your admin panel so your ops team can adjust it without a code deploy.

Payments in B2B ecommerce are dramatically more complex than consumer checkout. You need to support net payment terms (net 30, net 60, net 90), credit lines, purchase orders as a payment method, ACH transfers, and traditional card payments. Getting this wrong means your best customers cannot buy from you on the terms they expect.

Implementing Net Payment Terms

Net terms mean the buyer pays after delivery, within a specified number of days. A net 30 order placed on April 1 is due April 30. Your platform needs to: record the payment terms at the order level (inherited from the account's configured terms), generate an invoice with the due date clearly stated, track whether the invoice has been paid, send payment reminders as the due date approaches, and flag overdue accounts.

Stripe does not natively support net terms for B2B, but Stripe Invoicing can generate and send invoices with net terms. You trigger an invoice via the Stripe API after order fulfillment, set the due date, and Stripe handles payment collection via a hosted invoice page. The buyer can pay by card or bank transfer. For buyers who pay by ACH or check outside of Stripe, you need a manual payment recording mechanism in your admin panel.

Credit Lines

Some accounts will have a credit line: a maximum outstanding balance they can carry before new orders are blocked. When a buyer submits an order, your platform checks their current outstanding balance against their credit limit. If the order would push them over the limit, you block checkout and notify their account manager. Implementing this requires pulling current invoice balances from your accounting system (or storing them in your commerce database and syncing from ERP) and evaluating the credit check at order submission time, not at shipping time.

For subscription billing implementation on recurring B2B orders (monthly supply contracts, maintenance agreements), integrate with Stripe Billing or build your own recurring order logic. Recurring orders in B2B often have different pricing than one-time orders and may have their own approval and net terms treatment.

Purchase Orders as a Payment Method

Many B2B buyers are required by their finance departments to attach a purchase order number to every transaction. The PO number references an internal approval record in the buyer's accounting system. Your checkout needs a field for PO number entry, and that PO number should appear on every invoice and packing slip. This is a non-negotiable for selling to enterprise and government accounts.

B2B ecommerce exists on a spectrum. On one end, a fully self-service buyer portal where accounts log in, browse catalog, check their contract pricing, and place orders without talking to anyone. On the other end, a sales-assisted model where your reps create draft orders, apply negotiated pricing, and send them to buyers for approval. Most platforms need to support both simultaneously.

Designing for Self-Service

Self-service works well for repeat orders, standard catalog products, and buyers who already know what they want. The UX must show the buyer their specific prices (not list prices), their current credit availability, their order history with reorder buttons, and their saved addresses. Make reordering effortless: a "reorder" button on any past order that pre-fills the cart with the same items. Show real-time inventory so buyers are not surprised by backorders after submitting.

Self-service requires strong account setup UX. The first-time a new account logs in, guide them through setting up their shipping addresses, selecting their billing contact, and confirming their payment terms. A poorly designed onboarding for a new account results in support tickets and abandoned sessions.

Sales Rep Tools

Your admin panel needs a "shop as customer" feature that lets a sales rep log in, impersonate a specific account, and see exactly what that buyer sees including their price list. From there, the rep can build a draft order, apply a one-time discount, add a note ("pricing adjusted per call with Sarah on April 15"), and email the draft to the buyer for review. This is how your reps help buyers who call in or need assistance completing a complex order.

Sales rep dashboards should surface: accounts with no orders in the last 90 days (re-engagement opportunities), accounts approaching their credit limit, quotes that have been sitting in review for more than 5 days, and accounts whose contract is up for renewal. These signals turn your ecommerce platform into a sales tool, not just a self-service portal. For teams building a more complex marketplace app development model where buyers and sellers are separate entities, the account permission and rep tooling concepts apply directly.

Hybrid Workflows

Most successful B2B platforms support a hybrid model: new accounts or complex orders go through a sales-assisted flow while established accounts with standard orders self-serve. Implement this by configuring at the account level whether checkout requires a rep to finalize the order or whether the buyer can complete checkout independently. New accounts default to sales-assisted until they have been onboarded. As their ordering patterns become predictable, flip them to self-service. This gives you control over the experience for accounts that need more hand-holding without blocking your efficient, self-sufficient buyers.

Given everything above, here is the concrete tech stack and build order we recommend for a B2B ecommerce platform in 2026.

Recommended Stack

• Commerce Engine: Medusa v2 (Node.js, PostgreSQL) for most teams. Saleor if your team is Python-native and you prefer GraphQL.
• Frontend: Next.js 15 (App Router) with Tailwind CSS. Use Medusa's Next.js starter as a base and customize aggressively.
• Database: PostgreSQL (via Medusa's managed schema) with Redis (Upstash or Redis Cloud) for session caching and rate limiting.
• Payments: Stripe for card and ACH payments, Stripe Invoicing for net terms. Add a manual payment recording flow for checks and wire transfers.
• ERP Integration: Event-driven via AWS SQS or Google Pub/Sub. Build a dedicated integration service, not inline API calls.
• Search: Algolia or Typesense for product search with account-specific pricing in the index. Do not rely on database full-text search at scale.
• Email: Resend or Postmark for transactional emails (order confirmations, invoice reminders, quote notifications).
• Hosting: Vercel for the Next.js frontend. Railway or AWS ECS for the Medusa backend. Cloudflare for CDN and DDoS protection.

Build Order

Phase 1 (Months 1 to 3): Account management (company accounts, contacts, roles), product catalog with account-specific pricing, basic order flow with net terms and PO number support, Stripe payment integration, and ERP order sync. This gets you to a functional platform that your first accounts can actually use.

Phase 2 (Months 4 to 5): Quote-to-order workflow, internal approval chains, multi-warehouse fulfillment routing, credit line management, and the sales rep admin tools. This unlocks complex enterprise buying scenarios.

Phase 3 (Month 6+): Advanced analytics (account health scoring, reorder prediction), self-service account onboarding, bulk order import (CSV upload for large orders), and API access for buyer ERP-to-ERP integrations. This is where the platform starts becoming a competitive advantage rather than just a functional tool.

Timeline and Cost Expectations

A Phase 1 build on Medusa with a team of 2 senior engineers takes 10 to 14 weeks. Budget $60,000 to $120,000 for an agency build or plan for 3 to 4 months of dedicated engineering capacity if building in-house. Phase 2 adds 6 to 8 weeks. Do not try to compress these timelines by cutting the ERP integration or the approval workflow. Those are the features your buyers will ask about on the first sales call.

We build B2B commerce platforms that handle complex pricing and high-volume orders. Book a free strategy call to scope your platform.