s2Member is Incorrectly Ignoring some IPN (mp_cancel) requests

Mitch · 14 March 2021 06:38

Hi All,

I am using a Paypal payments pro setup with my installation and I have just discovered that some members on my website are not being allotted an EOT when they cancel their subscription to my site, and their paypal manager profile is not being updated either.

Likewise when users miss payments, I am not getting any demotions by S2Member.

Looking in my log I see that those users that cancel without an EOT being allotted are receiving:

“[3] => Ignoring this IPN request. The txn_type/status does NOT require any action on the part of s2Member.”

This is where the s2Member stops in the cancellation, no EOT is given, and no cancellation emails are sent.

However, for some users everything works fine.

All recurring payments are being handled correctly.

Since finding the problem and turning on logs, nothing at all is being logged in my **[paypal-payflow-api.log] but I do have logs in the core.

Any help would be much appreciated!

Regards,
Mg

clavaque · 14 March 2021 15:03

Hi Mitch.

If you’re not using PayPal Pro PayFlow Edition, you don’t need to enter PayFlow Account Details, or expect that log to have entries. No problem there.

If some users are getting an EOT and others aren’t, then it seems the integration is working, and the problem would be more related to those particular subscriptions than the integration itself.

s2 expects some details in the IPN before running with it, and I suspect that those subscriptions are missing one of those details and thus get skipped by s2.

Where those subscriptions created with an s2 button or form, or did you create them some other way (a custom button or manually, for example).

What are the txn_type and status in that IPN?

Also, what are the details for that IPN over at PayPal’s side? https://www.paypal.com/ie/cgi-bin/webscr?cmd=_display-ipns-history

I look forward to your update with those and any other details you could add, please.

Mitch · 15 March 2021 10:47

Hi Christian,

Thanks so much for the quick reply. I appreciate it, very much.

In answer to those questions. I am using Payflow Payments Pro, and all the subscriptions were created using s2 Member Pro-forms.

As I mentioned all payments are working, and new subscriptions are being set. The issues are only around cancellations, and some members cancellations are handled correctly, while some are not.

During a recent transfer of domains I manually updated the ‘custom’ meta tables for all users to reflect the new domain name, and updated my pro form shortcodes to reflect the change as well… but maybe there’s a clue there.

The IPN that results in the error has a txn_type = mp_cancel and the status = 1. Here’s the full IPN as it appears in the website log.

