PayPal Pro and members not demoting on declined credit cards

[lisaboydp31]

1. It seems that 2 recurring billing profiles are being setup for the same person. The last one is registered with WP, but the first one is still active. We've had people who've been billed twice the past 2 months.
2. Members are not being demoted correctly. Jason had looked at this issue before and we thought it was fixed, but it's not. When a person's credit card is declined, PayPal marks their account status as "Cancel" but this does not demote them in WordPress. We just cleaned up manually almost 200 members whose payments had not gone through yet they were still members. I knew that when the "fix" was put in place it would only catch new cases, but there were several that it had not demoted correctly since then.

Thanks! Really frustrated and appreciate the help!

[jaswrks]

@lisaboydp31 Thanks for this follow-up.

You should have this file, and I will need to see it to investigate this further for you.
/wp-content/plugins/s2member-logs/authnet-arb-ipn.log

Please post that privately for me here. Thanks!
http://wsharks.com/1mjbERc

[jaswrks]

@lisaboydp31 Just checking in. Did you send over that log file and I missed it? :-)

[lisaboydp31]

Hi Jason,

Sorry I hadn't had a chance to send it over before now. I'm assuming you
need the paypayl ipn log though not the authnet log? I've zipped all of the
logs I have in the directory to make sure you have what you need. Thanks!

simply His,
Lisa B.

---

Web Developer
Proverbs 31 Ministries
http://proverbs31.org

On Wed, Apr 23, 2014 at 4:56 AM, Jason Caldwell notifications@github.comwrote:

@lisaboydp31 https://github.com/lisaboydp31 Just checking in. Did you
send over that log file and I missed it? :-)

Reply to this email directly or view it on GitHubhttps://github.com//issues/104#issuecomment-41138727
.

[jaswrks]

@lisaboydp31 Thank you. I'm deleting the reference to that file here at GitHub because this is a public issue tracker. In the future please submit files like this privately for the best security. I would also suggest that you remove those log files from any publicly available location.

---

I just finished analyzing your log files, and in particular the paypal-payflow-ipn-* log files. These are where s2Member log it's communication with the Payflow API when it polls your current list of ARBs daily to check on the status of subscriptions.

In your most recent log files with over 4MB of data for LOTS of members, there is not a single non-ACTIVE status being returned by the Payflow API for any of your current subscribers. There is nothing which leads me to believe this is in error. It just looks like all of the members that you have are currently ACTIVE with their subscription.

That said, it does seem like you have LOTS of paying customers. Good for you! With so many paying customers for s2Member to keep tabs on through it's polling routine, you might want to increase the maximum number of polls per process to a higher number.

The current default value is to check up to 3 member subscriptions every 10 minutes. However, there are some internal performance tuning filters for very large sites. I will offer you the following suggested tweaks to help prevent the issues that you've reported here.

Please create this directory and file:
/wp-content/mu-plugins/s2-hacks.php

<?php
function s2_auto_eot_system_per_process(){ return 10; } // Up to `10` EOTs every 10 minutes.
add_filter('ws_plugin__s2member_auto_eot_system_per_process', 's2_auto_eot_system_per_process');

function s2_pro_payflow_ipns_per_process(){ return 20; } // Up to `20` status checks every 10 minutes.
add_filter('ws_plugin__s2member_pro_payflow_ipns_per_process', 's2_pro_payflow_ipns_per_process');

Noting that ws_plugin__s2member_pro_payflow_ipns_per_process is currently set to a maximum of 3. So with that in mind, it is possible that you have so many active paying subscribers that s2Member is simply not getting to the ones which are non-ACTIVE each day.

You want to set this value to something that will allow s2Member to check every single subscriber that you have on a daily basis, where the check runs once every 10 minutes. Thus, if you have it set to 20 (as seen in the example above) every 10 minutes throughout a single day, you can check up to 2880 subscription profiles for a possible non-ACTIVE status each day.

You can increase from there, but don't go too far with it because normally a hosting provider will limit the time each script can run to approx 30 seconds. If you start seeing "script timeout" errors in your PHP error log after increasing the value too much, back it down until those go away.

---

I'm going to leave this issue open for a few days while I wait to hear back from you.

Also, I think there is some room for improvement too. Ideally, s2Member would sort the list of subscriptions to check based on the last time it checked a particular customer; starting from the oldest ones first. This way in cases where the default 3 is not enough, they still get picked up the next day; and the next, etc.

I will post a new commit and update this issue once that has been implemented.

[lisaboydp31]

Thank you for the explanation! That makes sense as to why our members were
not being demoted properly. We have just gone through and cleaned up over
200 members manually who were having payment issues (declined cards) and no
payments for months -- so at least we're starting from a better place now.
The file's in place and we'll keep an eye on it to make sure it works
properly.

I also removed the files :) Sorry about that! It was a late night when I
replied and wasn't thinking clearly. I appreciate your help!

simply His,
Lisa B.

---

Web Developer
Proverbs 31 Ministries
http://proverbs31.org

On Wed, Apr 23, 2014 at 9:00 PM, Jason Caldwell notifications@github.comwrote:

@lisaboydp31 https://github.com/lisaboydp31 Thank you. I'm deleting the
reference to that file here at GitHub because this is a public issue
tracker. In the future please submit files like this privately for the best
security. I would also suggest that you remove those log files from any

publicly available location.

I just finished analyzing your log files, and in particular the
paypal-payflow-ipn-* log files. These are where s2Member log it's
communication with the Payflow API when it polls your current list of ARBs
daily to check on the status of subscriptions.

In your most recent log files with over 4MB of data for LOTS of members,
there is not a single non-ACTIVE status being returned by the Payflow API
for any of your current subscribers. There is nothing which leads me to
believe this is in error. It just looks like all of the members that you
have are currently ACTIVE with their subscription.

That said, it does seem like you have LOTS of paying customers. Good for
you! With so many paying customers for s2Member to keep tabs on through
it's polling routine, you might want to increase the maximum number of
polls per process to a higher number.

The current default value is to check up to 3 member subscriptions every
10 minutes. However, there are some internal performance tuning filters for
very large sites. I will offer you the following suggested tweaks to help
prevent the issues that you've reported here.

Please create this directory and file:
/wp-content/mu-plugins/s2-hacks.php

[jaswrks]

Thanks Lisa! :-)
We've had this routine further optimized in the development copy, and those changes will go out in the next maintenance release. The filters I pointed you to previously will continue to function as expected though :-)

[jaswrks]

Reopening this issue after another report came in. It seems there is still room for improvement here. When/if s2Member encounters a recurring profile for which there are no IPN Signup Vars associated with a particular user, we currently skip that entry all together. This makes it difficult to detect an issue when reviewing the log entries.

Line 81 in s2member-pro/includes/classes/gateways/paypal/paypal-payflow-poll.inc.php

if(($subscr_id = get_user_option("s2member_subscr_id", $user_id)) && !get_user_option("s2member_auto_eot_time", $user_id))
    {
        if(is_array($ipn_sv = c_ws_plugin__s2member_utils_users::get_user_ipn_signup_vars(false, $subscr_id)) #
        && ($paypal = c_ws_plugin__s2member_pro_paypal_utilities::payflow_get_profile($subscr_id)) && is_array($paypal["ipn_signup_vars"] = $ipn_sv))
            {
                if(preg_match("/expired|too many failures/i", $paypal["STATUS"]))
                    {