Support changes to subscriptions, e.g. giving increases

[artfulrobot]

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.

[artfulrobot]

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 contribution_recur record if there were two of these.

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)?

• Do it CiviCRM end: means staff users don't necessarily need access to the GC management pages (although I expect in most small-medium orgs those staff may well already have that level of access). Questions about UI and process - does CiviCRM already have a standard process for such changes?

• Do it GC end. Feels likely that this would be more accurate because it engages the staff member with more of the detail of how DDs and GC actually works. You can have what you want in CiviCRM but so long as the payments are being scheduled and taken by GC, GC remains the authoritative and most important data source.

Thoughts?

[wmortada]

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.

[artfulrobot]

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:

1. An API method that updates a subscription (recurring contrib) amount for a given contribution recur record ID.

2. A UI to allow a CiviCRM user to change a subscription amount. Note: it would also be nice if users could cancel a subscription from within CiviCRM.

3. A Contribution Search Task which loops contributions, finds the recur records, and calls the API for each of those updating the amount to a new user-specified value.

[wmortada]

Just to clarify the requirements, I'm working with an organisation that has membership set up like this:

• standard £20 (10,000 members)
• student £10 (2,000 members)
• organisation £100 (1,000 members)

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.

[artfulrobot]

Is this possible to do at the GC end?

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.

[wmortada]

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

[artfulrobot]

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

[wmortada]

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

[artfulrobot]

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.

[artfulrobot]

In case anyone is following this thread, I'm currently looking into this again.

[wmortada]

Yes, I'm still very interested in this functionality. Please let me know if I can be of any help.

[Upperholme]

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.

[artfulrobot]

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.

[wmortada]

Sounds good to me. It's a step in the right direction.

[artfulrobot]

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

[wmortada]

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.

[artfulrobot]

Closing as the basic functionality is there now and other issues exist for the other things mentioned.