My last post on the PCI SSC backing off on certifying mobile payment applications sure got a lot of people in touch with me. As a result, I would like to recap my discussions with them so that the rest of the readership can be up to speed on this topic.
Like the term “cloud computing,” “mobile payment” means a lot of different things to people. For most people, a mobile payment refers to the use of a cell phone, smart phone or personal digital assistant as the credit/debit card. However, for a number of my more progressive merchant clients, a mobile payment refers to the use of a mobile, wireless device as a cash register. This is one of the reasons why I believe that the PCI SSC has pulled back on certifying mobile payment applications. The definition is becoming too broad and confusing thus creating too many issues to cover in a quick time.
Then there are the methods as to how these mobile payments are conducted. From a consumer side, mobile payments can be done through RFID just like the contactless cards currently being deployed in the United States as well as using Bluetooth or Wi-Fi. From a merchant perspective, there are a number of large merchants that are rolling out smart phones and PDAs with software to process payments over Wi-Fi and cellular. All of these communication methods have risks associated with them.
Then there are the devices themselves that are involved regardless of whether you have the consumer or merchant view. When you talk of cellular devices such as cell phones and smart phones, you open a Pandora’s Box of operating environments from proprietary to Windows and a number of others in between. PDAs offer some common operating environments with their cellular brethren, but also bring some OSes of their own to the table. All of these operating environments have their own idiosyncrasies when it comes to security or lack thereof.
Add into the mix the variety of proprietary and open development environments for each platform. Then there is how applications get distributed. Apple started the application marketplace approach and all the other mobile OS vendors are following their lead. This all causes the issue of who makes sure that payment applications are certified? Is it the developer or the marketplace? Does the marketplace need to make sure that payment applications have been certified before they are allowed to be pushed out? It is issues such as these that need to be discussed and addressed before the PCI SSC can issue guidance. And these issues surrounding distribution are not simple ones.
Ultimately we are heading towards a payment environment where there is no card in the traditional sense. I truly believe that a software algorithm will be developed that will generate secure, single use “codes” that are used to conduct transactions between consumers and merchants. This algorithm will be similar to the Advanced Encryption Standard (AES) and will be platform independent and therefore can be run on any “intelligent” device.
In the end, I am sure all of this led the PCI SSC to want to take a step back rather than blindly charge ahead, issue a standard and then have to repeal or greatly modify the standard because of knowledge gained later. Such an approach, while inconvenient to the rush of technology, should create a much more thoughtful approach. So let us all be patient and let the Council do their work and get it right rather than issue something that ultimately is severely flawed.
PCI Guru 