Skip to content

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.

@eileenmcnaughton eileenmcnaughton force-pushed the master branch 3 times, most recently from 8f31154 to 679df0f Compare December 21, 2023 19:43
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.

3 participants