B2x Commerce and What It Means for Frontend Architecture

B2B and B2C are no longer separate builds. More brands sell to businesses and consumers from the same catalog, the same domain, and increasingly the same storefront. That convergence has a name, B2x commerce, and it puts pressure on a part of the stack that most replatforming projects treat as an afterthought: the frontend. Account-specific pricing, roles and approvals, mixed catalogs, and self-service are not backend features you switch on. They are experiences that have to be composed at the surface, per user, per session.

What is B2x commerce?

B2x commerce is the operating model where one storefront serves both business buyers and end consumers without forking into two separate applications. The "x" stands for whatever the visitor turns out to be: an anonymous shopper, a logged-in consumer, a procurement user on a negotiated contract, or a reseller with account-specific pricing. Instead of running a B2C shop and a B2B portal side by side, a B2x setup resolves the buyer context at runtime and renders the right catalog, prices, and actions for that context.

The reason this matters now: the line between the two audiences has blurred. B2B buyers expect the self-service and speed they get as private consumers, and consumer brands increasingly open wholesale, pro, or membership tiers. Maintaining two codebases for what is largely the same catalog is expensive, and it guarantees the two experiences drift apart.

Why B2x logic belongs in the frontend, not the backend monolith

There is a tempting assumption that B2x is a backend problem: add a B2B module, flip on account pricing, done. In practice, most of what makes a B2x experience work is decided at the surface.

Consider what changes between a consumer and a business buyer on the exact same product page:

• Price: list price versus a contract price tied to the account.
• Availability and units: single items versus case quantities or minimum order values.
• Actions: "add to cart" versus "request a quote", "add to requisition list", or "submit for approval".
• Catalog visibility: some SKUs are consumer-only, some are restricted to approved accounts.
• Navigation and content: a business buyer sees reorder, budgets, and cost centers where a consumer sees wishlists and recommendations.

None of these are single backend values. They are composed from several sources at once: the commerce backend for the base catalog, a pricing or contract service for account-specific prices, an identity provider for roles, and a content layer for messaging. The frontend is the only layer that sees all of them together for a given user in a given session. That is why B2x logic has to be composed there. A backend monolith can store the data, but it cannot assemble the experience without becoming a second frontend in disguise.

Roles and approvals are a session concern

Approval workflows are the clearest example. Whether a user can check out, or only submit a cart for a manager to approve, depends on the role attached to their session, the value of the cart, and the account's rules. That decision changes the UI in real time: buttons, banners, and available steps. Encoding it deep in the backend means every change to an approval rule waits on a backend release. Composed in the frontend, against a roles API, the same change ships as a frontend deployment.

How a composable frontend handles B2x without replatforming the backend

The composable move for B2x is the same one applied to search, payments, and subscriptions: keep the specialist systems where they are, and compose the experience in a decoupled frontend layer. Concretely:

• A unified data layer (typically GraphQL) sits in front of the commerce backend, the pricing or contract service, and the identity provider, so the frontend queries one endpoint and receives catalog, account price, and role in a single resolved response.
• The buyer context (anonymous, consumer, business account, role) is resolved per session and drives which components render. A composable, headless frontend treats that context as a first-class input, not a special case bolted onto a B2C theme.
• Catalog, pricing, and roles stay in their own systems. You do not migrate the backend to get B2x behavior; you compose on top of the backend you already run.
• The same component library renders both audiences. A product card, a price block, or a cart action becomes context-aware once, and every page that uses it inherits the B2x behavior.

Because the logic lives in a decoupled layer, a team can add a "request a quote" flow or a requisition list to the existing consumer storefront without touching the backend and without standing up a separate B2B application. The composable storefront is one build that behaves differently per buyer context, not two builds stitched together.

Mixed catalogs and self-service in one build

Two of the hardest B2x requirements, mixed catalogs and self-service, show why the frontend is the right place to compose.

Mixed catalogs mean the same storefront exposes different product sets to different buyers: consumer SKUs, business-only SKUs, and account-restricted SKUs. Filtering that purely in the backend leads to brittle, per-audience API variants. Resolved in the frontend against the buyer context, catalog visibility becomes a query parameter, and one set of listing and detail components covers every case.

Self-service, meaning account management, order history, reorder, budgets, and user administration, is where B2B customers spend most of their time, and where the experience most often breaks when it is redirected to a backend admin screen. Composed in the frontend, the account area uses the same components as the storefront, so the business buyer never leaves your brand to manage their account.

Native B2B module vs. composable B2x frontend

• Dimension | Native backend B2B module | Composable B2x frontend
• Buyer context | Fixed per store or per site | Resolved per session and role
• Account-specific pricing | Backend value, limited display control | Composed at the surface, fully styled
• Roles and approvals | Backend release cycle | Frontend deployment, against a roles API
• Mixed catalogs | Separate API variants per audience | One query, context-driven visibility
• Self-service area | Often a backend admin screen | Same component library as the storefront
• Adding B2C to a B2B build (or the reverse) | Second application | One build, new context

FAQ

Is B2x commerce just B2B and B2C on the same domain? No. Sharing a domain is the easy part. B2x means one storefront resolves the buyer context at runtime and renders the right catalog, prices, and actions for that user, instead of routing them into a separate B2B or B2C application.

Do we need to replatform the backend to support B2x? No. The point of composing B2x in the frontend is that catalog, pricing, and identity stay in their existing systems. A unified data layer joins them, and the frontend assembles the experience on top of the backend you already run.

Where do account-specific prices come from? Usually a pricing or contract service separate from the base catalog. The frontend requests the resolved price for the current account through the unified data layer and renders it in the same price component consumers see, with different values.

How are approval workflows handled? The user's role and the account's rules are resolved per session. The frontend reads them from a roles API and adjusts the available actions, checkout versus submit-for-approval, in real time. Rule changes ship as frontend deployments, not backend releases.

Can we start B2C and add B2B later? Yes, and that is the main advantage. Because the buyer context is a first-class input to the frontend, adding a business tier means adding a context and its components, not building a second storefront.

More from the Laioutr Platform

• Composable Headless Frontend: the decoupled layer where buyer context, pricing, and roles are composed into one experience.
• Composable Storefront: one build that renders both business and consumer buyers without forking into two applications.
• Frontend as a Service: how the frontend layer is operated and deployed independently of the commerce backend.
• Agentic Frontend Management Platform: how routine changes to context rules and components can be handled with AI agents.

Next step

Want to see what your B2x logic, account pricing, roles, mixed catalogs, and self-service, would look like composed in a decoupled frontend? Talk to the Laioutr team and we will map it onto the backend you already run.