Another feature that we worked on this week was integrating the "standard" version of PayPal as an additional payment option for CiviContribute. We waited for quite a few months for PayPal (or Google) to release a nice web 2.0 api for subscriptions / recurring transactions, but that did not seem to be happening. So we took the plunge and decided to implement PayPal Web Standards as the first step towards implementing PayPal Subscriptions (basically recurring donations)
PayPal has done an incredible job of documenting their API's and making the integration fairly easy. It helped that the Drupal e-commerce package has this feature, so we could peek into their code base and figure out how to do a few things. Getting a system up and working using the sandbox makes development so much easier, since the sandbox behaves identically to the live system. I was pleasantly surprised to see that we did not have to write a lot of code for this case, but primarily had to rearrange and cleanup the existing code to handle the synchronous (SOAP api) vs the asynchronous (IPN) implementation.
There was a discussion on the mailing list about providing support for other payment processors. We spend a significant amount of time in documenting, testing and making sure the design and implementation is general enough that folks can use it seamlessly. Unfortunately all the payment processors follow slightly different protocols (PayPal has 3 different ways!) with slightly different naming conventions for the same variable, different sandbox and testing procedures. We need to spend a significant amount of time for each processor, i estimate this to be approx 20-40 hours (depending on the wierdness of the processor protocol and how closely it fits one of our already implemented models). As an open source project, we do rely on the community to scratch some of their own itch, and we hope that implementing a transaction processor is a nice first step