A Narrative on Apple Pay, Google Wallet, CurrentC, & Mobile Payments

Apple Pay's introduction has certainly generated a lot of press coverage, especially as it relates to its banishment by retailer-led consortium MCX.

However, a lot of the articles I've read contain a great deal of incorrect information about Apple Pay and other mobile payment methodologies, so I thought it might be useful - especially to those without a background in technology or security - to put forth some explanation, corrections, and facts.

There's a lot at stake here, both for the companies involved and for you, the consumer. It's imperative that both make intelligent choices concerning how money is handled and secured in this new era of payment technology.

TL;DR: It's about security (not convenience) and what data you are willing to give up - or fight to secure.


"Okay, so talk to me about this mobile payment thing that's been in the tech and business news lately.."

Mobile payments suddenly became a hot topic several weeks ago when Apple revealed that the iPhone 6 and 6 Plus would support contactless payments through their new service called Apple Pay. Previously, the mobile payment system with the most traction - and this isn't saying much - was Google Wallet. When Apple Pay went live, CVS and Rite Aid quickly shut it down, and the world found out about another player that had been largely unknown - CurrentC. But right now, all the buzz is about Apple Pay and making credit card payments with your iPhone.

"OK, I'm not sure that I want to store my credit card data on my iPhone; that would make fraud possible if it is lost or stolen, right?"

Your credit card number isn't stored on your iPhone. It is replaced with a random number that your iPhone and bank agree on that looks like a credit card number to the payment system, but really isn't. Your bank can translate that number back into your real account number when they receive a payment request. This number is stored in an encrypted fashion in a special, secured part of the iPhone called the Secure Element, which is not accessible to the operating system itself, but only to the part of the iPhone that communicates with the payment terminal (the NFC chip, more on that later). Access to the Secure Element is predicated on successfully authenticating a given transaction with your fingerprint or passcode.

If your iPhone were to be lost or stolen, your cedit card number could not be retrieved from the phone, since it is never stored there in the first place. Any attempted transaction would require your fingerprint or passcode. Further, through the Find My iPhone feature of iPhone, you can disable payments entirely - or even the entire phone.

"Apple Pay costs retailers money, right?"

False. Apple makes 0.15% of each transaction made through its service, but that is paid by the banks themselves from the transaction fee they are already charging the merchant. In other words, the banks are giving up some of their cut to Apple. Why? Because they expect to more than make up for it in reduced fraud costs due to Apple Pay's inherent security. The merchant pays no more to process a sale through Apple Pay than they would with a swiped credit card.

It is true, however, that it may cost money for merchants to obtain a credit card terminal that contains the technology needed to enable Apple Pay (NFC - "Near Field Communication", a type of short-distance radio communication technology). However, most retailers either have, plan to, or are in the middle of upgrading to new terminals anyway, in order to support EMV credit cards, also known commonly as "chip and pin". These cards are not swiped, but rather inserted into the terminal, which reads your card number from the chip embedded in the card. You then enter a pin to both authorize the transaction and prove that you are the legitimate cardholder.

An EMV card

Retailers are being compelled to upgrade to EMV-compatible terminals before October 2015, which is a deadline imposed by the card networks - NOT by law as has been alleged - if the merchant wishes to avoid being held liable for fraudulent charges made at their stores.

Most terminals that support EMV that are available from the major manufacturers also support NFC, with some at a relatively low increased cost. Therefore, if a retailer has to upgrade to support EMV anyway, they may as well pay a little extra - if required - and get NFC support as well.

"Dont some retailers already have NFC capable terminals?"

Absolutely, some have had them for years. With some exceptions, you can identify an NFC-capable terminal by the presence of this logo:

CVS, for example, has had these terminals for well over two years - and Google Wallet users had been using them with little fanfare - until CVS shut down the NFC feature on their terminals.

"Wait, what? They paid for those terminals and then disabled the NFC capability?"

Yup, you got it. Within days after Apple Pay launched, CVS and Rite Aid disabled the ability to make NFC payments in their stores.

"That's odd. Why would they do that?!"

CVS and Rite Aid belong to a consortium of retailers known as MCX. MCX is in the process of rolling out an alternative payment system known as "CurrentC", and the move by CVS and Rite Aid is apparently related to this. MCX is backed by some heavyweights in retail, including Wal-Mart, 7-Eleven, Shell, Circle-K, and others.

