What's the bottom line on PA-DSS?

I was under the impression that I would have to use a PA-DSS compliant shopping cart in order to be PCI-DSS compliant as a merchant. However, page 11 of the PCI DSS 1.2.1 states:

Note: It is not a PCI DSS requirement to use PA-DSS validated applications. Please consult with each payment brand individually to understand their PA-DSS compliance requirements.

I also found this site very interesting: http://www.pcipolicyportal.com/index.php

CIM service is $20/month or $.67 / day

Hosted page is $39 / month or $1.30 / day … but you
pick up a boatload of turnkey services along
with it.

Either way, it’s the cheapest insurance you can get.

Surprisingly many online merchants simply do not know/have never heard of the PCI-DSS deadline :goof: despite of all the talks on all the forums. Perhaps PCI council did bad informing?

Or everyone waits for next SAQ troubles?

Chances are good to be like http://www.youtube.com/watch?v=yxY7ZjroIYM on next SAQ :injured:

Not wanting to deal with all this PCI junk, I opted to use a hosted payment page so my site does not store, process or transmit cardholder data :smiley: I thought it may hurt sales but I think customers like it better because it seems like an extra level of security to them, which I guess it is…

I think this becomes a “requirement” on July 1, 2010 although I’m not sure what the penalties are if you are not using a compliant application. Extra fees?

See: http://usa.visa.com/merchants/risk_management/cisp_key_dates.html

Acquirers must ensure their merchants, VNPs and agents use only PA-DSS compliant applications

It’s like driving without insurance.

If you don’t hit anything, nobody cares…

But the minute there’s trouble, the penalties
get pretty severe.

These new rules are going to be the death
of the stand alone, install it yourself cart apps.

This is similar to the autoresponder apps that
used to work from your desktop …now if you
want a 100+ emails to go out at one time, you
need a real autoresponder service to make it
happen

It’s coming …make sure you’re ready for the new
reality of ecommerce.

This is a requirement by Visa’s PA-DSS policy. As of July 1 this year if you don’t use a software application that is PA-DSS compliant or that is out of scope for PA-DSS compliance (there are solutions for software providers to do this), you will risk losing the ability to accept credit cards from your customers entirely.

Also, from what I understand PA-DSS is ridiculously expensive when all the dust settles for “mom and pop” shopping cart outfits, let alone free open source carts. The only way these carts will survive, if we understand it correctly, is if they offer hosted payment pages (paypal standard, authorize.net SIM…) I’ve chosen to go this way simply because I don’t want the headache of network scans and whatever else they want to throw at us.

If you’re using a PA-DSS certified/approved cart to store/process/transmit cardholder data, then you, the merchant, still need the PCI compliance. So I’d rather use a cart of my choice and turn a negative into a positive for the customers, something to the effect of:

“Due to our strict adherence to recent credit card industry regulations, if purchasing with a credit card, you will be directed to our secure payment page to complete the checkout process. You will then be automatically returned here to receive your order confirmation”

The scanning stuff isn’t that bad. I accept cards directly on site, and don’t use any off-the-shelf carts, so need the quarterly scan. It only found one thing I needed to change to “pass”, a tweak to the SSL configuration in apache. I was surprised one of the things the scan checks is whether it can find a WordPress install on the server and then what version is installed.

All this compliance stuff recently seems like overkill to me. I would’ve thought phishing scams to be a much bigger source of stolen cards than little web shops storing credit card numbers in plain text on a web server and getting targeted by hackers. Phishing’s just so much easier and can hit so many more people. Yet Visa/MC’s policies are completely counter to anti-phishing efforts if you ever look at how they run their 3DS (Verified by Visa/MasterCard SecureCard) stuff. The real thing looks and feels just like a phishing scheme.

I have also heard other things such as being on a shared host by its very nature causes you to not be PCI Compliant because you’re just one of many sites on the server. There’s a lottttt of web shops out there that are on share hosts too. I don’t know how true that is but it makes sense to me because if your site is very secure, that doesn’t mean one or more other sites are secure if if someone gains access to the root, well you know what that means…

The network scan while easy for some, as in your case, isn’t always easy. And it’s even harder if you’re not trained in servers, etc…

http://www.howtojoomla.net/how-tos/security/pci-compliance-article

All of this depends on just how heavily the merchant account providers will enforce these regulations.

