Let me make it simple: Unless you are huge (that is doing well in excess of $200K in charges per month) there really is no point in handling all this yourself, you will spend tons of money in keeping up with the compliance requirements, which change way too frequently and are contradictory in many places.
Outsource and be done with it, unless your turnover is so large that the accumulated fees for having some third party take care of it outweigh the costs of doing it yourself.
To many smaller merchants, outsourcing may not be an option. I'd suggest reading and understanding the PCI-DSS. While it may be a bit over-written and mundane, its good knowledge that can save a small, medium, or even large sized business owner a lot of Money.
The article talks a lot of scare, but if you visit the supplied link to Visa about what you need to do it gets a lot less scary. That makes sense as otherwise huge portions of merchants would be set to lose the ability to take cards and CC companies / gateways would lose buckets of cash.
Level 3 merchants (up to a million transactions a year) need to complete a self-assessed questionnaire annually, fill out a form and have an automated external test run. All are very minor hurdles and if you're running that many transactions should be an extraordinarily small amount of expense as a percentage of revenue. If you're doing 20,000 transactions there is even less to do.
Given that the solution suggested by the article is to use a gateway (with a payment page, instead of forwarding CC numbers yourself), the gateways stand to make more cash, especially since some charge more for storage (which you'll need for recurring payments).
Having said that, merchants at the level 2-3 size often won't have renegotiated rates agreed with their acquirer back when the merchant was smaller - doing so can soften the impact of outsourcing capture/storage considerably (perhaps even pay for it completely).
Agree that merchants should read PCI-DSS, but smaller shops may not have the expertise/time to realise/handle the implications (do you record telephone calls from customers, for instance?). For any size of merchant, to be able to say "we're unlikely to be breached as we don't store card numbers" is a good thing indeed.
One problem that PCI compliance has had in the past is that an enterprise was only "compliant" for a very brief period, right after the security scan. So it's easy for TJ Maxx to get nailed for "non-compliance" if and when they have a card number leak.
The PCI specification seems to have been written to protect the payment card industry, not the merchants.
> The PCI specification seems to have been written to protect the payment card industry, not the merchants.
That goes for almost anything in the credit card world. Witness the way chargebacks due to failed approval policies on the part of the credit card companies are taken out on the merchants, lending policies that are totally irresponsible get taken out on the general public and so on.
Credit card companies are amongst the biggest scum on the planet, unfortunately they are so entrenched now that you can hardly move without them.
Try renting a car or booking an airplane ticket without a credit card.
I've outsourced each and every bit of the handling and processing to third parties, we still get hit with the chargeback penalty.
That reminds me: why didn't we have any public debate about electronic money? We just let the Big New York Banks slide credit cards in, despite the badness of the format, and indeed, the whole system.
I guess we're all going to find out how a privatized monetary system works, at least on the consumer level.
Using VBV just reverses the penalty of abuse on to the user instead of the merchant, because it is 'secure', whatever that means. If and when it will be hacked there will be a bit of a problem.
I helped a friend that runs an IPSP implement it, the spec is so large and convoluted that there's bound to be holes, so the flaws in the implementations are a problem but flaws in the spec are likely to crop up as well.
I thought a merchant implementing 3DS wouldn't receive chargebacks if a customer denies placing the order, since the issuing bank has performed "enough" authentication to satisfy themselves that the transaction is legit.
If that's the case then, holes aside, it makes sense for a merchant to integrate 3DS to reduce chargebacks (not to mention some acquirers charge lower rates for VBV payments, which can help offset PSP fees). But your earlier comment suggested that you were still being stung for chargebacks - I'd be interested to know why.
(and yes, it's a lot of spec for what's essentially 3 XML request/response pairs, but that's the payments industry for you - you'll know what I mean if you've had the joy of ploughing through APACS-70 or its predecessors...)
If your app touches CC#s it should be so good and so secure that it is PCI compliant without even trying to be. The PCI specifications read like a laundry list of common sense practices.
I kind of agree with you here. There are a lot of problems with the specifics of the PCI requirements, but they're still a shitload better than what was common practice before the PCI DSS existed.
I was peripherally involved in some of the PCI compliance efforts at my workplace (big, household name international company).. Frankly I was incredibly frightened and embarrassed at some of the incredibly dumb, sloppy ways my employer were treating customer credit cards. Now don't get me wrong, we still do a lot of dumb shit, but at least some effort is taken to secure customer CC numbers now.
Here is my advice, from the trenches: don't handle credit card numbers. Delegate that to a payment processor. All this talk about what to do to comply with PCI-DSS obscures the facts that (a) most companies would be better off not dealing with hazmat data like this, and (b) PCI-DSS could be reinterpreted more onerously at any moment.
Is there proof of this? I haven't heard from my payment gateway and I don't know where to get pci certified. It would smell like a scam to me but they don't seem to be selling anything.
Just to note, I have clients who get emails scaring them into "pci scans" even when they don't handle credit card information.
Yes, there is proof of this. While the article is loaded with "Scare text", the warning is real. PCI-DSS compliance is required by July 1st, 2010. PCI - DSS = Payment Card Industry Digital Security Standard.
Simply put, there are 12 areas that you need to pay close attention to, and I've pasted them below.
Build and Maintain a Secure Network
Requirement 1: Install and maintain a firewall configuration to protect cardholder data
Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters
Protect Cardholder Data
Requirement 3: Protect stored cardholder data
Requirement 4: Encrypt transmission of cardholder data across open, public networks
Maintain a Vulnerability Management Program
Requirement 5: Use and regularly update anti-virus software
Requirement 6: Develop and maintain secure systems and applications
Implement Strong Access Control Measures
Requirement 7: Restrict access to cardholder data by business need-to-know
Requirement 8: Assign a unique ID to each person with computer access
Requirement 9: Restrict physical access to cardholder data
Regularly Monitor and Test Networks
Requirement 10: Track and monitor all access to network resources and cardholder data
Requirement 11: Regularly test security systems and processes
Maintain an Information Security Policy
Requirement 12: Maintain a policy that addresses information security
For more information on PCI-DSS, go to https://www.pcisecuritystandards.org. Also, consider downloading the PCI-DSS, its a 60-70 page PDF with all of the information that you need on the PCI-DSS. It also contains a Self-Assessment Questionnaire that you can use to review your site or app.
As I work with ecommerce sites daily, I can assure you, PCI is not something that you want to ignore. At the same time, its not terribly difficult to adhere to the rules.
As a quick reminder, any site that is found to be non-compliant at the time of a breach could face fines into the hundreds of thousands of dollars ($ USD)
I take issue with Requirement 5, why on earth would my web server need an antivirus? Other then that everything else is pretty much a no brainier. Where my real issues lie are in the certification's of PCI compliance. Companies charge a lot of money to do "scans" of your website and claim that you're required to be "scanned" for compliance. According to https://www.pcisecuritystandards.org that doesn't seem to be the case.
It could well be true, this took effect in Sweden a few years ago anyway. You probably shouldn't be getting PCI certified unless you have a fair amount of time and money to spend on the process.
If your gateway doesn't intend to supply a PCI compatible solution of their own you should probably get another implemented instead. (I have one or two customer that went through PCI certification, it's a pointless hassle and they have to get reassessed once a year)
For smaller sites the conversion rate has tended to increase slightly (in sweden, so ymmv..) when using a reputable vendor.
We have clients with different-enough needs that it's often easier to write a new, simple shopping cart for them than it would be to integrate an existing behemoth to do what they need.
Should we have every single project certified? How do you even go about that?
Have them not touch the CC#. Leave that last part of the funnel to some certified external. You'd also make them a big service. I simply abandon most carts if the CC entry stage is still on the merchant site and not on someone's big and recognized like PayPal, and I hate PayPal. I just don't trust the little, unknown, guys with CC# & details.
I'm never very bothered handing out my CC details. It's not like I'm liable for anything that happens with it, and when shopping online I generally just the one-time use numbers that all of my credit cards offer. Really, the worst that can generally happen is that I have to get a new CC #.
This is rubbish no where can I find a requirement that we need to go above and beyond what we normally do to remain compliant with PCI-DSS if we do not store our customers credit card data (which we don't).
I am marking this one as link bait and moving on, annoyed at the waste of a couple of hours.
While the use of PA-DSS validated payment applications is recommended, a payment application need not be included on Visa’s list of PABP validated payment applications or PCI SSC’s list of PA-DSS validated payment applications in order to comply with Phase 2, Phase 3 and Phase 5 requirements for use of PA-DSS compliant applications. Acquirers may determine the PA-DSS compliancy of a payment application through alternate validation processes, which should confirm that payment applications meet PA-DSS requirements and should facilitate compliance with the PCI DSS.
I was unable to find the corresponding clause for MasterCard, American Express, or Discover, and various forum posts I came across seemed to indicate it was a Visa-only mandate currently.
Outsource and be done with it, unless your turnover is so large that the accumulated fees for having some third party take care of it outweigh the costs of doing it yourself.