Card-testing bot flooding abandoned checkouts on Shopify Plus

[notavegan]

We run a Shopify Plus store on Shopify Payments, and a card-testing bot has been hitting our checkout since June. It escalated hard this month. We went from about 130 abandoned checkouts in all of August to more than 11,000 since September 1st, peaking near 3,800 in a single day. When we pulled a 90-day export, roughly 94% of the abandoned checkouts belonged to the bot.

The pattern, in case it matches yours:

• Nearly every checkout uses the same New York ZIP. A handful of phone numbers, most of them in the reserved 555 range, account for almost all of them.
• The emails are generated first.last names on gmail, yahoo, outlook and protonmail, and they get reused. Thousands of fake customer records have piled up, and many were auto-subscribed to our marketing list.
• Each checkout holds one unit of one cheap product. The bot switches to a different product every few days, so pulling a targeted SKU only moves it to the next one.
• It never loads our storefront. Storefront sessions and page views don’t line up with the checkouts, so it’s clearly going straight to checkout through cart links.
• Very few checkouts reach payment. Earlier in the year, though, a couple dozen $5 sample orders did get authorized before we caught them. Shopify’s fraud analysis flagged none of the abandoned checkouts.

What we’ve already done or ruled out:

• Payment capture is already set to manual.
• We already have a Plus support ticket open.
• We won’t block by address or require customers to sign in before checkout. Both would turn away real buyers, and our customers won’t tolerate the extra friction.
• From reading the other threads, storefront apps, IP and country blockers, and the login captcha can’t touch this, because the bot never loads the pages they run on.

Questions:

1. Has anyone on Plus stopped this with a cart and checkout validation Function? What did you match on that never caught a real buyer, and did it also cut down the abandoned-checkout records, or only the payment attempts?
2. For those who had Plus support turn on bot protection: it’s documented as a scheduled event of up to an hour. Did it do anything against continuous traffic like this?
3. Has Shopify purged fake abandoned checkouts for anyone? There’s no bulk delete in the admin or the API.
4. Has anyone gotten Shopify Payments to tighten card-testing or velocity controls on their account after documenting an attack?
5. Has anyone on Plus had Shopify confirm that rate-limiting checkout through their own Cloudflare in front of the domain is a supported setup?

Any experience would help, especially from other Plus merchants.

[vividusdesigns]

A checkout validation Function can stop bad attempts before payment, but it wont clear the abandoned checkout junk already created. For rules, dont block just on one ZIP or free email domains; that can hit real buyers. Safer is stacking signals like reserved 555 numbers, crazy session velocity, and obviously generated addresses together.

For the fake abandoned checkouts, Admin/API still have no bulk delete, so ask Plus Support if they can purge or help with reporting. Same ticket: ask about Payments velocity controls after an attack, and whether Cloudflare in front of your domain can rate-limit checkout on Plus (often checkout sits on Shopify’s side, so storefront Cloudflare alone may not cover it). Temporary bot protection helps bursts more than nonstop traffic; CAPTCHA plus validation is the steadier combo.

[Maximus3]

Getting mixed signals in some areas

Abandoned checkouts and actual fraudulent orders that get through. Even though they may stem from the same testing bots, they are very different areas of focus. You need to separate these two very different actions.

Fraudulent orders -

This is the first and foremost issue you should concern yourself with, as it could negatively contribute to bad authorizations and chargebacks. The first thing you should do is create a checkout validation, whether it be through an app like Blockify or whatever, and block checkouts for some metric you deem fit and see if it works. An app built on Shopify’s Cart and Checkout Validation Function API runs server-side on Shopify and can block checkout progression when its rule matches. Do not conflate this with trying to block the bot from reaching the checkout.

Orders that make it through whatever blocks and detection. Manual capture will not change this. The card company already authorized the payment. Manual capture will only change whether or not you capture the authorized funds.

Abandoned Checkouts -

There is currently no way to manually delete an abandoned checkout. They automatically disappear after 3 months. Don’t assume anything, including checkout validation, will solve that clutter. Also to note: Shopify Fraud Analysis does not generate a risk assessment on abandoned checkouts. I repeat: Blocked attempts that never become orders don’t receive an order fraud recommendation.

Abandoned checkouts really only harm 3 areas. Analytics, marketing, and customer profile bloat. There is virtually nothing you can do about the analytics side, apart from creating your own reports. The marketing side, as well as the customer bloat, is downstream, and has its own methods of correction, deletion, and avoiding mass emails from going out.

