Re: X-Cart and PCI-DSS / PA-DSS compliance
 

Some QA people would say that you store the credit card number in the memory of your server as it is your server that serves up and processes the credit card form. Further they may say that x-cart is a payment application, and as such it is not a PA-DSS compliant software and thus on 1st July you must stop using it.

The crux of the problem is the opinion of the person who says you are PCI compliant. Clearly as it is your server that hosts the payment form, it is more vunerable to hackers than a form hosted on say Sage's server. Sooner or latter you will be asked to ensure that your server is PCI compliant (and shared servers CAN be PCI compliant).

Re: X-Cart and PCI-DSS / PA-DSS compliance
 

It won't be a simple upgrade. However, since we will use the same css-based skin templates, I believe it won't require complete redesign either.



As far as I understand the standard, if credit card data ever touches your server (and it does with SagePay Direct: php scripts receive it from a customer's browser and send it to a SagePay's server), your server is in the PCI scope.

Although the SAQ-C form omits some requirements, I guess it still requires you to use a PA-DSS verified payment application (the one that transmits card data from a customer's browser to a gateway's server) on a PCI-DSS compliant server (there is a special section related to Shared Hosting in the standard). X-Payments will be a PA-DSS verified payment application that processes SagePay Direct payments in a PCI DSS compliant manner.

Re: X-Cart and PCI-DSS / PA-DSS compliance
 

That will make you PCI compliant without the X-Payments addon. Unfortunately, on top of PCI compliance VISA is mandating that all merchants use PA-DSS certified payment applications starting July 2010. X-Cart is not PA-DSS certified. X-Payments will be PA-DSS certified so you'll need to go to X-Payments at some point.

Re: X-Cart and PCI-DSS / PA-DSS compliance
 

Cheers Ralph. :)

Re: X-Cart and PCI-DSS / PA-DSS compliance
 

Weird that they don't require a server scan. Card numbers pass through your server so its in PCI scope. I would run the quarterly server scans anyway as PCI clearly requires them in this case.

What you are seeing is a result of the fact that the card brands leave it up to the acquirer to decide what proof of PCI compliance is required from small merchants. So it will vary what hoops any particular merchant will need to jump through. We will probably see the same thing with the PA-DSS mandate. A few months back someone posted that they couldn't get a new merchant account because X-Cart isn't PA-DSS certified. But overall, I think some acquirers will enforce it and some won't especially early on. Over time most will enforce it.

Re: X-Cart and PCI-DSS / PA-DSS compliance
 

Hmmm. I'm assuming ... more hoping ... that Streamline will turn around to us and sat "You have to get a Scan, bla bla bla moan moan moan..."

Re: X-Cart and PCI-DSS / PA-DSS compliance
 

I just wish we could get a working copy of x-payments to see what will be requires to integrate with our web sites. We are getting extremely close to the dead line, and no hint to what we are going to use.

Re: X-Cart and PCI-DSS / PA-DSS compliance
 

Has anyone actually received a notice from their processor informing them that their cart needs to be certified and compliant?

I haven't received any notification so far.

Steve

Re: X-Cart and PCI-DSS / PA-DSS compliance
 

Someone has been denied a merchant account because X-Cart is not PA-DSS certified.

http://forum.x-cart.com/showpost.php?p=263045&postcount=5

This is because the VISA mandate phase kicked in last year that requires acquirers to only board new merchants who are PCI-DSS compliant or are using software that is PA-DSS compliant. Apparently, some acquirers are missing the "or" in that and are requiring PA-DSS compliance for new merchants. In July of this year the next phase of the mandate kicks in requiring acquirers to ensure their merchants are only using PA-DSS compliant applications. No "or PCI-DSS compliant" in the July mandate.

Re: X-Cart and PCI-DSS / PA-DSS compliance
 

While I haven't received any personally, I know someone that got a notice from his processor (I think Wells Fargo) that he will be billed an extra $20.00 a month for being "non-compliant" and charged at the "card not present" rate even if the card is swiped. He figures for all of the stress and hassle involved it is an acceptable cost of doing business.

Re: X-Cart and PCI-DSS / PA-DSS compliance
 

We get scanned daily and are PCI compliant, and I fill in the SAQ-D every quarter and send it off you our processor. We would also be charged the $20 a month if we didn't send the stuff to them.

