Most advice about card testing tells you what to install: a CAPTCHA, a plugin, a country block. It is written from the defender's chair. The people running these attacks have a precise, unromantic understanding of how your store works and why it is useful to them — so the dissection has to start from their side.
Your checkout is the product
A card-testing operator holds a bulk list of stolen card numbers, and most of them are dead. Before any can be used for real fraud, the live ones must be separated from the dead ones. That sorting is the entire job your checkout performs: every authorization response from your gateway tells the operator live or dead. The product never matters. The order completing never matters.
Which is why most defenses fail: the attack succeeds the moment the card reaches your gateway. Whatever your fraud plugin does afterward — flagging, cancelling, refunding — happens after the answer was already delivered.
And since 2025, every probe carries a compliance cost on top: Visa's VAMP program counts enumerated transactions that reach the processor regardless of whether the payment was approved or declined. Your plugin cancelling the order afterwards does not remove the attempt from your count. Source: Stripe documentation on Visa monitoring programs
Why WooCommerce specifically
Attackers pick targets on economics, and WooCommerce scores well on every axis. The endpoints are identical across every install — checkout, cart, Store API, AJAX payment paths — so reconnaissance costs nothing. The install base is enormous, so one script amortizes across thousands of stores. And the long tail is soft: default configuration, a standard Stripe or PayPal integration, nothing between the open internet and the payment flow. You were not singled out; you matched a pattern.
Stripe cut successful card-testing attacks on its own network by 80% in two years — while global fraud rates rose 11%. Hardened gateways do not end the attack; they push operators toward the soft spot, which is individual merchant checkouts. Source: Stripe Engineering, 2025
Every defense, every counter
Order-level fraud plugins run after the gateway answered: they can stop the sale, they cannot un-validate the card. CAPTCHAs tax real customers and routinely break on Apple Pay and express flows. IP and geo rules punish shared networks and corporate VPNs while the operator moves to fresh addresses. Each of these defends one static signal with a documented bypass.
The defense that maps to the attack
Three principles follow directly from the dissection.
Decide upstream of the gateway. The allow-or-block decision has to happen before the request reaches your payment flow — in front of checkout, cart, the Store API, and the AJAX paths. Not in a plugin that wakes up once the order exists.
Score behavior, not identity. A request can lie about what it is; it struggles to lie about how it behaves. Velocity, request sequencing, JavaScript execution, TLS fingerprint, the absence of genuine human interaction — faking one cheaply tends to break another.
Correlate weak signals. No single data point separates a careful bot from a real buyer. Small authorizations + repeated declines + email mutation + rotating origins + inhuman timing, all moving together, do. Single-rule blocking loses to an adversary who defeats one rule at a time; correlation forces them to defeat everything at once. That is the realistic goal: make your store more expensive to test than the next one, on a layer your real customers never see and never abandon over.
Are you affected? A five-minute check
Open WooCommerce orders, filter to failed payments over the last 30 days:
- Clusters of small failed amounts, roughly $1–10
- Attempts concentrated overnight
- Repeated declines from email variations on one root (john1@, john2@, ...)
- Bursts aligned with unusual ad-spend activity
Two or more matches: your checkout is being used to read a live-or-dead signal right now, even if your fraud plugin is quietly cancelling the orders afterwards.
Frequently asked questions
What is card testing fraud?
Validating stolen card numbers through small automated authorization attempts. The authorization response — not the purchase — is what the attacker wants.
Why is my WooCommerce store targeted?
Identical endpoints across every install, a massive install base, and a soft default-configured long tail make WooCommerce the cheapest place to read a live-or-dead signal at scale.
Does a CAPTCHA stop card testing?
No. Operators route challenges through solver services or target express-checkout and saved-card paths where the CAPTCHA was never wired in — while your real customers feel the friction.
Can my fraud plugin stop card testing?
It can cancel the order, not the validation. The plugin runs after the gateway answered, and under Visa's VAMP rules the enumeration attempt counts against you whether approved or declined.
Get a free attack exposure report
If you recognise the pattern, we will map the automated traffic actually reaching your checkout and cart endpoints, the testing patterns visible from the outside, and where your setup is exposed — before your payment processor points it out. Request it here.