Confusion Runs Rampant
Many folks in the e-commerce industry have found themselves scratching their heads in confusion over the new PCI PA-DSS (Payment Card Industry, Payment Application - Data Security Standard) rules and guidelines. PCI Compliance has never been an easy topic to wrap one's head around and the new DSS is starting to cause panic among some involved in businesses that operate online. The July 1, 2010 compliance deadline is looming and many payment applications are still not DSS certified.

This is not good news for anyone involved in the e-commerce sector. There is no set punishment established for non-compliance with the new PA-DSS. If an online storeowner is found to be non-compliant then they will likely be charged increased merchant fees and penalties, face hefty fines and in some cases have their merchant account or even their entire website terminated.

Most of the confusion and controversy revolves around who exactly needs to comply with the new DSS. The answer to this is somewhat complex but the primary rule of thumb is that if your store processes credit cards online then you need to use a shopping cart that is PA-DSS certified in order to be PCI Compliant.

As an e-commerce merchant, vendor or retailer (those operating a business online), it is your duty to ensure you are utilizing fully PCI Compliant Hosting and that your shopping cart application is PA-DSS certified. If either your host or cart is not compliant with the PCI than your site is in trouble. Many carts and other merchant service providers are still shuffling to get scanned and added to the list of compliant applications before the July deadline.

If you are in the market for new shopping cart software than you do not want to use a program that is non-compliant with the PCI or PA-DSS. It is not worth losing money or possibly your business over something so simple to remedy. The responsibility falls on you - the storeowner - to find a host and cart that are compliant with the PCI and to fulfill the required network scans and questionnaires.

PCI Compliance vs PA-DSS - what's the difference?
The PA-DSS (Payment Application - Data Security Standard) applies to products that are distributed as applications that people can purchase and then do whatever they wish. For example, this applies to shopping cart programs and e-commerce solutions. The DSS started as the PABP (Payment Application Best Practices) by Visa before becoming affiliated with the PCI Security Council, which represents all five major credit card companies. In order to be PCI Compliant you must be on a DSS certified application. In other words, your cart must be compliant.

PCI Compliance is a broader set of rules and guidelines. The PCI Compliance rules are the standards for the way in which credit card transactions and other confidential information is processed online.

As of July 2010, both PCI and PA-DSS Compliance are necessary for a site that accepts credit card payments. The PCI applies to all e-commerce businesses, web hosts, shopping carts, payment gateways and merchant account providers. When a company becomes DSS certified they are then added to Visa's list of compliant companies. The PCI Compliance rules are the standards for the way in which credit card transactions and other confidential information is processed online.

In order to be fully PCI compliant with the new PA-DSS, level 4 merchants must be running compliant applications on their site (such as their shopping cart). Their web hosts must also be PCI compliant by using properly encrypted networks, regularly updating their anti-virus software and performing regular system scans.

There are a number of PCI scanning companies approved by Visa and MasterCard that will help small merchants pass PCI audits and complete the PCI questionnaire in order to show PCI compliance. Being fully PCI and DSS compliant is like having an insurance policy in the event of a security breech.

Excellent post! Can't say enough to make sure people are paying attention and are ready for the changes; and let’s not forget that the bi-annual release of new standards is due out this October, so there will be updates (virtualization) and clarifications to the PCI-DSS & corresponding documents (PA-DSS, etc).

To add to your post, PA-DSS can also affect those out there who have brick & mortar operations with storefront POS systems. If you have a standard POS system, then you may also be required to have a PA-DSS compliant setup.

According to the PA-DSS, the standard & requirements will _not_ apply if:

Hardware terminals with resident payment applications (also called dumb POS terminals or standalone POS terminals), do not need to undergo a PA-DSS review if all of the following are true:


The terminal has no connections to any of the merchant‘s systems or networks;
The terminal connects only to the acquirer or processor ;
The payment application vendor provides secure remote 1) updates, 2) troubleshooting, 3) access and 4) maintenance;
The following are never stored after authorization: the full contents of any track from the magnetic stripe (that is on the back of a card, in a chip, or elsewhere), card-validation code or value (three- or four-digit number printed on front or back of payment card), PIN or encrypted PIN block.

