Why Your Shopify Checkout Validation Needs to Move to Functions

If your store blocks checkout under certain conditions, a minimum order value, a COD limit, a pin code you refuse to ship to, or a quantity cap for wholesale buyers, there is a reasonable chance that rule is built on an API Shopify deprecated on 2 July 2026. Nothing has broken and no date has been announced. That combination is exactly why this gets ignored until it is urgent, so here is what changed and what the replacement actually gives you.

What Shopify deprecated

The changelog entry deprecates the useBuyerJourneyIntercept hook in checkout UI extensions along with the block_progress capability. Together those were how an extension stopped a shopper from advancing through checkout when a rule was not satisfied.

Two things about the timeline matter. Existing extensions continue to work on current and prior API versions, and Shopify says the API "will be removed in a future version" without naming one. So this is not a deadline in the way the 26 August checkout cutoff was a deadline. It is a direction, and the useful response is to plan rather than panic.

What replaces it

Business rules move to a cart and checkout validation Function. Instead of code running in the shopper's browser inside the checkout UI, the rule runs on Shopify's servers and blocks the order from completing when the cart does not meet your criteria.

Discount code rejection is handled separately. The discount Function API now supports rejecting a code with a custom message, so the common pattern of intercepting checkout purely to say "this code does not apply to sale items" has its own home now.

Why server side is genuinely better here

This is not Shopify moving things around for its own convenience. A rule enforced in the checkout UI only runs where that UI runs. A rule enforced in a Function runs everywhere the cart is evaluated.

That difference shows up immediately with express wallets. When a shopper taps Shop Pay, Apple Pay or Google Pay from the product page or cart, they skip the checkout steps your extension was watching. Any validation living in the UI simply does not fire. Shopify's own deprecation note calls out express wallets and agentic checkout as surfaces the Function approach covers, and agentic checkout is not hypothetical any more now that storefronts expose tools that agents can call.

If you have ever had a COD limit that customers bypassed by paying through a wallet, this is the explanation, and the fix is the migration.

What this looks like for an Indian store

The rules we see most often in this market map cleanly onto validation Functions.

• COD order value caps. Blocking cash on delivery above a threshold is the single most common rule, and the one most often bypassed through wallets today.
• Pin code and region restrictions. Refusing delivery where your courier performance is bad, which is a real lever on RTO cost.
• Minimum order value. Straightforward, and often the first Function a store writes.
• Wholesale quantity rules. Case pack multiples and minimum quantities for B2B buyers.
• New customer limits. Capping first order value, which Shopify's documentation gives as one of its own examples.

Where the error message actually appears

Worth knowing before you scope the work, because it changes your testing plan. Validation errors are exposed to the Storefront API's Cart object, in themes that use the cart template, and during checkout. Your rule stops being a checkout-only interruption and becomes something the cart can surface earlier.

That is an improvement for conversion. Telling someone at the cart that their pin code is not serviceable is far better than letting them enter an address and a payment method first. But it does mean your theme needs to display the error properly, and a theme that never had to render validation errors will need that work doing.

How many rules can you run

More than most stores need. Shopify raised the limit from 5 to 25 active functions per Function API on 19 May 2025, covering cart and checkout validations along with payment customizations, delivery customizations and fulfillment constraints.

The practical constraint is not the cap. It is that 25 separate rules become impossible to reason about. We would rather see four well-named Functions than fifteen overlapping ones where nobody can say which rule rejected an order.

What a rule can see, and how that changes the design

Moving a rule from the browser to the server changes how you have to think about it. A UI hook could react to whatever the shopper had typed at that moment. A Function evaluates the cart when Shopify asks it to, which is more reliable and less conversational.

In practice that pushes you toward rules expressed as facts about the cart rather than reactions to behaviour. "This cart contains a COD-ineligible product" works well. "The shopper just changed their mind about the delivery address for the third time" does not, and probably should not have been a rule in the first place.

Check the input schema in the Function API reference before you commit to a rule that depends on a specific field being present, particularly anything involving the customer record or the delivery address, since what is available to a Function is not always what was available to a checkout extension. Scoping a rule around a field that turns out to be absent is the most common way this work overruns.

What the migration usually costs in time

For a store with three or four straightforward rules, this is days rather than weeks. The Function itself is small. The time goes into three places that are easy to underestimate: writing down what the rules currently are, making the theme render errors properly at the cart, and testing each rule across standard checkout and every express wallet you accept.

The stores where this becomes a real project are the ones where nobody can produce a list of the rules in force. If your checkout behaviour is spread across two apps and an extension a former developer deployed, discovery is the project and the rebuild is the easy part.

How to approach the migration

Start by finding out whether you are affected at all, because plenty of stores enforce these rules through an app and have no custom extension. Check your installed apps for anything doing checkout validation, then check whether you have a custom checkout UI extension deployed.

If you do have custom rules, write down each rule in plain language before touching code. Most stores discover during this step that two or three rules are stale, added for a campaign that ended, and can simply be deleted. Then rebuild the surviving rules as Functions, and test each one against an express wallet path as well as standard checkout, because the wallet path is where the old implementation was quietly failing anyway.

Our walkthrough of building a first Function covers the toolchain, which is the same here.

What is useBuyerJourneyIntercept?

It was a hook in checkout UI extensions that let code inspect the checkout and stop the shopper from progressing when a business rule failed, paired with the block_progress capability. Shopify deprecated both on 2 July 2026 in favour of server-side validation Functions.

Is there a deadline to migrate off it?

No published date. Shopify states existing extensions keep working on current and prior API versions and that removal will come in a future version. Treat it as planned work for this quarter rather than an emergency, and do not let a vendor sell you urgency that Shopify has not announced.

Will my checkout rules stop working today?

No. Deprecated is not removed. The rules that are already failing today are the ones bypassed through express wallets, and that was true before this announcement. If you want to know whether you have that problem, place a test order through Shop Pay and see whether your rule fires.

Do validation Functions require Shopify Plus?

Cart and checkout validation is a Function API rather than a checkout UI surface, which is the distinction that matters, since checkout UI extensions on the information, shipping and payment steps are Plus only. Confirm your specific setup against current documentation before committing budget, because the plan boundaries around checkout have moved more than once.

Can I block COD orders above a certain value?

Yes, and this is one of the strongest reasons for Indian stores to do the migration properly. A validation Function evaluates the cart server side, so the rule holds whether the shopper goes through standard checkout or taps an express wallet. That closes the gap most COD caps currently have.

Get your checkout rules reviewed

Free rule audit. Email hello@exactwhy.com with subject "Checkout rules" and a list of the rules your checkout enforces. We tell you which are built on the deprecated API, which are already being bypassed through wallets, and which can simply be deleted. We respond within 4 hours.

Paid migration, Rs 40,000 to Rs 1.5 lakh. We rewrite your rules as validation Functions, make your theme render the errors properly at the cart, and test every rule against wallet and standard checkout paths.

Ongoing Shopify development, Rs 40,000 to Rs 1.5 lakh a month. For stores that would rather have deprecations handled while they are still cheap to handle.

The interesting part of this change is not the deprecation. It is that most stores enforcing a COD cap have a hole in it right now, and moving the rule server side closes it.