WooCommerce Card Testing Attack Protection

A Cloudflare rate-limiting rule for your Store API checkout endpoint, plus a checklist for the gateway settings that stop the rest.

Your details

Requests before challenging

Time window (seconds)

Action once the threshold is hit

Mitigation timeout (seconds)

Your domain (for reference only)

Cloudflare rate limiting rule + checklist

# Cloudflare rate limiting rule (WAF → Rate limiting rules → Create rule)
Rule name: WooCommerce checkout card testing protection
If incoming requests match: (http.request.uri.path contains "/wp-json/wc/store" and http.request.uri.path contains "checkout") or (http.request.uri.path eq "/?wc-ajax=checkout") or (http.request.method eq "POST" and http.request.uri.path contains "/checkout/")
Characteristics: IP address (with NAT support if available on your plan)
Period: 60 seconds
Requests per period: 20
Then: managed_challenge for 600 seconds

# Equivalent expression for a Custom rule (WAF → Custom rules), if you'd rather challenge
# unconditionally on suspicious traffic instead of by rate:
(http.request.uri.path contains "/wp-json/wc/store" and http.request.uri.path contains "checkout" and cf.threat_score gt 14) or
(http.request.uri.path eq "/?wc-ajax=checkout" and cf.threat_score gt 14)

Matches your checkout endpoints: the Store API route ("/wp-json/wc/store/v1/checkout", used by the block Cart and Checkout) and the classic AJAX checkout ("/?wc-ajax=checkout"). Card testing scripts hammer these directly, skipping the product pages a normal shopper visits first.

A 20-request-per-60s threshold is a starting point. Watch Cloudflare's Security Events for a few days after adding it before switching from "Log only" to "managed_challenge", so you don't block genuine shoppers on shared IPs (offices, campuses, mobile carriers).

Checklist beyond the WAF rule: turn on your payment gateway's own fraud tools (Stripe Radar, PayPal's fraud filters, or your processor's AVS/CVV matching); set WooCommerce to fail orders quietly rather than exposing which field was wrong; block guest checkout above a few failed attempts per session; and watch for a spike in "Failed" orders with sequential card-like values in WooCommerce → Orders.

Requires a Cloudflare account with your domain's DNS on Cloudflare and proxying (orange cloud) turned on. Rate limiting rule limits and available periods vary by plan.

What a card testing attack looks like

Card testing is automated abuse: a script fires small or zero-value orders at your checkout using stolen card numbers, one after another, to find out which cards are still active. It skips product and cart pages entirely and hits your checkout endpoint directly and repeatedly, which is the pattern this rule targets.

On WooCommerce, that's either the Store API's checkout route (/wp-json/wc/store/v1/checkout, used by the block Cart and Checkout) or the classic AJAX endpoint (/?wc-ajax=checkout). A real shopper hits either endpoint once per order; a card testing script hits it dozens of times a minute.

The rate-limiting rule

The generated rule matches requests to those checkout endpoints and challenges or blocks an IP once it crosses your chosen threshold within a time window. Start with Log only for a few days, check Cloudflare's Security Events to see what real traffic looks like, then switch to Managed Challenge or Block once you're confident the threshold won't catch genuine shoppers on shared IPs (offices, campuses, mobile carriers).

Beyond the WAF rule

Turn on your payment gateway's own fraud tools: Stripe Radar, PayPal's fraud filters, or your processor's AVS/CVV matching, since these catch patterns a generic rate limit can't.
Set WooCommerce to fail quietly: a declined-card message shouldn't tell an attacker which specific field (number, expiry, CVV) was wrong, since that helps them refine stolen card lists.
Watch WooCommerce → Orders for a spike in Failed orders with sequential, card-like values in the same short window.
Consider CAPTCHA on checkout (Cloudflare Turnstile or similar) if attacks continue after rate limiting.

Questions people ask

Do I need a paid Cloudflare plan for this?

Rate limiting rules are available on Cloudflare's free plan with lower limits on request thresholds and mitigation windows; paid plans raise those limits. Check your plan's specifics.

Will this block legitimate customers?

It can, if the threshold is too low or you skip the "Log only" testing period. Start conservative, watch Security Events, then tighten it.

Does this replace my payment gateway's own fraud protection?

No, it's a first layer that stops the bulk automated traffic before it reaches WooCommerce at all. Your gateway's fraud tools (Radar, AVS/CVV checks) catch what gets through.

Why target the Store API and the AJAX endpoint specifically, not the whole site?

Because card testing scripts go straight for the checkout submission, skipping normal browsing. Rate-limiting the whole site risks blocking genuine high-traffic browsing instead of catching the actual attack pattern.

What does "Managed Challenge" do that "Block" doesn't?

Managed Challenge asks the visitor to prove they're human (often invisibly) before letting the request through, so a real shopper who happens to trip the threshold can still get in. Block rejects the request outright.

Last reviewed 30 September 2026.

Sources: WooCommerce: Store API reference · Cloudflare: Rules language fields reference · Cloudflare: Rate limiting rule parameters