測試 WooCommerce 結帳保護時發現外掛載入順序錯誤

I work on WebDecoy. We set out to record a WooCommerce checkout-protection demo. Testing both checkout paths first found a real bug in our plugin.

The test used three rapid, synthetic failed orders from one test IP, then a fourth checkout attempt. A separate normal test client used an offline gateway to check that a normal order could still complete.

No real cards or payment processor were involved.

Blocks passed. Classic did not.

The Store API used by Checkout Blocks refused attempt four with HTTP 403 and webdecoy_carding. Classic checkout kept reaching the local decline gateway.

The checkout-protection setting was enabled. The validation callback was missing.

Our plugin initialized its hooks while WordPress was including the plugin entry point:

if ($this->options['protect_checkout'] && class_exists('WooCommerce')) {
    add_action('woocommerce_checkout_process', [$this, 'check_checkout']);
    // payment and checkout-attempt tracking callbacks
}

When WebDecoy loaded before WooCommerce, the class did not exist yet. The condition stayed false for that request, so classic validation and attempt tracking were never registered.

A valid setting did not mean the integration was running.

Register the integration after plugins load

Version 2.10.6 defers classic integration registration until plugins_loaded, after our includes load:

add_action('plugins_loaded', [$this, 'register_woocommerce_hooks'], 20);

That method keeps the protection-option and WooCommerce-presence checks, then registers the classic validation, payment and checkout-attempt callbacks.

We also added a runtime check to the WooCommerce compatibility smoke script. It checks the exact callbacks with has_action, so a missing callback fails the smoke check before checkout testing begins.

The fix and validation are in PR #116.

Repeat against the released package

After release, we installed the official WordPress.org 2.10.6 package in the isolated store and ran each checkout path independently, clearing only disposable test history between paths.

Environment: WooCommerce 11.2.1, WordPress 7.1 and PHP 8.3. Each failure sequence used distinct guest carts containing a $3 virtual product, an ordinary browser user-agent, and a local gateway that always fails without contacting a processor.

Classic and Blocks use different response formats. A test expecting HTTP 403 on both would misread the classic response.

The WordPress dashboard recorded a Woocommerce card testing detection. That is the source category; the test exercised a synthetic failed-order pattern, rather than actual card authorizations. Checkout refusal is also separate from a sitewide IP ban.

What I would test on another store

• The checkout path actually deployed, including Blocks if used.
• A normal successful test purchase and legitimate payment retries.
• The gateway’s documented test mode and any offline gateways.
• Guest checkout, shared-network customers and checkout extensions.
• Monitor mode versus enforcement, plus any proxy-configuration notice suppressing enforcement.

This does not establish resistance to rotating proxies, production conversion impact or a false-positive rate. The local checks use client-IP checkout history, so shared networks and IP rotation matter. Gateway fraud controls remain useful alongside application checks.

Try it

WebDecoy Bot Detection is on WordPress.org. Local protection works without a WebDecoy account. Update to 2.10.6 or newer before testing classic checkout.

Start in monitor mode, inspect the evidence, test your checkout in staging, and then review enforcement. The full test and rollout guide includes the setup and limitations.

Have you had a WooCommerce integration look enabled while its callbacks were missing? I would be interested in how you catch that in integration tests.

Written with AI assistance. Results come from the controlled tests described above.