Refunds and more

[Bernhard Schussek]

Hey everyone,

We are extending one of our websites to use the DirectLink service of
Ogone, which basically is a server-to-server solution for payments,
refunds etc. We do already use their Advanced E-Commerce solution that
works pretty much like PayPal.

I see the possibility of contributing this code to a new
sfPaymentOgonePlugin, but I'll have to check that with the responsible
stakeholders yet. Anyway, did you already plan how such functionality
would be integrated (API wise) in the payment plugin series?

Furthermore, where do technical questions regarding
sfPaymentTransaction et al. go? Is their API already finalized, or are
you still open for suggestions?

Bernhard
--
Software Architect & Engineer
Blog: http://webmozarts.com

[Antoine Leclercq]

Hi Bernhard,

Thank you for your email.

You are welcome to contribute to implement Ogone services, please go ahead and create the plugin when you are ready.

About server-to-server solution, we are aiming to provide this support for PayPal (Web Payments Pro) in a near future but we were waiting for contribution on this particular aspect. So your email comes right on time.

The sfPayment class structure and organization is still in heavy refactoring and any new idea/contribution to ease implementation of standard e-payment techniques are needed. The aim of this mailing list is to receive all technical questions regarding the development of the plugins (including sfPaymentPlugin therefore sfPaymentTransaction, which is still highly uncomplete).

Thanks for your contribution,

Antoine
http://letscod.com

[Bernhard Schussek]

Hi Antoine,

I did not look too much into sfPaymentPlugin yet, but I noticed a few things:

* The classes ending on "Interface" should (as per symfony convention)
be interfaces really. F.i., create an interface
sfPaymentGatewayInterface and an abstract base class sfPaymentGateway.
That would be much clearer (and flexible).
* I don't like the fact that the dynamic setters are realized using
__call(). This may easen the implementation of payment services, but
it makes their usage more difficult, because code completion is not
available.

Don't take my points personal, I really appreciate your effort. :-)

Bernhard

[Antoine Leclercq]

Hi Bernhard,

Thanks for your comments. If I took technical comments personal, I wouldn't be able to do open source.

 * Indeed for the naming of the class. This would be clearer. Do you want to register as a plugin dev and apply the changes ?
 * On the dynamic setters & getters, it has been a long discussion and we started by implementing methods but as those were constantly changing (the class still being in heavy development / refactoring), we decided to use dynamic calls. I do agree with you, the fact that it doesn't allow auto-completion makes it harder to use/discover. We'll move back to real methods once everything is settled.

Antoine

[Marijn Huizendveld]

Hi everybody,

Sore for the absence on the list, fortunately I've been busy working:-)

I agree with the comments Bernhard made and I actually thought we already decided to go down the path of interfaces given that it would be impossible for ORM objects to extend a base class from our plugin.

Like I said earlier I really think there are still quite a lot of things we need to discuss before we can really continue development. Earlier you dismissed my message about storing the transaction data one way or the other, that was a concern of the implementation for the plugin user. I still pretty much disagree with that and hope that we can come up with a more general approach for this.

I would like to propose a slightly different approach than the current one.

We keep all the different transaction gateway classes in the main plugin

One initialization sfPaymentPluginConfiguration checks payment_plugin.yml for configuration values of the different transaction gateways. All the gateways that are provided in this yml file are registered in the event system.

One general module in which the user can select the payment gateway and approve the payment.

A general save method which calls a sfPaymentStorageInterface. sfPaymentStorageInterface can be implemented by different types of datastorage like Propel, Doctrine, XML etc.

A general administration module can than be developed that aids the plugin user in creating a solid backend for their applications.

Because all is combined we don't have troubles with functional testing and unit testing dependencies, their is just one fixture application for testing.

The datastorage can be put in different plugins since their functionality isn't dependent on the rest of the transaction proces.

Just my two cents.

Kind regards,

Marijn

[Bernhard Schussek]

Hi Marijn,

I like what you proposed about sfPaymentStorageInterface and the
seperate storage plugins (sfPaymentStorageDoctrinePlugin,
sfPaymentStoragePropelPlugin). That sounds like a good idea.

Why do you want to configure any payment gateways in a YAML file? I
did not really understand this part.

