Stripe causing double payments

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

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. :expressionless:

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? :slight_smile:

Yes, it will be in the next version.

Great, thanks!

1 Like

We are getting less duplicate payments but they still spring up. For instance we just got this 9x (!!!) payment. Thankfully their bank refused the charge, but the customer was justifiably very upset.

The customer originally tried to purchase on September 20th using two different cards, call them A and B. All attempts failed. They tried again on October 12th using card B. A payment attempt was made against card A for 9x the amount.

Since it seems like the true cause is hard to find, can you add a sanity check on invoices so that there is never more than two items or more than 1 item not labeled “Trial period…”?

If I am correct, s2member never has more than two items on an invoice, and the only time there are two items are when one of them is labeled “Trial period…”

1 Like

Hi Alan.

9x! I edited this reply several times as I kept trying things lol… After much testing I think I found a way to reproduce this behavior… I’m looking at possible solutions now.

Thank you so much for your valuable feedback! I will post an update as soon as possible.

:slight_smile:

Thank you Christian! Did any of the possible solutions work out?

1 Like

Hi Christian, did any of the solutions you looked at fix the issue?

Hi!

Yes, I had tried several things, and finally arrived at one that isn’t too complex as some I attempted, but has worked fine in my tests.

I just published a Release Candidate, if you guys would like to try it. https://s2member.com/s2member-v201209-rc-release-candidate/

I would really appreciate your feedback! :slight_smile:

1 Like