This is page 2 of:
Acquirers Rush In Where PCI Fears To Tread: Mobile
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 wconway@403labs.com.
-Marc
December 1st, 2010 at 3:11 pm
Given the ridiculous situation that the PCI SSC finds itself in with a backlog of over 8 months for PA-DSS ROV reviews, the last thing they needs is more workload! So good on the acquirers, they accept the risk and technology advances!
December 2nd, 2010 at 10:38 am
Mobile payment applications are here and more are coming. Innovative devices like the iPad and Android tablets are going to change the way small merchants do business. We are moving away from the PC being the traditional POS device to an iPad/Android centric model. They are cost effective, easy to use, and highly mobile. The Standards Council must address this issue. They have to keep pace with the advancements in payment technology are get left behind and become obsolete.
December 2nd, 2010 at 12:30 pm
I think many retailers are looking at Apple Retail and thinking, “why can’t I use an iPod touch with scanner attachment for MPOS?” So the next question would be, “Is that PCI compliant?” If Apple is PCI compliant, does that pave the way for shoppers with iPhones? Will there be an m-commerce area on the app store, where ‘approved’ payment apps could be downloaded for consumers?
December 2nd, 2010 at 6:07 pm
The question, “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?” has one more answer. Outsource. Just like websites do, retailers can outsource payment acceptance on the mobile device to a Level 1 PCI provider and eliminate the need to PA DSS the software, at all. Whether it’s a mobile browser re-directing to a hosted payment page or a downloaded app programmed to call a secure hosted payment page or payment form, it should reduce the merchants’ scope of PCI. We launched this exact service to online merchants for paying over iPhones and Androids last week. I’d welcome your comments, Walt, on this approach.
December 2nd, 2010 at 6:40 pm
I was a little confused at first. It sounds like what you’re referring to is mobile terminals used by merchants for card acceptance. mCommerce on the other hand is when consumers make a purchase using their own mobile device. With mCommerce, PA-DSS is incredibly irrelevant since it’s intended for systems distributed to merchants for use in their card data environment. There’s nothing I’m aware of in PCI standards that addresses consumer applications.
December 2nd, 2010 at 10:07 pm
First of all, thanks to all for the excellent comments (and those of you who emailed me).
@Chalky and David, you both hit it on the head, but I’d like to add one thing. The point of the column was that it is not about the PCI Council or even Visa and the mandates. I was highlighting (as you both pointed out) that the news is about retailers and particularly their acquirers. I think there are risks to both, but those risks are manageable as evidenced by the recent announcements. A lively market benefits everybody, consumers and retailers (and certainly acquirers) alike.
@ Richard, I think what scares me is there already are payment apps out there. They are not PA-DSS validated (as far as I can tell), and it’s unclear whether Apple cares or wants to be responsible.
@Greg, I am also a fan of outsourcing as I’ve written several times. But in many cases the merchant may want to control their environment, have a particular application: what works for a store may not work for a coffee shop or a fitness center or a parking lot. Nevertheless, I agree hosting will have a role to play in this area. It will be interesting to see whether outsource vendors will address 12.8.2.
@Lucas, you raise a great point, and we may need to define our terms better. To me, mobile commerce can include a merchant using an enabled mobile device, whether it is an iPad, iPhone, Android, or whatever. I’m even including a cube to read the mag stripe and the sleds to transform a smart phone into a payment terminal. It’s a broad topic.
A great discussion. I hope it continues here and at NRF (be sure to catch StorefrontBacktalk (and me) there: http://www.storefrontbacktalk.com/securityfraud/at-nrf-storefrontbacktalk-panels-to-include-top-cios-on-mobile-security/
December 11th, 2010 at 4:18 pm
At first blush, I thought this was ridiculous. But now I’m just surprised that Visa has a loophole like this in their program. I imagine it was meant for acquirers to use rarely.
First, this is only Visa’s position. So how this may apply to any other card brand is uncertain.
For another thing, it is okay for an acquirer to take on risk this way. But if there is a compromise, what happens to the merchant? Do they still get safe harbor when not using a listed application? ‘Probably’ isn’t a great answer.
December 20th, 2010 at 5:04 pm
What about the existing Mobile applications already certified and the ones already with completed ROVs submitted for Listing? Will the SSC delist these applications and if so, on what grounds?
The SSC is getting itself in dangerous waters by selectively approving applications after it issued a standard and approval process.
Businesses on both sides of this issue are making important decisions based on what this organization has done to establish itself as a market controlling entity.
I would suspect lawsuits will follow if this ban on mobile applications that have been validated isn’t lifted soon.