Smartphone Credit Card Processing… Is it secure?
For the most part, smartphone credit card processing solutions have matured enough to the point where it’s use is accepted by both merchants and their customers. But even with this widespread acceptance, concern regarding security remains an issue. We trust that the following material will help you put these concerns into perspective.
At the foundation of smartphone credit card processing is the need to keep the customers credit card data secure and unavailable to those that might use this information for fraudulent activity. Smartphones handle much of this by encrypting the credit card data when it’s keyed in, only to be decrypted by the processing server. In more simple terms, the data is mixed up in a manner whereas nobody can read the data, except for the party intended, i.e. the processing server. Should anybody be able to capture this data, it would be of absolutely no use.
This is exactly how your internet browser keeps your credit card data secure when you are shopping on a website that starts with “https” vs. “http.” When using “https” your browser uses something called “SSL” (secured socket layer) which encrypts the data when you submit the credit card payment form, and that data remains jumbled until it hits the payment server. If someone were to intercept this credit card data, it would be of no use. In fact, much of smartphone security relies on the same “SSL” as does your browser since all this is transmitted on the internet. That’s right, your smartphone is using the internet, not your cell signal to process credit cards.
The PCI security standard, which is championed by the credit card industry, requires that credit card data remain encrypted from the point of entry, to the point of processing. This is absolutely imperative to understand when evaluating potential non-compliant applications. In the web example above, lets say the information was entered on a form and processed via a shopping cart connected to Authorize.Net or a similar gateway. That data has to be secure the entire journey, and only Authorize.Net should have the ability to decrypt and read the data. If so, it’s PCI compliant. Actually, it’s the SSL part of all this that is PCI compliant as that is the part which keeps the data secure.
A Simple Processing Example
1st National offers a series of free application downloads titled “Mobile Merchant Pro” which are available for the iPhone, Android, and Blackberry smartphones. These downloads are geared toward those that have a gateway such as Authorize.Net, Zoomgate, etc., and empower the users of these gateways to process credit card via their smartphones for keyed transactions only (no swipe readers).
The Mobile Merchant Pro application does this in virtually the same manner as an online shopping cart. The information is keyed into a form on the device, and when submitted, it does so through “https” (SSL) so the data is encrypted until it gets to the destination processing gateway. In fact, the Mobile Merchant Pro application doesn’t store “any” credit card data at all. What it does store is a reference number for the transaction provided by the gateway. By using this reference number, it can cancel or refund a transaction without ever having to store the credit card information.
So… is Mobile Merchant Pro PCI compliant? No, and it doesn’t need to be. Mobile Merchant Pro is doing just what your browser would do and that is to use “SSL” which “is” PCI compliant. Basically, smartphone applications using SSL should seek PCI Compliance if they are storing sensitive data OR if they are using a swipe device.
Swipe Devices & PCI Compliance
From the information above, it appears as though processing credit cards is every bit as secure as any general shopping cart transaction one might submit on the internet if using “https”, and that is largely true. But keep in mind that this only applies when actually “keying” in the credit card data. When a swipe device is used, it should also be PCI compliant. That means, you guessed it… the data must stay encrypted from the point of “swipe” all the way to the processing server. The challenge now is that SSL only works on the internet, not on swipe devices so it has to use another method of keeping the data secure.
That means that the swipe device has to include some form of a unique “key” that is also shared by the processing server. It requires this “key” so that it can encrypt/jumble the transaction so that nobody else can decrypt/un-jumble the data. This is precisely why you can see the same type of swipe devices branded by different companies, yet they aren’t interchangeable. Each swipe devices needs to be coded specifically for the processing gateway.
Well, lets say we had a smartphone application that worked like this:
- The card data is swiped and the data is encrypted
- The card data was “decrypted” on the smartphone then sent via SSL to the processing server.
Is that PCI compliant? No! It wouldn’t be secure because we’d be decrypting that data on the phone, which we can’t do. To be PCI compliant, we’d have to keep that data jumbled the entire journey from swipe to processing.
The Real Security Risks
Arguably, the most notable or likely security risk is going to be as it relates to “skimming” credit cards. This is the practice of reading the magnetic swipe information from a credit card which is then used to create a new card. This is the same practice we noted in our article about “Fraud at the pump… Don’t be a victim of skimming” Basically, when a non-PCI compliant swipe device is used, the data from a swiped card can be clearly read. So if someone uses a non-PCI compliant reader for a card scan, a criminal can easily use that information to duplicate a consumers card. But if that were a PCI compliant swipe device, they’d get a useless jumble of letters and numbers as we mentioned earlier.
Not all that long ago, merchants could buy Bluetooth card readers that didn’t need to be connected to the smartphone or computer. These were convenient for many, but unfortunately, many of those older wireless readers weren’t PCI compliant and didn’t encrypt the data. As a result, that data flowed through the card reader to the computer or smartphone in a manner that could be easily intercepted by anyone who knew how to hi-jack or monitor that Bluetooth signal.
And while 1st National only uses PCI Certified solutions for our customers, there are providers that offer solutions that are not PCI compliant. Most notably Squareup aka The Square don’t have readers that are PCI compliant. But in deference to our competitors processing solution, lets put this into perspective as well. Unlike the Bluetooth example above, their swipe device plugs directly into the smartphone or pad so there’s no real concern of that data being intercepted. And if they aren’t storing credit card data on the device, or at least doing so securely, that also is not of much concern. So from a Merchants perspective, there isn’t much exposure. But if that swipe device doesn’t encrypt data, it is at least presumable that the device could be used to skim credit card data. So while the merchant might not be concerned, some customers might be. But alas, customers that don’t trust the merchant are not likely to surrender their cards to processing. At least, we’d like to believe that’s the case.
Credit Card Processing Security, PCI compliance, etc. are all very detailed subjects. But we hope this information has been of some value; at least in regard to understanding the impact to Merchant and Customer when a transaction isn’t secure or compliant. In the coming years, those of us in the US will be migrating away from the magnetic stripe media used today in favor of EMV. The latter will rely on smart-cards embedded in your credit card which makes processing a great deal more secure. But this also means that smartphone processing solutions will also being seeing some changes as they’ll require different hardware to read the new cards.