GS Logo
The Green Sheet, Inc

Please Log in

A Thing
View Archives

View PDF of this issue

Care to Share?

Table of Contents

Lead Story

Agents of change


Industry Update

Private label, public dilemma

Fed insures open loop cards

Reading Black Friday tea leaves

PCI help on the way

Boost online loyalty with new tales


From restaurants to revenue streams

The archetype in the mirror

The archetype in the mirror

The archetype in the mirror

The archetype in the mirror

The spend of Holidays past


Consumers' new mantra: Shop smart

Patti Murphy
The Takoma Group

Embracing PA DSS compliance

Dave Faoro

Gear up now for PCI PED compliance

Biff Matthews
CardWare International

The case for collecting fees

Ken Musante
Humboldt Merchant Services

The case for collecting fees

Ken Musante
Humboldt Merchant Services


Street SmartsSM:
E-commerce essentials

Jason Felts
Advanced Merchant Services

Shifting focus for 2009

Christian Murray
Global eTelecom Inc.

Recruiting top college grads

Curt Hensley
CSH Consulting

A little analysis, significant rewards

Jeff Fortney
Clearent LLC

Looking beyond PCI

Tim Cranny
Panoptic Security Inc.

Preparing risk departments for the holidays

Deana Sellens
Take Charge Business Consulting LLC

10 ways to prevent credit card loss

Gino Kauzlarich

Company Profile

On-line Strategies Inc.

New Products

Lift that tradeshow burden

Jelco Inc.

POS in a box

HP rp3000 POS bundle
Hewlett-Packard Co. LP


Ditch the holiday roller coaster





Resource Guide


A Bigger Thing

The Green Sheet Online Edition

December 08, 2008  •  Issue 08:12:01

previous next

Embracing PA DSS compliance

By Dave Faoro

In April 2008, Visa Inc.'s Payment Application Best Practices (PABP) was absorbed into the Payment Application (PA) Data Security Standard (DSS) published by the Payment Card Industry (PCI) Security Standards Council (SSC). For all practical purposes, the new PA DSS requirements will lead to major changes in how POS terminals are certified and sold.

The PA DSS is intended to help software vendors and others develop secure payment applications that do not store prohibited data - such as full magnetic stripe, card verification value 2 (CVV2), PIN or sensitive data - and ensure their payment applications support compliance with the PCI DSS.

In essence, the PCI DSS covers merchants' overall security and the PA DSS covers third-party applications used in those environments. The PCI SSC has qualified organizations known as PA Qualified Security Assessors (QSAs) to validate that these payment applications support PCI DSS.

When a breach occurs, generally a forensic audit is completed by security firms. In this audit, everything is reviewed for compliance - hardware, site, application and communications. These audits result in judgments regarding whether merchant sites meet full PCI compliance.

Acquirers that do business with noncompliant merchants face stiff penalties. Visa, for example, said, "Members are subject to fines, up to $500,000 per incident, for any merchant or service provider that is compromised and not compliant at the time of the incident."

A recent report from Trustwave noted that 92 percent of its forensic audits had involved level 4 merchants, such as neighborhood convenience store merchants who accept less than 1 million transactions annually. Can you really afford to take chances when boarding new merchants?

Impact of PA DSS

What we know as stand-alone POS terminals did not fall under the scope of Visa's PABP; with the move to PA DSS, that has changed. Very few POS solutions may still escape the requirements for PA DSS audits. For merchants' payment applications to avoid a PA DSS audit, all of the following on-site conditions must be met:

From a manufacturer's perspective, developing terminals that would only work in those limited environments is not practical - they could not be sold to much of the general market.

Many PAs today are built to run in either a dial or Internet protocol (IP) environment, so they have to comply with the PA DSS. In addition, many merchants are taking it upon themselves to implement IP conversion solutions for traditional dial terminals, so something developed for a noncompliant environment today could end up being converted to PA DSS validation.

Implementation focus

While the PCI SSC implements the standards, each card brand and payment processor is responsible for managing enforcement to ensure non-PA DSS payment applications are ultimately outlawed from the payment networks.

Visa, for example, has already initiated its own three-year plan to accomplish this goal (see Also, major processors have already indicated they will not provide Class A and Class B support to applications that are not PA DSS validated.

The council requires that PAs be subjected to security audits by authorized PA QSAs. Responsibility for submitting an application to PA QSA organizations lies with the software vendor. However, resellers are held responsible by the council to:

Merchants have similar responsibilities with regard to configuration and implementation. They must also maintain PCI DSS-compliant status for both the environment and the application configuration.

Getting there from here

While the PA DSS sets some rigid requirements by which terminals can be excluded, the reality is that suppliers have to develop solutions for the greater good, not narrow exceptions. It is the responsibility of manufacturers and resellers to facilitate, not inhibit, PCI DSS compliance.Our downstream customers, whether integrators or merchants, expect us to provide them with secure products.

We shouldn't expect that they can all become security experts and understand all the rules of being PCI compliant. It's also not realistic to expect software developers and solutions providers to develop applications solely for a private-line world when most of the growth is for public-network access.

From our perspective, that means that we have to implement the PA DSS across the board for devices that could be used within the scope encompassed by the standard - the alternative would be to manufacture two versions of the same unit to have PA DSS and non-PA DSS versions. VeriFone has taken a proactive approach to this issue and recently announced an initiative for blanket implementation of PA DSS over applicable devices. Going forward, VeriFone is establishing a universal compliance program for all its applications used in its programmable payment acceptance devices. A universal compliance program takes the guesswork out of the PA DSS. It removes the potential for confusion among the parties regarding who is responsible for what. Ultimately, we're all responsible, and we all need to take steps to ensure we're each doing our part to ensure consumer trust in the payment life cycle.

Costs of compliance

All of this compliance testing comes at a cost, of course, and security is turning into a major component of payment solutions pricing today. Because each PA used by each bank, processor or acquirer must now be audited for each discrete payment terminal, full PA DSS compliance will result in hundreds of individual audits by qualified assessors.

Various service and solutions providers are now beginning to identify compliance costs as a separate line charge in their pricing to both identify for their customer the value of their efforts, as well as to ensure they can recover costs rather than absorb them.

That's the approach we plan on taking as well - not only does it put the manufacturer's security efforts upfront, but it should also make it easy to compare and contrast what each supplier is doing in that regard and how much it is costing customers. Identifying compliance costs serves a number of purposes:

VeriFone firmly believes security compliance costs should be highlighted to merchants in a separate line item fee. This will enhance their understanding that security is not only incumbent but also an ongoing focus for the solution they have purchased through ISOs.

Security is no longer an option for anyone; it's a benefit that shields merchants from fines, audit costs and loss of consumer trust. It's vital to educate merchants on the need for security. Those who attempt to hide the cost and fail to turn security into a value added service will ultimately be left behind by competitors that take a more proactive approach. At the end of the day, the only method of protecting ISOs from card network penalties in case of security breaches at ISOs' merchant systems is to strictly adhere to all security mandates.

That means updating merchants to PA DSS-approved applications as soon as they become available. Dave Faoro is Chief Security Officer for VeriFone. He can be reached at

Notice to readers: These are archived articles. Contact names or information may be out of date. We regret any inconvenience.

previous next

Spotlight Innovators:

North American Bancard | USAePay | Board Studios