Annual membership, monthly payments?

[ewanmclean]

Hello

I'm looking for some help. Our client is moving from a custom database to CiviCRM and I am trying to implement the membership system. They have one membership class, 'Member'. That membership lasts for one year from the date they take it out. The minimum annual membership fee is £12 for adults or £8 for students. Sounds easy right? The difficulty I've experienced is that they want people to be able to pay a monthly contribution towards their annual membership.

So they take out an annual membership, and pay that £12 as £1/month. This is because they've found it more attractive than asking people for a larger upfront payment. The issue is I can't figure out how to get CiviContribute to cope with this. When I give them a recurring monthly option (paypal), and say £1/month, it tells me that the membership requires £8. Of course it would in fact total up to £12 over the year.

Any ideas? Here';s the test page: http://nzy.me/civicrm/contribute/transact?reset=1&id=10

Thanks

[Eileen]

What happens if they don't pay all their months?

A membership paid monthly is best represented as a monthly recurring membership if at all possible - then it falls into grace / expires if they don't make all their payments & you aren't fighting the system.

However, You can override minimum membership fees using pricesets

[ewanmclean]

I'll speak to the client about the membership structure - this was my thinking too.

That said, I'm trying to find a work around in anticipation  of them saying no. I tried to create a price set of type 'Membership' this didn't appear in the online contribution page (it said no contribution price sets were configured). I tried creating a 'Contribution' type price set, this appeared but wouldn't let me use the Membership tab on the contribution page at the same time. I tried creating a price set of both types but it said you couldn't use both. Any ideas?

Thanks for your help

[artfulrobot.com]

Where did you get to with this?

[Martin Peth]

We are facing a similar problem. The workaround suggested by Eileen might be of some help (we thought of that, too), but after all it's really not a clean solution. We are now considering creating an extension that works like this:

• match incoming member fee payments to memberships (if they are not yet linked)
• have the payment cycle and amount of each expected payment stored in custom fields with the membership
• have a cronjob search for expected payments that did not come in and set the according memberships' status to something like "payment overdue"

This would enable users to search for memberships with overdue payments. Does this make sense to you? (We would still have to figure out how this would relate to the existing status mechanisms, especially the switch to grace period...)

[Dan C]

I echo Eileen's question though, what happens if they don't pay the full amount?  How is this annual membership paid monthly different from a monthly recurring membership? 

It just seems like a lot of work to create a different workflow for something that already exists in Civi.