It's cancelling immediately instead of next payment date.

[rnikoley]

It looks like you did a recent update to the add-on. 8/17?

Well, since then, all my cancellations are immediate, not on next payment date.

So, whereas before, it would retain the membership level and set expiration of membership at next payment date, in the last 3 cancellations, when I check, it's setting membership level to NONE and NO expiration date, so I have to fix manually.

So, basically, it looks like it's behaving as though the add-on isn't even installed.

[mircobabini]

Hey @rnikoley thanks for let us know.

Can you please share some details of your setup?

• active gateways
• pmpro version

Thanks!

[buzz0]

I am seeing this exact issue as well.

• Active Gateway: Stripe
• PMPro version 2.9.1 I also have WP Fusion installed, so I can give you a little more information about what's showing up in the logs.

The first user I am noticing an issue with this actually looks like it occurred on June 27. (Since this is a couple of months ago, I am going based on WPF logs and I can't guarantee that this is related.) On March 23, a batch process set the PMP expiration date to 1/1/1971 (a continuing subscription). The user had a PMPro start date of 7/21/21, and we would expect their expiration date to be set to 7/21/22 if they cancelled early. On June 27, the WPF log says "User left Paid Memberships Pro level [xxxx]" WPF immediately removed the tag associated with the membership, added a tag "former member," and then pushed the membership level 0, expiration date blank, and status inactive to our CRM. The first line showing an problem was the user leaving the PMP level upon cancellation (as opposed to being marked as pending cancellation).

Next user: start date 8/11/21 cancel date: 7/13/22 -> WPF logs show expiration date set to 8/11/22 as expected nothing is shown in the logs on 8/11/22 the site owner had to go into the user's account and manually cancel them 8/23 because the plugin did not set them to cancelled on the expiration date.

When a user expires (probably due to an inactive credit card), the expiration date and tags are correctly managed and the user has access until their next payment date. (Presumably this does not use the PMP cancel on next payment date plugin.)

[buzz0]

I should have specified that we last updated all plugins on 8/11. Paid Memberships Pro - Cancel on Next Payment Date You have version 0.4 installed.

[mircobabini]

When a user expires (probably due to an inactive credit card), the expiration date and tags are correctly managed and the user has access until their next payment date. (Presumably this does not use the PMP cancel on next payment date plugin.)

Correct. This is not CONPD related.

cancel date: 7/13/22 -> WPF logs show expiration date set to 8/11/22 as expected

This is what CONPD does. Setting the expiration date of the membership to a certain date on cancellation. That's it.

the site owner had to go into the user's account and manually cancel them 8/23 because the plugin did not set them to cancelled on the expiration date.

If CONPD was able to set the expiration date correctly but the membership is still not expiring (then you can see the cancellation date in the past), you should check your cron jobs.

If would suggest to:

• ensure you are on PMPro latest version
• ensure you are on CONPD latest version which is 0.5.1
• check the Tools > Site Health to see if there's something weird to be checked

If you need a deeper investigation on you setup, just open a ticket via https://www.paidmembershipspro.com/new-topic/ Otherwise, if you still think there might be a bug around, let me know.

[buzz0]

Thanks, I will check the cron jobs. However, the most common error that we are seeing when cross-referencing the WPF logs to retrace the errors is that the user clicks to cancel their membership and the membership is instantly cancelled, instead of cancelled on their next payment date.

Here's a sample WP Fusion log file, issue time stamped 8/19:

And another, issue time stamped 6/27:

You can see in both of these screenshots that the system cancelled the membership as soon as the user clicked the cancel button. In the first screenshot you can see the odd behavior that after the user cancelled and was removed from the membership and updated as "not a member" in our CRM (via WP Fusion), then CONPD updated the expiration date to the expected payment date. I haven't looked at the code, but could it be a threading problem, possibly? That might account for why usually the membership is immediately cancelled but sometimes it is handled correctly and occasionally it is cancelled first and then the expiration date is updated afterward.

I don't see anything useful in the error logs.

We are scheduling a site code update to see if it addresses the problem, but for our site this issue predated the 8/17 CONPD plugin date reported in the original post, and I thought that might be useful debugging info at your end.

[mircobabini]

Thanks for sharing. This seems to be an issue with WP Fusion and it might be related to this:

https://github.com/strangerstudios/pmpro-cancel-on-next-payment-date/blob/dev/pmpro-cancel-on-next-payment-date.php#L162-L190

It seems pretty solid. It does add a row into the table with the same level the user had before the cancellation (so nothing is really changing but adding and enddate). Also, this filter is returning the same identical $level the user had before the cancellation request so, once again, nothing is really changing.

The behaviour you are reporting btw existed in the past (CONPD 0.3) because at that time we were changing the level for a small amount of time. Check this one: https://github.com/strangerstudios/pmpro-cancel-on-next-payment-date/commit/2d630c70c3984627196990875423c3bf695f5878

From 0.4+ it should be fixed but still: I'd try to update to the latest CONPD.

[buzz0]

Can you clarify what indicates that it's a WPF issue? (other than the fact that I'm using the WPF logs to document the issue, I mean)

Here's someone who cancelled earlier today:

Here's the corresponding row in the wp_pmpro_memberships_users table:

I can see that the WPF logs (status, expiration date) don't match the wp_pmpro_memberships_users data, and I'll follow up with them about that. But the enddate (which would be the CONPD's responsibility, and shouldn't ever be written by WPF, just read) is set to the timestamp that the cancellation happened, not to the next payment date, which would have been 10/7/22. That seems like it should only be a figment of PMPro and/or CONPD, right? Or am I missing something looking at the logs and data?

[rnikoley]

Thanks for sharing. This seems to be an issue with WP Fusion and it might be related to this:

https://github.com/strangerstudios/pmpro-cancel-on-next-payment-date/blob/dev/pmpro-cancel-on-next-payment-date.php#L162-L190

It seems pretty solid. It does add a row into the table with the same level the user had before the cancellation (so nothing is really changing but adding and enddate). Also, this filter is returning the same identical $level the user had before the cancellation request so, once again, nothing is really changing.

The behaviour you are reporting btw existed in the past (CONPD 0.3) because at that time we were changing the level for a small amount of time. Check this one: 2d630c7

From 0.4+ it should be fixed but still: I'd try to update to the latest CONPD.

To clarify, I'm the one who raised the issue, but I do not have WP Fusion.

[buzz0]

Yes, I'm sorry to obfuscate the issue-- I thought that the additional WPF log information would help clarify what was happening in out instance of the same behavior. (I often use it to debug issues with other plugins because it's a good log of events when other plugins aren't logging potential bugs and the error log isn't showing anything useful.) In our case, we were able to identify at least one incident of the bug before the most recent update that you installed, and I thought that that information might also be useful in isolating the cause. I have raised an official support ticket, and I will follow up via that.

[buzz0]

Also, thanks for raising this issue! It's always good to find that you're not the first person to identify a bug and that someone else has seen the same behavior.

To clarify, I'm the one who raised the issue, but I do not have WP Fusion.

[mircobabini]

Thanks for sharing all these informations!

Dealing with old versions of core + addons is not always easy. This one is not an easy case, because of the way the cancellations can be raised and handled. It's not just one single flow.

Also, we changed things in the past and it also depends on the full stack of addons that you have installed + custom code.

Raising a ticket on site is a great way to share the Site Health data + the full stack you have installed. This way, the team is able to make a proper investigation which is what you are looking for.

@buzz0 Can you clarify what indicates that it's a WPF issue?

Not saying that. I say that sometimes these loggers are logging exactly what's going on under the hood, which is not always what you see at the end (because of the implementation strategy applied which can be a bit tricky sometimes).

I would ask you to update PMPro to the latest and CONPD to 0.5.1 which is the latest as today.

Doing this we gonna have fresh updated logs from now on to investigate over.

@buzz0 Also note that in the first WPF screenshot you shared there's a row which says "User clicked cancel and...". In the other screenshots/cases that row is missing. Which probably means that it's a cancellation from the gateway OR a billing failure.

