SagePay plugin

[rich_81]

Hi all,

I'm looking to use the sfPaymentPlugin classes to create a plugin that
will use the SagePay payment interface (http://www.sagepay.com/), as
I've used SagePay previously for a few UK-based e-commerce sites - the
most recent being with Symfony where I've developed a plugin of sorts
already, so it makes sense to port this to the sfPaymentPlugin
interface now! :-)

From reading the previous discussions on this group earlier in the
year, I was wondering whether there was any plans/thoughts/
developments on the following at all?

* Storage of returned data from the payment processor - SagePay,
particularly in their advanced product (Direct) - allow you to store
things like authentication codes so that you can perform refunds at a
later date. Are there any plans to introduce some form of model/
database storage for things like this?

* Transaction identifiers - with SagePay, they request a unique
identifier per transaction, eg an order ID number/reference. I'd
personally see this sitting with the original app rather than with the
plugin (as I've seen discussed) - the plugins should facilitate
payment rather than become almost an integral part of the e-commerce
process. Maybe an optional method to generate one if one isn't
supplied?

I'm also aware that there were plans to maybe change some of the
structures/methods in the base classes for sfPaymentPlugin - is this
still the case? Is it best to work with the branch rather than the
trunk code, if I'm starting out now?

Apologies for the long post, and thanks in advance :-)

Rich.

[Antoine Leclercq]

Hi Rich,

Great news for SagePay.

sfPaymentPlugin is now in heavy refactoring as we are reviewing, refactoring and improving its structure.

We haven't yet planned the storage of specific payment transaction parameters but as you bring this on the table today, I think it's worth it integrating it in the next release.

About the transaction identifiers, and the scope of the plugin, the discussion has been prolix. The plugin has to bring a maximum number features related to the payment and transactions in order to make the developer's life easy when dealing with multiple payment gateways. I think this includes providing support for transaction identifiers (generation & storage). However this specific part could be optional.

As the payment plugin is being refactored right now (check jiappo's branch), I think it'd be great if you could contribute to the discussion about those improvements. We'll meet online (chat & shared code) next week with some of the contributors of the project in order to have a real time discussion about the next version.

Antoine