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
 => 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 )