That’s definitely true. There’s at least one or two dozen rules in the standard you can’t meet on a shared host – you don’t control who can access the system, you don’t control logging and auditing, you don’t control the firewall, etc.

Well, ya can’t meet the PCI compliance requirements without being able to configure a server, so little shops without a server admin to consult with have not technically been allowed to accept credit cards directly over the web for many years.

Not such a bad thing, when you notice things like shopping carts that default to storing credit card numbers in plain text if you don’t add a different payment module. Sorry to agree with the bullies on that point, but if you’re not a technical type, you shouldn’t be trusted to protect the digital billing information of other people. You don’t have the skillset to match the responsibility. Good thing there are hosted payment solutions so you don’t need to.

Yep. With millions of merchants they’ll likely just throw ya to SecurityMetrics or one of the other companies that exist solely to help people stamp their servers as compliant. Which means they won’t care about anything but seeing that you filled out the self-questionnaire and passed an automatic scan.

Besides the expense, PCI makes day to day
use a little less convenient as well. Simple
things like the “Remember Me” on the login
page needs to be removed.

There’s also some pretty gray areas when it
comes to credit card storage and techniques.

Too many phrases like “as needed for business
purposes” …well who defines what a real
“business purpose” is?

They leave it up to the business owner to make
this determination but I’ll be willing to bet that
if you have a problem …they’ll be the ones deciding
if you were storing it for a legitimate “business purpose”.

My bet is to always go to the far end of the
conservative side of things when your business could
be on the line if there’s any issue.

There is absolutely no reason for anyone that comes to this forum to ever store payment information. You use something like Authorizenet CIM to have the gateway store it, not you. Storage requirements shouldn’t apply to individual merchants because individual merchants don’t need to store payment information. The gateways and other 3rd parties (like Recurly/Spreedly/Chargify/etc) can do the storage, and worry about being compliant, so that the individual merchants don’t have to. This while still being able to take the cards on our own sites – just to immediately pass them on. When you want to charge an existing customer using stored payment information, you do it by reference to the information the gateway stores, not by storing the information yourself.

The average webmaster has no business storing credit card numbers, and they can’t afford to do it right either. The information can’t be stored on an internet connected system, which means having a separate offline server just for storage… makes no sense when something like CIM costs $20/month.

When customers call in an order and they ask “do you have my credit card info from last time?” I simply tell them, “No, we do not store credit card information for your security” And they are happy about it. There’s no reason to store credit card info; like Dan says… No level 4 merchant is going to have that need, it’s not like we’re Amazon :smiley:

The technology to store credit card data is called tokenization. Some forms of tokenization work by transferring cardholder data to a secure data storage facility. All that’s left on your system is a unique identifier (token) that points to the actual data without containing any sensitive information itself. This allows you to securely process recurring bills, and transfer all risk of cardholder data storage. If your system were ever breached, the data stored at your location would be completely unusable to data thieves.

The gateways and other 3rd parties (like Recurly/Spreedly/Chargify/etc) can do the storage, and worry about being compliant, so that the individual merchants don’t have to.

These types of services are what I’m talking about…

…they actually do the “heavy lifting” for you so you
can focus on the business and not on PCI compliance.

The key is that these services allow you to do more
creative things like trial periods, variable payments, timing
etc.

To effectively do these advanced techniques it does help
a LOT to use a service. These advanced techniques are
also built into the most popular hosted shoppingcart
systems so you get the same benefits plus a lot more.

Of course, if you’re not running a site that has these
requirements, you’re better off not paying the monthly
fees for something not needed.

To elaborate more on tokenization, here’s how it works:

  • Business accepts credit and debit cards in the usual manner.
  • Business securely transmits cardholder data to Element’s PCI DSS compliant storage facility.
  • A unique reference pointer (token) is supplied by the storage facility for each record transmitted by the business.
  • The token is now stored at the business in place of cardholder data.
  • Future payment transactions are transmitted by the business using the token in place of cardholder data.

By removing the sensitive data from your software environment, tokenization provides your merchants the ability to more easily comply with PCI DSS and transfers the risk of storing cardholder data away from you, as Dan Grossman points out. In a recent report by PricewaterhouseCoopers presented at a PCI Security Standards’ Council Community Meeting, tokenization was highlighted as a “robust technology” that can help shift some of the risk and burden of PCI compliance from the merchant to the credit card processor.