- This topic has 55 replies, 2 voices, and was last updated 1 year, 2 months ago by
.
-
Posts
-
-
Hi Support, I have tried to dig through this and solve this myself, but have had no success. I am testing the updated Stripe module before rolling it out on the live site and it seems like the new Stripe integration is working properly as far as payments being accepted and transfers/payouts being made, but within WooCommerce/MultivendorX, I am seeing multiple status updates and if manage stock is enabled on the product, multiple stock reductions. I have email disabled on the sandbox site, so I’m not sure if multiple emails are triggered as well, but there is obviously an issue somewhere if the stock and status are being updated multiple times. Can you please help? My configuration under testing is as follows:
Stripe Test Mode Enabled
Stripe Connect – Express
Separate Charges and Transfers
Enable Stripe Marketplace
MVX 4.1.10
MVX Pro 1.3.6
WC 8.8.3Here are the screenshots of what I am talking about (these are from parent orders, not suborders, but there was only one vendor and one product on each order):
-
-
Sure. I am in a public place, so could not record audio, but you will see a simple order results in some crazy stuff happening in the order notes with stock reductions and status updates. In the database, you can also see there are a few records that are duplicated.
https://www.loom.com/share/5e98ae8b7d7148a29968dba0c11ae5d3?sid=aac94164-8a0d-4d87-a79b-1c3599249c99
Please let me know if you have any questions or need additional information. I can provide site access if needed.
-
-
-
Hello Justin,
Thank you for your cooperation. We have investigated the issue you reported. Firstly, let me clarify that the problem is not related to Stripe Marketplace. The function of Stripe Marketplace is to receive payments from customers and distribute them to the admin and vendors accordingly, and this process is working correctly.Regarding the issue with stock reduction, it appears that we are reducing the stock for suborders as well. That should not be the case. Not to worry, I have informed the dev team regarding this. They will add a fix for the issue in our next update. You can keep track of the issue from here :https://github.com/multivendorx/MultiVendorX/issues/758.
Regarding the multiple email triggers as we are not facing any such issue on our end, could you please specify which emails are being sent multiple times? It would be very helpful if you could provide access to a staging site where this issue is occurring so that we can investigate and assist you further.
For the status update sync, when the suborder status is synced with the main order status, we send an order note as shown here: https://prnt.sc/-Pe3AFCMvXg-. Could you please clarify the specific issue you are experiencing with this process?
Thank you.
-
Hi Sangita, thank you for the update. As I stated in my original post, I have emails disabled in the sandbox site so I don’t know whether multiple email notifications are going out, but I feared they might because of all the duplicate status updates and even the duplicate database records as you should have been able to see in my previous loom video. If you look in my previous loom video, you’ll also see there are LOTS of status updates in the notes… your screenshot is unrelated to the problem I am describing. Please rewatch my loom video and you’ll see that when placing an order, the following order notes show up regarding order status:
Order status changed from Pending payment to Processing.
Order status changed from Pending payment to Processing.
Order status changed from Pending payment to Processing.
Sync from vendor’s suborders: Order status changed from Pending payment to Processing.This is not normal. On the live site where I have not updated MVX, this is certainly not the case nor has it ever happened like this with MVX. There is only one “Order status changed from Pending payment to Processing” on all of our live site orders when an order is placed. I am also including a screenshot (from the same order in the loom video) that shows the timestamp on all the status updates is the same to prove that this is all happening at the time the order is processed and not caused by any action at a later time:
Please re-review the loom video in the previous post as it also identifies this issue just like the stock issue. Also note that in my loom video towards the end, I show that there are duplicate database records created for _mvx_vendor_new_order_mail_triggered. Whether or not two emails are sent out or not is, again, unknown since I have email disabled on the sandbox site, but the duplicate records are there in the database.
-
Thanks Justin for your detailed response. We checked your video again carefully and recreated the same flow on our end. But we did not get the multiple order status update notes on our end. Kindly check the video of the same from here – https://www.awesomescreenshot.com/video/28158991?key=a35c0cd8521ca25fc1c93cf60c6b4012.
Since you are encountering an issue with the database also, it might be related to another plugin or custom code. To troubleshoot, please deactivate all plugins except WooCommerce, MultiVendorX, and MultiVendorX Pro, and check the flow again. Additionally, switch to a default theme such as Twenty Twenty-Four or Storefront and check the flow.
If the issue persists with default theme and plugins also then , it could be due to database corruption on your end.
-
@Sangita The issue was not addressed in the last update and it has not been assigned or commented on in Github at all. What is the timeline on resolving this issue?
-
@Justin Harrison, We sincerely apologize for the delay. The issue has been logged on GitHub, and I have informed the dev team regarding the same and they will look into it and a fix accordingly. Also we will keep you updated as soon as a fix is implemented.
You can track the progress of the issue here: https://github.com/multivendorx/MultiVendorX/issues/758
Thank you for your understanding and cooperation.
-
-
@Sangita The fix did not fix the issue. I am still having issues with the stock being reduced multiple times. Here is a test from the latest order: https://prnt.sc/oFgZUy16AJmY
After reviewing the Github issue, it appears that the only changes were going from wp_get_post_parent_id( $order->get_id() ) to $order->get_parent_id() in two places in the MVX_Order class even though wp_get_post_parent_id is used in a lot of different functions in that class. If that were breaking something, it would need to be updated all over the place. I was surprised when I saw that because I didn’t think there was anything wrong with using either method, but I just have to trust the experts, however this indeed did not fix the problem.
Please test this fix yourself and address this with your developer. We have been waiting on this fix for weeks now and cannot update MultivendorX until it is fixed.
-
Sorry to hear that the fix did not work on your end.
As after adding the same fix on our end the stock was not getting updated after the order status update.
However, give us some time to check this further and we will get back to you accordingly.Thanks for your understanding and cooperation so far.
-
Hi Sangita, I have spent a lot of time troubleshooting and have narrowed it down to one setting…. Separate Charges and Transfers. If I keep everything the same and change to Destination charges, the issue does not occur. I will continue trying to debug the issue to see if I can locate the problem in the code myself, but if you followed my configuration above, you should be able to replicate this over a few orders:
Stripe Test Mode Enabled
Stripe Connect – Express
Separate Charges and Transfers
Enable Stripe MarketplaceI have turned separate charges and transfers on and off several different times and that is the one thing that triggers my issue every single time. In any other Stripe configuration, I do not get the issue like this screenshot:
https://prnt.sc/16r3_xCVWaIU -
@Sangita Please make sure to place many test orders when testing. Randomly on some orders, I’ll get a normal response and not tons of multiples of status updates and stock reductions. Most of the time I get the crazy results of multiple stock reductions.
-
Hi Justin,Thank you for sharing all the details with us.
We configured the Stripe marketplace exactly as you described and placed an order for a vendor product. While updating the order status from the suborder details page, we did encounter the stock reduction issue but did not experience any problems with multiple emails being triggered. We also faced the same stock reduction issue with other payment methods such as “COD.”
Please allow us some additional time, as our development team is currently working on a fix for the stock reduction issue.
Since we are unable to recreate the issue on our end particularly with Stripe marketplace payment option only, we kindly request that you create a staging site where the issue is present. Please share the staging site URL along with temporary admin and FTP access so we can investigate further.
Also while sharing the access don’t forget to mark your reply as private.
Thank you for your cooperation.
-
-
Justin, We sincerely apologize for the delay in providing the fix and appreciate your patience and understanding.
However thank you for sharing access to the staging site. We will review the stock reduction flow with the Stripe marketplace settings as you have outlined.
We will promptly share the fix with you as soon as it is ready.
Thank you once again for your cooperation.
-
-
Hi Justin Harrison, We sincerely apologize for the delay in providing a fix for the “Stock Reduction Issue.” Our development team is working diligently to resolve this as quickly as possible.
We have also investigated the issue on your end and confirmed that the same stock reduction problem occurs with the following stripe marketplace configuration that happens with other payment method such as COD.
Stripe marketplace account type: Express
Charge type: Destination chargesSo we would request you to provide us with some more time and we will provide you with the fix accordingly.
Again we are sorry for the delay and thank you for your understanding.
-
Hello Justin, We have added fix for the stock reduction issue on our github. Kindly download the fixed plugin from here- https://drive.google.com/file/d/1hNQ7GhGkZKCN6BFSZunk3RVNFpyQNRd8/view?usp=sharing and check whether everything works accordingly on your end.
We look forward to hearing from you regarding the same.
-
-
Hi Sangita, when testing with Destination charges, the new update seemed to fix the issue, but when I turned back on Separate Charges and Transfers which is the setup we use, I once again experienced the multiple stock quantity reductions. Please review the ticket as in multiple places I mention our setup being Separate Charges and Transfers. You can log into the sandbox site again and check my recent orders (350746 and 350750) and test for yourself. You can see in these screenshots the multiple stock reductions still occurring: https://prnt.sc/qQDx-toxLjQA and https://prnt.sc/atwVeTPa6L7i
Please let me know if you have any questions. Thank you.
-
Hi Sangita, while that did seem to fix the issue for Destination charges, it did not fix the issue for Separate Charges and Transfers which is the configuration we use. It worked while in Destination charges mode when I tested, but when I switch to Separate Charges and Transfers which I have mentioned many times in this ticket as our configuration, it does not work. Please log into the sandbox and test again. You’ll see the latest orders in the sandbox site have multiple stock reductions: #350746 and #350750. Here are screenshots: https://prnt.sc/atwVeTPa6L7i and https://prnt.sc/qQDx-toxLjQA
Please check on this with separate charges and transfers and take a look at the sandbox site to test there again. Thank you.
-
-
-
-
Hi Sangita, sorry, but we’re still seeing the issue on some orders. I placed 3 test orders since your last message that you added the fixed MultivendorX plugin to the sandbox site and 2 of the 3 orders still resulted in multiple reductions in stock. If you look at the orders on the site, you will see the 3 test orders I just placed and orders #350759 and #350767 both have their items stock reduced multiple times. (I won’t post screen links since those got flagged before) I am not updating or editing the orders in any way after the order is placed. The multiple stock reductions are happening automatically when the order is placed and processed without any change to the order status at the parent or vendor level by me (and obviously the timestamps should show that). I see your one individual test. Maybe when you test again or try to add in another fix, you can use the products from the two orders that are having issues to retest. I was randomly selecting products to test so I’m not sure why one order went through and only reduced stock once and the other 2 orders had multiple stock reductions. The products were not chosen for any particular reason as to what was being tested but they are from various vendors and are various types of products.
-
Hello Justin Harrison, We have checked the flow with the fixed plugin on your site, and it is quite strange that, while the fix works correctly on our site, it does not seem to be working on yours. Our development team needs to investigate this issue further.
We understand that this issue is causing significant problems for you, and we sincerely apologize for the inconvenience. Currently, our development team is occupied with preassigned tasks, so it may take some time to debug the issue on your site and provide a fix.
We will do our best to resolve this as quickly as possible. In the meantime, please keep the shared access to your staging site open so our team can investigate the issue.
We truly appreciate your understanding and cooperation.
Thank you again. -
Hi Sangita, I will do some additional testing to see if I can identify a commonality between products where it happens and products where it doesn’t. It is very odd to me that it works properly sometimes now but not other times, so I am wondering if there is a certain type of product or there are Stripe api calls and responses that are varying based on vendor. I will do some more testing, take a look at product details, take a look at the Stripe API logs to ensure they all match and do not vary, then report back any findings I have. I appreciate your assistance in this matter.
-
-
Hi Sangita, I did analyze the Stripe API logs and found no differences in the API logs on the requests and responses for orders where the stock was reduced multiple times versus just once, so I don’t believe there are any leads there to answer the question. I have not done any other troubleshooting or debugging on the site yet, but I did want to go ahead and mention that I ran comparison analysis on all Stripe API requests and responses and found no issues or discrepancies or differences there.
-
Hello Justin, Thank you for keeping us updated about your findings. .
As you mentioned, the fix sometimes works but sometimes it causes unusual stock reduction issues on your site. Our team will need to conduct debugging on your end to pinpoint the root cause and implement a suitable solution. Please allow us some time to proceed with this investigation.
In the meantime, please keep us updated with any further findings from your analysis. Any additional information will help our team in their debugging process and assist in resolving the issue.
Thank you once again for all your cooperation thus far.
-
-
-
-
Hello @Justin Harrison, We placed multiple orders for different products using different payment methods on your staging site, but we did not encounter any stock reduction issues.
Could you please let us know if this issue is occurring with a specific vendor or product on your end? This information will help us assist you more effectively.
-
Hi @Sangita, if you login and look at Order #350849, you’ll see the issue pop up. I just tested with the same product as one of your test orders and was able to recreate the issue.
-
-
Hello Justin,
We have rechecked the issue on your site by placing multiple orders to monitor stock reduction. While the issue does occur occasionally, most of the time there are no problems with stock reductions. To ensure this isn’t related to our plugin, we tested it on our own site by placing multiple orders, and we did not encounter any stock reduction issues.
Without being able to consistently recreate the issue or identify its root cause, it is challenging for our development team to debug further on your end.
It seems the issue on your site might be due to database corruption. We recommend creating a clone of the staging site and then reset database of that clone site and then checking whether the stock reduction issue persists.
We look forward to hearing back from you with any updates.
-
Hi @Sangita, I am in the process of setting up a fresh install with nothing installed but WooCommerce, MultivendorX, and MultivendorX Pro but the configuration of WooCommerce and MVX copied over to test and see if the issue occurs there. It seems unlikely to me that it could be database corruption since we don’t get this weird stock reduction behavior on other payment methods which uses all of the same tables, only this one method, but this will easily be proven or disproven with a new, fresh install.
-
@Justin Harrison It would be very helpful if you could implement the same flow on a new test site and identify the root cause of the issue. Once we have this information, our team will be better equipped to provide you with a solution.
We look forward to hearing from you soon with any updates you may discover. -
-
-
-
-
@Justin Harrison, We have once again attempted to place orders on your site to investigate the stock reduction issue further. However, this time, no such issue occurred with any of the products. If the problem were related to our plugin, it would consistently trigger under the same conditions, but that’s not the case here.
It appears that the issue may be linked to your server’s response. To investigate further, we recommend switching your site to a different server temporarily and then placing multiple test orders to see if the stock reduction issue persists.
Let us know how it goes.
-
I’ll be honest that this request seemed non-sensical and trying to blame anything else but your plugin since our test sites on the primary server don’t have any problems if it’s in Stripe Express Destination mode, only Separate Charges and Transfers, and we’re running Separate Charges and Transfers on an older MVX plugin version on the live site on the same server without any problems.
Nonetheless, I complied with your request and migrated the freshbox site over to separate server that we use for other client sites. It is configured very differently, runs on a different OS, and even runs on Litespeed instead of Apache. After running several tests, the issue did not popup at first, but then… it happened again. Orders #136 and #140 show you the issue has been replicated on the new server. I did nothing special while placing my test orders other than I was logged out while placing orders. So that should rule out this idea that it’s a particular server’s response creating the issue.
Your login for the site on the new server is the same, but if you need FTP access again, you will need to request it as it has changed for the new server. Please look into this again. If we need to schedule a meeting with your developers to discuss the issue, we are happy to do that or whatever is needed to get this working, but this troubleshooting has been going back 2 months since you released a fix that worked for Destination charges, but did not fix Separate Charges and Transfers.
Attachments:
-
Hello Justin, Kindly add the below code in the functions.php file of your current active theme and then place multiple test orders to check whether the stock reduction issue still occurs –
add_action('woocommerce_reduce_order_stock', 'skip_stock_reduction', 10, 1);
function skip_stock_reduction($order) {
if ($order->get_parent_id() != 0) {
return;
}
}
Also please do keep us posted about your findings. -
@Sangita That did not work. That action hook is not called in the WooCommerce function until after stock is already reduced, so it wouldn’t make sense that it would work. I did take that concept and tried something similar in an action hook and filter hook that fire earlier in the code, but it only created a situation where it stopped reducing stock altogether or didn’t fix the problem.
Also, just to let you know, even though I have selected “Notify me of follow-up replies via email”, I am no longer receiving notification emails from the website.
-
Hi Justin, Thanks for the update and sorry to hear that the solution is not working for you.
Now as mentioned earlier, the issue you’re experiencing is inconsistent; it occurs with some orders but not others with the same payment configuration. This variability makes it challenging for us to pinpoint the exact scenario causing the problem.
It would be very helpful if you could identify the specific conditions under which the stock reduction issue happens. With this information, our team will be able to investigate the scenario more thoroughly and implement a targeted fix.
Thank you!
-
Hi Sangita, I understand the variability makes it challenging. That’s why we need the help of the plugin developer to solve the problem that exists in the plugin. We have created the specific conditions in which this issue occurs, but it still doesn’t occur on every order. We have ruled out the server being the problem, the database being a problem, any other plugin being a problem, any other Stripe configuration being a problem. We know the problem happens intermittently when WordPress, WooCommerce, MultivendorX with the updated Stripe code, and MultivendorX Pro are active and the payment settings are configured for Stripe Connect Express Separate Charges and Transfers. That is a pretty specific condition in which this occurs and the fact that you’ve placed MANY MANY orders and can’t figure out how to identify a more specific condition and you’re the experts of your own plugin, I don’t know how you can expect us to basically troubleshoot this problem for you. We’ve identified the intermittent problem and you’ve acknowledged and replicated the problem, but at this point, I do feel like you’re basically asking us to troubleshoot the issue for you and once we diagnose the issue and identify it, you can fix it but you are unwilling to diagnose or attempt to identify it any further even though you acknowledge there is a problem. We don’t really have a choice to stay on the older version of MultivendorX forever, so we have no choice but basically to fix this for ourselves. Unfortunately it’s hard to have a positive view of this plugin if we’re left to support it ourselves.
-
Hello Justin, We completely understand your frustration with this issue and sincerely appreciate your patience. In the past, we were able to resolve your reported issues by recreating them under controlled conditions. Unfortunately, this time we have not been able to reproduce the problem with the setup you’ve described, either on our end or yours. Today, we placed several orders (188, 192, 196, 200, 204) to try and identify the issue, but none showed the stock reduction problem. To assist you effectively, we need a specific scenario where the stock reduction issue occurs. Currently, we are unable to recreate the issue.
To help resolve this, we have implemented custom code on your end to prevent stock reduction for suborders. Could you please verify if the issue persists with this adjustment? If the problem continues, we kindly request that you deactivate the MultiVendorX Pro plugin on your end and place additional orders to determine if you can recreate the issue. Additionally, we kindly ask for your assistance in documenting the issue:Please record a video of your entire testing procedure.If you successfully reproduce the issue, capture it in the recording.Share this video with us as soon as possible.This visual documentation will greatly help our team: Observe the exact steps leading to the problem
, identify any unique conditions triggering the issue and develop a more targeted solution.Thank you for your cooperation and understanding. We look forward to hearing back from you about your findings.
-
@Sangita Your sample size when testing is not sufficient. Because of the nature of the issue being random and intermittent, 4 or 5 orders may not recreate the problem. You said the same thing on August 19 but then when I showed you it was still happening, you went back and placed test orders on August 21 and you got the error 2 times out of 4 orders. You cannot simply place 5 orders and say, “oh, well the problem is gone. It must be on your end because it works for us.” Today, I placed 13 test orders and the stock reduction issue only happened on 2 or 3 of them.
The custom code in the functions.php was the code you already gave me to try and it didn’t work. I already relayed that days ago. Maybe there was some other code that was added, but trying the same code certainly did not work.
Here is a Loom showing my shopping and checkout process and the error occurring – https://www.loom.com/share/a4871718733b4a5fb81c16e00f8f2a5f?sid=a45b3265-00b4-4b75-85a7-6bcfa8e6a3ec. I’ve recreated those exact orders and it hasn’t done it again, so I have no idea what unique condition is triggering the issue. On August 21, you placed 4 orders and 2 of the created the issue. Did you identify any unique conditions that triggered 2 of the 4 orders on that day?
-
Justin, we genuinely understand your frustration. We have made several attempts to replicate the stock reduction issue on your end by placing multiple orders. Out of many attempts, we only encountered the problem once, even though we used the same configuration each time. This makes it incredibly challenging for us to identify a consistent trigger for the issue.
Given this, we can confidently say that the issue is not due to a bug in our code. If it were, there would be a specific and consistent scenario that would cause the problem, and we would likely have heard from other users experiencing the same. However, none of our other users have reported this issue.
We have also researched potential solutions and found that other WooCommerce users have encountered similar issues. Even after sharing these concerns with the WooCommerce team, they were unable to pinpoint a cause or solution. You can read more about similar cases here:https://wordpress.org/support/topic/stock-reduced-2x/ and https://wordpress.org/support/topic/duplicate-order-stock-deduction/
We remain hopeful that WooCommerce will find a solution, and when they do, the issue on your site should be resolved as well. -
-
- The topic ‘Stripe Marketplace – Multiple Status Updates and Multiple Stock Reductions’ is closed to new replies.
