What Cloudflare rules can and cannot do for a WooCommerce checkout

When card testing starts, many store owners open the Cloudflare dashboard first. That is a reasonable move. Cloudflare sits in front of your server and can drop traffic before PHP ever runs. It also has limits that matter a lot at checkout, and a rule written in a hurry can break real orders.

This note covers what Cloudflare can do well for a WooCommerce checkout, where it runs out, and how to write rules that do not trap paying customers. Plan features and rule limits change, so check your own dashboard for what your plan includes.

Know which URLs carry an order

Before writing a rule, list the requests that can create or pay for an order. On a typical WooCommerce store they include:

• The classic checkout submit, which posts to ?wc-ajax=checkout.
• The Checkout block, which posts to the Store API under /wp-json/wc/store/v1/checkout.
• Pay-for-order pages, under /checkout/order-pay/ followed by the order ID.
• The add payment method page in My Account.

Your paths may differ if the checkout page has a different slug or the site runs in a subfolder. Open your browser's network tab, place a test order, and copy the exact request path.

What Cloudflare does well

Rate limiting by path

A rate limiting rule can count requests to the checkout endpoints and block or challenge a source that exceeds a limit. This is useful against a crude script that hammers one URL from one address. Because Cloudflare counts at the edge, the blocked requests never reach your server or your gateway.

Pick the limit from your own order data, not a guess. A store that takes thirty orders a day can afford a much tighter limit than one running a flash sale.

Blocking obvious sources

Custom rules can block or challenge by country, ASN, or known bad networks. If an attack comes from a hosting provider's address range and your customers never do, a rule against that ASN on checkout paths can cut the volume quickly.

Bot scoring and challenges on page loads

Cloudflare's bot features and its Managed Challenge work best on full page loads, where the visitor's browser can run a challenge. Challenging the checkout page itself, not the submit endpoint, can filter out simple bots before they ever get a nonce.

Where Cloudflare runs out

Challenges break background requests

The checkout submit is a background request sent by JavaScript. If Cloudflare answers it with a challenge page, the checkout script receives HTML it cannot use, and the shopper sees a vague error or a spinner that never stops. A challenge on wc-ajax=checkout or the Store API usually breaks real orders.

For those endpoints, use block or rate limit. Keep challenges for page URLs.

Attackers rotate addresses

Card testers often use residential proxy networks. Each attempt comes from a different home connection in a normal country on a normal ISP. Per-IP rate limits and ASN blocks catch little of that traffic.

Cloudflare cannot see WooCommerce state

Cloudflare sees URLs, headers, and addresses. It does not know whether a request carries a valid cart, which gateway the shopper picked, or whether the same email placed five failed orders in ten minutes. Rules that depend on order data have to run inside WordPress.

Some routes hide inside generic paths

Payment methods and builder plugins can add their own endpoints, often under admin-ajax.php or a custom REST route. A path-based rule may miss them. Check your logs for any POST that creates orders during an attack, not only the paths you expected.

Rules that tend to go wrong

• Challenging the whole /wp-json/ path, which breaks the Checkout block, the cart block, and parts of the admin.
• Blocking a country you rarely ship to, then hearing from a real customer traveling there.
• A rate limit on checkout that counts failed card entries, so a buyer who mistypes a card three times gets locked out.
• Leaving an emergency block in place for months after the attack ends.

Write each rule with a description and the date you added it. Review checkout rules after every attack.

Restore the real visitor IP

When Cloudflare proxies your site, your server sees Cloudflare's addresses unless the web server is configured to restore the visitor IP from CF-Connecting-IP, and to trust that header only from Cloudflare's published ranges. If that setup is missing, WordPress plugins either lump every visitor under a few Cloudflare addresses, or they read a header that anyone can forge. Fix this at the server before relying on any per-IP logic inside WordPress.

Use both layers

Cloudflare is the cheapest place to drop crude, high-volume traffic. WordPress is the only place that can judge a checkout with full knowledge of the order. A sensible setup uses Cloudflare for broad rate limits and obvious bad sources, and checks inside WooCommerce for everything that needs order context.

Checkout Bouncer covers the WooCommerce side. It scores each order route with reCAPTCHA v3 and adds an order-rate throttle that works with any gateway, so it keeps working when attackers rotate addresses faster than an edge rule can follow.