How does Google Wallet 2.0 work?  In a nutshell:

1) All payments will be made using a Pre-Paid Virtual MasterCard (VMC) issued by BanCorp Bank that, in turn, is linked to the user's preferred credit/debit card. All credentials for this VMC will be stored in the phone's Secure Element (SE), all other card credentials will be stored in the cloud. No need for Google to negotiate with issuers / networks to include them in the SE, as was the case with the first Google Wallet (GW) iteration. 

Note:  At the moment, there is one notable exception to this rule:  Citi MasterCard, Google's first - and still only - banking partner.  Citi MasterCard credentials are stored in the SE.

2) Google is acting as 'merchant of record'.  The merchant will authorize/settle transactions with Google - paying fees based on the use of a present pre-paid debit card.  The VMC credentials will be sent via the MasterCard network to the issuing bank (BanCorp Bank).  In turn, and in real-time, BanCorp will map the VMC to the user's preferred method of payment and will seek authorization with the card issuer - paying standard fees related to the chosen card, probably as Card Not Present (CNP). Basically, the VMC is used by Google/BanCorp as a directory entry to link to the user's 'actual' card. These are two back-to-back processes. 

The graph below illustrates this process - in a very simplified manner - using the example of AmEx as being the preferred method of payment.

Note:  Citi MasterCard cards will not be processed directly by Citi, without the intermediation of BanCorp given that they are also present in the SE.  

Note:  Although AmEx has not approved Google to include its cards in GW, a user can link his/her AmEx card to GW.

3) The payment process may be a bit slower due to the need to perform these back-to-back processes. Google is probably making a loss with each payment given the difference between the fees they are charging to the merchant and the fees issuers are charging them. 

4) Google/BanCorp have now full access to all payment information, making it extremely easy for them to work with merchants to develop loyalty programs and with consumers to organize their spending. I believe issuers still receive all (or most) of the transactional information and can apply rewards and protection programs to the transactions, although Google makes it very clear that it is up to the issuer to decide how to treat these transactions and whether or not rewards and protections apply. 

5) GW can be implemented using an NFC-enabled phone but also just a plastic card (with mag stripe, contact or contactless technology) or even an NFC sticker.  These alternative options would provide a much poorer experience and less security but they may be a way to get consumers comfortable with using Google as a payment method (this is precisely what PayPal is trying to do through their partnership with Discover).   In any case, each transaction could always be instantly recorded in the cloud and immediately sent to the user's phone. 

6) You can store a number of payment methods in your GW account but only have one linked to the VMC at any given time, meaning that you cannot change the card you are using to pay at the till. This seems to be a bit limiting...  But it could easily be changed to, either have a set of rules to determine which card to use based on merchant and payment amount or to be able to choose the specific card you want to use at the till.  

7) Google's approach for the 2.0 version of its wallet differs greatly from the approach it took when it developed the first version.  At the same time, this approach seems to resemble that of PayPal - although with a different implementation - or, another way of seeing it, Google CheckOut with NFC capability.

How does Google Wallet 2.0 'stack up' against the criteria listed at the beginning of this series (click here to review the list)?

Reliability, Transaction Speed and Security:
It is an NFC-based solution, connecting the merchant (or Google, as the merchant of record) to the banks through the traditional processors and card networks.  This means the highest standards in reliability, speed and security.  Because in this case we have two back-to-back transactions (between the merchant and BanCorp and then between BanCorp and the actual issuer), speed may suffer but I am assuming not enough to make it noticeable.  

Ease of Use:
Again, as an NFC solution, use at point of sale is extremely simple - just tap-and-go.  The interface is also simple and intuitive enough.

Wallet Functionality: 
From a functionality perspective, it seems to be a bit limited.  This could be easily changed but, at the moment, only one card can be linked to the VMC.  This means that, although you may have all your cards stored with Google, you can only use one at the store.  You need to log into your account online to change your preferred method of payment.

Also, given the limited involvement banks currently have with this solution, it is difficult for them to use the wallet to create a more direct link with their customers.  

Acceptance:
There is a limited number of NFC-enabled POS in the U.S.  A much lower number than in Europe or other geographies.  This will change in April 2013, once acquirer processors and sub-processor service providers will be required to support merchant acceptance of EMV chip transactions by Visa and all other card networks.  This mandate will greatly accelerate migration of POS to provide support to, at a minimum, EMV contact cards and, in most cases, EMV contactless and NFC-enabled devices.  

Device Availability:
At the moment, GW only works on a few devices on Sprint's network.  This is an extremely limiting factor.  Given that GW requires an NFC-enabled phone with access to its SE, there may be a long road to travel to good device availability.

Value-add Apps:
In theory, GW can support all types of value-add apps to enrich the user's experience and make the wallet truly valuable.  Unfortunately, at the moment, there are no (or very few) apps available.

Food for Thought  
Considering that PayPal, Visa and MasterCard (among others) are already also providing, or plan to provide, other payment services such as P2P or remittances (we will discuss these capabilities in detail when reviewing each solution), shouldn't Google also take a stance in those areas?  

Edit (08/30/2012) - It hasn't even been a week since I posted this blog and I already need to make an update!  Google has spoken about the possibility of including P2P payments in its GW.

