Shopify Functions

Shopify Functions is the official successor to Shopify Scripts, built on WebAssembly to run merchant-defined checkout logic natively inside Shopify's infrastructure. Where Scripts ran Ruby in a loosely sandboxed environment and often exceeded 50-100ms, Functions execute compiled WASM in under 5ms — deterministic, cold-start-free, and auditable. The runtime is fully sandboxed: no network access, no file system, no external calls of any kind during execution. Every commerce developer working on a Shopify Plus store in 2026 needs to understand what this means structurally. The migration context is urgent. Shopify announced Scripts deprecation and has extended the deadline twice. The current hard date is June 30, 2026, with an editing freeze that passed April 15, 2026. An estimated 47,000+ active Shopify Plus domains have some form of custom Scripts in production. Any merchant who misses the June 30 deadline does not receive a graceful fallback — custom checkout logic simply stops executing, meaning discount caps, payment filters, and shipping rules disappear silently. There is no safety net. The technical constraints of Functions are design choices, not limitations to be worked around. The 5ms CPU budget and 64KB memory cap are hard limits enforced by the WASM sandbox. These constraints mean Functions cannot call an ERP for live COGS at decision time, cannot query a freight rate table over HTTPS, and cannot fetch live FX rates mid-checkout. This is architecturally significant for any merchant trying to enforce margin at checkout: Functions alone cannot make a profitable/unprofitable determination because they lack live cost data. The practical pattern for margin governance is to pre-stage cost data. A profit-firewall layer like Agentis computes per-SKU cost floors and writes them to Shopify metafields ahead of checkout. The Function then reads those local metafields within the 5ms budget and applies the floor logic. This decoupling — data pipeline outside Functions, decisioning logic inside — is the only architecture that satisfies both the WASM sandbox constraints and real-time enforcement requirements. Functions cover five major use-case types: Discount Functions (apply or block discounts based on cart state), Cart Transform (modify line items, add services, bundle products), Payment Customization (filter, reorder, or rename payment methods), Delivery Customization (modify shipping rates and names), and Order Routing (direct fulfillment to specific locations). Merchants who had Scripts for any of these areas need a Functions replacement before June 30. The migration effort is real. Scripts could be written by any Ruby-comfortable developer. Functions require either Rust or AssemblyScript (for the best performance), the WASM compile toolchain, and familiarity with Shopify's input/output query shapes. For most mid-market merchants without a dedicated platform team, the pragmatic path is a third-party solution that ships a pre-built Function alongside its data layer — avoiding the need to operate a WASM toolchain internally.