Omnipay Module beta 1 - a potential replacement for the Payment module.

[Jedateach]

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.

[c...@silverstripe.com]

Hey Jeremy, 

I'm just putting together the community newsletter. Would you like be to make a mention of your beta test and a little bit about the module?

If you can whip me up a short bit of copy text I'll include it when it goes out later this week/early next week :) 

Hope all is well with you, are you still living up the Kapati Coast?

[Ingo Schommer]

Hey Jeremy,

That’s really cool, good work! I’m a big fan of sharing code beyond communities and reusing existing libs, 

and hope to see more of that. It allows us to focus on things where we can differentiate,

for example making an awesome shop management UI (rather than payment plumbing).

Also thanks for documenting so well, and adding unit tests.

Its really encouraging to see how little effort is required to

get something running in your proof of concept “pay me” module.

Haven’t looked through the code in detail, just a few notes:

- 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.

- 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.

- 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.

- Let me know if you need help getting the module onto transifex for translation :)

Cheers!

Ingo

--
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.

[Jeremy Shipman]

- How about using Injector for Payment:: set_http_client()? So Payment::$dependencies = array(‘httpClient’ => ‘%$Guzzle\Http\Client’);

Yep, I knew that httpclient could be injected somehow. I haven’t got familiar with how the injection stuff works yet. Thanks for the example code.

- 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 :)

Jeremy