Opublikowane
2007-06-10 00:25
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 :)
Filed under
Comments
funny that you mention this, as part of v4 for E-Commerce I am redeveloping the payment system, and 1 thing is so that EC can accept payments for CiviCRM
I look forward to seeing more.
Hi gordon,
I currently involved in this project that aims to use Payflow Pro payment sistem (witch I already adapted for Drupal 5.2) in the CiviCRM transaction.
Is there any way to use the Drupal payment modules in CiviCRM with the current ecommerce 4.x snapshot ?
Thank you
Paolo