Earlier this month, Google announced that consumers would have the ability to enlist their own financial card information onto their Google Wallet instead of waiting for their bank to board their card credentials. This approach supports the ‘consumer centric’ model for mobile payments vs. having interested parties such as banks, mobile network operators, etc. in control.
In order to address the security glitches present on the phone, Google changed its approach from having the wallet on the phone to effectively having the wallet in its servers (or the cloud). This moves the security issues associated with the user’s card to a more secure environment, Google’s servers, rather than trying to secure it on the mobile device itself. This also simplifies the process of adding other cards to the wallet since now the sensitive information (your card) needs to be added to the wallet in Google’s servers vs. on the phone.
To enable the actual payment on the phone wallet, Google has opted to provide a virtual card number issued by Bancorp, a private label issuer, which links to the actual card. Using virtual account numbers is an option that has been leveraged in other cases where you could get virtual numbers associated with your card to make certain transactions. In the case of Google, the virtual card is a MasterCard prepaid card, even though the card you register with Google does not have to be a MasterCard. The transaction is processed with the virtual card and then Google charges your registered payment card for the purchase amount.
In a sense, it is similar to the PayPal model where you associate a card with your account and payment is made with the card you registered with PayPal. Of course, the difference is that Google has broadened the model to support multiple cards using the wallet approach. Another differentiator is that since it is a virtual card following traditional payment card numbering schemes, etc., the transaction from your mobile device will ‘ride’ the traditional payment card network, not as in the PayPal model where it is through PayPal as the acquirer. However, since we now have two transactions occurring, one with the virtual card to get to Google and another from Google to your issuer to actually authorize the transaction, there is the potential of two interchange fees.
From a security perspective, you still have to deal with protecting the virtual card number on the phone, only now it is not your ‘real’ card number. The same authentication issues are present in order to ensure it is the approved user enabling the payment vs. someone else using your phone and hacking the PIN; the original problem. With your real card information on its servers now, Google has the option for you to ‘disable’ use of your real card if your phone is lost or stolen, effectively unlinking your virtual card from the real card.
There has been much discussion as to what makes a good wallet model, whether on the phone or in the cloud. If we want mobile devices to truly behave as payment devices substituting physical cards, then we will have to ensure whatever is on the phone, a card number or an authentication method, is truly secure.
Part of the problem today is that the entire mobile payment space is evolving and we do not have all the answers on what will be the best model to make it trustworthy and convenient. The industry will go through several options, with the latest Google approach as another potential solution. The market will decide if it is workable or not.