Support non-recurring contributions
Created by: wpf500
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.
Activity
Created by: artfulrobot
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.
-
Created by: petednz
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.
-
Created by: artfulrobot
@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.
-
Created by: artfulrobot
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.
-
Created by: petednz
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
-
Created by: artfulrobot
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
-
Created by: artfulrobot
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
-
Created by: petednz
that is our internal ticket system - no i don't see we did anything on this. Other notes i see on our ticket are
- its better to error on the form rather than adding js and show/hide payment options based on price field selections
- need to handle situations where you do want one recurring membership and one non-recurring membership to be available on the same contribution page
sorry. not being of much help
-
Created by: a-sassmannshausen
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
-
Created by: artfulrobot
@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
- take mandate in usual way
- take payment from mandate (instead of setting up subscription)
- (thank user)
- webhook listens for payment confirmed, finds contribution, records Completed payment which in turn marks the Contribution as Completed.
- webhook listens for payment failed/cancelled, updates Contribution
- 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:
- GoCardless selected
- User authenticated and already has a live mandate? Process new payment in that. otherwise...
- 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:
- supporting one offs where each one-off is a new mandate (works ok if your donors/customers never come back!). I could probably take this on (but am booked up for next 2 months).
- supporting one offs and stored mandates: I'm probably not in a position to take this on until I've cleared a couple of big projects I have on, but someone else might want it.
-
Created by: a-sassmannshausen
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?
-
Created by: artfulrobot
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.
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