Can anyone ELI5 how Apple & Google Pay work in detail? I used to think they simply pass on my CC details to the merchant or the merchant's chosen payment gateway in one way or another (obfuscated or not), and the OP suggests the same. Moreover, I noticed that some merchants refuse my payment when I use e.g. Google Pay with my Amex instead of my MasterCard.
However, I'm sometimes under the impression that Apple/Google take on the role of a payment gateway or a payment method themselves. After all, they collect all my transaction data, and it also seems payment terminals at the grocery store needed special support for the Apple/Google Pay apps. Interestingly, this comment[0] is saying the opposite, namely that at least Apple Pay is very much rooted in standards.
But what is Apple and Google's special proprietary sauce then? Why are these apps so hard/impossible to replace by open-source alternatives? Is it because only Apple/Google get full access to the NFC chips on iOS/Android?
> 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.
They work using contactless EMV, which is the same way contactless credit cards work, and is the standard behind Visa/MC's Paywave and Paypass products.
This is why wireless terminals in general just work with apple and google pay and actually didn't need much in thw way of special support. From what I recall one of the few things that did change was raising of payment limits for these devices over contactless cards, because they are deemed more secure (can't be used by just anyone that happens to have stolen it).
> Why are these apps so hard/impossible to replace by open-source alternatives?
EMV implementations are non-trivial and need a lot of testing and validation using specialised equipment. There need to be secure enclaves on the device to hold private keys in a way that can't easily be compromised. The app needs to interact with the phone in such a way as it can tell that biometric or PIN-based unlocks have been used so that it can vouch for user security. And the app needs to interface with card-issuing banks on the back end during setup, to get the keys and details it needs issued.
An open source implementation would need to jump through a lot of hoops and set up agreements with the banks and pay for all sorts of lab verification (probably through UL).
> From what I recall one of the few things that did change was raising of payment limits for these devices over contactless cards, because they are deemed more secure (can't be used by just anyone that happens to have stolen it).
The limits are the same, but what these wallets added is on-device cardholder verification.
In a nutshell, it lets Apple Pay tell the terminal "the cardholder already did Face ID/Touch ID/entered their passcode; it's fine", which can then skip PIN entry or signature collection.
Other wallets do it differently and only prompt for that on-device authentication if the amount exceeds that where a PIN or signature would normally be required; yet others don't support it at all and just make you enter the PIN on the terminal (if there is any).
A couple of times that lack of signature verification tripped up a cashier, they’re obviously used to always needing it with however their terminal was configured, but with Apple Pay the receipt got printed with no signature line and after looking at it funny they’re like, “oh, well here’s you’re receipt I guess you don’t need to sign!”
I'm glad the cashiers in your country took it that well!
I've heard of a few cases of surprised employees getting suspicious or outright hostile in the early Apple Pay days (when it wasn't available to domestic cardholders yet and only tourists would use it)
This might be largely due to a strong culture of cashiers expecting to be handed over your card and them being the ones to insert it into the terminal (which is quite ridiculous – it causes the terminal to be pivoted between cashier and customer twice for each transaction for the mandatory PIN entry).
This is quite frustrating. I used to have a rather low limit for contactless payments. Back then, some terminals would not prompt for a PIN when the limit was exceeded and would simply decline the transaction. Abroad, I had several incidents where a cashier would take my card, see the "contactless" icon on the card and tap the terminal. It was usually difficult to explain with limited English that they needed to insert the card because the limit was exceeded.
I ended up crossing the contactless icon out with a marker.
I got this experience first hand in Boston in 2008ish, "Tap and Go" had been introduced to Australia for what seemed to be years before and the cashier expected me to "pass my card" after I had already tapped to pay.
Fortunately she took my explanation well and wanted me to demo it in front of a co-worker.
The only “secret sauce” is the liability shift. Traditional online and contactless payments are classed as “cardholder not present” transactions which place more liability for fraud on the merchant.
Apple and Google Pay (and other bank-provided payment apps) use biometrics to confirm cardholder authorisation, switching a subset of payment types to cardholder present.
This means some chargeback types are instantly declined, and others have a lower requirement for merchant proof.
This is all part of the card network standards, which are freely available if you’re interested from https://www.emvco.com/
The reason there’s no open source option is the requirement to certify the implementation’s security, so you need a commercial entity to work with the banks. Oh, and every bank has to integrate separately - that’s a lot of banks to talk to.
Contactless card transactions are not “Cardholder not present” transactions!
They are usually “No Cardholder Verification Method” transactions, though they can do ask for PIN entry in some circumstances.
And no, the liability is not with the merchant for contactless, or they never would have accepted it! It’s firmly with the banks, which is why the limits were initially so low - to limit potential fraud. When it transpired that fraud was more than acceptably low, they raised the limits a bit.
The liability is only with the merchant if the merchant chooses to accept a magnetic swipe transaction, or keyed card details. Not contactless EMV.
> They are usually “No Cardholder Verification Method” transactions, though they can do ask for PIN entry in some circumstances.
In Turkey, contactless transactions are "Special Cardholder Verification Required, no PIN" or "Cardholder Present, PIN required" depending on the amount. And they are legally required to be performed online with immediate confirmation.
>Moreover, I noticed that some merchants refuse my payment when I use e.g. Google Pay with my Amex instead of my MasterCard.
In my experience this is normally due to either how the card machine provider has set up the device or due to the lack of certification of the mobile wallet functionality on the "acquirer" backend ("host") that speaks to the card schemes.
It's annoyingly tricky to get the end-to-end transaction working properly across all schemes, all payment methods and devices. Different card schemes support different "payment kernel" parameters and have different certification requirements.
It could also be an attempt to save money on transaction fees, amex is generally significantly more expensive for merchants.
Historically, Amex always required a separate retailer relationship and to act as its own acquirer. I don't know how true that is any more. They've just always been the awkward one, with higher fees and special relationships. Also they used to use ANSI standards on some stuff where everyone else used ISO... but that's going back 20 years!
Yes, that is still true – AmEx own their own payment processing network, and they do not allow outsiders into it, even banks they have the brand sharing agreements with, hence a separate retailer relationship.
>Different card schemes support different "payment kernel" parameters and have different certification requirements.
Those certification requirements are one of the biggest hurdles because they can change quite often, and unless you are a high-volume gateway, there may be no leniency for you, making simply refusing the transactions cheaper than processing them and being fined.
The digital cryptogram requirements for visa caused some major engineering expenditures for a few payment processors I'm aware of.
When I briefly had my own store I blocked amex because of their ridiculous fees. And they are pretty merchant hostile re: chargebacks too. The overhead and headache wasn't worth dealing with them. That was a while ago so maybe they have improved, but I still occasionally run into places that don't take them so I guess not.
> Can anyone ELI5 how Apple & Google Pay work in detail?
Oh, in case this was not really answered in other responses ...
When you add a card to an Apple or Google wallet, the wallet softwares goes off to your card issuer and asks for permission to include it in the wallet. Your card issuer may then ask you directly if it's OK and please confirm. When you have confirmed, they provide some details to your phone including some private keys (likely derived from a master) and other bits and pieces like the PAN to use, supported transaction types etc.
OK, now it's set up in your phone. What happens when you tap?
The terminal first goes through a sort of rapid handshake - hey, I'm a terminal, please select your default card application, let's go!
Then it asks for a bunch of data - can I have your PAN, expiry, velocity data, hard and soft limits etc, please?
Then it sends a bunch of data to your card - transaction type (payment, cash, refund(?)), amount, date and time, terminal type, some other bits.
Your phone or card will then check these fit in with its internal rules (do I allow cash? etc), add some information (user unlocked biometrically/with PIN) arrange the data in a canonical order, hash and sign it and send back the resulting signature as a cryptogram. Part of this cryptogram will tell the terminal Yes/No to proceed and whether it needs to ask for a PIN or go online to the acquiring bank for approval. The terminal applies its own rules to the transaction as well, and can optionally downgrade the transaction from approved to online or denied, or from online to denied.
If it needs to go online, it will transmit the transaction details to the acquiring (merchant's) bank, which may approve the transaction immediately or itself refer the transaction to the issuing (your) bank. It's at this point, for Apple Pay, that Apple steps into the picture - as the PAN is not the 'real' PAN, the acquiring bank refers to apple, and they then refer to the issuer.
Then the approved message pops up :)
Apart from the issuer-proxying, the process is basically identical if you use a phone or your physical card.
I've probably glossed over quite a lot and got a couple of details wrong, but hey, that's the nature of ELI5.
> "But what is Apple and Google's special proprietary sauce then? Why are these apps so hard/impossible to replace by open-source alternatives?"
Google Pay and Apple Pay aren't unique. There's Garmin Pay and Samsung Pay, too, for example.
The EMV standards are maintained by EMVCo (www.emvco.com), and the specification documents seem to be out there and googleable. I'm sure anyone sufficiently qualified in NFC tech could have a go at implementing them on their own device.
The only tricky part is that you have to interface with each card issuer (bank) to generate DPANs?
The biggest difference is that no internet connection is required for the authentication because the bank trusts the user's device. CC number is randomized per transaction so that the merchant does not receive the real CC number.
I've seen cases contactless payment is not supported only for a particular brand and I believe it's because of missing software update on the payment terminal.
Honestly apples approach is pure security theater, as they're not an acquirer that process the transaction at the end.
Instead the real acquirer now reverses apples masking.
The merchants themselves aren't allowed to store the credit card information anyway, otherwise they'd lose their PCI certificate, losing the ability to process credit cards. And if they use a payment processor, then they didn't ever get in contact with the credit card information either.
No clue how/if Google does anything. I was just involved in implementing apple pay at a payment processor that was also an acquirer a few years ago. Ultimately, we've had the same information on the consumer, wherever they used Apple pay or just a regular credit card
I am not an expert in this so I can't explain it in any truly deep detail, and you might be right in terms of "Masking" the identity of the card number if you think this is a privacy feature, but there is much more to it than security theater of a per-device DAN.
Both when using EMV Contactless and when using Apple Pay on the web, some kind of dynamic and/or encrypted data is signed by the secure element of the device. EMV Contactless definitely signs the whole transaction, with Apple Pay on the web in at least some cases it will use either a dynamic CVV code and/or "cryptogram" containing the transaction data similar to the contactless protocol that verifies that specific payment request was signed by the secure device/card.
The payment processors can use this to know the transaction is freshly authorised and is not a replay of a skimmed credit card number/CVV (whether skimmed from another apple pay transaction, or skimmed from entering the static physical card details).
On the merchant/processor side, I believe in some cases you may get a better rate or different fraud protection for such transactions (especially at a large scale), or, it will also factor into the fraud control and the bank/payment network/etc are less likely to reject such a payment as fraud where as it may be more likely to reject the static physical card details as fraud, etc.
If someone knows better or different then please do share.
> EMV Contactless definitely signs the whole transaction, with Apple Pay on the web in at least some cases it will use either a dynamic CVV code and/or "cryptogram" containing the transaction data similar to the contactless protocol that verifies that specific payment request was signed by the secure device/card.
The same is true for chip card payments.
What makes Apple Pay significantly more secure in practice is that issuers can limit the device-specific card number to be only usable with a chip cryptogram, and not e.g. by manually typing it in on a website.
For POS and online payments, the idea was the same (eventually depreciate cryptogram-less use entirely and use 3DS online and chip/EMV at the POS), but alas, it never quite happened that way.
> On the merchant/processor side, I believe in some cases you may get a better rate or different fraud protection for such transactions (especially at a large scale)
Apple Pay usually shifts the liability for fraud to the issuer, yes. This is a huge advantage for merchants that would otherwise usually be on the hook for most types of fraud.
> What makes Apple Pay significantly more secure in practice is that issuers can limit the device-specific card number to be only usable with a chip cryptogram, and not e.g. by manually typing it in on a website.
That's sort of true for non 3DS enabled cards. For 3DS enabled cards, you need a second factor for most transactions on the internet.
> For POS and online payments, the idea was the same (eventually depreciate cryptogram-less use entirely and use 3DS online and chip/EMV at the POS), but alas, it never quite happened that way.
where I live it happened exactly this way since a few years. Online is 3DS only and in person is chip/EMV only
Can you not use your card in US online stores? These mostly don’t support 3DS, so there is still a large fraud vector for compromised cards that work internationally.
Apple Pay is also somewhat different from contactless/chip payments on a card because it's authenticated, whereas (US at least) cards are not authenticated since we don't use PINs.
IIRC in some countries this means it's accepted more or has higher payment limits.
A physical card usually uses the number embossed on the plastic on all other channels (i.e. magnetic stripe, chip, contactless) as well.
That's not a hard rule – some cards have no number embossed/printed at all (e.g. the Apple Card), and it's technically possible to use different numbers. But I haven't really seen it done since it could cause quite some confusion, as e.g. some airlines use the card number to look up your online booking at self-check-in machines, which wouldn't work if the two differ.
There are also some special cases of things that are technically regular old smartcards but that do (I believe) use tokenization/DPANs, like wearable form factor contactless payment devices by Swatch or Fidesmo.
My bad. I read the article but I must have skimmed past the section about DPAN being randomized because I don't remember seeing it. The majority of my attention went the last part about personal details where I thought it was pretty obvious. Short attention span.
I suspect there are more than just one combination of frontend and backend for Apple/Google Pay depending on how you're paying, masked behind that act of you presenting the device and store presenting the reader.
So I think there can be cases where "payments" (or promises thereof) can be made, while money withdrawn from banks notwithstanding, e.g. queued in an intermediary entity and manually resolved on request, in which cases the payment gateway might want to pattern detect and shut down such cases.
Correct. Though it's not the same on Android, you can be not-Google and do payments just fine, provided you have the same business relationships with the CC companies as a big merchant processor (good luck)
Not a huge fan of Android, but Android's pretty damn open, the open advocacy orgs unfortunately tend to conflate "you have to say "yes" to a dialog about untrusted apps in Android! intentionally difficult!" with the debacle the years-long Apple stuff has turned into.
I suspect we'll see less of that equivocation now that the petulance is nakedly visible, and gratefully, there's no longer billions spent on things like the "Privacy™" ad campaign, rushed after 100s of celebs had their nudes leaked from iCloud due to bad customer support.
However, I'm sometimes under the impression that Apple/Google take on the role of a payment gateway or a payment method themselves. After all, they collect all my transaction data, and it also seems payment terminals at the grocery store needed special support for the Apple/Google Pay apps. Interestingly, this comment[0] is saying the opposite, namely that at least Apple Pay is very much rooted in standards.
But what is Apple and Google's special proprietary sauce then? Why are these apps so hard/impossible to replace by open-source alternatives? Is it because only Apple/Google get full access to the NFC chips on iOS/Android?
[0]: https://news.ycombinator.com/item?id=39845805