Mobile Payments: What is Google Wallet?

What is Google Wallet?

Google Wallet is a mobile/digital wallet developed by Google. Their grand vision probably is to replace the complete physical wallet with its virtual counterpart. They are not there yet, but in the process of marching towards their grand vision, they have created a few important services. We will discuss them one by one in a moment.

Google Wallet has been around since 2011 and has seen at least 3 major revisions. Each version had a very different technical approach to mobile payments mostly because of the politically difficult landscape that surrounds it. We will discuss each version, challenges faced and how they achieve mobile payments in separate posts later. In this post, we will assume the third (and latest) version of Google Wallet. This version was released along with Android Kit-Kat and it uses Host-based Card Emulation instead of Secure Element based Card Emulation.

As a consumer you can add your debit cards, credit cards, stored value cards, loyalty cards, gift cards etc. to your Google Wallet account either on their website or using the Google Wallet app on your smartphone. You may even add some money directly to your wallet account balance.

Pay at Physical POS:

Using this service, you can use your NFC enabled Android phone to purchase in-store by just tapping your phone against a contactless terminal. The contactless terminals are not Google specific; they already exist in the wild and support contactless cards from Visa (PayWave) and MasterCard (PayPass). Google just uses the same standard protocols used by the Contactless cards so as to be compatible with existing infrastructure.

google-wallet-tap

Google has also developed a proprietary protocol on top of existing Contactless protocols to support making payments, redeeming coupons/offers and receiving loyalty all with just one tap. But for this to work, the merchants will have to upgrade their terminal to explicitly support Google’s own protocol.

But there is a big challenge with contactless terminals. Today, they are not very common with retailers in the United States. Most of the retailers still have only traditional Magnetic Stripe terminals. Eventually, the expectation is that all merchants will have a contactless terminal, but in the meantime, we need a solution. To fill this gap, Google Wallet also offers a Debit card from MasterCard that has a Magnetic Stripe interface. So, if a merchant does not have a contactless terminal, you can still use the Google Wallet Debit card to make a payment.

google-wallet-debit-card

Pay Online:

Using this service, you can pay on eCommerce websites and mobile apps where you see the Buy with Google sign. Here, Google Wallet acts more like a digital wallet than like a mobile wallet. Google offers different APIs for sale of digital goods and sale of physical goods. The difference is that, for sale of digital goods, a seller need not have a separate relationship with a payment processor. Google will take care of the payment processing as a whole. On the other hand, for sale of physical goods, a seller would need to have a payment processor and a merchant account with an Acquirer.

google-wallet-buy-with-google-2

Pay Friends:

Using this service, you can use Google wallet to send money to anyone in the US with an email address. This service is generally used to pay friends, split bills and sometimes referred to as Person to Person payments or P2P for short. Recently, Google also added the ability to send money as an email attachment when using Gmail as the email provider.

google-wallet-pay-friends

Mobile Payments Blog Series

Welcome to the Mobile payments FAQ and not so FAQ series and you are on FAQ #16. The idea behind this series is to share and learn as much as possible about the field of mobile payments. If you like, you can read all of the FAQs by visiting the Table of contents page.

Related Reading

Apple Pay vs Google Wallet : The Secure Element

Note: You can read all articles in this series by visiting the Table of Contents

Both Google Wallet and ApplePay are trying to solve the same set of problems – mobile payments at the physical POS and inside apps. They have many characteristics that are very similar, but they also differ in significant ways when it comes to implementation and user experience. In this series of blog posts, we will analyze a few similarities and differences one by one. We will start by talking about the Secure Element today.

A Secure Element (SE) securely stores card/cardholder data and does cryptographic processing. During a payment transaction it emulates a contactless card using industry standard protocols to help authorize a transaction. The Secure Element could either be embedded in the phone or embedded in your network operator’s SIM card. We will generically refer to them as device-based Secure Element. More recently, with the introduction of HCE technology by Google, the definition of Secure Element has been expanded to include a secure cloud as well. We will refer to them as cloud-based Secure Element.

In the beginning, Google Wallet v1.0 started its journey by using the device-based Secure Element for card emulation. This approach didn’t work out well for Google as most of the major network operators (Verizon, AT&T and T-Mobile) decided to support their own brand of wallet called Softcard (previously Isis) and blocked access to the Secure Element for any other wallet providers. Google had no choice but to move on.

se-hce-dual-ce

Today, Google wallet v3.0 does not use a device-based Secure Element. It uses a technology called Host-based card emulation (HCE) instead, where card-emulation and the Secure Element are separated into different areas. For example, in HCE mode, when an NFC enabled Android phone is tapped against a contactless terminal, the NFC controller inside the phone redirects communication from the terminal to the host operating system. Google wallet picks up the request from the host operating system and responds to the communication with a virtual card number and uses industry standard contactless protocols to complete the transaction. This is the card-emulation part. The transaction proceeds and reaches the Google cloud servers where the virtual card number is replaced with real card data and authorized with the real Issuer. Since the real card data is securely stored in Google’s cloud servers, the cloud represents the Secure Element part. In general, this approach is considered less secure compared to the embedded SE approach. But there are some areas (like Lost & Stolen use-case) where it is more secure. We will discuss that in a different post.

NOTE: This doesn’t mean that Android operating system does not support device-based Secure element anymore. In fact it supports both device-based Secure Element and HCE using a routing table at the NFC controller level.

ApplePay, in contrast, works using traditional device-based Secure Element. It does not use HCE technology. Consequently, Apple does not store the real card or token data in their cloud servers at all. The on-device Secure Element essentially performs card-emulation in addition to secure storage. It sends payment data to the contactless terminal when you Tap & Pay. I have attempted to demystify how ApplePay works in one of my previous posts. In many ways it is similar to how Google Wallet v1.0 used to work (with some important differences).

se-ce-iphone

First, ApplePay does not store the real card data inside the SE. This is in direct contrast to Google Wallet 1.0 and Softcard. Instead, they store a token that conforms to EMVCo tokenization specification. It is this token (along with a cryptogram) that gets sent to the contactless terminal. During the authorization flow, the card network identifies the token, de-tokenizes them into real PAN with the help of a Token Service Provider (TSP) and sends the real PAN over to Issuer for authorization.

Second, Apple owns and controls the Secure Element embedded inside the device thereby avoiding unnecessary challenges from the MNOs.

Finally, Apple significantly simplified the provisioning model. If they had to provision the real card details, they would have to depend on a complex and convoluted process. Fortunately, they provision a token instead and took the opportunity to simplify the process to a bare minimum.

In the next post, we will discuss how these two services differ when the device is lost or stolen.

Related Reading:

Mobile Payments: What is HCE?

What is HCE?

Previously, we discussed about Secure Element and how it enables payment transactions in card-emulation mode. We also briefly discussed that SE is not the only choice available. Today, we also have HCE as an alternative. HCE stands for Host-based Card Emulation. As its name suggests, it has something to do with card-emulation mode. But what does host-based mean? Before we talk about what host-based means, let’s review how things were before HCE.

Prior to HCE, the only way to emulate a card using a mobile NFC device was to use a Secure Element. Let’s take the Android platform as an example. Here, the host operating system (Android in this case) and its apps do not get involved with a payment transaction at all.

se-ce

When a consumer holds the device over an NFC terminal, the NFC controller in the device routes all data from the reader directly to the Secure Element. The Secure Element itself performs the communication with the NFC terminal, and no Android application is ever involved in the transaction. After the transaction is complete, an Android application can query the Secure Element directly for the transaction status and notify the user. This is the approach used by ApplePay as well

This SE based approach is inherently secure and that is a very big advantage. But, there are some downsides too. The SE owner owns the key to the kingdom. All others will have to go through complex business models, partnerships, and dependencies to gain access and it makes the whole process that much more complex and expensive. Moreover, the SE itself has only limited storage capacity and processing speed.

The alternative is to use Host-based Card Emulation. Here, the host operating system (Android) and its apps gets involved with a payment transaction.

hce-ce

When a consumer holds the device over an NFC terminal, the NFC controller in the device routes all data from the reader directly to the Host CPU on which Android applications are running directly. Then, an Android application (a Mobile Wallet) that deals with a particular payment application can do its magic and provide for the card emulation requests and responses.

Since the host CPU is inherently insecure, any mobile wallet worth its salt will not store the real payment credentials inside the phone. Google Wallet for example moves all such data to a hosted cloud environment, and that is where the secure storage and secure processing takes place. In essence, we have moved the Secure Element from inside a chip to a cloud environment (HCE Cloud) instead.

This approach has its downsides – like security and a need for data connection. This does not mean that your private information is vulnerable. We can still have a very high degree of security using other technologies. Payment card Tokenization is one of them and we will discuss it in an upcoming post. On the bright side, the complex business models, partnerships and access restriction to SE can be dramatically simplified. This enables payment application issuers to easily provision to the cloud and get it over with.

Using SE-based Card Emulation and Host-based Card Emulation is not an either-or scenario though. Android allows both to co-exist in the same NFC enabled device and offers tools and technologies to work with both of them as shown in the diagram below.

se-hce-dual-ce

All the above diagrams were taken from Android developers website.

Mobile Payments Blog Series

Welcome to the Mobile payments FAQ and not so FAQ series and you are on FAQ #15. The idea behind this series is to share and learn as much as possible about the field of mobile payments. If you like, you can read all of the FAQs on the Mobile Payments category or by visiting the Table of contents page.

Related Reading

Bring Your Own Wallet

Today, the mobile wallet is an overused buzzword discussed and debated by a variety of industries. Payment companies, financial institutions and merchants of all sizes are all vying for consumer attention. Technology companies, mobile network operators (MNOs), start-ups and even marketing companies are joining forces to innovate in this space. Though many are talking about it, asking a simple question like what is a mobile-wallet? brings surprisingly different answers depending who you ask.

The competition heats up

A question often asked is who could win the ‘wallet wars’ in the years to come? Isis Wallet was launched just a few weeks ago and is heavily backed by three of the top MNOs (Verizon, AT&T and T-Mobile). Google Wallet has finally escaped the clutches of MNOs by introducing Host-Card emulation in Android Kit-Kat. Are they in a position to reverse their wallet downfall? PayPal has started piloting their in-store beacon payment experience. With over 100 million credit-cards on file, is PayPal going to be the winner again? Will MCX wallet, with its support from all major retailers, be the Holy Grail for merchants? Can Square re-create their m-POS success in the wallet world? Apple’s passbook shows huge potential by itself. With the subsequent introduction of finger-print biometric and iBeacon in iOS7, is Apple in a better position than others?

Generic vs. merchant

These questions, however, are based on an assumption that a multi-purpose generic wallet will emerge as the winner. Considering that the mobile payments revolution is still in its nascent stages, it’s too early to assume that a single generic wallet will triumph over a merchant-specific wallet such as a Starbucks wallet. Starbucks claims that more than 10% of store sales are driven by its mobile wallet app and is the only success story in this space. The generic wallet fails to provide any credible proof to challenge this. So, the real question is: who will win the generic wallet vs. merchant-specific wallet war?

As far as merchants are concerned, this question need not be fully answered before they dive into their mobile wallet initiative. Here’s why: most of the wallets mentioned above try to solve the mobile payment challenge. But payment is just one part of the larger wallet ecosystem. Until other ambitious players solve the mobile payment challenge, merchants can use stop-gap payment solutions while focusing on the rest of the wallet ecosystem.

Bring Your Own Wallet

The most practical approach then would be for a merchant to follow the mantra, ‘your app is your mobile wallet.’ By building your own-brand mobile wallet, you can access customer profile information (demographics, purchase behavior, spending patterns) and track transactions which would otherwise be sold to competitors. Combining such valuable information with unique capabilities that smartphones offer, new and innovative solutions can be created to boost your sales, up-sell, cross-sell and elevate customer experience to a whole new level in several different ways:

  1. Improve the in-store shopping experience and customer engagement: staff can be equipped with mobile POS devices; in-store navigation can assist customers to the exact location of a particular product; access to store inventory can identify if a particular product is in stock; product comparison and user reviews can strengthen customer confidence; mobile ordering, smart-checkout and in-store pickup can reduce queue wait times.
  2. Increase customer loyalty and invite repeat-visits: access to digital loyalty/reward cards from the wallet; real-time rewards information access; creating badges and rewards gamification to increase customer spend; geo-fencing, to check-in customers and offer a personalized experience.
  3. Increase customer base using innovative offers: offering location based offers when the customer is in vicinity of the store; iBeacon technology to identify if a customer is checked into the store and leveraging that for targeted sales to motivate in-store purchases. This can also be used to bring your mobile wallet to the forefront without getting hidden in the fourth home screen.
  4. Support a payment solution that works today: use a stored-value digital card that the customers can refill with their linked bank accounts; or use a white-label mobile payment provider like Paydiant if you prefer to support all card networks from your mobile wallet. Regardless of payment option chosen, integrate it with your rewards program; offer additional incentives for consumers who use your mobile-wallet; ensure tight integration between the mobile payment system and the rest of the mobile-wallet ecosystem.
  5. Support generic mobile payment providers when they finally figure it out: eventually, the generic wallet providers will figure out a standardized way to make a payment at the physical or virtual POS. Design your mobile strategy to be flexible to support them so you don’t lose generic wallet customers. Your own loyal customers can be appropriately incentivized to continue using your mobile wallet.

Remember, the existing magnetic-stripe based card payment experience is not broken. It works, customers understand it and more importantly, they are happy with it. So, payment is not the problem you need to solve. Neither should you wait for generic wallet providers to solve the m-Commerce challenge for you. By placing your bet on your own unique mobile wallet today, you can focus on creating what adds value – a new and improved relationship with your customer and rewarding them with a pleasurable shopping experience.

The article was originally published on bobsguide on May 8, 2014 and is re-posted here by permission.