We accept FAX credit card information, so we need to fill in the SAQ-D because we have access to the credit card numbers.

I will wait and see if our processor checks on the cart we are using. X-payments doesn't sound like a good solution for us, unless we make some significant changes to it, or the way we extract data for our other systems.

Steve

Re: X-Cart and PCI-DSS / PA-DSS compliance
 

I changed processors because they were going to charge a 20.00 a month no compliant fee. They also required a membership at a scan company of there choice that was 700.00 a year, did not matter if you had the scan report or not, you had to use theirs.

Re: X-Cart and PCI-DSS / PA-DSS compliance
 

As for changes to x-payments, they said the code will be encoded, so I do not think we will be able to alter the code

Re: X-Cart and PCI-DSS / PA-DSS compliance
 

Why is RBS-World-pay gateway absent from this list?

As you know, we have spent a lot of time and money developing our site using X-Cart, based on the fact it supported a payment gateway we could use here in Asia...
i.e. without world-pay support we have wasted our time it seems...

Before I hit the roof and start getting really hacked off... please explain ASAP, what our options are going to be? - thanks, Asiaplay

Re: X-Cart and PCI-DSS / PA-DSS compliance
 

A quote from PA-DSS standard:


With the RBS Worldpay's gateway integrated with X-Cart 4.x (I mean Hosted Payment Page - HTML Redirect API) customers enter credit card data on a Worldpay's server, and neither your server nor X-Cart stores, processes or transmits cardholder data. So, from the standard's point of view, your X-Cart is just another web application installed on your server. As far as I know PCI DSS standard doesn't require all web applications to be certified as PA-DSS compliant. So, you don't need X-Payments in order to be PCI DSS compliant. Just make sure that all CC functions are disabled in your X-Cart. I believe it would be better if you clarify it with your acquirer. And I would appreciate if you let us know their response on this matter.

Re: X-Cart and PCI-DSS / PA-DSS compliance
 

Dear Xplorer,

Ok - thanks... I will discuss this with more with RBS Worldpay then ;)

