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).
crosses fingers
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.
According to /u/GraemeStanding, who appears to work on Android Pay (which is basically the old NFC payment portion of Google Wallet, split off and rebranded): https://www.reddit.com/r/Android/comments/4crogp/just_got_an...
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.
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.
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.
EDIT: Apple uses a tokenized system, each transaction nets them a fee. Google has a hack for the payment network, it costs them for each transaction.
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.
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.
You can't add any new cards to Android Pay unless the bank supports tokenization, and payments are processed directly by them, no longer going through Google.
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.
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.
So POS -> Payment Processor -> Card -> Issuer.
[1] https://en.wikipedia.org/wiki/Bank_card_number#Issuer_identi...
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.
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.