As retailers implement plans for mobile commerce, they are running into a frustrating situation: the PCI Council is not validating any mobile apps. Interestingly, it's the same roadblock that stymies the developers of those same retailers' mobile payment applications and their PA-QSAs. The problem is that a vacuum has formed between Visa's Payment Application Security Mandates and the PCI Security Standards Council's hold on validating new mobile payment applications.
More than two years ago, Visa mandated—effective July 1, 2010—that "Acquirers must ensure their merchants, (VisaNet Processors) and agents use only PA-DSS compliant applications." With nearly 800 PA-DSS validated applications listed on the PCI Council's Web site, retailers have a wide choice. Unless, that is, they are looking for a mobile commerce application.
The problem with mobile payment applications is that there are some valid security concerns, mostly dealing with the mobile devices themselves. Until these concerns are resolved, we cannot expect any new mobile payment software applications to be added to the validated list.
We, therefore, have a vacuum forming: Visa mandates that retailers use only PA-DSS validated payment applications, but there aren't any new mobile applications being officially validated—at least for now. What is a retailer intent on conducting secure mobile commerce to do?
As I recall from my physics courses, nature abhors a vacuum. Based on what I see happening in the marketplace, this law also applies to the world of PA-DSS and mobile commerce. In this case, we see some leading acquirers stepping into the void and approving payment applications on their own and then offering them to their merchants.
Visa's mandate allows acquirers this freedom of action. In clarifying the mandate, Visa noted that although using PA-DSS validated payment applications "is recommended, a payment application need not be included on Visa's list of PABP validated payment applications or PCI SSC's list of PA-DSS validated payment applications in order to comply with Phase 2, Phase 3 and Phase 5 requirements for use of PA-DSS compliant applications."
To those not familiar with the inner workings of the PCI world, it may seem inconsistent to mandate PA-DSS compliance for an application and yet not require that application to be on the approved list. But this is the case.
Anyone with an online newsreader has seen announcements of new mobile payment applications—in at least one case, offered by a leading acquirer. One thing you might notice is that none of those statements has mentioned anything about PA-DSS validation. Why? My take is because the acquirer is taking advantage of the provision in Visa's mandate that gives it the authority to approve payment applications directly.
That provision states: "Acquirers may determine the PA-DSS compliancy of a payment application through alternate validation processes, which should confirm that payment applications meet PA-DSS requirements and should facilitate compliance with the PCI DSS." But there's more to it than that.Acquirers can determine whether an application meets PA-DSS in a couple of ways. The most direct way is to hire (or have an application developer hire) a PA-QSA to perform an assessment. Alternatively, they could use their own compliance staff to do it.
Based on the findings, the acquirer would be in a position to confirm that the payment application meets PA-DSS requirements and will "facilitate compliance with the PCI DSS" and then offer it to their merchants.
In one move, therefore, an aggressive acquirer can enable its merchants' strategic plans, build customer loyalty and make it harder for a merchant to switch to a competing acquirer.
Does using an acquirer-approved (versus a PCI Council listed) payment application increase risk? It might for the acquirer. But if that acquirer has acted carefully, it should be able to manage that risk. It might be a different case for retailers, though.
In my opinion, if a retailer implements any payment application, regardless of who approved it, it is still ultimately responsible. As with any outsourcing, the retailer can outsource a function but it cannot outsource its responsibility for that function.
In the case of a mobile commerce payment application, the retailer will be the one in the headlines if there is a cardholder data breach. And it also will likely be the retailer on the receiving end of any fines or penalties.
Retailers and their acquirers, payment application developers and PA-QSAs all find ourselves in a mobile commerce vacuum. Some acquirers have broken that vacuum by stepping in and approving payment applications on their own, which is their right.
My forecast is that once new mobile applications are accepted, these acquirers and developers will call their PA-QSAs to have them formalize their findings into a Report on Validation (ROV) that can be submitted to the PCI Council.
Meanwhile, it will be interesting to see what effect these acquirer actions have on the development of mobile commerce. Retailers can stand by and wait, or they can plunge into mobile commerce with a payment application assessed as secure but without the blessing of the PCI Council. The next few months should prove interesting, indeed.
What do you think? I'd like to hear your thoughts. Either leave a comment or E-mail me at [email protected].