Now what does all this really mean. It all comes down to connectivity. If your POS ties into your office network for printing, back-end storage (it has a central data-base with multiple POS terminals), or connects to any other system “inside” your network then the POS terminal is required to have PA-DSS.
Even if your POS system “only” communicates with the acquirer or processor but is residing on your local network where other systems are, then you “may” need to have a PA-DSS compliant app.

Just like the PCI-DSS, with PA-DSS the only way you can really avoid it is to segment your network / applications and remove/reduce the connections & places your card holder systems communicate with.
Good luck to everyone struggling with PCI!

Oh and not to nit-pick but there are 6 card brands, not 5 :) (Visa, Master Card, Discover, American Express, JCB & Diners)

Z, Thanks for your addition to my post and all the info you provided. Really useful stuff!


Perhaps we could merge all the relevant posts regarding PCI and PA-DSS compliance into one mega-thread titled "The Ultimate Guide to PCI and PA-DSS Compliance" or something along those lines.

With the July 1st deadline for PA-DSS certification for payment applications rapidly approaching, it is now more important than ever to make sure you are fully compliant if you are the owner or operator of an e-commerce website.

How will PA-DSS compliance requirements affect those merchants who have set up their own custom cart software?

How will PA-DSS compliance requirements affect those merchants who have set up their own custom cart software?

It won't. PA-DSS does not apply to custom applications. If the custom cart software ever touches card account information, the the entire application falls within the merchant PCI-DSS and may require a security audit. Most likely, if you can't qualify for PCI SAQ-A, most merchant service providers will require an audit of the application by a qualified security assessor (QSA) -- very costly.

My recommendation is to use a cart and payment gateway that qualifies for SAQ-A -- whether or not the cart is custom or on the PA-DSS certified list.

This is a huge threat to open-source cart software. It's basically no longer a viable option for anyone who wants to process payments on-site.

