Google in Payments: Why Yesterday was BIG News

For eCommerce/mCommerce merchants this may be the biggest “no brainer” since Cybersource offered to offload card processing/fraud risk management. This is a killer… from both cost, and advertising perspective.

16 May

—- Correction — MA rate for non-regulated debit is 160 bps (not 105). My old Google card in the NFC wallet was card present.. I forgot to make the change to card not present…  Rate table below —-

Yesterday Google rolled out InstantPay, and a new planned P2P service integrated with Gmail, wallet, … etc. Although this is a step back from the physical card revealed by Android Police in November.  This is a VERY BIG DEAL for payments. Why?

Merchant Value Proposition

  • Reduce payments cost. No matter what card customer uses, everything will be priced as a non Durbin Debit (160 bps). This marks the First Time Ever a provider will take a LOSS on every payment, to get the data.
  • Customer uses whatever card they want, credit, debit, Amex.. or even ACH.
  • Merchant keeps current processor. The payment metaphor is a 16 digit PAN.. a Google MA that wraps everything else (see don’t wrap me).
  • Increased Conversion (particularly mobile). One button (pay with Google) and everything is filled out.
  • New performance measurement tools in google analytics
  • New offers and ad types possible (dependent on redemption, and/or number of purchases)
  • Possible loyalty programs
  • New physical merchant use cases (buy on mobile pick up in store).instant buy

Consumer Value

  • Centralized payment instrument/fraud protection. I’m not giving my card number out to all merchants
  • Ease of use.. no more form filling
  • Centralized e-reciepts
  • Use any payment instrument I want
  • Store coupons/incentives in wallet
  • Wallet on Android no longer NFC dependent

Consumer “downside”

  • Google gets to see more of your data.. but who do you trust with it? Google vs. Banks vs. none of the rates non-regulated


  • Expanding the google master account (GAIA) to manage verified identities and making new services available (to these consumers it has verified)
  • Ad delivery: Leveraging customer insight and “touches” to influence consumer
  • Ad quality: closing the loop with payment.. what ads contributed to what ACTUAL behavior
  • PAY FOR PERFORMANCE Advertising!??  No more CPC? one obvious future is if Google can see transaction then the could bill merchant for advertising based upon the purchase (not on the click). This is the Holy Grail of advertising and if there are indeed plans here.. it is beyond a moon shot. As an advertiser I would only pay for marketing that led to customers buying from me. This would spawn an entire new industry of campaign managers. More on this in future blog.
  • Phone as tool for Authorization of a given identity.
  • Business model… big win for merchant (cost, conversion, experience and reach) and consumer (protection, convenience)…

For eCommerce/mCommerce merchants this may be the biggest “no brainer” since Cybersource offered to offload card processing/fraud risk management.  This is a killer…  from both cost, and advertising perspective. The primary challenge Google faces is that 70% of eCommerce sales are controlled by Amazon, eBay/PayPal/GSI, and Visa/CYBS… They can make it difficult for smaller brands to turn this on.. but it will happen… Amazon may even want to let Google eat 1% interchange on all their sales.

Osama and the Google team have done great work getting this out to market. Congrats.


On the P2P side.. not quite sure. Sending money in gmail is certainly better than a stand alone service.. but EVERY SINGLE P2P effort money with gmailhas failed: Obopay, Visa Money Transfer, ClearXchange, POPMoney, Zashpay, paybox, ..  Consumers just don’t pay other people (like babysitters or golf bets) electronically, nor do they PAY FOR PAYMENTS. There is a strong social element in giving and receiving something of physical value (ie cash). Remember when your Grandmother sent you a birthday card with $20 in it? It just wouldn’t be the same if Granny sent me an email with an electronic notice..

With respect to Google’s new service, I will certainly say that Google has done a great job with integration, and there is no more highly used service in the world than Gmail.. so if anything had potential.. this is it. Google is not exactly a culture that seeks operational folks.. more of CREATORS.. not regulatory, payment ops, KYC, dispute, … experts. This will be one GIANT headache of a service to manage (globally).  If they can make this work, and extend to android.. it could be the LINCHPIN to ubiquity and payment success in emerging markets. Payments for “free”!!?? If cross border were enabled, what would this do to Xoom? PayPal? WU? See my blog on Growing the world’s economy and poverty alleviation.

 NFC Thoughts

Is Google walking away from NFC? Don’t think so.. there are probably markets where it makes sense. US doesn’t seem to be one of them.  Remember the NXP chips only just recently allowed more than one card emulation application.. so for last 5 years everything had to be Visa, or MA, or Amex.. ISIS is facing delays because of lack of Gemalto SWP SIMs and the handsets to support them… and consumer “demand”.  The NFC ecosystem is dead in the US… the only people that win are banks and telecos.. Merchants are not enabling contactless.. for a reason. As I told Google 2 yrs ago, to establish consumer behavior, you must use it 5+ times per week. There are 3 critical payment areas for this: Grocery, Gas and Transit.  Without participation here.. no payment change will occur.   See my note on Apple and NFC, and Google Wallet.

My top recommendation is to integrate this tightly with KYC/Authentication initiatives..  See blog on reputation.

