Articles

RSS

If there's one phrase VARs, POS (point of sale) software developers, and payment merchants are going to hear a lot about this year, it's 'PCI compliance.' This phrase generates a range of responses and an even greater amount of confusion in the channel. Because of the importance of this topic, I spoke with four industry experts who helped cut through PCI-compliance confusion and separate fact from hype.

Know The Key PCI Terms And Who They Apply To
Within the payment processing debate are several acronyms that are bandied around. The first one VARs should be aware of is PCI DSS (data security standard). According to Visa, which collaborated with MasterCard to create PCI DSS (which other U.S. card companies are adopting), this is an industry security requirement for payment processing application users that comprises 12 requirements:

1. Install and maintain a firewall configuration to protect data.
2. Do not use vendor-supplied defaults for system passwords and other security parameters.
3. Protect stored cardholder data.
4. Encrypt transmission of cardholder data and sensitive information across open public networks.
5. Use and regularly update antivirus software.
6. Develop and maintain secure systems and applications.
7. Restrict access to data by business need-to-know (i.e. ensure critical data can only be accessed by authorized personnel).
8. Assign a unique ID to each person with computer access.
9. Restrict physical access to cardholder data.
10. Track and monitor all access to network resources and cardholder data.
11. Regularly test security systems and processes.
12. Maintain a policy that addresses information security.

"The PCI DSS is the result of the credit card data breaches that have occurred over the past several years," says Marc Katz, CEO of Mercury Payment Systems. "The big issue today is getting merchants [e.g. retailers] to invest money in hardening their networks and payment processing applications. VARs are having a hard time convincing merchants to pay for upgrades that include better security. We've seen success, however, when VARs take the time to talk about how the new software reduces the risk of a card breach by reducing the storage of card data."

Now that you have a brief overview of PCI DSS, you need to understand the Visa U.S.A. Payment Application Best Practices (PABP), which are derived from the PCI DSS but apply specifically to software vendors that develop payment applications that store, process, or transmit cardholder data as part of authorization or settlement. "By October 2008, Visa has said that if a VAR/software developer does not meet PABP requirements, a merchant acquirer [i.e. payment processor] will not be allowed to process its payment transactions for any new customers," says Jamie Nonni, CEO of Nationwide Payment Solutions, LLC. "Many VARs have the false sense that they are not required to meet PABP requirements because they do not store cardholder data; however, this is false. PABP compliance is required even if the VAR only transmits payment data to the processor for approval."

Should You Get PABP-Certified?
Besides the fact that merchant acquirers won't support noncompliant payment processing applications after October 2008, there are additional risks VARs need to take into consideration, such as getting sued by their customers. "We've already seen a couple of cases in which a retailer's POS system was breached and credit card data was compromised, and the retailer sued the software provider," says Jeff Wakefield, VP of marketing at VeriFone. "In fact, one company that conducted a study on data security breaches discovered that 57% of the time the point of vulnerability was an improperly configured router or a POS system that used only the default password. A typical VAR facing a six- or seven-figure civil penalty could be put out of business."

Ultimately, VARs and ISVs (independent software vendors) need to make the decision whether to get their applications PABP-certified or work with a partner whose application is PABP-certified. Additionally, VARs need to ensure their implementations meet Visa's 12 requirements. Keep in mind, however, the cost of certification isn't cheap. "VARs will find that it will cost a minimum of $20,000 to become PABP-certified, plus they'll pay $6,000 a year to maintain their certification — and even more when you take into account their labor costs spent achieving/maintaining their certification," says Nonni. Some VARs may see these numbers and think they need to get out of the payment processing business altogether. However, there are other options. One option is to separate payment processing from the POS via a stand-alone card-swiping unit. This ensures the VAR's customer isn't storing credit card data on its computers and avoids the necessity to become certified. The downside of this option, however, is that having an integrated system is what helps your customer improve efficiencies (e.g. only entering POS information once) and reduce POS errors. "Businesses are driving for integrated gift card, back office accounting, and time and attendance systems; stand-alone systems are becoming a thing of the past," says Mark Goddard, senior VP of development and product services at Payment Processing, Inc. (PPI). "We recommend VARs partner with PCI-compliant vendors and other organizations rather than trying to achieve PCI compliance by themselves. Even though Visa lists only 12 requirement categories for compliance, there are a couple of hundred subcategories that VARs need to know about as well." Visa also has a list of POS applications that are compliant as well as a list of applications that aren't. You can access this info at http://usa.visa.com/ (under the 'Merchants' tab).

Working with a certified payment processing vendor and/or merchant processor is a step in the right direction, but according to Nationwide Payment Solutions' Nonni, the VAR still shares some of the liability if cardholder data is being stored or transmitted with customers' computers. "Another option VARs should consider is using a browser-based processing solution," he says. "In this scenario, a Web browser with a secure connection to a payment gateway is launched, and all the payment information is entered into the browser. Since the credit card payment is processed via a Web browser that wasn't created by the VAR, the VAR isn't responsible for the transaction security; rather, the payment processor is responsible. Once the transaction is complete, the browser-based solution updates the customer's POS system with nonsensitive data such as the customer's name, merchandise purchased, and the total amount of the transaction." This payment-processing model, like the stand-alone model, eliminates the need for VARs to become PABP-certified as well as the need to keep up with the latest communication updates (i.e. processing, clearing, and settlement of credit card transactions).

Capitalize On The Upcoming PCI Deadline
Even though there is going to be a lot of buzz about the upcoming October 2008 deadline, VARs should see this as an opportunity, not a threat. "The deadlines give VARs a good reason to visit customers with legacy POS systems that don't support the latest encryption standards and educate customers about the necessity to update these systems," says Goddard. Even if customers have systems that are newer, the VAR can help by providing auditing services to ensure the customer's network and routers are secure, no applications are using the default passwords, and data encryption is being used. "VARs should no longer see themselves as selling payment solutions," says Wakefield. "Instead, they should see themselves as selling secure payment solutions."