One thing I did realize is that maybe I could develop my own payment module (for Authorize.net's aim API, for example). If the only module touching payment info is developed in-house, my understanding is that it doesn't qualify for PA-DSS. Even if getting the code audited by a QSA is costly, wouldn't it still be less costly than getting an entire app validated for PA-DSS? To be honest, the only cart software out there right now that's compliant is either very expensive, or pretty awful compared to some of the F/OSS software out there (or both).

Just to clarify on code audits/review - this resides in section 6.6 of the PCI DSS. It does require the assessment to be done by an organization that specializes in security, but it can be automated. Automated tests are not necessarily very costly at all.

It seems to me like in-house development might be one of the most efficient ways to go if none of the PA-DSS apps are cutting it and neither external payment pages nor SaaS are options

It might be easier to separate your in-house developed module from the shopping system then your shopping cart wouldn't matter.

It won't. PA-DSS does not apply to custom applications. If the custom cart software ever touches card account information, the the entire application falls within the merchant PCI-DSS and may require a security audit. Most likely, if you can't qualify for PCI SAQ-A, most merchant service providers will require an audit of the application by a qualified security assessor (QSA) -- very costly.

My recommendation is to use a cart and payment gateway that qualifies for SAQ-A -- whether or not the cart is custom or on the PA-DSS certified list.

Not quite, if you do SAQ D you can do it w/out a QSA (unless you are in canada where SAQ is required to be reviewed by QSA)

Just to clarify on code audits/review - this resides in section 6.6 of the PCI DSS. It does require the assessment to be done by an organization that specializes in security, but it can be automated. Automated tests are not necessarily very costly at all.

It seems to me like in-house development might be one of the most efficient ways to go if none of the PA-DSS apps are cutting it and neither external payment pages nor SaaS are options

Commercial code review tools can cost in excess of $10,000 per programming platform. There are owasp and other tools available but you can't just run them and say you reviewed the code; you have to know what it found, know the issues it can't find (limitations on free sw vs commercial for this), etc.

Not quite, if you do SAQ D...Based on how I read and interprit PCI, true; but basid on how many Merchant Service Providers (MSP's) are interpriting PCI, and balancing the liability risk, many are requiring physical audits of custom applications.

This is a huge threat to open-source cart software. It's basically no longer a viable option for anyone who wants to process payments on-site.Incorrect -- you just have to use a payment solution that qualify for SAQ-A. While the most popular is Paypal using the page redirection (after all, SAQ-A was written specifically with Paypal in mind - they are on the PCI board), there are integrated solutions that use hidden page redirection that can give you all the same control as the traditional gateway interfaces where the cart handles the card information like periodic membership billing, book & ship processing, card on file functionality for one-click check-out, etc. While it gives all the same benefits, the cart is not really touching card information, only tokens. Google "simplify ecommerce security real tokenization" -- you find several solutions.

Based on how I read and interprit PCI, true; but basid on how many Merchant Service Providers (MSP's) are interpriting PCI, and balancing the liability risk, many are requiring physical audits of custom applications.

It doesn't matter how merchant service providers interpret the DSS, the interpretation is up to your merchant acquiring bank.

It is good to see other service providers helping take the initiative to help customers have apps that don't get "them" (the service provider) hacked but they (MSP's) don't define the standards but they can set the bar high for their choice of customers. If they don't offer real solutions with it (ie do they offer code reviews, pen-tests, etc) or are they just trying to keep the smaller (more hackable) merchants out of their customer base.

The MSP is usually the acquiring bank.

The MSP is usually the acquiring bank.

None of my customer ISO/MSP's are banks, all are sponsored by banks.

Quoted from wikipedia.

To market merchant accounts, an ISO/MSP must be sponsored by a member bank. This sponsorship requires that the bank verify the financial stability and suitability of the company that will be marketing on its behalf. The ISO/MSP must also pay a fee to be registered with Visa and Mastercard and must comply with regulations in how they may market merchant accounts and the use of copyrights of Visa and Mastercard. One way to verify if an ISO/MSP is in compliance is to check a website or any other marketing material for a disclosure "company is a registered ISO/MSP of bank, town, state. FDIC insured". This disclosure is required by both Visa and Mastercard and will cause a fine of up to $25,000 if it is not clearly visible. In almost all cases, if there is no disclosure, the company is likely to be an uninformed 4th party or worse. In many cases unregistered operators have been responsible for some of the worst horror stories from merchants.

http://en.wikipedia.org/wiki/Merchant_account#Marketing_by_Independent_Sales_Organization_.28ISO.29.2FMSPs

That definition is actually incorrect for the MSP portion. An MSP can be a member bank, and that is missing from the definition. Most of the MSP's my company deals with are member banks and there is no "sponsorship" in the mix.

Based on how I read and interprit PCI, true; but basid on how many Merchant Service Providers (MSP's) are interpriting PCI, and balancing the liability risk, many are requiring physical audits of custom applications.

The standards counsel creates the standards, the card brands create the validation requirements, and the acquiring banks enforce the validation. All merchants/service providers who make their own apps are required under PCI-DSS to perform code / security reviews. You are not required to "validate" your tests unless you are a Level 1/2.

If a MSP/bank is asking level 3 or 4 merchants to validate, especially with a 3rd party, then kudos to them for stepping up the bar; however that is above and beyond the requirement. If you are one of these merchants, I would suggest finding a new bank.

Even if you are not validating with a 3rd party, you still have the requirement to meet all of the standards. If you are ever compromised then what you are and are not doing will be disclosed.

That definition is actually incorrect for the MSP portion. An MSP can be a member bank, and that is missing from the definition. Most of the MSP's my company deals with are member banks and there is no "sponsorship" in the mix.

You are correct, a MSP can be a member bank. Please keep in mind that a sample of 1 does not represent an entire industry.

I'd think you'd need a QSA Audit if you have custom cart.

I'd think you'd need a QSA Audit if you have custom cart.

No, the only merchants who require a 3rd party QSA validation are level 1 and level 2. Level 3 and level 4 are self validating through a Self-Assessment Questionnaire (SAQ).

Though if you develop a software for sale to other merchants, it does require a PA-DSS validation. However if you keep the software for in-house use only no 3rd party validation is required for level 3 and level 4 merchants.

This would depend on the way the payment processing is handled by the shopping cart. If cardholder data (meaning card numbers and/or card security codes) ever touches the server the shopping cart is hosted on, then yes, an audit would be required. If the card data is posted directly to a approved payment provider (see PCI SAQ-A) using a page redirect or a hidden redirect, then no audit is required.