Why doesn't my old trick for blocking a customer at checkout work anymore?
The script-based tricks from old blog posts and forum threads no longer work on Shopify's current checkout - here's what actually blocks or stops a problem customer today.
What's going on
A lot of merchants dealing with a repeat problem customer - chargebacks, harassment, abusing a return policy - found instructions years ago for "blocking" them: paste a snippet of JavaScript into checkout that checked the customer's email or address against a list and bounced them out before they could pay. That trick lived in the checkout.liquid template or in the "Additional scripts" box, and for a long time it sort of worked.
It doesn't anymore, and merchants who go looking for why usually can't find a clear answer - they just notice the blocked customer got straight through. The reason is that Shopify has been steadily locking down what runs during checkout. checkout.liquid has been phased out in favor of Shopify's extensible checkout, and the "Additional scripts" field now only fires on the post-purchase Thank You / order status page - after the order and payment are already done, which is exactly the moment a blocking script needs to run before to be useful.
So the old instructions aren't wrong because Shopify changed its mind about fraud - they're wrong because the specific technical door they walked through (arbitrary JavaScript injected into the checkout flow) has been closed for security and performance reasons that have nothing to do with fraud prevention specifically. Merchants are left assuming there's no way to stop a bad-actor customer, when there are several current, supported ways to do it - they just look different from a checkout script.
Why it happens
Shopify has been migrating every store to "checkout extensibility" - a version of checkout built from sandboxed, Shopify-reviewed extensions instead of an editable Liquid template merchants could inject arbitrary code into. checkout.liquid is deprecated and, for most stores, no longer editable at all. That single change is what silently broke almost every checkout-script blog trick from 2018-2023, including the customer-blocking one, and it happened without Shopify specifically flagging it as removing an anti-fraud tool merchants were relying on.
Separately, "Additional scripts" (found under Settings > Checkout) still exists, but it was always scoped to run on the order status/thank-you page, not during the payment step. Some old tutorials glossed over that distinction or relied on checkout.liquid workarounds that no longer exist, so the instructions read as if they'd stop a sale in progress when, at best, they only ever ran after it.
5 ways to fix it
Automate it with a free Shopify Flow, not a script
Build a Flow workflow triggered on "Order risk assessed" or "Order created." Add a condition that checks the customer's tags (or email/shipping address against a list you maintain) and, when it matches, have Flow automatically cancel the order, tag it "blocked-customer," and notify staff. Flow is included free on every Shopify plan and runs server-side, so it can't be disabled by browser extensions or ad blockers the way a checkout script could be. Tag the customer record itself (e.g. "do-not-sell") so you have one clean list to maintain instead of scattered email strings.
Lean on Shopify's built-in fraud analysis before you fulfill
Every order gets a risk level (low/medium/high) from Shopify's fraud analysis, visible on the order detail page and filterable in Orders. Set up a saved filter or Flow trigger for "high risk" orders so nothing risky slips through to fulfillment while you're manually reviewing. This won't stop a known bad actor from placing an order, but combined with the Flow cancellation above it closes the gap between "order placed" and "order shipped."
For a hard stop at checkout, use a Shopify Function (Validation)
If you genuinely need to block certain customers from completing checkout at all (not just cancel after the fact), the current supported mechanism is a Cart and Checkout Validation function. It runs server-side during checkout and can reject the cart before payment based on rules you define (matching customer email domain, tagged customer, etc.). This requires custom development (or a partner/developer to build it) and, on most plans, deploying it through a small custom app - it's the closest thing to what the old checkout.liquid trick used to fake, done the way Shopify actually supports today.
Deactivate the customer's account for login-based abuse
If the problem is a logged-in repeat customer rather than a guest checkout, you can deactivate their customer account from Customers > [customer] > Account settings so they can no longer log in or check out using saved details tied to that account. Keep in mind this doesn't stop the same person from checking out as a guest with a different email, so it's a partial fix on its own.
Consider a dedicated fraud/customer-blocking app if you need this constantly
If you're dealing with repeat fraud often enough that manual Flow/tag maintenance becomes a chore, the Shopify App Store has fraud-prevention and customer-blocking apps that maintain blocklists (email, IP, device) and enforce them at checkout automatically. Worth it only if this is a recurring operational headache rather than an occasional annoyance - for a handful of bad actors a year, the free Flow approach above is usually enough.
Bottom line
There's no single "block this customer" button in Shopify admin, and the old approach of pasting a JavaScript snippet into checkout to redirect unwanted customers has not worked since Shopify moved checkout to its extensible, script-restricted architecture - that instruction is outdated wherever you still find it online. The reliable path today is layered: use Shopify's native fraud-risk data and Flow automation to catch and cancel bad orders for free, add a custom checkout Validation function if you need a true pre-payment block, and only reach for a dedicated fraud-blocking app if repeat abuse is frequent enough to justify managing it as an ongoing feature rather than an occasional cleanup task.
Browse the rest of the problem library, run a free storefront scan to catch issues like this automatically, or email us and we'll work out a custom solution for it.