PA-DSS vs Ubercart

...as of now anyone using UC unless its been heavily customised will be breaching PCI-DSS/PA-DSS...

This is absolutely not true.

PA-DSS doesn't apply to Ubercart because Ubercart as an open source application is considered to be equivalent to custom code (i.e., equivalent to an in-house developed application). PA-DSS is for code that is being sold and for hosted payment solutions, but specifically does not apply to in-house applications.

That does not exempt you from PCI standards. However, PCI compliance is not something that can be guaranteed by *any* cart software, because it depends on many things like your hardware, network, and internal company policies and practices. Ubercart does nothing that I know of to prevent you from being PCI compliant, but can't in and of itself provide you with PCI compliance. And if in the future something is found in Ubercart that prevents PCI compliance, it will be fixed. However, I know of several shops using Ubercart that have gone through a full PCI compliance review, and we have yet to receive any reports of problems.

Ubercart is definitely in the scope of PA-DSS. It fits in neither of the categories of software that are explicitly excluded from the scope of PA-PSS:

• "payment applications developed for and sold to a single customer for the sole use of that customer. [...] Note that such an application (which may be referred to as a “bespoke” application) is sold to only one customer (usually a large merchant or service provider), and it is designed and developed according to customer-provided specifications."
• "payment applications developed by merchants and service providers if used only in-house"

A merchant that processes credit card information through Ubercart will be infringing PCI DSS because it is using an application that is not PCI PA-DSS, but this *only* applies if you are processing cardholder data, defined as (from the PCI Glossary): "At a minimum, cardholder data consists of the full PAN. Cardholder data may also appear in the form of the full PAN plus any of the following: cardholder name, expiration date and/or service code".

As long as you are using a payment provider with an hosted payment page, and that no credit card information is ever transmitted and stored on your system, you don't have to worry about PCI compliance.

@Damien Tournoud:
I disagree. Ubercart is not a "Payment Application" as defined by PA-DSS. That does not exempt any site using Ubercart from PCI compliance: Ubercart *is* subject to PCI as I said, but it is only one component of PCI compliance. It is not covered by PA-DSS for the reason I stated above - it is considered an in-house application by the PA-DSS standard. And by the PA-DSS standard that means that evaluation of PCI compliance of a site will include a code review of all software used by the site, including Ubercart (and including Drupal, by the way...).

But as I said the cart is only a small portion of PCI compliance, and no cart can guarantee PCI compliance because there are too many aspects of PCI compliance that are not within the control of the cart. Cart software can guarantee NON-compliance, if for example it stores credit card data, but cart software can't guarantee compliance. As far as I know, Ubercart does nothing that will jeopardize PCI compliance. Again, I know a number of sites that have undergone this review and none that I know of has had to change Ubercart's code in order to achieve PCI compliance. If any review *did* mandate a change in Ubercart, we would make that change in the Ubercart distribution.

It is certainly NOT true that simply using Ubercart will violate your contractual obligations to your payment processor.

The only time you don't have to worry about PCI compliance is if you are using a hosted payment method, for example PayPal Website Payments Standard, where credit card information is passed directly from the customer's browser to the payment provider. If you are using a payment gateway, where the customer sends the card information to the store's website and the store's website then transmits that information directly to the payment provider, you *do* have to worry about PCI compliance. Even if the store's website doesn't save the card information locally. But proving PCI compliance is something that *must* be done by each merchant - the shopping cart software *cannot* assure compliance.

@future assassin: If you're using PayPal WPS, you don't have to worry about PCI compliance.

@TR: I would highly recommend you read more about PCI DSS and PCI PA-DSS. There are good resources around the net, so I will not answer in detail here.

Just to clarify one thing: Ubercart does indeed embed a Payment application. As defined by PCI, a Payment application is:

"Any application that stores, processes, or transmits cardholder data as part of authorization or settlement."

In Ubercart, the payment application is all that code that handles credit card validation, pseudo-cryptography and authorization.

In the post-PA-DSS world, merchants that wish to process credit card data directly will have to only use PCI PA-DSS compliant payment applications. But because everything in Drupal shares the same memory space (and as a consequence any module can intercept card data easily), the whole Drupal site would have to be certified, which is not possible. As a consequence, in a PA-DSS world no Ubercart user will be able to process credit card without infringing their own PCI DSS requirements.

