Magazine Article | February 14, 2012

New Technologies Add Complexity To Payment Compliance Landscape

By Brian Albright, Business Solutions magazine.

ISVs and VARs should tread carefully when it comes to ensuring payment standards compliance.

As retailers continue to upgrade their payment systems to remain in compliance with evolving Payment Card Industry (PCI) and Payment Application Data Security Standard (PA-DSS) requirements, they are increasingly relying on vendor partners, VARs, and systems integrators to help them ensure that the entire payment chain remains compliant. Resellers and software developers, likewise, have to ensure that they aren’t inadvertently missing parts of the compliance puzzle.

For example, the developer may make the mistake of thinking that, because a payment gateway is compliant, then the POS solution integrated with it is compliant. If the POS touches card data, then it is still subject to compliance with PA-DSS requirements.

“However, PCI and PA-DSS compliance can be made easier with newer technologies available,” says Shelley Plomske, senior vice president of technical services at Mercury Payment Systems. “There are so many options to reduce the scope of compliance, including end-to-end encryption, tokenization, or applications that handle the credit card data, than there were a couple of years ago.”

Are You In Or Out Of Scope?
Developers should take care when selecting the tools and partners for the offerings that they are putting together. “In remote cases, ISOs and agents that resell payment processing services have taken shortcuts around the PCI payment application validation process and claim that the gateway is the payment application, thus giving software developers and their customers a false sense of security about PCI validation,” says Tracy Metzger, executive vice president of SecureNet Payment Systems. “It’s mandatory that every application that processes payments becomes PCI-PA-compliant as a safeguard to the company producing the application and their customers.”

Other software developers claim to be compliant, but aren’t on the current lists for compliant service providers. “These software developers go wrong regarding their interpretation of the PA and PCI DSS regulations during the self-assessment process,” says Yasser Abou-Nasr, vice president of product/IT at T-Gate. “The most common reason is since they are not storing card holder data in their system, they feel that they are PCI-compliant. However, the scope of compliance is more than what is stored to memory in the application; it includes transient methods of sensitive data through the application.”

Other developers think they are out of scope because they use encrypted card readers. However, as long as the application has a method of allowing sensitive data to run through via manual entry or work with clear card readers, it is still in scope.

Fortunately, the POS vendor and resellers community has become more savvy about compliance. “Previously, more POS software developers believed they were PA-DSS-compliant than actually were,” adds Plomske. “Now we see a higher level of understanding in the POS developer community about compliance. Where software developers get caught not complying is with ‘hidden credit card data’ that they didn’t even know was there, but has been logged to a file or stored into memory.”

Many software developers also continue to evolve their payment processing interfaces and functionality after they have achieved PCI-PA compliance. They have to revalidate if any requirement under the PCI-PA standard has changed. “Many application developers use sub-versioning as a method to circumvent revalidation and that could result in the delisting of the certified payment application and put all of their customers at risk of not being able to accept credit cards through their POS application,” Metzger says.

When evaluating gateway or processor partners, developers should consider the company’s POS focus, organizational capabilities, the variety of their service offerings (hosted, mobile, softwarebased), and their support for a variety of technical environments and operating systems. “Software developers need to choose their points of integration wisely,” Metzger says. “Every time they modify their payment interfaces they are required to revalidate under the PCIPA standard, and that takes time and money. Selecting a payment gateway that has access to more than one processor and has additional value-added features such as encryption and tokenization capabilities will reduce the number of interfaces they will need to support and offer a broad range of options for their customers.”

Mobile payment applications, while increasingly popular in a number of markets, still present some specific compliance challenges because PCI has not yet clarified requirements for the technology. Developers should be aware that if the transaction flows through a back office system and contains clear sensitive data, then the back office system is in scope either for PA-DSS or (in the case of a hosted central system) as a PCI-DSS service provider.

In the meantime, companies within the industry, like Visa, have issued “best practice” recommendations for software developers writing payment applications on mobile devices. “During the period of uncertainty, a developer’s best bet for addressing compliance in a mobile environment is to reduce scope using end-to-end encryption,” Plomske says. “Then, the transaction is secure from the swipe on the mobile device to settlement. Companies like ID Tech and Magtek provide this level of security with their encryption card readers for mobile devices.”

Mobile Payment, EMV Cards On the Way
For POS VARs, the vendors interviewed for this story see an increase in mobile payment technology, alternative forms of payment, and new types of mobile POS devices (like iPads and other tablets) as one of the most significant competitive trends. “POS developers must ensure that their current solution is ready to compete with the new products or else consider developing a new solution with similar functionality,” Plomske says.

Encrypted card readers and tokenization products are another important innovation, Abou-Nasr says. Vendors use different encryption methods, which can complicate application design. “Make sure the encryption method being used by your peripheral is supported by your decryption service provider,” Abou-Nasr says. “Try to avoid third-party decryption services outside of the gateway or processor, since that is another point of failure that the gateway or processor does not have control of.”

The other major development this year will be the introduction of “PIN-and-chip” or EMV (Europay, MasterCard, VISA)-based cards that use microchips to validate payment, as well as near-field communications (NFC) payment technology. VISA is pushing for these types of payment options to be more widely adopted in the United States and will require VisaNet acquirer processors to support EMV by 2013. In addition, the company’s Technology Innovation Program goes into effect in the United States in October. The program allows merchants investing in payment terminals that accept both contact and contactless EMV payments to reduce their requirement to annually validate under the PCI-DSS compliance program. Merchants that have achieved a prior validation of PCI-DSS compliance within one year and are in good standing with the compliance standard can reduce their annual assessment expenses.

“Software developers that have applications based on card-present point of sale technology should make the necessary changes to accommodate these forms of payment in preparation for the advancement of NFC and EMV technology,” Metzger says. “The emphasis on payment card data security and the anticipation of NFCenabled smartphones is helping to drive this initiative, and software developers should consider support for these technologies to keep their application up to date.”

Abou-Nasr adds that the advent of these new technologies will make gateways more attractive to developers. “In order to keep up with all the trends and new regulatory mandates, VARs and integrators should reevaluate the benefit of a gateway versus managing their own processor interfaces,” he says. “They may gain up-front professional service sales, but the long-term impact is more costly when it comes to software and merchant retention.”