> But what is Apple and Google's special proprietary sauce then?
There isn't any. Many banks across the world offer their own HCE wallets, but these only run on Android (Apple simply doesn't offer the necessary APIs, although that's now changing in the EU).
What does matter a lot are defaults: You can only have one default Visa, Mastercard etc. wallet per device (that you don't need to specifically need to open before tapping your phone), so Google Pay has a huge advantage there, since it supports cards by many banks and not just one as would be the case for an issuer HCE wallet.
> However, I'm sometimes under the impression that Apple/Google take on the role of a payment gateway or a payment method themselves.
They don't. They're involved in mediating the initial setup of a new card on a given device, but aren't part of the actual transaction flow at all (at the POS, in any case).
> Moreover, I noticed that some merchants refuse my payment when I use e.g. Google Pay with my Amex instead of my MasterCard.
The underlying card brand still needs to be accepted by the merchant. Unlike e.g. early Google Pay (or what it was called back then; I lost track) and some other solutions, modern-day Google Pay and Apple Pay aren't "proxy cards" (which can sometimes change the card brand, e.g. from Visa to Mastercard; an example of that would be Curve).
> it also seems payment terminals at the grocery store needed special support for the Apple/Google Pay apps.
They don't. Unless a given POS terminal is buggy, it'll work anywhere that otherwise accepts the underlying card scheme. The physical and logical protocols are exactly the same as for actual plastic cards and mostly indistinguishable to the terminal; actually breaking Apple Pay/Google Pay support needs a lot of destructive energy on the merchant's/PSP's side.
On the web it's a different story; explicit support by both the store website and payment service provider is needed there.
This is underrated.
Eg I have Garmin Pay on my watch. It works anywhere Apple/google etc works, even though the merchants and quite possibly whoever set up their terminals have never heard of it.
Android essentially provided bunch of interfaces over time to either load a complete payment infrastructure through hw means (usually it involved telco cooperating with banks to provide EMV secure element on the SIM card, and the NFC chip has hardware connection to the SIM card), and later and more popular there's both complete Host Card Emulation capability (so you can run EMV protocol in your app) plus Google Pay integration making it easier on issuer because now they don't have to implement EMV themselves on HCE, and also provide more convenience to users vs forcing you to open specific app when you have more than one card connected.
> > it also seems payment terminals at the grocery store needed special support for the Apple/Google Pay apps.
> They don't. Unless a given POS terminal is buggy, it'll work anywhere that otherwise accepts the underlying card scheme. The physical and logical protocols are exactly the same as for actual plastic cards and mostly indistinguishable to the terminal; actually breaking Apple Pay/Google Pay support needs a lot of destructive energy on the merchant's/PSP's side.
this doesn't fit my experience. For example, Home Depot doesn't accept apple pay but their chip readers work with other cards. If there's no difference then it would seem impossible for the machines to distinguish apple pay from any other card.
Do their readers do contactless payment at all? Apple/Google Pay are just presenting your phone as a contactless payment card so it should work anywhere a physical card can be used that way.
My local HD does NOT do contactless of any variety. It's chip or swipe.
Same for my local Thai food carry-out.
I would have sworn my local bicycle shop did contactless for cards only (but not devices) - I'll have to test that next time I'm there. It could just be that the pub/cafe side has a contactless reader but the retail side is chip/swipe-only (effectily two businesses in the same space and owned by the same person).
I believe they don't have NFC enabled on the terminals at all. Same with Walmart (allegedly, I haven't been there in a while). I've heard rumours that the reason for this is so they can do customer tracking more reliably, but I'm not sure how much more valuable an actual card PAN is than a DPAN if the DPAN isn't getting rotated.
I’ve seen the data the reader gives us from a dip vs a tap (inserting your card vs NFC) and there is a difference. IIRC we would get the name on the card from a dip but not from a tap. In both cases we get the last 4 digits though.
At Home Depot at least they do this due (in part, if not in whole) to returns. Your virtual card number may change, since it’s generated every time you add it to a device. This breaks their easy return lookup where you simply present the item and your card, no receipt needed.
I actually ran into exactly this when I tried to make a return to Target after losing my receipt. I had replaced my phone and the card number changed. Luckily for random reasons I had my old phone laying around still and was able to come back and return with that.
Having done a receipt based return vs. dozens of card based returns at Home Depot, the staff time involved is orders of magnitude more so I understand why they would turn NFC off. Tracking may be part of this consideration too, but I’d speculate it’s secondary.
> "this doesn't fit my experience. For example, Home Depot doesn't accept apple pay but their chip readers work with other cards."
It must be different in the US, then. In Europe, Canada, and elsewhere, any terminal that accepts standard contactless cards (ie: pretty much 100% of them now days) will accept Apple Pay/Google Pay.
When Apple Pay first launched, there was an issue where some older terminals would apply the unauthenticated contactless payment transaction limit (£50 or whatever), instead of recognising that device-authenticated payments should have no limit. But that's long since been fixed.
I don’t know much about the underlying tech, but some large retailers (Target sprints to mind) resisted adding contactless payments and push users to use their own app. Some quick searching indicates they may have added support in 2018 or 2019. It sounds like Walmart still doesn’t support them.
Yeah, recently my Apple Watch stopped being usable with the tap terminals at a certain gas station chain here. I have to use the physical card. I use the Apple Watch tap at basically all vendors that accept tap, except this one gas station brand. Weird, right? Especially strange is that I paid with the same Apple Watch and Apple Pay setup for a long time (like years) and one day they just stopped accepting it.
For some reason, recently Apple Pay on my phone stopped working on the local trams. It works everywhere else, and Apple Pay on my Apple Watch, using the exact same card, works fine. No idea what weird technical glitch is going on there. The tram company says Apple Pay is supported.
In general, when you have this kind of bugs, it have to do with transaction amount limits which looks like they are a mixed bag of rules from the terminal and the card itself.
In the early days of mobile payments, I remember that some terminals were configured to enforce the legal limit for contactless cards (which was 30€ IIRC) even if you paid with mobile.
I haven’t encountered this issue for the last few years though, I even forgot my card PIN.
Oh, yeah no in this case you tap ahead of making the transaction. Maybe it preauths a certain amount? But.. I've made purchases of like $350 with Apple Pay, maybe more.
There isn't any. Many banks across the world offer their own HCE wallets, but these only run on Android (Apple simply doesn't offer the necessary APIs, although that's now changing in the EU).
What does matter a lot are defaults: You can only have one default Visa, Mastercard etc. wallet per device (that you don't need to specifically need to open before tapping your phone), so Google Pay has a huge advantage there, since it supports cards by many banks and not just one as would be the case for an issuer HCE wallet.
> However, I'm sometimes under the impression that Apple/Google take on the role of a payment gateway or a payment method themselves.
They don't. They're involved in mediating the initial setup of a new card on a given device, but aren't part of the actual transaction flow at all (at the POS, in any case).
> Moreover, I noticed that some merchants refuse my payment when I use e.g. Google Pay with my Amex instead of my MasterCard.
The underlying card brand still needs to be accepted by the merchant. Unlike e.g. early Google Pay (or what it was called back then; I lost track) and some other solutions, modern-day Google Pay and Apple Pay aren't "proxy cards" (which can sometimes change the card brand, e.g. from Visa to Mastercard; an example of that would be Curve).
> it also seems payment terminals at the grocery store needed special support for the Apple/Google Pay apps.
They don't. Unless a given POS terminal is buggy, it'll work anywhere that otherwise accepts the underlying card scheme. The physical and logical protocols are exactly the same as for actual plastic cards and mostly indistinguishable to the terminal; actually breaking Apple Pay/Google Pay support needs a lot of destructive energy on the merchant's/PSP's side.
On the web it's a different story; explicit support by both the store website and payment service provider is needed there.