@Damien Tournoud: Everything I've said above is consistent with the PA-DSS specification and with the information on the web in the broader (non-Drupal) open source community. Let me reiterate that there are Ubercart/Drupal shops that have been certified by a PA-QSA to be PCI DSS compliant. This directly contradicts your conclusion that "...no Ubercart user will be able to process credit card without infringing their own PCI DSS requirements." I suggest you do your own reading, including learning from some people who have actually gone through this process with Drupal and Ubercart. One example can be found at https://docs.google.com/present/view?id=dfd4vgps_0dvb822c8 . That was two years ago, and they have maintained their certification since even in the face of the new PCI requirements. I attended that session and also talked with the presenter afterwards to learn more details. She and her team will be at DrupalCamp Colorado again this year, and since you will be there I suggest you talk to them too. Perhaps we can all get together for a BOF session.

Any Drupal module accepting on-site payments must of necessity "process cardholder data" as defined by PCI. Therefore, according to your statements, each Drupal cart module - in fact each payment gateway module, not just the cart - must spend tens of thousands of dollars on PA-DSS certification. Furthermore, since PA-DSS certification must be done before each and every release (no non-certified releases like -dev releases would be permitted), must be reviewed at least quarterly, and includes auditing of the development process and procedures to an extent that's not possible with Drupal modules, this is an on-going expense and a standard that effectively excludes open source cart projects. The only voices on the web advocating that are vendors who sell cart software and who are threatened by open source solutions. I disagree strongly with that interpretation. However, neither you nor I are lawyers, and our interpretations are irrelevant in the face of the established precedent that I described in my first paragraph.

If you re-read #6, you will see that I'm talking in the future tense. What is discussed here is the "post PA-DSS world", also known as "Phase V" of Visa's "Payment Application Security Mandates". The original deadline was July 1, 2010, but most of the gateways in the US are still not enforcing this yet (some in Europe are starting).

Conclusions from two years ago are just not relevant. In a post deadline world: "Acquirers must ensure their merchants and agents use only PABP-compliant [ie. PA-DSS-compliant] applications."

Any Drupal module accepting on-site payments must of necessity "process cardholder data" as defined by PCI. Therefore, according to your statements, each Drupal cart module - in fact each payment gateway module, not just the cart - must spend tens of thousands of dollars on PA-DSS certification.

Yes, that's *exactly* what it means.

Subscribing...

subscribing

subscribing.

I'd also like to hear more comment on whether it is possible to make UC compliant going forward ("post PA-DSS world/Phase V"). Implementation requirements and estimated time-lines would be helpful.

I am strongly in favor of seeking voluntary financial contributions from the installed userbase to develop and maintain PCI/DSS compliance going forward. Many businesses have already invested time and money in UC integration and development, therefore I believe they are de-facto stakeholders. I think a suggested donation of between $100 and $1000 per merchant would not be onerous.

I gladly welcome the opportunity to support my mission critical open-source projects in this manner since I am not a coder.

Finally, if not UC, then what are the options for Drupal users? I would like to stay oss, and I feel committed to Drupal.

Subscribing.

PA-DSS doesn't apply to Ubercart because Ubercart as an open source application

If so TR, why did Zen Cart go through the expense and trouble of getting PA-DSS certification?
Zen Cart is totally open source.
So your explanation doesn't make sense.

http://www.zen-cart.com/showthread.php?191335-PA-DSS-Certification

or go to

https://www.pcisecuritystandards.org/approved_companies_providers/valida...

and search "Application" "Zen Cart"

I think the point here is that there is an urban myth about open source being exempt from PA-DSS requirements.

It's not.

As per the PA-DSS definition:
“Payment Applications” refer broadly to all payment applications that store, process, or
transmit cardholder data as part of authorization or settlement, where these payment
applications are sold, distributed, or licensed to third parties.

The fact that Zen Cart have gone to the trouble of getting PA-DSS official certification
is surely solid evidence of the fact.

I don't think there is much else that can be added here. Ubercart will not become PA-DSS compliant unless someone is willing to pay for certification; the maintainers are volunteers and simply do not have the free time or money to do so.

I guess such certification would be a "feature", so marking as such.