X-Cart and PCI DSS / PA-DSS compliance

just wondering · #**141** 02-04-2010, 07:34 AM

SagePay do the same thing with their Form system.

wolff · #**142** 02-04-2010, 08:45 AM

The same can be said for Quantum Gateway, as I think was stated earlier in this thread...

Regarding SEO: I'm not sure any of this matters in regards to SEO - All I'm talking about is the actual collection of the credit card data - an iFrame imbedded at a specific point in the payment page itself.

I have been watching a number of different cart forums regarding the whole PA-DSS issue, and it seems clear to me that the vast majority of them (especially the open source, of course) will not be compliant to this standard by the deadline, if at all.

Should that be the case, users of these carts will need to either embrace a third party gateway - which many contest will reduce sales due to the redirection to a different site - or find a PA-DSS solution, which means abandoning the cart they are invested in.

In many of these forums, the topic of iFrame comes up because it technically solves both problems - eliminates the application compliance requirement, as well as the problem of lost sales due to the user being diverted to another site.

I was initially turned off to the thought - but what has peaked my interest is the fact that certain gateways are specifically offering this as a solution now, complete with API's.

It seems that among all of the discussion, not many have gone this direction as of yet, and I am really interested in the pluses and minuses. The technology is obviously there, but...

1) Are there anti-iFrame technologies or certain browser settings that would cause the iframe to not show - and if so, can they be detected such that a normal redirect becomes the failsafe?

2) Is there a javascript solution, either using iFrames or as an alternative to them - such as how the commonly accepted Flash integration method works - that might make this concept more widely accepted, and have the redirect become the failsafe if no javascript detected?

3) Does having an iFrame invite site hacking, or automatically lower security such that an injection is more likely? I really question this when considering the fact that a number of gateways are promoting this as a valid solution.

Overall, it seems this method deserves more attention, if at the very least to provide an alternative to consider...

As an aside, I am really wondering why 3rd party gateways still create a reduction in sales - after all, in the beginning, these were relative unknowns, and getting redirected at the point of sale seemed insecure. If I recall, redirection attacks were just in their infancy at the time, so the concerns were certainly valid. But now, many are very well known, paypal, google, amazon, etc. and in light of all of the compliance & cc issues, it would seem some of these would become more accepted to the public than remaining within a site that may or may not be following the proper security practices. The dynamics have changed, and the attacks are coming at the server level, behind the scenes. But from everything I'm reading, it doesn't seem to be playing out that way... ???

just wondering · #**143** 02-04-2010, 09:02 AM

Quote:

Originally Posted by wolff

1) Are there anti-iFrame technologies or certain browser settings that would cause the iframe to not show - and if so, can they be detected such that a normal redirect becomes the failsafe?

A Firefox Addon called "NoScript" can sometimes block iframes, depending on what settings are being used on it. If the user green flags the iframe and/or the page it's loading, it'll allow it to work from there on in.

amy2203 · #**144** 02-05-2010, 01:52 AM

you can also edit the payment pages in Worldpay so they match your site, you can edit the 'header' and 'footer' which is basically everything you want to be before the form, and everything after. You can also modify the button colours to match,

hth

wolff · #**145** 02-05-2010, 05:11 AM

Thanks for your replies...

Amy, I assume you mean as a redirected 3rd party solution...?

If I'm reading you right, that would still result in a redirection - a separate URL in the address bar - and for whatever reason, it seems there are users that are still not as trusting of a redirected payment process, even with a known provider.

It's unfortunate, but it seems that many end users are just not aware that the security issues of today are more likely encountered at a site providing self hosted payment handling incorrectly (i.e. not pci compliant, etc.) than one that redirects to a known and trusted payment gateway.

I tried both ways a couple of years ago, and definitely experienced a difference between integrated and redirected payment handling - in my experience, the integrated always performed significantly better. With my online advertising costs vs. overall profit margin, I just can't afford to test those waters again and risk losing even a small percentage of conversions.

That's why this iframe concept has me intrigued...

kulture · #**146** 02-05-2010, 06:21 AM

Quote:

Originally Posted by wolff

So, after reading through this thread, am I correct that a valid option to anyone using x-cart that wants to be compliant and avoid the PA-DSS software requirements, is to integrate a compliant 3rd party payment gateway using an iframe?

A related question: With all of the iframe injection issues that have gone around, even if the above is true, would there be possible problems in relying on an iframe for this purpose?

Thanks

Yes it seems that an Iframe is a good way out of the PCI/PA-DSS problem. If you look at the UK payment gateway sapepay, they have a Iframe interface (called their "Server" interface) and they describe it as their most secure interface.

I suspect that the iframe injection situation will only be a problem here IF browsers start to have an option to block iframes.

BritSteve · #**147** 02-05-2010, 06:28 AM

I think the problem with redirecting or using an iframe is that xcart doesn't feed back the transaction result or the details to the cart. If this is the case, you would have to log in to the gateway, look for the result and either approve or decline the order.

Would be nice to get some clarification from xcart as to whether they support these methods.

Steve

amy2203 · #**148** 02-05-2010, 06:29 AM

Quote:

Originally Posted by wolff

Thanks for your replies...

Amy, I assume you mean as a redirected 3rd party solution...?

yes, the customer is redirected to the worldpay site.

It probably depends on your customer base, not all customers even notice the url change,

koz · #**149** 02-05-2010, 12:09 PM

With the newest release of x-cart 4.3, you are now able to use Cybersource Hosted Payment as an option. They allow you to *totally* modify the look of this page.... right down to the color of the buttons and what the buttons say. You're also able to include your own header and footer to further make it consistent with your site.

cautious · #**150** 02-07-2010, 04:11 AM

My previous post was either lost or dropped. I am reposting.

On the original issue: There is no need to encrypt software for PCI-DSS compliance - unless there is a hidden agenda to make difficult user mods and 3rd party mods.

Regardless of whether or not the underlying software is obfuscated, if you save a customer's credit card # and the CVV/CVV2 then you're not compliant. I have read policies that claim security and therefore compliance because they claim to delete these data after 30 days from their database.