How Apple Pay and Google Wallet actually work

It's hard to have a meaningful discussion about Apple Pay (iOS' most recent foray into mobile payments) and Google Wallet (Android's three-year-old platform that's had tepid success) without talking about how the systems actually work. And to talk about how those systems work, we have to know how credit card charges work.

It seems like a simple thing, especially in the US—swipe your card, wait a second or two for authorization, walk out of the store with your goods. But the reality is that a complicated system of different companies handles all that transaction information before your receipt ever gets printed.

The four-party system

If you're using a so-called “universal” card like Visa or MasterCard, there are typically four parties involved: the merchant, the payment processor, the merchant acquirer, and the issuer. Their roles are as follows:

1. The merchant is the person offering goods or services that you (the customer) want to buy.
2. The card issuer distributes cards to customers, extends lines of credit to them in the case of credit cards, and bills them.
3. The merchant acquirer signs up merchants to accept certain cards and routes each transaction to the card network's processor.
4. The processor then sends the transaction information to the correct card issuer so the funds can be taken from the customer's account and delivered to the merchant.

Visa and MasterCard are considered card networks in all of this. And as umbrella organizations, card networks aren't explicitly counted in that four-party system, but they facilitate the system's operation and often have ties to other parties involved.

MasterCard SVP & Group Head for Digital Channel Engagement Sherri Haymond explained the company's role to Ars. "MasterCard sits in the middle: we have a franchise that financial institutions apply to join," she said. From MasterCard's perspective, "acquirers bring merchants into the system, and issuers bring consumers into the system. MasterCard's role is to set rules and standards, and we facilitate movement of money, in most cases from the issuer to the acquirers."

For our purposes, we'll look at Visa- and MasterCard-like relationships, specifically. Just know that some companies—like American Express, Discover Card, and Diners Club—can play the role of the card issuer and merchant acquirer at the same time. And cards issued by companies like Macy's or Sears will likewise have a somewhat simpler system behind the transaction, because these “private label” cards are generally only accepted by one merchant.

Of course, things aren't always so straightforward in practice. According to a paper written by Ramon P. DeGennaro for the Federal Reserve Bank of Atlanta [PDF], “The payment card industry comprises many different entities that perform various tasks, and because many of them have formed alliances, the lines between them are often blurred.”

DeGennaro writes that the most important institutions in this four-party system are the merchant acquirer and the payment processor. Despite their importance, customers often never interact directly with these two entities. The functions of acquirers and processors can be performed by the same company, although many acquirers usually re-sell the services of a third-party processor.

What happens when you buy something

When a transaction takes place, two major processes occur: the card gets authorized, and the transaction is then cleared.

DeGennaro describes the authorization phase best:

The terminal sends the merchant’s identification number, the card information, and the transaction amount to the card processor. The processor’s system reads the information and sends the authorization request to the specific issuing bank through the card network. The issuing bank conducts a series of checks for fraud and verifies that the cardholder’s available credit line is sufficient to cover the purchase before returning a response, either granting or denying authorization. The merchant acquirer receives the response and relays it to the merchant. Usually, this process takes no more than a few seconds.

Once the card has been authorized, the second part of the transaction is clearing it, or getting the goods to the customer and the money to the merchant's bank. The merchant sends transactions to the merchant acquirer, and the merchant acquirer sends that information along to the merchant accounting system, or MAS, that supports an individual merchant's account. DeGennaro says that the distinction between the merchant acquirer and the MAS can be muddy. "In some cases, the MAS is a part of the merchant acquirer; in others, it is a different entity." DeGennaro continues:

The MAS distributes the transactions to the appropriate network—Visa transactions to the Visa network, MasterCard transactions to the MasterCard network, and so forth. Next, the MAS deducts the appropriate merchant discount fee (to cover the costs of the merchant acquirer’s activities) from the transaction amount and generates instructions to remit the difference to the merchant’s bank for deposit into the merchant’s account. The MAS sends these instructions to the automated clearinghouse (ACH) network, which is a computer-based system used to process electronic transactions between participating depository institutions.

