SagePay Form vs Inline payment page conversion

[Sam Boogie]

Hey Guys,

Im pretty set on using SagePay for my payment processing but am stuck deciding between using their 'form' version where the customer is redirected to the sage pay site to make payment versus getting a dedicated server and having the payment run 'inline' with the rest of the checkout process.

Just wondering if anybody out there has tried both and what differences there were in checkout conversion rates?

Thanks in advance guys

Sam : )

 

[PMSToys]

If you're big on branding and want your customers to feel as though everything is happening "in the same place" then inline would be the preferred option.

Some "nervous" shoppers might feel that they are being phished if they are taken away from your site to fill in credit card details on a seperate site. I guess you can't please everyone though and have to do what is best within your budget.

Personally I've purchased for my own needs through both types of payment and don't feel disadvantaged either way.

 

[Kerrib4]

This is something I am also interested in hearing opinions on. On my website I have Form payment (when they are taken away from my site). I have had some people go to the checkout and fill in all of the details and choose shipping, but then leave without completing the transaction. I am thinking maybe they didn't like being taken away from my site. To have the transactions take place on my site though, would be too complicated for my shopping cart to set up for me apparantly. If I could have this on my site I think I would.

 

[PMSToys]

Kerrib4,

If they got they far, ie filling in requisite fields etc, then it seems unlikely that they abandoned the checkout because they didn't like being taken away from the site. Does this happen a lot for you?

Perhaps they just changed their mind?

Quite a few times I've got myself to the Confirm Payment button and thought, Nah, can't really afford this, might come back next month.

It's frustrating as a merchant though because you have to try and 2nd guess the reason for the bailed carts.

I did look at inline myself but decided the volumes vs cost wasn't really profitable for me right now.

 

[Sam Boogie]

Yeh, I know as a consumer I much prefer it inline, provided the site looks reputable, if the site looks a bit dodgy then I actually prefer paying through the sagepay site!

Anyway, Im hoping someone will have had experience of both of these approaches on a respectable looking site!

: )

 

[Kerrib4]

Kerrib4,

If they got they far, ie filling in requisite fields etc, then it seems unlikely that they abandoned the checkout because they didn't like being taken away from the site. Does this happen a lot for you?

Perhaps they just changed their mind?

Quite a few times I've got myself to the Confirm Payment button and thought, Nah, can't really afford this, might come back next month.

It's frustrating as a merchant though because you have to try and 2nd guess the reason for the bailed carts.

I did look at inline myself but decided the volumes vs cost wasn't really profitable for me right now.

Yeah your right they could have just changed their minds. I thought they had maybe filled it out, got taken to the sagepay site, and not been sure about it so hit the back button. I could be wrong. I would prefer the transaction to take place on site though.

 

[Kerrib4]

Yeh, I know as a consumer I much prefer it inline, provided the site looks reputable, if the site looks a bit dodgy then I actually prefer paying through the sagepay site!

Anyway, Im hoping someone will have had experience of both of these approaches on a respectable looking site!

: )

As a consumer I prefer it to be inline too. As long as it looks secure.

 

[James1980]

Are we talking about the Sagepay inFrame system? This allows you to securely embed the form into your own website, without the need for a dedicated server.

You do, however, need to get an SSL certificate - otherwise savvy users will notice a lack of the https padlock and assume your website is insecure.

Sage Pay Go with Server & inFrame integration




James

 

[Sam Boogie]

According to the Sage Pay application process you seem to need a dedicated box for anything other than their form offering. I took a look at the link you provided but it doesnt really say either way although it does mention installation problems on rented boxes.

Anybody know if you can go and see Sage in person rather than trying to work stuff out from their site?!

 

[Kerrib4]

Sam Boogie,

I'm not too sure if you can actually see Sagepay in person, but have you tried calling their customer service line? I've always found them to be very helpful.

 

[Sam Boogie]

call me Sam : )

Yeh, Ive called them before when I tried applying the first time round and like you said they are very helpful. I'll try them again tonight

: )

 

[logicfusion]

I think SagePay form is where I am heading.

I really can't be bothered with the associated hastle of PCI compliance for Direct or using the Sage Frames technology.

You can add your own logo to the Sage Pay form to assist with branding.

As a customer, I feel a lot safer being redirected to the SagePay site than filling in details directly.

I'm using ZenCart. The amount of hacks / attempt hacks reported on their forums does worry me. The most important thing I guess is to make sure you keep your sofware bang up to date, correctly set read/write permissions on your site etc.

 

[Optegris]

According to the Sage Pay application process you seem to need a dedicated box for anything other than their form offering. I took a look at the link you provided but it doesnt really say either way although it does mention installation problems on rented boxes.

