Where the classic WooCommerce checkout actually submits
The form is on the checkout page. The request that places the order is not, and anything wired to the page template never sees it.
What we find in real checkouts, and what a shop owner can check for themselves.
The form is on the checkout page. The request that places the order is not, and anything wired to the page template never sees it.
The Checkout block posts JSON to a REST route. Code hooked to the classic checkout is never asked, which is why protection can look healthy and do nothing.
WooCommerce ships a second payment surface for orders that already exist. It calls your gateway directly, and none of your checkout validation runs there.
WooCommerce reads the shopper's address from a forwarded header. Behind a proxy that is either the proxy itself or a value the client chose, and both break rules.
Google gives a token two minutes and one verification. A checkout that takes longer than that fails honest shoppers, and the error code says so.
Failed orders are declines, not abandoned baskets. And the row count is not the attempt count, because WooCommerce reuses an order when the basket has not changed.
WooCommerce treats one page as the checkout. Any other page carrying the form can still place orders, and a captcha wired to the assigned page never sees them.
Google says the score is a risk signal, not a verdict. Here is how to read reCAPTCHA v3 scores on your own traffic and pick a threshold that does not cost you real orders.
Bursts of small failed authorisations, repeated addresses and throwaway emails look nothing like ordinary declines. Here is how to tell them apart with evidence you already have.
A captcha on the checkout page only covers the request it is wired to. The block checkout places orders through the Store API, where classic checkout hooks never fire.
Pro waitlist
The free plugin stays free. Join the launch list for founding pricing on Pro and one email when it is ready. Nothing else.
Received