How to Build a B2B E-Commerce Wholesale Platform From Scratch

Most founders assume building a B2B wholesale platform means taking a Shopify store and adding quantity discounts. That assumption will cost you six months and a failed product. B2B commerce is fundamentally different from consumer e-commerce in ways that touch every layer of your stack, from the data model to the payment flow to the frontend UX.

In B2C, you have one price per product, one buyer per account, and a credit card at checkout. In B2B wholesale, a single product might have 200 different prices depending on the customer, their contract tier, their order volume, and whether they negotiated a special deal last quarter. A single company account might have 15 buyers, each with different spending limits and approval requirements. Payment might not happen for 60 days after the order ships.

These differences are not edge cases. They are the core business logic. If your platform cannot handle customer-specific pricing, multi-buyer company accounts, quote-to-order workflows, purchase order references, and net payment terms on day one, your wholesale buyers will stick with phone calls and spreadsheets.

The opportunity is massive. Wholesale e-commerce in North America alone exceeds $2 trillion annually, and less than 20% of it happens through digital self-service channels. Distributors, manufacturers, and wholesalers are actively looking for platforms that understand their workflows. The bar is high, but the reward for clearing it is a sticky customer base with high lifetime value and predictable reorder cycles.

Your architecture choice determines how much pain you experience when B2B requirements inevitably conflict with off-the-shelf assumptions. Monolithic platforms like Magento or BigCommerce B2B Edition give you a starting point, but they lock you into their data models. When a wholesale client needs a three-tier approval workflow that triggers different discount rules at each level, you will be fighting the platform instead of building the feature.

Why Headless Wins for B2B

A headless architecture separates your commerce backend (catalog, pricing, orders, inventory) from your frontend (the buyer portal). This separation is especially powerful for B2B because wholesale buyers interact with your platform differently than consumers. They need bulk order forms, CSV uploads, reorder-from-history flows, and quote negotiation interfaces that no pre-built theme supports well.

If you have explored headless commerce storefront development, the same principles apply here with added complexity in the backend layer.

Medusa.js for B2B Commerce

Medusa is our top recommendation for B2B wholesale backends. It is open-source, TypeScript-native, and built with an extensible module system. You can add custom pricing engines, approval workflows, and company account logic as first-class modules without forking the core. Medusa's customer group system provides the foundation for tiered wholesale pricing, and its draft order API maps cleanly to the quote-request workflow.

For teams with Python expertise, Saleor is a solid alternative. Its GraphQL API reduces over-fetching on complex catalog pages, and its warehouse management handles multi-location inventory well. However, Medusa's TypeScript stack means your frontend and backend teams speak the same language, which reduces context-switching costs on smaller teams.

Custom Next.js Buyer Portal

Your frontend is a Next.js application that serves as a wholesale buyer portal. Unlike a consumer storefront optimized for browsing and impulse purchases, a B2B portal optimizes for efficiency. Buyers know exactly what they want. They need to find it fast, set quantities across 50 SKUs, and submit the order in under three minutes. Server Components handle the heavy data fetching (price lists with thousands of custom prices), while client components manage the interactive order form state.

The portal also needs role-based views. A purchasing agent sees order forms and their spending limit. A procurement manager sees pending approvals and budget dashboards. An accounts payable user sees invoices and payment history. Each role gets a tailored experience powered by the same backend APIs.

The company account is the foundational data model that separates B2B from B2C. In consumer commerce, one person equals one account. In B2B, one company has many people, each with different permissions, budgets, and ordering capabilities.

Multi-Buyer Company Accounts

Your data model needs a Company entity that owns multiple User entities. Each user has a role within the company: admin, buyer, approver, or viewer. Company admins can invite new buyers, set spending limits, and manage shipping addresses. Buyers can create orders up to their limit. Approvers can approve or reject orders that exceed a buyer's threshold.

