Getting Membership Types and Recurring contributions to work together

[mdlueck]

Drupal 6.x latest
Civi 3.2.x latest

For our organization, we need Civi to be able to support Recurring contributions along with a given Membership Type available on a specific contribution page. There seems to be a disconnect between Membership Types and having it be a Recurring contribution. Please help us understand what can / can not be done with Civi and propose a working solution to fit our needs.

When a person joins our organization, they may pick either PayPal or CC payment method. We have separate contribution pages for those two types.

Further, they can join with a Recurring payment of either monthly or yearly, thus a total of four contribution pages.

On each of these contribution pages, there are several membership levels offered. We have been planning to use Membership Types to accomplish this, which supports an intuitive radio button pick list on the contribution page.

However, it seems to be the fact that we are trying to include Recurring contribution in the equation that we end up with an extra field on the contribution page titled Contribution Amount which is a free-form entry field which seems to be what the person will actually be billed for their membership.

This disconnect between Membership Types and Recurring contributions is quite confusing.

How can we simply leverage the Membership Type and have it be Recurring? (Be it a monthly or yearly recurring frequency.) Thus no extra Contribution Amount field, just recurring of the amount next to the radio button selected.

[Donald Lobo]

This was a make-it-happen for 3.3 and we just met the goal a week ago (thanx to data scribe for stepping up big time). This feature will be part of a future release (either 3.3.x or 3.4). Dont know the exact specs, but we'll do it after 3.3 reaches final

lobo

[mdlueck]

Thanks lobo for that port hole view into the future.

What is the work-around to make this sort of thing happen with current code?

[Donald Lobo]

i dont think there is an easy workaround for this in the current code base. you might be able to do whats coming as a hook implementation on a contribution etc

lobo

[mdlueck]

hee hee hee...  Seeing raw capabilities in Civi causes me a strong desire to make something work.

All right, so assuming that Membership Types and Recurring contributions is the troublesome combination, then please follow me along the path of "what if..."

1) We have separate contribution pages for each Membership Type (Level and payment method... yes lots of pages) which eliminates the need to leverage the Membership Type pick list
2) Zero out the value that was in the radio button pick list
3) Hard code the value for the Contribution Amount so that it does not show up as a free-form field

In this case, would Recurring contribution work as needed?

[mdlueck]

What exactly is the road block with Recurring contributions?

Is it that we wanted a radio button pick list for Membership Types?

Or is it an active Membership being directly dependent on a successful Recurring contribution?

Is there anyway to successfully associate Recurring contribution with Membership activation?

ooohhh... http://wiki.civicrm.org/confluence/display/CRMDOC32/PayJunction+Configuration Seems with PayJunction Recurring is ugly no matter what... (sigh)

[Eileen]

So, there is funded work on Authorize.net for this - other payment processors can follow the model once it is written for Authorize.net

[mdlueck]

Please consider this work-around we thought of last evening and respond with "probable pass/fail" to the idea:

It seems that Recurring contributions do work reliably in general. Just that they can NOT currently be the trigger to keep the Membership status active.

Further, it appears that the default behavior is to expire the membership after n days (n depending on monthly/yearly membership).

So I thought to directly check the database with an external script, specifically the table containing Recurring contribution transaction history. When the script sees new successful transactions in the database, update the correct/corresponding Member for another n days.

Are we basically understanding the disconnect in this "Getting Membership Types and Recurring contributions to work together" topic? Could it be temp-fixed with a simple script doing such?

Specifically we are looking at PayJunction to be the CC gateway, and also direct to PayPal. Two gateways.

[Donald Lobo]

pass

that will be what the new code does. when a recurring contrib comes in, bump the membership dates as per the rules

lobo

[mdlueck]

pass

ffffeeeewwww!!!! One green light then!!

Waiting to see if the database driver I need to use to access MySQL is x64 compatible. x64 bit support is rather new in the Open Object Rexx community, so not sure if RexxSQL has been updated for x64 support. That would be my first choice. Failing that, perhaps Bash, or learn a bit more Perl / PHP I guess.

Thank you for the first green light, Don!!! 

[Donald Lobo]

that said, u might want to wait for 3.3.1 since we'll be releasing this feature in that release. 3.3.1 is scheduled to be out around xmas

will save u time and money, and u can help debug and test the solution. in return, u might want to consider helping other "make it happen" projects happen: http://civicrm.org/contribute

lobo

[mdlueck]

3.3.1 is scheduled to be out around xmas

hhhmmm... when I heard 3.3.1, I thought to myself, "3.2.x just came out, so must be going to be a while. Perhaps 3.3.x will not even still be D6 compatible!"

Christmas is indeed very close. Probably we will wait since monthly memberships will not even renew once if we cut over to the Drupal site today, if you make your Christmas projection.

Thank you for the added clarification.

[mdlueck]

Request for how this is implemented:

Please put verbose logging into the script so that we can audit what steps the script is performing.

I collect all script trace output and retain it on the server for 30 days.

"The truth is in the logs."

[mdlueck]

All righty, now upgraded to v3.3.1... I am not seeing a script which needs to be run in order to accomplish this task.

Please advise where it is, if it indeed made it into 3.3.1. Thanks!

[Donald Lobo]

it did not make it into 3.3.1, shooting for 3.3.2 now

lobo