WooCommerce

The Store API checkout path (POST /wp-json/wc/store/v1/cart/add-item, /wp-json/wc/store/v1/checkout, and the gateway create-order calls) has no built-in rate-limiting or bot screening. This makes it an easy target for card-testing (“carding”) bots: scripts hit the JSON endpoints directly, with no referer and no preceding page view, add a cheap product, post to checkout, and trigger order creation purely to validate stolen card numbers against the merchant’s payment gateway.

Observed in production
On one store this month we logged roughly 340 unique IPs in 24 hours hitting /wp-json/wc/store/* directly, none of them loading any HTML page first. The merchant experiences this as a flood of failed and cancelled orders, gateway decline noise, wasted PayPal/Stripe API calls, and real risk of higher decline ratios and gateway penalties.

Why current options are not enough
– Order-layer fraud plugins screen AFTER the order/payment attempt, so the gateway request (the thing the bot actually wants) has already fired. They also commonly hook woocommerce_thankyou, which Store-API/headless flows never reach, so bot orders can land in “processing” unscreened.
– An external WAF (e.g. Cloudflare “Under Attack” mode) does stop it (Store-API hits dropped from ~171 per 40 minutes to 0 in our test) but it is per-host infrastructure, challenges legitimate shoppers, and is not available or configurable on every hosting setup.
– WooCommerce does have a general REST rate limiter, but it is off by default, coarse, and not tuned to the checkout/create-order abuse pattern.

Proposed feature
Built into WooCommerce core, configurable under WooCommerce > Settings:
1. Per-IP (and optionally per-session) rate limiting specifically on the Store API cart/checkout/create-order endpoints, with sane defaults and admin-adjustable thresholds.
2. A pre-payment bot/velocity check on the checkout endpoint (e.g. too many add-item/checkout attempts per IP in a short window, no prior page-load token, missing/blank referer) that can soft-fail or challenge BEFORE the payment gateway is called, not after.
3. A documented hook/filter so fraud plugins and headless front-ends can plug into the same gating point, plus optional reCAPTCHA/Turnstile support on the Store API checkout.
4. Logging of blocked attempts so merchants can see the volume they are being protected from.

Benefit
Stops card-testing at the cheapest possible layer (before the gateway call), protects merchants from decline-ratio penalties and gateway noise, and gives every store this protection without requiring a specific host, WAF, or third-party plugin.