Features
Every way an order can enter your store. Found, protected, or blocked.
On this page11 sections
- WooCommerce checkout protection across four surfaces, one token
- The Checkout Scanner
- Blocking: close the routes a token cannot reach
- The order-rate throttle
- Scoring, thresholds and what happens when Google is down
- Aim it precisely. Stay out of the way of real people.
- The events table and dashboard
- Compatibility and requirements
- What it does not do
- Questions shop owners ask
- Find out what your checkout looks like from the outside
WooCommerce checkout protection has to cover every route an order can arrive through. Checkout Bouncer scores every checkout attempt with Google reCAPTCHA v3. That includes the block checkout, which submits through the WooCommerce Store API and never fires the classic hooks a captcha plugin typically listens to. Then it scans your site for the routes it cannot score, and lets you close them.
Free on WordPress.org. Invisible to real customers. No puzzles, no image grids. For the reasoning first, why a captcha can be installed and still never run explains the gap this closes.
WooCommerce checkout protection across four surfaces, one token
A WooCommerce store rarely has one checkout. It has the page customers see, the endpoint the block checkout posts to, the pay link you send when an invoice needs settling, and the card-saving flow. Checkout Bouncer carries a reCAPTCHA v3 token through each of them and verifies it before the order exists.
Classic shortcode checkout
The traditional [woocommerce_checkout] page. The plugin attaches the token to the checkout submission and scores it during validation, so a failing order never becomes an order.
The gap several plugins still miss
Block checkout (Store API)
The block checkout posts to the WooCommerce Store API. Checkout Bouncer registers Store API endpoint data so the token travels with the request and the server verifies it before the order exists.
Pay for order
The pay link you send for manual invoices, and the page a customer lands on to retry a failed payment. It takes card details like any checkout, and it is often left unguarded. Checkout Bouncer scores it too.
Add payment method (optional)
Saving a card usually runs a small authorisation against it, which is exactly what a card tester wants. Protection here is a switch, because some stores use the flow heavily and some not at all.
Why the block checkout is the blind spot
Two orders can look identical in your dashboard and take completely different paths to get there. A captcha plugin hooked into the classic checkout sees the first path and nothing at all of the second. The store owner sees a plugin marked “active” and assumes the door is shut.
- ShopperCustomer
- PageClassic checkout
[woocommerce_checkout] - ServerClassic checkout hooksFire as expected
- ResultOrder
VerifiedA classic captcha plugin checks here, and this is the only route it watches.
- Shopper or botCustomer
- PageBlock checkoutWooCommerce Blocks
- ServerStore API route
POST /wc/store/v1/checkoutNo classic hooks fire - ResultOrder
UnwatchedMost captcha plugins never check this request. Checkout Bouncer carries the token through the Store API and scores it before the order exists.
The Checkout Scanner
Protection only counts when it points at the right page. The scanner reads your site the way an attacker would: it works out which page really is your checkout, what is rendering it, what else on the site can take an order, and whether your current settings actually verify anything.
1. It finds the checkout you are actually using
It locates the active checkout page, then works out what renders it: the WooCommerce checkout block, the classic shortcode, or a page builder. It detects six builders by name (Elementor, Divi, WPBakery, Beaver Builder, Bricks and Oxygen) because a builder can wrap the checkout in its own widget, and where the token has to be injected changes with it.
2. It hunts for duplicate and rogue checkouts
Most stores have more than one page that can take an order and do not know it. The scanner looks across the site for other pages carrying a checkout: the old design nobody deleted, the landing page a marketer built, the copy left behind by a migration, the draft that is still publicly reachable by URL. Every one of them is a working door.
3. It checks whether the Store API checkout route answers requests
The Store API checkout route accepts an order over HTTP whether or not anyone ever loads your checkout page. If your store does not use the block checkout, that route is a door with no lock on it. The scanner tells you whether it is reachable, and what your options are.
4. It flags settings that silently verify nothing
The worst state is not “unprotected”. It is the belief that you are covered. The scanner checks the configuration for combinations that quietly do nothing. It looks for missing or mismatched keys, script loading narrowed so no token ever reaches the surface you are protecting, gateway targeting that excludes everything, a protected surface your store does not use while the one it does use is left open.
Every finding comes with an action
A report you have to act on somewhere else is homework. Each finding offers a one-click Protect or Block on the spot, then you re-run the scan and watch the list shrink.
| What the scanner finds | Why it matters | What you can do |
|---|---|---|
| Active checkout renders the block checkout | Orders arrive through the Store API, invisible to classic hooks | Protect (token carried through the Store API) |
| Active checkout renders the classic shortcode | Standard path, standard validation | Protect (token verified before the order is created) |
| Checkout wrapped in a page builder widget | Token has to be injected where the builder renders the form | Protect (builder-aware) |
| Duplicate or rogue checkout page elsewhere | A second working door you are not watching | Protect it, or block the page outright |
| Store API checkout route reachable | Orders can arrive without a page ever loading | Protect it, or hard-block the route (404 or 403) |
| Configuration that verifies nothing | You think you are covered and you are not | Fix it from the finding |
Blocking: close the routes a token cannot reach
Some routes take no score at all, because nothing on the other end is a browser. A script posting straight at the Store API checkout route never runs your JavaScript, so there is no token to grade. For those, the answer is not a better score. It is a closed door.
What you can block
- The Store API checkout route. Hard-blocked, returning either a 404 so the route looks like it does not exist, or a 403 so the refusal is explicit in your logs.
- Rogue duplicate checkout pages. The stray copies the scanner turned up, closed one at a time.
The guard rails
- It never offers to block your own active checkout. The one page your revenue depends on is not on the menu, however hard you click.
- It warns before you enable a block. If your store runs the block checkout, blocking the Store API route would break your own orders, and you are told that before anything changes, not after.
- Every block is reversible from the same screen that set it.
The order-rate throttle
A score judges one visitor at a time. Card testing has a shape a score cannot see: the same source, over and over, faster than any person shops. The throttle watches that shape and counts, per IP address.
Orders per hour
A ceiling on how many orders one IP address can place in an hour. You set the number to suit your store.
Failed payments per 15 minutes
The signature of a stolen-card run. Real customers mistype a card once, maybe twice; they do not mistype it eleven times in a quarter of an hour.
Distinct billing emails per hour
One address, a new identity every attempt. Households share an IP; they do not burn through a dozen different email addresses in an hour.
Monitor mode: try it before it can cost you anything
Rate limits make owners nervous, and they should, because a limit set too tight turns away paying customers. So the throttle has a monitor mode. It logs everything it would have stopped and blocks nothing. Run it for a week, open the events table, and see exactly who your limits would have caught. If the list is bots, switch enforcement on. If a real customer is in there, loosen the number first. You never have to guess with live orders.
Scoring, thresholds and what happens when Google is down
The threshold is yours
reCAPTCHA v3 returns a score between 0.0 and 1.0. The lower it is, the more the traffic behaves like automation. Anything under your threshold stops, with the reason in the log. The setting is configurable; 0.5 is Google’s own recommendation and a sensible place to start. Raise it if you are under attack, lower it if legitimate customers are being caught, and use the events table to decide which.
Fail open, or hold the line
If Google cannot be reached (a network problem, a timeout, a key that has stopped working), something has to give. Fail-open is configurable. Leave it on and orders keep flowing while verification is unavailable. Turn it off and nothing gets through unverified. It is a straight trade between lost sales and unchecked orders, and it is your call, not ours.
Why the script loads sitewide by default
reCAPTCHA v3 scores a visitor on how they behave across your whole site, not on one page in isolation. A visitor who lands directly on the checkout and submits gives Google almost nothing to judge. That is why the script loads sitewide by default; it is what Google recommends, and it produces a score worth acting on. If you would rather keep third-party requests off the rest of the site, you can narrow loading to checkout screens only, accepting a thinner signal in return.
Aim it precisely. Stay out of the way of real people.
A security plugin that gets in the way of your own team, or of a trusted wholesale customer, gets switched off within a month. These settings exist so it stays on.
Per-gateway targeting
Apply protection to all gateways, or include only the ones you choose, or exclude specific ones. The list is built from your store’s real gateways, so you pick from what you actually have. Guard the card gateways bots are testing against; leave bank transfer or cash on delivery alone.
Staff-role bypass
Chosen roles skip the check. Placing a test order, taking a phone order, or reproducing a customer’s problem should never end in a failed score and a support ticket about your own security plugin.
IP allowlist, IPv4, IPv6 and CIDR
Single addresses or whole ranges in CIDR notation, IPv4 and IPv6 both. Your office, your warehouse, your agency, the trade customer who orders forty times a week from one connection.
The events table and dashboard
WooCommerce checkout protection is only as good as the evidence it leaves behind, and most security plugins ask you to take their word for it. Checkout Bouncer writes down every decision it makes so you can check its work.
- Every check is recorded as an event, whether pass, fail or block, with the reason it was recorded that way.
- The dashboard totals your passes, fails and blocks, and ranks the top block reasons so you can see at a glance what is actually hitting your store.
- Export the events to CSV when you want to work in a spreadsheet, keep a longer record, or show someone else what happened.
- This is how you tune the threshold, and how monitor mode pays for itself: real numbers from your store rather than a guess.
Compatibility and requirements
| Requirement | Detail |
|---|---|
| WordPress | 6.2 or newer |
| PHP | 7.4 or newer |
| WooCommerce | 7.0 or newer |
| HPOS (custom order tables) | Compatible |
| Block checkout | Compatible, via Store API endpoint data |
| Google reCAPTCHA v3 keys | Required. Free from Google. |
What it does not do
WooCommerce checkout protection has edges. You are going to find them on day one anyway, so here they are on day zero. Knowing the edges of a tool is how you know what else you still need.
- reCAPTCHA v3 only. No v2 checkbox, no hCaptcha, no Turnstile. If your policy requires one of those, this is not your plugin.
- It protects the checkout, and only the checkout. Login, registration, comments and contact forms are outside its scope. Use a dedicated plugin for those.
- It is not a firewall and not a malware scanner. It does not sit in front of your site, inspect files, or clean an infection. It makes a decision at the checkout.
- It needs free Google reCAPTCHA v3 keys. Ten minutes with a Google account. No keys, no scoring.
- No score is perfect. That is precisely why there is a threshold you control, a monitor mode, an allowlist, and an events table that shows you every decision.
Questions shop owners ask
I already use Cloudflare. Do I need this?
Cloudflare and Checkout Bouncer solve different halves of the problem, and Cloudflare is genuinely better at its half than this plugin will ever be. It is the right tool for volume: floods, layer-7 denial of service, and traffic from known-bad networks, all stopped before it costs your server anything. Checkout Bouncer runs after WordPress has loaded, so every request it judges has already cost you PHP.
What Cloudflare cannot see is your orders. It inspects HTTP requests, so it does not know which gateway was charged, which billing address was used, or whether a request actually created an order. It cannot express the rule that matters most against card testing: this address has placed nine orders with nine different email addresses in the last hour, and seven of them failed authorisation. That information only exists inside WooCommerce.
Rate limiting does not map neatly onto checkouts either. The block checkout posts to the same Store API namespace that real shoppers use for cart updates and shipping recalculation, so a blunt limit there turns customers away before it stops a bot.
There is a pricing reality too. The Cloudflare product that genuinely scores this traffic is Bot Management, an Enterprise feature. Most WooCommerce stores run on the free or Pro plan, where the available bot protection is tuned for crude automation rather than a headless browser on a residential proxy placing a handful of orders an hour.
Run both. Cloudflare for volume, Checkout Bouncer for intent. And note that Cloudflare will never tell you your block checkout is unprotected, but the Checkout Scanner will.
Setup, cost and running it day to day
Will my customers have to solve anything?
No. reCAPTCHA v3 is invisible. There are no puzzles and no image grids. A real customer checks out exactly as they did before and never sees the plugin.
I already have a captcha plugin. Why would I need this?
Run the Checkout Scanner and find out. If your store uses the block checkout, orders arrive through the Store API and never fire the classic checkout hooks a general captcha plugin hooks into. The scanner also finds duplicate checkout pages and settings that quietly verify nothing. If it comes back clean, you have lost ten minutes and gained a certainty.
What happens to an order that fails the check?
It is stopped before it becomes an order, and the attempt is written to the events table with the reason. Nothing reaches your gateway, so there is no authorisation to be charged for and no failed payment sitting in your account.
Is it safe to turn on during a busy trading period?
Start with monitor mode on the throttle, keep fail-open enabled, and leave the threshold at Google’s recommended 0.5. Watch the events table for a few days, then tighten. Nothing has to be decided blind.
Does it cost anything?
No. The WordPress.org version is free and fully functional: everything on this page is in it. A Pro tier is planned but not released yet; you can join the waitlist on the pricing page.
Find out what your checkout looks like from the outside
Install it, run the scan, read the findings. That is WooCommerce checkout protection in the order that works. Protect what can be protected and block what cannot. It is free, it is fully functional, and the whole thing takes about ten minutes.
Questions about a specific setup? Support · How the scanner works · Changelog