Shopify Functions for B2B.

Every Function API mapped to its wholesale job: validation for order rules, discounts for volume pricing, payment customization for terms and review, plus the hard limits Shopify enforces.

Shopify Functions are how you change checkout behavior without hosting anything yourself. You write a small program, Shopify compiles it to WebAssembly, and Shopify runs it at the exact moment the logic applies: when discounts calculate, when payment methods render, when the buyer submits the order. For a B2B merchant, this is the layer that turns a generic checkout into a wholesale checkout: order minimums per company, net terms set by rule, mandatory review for new accounts, volume pricing that follows contract tiers.

This chapter of the Shopify B2B Deep Dive maps each Function API to its B2B job, lists the hard limits, and flags what stays out of reach.

What are Shopify Functions?

Shopify Functions let developers customize the backend logic that powers parts of Shopify: discounts, cart presentation, payment methods, delivery options, and checkout validation. The code runs on Shopify's infrastructure, not on your servers. Functions compile to WebAssembly, so any language that compiles to Wasm works: Rust, JavaScript, TypeScript, Zig, TinyGo. Shopify recommends Rust as the most performant choice.

Functions are pure and deterministic. They receive an input (the result of a GraphQL query you define, describing the cart and buyer), they return an output (a list of operations), and nothing else happens: no network access, no filesystem, no random numbers, no clock. The only exception is a fetch target gated to specific enterprise plans, covered below.

Availability splits in a way that matters for B2B merchants. Stores on any plan can use public App Store apps that contain functions. Only stores on a Shopify Plus plan can use custom apps that contain Function APIs, and some individual capabilities are Plus-only regardless of how the function ships.

Which Function APIs matter for B2B?

The current, non-deprecated Function APIs are Discount, Delivery Customization, Payment Customization, Cart Transform, Cart and Checkout Validation, Fulfillment Constraints, and the two pickup option generators. The old Order Discount, Product Discount, and Shipping Discount APIs are deprecated in favor of the unified Discount Function API. Five of these carry the B2B weight:

How does a function know the buyer is a B2B company?

Function input can include the buyer's company context. cart.buyerIdentity.purchasingCompany exposes the company, the company location, and that location's totalSpent and ordersCount. A non-null purchasingCompany means a B2B checkout; the spend and order-count fields are what make conditional wholesale logic possible. Shopify's own payment customization example requires order review when a company location has fewer than 10 orders, using this input query:

query CartPaymentMethodsTransformRunInput {
  cart {
    buyerIdentity {
      purchasingCompany {
        location {
          id
          totalSpent { amount currencyCode }
          ordersCount
        }
      }
    }
  }
}

Merchant settings follow a standard pattern: configuration lives in JSON metafields on the function owner, edited through an admin UI extension. And since functions cannot call external systems at runtime, the documented approach for external data is to write it into metafields ahead of checkout via the Admin or Storefront APIs, then read those metafields in the function input.

What can validation functions enforce for B2B?

The Cart and Checkout Validation Function API is the only server-side way to validate cart and checkout, and its documented use cases read like a wholesale requirements list, verbatim from Shopify: "Provide B2B product minimums, maximums, and multiples. Provide B2B location order minimums, maximums, or credit limits. Validate purchase order numbers for B2B customers."

• Coverage. Validation runs on B2B checkout, cart, standard checkout, draft orders, admin, storefront, and accelerated checkout, including express wallets such as Shop Pay, PayPal, Google Pay, and Apple Pay. It does not run on POS, order edits, the Create Order API, pre-orders, or subscription recurring orders.
• Error surfaces. Failures appear in three places: the Storefront API Cart object as userErrors with code VALIDATION_CUSTOM, themes using the cart template, and checkout itself.
• PO numbers. poNumber is available on cart input, so a function can reject checkouts with a missing or malformed purchase order number.
• Hard boundary. A validation function can only block checkout with an error message. It cannot remove an item from the cart.

This is enforcement, not workflow. For what B2B checkout itself supports, see B2B checkout and draft orders.

How do discount functions handle volume and contract pricing?

The unified Discount Function API processes one discount, code-based or automatic, that can apply savings across three classes at once: product, order, and shipping. Shopify documents volume discounts directly: a discount function can apply different rates when a line item quantity meets defined thresholds. Tiered discounts with qualifying item, subtotal, and delivery requirements are also documented use cases.

Two constraints shape how far this goes. Up to 25 discount functions can be active, and they all run concurrently with no knowledge of each other; outputs combine according to the stacking rules on each discount. And one stacking control, multiple product discounts on the same cart line via tag match, is available only on Shopify Plus. The API is moving quickly: cart metafields landed in function input in July 2025 and custom rejection messages for discount codes shipped in Q4 2025, per the checkout roadmap.

