Card testing attacks on WooCommerce, and how to actually stop them.
Someone is running stolen cards through your checkout to find the live ones. Your shop is not the target — it is the test rig. You get the declines, the gateway fees and the chargebacks.
Last updated: August 2026 · Written & verified by the GatekeepWP team
What it looks like in your orders.
A burst of failed payments with almost no completed sales. That last part is the tell — a busy shop produces declines too, but a busy shop is also selling.
Many cards, one hour
Dozens of distinct card numbers, each declining once. A real customer retries the same card; a tester never reuses one.
A fresh identity each time
New name, new email, new address for every attempt, so no single customer record ever looks unusual.
Tiny amounts, no orders
The tester only needs an authorisation, not a haul. Nothing is ever fulfilled, because nothing was ever bought.
It runs while you sleep
Usually the small hours, when nobody is watching the order screen and the shop's own sales have stopped for the night.
Your gateway emails you
Often the first anyone notices: the processor flags your decline ratio before you have looked at the orders yourself.
Addresses that rotate
A capable operator changes IP between attempts, which is why blocking the address you can see stops almost nothing.
The declines are the smallest part of the bill.
Per-attempt fees
Many processors charge for an authorisation attempt whether it succeeds or not. A few hundred declines is a real invoice for a night that sold nothing.
Chargebacks with your name on them
The card gets confirmed live on your shop and spent elsewhere — but yours is the merchant name on the statement the cardholder disputes.
A processor review
A sustained decline-ratio spike can put your merchant account under review, and in bad cases into a reserve or a termination.
We attacked our own detector. Here is what got through.
Not estimates. These are the measured catch-points from red-teaming the module as an attacker who had read its source and knew every threshold.
| Attack pattern | Result |
|---|---|
| One card tried under many email addresses | Caught on the 3rd attempt |
| Several cards from one buyer, no completed sale | Caught on the 3rd attempt |
| Slow drip — one card every 25 hours, same identity | Caught on the 8th |
| Aged “trusted” account, then a burst of declines | Caught on the 13th |
| Fresh IP, email and card on every single attempt | Blocked on a quiet shop, flagged on a busy one |
| Fully rotated and dripped — one card a day | Not caught. This is the honest limit. |
Measured against the real detector on a shop with normal trading history, August 2026.
The last row is where in-shop detection genuinely ends. An attacker who rotates every identifier and waits a day between attempts leaves a pattern indistinguishable from a quiet, legitimate store. Beating that needs data pooled from other people's sites — so we name the limit instead of pretending past it.
Blocking real buyers costs more than the testers ever will.
Black Friday looks statistically like an attack: a flood of unfamiliar buyers, a raised decline rate, no purchase history on anyone. The difference is sales — a good day completes orders throughout, an attack completes nothing.
The nervous buyer
Three declines on the same card, then it works. One card, not many — never treated as an attack.
The expired first card
A customer trying a second card is ordinary. It takes several cards and no completed sale before anything fires.
Subscription dunning
Dozens of renewals failing on file the same morning — from customers who have already bought, so they never enter the count.
Four things to do tonight.
Rate-limit checkout
So one visitor cannot make unlimited payment attempts, whatever else you change.
Kill the tiny amounts
If nothing you sell costs $1, nothing should be chargeable at $1. Testers use the smallest amount that authorises.
Read the decline codes
A wall of the same reason across many different cards is card testing, not a broken checkout.
Keep the evidence
If chargebacks follow, the attempt log is what your representment is built from.
The things people ask first.
Carding is the wider trade in stolen card data. Card testing is the specific step where someone checks which stolen numbers are still live — and it is the step that runs through merchant checkouts like yours, which is why you see it and the cardholder does not.
Because it was reachable, not because it was chosen. Testers scan for checkouts with no attempt limits and no fraud rules. A small shop running a default configuration fits that description exactly, and being small is no protection at all.
Briefly. Any tester worth worrying about rotates addresses between attempts, so address blocking stops the amateurs and nobody else. Detection has to key on something the attacker cannot rotate — which is why the card fingerprint and the shop-wide pattern matter more than the address.
It raises the cost and stops the crudest scripts. It does not stop a determined operator, and it charges every honest customer for the privilege — which on a checkout is the most expensive place in your shop to add friction.
Your gateway sees one attempt at a time; the attack only exists across many. Each individual decline is unremarkable — a card was presented, the bank said no, the transaction ended correctly. Spotting the pattern is a different job from authorising a payment, and it falls to the merchant.
Not by any tool that keeps your data on your own site. An attacker who rotates every identifier and waits a day between attempts is indistinguishable from a quiet shop without cross-site reputation data. Everything faster or less careful than that is catchable, and the table above shows exactly where the line falls.
Catch it before your processor does.
Correlation across orders, a rehearsal lab so you can see it work, and an honest account of the one attack it cannot catch.