Cancellations on site

There's an open issue somewhere which shows that if a user double clicks on the cancel button in the cancel confirmation page, the membership got immediately cancelled instead of set an enddate. This might be the case with the older issue you faced.

Cancellations from the gateway

There are no known issues with webhook processing with Stripe, let me know if you are on a different gateway though.

Failures from the gateway

This is the part which is not always handled the same way. Before 0.5+ sometimes we were NOT cancelling immediately on billing failure. From 0.5+ the cancellation is immediate if there's a billing failure on the gateway (with PPE + Stripe). Let me know if you use a different gateway.

Other addons/snippets

1. This addon can change the behaviour: https://www.paidmembershipspro.com/add-ons/failed-payment-limit/. Let us know if you have it installed.

2. This snippet can change the behaviour: https://gist.github.com/mircobabini/950523ae1efc594a34bf931445ecdde5. Let us know if you have it installed.

Summary

@rnikoley and @buzz0: thanks for raising the issue and for sharing all the informations. As you can see this is not an easy investigation and at the moment we are not able to replicate the issues you are facing. Thanks again for raising a ticket on site and if you can update PMPro + CONPD, do it. It would be useful and makes the investigation easier and faster.

@rnikoley Can you please share some more informations about your stack?

• active gateways
• PMPro version
• any other addon which deals with expiration dates or anything which can be related

Thanks.

[rnikoley]

@mircobabini:

Active gateway is Stripe. Zero problems and I verify every cancellation.

PMPro 2.9.2

CONPD 0.5.1

Other add-ons:

Add Name to Checkout Advanced Levels Page Shortcode Member Directory Nav Menus

Pretty thin install, simple to operate. Love it.

Richard Nikoley @.*** https://freetheanimal.com

On Aug 25, 2022, at 12:17 PM, Mirco Babini @.***> wrote:

Thanks for sharing all these informations!

Dealing with old versions of core + addons is not always easy. This one is not an easy case, because of the way the cancellations can be raised and handled. It's not just one single flow.

Also, we changed things in the past and it also depends on the full stack of addons that you have installed + custom code.

Raising a ticket on site is a great way to share the Site Health data + the full stack you have installed. This way, the team is able to make a proper investigation which is what you are looking for.

@buzz0 https://github.com/buzz0 Can you clarify what indicates that it's a WPF issue?

Not saying that. I say that sometimes these loggers are logging exactly what's going on under the hood, which is not always what you see at the end (because of the implementation strategy applied which can be a bit tricky sometimes).

I would ask you to update PMPro to the latest and CONPD to 0.5.1 which is the latest as today.

Doing this we gonna have fresh updated logs from now on to investigate over.

@buzz0 https://github.com/buzz0 Also note that in the first WPF screenshot you shared there's a row which says "User clicked cancel and...". In the other screenshots/cases that row is missing. Which probably means that it's a cancellation from the gateway OR a billing failure.

Cancellations on site

There's an open issue somewhere which shows that if a user double clicks on the cancel button in the cancel confirmation page, the membership got immediately cancelled instead of set an enddate. This might be the case with the older issue you faced.

Cancellations from the gateway

There are no known issues with webhook processing with Stripe, let me know if you are on a different gateway though.

Failures from the gateway

This is the part which is not always handled the same way. Before 0.5+ sometimes we were NOT cancelling immediately on billing failure. From 0.5+ the cancellation is immediate if there's a billing failure on the gateway (with PPE + Stripe). Let me know if you use a different gateway.

Other addons/snippets

This addon can change the behaviour: https://www.paidmembershipspro.com/add-ons/failed-payment-limit/ https://www.paidmembershipspro.com/add-ons/failed-payment-limit/. Let us know if you have it installed.

This snippet can change the behaviour: https://gist.github.com/mircobabini/950523ae1efc594a34bf931445ecdde5 https://gist.github.com/mircobabini/950523ae1efc594a34bf931445ecdde5. Let us know if you have it installed.

Summary

