B2B B2C hybrid commerce without breaking B2C flows

A consumer platform and a B2B chain customer disagree on nearly every assumption baked into a standard checkout. A consumer is one identity, pays immediately by card, sees a single public price, and signs up on their own. A chain customer is a structure of people buying under agreed terms, often pays by invoice after goods arrive, sees prices negotiated for their organization, and is set up by an administrator rather than a signup form. Hybrid commerce works only when the system treats those differences as first-class, rather than patching the consumer model with exceptions.

The contrast is easiest to see across the five areas where the two models diverge:

Each row looks like a configuration detail and behaves like an architectural decision. Modelled as flags on the consumer schema, these differences leak into every query and template; modelled as their own entities, they leave the consumer flow untouched while the B2B flow gets the structure it needs.

A chain customer is rarely one buyer; it is an organization with several levels that the data model has to represent explicitly. Treating it as a single account is where most one-platform builds start to strain, because a flat customer record cannot hold the relationships a chain depends on.

The three levels that have to be explicit

A typical chain breaks into three levels: the parent chain at the top, its departments or shops in the middle, and the managers who actually place orders at the bottom. One manager may be responsible for several departments, so the relationship is many-to-one rather than a clean tree. Pricing, ordering rights, and approval permissions attach at the department level, which means a manager might order for departments A and C at department-specific prices while having no authority over department B. A flat customer record cannot express that, and role-based access has to be designed around the hierarchy rather than around a single user flag.

The Kortreistved marketplace build runs a consumer webshop and a separate chain-customer webshop on the same platform, which is why the hierarchy had to live in the core data model rather than in a plugin bolted onto the consumer schema.

b2b-b2c-chain-customer-hierarchy

A B2B chain customer needs an explicit hierarchy, where departments hold negotiated prices and managers receive ordering rights.

Bulk onboarding from spreadsheets

Chains rarely arrive node by node. They come with their structure already defined in spreadsheets, sometimes hundreds of departments and managers, and an administrator imports the hierarchy in bulk rather than creating each record by hand. This is an operational reality more than a headline feature, but it shapes the data model: the import format has to map cleanly onto the parent-department-manager structure and the per-department pricing that comes with it, or the first onboarding turns into manual data entry that nobody budgeted for.

Chain pricing is negotiated for the organization and stored as its own price structure, not as a markdown applied to the public catalogue. Each chain, and sometimes each department, has agreed unit prices that can differ from the consumer price and from what other chains pay. The cleanest way to hold this is a price list bound to the company account, so the negotiated price is the value that account sees, that the cart computes against, and that the invoice is issued on.

This pattern is well established in mature B2B platforms. Adobe Commerce, for example, uses gated shared catalogues with custom pricing assigned to specific company accounts, so a logged-in chain sees its own prices while consumers see the public catalogue. The Adobe Commerce B2B documentation sets out how company accounts, shared catalogues, and quote workflows fit together, and it is a useful reference point even if you are building custom.

Why pricing-as-a-discount drifts over time

A negotiated price that lives only as a percentage off the current list price creates a quiet data-integrity problem. When an admin later changes the package or the list price, historical orders that referenced the live value recalculate, and last quarter's invoices no longer match what the customer agreed to. The fix is snapshotting: at order creation, the system copies the price and the product definition into the order itself, so the order stays immutable regardless of later catalogue changes. Automatic price propagation can still update every active listing when an admin changes a negotiated price, but orders already placed keep the terms they were placed under.

If you are weighing how much of this belongs in your platform versus a layer on top, that judgment is easier with people who have shipped both models on one codebase. Our e-commerce engineering team has built chain-customer and consumer flows together and can sanity-check your approach before it sets.

Invoice payment changes the order lifecycle, because money no longer moves at checkout. A consumer order is simple: pay, then fulfil. A chain customer often orders against agreed credit terms, receives delivery, and is invoiced afterward, which means the order can be fulfilled before any payment is recorded. The state machine that assumed 'paid equals ready to ship' has to be rebuilt so that fulfilment, invoicing, and payment become separate, trackable stages.

Admin-controlled onboarding and credit terms

