Writing · shopify plus

Shopify Plus Checkout Extensibility for B2B: What Actually Ships in 2026

By Leo Nguyen · Jul 7, 2026 · 9 min read

Jump to section›

#Short answer

In 2026, a Shopify Plus B2B checkout customization is not one thing — it's a stack of three primitives: checkout UI extensions for what the buyer sees and types, Shopify Functions for how the cart, payments, and shipping behave, and the checkout branding API for how the surface looks. The checkout.liquid file most legacy Plus stores used to hack B2B logic into is gone at the information, shipping, and payment steps, and the extensibility stack is what replaced it (Shopify checkout customization documentation).

Most Plus stores we've audited across 50+ projects miss the same thing when they migrate: they think in "features I need to rebuild" instead of "primitives I need to compose." The B2B customizations that ship reliably in 2026 are composed of a UI extension plus a Function working together — and that pairing is where the leverage sits.

#The B2B checkout stack in 2026

Checkout UI extensions — add fields, banners, and inline logic at defined targets across the information, shipping, payment, Thank-you, and Order-status steps.
Shopify Functions — change how the cart, payment options, delivery options, or discounts behave, based on cart contents, buyer, or a captured extension value.
Checkout branding API — style the surface consistently with the storefront, without touching layout.
Checkout UI extension targets — the specific slots where an extension can render (before/after payment, in the order summary, on the Thank-you page, etc.).

Everything you build for a B2B checkout in 2026 is a composition of these four, plus the B2B primitives already native to Shopify Plus — companies, locations, gated catalogs, price lists, and payment terms.

#Why B2B checkout is where enterprise deals stall

Retail checkout is a well-solved shape. Cart, address, shipping, payment, done. B2B checkout is the shape where every legacy operation has bespoke details that a retail flow doesn't capture: a purchase-order number that finance must have on the invoice, a delivery date the warehouse commits to, a tax-exempt certificate on file, buyer notes for the receiving team, a net-30 payment method that shouldn't be visible to retail shoppers, a rule that says orders over a threshold require approval before payment.

Legacy Plus stores encoded this in checkout.liquid — a file that no longer exists at those steps. The failure pattern we see most often on B2B migrations is a team that spent a year building checkout customizations in liquid, discovered late in the migration window that liquid is gone at the checkout steps, and then tried to squeeze the same logic into a UI extension one-to-one. It doesn't map cleanly, because UI extensions are surface-scoped by design and Functions are behavior-scoped. The mental model has to change.

#The 5 B2B customizations that ship reliably

These are the patterns we see composed most often across serious B2B Plus stores in 2026. Each one is a UI extension paired with a Function.

#1. Purchase-order number capture with threshold rules

A required PO field at the information step, rendered only for B2B buyers. Below a certain cart total, PO is optional; above it, PO is required and the checkout blocks progression until it's filled. The UI extension captures the value and attaches it to checkout attributes; the Function reads cart total and buyer segment to decide whether to enforce the requirement.

#2. Delivery date and window picker

A calendar or delivery-window selector at the shipping step, exposing only dates the warehouse can commit to. The extension captures the chosen slot; a delivery customization Function optionally filters shipping methods to those compatible with the chosen date. The fulfillment integration reads the captured date from the order — this is the piece most teams forget to wire.

#3. Net-terms payment method gating

Net 15, net 30, net 60, and due-on-fulfillment as native Shopify B2B payment methods (payment terms in B2B), gated so they only appear for buyers whose company location has that terms template assigned. A payment customization Function hides them from retail and from B2B buyers who don't yet have credit approved. This is the customization that most protects the finance team from mistakes.

#4. Tax-exempt certificate upload and validation

A UI extension that renders a file-upload widget or a certificate-number field on the information step for buyers flagged as exempt. The upload attaches to the order as metadata; a validation banner surfaces if the certificate is expired or missing. Downstream, the ERP integration picks up the certificate reference alongside the order.

#5. Buyer notes and delivery instructions

A structured buyer-notes field — one for accounts receivable, one for the warehouse — instead of a single free-form textarea that no downstream system can parse. Each notes field is a distinct extension target with its own label and validation; the order export splits them into separate fields for the ERP and the warehouse management system.

#What Shopify Functions unlock beyond the checkout surface

The Function categories most B2B operations end up using — beyond what's already visible above — are:

Discount functions, for volume breaks and contract pricing that layer on top of gated catalogs.
Cart-transform functions, for bundled line items, sample-with-order rules, or automatic add-ons based on cart shape.
Delivery customization functions, for reordering, hiding, or renaming shipping options based on buyer or cart.
Payment customization functions, as covered above, for gating payment methods by buyer segment or cart total.

Each Function is deployed as a compiled WebAssembly module that runs inside Shopify's infrastructure, so latency is bounded and the behavior is deterministic. That's what makes them safe to use at checkout, where every millisecond of added latency shows up in conversion.

#The migration path from checkout.liquid

Shopify has documented the migration from legacy checkout to checkout extensibility as the required upgrade path for Plus stores (checkout customization documentation). For B2B stores specifically, the migration is not a lift-and-shift — it's a re-modeling exercise. Every piece of checkout.liquid logic gets sorted into one of three buckets:

