There is a specific flavour of this problem that makes merchants feel like they are going mad, and it goes like this. You are getting dozens or hundreds of fake abandoned checkouts a day. You install a bot blocker. The fake checkouts keep coming. You turn on CAPTCHA. They keep coming. You make name and address required in checkout settings. They keep coming. And the whole time, your storefront session count looks completely normal.
That last detail is the one that tells you what is going on. Your sessions look normal because these bots are not visiting your store.
What is actually happening
Shopify lets anyone build a URL that drops a product straight into a cart and lands on checkout. The format is public and documented, because it is genuinely useful — it is how merchants put “buy now” links in emails, ads and SMS.
A bot can use the same URL. It requests it, Shopify builds a cart, and the bot is standing in your checkout without ever having loaded your homepage, your product page, or your cart page.
Everything you installed to stop bots lives on those pages.
That is not a criticism of those apps. It is a description of where they run. A storefront bot blocker is JavaScript in your theme, or a check that fires when someone requests a page of your site. If the visitor never requests a page of your site, there is no moment at which that code executes. It is not that the app is bad at catching these. It is that the app is never invited.
The same applies to most of what people try next:
- CAPTCHA is a challenge presented on a page. No page, no challenge.
- IP and country blockers generally filter requests to your storefront. And these bots usually rotate addresses anyway, so you end up blocking one and seeing the next from somewhere else.
- Theme-level rate limiting counts page views. There are none to count.
- “Require name and address in checkout” does not help either, and the reason is worth understanding properly — see below.
Why making fields required does nothing
This one catches almost everybody, because it feels like it should work.
Shopify creates the abandoned-checkout record when the email address is captured, partway through checkout. The shipping address and name are collected after that, and validated after that. So by the time your required-field rule has anything to say, the record you are complaining about already exists.
The bot supplies an email, Shopify writes the record, and the bot leaves. It never reaches the step your rule guards.
This is also why so many merchants report that an app “didn’t do anything” — they were measuring the count of abandoned checkouts in their admin, which is a number almost nothing can prevent, rather than the downstream damage, which several things can.
The damage is downstream, and that is where to aim
Separate the symptom from the harm. The symptom is a list of junk checkouts in your admin. Annoying, but it does not cost you money.
The harm is what that junk touches:
- Your email tool. Abandoned-cart recovery flows fire at fake addresses. Those addresses bounce or sit dead, your sender reputation drops, and your real recovery emails start landing in spam. This is the expensive one and almost nobody notices it until deliverability tanks.
- Your customer list. Junk profiles inflate your list size, which costs money at most ESPs and wrecks your segmentation.
- Your analytics and ad platforms. Bot sessions fire pixel events. Your conversion rate drops for no reason, your lookalike audiences get trained on noise, and your ROAS numbers stop meaning anything.
- Your payment relationship. If the bots are card testing rather than just squatting, you are accumulating declines and potential disputes against your processor’s risk thresholds.
If you aim at the symptom, you will be disappointed by everything you try. If you aim at the harm, several things work well.
Two shapes of fix, and they are not equivalent
Almost every tool in this category does one of two things.
Score the checkout after it exists. Look at the email, the address, the timing, the IP, and guess. This is what most bot apps do, and it is what the storefront apps fall back to when they realise they cannot see the request. It works in proportion to how sloppy the bot is. Against a bot that supplies a plausible-looking email and a real street address, a scorer has very little to go on — and the checkout already exists either way, because you scored it after the fact.
Attest the real sessions instead. Invert the question. Rather than trying to enumerate what a bot looks like — an arms race you lose slowly — have genuine storefront sessions carry proof that they happened, and check for that proof later in checkout. A real shopper who browsed your store has it. A request that materialised directly at checkout does not, because it was never on your storefront to pick it up.
The second shape is strictly better against this specific attack, for a boring structural reason: it does not depend on the bot being detectable. It depends on the bot not having done something it genuinely did not do.
It is not magic, and it has real edges. Anything that legitimately arrives at checkout without touching your storefront looks the same as a bot: a bare cart permalink in an email campaign, an external buy button, a headless storefront. Any honest implementation has to decide what to do about those rather than pretend they do not exist.
What you can do today, for free
Before buying anything:
1. Stop emailing them. This is the highest-value thing on this page and it costs nothing. In Klaviyo, Omnisend, Mailchimp or Shopify Email, add a condition to your abandoned-cart flow so it only sends when the checkout has a shipping address or a customer name. Bot checkouts have neither. Your recovery flow stops firing at fake addresses immediately, and your sender reputation stops bleeding.
2. Keep them out of your list. Suppress or tag profiles created from abandoned checkouts that have no name. Most ESPs can do this with a segment condition.
3. Exclude them from reporting. Shopify’s own bot-session filter helps with Shopify’s reports. It does not touch GA4, Meta or your ESP, so do not expect it to clean those.
4. Collect evidence before you contact support. Grab a handful of checkout IDs and timestamps. Shopify support can see the traffic source and has throttled these waves for specific stores.
5. Wait a bit. These waves often subside after one to three weeks on their own. That is not a reason to do nothing, but it is a reason to be sceptical of any tool you installed three days before the wave ended — including ours. Attribution is genuinely hard here, and a lot of the glowing reviews you will read are measuring a coincidence.
FAQ
Why do my sessions look normal if I’m getting hundreds of fake checkouts?
Because the bots never load a page of your storefront. Sessions count storefront visits. Checkout is hosted by Shopify on separate infrastructure, so a request that goes straight there produces a checkout without producing a session. The mismatch between the two numbers is actually a good diagnostic: normal sessions plus abnormal checkouts is close to a signature for this attack.
Can I block them with Cloudflare or a WAF?
Partly, and with a real trade-off. Some tools work by having you point your domain’s DNS at their network so traffic passes through them before reaching Shopify. That does put a filter in front of checkout, which storefront apps cannot do. It also means routing all of your store’s traffic through a third party, adding a dependency during your highest-traffic sales, and handing another company your customers’ request data. That may be a trade you want. It should at least be a trade you make deliberately.
Will Shopify fix this at the platform level?
Shopify has shipped improvements, and they have mostly targeted card testing — bots that attempt payment. The squatting pattern, where a bot creates a checkout and never attempts payment, is harder for Shopify to act on because it is not obviously distinguishable from a shopper who changed their mind. Do not plan around a platform fix arriving.
Should I just ignore it?
If your email flows are filtered, your reporting is clean and nothing is hitting your processor, then honestly yes. A list of junk checkouts you never act on is cosmetic. Fix the downstream damage and the admin clutter stops mattering.
They’re hitting a sold-out product with an order minimum. How?
The permalink does not check either. It builds the cart first; stock and minimums are enforced later in the flow, and the bot never gets that far. This is another reason the abandoned-checkout record is not preventable by configuration — it is created before most of your rules apply.
Where Doorman fits
Doorman is a Shopify checkout-layer bot blocker, and it takes the second shape above: real storefront sessions are attested, and the checkout is validated server-side inside Shopify rather than scored after the fact. It runs on any Shopify plan and needs no DNS change.
Being precise about what that does and does not do, because this post has spent 2,000 words arguing that precision is the whole problem here:
- It does not stop fake abandoned-checkout records from appearing in your admin. Nothing running inside Shopify can, for the reason explained above — the record is created when the email is captured, before a checkout validation runs. Any tool claiming otherwise is either working outside Shopify or is overstating.
- It does block the completed fraudulent order, which is the card-testing case, and that is a layer storefront apps structurally cannot reach.
- It keeps the fakes out of your Klaviyo recovery flows, which is the deliverability harm — the one that actually costs money.
If the free fixes above hold for you, use them and keep your money. If the pollution is still reaching your email tool and your pixel after you have done all five, that is the gap this is built to close.
The founding cohort is open — doormanapp.com.