Stripe Failed Payment Not Triggering an EOT

#1

Hello All:

I’ve been using S2 for about a year on my client site, and we discovered that when a Stripe subscription payment fails, it’s not triggering an EOT and properly demoting the users. We have the failed behavior in Stripe set to cancel the subscription, but that isn’t getting passed to the website.

I saw this post from Sept. 2017 about this very topic: Bug: Stripe Subscription payment failing - users not demoted

But I don’t see a resolution to the issue. Has S2 acknowledged that this is a bug?

Cheers!
Angela

#2

Have you checked that the EOT cronjob is running? I (and others) have experienced its somehow being deleted on some sites. See S2Member not demoting users when they reach their EOT

Use WP Crontrol to see whether the cronjob is running. If not, you just need to reset it from within Stripe Options.

#3

it’s in my case definitely not a bug on any setting - but one of the countless s2member bugs that are not getting fixed… (all of them I encounter are related to s2member wrongly deciding to ignore to take action).

60% of my stripe subscriptions that are failing due to payment not going through turn themselves into accounts activated forever…

I actually wanted to give Stripe another chance for subscriptions as they now inform the customers about failed payments - something paypal doesn’t and built up some trust with European credit card issuers so maybe yearly subscriptions could work better than in the past when Stripe was useless for them - but this bug not getting fixed (I provided all the logs possible - clearly not a settings problem) stops me (would just love a good alternative to s2member that can work with incoming s2member subscriptions, would be happy to pay a couple of grand for it - s2member cost me way more).

#4

Felix,

This is getting ridiculous. You are hijacking a thread with irrelevant drivel. This is about EOTs and nothing else.

In any event, I don’t believe a word you say any more. If s2Member had really cost you so much, you would have found something else by now. So either you’re lying or just an idiot. Either way, you have no business on this thread.

#5

well I opened the thread referrred in first post here: Bug: Stripe Subscription payment failing - users not demoted

and I did provide all relevant debug logs. It’s clear that there is no configuration problem because the IPN about failed payments are received as it shown up in the log:

[s2member_log] => Array
(
[0] => Ignoring this Webhook/IPN. The event does NOT require any action on the part of s2Member.
)

)

but this should not happen on the final notice from Stripe. Strangely from users who checked out to prolong 80% of the EOT are treated correctly, from new users 95% are ignored by s2member. My logs are still getting longer. Paypal and stripe sometimes change the IPN statements slightly - and s2member is not up to date with the full terminology.

This thread is about the exact same bug. Stripe subscription payments failing and users not demoted. On paypal it works fine (though the handling of conflicts is faulty for both stripe and paypal as s2member should only take action once conflict is decided and not on opening of conflict - it’s very easy to get that right (e.g. quaderno gets all of those invoices right in case of conflict - s2member has no code to properly react - but yeah that’s off topic here)

(s2member cost me >5k€ for programming a VATMOSS invoicing system end 2014 (I even published most of the relevant code back then somewhere on s2member forums) - now I just pay ~1000€/yearly for quaderno invoicing - something that would be a one up fee with proper plugins for EDD or woocommerce. It’s way strange that s2member has no invoicing support itself. Quaderno s2member paypal support is hacked around a bit but a natively integrated and reliable solution would be better as quaderno relies on s2member not ignoring IPNs from paypal )

#6

s2member cost me >5k€ for programming a VATMOSS invoicing system end 2014

Yeah, that’s really relevant to this thread, isn’t it? Your needle has got stuck again. Time to upgrade to digital!

It’s also not true. You chose to pay that because you spooked yourself instead of either (a) taking proper legal advice or (b) choosing an alternative method of processing payments.

As I said, either you’re lying or just an idiot.

#7

Hi Tim, Thanks for your response. The cron job is running. See screenshots. My impression is this may be a bug. We’re going to keep an eye on things on my client site, and I’m also watching the Github thread you started. Thanks for your help!

Screen Shot 2018-01-08 at 8.10.31 AM.png2880×1800 581 KB

Screen Shot 2018-01-08 at 8.05.34 AM.png2880×1800 1.16 MB

#8

of course this is a bug - if you enable debugging - I’m sure you will also get

[s2member_log] => Array
(
[0] => Ignoring this Webhook/IPN. The event does NOT require any action on the part of s2Member.
)

inside the log noticing that s2member wrongly just drops the notification - which is correct for the first 3 tries, but not for the final one.

#9

I’m having this same issue. s2member is not correctly demoting someone who had a failed Stripe payment. Works fine with Paypal