More On Mobile Payments

As I have found out, the definition of “mobile payment” is defined by to whom you are talking.  For consumers, mobile payment means using their smartphone to pay for goods and services.  For merchants it includes the consumer definition as well as using smartphones or similar mobile devices to process payments.

Last year I wrote a post regarding mobile payments and the use of smartphones, primarily the iPhone, for use as credit card terminals.  When I wrote that first post, Apple was running an advertisement for the iPhone that showed it being used to process a credit card payment with the ubiquitous tag line, “There’s an app for that.”  Shortly after that post, the advertisement dropped the iPhone as a credit card terminal.  I am not aware that the PCI SSC or any of the card brands complained about that advertisement, but I found it interesting that those images of it processing a credit card were removed particularly given that a number of security and privacy issues that were and still are being discussed regarding the iPhone.

That is not to say that iPhone credit card adapters have not continued to be developed.  It is just that they are nothing like the one shown in that original Apple advertisement.  The first one that I came into contact with was Verifone’s PAYware Mobile solution and the fact that it is PA-DSS certified.  Whoa!  In my previous post I talked about all of the issues with the iPhone that make it almost impossible to be PCI certified.  How did Verifone create a PA-DSS certified application on the iPhone?  What Verifone did was to create a digital back to the iPhone.  All of the operations that need to comply with the various PCI standards are done through the digital back, not the iPhone.  The iPhone is just used as a display.  In the event that a credit card will not swipe through the digital back, the customer must go to a standard register.  I have also been privy to a number of similar iPhone applications.  All of them avoid the iOS interfaces as iOS is the problem in achieving PCI compliance.

While iPhone is the “Big Kahuna” of smartphones, it does not mean that Android and Windows Phone devices are not also used for credit card payments.  Unfortunately like the iPhone, Android and Windows Phone devices have similar issues that make them difficult, if not impossible; to have PA-DSS certified applications.  So from a merchant perspective, iPhone, Android and Windows Phone all have to be treated very carefully when they are used to process credit card payments.

But security concerns have not stopped merchants from rolling out mobile payments.  Starbucks recently introduced an iPhone and Android application that allows the customer to put their Starbucks cash card on their phone.  The application creates a 2D bar code with the cash card’s number.  The Starbucks POS system reads the bar code and automatically deducts the purchase from the account’s balance.  Within a week of releasing the application, it was determined that if you take a picture of the screen containing the bar code, anyone with the bar code can use the account until it cannot pay for a purchase.  So much for secure mobile payments.

If we expect to secure payments, the traditional credit card is just not going to get the job done.  EMV, aka Chip and PIN, is a short term technological fix but also a back up payment method for where I think we are really headed.  I truly believe that the future in payments is smartphones and other mobile devices with software that generate one-time transaction codes for paying for goods and services.  Whether those codes are displayed as a 15/16-digit number or bar code on a screen or transmitted via Wi-Fi, Bluetooth or RFID, a consumer will not need a traditional credit card.  A 15 or 16 digit number will be necessary to use so that POS systems do not have to be re-engineered to support the new payment method.  Scanners are already capable of reading bar codes from smartphone screens, so that much of the solution is already in place.  Wi-Fi, Bluetooth and RFID technology is coming as we speak so it is only a short matter of time before the infrastructure is in place to support such a solution.  All that is needed is the software.

Such an approach not only will secure card present transactions, but would also tackle the security issues we face with card not present transactions.  If done right, mobile payments can become the solution to our PCI compliance problem.

Advertisement

Extremely Mobile Payment Processing

In a previous post I discussed mobile computing and PCI compliance.  In the last couple of weeks I have been questioned about using mobile devices such as smartphones and Wi-Fi enabled PDAs as payment terminals and I thought this particular incarnation of mobile computing deserved an in-depth look.

