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

Set recur contribution status to failed if a payment failed #215

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

michaelmcandrew
Copy link
Contributor

When a payment processor cannot take a payment, we set the new contribution to failed but do not update the recurring contribution.

This patch sets the recurring contribution to failed.

We are in the process of testing this with a client. Will report back here when we have some feedback on whether this approach works.

@civibot civibot bot added the master label Nov 9, 2021
@michaelmcandrew michaelmcandrew force-pushed the set-rc-status-to-failed-on-failure branch from 4da2474 to d58ac93 Compare November 9, 2021 15:07
@eileenmcnaughton
Copy link
Owner

@michaelmcandrew I think there is an intent that 'Failed' will be after x attempts (probably 3)- there is also a 'failing' status I think for the interim period

@michaelmcandrew
Copy link
Contributor Author

This isn't a definitive answer - more of a conversation 😄.

I agree that this could be a good approach and. We did talk about it but decided against it, at least for now because:

  • We didn't really want to implement any complex retrying logic because we wanted to keep things simple - at least to start. And we weighed up the added complexity against the potential benefits. If it doesn't work today, what are the chances that it will work in the next few days? Is it worth the extra chance that we could muck things up. We decided that it would be simpler / safer to just mark it as failed and requires admin attention for now.

  • We are not sure if there is a single right approach for all payment processors / all omnipay payment processors. I think that different payment processors probably need and want to do different things here. I would like to be able to muck around with paypal without thinking that I was going to muck up other payment processor code. One approach would be to create a different processrecurring job for paypal.

  • I am not sure what CiviCRM would consider the right thing to do is - you have also used the word think and probably a couple of times :) Is it documented? Should we try and document it?

  • Finally, a devil's advocate question. What is this shared extension bringing to the party? Shouldn't all shared code be in core payment processor extensions should just concentrate on providing the edge cases for their payment processing?

@mattwire
Copy link
Contributor

@michaelmcandrew I like the workflow/cycle published by @artfulrobot for GoCardless here: https://docs.civicrm.org/gocardless/en/latest/reference/technical/ - Stripe partially implements that lifecycle currently but the intention is to fully implement.

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

Successfully merging this pull request may close these issues.

None yet

3 participants