« Back to home

SilverStripe Payment Module New Architecture

I'm currently doing Google Summer of Code with SilverStripe for the Improve Payment Module project. Basically the project aims to refactor the Payment module, a very important part of SilverStripe ecommerce solutions, to make it more robust and flexible. Over the last few weeks during the community bonding period, my mentors and I have discussed the new architecture of the module and here's what we've come up with:

Goals:

  • Make it as easy as possible for developers to process payment on an ecommerce site.
  • Decouple the module's components and separate payment gateways into sub-modules. The core module after GSOC should not be changed much, and changes to payment gateways can be made separately from the core module.
  • Provide unit testing capability.

Architecture:

The old Payment class now is separated into a model and controller. The new Payment class now only acts as a model to record the payment information. Anything related to payment processing is now handled by PaymentController. Each payment gateway module should sub-class the 2 base classes to satisfy the specific requirements pertinent to that gateway. One thing to take note is that each gateway module can have up to 3 different controllers for the 3 purposes: production, development, and testing. The architecture is set up in the way such that developers can easily set up which controller they want to use through the config.php file and that controller will be used by PaymentProcessor accordingly. PaymentProcessor takes order information from the order form and forward the request to the PaymentController currently in use.

To make it even easier for developers, we provide a PaymentFactory class which is in charge of creating the model and controller objects of the gateway that they want to use. For example, processing a payment with PayPal now can be easily done as follow:

$paymentProcessor = PaymentFactory::createProcessor('PayPal');
$paymentProcessor->processPayment($data);

Basically that's the direction we're heading so far. I forsee we'll need to modify the architecture a little bit here and there as we go along, but I hope the changes will not be significant and we'll not have to get off the current track.

Comments

comments powered by Disqus