I have had about 5 clients with payment failure since Jan 19, 2023, and s2member could not identify this and the clients still have access to the dashboard.
How can you solve this?
I can’t trust s2member.
Payment failed and members still have access
1 Like
I have too many members, so I can’t check it manually.
How disappointing that is.
Is it just me or nobody is supporting s2member anymore ?
You need to provide proper info. Do the members have an EOT in the past? Loads of threads how to solve it and happens commonly.
Or is it subscribers with unpaid/cancelled subscription and no EOT was entered. This situation is complicated and several rare problems can lead to it
Users have are subscribers with unpaid/canceled subscriptions and no EOT has been entered.
s2member does not recognize these members who have not paid.
I am using Stripe.
I still can’t solve it, I have to keep doing the work manually.
Where do I set the limit for attempted payment ?
This is my shotcode.
[s2Member-Pro-Stripe-Form coupon="" accept_coupons=“1” default_country_code=“BRL” captcha=“0”]
[s2Member-Pro-Stripe-Form level=“1” ccaps="" desc=“MONTHLY $47.00 / (Billing every month, recurring)” cc=“BRL” custom=“mysite.com” ta=“0” tp=“0” tt=“D” ra=“47.00” rp=“1” rt=“M” rr=“1”/]
[s2Member-Pro-Stripe-Form level=“1” ccaps="" desc=“QUARTERLY $135.00 / (Billed every 3 months, recurring)” cc=“BRL” custom=“mysite.com” ta=“0” tp=“0” tt=“D” ra=“135.00” rp=“3” rt=“M” rr=“1”/]
[/s2Member-Pro-Stripe-Form level=“1” ccaps="" desc=“WEEKLY $260.00 / (billing every 6 months, recurring)” cc=“BRL” custom=“mysite.com” ta=“0” tp=“0” tt=“D” ra=“260.00” rp=“6” rt=“M” rr=“1”/]
[/s2Member-Pro-Stripe-Form]
The problem is that the plugin does not demote upon failed payments. I asked @clavaque for a fix but I guess he didn’t have the opportunity to work it out. Same with PayPal. s2Member only removes access when a subscription is cancelled, but the entire point is to cut access, keep the subscription active at the payment processor indefinitely so the payment processor continues trying to collect, then reactivate the user if a future payment is successful.
I wish I were able to code it myself, but I don’t have enough knowledge for such implementation, sadly.
One of the most intensive parts of my work managing subscription is exactly this. Checking failed payments and demoting users manually, one by one, every single time. 
It is not rare at all (people subscribe, run out of money, have no funds for a few days, if you keep trying their payments go through). s2Member does not demote users when they don’t pay when it’s due (it ignores the IPN notification but sees it). That’s a massive bug that should be addressed. Sorry, but I have been asking for help on it for years.
It keeps waiting for the subscription to be cancelled, which makes no sense since you lose a very large percentage of subscribers with such policy. The system should continue trying to collect until successful, then re-promote the user upon payment of whatever was pending.
I have failed payments every single day and I have to set EOT manually, one by one. I also have a lot of extra work when I am able to see a late payment, since those users are usually already demoted and I am not notified by the payment processor when it happens.
Stripe also has a very neat feature that could be used by s2Member to try to collect from each customer with pending payments automatically, but it’s also not implemented. For that I was able to create a macro that literally clicks on each unpaid invoice and tries to collect it. 
I’m really not following you. Stripe (and I assume Paypal too as I don’t use that) try a number of times to capture funds upon renewal. For me it’s 4 times within a week. Those settings are done in Stripe or Paypal. If all fail, the subscription is cancelled and the user is demoted. If it’s an annual membership that would occur on cancel. If it’s a monthly membership that would happen at the end of that month’s billing cycle.
Limit for attempted payments is done within your Stripe account dashboard.
It’s also important to make sure your cron job is being run daily
https://www.yoursite.com/?s2member_auto_eot_system_via_cron=1
You can look that up on other threads for users who have had a similiar problem.
No, you don’t have to do things that way. When a payment fails I remove access right away but I do NOT cancel their subscription. Once a late payment happens I reupgrade the user manually.
If you cancel the subscription you lose that revenue forever.
Some users go for months without paying but they eventually fix whatever was wrong with their card(s) and you’re able to recover them without them having to actively start a new subscription (which is something very unlikely to happen).
It’s interesting nobody seems to notice this massive issue or want to work towards fixing it, as it means a gigantic revenue loss if you compound that involuntary churn over time.
Ideally s2Member would set EOT for a set amount of hours when the first decline happens but keep the subscription active at the payment processor. Once a late payment happens and the notification from Stripe or PayPal is sent to our sites, s2Member should reupgrade those previously demoted users. Admin emails sent to us for each event like we get with EOT and new subscriptions.
Oh, and when PayPal and Stripe give up collecting after x tries you can open the subscription using their interfaces and revert it. PayPal allows you to set ZERO as the maximum number of tries. Stripe doesn’t have it but on both you can manually collect one by one. When you’re small like me you can do it manually (still time consuming) but this is much harder if you ever have a large number of subscribers. This should be all automated towards maximum revenue. Not the other way around. If a user wants to cancel a subscription they always reach out and to that. Cancelling a subscription should never be the default procedure. You want all the friction to be on things that reduce revenue, not the other way around.
Not sure what kind of business you are running, but at least in mine, if the card is declined 4 times, they are certainly aware of it as they are getting emails. This means they have no intention of fixing the problem and I am no longer authorized to bill them while they are no longer authorized for membership. I am not going to bill them 6 months later and deal with chargebacks. They can certainly come back and re-register if they want and many of mine have.
That’s your choice. I make my policy very clear to my users when I notify them as they have payments pending. I’d have lost more than 30% of my current user base otherwise. Probably half.
We should have the option to choose s2Member’s behavior. The user should lose access right away when a payment is declined (or after a set number of hours/days after a decline) and they should be reupgraded upon payment. As simple as this. Requiring the user to go through the friction or starting over a new subscription means reducing your base dramatically long term. Just think about it.
It’s more than my choice, it is the law I believe. Creating additional retries may be seen by issuers as potential fraud and could result in legitimate charges being declined more frequently. Authorizations expire. Check the laws in your state.
I don’t live in the United States. But if you have a debt it’s normal to expect your creditor will continue trying to take from your card. When users don’t want to pay they always reach out and/or cancel themselves, pretty quickly and efficiently. The issue is usually involuntary churning.
There’s even third party services designed to help with that, but they basically keep trying, so there’s not much of a point on paying them…
Always make your subscribers aware in advance it will happen. They will contact you to cancel if they want to and they will contact you to reactivate their accounts when they’re charged as well.
I am running a test right now. Not sure if it will work out but I changed the file /s2member/src/includes/classes/paypal-notify-in-subscr-or-rp-payment-failed-w-level.inc.php by copying and editing segments of the file that handles subscr cancellations so we get the same behavior (EOT when payment fails, like what we have when a subscription is cancelled via PayPal). I will try to do something similar to Stripe’s Integration. Please keep in mind I do NOT know PHP and I am just “hacking my way” through the code by making adjustments that might work, or not… 
paypal-notify-in-subscr-or-rp-payment-failed-w-level.inc.php.zip (3.2 KB)
Also changed file /s2member-pro/src/includes/classes/gateways/stripe/stripe-notify-in.inc.php and attached it as well. I copied the routine from subscription’s cancellations to be also applied to the payment failure cases. I notice most people don’t bother fixing their payments when a recurring fails. Since I don’t know how to program it to give a courtesy time after a notification, I’ll just let it cancel right away until I figure out a better solution.
stripe-notify-in.inc.php.zip (4.1 KB)
Just saw 1 user being demoted. Funny the system assigned May 31st as EOT even though it’s June 30th.
No idea why but I’ll keep an eye on it. 
1 Like
Worked for both PayPal and Stripe. Immediate demotion. I will see later on how to make the grace period work.
It’s quite convenient to have this working, I am glad that my crazy method seems to work, after all?
PayPal buttons are working unencrypted.
So far demotions are working surprisingly well. I am quite happy with the modification for now. I’ll keep observing and I’ll see if I can improve it in the future.
I have no idea how php works but I am glad my background programming other languages for a few decades helped. 