Here is how this plays out in practice. A regional restaurant chain has a corporate office and 40 locations. The corporate procurement team sets up the account, defines approved product lists for each location, and assigns location managers as buyers with a $5,000 weekly limit. Location managers log in, see only the products approved for their region, and place orders that route to corporate for approval if they exceed the budget. This is table-stakes functionality for enterprise wholesale buyers.

Approval Workflows

Approval workflows range from simple (any order over $10,000 needs manager sign-off) to complex (three-tier approval with different thresholds, plus mandatory finance review for new vendors). Build your workflow engine as a state machine. Each order transitions through states: draft, pending approval, approved, submitted, and fulfilled. Transition rules are configurable per company.

Notifications matter here. When an order needs approval, the approver gets an email and an in-app notification. If they do not act within 24 hours, escalate to their manager. These SLAs are configurable because different companies operate at different speeds.

Reorder Functionality

Wholesale buyers reorder the same products constantly. A coffee roaster orders the same 12 bag varieties every two weeks. A restaurant chain orders the same produce mix every Monday. Your platform needs one-click reorder from order history, saved order templates (named lists like "Monday Produce" or "Q4 Promo Stock"), and scheduled automatic reorders with approval bypass for recurring templates.

This reorder functionality is what makes your platform sticky. Once a buyer builds their templates and schedules, switching to a competitor means rebuilding all that configuration. It is the best kind of lock-in because it genuinely saves the buyer time.

Pricing is where most generic e-commerce platforms break down for B2B. Consumer pricing is simple: one product, one price, maybe a sale price. Wholesale pricing is a matrix of variables that can produce a different price for every single customer-product combination.

Customer-Specific Price Lists

Every wholesale customer gets a price list. This might be a percentage discount off the base price (Tier A gets 30% off, Tier B gets 20% off) or a completely custom price for every SKU. Large accounts negotiate item-level pricing. Your pricing engine needs to resolve the correct price by checking, in order: contract-specific price, customer-specific price list, volume tier price, customer group price, and finally the base wholesale price.

Store price lists as a separate entity linked to customer accounts. Do not bake pricing logic into the product catalog. A product has a base cost and a base wholesale price. Everything else is a price list override. This architecture lets you update one customer's pricing without touching the catalog and without triggering cache invalidation across your entire storefront.

Volume-Based and Tiered Discounts

Volume discounts come in two flavors. Quantity breaks apply per-line-item: buy 100 units at $5 each, buy 500 at $4.25, buy 1,000 at $3.80. Order-level tiers apply to the total: spend over $50,000 this quarter and unlock Platinum pricing on all future orders. Both need to work simultaneously, and the buyer needs to see exactly which tier they are hitting and how close they are to the next break.

Quote Request Workflow

Not every order has a fixed price. Large custom orders, new product inquiries, and special packaging requests all start as quote requests. The buyer submits a request with quantities and notes. Your sales team reviews it, adjusts pricing, adds any surcharges, and sends back a formal quote. The buyer approves it, and it converts into an order.

Build this as a first-class workflow, not an afterthought. The quote should have an expiration date, version history (so you can track negotiation back-and-forth), and one-click conversion to a purchase order. If you are building a marketplace-style platform with multiple suppliers, each supplier needs their own quoting interface.

Purchase Orders and Net Payment Terms

B2B buyers do not pay with credit cards at checkout. They reference a purchase order number, and you invoice them with net-30, net-60, or net-90 payment terms. Your platform needs to accept PO numbers at checkout, validate them against the buyer's credit limit, generate invoices on shipment, track payment status, and handle partial payments and credits.

Credit limits are critical. A new customer might start with a $10,000 credit limit. As they build payment history, you increase it. If they are 60 days overdue, the system should automatically block new orders until the balance is cleared. This logic protects your cash flow and reduces the need for manual credit checks.