However, the reasoning is cloaked in mystery. The New York Times published an article stating that MCX members are contractually prohibited from accepting other forms of mobile payment:

The problem is that under the terms of their MCX contractual agreement, they are not supposed to accept competing mobile payments products like Apple Pay, according to multiple retailers involved with MCX, who spoke on the condition of anonymity. If these retailers break their contracts, they will face steep fines for doing so, these people said.

However, MCX held a press conference with reporters where their CEO appeared to refute it, only to have his responses "clarified" by MCX's COO:

Rankin said despite what has been reported, MCX retailers were allowed to use Apple Pay without suffering any sort of penalty. However, MCX retailers will have to leave MCX if they want to accept Apple Pay.

He then appeared to clarify his own clarification:

"When merchants join us, they have a choice... they can't have Apple Pay or Google Wallet until their exclusivity expires," said Scott Rankin, MCX chief operating officer.

Read more at http://www.tweaktown.com/news/40883/currentc-open-to-more-consumers-but-fighting-tough-marketing-battle/index.html

So essentially what it boils down to - at the moment - is that a retailer can be part of MCX, or accept Apple Pay, but not both.

Oddly, one MCX member, the grocery chain Meijer, has said that it will continue to accept Apple Pay, leading to speculation that it will be leaving MCX.

“We have had the technology in our stores to accept mobile wallets for several years now,” Meijer spokesman Frank Guglielmi said. “If a customer has Apple Pay capability, our hardware works with it.”

“We don’t plan to remove or disable these systems,” he further said.

"Okay, so what about this CurrentC? If Wal-Mart and those other major retailers are backing it, maybe I should use that?"

A valid question. Let's examine CurrentC:

CurrentC appears to have been designed to overcome two issues that retailers want to solve: Avoiding the transaction fees that merchants pay to accept credit cards, and to allow merchants to collect (and potentially share) more information about their customers.

The second point has, in my opinion, been blown out of proportion slightly. In many cases, this information - usually tied to some sort of loyalty program - is benign, and might even offer the customer some benefits, such as discounts, coupons, or product recommendations. However, some view this as too invasive to privacy, demonstrated in the extreme in this Forbes article which details how Target analyzed a teen's purchases, deduced that she was probably pregnant, and sent her coupons for baby clothes and cribs, in the process outing the pregnancy to her father. Data mining in this manner is compellingly interesting. From the article:

One Target employee I spoke to provided a hypothetical example. Take a fictional Target shopper named Jenny Ward, who is 23, lives in Atlanta and in March bought cocoa-butter lotion, a purse large enough to double as a diaper bag, zinc and magnesium supplements and a bright blue rug. There’s, say, an 87 percent chance that she’s pregnant and that her delivery date is sometime in late August.

Now, this can be, depending on your outlook, either quite helpful or seriously creepy. I'll let you decide for yourself if this is a potential positive or negative.

What is more concerning, however, is related to the first point - avoiding credit card transaction fees. CurrentC will get around these by taking payment directly from your checking account, using a bank draft known as ACH. ACH payments carry a much lower fee for transactions, and thus are preferable - to the merchant. However, ACH debits (and debit card use, incidentally) have far less consumer protections than credit card transactions do. Let's examine what might happen if either was the subject of fraudlent transactions, from this paper by the Federal Reserve Bank of Chicago:

Federal law generously protects consumers against responsibility for unauthorized ACH, credit card and debit card transactions. However, some of the liability for unauthorized transactions can be shifted to consumers and the amount that can be shifted to the consumer is higher if a debit card or ACH is involved than if a credit card is.

(By law) the credit card holder can be held liable for the lesser of $50 or the amount obtained by the unauthorized use before notification to the card issuer about the loss, theft or possible unauthorized use. This is the generally the maximum consumer liability irrespective of when the card issuer is notified.

Most credit card customers know this; if your card (or card number) is stolen, you are liable for, at most, $50.00. Further, both MasterCard and Visa have "zero liability" policies covering both credit AND debit cards made through their networks.

ACH protections are not that simple:

The rules are more complex -- three possible tiers of liability are specified. Simplistically, a consumer may be liable for (l) up to $50 (if notification is given to the financial institution within two business days after learning of the loss or theft of the access device); (2) up to $500 for unauthorized transactions made more than two business days after the discovery of the loss (if the financial institution is not notified within two business days); or (3) an unlimited amount depending on when the unauthorized electronic fund transfer occurs (i.e. if the consumer does not notify the financial institution within 60 days after receiving a periodic statement showing an unauthorized transaction and unauthorized transactions occur subsequent to the 60-day period that could have been avoided with appropriate notification, the consumer may be liable for those later transactions). If a stolen debit card is used to initiate the transaction, all three tiers of consumer responsibility are potentially applicable. However, if the transaction is an ACH transaction against a deposit account and no card or personal identification number is used, than only the third tier of consumer responsibility is applicable.

Confused yet? The truly salient point above is this: "if the transaction is an ACH transaction against a deposit account and no card or personal identification number is used, than only the third tier of consumer responsibility is applicable".

That "third tier", remember is: "an unlimited amount depending on when the unauthorized electronic fund transfer occurs (i.e. if the consumer does not notify the financial institution within 60 days after receiving a periodic statement showing an unauthorized transaction and unauthorized transactions occur subsequent to the 60-day period that could have been avoided with appropriate notification, the consumer may be liable for those later transactions)."

So, essentially, if you don't notice the transactions, fail to report them, or simply cant prove that you did report them, you can be liable for every transaction that occurs after the 60 day period following the receipt of your monthly statement.

Secondly, if your credit card is used to make unauthorized transactions, you aren't actually out any money; you are permitted by law to withhold that amount from your credit card payment while the matter is under dispute. If your bank account is debited, that money is simply gone and completely unavailable to you - and the process to (attempt to) recover it is far, far more difficult than filing a credit dispute. Further, you have no recourse for any fees resulting from the fraud, like any fees you pay if your account is subsequently overdrawn because of the fraudulent debit.

So using ACH as a payment method is certainly not as safe as using a credit card, or, largely, a debit card. However, to avoid the credit card transaction fees, this is what CurrentC will require you to do, as they only accept ACH or Target cards, even though they claim that you will be able to use credit cards as well in the future. Given that the major reason for CurrentC's existence is to avoid the use of credit cards, this seems a dubious claim at best.

Worse, when you add your bank account, CurrentC requires you to provide your Social Security number AND Driver's license number ("used to confirm your identity"). They say that this data "is not stored on your phone", but - perhaps tellingly - don't say that it isn't stored anywhere on their systems.

This becomes of critical interest when we consider the sum of the information that CurrentC is likely to store about you:

  • Name
  • Address
  • Date of Birth
  • Social Security Number
  • Driver's License number
  • Bank account and routing number

Update: MCX is now saying that driver's licenses and social security numbers will not be required to sign up for CurrentC. However, their privacy policy still states that they will be collected (and therefore still a concern), but not retained. What does this mean? Who knows... We will have to wait and see.

This is such an obvious target for identify theft that it scarely needs to be said. Were MCX's databases containing this data to be breached, it would be an absolute nightmare for users of CurrentC, far worse than the ramifications of any of the major data breaches at Target, Home Depot, TJ Maxx, et al. What would you, at a minimum, need to do?

  • Close and re-open your bank account
  • Order new checks
  • Order a new debit card
  • Change any recurring online payments (utility bills, etc)
  • Request a new Social Security card/number, which complicates obtaining new credit and dealing with agencies (like the IRS) that have your old number on file.
  • Order a replacement driver's license

On top of that, add the hyper-vigilant credit monitoring that will be required for the foreseeable future to catch any use of your identity before it causes you major problems. How major? Well, besides financial ruin and massive amounts of time cleaning up the charges and your credit history, you can also wind up proving that you are not a criminal or losing your driver's license.

In case those links don't frighten you sufficiently, here's some more victim's stories.

Incidentally, CurentC will collect details of your medical history (through prescription purchases, for example) which may be a cause for concern as well. As MCX states in their Privacy Policy amongst the types of data they collect:

"Your protected health information, claims or other information used to measure your health or wellness if such information is included in your Payment Account transactions. **Please note that while direct protected health information is not normally required for a Payment Account transaction, some protected health information, such as the number of prescriptions you purchase each month, or the location of the pharmacy or store where you purchase prescriptions, may be included in information generated in conjunction with a Payment Account transaction."

If leaked, this data could certainly cause some privacy-related concern, especially if it was posted/indexed online. Searches for your name might, for example, reveal that you purchase medication to treat HIV, depression, or other conditions that you'd rather keep private.

"Wow, that's some pretty sensitive data. How's their security track record?"

Not promising. 25% of the retailers that make up MCX have been involved in breaches in recent years:

MCX itself was the subject of a relatively minor compromise of email addresses belonging to their pilot program members. While they claim that it was not their network - rather that of a third party email provider. This should be cause for concern, but it's not a show-stopper in and of itself.

However, in toto, this is a lot of sensitive data in the hands of a consortium that itself has no positive record in data security to speak of and is made up of members who have a less than stellar record, all considered. And, remember, the documented breaches occurred long before they were disclosed; there may be others that haven't been discovered or disclosed yet. Giving MCX this data seems to be a risky gamble.

Also, CurrentC is not yet available, and isn't expected to be until sometime in 2015. Consumer backlash and subsequent media attention in the wake of the CVS and Rite Aid diablement of NFC (thereby thwarting users of both Apple Pay and Google Wallet) might cause a net loss of merchant members through defections, further limiting where CurrentC can be used. Several analysts are predicting that CurrentC is "dead on arrival", and it is hard to argue with their conclusions.

"Okay, so how do Apple Pay and Google Wallet overcome these security issues?"

In similar, yet differing ways.

Before we discuss them, let's examine how a credit card transaction works:

  1. Customer's credit card is swiped into merchant's terminal.
  2. Merchant's terminal reads the credit card number (called the "Primary Account Number", or PAN), the expiration date, and a security code called "CVV1". Note that this CVV is NOT the one printed on the back of the card, which is called "CVV2". CVV1 is intended to prove that the card was swiped in person ("was present"). The CVV2 is used for online or telephone transaction where the card, by definition, is "not present".
  3. The PAN, expiration date, CVV1, and other data is transmitted to one or two entities collectively known as the "aqurier" - a company who sells and places the terminal equipment at the merchant, and the bank (known as the "merchant bank" that handles the transaction. In some cases, the merchant bank also provides the equipment, so both entities are the same.
  4. The acquirer transmits the payment data to the card network (Visa, MasterCard, etc).
  5. The network routes the payment data to the issuing bank - the one you have your account with - that issued the card.
  6. The issuing bank approves or denies the transaction. Assuming it is approved, an approval code is sent, your account is charged (the amount is "held", and actual payment occurs behind the scenes (the amount is "posted" to your account).

The vulnerability here is that anywhere along the path from the merchant's terminal to the bank, this data - which is not encrypted in any way - can be intercepted and used by criminals to make unauthorized purchases. This is precisely what happened in the Target and Home Depot breaches, for example; malware was installed on the payment system computers connected to the terminals that processed the transactions, which copied the data and sent it to the criminals.


Apple Pay is not so much a mobile payment platform as it is a mechanism to securely process a standard credit card transaction. Apple Pay implements a concept known as "tokenization", which in this case replaces the credit card number (PAN) with a substitute value - chosen at random - called a "token". The actual details of the process have not been entirely made public, but here's a combination of what is known and what, therefore, is likely:

  • You enter your card information - manually or with the iPhone camera - into the Passbook app on iPhone. Note: Contrary to some claims, you don't take a picture of the card. It is read through Optical Character Regognition - meaning that the iPhone reads the numbers and letters off the card and enters them for you instead of you typing it yourself (and perhaps making a typo).
  • iPhone determines if the card belongs to a bank that works with Apple Pay. If so, it looks up the public key that belongs to that bank - likely provided during software updates - and establishes an SSL tunnel with the bank for secure communications.

Some quick notes here:

For brevity, I won't get into public key cryptography or SSL here, except to say that they are very secure and industry-standard ways of establishing secure communications and authenticating that you are communicating with whom you believe you are communicating to. While not infallible, when implemented properly they are very secure,especially for short-duration communications. Secure web pages use this technology.

Apple's security guide that covers Apple Pay states that SSL, rather than the much more secure replacement protocol TLS, is used. It is unclear if SSL is indeed in use (which would be bad) or if Apple just chose to use the more widely recognizable term, but is really using TLS.

  • The iPhone and the bank agree on a Device Account Number (I will call it the DAN here, though Apple doesn't use the term) to replace the PAN (this process is not described, but presumably uses pseudo-random numbers that meet the requirements for a legitimate credit card number). The DAN is then encrypted and stored in the Secure Element in the iPhone. At this point, the card is available for use.
  • When you use Apple Pay at a merchant, you authenticate using TouchID (your fingerprint) or your passcode. The DAN is then released from the Secure Element along with a one-time authentication code (likely sent in place of the CVV).

More notes:

The one-time authentication code is only described in terms of what elements are used to derive it; the method in which it is derived is from these elements is unknown. This is a concern, but an educated guess from the nature of the elements in use - I will spare you the details - would be that there is no likely vulnerability here. The elements are presented in the Security guide.

The code is said to be computed in part from a key that is known to "the payment network and/or the issuer". Presumably, since American Express not only issues cards itself but also allows banks to issue cards, this particular phrasing was used to accommodate both possibilities. I.E., American Express might be where the DAN is translated into the PAN, even if AMEX didn't issue the card itself. Following this logic, MasterCard and Visa wouldn't be able to convert the DAN to the PAN, only the actual issuing bank would. Again, an assumption, but a logical (and crucial) one:

  • The payment information (DAN and security code) make their way to the issuing bank (or, for AMEX, possibly terminating at AMEX as described above).
  • The bank translates the DAN into the PAN and charges the account as it would a traditional "swiped" charge.

The important part here is that the PAN is never stored in the iPhone nor transmitted. Neither is the CVV. The DAN is useless without the one-time code, and since the one-time code cannot be re-used, interception of the DAN and code is pointless, since an attacker cannot (in theory) properly authenticate use of the DAN since it relies on information (how to generate the one-time code) that the attacker cannot know. This means that if Apple Pay had been available and used at Target or Home Depot during the period in which they were breached, that the customers using Apple Pay would not have been affected.

In fact, the only way to gain the requisite information to generate the one-time code is contained in the iPhone, so the attacker would have to steal one. However, the applet that generates it is in the Secure Element, which, you may recall, is not accessible by the operating system. Further, the owner of the phone can invalidate all of the DANs in the phone remotely with the Find My iPhone feature, and presumably with a call to the bank as well.

The other possibility is to attack the bank directly. Of course, this has been a possibility all along; the bank has always (obviously) had all of the credit card information on file, since it issued it and validates it for each purchase.

However, one other salient point to consider is that if a bank does suffer a breach, that breach only impacts that bank's customers. Remember, if CurrentC is breached, every one of their customers is at risk - and for a lot more than credit card fraud.

One other difference between Apple Pay and CurrentC - Apple Pay does not require internet access to be used, where CurrentC will. That has implications for areas in which internet access is poor, non-existent, or too expensive (some stores, for example, where cell service is spotty, or while aboard cruise ships or on airplanes).

Google Wallet can best be described as a hybrid between CurrentC, Apple Pay, and traditional card swiping. As a pioneer in mobile payments, it has had - and has largely overcome - some of its largest hurdles, but adoption and usage never reached critical mass.

Google Wallet offers mobile payments via most recent Android handsets with NFC capabilities as well as a physical credit card. You fund your Google Wallet via your credit card (yay!) or your bank account (boo!), and are strongly incentivized to use the latter, since Google will charge you a transaction fee to fund with a credit card (double boo!).

Unlike Apple Pay, Google Wallet doesn't appear to perform tokenizaton per se, but instead assigns a virtual MasterCard to your Google Wallet account. The payment is processed by Google (in effect acting as the acquirer), and the funds deducted from your Google Wallet balance. You can also obtain a physical Google Wallet card for use in online or in-store transactions that debits from your Google Wallet account as well.

Google Wallet doesn't perform tokenizaton, but instead assigns a one-time virtual MasterCard to your Google Wallet account for each transaction you make. The payment is processed by Google (in effect acting as the acquirer), and the funds deducted from your Google Wallet balance. You can also obtain a physical Google Wallet card for use in online or in-store transactions that debits from your Google Wallet account as well.

The on-time virtual MasterCard expires when a transaction is complete, which means that Google Wallet - when used to tap and pay from an Android phone - is not vulnerable to the same type of card interception suffered by Home Depot & Target.

So for NFC payments, the security, fraud detection, and billing are all concentrated at Google - making them a target for hackers. Google, it must be said, has a good security track record thus far.

However, we can expect that the physical Google Wallet card behaves like a regular mag-stripe card, so this card would appear to be vulnerable to interception.

"Okay, so which is the most secure?"

I have to go with Apple Pay here. It is the only solution of the three that:

  1. Tokenizes payment data end-to-end
  2. Holds no sensitive data
  3. Does not use ACH debits

While there still remain questions about how some of the security and keying material is derived with Apple Pay, it seems quite clear that it is the most secure option that consumers have today.

"That's settled, then. How about ease-of-use? And doesn't CurrentC use those old and outdated QR codes?"

Apple Pay seems to be by far the easiest solution to use, given that you never wake up/turn on the phone, you merely put the phone near the terminal, authenticate with your fingerprint, and it's done. Google Wallet requires waking up the phone, running an app, tapping the pgone to the terminal, entering a pin, and making the payment. CurrentC will (it seems) have you do much the same, but will have you scan a QR code instead of tapping the phone to pay.

Let's talk about QR codes for a moment. While they may not be as sexy as NFC terminals, QR codes are pretty much top dog when it comes to barcodes. They are ridiculously fast to scan, very easy for a scanner to distinguish (meaning you can scan them more reliably), can be scanned in any orientation, and can contain a lot of data (relative to other bar code symbologies, that is..). There's nothing clunky about them! If you have to scan a barcode with a phone (or scan a code OFF a phone), QR codes are the ones you want to use. Hopefully CurrentC will use dynamic, one-time bar codes for each transaction, unlike Starbucks' mobile app.

"Wow, so QR codes aren't all ba---wait, what was that about Starbucks?!?"

You caught that, huh? Yep, when you use your Starbucks app to pay for your Frappe, the same exact bar code comes up every time. If you don't believe me, the next time you go to pay at Starbucks, take a screen shot of the bar code screen. When you return, don't run the app at all - just pay with the screen shot. You can even print the bar code and put it on your employee badge for convenience.

"Wait, so what happens if someone sneaks a scan of my bar code or snaps a picture of it?"

You're buying the next round.

Don't worry, it's not quite that easy to do unless you are holding your phone facing away from yourself the entire time you are on line, but still, it is a legitimate concern. Of course, you have to reload your Starbucks card (and soon you will be able to do so in-app with Apple Pay), so hopefully no one is racking up thousands of dollars in lattes. Well, not without you knowing about it quite early in the process from the alerts you can elect to get when your account is reloaded.

"Well, aren't you a ray of sunshine. So how will the whole Apple Pay/CurrentC/Google Wallet thing shake out?"

My money is on Apple Pay to become wildly successful assuming a few things:

  • Merchants install NFC widely in 2015, widening the support for Apple Pay.
  • Apple continues to add on new banks at a rapid clip.
  • Apple - or others - get the word out that Apple Pay isn't really about cool, fast mobile payment, but about security. Apple is talking it up as the "fast and convenient" mobile payment system. While it is, the real problem is that no one has a problem with using their credit card, which is almost as fast and convenient. The security is what should sell Apple Pay; but Apple doesn't market security.

I expect that Google Wallet will ride Apple Pay's coattails as the little kid whose college-age brother just came home and is taking over the place. They are really two different peas in similar pods, just that Apple is executing their strategy that way that Google could not or simply did not. For example, did you know that Google Wallet is available for iOS? Did you know that you can send money to your friend's Google Wallet? Pretty much no one does, because Google has zero clue about how to market things effectively. Apple Pay is a great example of what Apple does best - study something over time, formulate a strategy, and execute it with excellence. Even the launch timing - right at the beginning of a major terminal refresh to support EMV (chip & pin) - is evidence of Apple paying attention to the market far more than Google ever did. However, it must be said that a victory for one in terms of NFC adoption is a victory for all, so they can only benefit each other.

As for CurrentC, well, if it is going to survive, it faces an uphill battle accomplishing the following:

  • Keeping merchants from jumping ship. Meijer was first, and if you are getting as hammered in social media and the press as CVS is, it has to be a major topic of discussion in the boardroom. Target is half in Apple's camp anyway, with support for Apple Pay in their mobile app. When their exclusivity clauses expire, will there be a domino effect?
  • Overcoming the perception that the information they collect is not too invasive and that they can secure it. (Good luck!)
  • Convincing people who have and continue to use credit cards that they need or want CurrentC. CurrentC is far less convenient than swiping a card or paying cash, so they will have to lather on the loyalty love in the form of coupons and other enticements to get people to care about it in the first place.

I think that CurrentC could have had a future until the moment that CVS and Rite Aid shut down NFC on their terminals. Now, the spotlight is on them, and there's definitely not enough lipstick on this pig.

"You think it'll work?" "It'd take a miracle.."

Mobile payments need to offer customers a raison d'etre for consumers to want to use them over cash or cards. Right now, even amongst the tech-savvy, there doesn't seem to be a reason to use mobile payments - they are a solution in search of a problem. A student, quoted in an article on mobile payments:

“It’s totally a gimmick,” Franco said, “I mean, it isn’t even available anywhere, and it isn’t that much easier than using a credit card. Since I have my wallet in my pocket anyways, I might as well just pull it out and pay. Saving a couple seconds of my time every time I make a purchase doesn’t really seem worth paying all that money for a new iPhone.

This, of course, is a "failure to educate" - to educate users about the insecurity of most payment technologies today. Security is the problem that mobile payments should - and in Apple Pay's case, does - solve.


Epilogue

One thing that always amuses me is when the mainstream media, in trying to report on complex technical issues, gets things wrong. Here's some of the "bloopers" I've spotted lately, and the facts -- which by now, you should already know:

The NFC option, and specifically Apple Pay, offers consumers a painless payment experience while promising credit card information security since those details are stored not in the cloud but on users' phones.

No, the credit card information is NOT stored on the phone. The DAN is.

CurrentC is a mobile payment system that works just like the Starbucks payments app and connects directly to a consumer’s bank. This way, the merchant is relieved of paying a 2-3 percent interchange fees to the credit card companies on each transaction.

You can't add a bank account to fund your Starbucks card, just a credit card. And soon, you will be able to use Apple Pay in the Starbucks App. Further, my local Starbucks barista informed me that they have recevied NFC terminals to support Apple Pay that will be installed soon. About the only way that Starbucks is like CurrentC is that the app uses a barcode. Oh, and by the way, Starbucks does NOT use a QR code - they use PDF417. Not important, but, you know, accuracy.

“With Apple Pay, Apple would have access to transactional information they don’t currently have,” said Douglas Rozen, chief innovation officer at content marketing agency Meredith Xcelerated Marketing. “That could be a threat to retailers.”

From Apple's iOS Security Guide: "Apple Pay is also designed to protect the user’s personal information. Apple Pay doesn't
collect any transaction information that can be tied back to the user. Payment transactions are between the user, the merchant, and the bank."

Google Wallet, on the other hand, uses its own vaulting system to store your credit card info. When you add a card to the app, Google gets all your personal data, including your social security, bank account, and routing numbers. It stores that information on its servers and encrypts them with industry-standard SSL (secure socket layer) technology.

Information is encrypted by SSL when it's "in motion" - traversing a network from one point to another point. It is always between two parties. SSL cannot encrypt "data at rest" - data stored on disk on a server.

Apple Pay keeps payments anonymous—so anonymous that retailers will lose some valuable information about shoppers: what they’re buying, what they’re returning, what they might be interested in next. It’s why customers who are paranoid about privacy love Apple Pay, but data-driven retail marketers can’t stand it. Even Apple-friendly brands like Starbucks have been hesitant to fully implement Apple Pay for this very reason. The Starbucks iOS app lets the coffee shop understand individual customers and offer them relevant promotions. A full-fledged Apple Pay solution would cut out the flow of customer data.

This is incorrect on a few different levels.

  • This is no different than using a regular credit card! The merchant still gets my name, just as they would with a swiped credit card. If the merchant was storing and indexing data on my purchasing habits by referring to my credit card number (PAN), well, shame on them. But in reality, the DAN, for most people, won't change - so they can still track it. However, to say that a merchant will lose "valuable information" about what I am buying is crazy - they are still ringing up the sale, after all.

Further, nothing prevents a merchange from scanning a loyalty card that you might have. I scan my card at Walgreens when I shop there, and nothing is preventing Starbucks from converting their cards from payment cards into regular loyalty cards. Heck, that would make their static bar codes a lot safer as well.

The Coup de Grâce

Brett Molina, tech reporter for USA Today, says that the security of Apple Pay and CurrentC is "roughly the same" and speculates that the disabling of NFC by CVS and Rite Aid is to "get ready for the rollout" of CurrentC.

...Sorry, I can't comment. I'm too busy laughing.