Skip to content
This repository has been archived by the owner on Jun 25, 2021. It is now read-only.

Support non-recurring contributions #12

Open
wpf500 opened this issue Jan 17, 2017 · 17 comments
Open

Support non-recurring contributions #12

wpf500 opened this issue Jan 17, 2017 · 17 comments
Labels
enhancement funding needed Some people are interested in funding this, please contact me if you are too!

Comments

@wpf500
Copy link
Contributor

wpf500 commented Jan 17, 2017

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
Copy link
Owner

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.

@artfulrobot artfulrobot changed the title Non-recurring contributions Support non-recurring contributions Jan 18, 2017
@artfulrobot artfulrobot added the funding needed Some people are interested in funding this, please contact me if you are too! label Apr 26, 2018
@petednz
Copy link
Contributor

petednz commented Nov 12, 2018

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
Copy link
Owner

@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
Copy link
Contributor

petednz commented Nov 12, 2018

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
Copy link
Owner

artfulrobot commented Nov 12, 2018

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
Copy link
Contributor

petednz commented Nov 12, 2018

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
Copy link
Owner

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
Copy link
Contributor

petednz commented Nov 13, 2018

have added to our list fz-16765

@artfulrobot
Copy link
Owner

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
Copy link
Contributor

petednz commented Feb 5, 2020

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

@artfulrobot
Copy link
Owner

No, that is helpful, thanks.

@a-sassmannshausen
Copy link

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
Copy link
Owner

@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:

  • 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.

@a-sassmannshausen
Copy link

a-sassmannshausen commented Apr 18, 2020

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
Copy link
Owner

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
Copy link
Contributor

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
Copy link
Owner

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!

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
enhancement funding needed Some people are interested in funding this, please contact me if you are too!
Projects
None yet
Development

No branches or pull requests

5 participants