B2B Commerce Portal: Punchout, Tiered Pricing, and Quick Order in the Frontend

A B2B online shop is not a B2C shop with a company login added at the top. If you run a manufacturer, wholesaler, or distribution operation, you know the real requirements: a purchase inside a customer organization has budget limits, approval workflows, and cost center assignments. The catalog looks different for each customer. Prices are negotiated, tiered, or come directly from the ERP. And a significant share of orders does not arrive manually - they come via punchout from the customer's procurement system.

These requirements cannot be cleanly handled by a standard storefront frontend. But they do not require a multi-year custom development project either. This post explains how to implement the three most critical B2B purchasing process components - punchout, tiered pricing, and quick order - as a frontend layer on your existing backend.

All components described here are included in the Laioutr B2B Growth Kit, a complete UI set you can place on top of your existing stack.

What sets B2B commerce apart from B2C frontend requirements

In a B2C shop, one person decides, adds to cart, and pays. In B2B, multiple processes run simultaneously:

• Multiple buyers share a customer organization with different roles
• Prices come from ERP condition tables, not a unified price list system
• Orders above a certain value need approval before they can be placed
• Buyers work with procurement systems (SAP Ariba, Coupa, Jaggaer) that connect to the shop via punchout
• Large accounts reorder the same items in high quantities on a regular schedule

A frontend that ignores this reality forces workarounds: PDF quotes via email, phone calls for price inquiries, manual ERP exports. Every workaround costs processing time on your side and friction on your customer's side.

The approach taken by Laioutr as a Frontend Management Platform (FMP) is different: the frontend layer is decoupled from the backend and covers B2B logic through configurable components, while the backend - whether SAP, Shopware, commercetools, or OXID - stays unchanged.

Punchout (OCI/cXML): the invisible B2B channel

What punchout is and why it is often missing

Punchout means: the buyer in the customer company leaves their procurement system (e.g., SAP Ariba), "punches out" into your shop, fills their cart there, and the cart is transferred back to the procurement system as an electronic document. The order then runs through the customer company's approval process before it arrives at your end as a confirmed order.

OCI (Open Catalog Interface) is the SAP standard for this. cXML is the more open standard used by Coupa and many other systems.

Why punchout is underestimated as a frontend concern

Punchout is frequently treated as a backend topic: ERP integration, document format, protocol. The frontend share gets underestimated. But the punchout flow is entirely a frontend experience from the customer's perspective:

• The session handoff (customer identification, condition data) needs to be evaluated in the frontend
• The catalog shows only the contractually agreed products and prices for that organization
• The "transfer cart" button is a UI element that generates OCI- or cXML-compliant XML and transfers it back to the procurement system
• Errors in the flow (expired session, incorrect condition data) appear as frontend error messages

The B2B Growth Kit includes punchout components supporting both OCI and cXML. Session initialization, catalog filtering by customer segment, and the transfer process are implemented as ready-to-use, configurable building blocks - you do not need to implement the protocol yourself.

What you need on the backend side for punchout

Punchout requires your backend to:

• Return customer-specific conditions (prices, availability, catalog segments) via an API
• Authenticate punchout sessions via token or SAML
• Receive and process orders in cXML or OCI format

This is typically a backend responsibility. If your shop or ERP does not support this yet, punchout is a backend problem, not a frontend problem. The frontend layer can only represent what the backend provides.

Tiered pricing: each customer sees their own conditions

The reality behind tiered pricing

"Tiered pricing" sounds simple: units 1-9 cost X per piece, units 10-49 cost Y per piece. In practice, it is more complex:

• Conditions often come directly from the ERP (SAP Condition Records, Shopware Customer Groups, commercetools Price Selectors)
• The same item may have different tier structures per customer organization
• Some conditions are time-limited (seasonal discounts, promotional pricing)
• Net/gross switching needs to work correctly, because buyers calculate in net while the shop sometimes displays gross prices

A cleanly implemented tiered pricing frontend:

1. Fetches conditions for the currently logged-in customer when the product detail page loads
2. Displays tiers clearly (quantity thresholds, unit price, total price at current quantity)
3. Updates the price display in real time when the quantity input changes
4. Makes net/gross switchable

Technical integration without custom frontend code

With the Laioutr Frontend Management Platform and the B2B Growth Kit, the tiered pricing component connects directly to your backend's pricing API. You configure which API fields map to which UI elements - the component code itself does not change. That is the difference from a custom build, where every backend-specific behavior ends up as new frontend code.

And further: the tiered pricing component lives in your UI library. Once configured, you can reuse it across every frontend for your brands and markets without rebuilding it.

What commonly goes wrong

Two typical problems with tiered pricing frontends:

• Prices are cached even though they are customer-specific: a different buyer from the same organization then sees incorrect conditions. Solution: never cache prices at CDN level, always load via customer context.
• The quantity input in the quick order flow and the tiered pricing display on the product detail page are not synchronized. Result: buyers see no tier information in quick order and place a suboptimal quantity. Solution: make the tiered pricing component available in the quick order context as well.

Quick order: large volumes in seconds

Who needs quick order

Quick order is the most important differentiating feature of a B2B shop compared to a consumer shop. Anyone reordering the same items regularly does not want to navigate category trees every time. Quick order means: enter an item number or EAN, enter quantity, add to cart. Done.

Typical users: buyers in production facilities, warehouse managers with fixed replenishment lists, store managers restocking standard items.

Three variants in one kit

The B2B Growth Kit includes three quick order variants that all call the same backend endpoint:

1. Line-based entry: fields for item number and quantity, as many rows as needed, "add all to cart" as a single action. Best for buyers who have item IDs memorized.

2. CSV upload: upload a spreadsheet export from Excel or your own ERP - the shop automatically recognizes item numbers and quantities. Best for large order lists from the production floor.

3. Order lists and cart templates: saved lists from previous orders as templates. Load "Monthly Order Plant Hamburg" with one click and adjust. Best for recurring standard orders.

Validation in the frontend

Quick order must not fail silently. If an item number is not found, if a minimum order quantity is not met, or if an item is not authorized for that customer organization - this needs to be visible and explanatory before the buyer clicks "add to cart."

This sounds obvious but is frequently a post-launch fix in custom builds. The B2B Growth Kit has validation feedback and error states for all three quick order variants included from the start.

Approval workflows and requests for quotation

B2B purchasing processes do not end at clicking "buy." Two additional flows are part of a complete frontend:

Approval workflow

When a buyer creates an order above a defined budget threshold, it does not go out immediately but enters an approval process. In the frontend this means:

• Buyer creates the order, sees "Pending approval"
• Approver receives a notification, sees pending approvals in their account area
• Approver approves or rejects, with optional comment
• Buyer receives a status update

The budget limit and approver structure come from your backend. The frontend layer renders the visible workflow without owning the logic.

Request for quotation (RFQ)

Not every B2B order goes through at list prices. For individual large purchases or new products, an RFQ process is needed. In the frontend:

• Buyer adds items to a quote draft (not a cart, but a quote)
• Comment field for quantity, delivery, and pricing expectations
• Quote goes to your sales team, who respond with a binding offer
• Buyer can accept the offer and convert it to an order

The B2B Growth Kit includes both flows as ready-to-use components. You configure the connection to your workflow backend (ERP, OMS, or simply an email notification) in Laioutr Studio.

Self-service as support load reduction

Every question a buyer asks by phone or email costs you processing time. Typical B2B self-service features that reduce this load:

• Order history with delivery status and tracking link
• Delivery note and invoice download
• Return request (RMA) without needing to call
• Recurring orders ("repeat this order")
• Contact person with direct contact link

These are not convenience features. They determine whether your customer service team handles 50 or 500 B2B requests per week.

Performance and compliance built in, not added on

B2B portals often run on legacy stacks where WCAG compliance and Core Web Vitals were retrofitted. That costs time and creates technical debt.

In the B2B Growth Kit, trust, compliance, and performance are built into all components as a cross-cutting concern:

• WCAG 2.1 AA and BFSG-ready out of the box (no after-the-fact accessibility retrofitting)
• Median LCP under 1.2 seconds in live frontends
• SEO and Schema.org markup on product and category pages
• Multi-locale and GDPR-compliant, EU-hosted

FAQ: B2B commerce frontend

What backend changes do I need to use the B2B Growth Kit? The kit sits as a frontend layer on top of your existing stack. You do not need backend changes as long as your backend exposes the necessary APIs (products, prices, order logic, customer data). What is frequently missing are customer-specific pricing APIs - that is a backend concern, not a frontend concern.

Does punchout work with cXML if our key accounts use Coupa? Yes. The punchout components in the B2B Growth Kit support both OCI (SAP standard) and cXML. Which standards your backend supports on the receiving side determines which procurement systems can be connected.

Can we use tiered pricing and punchout at the same time? Yes. In a punchout session, conditions are loaded from your backend for the respective customer - including tiered pricing. Punchout and tiered pricing display use the same condition logic, just in a different session context.

How long does implementation typically take? A complete B2B portal with punchout, tiered pricing, quick order, and approval workflows is typically live in 4 to 8 weeks - depending on the complexity of the backend APIs and the number of brands and markets.

Can we add new pages after the initial launch? Yes. That is one of the core benefits of the Laioutr Frontend Management Platform: your marketing team can assemble new landing pages and sections directly in the editor without a developer ticket. The B2B Growth Kit provides the component foundation.

Summary: frontend layer, not custom build

B2B commerce portals frequently fail not because features are missing, but because of the time it takes to build and maintain those features. Every B2B-specific requirement - punchout, tiered pricing, approvals - ends up as custom code that needs maintenance with every backend update.

The alternative: a composable frontend with pre-built B2B components on your existing stack. No replatforming, no greenfield project, no lock-in.

The B2B Growth Kit includes all components described here as a testable, production-ready UI set. An overview of all eight industry-specific kits is available in the UI Growth Kits hub.

If you want to understand which components fit your stack and backend, let's talk.

Laioutr is the [Frontend Management Platform (FMP)](https://www.laioutr.com/en/composable-headless-frontend) for composable commerce. The [content management product](https://www.laioutr.com/product/content-management) lets your marketing team compose pages in the editor without developer dependencies.

More on Laioutr: Personalization.