Remember the “Millennium Bug,” or Y2K scare, when we thought computer systems would come crashing down at midnight on Jan. 1, 2000? Direct merchants now have a fresh headache and new deadline to contend with: PA-DSS.
You have just 15 months to make sure the systems you use to process credit card transactions comply with the new Payment Application Data Security Standard established by the Payment Card Industry Security Standards Council (PCI SSC).
If your systems are not PA-DSS compliant by July 1, 2010, you can’t meet PCI standards, and you’ll be in danger of losing your merchant account — your right to accept credit card transactions. Ouch.
PCI compliance has been around for several years, but until recently it had all the earmarks of the Y2K scare: warnings of dire outcomes, but no major consequences for the non-conforming.
But last year, the PCI SSC announced this new component in the compliance equation. PA-DSS applies not to the merchants, but directly to the credit-card processing systems themselves.
PA-DSS represents specific requirements (see “Top 10 PA-DSS requirements” on page 38) that a system must meet if it is used in processing credit cards. An assessor approved by the PCI SSC must audit each and every such system, and assign a “pass” or “fail” to the application.
Those that pass will be put on an official list of PA-DSS-compliant applications. (The list is available at www.pcisecuritystandards.org.) If a merchant is using a third-party system that’s not on that list on July 1, 2010, it is not truly PCI-compliant.
Are there any exceptions? If you have a homegrown system, or one that has been written for you on a custom basis by an outside developer, it is exempt from PA-DSS requirements. You only have to pass the PCI test.
The only other exception is for merchants using browser-based systems or thin-client applications on solutions hosted off-site (software as a service), with all data maintained on the hosted solution. But these systems themselves must be certified PCI-compliant, and merchants using them still need their own PCI certification.
MCompliance strategies There are, inevitably, a number of gray areas with PA-DSS and PCI DSS compliance. For instance, there’s the way in which PA-DSS compliance is determined by qualified security assessors (QSAs) designated and approved by the PCI DSC.
A software vendor can approach several QSAs for preliminary discussions and select the one that seems most likely to approve its system. While no QSA will run the risk of disqualification — or worse — by fabricating compliance where it doesn’t exist, one QSA could make a good faith assessment that differs in its conclusions from another QSA.
From the merchant’s perspective, there is no difference: As long as a system is on the approved list, it doesn’t matter how it got there. And indeed, no QSA is going to misrepresent a system that is clearly out of compliance; only those that come close but may use unorthodox security strategies could be “passed” when they should be “failed.”
Some of these will make use of “compensating controls,” which are workarounds permitted in PCI SSC compliance testing, but not allowed in PA-DSS testing. This difference is bound to cause confusion.
MTime and money Any way you slice it, though, PA-DSS is going to cost everyone more money than they would care to spend — especially now. Most software vendors will have to invest some tens of thousands of dollars (possibly more than $100,000) to get their systems to conform to the PA-DSS regulations, and from $2,500 to $30,000+ for a compliance audit.
To add insult to injury, there is an annual fee of $1,250 just to be put on the official list of compliant applications.
And only the latest version of a system is likely to be listed — although PA-DSS allows multiple version listings if the vendor wants to retrofit them. So a large proportion of the users of any given order management system — for instance, those running on older versions — may have to pay to upgrade to the compliant, listed version of the system.
Expense aside, there will be a rather daunting scheduling challenge to get all merchants upgraded in time.
Another gray area is whether a standard third-party system that has been highly customized for a specific user site is exempt or not. The official PA-DSS language is ambiguous here: “PA-DSS does apply to payment applications that are typically sold and installed ‘off the shelf’ without much customization by software vendors.”
Uh, how much is “much customization”? You could argue that the vast majority of enterprise multichannel order management systems are installed with enough customization to render them exempt.
MSystems and tokens Which systems are involved? This is more clearly defined by PA-DSS, although open to misinterpretation by vendors. Any system that captures, processes, stores and, most important, transmits or receives credit-card data must be certified.
This includes every multichannel OMS, POS systems and any e-commerce shopping cart module. If the e-commerce platform itself does not capture or store any credit-card data, it would not be included; if it does, it would.
Some system vendors are hoping that use of a third-party payment-processing module, operating off-site, will let them dodge the bullet.
That may be the case for e-commerce or browser-based solutions in which a third-party payment “widget” can be incorporated into the order processing screen or checkout process. But it’s much harder to include this in a client-server application in a call center.
There’s no point in capturing the credit-card data in the legacy system and passing it immediately to a separate module behind the scenes. The simple capture/passing activity — even if the credit-card data is encrypted — renders the order management system vulnerable to PA-DSS testing.
With most third-party modules, and sometimes within a system itself, part of the security strategy involves creating a unique data string “token” that represents the credit-card number. Once the encrypted credit-card data is passed along to the transaction processor, the merchant never has it again, using the token instead to refer to the data.
Tokenization can be set up by the transaction. This means that once the card has been charged for the order, the token no longer has a reference to the card information.
Or tokenization can be set up by credit card, meaning that the credit-card number can be referenced for follow-up activity, such as back-order cancellation or customer refunds. For catalogers and Web merchants, card tokenization is clearly preferable.
Continue on Page 2
Keep in mind that with data encryption, a system must support “key rotation” (to periodically refresh encryption algorithms) or “split keys” (which require input from two key holders for decryption) to be PA-DSS compliant, not just simple encryption or data masking.
MWhat you should do Contact your system vendors immediately to find out what they are doing to become PA-DSS compliant. As of early March, no OMS vendors were on the PA-DSS approved vendor list.
Ask when your vendors expect to be certified, and whether the version of the system the merchant is running will be included in certification. And if so, will there be any additional costs to the merchant? If PA-DSS compliance will require an upgrade, how much will it cost, and when can an upgrade installation or conversion be scheduled?
Most vendors are likely to be uncertified until early 2010. By then, if your provider is still not on the list, you’ll have little time to convert to another system by July 1.
So it behooves you to put pressure on your current provider to achieve PA-DSS compliance as soon as possible — and to secure your place now in the upgrade queue if an upgrade will be required.
If your compliance efforts go awry, you might be able to work with your provider to maintain your account if you can demonstrate steady progress toward compliance. So it’s better to do something, and have a process in place with your system vendor, than to do nothing at all.
Beating the clock: PA-DSS is a work in progress for the Security Standards Council, so there will likely be a crush of assessments in the first half of 2010. And there will probably be revisions of current mandates to clarify some of their ambiguities as assessors start dealing with the reality.
But one thing is for sure: Even if the Council is forced to move the deadline to a later date, coping with PA-DSS is going to be a major challenge that multichannel merchants will ignore at their peril.
Ernie Schell ([email protected]) is director of Ventnor, NJ-based consultancy Marketing Systems Analysis.
TOP 10 PA-DSS requirements
-
CVV or card validation codes must be encrypted, and not stored anywhere after card authorization
-
Encrypt credit-card numbers everywhere
-
Require secure authentication log-ons for system users
-
Keep logs of all payment activity
-
Maintain network security
-
Maintain secure data communications
-
Don’t store credit-card data on servers with Internet access
-
Test all interfaces to other systems for meeting PA-DSS security standards
-
Maintain instructional documentation for system use
-
Maintain a PA-DSS Implementation Guide that documents how PA-DSS requirements are met for this system
ADVERTISER INDEX
Receive supplier information fast using Multichannel Merchant Advertiser Index
| ADVERTISER | PAGE | PHONE | WEBSITE |
|---|---|---|---|
| AccuData Integrated Marketing | 18 | 800-732-3440 | www.accudata.com |
| B&W Press | 23 | 877-246-3467 | www.bwpress.com |
| Blue Package Deliver LLC | 3 | 651-773-0031 | www.bluepackage.com |
| CCT Marketing, LLC | 4 | 800-213-4144 | www.cctll.com |
| Dydacomp | 21 | 800-858-3666 | www.dydacomp.com/mmm |
| Escalate Retail | 39 | 888-777-6811 | www.escalate.com/ecometry |
| FedEx SmartPost | 11 | 800-GoFedEx | www.fedex.com/us/smartpost |
| Global Response | 12 | 800-537-8000 | www.globalresponse.com |
| InOrder Enterprise Management System | C2 | 888-667-7332 | www.getinorder.com |
| iServe Direct Commerce Services | 26 | 866-895-4379 | www.iServeDCS.com |
| Lexis Nexis | 36 | 866-818-0265 | www.risk.lexisnexis.com/charge-back |
| MeritDirect | C3 | 914-368-1000 | www.MeritDirect.com |
| Millard Group, Inc. | 29 | 603-924-9262 | www.millard.com |
| NewPage | 14 | 800-638-3313 | www.Newpagecorp.com |
| NXTbook Media | 30 | 866-268-1219 | www.nxtbookmedia.com |
| PCS ProfitCenter Software | C4 | 888-446-6240 | www.profitcenter.com |
| Ripon Printers | 17 | 800-321-3136 | www.riponprinters.com |
| U.S. Monitor | 33 | 800-767-7967 | www.usmonitor.com |
| Walter Karl, Inc. | 6 | 845-620-0700 | www.walterkarl.com |
| William-Neil Associates | 32 | 800-846-8902 | www.william-neil.com |
| MCM NCOF SUPPLEMENT 2009 | |||
| 24-7 InTouch | N2 | 800-395-8301 | www.24-7intouch.com |
| ACCM 2009 | N5 | www.accmshow.com | |
| Blower Application Company | N4 | 800-959-0880 | www.bloapco.com/rungreen |
| Chicago Tag & Label, Inc. | N7 | 800-826-8260 | www.chicagotag.com |
| Dydacomp | N11 | 800-858-3666 | www.dydacomp.com/mmm |
| Endicia | N12 | 800-576-3279 | www.endicia.com/mcm |