User-Agent: PayPal IPN ( https://www.paypal.com/ipn )
Array
(
    [txn_type] => mp_cancel
    [last_name] => ...
    [mp_currency] => CAD
    [residence_country] => CA
    [mp_status] => 1
    [mp_custom] => 
    [verify_sign] => AGXI4xCtkJvBtKII9WZ.J6fe94aOASRUhiYD9TSuJhj4c9OzTrDp92Vf
    [payer_status] => verified
    [payer_email] => calvin...@gmail.com
    [first_name] => Calvin
    [payer_id] => E5CDH99QBRDEC
    [reason_code] => mp_2002
    [mp_id] => B-4MG03229F3963141P
    [charset] => windows-1252
    [notify_version] => 3.9
    [mp_desc] => Discount: 25% off. (Now: $9.74 / monthly) ~ ORIGINALLY: 1...
    [ipn_track_id] => 8003db4732e49
    [s2member_log] => Array
        (
            [0] => IPN received on: Sat Mar 13, 2021 2:13:06 pm UTC
            [1] => s2Member POST vars verified through a POST back to PayPal.
            [2] => s2Member originating domain (`$_SERVER["HTTP_HOST"]`) validated.
            [3] => Ignoring this IPN request. The `txn_type/status` does NOT require any action on the part of s2Member.
        )

    [subscr_gateway] => paypal
    [custom] => harmonicatime.com
)

On the Paypal Side it looks like this:

txn_type=mp_cancel&last_name=...&mp_currency=CAD&residence_country=CA&mp_status=1&mp_custom=&verify_sign=AGXI4xCtkJvBtKII9WZ.J6fe94aOASRUhiYD9TSuJhj4c9OzTrDp92Vf&payer_status=verified&payer_email=calvin...@gmail.com&first_name=Calvin&payer_id=E5CDH99QBRDEC&reason_code=mp_2002&mp_id=B-4MG03229F3963141P&charset=windows-1252&notify_version=3.9&mp_desc=Discount: 25% off. (Now: $9.74 / monthly) ~ ORIGINALLY: 1...&ipn_track_id=8003db4732e49

Meanwhile this morning I had a cancellation from a member and the EOT was assigned to their signup date, so as soon as they cancelled they lost access. I know this has been happening frequently too but maybe another clue there for you!

Here’s than IPN:

User-Agent: s2Member v210208; https://harmonicatime.com
Array
(
    [txn_type] => subscr_cancel
    [subscr_id] => RP0000001137
    [custom] => harmonicatime.com
    [period1] => 0 D
    [period3] => 3 M
    [payer_email] => davide...@gmail.com
    [first_name] => Davide
    [last_name] => ...
    [option_name1] => Referencing Customer ID
    [option_selection1] => RP0000001137
    [option_name2] => Customer IP Address
    [option_selection2] => 172.58.227.155
    [item_name] => 1598797944:0 D:3 M~mitchgrainger.com~2:quarter,annually,billing,downloads,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,
    [item_number] => 2:quarter,annually,billing,downloads,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,
    [period] => 0 D
    [option_name] => Referencing Customer ID
    [option_selection] => RP0000001137
    [proxy_verified] => paypal
    [s2member_log] => Array
        (
            [0] => IPN received on: Sun Mar 14, 2021 10:17:25 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_cancel|recurring_payment_profile_cancel|mp_cancel` ).
            [4] => Auto-EOT Time for this account: Mon Aug 31, 2020 7:00 am UTC
            [5] => Cancellation Notification Emails have been processed.
        )

    [subscr_gateway] => paypal
    [subscr_baid] => RP0000001137
    [subscr_cid] => RP0000001137
    [level] => 2
    [ccaps] => quarter,annually,billing,downloads,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,
    [ip] => 172.58.227.155
    [s2member_paypal_proxy] => paypal
    [s2member_paypal_proxy_use] => pro-emails
    [s2member_paypal_proxy_verification] => d753460955bb44de42f41487b700edf0

I know that’s a lot. Hopefully this helps!?

The only other thought I had, is Payal updated the list of IP address they use to send IPN’s in December too. That’s above my head though…

Thanks again for your time on this!
Mg

clavaque · 15 March 2021 11:39

Thanks for the details! That’s very helpful.

These things jump at me first:

You’re using PayFlow Pro, but s2 isn’t supposed to have support for it. It does include the PayFlow credentials, but for the PayFlow Edition of PayPal Pro. https://s2member.com/kb-article/supported-paypal-account-types/

So it’s great that you manage to get payments at all, but it doesn’t surprise me that there’s at least a glitch like what you’re experiencing. I haven’t had a PayFlow Pro account to explore, but we can take a look with yours and see if we can make it work better.

I see that the first log has txn_type “mp_cancel”, and there must be something in the vars that s2 considers is not something to process. Could you show me the full IPN details from PayPal’s side? (screenshot of the details page, and copy the text in the box, pls)

The other one, though, is txn_type “subscr_cancel” and was processed.

With that one, though, the EOT seems to be off for some reason. Demotion was applied immediately because EOT time is in the past (Aug 31, 2020). When was the subscription created? I wonder if some variable in PayFlow Pro is named differently in a way that s2 can’t see when the last payment was and can only find the subscription creation time. It’s possible that because of the different API, s2 can’t connect to figure out that last payment time.

thesimarchitect · 16 March 2021 02:41

Hi! Just a quick observation, the users are still not demoted if their payment fails using regular PayPal as well (without Pro) and also on Stripe. They’re only demoted when their subscription is cancelled.

I have to set EOT manually very frequently (I use 25 hours to force the plugin to send a last warning to the user with a declined payment) because many users just don’t pay but they won’t cancel either, and I don’t want to cancel their subscription on PayPal because I want PayPal to continue trying to collect from them each 5 days.

I hope an implementation around that is somewhere in your “to do list” even if low on it

It would be nice if your plugin sent the user a message saying their payment was declined and that they have “x amount of time” to pay or they’ll lose access.

Sadly I am not savy enough to code it myself, but perhaps you could add this fix amongst other possible related functionality on a “payment recovery” addon for s2Member Next?

Mitch · 16 March 2021 18:34

Hi Christian,

Again, thanks so much for your time on this!

Firstly I apologize, I am using Paypal Payments Pro (Payflow Edition), not Payflow Pro standalone. I called paypal to confirm this today, as I was a little confused myself.

I’ve attached a screenshot of the details page for that IPN you requested.

And here’s the code in the box.

txn_type=mp_cancel&last_name=Monaghan&mp_currency=CAD&residence_country=CA&mp_status=1&mp_custom=&verify_sign=AGXI4xCtkJvBtKII9WZ.J6fe94aOASRUhiYD9TSuJhj4c9OzTrDp92Vf&payer_status=verified&payer_email=calvin...@gmail.com&first_name=Calvin&payer_id=E5CDH99QBRDEC&reason_code=mp_2002&mp_id=B-4MG03229F3963141P&charset=windows-1252&notify_version=3.9&mp_desc=Discount: 25% off. (Now: $9.74 / monthly) ~ ORIGINALLY: 1...&ipn_track_id=8003db4732e49

In reply to your question:

“With that one, though, the EOT seems to be off for some reason. Demotion was applied immediately because EOT time is in the past (Aug 31, 2020). When was the subscription created?”

August 31st 2020 was the subscription creation date!

This promoted me to do a deep dive today and I found after exporting all users using the s2Member basic exporter, that 95% of my members last payment time is either blank or showing their original signup date. Hopefully this is the big clue to resolve the problem?!

I then further tried to find any obvious differences between the few member profiles who operated correctly and those that did not (using an advanced export) but I could not find any consistencies on either side. Some users had signup-vars, some did not, some had activation codes, some did not… some used paypal, some cc.

Hopefully this all helps?

Please feel free to make any other requests of my time in getting to the bottom of this.

Once this issue is resolved, I’ll be a very happy man!
Mg

clavaque · 22 March 2021 19:26

Hi Mitch.

Thanks for clarifying that, and all the additional info.

Well, s2 does look out for mp_cancel events, as it mentions in the log entry for Davide. But Calvin’s is not acted upon, so my suspicion is that one of the other things s2 checks for, didn’t work out, causing the notification to be ignored…

In Calvin’s profile on your site, what PayPal ID does he have? Is that ID in the notification? And does his profile email match the paypal one?

Thanks!

clavaque · 22 March 2021 19:27

Yes, an account suspension option on failed payment attempts, is on my list.

thesimarchitect · 22 March 2021 20:16

Awesome!

I’ll continue to set their EOT to 25 hours until then.

And, while you’re at it, if possible, you can also implement a “reupgrade” in case the payment happens later on, but that part is optional, since the customers usually contact us when they pay for something and have no access to it, which is something that doesn’t happen the other way around

clavaque · 22 March 2021 21:43

I agree. Yeah, restoring the access when the payment is good, would also be nice.

thesimarchitect · 22 March 2021 22:01

Nice! If you do that, remember to keep the “previous” Payment IDs somewhere, since your plugin deletes the Payment ID when EOT arrives (it’s copied to the notes field, but I am not sure how easy would it be to use it, since many users have multiple payment IDs after they churned their subscriptions or had multiple delayed payments etc).

clavaque · 22 March 2021 22:26

Yes, I want to improve that too. I really don’t like losing the previous IDs, so it’s high on my list.

thesimarchitect · 23 March 2021 01:58

I changed that line of code that enables visualization and search on the “notes” field (How to Display & Enable Search for Administrative Notes Field), because I search for users by their PayPal ID multiple times a week and many of them are demoted already, for example, or had other IDs in the past etc.

But having a field like “Other Payment IDs” (I don’t call it previous because sometimes a user may be transitioning or have multiple payment IDs across multiple processors or on the same one) might be quite convenient.

Alternatively you could save Payment IDs (instead of a single one) in the Payment ID field, separating them with commas (or any other separator of your choice), but I feel you’d have a massive amount of code to rewrite, not sure it’s a great return from the effort.

Mitch · 23 March 2021 06:40

Hi Christian,

Thanks for the reply!

By looking at an advanced export file I see Calvin’s profile has;

A s2member_subscr_id of: RP0000001246

and a s2member_subscr_baid of: B-4MG03229F3963141P

In the notification we have: [payer_id] => E5CDH99QBRDEC

And [mp_id] => B-4MG03229F3963141P

His email is the same in both. Does that give any clues?

Also, would having a different custom value “harmonicatime.com” in his current profile cause this issue? As he signed up using a different custom value “mitchgrainger.com”.

Again all payments are being processed fine.

Looking forward to your reply!

Thanks again.
Mg

clavaque · 23 March 2021 22:39

Thanks for the new details!

Well, the custom value is important for s2, so it could be the reason, but I’m not so sure. You mentioned having updated that value, and you seem to have done it well enough, because your log entries say that it passed that validation.

[2] => s2Member originating domain ($_SERVER[“HTTP_HOST”]) validated.

Did both of those subscriptions have the custom value updated, or only one? The subscriptions that don’t have the cancellation problem we’re talking about, were all after the new domain, or did you update some of those custom values too and didn’t have a cancellation problem there?

I see that the subscr_baid and mp_id match. I’ll look closer at the code that tries to find the user for that IPN, to see if that combination is tried too.

Mitch · 24 March 2021 13:14

Right, come to think of it, the custom value has been updated on all profiles, so that can not be the problem.

There is also the fact that the last payment time on all the profiles with the problem was not being updated by s2Member. I found a direct correlation and this was happening at the old website too.

If you can tell me why some members profiles are updated with a last payment date and some not? then I think that might solve it.

Let me know if you need anything else checked on this end?

Thanks again Christian, I really appreciate it!

Mitch · 10 June 2021 09:00

Hi Christian,

This problem is still persisting. And now, this week when a user cancells the API seems to be handled correctly, and an EOT updated according to he log, yet the member is demoted immediately.

I had to go in and manually restore the account and update it to have an EOT of October 3rd.

Have you any clues?

Here’s a log entry:

LOG ENTRY: Tue Jun 8th, 2021 @ precisely 9:37 pm UTC
PHP v7.3.28 :: WordPress v5.7.2 :: s2Member v210208 :: s2Member Pro v210208
Memory 13.27 MB :: Real Memory 14.00 MB :: Peak Memory 13.61 MB :: Real Peak Memory 16.00 MB
harmonicatime.com/?s2member_paypal_notify=1
User-Agent: s2Member v210208; https://harmonicatime.com
Array
(
[txn_type] => subscr_cancel
[subscr_id] => RP0000001208
[custom] => harmonicatime.com
[period1] => 0 D
[period3] => 1 M
[payer_email] => cjrvan@msn.com
[first_name] => Charles
[last_name] => Vanvleet
[option_name1] => Referencing Customer ID
[option_selection1] => RP0000001208
[option_name2] => Customer IP Address
[option_selection2] => 107.2.177.63
[item_name] => 1601618188:0 D:1 M~mitchgrainger.com~2:month,annually,billing,downloads,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22
[item_number] => 2:month,annually,billing,downloads,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22
[period] => 0 D
[option_name] => Referencing Customer ID
[option_selection] => RP0000001208
[proxy_verified] => paypal
[s2member_log] => Array
(
[0] => IPN received on: Tue Jun 8, 2021 9:37:49 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_cancel|recurring_payment_profile_cancel|mp_cancel ).
[4] => Auto-EOT Time for this account: Sat Oct 3, 2020 7:00 am UTC
[5] => Cancellation Notification Emails have been processed.
)

[subscr_gateway] => paypal
[subscr_baid] => RP0000001208
[subscr_cid] => RP0000001208
[level] => 2
[ccaps] => month,annually,billing,downloads,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22
[ip] => 107.2.177.63
[s2member_paypal_proxy] => paypal
[s2member_paypal_proxy_use] => pro-emails
[s2member_paypal_proxy_verification] => d753460955bb44de42f41487b700edf0

)

Mitch · 21 June 2021 08:38

Hi Christian,

I realize you must be busy and can’t possibly help everyone on here. Can you recommend any freelance developers that could help trouble shoot this?

I am on O desk, but it would be good to know someone you recommend.