When Apple Pay first started to become common, I looked hard at it through the lens of my own retail payment processing experience. One of the things that impressed me most about it at the time was just how rooted in industry standards it was. None of it from the radio back was Apple-specific at all at the time, and by my read of this piece, that has held up through the present.
At the time, I recall a few merchants who were intentionally accepting card-based tap-to-pay needing to alter their systems because they found themselves accidentally accepting the very standards-based Apple tap-to-pay, and they didn't want to. (CVS comes specifically to mind... IIRC they were part of a competing scheme, and they wanted the fact that their competing scheme was accepted at their retail locations to help differentiate that scheme from Apple Pay.)
I'm goad the author took the time to do a more current review in this context, because when the "only Apple Pay does this" mythology started to emerge recently, I was scratching my head, wondering if something had changed since I had last gotten to look.
Something that's missing from all of these discussions is that transactions on Apple Pay (and all similar wallets like Google Pay, Samsung Pay etc.) are now just as trackable as those done using the underlying card number.
While the DPAN is unique to a given device, the merchant's payment service provider these days can receive a unique identifier called PAR in the authorization response from the card network. That identifier is consistent across all DPANs for the same card (and aspirationally even across card number changes on the same underlying account).
The PAR can't be charged by any merchant, so this is not a security problem, but don't expect your digital wallet payments to be any more private than those done using your regular card or card number.
https://wcapra.com/payment-account-reference-capraplus-your-...
https://www.securetechalliance.org/wp-content/uploads/EMVCo-...
The post by Matt Birchler has been amended with the paragraph "A previous version of this post suggested the DPAN changes between merchants, but that was a mistake. Serves me right for cranking this post out too quickly. Seriously, my bad.". However, the rest of the post still suggests that there is a unique DPAN per merchant, but I can't find any basis for that.
Even Apple's own documentation at https://support.apple.com/en-us/HT203027 says that the DPAN (called Device Account Number here) is only unique per device. When a card is added to Apple Pay a DPAN is created for that device, and it never gets changed afterwards unless the card is removed and re-added.
So whereas you can't be tracked by using the same card on two devices (e.g. iPhone and Apple Watch) because they will have two different DPANs, I'm pretty sure data brokers can track you when using the same card on the same device across different merchants.
Why are SSO and mobile pay not standard interfaces that anybody can build a provider for? Why is there "Login with Google" or "Login with Apple" instead of "Login with [my default configured SSO provider]". Or "Pay with [my default configured pay provider]"
Even worse, many times vendors/sites only support a subset of these providers, making SSO not really SSO at all.
I'm sure the reasons are out there, but I haven't researched it in-depth. It seems to me there should be a common agreed upon spec that all vendors adhere to. If not, it will probably be legislated to this standard sometime in the future
Funnily enough, Apple Pay launched in Australia following a multi-year push by local big banks to increase the use of contactless payments. So all the infrastructure was already there, built out by the banks themselves, when Apple came in demanding a US-style cut, as though they built the thing. The local big banks held out for years on supporting Apple Pay, before the customer pressure became too overwhelming and they relented.
They're all still very upset about this, and would drop Apple Pay in a second if the NFC chip were forced open by a regulator, but to date they've found it hard to find anyone too sympathetic to a sob story from - well - the nation's biggest banks.
> the merchant chooses how much personal info they want or need to collect, and Apple Pay doesn’t prevent them from asking you for that at checkout.
Does this happen when shopping in-person?
> of course that info would be there! In this example, my checkout page was for a physical item so I needed the customer’s shipping info.
They don't need my name and address if I'm buying eggs in a grocery store. Does Apple/Google require my consent to share that info when it's obviously not required? Is it similar to a terms & conditions, or shrink-wrapped EULA? (ie take it or leave it)
I've never used these payment systems.
Off-topic, but I still don’t understand why Apple Pay cannot display on the screen the sum currently to be paid before I validate the transaction. I suppose it is not a UX issue, but I suppose that sum is simply not known by the Apple device. Any idea?
Where did Gruber say that “only Apple Pay does this”? The writer goes on to point out a few mistakes (or rather, didn’t quite get the details right) Gruber made, and that’s seems to be it.
> Apple did a great job mainstreaming digital wallets like this, what they do is not unique in the industry.
I may misremember, but I think Apple Pay was pretty unique when it first launched, which is why it was supported at so few places. Other phone payment systems (like I think the original Samsung Pay) just sent the card number straight to the machine.
It says that Apple Pay protects your privacy by randomizing the number, but Clover based stores seem to have no trouble tracking my loyalty rewards once I linked my phone number to my virtual card.
Same for transit like OMNY in NYC. It tracks my virtual card enough to implement fare capping.
There seems to be a misunderstanding about the details of how Apple Pay is spelled here...
Can we fix the typo in the title?
I am not sure if I'm losing it but the following statement doesn't make sense in my head:
> Your same card used through Apple Pay on your iPhone and iPad will show different DPANs, though since each device gets its own number.
That 'though' does not compute.
> Basically, when that Apple Pay card pops up when you’re checking out, expect everything on that card to be sent to the merchant
Apple Pay. But what about Apple Pay? You know, the one in store, where you hold your phone against the NFC reader?
The author should not be using pixilation as a method to redact information from his screenshots.
This was a fun read, appreciate your work. Did you read anything about iCloud Private Relay emails and how they get used with apple pay?
Apply Pay?
> Apple Pay through Wallet obfuscates your actual credit card numbers, which retailers infamously use to track customers. It’s far more private than using your credit card itself. I highly doubt any banks or credit card issuers would do this themselves if given access to NFC tap-to-pay.
Maybe someone can answer whether this is already solved by GDPR? If I do not give explicit consent to use my credit card details for anything else but withdrawing the agreed upon amount, that would be illegal (... in EU countries).
Edit: It seems like this is, at least in some capacity, a commentary on the DMA. I understand the concerns about privacy in a US context, but these issues should already be solved in an EU context.
So what Apple will most probably do, keep US companies from implementing NFC wallets but allow EU companies to implement NFC wallets, seems to be a really good compromise for the author - Privacy is kept both for the EU and the US users.
Look up Network token - or EMV token.
@dang @CharlesW typo. Please fix.
You don't need a digital wallet app to do this, either. Plenty of credit card companies let you generate burner numbers to avoid giving out your real number.
EDIT: Would someone like to explain why this is downvoted? This statement is objectively true; for example, Capital One calls these "virtual card numbers".
That's a really good break down.
>I highly doubt any banks or credit card issuers would do this themselves if given access to NFC tap-to-pay.
Yeah, that's just more FUD around "Apple protects consumers therefore they should be able to do what they want", very topical atm. Idk why people glorify Apple and expect them to protect consumers when we should really be asking this of our governments (ie GDPR, the way that governments hold banks to particular standards) this is something the EU should push harder and expand on, imo - rules that are applicable to all companies.
What's interesting is Apple's evolution in their marketing of privacy+security, because it's not something they've always done and it seemed to have started when they realised all their competitors have fragmented platforms and that Apple can compete since they do not need the revenue from onselling consumer data.
Nice post!
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?
[0]: https://news.ycombinator.com/item?id=39845805