A merchant watching a card testing attack sees the same thing every time. Orders for the cheapest item in the catalog, arriving in bursts, every one with a different name and a different card and the same shipping address. Hundreds of abandoned checkouts a day that no human created. Almost none of them succeed, which is the part that makes people assume it is somebody else’s problem.
Signifyd measured card testing attacks up 175% across January to April 2026 against the same months in 2025, and attributes the rise to automated credential validation. Over the same window it puts fraud pressure in North America up 33% and account takeover attempts up 78%.
The reason it is so hard to stop on Shopify has nothing to do with how good the defenses are. It is where they sit.
What the attacker is actually doing
The confusing part is the motive. Somebody is running hundreds of orders through your store and abandoning almost all of them, which looks like vandalism until you understand that the orders were never the point.
Many of the card numbers were never stolen from anybody. They were guessed. A card number is not random. The first six to eight digits are the Bank Identification Number, which identifies the issuing bank, and those ranges are public. The last digit is a check digit produced by the Luhn formula, which is arithmetic anybody can run. An attacker picks a BIN belonging to a bank worth targeting, fills the middle digits with candidates, and calculates the final digit so each number is structurally valid. That produces an endless supply of numbers that look real to any form that checks their shape.
Structurally valid is a long way from usable. Most of those numbers belong to no account at all, and of the ones that do, most are expired, frozen, or already cancelled. The same is true of numbers taken in a breach, which sit in a dump for months before anyone gets to them.
So the attacker has a pile of candidate numbers and no idea which ones are alive. There is exactly one way to find out, and that is to ask a bank. Asking a bank directly is not something a criminal can do. Asking a merchant is trivial, because every ecommerce checkout in the world exists to pass a card to a payment processor and return the answer.
That answer is the product. A card that approves a two dollar charge is a live card with a working expiry and a valid security code, and it is worth many times an untested number on a resale market. The goods are irrelevant. The attacker is not shopping.
Why your store and not someone else’s
Nothing about your store attracted this. Card testing runs against whatever checkouts are cheap to reach, and a Shopify store is cheap to reach because Shopify is consistent. The same URL patterns work across every store on the platform, so a script written against one works against all of them without modification.
Small charges keep it quiet. Attackers work in ones and twos, on the cheapest product in the catalog, because a small amount draws less scrutiny from risk systems and costs almost nothing on the rare occasion it goes through. Gift cards and zero-value items are better still, and merchants report them being targeted first.
How they reach checkout without ever browsing your store
This is the part that surprises people, and there is no exploit in it.
Shopify supports cart permalinks, a documented feature every merchant uses for ad links and email campaigns. A URL in the form /cart/{variant_id}:{quantity} builds a cart and sends the visitor straight to checkout, skipping the product page, the cart page, and everything else. It exists so a Black Friday email can drop somebody into checkout in one tap.
A bot uses it for the same reason a marketer does. One request creates the cart and lands on checkout, with the storefront skipped entirely. Add an automated browser driving the payment step, spread the traffic across residential proxy addresses so no single one stands out, and the whole thing runs unattended.
Nothing in that sequence is broken or unusual. The attacker is using a supported feature exactly as designed, at a volume and for a purpose nobody intended.
The attack never loads the pages you are defending
Merchants describing these attacks in Shopify’s own community forum report the traffic arriving at the checkout URL directly, without browsing the storefront to get there. That single detail explains why the usual responses come back clean.
A captcha on the product page guards a page the bot never requests. An app that blocks countries or addresses filters storefront sessions the bot never opens. Shopify’s fraud analysis scores completed orders, and a card testing attempt that gets declined never becomes one, so the tool that is supposed to catch fraud has nothing in front of it. One merchant in that thread reports reCAPTCHA being bypassed with the bots still reaching checkout.
The reported pattern is consistent enough to recognize: a new customer account per attempt, rotating email addresses that are frequently real ones taken from breaches, and a single reused shipping address underneath them all. The target is whatever costs least. Merchants name newly added low-price products, and gift cards or zero-value items where the store has them.
The volume is what makes it expensive to ignore. One merchant reports hundreds of fraudulent abandoned checkouts a day, another an attack running continuously since June 2025, and a third measured abandoned checkouts up 18.4% over four weeks.
Every declined charge still costs you something
This is the part merchants underestimate, and it is the reason a store with zero fraudulent orders can still be badly damaged by an attack.
An authorization request that fails is a data point about you, sent to the bank that declined it. Enough of them, close enough together, and your store starts looking like a bad risk to the institutions that decide whether to approve your customers. Shopify describes the outcome directly: failed transactions degrade a merchant’s standing with banks, and legitimate customers get declined long after the attack ends, with a lingering drop in authorization rates.
Shopify reports that merchants covered by its protection see 13% more of their legitimate sales approved. Read that as the size of the hole rather than as a feature, because it is the same number seen from the other side.
There is a second cost with no upside at all. The fraudulent abandoned checkout records cannot be removed, and merchants report confirming that with Shopify Flow, the admin, and the API alike. Every conversion rate, cart abandonment figure, and funnel report covering those weeks is permanently wrong.
Visa monitors enumeration as its own category now
The Visa Acquirer Monitoring Program consolidated the older fraud and dispute programs into one, with thresholds effective 1 June 2025 and an advisory period that closed on 30 September 2025.
The headline metric is a ratio of fraud and disputes to settled transactions:
VAMP Ratio = Count of [Fraud (TC40) + Disputes (TC15)] / Count of Settled Transactions (TC05)
For merchants in the US, Canada, the EU and Asia Pacific, the Excessive threshold was a VAMP ratio at or above 220 basis points together with at least 1,500 fraud and dispute events in a month. That threshold dropped to 150 basis points on 1 April 2026.
Underneath it sits the clause that applies to card testing specifically. Visa requires acquirers to keep merchants below two enumeration thresholds:
| Measure | Threshold |
|---|---|
| Enumeration Ratio: enumerated authorizations divided by all authorizations, approved and declined alike | 2,000 basis points, which is 20% |
| Enumeration Transaction Count: enumerated transactions in a month, approved and declined alike | 300,000 |
Read the first row carefully, because the denominator is authorization attempts rather than completed orders. A store doing modest volume can cross 20% of its authorization attempts during a single sustained attack while never coming close to 300,000 transactions. Small stores are not protected by being small here. They are exposed by it.
Visa does not publish the fee amounts attached to these tiers. Payment processors documenting the program describe fines applied per transaction counted under the metric once the grace period ends, and at least one documents an early warning tier that carries no fee at all. Anyone who needs the number should ask their acquirer rather than trusting a figure from a blog, and that includes the figures circulating with confident dollar amounts attached.
What Shopify does, and where it stops
Shopify published a description of its own defenses in June 2026, and the numbers in it are worth taking seriously.
Its machine learning model scores every payment attempt before it reaches the processor, and blocks approximately 90% of card testing attacks on guest credit card checkouts. That is a real defense doing real work, and it is free if you are on Shopify Payments.
Three limits come with it. The cover is for guest credit card checkouts, and only for merchants using Shopify Payments. Approximately 90% also leaves roughly one attempt in ten getting through, which at the volumes merchants describe is still a substantial number of authorizations hitting your rates every day.
Shopify also describes how the attacks have changed, and the description matters more than the percentages. Modern attacks are distributed and low volume across thousands of merchants at once, routed through residential proxies to look like ordinary traffic. That is a deliberate design to defeat exactly the defense most people reach for first.
The edge can see checkout now, which was not always true
For years the standard advice was to keep a proxy away from checkout. Guidance still circulating today tells Shopify merchants to leave checkout subdomains unproxied.
That advice is out of date, and testing it takes a minute. Request the checkout URL on a live Shopify store and it resolves to your own primary domain, in the form yourdomain.com/checkouts/cn/<token>. It is not on a Shopify-owned hostname. A zone that is proxied through Cloudflare sees those requests and can act on them.
That changes what is available to you. Rate limiting, managed challenges and WAF rules can be written against the path the attack actually uses, rather than against the storefront it never touches.
One exception is worth stating plainly rather than discovering later. Shop Pay and other accelerated checkouts redirect to a Shopify-owned domain outside your zone, and no rule of yours reaches that path.
Rules that match the attack
Published guidance for checkout paths starts around 5 to 10 POST requests per IP per minute, then blocks or challenges for several minutes. That is low enough to stop a bot hammering the endpoint and high enough to leave a real buyer retrying a declined card alone.
Tier the strictness by path rather than raising it everywhere. Checkout and payment paths earn stricter treatment than product browsing, which is the whole advantage of ruling at the edge instead of inside an app that cannot tell the two apart.
Use a challenge before you use a block. LexisNexis found that 56% of US retailers and 54% of US ecommerce merchants report increased customer churn tied to their own anti-fraud measures, which is a real cost paid by real buyers. A managed challenge costs a false positive a second. A block costs you the sale.
Pair the challenge with the rate limit rather than choosing between them. A challenge acts at the form. A rate limit catches requests that never render the form, which is the documented behavior here.
Accept what a per-IP limit cannot do. Against a distributed attack spread thin across residential proxies, per-IP counting is a floor rather than an answer, and the honest version of this advice says so. One merchant in that community thread reports spending thousands of dollars on a WAF with limited success, which is what happens when good tooling is aimed at the wrong layer.
Take the target away before you tune anything
The cheapest wins here are not rules at all, and merchants report them working.
Unpublish zero-value and gift-card products the store does not need, because those are what the bots reach for first. One merchant reports that unpublishing them alongside switching to a three-page checkout cut most of the volume.
Capturing payment manually rather than automatically removes the instant authorization signal the attacker came for, which makes your store a poor test rig and encourages them to go elsewhere.
Neither of those requires a WAF, an app, or a conversation with your acquirer. Both reduce how attractive the target is, which is a more durable answer than out-tuning an attacker who can change addresses faster than you can list them.
What this is and is not
This article describes attack patterns merchants have reported publicly and thresholds published by Visa. It is not legal or compliance advice, and the specific fees, remediation requirements and reporting obligations that attach to your account come from your acquirer.
If your store is under an attack right now, the order of operations is short. Take away the cheap targets, put a challenge and a rate limit on the checkout path, and get your authorization rate in front of your payment provider before the decline pattern becomes the thing you are explaining rather than the thing you are fixing.