Loosely coupled payment system

Submitted by redben on Thu, 11/26/2009 - 10:42

I would be great to have the payment module independent of other system entities and only use the cart/order base class/interface
So that modules can be built for special cases where there is no cart, order or product involved (like donations)

‹ Notes on development standards Root level entities and systems notes ›

Comments

Submitted by CpILL on Thu, 12/10/2009 - 06:35.

OOP

Sounds like basic OOP to me. Have a Payment class which defines the interface and the various payment types inherit from it. The system would be be configured to choose the specific payment system, instantiate it and pass it to whatever needed it. Would be easy to then have multiple payment methods as the checkout code would be the same for all of them.

Submitted by univate on Sun, 12/13/2009 - 20:30.

Total agree

The current interface to payment systems would be simplified if gateways were written using OOP.

Submitted by Ryan on Mon, 12/14/2009 - 11:54.

Linking for reference...

Linking for reference... chatted w/ Allie at DIWD and she pointed out she has a module attempting to do this:

http://drupal.org/project/pay

Submitted by alpritt on Tue, 12/15/2009 - 11:29.

Ah, thanks for that link. I'd

Ah, thanks for that link. I'd missed that module.

I've been steering towards the same goal from another direction. Namely I've been working specifically on a PayPal integration, with the intention of making it work as a standalone module, but also one that could fit into Ubercart. The end goal is to have a common interface that could work across different gateways (though I only really know PayPal at the moment.)

The Pay module looks like it is after the same thing, but starting from the interface perspective rather than a specific gateway. It would be good if I can integrate my work so that it is built on top of the Pay module. I've just taken a quick look through the Pay module and it seems to follow a similar pattern to my plan, though I have yet to fully grok it and have a few uncertainties.

It certainly looks like a promising approach.