If you run a WooCommerce store and Stripe or PayPal has flagged your account, there is a strong chance it was not your customers. It was a card-testing attack on your checkout. This is the spam that costs money — chargeback fees, processor-side risk scoring, and in the worst cases a frozen merchant account. Here is how it works on WooCommerce and what to do about it.
What card testing actually looks like
A card-testing attack is automation that runs stolen card numbers against a low-risk public checkout to find out which ones still work. The attacker does not want your product. They want the success response from Stripe. They buy or generate a list of card numbers and need a checkout that does not stop them from trying.
WooCommerce is a popular target for three reasons: the checkout endpoint is well-known, there is rarely a CAPTCHA in front of the pay button, and most stores accept very small order totals (a $5 product is enough to validate a card). A typical burst looks like 80 to 400 attempts in a window of 2 to 15 minutes, often at 3am local time.
Why your processor flags you, not them
Stripe and PayPal score risk at the merchant level. A spike of declined charges, especially in a tight window, looks identical to a compromised merchant on their side. Their automated response is to:
- Raise your risk score
- Throttle your account
- Hold your payouts
- In severe cases, freeze the account pending review
The card tester moves on. You spend a week on the phone with risk teams. This is why “we accept the chargebacks” is not a strategy.
What does not work
Three things people try first that do not stop card-testing bursts:
- reCAPTCHA on checkout. Solvers handle it. It mostly annoys real buyers.
- IP rate limits. Attackers rotate residential IPs and you cannot tell them apart from real visitors on shared NAT.
- Stripe Radar alone. Helpful, but it sees individual charges. It does not see your checkout as a pattern.
What works on WooCommerce
The defence that has held up in production is checkout-level burst detection, not per-payment scoring. You watch the woocommerce_checkout_order_processed hook for velocity (orders per IP, per device fingerprint, per email domain, per amount range) and stop the burst before it gets to Stripe. You also score the customer-side fields (random-looking emails, mismatched billing data) before submission.
QWeb Spam Shield protects WooCommerce checkout out of the box
Spam Shield ships with WooCommerce-specific velocity rules and AI risk scoring on checkout submissions. It stops card-testing bursts at the form layer, before they hit your payment processor and put your account at risk. No code, no per-form configuration, free 7-day trial.
What to do this week
Two things you can do today even without a plugin: in your Stripe dashboard, turn on the Radar rule “Block if CVC check fails” and set a per-IP attempt limit on the checkout endpoint at the web-server level (Cloudflare rate-limit rules are free for one rule). That removes the smallest, fastest bursts. The next tier — the sophisticated bursts that rotate IPs and look like real traffic — is where a dedicated checkout-aware filter pays for itself in the first month.
Card testing is not the spam that fills your inbox. It is the spam that quietly costs you your merchant account. Treat it that way.