Stripe causing double payments

@coreyalderin - I have not tested the 200422a-stripe-utilities.inc.zip update but @clavaque knows what he is doing so I would trust it. My previous comment is that this patch will reduce some of the occurrences but not all the occurrences and the transactions it fixes is actually as a side-effect. It’s like putting a band-aid on a wound that keeps bleeding. It helps but does not fix the problem.

@madeglobal - Yup…I’m just a user like you and the others :slight_smile:

@Cralamarre - I share your sentiment…which is why I am active on the forum helping and fixing where I can. I have clients that are using this plugin and I have to see it gets fixed or I have to fix it myself. I just don’t have the bandwidth to fix this myself at the moment. The code is actually quite oblique so reverse-engineering it, reproducing the errors, provably fixing the errors and not creating side-effect errors is actually a significant time investment.

I got a response to a private message to @clavaque today. He indicated he has been going through a tough time over the past few months but that things are starting to go back to normal. I would expect you will start to progressively see more of him in the forum but maybe not for another couple of weeks. I don’t know more than that.

I’ve been testing the 200422a-stripe-utilities.inc.zip update. It’s definitely better than before. We are seeing about 1/4 the number of duplicate charges compared to before, but it still happens and is a serious issue.

Good to know. As I said previously:

The fix Cristian provided in the zipfile above adds support for failed message retry protection which alleviates our problem as a benign side-effect but only if the final successful payment occurs within 24 hours of the failed payments. If the failed payment subsequently succeeds more than 48 hours later then the aggregated payment bug will still occur.

Sorry for the hiatus. Had some things happen that kept me away, but I’m back. Don’t worry, s2Member is alive.

Regarding this issue. There are a few of you here with a similar issue, but they’re not all the same. I see two separate things:

  • An issue with subscriptions that have a paid trial term. If your logs mention “invoice”, this is most likely the case. Only paid trials use invoices as a way to get a payment for the trial term, because Stripe’s subscriptions normally only have free trials. The fix I posted last time addresses this, and I believe it solves it, from what I could see in my tests. This fix doesn’t have a problem if the person tries it again later, even if it’s a day or more. I will include this fix in the coming release. Stripe causing double payments

  • An issue that has been very elusive so far. I still haven’t been able to reproduce it, no matter how many things I tried. Only recently, after all these months, I had a duplicate payment from a customer happen to me for the first time, so I had some logs to go over. I couldn’t find any errors in them. The logs lead me to suspect that something is causing the payment submission to be duplicated, although the form’s javascript normally prevents it. It’s either some browser setup that keeps this safety measure from working, or there’s a miscommunication between the site and Stripe, which causes a connection retry when the previous one didn’t fail, ending as separate transactions.

This strange behavior doesn’t seem to be a bug in s2Member, as in my research of this problem I’ve seen others developers with different integrations, asking Stripe support about random/rare duplicate charges. It’s a network thing that any connection with Stripe could have. Stripe has implemented a way to help prevent duplicates from these, so following the advice of Stripe developers to those reports, I’m working on some changes to s2Member that could be just what’s needed here.

:slight_smile:

2 Likes

Welcome back Cristian! Please don’t forget about us PayPal users who also experience random double payments.

Thanks, Stephen! :slight_smile:

PayPal duplicate payments? Did you start an issue for it? I don’t want to mix it in this thread. If you didn’t start one already, please do and add all the details you can: how to reproduce it, log entries, etc. Thanks!

So happy to see you back!

In my situation, the first month has to be more expensive than subsequent months because of business requirements. The only way I could figure out how to do this on s2member was by setting a trial price (ta) which is higher than the recurring price (rp)

Is there a way for me to do this on s2member without using trial price (ta)? If I can do that, then it should avoid this issue completely.

1 Like

Very happy to see you guys too! :smiley:

No, you need the paid trial, because the recurring amount can’t be changed. The fix I posted above should take care of the issue, because it removes the invoices from failed subscriptions, so they don’t accumulate with following attempts. Stripe causing double payments

Did you try that fix already? Can you reproduce the problem when you use that fix? If so, please give me more details from your test, so I can take a closer look. I wasn’t able to reproduce the problem after applying that fix, so I will need all the details you can provide if it persists for you. You can send me a private message with the logs and other info if you prefer.

I look forward to your update. :slight_smile:

Great, glad to hear that s@Member is moving forward. Thanks Cristian

1 Like

Thank you for following up. I am still having issues even with the fix. It’s about 1/4 as likely but still happens. I will message you directly.

1 Like

Do we have any more updates on this please? It has been going on for a while now, I’m hoping we’re closer to an official fix being released?

Hi guys.

Thanks for your patience.

I’m preparing a new release to be made soon, which will include the additional improvements to avoid possible double charges. In the meantime, I leave you the file in case you want to help me try it some more before the release.

I have tested what I could on my side, but since this behavior is pretty random, and you’re the ones that have had it, I hope you can try it and see if the normal transactions work for you.

In the future, after some time has passed where you’d have probably gotten one of those extra charges show up, please let me know how things are looking. And of course, if you still have the problem, let me know the details to dig deeper into it.

It’s not a full release of s2Member Pro, it’s just the relevant file for s2Member Pro v200301. It goes here: s2member-pro/src/includes/classes/gateways/stripe/stripe-utilities.inc.php 200824a-stripe-utilities.inc.zip (11.6 KB)

:slight_smile:

Thanks for they update. I will have a look later this week and try to implement the changes to monitor improvement :slightly_smiling_face:

1 Like

I have been testing this but today I have found something interesting out. I was doing some mods to my site and wanted to test that my stripe forms were working. I put some made up card details in which obviously came back with the error for wrong card number. The interesting thing was that it still charged me for the card that stripe had on file! This is seriously bad and needs sorting too.

I tried out the code, but it broke non-subscription (buy now) purchases via stripe for me. When people tried BN purchases, they got “Stripe API error; please try again.”

It looks like our install of s2member is using Stripe API version 2019-10-08. Is that correct?

Thanks for the report, Alan. I will look closer into that.

Yes, that’s the API version in use.

This is the actual error message that comes from the Stripe API:

“Keys for idempotent requests can only be used with the same parameters they were first used with. Try using a key other than ‘XXXXXXXXXXXXX[redacted]’ if you meant to execute a different request.”

I’ll send you the full var_dump of the Stripe Exception object via pm

1 Like

I think I figured it out! The problem is in
stripe-utilities.inc.php on line 1248:

‘idempotency_key’ => md5(serialize($charge))
should be
‘idempotency_key’ => md5(serialize( $intent ))

$charge is never set. So the md5 of $charge is always the same. The first payment for an account can go through because it’s the first time that key is used. But each subsequent one would fail.

That’s why Stripe is complaining the idempotency key is repeated. That explains why on my side, I could get it to work once on each of my accounts, but not on any subsequent times.

I replaced it with $intent because that is the variable that is initialized a little earlier on in the file. I’m going to use this fixed version on my side for now. Please let me know if this looks right to you and if it will be integrated into the next version.

Thanks!

1 Like