Untrue. You do not need a dedicated or even a VPS server to use the direct payment method. Your host does need to be able to go through a PCI scan though which some cheaper hosts will not be able to do on a shared basis.

It is easier to get through PCI scanning on a VPS/dedicated box but it's not impossible on shared at all...

 

[logicfusion]

Untrue. You do not need a dedicated or even a VPS server to use the direct payment method. Your host does need to be able to go through a PCI scan though which some cheaper hosts will not be able to do on a shared basis.

It is easier to get through PCI scanning on a VPS/dedicated box but it's not impossible on shared at all...

Is it not true that most of the PCI compliance requirements are pretty much controlled by your actual host?

So, you could pass PCI on your first quarter scan and fail on the second due to a setting your host has made - that you have no control over.

I'd be really nervous about such a scenario occuring. Presumably if you fail PCI - your merchant provider can withdraw your services?

For me, Sage Form sounds like a safer bet.

 

[Optegris]

Yep the majority of PCI requirements are server side but the software you use also plays a part i.e. ensuring it does not store card details etc...

If a host fails a previously approved scan then it is likely they will rectify the situation as they were previously supplying a PCI secured service. If they don't/won't then find a new host

Either way, the merchant provider won't immediately remove the facility if the host fails as they won't actually know about it. So the host would have a reasonable amount of time to rectify the situation. Most merchant providers can/will ask for proof of compliance at any time though...

 

[PMSToys]

upnorthal,

I'm also using Zen cart. The attempted hacks only work if your php config is weak and you haven't renamed your admin folder or have named it something easy to determine.

I get daily attempts to access a robots.txt file to see if I have disallowed bots to crawl the admin folder. However, that file doesn't exist.

I find Zen pretty solid, although I'm drifting off topic here, apologies.

 

[Sam Boogie]

Cheers guys, you're quite right, Ive just spoken to Sage and I dont seem to need dedicated hosting although application process seems to guide you towards form if you dont have it!

They also said I could apply for whichever style I like and easily change at a later date, even said I could run form vs server in an A/B split to see which one converts better!

So far so good with Sage. : )

 

[kulture]

I would NOT use the sagepay direct interface any more. If you want an in-line process use the sage pay server in Frame interface. This is because by 1 July 2012 if your site stores OR TRANSMITS credit card information, then you have to be using a PA-DSS approved payment application. I am not sure if ZEN is or ever will be a PA-DSS approved application.

If you use the form or iframe server interface, then you take your site out of scope for this requirement.

 

[Optegris]

Just had a very enlightening conversation with an approved QSA about this situation and our own eCommerce software package.

As the software we supply is hosted on our platform, the onus for being PCI compliant falls to us. Now as we are already PCI compliant there is actually no requirement for our store owners to provide their own PCI-DSS compliance.

The PA-DSS only applies to applications that can be purchased and installed anywhere such as Zen cart, OSCommerce, CubeCart etc...
This does mean we will have to tweak our sales page a little to show this and insist the software is hosted with us but at £60 pa for hosting it's hardly a big issue...

 

[kulture]

Interesting plug.

Also somewhat misleading. The retailer is the one who has a merchant account. The merchant provider requires that all merchants are PCI compliant. Being compliant is a bit more than having a PCI compliant host, or a host running software in a PCI compliant environment. It is the retailer/merchant who has to get their name ticked on the list of all PCI compliant merchants.

Therefore it is up to the retailer to persuade THEIR QSA that they are complaint by using your services. AND by following all the other necessary procedures.

Personnaly I would be unable to persuade my QSA that your software need not be PA-DSS compliant as to me you are not providing a BESPOKE service but are a third party provider. That said IF my QSA agreed with yours I would be happy, but personnaly I would rather not take the risk.

 

[Optegris]

Well all I will say is that I spent a good hour discussing this with a Visa approved QSA to ensure we are compliant and I'm happy that we are. Of course if you think they are wrong and you are right then that's up to you.

 

[kulture]

It is not up to me. It is up to each and every one of your customers, if they have their own merchant accounts, to satisfy for themselves, that they are PCI compliant.

I would not like to be in your position if they took your word for it, and subsequently found that their merchant provider does not agree.

Regardless I saw your post as a slightly off topic plug for your services, and we are now way off the original topic of this thread.

 

[Optegris]

Like I said, you are welcome to your own opinion, I am just going on advice given by someone who knows what they are talking about.

 

[kulture]

LOL, in my experience, most of the front line staff at many QSA companies do not know what they are talking about. They have a script to follow and ask questions and thus take you down the route depending on your answers. If you ask them what the questions mean, and try for detailed explanations then confusion can arise.

 

[Optegris]

OK two points.

Firstly this wasn't some major company I was dealing with here, it was a smaller UK assessment centre who have worked with major brands. I was dealing with one of directors of the business.

