The PA-DSS (Payment Application Data Security Standard) was initially created by Visa in 2005 and known as the PABP (Payment Applications Best Practices). The PABP and the PA-DSS were fashioned as a method to maintain a safe and secure online environment for e-commerce and to prevent credit card fraud and identity theft. Visa has since partnered with the other four major credit card companies in order to form the PCI Security Council. The mission of the PCI is to require all websites that use and/or store credit card numbers and other confidential information to be compliant by adhering to their standards. Therefore, owners of e-commerce websites must ensure their site is utilizing PCI Compliant Hosting.

PCI vs. PA-DSS: What’s the Difference?
The PA-DSS applies to products distributed as applications that people can download and use however they went. For e-commerce operators, this refers to their shopping cart and shopping cart hosting solutions. By July 1st 2010, all shopping carts must be compliant with the new PA-DSS. If your website uses a cart or host that is non-compliant with PCI Security regulations then your store risks being charged higher fees and penalties for transactions, fines and even the possible cancellation of your merchant account. If your merchant account were to be canceled then your business could no longer accept credit cards, which could very well put you out of business.

Becoming compliant with the PA-DSS is a very costly process for developers and distributors of shopping cart software. Many of the open-source shopping carts on the market will not be able to afford audits performed by the PCI’s Qualified Security Assessors (QSAs) and therefore will not be compliant be the deadline. As an e-commerce merchant, it is your responsibility to ensure that your cart is PA-DSS certified. If your cart is not compliant with the DSS then your site is not PCI Compliant and you will need to switch to a compliant cart in order to remedy this.

If you are opening a new store then you must make sure that you are signing up with a compliant cart and a PCI web host. By the July deadline, all level 4 merchants must be hosted on DSS certified applications regardless of whether or not they store credit card data. There are some exceptions to this rule. For example, if you strictly use a third-party service such as PayPal, Google Checkout or Amazon Payments and credit card numbers never touch your server then you might not have to prove compliance.

PCI Compliance covers a broader spectrum than the DSS and involves the host of your website rather than only your shopping cart and applications. Managed e-commerce hosting providers are responsible for following the guidelines laid out by the PCI Security Council in order to be fully PCI Compliant. Web hosts must follow the rules of the PCI by making sure their anti-virus is up to date and the proper firewalls are in place. As an e-commerce business operator, you must ensure that your host is PCI Compliant or you cannot legally process credit card transactions on your site.

Why Does the PCI Exist?
The biggest reason that the PCI was created is to protect banks from having to reissue credit cards, which is extremely costly. When something costs banks money, it trickles down to their clients and the consumers in the form of increased fees. One security breech can compromise hundreds or even thousands of credit cards. One compromised card costs a bank approximately $100. This can easily add up to millions and millions of dollars in replaced credit cards alone, not even taking into account stolen merchandise and the refunding of fraudulently spent money.

How Do I Prove Compliance?
First, you need to understand the different merchant levels. Online stores are rated from level 1 to 4 and your merchant level determines the rules that you must follow in order to be compliant. Level 1 is the highest and applies to stores that process 6 million or more transactions per year. Level 4 applies to companies that handle less than 20,000 transactions per year. Most small online businesses will fall into the Level 4 category.

Level 4 merchants must complete a quarterly network scan and questionnaire (there are companies like ControlScan and McAfee that will help with these steps). Merchants must also follow all other PCI compliance guidelines including the regular updating of anti-virus software and having strong firewalls in place. If the merchant stores credit card information then it must be on a separate server that is not web accessible and can only be reached by certain certified members of the company. They must also ensure that they have a PA-DSS compliant cart or any other applications. Higher level merchants may even be required to have someone on staff to handle PCI Compliance issues.

As previously mentioned, if your website strictly uses a third party payment processor then you might not need to prove that you are compliant and can host all of your store on a single server. However, not everyone has a PayPal or Google account and in order for your online business to be taken seriously, you should probably be able to process credit cards. If you can accept credit cards then you will not limit your sales and will be able to operate a truly successful e-commerce business.

The PCI questionnaires fall into two categories: SAQ-A (for those that do not store credit card data) or SAQ-D (those who do store credit card data). Obviously, the SAQ-D is more work and if a credit card number touches your server then you will need to complete this questionnaire.

