I am able to repeat the issue! I set the Threshold to 1 so it asks for the checkbox each time. I found it fails with Chrome, not Safari. When I click the by Debit or credit card, it just scrolls back up and doesn’t let me enter a credit card number. I am able to make it fail on my staging site as well as the live site.
ChatGPT tells me this –
The JSON response + payload tells us exactly what’s happening:
- The server is rejecting the
?wc-ajax=ppc-create-order call with ppcp_recaptcha_missing_token.
- In your request payload,
g-recaptcha-response is empty.
- The only reCAPTCHA-looking token I see is inside the big
form_encoded=... string (ppcp_recaptcha_token=...), but the backend is still deciding “no token was provided”.
So this is not “you didn’t solve the picture puzzle.” It’s a token handoff problem: the PayPal Payments “create order” request isn’t delivering the token in the exact place/format the plugin expects at the moment it creates the order, so it loops you back. This matches what WooCommerce describes: their PayPal Payments CAPTCHA is a layered v3→v2 system and order creation is blocked when verification isn’t present. Two important observations from your payload
g-recaptcha-response= is blank
That’s the standard field reCAPTCHA v2 normally fills. When it stays blank, lots of integrations interpret that as “CAPTCHA not completed,” even if the widget UI still looks checked.- This is happening on the card funding source path
Your payload includes ppcp-funding-source=card. Your customers specifically said it fails when they click Debit/Credit Card. So the problem is very likely specific to the card button flow, not PayPal in general.
Thanks for any help.
Hi @avfadagio,
Thank you for the detailed investigation and for sharing the payload findings, that was incredibly helpful. I can see how concerning this is, especially when it directly affects customers choosing Debit or Credit Card and loops them back to the CAPTCHA instead of letting them complete the order. You absolutely made the right call disabling it temporarily to avoid losing sales.
From what you’ve described, this does look like a token handoff issue between the PayPal Payments card flow and the reCAPTCHA validation. Since g-recaptcha-response is coming through blank while the order is being created, the server is correctly blocking the request with ppcp_recaptcha_missing_token. That would explain the loop behavior in Chrome, particularly on the card funding path.
To narrow this down further, here are the next steps I recommend:
- Run a full plugin conflict test: Deactivate all plugins except WooCommerce and WooCommerce PayPal Payments, then switch temporarily to a default theme like Storefront or Twenty Twenty-Four and test the card flow in Chrome again.
Guide: https://woocommerce.com/document/how-to-test-for-conflicts/
- Clear all caching layers: If you are using any caching plugin, server cache, or Cloudflare, clear everything and retest. reCAPTCHA tokens are time sensitive and caching can interfere with how they are passed during AJAX requests.
- Check PayPal Payments version: Please confirm you are running the latest version of WooCommerce PayPal Payments. If not, update and retest.
- Share logs and System Status Report: Go to WooCommerce → Status → Logs and check for PayPal Payments related errors around the time of the failed attempt.
Also share your full System Status Report via https://pastebin.com or https://quickforget.com so we can review the environment setup.
If the issue persists even after a clean conflict test, this may point to a regression specific to the card funding flow in combination with reCAPTCHA. In that case, we can escalate with a reproducible report including your logs and SSR.
You’ve already done excellent debugging here. Let’s run through the conflict test and logs next so we can pinpoint whether this is environmental or something we need to flag upstream. Looking forward to your findings.
I might have been wrong about Safari working. Looks like both fail.
I will work on getting another staging site where I can disable plugins. I’ll keep you informed.
I disabled most of my plugins. Switched to Storefront. Cleared cache. It still failed. But then I deactivated CleanTalk. Lo and behold it worked! The thing is I had contacted CleanTalk first and they said they had nothing to do with recaptcha!
I will contact them again since I can now make it fail on my staging site. That’s the key. I hate disabling spam checking on a live site. They are a good company so I expect they will respond well.
Thanks so much for your guidance. I will keep you informed on what I find.
Hi @avfadagio,
This is excellent troubleshooting on your part. I can imagine how frustrating it must have been seeing valid customers blocked at checkout, and you did a fantastic job isolating the issue down to CleanTalk. Being able to reproduce it on staging and confirm the conflict gives you a solid position when coordinating with their team.
Since we have now clearly narrowed this down to a plugin conflict with CleanTalk and WooCommerce core itself is not at fault, I will go ahead and mark this topic as resolved. That said, please feel free to return here and open a new topic if anything changes or if you need further assistance while working with their support team. We are always happy to help.
If WooCommerce has been helpful in your investigation and overall store setup, we would truly appreciate a quick 5 star review. It helps other merchants and supports the project’s continued development: https://wordpress.org/support/plugin/woocommerce/reviews/#new-post
Thanks again for your thorough debugging and collaboration here.
Hello,
I’m from CleanTalk support team.
If anyone encounters this issue, we have already fixed it. All the changes made will be included in the next stable release. The fixed version is here: https://github.com/CleanTalk/wordpress-antispam/releases/download/fix-version/cleantalk-spam-protect.zip
Use this instruction below to install the fixed version:
- Go to the WordPress Administrator Panel —> Plugins.
- Find the plugin “Anti-Spam by CleanTalk” —> Deactivate.
- After the automatic page refresh, find the plugin again “Anti-Spam by CleanTalk” —> Delete. Confirm “Yes, delete these files”.
- Go to Plugins —> Add New —> Upload Plugin.
- Download the plugin archive from the link above.
- Choose the downloaded archive and press “Install Now”.
Hi @avfadagio,
Thank you for following up, and thanks to the CleanTalk team for identifying the cause.
It’s great to hear that this has now been addressed on their end. As mentioned, the issue appears to have stemmed from a conflict between the Anti-Spam by CleanTalk plugin and the reCAPTCHA validation used during the PayPal card payment flow, which prevented the required token from being passed correctly.
We recommend installing the patched version shared above on your staging site first and confirming that the Debit/Credit Card checkout flow works as expected with reCAPTCHA enabled before applying it to your live site.
Please let us know how it goes once tested, we’re happy to assist further if needed.
Both WooCommerce and CleanTalk tech support have been great during this process. Thanks to both. My site is working great again with reCaptcha.
Hi there!
Great to hear everything’s working perfectly now! Your feedback helps us improve and reach more users. If you have a moment, we’d be incredibly grateful if you could share your experience by leaving a review here:https://wordpress.org/support/plugin/woocommerce/reviews/#new-post
Thank you
