WooCommerce Card Testing: Why Your CAPTCHA Is Not Enough

If your WooCommerce store suddenly shows dozens of failed orders for your cheapest product, with names like "asdf qwer", you are probably being used for card testing: a script checking which stolen card numbers still work. The checkout form is not the only target, and that is why a CAPTCHA plugin alone often does not stop it.

Disclosure: I'm part of the team behind NodeThemes Security AI, a WordPress security plugin with a card-testing feature in its Pro version. Everything else here is plain WooCommerce and Stripe.

How the attack works

Stripe's card testing guide describes two methods: small payments, and saving a card without paying. Attackers like the second one because those checks rarely show up on the cardholder's statement. On WooCommerce that means three routes:

Scripts don't need your checkout page at all. They call the Store API directly. If your CAPTCHA only hooks into the classic checkout form, the bot never sees it. WooCommerce's developer blog covers this in Card testing attacks and the Store API.

How to tell it's card testing

• A spike in orders with the status Failed, often with declined-card notes.
• Many tiny orders, or the same cheap product again and again.
• Random names and e-mail addresses, billing addresses that don't match the card country.
• New customer accounts that add several cards and never buy.
• In Stripe: a jump in failed or blocked payments and generic_decline errors.

The cost is not only the fees. A high decline rate makes card issuers trust your shop less, so real customers' payments start failing too, and successful fraudulent payments turn into disputes later.

First hour checklist

1. Refund the fraudulent payments that succeeded. A dispute costs more than a refund.
2. Hide products with a tiny or zero price, and pay-what-you-want products.
3. Turn off guest checkout for a day or two.
4. Ask your payment provider to tighten fraud rules (for Stripe, look at Radar rules).

Turn on Store API rate limiting

WooCommerce ships with rate limiting for the Store API, off by default (docs):

add_filter( 'woocommerce_store_api_rate_limit_options', function () {
    return array(
        'enabled'       => true,  // default: false
        'proxy_support' => false, // true only behind a proxy such as Cloudflare
        'limit'         => 25,    // requests ...
        'seconds'       => 10,    // ... per 10 seconds (the defaults)
    );
} );

Recent WooCommerce versions also have a stricter limit for the Place order request only, under WooCommerce › Settings › Advanced › Features ("Rate limiting Checkout block and Store API"), which allows at most 3 Place order requests per 60 seconds.

One trap: behind Cloudflare, without proxy_support, every customer has Cloudflare's IP and shares one limit.

Pause IPs with too many failures

Rate limits slow a script down; they don't stop a patient one. A rule that works well in practice: if one IP has several failed payments, or many orders, within an hour, pause checkout and "Add payment method" for that IP for a few hours. Real customers almost never fail three payments in a row. Shop managers and your own IP should be exempt.

In Security AI Pro this is a setting: by default 3 failed payments or 10 orders per hour pause that IP for 6 hours. It hooks into the classic checkout validation, the Store API checkout and the add-payment-method form, and writes every pause to the firewall log. If you'd rather build it yourself, those are the three places to hook.

What not to rely on

• IP blocking alone. Attackers rotate IPs; this is one layer.
• CAPTCHA alone. Only if it also protects the Store API and Add payment method.
• Your plugin instead of your payment provider. Stripe Radar and similar tools see patterns across many shops. Use both.

Full guide, with the signs of an attack and a first-hour table: WooCommerce card testing attacks: how to spot and stop them.