Pay attention to that Apple iPhone advertisement.  If you notice in one of their advertisements they show a person processing a credit card payment on their iPhone.  As Apple likes to say, “There’s an app for that.”  However, it is not just Apple that has a payment application for a mobile device; there are also payment processing applications for Windows Mobile environments.  There are also proprietary solutions from VeriFone and the like.  Some of these applications are PABP and/or PA-DSS certified.  Devices from VeriFone and the like are PCI PTS certified, but the iPhone and other cellular phones as well as PDAs are not PCI PTS certified devices.

So when the pizza delivery person shows up at your door and wants to swipe your credit card through their mobile device, how do you know that it is safe?  You likely will not know.

The security surrounding the telecommunications used by these devices is the easiest thing to discuss.  All of the devices I have been able to examine use telecommunications methods that are encrypted either by SSL v3 or TLS.  The cellular network and Wi-Fi are just used as the conduit and are not relied upon to provide any security.

Do not assume that VeriFone and the like are meeting all of the PCI standards.  While their mobile payment terminals are PCI PTS certified, the application software in those devices is not PA-DSS certified.  I pointed to the flaws in these devices in a previous post.

But there are bigger problems lurking with the iPhone.  Ask any computer forensic examiner about the iPhone and they will talk at length about the fact that the iPhone has a number of “features” that make security and privacy things of the past.  From a PCI compliance perspective, some of the more problematic issues are as follows.

• Deleted information does not physically get deleted.  In some cases, deleted data can remain on an iPhone for up to six months or even more depending on use.
• The iPhone has a built-in keyboard logger, so anything typed into it is recorded.
• While it is not certain that card swipes would be retained on the iPhone, given all of the other information it retains, it is highly likely that such information would also be retained.

As a result, using the iPhone as a payment processing platform is probably not a good idea until it is certified.

So what, if anything, are the PCI SSC and/or the card brands doing about this situation?  As much as they can, given that these solutions are popping up faster than they can identify them.  The problem is that the developers of these applications are usually unaware that they are required to comply with various PCI standards.  And since the developer is responsible for certifying their solution unless they get ‘ratted out’, the solution will not get certified.  So it is up to the application developer and the merchants to ensure that an application is properly certified.  If that is not worrisome enough, the cost involved in certifying such an application would likely raise the cost of that solution to a point where it would not be economical to the merchant or salesperson.

Dispelling Rumors – CVV/CVC

One of the things I hate about blogs is that they seem to generate more rumors than dispel. One of the reasons I created this blog was to get rid of some of the rumors surrounding the PCI process. Where these rumors come from, I’m not sure. However, the sooner they are dispelled, the more secure we will be.

The rumors I would like to dispel in this posting are related to why merchants seem to think they need to retain the card verification value or code otherwise known as CVV/CVC. It’s that three digit code on the backs of Visa or MasterCard cards and four digit value on the front of American Express cards. Actually, to be correct, American Express calls it the CID. Regardless of what it’s called, it is NOT allowed to be retained once a transaction has been processed.

The first rumor is that by using the CVV/CVC in transactions merchants reduce their interchange fees with their processor and the card brands. This is not true.

What is true is that by including the CVV/CVC value when a merchant submits a transaction for authorization, should a dispute or chargeback situation arise, the processor and/or card brands will reduce their fees on the dispute or chargeback. The rationale being that the processors and card brands assume that by having the CVV/CVC, it is less likely that the transaction will result in a dispute or chargeback.

The second rumor is that merchants conducting repeat transactions need to submit the CVV/CVC for the original and all subsequent transactions. Again, this is false.

There are two ways to conduct such recurring transactions. The easiest way is to use a processor that can provide you with a reference number from the original transaction and then process all subsequent transactions by allowing you to use the reference number so that your organization does not have to store the cardholder information. The other option is for your organization to store the cardholder’s name, account number and expiration date. Of course, if your organization is storing this information, you need to ensure it is stored securely either by encrypting it if on a computer or physically securing it if using a manual system.