search

artfulrobot / uk.artfulrobot.civicrm.gocardless

A CiviCRM extension providing GoCardless integration to handle UK Direct Debits.
GNU Affero General Public License v3.0
5 stars 18 forks source link

Membership not updated if there are multiple recurring contributions #88

Closed wmortada closed 3 years ago

wmortada commented 3 years ago

If a member signs up by direct debit more than once it is only the last sign up that is linked to the membership (i.e. the last recurring contribution ID is recorded on the membership record). This can cause a problem if it was the older direct debit that is active because it is no longer linked to the membership. If a payment comes through for this recurring contribution it doesn't update the membership because the extension looks for a membership with a matching recurring contribution ID and there isn't one. This can happen for example if a member signs up twice - the first time completing the process but the second time starting the process but not completing it (the second recurring contribution is created at the point they click confirm on the CiviCRM contribution page so they don't need to type in their bank details in GoCardless for this to be an issue). Obviously this isn't rational behaviour and most of our members don't do this but there are a few that have done this for whatever reason - perhaps they forgot they'd already set up a direct debit or perhaps they received a renewal reminder by mistake.

It's this bit of code that is responsible for this behaviour: https://github.com/artfulrobot/uk.artfulrobot.civicrm.gocardless/blob/master/CRM/GoCardless/Page/Webhook.php#L317-L326

If there was another way of getting the membership ID that might help to fix this issue for this extension. I'm guessing it may be an issue for other payment processors too though. It is a bit of a limitation that CiviCRM only allows one recurring contribution per membership. Ideally it should allow multiple recurring contributions I think - which would mean a change to core.

wmortada commented 3 years ago

Good to get your thoughts on this @mattwire

artfulrobot commented 3 years ago

I can see the problem though: the membership is linked to the ContribRecur before the ContribRecur gets properly set-up (before it is "In Progress").

I think that is a core issue: it's not this processor that creates the records or links them to the memberships.

I can't think when you'd want multiple subscriptions paying for one membership - it doesn't seem too much of a limitation to me - although if it did have that feature then this issue would be mitigated because the incomplete CRs would just sit there, it's an awkward case.

wmortada commented 3 years ago

Yes, I was thinking it is probably a core issue. And no, I can't think of a situation where you would want multiple active subscriptions paying for the same membership. But we do have quite a few instances where there are multiple subscriptions/recurring contributions linked to the same membership. Typically only one of them is active and the rest are inactive - i.e. someone has set up one direct debit cancelled it then set up another one. This is fine if the last direct debit is active (which is the usual case) but a problem if the last direct debit is the inactive one.

artfulrobot commented 3 years ago

yeah makes sense.

Do you want to close this as it's a core issue?

wmortada commented 3 years ago

Yes, okay. I'll raise it in core.

wmortada commented 3 years ago

See https://lab.civicrm.org/dev/core/-/issues/1907