B2B ecommerce platform: the seven things a consumer store cannot do

Most B2B ecommerce projects start the same way: the business already sells to consumers, or the team already knows a consumer platform, and the plan is to add a trade login and a wholesale price list.

It works for about six months, and then it stops, because B2B is not a consumer store with permissions on top. Three things are structurally different:

The buyer is an organisation, not a person. Several people, with different rights.
The price is negotiated, not published. There is no single price for a product.
The order is a step in a procurement process, not the end of a shopping session.

Everything below follows from those three. This is what a B2B platform actually has to do, why the common workarounds fail, and where building your own is genuinely the right call.

The floor: what online stores actually ship

We counted what online stores ship across 90 core sources — platform documentation, open-source ecommerce starters, live marketplace scripts and demo admin audits. Ranked by how many of the 90 evidence each capability:

Capability	Sources	Share
Product variants and options	49	54%
Customer accounts	48	53%
Order management	47	52%
Checkout and order creation	44	49%
Payment gateway integration	42	47%
Search, filter and sort	42	47%
Shipping and fulfilment	40	44%
Inventory tracking	39	43%
Reviews and ratings	35	39%

That is the consumer-shaped floor, and every mainstream platform clears it. Read the list again with a trade customer in mind and notice what is not there: no price lists, no quotes, no purchase orders, no approval chains, no account-scoped catalogue. None of it is missing by accident — those things do not exist in a consumer store, which is why bolting them on is the whole problem.

The seven things B2B needs

1 · Customer-specific pricing

The defining requirement. In B2B a product does not have a price. It has a list price, a price for each customer tier, contract prices negotiated with individual accounts, and volume breaks within each of those.

The correct model is a price resolution: given this product, this customer, this quantity and today's date, what is the price? Contract prices have start and end dates, and a contract that expired last week must stop applying without anybody remembering.

The consumer workaround is customer groups plus discount percentages, and it fails on the first account that has negotiated a flat price on three specific lines rather than a percentage off everything.

2 · Quotes

A significant share of B2B orders start as a request rather than a purchase. The buyer asks for a price on a basket, somebody prices it, the buyer counters, and the agreed quote becomes an order without being retyped.

That means a quote is a real object with a state — requested, priced, sent, accepted, expired — and an expiry date that matters, because materials prices move. A "request a quote" form that emails your sales inbox is not this; it is a contact form, and the re-keying is where the errors come from.

3 · Purchase orders and payment terms

Trade customers do not pay by card at checkout. They order against a purchase order number, on agreed terms, and pay on invoice.

What the system needs: a PO number captured at order time and carried onto the invoice, credit limits per account, a check against the limit before the order is accepted, and an account status that can put a customer on hold. Card payment should still exist for the accounts that want it — but it is one option among several rather than the mechanism the checkout is built around.

This is the requirement most likely to be hand-waved in a demo. Ask to see an order placed with no payment taken at all.

4 · Several buyers per account, with approval

An account is an organisation. Within it there may be a requisitioner who assembles the order, a manager who approves it above a threshold, an accounts-payable contact who never places orders but receives every invoice, and a head-office administrator who can see every site's orders.

That is a permission model inside the customer, which consumer platforms have no concept of at all — their model is one login, one person, one order history.

5 · Order quantities that are not one

Pack sizes, case quantities, minimum order values, order multiples, and units of measure that differ between how you buy and how you sell. A consumer store lets you put 7 of anything in a basket. A trade store frequently must not.

Small, boring, and it generates a constant stream of manual corrections when it is missing.

6 · Account-scoped catalogue

Not every customer may see or buy every product. Exclusive lines, regional restrictions, products only sold under contract, and — commonly — the entire catalogue hidden until sign-in, because published trade prices are a competitive problem.

The implementation rule is the one that catches everybody out: catalogue restriction has to be applied where the data is served. A storefront that fetches all products and filters them in the browser has published your price list to anyone who looks at what the server sent.

We saw exactly this failure class in our own audits. One storefront build had a customer list — names, emails, addresses and order history — readable by catalogue and warehouse staff, directly contradicting the build's own permissions table. The table was right; the implementation had not followed it.

7 · Reordering

B2B buying is repetitive. The same customer orders substantially the same basket every month. Saved lists, reorder-from-history, and CSV or scanner upload for large orders are not conveniences here — they are the difference between the portal being used and the buyer emailing the order in, which is what they will do otherwise.

Why the consumer-platform workarounds fail

Every business that tries this arrives at the same three, and they all work for a while.

Customer groups plus discount codes. Handles percentage-off tiers and nothing else. It breaks on flat negotiated prices, on per-line contracts, and on volume breaks. It also puts your pricing logic in two places, so nobody can answer "what does this customer pay for this product" without checking both.

A price list in a spreadsheet, applied by hand. Extremely common, and it is the one that costs real money: quotes go out at stale prices, and expired contract rates keep being honoured because the spreadsheet was never updated. There is no audit trail of who changed a price, which becomes uncomfortable when a customer disputes an invoice.

Worth noting that this failure is not hypothetical for built systems either. In one storefront we audited, catalogue staff could change prices by importing a spreadsheet — the permission was correctly enforced on the price field in the interface and not on the import path. The strongest build in that set locked price changes to the owner in three separate places, including import, precisely because import is the door people forget.