One more thing worth noting: Shopify explicitly states that attempts it actually identifies as suspected card testing/bot activity shouldn’t appear in the abandoned-checkout list, which makes those 11,000 entries worth escalating.

[NativeCode]

This is almost exactly the kind of attack that pushed us to build Halt in the first place. We originally built it internally after seeing card-testing traffic hammer large Shopify stores, then eventually turned it into a public app that Shopify just approved a few days ago.

The interesting part here is that your bot is going directly through cart links and rotating products. That’s important because a lot of the usual storefront-level protections won’t ever see it.

Halt works at checkout rather than relying on storefront traffic, IP blocking, or CAPTCHA. We use checkout validation to stop suspicious attempts before they reach payment, while trying to avoid adding friction for legitimate customers.

Your 11,000 abandoned checkouts are an extreme case though, and I’d genuinely be interested in seeing whether the patterns we’re detecting line up with yours. Especially the repeated ZIP, phone numbers, emails, and velocity.

If you’re open to it, give our app a chance and we can improve it based on your needs. This is exactly the kind of real-world card-testing attack we’re trying to understand better as each merchant needs vary.

[MattHowe]

Nothing ended up working for us. We ended up just having to pay for a app but abandoned checkouts have stopped after installing it

[NativeCode]

What app did you end up going with? Ours just got approved by Shopify a few days ago. We want to improve it and release updates constantly to help everyone here.

[kishoreaxioprax]

Agree on challenging at checkout. The second half that bites later is CRM pollution.

If ~94% of abandons are bot, those fake customers and emails will still enter recovery, segments, and lookalike audiences unless you quarantine them. Practical cut from your pattern: same ZIP cluster, 555 phones, recycled first.last emails across major free mail domains.

I would mark those records “bot/card-test,” exclude them from abandon metrics and flows, then keep a short weekly review of new abandon spikes so the next wave does not silently re-enter.

Are recovery emails already going out to that set, or did you pause flows first?

[Lilian11]

Hi @notavegan,

For the pattern you’re describing, I’d separate the problem into two parts: preventing the bot from creating the checkout attempts in the first place, and dealing with the abandoned-checkout records that have already been created.

If the traffic is going directly to checkout/cart links without loading the storefront, I wouldn’t expect a typical storefront bot blocker, country/IP rule, or login CAPTCHA to be very effective. The fact that the bot is rotating SKUs also makes product-specific blocking fairly easy for it to bypass.

For the checkout side, a cart/checkout validation Function may be worth testing if you have a signal that is specific enough not to affect legitimate buyers. I’d be careful about using ZIP, phone prefix, email domain, or a single SKU as the only condition, since each of those can eventually match real customers.

If the main issue is card-testing traffic reaching checkout, there is also a dedicated option for that layer.

Disclosure: I work on Blockio. It is designed to detect and block card-testing bots before they can repeatedly abuse checkout, and it can be started in Monitor mode so you can review the traffic it would block before enabling enforcement:
Blockio Card Testing Blocker - Shopify App Store

I’d treat that as complementary to Shopify Plus and Shopify Payments’ own protections rather than a replacement for them. It also won’t necessarily clean up the abandoned-checkout records that were already generated, so I’d still ask Shopify Support specifically what they can do about the historical records and whether they can apply additional controls to the payment/checkout traffic on their side.

[ahsandoesntcare]

Turn off marketing consent capture at checkout so the bot stops growing your list: Settings > Checkout > Marketing options, disable the automatic sign-up and the opt-in checkbox. Then use Flow’s abandoned checkout trigger, if available on your plan, to tag the customer, and exclude that tag from your email segments.

For the abandoned checkout records themselves, there’s still no bulk delete in the admin or API. Ask in your existing Plus ticket whether Support can purge them server-side, and keep the export as evidence for Shopify Payments.

Cloudflare proxying in front of your Shopify domain isn’t something I’d assume is supported; treat that as a question only Plus Support can confirm in writing.

[nautahakk]

What you are describing is a checkout permalink bot rather than anything on your storefront, which is why the storefront tools did nothing.

On your first question, and this is the part I would want to know before installing anything: a cart and checkout validation function stops the payment attempt, but it will not bring your abandoned checkout count down. The record is created when the bot fills in contact details, and the function runs after that, so the count stays ugly even when every attempt is being blocked. If the 11,000 records are the real cost to you rather than the payment attempts, that is a separate problem, and the lever is Plus support looking at the cart permalink traffic, since that is the door it is walking through.