Surface logic (render a field, show a banner, capture input) → UI extension at the right target.
Behavior logic (change payment options, reshape delivery, apply discount) → Function of the right type.
Assisted-selling logic (build the order on the buyer's behalf, negotiate pricing) → stays in the draft-order flow inside the admin, not the checkout at all.

Teams that stall on the migration are almost always trying to force bucket 3 logic into buckets 1 or 2. The self-service checkout is not the right place for assisted selling. Keep those flows separate and each half becomes tractable.

#What extensibility still doesn't cover

Two patterns still route through the native draft-order flow, not through extensibility:

Assisted selling and negotiated quotes. When a sales rep builds an order on the buyer's behalf — a bespoke price that isn't a catalog rule, a mixed sample and paid order, a quote that needs sign-off before payment — the draft order inside the Shopify admin is the right tool. Extensibility is for the self-service path.
Some pre-order and reservation flows. A future-dated payment against a not-yet-fulfilled item, common in wholesale seasonal buying, is still usually cleaner as a draft order with terms attached than as a checkout customization.

Both are covered inside the native B2B feature set — the mistake is trying to build them into the self-service checkout instead.

#The failure modes we see most

UI extension collects a field, no Function acts on it. The buyer types a delivery date. The order ships whenever the warehouse pulls it. The captured field is a data point, not a behavior — a Function has to close the loop.
Function is written but not scoped to B2B buyers. A payment customization hides net-terms methods from wholesale as intended, but the same Function runs on retail carts and hides valid retail methods. Every Function needs an explicit buyer-segment check at the top.
Extensions built for the buying path, admin draft-order flow left untouched. Reps place half the orders through the admin, and none of them see the customization. The draft-order flow needs its own review during migration, even if the customization only ships at the buyer-facing checkout.
No pre-launch test matrix. Every serious B2B checkout customization needs a buyer-by-buyer walkthrough before cutover — one representative buyer per pricing tier, per payment-terms configuration, per exempt-status flag. Skipping the matrix is the single most common reason a technically correct migration produces a messy first week.

#Takeaway

The 2026 Shopify Plus B2B checkout is not a checkout.liquid file with more room to hack. It's a stack of primitives — UI extensions for surface, Functions for behavior, native B2B for structure — that compose into every customization a wholesale operation actually needs. The teams that ship cleanly are the ones that stop trying to rebuild checkout.liquid and start composing the stack the platform now offers.

If you're mid-migration and unsure whether a legacy customization belongs in an extension, a Function, or the draft-order flow, that sorting exercise is the highest-leverage hour you can spend before touching code.

#Sources

Frequently asked

Is checkout.liquid still supported on Shopify Plus in 2026?›

No. Shopify retired checkout.liquid for the information, shipping, and payment steps as part of the platform's move to checkout extensibility. Stores still running legacy checkout customizations at that boundary needed to migrate to checkout UI extensions, Shopify Functions, and the branding API before their upgrade window closed. If your Plus store is still on checkout.liquid for those steps today, you're either grandfathered on a narrow exception or your checkout is running an unsupported configuration — either way, migration is the priority, not another custom-liquid patch.

What can I actually customize in a Shopify Plus B2B checkout with UI extensions?›

Checkout UI extensions let you add custom fields, banners, and inline logic at defined extension targets across the information, shipping, and payment steps, plus the Thank-you and Order-status pages. For B2B specifically, the common pattern is adding a required purchase-order number field, an optional buyer notes field, a delivery-date picker, and a tax-exempt certificate upload — each one attached to a target and rendered only for B2B buyers via checkout attributes or company-location metadata. What you cannot do is arbitrarily replace the checkout's native layout — extensions are surface-scoped by design, and that constraint is why the checkout stays performant.

When do I need Shopify Functions instead of a UI extension?›

Use UI extensions when you need to render, capture, or validate information at checkout. Use Shopify Functions when you need to change how the cart or checkout behaves. Payment customizations that hide net-terms payment methods from retail buyers, delivery customizations that reorder or hide shipping options for wholesale orders, cart-transform functions that inject a bundled line item, and discount functions that apply contract pricing or volume breaks — those are all Functions, not extensions. In practice, most B2B checkout customizations use both: an extension to capture buyer input and a Function to reshape the cart, shipping, or payment options based on it.

Does Shopify Plus B2B support purchase orders and net payment terms natively?›

Yes. Shopify B2B natively supports purchase order numbers and net payment terms as part of the wholesale buying flow — you configure payment terms (net 15, net 30, net 60, due-on-fulfillment, or a fixed due date) as templates and assign them per company location, so buyers on terms see them as a payment option at checkout and the order moves to a pending-payment state until reconciled. What UI extensions add is customization on top of the native flow: an extra required PO field for buyers who need a specific format, a delivery-window picker, or a rules layer that requires PO for orders above a threshold.

What still forces a draft-order flow instead of extensibility?›

Assisted selling and negotiated one-off quotes. When a sales rep or account manager builds an order on the buyer's behalf — bespoke pricing that isn't a catalog rule, a mixed sample and paid order, or a quote that needs to be sent for approval before payment — the native draft-order flow inside the Shopify admin remains the right tool. Checkout extensibility is designed for the self-service buying path; the draft-order flow is designed for the assisted path. Trying to force one to do the other's job is a common failure mode. A serious B2B operation typically runs both in parallel, cleanly separated by which buyer segment or order type triggers which path.

What breaks most often when B2B teams first ship checkout extensions?›

Three patterns, in order. First, a UI extension collects a field but no Function acts on it — a delivery-date picker is shown at checkout, but nothing in the fulfillment integration reads it, so the order ships whenever the warehouse pulls it. Second, a Function is written but not scoped to B2B buyers — a payment customization hides net-terms methods from wholesale accounts as intended, but the same Function accidentally runs on retail carts and hides valid retail methods. Third, extensions are wired for the buying path but the admin-facing draft-order flow that reps actually use most days is left on the old configuration, so half the orders never see the customization. All three are caught by the same discipline — a pre-launch test matrix that walks a representative buyer from every segment through the checkout and confirms every downstream system sees the right data.