Your wholesale platform does not exist in isolation. It sits between your buyers and your operational systems. Inventory lives in your ERP. Orders need to flow into your fulfillment system. Invoices need to sync with your accounting software. Getting this integration layer right is the difference between a useful platform and an expensive order-entry screen that creates double work for your operations team.

Real-Time Inventory Sync

Wholesale buyers order in bulk. If your platform shows 500 units available but your warehouse actually has 200 (because 300 were allocated to orders placed by phone), you have a serious problem. Inventory sync needs to be near-real-time, with updates flowing from ERP to platform within 60 seconds of any change.

For SAP Business One or SAP S/4HANA, use the SAP Business Technology Platform integration suite or build a custom middleware layer that polls the inventory API every 30 seconds and pushes changes via webhooks. For NetSuite, the SuiteTalk REST API provides inventory item endpoints, but be aware of governance limits. Batch your reads and use delta queries (items modified since last sync) to stay within rate limits.

QuickBooks Online has tighter API constraints. If your catalog exceeds 5,000 SKUs, consider a middleware platform like Celigo, Boomi, or a custom Node.js sync service that maintains a local cache and reconciles periodically.

Order Flow to Fulfillment

When a buyer places an order on your platform, that order needs to reach your warehouse management system (WMS) or ERP within minutes. The integration should push order details (line items, quantities, shipping address, delivery date requirements, special handling notes) and pull back status updates (picked, packed, shipped, tracking number).

Build this as an event-driven pipeline. Order placement triggers an event. A sync worker picks up the event, transforms the data into the target system's format, and pushes it. If the push fails, it retries with exponential backoff and alerts your ops team after three failures. Never silently drop orders. A dead-letter queue with manual retry capability is essential.

EDI Integration

Enterprise buyers often require EDI (Electronic Data Interchange) for order transmission. EDI 850 (purchase orders), EDI 855 (order acknowledgments), EDI 856 (advance ship notices), and EDI 810 (invoices) are the core transaction sets for wholesale. If your largest customers mandate EDI, you need an EDI translator that converts between your platform's JSON/REST format and the ANSI X12 EDI standard.

Services like SPS Commerce, TrueCommerce, and Orderful handle EDI translation as a service. You send them a JSON payload via API, and they transmit the EDI document to the buyer's VAN (Value Added Network). This is significantly cheaper than building EDI compliance in-house, which requires deep knowledge of segment terminators, element separators, and trading partner-specific variations.

B2B payment processing is nothing like consumer checkout. Forget Stripe's one-click card capture. Wholesale payments involve ACH bank transfers, wire transfers, paper checks (yes, still), and open credit terms with invoicing. Your payment architecture needs to support all of these simultaneously because different customers prefer different methods.

ACH and Wire Transfers

ACH (Automated Clearing House) is the most common B2B payment method in the US. It costs $0.20 to $1.50 per transaction versus 2.9% for credit cards. On a $50,000 order, that is the difference between $1 and $1,450 in processing fees. Your platform must support ACH.

Stripe offers ACH Direct Debit for pulling funds from a buyer's bank account, but settlement takes 4-5 business days. For faster settlement, consider dedicated B2B payment providers like Balance, Resolve, or Apruve. These platforms specialize in net terms, offering you immediate payment while they collect from the buyer on net-30 or net-60 terms. You get paid in 1-2 days; they take the credit risk.

Wire transfers are common for large international orders ($100K+). These are initiated by the buyer through their bank. Your platform generates a pro-forma invoice with your banking details, and the buyer wires the funds. You need a reconciliation process that matches incoming wire transfers to open invoices, which often requires manual review because wire reference numbers do not always match your invoice numbers cleanly.

Net Terms and Credit Management

Offering net-30 or net-60 payment terms means you are extending credit to your buyers. This requires a credit application process (collect business references, run a Dun and Bradstreet check, set an initial limit), ongoing credit monitoring (flag accounts approaching their limit or with aging receivables), automated dunning (send payment reminders at day 25, day 30, day 37, day 45), and collections escalation (restrict ordering, involve collections team, report to credit bureaus).