Considering the discussion of gateways in seperate plugins or not: I
guess if Antoine and the other devs here have come to the conclusion
that seperate plugins are best, than we should go that way.

> Indeed for the naming of the class. This would be clearer. Do you want to register as a plugin dev and apply the changes ?

I would appreciate that. I won't be able to do it until I start work
on the Ogone adapter though.

[Marijn Huizendveld]

Hi Marijn,

I like what you proposed about sfPaymentStorageInterface and the
seperate storage plugins (sfPaymentStorageDoctrinePlugin,
sfPaymentStoragePropelPlugin). That sounds like a good idea.

I'll be working on that in my own branch.

Why do you want to configure any payment gateways in a YAML file? I
did not really understand this part.

One might use different gateways in an application. For example paypal and ogone. They need some configuration up front like the account id for the papal account that receives the money. By putting this in a yaml file the configuration could check for which gateways a configuration is available. Those would than be registered and the others not.

Considering the discussion of gateways in seperate plugins or not: I
guess if Antoine and the other devs here have come to the conclusion
that seperate plugins are best, than we should go that way.

Well, I've made this argument before and I'll do it again, it's a testing hell and I believe that Antoine has run into this with his first release. Besides it only creates more overhead on the plugin developer side while rather adds up to the total size of the plugin (more folders and plugin config files).

Indeed for the naming of the class. This would be clearer. Do you want to register as a plugin dev and apply the changes ?

I would appreciate that. I won't be able to do it until I start work
on the Ogone adapter though.

Bernard, perhaps you could have a look at my branch, non working code and already a little outdated but it will give you some grasp of where I would like to see this going.

Bernhard
--
Software Architect & Engineer
Blog: http://webmozarts.com

Kindest regards,

Marijn

[Bernhard Schussek]

Hi Marijn,

Thanks for your reply. All of your points make absolutely sense. I
will look at you branch once I have time.

[Marijn Huizendveld]

Hi,

I just re-read my previous posts and they all sound a little cranky,
in fact I am because I'm too busy with other stuff before I go on a
holiday next week and hence haven't had the time to work on this
project. Sorry for that guys:-) Its just that I really want this to
succeed and unify all these payment plugins:-D

Kindest regards,

- Marijn

[Antoine Leclercq]

Hi all,

@Marijn, @Bernhard : Thanks for your contributions and comments.

We still have a lot to discuss if we want to come up with a standard and flexible solution. The actual technical choices are going to evolve depending the feedbacks of the community, but I think it is good point that we already have a first functional solution.

Transaction storage

About the transaction storage. At first I thought it was not the purpose of the payment plugins, that it should be handled by the eventual shop / application the plugins would be connected to. However, after reading you guys and thinking about it twice, it would be a lot easier for the developer if it was handled directly by the payment plugins. I'd be really interested in getting some more feedbacks on this.

About the interfaces, I am interested to know how you (@Marijn) would manage the gateway objects. For me, the ORM has nothing to do with the gateway but will be linked to the storage which will be injected in the transaction. Am I missing something ?

Gateway support separated by plugin

I think on this part we do really have to think about the pros and cons.

 * Separated :

  + Official developer lead per plugin (easier to identify)

  + Easier to certify / validate (i.e. my last message on Paybox potential validation)

  + Version managed installation

  + Structure / gateway support separation

  + Easier to document in symfony plugin repository

  - Harder global tasks : test, update...

 * Unified in a single plugin :

  + Easier to run the tests

  - When you modify the core classes (sfTransaction or sfGateway), you have to test and update each gateway support class before packaging a version. It's not a problem in the separated way as the plugin versions management (package.xml) deals with version compatibility.

 Again, as I said many times, I don't have sufficient feedbacks on that method. We need some more people to join this discussion to dig. Right now I don't think it's blocking anything though...

YML configuration & sfPaymentPluginConfiguration

Sounds a good idea. Right now the gateway configuration is stored in the app.yml of the application but it is more related to the project.

So far, for those who installed the plugin, we have a functional first version. However, it may lack some flexibility and features. We are implementing Paybox Direct which is the direct server-to-server payment handling, we'll see how flexible is the method.

I'll post a message on the symfony-users mailing list to bring some more interested developers in.

Antoine