WooCommerce Bot Protection: Test Your Checkout

A string of failed WooCommerce orders can be the first visible sign of checkout automation. Rejecting one payment does not necessarily stop the next attempt.

We tested whether WebDecoy could refuse a repeated failed-order pattern at checkout, then checked whether a separate normal test order still completed. We ran the test independently against classic shortcode checkout and the Store API used by Checkout Blocks.

Both paths refused attempt four after three rapid synthetic failed orders. Normal offline test orders completed on both paths.

Install WebDecoy Bot Detection from WordPress.org to try local bot detection and checkout protection. No WebDecoy account is required for local protection.

Watch the checkout test

Watch the 48-second checkout test on YouTube.

The demonstration uses an isolated store, fake billing details and a local gateway that always returns a failure. It never contacts a payment processor. These are synthetic failed orders, not real card authorizations.

What we tested

We cleared the disposable lab’s checkout-attempt history between checkout paths so the first run did not prime the second. We kept the standard protection thresholds.

The recorded result

The protocol matters: classic checkout reports its refusal inside the checkout JSON response; the Blocks API returned HTTP 403. They do not return the same response format.

WebDecoy also recorded a Woocommerce card testing detection in its WordPress dashboard. That source name describes the detection category. The test itself exercised a synthetic failed-order pattern.

Actual isolated test store. Dashboard totals include setup and repeat verification runs; they are not customer traffic or an accuracy measurement.

Why the pattern triggered protection

The local WooCommerce checks use recent unsuccessful checkout attempts associated with the client IP. Several rapid, low-value failures across distinct orders provide more evidence than a single failed purchase.

This is useful application context, but it has practical limits. A shared network can contain several customers. An attacker can rotate IP addresses. A legitimate customer can retry a payment. Treat checkout-history checks as one layer alongside your gateway’s fraud controls and the rest of your site’s bot defenses.

A checkout refusal is separate from a sitewide IP ban. The result shown here is refusal of the checkout attempt, not a claim that every subsequent request from that address was blocked.

Install and verify WebDecoy on your store

1. In WordPress, open Plugins → Add Plugin and search for WebDecoy Bot Detection. Install and activate the plugin from WordPress.org.
2. Update to 2.10.6 or newer before testing classic checkout. That release fixes a load-order issue that could leave classic checkout callbacks unregistered when WebDecoy loaded before WooCommerce.
3. Open WebDecoy → Settings. Confirm Protect Checkout is enabled. Review monitor mode and any notice saying enforcement is suppressed, including proxy configuration notices.
4. Start in monitor mode while you inspect your traffic and test checkout. Monitor mode records evidence without applying the checkout refusals demonstrated above.
5. In staging, test the checkout path you actually use: classic checkout, Checkout Blocks, or both. Use your gateway’s documented test mode or a local synthetic gateway. Keep test traffic away from production fulfillment and payments.
6. Submit a normal test order and verify its order status. Test legitimate payment retries, guest checkout and relevant offline gateways too.
7. Review WebDecoy → Detections, enable enforcement after reviewing the results, then repeat the checks. Confirm the suspicious attempt is refused and the expected normal checkout still completes.

For the complete plugin installation walkthrough, see WebDecoy for WordPress. The plugin’s local protection does not require a WebDecoy account. Cloud connection is optional.

Keep payment-provider defenses enabled

WooCommerce’s Store API card-testing guidance explains why checkout endpoints deserve specific attention. Its Checkout Blocks protection integration guide is also useful when assessing whether a protection plugin covers the checkout you use.

Continue using the fraud controls appropriate to your gateway, including its supported verification and test tools. A WordPress plugin does not replace payment-provider controls.

Check gateway logs and WooCommerce order outcomes together. A checkout refusal should prevent another payment attempt on the tested path; a later payment decline means the request reached the gateway. Those are different outcomes.

What this demonstration proves

It verifies that the tested WebDecoy release can recognize this particular local failed-order pattern and refuse another checkout on classic and Blocks paths. It also verifies that separate normal offline test orders completed in the same lab.

It does not establish a detection rate, production conversion impact, resistance to proxy rotation, or compatibility with every theme, payment gateway and checkout extension. The successful orders used an offline gateway, so they do not validate a live card-payment integration.

Install WebDecoy, inspect your bot traffic, and test your own checkout.

Get the free WordPress plugin →