PCI SSC issues mobile payment app guidance

Today the PCI SSC issued a short guidance document based on the work undertaken by the mobile working group. This follows on from an FAQ on the subject issued earlier in the month. In summary they have created three categories of mobile devices that accept payments. The first two categories cover more traditional payment application devices with the first category requiring prior PTS certification and the second being a custom built solution whose only applications is processing payments. This obviously segregates payment applications running on mobile devices such as smart phones which have an underlying mutli-purpose operating system. This third category is currently excluded from being submitted for PA-DSS certification. As a result it is not possible for vendors to demonstrate that these kind of application are capable of being deployed in a PCI DSS compliant manner (this is different from them not being capable of being PCI DSS compliant). It seems as if the complexities in reaching a decision to allow this kind of application to be validated is still an issue. However the FAQ does make it clear that merchants using such application should include these devices in their annual PCI DSS assesement (i.e. they are in scope).

However this hasn't stopped vendors putting solutions into the market place which are leveraging the rapidly growing number of smart phones. For example a Canadian company PayFirma has recently launched a iphone payment application that can even swipe a card and accept a customer signature on the iphone touch screen. Payfirm are not alone, a quick google search on the string "iphone payment application" brings back plenty of other vendors.

So why is this a concern? The underlying issue has to be regarding infection of these devices with malware. An infected device which also connected to the internet would allow criminals to harvest data remotely. No need to tamper with the physical payment terminal anymore simply target devices through the web. There is also the larger concern of infected applications by targeting the application in the various 'app stores' themselves. We have recently seen Google drop the kill switch on infected android apps which demonstrates that this is in the realm of the actual rather than theoretical.

It is interesting to see that much of the growth in the mobile payment application is in regions where penetration of EMV is low. In theory the presence of 'chip and pin' should mean that customer present transactions require authentication by the customer entering a pin. Pin entry devices are not so easy to tack onto a smart phone.

So why the interest in mobile payment applications in the first place? Well the first bit is obvious, they are mobile in the true sense (not just on the shop floor) so for merchant who are very mobile this is a very convenient method of accepting payment (plus you don't need to hawk large amounts of cash around). The second is the possibility to add a richer set of information around the payment itself, such as recording product details, identifying repeat customers and making reconciling payments that much easier. The benefits are easy to understand.

However the issue of compliance still remains and ultimately it is up to the merchant who is accepting payments to ensure they are PCI DSS compliant. So how does PCI DSS apply to payment applications on devices such as smart phones? This is an interesting question and one that is not easily answered at present. For example is a smart phone a system that is 'commonly affected by malicious software' and therefore will requirement 5.1 apply? If so you need anti-virus/anti-malware software active and running. This is just the tip of the iceberg as PCI DSS was not really designed to apply to this type of scenario. The situation is compounded by many applications actually processing the payment request using remote payment applications being accessed by a web browser on the smartphone. Assuming this connection is protected using SSL/TLS is the payment application really a payment application or simply a 'thin client'? Also for regions where EMV penetration is high the customer is typically required to authenticate themselves in a customer present situation by entering their pin into a pin entry device. To date I am not aware of any smart phone application offering a connected pin terminal. Downgrading the transaction to a swipe equivalent will leave the merchant exposed to possible fraud and associated charge backs.

In summary mobile payment applications on devices such as smart phone continue to be in 'limbo' with respect to PCI DSS compliance. It will be interesting to see how this emerging technology matures.


Comments (2)

Said this on 7-31-2011 At 09:18 am

Whveoer wrote this, you know how to make a good article.

Said this on 8-16-2011 At 12:44 pm

Thanks Tory, I have a follow up article on the subject in the nex week dealing with some of the security issues around the square application that have surfaced over the last few weeks.

Post a Comment
* Your Name:
* Your Email:
(not publicly displayed)
Reply Notification:
Approval Notification:
Website:
* Security Image:
Security Image Generate new
Copy the numbers and letters from the security image:
* Message: