First release for sfPaymentPlugin scheduled

[Antoine Leclercq]

Hi all,

We've been working on the plugin during the last weeks, reviewing and testing various options, checking also how we could make the plugin as flexible but easy to use as possible.

We should release a first base by the end of the week (check http://wiki.github.com/letscod/sfPaymentPlugin). It is going to be strongly inspired from the discussion we've had on the symfony-users mailing list (http://groups.google.com/group/symfony-users/browse_thread/thread/9be2bdb7cff682bf), as well as from various open source contributions and @Marijn branch.

Till now, the option taken has been taken to use a transaction class (sfPaymentTransaction) injected with a gateway instance (sfPaymentPayPal extending sfPaymentGatewayInterface). This gives us a pretty solid and flexible structure so far.

For those who are interested in following and contributing to the first steps of the development, you are more than welcome.

We'll keep you posted.

Antoine

http://letscod.com

[Marijn]

Hi everybody,

First off, Antoine I think its great you're taking the time to get
everybody together:-)

Unfortunately I wont be able to do any coding on this during the
course of this week, not only because I have no time but also because
I think that the current architecture in my branch isn't solid enough.
Let me elaborate on the latter for a bit.

First off we need to do some investigation on the processes of
transaction/payment handling with the different providers before we
can come up with a flow for the user and thus the architecture of the
transaction/payment adapter objects and their interfaces. Before we
have established what their common practices and differences are it's
useless to start coding, we will end up with a lot of rewriting.
Second we need to think of a way to store the data in a decent way.
Our current implementation with interfaces seemed a great start
because any ORM generated object could simply adept the interface… The
problem is that interfaces don't know about magic methods which are
very common for ORM objects so we need to recreate all those methods
for different ORM, not really DRY so to say. Besides that it would be
hard to create a single (or multiple) module and their respective
forms that guide the user through the transaction/payment process.

My comments might feel a little weird since I'm the one already
committing code but that was how I found out about these problems. If
we don't want to create yet another payment plugin my suggestion would
be to think about these problems.

One last thought, I really doubt we need to separate out all the
different providers in different plugins. I strongly urge everyone to
consider moving all providers into just this plugin, if only for
testing purposes and convenience for end users.

Kindest regards,

Marijn

On Jul 21, 5:09 pm, Antoine Leclercq <antoine.lecle...@gmail.com>
wrote:

> Hi all,
> We've been working on the plugin during the last weeks, reviewing and
> testing various options, checking also how we could make the plugin as
> flexible but easy to use as possible.
>

> We should release a first base by the end of the week (checkhttp://wiki.github.com/letscod/sfPaymentPlugin). It is going to be strongly
> inspired from the discussion we've had on the symfony-users mailing list (http://groups.google.com/group/symfony-users/browse_thread/thread/9be...),

[Antoine Leclercq]

Hi all,

@Marijn, thanks a lot for sharing your thoughts.

I do agree with you on the need to continue our researches on the various payments options available and to continue designing a flexible structure. We already did a first bunch of researches, as well as discussions, and I decided to make the plugin move on to development as I think it is difficult and somehow risky to stay in the theoretical path for too long. For sure the first option is going to be discussed and refactored, this is the goal of this approach.

About the data storage, as for me, it is not the purpose of this plugin right now. We want to limit explicitly the plugin job to process online payment using various gateways, and there is already a lot to do. Bringing in ORM and data structure issues is just not what we want right now as it will complexify the development for no good enough reason. Payment data storage and collection has to be fulfilled elsewhere (in an hypothetical online shop? there comes the troll again).

About the plugin separation for the gateway support (sfPaymentPayPalPlugin, sfPaymentPayboxPlugin, sfPaymentGoogleCheckOutPlugin...), the idea at first was to separate the structure from the specific code used for gateway support. Because it will let any developer free to start his own plugin development and document it following the sfPaymentPlugin "how to add support for a new gateway", however I don't have sufficient feedback on that method. I guess we should wait for sympal to get mature to know how it's doing (sympal uses a similar method for content type management).

Thanks for sharing guys,

Antoine

http://letscod.com

[Jonathan]

Just wanted to give you my support for this excellent project, and let
you know you'll have a dedicated user here. Bravo and keep up the
good work.