Peer support for CiviCRM in class registration / event registration context?

[smokinggoat]

I am supporting Regenerative Design Institute's implementation of CiviCRM ver 1.7.98 on Drupal 5.1.  They use CiviCRM to mange their class registrations and payments: classes are added in Events, payments are made via CiviContribute. 

I'm looking for users of CiviCRM who are using their implementation in similar ways - using CiviCRM to manage class registrations and payments.  Because this kind of implementation seems to raise issues that are either not supported or need to be managed manually (see below), we'd love to talk to other orgs that are trying to do this, and develop a small "community of support" with a (preferably Bay Area) org to help each other.

• Are there Bay Area (or beyond) organizations that are using CiviCRM to manage classes (or event registration and payment) that would like to talk about their issues and solutions with RDI (on or off this forum)?

(I've looked at the case study list, and none seem to me to be using CiviCRM for class / event registration).

Some sample challenges are listed below.  I'm not saying these are endemic to CiviCRM; they are a by product of using the system for class registration and payment:

• Payment failure:  People register for a class.  They go to pay, and are punted to PayPal to finish the payment.  PayPal fails (a fairly common occurrence, especially with big-ticket long-term classes that cost several thousand dollars).
  - Their contribution is listed as "Pending" - and never goes away unless manually removed.  Also, the total payment is counted in the contribution totals (as far as I can tell), which skews how much each class has collected to date.
  - The person re-registers, since there appears to be no method of checking on existing registrations (see http://forum.civicrm.org/index.php/topic,767.msg3124.html#msg3124).  The original registration, that failed, must be manually removed, otherwise the class lists are bloated with people who've registered again after their initial payment failed.
  
• Paying in installments:  Since some classes cost over $4k, RDI allows payment in installations.  However, since people cannot go in and see their current registrations / contributions, people have to register for the class again in order to add the next installment contribution. This adds another entry of their name to the class registration.  But we don't want to remove these registrations for fear of creating "orphan" contributions.

Thanks for any help finding peer orgs, or with the actual challenges we're looking at.  :-)

Greg

[geilhufe]

I can't help with the peer to peer part, but a thought:

(1) Have you looked at the contact dashboard CiviCRM generates for every contact that can be linked to from the Drupal user record? [http://demo.civicrm.org/drupal/civicrm/user?reset=1&id=102]

This shows contributions and memberships and could potentially be used for installment type stuff. You could generate a special contribution page for the 2nd and 3rd, etc. payment. Workflow would be individual signs up for class, makes first payment. Views record and makes 2nd payment from a contribution page. Views record, makes third payment, etc. You'd need to name a spacial contribution type for this to make sense to users, I suspect.

[Dave Greenberg]

• Payment failure:  People register for a class.  They go to pay, and are punted to PayPal to finish the payment.  PayPal fails (a fairly common occurrence, especially with big-ticket long-term classes that cost several thousand dollars).
  - Their contribution is listed as "Pending" - and never goes away unless manually removed.  Also, the total payment is counted in the contribution totals (as far as I can tell), which skews how much each class has collected to date.
  - The person re-registers, since there appears to be no method of checking on existing registrations (see http://forum.civicrm.org/index.php/topic,767.msg3124.html#msg3124).  The original registration, that failed, must be manually removed, otherwise the class lists are bloated with people who've registered again after their initial payment failed.
  

Greg - I'm hoping some other folks on the user side will chime in hear. However I do have a comment and a question about the Payment Failure issue.

• If Pending contributions are being counted in total contributions - I think this is a bug. Can you clarify if this is indeed happening in places where you've not explicitly searched on "Pending" status records. If so, please file a bug report w/ specifics on recreating.
• Have you considered switching to one of the payment processors that does inline / real-time verification of the transaction (e.g. PayPal Pro, Authorize.net - and probably PayJunction in 1.9)? I'm pretty sure that payment failures with these processors do NOT create a pending contribution (as we know "inline" whether the transaction succeeded or not). Given the size of the transactions, this might be preferable - altho the fees are a bit higher.

[smokinggoat]

David - Thanks for the quick reply.  Your answer raises another issue - we allow "anonymous" (to use Drupal's term) class registrations.  I.e. you don't need to create a Drupal account on our site to register and pay for a class.  We are actually considering moving in that direction, but then the big question is - how do we manage / migrate all the existing users in  CiviCRM?

Dave - I'll check again where I saw that the totals being lumped into the "pending".  It might have been the default setting for a search page that I didn't catch.  I'll write back (here) if it's my error or a bug and if the latter, obviously I'll submit a report.

Your suggestion of inline payment processing might be the ticket though - RDI has asked if there's anything that they could do with PayPal to make the process better.  There's nothing we can do about people getting denied when trying to pay for a $4k class, but getting that info inline might help us manage the registrations.....  Is there anything that changes in CiviContribute?

Thanks both of you for suggestions.

No one's got recommendations for "peer" orgs, though?   

[Dave Greenberg]

Your suggestion of inline payment processing might be the ticket though - RDI has asked if there's anything that they could do with PayPal to make the process better.  There's nothing we can do about people getting denied when trying to pay for a $4k class, but getting that info inline might help us manage the registrations.....  Is there anything that changes in CiviContribute?

Follow the instructions on the wiki (and on the payprocessors site) for applying for merchant account and configuring a new payment processor in CiviCRM. Note that as of 1.8 you can have multiple payment processors configured for a single site - and use them on different contribution or event registration pages. This means you can try out the new processor for a non-exposed / test Event Reg page etc.

The main behavior difference for these inline processors is that the registrants' credit card and billing address info is collected on your site (rather than PayPal's) - and transaction is accepted or declined "realtime". A side-note is that you need to obtain and configure an SSL certificate for the site, since folks are entering credit cards on your forms.

[geilhufe]

David - Thanks for the quick reply.  Your answer raises another issue - we allow "anonymous" (to use Drupal's term) class registrations.  I.e. you don't need to create a Drupal account on our site to register and pay for a class.  We are actually considering moving in that direction, but then the big question is - how do we manage / migrate all the existing users in  CiviCRM?

Well, there just was added a feature where you can make a CiviCRM profile create a drupal user on submit. Avoids the user having to create a drupal account. I have not used it yet, so not sure exactly how to structure this. I also don't think the docs have caught up yet, so you'll have to play with it.

[Dave Greenberg]

I also don't think the docs have caught up yet, so you'll have to play with it.

Docs are now updated. Feature requires Drupal 5.x and takes some playing with if you want to use it in a "Standalone Profile form" (check for posts on this forum if this is what you need).

http://wiki.civicrm.org/confluence/display/CRMDOC/How+to+Create+Profiles

[geilhufe]

Didn't mean to create work for you Dave

Thanks though,

[smokinggoat]

Well, there just was added a feature where you can make a CiviCRM profile create a drupal user on submit. Avoids the user having to create a drupal account. I have not used it yet, so not sure exactly how to structure this. I also don't think the docs have caught up yet, so you'll have to play with it.

Thanks to both of you for these suggestions.  We're looking at this solution, although to be honest it'll take me a while to work through the specifics of it.  Will this tool allow us to migrate the dozens (100+?) of existing CiviCRM profiles - people who come back for more than one class - to Drupal accounts; or does it just more easily create Drupal accounts when a new CiviCRM profile is created (in an event registration, for example)?

As for the "pending" being counted in the totals - that's completely a user error. I missed the "status" radio box in the Contrib search page, and was pulling up "all" contributions, not just completed.

By the way - we hooked up with Tryon Farm (linked in the case study list).  Turns out they do offer classes, and use CiviCRM for event reg and payment.  So we've made a useful connection there.  :-)

[geilhufe]

OK, slight language disconnect. A CiviCRM profile is a collection of fields. You don't really create a profile, you use a profile to create or update a record in CiviCRM.

This does not help you deal with the the people that have already registered for classes. JUST new folks going through the profile. In general, if you want the user to update their own records, you want to make sure they have a Drupal login.

The drupal account+profile solution would work best with a fresh batch or registrations.