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

Support non-recurring contributions #12

Open wpf500 opened 7 years ago

wpf500 commented 7 years ago

I've done some testing with memberships around when ContributionRecur records exist, and it seems that its only when the membership is set to auto-renew, as @artfulrobot suggested.

The plugin currently creates GoCardless subscriptions and not payments (which are one off), so does not support non-recurring contributions. I'm hoping I can get that functionality working at some point, but for now, just leaving this issue here as a reference. Just in case anyone is worried, any non-recurring contributions won't get silently turned into recurring ones, the plugin just throws an exception.

artfulrobot commented 7 years ago

Yes, I confirm this is the case. For completeness' sake it would be good to get this functionality working. For the sake of comment: having used GC for one-offs with a client with a good number of supporters for a while we've abandoned it based on supporter feedback: people feel it's weird to give bank details and feel safer giving card details for one-off payments.

petednz commented 5 years ago

wondering if it would be worth having a warning come on screen if you save the admin-facing form Contribution page 'Amounts' tab that has GoCardless selected but does not have 'recurring' enabled, to avoid creating a page that then fails, and/or having the public form set so that if someone does not select 'recurring' then the GoCardless option does not show.

artfulrobot commented 5 years ago

@petednz sounds good.

The warning on admin screen makes sense.

Altering contribution page sounds like it could have side effects; it would need to also check if any other payment processors were in use before force-checking the regular box.

petednz commented 5 years ago

thx. perhaps my second point wasn't clear - i didn't mean to suggest that the recur box be force checked - but the reverse, ie if recur is not checked then GoCardless is not shown as an option for payment

artfulrobot commented 5 years ago

Yep that makes sense technically. What happens when there is only gc payment processor/no choice?

Although I think it's a poor UX for users in the cases when the form is specifically for recurring payments and the user is expected to remember to tick that box. (Obviously it's just as a bad if they accidentally don't and it crashes ugly!)

And from a supporter development/fundraising pov better to make regular payments easier rather than adding more barriers, so I think "if gc selected, or gc only processor, force regular". But then people might change back to another processor and forget to un-tick the box. So maybe it should also show an alert to explain itself.

But then I've not seen a decent contribution form that doesn't have some custom code on it somewhere. And in that case people can do what they like. I'm not sure how useful it would be to add this at this level. It feels out of scope. CiviCRM should make nicer contribution forms, perhaps it's not the place of a payment processor to do that?

Hmmm. 🤔

petednz commented 5 years ago

key reason for raising this is client reporting that a page that had GC on it was delivering Failed contributions. reason? because it page was not set for 'recur' - hence suggestion a/ that we notify admin if they try saving such a Contribution page.

next issue though is that even if recur checkbox is available, it doesn't avoid user going ahead and selecting GC - hence wanting to hide GC as an option if recur is not selected by user, or required by admin

artfulrobot commented 5 years ago

Yeah, that's ugly.

The admin thing seems v sensible to me.

The other hack might be a necessary evil because of the limitations of core.

Ironically if single payments were implemented this issue would not exist but things would still be going wrong.(single payment when you wanted recurring)

If someone wants to do a PR please go ahead. If anyone has funding for me to work on this phrase hey in touch.

Thanks

petednz commented 5 years ago

have added to our list fz-16765

artfulrobot commented 4 years ago

Hey @petednz I don't know what "fz-16765" is, but if it happened, a PR for this would be welcome. It regularly trips people up

petednz commented 4 years ago

that is our internal ticket system - no i don't see we did anything on this. Other notes i see on our ticket are

sorry. not being of much help

artfulrobot commented 4 years ago

No, that is helpful, thanks.

a-sassmannshausen commented 4 years ago

Hey @artfulrobot,

I have a client who uses one-off contributions through GoCardless at the moment and are loath to switch to using a payment processing system that does not support this. So we are interested in this feature.

Do you have an idea for how much work this would entail or how much funding you'd be looking for? Has anyone else stepped forward to fund this?

Cheers,

Alex

artfulrobot commented 4 years ago

@a-sassmannshausen from time to time someone says they're interested, but they seem to drift off!

I think it would take about 14 hours to get one offs working in the way that each donation is a new mandate. It's complex because the process is

  1. take mandate in usual way
  2. take payment from mandate (instead of setting up subscription)
  3. (thank user)
  4. webhook listens for payment confirmed, finds contribution, records Completed payment which in turn marks the Contribution as Completed.
  5. webhook listens for payment failed/cancelled, updates Contribution
  6. webhook listens for mandate cancelled and then needs to be able to find and fail any/the outstanding contribution(s) made with it, which means we probably need to store the mandate ID on the contributions somewhere.

But if you have users who regularly donate/buy and want to use it for that sort of ad-hoc repeat transaction then this is going to really annoy them because (a) they have to enter their details every time and (b) their bank will show N direct debit mandates set up, where N is the number of payments they've made.

So to make it available for transactions "properly" would be akin to supporting "card on file" - whereby the flow is:

  1. GoCardless selected
  2. User authenticated and already has a live mandate? Process new payment in that. otherwise...
  3. No mandate? Set up new mandate, take payment from that.

This is much more complex as it requires storing details on mandates - currently we only store details on subscriptions on the Contribution Recur record. There's also the issue that Civi expects a redirect offsite, which wouldn't be happening if we already have a live mandate.

So:

a-sassmannshausen commented 4 years ago

Hi Rich,

Thanks for this detailed overview! It sounds like the use case of my customer is currently scenario one, for all its disadvantages!

It's good to hear you might be able to take on that work in 2 months time perhaps, and an estimate of hours.

Would you be comfortable giving a price estimate for the 14 hours of work? Would you prefer a private email address for this?

Best wishes,

Alex

PS: do you think it's feasible to implement solution 1 in such a way that it provides a foundation for solution 2, or are they entirely orthogonal in your estimation?

artfulrobot commented 4 years ago

I don't think they're entirely orthogonal, but I suppose (2) would solve (1) naturally, where as (1) then (2) can be done cheaper by taking a slight detour. As for estimates, could you email me? Please let me know who your customer is - I have a social mission to my work and like to know who I'm helping achieve what. Thanks.

pradpnayak commented 3 years ago

Hi @artfulrobot

Just checking if there is any progress on this to support Invoiced based system i.e one off membership payment (not auto renew).

Thanks Pradeep

artfulrobot commented 3 years ago

Hi @pradpnayak I've got a fairly clear route ahead, just need a little funding. Please get in touch if you can help with that!