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.
- Visa TIP comes the US August 16, 2011
- PCI DSS V2.0 Risk Assessment June 28, 2011
- PCI SSC issues mobile payment app guidance June 24, 2011
- Compliant in the Cloud? Sounds like a reality now! March 9, 2011
- Visa Europe - Understanding PCI DSS Merchant Training Workshop November 25, 2010
- SC Magazine - Most Influential 2010 October 22, 2010
- PCI DSS Merchant Training Nottingham UK June 29, 2010
- Clouds in the sky May 19, 2010
- PCI SSC Releases ISA Details May 8, 2010
- Visa PCI Merchant Training Zagreb April 29, 2010