Discount functions layer on top of Shopify's native pricing stack, not instead of it. Start with catalogs and price lists for baseline contract pricing, and see live pricing beyond price lists for when ERP-driven prices enter the picture.

What can payment customization do for terms and approvals?

The Payment Customization Function API carries four operations: paymentMethodHide, paymentMethodMove, paymentMethodRename, and paymentTermsSet. For B2B, two capabilities stand out.

Setting payment terms by rule

Since API version 2025-07, a function can set fixed, net, or event-based payment terms with optional deposits, for example a 50 percent deposit on B2B orders over $500. The documented boundaries: the shop must be on Shopify Plus, terms apply only to that specific order and never change the buyer's default terms, existing terms are not visible in function input, and terms cannot be set on accelerated checkouts. B2B checkouts do not support automatic payment capture for event-based terms; merchants capture manually. For the native terms system these functions build on, see payment terms, net terms and credit.

Requiring review before an order exists

A function can add a review requirement so that submitting the checkout creates a draft order instead of an order. This applies to B2B checkouts only, and it cannot be applied to draft order invoice checkouts or admin draft order flows. It is a single gate, not an approval workflow: no roles, no routing, no escalation. For the workflow gap and how to close it, see the order approvals fix.

Wallet limitations apply across the API: payment methods with logo names (Shop Pay, Apple Pay, Google Pay) cannot be renamed, wallets can be removed but not reordered, and payment functions do not run in POS.

Where does Cart Transform fit, and where does it stop?

The Cart Transform Function API changes cart pricing and presentation: expand one line into bundled components, merge lines into a bundle, or update a line's price, title, or image. The update operation is the interesting one for B2B, and it is gated: only development stores or Shopify Plus stores can use apps with lineUpdate operations.

Each app can register one cart transform per store; when multiple apps install transforms, all of them run, with documented collision rules.

What are the resource limits?

Every function runs inside fixed and dynamic limits. The fixed limits (note: Shopify counts 1 kB as 1000 bytes here):

The dynamic limits apply up to 200 cart line items and scale proportionally beyond that, which matters for large wholesale carts:

Input queries have their own budget: a maximum of 3,000 bytes, a calculated query cost cap of 30 (metafield, tag, and collection checks cost 3 each), list arguments capped at 100 elements, and metafield values over 10,000 bytes not returned at all. Exceeding any limit surfaces as a typed runtime error such as InstructionCountLimitExceededError or OutputTooLargeError in function monitoring.

What can Shopify Functions not do?

• NOT NATIVE Call your ERP at checkout. Network access exists only as a fetch target on custom apps for Shopify's enterprise offering (Commerce Components), covering validation, discounts, and local pickup generators. Everyone else pre-syncs data into metafields.
• NOT NATIVE Remove an item from the cart. Validation can only block checkout with an error.
• NOT NATIVE Use randomness or the clock. Functions are deterministic by design.
• NOT NATIVE Reference another app's function. Admin API mutations only accept the app's own functions.
• NOT NATIVE Ship dynamic code editing. The App Store does not permit apps that provide dynamic editing and execution of function code.
• NOT NATIVE Strip the carrier name from a renamed delivery option. "UPS Standard Shipping" is possible; a bare "Standard Shipping" is not.

One platform constraint sits underneath all of this: Shopify B2B itself does not support purchase options such as subscriptions, pre-orders, and try-before-you-buy, so no function can add them to a B2B checkout. Plus stores still on legacy checkout.liquid customizations must upgrade to checkout extensibility before they can use Function APIs. The full list of platform boundaries lives in the Constraints Ledger.

When do you write a function, and when do you install one?

Write a function when the rule is genuinely yours: a credit-limit formula, a PO format, a deposit policy nobody else has. That path requires a developer, a custom app, and a Plus plan. Install one when the logic is a category, not a quirk, because public apps carry functions onto any plan and someone else maintains them against API changes.

B2B Supercharge takes the second path for the workflows around checkout. NATIVE to the suite: order approvals where orders over a threshold route to the right approver automatically with full history (Account Tools), quotes your team builds against margin floors that buyers accept and convert (Buying Tools), and two-way sync with Dynamics 365, NetSuite, Sage, HubSpot, and Salesforce so quotes, orders, invoices, and remittance stay current without checkout-time calls (ERP & CRM). See the ERP and CRM sync fix for how that data pipeline works, or book a demo to walk through it live.

Frequently asked questions