Are We Getting Closer to a Mobile Payment PCI Standard?

6/28/2011
Is the PCI Security Council getting closer to a mobile payment certification standard? It would appear so.
 
Last week, the PCI Security Standards Council released its long-awaited update on mobile payment applications. After months of examination, the Mobile Working Group, a Council-led team consisting of representative from each payment card brand, completed the first phase of mobile payment acceptance applications assessment. The purpose: to identify and clarify the risks associated with accepting and validating mobile payment solutions to version 2.0 of PA-DSS.
 
The Council classified mobile payment acceptance applications into three categories according to type of underlying platform/environment and its ability to support PCI DSS certification. They are:
  • Category 1: Payment applications that operate only on a PTS-approved mobile device
  • Category 2: Payment applications that meet the following criteria:
    • Applications that are provided as a complete solution that are bundled with a specific mobile device from a vendor
    • An underlying mobile device that is built (be design or by constraint) with a single function of performing payment acceptance
    • A payment application that when installed on the bundled mobile device (as assessed by the Payment Application Qualifed Security Assessor and explicitly documented in the payment application’s Report on Validation), provides an environment which allows the merchant to meet and maintain PCI DSS compliance
  • Category 3: Payment application operates on any consumer electronic handheld device (e.g., smart phone, tablet or PDA) that is not solely dedicated to payment acceptance for transaction processing
Any mobile payment applications that fall within Categories 1 and 2 will be considered for inclusion as a PA-DSS validated payment application. Meanwhile, mobile payment applications that fall under the third Category will not be evaluated for PA-DSS verification until the “development of appropriate advice, guidance and/or standards to ensure that such applications are capable of supporting a merchant in being PCI DSS compliant.”
 
“We understand that there is a growing demand in the marketplace for guidance on how to so safely and securely implement mobile payment according to the requirements of the DSS and PA-DSS, and we are committed to providing this guidance,” says Bob Russo, general manager, PCI Security Council. The Council is poised to next focus on investigating Category 3 applications.
 
Mobile certification timeline
The move to establish a certification standard began in late 2010 when the PCI Council announced that, “until it completed a comprehensive examination of the mobile communications device and mobile payment application landscape [it] will not approve or list mobile payment applications used by merchants to accept and process payment for goods and services as validated PA-DSS applications unless all requirements can be satisfied.” Just a few months later in early 2011, the Council de-listed a number of mobile payment applications that it had previously been certified by the Council.
 
In late May, Hospitality Technology asked Russo to explain the thought process behind the Council’s decision to de-list mobile payment applications. He said: “Merchants want to do things in a mobile way because it certainly makes things easier for their customers. It’s wonderfully convenient for the customer, but how secure is that device? That’s a big area that we are studying now, and we are studying it really hard. “We realize that there is a big appetite out there for people to get mobile applications to make it as convenient as possible for customers to come in and but whatever they want to buy. But how secure is my credit card information on an iPhone? These are some of the issues that we have to answer, and we are dealing right now with a number of experts in the industry and a number of people in our task force to go through these things— examining them to understand all of the different components because it is not just the application anymore. When it was purely PA-DSS it was the application, not it’s the application plus the device that it is working on and there are hundreds of [different] kinds of phones out there— hundreds of different kinds of mobile devices that people want to be taking these things on— and all of that needs to be secured.”
 
And while the PCI Council was busy examining the mobile payment acceptance application marketplace, the hospitality industry continued its investment in mobile payment applications. Although 2011 is only half-way over, there have already been a number of new mobile payment solutions to hit the market from vendors including: Agilysys, eTab, Revel, Squirrel and more. Likewise, companies including Starbucks, Five Guys Burgers & Fries, and Stacked have invested in mobile payment applications this year.
 
The check-list
So how do you know if your application is eligible for PA-DSS certification? The Council offered the following list of questions to use as a jumping-off point. If you answer yes to any of them, then the application is not eligible:
  • Is this a beta version of the application?
  • Does the application handle cardholder data, but the application itself does not facilitate authorization or settlement?
  • Does the application facilitate authorization or settlement, but has no access to cardholder data or sensitive authentication data?
  • Does the application require source code customization or significant configuration by the customer (as opposed to being sold and installed “off the shelf”) such that the changes impact one or more PA-DSS requirements?
  • Is the application a back-office system that stores cardholder data but does not facilitate authorization or settlement of credit card transactions? For example, reporting and CRM, rewards or fraud scoring
  • Is the application developed in-house and only used by the company that developed the application?
  • Is the application developed and sold to a single customer for the sole use of that customer?
  • Does the application function as a shared library (such as a DLL) that must be implemented with another software component in order to function, but that is not bundled (that is, sold, licensed and/or distributed as a single package) with the supporting software components?
  • Does the application depend on other software in order to meet one or more PA-DSS requirements, but is not bundled (that is, sold, licensed and/or distributed as a single package) with the supporting software?
  • Is the application a single module that is not submitted as part of a suite, and that does not facilitate authorization or settlement on its own?
  • Is the application offered only as software as a service (SAAS) that is not sold, distributed, or licensed to third parties?
  • Is the application an operating system, database or platform; even one that may store, process, or transmit cardholder data?
  • Does the application operate on any consumer electronic handheld device (e.g., smartphone, tablet or PDA) that is not solely dedicated to payment acceptance for transaction processing?
RELATED ARTICLE
X
This ad will auto-close in 10 seconds