Secondly I do happen to know what I'm doing in this industry and certainly know the difference between fact and fiction.

You obviously disagree with what I've said, that's your choice, but don't patronise me by insinuating that I don't have a clue.

 

[kulture]

I am not trying to patronise you. Its just when you make such a bold statement

" Now as we are already PCI compliant there is actually no requirement for our store owners to provide their own PCI-DSS compliance."

That I spoke out. Now if you had said that your customers do not have to worry about PA-DSS approved payment applications, then you would be correct. (although why 3rd party hosts like yourself who provide carts as a service get exemption is a different matter).

Your post, uncorrected, would seem to imply that your customers do not need to worry about PCI compliance. That simply being your customers means that they are compliant. It is possible that you did not mean to give this impression.

All your customers do need to achieve PCI compliance. I refer you to
https://www.pcisecuritystandards.org/pdfs/pciscc_ten_common_myths.pdf

and

https://www.pcisecuritystandards.org/pdfs/pcissc_getting_started_with_pcidss.pdf

Now I am sure that your customers, if they have their own merchant numbers, will probably fall under SAQ validation 1, namely "Card-not-present (e-commerce or mail/telephone-order) merchants, all cardholder data functions outsourced. Does not apply to face-to-face merchants". They will have to then fill in the Self Assesment Questionaire A, and adhere to the principals and procedures involved.
This is a relatively painless process, BUT it has to be done.

I know that you could point out in the first paragraph of the PCI getting started document it says "The standard includes 12 requirements for any business that stores, processes or transmits payment cardholder data." Seems to exempt your customers, as they never store, process or transmit cardholder data. BUT If you look at the PCI overview document https://www.pcisecuritystandards.org/pdfs/pcissc_overview.pdf
Half way down the first page, on the left under the heading "PCI Standards Include :" and the sub-heading "PCI Data Security Standard:" it clearly states

"If your business accepts or processes payment cards, it must comply with the PCI DSS."

So I have no intention to be patronising. I am simply trying to stop misconceptions.

 

[Optegris]

Frankly I'm getting bored of repeating myself. I am well aware of the PCI standards and the misconceptions. I am relaying what I have been told by an expert in their field but obviously that's not good enough for you.

And for the record we are not a "third party host who provides a cart". We wrote OMC from the ground up and I've already explained why we are exempt but you seem to be more interested in labouring your point.

 

[kulture]

OMC is a cart, is it not? You provide your cart, OMC, as a service do you not? So you are effectively a third party host who provides a cart as a service. I dont get your point.

Your argument seems to be that a QA person who is an expert says that your customers are PCI compliant because they use your services. My argument is that the PCI standards organisation, in all their documents, say that your clients will not be compliant just by using your services. That they have to fill in the SAQ A and adhere to the processes.

In the end the point is immaterial, as it is not up to you or I to say whether your clients are compliant. It is up to their merchant providers.

I will end this with a quote from the official Visa Europe site

"Merchants adopting secure technology and solutions whose implementation may reduce the scope and size of their PCI DSS compliance validation process need to discuss their plans with acquirers, to ensure their plans satisfy the minimum level of security set by the card industry through PCI DSS.

All merchants, regardless of size, should comply with PCI DSS. Visa Europe has produced simplified guidelines for small merchants. "

If you are interested, this can be found on this page.
http://www2.visaeurope.com/merchant/ais/requirements.jsp

but of course you are not going to bother to read this, after all your expert has told you everything you need to know, and as he is an expert he must be right.

 

[Optegris]

As I said several times, I would rather base decisions on experts in their field rather than opinion.

 

[kulture]

I am sorry if you feel that I have insinuated that you do not have a clue, or that I have been patrionising. That is certainly not my intent. Perhaps you should re-read the posts however. I have NEVER said that your company is not compliant. (as you imply in your post of 11:46). All I am saying is that your customers have to be compliant TOO, and that they need to do more that just be your customers.

I have backed up my "opinion" with references from authorative sources. Namely VISA Europe, and the PCI Standards Organisation.

In re-reading your posts, I see that you equate the quotes and documents from the PCI standards organisation as "fiction" verses your expert's opinion as "fact". I see that this is a pointless discussion. Your tag "openmind" is clearly ironic.

 

[Optegris]

I have not once stated that the references are fiction. As far as I can see this has become a pointless discussion as you and I are not going to agree.

 

[logicfusion]

So what happens if a customer sets their own admin password to 'password'. Is that not something a PCI tester would pick up on, and thus possibly mean a customer breaches PCI compliance?

How can you control any backdoors your customers may leave open?

 

[kulture]

If I am correct, and it is up to the customer to be PCI compliant, then they have to fill in the questionaire AND stick to the implied procedures which include haveing good passwords and changing them frequently.