| 2:59 am on Apr 10, 2010 (gmt 0)|
There are two standards: PA-DSS relates to the software, and addresses the rules for storage, encryption, and handling of sensitive information including cardholder data. There are companies that specialize in the auditing of shopping cart software (via documentation & questionnaires rather than line-by-line review of code), and issue certifications if the documentation is in order. The number you quoted is probably accurate for a first-time audit.
The second standard is PCI-DSS, and it relates to the merchants' implementation of the shopping cart software. The standard addresses access control, firewalls, regularly-scheduled scanning by outside specialists, physical access restrictions to stored cardholder data; in other words, the physical installation. Unless you're processing 20k+ Visa transactions (or 50k+ credit card transactions), they probably won't bother with you (what they call "Self-assessment").
If you are caught breaking a rule (say, you get hacked), they would probably close your merchant account, fine you, or possibly require you to document your PCI-DSS compliance.
I think the goal of these standards is admirable and totally appropriate. But I don't think they'll ever approach 100% compliance. Remember, these are the same companies that will gladly approve a credit card authorization request containing an incorrect billing address. They make a lot of money from honest merchants, and the last thing they want to do is cut off that revenue stream, or send more merchants to PayPal.
| 2:43 pm on Apr 10, 2010 (gmt 0)|
Thanks allot for that overview, that clears allot up for me.
So do merchants ever ask for PA-DSS compliant software? Do they give certain benefits to those who run software that has that certification?
| 4:31 pm on Apr 10, 2010 (gmt 0)|
I don't know if merchants specifically seek out shopping carts that are certified. The certification can't hurt, but the certification costs get passed-on in the price of their products. I'm not convinced it's worth the higher price.
On the flipside, there are rules that certified carts must abide by, which in my opinion, hurt the merchant. For example, certified software must block the password when viewing a customers' contact info.
This sounds great on paper, but there are legitimate circumstances where I need to log-in as the customer to mimic their user experience, or to help them over the phone to log-in.
If your cart is PA-DSS-certified, you cannot view the password; your software must generate a new, randomized password (of sufficient strength), and email it (not phone it... another rule) to them. So Grandma's forgotten password goes from "grandson" to "aI9!65Qm". This is how things work under PA-DSS certification.
| 5:50 pm on Apr 10, 2010 (gmt 0)|
Well what I am confused by is WHY would a commercial cart go to the lengths of getting a PA-DSS certification, costing 40K, etc. There must be a reason like it will become a must soon or something, or is it just marketing at this point?
| 7:19 pm on Apr 10, 2010 (gmt 0)|
Well last I heard it is becoming a mandate as of July 1 2010 that Visa/MC merchants must be using PA-DSS certified payment applications (including shopping carts, POS applications etc) or else be considered out of compliance (fines, recision of processing ability).
How heavily will it be enforced? Well that's a risk some merchants may take. But yes, it is going to be required.
Be aware that custom applications written for use by one company fall outside the scope of the pa-dss. However, any application that is packaged and distributed is under the umbrella.
| 10:06 pm on Apr 10, 2010 (gmt 0)|
ahh, ok thanks Rachel, that makes sense. So custom-in-house apps are ok (for now!).
| 2:58 am on Apr 11, 2010 (gmt 0)|
That's 80 days from now.
But the bankers in charge of PCI Security don't know if your cart software is PA-DSS compliant or not. And in most cases, PCI-DSS compliance is via self-assessment.
How will they fix this in time?
| 4:30 pm on Apr 11, 2010 (gmt 0)|
|How will they fix this in time? |
There will be wide-spread and massive non-compliance. They've already moved the deadline back at least twice.
Like PCI-DSS, they aren't going to actively look for people and start revoking processing ability. Wouldn't be prudent or practical.
But practicality or impossibility of enforcement never stopped them in the past. When the PCI-DSS came out it was the same situation. Now several years in at least it is something that (most?) more people know about and try to follow...this will be the same sort of deal I think.
Also is another way card companies shift any and all liability to the merchant in the case of a breach.
| 5:51 pm on Apr 27, 2010 (gmt 0)|
Rachel, so if I just provide ecommerce consulting, using my platform, but don't sell/distribute it in the sense people can buy the software, I am ok? (I will create ecomm websites for my clients, using my softare, but it is 'custom').
| 7:31 pm on Apr 27, 2010 (gmt 0)|
I'm no expert - you'll probably want to read up on it yourself since you know your business best. I believe the wording is "packaged and distributed" - and probably the most liberal interpretations of each. ;)
|Payment applications that are sold, distributed or licensed to third parties are subject to the PA-DSS requirements. In-house payment applications developed by merchants or service providers that are not sold to a third party are not subject to the PA-DSS requirements, but must still be secured in accordance with the PCI DSS. |