Shopify Functions

Why it matters

Functions solved a real problem. Custom checkout logic used to mean either Shopify Scripts, which ran on a legacy runtime available to few merchants, or an app making a network call during checkout, which is exactly where you least want to wait on someone else's server.

Running inside Shopify's infrastructure changes the trade-off. The logic executes as part of the request rather than as a call out of it, so a complex discount rule does not add a round trip to the highest-converting page on the store.

The constraint that follows is the point: a Function cannot call out. No fetching prices from an ERP mid-checkout, no live lookups. Everything a Function needs must already be in Shopify — which is a data modelling requirement disguised as a technical limitation, and the reason many Function projects turn into metafield projects first.

How it works on Shopify

You write a Function in Rust or JavaScript, it compiles to WebAssembly, and it deploys as part of an app — including a custom app built for one store.

Each Function targets a specific extension point: discounts, delivery method availability, payment method availability, cart and checkout validation, cart transforms for bundling, order routing, and others added over time. The shape is consistent — Shopify passes an input document describing the cart and context, the Function returns operations describing what to change.

The input is a GraphQL query you define, which is where metafields enter. A discount Function that depends on customer tier reads that tier from a metafield, because it cannot ask another system.

Execution is bounded by time and memory. Functions are meant to be small, deterministic decisions, and the runtime enforces it.

Availability follows Shopify Plus for the checkout-facing extension points.

Common mistakes

• Expecting network access. The most common early surprise. Design the data model first: whatever the logic needs has to live in Shopify before the Function is written.
• Building business rules that belong in configuration. A Function encoding thresholds that marketing changes weekly means a deploy every week. Read the values from metafields instead.
• Skipping the input query. Requesting more than needed wastes the execution budget; requesting too little produces a Function that silently cannot decide.
• No test coverage. This code runs on every checkout. Discount logic without tests is a pricing incident waiting for a Friday.
• One Function doing everything. Extension points are separate for a reason. Combining unrelated logic makes failures hard to isolate.

When you need help

The clearest signal is a requirement that keeps being described as "we need the checkout to know". Whether that is expressible as a Function, and what data model it implies, is an assessment worth doing before a build is scoped — the answer is frequently that the Function is a week and the data work behind it is a month.

The other case is anything touching money. Discount stacking, tiered pricing, and B2B rules interact in ways that are difficult to reason about and expensive to get wrong, and they run on every order until someone notices.