Thread: Sage Pay Go Server interface

ASPDNSF 8 comes with a SagePay/Protx gateway, but it uses the SAGE Pay Go Direct interface which is causing problems with PCI/DSS compliance because technically we process confidential credit card information under the terms of PCI/DSS which requires SAQ (self-assessment questionnaire) D and is rather onerous to comply with. If the Sage Pay Go Server interface was used, it looks like we would get away with SAQ A which is a breeze, relatively speaking. Has anyone implemented the "Server" gateway interface or have any comments on their experience getting PCI/DSS approval for the existing "direct" interface? Is there anyone who would like to develop a "Server" interface for me?

David.

Asking dev to chime in on this. thx.

Having the same issues here, would be very interested to get an update on this.

Likewise.

We need to be able to turn off the bit where it asks for credit card details and simply send the customer to Sage Pay where they will handle that part of the process.

Some kind of helpful response to this would be would be nice, please.

We're looking into adding more of these 'boomerang' type gateways in the future, but there's no set timeframe for specific gateways yet. If you're after this right away, you'll need to purchase the source code and have a developer do that for you. Any of our DevNet partners would be happy to help I'm sure.

I am a developer and we have the source code. To save me trying to fathom it out can you point me in the right direction of the area of code I would need to look at modifying.

I'm surprised this kind of 'boomerang' gateway isn't already catered for to be honest. They've been around a long time, include Worldpay Select Junior which seem to remember worked the same way and I notice is already on the list of gateways to choose from.

Oh well, any pointers would be helpful. Thanks.

Like you saw yourself, we do support several 'boomerang' gateways (Worldpay, Google, Paypal, 2Checkout, International Checkout, etc) - Sage Pay Server just isn't one of them.

Historically there hasn't been much demand for these types of gateways, as conversion rates with them are always drastically lower. You'll get customers who get confused and leave, or who don't trust the other site, who forget to click something to return to the site, or any number of things. Once the customer's off of your site, there's nothing you can do about it. Many store owners are looking more seriously at these types of gateways to make PCI compliance easier, but the conversion hit you'll take is going to hurt a lot.

As for where to make the change, take a look at Gateway.cs and Protx.cs in the AspDotNetStorefrontGateways project as a place to start, but you'll probably want to make a separate class to handle the integration to make upgrades in the future easier.

Did anyone manage to get a SagePay 'boomerang' payment system working? My client needs to switch from the SagePay direct for PCI compliance reasons.

Originally Posted by Chris@Cora

Did anyone manage to get a SagePay 'boomerang' payment system working? My client needs to switch from the SagePay direct for PCI compliance reasons.

Hi Chris.

I started this thread off, and in the end, yes I developed the SagePay Server interface for myself and got it working to my satisfaction last October for a new website for a new client. I'm now in the process of updating another existing client's website to the latest ASPDNSF version and will also be putting in the SagePay Server interface I developed for them. I guess with this client we're about to find out if and how much sales we lose because of a "boomerang" interface. Having said that, on the solution I developed the SagePay site's bits are inline framed into our own site so they see our own https URL, page headers/page layout and so on throughout the whole sales experience so I'm hoping that the "boomerang" is actually pretty well disguised, if not practically invisible. I have a memory like a sieve, but I do recall it took quite a bit of effort to get it all working and reliable, especially the inline frame bit.

David.

Can you develop the SagePay Server interface for us? We're faced with the same problem. Martin