Shopify Functions: custom discounts, delivery, payment and cart logic

Shopify Functions let you replace parts of Shopify's backend logic with your own code: discounts Shopify doesn't offer natively, bundles, rules for which delivery and payment options appear, and validation that stops an invalid order at checkout. Functions are compiled to WebAssembly, ship inside an app, and run on Shopify's infrastructure at the right moment in the cart and checkout. They are also the replacement for Shopify Scripts, which stopped running on June 30, 2026.

The Function APIs

Shopify allows up to 25 active functions per Function API for payment customizations, delivery customizations, validations and fulfillment constraints, so unrelated rules can live in separate, simpler functions.

Plan requirements

• Public apps from the App Store that contain Functions: usable on any plan.
• Custom apps that contain Functions: usable only on Shopify Plus.
• Some capabilities are Plus-only inside an API. For example, a payment customization on a non-Plus store hides the whole payment method rather than an individual placement.
• Network access from Functions is available primarily to Shopify for enterprises merchants, for specific Function APIs.

This is why the same requirement may be a custom app for a Plus store and a public app for a store on another plan.

How a Function is built

A Function is an extension inside an app, generated with Shopify CLI:

shopify app generate extension --template discount

It has three parts: configuration, an input query that declares the data it needs, and the run code that returns operations. Here is a tiered order discount that reads its tiers from a metafield, so merchants can change thresholds without a deploy.

Configuration

# extensions/tiered-discount/shopify.extension.toml
api_version = "2026-07"

[[extensions]]
name = "Tiered order discount"
handle = "tiered-discount"
type = "function"

[[extensions.targeting]]
target = "cart.lines.discounts.generate.run"
input_query = "src/cart_lines_discounts_generate_run.graphql"
export = "cart-lines-discounts-generate-run"

[extensions.build]
command = ""
path = "dist/function.wasm"

Input query

# src/cart_lines_discounts_generate_run.graphql
query CartInput {
  cart {
    cost {
      subtotalAmount {
        amount
      }
    }
  }
  discount {
    discountClasses
    metafield(namespace: "$app", key: "function-configuration") {
      jsonValue
    }
  }
}

Run function

// src/cart_lines_discounts_generate_run.js
import {DiscountClass, OrderDiscountSelectionStrategy} from '../generated/api';

// Config example: {"tiers":[{"minSubtotal":100,"percentage":5},{"minSubtotal":250,"percentage":10}]}
export function cartLinesDiscountsGenerateRun(input) {
  if (!input.discount.discountClasses.includes(DiscountClass.Order)) {
    return {operations: []};
  }

  const tiers = input.discount.metafield?.jsonValue?.tiers ?? [];
  const subtotal = Number(input.cart.cost.subtotalAmount.amount);
  const tier = tiers
    .filter((t) => subtotal >= t.minSubtotal)
    .sort((a, b) => b.percentage - a.percentage)[0];

  if (!tier) return {operations: []};

  return {
    operations: [
      {
        orderDiscountsAdd: {
          candidates: [
            {
              message: `${tier.percentage}% off`,
              targets: [{orderSubtotal: {excludedCartLineIds: []}}],
              value: {percentage: {value: tier.percentage}},
            },
          ],
          selectionStrategy: OrderDiscountSelectionStrategy.First,
        },
      },
    ],
  };
}

The function never fetches data and never touches the cart directly. Shopify gives it exactly what the input query asks for, and applies the operations it returns. That's what makes Functions fast and safe to run at checkout scale.

Validation, delivery and payment: the same shape

The other APIs follow the same pattern with different targets and operations:

• Validation (cart.validations.generate.run) returns validationAdd operations with error messages and targets such as $.cart. Its input includes the buyer journey step, so you can validate only at checkout.
• Delivery customization (cart.delivery-options.transform.run) returns operations such as deliveryOptionHide for a delivery option handle.
• Payment customization (cart.payment-methods.transform.run) returns operations such as paymentMethodHide for a payment method ID.
• Cart transform (cart.transform.run) returns expand and merge operations, reading bundle definitions from metafields.

Configuration: metafields, not code

Well-built Functions keep their rules in metafields on the discount, customization or shop: thresholds, tiers, excluded products, customer tags. An admin UI in your app, or an admin UI extension, lets the merchant edit them. The function code stays the same while the business changes its rules.

Limits to design around

• Functions have no network access by default. Put the data they need into metafields ahead of time.
• Execution has resource limits, so keep input queries small and logic simple. Request only the fields you use.
• Functions are deterministic: same input, same output. No clocks, randomness or state between runs. Use metafields updated by your app for time-based rules.
• Some behaviours are fixed by Shopify. For example, wallets can't be renamed by a payment customization, and payment customizations don't run in POS.

Testing and rollout

• Unit-test the run function with JSON input fixtures, which is easy because it's a pure function.
• Use shopify app function run and the function logs in the dashboard to replay real inputs.
• Deploy, then activate the discount or customization for a test segment first, such as a customer tag or a single market, before turning it on for everyone.

Decision checklist

• Which Function API matches the requirement? Could a native setting do it?
• Is the store on Plus (custom app possible) or not (public app needed)?
• What data does the function need, and which metafields will hold it?
• Who will change the rules, and through what UI?
• How will you test it with real carts before launch?