CiviCRM Community Forums (archive)

Recurring contributions are supported for Authorize.net as of 2.0:
http://issues.civicrm.org/jira/browse/CRM-2009

I have not tested this myself - and this is community contributed code - but I think folks are using it in production.

The "help" you've quoted is obsolete - and I've updated it for 2.1 to include Authorize.net in the statement.

That said - you'll need to do some custom work to keep people's drupal roles updated based on their payment status. There's a community developed civicrm_member_roles module that does this synchronization - and you might be able to stitch things together using that along with a modified version of the cron-driven script which keeps CiviMember membership statuses updated (bin/UpdateMembershipRecord.php). Do post back here w/ any solutions you've come up with as I think other folks would find this combination of functionality quite useful.

I think you meant CiviMember_Roles (rather than civicrm_member_roles). It syncs CiviCRM memberships to Drupal roles, and seems to be just the thing to make this possible.

So I'll outline what I'm trying to do here step by step, and see where this goes.

- Install Content Access and CiviMember Roles modules.
- Create a drupal role [subscribed] and a content type [video]
- Give view permissions for [video] to role [subscribed] (using Content Access module)
- Create membership type [Subscribed to Video]
- Sync [Subscribed to Video] with [subscribed] (using CiviMember Roles module)

Now whoever has the membership [Subscribed to Video] will be able to view the content type [video]

So far so good, now comes the tricky part. We need to set up recurring billing.

As far as I understand it, for someone to become a member, they have to go through a contribution page. The membership has a duration, so it can expire in 30 days. Contribution page supports recurring billing, so potentially there is a way to set it up to bill every 30 days automatically by using some HTML/CSS customization.

Does the membership get renewed once someone gets automatically billed?

I welcome your thoughts and ideas on this.

Thanks,
Andrey.

1. Recurring billing on contributions is currently only supported for PayPal Std and PayJunction processors.

According to Donald Lobo the following post, the help text is outdated and Authorize.net is supported for recurring billing in version 2.0 [http://forum.civicrm.org/index.php/topic,4251.msg18517.html#msg18517]

Or did I misunderstand it?

2. There is no code yet which would automatically renew a membership based on a recurring contribution being received. However, as I said earlier - I think it would be possible to extend UpdateMembershipRecord.php (or create a new script) which checks for newly completed civicrm_contribution records (probably using a specific contribution_type by convention) and renews that contributors membership when found. Once decent approach to "mark" contribution records as "processed" is to create the link record in civicrm_membership_payment as you renew the membership. The script would then "know" that a renewal has been processed for that contribution record and ignore it on the next run.

How does UpdateMembershipRecord.php get run?

UPDATE: A cron job with wget seems to be the way.

I found the UpdateMembershipRecord.php.txt file in /bin, it said to put in an email address on line 63. This is line 63:
$config->userFrameworkClass     = 'CRM_Utils_System_Soap';
I don't think the email goes here.

UPDATE: It's actually line 130 - look for the $from variable.

UPDATE: There is a how-to located here, under "Membership Status and Reminder Server Requirement": http://wiki.civicrm.org/confluence/display/CRMDOC/Membership+Types

Also, when I rename it to .php and run it manually from a web browser, I get the following error:

ERROR: You need to send a valid user name and password to execute this file

UPDATE: You now need to have a drupal username and password (with Edit Contact permission) as part of the URL, so it looks like this:
http://<drupal_root>/sites/all/modules/civicrm/bin/UpdateMembershipRecord.php?name=<username>&pass=<pw>

To tie ARB with membership renewal, we basically need to do the following in UpdateMembershipRecord.php:
- Check if a recurring billing has occurred.
- Check what membership was tied to that contribution page.
- Check the membership duration that was tied to that contribution page.
- Set the membership end date ahead.
- Check membership status, and set to current if was expired.

So step by step:

- Check if a recurring billing has occurred.
Contributions are stored in `civicrm_contribution` table. `receive_date` is where the date is stored, so we can store the last run date, and execute the script only if there are new contributions.
Q: Is there a place to store random variables in CiviCRM a la Drupal's `variables` table?


- Check what membership was tied to that contribution page.
Q: Where is the information stored about which membership ties to which contribution page?


- Check the membership duration that was tied to that contribution page.
`civicrm_membership_type` stores the duration of membership.
`civicrm_contribution_recur` stores the frequency of recurring contribution.


- Set the membership end date ahead.
This can be calculated from the `civicrm_membership_type` membership duration.
Alter `start_date` and `end_date` in `civicrm_membership`


- Check membership status, and set to current if was expired.
`civicrm_membership_status` stores the status values
`civicrm_membership`.`status_id` stores the actual status id for a particular membership. This can be checked and changed.

I welcome your feedback and ideas.

In 2.1 we've turned off the "recurring" flag for authorize.net to avoid confusion

I'm writing this on 2.0, so the Authorize.net should work for now. If nobody steps up, I'll probably put some attention to it.

Best,
Andrey.

Someone posted a comment on the ARB for Authorize.net's project page:

Shailesh Lende - 30/Jul/08 12:46 PM
Tested and verified for 2.1 rev-16242.

http://issues.civicrm.org/jira/browse/CRM-2009

Also, on top of the page, it says:

Fix Version/s:      2.0, 1.8

I'm obviously not understanding something here. Does this mean that it still doesn't work on 2.0 or 2.1? Or that the file that comes by default with 2.0 and 2.1 is from version 1.7? It seems like it's been verified to work with 2.1 (and possibly 2.0)? Can I just replace the file (since patching it doesn't seem to work)?

Thanks,
Andrey.

I don't think we've defined an approach for linking "future recurring contributions" to a membership. However, there are some linkages in the data model which MIGHT be usable for this...

civicrm_membership_payment : currently used to link a contribution to the membership that the contributor is paying for (signup or renewal)
civcirm_contribution_recur : I believe this record is instantiated when a recurring contribution is initiated.
civicrm_contribution.contribution_recur_id : FK to civicrm_contribution_recur.id (not sure if existing recurring contrib code is populating this when recurring contributions are recorded ??)

One approach would be to create a civicrm_membership_payment record linking the membership to a recurring contribution record (if auto-renew billing is enabled). This record then becomes the link between incoming recurring contributions and the membership to be renewed.

You still have the issue of limiting processing to contributions > $last_run_id and I'm not aware of a random variables storage area (might check w/ folks in #civicrm IRC on this).