Hi all,
I'm pleased to announce that the silverstripe-omnipay payments module is ready for beta testing.
The best place to get started is here: https://github.com/burnbright/silverstripe-omnipay
What is it?
This module is a new approach to accepting payments within SilverStripe applications. It is effectively just a wrapper of the omnipay php library. It is intended to completely replace the SilverStripe Payment module.
Why do we need another payment module?
The existing payment module has been doing its job, but it's not as good as what it could be.
There is hardly any standardisation of how each gateway integration was written, which means you are re-inventing the wheel each time you try to integrate with another gateway. There is much more standardisation/ abstraction/ separation that can be leveraged than what has been currently done in the Payment module.
The current Payment module isn't simple to use for newcomers. It requires passing form data to a 'process' function, where there is no specification of what fields are for what.
There are very few contributors to the SilverStripe payment module. Omnipay has, and probably always will have more contributors, as it caters for many other frameworks and applications. This helps to ensure bugs are picked up, and the gateway integrations are scrutinised by a wider community.
This has been a significant factor in choosing to integrate with the omnipay library.
How did work on the omnipay module start?
The maintainer of omnipay posted a github issue: https://github.com/silverstripe-labs/silverstripe-payment/issues/23, suggesting that we consider integrating with the library.
Being unhappy with the quality of the payment module, I've thought about integrating with omnipay for a while. The rise of the use of composer with SilverStripe has made it more appealing. I have also been fortunate in my current work position to be able to put some paid time into this module, as well as the Shop module.
I decided to treat this as a separate module from payment to avoid any friction that could be generated. People may not like this new approach, so they can just carry on with the payment module.
What about the GSOC 2012 on Payment 1.0?
I was involved first-hand with the work to upgrade the payment module to version 1.0. I got to work with the very talented developers: Frank Mullenger, and Ryan Dao. We managed to architect and build a better solution than what we had previously. We learned a lot about payment gateways in the process (finding good terminology is a big part).
We did research other php payment libraries during the project, but opted at the time to implement our own suite, but took on-board some of their ideas and terminology.
I know it is still used, but for such an important component of a site, I think not enough. There is just not a large enough community to scrutinise each gateway type. I attempted to integrate it with my own shop module, but that effort fizzled out because I didn't have time, and I was concerned about the above issues.
State of the art
The omnipay (silverstripe wrapper) module is ready for you to try out. It is a complete rewrite from the ground up, but you'll notice it has borrowed many ideas from the Payment module.
I've written lots of unit tests (still room for more), which also make use of mock gateway responses. The tests are set up to run on Travis CI. The module makes good use of the SS3 configuration system. I have also created a "Payable" extension. See the README for more info.
I've created a simple 'Payme' module (https://github.com/burnbright/silverstripe-payme), built for testing purposes, but it has potential to be developed further, if someone wants to take it on.
I've also been working on integrating this omnipay wrapper with the Shop module. https://github.com/burnbright/silverstripe-shop/tree/omnipay-integration
Get Involved!*
Whilst there is more work that can be done at this stage, I believe the module is ready for community input and testing. I have tagged the module in it's current state as: 1.0-beta1.
Please feel free to test out the module. Submit pull requests and issues. Please indicate (in gitub issues), any problems you have setting up, or any lacking documentation. I want to know if this module meets your expectations, and how to improve it, if not.
The Omnipay library supports a few additional gateway features: authorise/capture, refund, and void functions, which have not yet been worked into this wrapper module (only stubs).
I have set up a 1.0 milestone for the module: https://github.com/burnbright/silverstripe-omnipay/issues?milestone=1
I believe that if SilverStripe can handle payment / shopping related applications really well, then it is more likely to be adopted and chosen. This benefits us all.
--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to silverstripe-d...@googlegroups.com.
To post to this group, send email to silverst...@googlegroups.com.
Visit this group at http://groups.google.com/group/silverstripe-dev.
For more options, visit https://groups.google.com/groups/opt_out.
- How about using Injector for Payment:: set_http_client()? So Payment::$dependencies = array(‘httpClient’ => ‘%$Guzzle\Http\Client’);
- Architecturally it would be cleaner to leave gateway interactions out of the Payment class,and e.g. have a PaymentService->purchase() which stores the outcome in a Payment object.
Yes, I think this is a good change. The Payment class has been getting a little bloated.
- I think a sequence diagram with the different classes involved for some more common scenarios will go a long way to help devs understand the features.
This is probably the closest to what you’re talking about: https://github.com/burnbright/silverstripe-omnipay/blob/master/docs/en/payment-scenarios.md
It just needs to be converted to a diagram.
- The docs are pretty fragmented into short individual files. How about making them one long doc instead? Easier to search (via browser) and browse through.
Ok, yep will do.
- Let me know if you need help getting the module onto transifex for translation :)
I’ll take any help I can get :)