Forum Replies Created
-
Posts
-
@MaxenceTP Here is a screenshot of the email from Stripe to document that it is possible.
Attachments:
@MaxenceTP Yes, it is possible to have them disable hCaptcha. I was told by Stripe support 3 separate times that it was not possible and was not able to make any progress until my ticket was escalated so you must request that your ticket be escalated. It took 6 days for me. I kept referencing their own documentation on this page where it specifically says “To opt out of use of hCAPTCHA integration, reach out to Stripe Support.”: https://docs.stripe.com/disputes/prevention/advanced-fraud-detection
Good luck! Stripe did not make it easy! Their support response times were beyond terrible.
Regarding your previous questions, I will let MultivendorX answer that for you.
@MaxenceTP If you want your checkout to start working again, I would suggest you ask them to disable it temporarily. In their own documentation, it says you can ask them to disable it. The problem lies with a change in their implementation of hcpatcha. If you don’t know what it is, here’s what Stripe says “hCaptcha is a type of CAPTCHA that helps stop fraud and provides additional signals to Stripe while being low friction for legitimate customers. To opt out of use of hCAPTCHA integration, reach out to Stripe Support.”
MultivendorX never responded to the additional information I provided about what Stripe told me – Your integration created a Source and Token at the exact same time, which was incompatible with the hCaptcha implementation. Stripe also seemed to indicate that they are working on fixing this on their end too.
Lastly, (sorry to blow up everybody following this ticket) it sounds like Stripe is also working on a fix for this so hopefully between their efforts and MultivendorX’s efforts, this will be solved in one way or another soon. I do believe this shows and proves that there was a change on Stripe’s end that everyone was unaware of and there is no documentation/announcement regarding this change. This is not MultivendorX’s fault and other multivendor plugins are having these issues as well.
Correction…. they emailed back after I asked for clarification on when hcaptcha was disabled and it looks like my code change based on Dokan’s fix precisely corresponded with when they disabled hcaptcha (within an hour when no checkouts were attempted), so they disabled it yesterday and just let me know about it a little bit ago. So it looks like it was a very coincidental case of me making the code change on the website and them disabling hcaptcha on our account.
I can only suggest for all other MultivendorX clients to contact Stripe and ask them to disable hCaptcha on their account. Please keep in mind that all tier 1 support reps told us it could not be done despite the fact that it says you can contact your customer support rep to have it disabled. I would just hammer them as much as possible to get it disabled and use my case as proof that it can be.
@Sangita @Moumita I finally received a response from Stripe’s technical team 5 days after requesting that the ticket be escalated. Here is what they said:
“We’ve identified the underlying issue and have temporarily disabled hCaptcha for your account. Your integration should be working now.
Your integration created a Source and Token at the exact same time, which was incompatible with the hCaptcha implementation. We will work around this!”
They did not disable hCaptcha in our account until a few hours ago and our integration began working last night after making the code change in the plugin, but maybe this information can help lead you to solving these issues for all MultivendorX users.
@MaxenceTP Yes. As I mentioned in my original post, I only expected this fix to work for Stripe Connect Express.
We have changed nothing other than that one line of code (copying the change from Dokan), so I’m surprised it’s not working for anyone else since Dokan found that the change worked for them as well. Orders are still flowing in this morning. We are on the latest versions of MultivendorX and MultivendorX Pro. We are on WooCommerce 8.5.2. We are located in the USA, so I’m not sure if there are any differences there in regards to this issue with Stripe.
Here is a screenshot of our MVX Stripe configuration.
Attachments:
I’m sorry this fix didn’t work for you @Crisim. This is the change implemented in Dokan Pro as their fix and this is the change we implemented as our fix.
I, like MultivendorX, spent many hours troubleshooting and trying to communicate with Stripe to resolve this issue. Ultimately, we had to spend $249 on Dokan Pro to investigate the issue, track down their code changes, and do our own testing to confirm the solution. I believe there should be some type of finder’s fee for this considering our own investment in finding a fix. I did not ask for any monetary compensation from MultivendorX, but I did request that they push our feature requests to the top of the list and make it a priority as a reward for helping out and ultimately saving them and you time, money, and hassle – primarily we are requesting refunds from the dashboard or Affirm or Afterpay options at checkout be prioritized as new features.
While this fix has not been tested with any other sites or scenarios beyond our own, I believe it to be a fix for anyone using Stripe Connect Express. The fix is adding one line to /mvx-pro/modules/stripe-marketplace/includes/WebhookHandler.php. The issue I believe is an undocumented change to Stripe’s API where the Webhook Endpoints parameter ‘connect’ no longer defaults to ‘false’. It defaults to ‘true’ which is causing all the issues including hcaptcha showing up in the API requests. After adding the following line of code and explicitly setting the ‘connect’ parameter to ‘false’, all our problems were solved, things went back to exactly as before, and the weird hcaptcha API response data disappeared:
Add to line 55 of /mvx-pro/modules/stripe-marketplace/includes/WebhookHandler.php:
‘connect’ => false,I have also included a screenshot for clarity. I hope this helps everyone in this thread that also suffered the same issues as we did.
Attachments:
I have found a fix based on Dokan’s fix. It’s simple and an undocumented change to Stripe’s API. MultivendorX, please contact me privately if you are interested in the fix. We are accepting checkouts again! Yay!
I also appreciate that this is a difficult situation for all, but better communication on the process, issue, and timeline would certainly not require anything that a small team can’t handle. Right now, there’s been very little information about the details of the problem, what is being done, and when it might be completed. Improving communication would go a long way with satisfying MultivendorX customers (us) that are waiting on this fix.
Sangita, I hate to keep asking, but we’re still unable to accept orders until this gets fixed. I realize that your team is working on it, but can you give me any kind of of timeline of when that will be? We’ve been down for 5 days now. Any additional information apart from the boilerplate response of “we’re working on it” would be helpful. Dokan published their fix over 36 hours ago so I was hoping this would be resolved soon since they were able to roll out a fix quickly, but I really have no idea based on the responses given in this thread. Thanks.
Sangita, just checking on this again to see if there is any update on a timeline for the fix? We’re unable to accept orders until this fix is available. Thank you.
Thank you Sangita! I saw Dokan rolled out their fix a few hours ago. Do you have a timeline on when this fix will be available? Within the next 24 hours?
As a note, we contacted Stripe 5 times about this asking them to escalate the issue to get more information. They escalated the ticket, but we still have not heard back from their escalation team. If they ever contact me, is there anything I need to ask them?
