Search

A new extension, "Symphony Checkout" is now available for download. Comments and feedback can be left here but if you discover any issues, please post it on the issue tracker.

Symphony Checkout is an extension that aims to bring more robust payment functionality to symphony. Inspired by paypal payments and PGI loader, Symphony Checkout provides a Transaction field that can be used to store the relevent data to process a transaction.

A 'Transaction' field goes into a section whoes entries represent a payment. The field can then map in data from the other fields in the entry (such as names, addresses, emails etc) in order to pass the relevent data to a payment processor. The field can then post the data to the payment processor via an event and then reconcile the transaction into the field.

Currently only sagepay server integration is supported but a test payment gateway class is provided which can be extended for any other payment gateway.

Will definitely have a closer look during one of my next projects. May take some time, though, so just stay tuned for feedback a little longer... ;)

You wrote it's 'inspired' by PGI loader. Can you be a little clearer on that? Does it not actually implement the interface provided by PGI loader and is therefore not compatible with other payment extensions using that interface?

I too would like to know this. The PGI Loader was set to be more or less the defacto way to create payment gateways for Symphony, after a little more testing and extension, so to side step that would be an issue for me.

We have a project coming up that requires SagePay integration, and I was expecting to use the PGI Loader, but now I will most likely be using this one.

This raises the question then, could this be engineered to extend the PGI Loader and provide it's gateway through that?

Hi

Sorry for the delay in response. In terms of PGI_Loader the extension isn't currently compatible. It's been a while since I was working on this so this may not be entirely accurate but the rational for this is as follows:

The PGI_Loader provides a very abstract way for processing payments but doesn't really do anything other than provide a common interface. This could have been used for development of this sagepay extension however I wanted to provide a more substantial interface. What I mean by this is that the checkout extension provides essentially the same functionality as the PGI loader but with some significant additions, most notably a field.

The extension is structured such that there is a common gateway interface (similar to PGI loader) but more methods are required in order to handle the saving and processing of responses.

Currently the PGI loader servers as an interface for loading a payment gateway and not much more. The checkout extension serves as a common interface for loading a payment gateway, populating a transaction with data from symphony and then saving the response back into symphony. As such it is a much more end user friendly extension.

It is structured such that there is an abstract gateway class (similar to PGI loader) that additional gateways can be added from. Currently only sagepay is implementde but it would probably be relatively easy to port PGI_loader extensions into this format.

It probably would make sense to combine this with PGI loader in someway but I haven't really thought about it much.

@designermonkey just to clarify your last question, this extension isn't just a gateway it's more of a 'checkout' with one gateway currently implemented (sagepay!)

Hope that all makes sense, let me know if you have any further questions.

Thanks for explaining all that David, I shall have a good look at this soon as I'm in need of SagePay on an upcoming project.

As I'm still new to SagePay, I see there's the server integration in this extension. Does that work with the iframe and server API that they have on offer? Our client has that requirement with their PCI compliance.

Thanks in advance.

I'm sure you've already seen it but here is info on PCI:

With the server integration (that's what the extension uses), there is no actually PCI compliance issues as you do not store credit card information at any point in time.

The extension theoretically supports the inFrame (iFrame) integration but this hasn't been tested yet so I anticipate that it probably isn't stable yet. The inFrame integration needs some fiddling to integrate in terms of how you break out the frame at the end but the project I'm working on hasn't reached that part of development yet.

I'll be working on the iFrame code over the next few weeks though so I'll update it and write a bit of a read me when I get round to it.

@designermonkey, I don't check these forums that regularly but if you have any questions or difficulties then feel free to email me (dave [at] veodesign.co.uk)

David, thanks for your offer of info and help, I will get in touch at some point soon. Just running through a couple of other builds at present, and when I can hand them to the team, I'll give you a shout.

Create an account or sign in to comment.

Symphony • Open Source XSLT CMS

Server Requirements

  • PHP 5.3-5.6 or 7.0-7.3
  • PHP's LibXML module, with the XSLT extension enabled (--with-xsl)
  • MySQL 5.5 or above
  • An Apache or Litespeed webserver
  • Apache's mod_rewrite module or equivalent

Compatible Hosts

Sign in

Login details