Build credit limits as a first-class attribute on company accounts. Every order submission checks the buyer's available credit (limit minus outstanding balance) before allowing the order to proceed. If the order exceeds available credit, route it to your credit team for manual review rather than blocking it outright. Many wholesale buyers have seasonal patterns where they temporarily exceed limits before paying down their balance.

Partial Payments and Credits

Wholesale orders frequently involve partial shipments, returns, and credits. A buyer orders 1,000 units. You ship 800 because 200 are backordered. You invoice for 800. The buyer receives them, finds 50 damaged, and requests a credit memo. Your system needs to handle partial invoicing, credit memos that reduce the outstanding balance, and backorder invoicing when the remaining 200 ship later. Each of these events needs to sync back to your accounting system automatically.

Do not try to build every feature at once. Wholesale platform development should follow a phased approach that gets core value to buyers quickly while building toward full feature parity with your offline ordering process.

Phase 1: Core Ordering (Months 1-3, $80K-$120K)

Launch with the minimum viable wholesale experience. Company accounts with basic roles (admin and buyer). Customer-specific price lists pulled from your ERP. A product catalog with search, filtering, and bulk add-to-cart. Simple checkout with PO number capture. Email notifications for order confirmation and shipping updates. Manual invoicing through your existing accounting system.

This phase proves the concept. Onboard your 10 most tech-forward customers and measure adoption. Are they placing orders through the platform or still calling your sales reps? The answer tells you what to prioritize next.

Phase 2: Automation and Self-Service (Months 4-6, $60K-$90K)

Add approval workflows so enterprise buyers can enforce their purchasing policies. Implement reorder-from-history and saved order templates. Build the real-time inventory sync with your ERP so buyers see accurate stock levels. Add automated invoicing triggered by shipment confirmation. Integrate ACH payments through Stripe or a B2B payment provider. Build a buyer dashboard showing order history, open invoices, and account balance.

Phase 2 is where the platform starts saving your sales team time. Orders that previously required a 15-minute phone call now happen in 3 minutes without human involvement on your side.

Phase 3: Advanced Features (Months 7-10, $70K-$100K)

Implement the quote-request workflow for custom and large orders. Add EDI integration for enterprise customers who require it. Build volume discount engines with real-time tier visualization. Add scheduled/recurring orders with approval bypass. Implement credit limit management with automated dunning. Build analytics dashboards showing customer purchasing patterns, reorder frequency, and revenue by account tier.

Total investment for a production-ready B2B wholesale platform: $210K to $310K over 10 months. This includes backend development, frontend buyer portal, ERP integration, payment processing, and QA. It does not include ongoing hosting ($2K-$5K/month), maintenance, or feature additions. Compare this to enterprise B2B platforms like Oro Commerce ($50K+ annual license) or SAP Commerce Cloud ($200K+ annual license plus implementation) where you also spend $150K-$500K on customization to match your workflows.

If you are building a custom e-commerce application for the first time, this phased approach lets you validate market fit before committing the full budget.

Technology Cost Breakdown

• Commerce backend (Medusa.js): Free, open-source. Hosting on AWS or Railway: $200-$800/month.
• Frontend (Next.js on Vercel): $20-$150/month depending on traffic.
• Database (PostgreSQL on RDS or PlanetScale): $50-$300/month.
• Search (Algolia or Meilisearch): $0-$500/month depending on catalog size.
• Payment processing (Stripe ACH + Balance for net terms): $0.80 per ACH + 1-3% of net-terms volume.
• ERP integration middleware (custom or Celigo): $500-$2,000/month.
• EDI translation (SPS Commerce): $500-$1,500/month per trading partner volume.

Ready to build a wholesale platform that your buyers will actually use instead of calling your sales team? Book a free strategy call and we will map your B2B requirements to a concrete technical plan and timeline.