-
Notifications
You must be signed in to change notification settings - Fork 18
Support changes to subscriptions, e.g. giving increases #6
Comments
Info: When you change a charge amount at GC, the subscription ID remains the same. This could cause problems with future webhooks' ability to identify the Q. Would users prefer to administer changes in CiviCRM (and have it update GC via API) or administer changes using the GC manage website (and have it update CiviCRM via webhook)?
Thoughts? |
I don't have a strong preference either way, but I'm not sure how it would work at the GC end. If you have several different types of membership how would you be able to work out which contacts in GC were of which type? And how would you change the amount charged? I'm not sure if this sort of bulk change is even possible in GC. So, I guess it would make more sense to make the change at the CiviCRM end where you have the full information about which contact has each type of membership. |
I think @wmortada is referring to a bulk change in charges, rather than the more generic case of being able to update any single subscription amount. e.g. increase in standard membership fees. As that is a requirement for at least them, I think it would be more helpful if there was a way to do it from within CiviCRM, since then somone could make a Search Task or some other means of looping certain records, and process each subscription that way. As far as I know there is no means of searching or bulk-processing Recurring Contribution records, but I imagine it would be possible to do it from a set of Contribution records and just look up the Recur record for each, taking care to not process one recur record twice (e.g. if two contribs belong to the same recur record). GC is fundamentally based on individuals and individual subscriptions, so you're going to need a programmatic loop to implement such a change to a group of subscriptions. I would suggest we need:
|
Just to clarify the requirements, I'm working with an organisation that has membership set up like this:
Payments are taken annually. In future, they may want to increase the membership fee, say by 10%. This increase would apply to all existing members (including those on a current GC subscription). How would they do this? Is this possible to do at the GC end? I'm sure this must be a common scenario for many membership organisations. |
You'd have to ask them. Doesn't look like it to me though. This extension uses GC subscriptions, set up through GC's 'redirect flow' web pages which means GC handle all the legal requirements around DDs, and deal with taking the payments. CiviCRM does not send anything to GC to say "please make the following transfers for the following people"; CiviCRM is not in that role and has no control. It's cheap and cheerful. The other way to use GC would be to have CiviCRM do all the heavy lifting. That would be quite a different extension; it would require a completely different integration for the mandate creation/data collection; a cron job to create the BACS files every day detailing who to charge what amounts, and to send notification emails in the week before to comply etc. This way CiviCRM would be in control and all responsibility would lie with it. This way, if you had some way of updating how much a membership cost at CiviCRM (I don't know whether this exists or not; I've not worked with memberships much) then those additional costs would be charged. But to be clear: this would probably be a different payment processor; a different integration extension. You might be better doing the BACS yourself and using Systopia's more generic SEPA extension - but it's a LOT of work, and more suited to big orgs. What I'm suggesting is a way to update the subscriptions at GC from within CiviCRM. But this would be a manually-driven, deliberate process rather than just changing the membership fee in one place and everyone getting charged more automagically. |
Thanks @artfulrobot, that's really helpful. I think this is starting to come a bit clearer. From what I understand, you are talking about changing the contribution amount for an individual contact (e.g. a donor that wishes to increase/decrease their monthly donation). What I'm talking about is making a bulk change to a large group of contacts at the same time (e.g. all members of the organisation). |
@wmortada yep. And I'm talking about a way it might be possible to achieve your bulk update via a repeated operation on a (selection of) contribution search results. |
Thanks @artfulrobot. That sounds good. GoCardless have pointed us to information in their developer docs about how to update an existing subscription via their API. They also said: "Please note that a subscription amount can be edited to a maximum of 10 times. After this, a new subscription would need to be created if you'd like to edit the amount again." |
Yes, as you will now have seen, a subscription belongs to an individual mandate and cannot be updated en-masse across many people in one GoCardless API request, which is why I've proposed the above. |
In case anyone is following this thread, I'm currently looking into this again. |
Yes, I'm still very interested in this functionality. Please let me know if I can be of any help. |
Also interested. I'm currently using this extension with one membership based org, and recommending it to another. The ability to increase membership fees within an existing mandate would greatly enhance the utility of the extension. |
Just to lower expectations a bit, I have a client whose interest is in being able to increase regular donations (not memberships). I'm working on something for them so they can email supporters with a linnk that will show something like "Thanks, you're giving £6/month, you can increase your monthly giving if you like, enter the new amount here :£_____ " - that page will not be part of this extension though. The functionality I'm developing also means that from within CiviCRM when looking at a contact's Recurring Payment, you (as staff) wil be able to change their regular payment amount. And from CiviCRM 5.20 (I hope) you'll be able to cancel it from there, too. If your membership needs are simply that more money is taken by the recurring payment, then this should work for you (although you'd stil need a way to bulk process them). But if, for example, you want to bump them onto a different priceset tier - that's not going to be in scope for what I'm doing here. Finally on expectations again, I'm not planning to implement dealing with failed upgrades at this stage - e.g. if a subscription is changed more than 10 times it won't allow more changes. |
Sounds good to me. It's a step in the right direction. |
1.9beta now supports changing a subscription via CiviCRM's staff interface - i.e on a contact's record. It may also support cancelling the subscription (but currently not the mandate) via the same UI. https://github.com/artfulrobot/uk.artfulrobot.civicrm.gocardless/releases/tag/1.9beta |
I've added a new issue to separate out the use case of a membership organisation needing to change the membership fee in #87. I think it is sufficiently different to warrant a separate issue. |
Closing as the basic functionality is there now and other issues exist for the other things mentioned. |
I'm not sure how CiviCRM handles this, or should handle this, for something like a Direct Debit. Does it 'Complete' one ContributionRecur record and create another to describe the new arrangement? What happens at GoCardless in terms of subscription IDs?
Needs a plan.
The text was updated successfully, but these errors were encountered: