Shopify Scripts stopped running on June 30, 2026. If you are reading this after that date and your custom pricing logic disappeared, you are not alone. If you are reading this before and still have not migrated, the edit lock already kicked in on April 15 and you cannot modify your Scripts anymore. Either way, the only path forward is Shopify Functions.
This is not the general checkout extensibility guide (we wrote that one here). This is the deep technical guide specifically for enterprise brands that used Shopify Scripts for complex pricing logic: tiered discounts, customer-group pricing, volume breaks, conditional free shipping, B2B contract pricing, and payment method restrictions. The stuff that actually makes enterprise commerce work.
What Shopify Scripts Did (and Why Functions Work Differently)
Scripts were Ruby snippets that ran inside the checkout process. They were simple: write some Ruby, test it in Script Editor, deploy. The simplicity was the appeal and the limitation.
Functions are fundamentally different. They run in a WebAssembly sandbox, they are written in JavaScript or Rust, they deploy as part of a Shopify app, and they execute server-side with strict performance constraints. The architectural shift matters because it changes how you think about pricing logic.
| Dimension | Shopify Scripts | Shopify Functions |
|---|---|---|
| Language | Ruby (Script Editor) | JavaScript or Rust (compiled to Wasm) |
| Deployment | Script Editor in admin | Deployed as part of a custom Shopify app |
| Execution | Single runtime, limited sandbox | WebAssembly sandbox, strict 11ms instruction limit |
| Data access | Cart object, customer object, limited metafields | GraphQL input queries, metafields, metaobjects, external data via cart attributes |
| Scope | Line item Scripts, shipping Scripts, payment Scripts | Discount Functions, Delivery Functions, Payment Functions, Cart Transform, Fulfillment Constraints, and more |
| Merchant control | Script Editor (Plus only) | App settings UI you build, or Shopify's automatic discount interface |
| Performance ceiling | Generous (but unscalable) | 11ms instruction limit, optimised for high-throughput checkout |
The key insight: Functions are more powerful than Scripts but require more upfront investment. You are not writing a script in a text box anymore. You are building and deploying an app. For enterprise brands with complex pricing, this is actually better because it gives you version control, testing, staging environments, and proper CI/CD. But it changes the cost profile of the work.
The Five Enterprise Pricing Patterns
Most enterprise pricing logic falls into five patterns. Here is how each one translates from Scripts to Functions.
1. Tiered volume discounts
Script version: "Buy 10+, get 15% off. Buy 25+, get 25% off. Buy 100+, get 35% off."
Function version: A Discount Function that reads the cart line quantities, matches them against tier thresholds stored in metafields (so the merchandising team can adjust tiers without a developer), and returns the appropriate percentage discount. The key difference is that the tier configuration lives in metafields on the product or a metaobject, not hardcoded in the script.
This is a clean migration. The logic is straightforward. The complexity is in building the merchant-facing UI that lets your merchandising team configure tiers without filing a dev ticket every time pricing changes.
2. Customer-group specific pricing
Script version: "VIP customers get 20% off everything. Trade customers get wholesale pricing. Staff get 40% off."
Function version: For B2B, this is now native. Shopify Plus B2B catalogues handle customer-specific pricing through company catalogues with fixed prices or percentage adjustments. For DTC customer groups (VIP tiers, loyalty programmes), a Discount Function reads the customer's tags or metafields and applies the appropriate discount.
The migration decision: if your customer groups map cleanly to Shopify's B2B company structure, use native B2B catalogues. If they are DTC segments (loyalty tiers, employee discounts), build a Discount Function. Many enterprise brands need both.
3. Complex conditional discounts
Script version: "Buy any 3 items from Collection A, get the cheapest one free. Spend over $500 on Collection B, get free express shipping. Buy from Collection C and Collection D together, get 10% off both."
Function version: These multi-condition discounts are where Functions shine over Scripts. Functions can query product metafields, collection memberships, and cart attributes in a single input query, then return complex discount allocations. The 11ms execution limit sounds tight, but for discount logic it is generous because you are doing arithmetic, not I/O.
The trap: do not build one monolithic Function that handles every discount rule. Build composable Functions, one per discount type, and stack them. Shopify's discount combination rules (introduced in 2024) let you control how multiple discounts interact: which stack, which are exclusive, which take priority.
4. Payment method restrictions
Script version: "Hide Afterpay for orders over $2,000. Show invoice payment only for B2B customers. Remove credit card option for flagged accounts."
Function version: Payment Customization Functions filter available payment methods based on cart contents, customer attributes, or order value. The function receives the full list of available payment methods and returns which ones to hide or reorder.
Enterprise nuance: if you are running B2B with payment terms (net-30, net-60), this interacts with Shopify's native B2B payment terms feature. Map the overlap before building custom logic that conflicts with native functionality.
5. Dynamic shipping rules
Script version: "Free shipping on orders over $150. Hide express shipping for oversized items. Add a $15 handling fee for hazmat products."
Function version: Delivery Customization Functions modify the shipping options presented at checkout. They can hide, rename, or reorder delivery options based on cart contents, destination, or customer attributes. For adding fees, Cart Transform Functions can add line items that represent handling charges.
The limitation: Functions cannot create new shipping rates. They can only modify rates returned by your shipping rate provider. If you need to generate custom rates (calculated shipping based on proprietary logic), you need a Carrier Service API integration, not a Function.
The Architecture That Keeps Working
Most agencies migrate Scripts to Functions as a one-time project: build, deploy, done. The same build-and-forget pattern that created the problem in the first place. Three months later, Shopify ships a new Function API version, your competitor launches a pricing strategy you cannot match, or your merchandising team needs a new discount type and cannot get a developer for six weeks.
We approach Functions as part of a living ecosystem. The difference:
| Dimension | Traditional approach | Living ecosystem approach |
|---|---|---|
| Deployment | Build, deploy, walk away | CI/CD pipeline with staging environment. Every Function change tested against real cart scenarios before production. |
| Monitoring | You find out a Function broke when customers complain | AI monitors discount application rates, checkout completion rates, and Function error logs. Anomalies flagged in real-time. |
| API updates | You miss the deprecation notice. Function stops working. | Every Shopify API update evaluated against your Functions. Updates applied proactively before deprecation deadlines. |
| Merchandising agility | New discount type = new dev project (4-8 week lead time) | Function architecture built for composability. New discount types deploy in days, not months. |
| Performance | Built once, never profiled again | Function execution times monitored. Performance regressions caught before they impact checkout conversion. |
Your checkout logic is the most revenue-sensitive code in your entire stack. A Function that silently fails to apply a wholesale discount costs you the margin on every B2B order until someone notices. In a living ecosystem, someone is always watching.
Common Migration Mistakes
We have audited enough post-migration Function deployments to see the patterns. Here are the mistakes that cost enterprise brands the most:
Mistake 1: One giant Function
Building a single Discount Function that contains all your pricing logic. When one rule needs to change, you risk breaking everything else. Build one Function per discount type. Use Shopify's discount combination settings to control how they interact.
Mistake 2: Hardcoding business rules
Embedding tier thresholds, discount percentages, and eligibility rules directly in the Function code. Every change requires a developer and a deployment. Store configuration in metafields or metaobjects. Build a merchant-facing settings UI in your app. Your merchandising team should be able to adjust pricing rules without a pull request.
Mistake 3: Ignoring the execution limit
The 11ms instruction limit is not a suggestion. If your Function exceeds it, it silently fails and the discount is not applied. This is catastrophic for pricing logic because the customer sees the wrong price and either bounces (if it is too high) or you eat the margin (if a discount should have been restricted). Profile your Functions under realistic cart sizes. A Function that runs in 3ms with 5 items might hit 15ms with 50 items.
Mistake 4: Not testing discount stacking
Shopify allows multiple discounts to combine. If you have a volume discount Function, a loyalty discount Function, and a promotional code, you need to define combination rules explicitly. Otherwise a customer can stack all three and your margin evaporates. Test every combination before launch.
Mistake 5: Forgetting the merchant experience
Functions run as part of a Shopify app. That app needs a UI. If your merchandising team cannot see which Functions are active, what rules they apply, and how they interact, they will not trust the system. Build a dashboard, not just a Function.
Investment Ranges
The cost of a Scripts-to-Functions migration depends on the complexity of your pricing logic, not the number of scripts. Here are realistic ranges:
| Complexity | Typical scenario | Investment range | Timeline |
|---|---|---|---|
| Standard | 2-3 discount types, simple tiered pricing, basic payment restrictions | $25,000-$45,000 | 4-6 weeks |
| Complex | 5-8 discount types, B2B + DTC pricing, complex conditional logic, custom merchant UI | $45,000-$85,000 | 6-10 weeks |
| Enterprise | 10+ discount types, multi-market pricing, ERP-driven pricing, advanced stacking rules, full merchant dashboard | $85,000-$150,000 | 10-16 weeks |
These include the Function development, merchant-facing app UI, testing, staging deployment, and 90 days of post-launch monitoring. The ongoing monitoring and maintenance as part of a living ecosystem retainer adds $2,000-$5,000/month depending on the number of active Functions and the frequency of pricing rule changes.
When Functions Are Not the Answer
Functions solve most enterprise pricing problems but not all of them:
- Real-time external pricing: If your pricing comes from an external system that needs to be queried in real-time (commodity pricing, competitive price matching), Functions cannot make HTTP calls. You need a different architecture: pre-sync prices to metafields via a scheduled job, or use the Cart Transform API with pre-fetched data.
- Complex CPQ (configure-price-quote): If your checkout involves a product configurator that generates custom pricing based on dozens of input parameters, the 11ms limit may be too restrictive. Consider a hybrid approach: CPQ logic runs externally, results are passed to the checkout via cart attributes, and a lightweight Function applies the pre-calculated price.
- Multi-currency pricing with market-specific rules: If each market has entirely different pricing logic (not just currency conversion), you may need market-specific Functions. Shopify's Markets API supports this, but the complexity scales linearly with the number of markets.
Next Steps
If your Shopify Plus store relied on Scripts for pricing logic and you have not migrated yet, the clock is past zero. If your Scripts already stopped working, we can do an emergency migration in 3-4 weeks for standard complexity. If you are planning ahead for a more complex implementation, start the conversation now.
We will audit your current pricing logic, map each Script to its Function equivalent, identify where native Shopify features (B2B catalogues, automatic discounts, Markets) can replace custom code, and give you a straight estimate.