WASM Checkout (WebAssembly at Checkout)

WASM checkout refers to executing merchant-defined logic during checkout as WebAssembly modules. The most concrete example is Shopify Functions: developers write discount, validation, delivery, payment, or cart-transform logic in Rust, JavaScript, or another language that compiles to WebAssembly, and Shopify runs the compiled module inside its own checkout infrastructure. Shopify moved to this model to replace Shopify Scripts, its earlier Ruby-based surface, which stopped executing on June 30, 2026. WebAssembly suits this job for three reasons: it executes quickly and predictably, which matters for anything inserted into checkout; it is sandboxed, so one merchant's code cannot reach the file system or other tenants; and it is language-flexible, so one runtime can serve many developers. The trade-offs against Scripts are mostly about effort and data. Functions can do more than Scripts did and are the supported path, but they require a developer comfortable with the toolchain and Shopify's input and output schemas. They also run under strict resource limits and, for most function types, cannot call external systems during execution, so any data a rule depends on, such as cost or margin thresholds, has to be staged ahead of time (for example in metafields) and kept current by a separate process. For margin governance, that means a WASM-based checkout rule can only be as accurate as the data that was staged for it. Agentis does not use WebAssembly or Shopify Functions and does not run in checkout. It reads each order after it is placed, computes true net margin within 60 seconds from live store data, NetSuite COGS, freight, fees, and FX, and flags the order or holds it before fulfillment under merchant-approved rules. WASM checkout and a post-order margin check answer different questions: the first shapes what a buyer can submit, the second decides whether a submitted order should ship.