Hi @golfball-uhu,
We noticed that your website is using an outdated version of our AntiSpam plugin.
Could you update the plugin to the latest version, clear the website cache, and then submit another test order and cancellation request?
Please let us know the results. Thanks!
Hi,
thank you for your reply.
I understand that updating the plugin is generally recommended. However, I am operating a live WooCommerce store with a relatively complex setup, and I do not update plugins on production systems solely for troubleshooting purposes unless there is a clear indication that the issue is related to a known bug fixed in a newer version.
My original question was actually about the behavior itself:
The exact same email address and IP address were accepted during the WooCommerce checkout process. Immediately afterwards, I submitted a cancellation request through the new cancellation page required by German/EU regulations, and CleanTalk blocked the request with the message:
“This message is blocked by CleanTalk anti-spam.”
Could you please explain why the checkout was accepted while the cancellation request was classified as spam?
Is the cancellation form processed differently from the WooCommerce checkout? Can you see in your logs which specific rule or spam check caused the block?
Before performing updates on a live system, I would appreciate understanding the root cause of the issue and whether it is related to a known compatibility problem or bug that has already been fixed in a newer version.
Thank you for your assistance.
@golfball-uhu We checked the request and noticed that some important parameters were not transmitted. Because of this, the plugin classified the request as spam.
We strongly recommend updating to the latest version of the plugin, as newer versions contain many improvements and compatibility fixes.
Hi Andrei,
I think we are talking past each other.
My main question is still unanswered:
Why was the WooCommerce order accepted from the exact same IP address and email address, while the cancellation request submitted immediately afterwards was classified as spam?
You mentioned that “some important parameters were not transmitted”.
Which parameters exactly were missing?
And why did their absence cause the cancellation request to be blocked, while the order itself was accepted?
You also recommend updating the plugin.
Can you explain specifically why updating should solve this issue?
- Is this a known bug?
- Was this exact problem fixed in a newer version?
- Which version contains the fix?
- What changed?
I operate a live WooCommerce store and I do not update plugins simply because support recommends it. Before updating, I need to understand the root cause and whether the newer version actually addresses this specific issue.
At the moment I still do not understand why a legitimate customer could place an order successfully but then be prevented from submitting a cancellation request from the same IP address and email address.
Thank you.
@golfball-uhu Thank you for your questions.
Why was the WooCommerce order accepted from the exact same IP address and email address, while the cancellation request submitted immediately afterwards was classified as spam?
And why did their absence cause the cancellation request to be blocked, while the order itself was accepted?
The WooCommerce checkout form and your cancellation form are different forms and use different hooks for spam protection. The WooCommerce order form did not have any issues transmitting the required parameters, so the request was processed successfully.
You mentioned that “some important parameters were not transmitted”. Which parameters exactly were missing?
We cannot disclose the exact parameters involved in our spam detection process.
These parameters help determine whether a form was submitted by a real user or an automated bot (for example, time when the form was filled and submitted).
If these parameters are missing or transmitted incorrectly, it can affect the verdict returned by our protection. This may be caused by caching, optimization settings, or another plugin installed on the website.
Is this a known bug? Was this exact problem fixed in a newer version? Which version contains the fix? What changed?
This is not a known bug, but as mentioned earlier, we continuously improve both our spam detection mechanisms and our integrations with form plugins. At the same time, form plugin developers regularly update their own products, so we test new releases and make adjustments when necessary to maintain compatibility.
If you still prefer not to update the Anti-Spam plugin, please let us know the name of the plugin which is used to create the cancellation form, and we will test it on our side.
Thank you!
Hi Andrei,
thank you for the detailed explanation.
The cancellation form is part of the German Market plugin. This functionality was introduced recently due to the new mandatory EU/German online cancellation button requirements.
I am no longer completely sure whether the specific test that triggered the block was performed as a logged-in customer or as a guest customer. However, that should not make a difference, as the cancellation process must work reliably for both scenarios:
- logged-in customers
- guest customers
My main concern is that legitimate customers could potentially be prevented from submitting a legally required cancellation request.
I appreciate your offer to test the form on your side. Please let me know if you need any additional information regarding the German Market plugin version or the cancellation process itself.
If you identify a compatibility issue between CleanTalk and the German Market cancellation form, I would be happy to forward the information to the German Market developers as well.
Thank you.
@golfball-uhu Thank you for the information.
We found two different plugins that may match your description: Germanized for WooCommerce (https://wordpress.org/plugins/woocommerce-germanized/) and German Market (https://marketpress.com/shop/plugins/woocommerce/woocommerce-german-market/).
Could you please confirm which of these plugins you are using?
Thanks.
Hello @golfball-uhu,
Please allow us 2-3 business days to the form. We’ll contact you as soon as we have any news.
Hello @golfball-uhu
Unfortunately, we’ve determined that we cannot resolve this issue from our end. To understand the root cause of the problem, we need to investigate it within your specific environment.
For access details (admin panel, FTP), please contact us through our private ticket system:
https://cleantalk.org/my/support/open
Hello denisxam,
thank you for your response.
However, I do not allow third-party access to my live shop via admin account, FTP or similar methods. Therefore I cannot provide the requested access credentials.
I have now updated CleanTalk on the live site (admittedly a bit reluctantly) and performed several tests afterwards:
- WooCommerce order as guest customer: successful
- WooCommerce order as logged-in customer: successful
- Cancellation request as guest customer: successful
- Cancellation request as logged-in customer: successful
At the moment everything appears to be working correctly and I am no longer able to reproduce the issue.
For now I consider the matter resolved and will continue to monitor the site.
Thank you for your support.
Best regards,
René Schadowski
Hello Rene,
Thank you for your response.
Please let us know if the problems recur.
Please keep us informed.
Best regards,