Ensure Compliance Now!
Since July 1st is rapidly approaching then it is in the best interest of all e-commerce storeowners to ensure PCI Security Compliance for their website(s). It is not worth jeopardizing your business and livelihood over non-compliance. The risks are simply too great.

First of all thank you for this post very informative. If using Paypal payments Pro everything is processed on their server and doesn't touch mine right?

https://www.paypal.com/pcicompliance

This is somewhat of an ambiguous question and you will find various answers to it ... this is something that you should ask a QSA from the PCI.

The obvious answer is that if you are not storing or processing credit card transactions then you do not need to comply with the new PA-DSS but will still need to make sure that you are following the other guidelines established by the PCI.

Since this topic is rather confusing and there are no definitive answers to some questions, your best bet is to contact the PCI or PayPal to ask them ... this way if a security breech were to occur then you would have done all that you can to prevent it.

First of all thank you for this post very informative. If using Paypal payments Pro everything is processed on their server and doesn't touch mine right?

https://www.paypal.com/pcicompliance


No, that is not true. Paypal Payments Standard is the offering you are thinking of.

This is sort of a gray area ... there is some confusion regarding this and I have read conflicting pieces of advice and whatnot. The best bet is to contact a PCI QSA and ask them about your specific site. From what I understand, you will still need to complete the questionnaire. Better safe than sorry when it comes to the new PA-DSS because it is a fairly confusing topic.

The obvious answer is that if you are not storing or processing credit card transactions then you do not need to comply with the new PA-DSS but will still need to make sure that you are following the other guidelines established by the PCI.This is incorrect. I did not click on the Paypal link so I'm not sure if they are confusing people further. If you accept credit or debit cards as a merchant, then you must comply with PCI. If you outsource your payments to a third party, you still must comply with PCI but it makes the process much simplier. Merchants using Paypal must still fill out PCI SAQ-A and provide it to their bank.

Now I guess Paypal could be acting as the bank and not require the SAQ-A, but this would violate PCI and they would be taking on all the PCI liability if they do so. Maybe that's why Paypal is so quick to block accounts and hold merchant funds?

This is incorrect. I did not click on the Paypal link so I'm not sure if they are confusing people further. If you accept credit or debit cards as a merchant, then you must comply with PCI. If you outsource your payments to a third party, you still must comply with PCI but it makes the process much simplier. Merchants using Paypal must still fill out PCI SAQ-A and provide it to their bank.

Now I guess Paypal could be acting as the bank and not require the SAQ-A, but this would violate PCI and they would be taking on all the PCI liability if they do so. Maybe that's why Paypal is so quick to block accounts and hold merchant funds?

I said that you would not need to comply with the PA-DSS, not the PCI ... all e-commerce sites must adhere to the PCI. Even if you use PayPal or a third-party payment processor, your site must still be PCI Compliant .... if you read what I said, I was referring to PA-DSS.

One tidbit to keep in mind that is generally true -- PCI compliance pretty much refers to security and safety measures relating to your web hosting account (firewalls, anti-virus, network scans, etc) while the PA-DSS refers to any payment applications (shopping cart software, merhant programs, etc.).

True. I overlooked the "PA" portion, sorry. It's strange, I usually pay closer attention to that because I'm always explaining the programs. PA-DSS is software, PCI-DSS is merchant (and hosting provider), and PCI encompasses both.

I read recently that there will likely be an increase in online merchants returning to third party processors like Sage Pay and Paypal in the near future due to the next batch of changes for PCI-DSS.

Thankfully the sites that I've developed in the past have always used this type of processor and have never stored any of the card details.

It is incorrect to state that all eCommerce sites or all shopping cart software solutions must comply with PCI regulations.

You only have to read page 5 of the Payment Card Industry (PCI) Data Security Standard, Version 1.2, to know that this is wrong:

"PCI DSS requirements are applicable if a Primary Account Number (PAN) is stored, processed, or transmitted. If a PAN is not stored, processed, or transmitted, PCI DSS requirements do not apply."

A PAN is the credit card number. So really, there is no gray area in regards to this at all. If you use PayPal and you send customers to the PayPal Website where the customer enters the payment details, you do NOT have to comply with PCI.

If you use a PayPal API and collect the credit card number on YOUR website server, then you MUST comply with PCI.

It is as simple as that, and there is much disinformation being spread.

In regards to eCommerce solutions, this is a big problem for open source e-Commerce solutions. Even if you do not store the credit card number and you simply have a form on your site where you collect the number and then pass it on to a payment gateway in the background via an API or backend call, you must comply with PCI. Many Open Source cart users use their existing offline merchant accounts to cut costs and store credit card details on their server. That is definitly not allowed, unless the server and server environment are PCI compliant.

However if you use a shopping cart solution <<snipped>> which always connects to a server which is not controlled by the merchant when it comes to accepting credit card details, then you do NOT have to be PCI compliant on your site. The same applies if you use PayPal buy now buttons on your website. If customers don;t enter payment details on your server, you have nothing to worry about.

This is the reason why 3rd Party Payment gateways are becoming more popular again.

The problem is that even if you process only a small number of transactions, and you can do the PCI self assessment, there is an awful lot of complex work required to make your server PCI compliant.
You can do it with open source software, but it is a real pain and very time intensive. Experts are expensive, and if you have too many transactions - I think 100,000+ credit card transaction for Visa per year - your server location must be physically reviewed before you can get approval. They then check things as simple as if cameras are monitoring your server, if access to the server is limited to those with the right permission, if those people wear name tags, if logs are kept of who has had physical access to the server and so on. They also check on the server if you have firewalls installed, intrusion control software, if you log everything on your server, if anyone has root access and so on.

If you are in for that kind of control it gets really expensive - I have seen quotes for $20,000 and more per year to maintain

So you really only want to do it, if there is absolutely no way around it.

Re PA-DSS: This applies to Payment application software - not to shopping cart software in general. Only shopping cart software which has a module to accept credit card payment details on the same server would be affected by this.

:)
Rough Orange

Unless you were asked to make this posting and have it a sticky your wasting peoples time posting stuff like this.

You want the ultimate guide to PCI compliance? Take it from companies that haven't already had data breaches.

Good luck finding many big ones.

Hi Woods,
relax, you are a professional ;)
I don't think posting this is a problem, but the facts should be right.
: )
Rough Orange

It is incorrect to state that all eCommerce sites or all shopping cart software solutions must comply with PCI regulations....This is the reason why 3rd Party Payment gateways are becoming more popular again.Yes and no -- this depends on which definition of "Third Party Payment Gateway" that you use.

One definition is a PayPal like service where the ecommerce site is not the merchant of record as far as the banks and card brands are concerned. In this configuration Paypal (or whatever the payment provider is) is the merchant and with this definition you are correct, PCI is not required by the banks or card brands for the ecommerce site.

Another definition is a traditional gateway where the merchant has a real merchant account. In this configuration, even if you use hosted payment pages via the payment gateway (which PCI calls a third party payment provider) you must comply with PCI and provide an annual PCI SAQ-A at a minimum. Yes, this may seem like a catch-22 but the rule of thumb is that if you have a merchant account, you must comply with PCI.

Yes and no -- this depends on which definition of "Third Party Payment Gateway" that you use ... but the rule of thumb is that if you have a merchant account, you must comply with PCI.

Sorry, I disagree. The rules are very simple. If the credit card is not handled on your website but on someone else's website, you don't have to bother about PCI. Plenty of payment gateways have their own payment pages which you can use. Most 3rd party gateways require that you have a merchant account.

In some cases the 3rd party payment gateway can be called into the website into an iFrame - so it looks like the same site still but is actually a different server. Doesn't matter. As long as the card details are not handled on the server of the merchant there is no issue.

But many open source solutions actually accept the payment details on the merchant server and then pass them on to the payment gateway via an API, which means they fall under the PCI rules because the handle the credit card number.

If you want to set up a rule, then it would be more along the lines of "If you talk to a payment gateway via an API or other backend function to pass on credit card details for transactions, you must be PCI compliant."

We have integrated more than 60 eCommerce providers in ShopFactory - the vast majority of them require a merchant account and all of them allow using their website and often also an API.
: )
Rough Orange