On what to match on without catching real buyers, your emails are the weakest signal you have. first.last on gmail is also what your actual customers look like, and a disposable domain list will not touch protonmail. The thing that is actually distinctive in what you posted is the same address coming back over and over on single cheap items. Low cart total on its own will block real people, so it only works paired with the repeat.

Worth doing today regardless: turn off the pre-checked marketing consent at checkout so those fake records stop landing in your list, and clear the ones already in there before it costs you sending reputation.

I build an app called Deadbolt that is this exact thing, a checkout validation function with email and cart rules. Run it in test mode for a day first, where it records what it would have blocked without blocking anything, so you can check it against your own traffic before it touches a real buyer. Two things it will not do for you though: it keys on the email address, so the moment your bot rotates to fresh addresses it is through again, and its automatic burst rule counts completed orders, which on traffic like yours that never completes is nothing to count.

[SealSubs-Roan]

Hi there @notavegan
Another Plus strategy is to treat this as checkout abuse, not a traffic problem on your storefront. You can use a Cart and Checkout Validation Function to block things like repeated reserved 555 phone numbers, suspicious ZIP and email combinations, or unusually high rates of checkout activity prior to payment. I would stay away from broad address or SKU rules that may prevent legitimate buyers from purchasng. Additionally, payment authorization controls should be independent of abandoned checkout creation, as preventing card attempts does not necessarily prevent abandoned records from being created. As part of cleanup, you can export the relevant records and then refer to the documentation of the Plus protections available to you to protect against the type of attack you have identified.

[informacione]

On your first question, we’ve had a successful result stopping card-testing attempts from reaching our payment processor. After enabling Checkout Firewall in our own Shopify store a few days ago, those attempts reaching Stripe dropped to zero.

Disclosure: I built the app. That result concerns payment attempts; I’m not claiming it removes existing abandoned checkouts or prevents every fake customer record.

You mentioned that address blocking isn’t acceptable for your store. Repeated addresses were part of the pattern in ours, so I wouldn’t assume our configuration would suit yours without explaining the matching rules first.

For evaluating any solution here, I’d compare payment attempts reaching the processor separately from abandoned-checkout volume. A reduction in one doesn’t demonstrate a reduction in the other.

[EverythingDSM]

This sounds like a case where it is important to separate storefront bot traffic from direct checkout abuse, because many of the standard recommendations for blocking bots probably will not address what you are seeing.

This Doesn’t Appear to Be a Storefront Problem

Based on your description, the bot isn’t browsing the storefront normally. It appears to be reaching Shopify checkout directly, potentially through generated cart/checkout links.

If that’s the case, storefront-level protections may have little or no effect, including:

- Theme-based CAPTCHA or JavaScript challenges

- IP/country-blocking apps that operate on the storefront

- Theme-level bot protection

- Blocking individual products

- Requiring additional storefront interactions before checkout

The fact that your storefront sessions and page views aren’t increasing alongside thousands of checkout attempts is particularly significant.

Going from approximately 130 abandoned checkouts in August to more than 11,000 since September 1, with a peak near 3,800 in one day, also makes it very difficult to characterize this as ordinary abandoned-cart activity.

Card Testing vs. Automated Checkout Abuse

I would make one distinction when escalating this with Shopify.

The earlier ~$5 orders that actually received payment authorizations certainly sound consistent with card testing. However, you mentioned that very few of the current attempts reach payment.

That could mean Shopify is already stopping some of the activity before an authorization is attempted.

If so, there are really two related problems:

- Automated checkout creation is generating thousands of bogus abandoned checkouts, customers, and marketing records.

- The same pattern has previously progressed to payment authorization, creating a legitimate card-testing concern.

That distinction may help get the case escalated beyond general Plus support and into the appropriate checkout/payments/security teams.

Checkout Validation Functions

A cart/checkout validation Function seems like one of the more interesting merchant-controlled options available to a Plus store, but I would be very cautious about blocking on a single attribute.

I would not rely solely on:

- ZIP code

- Email domain

- Phone number

- Product/SKU

- Order value

All of those are easy for the attacker to change, and most could eventually match a legitimate customer.

If you can identify a combination of characteristics that is effectively unique to the attack, a validation Function could potentially be useful.

However, there is an important question Shopify should answer first:

At what point is the abandoned checkout record created relative to execution of the validation Function?

If Shopify has already created the checkout before the Function rejects it, the Function could successfully prevent the bot from progressing while still leaving you with thousands of abandoned-checkout records.

In other words, it could protect the transaction without solving the data pollution.

I would specifically ask Plus support to confirm the execution order before investing much development time into that approach.

Shopify Plus Bot Protection

The documented Plus bot-protection feature doesn’t seem particularly well suited to this type of attack if it is limited to scheduled protection windows.

That makes sense for things like:

- Flash sales

- Product launches

- Limited releases

- Known high-demand events

It makes much less sense for automated abuse that has been occurring continuously for months.

I would still ask Plus support whether they have internal or continuous bot mitigation options that can be enabled during an active attack.

There may be controls available to Shopify internally that aren’t exposed as merchant-facing settings.

With 11,000+ fraudulent checkout creations, I think you have a reasonable case for asking Shopify to treat this as an active infrastructure-abuse issue rather than normal bot traffic.

Shopify Payments / Velocity Controls

This is the area where I would push particularly hard.

You have considerably more evidence than simply saying, “We’re seeing suspicious checkouts.”

You have documented:

- Approximately 130 abandoned checkouts during a normal month

- More than 11,000 since September 1

- Approximately 3,800 in a single day at the peak

- Roughly 94% of the 90-day abandoned-checkout export attributed to the bot

- Repeated ZIP-code patterns

- Repeated fake/reserved phone numbers

- Repeated/generated email patterns

- One-unit, low-value carts

- Products being rotated when one becomes unusable

- No corresponding storefront traffic

- Previous ~$5 orders that successfully reached authorization

That is a substantial behavioral pattern.

I would explicitly ask Plus support to escalate the case to the team responsible for Shopify Payments risk/card-testing abuse and checkout security, rather than allowing it to remain a general support ticket.

Shopify necessarily has fraud, velocity, and abuse controls at the platform/payment-processing level that merchants cannot configure themselves.

Those controls also aren’t likely to be fully documented publicly, for obvious reasons.

This is exactly the layer where a behavioral/velocity response makes more sense than blocking individual ZIP codes, products, or email addresses.

The Fake Marketing Subscribers Are a Separate Problem

I would also raise the marketing subscriptions separately.

Thousands of fake checkout attempts becoming customer records is already undesirable. Having those fake customers automatically added as marketing subscribers is potentially worse.

That can contaminate:

- Customer segmentation

- Marketing analytics

- Email-list quality

- Deliverability metrics

- Subscriber counts

- Marketing costs

- Consent records

I would ask Shopify specifically why these checkout attempts are resulting in marketing consent being recorded and whether the affected records can be identified and cleaned up in bulk.

I certainly wouldn’t treat those addresses as legitimate subscribers simply because Shopify currently shows them as subscribed.

Purging the Abandoned Checkouts

I think Shopify ultimately needs to own this part of the problem.

Stopping the attack tomorrow doesn’t undo the 10,000+ bogus checkout records that have already been generated.

If Shopify doesn’t provide merchants with a supported bulk-delete mechanism or API method for removing them, I would ask Plus support whether Shopify can perform a server-side cleanup.

Ideally, they should be able to identify the affected records based on:

- Date range

- Known attack characteristics

- Repeated contact information

- Checkout patterns

- Other internal identifiers available to Shopify

Even if the fraudulent checkout attempts aren’t costing you transaction fees, permanently polluting your store’s checkout and customer data is still a real operational problem.

Cloudflare Probably Isn’t the Solution

I would be cautious with the Cloudflare approach.

Putting Cloudflare in front of the storefront domain does not necessarily mean Cloudflare is sitting in front of every request to Shopify’s hosted checkout infrastructure.

If the attacker can reach a Shopify checkout endpoint without traversing the portion of the request path controlled by your Cloudflare configuration, your WAF and rate-limiting rules won’t see those requests.

I would therefore not change DNS/proxy architecture on a production Plus store specifically to combat this unless Shopify confirms:

- The configuration is supported.

- Checkout traffic will actually traverse your Cloudflare controls.

- It won’t interfere with Shopify checkout, Payments, Shop Pay, accelerated checkout, webhooks, or other Shopify functionality.

Otherwise, you could introduce additional complexity without actually touching the traffic causing the problem.

Avoid Playing Whack-a-Mole

I think you’ve already demonstrated why blocking individual attributes isn’t going to be a durable solution.

