Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Failure Threshold revert to normal non auto-renew contribution/membership #462

Open
shaneonabike opened this issue Aug 29, 2024 · 7 comments

Comments

@shaneonabike
Copy link
Contributor

Overview

So I have an organization I work with that has a need that I think is a possible enhancement, but I think I need some guidance on how to go about doing it.

Essentially, the idea is that instead of simply pushing the contribution to the next year (after X failures) we actually cancel the auto-renewal of their contribution. For memberships this is pretty ideal, because in most organizations that I work for this means access to specific privileges and other things. So when people login they clearly see that they need to renew.

Present situation

  1. User sets up auto-renew on membership
  2. Their CC expires and they get a new one (forgetting to update their account)
  3. The payment goes through X times and fails
  4. The membership auto-renewal gets bumped to the following year to retry
  5. Workers need to fix memberships which are bumped up, contact members, and reprocess everything

Suggested solution

  • Provide a means that would allow the cancellation of the auto-renewal contribution after the threshold instead of pushing it up to the next year as it does
  • Document that it is advised to send emails of failed transactions to their members so that they are aware of what is happening

Thoughts?

cc @adixon

@adixon
Copy link
Contributor

adixon commented Aug 29, 2024

I think there's already a feature to send emails of failed transactions to the cardholder (or at least a discussion and/or PR, it sounds familiar).

Re: auto cancellation, I'm not clear about the problem you're trying to solve here.

Agreed that the current behaviour of 3 attempts and then pushing to the next date was designed as a fallback behaviour for contributions, not memberships. Maybe an alternative is provide an option to "suspend" the recurring contribution after three failures? Or is that what you're proposing? Actually cancelling seems like the wrong thing to do, that feels like something that should be done by an actual person to confirm it.

@adixon
Copy link
Contributor

adixon commented Aug 29, 2024

Take a look at the UI configuration option "Email receipt for a Contribution if Recurring payment fails - with error message", I think that would be what you want to do to alert a custom that their cc has failed.

@shaneonabike
Copy link
Contributor Author

I think there's already a feature to send emails of failed transactions to the cardholder (or at least a discussion and/or PR, it sounds familiar).

You bet it does! I was mainly saying that we should document somewhere that this is done if we implement my solution.

Auto cancellation

I probably used the wrong terminology here. I meant that we essentially stop attempting to process the contribution and don't push the next date to the next year. So a suspend is a great idea. I would imagine that in that case we could do a few things

  • Display a message on the appropriate Contribution page to indicate why it was suspended
  • Allow a person to recomplete the Contribution page with their new details

@shaneonabike
Copy link
Contributor Author

shaneonabike commented Aug 29, 2024

.. and just to be totally clear I think you can leave how it works presently because maybe people would like that, but I am proposing to add a new option that says something like

```After the failure threshold has been reached suspend the contribution from further being processed````

and then in the help text it would read

It is recommended that you send a Email receipted to the people who have setup auto-renewal upon failure as this option will simply stop processing after the threshold is reached.

Hopefully, that's a bit clearer what I'm trying to get at... and I don't know if you think it's easy and/or logical. Or even better we simply send a small email via a template indicating that their contribution has been suspended due to the threshold being reached which is probably even better!

@adixon
Copy link
Contributor

adixon commented Aug 29, 2024

Yup, PR welcome to provide a new configuration re: behaviour after threshold failures.

If you're doing annual auto-renewals of membership AND recurring monthly donations, it might make sense to have different settings, but that would also be complicated, so let's start with a single setting that applies across the board.

@shaneonabike
Copy link
Contributor Author

Happy to do this. Can you give me some pointers though on the suspend portion. I see you check for the threshold (here)[https://github.com/iATSPayments/com.iatspayments.civicrm/blob/5dcc8715ac316e5c8cf48d9c2598e36b45d34cdc/CRM/Iats/Transaction.php#L119]

But I'm a bit lost as to what is happening after that (if it fails say after 3). I see you are creating a ContributionRecur if we have a failure. I guess I can assume that basically when it fails the existing one never gets processed again so it creates a new ContributionRecur to process the next one right?

In our case, if the threshold was reached I could technically update the existing to Suspend ?

cc @adixon

@adixon
Copy link
Contributor

adixon commented Aug 29, 2024

No, I think you're misunderstanding the code. The 'creation' of a ContributionRecur is actually just updating the existing one, I'm not creating any new schedules.

The behaviour if it's over the threshold is defined by this comment:

// otherwise, we'll keep the next collection date as passed in from the caller

So instead we need to test your new configuration switch, and if we're only suspending, then we also push the next contribution back and set the status to 'pending'.

The thing to know at this stage of the code is that, for "bulletproof" reasons, the recurring contribution has already been updated on the assumption that the recurring contribution succeeded (to avoid recharging a schedule where the payment goes through but that information doesn't get recorded in civi, for a variety of possible reasons). So we're updating that recurring schedule to handle cases where that's not true.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants