PCI Compliance Confusion Persists

By Pedro Pereira, Business Solutions magazine

ISV misperceptions place the onus on VARs and integrators to do homework on the solutions they deploy.

Even though PCI-DSS (Payment Card Industry Data Security Standards) and PA-DSS (Payment Application Data Security Standards) guidelines have existed for several years, many independent software vendors (ISVs) remain confused or misinformed about what compliance entails. Thus, VARs and integrators who deploy POS and credit card-processing applications must be extra diligent in learning about the PCI compliance of a solution before recommending it.

PCI and PA guidelines, which cover such things as encryption, storage, network firewalls, cardholder data access restrictions, and tracking and monitoring of access to the data, affect an intricate network of entities, from software developers to hardware providers to merchants to credit card processing companies. The level of required PCI and PA compliance differs from one entity to another, and according to each merchant’s POS and card-processing setup.

“The most common misperception among ISVs regarding PCI compliance is that if the applications they represent do not store credit card data, they are freed from the burden of the regulations,” says Randy Park, CTO of POS vendor UP Solution. However, he says, some regulations still apply for applications that don’t store the data, though they are less stringent.

Tracy Metzger, executive VP and CTO of payment solutions vendor SecureNet, says many application developers believe mistakenly that if their software interfaces with a PCI-compliant gateway or processor, the application itself doesn’t have to be compliant. “The rules are still the same for all software that processes or passes cardholder data through their application,” he says. “They must be compliant without exception if their application ever touches the card data.”

Payment Complexity Breeds Confusion
Much of the confusion is due to the complexity of the regulations, explains Sean Kramer, president and CEO of Element Payment Services, a payment processing solutions vendor. A SaaS (software as a service) POS application, for example, may qualify to bypass some regulations but be required to comply with others, depending on card-brand requirements, he says. “The complexity of merely determining compliance requirements can be overwhelming for ISVs, let alone meeting these obligations and undergoing validation. This is why selecting a processing partner with proven PCI expertise can truly give an ISV a leg up on the competition.”

ISV misconceptions put the burden on VARs and integrators to ascertain the compliance of the applications they sell, lest they steer clients in the wrong direction. Clients, after all, often don’t know enough about PCI regulations, so they rely on a VAR or integrator to help them get compliant. “While VARs and integrators generally do not need to be PCI-compliant themselves, the product they represent must be if they process cardholder data,” says Metzger.

To their credit, says Kramer, VARs and integrators in recent years have done their homework on PCI compliance, though some requirements still overwhelm them. “It is obvious they have become more educated, and that is evident by their choosing products and services with increased security awareness,” he says.

Mobile POS Creates New Challenges
Adding to the complexity of compliance regulations, mobile POS solutions are creating a new set of security concerns that application developers, VARs, and integrators must keep in mind. Popular mobile platforms are still relatively new and, though they are being used for transactions, they generally lack the security to make them PCI-compliant.

The primary concern revolves around the transmission of cardholder data. Even in cases where mobile POS applications are compliant, the card readers with which mobile devices communicate wirelessly are not using encryption, which makes them vulnerable to skimming, says Kramer. “Because of the prevalence of unencrypted card readers and the associated security issues, mobile POS appears to be a high security risk,” he says.

NFC (near field communication) technology was developed to make it easier for consumers to use mobile devices for transactions and exchange digital content. The problem, says Park, is that a POS application using an NFC reader is easily intercepted. A solution would be two-factor authentication, which combines two security methods such as a token card and password to access systems. “Thus far, twofactor authentication is lacking in mobile POS software, and fraudulent transactions can easily occur,” Park says. “Just as with a desktop POS, if malicious software is installed on a mobile phone, private data can be easily transmitted.”

The PCI Security Standards Council released guidelines in June 2011 for mobile payment applications and is expected to issue best practices later this year. The guidelines, however, do not address security of payments through mobile devices because the devices are outside the scope of PCI compliance, says Kramer. Nevertheless, he recommends that developers create mobile apps based on PA-DSS guidance.

One major POS-related deadline that developers and VARs need to keep in mind is April 2013. That is when all POS terminals and ATMs will have to comply with EMV (Europay, Master Card and Visa) standards for authenticating credit card transactions. “Every credit card processor must be capable of accepting EMV transactions by April of 2013, but there is still no mandate to move all payments to this standard,” Metzger says. “Software developers will need to modify their applications to support devices such as POS PIN pads and readers and make certain their processing partners have the capability to support them.”

PCI Compliance In The Cloud
As with other areas of technology, cloud computing is having an impact on POS applications, with some developers starting to work on cloud-based applications. A cloud-based approach centralizes applications management, reducing the costs of management, equipment, and human resources. But, the cloud places new demands on developers who host the application; they have to undergo the same compliance regimen required of credit card service providers, which Metzger says is costly, difficult, and time-consuming.

There is a way around it, he notes. “They may work with a hardware peripheral company that directly interfaces to the payment processing partner, which moves the payment completely outside of the POS application and puts the PCI compliance responsibility on the peripheral company. But those that chose to pass cardholder data through their cloud-based application will have to go through an annual PCI audit as a service provider.”

Kramer says developers can employ “de-scoping” technologies such as point-to-point encryption, tokenization, and hosted payments, which remove transmission, storage, and processing of cardholder data and transfer the responsibilities to a PCI-compliant service provider. “By doing so, the application is no longer required to undergo PCI validation, and the benefits are transferred downstream to merchants,” he concludes.