Sorry, I disagree. The rules are very simple. If the credit card is not handled on your website but on someone else's website, you don't have to bother about PCI. Plenty of payment gateways have their own payment pages which you can use. Most 3rd party gateways require that you have a merchant account.I beg to differ - I'm one of those payment gateways you refer to. Please see PCI website: Self Assessment Questionnaire Form (https://www.pcisecuritystandards.org/merchants/self_assessment_form.php)

Specifically: SAQ Validation Type 1 - SAQ-A Required - Card-not-present (e-commerce or mail/telephone-order) merchants, all cardholder data functions outsourced. This would never apply to face-to-face merchants.

Again, you are correct with a Paypal type gateway (traditional Paypal) where Paypal is the merchant of record for the transaction. With the Paypal Pro like interface or any traditional merchant account gateway, SAQ-A at a minimum is required (SAQ-C or D if the payment data touches the merchant's web server).

I agree with Steve. 95% of the merchants we setup are using Authorize.net to run their transactions. Many are strictly using the Virtual Terminal. Yet, all are still required to provide proof of PCI compliance and I have yet to see the merchant service provider waive the fee. In my opinion, PCI compliance is little more than the merchant providers creating a new revenue stream.

In my opinion, PCI compliance is little more than the merchant providers creating a new revenue stream.


I think one could argue this statement.

Personally, I feel that PCI compliance requirements separate serious businesses and entrepreneurs from illegitimate "companies" formed with a WHOIS protected domain and a PayPal account offering web hosting just to make a quick buck (of course, webhosting is not the only industry where this happens).

I, like many others, would prefer to buy from a merchant whose website is checked by professional third party services for security. There are many flaws and vulnerabilities in our software that sadly, people take advantage of. If I input my CC number into a web form, I want to know it's as safe as it can be.

In the end, PCI compliance makes a buck for companies that specialize in this field, but nothing is free in today's society.

I agree. Legitimate processors want to keep cardholder data safe. My point is that processors, card associations, payment gateways, and financial institutions have continually worked at keeping data safe, and combating fraud.

Instituting rules which basically assume all are NOT compliant, making merchants prove that they are honest, doesn't seem correct to me. MSP's charging merchants a PCI compliance fee does little for the merchant or consumer, and a LOT for the MSP's, who do use it as a revenue stream and pay ISO's/Agents a portion thereof.

If they really wanted to ensure security, why not have automatic exclusions? For example, if you use Authorize.net's virtual terminal and a certified shopping cart, you are automatically considered compliant. With Authorize.net being the largest gateway provider, now being owned by Visa, I would think that this would not be terribly difficult. Obviously, playing favorites does not necessarily work, but my point is that there are options available. Let's not forget, the Fraudsters will find a way to commit fraud. Laws against Murder don't deter murder, etc. My guess is that the PCI line item has already become a financial boon.

Over the past decade there has been a huge increase of interest in "everything electronic". Credit/debit cards, over the internet movie rental, online stores, online auction sites, online car rentals, online movie reservations etc.

With ALL of that, there is a need for safe payment processing. Now just from that term alone, we get two industries: payment processing and merchant security (PCI compliance). Payment processors now offer payment gateways, merchant accounts, all in one solutions, and all of that comes with fees to make the guys behind this machine very rich.

It's a lucrative business, merchants need to accept payments, they need the consumers' trust, and they themselves want to profit as that is the point of any business. Cash is becoming obsolete, and with that there are opportunities for many new industries.

If they really wanted to ensure security, why not have automatic exclusions? For example, if you use Authorize.net's virtual terminal and a certified shopping cart, you are automatically considered compliant...
I agree with you about PCI being nothing more than a revenue stream for many in the payments area, but here you trying to package up security into a nice box labeled PCI. Security does not work that way. In your VT/certified shopping cart example, since the merchant is "compliant", who's problem is it when the web server gets hacked and the payment code is modified to redirect the payment info to hacker.net instead of authorize.net?

There is more to PCI than simply using a certified shopping card and certified payment gateway. Now the really confusing part is something I and others harp on and blog about: compliance <> security, and I think this is where much of the "revenue stream" frustration lies.