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
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.
Welcome back Cristian! Please don’t forget about us PayPal users who also experience random double payments.
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 (
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.
Very happy to see you guys too!
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.
Great, glad to hear that s@Member is moving forward. Thanks Cristian
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.
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?
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)
Thanks for they update. I will have a look later this week and try to implement the changes to monitor improvement
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
I think I figured it out! The problem is in
stripe-utilities.inc.php on line 1248:
‘idempotency_key’ => md5(serialize($charge))
‘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.
Well done spotting that, Alan! Thanks for the additional info with the error you were seeing, and with your finding in the code.
Right, it should have been $intent. I don’t know why it said $charge… That would affect buy-now payments
I used $charge before but later changed it to $intent. I must have hit undo before saving, or I just zipped a previous version of the file.
Thank you very much for catching it. In my development site I had the right one, so I couldn’t spot it. I should have gone back to double-check the one in the zip. I guess no one else tried it with buy-nows, just subscriptions, that’s why only you saw it.
Okay. After changing it to $intent, how has it been working for you?
Yes, it will be in the next version.