sarldsecom
Forum Replies Created
-
As I cannot edit my first post, here is an update regarding what I have been able to find to improve the situation:
1: In the Apple Pay browser-controled fragment (the iOS/macOS native component showing up when the shopper is clicking the Apple Pay button), the merchant name is currently set as the merchant company legal name.Actually, the merchant name in Express Checkout buttons it is set to the “Legal Name” if your “Trading Name” is undefined in https://business.revolut.com/settings/business-details. My Trading Name was undefined, so I have modified it to the store name. This solution will not suit corporations running multiple stores, but it can suit corporations running a single store.I understand. Our account
acct_1H4UDbA4E9tWwRaZhas been closed a few days ago during my vacation because of this bug leading to a spike of chargebacks for “Duplicate” reasons, so I will just create this Github issue -> https://github.com/woocommerce/woocommerce-gateway-stripe/issues/3509I’d appreciate if someone from Stripe could help in getting my account back up, after all, that’s because of a bug in the plugin, not because of our business.
Hi Zubair,
According to the stack trace, the issue happens when a failed payment is retried (see the call to function retry_after_error()) and for some reason, the $token cannot be retrieved.
I have went with a temporary solution in horrifiq.com, with this code just aborting the order and setting it as failed if the token is null. Not ideal as we should rather find the root cause on why the token is null in the first place.
Here is the Woocommerce status report –> report
Regards
Hi Zubair, hope you’re doing well !
Actually, I haven’t been able to reproduce the issue myself, even trying to use a saved payment method twice, so I believe the issue is indeed sporadic, and it most likely doesn’t affects all users. I did not had anyone confirming this was coming from the saved payment methods feature, but according to the stack, it most likely is.
I have sent you the related system report using your contact form on your website just now, hope it helps !
Regards
Edit: It seems to have happened at least 4 times today in our store, and we can link these crashes to payments
pi_3Q40oOA4E9tWwRaZ0Md0jnYF,pi_3Q40pCA4E9tWwRaZ1484062Q,pi_3Q42uxA4E9tWwRaZ1kSdv8FNandpi_3Q42vmA4E9tWwRaZ1fRFxaSv. This issue seems to mislead shoppers enough to believe their payment failed while it went through, and so, some of them are doing multiple orders inadvertently. There’s a real human and financial impact linked to this bug.- This reply was modified 1 year, 8 months ago by sarldsecom.
Forum: Plugins
In reply to: [WP Mail Logging] Woocommerce customer emails not loggingHi,
I can confirm the plugin doesn’t logs all emails for me too. Order on-hold, Processing order, Shipped Order and emails from WooCommerce Cart Abandonment Recovery (using the WordPress native wpmail) are not logged properly.
My hosting is Cloudways, and I’m using the latest version of the plugins.
- This reply was modified 2 years, 8 months ago by sarldsecom.
Deleted
- This reply was modified 2 years, 10 months ago by sarldsecom.
Forum: Plugins
In reply to: [Breeze Cache] Frequent 404 errors with cached JS and CSS filesIf my assumptions are correct, yes I think this would be a good workaround for this issue that you could implement. There are probably a lot of people using Breeze who are not monitoring their 404 errors and who would benefit from this.
Forum: Plugins
In reply to: [Breeze Cache] Frequent 404 errors with cached JS and CSS filesOkay, if I understand well, that’s why. For horrifiq.com we use the default value of 1440 minutes (1 day) for Purge Cache.
Let’s imagine without any post/page update, then it will remove the cache every day at let’s say 5am. But files are created all around the day, when people visit the website. So, it is possible that a file has been created at 4:50 am and is deleted just 10 minutes later.
We tested this tweak (set to 3 days instead of 2) to prevent files from being deleted if they’re less than 3 days old, and it seems to solve the 404 errors for us. The disadvantage is that a lot of cache files accumulate in 3 days but we’d rather lose 1-2gb of space than customers.
You might want to implement this into Breeze, while of course allowing admins to enable or disable it if they experience 404 errors.
Forum: Plugins
In reply to: [Breeze Cache] Frequent 404 errors with cached JS and CSS filesHi,
Yes absolutely, I can confirm that. In fact, it seems like it’s working fine most of the time, but our 404 monitor still registers errors for Breeze cache files that aren’t in their folders anymore. I have tried to replicate the issue without success but it seems like some of our customers are still encountering it. These files might get deleted too early by the plugin.
Just to make sure, are the folders purged every x minutes as set in the “Purge Cache After” setting, or are files independently removed x minutes after their creation date ?
- This reply was modified 3 years, 1 month ago by sarldsecom.
- This reply was modified 3 years, 1 month ago by sarldsecom. Reason: Ask about removal logic