This makes it obvious how successful the Wallet Card was, I wonder how well Google Pay is doing. I would not have even heard about Google pay if I wasn't on HN, and I have used Android from the beginning.
The issue is that by using virtual Master Cards they have to pay part of the interchange fee to Citi (or was it Bancorp?). Not only that, but if you were backing it by a credit card, then they ate the 2% fee that they get charged in the backend when hitting your real credit card.
Plus the fact that they were essentially issuing you and everyone else short term credit when you made a purchase and that every transaction was Card Not Present no matter what (even if you swiped the "real" google wallet card, which was fun to do)
... yeah.
It was never going to stick around unless you got charged for usage, at which point it's not so attractive.
The pressure in the industry is to move to the secure-element/token based system anyway, i.e. Samsung/Android/Apple pay.
If you want to do funky stuff in the backend to abstract your purchases into one place then Simple or something like that is for you.
What I'm worried about is what's going to happen with the send-money feature of Google Wallet, which was attractive for short-term keeping track of who owes who what without Paypal fees.
I'm hoping they bring that back and somehow link it into Android Pay, even if there's some kind of fee coming or going for when you actually "collect". (Keeping it otherwise liquid and fee-free when you're just moving numbers around between accounts inside the system).
Google Wallet will still be used to send money between Google users. In fact, that appears to be its only function going forward.
Money will be taken directly from the sender's debit card or checking account, and the recipient can deposit it in their checking account. The only features going away are the physical Wallet card and the ability to add to your Wallet balance.
Unfortunately this is still a step back because the whole upside to Google Wallet was that you could "carry" the Wallet balance and use it as no-fee settlement between acquaintances, or turn around and pay for Google services with small amounts not worth withdrawing.
I mean if you can do ACH (i.e debit cards) with both parties and avoid fees then that's convenient in that you don't have to exchange checking account numbers or something outrageous (just email addresses), but that still could take an indeterminate amount of time to settle. Next day? A week?
But with the wallet balance you could hold transfers I got from other people or put money in ahead of time from my bank and then when I need it, the other party knows they got it on their phone.
There is no backing credit card with Google Wallet Card. The card is debit card for the balance in Google Wallet. The Google Wallet balance could be transferred from bank accounts or debit card, or from credit cards with fee.
The confusion is that Google Wallet app did both the Wallet transfers and NFC payments. Before Android Pay, the NFC payments used virtual credit cards.
The send money functionality for Google Wallet still exists. It is now the only purpose of the separate Wallet app.
While Apple Pay adds dozens of banks each month, the list of Android Pay participating banks seems to have barely budged since the beginning (https://support.google.com/androidpay/answer/6314169?hl=en). In particular, Chase still doesn't work with Android Pay.
Honest question, I must be missing something here - Why does your bank need to participate? I just add the card number from any credit or debit card and tap to pay just works. I don't use any of the banks on the supported list.
EDIT: Taking a stab at answering my own question - it looks like you can only set up ACH drafts from the list of supported banks, but as far as I can tell you can use any major credit card to fund purchases.
EDIT AGAIN: As pointed out below, this only works for me because I added these cards in to the old app and they were grandfathered in.
I believe Google Wallet works with any credit card because the payments go through Google, and then Google bills your card.
NFC tokenized payments (e.g., Apple Pay and Android Pay) use an alternative credit card number issued by the bank. Payments do not go through Google or Apple, and only the bank knows that this alternate number is associated with your credit card account.
Google Wallet actually moved to a prepaid model - you can only spend money that you add.
Android Pay works for me the way that you described Google Wallet working. I add a card number (seems like almost any card works, I have a MasterCard Amex and Visa Credit and Debit that all work) After I tap to pay Google charges my card for the amount.
EDIT: I just looked back at one of the recent tap-to-pay purchases I made with Android Pay, the charge on my card says 'GOOGNFC*[merchant-name]'. I believe that means that Android Pay charges are going through Google.
Android Pay grandfathered cards that were entered in the old app. Those still use virtual credit card if the bank doesn't support tokenization.
After grace period, Android Pay no longer supports adding cards without support from bank and tokenization. For example, I had deleted my Chase card and get an error about bank not being supported if I try to add it.
Ah that's interesting - I wondered if that might be the case. Mine have all been in there for a while. Seems like they'd have to as they're probably losing money every time I make a transaction. I guess I better not delete any of mine then :)
When they say "bank", the term used in payments processing is "issuing bank", or more simply "issuer". The issuer is the entity that processes your application and issues you a card. They are responsible for approving purchases [0] on cards they issue and settling with the merchants.
So that list is basically the set of issuing banks which have done whatever steps are necessary to integrate with Android Pay.
[0] Typical flow looks something like this:
The merchant signs up with a payment processor who issues them a POS; this is the machine you swipe your card through. That swipe goes to the payment processor's network, which looks at the first 6 card digits, otherwise known as the Issuer Identification Number [1], and routes to the appropriate card network. For instance, any card starting with "37xxxx" is going to route to AmEx. The card network then routes to the issuing bank, who actually approves (or not) the transaction.
I think the point I'm trying to make is that you don't need to be using one of those banks to be using Android Pay. I use Android Pay for tap-to-pay purchases regularly and do not use one of the supported banks. You can use Android Pay with any major credit or debit card.
Note the verbiage on the second section of the supported issuers: "Add a card from any of these participating banks and continue to get the same rewards, benefits, and security of your cards."
I have a feeling that unless the issuing bank is supported, that Google is basically routing the payment through themselves. (Your responses on the other thread seems to confirm this.) So basically, Google bills your card directly, and they somehow route the money to the merchant. (Not sure what would the the "normal" way to do that; a bit out of my depth. I could probably ask people if you really want to know.) This means that, for instance, if your card gives a bonus for restaurants, and you use Android Pay and the issuer is not supported, that you likely will not get that bonus. Because according to your card the merchant is actually Google and not the restaurant.
So basically, Google is acting as a middle man in the transaction. They (somehow) pay the merchant in lieu of your card, then bill your card directly. This would not happen with a supported issuer; the payment would proceed as it normally would without Google and you get all your sweet, sweet reward points.
Thank you, my curiosity is sated :) I think the 'somehow' is pretty simple - I think they just provide their own CC number (or one they've assigned to me) to the merchant when I tap my card, and then charge me later.
Good point about the merchant specific CC points - it seems obvious that Google is losing out in this strategy because they're probably footing part of the merchant fees instead of passing them on to me (or the seller.) I couldn't think of a way that that would matter to me as a user, though.
I use my Chase debit card with Android Pay almost every day. It really doesn't matter which bank you have, as long as your debit card is supported, and I don't know of any major cards that aren't.
The issue is that by using virtual Master Cards they have to pay part of the interchange fee to Citi (or was it Bancorp?). Not only that, but if you were backing it by a credit card, then they ate the 2% fee that they get charged in the backend when hitting your real credit card.
Plus the fact that they were essentially issuing you and everyone else short term credit when you made a purchase and that every transaction was Card Not Present no matter what (even if you swiped the "real" google wallet card, which was fun to do) ... yeah.
It was never going to stick around unless you got charged for usage, at which point it's not so attractive.
The pressure in the industry is to move to the secure-element/token based system anyway, i.e. Samsung/Android/Apple pay.
If you want to do funky stuff in the backend to abstract your purchases into one place then Simple or something like that is for you.
What I'm worried about is what's going to happen with the send-money feature of Google Wallet, which was attractive for short-term keeping track of who owes who what without Paypal fees.
I'm hoping they bring that back and somehow link it into Android Pay, even if there's some kind of fee coming or going for when you actually "collect". (Keeping it otherwise liquid and fee-free when you're just moving numbers around between accounts inside the system).
crosses fingers