Most ecommerce platforms were built for B2C. A consumer browses products, adds items to a cart, enters a credit card, and checks out. The architecture is optimized for this: single buyer, single payment method, simple pricing, immediate fulfillment. When teams try to use this same architecture for B2B ecommerce, they run into walls almost immediately.
B2B ecommerce is not B2C with bigger order values. The buying process, the pricing model, the payment terms, the user hierarchy, and the fulfillment expectations are fundamentally different. In our experience building ecommerce platforms for both models, the architectural differences are significant enough that retrofitting a B2C system for B2B use is often more expensive than building purpose built B2B functionality from the start.
This post breaks down where B2B and B2C architectures diverge, why those differences matter, and how to make the right design decisions if you are building for business buyers.
Pricing Is Not Simple
In B2C, a product has a price. Maybe it has a sale price. Perhaps there are quantity discounts or a coupon code. That is the extent of pricing complexity for most consumer stores.
In B2B, pricing is a negotiation layer. The same product might have a different price for every customer. Contract pricing locks in rates for a specific account over a defined period. Tiered volume pricing adjusts the unit cost based on total quantity ordered, often across an entire account's history, not just the current order. Customer specific catalogs restrict which products a buyer can even see, let alone purchase.
Architecturally, this means your pricing engine cannot be a simple lookup. It needs to resolve prices through a chain: check for a customer specific negotiated price, then check for a contract price, then check for a segment tier price, then fall back to the list price. Every step in that chain has effective dates, quantity thresholds, and override logic.
Your product catalog also needs to support price visibility rules. Some B2B stores do not show prices at all until the buyer is authenticated and their account is approved. Others show list prices but only reveal the buyer's actual price after login. This "request a quote" pattern is uncommon in B2C but standard in B2B, and it affects your product pages, search results, and API design all the way through.
Accounts Are Hierarchical
A B2C customer is an individual. They have one account, one set of preferences, and one payment method. The person browsing is the person buying is the person paying.
A B2B customer is an organization, and organizations have structure. A company account might have a purchasing manager who can place orders, an approver who must authorize orders above a certain amount, a finance contact who receives invoices, and a receiving contact at the warehouse who needs shipping notifications. Some companies have multiple divisions, each with their own budget, their own shipping addresses, and their own product access.
Your user model needs multi user accounts with role based permissions. A buyer can add items to a cart but cannot submit an order over $5,000 without approval. An approver can authorize orders but cannot change payment terms. An admin can manage users within their organization but cannot see another organization's data. We covered these patterns in our user roles and permissions guide, and B2B ecommerce is one of the most demanding use cases.
The checkout flow changes accordingly. Instead of a linear flow (cart, shipping, payment, confirm), B2B checkout often includes an approval step. A buyer submits an order for review, approvers are notified, they approve or reject, and only then does the order proceed to fulfillment. This approval workflow has its own escalation rules, delegation paths, and audit trails.
Payment Terms Replace Credit Cards
In B2C, payment is immediate. The customer pays at checkout with a credit card, debit card, or digital wallet. The merchant receives the funds (minus processing fees) within days.
In B2B, payment terms are the norm. Net 30, net 60, and net 90 are standard. The buyer places an order, receives the goods, and pays the invoice weeks or months later. This fundamentally changes your payment architecture.
Your system needs to support invoicing as a first class payment method. When a B2B buyer checks out with "Net 30" terms, no payment is collected at checkout. Instead, the system generates an invoice, sends it to the buyer's finance contact, and tracks the payment status over time. Your order management system needs to handle the disconnect between order fulfillment and payment collection.
Credit limits add another layer. A buyer with a $50,000 credit limit and $35,000 in outstanding invoices can only place new orders up to $15,000. Your checkout flow needs to check available credit in real time and either block the order or route it to credit approval.
Purchase orders are part of many B2B buying processes. The buyer has an internal PO number that must appear on the order and invoice. Missing PO numbers delay payment because accounts payable cannot match the invoice to their internal authorization.
None of this exists in a standard B2C platform. Building it on top of one means adding invoice generation, payment tracking, credit management, and PO support to a system designed around immediate card payment.
Ordering Patterns Are Different
B2C customers browse, discover, and impulse buy. The shopping experience is designed to encourage exploration. B2B buyers already know what they need. They want to reorder efficiently.
Quick order forms let buyers enter SKUs and quantities directly, bypassing the browse experience entirely. A restaurant supply buyer reordering 47 items does not want to search for each one. They want a spreadsheet style input where they paste SKUs and quantities and add everything to cart at once.
Saved order templates let buyers store frequently ordered combinations and reorder with a single click. A buyer who orders the same 30 items every two weeks should not rebuild that cart from scratch each time.
Bulk CSV uploads let buyers upload order files from their procurement systems. Your system needs to parse the file, validate SKUs against the buyer's catalog and pricing, report errors, and create the order.
These patterns mean your cart and ordering APIs need to handle operations that B2C systems never encounter: adding 200 line items in a single request, applying 200 different negotiated prices, validating availability across 200 SKUs. A B2C cart API that processes one item at a time will be painfully slow for B2B use cases.
Fulfillment Expectations
B2C fulfillment is typically straightforward: pick, pack, ship to the customer's address. B2B fulfillment introduces additional complexity.
Scheduled delivery windows. A business receiving a pallet of supplies needs to know exactly when it arrives so staff can be at the loading dock. Delivery is not "3 to 5 business days." It is "Tuesday between 8 AM and 12 PM."
Partial shipments and backorders. B2B buyers often accept partial fulfillment with the remainder backordered. Your order management system needs item level fulfillment tracking and separate invoices per shipment.
Drop shipping and multi warehouse routing. B2B orders might ship directly from a manufacturer, from regional warehouses, or a combination. Your fulfillment engine needs routing logic that considers inventory location, shipping cost, and delivery requirements.
Custom packaging and labeling. Some B2B buyers require specific labeling, barcoding, or packaging to match their receiving processes. Most B2C platforms do not accommodate this.
The Build Decision
If your business serves B2B buyers, the platform decision is consequential. Off the shelf B2C platforms like Shopify can handle simple B2B scenarios with apps and customizations, but the more of the above requirements you have, the more you are fighting the platform rather than building on it. We have seen teams spend 18 months customizing a B2C platform for B2B only to realize they have built a fragile layer of workarounds on top of a foundation that was never designed for their use case.
Purpose built B2B platforms (like Saleor, Medusa, or custom builds) offer more flexibility but require more upfront investment. In our experience, the break even point is clear. If you need contract pricing, approval workflows, and invoice based payment, you need B2B native architecture. Trying to bolt these onto a B2C system creates technical debt that compounds with every new requirement.
On the system architecture side, B2B ecommerce systems benefit from modular design: a pricing module, an accounts and permissions module, an ordering module, and a fulfillment module, each with clean interfaces between them. This lets you evolve each piece independently as your business requirements change. If you are weighing the tradeoffs of custom ecommerce versus an existing platform for B2B, the answer depends almost entirely on how many of the requirements above apply to your business.
If you are building a B2B ecommerce platform and want architecture that supports your actual buying process rather than fighting it, talk to us and we will help you design the right system.