If you block the cheap SKU, the bot chooses another product.

The same thing can happen if you block:

- A ZIP code

- A phone number

- An email address

- An email provider

- A particular product

- A particular cart value

Those are all inexpensive attributes for an automated attacker to rotate.

The durable solution needs to be based on behavior and velocity at Shopify’s checkout infrastructure level, rather than individual values the attacker can change.

What I Would Ask Shopify to Escalate

Given that you’re on Plus and using Shopify Payments, I would ask for three specific escalations:

1. Checkout / Security

Ask what Shopify can do server-side to detect, challenge, or rate-limit the automated checkout creation before it generates abandoned-checkout and customer records.

2. Shopify Payments / Risk

Ask whether Shopify can apply or adjust card-testing and velocity protections for the store based on the documented attack history, particularly since some earlier attempts successfully reached authorization.

3. Data Cleanup

Ask whether Shopify can identify and purge the bot-generated abandoned checkouts, customer records, and incorrect marketing subscriptions—or provide a supported bulk method for you to do it.

I would also ask Shopify one very specific technical question:

Does a cart/checkout validation Function execute early enough to prevent an abandoned checkout from being created, or does it only prevent the customer from proceeding after the checkout already exists?

That answer determines whether building a validation Function actually addresses your primary problem.

Bottom Line

You’ve done considerably more investigation than most merchants reporting “bot traffic.”

You’ve established a normal baseline, quantified the increase, identified repeating attributes, documented the product-switching behavior, compared checkout activity against storefront sessions, identified fake customer/marketing records, and documented previous payment authorizations.

At 11,000+ attempts and roughly 3,800 in a single day, I don’t think “install a fraud app,” “block the ZIP code,” or “remove the cheap product” is an adequate resolution.

The attack appears to be occurring primarily at a layer that Shopify controls, and the behavior is occurring at enough volume that Shopify should have significantly better visibility into it than any storefront app could.

I would keep pushing for escalation to the teams responsible for checkout security, automated abuse, and Shopify Payments risk, while using the Plus support case to get definitive answers about validation Functions, cleanup of the existing records, and any server-side velocity controls Shopify can apply.

[GiorgiMazm]

One thing still open here is the execution-order question, so I checked it on my dev store (I build checkout validation Functions). I sent a bot-style checkout through a direct cart permalink, with no storefront visit, and my Function blocked it:

• Abandoned checkout record: still created
• Customer record: still created
• Payment: blocked before authorization

So a validation Function protects the money side: no authorizations, so no more ~$5 test charges going through. But it does not prevent the abandoned checkouts or the customer records. On its own it won’t fix your data pollution.

What I’d take from that:

1. The earlier ~$5 authorizations are the part with real cost (disputes, fees, payment-account risk). That’s where a Function, or pushing Shopify Payments risk as suggested above, actually helps.
2. Abandoned checkouts can’t be deleted through any API, so that cleanup really has to come from Shopify. Worth pushing Plus support on it.
3. Fake customers with no orders can be cleaned up. Export them first, filter on the ZIP/phone/email patterns you found, then delete or tag them. Before your next campaign, make sure they’re excluded from Klaviyo or Shopify Email, because sends to fake addresses hurt deliverability.

Disclosure: I’m building an app for this pattern. Based on the test above, it would cover blocking at payment and cleaning up fake customers, not the abandoned checkouts. If that’s still useful, I’m happy to set it up for free and watch the attack with you. DM me if relevant.

[Arijit_Mandal]

before you size this, pull one number out of the 11,000: Orders, then Abandoned checkouts, then the Blocked view. when Shopify Payments stops a checkout before an order exists, the checkout’s timeline reads “Blocked due to high risk of fraud” and no payment is captured. those never became orders. they are not in the abandoned-checkout export you counted, and they have not cost you a fee. knowing how many sit in that view changes what you are actually buying: something to stop the traffic, or cleaner reporting around it.

worth knowing too: Shopify Payments re-evaluates risk every time the customer submits checkout. a bot that rotates ZIP and product every few days dodges your rules and re-rolls the model at the same time. anything keyed on a single field will keep leaking, which is why stacking signals is the only version of this that holds.

at your volume I would put one person on it with a weekly log of what got through. patterns move, and a log is the only way you see it move before the next spike.

I study the comparison between what the customer claimed happened vs what the photo actually showed — that’s what separates real damage from the fakes.