Widespread Fraud Bot Using Shopify Checkout to Test Stolen Credit Cards (John Doe / Failed Payments)

[ShopGirl1]

We are experiencing the same issue many others have mentioned here, and it has been ongoing for months. In our case, it has sharply escalated over the last few days.

We now have thousands of abandoned checkouts created by a clear fraud bot pattern, most using the name “John Doe”, with failed or attempted payments attached. These are not real customers. This is a card-testing operation using Shopify’s checkout infrastructure.

Key characteristics:

• Different email addresses and shipping addresses on every attempt

• Rotating IPs via proxies/VPNs

• Repeated failed payment attempts

• Some fraudulent orders successfully pass and must be manually caught

• Checkout is being abused as a credit-card testing endpoint

This is not something merchants can stop on their own.

We have implemented everything available to us:

• Shopify Flow

• hCaptcha

• Manual fraud rules

• Additional app-based protections

None of these stop the attempts at the source. At best, they only help us mitigate damage after the fact.

Additional critical impact: email and domain reputation

These fake checkouts also create a serious email deliverability problem:

• Abandoned checkout emails are sent to bogus or disposable email addresses

• This results in high bounce rates

• High bounce rates damage sending reputation

• Damaged reputation impacts all transactional and marketing emails, including legitimate order confirmations and customer communications

Merchants should not be penalized at the email infrastructure level because Shopify checkout is being abused by fraud bots. This is another example of real, downstream harm caused by an issue merchants cannot control.

Why this is a serious platform-level problem

This goes far beyond abandoned carts:

• Domain and payment reputation risk
  Card testing activity increases chargebacks and processor scrutiny for innocent merchants.

• Customer trust and brand damage
  Shopify-hosted stores are being used as fraud tools against cardholders.

• Analytics and reporting corruption
  Fake checkouts destroy conversion data, funnel accuracy, and forecasting.

• Advertising performance degradation
  Polluted conversion signals negatively affect paid ad optimization.

• Operational burden on merchants
  Manual review, cleanup, and monitoring cost time and money.

The core issue

Merchants do not control Shopify’s checkout at a server or network level. This type of abuse can only be stopped by Shopify through:

• Velocity and behavior detection at checkout

• Card-testing pattern recognition

• Platform-wide fraud signatures

• Network-level blocking

This is not a merchant configuration problem. It requires Shopify engineering and fraud prevention intervention.

This issue has been reported repeatedly on this forum. It is known. It is ongoing. And it is escalating.

Shopify has a responsibility to protect its merchants from having their storefronts and domains used as part of a large-scale credit card fraud operation. Continuing to shift mitigation onto merchants damages trust in the platform.

This needs immediate escalation and a real fix at the platform level.

[user4156]

Thank you for outlining this issue so clearly. What you are describing aligns with known automated card-testing and fraud activity targeting checkout infrastructure, not genuine customer behavior.

You are correct that merchant-level tools such as Flow, CAPTCHA, and third-party apps can only mitigate impact after the fact. Merchants do not have access to the network-, velocity-, or behavior-level controls required to stop this type of abuse at the source.

We also acknowledge the downstream effects you highlighted, including payment risk, corrupted analytics, degraded ad optimization, operational burden, and especially email and domain reputation damage caused by fraudulent abandoned checkouts. Merchants should not be penalized for reputational harm resulting from abuse of platform-hosted checkout systems.

This issue has been escalated to the appropriate fraud prevention and engineering teams. Addressing card-testing and automated abuse requires platform-level detection and enforcement, and Shopify recognizes its responsibility to protect merchants from this activity.

Thank you for raising this and contributing to ongoing efforts to strengthen platform-wide protections.

[imperfect]

The email reputation impact is also very real and often ignored. Sending abandoned checkout emails to fake or disposable addresses drives bounce rates up, which hurts your domain reputation and can affect legitimate transactional and marketing emails. Merchants shouldn’t be paying that price for something they can’t control.

