gyrdnv
Forum Replies Created
-
Forum: Plugins
In reply to: [WooCommerce PayPal Payments] Increase of fraud orders@chriscarman there is an easy way to block these. I didn’t put the whole query string here publicly on purpose, since they may change it, etc., but anyway.
Back to blocking these — you can use either Cloudflare and create a custom rule on the WAF. Or you can use Wordfence and use the “Immediately block IPs that access these URLs” option.
But I think either WordPress/WooCommerce or WooCommerce PayPal Payments must address this issue sooner, as it’s ridiculous how easy it is to do fraud using WordPress. They are not very worried since most of the attempts fail, but I don’t see it this way. There’s obviously a vulnerability and they refuse to fix it.
Forum: Plugins
In reply to: [WooCommerce PayPal Payments] Increase of fraud ordersDisabling guest checkout didn’t work for any of my sites that are experiencing the current issue.
For now I mitigated this on one of my sites by using a Cloudflare custom rule, along with Wordfence’s feature “Immediately block IPs that access these URLs” by specifying /wp-json/wc/ and a very particular query string they all have been accessing.
Forum: Plugins
In reply to: [WooCommerce PayPal Payments] Increase of fraud ordersWe are not using Cloudflare — I will try implementing it on one of the sites and will see how it goes. For some reason I cannot log in to Woo.com, so can open a support ticket with the debug logs at the moment. Will try doing it later.
In the mean time, if you discover anything or have any other ideas, please share them here.
Forum: Plugins
In reply to: [WooCommerce PayPal Payments] Increase of fraud ordersHi Krystian,
thanks for your reply!
Most of these fraud orders fail. 3DS is set to “when required”.
FraudNet has been active all the time.
Payment intent is set to “Capture”, but as I said, most of these fail anyway, so that’s not the problem.
reCaptcha did not help.
One thing you didn’t address is that orders are *always* first created as drafts — this is not how normal orders received through the normal checkout flow are created. Here’s a screenshot of how the Order Notes look like for all of these fraud order attempts: https://imgur.com/a/6qKO2vC
This isn’t normal, so these are not being submitted on the checkout page. Additionally they all have “unknown” as their origin.
Moreover, I have now checked Wordfence, which is set to log all traffic. I checked it against one of the IPs used to submit these fraud orders and here’s what I see (I’ve hidden the IP address due to privacy): https://imgur.com/a/zslfP4n — this doesn’t seem right.
I’m concerned about sharing the the debug log of these orders publicly, as this seems to contain sensitive data.
In another support thread here, someone suggested disabling the wc_endpoint using a function. I haven’t tried that yet, but it doesn’t seem ideal anyway.
- This reply was modified 1 year, 5 months ago by gyrdnv.
Ah, thanks. I somehow didn’t see this. I will mark this as solved for now. Thank you!
Forum: Fixing WordPress
In reply to: no editor in 6.7 for SafariI’m assuming you are using Cloudflare – I had the same error in my browser’s console (on various browsers) on 2 sites behind CF. Ended up changing the caching level in Cloudflare from “Standard” to “No query string” and this sorted it for me.
Hi @shameemreza, we did not have much luck with Stripe’s support, unfortunately. They say the issue is most likely due to the integration we have on the website with Stripe, which is basically the plugin.
Just an update — we enabled the legacy checkout experience and Spanish is not appearing at the moment on the checkout.
Hi @shameemreza, here is the system status report: https://paste.mozilla.org/zLrKMScy
Thank you!
Hi @shameemreza, thanks for replying.
Unfortunately, it is very random to replicate. You are correct, that we are using Funnel Builder, but the Spanish language is coming from Stripe and not from the Funnel Builder.
I am attaching an image showing the browser inspector when the placeholders are in Spanish. The .pFieldLabel element is from js.stripe.com.
Do you want me to share the System Status Report?
Hi @doublezed2, the screenshot is from Safari, but I believe it has also happened in Chrome. You are right that the font is bold, but we don’t know why this is, either.
Do you, perhaps, have any other ideas?
Hi @carolm29, thanks for your reply!
Here are the answers to your questions:
- Do you know if the people seeing this are in countries where Spanish is the first language? — No, it’s happening in the UK, and we also had someone in Indonesia who was also able to replicate it.
- Do you see any similarities between the customers that are seeing this in Spanish? — not really, it is completely random.
- To confirm, this is only happening with Spanish and not any other language, correct? — yes, that’s correct. So far it has happened only with Spanish.
Thanks for your help! Let me know if I can provide you with more details.
Anyone care to reply? I see other support requests have been replied to, but mine seems to be actively ignored.
Thanks for your reply and feedback. Hope it can be fixed sooner.
Thanks for replying.
Sorry, I am not sure I understand. The problem is when I change in bulk from Custom status to a Standard status. There’s an apparent issue that an email is not being sent in such cases and I think it needs to be addressed by the plugin.
Changing the status from Standard to Standard works fine and emails is sent. Changing from Standard to Custom also works fine. But changing from Custom to Standard is where the problem is.
Anyone care to assist at all?