How reCAPTCHA verification works
Updated September 13, 2026
Verification happens in two halves: the browser solves a challenge and receives a token, then your server sends that token to Google to confirm it is genuine. Understanding the split explains most of the problems people run into.
The client half
The plugin renders a g-recaptcha container carrying your site key, and loads Google’s api.js. Google turns that container into the familiar checkbox widget.
When the visitor completes the challenge, Google places a response token in the page. On a classic form it goes into a hidden g-recaptcha-response field that posts with the form. On the Checkout block there is no form post, so a callback writes the token into the checkout’s Store API extension data under the rcfwc namespace instead.
The site key is public by design. It identifies your site to Google and is visible in the page source of every protected form.
The server half
On submission the plugin reads the token and sends it, with your secret key, to Google’s verification endpoint:
https://www.google.com/recaptcha/api/siteverifyThis is an outbound POST request made from your server with wp_remote_post(). Google replies with a JSON body containing a success boolean and, on failure, an error-codes array. The plugin blocks the submission whenever success is not true.
Because the check is server-side, your host must allow outbound HTTPS to google.com. A firewall blocking that fails every submission regardless of what the visitor does.
Token lifetime and single use
Two properties of the token cause most support cases. It expires roughly two minutes after the challenge is solved, and it can only be verified once. A visitor who solves the challenge early and submits late, or who retries after an unrelated error, will fail.
The plugin therefore resets the widget when the checkout updates or returns an error, so a fresh token is issued for the next attempt. If JavaScript on the page is broken, that reset does not run and the customer gets stuck.
Where the check is attached
Each protected form hooks its own validation point. The classic checkout validates during checkout processing and adds a WooCommerce error notice. The block checkout validates while the order is built from the Store API request and throws an exception instead. Login runs on authentication and returns a WP_Error; registration and password reset add to the existing validation error object.
This is why failures surface differently depending on the form, even though the underlying check is identical.
Order of exemptions
Several conditions short-circuit the check before any request reaches Google: XML-RPC and REST requests on login and registration, gateways on the skip list, express payment detection on the block checkout, and the whitelist settings. If a form is not being enforced, work through those before suspecting the keys.
Compatibility
The plugin declares compatibility with WooCommerce High-Performance Order Storage, so it works on stores using custom order tables as well as legacy post-based order storage.