Coin vs Google Wallet: comparing card-aggregation designs (part II)


[continued from part I]

Google Wallet: one more level of indirection

“All problems in computer science can be solved by another level of indirection.” — attributed to computer science pioneer David Wheeler

Google takes a very different approach to supporting multiple cards in a mobile wallet. Instead of carrying a literal representation of all the payment instruments, they are all hidden behind a “virtual card” which can effectively redirect transactions to any of these original credit cards. But this routing is done in real-time via the payment network itself, instead of trying to recreate a bitwise clone of the card.

Google Wallet: using virtual cards to proxy transactions

Google Wallet and virtual cards

Virtual cards

The picture above illustrates how this works, in the context of mobile payments using an Android phone over NFC. (Note that Google also launched an ordinary plastic card in 2013 which has slightly different functionality. In this example we cover the better-known NFC payment scenario where the existence of the virtual card is less obvious.)

Users have one or more backing instruments or funding sources in their wallet. These are standard credit cards, “added” to the conceptual wallet once by entering card-number and other relevant details such as expiration and CVC2 on a web-page or the mobile application, much like one would enter credit-card information when making an online purchase. This step is the rough equivalent of the swipe-magnetic-stripe/photograph/confirm sequence used by Coin when adding cards.  At any given time, exactly one of these backing instruments is active, which is to say the transactions will be charged to the card. Also much like Coin, the Google Wallet mobile app has UI for selecting among the options.

Proxying transactions in real-time

Where the two models diverge despite superficial similarities in UI metaphors is what happens during a transaction. When Google Wallet is used for an in-store NFC purchase, the credit-card seen by the point-of-sale terminal is not any of the actual backing instruments. Instead it is a virtual card, unique to that instance of Google Wallet. Each user and even each instance of the wallet application associated with a given user has its own virtual card provisioned. In one sense, this card is very “real:” it is a full-fledged MasterCard effectively issued on behalf of Google, accepted at any NFC terminal that supports the MasterCard PayPass protocol. It has an ordinary 16-digit card-number with a prefix associated with the MasterCard network, an expiration date and for NFC transactions, cryptographic keys used to generate the dynamic CVC. It is only “virtual” in the sense that its existence is not explicitly surfaced. For example, nowhere in the mobile app are the card-number or other details about this card revealed to the user, although one can often spot the last 4 digits printed on paper receipts. (In principle a determined user could simulate the NFC transaction with their own reader to observe the card-number, since this is part of simulated track-data exchanged in the clear as part of PayPass.) Consequently it is never directly handled by the end-user– never entered into a form on a web-page or recited over the phone. Nor does it ever appear on a consumer credit report as an additional card; much like a prepaid card would not show up as a line of credit.

When a user makes an NFC transaction with Google Wallet, the payment network– MasterCard in this case– will route the authorization request to Google, the nominal issuer of the virtual card. Google will in turn place a payment request on the active backing card for the exact same amount. Pending the outcome of that authorization, the original “front-end” transaction is approved or declined. All of this is done in real-time, and must complete in a matter of seconds to comply with network rules around transaction deadlines.

Two transactions in one

There are interesting consequences to this design. First is that Google plays dual roles:

  • Issuer: As far as the merchant is concerned, Google is the issuer for the card the customer just used. (Nominally Google partners with Bancorp Bank for this purpose, with Bancorp ending up as the issuer of record, as described in the Wallet FAQ entry.)
  • Merchant: As far as the original issuer of the backing card is concerned, Google is a merchant requesting payment authorization from that card.

Second observation is that virtual-card and actual backing instruments are completely decoupled. Unlike in the case of Coin, the Google Wallet virtual card is not a perfect replica of the original card the user added to their wallet. It does not have the same expiration date. They do not share the same name: for NFC transactions, cardholder names–ordinarily part of the emulated track data– are redacted. In fact they may not even be on the same network: the virtual cards are MasterCard but the active funding source could be a Discover or American Express card. This is the illusion created by the virtual card: as far as the customer is concerned, they just paid with their American Express card– even if the merchant does not actually accept AmEx cards, a common situation at small businesses. The merchant on the other hand may be slightly better off in terms of transaction fees. Even if they were accepting AmEx, they will likely pay a lower transaction fee for processing the same amount over MasterCard network, compared to ringing up a “native” AmEx card.

Another interesting property: the transaction types are different. The merchant side experience is a card-present (CP) payment– this is how all NFC tap-payments are treated, no different from swiping the magnetic stripe. Meanwhile the original issuing bank for the backing instrument sees a card-not-present (CNP) transaction from Google, similar to what would happen when making a purchase online by typing card details into a web page. In effect the CP transaction at the point-of-sale was proxied in real-time into a CNP transaction against the backing card.

Other twists are introduced by this two-sided design, such as the handling of disputes and charge-backs, as well as handling merchant-specific rewards such as a credit-card that gives cash-back for purchases made only at gas stations. For our purposes, the key architecture difference between cloning cards (Coin) and proxying transactions in real-time to another card (Google Wallet**) is sufficient to explore questions around how each technology holds up against common fraud-vectors, as well as their future prospects in the face of EMV chip & PIN adoption.

[continued]

CP

** Historical side-note: the first version of Google Wallet in late 2011 did not use virtual cards. Instead users had the option of provisioning their existing Citibank MasterCard or requesting a new prepaid card, also on the MasterCard network. Both of these were “native” cards: transactions were routed directly to the issuer without Google in the loop. From an implementation perspective, each card was represented by a distinct applet on the Android secure element. Virtual cards were introduced in an update the following August, and native cards subsequently deprecated.

One thought on “Coin vs Google Wallet: comparing card-aggregation designs (part II)

  1. Alexej Muehlberg says:

    Maybe some words why Google made this change in the design, moving from native card to virtual card?

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s