Have an online store? What you need to do by July 1.

Let me make it simple: Unless you are <i>huge</i> (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.<p>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.

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.<p><a href="http://usa.visa.com/merchants/risk_management/cisp_merchants.html#anchor_2" rel="nofollow">http://usa.visa.com/merchants/risk_management/cisp_merchants...</a><p>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.<p>tl;dr FUD

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.<p>The PCI specification seems to have been written to protect the payment card industry, not the merchants.

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.

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.<p>Just to note, I have clients who get emails scaring them into "pci scans" even when they don't handle credit card information.

Wow so when was our CC gateway going to tell us this?<p>Just before July 1 so we're scrambling to get code out to we can continue to make money?<p>Or after the giant business murdering fine arrived?<p>And we are with one of the <i>really BIG</i> ones . . .

That article is very much a scare tactic. The actual stipulations listed in Visa's terms do not sound nearly as bad:<p><a href="http://usa.visa.com/merchants/risk_management/cisp_payment_applications.html#anchor_3" rel="nofollow">http://usa.visa.com/merchants/risk_management/cisp_payment_a...</a><p><i>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><p>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.

Not sure that I totally agree with the rationale here, what's the consensus here at HN?