Following last week’s blog, where we discussed the basics of interchange fees – what they are and why they are controversial – we will now focus on possible ways in which they will evolve as all parties involved – regulators, merchants, issuing & acquiring banks, networks and consumers – seek to improve card payments systems.

All of the options being considered aim to solve one or more of the reasons why interchange fees are controversial (list included in previous blog).  Below I list a number of these options:

1)   Do nothing.  It would only make sense to change the status quo if we can ensure that the resulting outcome will be more efficient.  It is very difficult to develop this type of quantitative ‘proof’ given the complexity of the system, so how can we determine the best alternative if we cannot measure and compare the different outcomes?

2)   Further enable differential pricing across payment methods (affecting the no-surcharge rule).  When considering this alternative, it is important to remember that most merchants in countries (or states within the US) that are already allowed to apply differential pricing have chosen not to do so.  The reason for this is probably the unknown effect it has on sales.  If faced with higher prices at a store to use, for example, an AmEx card, will the consumer just use a different card (if he does indeed have another card)?  Will he go to another store instead?  How many impulse purchases will be lost?  There may be too many unknowns for retailers to feel comfortable with experimentation, particularly within the current economic environment.

3)   Allow bank / merchant determination of interchange fees.  This option would (a) eliminate anti-competitive concerns (external third party setting up fees in a way that may encourage higher prices) and (b) allow large merchants to leverage their size in negotiations, potentially giving consumers a more efficient system. 
The main draw-back would be complexity – Each issuer would, potentially, need to negotiate fees with each merchant, raising the number of contracts each issuer needs to manage into the thousands.  The same would be true for each merchant.

4)   Regulate fee level.  Given that the general perception is that interchange fees are too high, this option would probably equate to lowering them.  The problem the regulators would face is the same banks and merchants are struggling with today:  How to set this level so as to ensure that it reflects benefits / costs borne by the parties?  What level will make the credit card system most efficient and beneficial for the consumer (for example, in the way it would affect acceptance and rewards)?

5)   Relax card acceptance requirements (affecting the honor-all-cards rule).  The honor-all-cards rule has become very controversial in the last few years as the networks have introduced premium cards that have higher interchange fees attached.   It could make sense to allow merchants to decide which cards, within each network, they wish to accept. 
The main issue is that we could run into similar problems as those described in the second option above:  What would a consumer do if his preferred card is not accepted at a store?  How much would be lost in sales?  Furthermore, how can a merchant describe the credit card programs it does and does not accept in a way easily understandable to consumers?

6)   Allow multi-bugged cards.  The idea in this case is to provide consumers with one card that connects to all networks.  Then, at the point of sale, based on the specific purchase, the retailer will choose the best network (probably cheapest) to carry out this transaction.  It would mean each issuer would need to enter contracts with multiple networks.
This option may be the one that will result in the most efficient outcome since it allows for direct competition among networks at the point of sale.  At the same time, it would be difficult to implement.  For example:  What info would the merchant provide to the consumer regarding routing (or would it not be relevant)?  What logos would the card carry?  Would this result in less brand recognition for networks and therefore fewer incentives to innovate?

Whatever option is taken, except for the ‘Do nothing’ alternative, change will come slowly since:

1)   The effects need to be detailed and quantified:  Because of the number of players and the complex relations among them, any change will have numerous implications, some of which are difficult to anticipate. 
Also, up to this point, regulators and industry players, have been able to describe some of the qualitative effects of these changes but have had difficulties in creating credible and comprehensive quantitative models.

2)   Revenues – whether more or less – need to be re-distributed.  As we have previously discussed, interchange fees are meant to reflect the benefits of the merchants and acquiring banks while covering the expenses of the issuing banks.  Both things are extremely difficult to measure – some may even argue impossible to measure.  How then should a new revenue and fee structure be built? 

3)   Three-party networks and debit-card transactions also need to be included in the conversation.  So far, the conversation has focused on four-party credit card networks but the full spectrum of payment options should be included in the conversation to avoid networks migrating from more to less regulated service options. 
Furthermore, with new payment systems constantly being developed, any new rules and regulations should be flexible enough to allow for new options and challenges.

Interchange fees are a controversial topic.  Changes will be implemented slowly given the difficulty in determining the cost / benefit the credit card structure provides to issuers and merchants and in quantifying the effects of any change.  Controversy is here to stay!

Sources:
1)  'Payments Systems in the U.S. - A Guide for the Payments Professional' by C. Coye Benson and Scott Loftesness.  Glenbrook Payment Essentials.
2)  'Finance and Economics Discussion Series.  Division of Research & Statistics and Monetary Affairs.  Federal Reserve Board, Washington, D.C. - Interchange Fees and Payment Card Networks:  Economics, Industry Developments, and Policy Issues' by Robin A. Prager, Mark D. Manuszak, Elizabeth K. Kiser and Ron Borzekowski.
3)  'Theory of Credit Card Networks:  A Survey of the Literature' by Sujit Chakravorti from the Federal Reserve Bank of Chicago.
4)  'Working Paper 03-10.  An Introduction to the Economics of Payment card Networks' by Robert M. Hunt from the Federal Reserve Bank of Philadelphia