Shopify’s own documentation on Functions is thorough on the technical side, how to scaffold a function, what the input/output schema looks like, how to deploy via the CLI, but it’s thin on the part most merchants actually want to know: what does this look like when it solves a real business problem?
Shopify Functions replaced the older Shopify Scripts as the way Plus (and now some non-Plus) merchants customise checkout logic, discounts, shipping rates, payment method availability, and validation rules, using server-side code that runs inside Shopify’s infrastructure rather than a theme. If you’ve read the reference docs and are still not quite sure when you’d actually reach for a Function instead of an app, this is the gap this post is written to fill, with concrete examples relevant to Australian merchants specifically.
What Shopify Functions Actually Replace
Before the examples, a quick grounding point because this trips people up: Functions are not a theme customisation tool. They don’t touch your storefront’s visual design. They run at specific extension points Shopify defines, product discounts, order discounts, shipping discounts, delivery customisation, payment customisation, and cart/checkout validation, and they return a structured decision (apply this discount, hide this shipping method, block this payment option) based on logic you write.
This distinction matters because merchants sometimes go looking for a “function” to solve a problem that’s actually a theme or app problem, and vice versa. If you’re trying to change how something looks, that’s Liquid and theme code. If you’re trying to change what happens at checkout based on conditional logic, that’s the Functions territory.
Example 1: Tiered Wholesale Discounts Based on Order Quantity and Customer Tags
This is probably the single most common reason Australian B2B and wholesale Shopify Plus merchants end up building a custom Function. The scenario: you sell to both retail customers and wholesale accounts through the same storefront, and wholesale customers get different discount tiers depending on order quantity thresholds, say, 5% off at 10+ units, 10% off at 25+ units, 15% off at 50+ units, but only if they’re tagged as an approved wholesale account.
Native Shopify discount codes can’t do this cleanly because they don’t have quantity-tiered logic tied to a customer tag out of the box. A discount Function can:
- Check whether the customer has a specific tag (e.g.
wholesale-approved) via the customer input - Sum the quantity of eligible line items in the cart
- Apply the correct percentage discount to the eligible lines based on which quantity band the order falls into
- Optionally exclude specific product types (e.g. sale stock or gift cards) from the tiered calculation
This is a genuinely common ask for stores expanding into B2B and wholesale selling, where retail and trade pricing need to coexist on one storefront without running two separate stores.
Example 2: Regional Shipping Rules for Australian Freight Realities
Australia’s shipping geography creates problems most Shopify Functions examples (written for US or UK merchants) don’t address: WA and NT freight costs and delivery times are materially different from the east coast, and many merchants want to reflect that without maintaining a spreadsheet of postcode exceptions inside a shipping app.
A delivery customisation Function can:
- Read the destination postcode or state/territory from the checkout input
- Hide or reorder shipping methods based on region, for example, hiding a “next day” option for regional WA or remote NT postcodes where it genuinely can’t be fulfilled, rather than letting a customer select a promise you can’t keep
- Adjust which carrier options are presented for bulky or heavy items differently by state, where freight partners vary by region
This is a case where the Function is really doing customer experience and trust work as much as logistics work, showing a delivery promise that’s actually achievable for a customer’s postcode avoids the much bigger problem of failed delivery expectations and support tickets after the fact. This kind of postcode-aware logic typically pairs with your carrier integration setup, worth reviewing alongside Australia Post integration if freight zones are a live issue for your store.
Example 3: BOGO and Complex Bundle Logic That Discount Codes Can’t Express Cleanly
“Buy one get one” and mix-and-match bundle logic is one of the most requested promotional mechanics, and it’s also one of the most awkward to build with standard Shopify discount codes once the rules get specific. A basic BOGO (buy 2 get 1 free of the same item) is doable natively. But real promotions are messier:
- “Buy any 2 items from Collection A, get the cheapest one free”, the cheapest, not a fixed item, requires calculation logic
- “Buy 3, get 20% off the whole set” only when all 3 are from a specific bundle-eligible tag
- Excluding already-discounted or clearance items from stacking with the bundle offer
A product discount Function can evaluate the cart contents against these rules and apply the calculated discount to the correct line items automatically, which is far more reliable than relying on staff to manually apply codes or hoping customers find and correctly use a promo code.
Example 4: Payment Method Customisation for Local Payment Preferences
Australian consumers have specific payment method expectations, Afterpay and Zip are near-standard for certain categories (fashion, beauty, homewares), and some B2B buyers need invoice-based terms rather than instant card payment. A payment customisation Function can:
- Hide buy-now-pay-later options for B2B/wholesale customers where instalment payment doesn’t make sense for a $4,000 trade order
- Hide BNPL options entirely for orders below or above a value threshold where the BNPL provider’s own terms don’t apply
- Reorder payment methods so the most relevant option for a given customer segment appears first
Scripts vs Functions: Why This Matters if You’re on Legacy Code
If your store still has Shopify Scripts running (the older Ruby-based checkout customisation system), it’s worth knowing Scripts have been deprecated and Shopify has been actively pushing merchants toward Functions, which run on a different, faster infrastructure and use a defined schema rather than arbitrary Ruby code. If you’re not sure whether your store still depends on legacy Scripts, that’s a genuine audit worth doing before Shopify forces the migration on a timeline that isn’t yours to control.
Example 5: Cart and Checkout Validation for Business Rules
Beyond discounts, shipping, and payments, a fifth Function category, validation, is worth knowing about because it solves a different class of problem: stopping an order from proceeding at all under certain conditions, rather than changing pricing or available options.
Real Australian examples this applies to:
- Minimum order value enforcement for wholesale accounts, blocking checkout if a tagged wholesale customer’s cart falls below an agreed minimum order value, with a clear validation message explaining why, rather than allowing the order through and chasing it up manually afterward.
- Age-restricted or regulated product checks, for categories like certain supplements, vaping accessories, or knives, where a validation Function can require confirmation or block checkout entirely based on product tags in the cart, supporting compliance obligations that a generic “are you 18+” checkbox on a landing page doesn’t reliably enforce at the actual point of purchase.
- Geographic restriction enforcement, blocking or flagging checkout for shipping addresses outside your genuine fulfilment area, where a general shipping rate absence isn’t enough because the customer could otherwise reach payment with no valid delivery option ever calculated.
Validation Functions are a good example of the broader point about Functions generally: they exist because Shopify’s native settings, while extensive, can’t anticipate every specific business rule a merchant needs enforced automatically, consistently, and without relying on staff to catch it manually.
Where the Line Sits Between “Use an App” and “Build a Function”
Not every custom requirement needs a bespoke Function, and it’s worth being honest about that before committing development budget to a build. A useful way to think about it:
- If an established, well-reviewed app already does close to what you need, it’s usually more cost-effective to configure that app than to build and maintain custom code, apps get updated for Shopify platform changes on the vendor’s timeline, whereas a custom Function is your responsibility to maintain going forward.
- If your requirement is genuinely specific to your business (a particular wholesale tiering structure, a regional shipping rule tied to your specific fulfilment footprint, a bundle promotion mechanic no app quite replicates), that’s where a custom Function earns its cost, because no off-the-shelf app is going to match a rule that specific without extensive workarounds.
- If you’re not sure which category you’re in, it’s worth a proper scoping conversation before committing, a poorly-scoped custom build that an app could have handled is wasted development spend, and a workaround-heavy app configuration that a Function could have solved cleanly is ongoing operational friction.
How a Function Actually Gets Built and Deployed
For context on the general shape of the work, since this is different from a typical theme change:
- Define the exact business rule in plain English first, “10% off orders of 25+ units for tagged wholesale customers, excluding clearance items”, before any code is written. Ambiguity here is the most common cause of rebuilds.
- Scaffold the Function using the Shopify CLI, choosing the correct extension target (product discount, shipping, payment, etc.)
- Write and test the logic, typically in Rust, JavaScript, or another supported language that compiles to WebAssembly, using Shopify’s local testing tools before deploying
- Deploy to a development store first and test with real cart scenarios, including edge cases (empty cart, single item, mixed eligible/ineligible items)
- Publish and activate the Function through the Shopify admin, attaching it to a discount or delivery/payment customisation record
- Monitor after launch, checkout-level logic errors are high-visibility because they affect every customer at the point of purchase, so this isn’t a “set and forget” deployment
Because Functions run at checkout and directly affect pricing, shipping, and payment availability for every customer, this is genuinely not a place to learn by trial and error on a live store, a bug in discount logic can either cost you margin at scale or block customers from checking out entirely. If your store needs custom checkout logic like this, it’s worth scoping with a team that builds on Shopify Plus development regularly, since Functions require both the technical build and an understanding of how Shopify’s checkout extension points interact with the rest of your store.
FAQ
Do I need Shopify Plus to use Shopify Functions?
Historically Functions were a Plus-exclusive capability, though Shopify has been expanding access to certain Function types on standard plans over time. Check current plan-level availability for the specific extension type (discounts, shipping, payments) you need, since access has changed as Shopify rolls this out more broadly.
Can Shopify Functions replace all of my discount apps?
Not necessarily, Functions are best for logic that’s specific to your business rules and not well served by existing apps. If an established app already does exactly what you need reliably, a custom Function is extra maintenance overhead you may not need. Functions earn their keep when your discount or shipping logic is genuinely non-standard.
What language are Shopify Functions written in?
Functions are typically written in languages that compile to WebAssembly, with Shopify’s tooling supporting options such as JavaScript/TypeScript and Rust. The right choice generally depends on your development team’s existing skillset and the complexity of the logic.
Will my existing Shopify Scripts stop working?
Scripts have been deprecated in favour of Functions, and Shopify has communicated migration timelines to affected merchants directly. If you’re unsure whether your store relies on Scripts, check your admin for legacy script editor usage or ask your development team to audit it before Shopify’s cutover forces an urgent rebuild.
How long does it take to build a custom Shopify Function?
It depends heavily on the complexity of the business logic and how many edge cases need testing, a simple quantity-tiered discount is a much smaller job than multi-condition bundle logic with exclusions. Treat the plain-English rule definition step as the real time investment; the build itself moves faster once the rules are unambiguous.
Want This Built Properly the First Time?
If you’ve got a discount, shipping, or payment rule that standard Shopify settings and apps can’t express cleanly, book a call and we’ll help you work out whether a custom Function is the right fit before you commit development time to it.
