Just want to let you know after reconfiguring everything from scratch, the issue is no longer reproducible, feel free to switch the thread to “solved”.
Thank you so much for the amazing support! EZ 5 start review!
The mode is set on the WooCommerce order’s metadata when it’s processed via the checkout page. Is it possible someone changed the order’s status to pending and tried to process a payment again with test mode enabled?
The behavior is consistent with all ACH order so far.
Here’s the timeline:
Payment started in Live mode (Feb 2, 2024, 11:20 AM)
After 6 days, Payment succeeded was triggered in Live mode (Feb 8, 2024, 6:42 AM)
After one minute a new payment started in Test mode for the same Woo order ID (Feb 8, 2024, 6:43 AM)
The _payment_intent order meta data in Woo now belongs to the new Test mode payment.
Because of this, the webhook process function fails to change the order status.
There are quite a few merchants using the ACH integration and I’ve never heard of this issue before.
Yes, that’s why I’m still not convinced it’s a reproducible issue. I’m still waiting to hear back from my client. I’ll let you know if uninstalling/reconfiguring everything doesn’t help.
What is your Stripe account ID? You can find that on the API Settings page of the plugin.
The account ID in the plugins setting’s match the one in Stripe.
Here’s what I found.
At 2-Feb an order was started with ID 14930 (Live Mode).
When the ACH payment cleared on the 8th, the payment in Stripe was completed but at the same time, a new payment was started in test mode for the same order ID with incomplete status. Its intent ID is the one I found in the order meta is the one from the test mode payment.
I will be asking my client if they’re ok with uninstalling the plugin and reconfiguring everything from scratch.
Before I ask them to place a new livemode order, do you know how something like this would happen?
Your logging statements are a bit confusing because you used The order: twice. It’s best to make unique statements per log entry so there’s not confusion about what line it came from.
I’m only keeping it one at a time, so I know where it’s coming from. Sorry, I should’ve mentioned that.
I did your way, and it’s the one from line 293, which is expected the site is using the post table.
The culprit isn’t wc_get_order, the value of the $order variable is correct when logged.
It’s only when passed to wc_stripe_process_payment_intent_succeeded , the value is NULL even though the $intent is valid.
In WC_Stripe_Utils::get_order_from_payment_intent, the plugin makes sure the _payment_intent_id metakey exists and it’s value matches the ID of the payment_intent from the webhook. You can view that code here. See if your order is missing the _payment_intent_id metakey or value.
Both the key and value are there. Also, wrapping it with absint made no difference.
I don’t get why would this happen only in Live mode.
Since you’re using HPOS, did you confirm that the order ID in the payment_intent’s metadata corresponds to an entry in the orders table?
The site is actually using the post table, but I did test with both storage modes, same result.
Are you using the filter wc_stripe_filter_order_id at all?
I was just given access to the website today, but I disabled all plugins and switched themes in case there was something in the functions.php file, so no, it’s not possible.
When fetching an order via the wc_get_order function, WooCommerce attempts to find the order in the cache first. Perhaps you have a caching issue with live orders?
Hmm, I didn’t know this. The website is hosted on WP Engine which has many caching features. I’ll try to disable all the options they allow and let you know.
EDIT:
Do you have multiple webhooks setup for this Stripe account that point to different websites?
There are only two webhooks, one for test and one for live mode.
Hello we are selling physical product. Yes the status is changing.
To confirm, does this happen with all payment methods?
In WooCommerce, it’s normal for orders to be cancelled if they remain unpaid for 30 minutes so your payment gateway might be simply not marking the order as paid within this time frame. You can adjust this period from WooCommerce → Settings → Inventory.
If it happens with all payment methods, please provide a screenshot of the note from an example order.
If you don’t already have a screenshot service installed, here are a few free options:
Yes, everything is basically the same. There are a couple plugins you won’t see such as “Atrexsync” this is our ERP system, and we don’t want to sync our live inventory with the test site (for obvious reasons). If you can’t find anything at all then that means this problem lays in the arms of our ERP. So, again I really appreciate you doing a deep dive look in to this issue
I tried replicating this by creating a test product with a category using the REST API but everything is working as expected.
Something in your site is forcefully defaulting to the “Uncategorized” category, possibly due to a custom solution/plugin.
Or as the ERP developer’s suggestion, the problem might be related to the WooCommerce REST API. However, I’m currently unable to replicate the issue. To effectively troubleshoot, it would be helpful if the ERP developer could provide any findings or steps they’ve encountered regarding this issue.
Please note that we can only help with the WooCommerce side of things per our support policy. If you require assistance with implementing or fixing third-party solutions, we recommend hiring from our pool of vetted WooExperts available here: WooCommerce Experts. :)
We’re going to do a sales action and only those registered in a group will have access to the category only those registered in a group. I don’t know if the plugin indicated is indicated.
If your goal is to password-protect specific pages, then yes, this plugin can assist you with that. :)
Thank you for bringing this issue to our attention. The team is actively working to resolve it as fast as possible.
If for whatever reason you’re not able to downgrade to version 8.4.0, you can try enabling the marketplace suggestions option which the issue originates from via the following WP-CLI command.
