Multiple payment intents on renewal even after payment succeeded

  • Resolved dmcat

    (@dmcat)


    3 months, 4 weeks ago

    Hi there!

    We’re having some trouble with several payments where it appears the Stripe Standard for WooCommerce payments took subscription renewals and while in status “on hold” it kept creating payment intents over and over again for multiple days even after payment was received during the first intent. In Stripe I can see each person was charged a few times each day up until now (as I manually changed the status to complete). This means we’ll have to refund a lot of charges and lose out on a lot of processing fees. This issue only seemed to start in the last few days as we haven’t had an issue like this previously.

    The commonality between all of these is:

    1. They all paid with card via Stripe
    2. They were all paying their 3rd payment in a subscription
    3. They were all renewing around July 25-28

    We are using:

    • WordPress 6.6.1 (just auto-updated several days ago)
    • Woocommerce 9.1.2
    • Yith to manage subscriptions (but processed via Woocommerce for payment)

    Here’s a snip of just one day of order notes of it happening: https://snipboard.io/KGk1OE.jpg

    Grateful for any thoughts or support on this one!

Viewing 15 replies - 1 through 15 (of 16 total)
  • Thread Starter dmcat

    (@dmcat)

    Just following up with a few more details after a bit of research.

    We’re also using Woocommerce Stripe gateway 8.5.2 (which I see was just updated July 22 – right before this issue occurred). Looking at the change log (details below) I’m curious if something between the “automatic” capture method and Stripe webhooks may not be firing correctly for Woo to update the order status to complete and not re-collect the same payment – though I’m just making a guess here…

    According to the change log these items had been updated:

    • Fix – Fixed errors when using Link to purchase subscription products that could lead to duplicate payment attempts.
    • Fix – Prevent failures creating SetupIntents when using a non-saved payment method on the Legacy checkout experience.
    • Fix – Ensure immediate balance transaction assignment for subscription renewals by specifying capture_method => automatic in Stripe payment intents.
    Plugin Support Shameem R. a11n

    (@shameemreza)

    Hi @dmcat

    Thanks for your detailed explanation of the issue you’re experiencing.

    Based on the commonalities you’ve noted and the recent updates to your WordPress, WooCommerce, and WooCommerce Stripe Gateway, it’s possible that there might be a conflict or a glitch.

    The updates you mentioned in the change log, particularly regarding the automatic capture method and Stripe webhooks, could be related to the issue. However, it’s hard to determine without further investigation.

    As a first step, I recommend updating your WooCommerce Stripe Gateway to the latest version, if you haven’t already done so. This can often resolve any issues identified and fixed in later versions.

    If the issue persists, we may need to investigate further. To do so, please can you share a copy of the following:

    • System Status Report: Navigate to WooCommerce → Status. Select Get System Report and then Download for Support.
    • Fatal Error log: Share a copy of any fatal error log found under WooCommerce → Status → Logs. (Make sure you’ve enabled debug mode in the Stripe setting)
    • A screenshot of your order page.

    You could copy and paste your reply or share it via Mozilla Community Pastebin and share the link here. Feel free to redact all the private information before sending it over.

    Thank you for your patience and understanding.

    Thread Starter dmcat

    (@dmcat)

    Hi @shameemreza ,

    Thanks so much for your time and support on this, greatly appreciated! After a little more digging, it turns out there were 53 charges across 5 different users within 4 days, and the client had to go through and refund thousands back to their customers. Thankfully these individuals have been very gracious in the process, but it’s been a pretty serious matter for the client.

    Just a side note – this is a site I’ve taken on maintenance of, and the previous developer has locked a number of things down to prevent accidents – so unfortunately my access to some areas (eg. admin plugin page) is limited at this time. However I have been able to go through and get the reports etc. you mentioned, and can confirm the WooCommerce Stripe Gateway is on the latest version.

    System report: https://paste.mozilla.org/Lw9FVggR

    The last fatal error was on the 17th (well before all of this) and doesn’t seem to be stripe related: https://paste.mozilla.org/u3n4xeFU

    Here’s a small redacted snippet of the Stripe log for one day – in it you’ll find the “automatic” charge for the same subscription twice for one user in a single day: https://paste.mozilla.org/D8x6An57

    An order notes: https://snipboard.io/cr1T6I.jpg

    Order page snippet – in each case there is only one order created, but multiple payment intents/charges in each (as seen in the order notes and Stripe log above): https://snipboard.io/1qClYb.jpg

    Plugin Support Shameem R. a11n

    (@shameemreza)

    Hi @dmcat

    Thanks for sharing detailed additional information.

    I understand the gravity of the situation, and I’m sorry for the inconvenience this has caused you. I can see how this could be a serious issue for your client, and I appreciate your patience and understanding in this matter.

    To ensure we are on the same page, is this issue still occurring? Also, are you using the new checkout experience or legacy?

    Please note that our dev team is already aware of a similar report here:

    And a fix already proposed and waiting for review here:

    In the meantime, I would recommend enabling the legacy checkout experience.

    I wish I could help more, but hopefully, this provides some clarity. Please let us know if you have any other questions!

    We have the same problem, several charges for the same order to the same customer in few hours because stripe plugin continuously generates payment intents. We have always been running the legacy checkout experience. The gravity is highest, customers are canceling orders and subscriptions, a huge business damage.

    Hey, @sannadigital!

    Per WordPress forum guidelines, would you mind opening up a new thread for this so that we can keep things organized and offer more personalized support for you? We’ll be happy to help you out with this over there!

    Have a wonderful day!

    Thread Starter dmcat

    (@dmcat)

    Hi @shameemreza Thanks for the info and links to review previous support requests and fixes in the works! I appreciate your efforts here.

    I’m not sure just yet if it’s still occurring as we haven’t had any further orders since, but happy to keep you in the loop, though I noticed it doesn’t seem to be effecting one time purchases as they are flowing correctly through the process, it just seemed to be these subscription items so far, after the recent update. To note: we are using the legacy version – we had different errors previously and tried to resolve by moving to the new checkout, but things got worse (this was a little over a month ago), so we reverted back to legacy and that’s been fine till now.

    Just curious as I noticed all those links are dating back to 2022. Is there any likelihood they aren’t related since this particular error only just occurred for us in the last week (after the update) and the client has been running things as is for years with almost no errors till now? And what is the likelihood the fixes for the linked items will happen soon since we’re well into 2024 now?

    Hey, @dmcat!

    Just curious as I noticed all those links are dating back to 2022. Is there any likelihood they aren’t related since this particular error only just occurred for us in the last week (after the update) and the client has been running things as is for years with almost no errors till now? And what is the likelihood the fixes for the linked items will happen soon since we’re well into 2024 now?

    The issue was first reported in 2022, but we did start getting more reports on it recently, so it is probably related.

    While the original reports are a bit old, this pull request is from 2 weeks ago and has activity as soon as a few hours ago, so as you can see, our team is actively working on it and we hope to have a fix for it as soon as possible??

    Please let us know if there’s anything else we can do to help or if you have any questions.

    Have a wonderful day!

    Plugin Author jamesgallan

    (@jamesgallan)

    Hi @dmcat,

    I wanted to suggest another potential area for investigation. You mentioned that your client is using the YITH Subscriptions plugin.

    For context, subscription renewal payments are initiated by the Subscriptions plugin, with the Stripe plugin handling the payment collection. If multiple renewal payments are occurring, it might indicate that the Subscriptions extension is triggering the gateway multiple times.

    You also mentioned that these payments were occurring up to 3 days after the initial payment succeeded, and even in cases where the subscription is on hold. These are strong indicators that the subscription plugin might be engaging the payment method outside of the expected schedule.

    Since YITH Subscriptions isn’t one of our extensions, I’m not familiar with how their plugin interacts with the Stripe extension. However, it might be worth investigating whether these duplicate charges occurred due to YITH Subscriptions running a renewal process out of schedule.

    Thread Starter dmcat

    (@dmcat)

    @carolm29 Thanks so much for that update and pointing out that pull request, I appreciate the support and that your team are actively working on this.

    @jamesgallan Thanks also for the info and suggestion! Yith is mainly used for the subscription creation. Though, looking at the logs, It appears to run a chron job several times a day to review subscriptions and see if renewals are needed. If they’ve failed or haven’t been paid it will request a payment intent be sent again (supposed to be a max of 4 tries). As you mentioned, it’s not collecting the payment, rather sends the data to WooCommerce Stripe plugin to collect the payment until the payment has been completed.

    What I noticed with subscriptions before this error, and with non-subscription orders, a payment intent is sent, Stripe processes this and then a charge id is sent back and added to the order to confirm completion, so no further intents are sent and the payment status is updated with the charge id. In the case of these subscriptions the payment intent went out, and from the Woocommerce Stripe plugin logs a charge id came back from Stripe but it wasn’t added to the order to confirm payment was complete so Yith would request the gateway send a new payment intent.

    Thread Starter dmcat

    (@dmcat)

    Hi there just following up with updates to keep you in the loop as things emerge.

    We’ve had a few more of the same errors with the subscriptions. It turns out each payment intent is sent correctly, and charged in Stripe – we can see successful payments there. Once, that happens the Charge ID comes back (which I can see in the WooCommerce Stripe Gateway logs), however the ID is empty in the order notes (see here: https://snipboard.io/jrgGMY.jpg).

    From my investigation I noticed that with previous subscriptions (and non-subscription payments) the Charge ID would be added to the order and end the cycle of requesting payment. In these new instances since there is no charge ID associated to the order the renewal payment request gets stuck on a loop to keep requesting.

    Plugin Support Shameem R. a11n

    (@shameemreza)

    Hi @dmcat

    Based on your shared details, the issue seems to lie in the interaction between the YITH Subscriptions plugin and the WooCommerce Stripe Payment Gateway plugin. As you mentioned, the Charge ID from Stripe isn’t being properly added to the order, which means YITH is continuously requesting new payment intents, resulting in multiple charges.

    While we’re actively working on resolving similar issues as per the GitHub links shared previously, it’s also crucial to investigate this specific interaction between the plugins.

    I would also recommend reaching out to the YITH support team, as they might have more insights into this particular issue. In the meantime, we’ll continue investigating this on our end and keep you updated on any progress.

    Thank you for your patience and understanding, and please feel free to reach out if you have any other questions or concerns.

    Plugin Author jamesgallan

    (@jamesgallan)

    Once, that happens the Charge ID comes back (which I can see in the WooCommerce Stripe Gateway logs), however the ID is empty in the order notes (see here:?https://snipboard.io/jrgGMY.jpg).

    @dmcat sorry for the delay and thanks for the additional details.

    I can see in your screenshot that the charge ID logged in the order notes is empty. There’s a few places in the code where we record the charge ID in that format. All of them fetch the charge ID from the Stripe charge response or Webhook notification. You mentioned that you can see the charge ID in the Stripe logs. Given that, I’m not sure where the charge ID is going missing between it being logged in the Stripe logs but is empty in the order note.

    Do you have any php error logs like Attempt to read property "id" on ... or similar?

    Another thing I noticed looking at your order note screenshot is that the charge is being logged 4 hours after the intent was created. ie the payment intent was created at 04:02 but the charge entry occurred at 08:05. Is that similar with all these cases? Card payments are typically processed immediately so that stuck out.

    Given the time gap, I suspect these empty order note charge entries are occurring via a webhook notification. Can you confirm that?

    Plugin Support Shameem R. a11n

    (@shameemreza)

    Hi @dmcat

    I’m marking this topic as “resolved” due to recent inactivity. If more assistance is needed, feel free to post back here or open a new topic.

    Thanks!

    Thread Starter dmcat

    (@dmcat)

    Hi @jamesgallan Thanks for the ideas and support on this!

    There actually are a number of id errors as you noted! Here’s a link to the pastebin of it: https://paste.mozilla.org/JQuLOUWU

    I believe the 4 hour delay is based on the cron job times that Yith runs to check/initiate payments if any are needed, but I do believe you’re right about the webhook, I had a look in the webhook handler file in the plugin, and made a small edit to test. I also noticed Yith did extend some of the webhook handler functions for subscriptions to gather the data it needs to process, so am testing a small edit of code there to. Happy to share results when I get them.

Viewing 15 replies - 1 through 15 (of 16 total)
  • You must be logged in to reply to this topic.