s2Member sending request to Cancel Subscription to Stripe

#1

I don’t know what happens but there’s one specific subscription that was fine (modification from free to paid), then s2Member sent Stripe a cancellation request and cancelled the subscription.

I had to override it by manually creating another subscription on Stripe.

A few hours later, around midnight, s2Member sends ANOTHER cancellation request and attacks my manually created subscription, for no apparent reason. :sob:

I know the user did not cancel because I don’t use cancel links or buttons on my site as it’s much more reliable to have the user email me instead, so I know it’s not caused by the user.

#2

Hi @clavaque! Since now you have full access to my database, I’d like to let you know this problem happened once again today, user subscribed, s2Member cancelled the subscription a minute later.

I do NOT have any cancellation button as I prefer to ask my subscribers to email me directly instead, so I can double check their subscriptions are actually cancelled, therefore preventing unwanted charges, but this problem is the opposite, the user resubscribes/modifies, s2member likely cancels it thinking it’s a double subscription or something like that. :thinking:

I think you have an anti duplicate subscription routine that fails and triggers when it should not. It would be nice to have at least a temporary flag in the settings to disable it, I prefer to cancel duplicity subscriptions manually instead. Would it be possible? Or is it possible to disable that routine with a filter or should I edit the code manually somewhere? I’d rather have the plugin NEVER CANCEL any subscription under any circumstance at payment processor’s level. I prefer to do it always manually. If it happens with PayPal, for example (didn’t see the issue with PayPal) it’s unrecoverable without the user paying again. EOT on wordpress is ok and easy to deal with, of course.

#3

Hi Sim.

That’s not a normal behavior. I don’t know that s2 would do that except for the cancellation button… Maybe also with a non-recurring subscription, or with a set number of installments subscription…

I took a look at s2’s stripe-api log, and see some entries that say “[recurring_times] => -1”…

What user is this? How can I find his entries in the logs?

Could you show me the shortcode he used to subscribe?

I know you said you created a subscription manually on Stripe’s side, but how did you tie it to the user on the site? Maybe there were details from the previous attempt in the db tied to the user (i.e. signup vars).

#4

I tie it to the user by manually filling the cus_ and sub_ codes.

I manage a bunch of things manually because the plugin is broken or isn’t properly designed for customer retention, dunning routines, downgrading when payments fail and reupgrading when they happen later on etc. I would likely have less than half of the subscribers I do if I just let the system do its thing, plus people would be getting free access for far too long. I recover a lot of users sometimes after weeks or even a couple of months trying to collect. Only a few users take action to fix a subscription when a payment doesn’t go through but they surely contact me when it does and they’re not properly reupgraded. :smirk:

Oh, and shouldn’t recurring times be -1 normally, since it’s a recurring subscription towards infinity? I wonder if any other subscription without a set term is different… :thinking:

Sorry for the out of topic paragraph above. Anyways, I can send you a DM with the user name so you can see her.

:slightly_smiling_face:

#5

Happened again.

I have a feeling it’s the anti duplicate subscription. Maybe Stripe sends two requests because the first one isn’t confirmed quickly enough by the server, maybe because it’s busy or something similar. Then it’s possible that s2Member thinks it’s a second subscription for the same product on the same customer and sends the signal to cancel the “previous” one, which is equal the last one that’s just being notified by Stripe a second time.

Makes sense?

How can we disable that feature and let Stripe create as many duplicates as necessary, at least for the time being? Or perhaps it can check both cus and sub codes and not cancel if they match.

This bug is really not nice because I am forced to operate on Stripe, assign credit, resubscribe the user, copy the values manually etc.

If possible to do something easy, of course, maybe even if it’s temporarily just not letting the anti duplicate subscription routine kick in?

#6

Hmm… I’m not sure I’m understand it well yet…

Could you describe it again, maybe as a step by step list of what happens? Maybe with enough details to be able to try reproducing it on my end.

:slight_smile:

1 Like
#7

Hi!

This is what seems to happen:

  1. User Subscribes / Upgrades / Resubscribes / Reupgrades (with or without existing paid subscription) via Stripe using s2Member pro form;

  2. Stripe sends notification to my web server, s2Member receives it, upgrades user as it should etc.

  3. Stripe doesn’t receive a notification back from my site (it only happens sometimes) saying 200 OK or other sort of handshake it should, maybe because the server is busy, maybe because there’s a communication issue.

  4. Stripe, then, sends the same notification (Item 2 above) to the server again, after a minute or a few, maybe once more, maybe a few more times, expecting to receive a handshake / confirmation / 200 OK or whatever is normal back from my Web Server.

  5. s2Member CANCELS the subscription because of s2Member’s own “anti duplicate subscription” functionality as it thinks the user subscribed twice for any error. THIS is the feature that needs to be fixed to perform differently. s2Member also sends a request to Stripe to cancel the user’s subscription.

  6. Final result is you get one single payment and the user is left downgraded and the recurring subscription is cancelled, meaning the system won’t collect automatically as expected, because s2Member sent Stripe a cancellation request, which Stripe fulfilled.

