Max failed payments not demoting members

Hey guys,

I’ve been allowing IPN logs for a little while to see what’s up with max failed payments not demoting any members, and have got some handy info, but not sure what the next step is.

The client simply receives a PayPal email to say “You didn’t get your money” and “The automatic payment from has failed 1 times. As a result, we will not try to process this automatic payment again.”

Checking the IPN logs, this is the short version of what’s happening:

  1. Account has 3 attempted charges;

  2. The first 2 are logged as ‘recurring_payment_skipped’ and each time this occurs the next attempted-charge is set for 5 days time by PayPal.

  3. S2M does not take any action based on any number of ‘skipped’ payments, so the account stays the same.

  4. The last 1 is ‘recurring_payment_failed’ which sets the next attempted-charge for 82 days’ time, which I’m guessing is ‘3 months’ (the subscription duration) minus the 10 days it took to reach that last failure from the initial failure.

  5. S2M then logs “s2Member does NOT respond to individual failed payments, only multiple consecutive failed payments.”

Here’s the s2M log from that final ‘failed’ payment:

        [0] => IPN received on: Thu May 18, 2017 11:11:35 am UTC
        [1] => s2Member POST vars verified through a POST back to PayPal.
        [2] => s2Member originating domain (`$_SERVER["HTTP_HOST"]`) validated.
        [3] => s2Member `txn_type` identified as ( `subscr_failed|recurring_payment_failed|recurring_payment_skipped` ).
        [4] => This `txn_type` does not require any action on the part of s2Member.
        [5] => s2Member does NOT respond to individual failed payments, only multiple consecutive failed payments.
        [6] => When multiple consecutive payments fail, a special IPN response will be triggered.

So, where to from here? I’m using Pro Forms with rra=2. Do I need to change this rra value? It seems like PayPal gives up after 1 ‘failed’ payment which doesn’t include the previous ‘skipped’ payments, but that isn’t enough to trigger any action by s2Member. I’m a bit stuck!

Anyone with even a rough idea of what I might be able to try here?

Would setting “rra=1” change anything, or just mean I get one ‘skipped’ payment instead of two before the singular ‘fail’?

It seems like somewhere along the line this process breaks down.

As an aside, if the client edits a PayPal recurring profile to change the status from Active to Cancelled, will this be picked up by s2M and see the user(s) demoted when the CRON job runs?

Should I be seeking (Pro) support somewhere besides here?

After dealing with PayPal support (like drawing blood from a stone) I have a little more info to add to this and hopefully contribute to the solution!

Regarding all new profiles:

If you want to cancel profile automatically after failed payment, you’ve to set below parameters while creating recurring payment:

To know more about it, please refer below link:

Regarding existing profiles:

If you want to update MaxFailedPayments in current active profiles, you can do it using UpdateRecurringPaymentsProfile API method.

To know more about it, please refer below link:

Now, the first bit (new profiles) I suppose I can resolve by changing all PayPal forms on the website to have RRA=0 - if anyone can confirm or deny that…?

I am completely in the dark when it comes to NVP, API operations, calls etc. so if anyone has experience with this and wouldn’t mind helping out I would be indebted. I tried to dive head-first into it but a lot of the language is beyond me.


Hello Tom,
Have you had any resolve or response on this issue?

I am having the same exact issue as you are regarding the demotions. For some reason s2member developers cannot give me the help I need. I have spoken to many other site owners using s2member and they are having the same issue with no help.

Hey Mariana,

I didn’t hear from anyone, no.

Some 3-month subscribed members have since gone past their next ‘failed’ payment (not ‘skipped’) and been demoted. Other users we have manually demoted, which was a miserable job.

We decided not to bother attempting to alter the existing profiles via API calls and just let this whole thing ride out. Instead, we have moved payment gateways to Stripe, where there is much more flexibility in that regard. You can set up your demotion rules within Stripe itself rather than setting an RRA number in your shortcode and hoping for the best.

However, we have also seen a pretty steep decline in cash flow since moving to Stripe. I don’t think it’s really a ‘trusted’ brand here in Australia yet. So we’re doing some tracking to see how we can address that. If it’s not one problem, be sure there is another waiting!

Hi Tom,
Thank you for getting back to me. Just as an FYI I am using both gateways (Paypal and Stripe). The issue still is happening so we have had to rely on manual demoting for some users and as you said it is a major task. Because I have yet to find any solution or support with this issue I am thinking about switching to WooCommerce. Have you thought of this? Thoughts? Thank you again.

Hey Mariana,

I did look at Woo Memberships when we initially set out to build a subscription-based site. It seemed to add a lot of beginner-level UI while the actual features list wasn’t as impressive as s2Member.

While it could be an idea to try it, I have used Woo Bookings and some other Woo extensions in the past with mixed results. So I wouldn’t go into it thinking that Woo Memberships + Subscriptions is going to solve all your problems - it might make its own new ones instead. Worth consideration though.

Consider submitting your issue to the github issues page…I nearly did, but client is happy enough to slowly move everyone over to Stripe (or let people with no payment problems continue to use their PayPal payments).

I have always had my rra set to 1 - and it’s always worked perfectly.

Still does to this day.

Are you guys using https on your sites now? That’s required for PayPal’s IPN to work nowadays, from what I know anyway.

I’ve even included all the logs here - s2member pro seems to be dead.

Let’s hope eventually it will be fixed - the bug is fully on s2member side as I could document with my logs.

Yes Ross, we’re using https. Did have some initial trouble while serving over http which was resolved by the SSL cert.