CAPTCHA prevents login or order — safe recovery of keys, domain, provider and checkout compatibility

Goal

This guide explains how to diagnose and resolve a blockage caused by a CAPTCHA (e.g. Google reCAPTCHA v2/v3 or equivalent) that prevents:

• logging into the administration or a user account;
• creating an order or completing payment (checkout);
• registering or recovering a password.

It covers the safe retrieval of keys, domain and provider verification, and compatibility points for WordPress/WooCommerce and PrestaShop (1.7 → 9).

Prerequisites

• Administrator access to the CMS (administration interface);
• Access to the CAPTCHA provider (Google reCAPTCHA account or other);
• Access to the Securantis panel (SaaS) if you use centralized configuration;
• Recent backup of the site (files + database) before any security change affecting authentication.

Before acting: essential precautions

• Never send passwords by email or chat. Any request for access must go through the secure client area for a paid intervention.
• Do not automatically delete WAF rules or perform a restore without validation: quarantining and removing malicious files requires a human decision.
• If the CAPTCHA is applied server‑side (SaaS/WAF), note that a “fail-open/close” setting may exist; change it with caution.

Common diagnostic steps (applied to all platforms)

1. Reproduce the error in private browsing and without extensions to exclude browser cache and extensions.
2. Identify the exact moment when the CAPTCHA blocks: login page, registration, password lost, checkout step (cart validation, payment, bank redirection).
3. Check client‑side visible error messages (JavaScript console): key errors, unauthorized domain, missing API version or blocked request.
4. Verify whether the blockage is global (all users) or related to certain IP addresses/regions: ask a colleague or use a VPN.
5. Record the exact time and affected page — useful for correlation with WAF/server logs.

Safe key retrieval and domain verification

1. Log in to the CAPTCHA provider account (e.g. Google reCAPTCHA Console).
2. Check the key type (v2 “checkbox”, v2 “invisible” or v3) and retrieve the public key (site key) and the private key (secret key).
3. Verify the list of allowed domains for the key:
   • For HTTPS sites, ensure the exact domain (with or without www according to your site) is listed.
   • For multi‑domains or staging environments, explicitly add each domain or use a wildcard if the provider allows it.
4. If keys were regenerated recently, update the configuration in Securantis and in the CMS module/plugin. An incorrect key causes a browser‑side error or a server failure.
5. If you suspect a provider issue (CAPTCHA API outage), check their status page or test with a public test key if available.

WordPress & WooCommerce specifics

Goal: protect forms (login, registration, lost password) and the WooCommerce checkout without blocking the storefront.

Steps

1. Go to the CAPTCHA configuration panel in the Securantis interface or in the WordPress plugin (if you enabled a local integration).
2. Verify the supported version (v2 or v3) and ensure the key matches the selected type.
3. In WooCommerce, check the supported locations: standard checkout fields, account creation, etc. If you use a custom checkout (page builder, third‑party payment plugin), test the standard checkout to isolate the issue.
4. Temporarily disable CAPTCHA for the checkout only (if the option exists) and test whether the payment goes through. Do not leave the checkout unprotected longer than necessary.

Common errors and specific troubleshooting

• “Unauthorized domain” error: add the exact domain in the CAPTCHA console (www/non‑www) and wait a few minutes for propagation.
• JavaScript error (nonexistent key or wrong format): confirm that the public key is correctly entered in the plugin configuration.
• Broken custom checkout: some payment plugins perform special AJAX submissions — enable WooCommerce logs and compare network requests to see if the CAPTCHA token is sent.
• reCAPTCHA v3 score too low: v3 assigns a score; if your configuration requires a high threshold, it may reject legitimate users. Lower the threshold cautiously or experiment with v2 for the checkout.

PrestaShop (1.7 → 9) specifics

Goal: ensure the CAPTCHA module for PrestaShop protects front‑office forms (customer login, account creation) and checkout steps without interrupting completion.

Steps

1. Go to the CAPTCHA module in the PrestaShop back office and verify the API version (v2/v3) and the entered keys.
2. If a third‑party PrestaShop module affects the checkout (one page checkout, payment modules), temporarily disable CAPTCHA on the checkout to check if it is the blocker.
3. Test the flow with the “test mode” option if the module provides it.

Common errors and troubleshooting

• Module not compatible with third‑party checkout: some CAPTCHA modules do not recognize AJAX submissions or custom controls of payment modules. In that case, contact the checkout module vendor to verify compatibility.
• Missing token in the server request: enable the CAPTCHA module (or server) logs to verify whether the token is transmitted during submission.

Cautious settings and recommendations

• Do not switch CAPTCHA “off” for the checkout for an extended period: this exposes the store to bots and fraud.
• If you must reduce false positives, test: lower the v3 threshold gradually, temporarily switch to v2 “invisible” or restrict CAPTCHA to certain forms only.
• Document every change (who, what, why) and restore the previous configuration if the change worsens the situation.

Advanced troubleshooting

• Check WAF/Securantis logs to correlate the blockage: there may be overlap between WAF rules and CAPTCHA verification.
• Inspect HTTP headers and CORS headers if the token is loaded from a third‑party domain.
• For AJAX issues, use the browser Network tool to confirm the presence and format of the token in the POST request.
• If the CAPTCHA provider indicates the key is valid but your site receives a rejection, test with a test key or create a new temporary key pair for validation.

When to contact Securantis support

Contact support if:

• you have checked keys and domain and the CAPTCHA continues to block despite correct configuration;
• the blockage appears to originate from the WAF/Saas Securantis (correlation in logs);
• you see repeated error entries in Securantis logs and want assistance with analysis;
• you use a third‑party checkout module and need help confirming compatibility.

Information to provide to support (never transmit passwords)

1. Exact URL of the affected page and screenshots of client‑side visible errors;
2. Time(s) and timezone of reproducible attempts;
3. CAPTCHA type (reCAPTCHA v2 checkbox / v2 invisible / v3 or other) and confirmation that site/secret keys have been verified;
4. Indication if the checkout uses a third‑party module (name and version);
5. Export of relevant logs (WAF/Securantis) and captures from the network console showing the request/response (token present or absent, API error code).

What Securantis can and cannot do

• Securantis can help analyze logs, verify SaaS‑side configuration and propose WAF rule adjustments or CAPTCHA configuration changes.
• Securantis will not automatically remove a component nor recklessly change your keys; any impactful action (restore, file removal, access modification) requires your explicit agreement.

Expected outcome after resolution

• Users and administrators can log in and complete orders normally;
• Valid CAPTCHA requests are accepted by your backend and tokens are correctly transmitted from the frontend;
• False positives are reduced without exposing the checkout to bot risks.

Conclusion

First follow the diagnostic and key/domain verification steps, test on a standard checkout to isolate conflicts with third‑party modules, and provide logs and screenshots to support if the problem persists. Always act with caution and keep a backup before any major change.