A "call us for trade pricing" button. An honest admission rather than a solution. It works if your trade volume is low, and it caps you at whatever your sales team can process by phone.

The question that actually kills B2B ecommerce projects

Everything above is a software problem. This one is not, and it sinks more of these projects than any technical decision.

What happens to the sales rep whose customer starts ordering online?

If the rep is paid commission on the accounts they manage, and the portal takes those orders without them, you have just asked your sales team to help build the thing that reduces their pay. They will not say that out loud. What happens instead is quieter: accounts do not get onboarded, the portal is never mentioned on a call, and adoption stalls at fifteen percent while everyone blames the software.

The organisations that get this right decide it before launch, and it has direct software consequences:

Commission follows the account, not the channel. The rep is credited for orders their accounts place, however they place them. This is a reporting requirement, and it needs the order to carry the account's owner at the time of the order rather than the current one.
Assisted ordering. The rep can place or edit an order on behalf of a customer, from the customer's own catalogue and prices. This is a genuinely useful feature — reps stop rekeying orders from emails — and it is a permission model: acting as a customer, with an audit trail that says who really did it.
The rep's job changes rather than shrinks. Repeat orders move online; the rep spends time on new lines, larger accounts and problems. That is a better job, and it is worth saying explicitly to the people affected.

The software requirement that comes out of this is small and specific: an order records both the buyer and the actor. If a rep placed it on the customer's behalf, both facts are on the record. Without that, you cannot pay commission correctly, and you cannot answer a dispute about who ordered what.

Ask any vendor to demonstrate assisted ordering. It is a good proxy for whether the product was built by people who have sold to distributors.

The four routes

Consumer platform plus a B2B app or extension. The cheapest start, and genuinely fine for simple trade pricing on top of a consumer business. Interrogate how the extension resolves price — if it computes at display time rather than at order creation, you will eventually ship an order at a price the customer never saw.

A dedicated B2B platform. Right when trade is the business. Built by people who have met purchase orders before. It costs meaningfully more and takes real setup, and the pricing model is usually a percentage of turnover, which is worth modelling before you commit.

ERP-led. If the ERP already holds the price lists, the contracts and the credit limits — which it often does — the store can be a front end to it rather than a second source of truth. This is frequently the right answer for established distributors and it is under-considered, because the ERP vendor's web module is rarely anybody's favourite product.

Build it. Genuinely reasonable here, more so than in consumer ecommerce, and the reasoning is specific: your pricing rules and your approval chains are yours. Nobody else's product models them exactly, so you are choosing between configuring around a mismatch forever or building the thing that fits.

If you build one

Three storefronts were built from a single specification by three coding models, taken to full scope. All three take a real order end to end. What the audits found is what to specify.

The correctness properties the strongest builds had, and which you should write down explicitly:

Returning to a paid checkout page never charges twice. A repeated confirmation must be recognised and ignored, not processed.
Two buyers cannot both take the last unit. Stock is rechecked at order creation, as a database guarantee rather than a check in application code.
Stock only leaves the shelf once payment actually succeeds — or, in a B2B context, once the order is accepted against terms.
Price authority is enforced everywhere prices can enter, including spreadsheet import.
Accepting a return does not quietly restock or refund by itself. Those are separate decisions.
Unpaid orders on terms are not counted as money received. Obvious, and one of the three builds needed it stated.

And for B2B specifically, on top:

Price resolution is a single function — product, customer, quantity, date — used by the storefront, the quote, the order and the invoice. One place, or they will disagree.
Catalogue and price visibility enforced server-side. Never filtered in the browser.
Quote as a first-class object with states and an expiry.
Credit limit checked at order acceptance, with account hold.
Users within an account, with an approval threshold.
Order quantity rules — multiples, minimums, pack sizes — enforced at the line.

What none of that requires is a payment gateway on day one, which is worth saying because it is the piece people assume is essential. A B2B store where every order goes out on terms and an invoice follows is a complete product.

The evaluation checklist

Show me two customers seeing different prices for the same product, and tell me where that price is resolved.
Set a contract price with an end date. Move the clock past it.
Place an order with no payment, against a PO number, on 30-day terms.
Exceed a credit limit.
Have a requisitioner place an order above their approval threshold.
Sign out and read what the server sends for a product page. Are trade prices in it?
Turn a quote into an order without retyping anything.
Reorder last month's basket in under a minute.
Import a spreadsheet as a user who should not be able to change prices.

Check six and check nine are the two that catch built systems, and both are about the same mistake: enforcing a rule where the user can see it rather than where the data is served.

If you are choosing a platform more generally, choosing an ecommerce platform covers the six different businesses that all call themselves online stores and what each one actually needs. If search traffic is the priority, best ecommerce platform for SEO covers that axis, and if stock is the harder half of your problem, what a retail inventory management system includes is the counted inventory for it.

And if you are building, the Online Store planner is the specification we hand our own agents — the store shape locked before anything else, and the checkout, stock and price-authority rules written in so an agent has to build them rather than produce a catalogue and a cart.