I understand that it’s expected that s2member will cancel an existing subscription when a user starts a new subscription to prevent the user from paying for more than a single subscription, as simultaneous subscriptions aren’t currently supported by s2member for a single user.

That routine that is designed to prevent duplicity should only act when there’s an actual duplicity and it should never cancel the subscription that it’s being notified on. Therefore there should be better testing to prevent a new subscription from ever being cancelled in that situation (if the user will have no subscription).

Also, ideally (maybe in a remote future), s2Member should use the fields that are editable by us like cus and sub fields not that long “string” that stays hidden from view. I frequently re-upgrade users that make late payments by editing both fields manually as s2Member doesn’t have dunning and recovery routines.

Of course, those things can be fixed on a later date but we need to have at least this feature that nukes subscriptions on Stripe deactivated somehow.

It’s ok to downgrade the user on your database only, we’re notified by it and we can re-upgrade the user manually, but recreating the user subscription on Stripe is a massive pain plus we lose 3D Secure status for any future payments related to that subscription.

I don’t use s2Member cancellation routines towards payment processors (I only take email requests for cancellations, I don’t trust cancellation buttons for many reasons). I cancel everything manually upon request or when I find redundancy. Is there an easy way to add a couple of php lines on my generic must use plugin to prevent any cancellation request of any sort to be ever sent from s2Member to payment processors as a temporary workaround until you fix this bug?

Thanks in advance! :slightly_smiling_face:

#8

Hi, i was having a look at your website, https://thesimarchitect.com and I noticed that most of the images don’t load. If I check the code and try to download the image from the direct link, I get an error. Maybe, somehow it’s related.

1 Like
#9

Hi! Really? My site looks normal here :grimacing:

#10

Looks normal to me, too.

1 Like
#11

Thank you, that made it very clear. I’ll look into this.

Also, ideally (maybe in a remote future), s2Member should use the fields that are editable by us like cus and sub fields not that long “string” that stays hidden from view. I frequently re-upgrade users that make late payments by editing both fields manually as s2Member doesn’t have dunning and recovery routines.

You mean the signup vars, right?

Is there an easy way to add a couple of php lines on my generic must use plugin to prevent any cancellation request of any sort to be ever sent from s2Member to payment processors as a temporary workaround until you fix this bug?

I’ll tell you if I see a way.

:slight_smile:

1 Like
#12

Awesome!

Signup vars might be their name, I didn’t want to risk giving you wrong information? That long string that has a bunch of sub elements bundled together instead of proper separate fields that we can edit (and see) using the admin view from the back end. :slightly_smiling_face:

When I edit a PayPal subscriber I just need to add it to the sub and cus fields and the integration sees and interacts with it. Stripe only interacts with the complex one that’s always hidden from us and that shows as a single string with subparts when exported. :crazy_face:

I hope that I can at least neuter this behavior temporarily with a hack or two.

Thanks and welcome back again! :slightly_smiling_face:

1 Like
#13

Just had a similar but different case.

User had a pending invoice.

Instead of paying it, they started a new upgraded subscription via Stripe

s2Member recognized the operation as a modification, upgraded the account.

Right after doing it, s2Member demoted the user and sent an EOT message.

Thankfully the subscription is still active on Stripe and I reupgraded the user manually at Wordpress, as usual.

Sadly I know there’s a high chance s2Member sends a cancellation request to Stripe later, I hope not. :pray:t2:

#14

Thanks for the update. Any related entries in the s2 logs about it? Could I see them? (edit any sensitive information, please)

:slight_smile:

1 Like
#15

I thought you had seen my private message with the logs.

I notice there was an update to the plugin today. Do you want me to re-edit that part for testing manually again or should I just keep the code as is?

#16

I thought you had seen my private message with the logs.

Thank you! I saw them now.

That’s from s2’s stripe-api.log, right? Could you show me the related entries from the log over at Stripe? I’m trying to see what part of the webhooks is causing s2 to end up firing the EOT. I have a suspicion, but trying to confirm it.

I notice there was an update to the plugin today. Do you want me to re-edit that part for testing manually again or should I just keep the code as is?

Do you mean this? Ipn_signup_vars

Sure, you can reapply it if you want to keep testing that.

:slight_smile:

1 Like
#17

Problem happened again today. User tried to subscribe, payment failed. They did it again a minute later successfully.

s2Member cancelled the successful subscription.

How can we disable any signal from s2member cancelling subscriptions, so this does not happen? I don’t use Cancel buttons on my site as I process cancellations always manually to avoid issues like users saying they clicked on a button when they didn’t etc.

Can you help me with a snippet of code or a portion of the plugin to modify so s2member NEVER sends a request for Stripe to cancel a subscription under any circumstance? :pray:t2: