B2B Ecommerce: Price Belongs To The Relationship

B2B ecommerce gets sold as retail with bigger orders. It is not. Almost every difference comes from one fact: in B2B the price is not a property of the product, it is a property of the relationship.

Once you accept that, most of the confusing requirements stop being a list of features and start being consequences of the same thing.

Price belongs to the relationship

In retail, a product costs what it costs. In B2B, this account pays one number, that account pays another, a third has a contract fixing their price until March, and a fourth gets a break at fifty units that does not apply below that.

None of that fits a price field on a product. It needs price to be resolved at the moment somebody asks, from who is asking, what they are buying, how many, and what has been agreed with them.

Which produces the requirement people always mention first and rarely explain: a logged-out visitor cannot be shown a price, because there is no price until the system knows who they are. That is not a permissions setting bolted onto a retail store. It is the data model.

The buyer is an organisation, not a person

A retail customer is one account with one address and one card. A business customer is a company with several people, who do not have equal authority.

An assistant builds a basket and cannot approve it. A manager approves up to a limit. Somebody in finance sees invoices and never touches the catalog. Three warehouses have three shipping addresses and one billing address.

So accounts are hierarchical, roles are real, and an approval step sits between the cart and the order. A store that models the buyer as an individual cannot express any of this, and the workaround is shared logins, which is how a business ends up unable to tell who ordered what.

Payment is credit, not a card

The retail flow assumes payment then dispatch. B2B frequently inverts it: goods go out, an invoice follows, payment arrives thirty or sixty days later against agreed terms.

That means a credit limit the system enforces, an order that can proceed unpaid, and a purchase order number that has to travel from the cart through the invoice into the accounting system, because the customer's finance department will not pay an invoice they cannot match to a PO.

Cards still show up, usually for smaller accounts. Both paths have to exist.

Reordering is the real usage pattern

Retail is browsing. B2B is mostly buying the same things again.

Which makes the important features unglamorous: order history you can reorder from in one action, saved lists, upload a spreadsheet or paste a list of SKUs and quantities, and a fast path for someone who knows exactly what they want and does not need to be sold to.

Product discovery matters much less than most B2B storefronts assume. Nobody is browsing your catalog for inspiration on a Tuesday afternoon.

The catalog is different per customer

Not just the prices. Some accounts should not see some products: regional exclusivity, a contract, a line you only sell to certain partners, or a product not approved for their market.

So the catalog is filtered by who is asking, at the same time and for the same reason the price is.

Two more that reliably get missed

The tax situation is not retail's. Resale certificates and exemptions mean some customers are correctly charged no tax, and the exemption has to be recorded and applied automatically rather than handled by somebody remembering.

The ERP is the source of truth. In most established B2B businesses, the pricing agreements and stock already live in an ERP that predates the website. The store is a channel onto that data, not a second copy of it. Which makes the integration the project, and the storefront the easy part.

What this rules out

A retail platform with a wholesale app usually gets you customer groups and hidden prices, and stops before approvals, credit terms and per-account catalogs. That is fine if your B2B is a discount tier for regular buyers. It falls over the moment two accounts have genuinely different agreements.

The structural question is whether price and catalog are resolved per request from the customer's context, or looked up on the product. Everything above follows from which one it is.

Where we fit, and where we do not

dashfordevs is a backend behind an API, which suits the part of B2B that hurts most: the storefront is yours, so a portal that behaves like a procurement tool rather than a shop is something you build rather than something you fight a theme for. Pricing and catalog resolve server-side per request, and orders support the partial states that B2B fulfilment actually produces.

Where we are the wrong answer: if your ERP is the system of record and you need deep two-way integration with it, that integration is the project and you should choose based on who can build it. If you want a B2B portal out of the box without writing a front end, dedicated B2B platforms ship one and we do not. And if your B2B is really a wholesale price list for twenty regulars, a customer group on your existing store is the correct amount of technology.

The short version

Price and catalog resolve from the relationship. The buyer is an organisation with roles and approvals. Payment is credit with terms and a PO number. The main journey is reordering.

If those four describe your business, ask any platform how it does each one before looking at anything else. The docs show how pricing resolves per request on our side.