Skip to main content
Ungathered Thoughts

CiviCRM, payment, and processing

CiviCRM's contribution pages are no Obama campaign. Certainly not out of the box. On the backend, there are issues too - like the fact that CiviCRM's forms layer drops submitted data to the DB while processing submissions, and that contribution form submissions contain credit card details. (It's OK, provided your contribution doesn't fail, CiviCRM will clear your PAN and CVV really soon, promise.)

Unless a client has a dedicated security team (in the CiviCRM space, probably only the EFF) I push them to use a hosted processor. I'd rather you use PayPal than stored PANs in the DB. But onsite transactions are a thing, and if we're building modern contribution pages, we're not going to 302 you off to paypal mid process.

So - how to get some contributions into CiviCRM and sidestep the horrors of CiviCRM's forms layer? Glad you asked :)

For the AU Green Party in the 2010 Australian Federal Election, we added an API method to CiviCRM so that we could access transaction processing via the API. (Nothing to do with PAN storage, all about the horrors of Smarty at the time.) We used Drupal FAPI to build a simple form for the donate interface, then called civicrm_api() from Drupal's form submit hook to do the CiviCRM layer stuff.

This year is election year in Australia as well, and so the same question comes up. I expect we'll face this in 2014 with both Labour and the Greens in NZ using the Drupal/CiviCRM combo.

If I was rewriting that three years later, I'd be thinking about these things -