@rnikoley https://github.com/rnikoley and @buzz0 https://github.com/buzz0: thanks for raising the issue and for sharing all the informations. As you can see this is not an easy investigation and at the moment we are not able to replicate the issues you are facing. Thanks again for raising a ticket on site and if you can update PMPro + CONPD, do it. It would be useful and makes the investigation easier and faster.

@rnikoley https://github.com/rnikoley Can you please share some more informations about your stack?

active gateways PMPro version any other addon which deals with expiration dates or anything which can be related Thanks.

— Reply to this email directly, view it on GitHub https://github.com/strangerstudios/pmpro-cancel-on-next-payment-date/issues/43#issuecomment-1226786405, or unsubscribe https://github.com/notifications/unsubscribe-auth/A2UJ335NJODOZNYIKABWWHTV236WBANCNFSM57F2CLRQ. You are receiving this because you were mentioned.

[mircobabini]

@rnikoley thanks for your answer.

You say "zero problems" with Stripe --- except for this one, right?

In your setup you consistently (100%?) have that on cancel the membership is immediately cancelled instead of setting a future enddate, right?

Just to be sure we are on the same page here.

[rnikoley]

" except for this one, right?”

No, not a Stripe issue. It is cancelling at the gateway for all future invoices immediately, as it should.

The problem is that PMP pro is cancelling the membership immediately instead of setting an expiration date when the next payment should be.

In other words, while Stripe is properly ensuring there will be no future payment charge, PMP is not keeping the membership active for the subscription period the member has already paid for.

Same page?

On Aug 26, 2022, at 5:52 PM, Mirco Babini @.***> wrote:

@rnikoley https://github.com/rnikoley thanks for your answer.

You say "zero problems" with Stripe --- except for this one, right?

In your setup you consistently (100%?) have that on cancel the membership is immediately cancelled instead of setting a future enddate, right?

Just to be sure we are on the same page here.

— Reply to this email directly, view it on GitHub https://github.com/strangerstudios/pmpro-cancel-on-next-payment-date/issues/43#issuecomment-1228349145, or unsubscribe https://github.com/notifications/unsubscribe-auth/A2UJ33YBMXDECPFE3FD7B5DV3COWPANCNFSM57F2CLRQ. You are receiving this because you were mentioned.

[buzz0]

Thanks. I updated the site the evening after posting to this thread, and we are now watching the site to see if we notice more issues of this sort. We are in the fortunate condition of having few cancellations, so it takes a while to determine if/how something is broken, especially when it's working sometimes and not other times. Test subscriptions went through and cancelled correctly, but we haven't had issues with test data in the past, either, so that's not conclusive.

We don't currently run either of the Failed Payments code that you linked to, though our site is much "heavier" than @mircobabini 's site. (In fact, one of the reasons that it had been several weeks since updating the plugins is that the last time we updated, there was a conflict between some PMPro refactoring and the PMPro Zapier plugin that took us a while to notice and clear, and it made us more cautious about running updates at times when we could run full test rounds immediately after.) In related news, I see that there's another PMPro update out in the last day or so and we haven't yet managed to schedule an update/test round for that yet, so we're (again) not running fully updated.

I especially appreciate the information about the "click cancel twice" bug, since that one would be almost impossible for us to know without watching our users as they do a cancellation.

[mircobabini]

@rnikoley thanks, same page sure. Still can't replicate though!

@buzz0 thanks. 2.9+ is enough, thanks.

Well, this is the code to avoid "click cancel twice" which can be the root of all the issues here.

https://github.com/strangerstudios/paid-memberships-pro/pull/2216/commits/9d9597ac50aebf2e5ed6fd8aa262fcc8f53c37c5

If you want to try to patch you code, it's a one liner. Let's see how it goes.

[rnikoley]