13 thoughts on “Google in Payments: Why Yesterday was BIG News”

    1. From the Instant Buy FAQ (
      “For Instant Buy transactions, … the payment is authorized against the Google Wallet Virtual OneTime Card, and then Google charges the user’s credit or debit card for the same amount.”

      My initial bet would have been this:
      If Google is working with a small (Durbin exempt) issuer for creating these temporary cards, pricing will to my understanding be non-Durbin debit, as suggested by Tom.

      However, the following Q&A is also found in the FAQ, which makes me uncertain:
      ” Who is the merchant of record?
      Even though the transaction is facilitated by Google, the merchant is the seller of record for the purchase.”

      I’m not sure if this affects the merchant service charge, but to me it sounds as if Google has found a new way to create a staged wallet… and my first suspicion is that with this approach Google is maybe not affected by MA’s new staged DWO fees. However, I might be completely off base, and am hoping that Tom or some other informed person can clarify.

      1. Staged wallet fees from MA would only apply if it was a different acceptance brand (ie pay with paypal), not with a MA PAN.. so there are no MA Staged Wallet fees in Google’s model because they operate on a Mastercard.

        Very good find on the “order” of the transaction. Obviously they must have some very good risk management. Hope the issuers don’t play games with them.. having Goog auth the transaction first before hitting consumer’s card can be problematic. Reminds me of the VBV fiasco in Europe 5 yrs ago. VBV shifted liability to issuer.. but it was complete garbage. Fraudsters were registering for the VBV service (as card holders), a top 3 UK issuer told me British Airways was a popular target.. and the banks were eating all the fraud loss. So what did the banks do? they turned up the authorization tolerances in their HNC Falcon implementations.. in other words consumers were getting declined. BA was flipping out.. consumers could make reservations with other airlines..

        So much for liability shift … banks still had power of authorization. Banks would need to have a good case for doing this to their customers in US.. but they could still make life difficult.

      2. Discussing in Twitter space w/ @SJL on whether Google MA is hybrid card or pre-paid. Lasse, the wallet FAQ you reference may not be current. Or it may be current for the NFC wallet… but not Google InstantPay. We should see details from Google on the merchant cost of instant pay soon.. which will lead us to understanding of pre-paid vs. hybrid card.

    2. See discussion here

      MA’s Rates for non-regulated debit (Card not present) is 160bps. Card present was 110.. my fault. will adjust blog.

      As Durbin 235.2f part 5 (Debit Card) outlines for “virtual wallets”
      The Board has added comment 2(f)-4.i to clarify that hybrid cards that permit some transactions to be posted directly to an account as defined in § 235.2(a), rather than posting first to a credit account, are considered debit cards for purposes of this part. Only those transactions that post directly to the account, however, will be considered electronic debit transactions.

      And Part 6
      If at least one virtual card within the virtual wallet may be used to debit an account under § 235.2(a), then that virtual card is a debit card for purposes of this part, notwithstanding the fact that other cards in the virtual wallet may not be debit cards for purposes of this part. The entire virtual wallet is not considered to be the card, or other payment code or device.

      The last part is a gift to Paypal.. for NON POS PAYMENTS. Payment with Wallet only (a three party network transaction using cards stored in the wallet for settlement) is not covered by durbin. However POS Wallet payments are Debit transactions when one card is debit.

      In the market, we see 2 different solutions. Fifth third taking PIN for debit or swipe for credit so that their hybrid allows the merchant to route at POS.. and complies with Durbin debit routing rules. (see

  1. Tom, how is the rate merchants pay different in this case than with previous iterations of Google Wallet… wasn’t the merchant-facing payment vehicle always a MC virtual debit card?

    1. Previous goog wallet was combination of old checkout, chrome auto fill and the NFC wallet. The current NFC wallet 1.5 operates as a MasterCard (since 11/12). The online wallet did not. Chrome used the cards in the wallet to auto fill the card numbers you had stored, it was the checkout model… Sort of.

      Now the ECOM/mCom wallets (instant pay) works the same way as the NFC wallet. Of course this is in a card not present model…where the NFC is a card present transaction for MasterCard… And debatable for all of the other cards.. This is the don’t wrap me issue.

      Clear as mud? Anyone else care to comment?

  2. Ah, I was imprecise in my comments– this is online vs. offline fuzziness, and we agree, I think. The offline Google wallet (e.g. the one used at physical POS, via NFC) has always been a MC debit card, getting card present interchange. Now with the m-commerce solution, it will always been seen as MC Debit by merchant and get MC CNP debit rates.

    Offline, no change.

    I think we got it.

    1. Probably a few discussions within this.

      1) What is success? Domestic v. International, usage v. profitability, volume growth, penetration vs. alternatives, bank dependency/incompetence, customer satisfaction, competition v. alternatives, Customer behavior

      2) Stand alone P2P, vs an add on service to something that already exists.

      I would argue that Paypal’s P2P success is more in international remittance than domestic.. which would fall into class of remittance (vs P2P).. My view is that if we look at broad adoption, and profitability, all are failures..

      Banks have the ability to turn this on for free… and kill any start ups.. they haven’t done so for a reason.. friction in money transfer is important to them. They are in complete control of the “speed” of transfer.. something they will push even harder on when their token project moves to next phase.

Leave a Reply

Your email address will not be published.