Bug: Stripe Subscription payment failing - users not demoted

openmtbmap · 2 September 2017 21:31

I setup Stripe to try the max of 3 retries for subscription - however when the 3rd retry fails - user simply stays active and is not demoted!

Paypal demotions on failed payments work, Stripe do not. Otherwise Stripe payments work fine (while paypal is the typical s2member mess).

the failed payment shows up in both stripe log files - however even though at Stripe the profile is closed, in the logs s2member states:

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

)

I can see that since 24.08 no more closed payments that failed demoted the user - failed payments before lead to demotion as far as I can see. Or is the grace period over 7 days now? In this case it should demote instantly after payment is failing 4 times and closed.

However going through all users that failed and closed - also for older ones often the user is not demoted! Really s2member and subscriptions is simply a big big mess if not only paypal IPN is unrealiable but not also Stripe support is dropping unrealiable.

openmtbmap · 3 September 2017 00:30

Actually - 80% of all users are not demoted over the last 3 months - did not get trough the older supposed demotions yet - ■■■■ - 500 users that should have been demoted in the last 2 years to check up - I know in the beginning it did work - s2member really blows it just once more. Paypal 1-3% of IPN ignored wrongly, stripe demotions on subscriptions ignored falsely in 80% of cases.

Simply great by s2member, simply great.

Edit: I noted that users who prolonged/extended their accounts - are always correctly demoted. Those who checked out as new users however are not demoted in 95% of all cases.

Just if you want to check up - go to the subscribtions page on your Stripe account - then set 2 filters, a) for unpaid payments, b) for closed. then just check through your userlist. It’s a PITA now that I have to manually go through over 500 users to manually demote them.

(it’s crazy how much time this needs - spend 4 hours now to go through 200 of the >500 users to demote - so again 10 hours wasted due to s2member malfunctioning).

openmtbmap · 3 September 2017 23:49

actually - what happens if I simply demote all those users - without deleting the Stripe payment info from their fields if they extend their account with a new payment? Is the data written over correctly also for paypal as there is no CID?

If I had to delete all those CID fields too - I would have spent 20-30 more hours on deleting all the data. Oh s2member is a real PITA right at the moment with all those bugs. I really have to find the best way to get rid of it without loosing all the subscriptions. This bug easily cost me a couple thousand of Euros turnover because nearly none of those users renewed their account but kept on using it.

Persyo · 7 September 2017 00:35

We are experiencing the exact same problem. Payments on Stripe has been failing and they do not get downgraded or demoted.
looking for a solution

openmtbmap · 7 September 2017 19:47

I’m sure everyone has this problem - but not many people use s2member really productively with subscriptions - or they never checked if demotions worked (it does work for people who cancel the payment - just not for new users where subsequent payments are failing without being canceled by the user itself).

rossagrant · 8 September 2017 15:49

Guys, I think this could be due to your Stripe settings and not s2’s fault.

Have a look at your subscription settings. After all of the payment retries, you have to tell Strioe what you want t to do.

Anything from cancel the payment, to leaving the subscription open, to trying again the following month.

If you don’t have it set to cancel, it will never tell s2 to demote.

Check out what you have it set to.

openmtbmap · 8 September 2017 20:42

They are set to cancel after 4. unsucessful payment - and there is not difference between new users or users upgrading their accounts/prolonging - however the first is affected while the second works without problems.

Is it possible that s2member cannot cope with the 4 tries - as paypal tries 3 times max? (stripe offers 4 times retry max (I don’t even have the possibility to retry unlimited times). After 4. time there is no way to restart the payment - customer can only check out again. The bug is definitely within s2member and not a stripe setting.

4 times is really needed however as Stripe puts a 5 days interval. So 3 retries means user has 19 days to update his data in case of failure (well theoretically as the user is not informed about failed payments - hope that s2emails plugin can do this in future). 19 days usually is giving you like a 55/45 chance for payments failing due to low balance/over monthly spending limit (if user in principle is solvent) - while 14 days (2 retries like paypal) would give less than 50% chance.

rossagrant · 9 September 2017 13:25

Have a look at the IPN history of these failed transactions and see if the webhook from Stripe is showing as received by s2Member.

The status on the webhook needs to say ‘Successful’ not ‘Pending’.

I think you will only be able to see this on transactions that are less than 14 days old though, as Stripe archives them after that.

I’ve been using s2 for years - and BOTH PayPal and Stripe webhooks/ IPNs are working perfectly upon upgrade/ demotion/ cancellation.

Are you guys using FULL https:// on your sites now too? If you are using plain http:// with no SSL certificate, this will cause issues with IPNs too.

openmtbmap · 15 September 2017 11:59

As I said - I can even the the Stripe message being received in s2member debug logs - however s2member falsely decides to ignore the IPN. (and I switched my website to be https only before I even started accepting Stripe - over 3 years ago).

Actually noticed I can change the first retry to also 7 days - before it was 5 days - then 7 days. However this must have been correct anyhow - users who upgraded/extened their account always got correctly demoted, users who subscribed newly did not - even though the s2member shortcode is basically identical except in the amount.

It’s clearly canceled in Stripe log - and IPN was received. In this case everything is fine - as the user upgraded and it was not a new payment and s2member demoted. The payment was created with the following shortcode:

[s2Member-Pro-Stripe-Form level=“1” ccaps="" desc=“First_Year_for_15Euro_then_13Euro_yearly_(recurring_charge,_for_OpenMTBMap_access)” cc=“EUR” custom=“openmtbmap.org” ta=“15” tp=“1” tt=“Y” ra=“13” rp=“1” rt=“Y” rr=“1” coupon="" accept_coupons=“0” default_country_code="" captcha=“0” /]

Here is the screenshot on the other hand for someone subscribing newly - and consequently not demoted by s2member even though all IPNs were received
This was the shortcode for creating the subscription:
[s2Member-Pro-Stripe-Form level=“1” ccaps="" desc=“First_Year_for_20Euro_then_13Euro_Yearly_(recurring_charge,_for_Openmtbmap_access)” cc=“EUR” custom=“openmtbmap.org” ta=“20” tp=“1” tt=“Y” ra=“13” rp=“1” rt=“Y” rr=“1” coupon="" accept_coupons=“0” default_country_code=“DE” captcha=“0” /]

Here is the relevant part about payments (dates not visible in order to hide the payers email address)

This bug is therefore clearly caused by s2member.
(go to subscription --> then click on the invoices tab --> then filter for unpaid and closed - and check if all users found this way are demoted. I guess not.

openmtbmap · 15 September 2017 12:21

And here is the log from the Stripe IPN debug - clearly showing s2member is buggy!

Any other solution but s2member is super buggy? It’s really a PITA using s2member and stumbling from bug to bug while being locked in due to the subscriptbions to easily move away to a reliable membership plugin. Paypal is buggy as hell with s2member - and Stripe too (plus checkout form with usability from the 90s if you need address).

openmtbmap · 15 September 2017 12:20

However the working Stripe IPN receival is also showing ignored at the end - I’m not sure what message to log for in the logs. ■■■■ - this works should be done by s2member quality management.

openmtbmap · 15 September 2017 12:32

For the user who was demoted - in the gateway core ipn log - I can find the following entry - this entry simply does not exist for user who are not demoted. All Stripe IPN messages are received however (status 200 ok):

LOG ENTRY: Sat Sep 9th, 2017 @ precisely 2:49 pm UTC
PHP v7.0.22-2+ubuntu16.04.1+deb.sury.org+4 :: WordPress v4.8.1 :: s2Member v170722 :: s2Member Pro v170722
Memory 7.76 MB :: Real Memory 8.00 MB :: Peak Memory 7.87 MB :: Real Peak Memory 8.00 MB
www.velomap.org/?s2member_paypal_notify=1
User-Agent: s2Member v170722; https://www.velomap.org
Array
(
    [txn_type] => subscr_eot
    [subscr_cid] => cus_*******
    [subscr_id] => sub_*******
    [custom] => www.velomap.org
    [period1] => 1 Y
    [period3] => 1 Y
    [payer_email] => *******
    [first_name] => *****
    [last_name] => ********
    [option_name1] => Referencing Customer ID
    [option_selection1] => 1708
    [option_name2] => Customer IP Address
    [option_selection2] => *******
    [item_name] => First_Year_for_15Euro_then_13Euro_yearly_(recurring_charge,_for_VeloMap_access)
    [item_number] => 1
    [period] => 1 Y
    [option_name] => Referencing Customer ID
    [option_selection] => 1708
    [proxy_verified] => stripe
    [s2member_log] => Array
        (
            [0] => IPN received on: Sat Sep 9, 2017 2:49:22 pm UTC
            [1] => s2Member POST vars verified with a Proxy Key
            [2] => s2Member originating domain (`$_SERVER["HTTP_HOST"]`) validated.
            [3] => s2Member `txn_type` identified as ( `subscr_eot|recurring_payment_expired|recurring_payment_suspended_due_to_max_failed_payment` ) - or - `recurring_payment_profile_cancel` w/ `initial_payment_status` ( `failed` ).
            [4] => Member Level/Capabilities demoted to: Subscriber.
        )

    [subscr_gateway] => stripe
    [subscr_baid] => sub_*******
    [ip] => *******
    [currency] => 
    [currency_symbol] => $
    [s2member_paypal_proxy] => stripe
    [s2member_paypal_proxy_use] => pro-emails
    [s2member_paypal_proxy_verification] => *******
)

rossagrant · 21 January 2018 19:21

Sounds simple, but have you checked what behaviour you have selected under the Stripe options for ‘Automatic EOT Behaviour’.

I’m using PayPal and Stripe and am not seeing any bugs like these right now.

openmtbmap · 28 January 2018 23:07

if you would look at my replies further up you see a screenshot of that Stripe setting - it’s correctly setup to cancel.

Note it usually only happens for users that setup subscription with their account directly. users prolonging with subscription are mostly correctly demoted.

As s2member receives the IPN about cancellation of the payment (see logs above) - there is clearly a bug in s2member. Also my invoice provider receiving those exact same IPN calls (quaderno.io) get’s it right, just s2member bogs it up.

ralpheconde · 30 May 2018 18:47

I have the same problem I have a customer that his has account has been past due for 10 days and Strip try to collect the money 3 times already nothing happen and the payment fail but the customer still have access with his membership level.I need help cause I think S2member should cancel the subscription automatically once the payment fail.

Starbucksamore · 31 May 2018 00:05

Agreed with @RossaGrant - you might want to check how you have your EOT behavior set up. I’m also not seeing any problems at all.

You will want the system to try a certain number of times and then delete the account. (At least that’s how I do it, rather than keep the subscriber at a level 0, I just delete them. This gets rid of the problem where they are demoted but can still log in and get redirected to the Member purchase page.)

openmtbmap · 24 April 2019 18:32

Could this please be solved - the problem still exists! Basically no members are demoted after payments are failing - because s2member wrongly decides to drop the Stripe IPN messages.

If there is any need for more debug data I can provide it - but I’m pretty sure all needed is above already.

clavaque · 7 October 2019 21:11

Hi Felix.

Was reviewing what else needed fixing with the Stripe integration and found this. Do you still have this happen? Could you give me some more details?

I see that the log entry you pasted is a charge.failed event. s2Member doesn’t act on those.

s2Member sets an EOT for the user when his subscription ends. If there are failed payments but the subscription continues, then there’s no EOT.

The users you expect demoted because of failed payments, did they still have the subscription active on Stripe?

The Stripe events that could cause an EOT or demotion in s2Member, would be:

customer.deleted
customer.subscription.deleted
charge.refunded
charge.dispute.created

What do you see in the logs for those events?

openmtbmap · 7 October 2019 21:41

yes I still have this issue. Will check again on the messages.

But no - the users are not active anymore on Stripe. It fails on the 4. attempt. My guess somehow is that s2member is not reacting to the 4 attemps anymore as paypal only tries 3 times.

openmtbmap · 7 October 2019 22:32

On the latest I see a: Automatic collection for this invoice was turned off message.
Actually Stripe tried 6 times unsuccessfully (over the course of 29 days). Only after the last try they failed the payment finally.

Automatic collection for this invoice was turned offOct 4, 2019, 7:24 PM