Happy to report that I just received a cancellation (I don't get many) and it was done correctly this time, keeping the membership level intact and setting an expiration date for when the next payment would be made. It was also cancelled at the gateway (Stripe).

[mircobabini]

Thanks @rnikoley. This is after applying the patch posted above?

[rnikoley]

@mircobabini "This is after applying the patch posted above?"

Just whatever plugin updates, if that’s what you mean by patch.

...I hope I didn't speak too soon though, because now another issue has arisen (maybe). Could be a gateway hiccough, but I noticed when logging into Stripe this morning that there was a failed payment yesterday, but I got no email notification. The FluentSMTP log shows nothing, meaning it either failed at the gateway (though no indication from Stripe's logs) or it failed at PMPro.

So, just an alert to keep an eye out for it.

[rnikoley]

Just whatever plugin updates, if that’s what you mean by patch.

Richard Nikoley @.*** https://freetheanimal.com

On Aug 28, 2022, at 8:44 PM, Mirco Babini @.***> wrote:

Thanks @rnikoley https://github.com/rnikoley. This is after applying the patch posted above?

— Reply to this email directly, view it on GitHub https://github.com/strangerstudios/pmpro-cancel-on-next-payment-date/issues/43#issuecomment-1229460127, or unsubscribe https://github.com/notifications/unsubscribe-auth/A2UJ332VNKIFZ42CVOWZYDTV3NULDANCNFSM57F2CLRQ. You are receiving this because you were mentioned.

[rnikoley]

PMpro 2.9.2

Cancel on next payment date, 0.5

Don’t know what you mean by active gateways. Nothing has changed on my end. I’m on a 3BB internet router/wifi, just like always. Cancel next payment date was working fine until last 3 cancelations, which were in the last couple of days.

Richard Nikoley @.*** https://freetheanimal.com

On Aug 22, 2022, at 12:31 PM, Mirco Babini @.***> wrote:

Hey @rnikoley https://github.com/rnikoley thanks for let us know.

Can you please share some details of your setup?

active gateways pmpro version Thanks!

— Reply to this email directly, view it on GitHub https://github.com/strangerstudios/pmpro-cancel-on-next-payment-date/issues/43#issuecomment-1221851969, or unsubscribe https://github.com/notifications/unsubscribe-auth/A2UJ33YWD6A5TBRUMB7FE2TV2MGD7ANCNFSM57F2CLRQ. You are receiving this because you were mentioned.

[RKWO]

We are having a similar issue with this add-on, and we've narrowed it down to the theme we're using.

The theme is bespoke, and there is zero indication or error to say why this would not work as normal. There isn't even any custom template for PMPro being used for these steps.

Is this still a known bug @mircobabini or has it been settled?

[rnikoley]

This is old and I’ve not had any continuing issues for a long time.

-- Richard Nikoley @.*** https://FreeTheAnimal.com https://YouTube.com/c/RichardNikoley https://Twitter.com/rnikoley

On 30 Jun 2023, at 07:54, RKWO @.***> wrote:

We are having a similar issue with this add-on, and we've narrowed it down to the theme we're using.

The theme is bespoke, and there is zero indication or error to say why this would not work as normal. There isn't even any custom template for PMPro being used for these steps.

Is this still a known bug @mircobabini https://github.com/mircobabini or has it been settled?

— Reply to this email directly, view it on GitHub https://github.com/strangerstudios/pmpro-cancel-on-next-payment-date/issues/43#issuecomment-1613969966, or unsubscribe https://github.com/notifications/unsubscribe-auth/A2UJ33YDTOVPGHGKWJEZC2TXNYPTVANCNFSM57F2CLRQ. You are receiving this because you were mentioned.

[jawzz47]

I just encountered this issue with a Paypal payment. The user's subscription was annual starting on June 7 of last year and he just (mistakenly) canceled his recurring payment. He ended up being cancelled at our website. I'm using the plugin explicitly to avoid this kind of problem.

[mircobabini]

I don't really think the plugin is buggy in that part. I think this is because the user clicked twice on the "cancel" button. And yes, this is a known issue which sometimes can happen (double click => double cancel. First cancel set the expire date, second cancel request completely cancel the membership).

Since this addon will be merged into core soon (with a different logic, not affected by that bug described above), I would suggest to just fix that membership manually and wait for updates.