Until Shopify addresses this at the platform level, the only real mitigation is early fraud detection and automation. Tools like Fraudless (real-time risk scoring, card-testing pattern detection, auto-tagging or canceling risky orders) and NoFraud (fraud decisions with chargeback protection) can reduce how many fraudulent attempts slip through and cut down manual review. They’re not perfect — the root issue is still checkout abuse — but they do limit the damage.

This is a Shopify-level problem, not a merchant mistake. The more people call it out publicly, the harder it is to ignore.

[dolia_goprofit]

Hey @ShopGirl1! Thanks for sharing this — it clearly explains the issue and the real impact it’s having. Hopefully this helps bring more visibility and leads to a proper solution.

[dingle-larry]

Apps only block bots at your website, NOT checkout

[katy_7]

I have been having the same issues and have just been having the most frustrating chat with an Advisor who says he cannot escalate this and they do not have a specific team to handle this. So when they say they have been escalating this to fraud prevention and engineering teams I am really lost!

[LevaDesigns]

We’re having the same issue and now have to deal with a chargeback even after order was cancelled and refunded.

[vintagetoyroom]

I have been getting these too, I added a few other steps to hopefully stop pmts from processing going forward. A few already passed and I canceled as well. They did a chargeback even though you canceled the order @LevaDesigns ? I dont get how that happens if you never except the order and return to the same source,

[LevaDesigns]

That’s before I switched to manually accept payments. Even though I canceled order and refunded same day, two days later I got a chargeback for $15 on top of what was charged and already refunded. Now I’m accepting payments manually which is a pain.

[kestrel-ian]

You’re right that this is something that Shopify has to attempt to handle, as the core issue is that bots don’t even usually visit your store. They use Shopify’s built-in cart URL schema to skip directly to checkout without loading a single storefront page. No JavaScript executes, no CAPTCHA renders, no merchant-installed app ever sees the request. This is why storefront-level bot protection apps don’t always help, the “smart” bots never hit your store at all.

The old Checkout API (which allowed bots to complete purchases entirely via API) was deprecated in April 2025, which helps. But the Storefront Cart API that replaced it has no global rate limits by design, so bots can still create carts and obtain checkout URLs freely.

Here’s what you can actually do right now:

If you’re experiencing an “attack”, disable abandoned checkout emails: Every email sent to a bot-generated address creates hard bounces that damage your sending domain reputation. If you’ve authenticated your domain, those bounces accumulate against you directly. Industry thresholds flag anything above a 2% hard bounce rate, and domain reputation damage takes weeks to recover. Sacrifice the abandoned cart flow temporarily, even if it costs a bit in the short term.

Switch to three-page checkout. One-page is recommended by Shopify, but it’s easier to automate against. Three-page adds enough friction to slow automated scripts and might make you a higher effort target vs. one page checkout flows. Most botnets are looking for Shopify checkout because it’s familiar and reliable. Your conversion data is already corrupted by thousands of fake checkouts, so the theoretical conversion cost is irrelevant right now. (I also have some data showing the multi-step converts just as well for most stores anyways.)

O2O with Cloudflare: If you’re a “technical person” or have a dev/agency you work with, look into this: Improved onboarding for Shopify merchants · Changelog . (If this doesn’t make sense to you, skip it. It’s officially unsupported on the Shopify side.)

Shopify is the best-positioned team to actually solve this problem for you - but it’s important to note that these issues are not unique to Shopify. These botnets attack every major ecommerce platform and it’s essentially an arms race - every defense is met with a new attack.

The Shopify team already sit on data from billions of transactions across millions of stores and they’ve already successfully built card-testing countermeasures that handle significant volume. The current protections aren’t catching the more sophisticated operators using proxy rotation and identity cycling. Shopify has the data, the infrastructure, and the engineering talent to close this gap at the platform level in a way no individual merchant or third-party app ever will.

File formal support tickets with specific data: number of fake checkouts, date ranges, estimated revenue impact from chargebacks and lost email deliverability. Risk giving them more information than the support person you’re talking to is going to need. That specific information might be useful to the product or engineering teams.