Merchants typically pay what is called a Discount Rate and a Transaction Fee, which are tied to what is called an Interchange Fee, which is determined by the payment card network (again, Visa or MasterCard). According to a Quora post by CEO of 1st American Card Service Brian Roemmele, republished on Forbes, 85 percent of this Interchange Fee is paid to the card's issuing bank (like Chase, or Bank of America, for example). These fees usually amount to about two percent of the purchase price on credit card purchases and are a profit driver for the issuing bank. They also help cover fraud costs and fund reward programs.

This system is complicated, and it is growing increasingly fraud-prone, especially when card information is stored on a merchant's terminal or is sent insecurely. To keep this article (relatively) short, we won't discuss Card Not Present (CNP) transactions, which usually occur online or over the phone and require a customer to input her or his card's security code (those digits on the back of the card).

In a quick note, however, because CNP transactions are much less secure than transactions where the card is present, CNP transactions usually demand higher Interchange Fees from merchants. But although NFC transactions on an Apple Pay or Google Wallet-enabled phone don't physically require a card to be present, they transmit information as if the card was present, so fees aren't higher for merchants that choose to enable NFC on their terminals.

The little-known Google Virtual Wallet Card

The important thing to know about Apple Pay and Google Wallet is that neither payment platform was first to develop tap-and-pay transactions. In fact, a number of stakes holders, especially Visa and MasterCard, had been doing research and development, running pilot programs, and issuing contactless payment-capable credit cards for years by the time Google Wallet entered the scene in 2011. MasterCard, especially, with its growing PayPass platform, had been working with retailers to make RFID, and later NFC (Near-field Communication) chips—which allow two-way communication between the chip and the terminal—readable by terminals at major retailers like Macy's, Whole Foods, and McDonald's.

That said, Google Wallet was the first major deployment of a mobile phone-based NFC payments system. When it debuted, Google Wallet was only available on the Sprint Nexus S 4G, and its official partners were MasterCard and Citi Bank. You could also buy a prepaid card through Google. With its limited number of partners, Google originally stored credit card information directly on the phone's Secure Element—an isolated chip in the phone that has very limited interaction with the rest of the phone's OS. When the phone came close to an NFC reader, Google required a four-digit PIN to be entered before the chip transmitted the card information to the terminal. Since 2014, Google no longer uses a Secure Element, instead relying on Host Card Emulation, which makes it easier for third-party app developers to take advantage of Android phones' NFC capabilities. Four-digit PIN authentication is still required for payments to take place. From there, the transaction proceeds as any normal credit card interaction would. With the four-digit PIN, users are prevented from, say, accidentally buying something.

But the small number of partners made Google Wallet adoption stall. In 2012, the company tried to bring more users into the fold by issuing an update that permitted “all credit and debit cards from Visa, MasterCard, American Express, and Discover” to be uploaded to Google Wallet's cloud-based app. That didn't mean that Google developed partnerships with these companies necessarily (American Express notably balked at the announcement), but Google's new scheme opened the payments system up to greater mobile payments adoption than ever before. That scheme, which remains intact as per Google Wallet's Terms of Service (TOS), last updated in July 2014, is facilitated by issuing the customer a Google Wallet Virtual Card. This Virtual Card is issued by Bancorp Bank through Google, and it essentially acts as an intermediary between the customer's preferred card and the merchant.

“To enable your use of the Google Mobile Wallet Service via your NFC mobile device, GPC [Google Payment Corporation] has arranged for Bancorp to provide you with access to a MasterCard®-branded virtual prepaid debit payment card product, the Google Wallet Virtual Card, which is stored on your mobile device,” Google writes in its TOS. “By requesting the Google Mobile Wallet Service on your NFC enabled mobile device, you are requesting the issuance of the Google Wallet Virtual Card in order to facilitate your use of the Service.”

This setup naturally makes the four-party payments system more complicated. Instead of having your Chase-issued Visa card information sent from the merchant's terminal to the merchant acquirer, the Google Wallet Virtual Card requests the funds from your preferred card, and the Virtual Card information is then sent to the merchant, who subsequently sends it on to the payments processor. From there, that information is processed as a traditional card's information would be.

As Google describes a transaction: “When you place your mobile device near the merchant's NFC reader, your Google Wallet Virtual Card information will be transferred from your NFC mobile device to the merchant for use in processing the Payment Transaction. The Google Wallet Virtual Card is a prepaid debit card that can be used to make purchases when you use the Google Wallet Mobile Service at a merchant location that accepts contactless payments, even if the issuer of your registered debit or credit card is not a Google Wallet partner for NFC transactions. The Google Wallet Virtual Card is different from your debit or credit card registered in Google Wallet. The merchant will not receive your registered debit or credit card information.”

This setup is good for the customer, but it's a little less positive for Google. On the one hand, using a virtual card is considered a card fraud mitigation technique that has been around for quite a while—using pseudo-fake data to separate your real card information from the transaction process is a good idea. It also hands more power to Google and its customers, who now have more choice when it comes to supported cards. “Google sits in the middle of its Wallet transactions, rather than just passing through plastic credentials to an NFC enabled smartphone,” American Banker writes.

This setup also removes credit card information from the phone itself, although your real credit card information is still stored on Google's servers. As the company writes in its FAQs: "Your actual credit card number is not stored. Only the virtual prepaid card is stored and Android's native access policies prevent malicious applications from obtaining the data. In the unlikely event that the data is compromised, Wallet also uses dynamically rotating credentials that change with each transaction and are usable for a single payment only. Finally, all transactions are monitored in real-time with Google’s risk and fraud detection systems."

Google also offers a robust fraud protection program that "covers 100 percent of verified unauthorized Google Wallet transactions reported within 120 days of the transaction date," the company says.

On the other hand, this setup makes transactions more complex, requiring Google to shoulder part of the burden in securing those card numbers stored on its servers. It might even be costing Google a bit of money. UniBul Credit Card Blog noted that Google's Virtual Wallet system involves two issuers—the customer's preferred card issuer and the virtual card issuer (Bancorp Bank). Recall that when a payment is made, the card issuer collects an Interchange Fee that's usually around two percent. But with a "real" card and a virtual card involved in the interaction, interchange fees will be charged for both issuers. “From the merchant’s stand point, the transaction is completed using the virtual card,” UniBul writes. “After all, that is the only card the merchant sees. So the interchange will be paid by the merchant, through its acquirer, and collected by the virtual card’s issuer—The Bancorp Bank, Google Wallet’s partnering bank. However, right after this transaction is completed, Google will transfer the sales amount from the card that was actually selected by the user to the virtual card. And now the issuer of the ultimate payment source will also have to collect its interchange fee. This time Google will have to pay for it, and it doesn’t seem like the search giant can offload the interchange to anyone else.”

When the movement to virtual cards occurred in 2012, American Banker wrote that “some analysts believe that, while Google's intentions are unknown, it's unlikely that they'd want to start collecting interchange [from merchants that support Google Wallet]—at least until the search engine company first [starts] to profit from advertising revenue associated with a person's use of Wallet.” It's unclear whether Google has turned a profit from Wallet, but it does seem apparent that Google's goal in its mobile payments endeavor is the same as with the rest of its free services—to collect as much data as possible from its customers.

Apple gets buddy buddy with banks

Apple Pay is one of the biggest features expected to launch with iOS 8.1 later this month.

Credit: Apple

Although much of Apple's integration into the card payment system is obfuscated by secret deals the company has with the various players, three different sources told Bloomberg recently that Apple would actually be collecting a percentage of every transaction made on Apple Pay from certain issuing banks.

In other words, Apple was reportedly able to convince JPMorgan Chase & Co., Bank of America Corp., Citigroup Inc., and others that it deserves a cut of each purchase made on the iPhone 6 or 6 Plus, because customers will spend more using the phone than they would with a regular credit card. According to Bloomberg, “Under deals reached with banks individually, Cupertino, California-based Apple will collect a fee for each transaction, said one of the people, who requested anonymity because terms aren’t public."

Apple also may have been able to convince the banks that its platform could reduce fraud and thus reduce the associated costs to the issuing bank (allowing the bank to keep more of that Interchange Fee).

Like with Google Wallet, making a contactless payment using Apple's phone requires the user to verify the payment on the phone before it can go through. Whereas Google Wallet uses a four-digit PIN, Apple Pay requires the customer to verify using TouchID, which reads the user's fingerprint.

On top of that, Apple has introduced tokenization into its payment system. Like Google Wallet's Virtual Card, this obfuscates the user's actual credit card number, but it does so using a security standard developed by various standards groups and big-name card networks like Visa. It all happens without having to go through another bank as an intermediary supplier of a virtual card. While many card networks and banks have experimented with ways to implement tokenization security, Apple's method goes to lengths to keep a user's card data out of Apple's hands and off its servers, except during setup.

You can snap a photo of your credit card to avoid having to key-in all 16 digits. The photo is not stored on your phone.

Credit: Megan Geuss

When you first set up Apple Pay, you can either manually input your card details or take a photo of the front of the card. If you choose to snap a photo, the photo isn't stored on your phone. All the information is, according to Apple, encrypted and sent to the company's servers, where they decrypt the data and determine the card network or card issuer. Apple then “re-encrypts the data with a key that only your payment network can unlock,” as the Apple Pay support page details. Apple next “sends the encrypted data, along with other information about your iTunes account activity and device (such as the name of your device, its current location, or if you have a long history of transactions within iTunes) to your bank. Using this information, your bank will determine whether to approve adding your card to Apple Pay.” In a sense, this setup process is like the initial authorization in a traditional credit card payment. In a simple credit card transaction, card details are sent to the bank for authorization, and an approval comes back to the merchant that lets the transaction go through.

The Apple Pay setup, however, appears to be the first and only time your real credit card information is passed around between Apple and an issuer. Once the information gets to the card network, it's decrypted, and the card network issues a token called a Device Account Number (DAN). The DAN is device-specific. The card network sends this DAN to Apple along with other information “such as the key used to generate dynamic security codes unique to each transaction,” according to Apple's support page.

The blog Bank Innovation explains this “dynamic security code” scheme a bit, noting that in EMV transactions (and Apple Pay does use the soon-to-be-adopted-in-the-US EMV standard), the chip in the phone (or in the card, in a traditional EMV transaction) interacts with the merchant's terminal to “generate a cryptogram—the transaction’s security key—and attach it to the consumer’s personal account number (PAN). The cryptogram is generated, in part, by the chip on the card, which was previously given to the consumer by the issuer. The cryptogram is then sent back to the issuing bank, which processes the transaction. Because the issuer—in other words, the banks that work with the card networks—gave the consumer his card, the issuer is responsible for the quality and security of the cryptogram.”

So using this method, Apple not only uses a token as a proxy for a real credit card number that is device-specific and ideally should not be able to be replicated across another device, but it also offloads responsibility for the security of the token and the cryptogram to the card issuer. The token and the cryptogram are both encrypted with the card network/issuer and are then sent back to Apple. The company claims it cannot decrypt this information, and it simply adds it to the Secure Element on your device. As Apple claims, on the Secure Element your token and its accompanying cryptogram are “isolated from iOS, never stored on Apple Pay servers, and never backed up to iCloud. Because this number is unique and different from usual credit or debit card numbers, your bank can prevent its use on a magnetic stripe card, over the phone, or on websites.”

So when you go to make a payment with Apple Pay, you bring the phone up to an NFC-enabled terminal (which will only read devices that are a matter of inches away) and the phone will ask you to authenticate the payment with TouchID. That authentication signals to the phone that it can transmit the Device Account Number and its accompanying “transaction specific dynamic security code” to the merchant's terminal, and the transaction then proceeds as a normal credit card transaction would. The only difference is the bank network or issuer verifies that your payment information is coming from the correct device and has not been duplicated.