Based on some conversations on IRC with Marshall from Ideal Solutions LLC, I embarked on extending CiviCRM to allow different payment processors for different contribution/member/event pages. Our current restriction of just one payment processor for the entire system did not feel right and we had a few requests to extend this functionality. I took this opportunity to review parts of the code base that I was not familiar with and make a few improvements to CiviCRM in the process. I suspected this would be a fairly quick project. It boggles my mind as to how wrong I was on this count. A look at the Fisheye revision history gives you a better idea of how extensive those changes were. We are still wrapping this up and need to do a bit more extensive QA before resolving the issue.

I'm glad we took this on and cleaned up the code. We made things more configurable and simplified the code a fair amount. We also eliminated all payment processor variables from the config object and moved them into the database. This is inline with our longer term plans of making the config object smaller (this in turn should speed up page downloads a wee bit since the config object is loaded on ALL pages). We had to introduce two new tables

• civicrm_payment_processor: This table contains all the information about a payment processor interface including the api login, password, signature, url, image. It also contains the php class name that implements the interface with the processor api's. Contribution / Membership / Event pages all contain a foreign key that points to a specific payment processor.
• civicrm_payment_processor_type: This table contains meta information about a payment processor. This includes what fields are used and what they are called (user_name is called Merchant ID, Login, API Login etc). To introduce a new payment processor in CiviCRM, we just need to make any entry into this table (via a web interface). No more changes to code to add a new payment processor :)

Since we were in the payment processor arena, we decided to give the admin user the ability to process a credit card contribution via CiviCRM (thanx to a forum post by Dave Lange). This was a nice extension to make and we could reuse most of the code from the online payment forms.

This highlights something that we need help figuring out. How do we get the consulting / user community to step up and make generic contributions to CiviCRM that are applicable to the wider community at large, and hence can be integrated into core. There is always a fine balance between client's needs / demands / billable hours vs design / implement / support for something more generic. There are quite a few companies out there that deploy CiviCRM but we do not seem to be getting a lot of code contributed back into the project. We could attribute this to a variety of reasons, but we definitely would like to improve the bottom line and get more contributions in. Any thoughts, comments or suggestions are welcome and more than appreciated :)