Alexandru Cotescu
Forum Replies Created
-
Hello again,
Thank you for all your suggestions, but it seems we don’t have the same understanding about this issue. Could you please tell me what do you want to test on the staging environment? Could you please detail a little bit your investigation strategy? A plugin conflict (that you are expecting to find) would have been there since the first installation of the actual environment. It would not appear overnight, after 3 months of correct usage of the EXACT SAME environment. Do we agree on this?
Since this morning I am trying to explain, there are some scripts triggered by Stripe overloading the processor and blocking the page in the browser.
The scripts overloading the processor are related to hCaptcha – Advanced fraud detection policy used by STRIPE with captcha integration. These scripts are blocking the browser, so the page becomes unresponsive. After manually blocking these requests, the checkout page is not blocking anymore, but no payments were available for the customers.
Did you simulate the checkout process on your end, on the production website?
I am looking forward for a real solution as soon as possible. My business is blocked for the 2nd time in the last 3 months because of this issue – not related to our backend environment.
Hi again,
Additional details: we do not use any caching system (as WpRocket or something similar) on the website. The server is just fine, if I disable the Stripe plugin everything goes back to normal, but without having the correct payment methods available for customers.
What I mean by blocking my checkout page looks as following:
- you add to cart one product and go to the checkout page
- first, everything loads correctly
- when you try to fill, for example, the shipping details (name & address) the form becomes unresponsive, you click in the name field and it takes seconds until you can start adding your name, every letter you type takes again seconds to be registered in that field.
- also, while you choose your preferred payment method it takes several seconds to update your selection
- again, if you want to check the “I agree terms & condition” box, it takes again seconds and everything becomes more and more unresponsive in time.
- in the end, if you manage to fill in all the details and click on “place the order”, the page becomes totally unresponsive while trying to load.
According to my developer analysis since last time, there are some hCaptcha processes (infinite requests) running in the background and overloading the processor so the page becomes unresponsive). If I manually block those requests, the page becomes responsive again but the payment methods are not shown anymore on the page.
If you want to test it on your own, here is my website: https://azpets.nl, add any product to cart and try to simulate the checkout process on your own. If you make an “inspect element” in the checkout page, you’ll the those infinite requests (hCaptcha) blocking the page.
Regarding updating the WooCommerce version to last release, I understand why you recommend keeping the system to last version. For now, on my end it is not possible because I have some other critical plugins without support yet for the latest WooCommerce release.
Thank you, Alex
Hi,
Thank you for your fast reply. Before rushing things to Woocommerce update, the topic is not related to WooCommerce Stripe Gateway version 9.8.1.
I am not sure if you understood the issue as presented, but the environment used on prod at the moment the issue appeared was exactly the same as 3 month ago, the same Woocommerce version 9.9.4 & the same WooCommerce Stripe Gateway 9.5.2.
As also mentioned above, the first time this issue appeared on my end it was solved after a while, without any action implemented on my end.
Could you please start your analysis starting from this inputs? I can’t update WooCommerce to latest version because of other plugins compatibility. Anyways, you have to understand the same environment had this issue 3 months ago, after a while the issue disappeared and 2 days ago it appeared again. The exact same environment.
Do you have any idea on how is this possible?
See here again the main issue explained in the initial post:
“The scripts overloading the processor are related to hCaptcha – Advanced fraud detection policy used by stripe with captcha integration. Last night we’ve noticed a lot or request were sent to hcaptcha.com coming from the stripe script. (we have no other plugin to use captcha). After manually blocking requests to ‘r.stripe.com’ and ‘js.stripe.com’, the checkout page was not blocking anymore, but no payments were available for the customers.
We also tried to activate test mode, and while doing this, everything works fine, nothing is blocking the checkout page.
We already checked logs and nothing related to this can be found.”
Thanks,
Alex
- This reply was modified 9 months, 1 week ago by Alexandru Cotescu.
The issue was solved in the meantime. I still don’t understand how was that possible, because I still didn’t make any modification on my end. Thank you for your involvement.
Hello and thank you for your reply,
It is difficult to imagine some plugins conflict as long as it worked perfectly until 16th of June (when I received several orders from customers). As I mentioned in my initial post, there were no modifications / configuration updates / plugin updates between 16th and 17th of June when issue appeared. Once noticing the issue during a test order, on 19th of June in the evening, I updated plugins to last versions looking for a solution.
I can try to do the test on staging version, but I am afraid the issue is not related to any conflicts. If there is a plugin conflict, it should generate issues since the beginning.
Looking forward to hearing from you.
Alex
Hello Mahfuzur,
Thank you for your reply.
The scripts overloading the processor are related to hCaptcha – Advanced fraud detection policy used by stripe with captcha integration. Last night we’ve noticed a lot or request were sent to hcaptcha.com coming from the stripe script. (we have no other plugin to use captcha). After manually blocking requests to ‘r.stripe.com’ and ‘js.stripe.com’, the checkout page was not blocking anymore, but no payments were available for the customers.
We also tried to activate test mode, and while doing this, everything works fine, nothing is blocking the checkout page.
We already checked logs and nothing related to this can be found.
Looking forward to hearing from you,
Thanks,
Alex
- This reply was modified 11 months, 3 weeks ago by Alexandru Cotescu.