Forum visibility helps, but quantified business impact in support requests will help their team drive engineering prioritization.

[LevaDesigns]

Not sure why I didn’t receive this on my first two chats with Shopify, but this is what they recommended I do on my third chat after I received a chargeback.

[Jason_Buehler]

kestrel-ian’s read is right and it’s why nothing in your stack catches this. Bots POSTing directly to checkout endpoints don’t load JavaScript, don’t render CAPTCHA, and don’t trigger any merchant app that hooks into your storefront pages. The April 2025 Checkout API deprecation kestrel-ian mentioned is part of what changes here, since it pushed Shopify toward
an extension architecture where apps can actually intercept the checkout request itself. That’s where the small handful of useful blockers sit. Most of what comes up in App Store search for “block bots” is country/IP geo-filtering with a checkout UI bolted on, which is not the same thing and won’t dent a real card-testing wave.

The other half of this, which is the half merchants can actually do something about today, is the downstream damage. Even when every bot transaction fails, the abandoned checkout records still get created, the recovery emails still fire to garbage addresses, Klaviyo and the rest still treat those events as buyer behavior, and your Meta pixel still slurps the
sessions into your lookalike data. None of that depends on whether you can stop the bots upstream. The fix on each is mechanical: Shopify’s “Human or bot session” filter on reports cleans the native dashboards, a regex suppression on the John Doe name pattern in your ESP’s abandoned-cart flow cuts the bounce volume hitting your sending domain, and a
custom-audience exclusion in Meta stops new lookalikes from being trained on bot sessions. None of those fix the upstream problem either, but they keep the cost from compounding while you wait.

ShopGirl1’s “merchants shouldn’t be penalized at the email infrastructure level” is the right policy framing. The upstream fix has to come from Shopify on their timeline. The damage-control side is what doesn’t depend on that.

[sebastien_v]

Your post is the clearest writeup of the part most people skip: the email and domain reputation hit. Hard bounces from recovery emails firing at bogus addresses, dragging down deliverability for your real order confirmations and marketing, is a cost that keeps compounding long after the bot wave passes.

kestrel-ian and Jason already laid out the mechanical damage-control well (kill the abandoned flow during a wave, regex-suppress the John Doe pattern in the ESP, exclude bot sessions from your Meta audiences), and the upstream block has to come from Shopify on their timeline.

I’m digging into this specific problem seriously right now, and I’m not selling anything. One genuine question, to size how bad it really is: what has this actually cost you per month? Sender reputation and deliverability loss, ad budget burned on poisoned audiences, processor scrutiny, hours on manual review and cleanup. And what have you already tried or paid to limit it?

Trying to understand the real cost for stores in your position. Happy to compare notes.

[Tiffanyy]

The ““John Doe”” pattern with failed payments is textbook card testing, attackers running stolen card numbers through any checkout that gives them a quick yes/no. They’re not interested in your products, only in whether the card authorizes, which is why the checkouts abandon and why blocking by product-page behavior misses them.

A few things that genuinely help with this one:

Turn on Shopify’s built-in card-testing prevention if you haven’t, and make sure reCAPTCHA is enabled on checkout (Settings > Checkout > Spam protection). It’s not bulletproof but it raises the cost for the attacker.

Set payments to manual capture so a successful test doesn’t immediately pull funds, and so you can void without a refund fee.

If you’re on Shopify Payments, watch your authorization rate, because a flood of failed attempts can put your account at risk, and contact Shopify support proactively so it’s on record that you’re being targeted.

The uncomfortable truth a lot of merchants hit: because this bot goes straight to the checkout endpoint, a storefront IP/country app can’t see it. The layer that can is a WAF (Cloudflare etc.) in front of your domain, which can rate-limit or challenge the checkout path. Storefront fraud apps like Blockify are useful for the broader IP/country/VPN and fake-account side, but I wouldn’t position one as the fix for the card testing itself, that part needs the WAF. Worth being clear on which layer solves which problem before spending money.