Duplicate orders ~ 10% of the time.

Hi there!

You mentioned that you are using the Stripe API, are you doing anything outside of just the regular application of the plugin?

The orders that are failing, are they being entered by the customer during the regular checkout process?

Often duplicate orders are due to customer clicking the button twice on a slow site.

Hi @melindahelt. Let me give you some more info on this issue:

When I say I’m using the API Version:2019-05-16, I mean that’s what I have it set to in the Stripe website dashboard. I’m not doing anything bespoke at all, just relying on the Stripe Woocommerce plugin to do all the talking.

These are standard customer orders.

Regarding the suggestion about the customer clicking twice on a slow site: The site itself doesn’t seem to be slow, even during busy times, (I’ve run ‘top’ and monitored CPU, RAM & MySQL usage over time). Furthermore, as soon as a customer clicks ‘place order’, the standard WooCommerce behavior is to add a class of ‘processing’ to the form and also disable the place order button. Also, we also use Paypal as a payment method and never see any duplicates with that. ( I do appreciate that Paypal works differently, however. )

The key point here (I think) is: Whenever we get a duplicate order, it always coincides with the webhook in the stripe dashboard failing.

For example, the first time the order is attempted by the customer, the webhook success call from stripe that is supposed to inform our site of payment, fails, and the customer thinks the order didn’t work, even though the payment was taken.

So then the customer tries again and makes a second payment. This time the webhooks work.

The status code in Stripe is ‘unreachable’ as you can see from the screenshot: https://drive.google.com/file/d/1Dpn-JWdEP9q53rfH2cocVJr0s5U8F0ww/view?usp=sharing

I’ve also asked Stripe about this, but at this point, I’m trying to pinpoint the cause of the webhook endpoint rejecting the webhook call, that’s why I’m posting this ticket.

Many thanks.

• This reply was modified 5 years, 7 months ago by Chris Allen.
• This reply was modified 5 years, 7 months ago by Chris Allen.
• This reply was modified 5 years, 7 months ago by Chris Allen.
• This reply was modified 5 years, 7 months ago by Chris Allen.
• This reply was modified 5 years, 7 months ago by Chris Allen.
• This reply was modified 5 years, 7 months ago by Chris Allen.
• This reply was modified 5 years, 7 months ago by Chris Allen.
• This reply was modified 5 years, 7 months ago by Chris Allen.

Thanks for the update! We’ll need to move this to a ticket for additional support.

Please contact us at WooCommerce.com > My Account > Tickets. You may need to create an account before you can access that page.

Please include a link to this forum thread, so that we can keep track of what’s already been done. (and/or just copy and paste your last note, no need to re-type it!). Make sure to include a copy of your system status report as the ticket form requires.

We will be able to help you further there.

Hi @chrisjallen … I’m seeing the exact same on a client store and concur it appears to be to do with the webhook not being recognised/failing. Another thing that may be related is when initiating a refund via Stripe on the individual order screen, I get the spinner that doesn’t go away, and assume it’s because Woocommerce is not receiving a response back from Stripe as in the Stripe dashboard the refund goes through fine. If I reload the order, Woocommerce then shows the transaction from Stripe however the order status is still shown as “Processing” and not “Refunded” as I’d assume it should be.

Any news on a possible fix? I’ve also made a support request via Woocommerce ??

Cheers
Scott

Hi @sanziam. I have also made a request to Woo & Stripe to try to track this one down. I’m still trying to find a fix but I have a suspicion its due to the webhook timing out, or not being served up in a timely fashion. Steps I’ve taken so far include:

Checking the speed of the site and server. Its a 64GB RAM dual-core dedicated server so its more than adequate, but I did upgrade to MariaDB 10, and increase some settings in my.cf. (This is all cautionary though, this is not the actual answer.)

I am using Cloudflare but for DNS only, so no caching there. However, I was using Autoptimize plugin & Cache enabler, so I’ve disabled that.

Basically, try to trim the site down to bare bones, by disabling any non-essential plugins, especially caching & optimisation plugins.

I’ve not had another occurence YET. I’ll keep you posted.

Thanks @chrisjallen … my server isn’t quite so large but I’m not seeing it struggle in any way and the site itself is small (only couple of dozen products). I agree it seems like a timing issue communicating with Stripe. One thing in common is I’m also running Autoptimize and also WP Super Cache. I’ll strip it back to only essential plugins and turn off the caching etc to see if that helps. Cheers for the update ??

Sanz

Interesting you mention Autoptimize. One of the support guys said he’d reported a CSS loading issue in the admin panel, I personally suspect that was due to autoptimise.

One of the support guys said he’d reported a CSS loading issue in the admin panel, I personally suspect that was due to autoptimise.

ah, but AO doesn’t optimize the admin panel, so no ??

frank (ao dev)

Hi Frank, thanks for the reply. To be honest its such a weird error, I’m clutching at straws a little.

Hi @chrisjallen,

I checked your user in our system but I do not see any tickets submitted recently; just one back in June. Were you able to submit the ticket so we can dig into the issue further?

With the ticket we would be able to see more of your site and possibly log in/have the developers check to see what is going on. I look forward to your submission there!

@sanziam,

I’m seeing the exact same on a client store and concur it appears to be to do with the webhook not being recognised/failing.

If this is happening with the webhook, have you replaced the webhook in Stripe? Try that and see if it stops doing it.

One thing in common is I’m also running Autoptimize and also WP Super Cache. I’ll strip it back to only essential plugins and turn off the caching etc to see if that helps.

Did this work? Let us know, as if it does then you can re-enable and test to see which it is. Perhaps it ends up being something common to the cache plugins; please note that the Checkout, Cart and My Account pages are not supposed to be in the cache plugins, if they are it can cause issues such as this.

We haven’t heard back from you in a while, so I’m going to mark this as resolved – if you have any further questions, you can start a new thread.

Hi I have the same problem (duplicate charges via stripe and this plugin), and Stripe recommended to use their idempocy feature (recognizing idempotent charges – which means, they want the same thing, and then only ever putting one of them in action). Is this something that this plugin can deliver? Now or at any time in the future? If not, are you aware of an alternative plugin that does?
Thanks! Tex