Can you please add a honeypot to prevent spammers?

Thank you reaching out to us. I have submitted a message to the developers to investigate further your request.

Kind regards.

The question is the following:

If it will be a good long term solution that will solve the issue for good.

The captcha option offers that ultimate solution. So we ended up implementing that solution after discussing this with Stripe engineers.

We will explore the honeypot option that you recommended.

@mra13, well captcha is not the “ultimate” solution to users who care about their customers’ privacy and who are aware of the extensive legally required disclosures in a privacy policy that are required to us Google reCaptcha. I believe that most WordPress “web developers” have not brought this up yet simply because they are ignorant of the law and privacy concerns around implementing Google reCaptcha into a website.

Thank you for exploring this. Honeypots are not at all complicated to code into a form. If you do, please forgo the “display:none” format since many bots are trained to ignore such fields and, instead, opt for a hidden repositioning.

Hi.

The way payment form works, honeypot won’t help to prevent cards testing attempts. Payment is handled by JavaScript code via AJAX requests. It is made like that so the customers could have single-page checkout experience – e.g. if any error is occurred during the process, they’re informed at once, without the need to wait for the page to reload etc. Since this is not the actual form submission, honeypot is useless.
When the form is actually submitted to the server (e.g. when redirecting to thank you page), the payment is already processed by Stripe. So checking the honeypot at this stage is useless as well.

If you can provide server access logs and plugin logs (for the time period when you had spam submissions) for us to analyze, we can try to think of some alternative method of repelling spam submissions.

@alexanderfoxc I am confused when you say:

When the form is actually submitted to the server (e.g. when redirecting to thank you page), the payment is already processed by Stripe. So checking the honeypot at this stage is useless as well.

I understand the workings of Javascript in creating a live-response environment. But why would Stripe already process a transaction that a customer has not yet even consented to and potentially lose their transaction charge cost if said customer does not purchase? I don’t even think that is legal to do per PCI compliance and transaction laws. Also, how is it that you can successfully implement Google reCaptcha into this process but not a honeypot? Both operate as static barriers to overcome before advancing in a process like a button press or a form submission so why would one be possible to implement and not another?

I think you misunderstood me a bit.

By actually submitted I meant the HTML Form submission.

Also, how is it that you can successfully implement Google reCaptcha into this process but not a honeypot? Both operate as static barriers to overcome before advancing in a process like a button press or a form submission so why would one be possible to implement and not another?

Because Google reCaptcha operates differently than a honeypot. Honeypot is just a form field, while reCaptcha has certain logic that can tell a bot from a human by using behavior analytics etc. It’s also can’t be solved with JS disabled in the browser (unlike honeypot), which adds additional barrier against some bots.

Last, but not least: due to increasing plugin’s popularity, there seem to be tailor-made bots that are targeting payment forms. So even if there was a way to add a honeypot, it wouldn’t be much helpful anyway as bots can be easily adjusted to ignore those. And this is the reason why I have asked you to provide bots access logs if possible. This should help us to figure out how they operate and what can be done to repel them.

At the moment, reCaptcha is the best option. Another option is to use free CloudFlare protection, which does pretty good job at blocking bots.

Additional solution that comes to my mind is to use our own kind of captcha (not Google reCaptcha), which can be built it in into the plugin.

By actually submitted I meant the HTML Form submission.

I feel as though you are talking in circles with me. Are you saying that your plugin uses an HTML form submission for the Stripe payment gateway? Honeypots can specifically be implemented into HTML forms. I don’t understand the hold-up there.

Because Google reCaptcha operates differently than a honeypot. Honeypot is just a form field, while reCaptcha has certain logic that can tell a bot from a human by using behavior analytics etc.

So, are you talking about Google reCaptcha V3 then? It sounds like you are because v3 is the only version of Google reCaptcha that uses live page tracking methods. This confuses me since your plugin is only designed for Google reCaptcha v2, which is specifically designed to use a static not-a-robot click prompt via HTML submission, exactly like a honeypot would do.

Last, but not least: due to increasing plugin’s popularity, there seem to be tailor-made bots that are targeting payment forms. So even if there was a way to add a honeypot, it wouldn’t be much helpful anyway as bots can be easily adjusted to ignore those. And this is the reason why I have asked you to provide bots access logs if possible. This should help us to figure out how they operate and what can be done to repel them.

I think that you are a bit misinformed with honeypot technology and how successful they are at blocking bots. They have advanced in their methodology over the past several years to stay ahead of bot games rather well. A properly (and incredibly easily) designed one can have multiple ways to fool bots so that a successful bot would have to overcome not just one filter but multiple. Case-in-point, before using the Elementor honeypot on their forms, I would get hundreds of bot spams all the time. Since implementing them on my sites multiple years ago, I have had exactly 0 bots get through.

At the moment, reCaptcha is the best option. Another option is to use free CloudFlare protection, which does pretty good job at blocking bots.

CloudFlare has major issues with its CDN and IP blocking that I choose not to partake in and hinder my page speeds, uptime, and international customers. In a world where cloud content host provider technology is more and more normalized, CloudFlare becomes less and less of a viable option which more often hinders than helps a website in said circumstances. But I appreciate the suggestion as a possible alternative solution.

Additional solution that comes to my mind is to use our own kind of captcha (not Google reCaptcha), which can be built it in into the plugin.

The less outside access to my customer data the better so I tend to stay away from captcha technology all together when honeypots still work quite well but yes, if you added hCaptcha support to the plugin (incredibly simple to do if you have already added Google reCaptcha support) that would be a step in a good direction.

• This reply was modified 3 years, 2 months ago by Superpigdots.

I feel as though you are talking in circles with me

That’s incorrect assumption and I’m sorry if my replies made you feel this way. What I’m saying is that the way our plugin is using AJAX requests, honeypots won’t work. And I do know how they work. It seems like you’re not quite understanding how AJAX stuff works. But it’s out of my competition to mentor you on this topic, please accept my sincere apologies for that as well.

So, are you talking about Google reCaptcha V3 then? It sounds like you are because v3 is the only version of Google reCaptcha that uses live page tracking methods. This confuses me since your plugin is only designed for Google reCaptcha v2, which is specifically designed to use a static not-a-robot click prompt via HTML submission, exactly like a honeypot would do.

Our plugin is using reCaptcha V2 indeed, which does relies on user actions analysis. When it thinks that a user is a bot, it requires them to find fire hydrants. If not – checkbox click is sufficient. So there is a big difference between a honeypot and reCaptcha V2.

if you added hCaptcha support to the plugin (incredibly simple to do if you have already added Google reCaptcha support) that would be a step in a good direction

Heard you loud and clear ?? We already had several requests to implement hCaptcha as an alternative to reCaptcha, we have a ticket created for this request in our inner system. I will make sure to assign a higher priority for it, so expect this to be available in the next plugin version (which should be coming early next week).