Every Shopify store has a second front door, and you cannot lock it

In April 2026 a Shopify merchant, posting on Reddit as DiscoverMyBusiness, described an attack on a store they manage that was generating more than 500 fake cart additions an hour. The abandoned checkout list filled with false names and addresses. Email flows fired at contacts who did not exist. The customer database bloated with accounts nobody had opened.

We have not seen the original post. What follows is the account given by the trade site ppc.land, which reported it in April 2026 after it circulated on LinkedIn. On that account, the response was comprehensive. Strict hCaptcha and reCAPTCHA controls were added to the add-to-cart and checkout flows rather than only to web forms. A premium bot-protection app was installed, configured to assess behaviour rather than IP addresses. Cloudflare was put into Challenge Mode with aggressive rate limiting on add-to-cart. Traffic from suspect countries and autonomous system numbers was blocked at the network layer. The out-of-stock products the bots appeared to be targeting were hidden.

The attack continued.

An inspection of the server logs produced the explanation, which the merchant put in one sentence: "The bots were not hitting our main domain."

Everything the merchant tried

The defensive stack matters, because each layer is individually reasonable and collectively useless against this particular attack.

The second front door

Every Shopify store is issued a permanent address at yourstore.myshopify.com. Connecting a custom domain does not retire it. The subdomain remains live, serves the same storefront, and reaches the same checkout.

It also routes through Shopify's own enterprise Cloudflare account rather than the merchant's. This is the mechanism as merchants and the trade reporting describe it, and we have not tested it. Rules built inside a merchant's Cloudflare account apply to traffic arriving at the merchant's hostname. Traffic arriving at the myshopify.com hostname is handled upstream, in infrastructure the merchant has no access to and cannot configure.

An informed reader will raise an objection here, and it deserves an answer we do not fully have. Once a custom domain is set primary, Shopify treats the myshopify.com address as a redirect domain and issues a 301 from it for ordinary storefront pages. So why does the bypass work at all? The likely answer is that a script requesting a cart permalink or posting to /cart/add is not performing an ordinary page load, and is not following redirects in any case. We could not establish from public documentation why the redirect does not cover the cart and checkout endpoints, and we did not put the question to Shopify before publication.

The bot does not need to load a product page, and in most cases does not. Shopify publishes cart permalink parameters, so a script can construct a URL containing a variant ID and a quantity and arrive at checkout directly. One merchant reported being shown exactly this pattern in their own logs, in the form store.myshopify.com/cart/46197058797731:1.

The gap has been under discussion on Shopify's own community forum since at least December 2025, in a thread whose title records its own duration: three months, no resolution. The merchant who opened it wrote that the traffic "completely bypass the protection we have in place on our custom domain, where we are already using Cloudflare WAF and bot protection," and added the observation that makes this a structural problem rather than a configuration error:

"What is most concerning is that merchants have no control at the Shopify domain level, and third-party security solutions cannot be applied to .myshopify.com. This leaves a significant security gap that merchants cannot mitigate on their own."

Shopify Community, thread opened December 2025

A merchant posting as Nancy88 reported in the same thread that Cloudflare's technical team had helped her test the problem and had "confirmed that the malicious crawlers were indeed coming through the Shopify domain, not my custom domain." That is the only third-party technical corroboration we found.

One distinction the sourcing does not support collapsing. The December 2025 thread describes crawler traffic; the March 2026 thread describes card testing; the April account describes cart floods and fake accounts. We treat them together because the routing fact is the same and merchants in all three describe the same controls failing for the same reason. The motives are not the same, and nobody has established that the operators are.

Why the cheapest product

The attack has a recognisable target selection, and it is not random. Merchants across several threads report the same thing: the bots go for the cheapest item in the catalogue, or the most recently added one.

The reason is mechanical. A card tester is not shopping. They hold a list of stolen card numbers and need to know which are still live, which requires a successful authorisation and nothing more. Small transactions clear issuer fraud checks at a higher rate than large ones, so the cheapest SKU produces the highest yield per attempt. New listings get picked up quickly once they go live, which is why the attack appears to track additions to the catalogue.

That produces an unusually clean fingerprint.

The damage is not confined to the checkout list. Merchants report each attempt creating a permanent abandoned checkout record, and Shopify provides no mechanism to remove them. One merchant, in a thread opened in March 2026, set out the position: the records cannot be deleted through the admin, through Shopify Flow, or through the API. Hundreds of fraudulent entries per day accumulate permanently, burying genuine abandoned carts and making recovery campaigns unreliable.

Those campaigns are the second-order problem, and they compound. An abandoned checkout carrying a real but non-consenting email address will be mailed by the store's own recovery flow, which is the mechanism examined in our second dispatch. A card-testing attack on the checkout therefore also degrades the sender reputation of a domain that had nothing to do with it.

The larger stake is financial, and it is the part merchants tend to discover late. A sustained wave generates per-authorisation and decline fees on every attempt. Holds that were never captured can still produce chargebacks when the real cardholder queries them. And a rising decline and chargeback ratio moves a store toward the card networks' fraud monitoring thresholds, where the end state is losing payment processing altogether. Measured against that, an untidy abandoned-checkout list is the least of it.

What Shopify says

Shopify has responded, in the sense that Simon Bolduc, a product manager on its checkout team, posted in the thread on 28 April 2026. Read it closely:

"We know fake abandoned checkouts caused by bots can be disruptive. To address this, we're continuing to strengthen our bot protections to reduce this activity at the source, rather than relying on removing these records manually. We recently rolled out additional measures that should help reduce the number of fake abandoned carts."

Simon Bolduc, product manager, Shopify checkout team, Shopify Community, 28 April 2026

Six words in that answer do the work: "rather than relying on removing these records manually." What the thread had asked for was a way to delete the records. The answer sets that approach aside and offers stronger upstream filtering instead.

Merchants replied with numbers. One, posting as David_Customer_Servi, responded the same day reporting abandoned checkouts up 18.4 percent over the previous four weeks against the period before it. A second, sebastien_v, cited the same figure on 8 June 2026 and wrote that the strengthened protections were not "landing on the ground yet."

On the underlying architecture, the position is firmer. Merchants who asked Shopify to apply IP or ASN blocks to their myshopify.com subdomain report being told the company does not apply custom WAF rules to individual subdomains. A merchant identifying as a Shopify Plus customer, quoted in the ppc.land account, described the response they received: Shopify "acknowledged the issue but refused to do anything about it. They said we should just delete the spam customers as soon as they came in."

The setting that works, and its price

One control stops the attack. Under Settings → Checkout, requiring customers to log in before checkout moves the barrier out of the network layer and into Shopify's application logic, where it is enforced regardless of which hostname the request arrived on. The bot reaches the login wall, cannot produce a verified customer token, and Shopify declines to create a checkout session.

The merchant in the April 2026 account described it as the only measure that fully worked, writing that it was "the ONLY one helped." We found no second first-hand account of it.

The cost is severe, and any recommendation that omits it is not worth taking. Guest checkout is how most small stores convert. help1.io, a Shopify consultancy that sells paid support sessions, reports that "one agency documented a 95% conversion drop" after enabling it. It names no agency, no store and no measurement period, and we could not corroborate the figure elsewhere. Treat it as a direction of travel rather than a measurement.

There is also a consequence merchants frequently miss. Shopify's documentation states that when sign-in before checkout is required, accelerated checkout buttons such as Apple Pay are hidden from the online store cart, precisely so they cannot be used to bypass the sign-in. Losing those buttons is likely part of why the conversion damage lands as hard as merchants describe. The setting additionally conflicts with Google Merchant Center's guest checkout requirement, which matters to any store running Shopping campaigns.

Between doing nothing and losing most of your conversion rate, there are four measures that reduce volume at lower cost:

• Switch payment capture to manual, understanding what it does and does not do. Under Settings → Payments. The authorisation still succeeds, so the tester still learns the card is live and your store remains exactly as useful to them. What manual capture buys is a window to cancel before funds move, which limits processing fees and chargebacks on captured payments. Treat it as damage limitation rather than deterrence, and note two costs: every genuine order now needs capturing by hand before its authorisation expires, and the holds still appear on real cardholders' statements, which can produce chargebacks on payments you never took.
• Change to the three-page checkout layout. Under Settings → Checkout → Configurations. The additional round trips defeat simpler scripts, and merchants who tried it report volume falling within a day or two, with more capable bots adapting after that. Check what your store can still select: Shopify's checkout extensibility migration deadline for non-Plus stores is 26 August 2026.
• Unpublish very cheap and zero-value products. Gift cards, $1 samples and $5 add-ons are the preferred targets precisely because small authorisations succeed more often.
• Turn off abandoned checkout emails for the duration. This protects your sending domain from the bounce load, and stops your own automation mailing strangers. Re-enable once the wave passes and the bounce rate settles.
• Add a theme-level host check. A Liquid condition on request.host can block or redirect storefront requests arriving on the myshopify.com hostname. It takes minutes and costs nothing. It does not cover checkout, which does not render your theme, so it will not stop the attack described here. It does reduce the storefront-side scraping and cart building that often precedes it.
• Watch declined transactions, not just abandoned checkouts. A card-testing wave shows as a spike in failed authorisations. A crawler or cart-spam wave does not. The two need different responses, and the abandoned checkout list alone will not tell them apart.

For the records already accumulated there is no remedy, and we said so above: they cannot be deleted through the admin, Flow or the API, and they are not taggable or archivable either. What you can do is tag the customer records these attacks generate, and add an exclusion rule in your email platform so the cohort never enters a recovery sequence. The abandoned checkout records themselves stay where they are.

What we can and cannot do

Spambuster is a storefront form filter. This attack does not use a storefront form. We cannot stop it, and no configuration of our app will stop it. Ask any vendor in our category who tells you otherwise which hostname their script runs on.

We state it plainly because the Shopify Community threads on this subject contain a great deal of app recommendation, and a merchant who buys a storefront bot blocker to solve a direct-to-checkout attack has spent money on the wrong layer. A contributor to the March 2026 thread put it this way: an app that blocks by IP or country at the storefront level "won't catch a bot that never touches your storefront. That's why the usual 'install a blocker' advice often disappoints for card testing specifically."

The boundary is worth drawing precisely, because it is easy to blur in our favour. The customer records a checkout-driven attack generates are created by checkout, from the address entered there. We do not stop those. What our app scores is the account registration form, and campaigns that post directly to it are a separate flood that frequently runs alongside the checkout one. If your Customers list is filling from checkout, no storefront app will help. If it is filling from registration, ours will. Establish which before spending anything.

For anyone arriving here mid-attack: work the list in section 05, starting with abandoned-checkout emails and manual capture, because those take ten minutes and stop the worst of it. Treat the login requirement as a decision about your conversion rate rather than a security fix. And do not spend the week several merchants in these threads describe spending, tuning a WAF that the traffic never reaches.

Merchants seeing the same pattern arrive through contact and newsletter forms rather than checkout should start with our first dispatch, which maps which forms Shopify's built-in protection actually covers.