I guess we will have to get PCI Compliance Vulnerability Scanning done quarterly and complete the self assessment document anyway - there seems no way around this part since our site is modified heavily... so even if X-Cart was PA DSS validated (which I understand it isn't and never will be), it seems we can not avoid that cost anyway...

Cheers, Asiaplay

Re: X-Cart and PCI-DSS / PA-DSS compliance
 

I have just spoken to Sagepay who tell me that because we use vspform it is they who have to be pci compliant and not our site.

However because I also take payments via the phone I have to have a 'certificate'.

Looking more into this but if this is correct then that's really good news as am currently looking for an alternative shopping cart in fear that x-cart will not be ready in time.

Re: X-Cart and PCI-DSS / PA-DSS compliance
 

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?

If this is true, wouldn't it be a good idea for someone to start cranking out iframe integration modules for the various 3rd party gateways?

...or am I missing something with all of this?

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

Re: X-Cart and PCI-DSS / PA-DSS compliance
 

I don't trust iframes as far as I can throw them. They are evil when it comes to SEO and as you say, iframe injection is a real & serious worry. I point blank refuse to use them anywhere.

Re: X-Cart and PCI-DSS / PA-DSS compliance
 

USAEpay appear to have a configurable page that is hosted on their secure server, and can be made to look like it is still on your site. Haven't tried it yet, but it may be a solution.

The only possible drawback is that xcart may not support this method.

Steve

Re: X-Cart and PCI-DSS / PA-DSS compliance
 

SagePay do the same thing with their Form system.

Re: X-Cart and PCI-DSS / PA-DSS compliance
 

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... ???

Re: X-Cart and PCI-DSS / PA-DSS compliance
 

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.

Re: X-Cart and PCI-DSS / PA-DSS compliance
 

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

Re: X-Cart and PCI-DSS / PA-DSS compliance
 

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...

Re: X-Cart and PCI-DSS / PA-DSS compliance
 

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.

Re: X-Cart and PCI-DSS / PA-DSS compliance
 

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

Re: X-Cart and PCI-DSS / PA-DSS compliance
 

yes, the customer is redirected to the worldpay site.

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

Re: X-Cart and PCI-DSS / PA-DSS compliance
 

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.

Re: X-Cart and PCI-DSS / PA-DSS compliance
 

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.

Re: X-Cart and PCI-DSS / PA-DSS compliance
 

That is correct. I don't know where vendors get the idea they need to do this. Its not very friendly to those of us who bought the software because they get the source code and can modify it.

No, storing card numbers is allowed by both PCI-DSS and PA-DSS and storing CVV/CVV2 is allowed PRIOR TO AUTHORIZATION only. Any card data must be stored encrypted using strong key management and once the card is authorized CVV/CVV2 must be deleted using a secure deletion method (e.g. multiple overwrites). There are a lot more hoops to jump through if you choose to store card numbers. I wouldn't recommend any small merchant store card numbers as meeting the requirements is a significant undertaking.

Re: X-Cart and PCI-DSS / PA-DSS compliance
 

I may be reading too much into the compliance requirements. My understanding is that, regardless of whether the stored data is encrypted or not, both numbers should not be stored together. The CVV should not be stored at all.

The idea is to use it live on demand. I mean, there should be no storage prior to authorization. Just use the number and the CVV to get the authorization, discard the cvv and optionally store the main# if the shop has the capacity to safeguard it and strongly encrypted. There is no need to ever store the cvv, it should be treated like the second part of a two factor authentication.

If both the cvv and main# are stored encrypted together prior to authorization, an attacker can steal the storage and apply brute force. And it'll be worth it because, for a big merchant, the reward is that the cracked storage will yield millions of complete cvv, main# pairs ready to use.

Re: X-Cart and PCI-DSS / PA-DSS compliance
 

You are reading too much into it. Take a look at PCI-DSS 1.2.1 on page 5, footnote 2. It says "Sensitive authentication data must not be stored after authorization (even if encrypted).". Sensitive data is defined as full magnetic stripe data, CAV2/CVC2/CVV2/CID and PIN/PIN Block. Its left open to store this data prior to authorization because of the big boys who use store and forward messaging systems to communicate with their backend systems that do the authorization for their other systems. In hanging out on PCI forums with QSA's its a common misconception that you can't store the CVV2 prior to authorization but the QSA's universally agree its acceptable. The QSA's say that the PCI-SSC, the group responsible for PCI-DSS and PA-DSS, has started a task force to look at security requirements prior to authorization but at this point PCI-DSS doesn't cover security prior to authorization.

I agree this is the way merchants should operate but it is not mandated by the card brands, PCI-DSS or PA-DSS. All of the reasons to store CVV2 prior to authorization have better ways to deal with the problems.

Not really an issue. If you use the encryption algorithms and key management practices required by PCI-DSS, brute force would take decades to crack the encryption.

Re: X-Cart and PCI-DSS / PA-DSS compliance
 

Good info. Thanks.

My bad - that I always forget that there is always an exception for the big fish, for the "privilegeds".

But we have taken the advise of our IT to not emulate the big boys; therefore, we've taken the "best course of action is avoidance" approach. We never store the cvv (encrypted or not). The consequences/implications of this approach are these --- and they should be familiar with businesses that follow the same "avoidance" approach:

1. We do not take credit card #s over the phone anymore. So there is no danger that the numbers will be written down somewhere and not shredded after authorizing the charge via a virtual terminal. The customer in physical possession of her card is always in charge of authorizing the payment via the secure ssl channel we provide.

2. We do not have an exchange. Technically, we do; but not in the traditional sense. All of our exchanges are processed as Returns, meaning that we will process an exchange by first refunding any due amount. Then the customer, if he so wishes can purchase the replacement item himself with his card. Why?
Usually, our typical exchange is the customer wanting to get a replacement item that costs more than the original. The vitual terminal interface at our payment processor requires both the main# and the cvv to authorize payment. Since we did not store the cvv then we are stuck and unable to charge the customer the extra difference due to the replacement. But our gateway does not need cvv for the merchant to refund a card. Hence, we process the exchange by refunding the amount due. The customer who is in physical possession of both the card can then buy the replacement item and authorize it herself.

Again, good info. And thanks for sharing the expertise.

Re: X-Cart and PCI-DSS / PA-DSS compliance
 

PCI compliance: What it is and why it matters (Q&A with Bob Russo, general manager of the PCI Security Standards Council):

http://news.cnet.com/8301-27080_3-10448197-245.html?part=rss&subj=news&tag=2547-1_3-0-20

Re: X-Cart and PCI-DSS / PA-DSS compliance
 

Wait a minute - I thought X-Cart supported redirection to a gateway... is that not the case? If so, isn't an I-Frame is just showing this redirected page in a different way (as a window inside of the existing checkout page) - and (still if so), why would X-Cart need to operate any differently in how it physically processes the transaction?

If X-Cart supports the redirect gateway method at all, this seems like a reasonable solution to consider. I'm surprised there aren't more people talking about this.

Is this how X-Payments is going to work?? After all, isn't X-Payments essentially supposed to function as a 3rd party gateway, except somehow appear seamless? If so, how is it going to achieve it's seamless look...?

Re: X-Cart and PCI-DSS / PA-DSS compliance
 

Vyacheslav,

Bzzzzt... Wrong answer.

The encryption of the source code using ionCube / etc. has NOTHING, ZERO, NADA, ZILCH to do with PCI-DSS. I deal with PCI ALL DAY LONG...
I've never heard a company that does audits come back and say "Oh, you need to encrypt your source code..."
In fact, most of them never even look at the source code.

If other shopping carts (Magento for example are "PCI") and they are not encrypting their payment module(s), why do you need too? Very strange.

Unless you're going to sell that as an "add-on", thats my guess?

Encrypting of the source code has nothing to do with PCI protection. PCI is all about following the rules and standards.

You folks need to hire a an outside company that does PCI audits, have them go through X-Cart then have them explain to you what needs to be fixed.
For PCI compliancy its typically around HOW you're doing things not usually how the code is doing it.

This guessing game won't work, and certainly locking down the payment module has really NO merit towards PCI, you could still have a payment
module thats encrypted with ionCube still NOT be PCI.

Lastly, I'll ask what nobody else wants too...

How much will the payment module cost once its encrypted? I see no other reason to lock down the source code of part of X-Cart only to
be able to market it and sell it as the "PCI version" of the product and charging more.

Hopefully I'm wrong.

Re: X-Cart and PCI-DSS / PA-DSS compliance
 

Anyone using the Dydacomp Payment Processing Gateway, or the Dydacomp Mail Order Manager (M.O.M.)?

Dydacomp Payment Processing Gateway:
Card purchases can be approved/transacted in real time online through SiteLINK Ecommerce or from the order entry screen while the customer is on the phone. The payment gateway is PCI compliant and supports a broad range of payment solutions, all card types, card present and not present transactions, dynamic DBAs, purchasing card transactions, and more.
http://www.dydacomp.com/gateway-merchants.asp

Dydacomp Mail Order Manager (M.O.M.):
Mail Order Manager (M.O.M.) 7 is developed for use in a Payment Card Industry Data Security Standard (PCI DSS) compliant environment. Dydacomp follows the PCI Payment Application Data Security Standard (PA-DSS) and has undergone an independent third-party audit of our development processes as well as the M.O.M. application.
http://www.dydacomp.com/pci-compliance.asp

--- Other PCI Links of Interest ---

List of Validated Payment Applications:
https://www.pcisecuritystandards.org/security_standards/vpa/
Note: Click on the "Accept" button to see the full list
(362 Vendors, 710 Payment Applications listed on 36 pages... Click the "Export to Excel" link to get the full listing in a .xls file)

Encryption for PCI Compliance:
http://pcianswers.com/2007/05/01/encryption-for-pci-compliance/

Re: X-Cart and PCI-DSS / PA-DSS compliance
 

Why doesn't x-cart support e-Select plus' hosted payment page? This would make it a lot simpler for a lot of Canadian stores, since Moneris/eSelect is one of the largest payment processors in Canada. It seems that support for the hosted payment page was dropped at some point - why? Is it possible to set it up anyway by having someone customize it?

I have to say that reading through this thread has given me a huge headache as a small store owner who is trying her best to fully understand all of this. I cannot afford to switch to another cart at this point so I'm stuck with whatever happens... where is X-Cart at with X-Payments?

Re: X-Cart and PCI-DSS / PA-DSS compliance
 

eSelect Hosted Paypage API is supported in X-Cart since the 4.3 version.