The pay-for-order page is a checkout too
Bots test cards on the WooCommerce pay-for-order page by retrying a failed order. Here is how it works and how to protect or close it.
What we find in real checkouts, and what a shop owner can check for themselves.
Bots test cards on the WooCommerce pay-for-order page by retrying a failed order. Here is how it works and how to protect or close it.
What a reCAPTCHA v3 score of 0.5 or 0.7 means at checkout, and how to pick a threshold from your own store data instead of a forum post.
Bots can place WooCommerce orders through the Store API checkout route without ever loading your checkout page. Here is how, and what protects it.
What to do in the first hour of a card-testing attack on WooCommerce, step by step, from confirming it to talking to your gateway.
Google runs two products under the reCAPTCHA name, in two consoles, with two different verification APIs. Here is how to tell which one your keys belong to, and what follows from that.
A velocity check counts repeated events and reacts when a threshold trips. The interesting part is not the counting, it is choosing what counts as the same thing.
WooCommerce records where each order came from, but the browser collects that data and submits it with the order. What the fields are, and what an odd profile is actually worth.
Order notes need an order to exist. The attempts that never became one live in logs or nowhere, and logs only record what was running at the time.
A WordPress nonce is not used once. It is valid for a window, and a cached checkout page carries one minted for somebody else. Your own test order passes because you are signed in.
A BIN attack fixes one bank's card range and varies everything else. Here is what that leaves behind in your own order data, and what it does not.
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