Chain customers are not self-registered, because the relationship is negotiated before the first order is placed. Setup covers the agreed pricing, which vendors the chain may buy from, invoicing details, and the people authorized to order on each department's behalf. Putting that behind an admin process instead of a public signup form is what makes credit-based ordering safe to operate at all, since the platform is effectively extending trade credit the moment it lets a chain order before paying.

Where the order state machine has to change

Decoupling 'fulfilled' from 'paid' touches more than the orders table. Returns, partial deliveries, credit notes, and reconciliation all need states that a card-first flow never modelled, and the finance system downstream has to agree with the platform about what 'complete' means. Skipping this is a recurring source of B2B integration trouble: see how silent ERP integration failures surface under load, where order and finance systems quietly disagree until reconciliation breaks.

Electronic invoicing in regulated markets

In several markets the downstream invoice is a structured electronic document rather than a PDF. Norway, for example, exchanges invoices as EHF over the Peppol network, and EHF Billing 3.0 is the Norwegian implementation of the European standard EN 16931 through Peppol BIS Billing 3.0. The specification is published in the Peppol BIS Billing 3.0 documentation, its Norwegian profile in the EHF Billing 3.0 specification, and the public-sector mandate context in the European Commission Norway e-invoicing factsheet. For a chain-customer platform that issues invoices, this shapes how invoice data is generated and handed to accounting systems; the integration depth — access points, document exchange, accounting handoff — is its own topic beyond the architecture decisions covered here.

A chain customer does not see the whole catalogue; it sees the subset of products that satisfy several conditions at once. Visibility is computed for the specific chain-and-vendor relationship, and a product appears only when every one of the following holds:

• an active negotiated price exists for that chain
• the vendor is active and approved to sell to that chain
• the item is in stock
• the delivery address falls inside the vendor's coverage zone
• the chain-vendor relationship is explicitly enabled

Vendor restrictions matter here: not every supplier is allowed to sell to every chain, so the same product can be visible to one chain and hidden from another for commercial reasons rather than inventory ones. Computing this on every catalogue request is expensive, which is why availability is usually cached and recomputed on change rather than evaluated live for each page view. These rules are specific to multi-vendor e-commerce platforms where suppliers, delivery zones, and negotiated relationships all intersect on the same product.

The decision that drives long-term cost is which of these belong in the platform's core model and which can sit in a thin layer on top. Hierarchy and negotiated pricing are foundational, because onboarding, visibility, and the order lifecycle all read from them, so they belong in the data model from the start. Features further out — quote workflows, requisition lists, approval chains — can be added later without reshaping the core, which makes them safe to defer.

Treat the B2B model as an afterthought and the same failure conditions tend to recur:

• pricing modelled as discounts, so historical orders drift when list prices later change
• self-service onboarding that cannot express negotiated terms or vendor permissions
• a payment-gated order state that blocks invoice customers from being fulfilled
• catalogue queries littered with chain-specific conditionals that slow every page view

Building the hierarchy and pricing as first-class data costs more up front and far less over the life of the platform, because the consumer flow never has to absorb B2B exceptions and each new chain becomes data to load rather than code to change.

• Hybrid B2B/B2C commerce works when chain hierarchy, negotiated pricing, and invoice flows are modelled as first-class entities rather than flags on the consumer schema.
• A chain customer is an organization with levels — chain, departments, managers — and a flat customer record cannot express its ordering and pricing rules.
• Negotiated prices should be snapshotted at order creation so historical orders stay immutable when catalogue prices later change.
• Invoice billing decouples 'fulfilled' from 'paid', which forces the order state machine to model fulfilment, invoicing, and payment as separate stages.
• Chain catalogue visibility depends on price, vendor approval, stock, delivery zone, and an explicit chain-vendor relationship, and is usually cached rather than computed live.

Running B2B and B2C on one platform is an architecture decision long before it is a feature list. The platforms that hold up put the chain hierarchy and negotiated pricing into the core model first, then let onboarding, catalogue visibility, and the order lifecycle build on that foundation, so adding a chain customer never means adding exceptions to consumer code.

The ones that struggle started from the consumer schema and tried to express organizations, credit terms, and gated catalogues as conditionals, which works until the first large account exposes every shortcut at once.

If you are mapping this out for your own platform, a conversation with engineers who have built both models together will surface the costly decisions early. Start a B2B/B2C architecture review.