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.
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.
Sharing a personal anecdote - when Apple Pay first launched, it only worked in the US. A more accurate statement though was it could only be set up in the US. I very shortly after moved to Australia, where tap-to-pay is the standard.
It was kind of crazy because despite not officially being supported, Apple Pay worked everywhere in Australia. Whereas only a small handful of merchants supported it in the US, 99% of point of sales in Australia supported it because it was based off the standard.
This also worked in reverse. When I was visiting the USA, when I tapped my credit card to pay on terminals that were seemingly set up for Apple Pay, it was mind-blowing for some people. I didn’t realise contactless cards were so rare over there at the time.
I had a similar experience. After it was released in the US, I took a trip to the Netherlands. I had a lot of “how did you do that?” reactions from merchants when I paid for things with my phone.
Depends on country, and how contactless cards being the norm in many places meant there was less push among people for payment with phones, compared to USA where it seems it no modern bits for card payments happened between introduction of magnetic strip and phone-based EMV2 NFC payments.
I remember changing card ~2012, in Poland, because my ancient Visa Electron with magstripe-only was confusing to new cashiers who thought lack of chip meant it's contactless. Around that time phone-based "cards" were also widely promoted though the tech wasn't exactly ready yet so you needed cooperation between banks and telcos to provide secure element.
I had the same experience as you on a trip to the Netherlands. Ironically, the only place where it didn't work was the Apple store in Amsterdam. I don't know if that was an actual technical limitation, or they were aware that it was not yet available in the Netherlands and so didn't even let me try with my phone and its US credit card.
Same, I used Apple Pay in Germany before it was officially launched there and people were very surprised that I could just pay with my Watch. Contactless payment was already becoming more prevalent, so it worked in a lot of places.
It was standards based, but the way Apple ran the launch and marketing (kind of genius, actually), they gave the impression that Apple Pay was the only phone-based tap-to-pay around. Merchants would have signs saying "Apple Pay accepted" but not mention Google, leading to confusion over whether non-Apple payments would work.
Part of that is definitely the confusing state of payments on Android. Samsung Pay could refer to either NFC or magstripe-emulation. Google, of course, is terrible at branding stuff, and between Wallet and the many iterations of Google Pay it's still difficult to figure out what's what.
> Samsung Pay could refer to either NFC or magstripe-emulation
Last time I checked, you've got to swipe a magnetic-stripe card (we mainly use C&P/contactless). Unless there's some really cool sci-fi pop-up plastic tab inside the phone / case / a separate re-programmable card, I'm really curious as to how this could work?
I haven't been able to find a detailed explanation of how it works. Somehow it emits a magnetic pulse that simulates the card being swiped, without having to physically swipe the card. Best guess is that it uses some kind of magnetic induction to induce a current in the reader the same way that a swipe would.
I never had a Samsung phone so I can't comment on how it worked in practice or the reliability. Can't find any mention of having to hold your phone a particular way so presumably it's direction-independent, although apparently sometimes it might not be possible to hold your phone close enough for the reader to pick it up.
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.
This is a very weird understanding of what IC cards are in Japan.
Yes, Apple Pay supports them, and they're ephemeral and easily recreated, and semi-anonymous; but Apple Pay over here absolutely still supports "regular" cards here.
And you can't use your IC card for online purchases, which is most of the article was about anyway.
> Yes, Apple Pay supports them, and they're ephemeral and easily recreated, and semi-anonymous
…so what I said, yes.
> but Apple Pay over here absolutely still supports "regular" cards here
But you don't have to use em.
Strange interaction here: you can refill Suica with a foreign credit card, there is no transaction fee for it, and it means you can turn anything you can purchase via IC card into 5x travel spending with the right card.
Maybe it's a non-native speaker thing; but for me when you says "Apple Pay uses XYZ here"; it implies exclusivity, that it underpins the whole system; not that it's one of the available option.
I can see now that's not what you meant.
> But you don't have to use em.
You do, if you want to use it over the internet. You and I might have a good grasp of what IC cards here are; but your comment without that knowledge can be misleading.
> it means you can turn anything you can purchase via IC card into 5x travel spending with the right card.
As long as nothing you buy costs more than 20000 JPY ;)
Sure, you can also add some anonymous prepaid/gift cards to Apple Pay, but my point is that Apple Pay does not add any privacy/anonymity beyond that of the underlying card, contrary to what some people seem to still believe.
The PAR was introduced after Apple Pay (and in a way in response to it and other wallets), and some people might have missed it.
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.
In Apple Pay they are sort of static. Not per merchant, but they don’t cycle by default for any reason. I believe there is a button you can press to have the number changed. I think I’ve seen it before but I’ve never used it.
And of course you could always just remove your card and then re-add it. That would give you a new DPAN.
Credit theft affects the banks and merchants. They are out of the money not me. Its for their benefit. I just suffer the inconvenience of getting a new card.
I noticed that the last 4 digits of the card used with Apple Pay is different every time I pay (I use my Apple Watch mostly). Not use between merchants but also with the same merchant.
Are you sure you're not mixing up phone and watch payments? And is this with a Mastercard or Visa card, or something region-specific?
The DPAN has always been constant in many years of using Apple Pay for me, which is useful to e.g. check which card I've actually used on by comparing the last four digits printed on a receipt to those I can see on my phone or watch (the card details show both the funding and the DPAN last four digits).
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
I believe what you're looking for for SSO is RFC 7591[0], which describes how to register with an oauth IdP on the fly. RFC 8414[1] describes well-known locations to get metadata about the registration process. So the standards are there, and in theory you could have a login form where e.g. someone types their email (or the browser autofills it), and that kicks off an oauth login to that domain, doing client registration on the fly if the server has never talked to that domain before. I've never seen it in the wild though. Would be nice.
I think tailscale supports exactly that? You give them your email address and they check the web finger endpoint of the domain for your configured SSO provider. https://tailscale.com/kb/1240/sso-custom-oidc
Because of "growth & engagement". Somewhere around 2010, technology shifted from being a tool to empower the user to a tool to waste the user's time with spam. Things shifted from offering a service and collecting a fair fee to spamming the user or collecting their data (so it can be used to further spam the user down the line).
An open standard isn't something any of the current providers want since otherwise users can easily substitute them with different alternatives and no longer "engage" with them.
Because user verification varies significantly between businesses, and so they need to vet and trust SSO vendors to uphold the standards they require. If there are a million sso vendors, who knows what standards each upholds.
The difference is that you can be reasonably sure that an email will be delivered to the user's address that they specified, and there is a common understanding that sharing your email credentials will result in immediate financial loss. The communication is out-of-band, as SMTP is not an authentication protocol, so the user must perform some affirmative action (such as clicking a link in the email) to authenticate the request.
With SSO, the claim that a user is authentic lies completely with the provider. If there is a bug in the implementation, a user could be authenticated when they should not be, and the actual account owner may never even be notified that such an authentication occurred.
With oauth/oidc, the service that's requesting the token doesn't even specify the username. What would the IdP send back if the user is not authenticated? The concern is it will just issue a token for a random user? Or that someone will break into another account on the IdP's login form?
I don't see any difference with email besides convenience. If an email provider has a bug, they might allow someone else to read your email and click the link without any notification to the actual account owner that such an authentication occurred. In fact, if a provider has oauth and webmail, the two probably use the same authentication system (e.g. they use the same session cookie and login form, or the webmail might use the oauth service as its auth). Even native email clients are using oauth these days. This is a good thing. It lets you store a token with limited permission in your email client instead of storing a password for SMTP that also gives you full permissions to everything the account can do.
Also most oauth implementations I've seen actually do have a dashboard in your user settings where they record which services you've provided tokens to, and what scopes those tokens have.
If you're worried about CSRF, that's what the state parameter is for, and it's the consuming service that needs to use it appropriately, so you don't need to worry about whether the IdP did it right. If the IdP gives the wrong state back, the login will fail when your service checks it.
To support "Login with Google" you have to do some config on the Google side. You have to tell them, this ils my app, this is the URL you have to redirect back to after authenticating, and do on. Otherwise there would be security problems.
Passkeys are great(-ish) for authentication, but don't offer identification at all.
It's just not in scope (and I think that's a good thing; the two problems are pretty different, and WebAuthN is already extremely overloaded with features serving conflicting goals).
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.
Amusingly, all the Australian banks asked the ACCC for permission to form a cartel and collectively bargain with Apple on Apple Pay terms. They were denied.
> 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
Not if the users have anything to say about that.
Canadian banks tried to do their own contactless payment on Android (TD Pay, lol), but nobody wants it. In the end they caved and finally offered Google Pay.
I predict it's gonna be similar. Even if Apple opens up NFC payment, nobody will use them and prefer 1st party support like Apple Pay or Google Pay.
Just see how many people actually use Samsung pay vs Google Pay.
To be part of Apple Pay, banks have to enter into an agreement with Apple. Though the details of this agreement are generally confidential, it's fairly well known that there is an Apple cut, and that that cut is rather high. (It's Apple!)
The moment a bank has the option to extract itself from this arrangement, it will. Not just because there's absolutely no reason to give Apple a cut of the bank's own business if the bank doesn't need to, but also because the bad blood between Aus banks and Apple is very real at this point.
> Even if Apple opens up NFC payment, nobody will use them and prefer 1st party support like Apple Pay or Google Pay.
And since that costs the bank money, it won't be an option. Also, I think the bank would think of itself as a first party in a payment made using their card, and Apple as a parasitic third party.
I'm not saying people won't grumble, but there is no way - unless Apple actually makes Apple Pay somewhat attractive to banks - that the banks will continue to support it if they don't absolutely have to.
(I'm not siding with the banks on this, I'm just trying to lay out their logic.)
The 15 basis points Apple supposedly charges for with card payments from Apple Pay is meant to come from the fraud budget; that a biometric-based authentication is consider both more secure and easier to counter payment disputes. The rest comes from the convenience and hope that actually results in more card payments.
In the US where there's no PIN, fraud is high. Parts of the country are still heavily cash based, so there's a good margin to gain if added convenience results in more card payments.
For heavily credit card based markets with chip-and-pin, you have less fraud concerns and less to gain from convenience.
My take though is that even if apple opens up the NFC chip, they aren't opening up the Secure Enclave. So even if a bank app can take over the NFC chip, they still will have secrets in memory at some point without a new P-256 based payment protocol.
Unless this is a new app backed by a bank cartel, you'll also go from being able to use multiple cards to just one first-party card.
This all leads to my opinion of a pretty wonky situation - opening NFC up probably increases the value of Apple Pay, since it can now be compared to other software-based wallets by users, and Apple Pay support again becomes a differentiator for the payment card.
> My take though is that even if apple opens up the NFC chip, they aren't opening up the Secure Enclave. So even if a bank app can take over the NFC chip, they still will have secrets in memory at some point without a new P-256 based payment protocol.
The NFC chip is itself a secure enclave. (It's called a "secure element" but same thing.)
It does its own key storage, which is why it can work when the phone is turned off.
> This all leads to my opinion of a pretty wonky situation
Yep, that's sadly accurate for all the banks' other tech, so I see no reason they'd shy away from it here either.
I feel like you're coming at this from the wrong angle. No one is saying Apple Pay is bad, or that the banks' solutions will be better. The question is: will banks voluntarily give up a cut to a third party intermediary, when they can roll a slightly-less-convenient-but-good-enough tech stack and keep all the money for themselves?
One doesn't exactly become a top 4 bank by handing out a cut to intermediaries willy nilly. Even if the Apple cut were eliminated (unrealistic), the banks would need a very good reason to allow an intermediary between themselves and their customers at all.
The NPP is about removing the Visa/MC networks from the equation. It would also remove the EMV requirements, if I'm identified by my mobile phone number + biometrics linked to a bank account, which can have it's own credit line associated with it, why does the bank need to support Visa/MC?
The new payment platforms with instant settlement effectively remove the branding and merchant agreements that Visa/MC offer.
Person A can transfer money to Merchant M immediately, no intermediaries except the two banks/account provider and the payment platform usually run by the central bank.
Owning a bank is an extreme regulatory headache. You always want someone else to be the bank. Or even better multiple someone elses - in the US, small banks are allowed to do things large ones aren't, so you sometimes gather up a bunch of them and become a single proxy for them.
They probably won’t do that in the current antitrust climate. I hope the DOJ and the EU continue probing the big companies because I’m sick and tired of my non-ecosystem device choices not working well together.
Apparently, too, merchants aren't actually charged for Apple Pay, it's the banks themselves that are. Merchants apparently pay the regular charge to their payment processor whether I use my Visa-through-Apple Pay or my Visa as a physical card. https://paymentdepot.com/blog/apple-pay-fees-for-merchants/
At any rate, Apple Pay is ridiculously convenient compared to anything my bank has ever come up with. The last time there was a Pay With Bank $X thing on a website that I tried, I ended up getting directed through some kind of Verified by Visa thing where they were asking for some kind of security code that I don't recall ever setting up. Or... I can double-tap the power button on my phone to verify a payment I'm making on my laptop. If the banks are unhappy about giving a cut to Apple, my recommendation to them would be: Suck Less.
For example, a bank could offer partial rewards for using their payment system, over Apple's. The effect would be the same as passing on the savings to the consumer.
Given the software that banks generally produce, it’d have to be a sufficiently good reward. If I’m buying a $10 sandwich at a deli counter, I’m going to double tap my power button and tap my phone on the debit machine. A $0.03 cash back isn’t worth the hassle to fish around to find my bank’s app, enter a secure password, and then enter a 2FA code. I had another comment elsewhere in this thread: want me to use the bank app instead of Apple Pay? Make the bank app suck less.
I don’t get charged for using Apple Pay, I get charged for the processing fee for the card I used (which is an entirely separate discussion), and given the option between “just continue using Apple Pay” or “download several janky apps just because the bank wants its own wallet impl”, I’m going to stick with Apple Pay.
If Apple is getting 0.15% as stated in a sibling, it's coming from somewhere. Maybe it's added on top of the fees the merchant pays, and like other payment fees gets kind of mixed into the price of everything you buy. Maybe it comes out of the fees your bank gets on purchases, which will reduce their income and then they'll need to increase fees, reduce benefits for depositors, or reduce dividends to investors.
Yeah, I have no interest in keeping 15 digital wallet apps, even if they offer incentives, for the same reason I don’t carry a physical wallet for each physical card.
Now I could see an argument for wallet apps being generic so e.g. the apps for Chase, BofA, SoFi, etc could carry all the user’s cards like Apple/Google wallet should the user want that, but I doubt banks would have much interest in that (at least if it’s privacy respecting and not skimming transaction history) because it’s not prying mindspace away like per-provider apps do.
It should be assumed that if the banks get an opportunity to implement their own NFC payment system on iPhone, they’ll switch off Apple Pay. Otherwise no customer would have any incentive to migrate over. And the incremental cost of Apple Pay is too little to be redirected towards some customer incentive program.
(Of course that doesn’t preclude a bank from making an irrational decision.)
Eh, maybe not in Australia. Remember Australia doesn't have like 5 million banks, we have essentially 4 big ones and they already are pretty cutting edge vs US/Canadian banks. i.e instant transfers are normalized, NFC is the norm, apps and Internet banking have been very good for about 10 years.
If the NFC chips were opened up through regulation I have zero doubt Australian banks would just say "we support contactless with our first party app" and that would be the end of that until Apple asked for a more reasonable cut.
When all your banks suck and Apple seems to be the only people with their shit together, sure but Australia doesn't live in that world.
Canada has essentially 6 big banks, instant transfers using Interac has been the most common way of transferring money for years (it launched in 2003) and payment using NFC has been the norm for a decade.
The mobile phone apps are probably just as bad, but e-transfers (Interac, EMT, whatever you want to call it) generally work pretty well. And they're still somewhat of a hassle compared to I guess Venmo or Cashapp or... I've never used those but they seem pretty slick in comparison to having to go into a banking app, set up an EMT Payee using email/phone number, set a password on the transaction, hope that they remember to cash the EMT before it expires, etc.
> When all your banks suck and Apple seems to be the only people with their shit together, sure but Australia doesn't live in that world.
ANZ was too busy charging dead people to bother implementing it. God only knows what westpac was up too, NAB had an implementation on Android, and having used it a bunch, it was _awful_ and I was glad when they gave up and just accepted the alternative. Combank did their own thing, and seemed the furthest along, but support seemed patchy and they ended up junking their solution anyways and going to Android/Apple pay anyways IIRC.
These places can hardly manage to maintain their own apps, I have about zero confidence in them deciding to wander off into the wilderness and trying again.
Not to mention, all the non-big-4, and all the smaller banks probably won’t bother with reimplementing NFC pay as they either don’t have the resources, or can’t rely on institutional-inertia to foist useless changes onto their customers.
The CBA Android app supports contactless, or you can add your card to the Google wallet. It seems to work equivalently well (although the enrolling bit has less friction in CBAs own app).
> […] we have essentially 4 big ones and they already are pretty cutting edge […]
The Big Four are not the cutting edge, it is a delusion. Out of four, only the Commonwealth Wank has transitioned onto a modern core banking platform for retail banking. Business accounts still run on the legacy core banking platform, if my understanding is current and accurate.
The remaining ones are as backward (from the technology POV) as they have always been. Westpac acquired St George Bank in 2008 trumpeting their core banking platform as the reason for the acquisition and the intention to transition onto it. To the best of my knowledge, that has not happened as of 2024, and Westpac contunues to use its own legacy core banking platform disjointly from that of St George's. Moreover, banking is not even integrated between the two even today, and the St George core banking has fell into a state of disrepair – EFT's can take a few days to reach the receipient's account depending on the receipient's bank.
The actual – pretty much only – innovator is Macquarie Bank that has invested a lot into revamping their banking platform from the ground up, plus neo-banks – newcomers to the banking market albeit niche ones.
The Big Four (or, most banks in general) loathe technology and IT as they see both as a liability, not a competitive advantage, due to tech not being their core business and due to being run by old farts with ossified brains. And that was the reason why they started rapidly losing millenials, Gen Z and other young customers to neobanks. It was a wake-up call for them.
> […] instant transfers are normalized […]
… and it has nothing to do with the Big Four. The Big Four, in fact, sabotaged instant payments for many years due to a lack of interest to advance the payment technology, and the instant payments in Australia only succeeded at the third (or at the fourth – I have lost the count) attempt after the Reserve Bank held the Big Four at a gunpoint and threatened them with severe penalties if they pull out again, as they had done every single time before. Instant payments in Australia are done via NPP/Osco, an independent company set up by the RBA, a BPAY subsidiary, and the Big Four as well as other local banks are mere users of it. None of the four control NPP/Osco payments, and that is a very good thing.
> If the NFC chips were opened up through regulation I have zero doubt Australian banks would just say "we support contactless with our first party app" […]
… and users would be left with the atrocious quality banking apps and with banks tracking the users all the way down into the customer's colons.
User tracking was the actual reason behind the spat between the Big Four and Apple – the former wanted to get a way into users' smartphones and all sorts of device and chip ID's – to track the user behaviour to which Apple said no. As a customer, Apple's stance suits me way more.
Of course, banks have found other ways to track the iPhone users courtesy of advances in the big data science, although the attempt has been somewhat hampered. The Big Four are the largest employers of data scientists and for a reason.
You can't be naive and look at the Big Four through the rose tinted glasses – they are in the business of making very big money and treat their customers as acquisition assets and cows to milk. Commonwealth Wank has been onselling the transaction information to Equifax (other than reporting the credit history), and Equifax has been onselling that transaction information to some pretty shady loan shark companies.
> and Westpac contunues to use its own legacy core banking platform disjointly from that of St George's
It's so difficult to do this stuff. I firmly believe they should just start a new tech-focused bank from the ground up, and transition customer to it gradually over the subsequent 10 years. Maintain 2 apps; shift to a new backend gradually. But I think it has to be in-house, and built with this in mind. Mergers don't work with banking tech.
Westpac has been saying just this week that their big transformation will be done in the next few years.
I've never worked in banking but having seen some other big transformation projects in my career, I'm not optimistic.
Samsung isn't even interested in Samsung Pay. I work at an FI, and have submitted an application repeatedly to integrate the SDK. We have yet to receive a response.
I use Samsung Pay in Spain. I like it because it's better integrated on my phone and more importantly I don't need a Google account for it. I don't even have one set up on my phone.
Of course Samsung does see my data this way but they have less info to correlate with. Also I don't use many of their services.
I do wish there was a truly open payment solution though that doesn't require me to trust a big tech party.
> I do wish there was a truly open payment solution though that doesn't require me to trust a big tech party.
Cash? Everything else needs a relying party of some kind in order to facilitate the transaction. If it's a credit card or digital wallet, the transaction passes through the credit card or debit card networks, and your info is logged and, depending on laws, potentially re-sold.
Don't get me wrong, I sometimes feel like Google shouldn't know my location either, but if my cell carrier already knows my location, I actually trust Google to not resell my location more than my cell carrier - it's worth more to Google if they're the only ones with that information and the same applies to Apple.
Another way of putting it, rules and regulations, strictly enforced and updated, is probably the only way to prevent tracking and abuse by legitimate big actors.
> If it's a credit card or digital wallet, the transaction passes through the credit card or debit card networks, and your info is logged and, depending on laws, potentially re-sold.
The reliance on credit card networks is part of the problem. There's no way to avoid them. And they're all from the US. This causes privacy issues but also moral problems because they tend to block sexually oriented products and services. In Europe a lot of countries are way more progressive than the US.
I was hoping bitcoin would become this system but obviously it's been completely hijacked by speculators and its original purpose of control of ones own money has been perverted.
There really should be a digital alternative for cash though. It's really silly that we still have to drag around pieces of linen and metal.
And no, I don't trust Google for anything at all. I don't want them making money off of me. I also block a lot of ads of course.
Debit cards don't all have to be processed through credit card networks, it's easier to do it that way. Websites could also take direct bank transfer payments if they felt like it, but it would hard internationally.
Apple didn’t create contactless payment infra in the US either. The contactless interface was already there, had its own logo, usable by tap cards, etc.
Some retailers eg CVS turned off tap payments when Apple Pay was introduced.
Where each bank had their own janky implementation inside their own specific app, which was both slower and had a worse UX.
Had a credit (a la Amex) that wasn’t from a major bank? Well womp womp no wireless pay for you.
I for one welcome the Australian banks getting put out to the curb on this. The Apple Pay/Wallet experience is genuinely better in just about every single way. I also enjoy the virtualised card number I get with Apple Pay, which I don’t believe any of the Australian banks bothered implementing, presumably because they were all too busy illegally charging dead people, and hiring corrupt ex state PM’s to build anything good.
The apps are bad, sure, but it was the banks who heavily pushed contactless EFTPOS terminals out to merchants in Australia. Without those, Apple Pay is a very cute curiosity on your phone, but I hope you remember your PIN because here comes the restaurant's dinosaur card machine. (Or worse, a click-clack card imprinter.)
Similarly a ton of retailers in the US hated what Apple did. They came in right as EMV was starting to be mandated and contactless was being installed everywhere, even if it often wasn’t on or working.
The banks and retailers all try to make their own thing that they work that way. CurrenC was one, it failed horribly and relied on people taking pictures of QR codes to transfer debit payments, thus avoiding card fees.
ApplePay can do debit also. But they didn’t push that. More “we don’t control it so it’s bad” nonsense.
Everyone along the payment food chain takes a cut so was always surprised that people thought Apple wouldn't. Especially when they are adding a value add on top.
And banks are free to drop Apple Pay. Customers will simply move their business to those who do support it. Just like happened when Apple Pay first launched in Australia and banks like Commonwealth Bank held out.
> 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)
For POS payments, usually only the device account number (DPAN) is shared with the merchant. Even the name is usually redacted, similar to contactless and as opposed to chip or magstripe payments.
All of the additional details mentioned in the article are only shared when you pay "online" – but that includes scanning a QR code on your phone and paying in Safari or an App Clip, which is something I've seen in a few restaurants these days.
That way, the restaurant gets as much as they ask for, which can include your name, your address, and your email address. I think this is usually displayed on the payment sheet, but it didn't really register for me the first time I used it in some restaurant. Now I make sure to ask the waiter for an actual terminal to tap or just give them my physical card.
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?
Just think of your phone like a plastic card. It's listening for the request from an NFT reader, at which point it beams out your 'card number', and that is that.
This took me a while to grok. I couldn't understand how Apple Pay could work when my phone was in Airplane mode. But of course it does! Your existing Visa card works just fine without an internet connection.
Fundamentally, they're the same thing. That's why, if everyone is playing by the standards, there's nothing extra to 'support'. See jjcm's sibling comment here. https://news.ycombinator.com/item?id=39846117
So I dare say the NFT reader isn't 'broadcasting' the amount to pay. Why would it be? Your plastic card had no way of dealing with that information. And so your iPhone has no way of receiving it, and telling the NFT reader to hold on a second while you swipe-to-accept.
> So I dare say the NFT reader isn't 'broadcasting' the amount to pay. Why would it be? Your plastic card had no way of dealing with that information.
Ah but it is, and it does :)
You see those four lights that are on contactless readers? I know they're mostly meaningless to laypeople and they more or less just flash in unison to the naked eye, but they show stages of the transaction progress, left to right.
There's a bunch of two-way comms going on there, including the transmission of the transaction amount, date/time, various transaction details, maybe a cryptographic challenge (nonce), and a bunch of other stuff I can't remember, from the terminal to your card.
Your plastic card has an active chip on it, it's not just a dumb NFC tag, it is powered by the field the NFC reader is giving off. It does send a bunch of data to the terminal on request as an early part of the process, then receives transaction data back, arranges it with some internal bits of its own, pads, hashes and encrypts it using a key (usually a session key derived from a stored private key) and sends back the resulting cryptogram to the terminal. In fact your card makes important decisions about whether to allow the transaction to proceed, based on the transaction data, various counters and limits it maintains, etc etc. If the card doesn't approve the transaction (and show that approval in its cryptogram), the terminal cannot approve.
You phone does the same stuff, but obviously without needing to use the power the reader puts out.
The problem with displaying the amount before you validate, is that it would interrupt the process and require running the transaction in two halves, and it would kill the "tap'n'go" aspect of the transaction. But the phone can immediately display the amount afterwards.
Incidentally, this sort of thing is why we have rules that the terminal must display the amount in a way that's visible to the customer, to be compliant.
> It's listening for the request from an NFT reader, at which point it beams out your 'card number', and that is that.
This is definitely not the case, and if it were the case, contactless cards would be trivial to clone!
It actually is most of the time, but it’s often a placeholder amount (some POSes let you tap before the check is finalized), so it’s too unreliable to display in the wallet directly.
The phone would also not have any way to verify if the terminal actually sent the payment online, causing confusion in case of having to tap again (that would then look like a double booking).
> Your plastic card had no way of dealing with that information.
You'd be surprised! Plastic cards can do all kinds of elaborate things, like deduct that amount from an offline transaction balance, replenishing that balance the next time it gets to talk to the issuer during a chip-dipped payment (assuming the card is still in good standing), update currency conversion rate tables used abroad, maybe even play doom – but probably not all of them.
> like deduct that amount from an offline transaction balance, replenishing that balance the next time it gets to talk to the issuer during a chip-dipped payment (assuming the card is still in good standing)
That deserves its own article. Where/why in the world would you need that!?
For offline support! Chip cards were introduced before internet connections were ubiquitous.
Some cards were even explicitly offline-preferring as long as there was any offline balance remaining to save on data transmission and processing bills.
There are even some fully offline chip systems around (where both terminal and card are mostly offline) that take the “offline purse” idea even further, but these are usually separate from the mostly account-based debit and credit schemes popular today, and are often getting phased out.
These days, cards are mostly online-preferring or even online only, with some merchants taking on the risk of accepting cards while offline.
Isn't it mostly obvious? Offline transactions are needed whenever a transaction is made without access to the internet. Like a train in the middle of nowhere or a flight.
Typically the POS just accepts the card, and then when Internet access is restored, sends them all out. So the merchant takes the risk of a customer using a bad card. But with smart functionality in the card, the card itself could make a determination of whether the payment should be approved.
> I couldn't understand how Apple Pay could work when my phone was in Airplane mode. But of course it does! Your existing Visa card works just fine without an internet connection.
If you set it as an express card, it also works if the phone is shut off or has a dead battery. (As long as it's not too dead.)
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.
[Update: Whoops, I was wrong about that. Matt Birchler, who works in the payments industry, has a great explainer about how this works, and it turns out major banks and credit cards do generate per-merchant “DPAN” numbers for tap-to-pay transactions. I stand by my argument that Apple Wallet is at least as, if not more secure than, any digital payment app provided by a card issuer.]
Yeah, Gruber is one of the most enthusiastic cheerleaders for Apple outside of Cupertino itself. It comes from a place of deep and abiding love, but he seems to see Apple kind of the way its internal culture also does — as a plucky upstart who has to fight for its very survival against all the big bad industry leaders (IBM and MS, originally). That viewpoint has become more and more absurd the larger and more dominant that Apple has got, leading us to this point where they want to argue that they should be able to simultaneously be an iron-fisted gatekeeper, and a purveyor of apps that “compete” with less-privileged apps on that same platform.
Gruber has always been an Apple fanboy, but in the past few months it's taken a turn into ragebait territory, and i'm this close to stopping reading it
How many things that most people ( within Apple Fans circle ) commonly believes that are plain wrong was started by him?
Apple invented USB-C and turned it over to USB-IF
The original AirPod was sold at cost.
These are the two I remember well, others including Modem, CPU, Unified Memory, and now Payment. Although arguably Payment doesn't count because he did admit he is wrong.
Basically Gruber and Daniel Eran Dilger from AppleInsider have similar traits, they have made their own conclusion and they derived their explanation backwards.
Gruber also lies about having invented markdown, which was actually invented by Aaron Swartz in 2002 (http://www.aaronsw.com/2002/atx/intro.html). Gruber just wrote a little perl script called Markdown.pl in 2004, but after Swartz's suicide in 2013, he pretended that he had come up with the whole thing, and has been using it to market himself ever since. Truly repugnant behavior.
Ah, now that I'm looking closer at the blog, it looks like a one-man MacRumors to me. Out of 21 blog posts this calendar year, all of them either appear to be Apple related, or they appear to be promoting his podcast, which is also about Apple.
>any digital payment app provided by a card issuer
from this line, it seems like the author here and gruber are kind of arguing beside each other. Birchler says that google and samsung pay work the same way. gruber says bank's own apps don't work this way. they can both be right.
does anybody here know if the payment apps operated by card issuers work this way? (or else, do card issuers actually have payment apps? my bank doesn't)
Many bank-specific wallets also use device account numbers. Storing full credit card numbers and the associated cryptographic keys on a device's application processor (like many wallets on Android do, both Google Pay and others) is a big no-go, and even for secure element based solutions like e.g. Apple Pay it's a big advantage being able to lock the number for a lost/stolen device server side without having to reissue the associated physical card and vice versa.
> do card issuers actually have payment apps? my bank doesn't
They've been somewhat popular regionally, especially in countries where Google took their time with rolling out Google Pay support in, or for regional payment schemes that aren't supported in Google Pay. (They're only possible on Android; iOS hasn't traditionally supported the necessary APIs, until very recently when the EU forced them, and still only offers them there).
I don't think they ever were a big thing in the US.
> I highly doubt any banks or credit card issuers would do this themselves if given access to NFC tap-to-pay.
Birchler points out that the banks did do this.
And Gruber has acknowledged his mistake.
Gruber is an open fanboi but for the most part he would at least get his facts straight and would be open about what he didn’t understand and would link to experts in the field.
However, since the EU DMA actions on Apple he seems to have completely lost his objectivity. First by pretending to understand the legalese better than apparently the EC does, then by applying American lawmaking approaches to European ones which are very different and then finally by taking Apple’s bad faith statements at face value (Gruber’s turn has coincided with Apple’s very weird bad faith approach to the EU so maybe the fundamental issue is his trust in Apple).
And he seems to be carrying over that to the U.S. govt’s antitrust action as well.
Also, to be fair, social media is absolutely filled with Apple people pretending to be legal experts but being completely wrong about almost everything. So it might be hard for him to even see opposing viewpoints from legitimate folks.
Gruber never pretends to be objective - he likes what he likes, and he dislikes what he dislikes. Notably, he has a pretty strong "pro-business" streak in him that objects to anything resembeling workers rights or unions, and government regulation/interference in businesses.
The EU tends to do a lot of that, so overall he's very critical of it. And at the moment there's a lot of governments telling Apple what to do, so it's the perfect storm of getting his knickers in a twist constantly.
I don't think I've seen him do opposition to workers rights / unions? He hasn't been constantly yelling about supporting them either, but that's different.
Closest to a negative I found in that quick search was him making fun of the Maryland Apple Store union that was asking to be allowed to request tips from Apple Store customers... while also saying that the rest of their demands sounded like good things to ask for.
Have you actually looked into the claims of the US case? Some of their statements are completely incorrect and they don’t even try to address what most commenters on HN seem to care about
He and Ben Thompson are very consistent. If the government wants changes in the way that Apple and other tech companies operate - pass laws - like they did in the EU instead of trying to make up definitions and facts based on a law that was passed almost 100 years ago
Yes I have. But that’s completely irrelevant because I’m not a lawyer.
Ben Thompson and Gruber are not lawyers.
Lawyers I’ve followed have not found any mistakes though they do think some stuff is pushing it, but that’s completely normal and how all such cases work.
You have a core case on which you add a bunch of stuff. Because, one, you expect stuff to get thrown out, but more importantly these cases are rarely litigated to the end. They’re settled. So you put more in, even the slightly weaker stuff, so you can compromise on it during negotiations.
I wouldn’t have know this stuff, which is why I don’t pretend to know this stuff. Unlike Gruber and Thomson. Instead I follow lawyers online and speak to friends who are lawyers who have a better idea of what’s going on.
The ridiculous part of Gruber’s assertions is because he hears about these things only when Apple is involved he seems to think they are unique or new. That’s why his insinuations in a couple of posts that the EU actions were to punish American companies and protect European ones. If he had half a clue about this area he would have known that the EU has fined way more European companies than it has companies from the rest of the world put together.
However, Andrew Sharp, Ben’s cohost on SharpTech was a lawyer and he also says that the judicial system is not the way to go and they should pass laws.
But you don’t have to be a lawyer to know the statements of fact are in correct as far as the technology.
They also condemned EUs ruling against Facebook where Facebook can’t even give users a choice of having an ad free experience by paying.
I have no problem paying money for stuff I want. I think that’s an honest transaction.
On Dithering, Gruber commended the EU for actually passing a simple law forcing Apple to open up NFC and the USB C mandate for iPhones instead of dragging it through some arcane legal doctrine. He didn’t necessarily agree with the law. But it was at least straightforward and honest.
But even if you aren’t a lawyer - the things that most HN users care about were not addressed at all in the lawsuit. For instance there is no mention of the App Store at all except concerning NFC, cloud gaming (that Apple has already addressed) and whatever apps are called with other embedded apps.
And no one in the Apple commentary community thinks the anti steering provision for Spotify and Kindle and Netflix etc is legitimate nor the former ban on cloud gaming.
Right now I’m listening to the Talk Show podcast with Gruber and Jason Snell (former editor in chief of Macworld) and they aren’t giving Apple a pass at all for the three items I mentioned
The fact that the DOJ may be able to win the case does not make an antitrust case like this the correct way to legislate how we want companies to operate.
It would be SO MUCH SIMPLER to just pass a law that says “sideloading has to be legal, easy, and free”. That’s all it would take.
Or maybe “all cell phones must support RCS.”
But not only have we not done that, the lawsuit against Apple for being a monopoly on the App Store was won by Apple. A court said they are legally in the clear. Apple already said they were adding RCS before this whole thing started.
So the DOJ has come up with a bunch of issues, some of which that don’t even seem relevant anymore, in an attempt to draw out concessions from Apple in a settlement to get what they couldn’t get through previous court cases. Or perhaps win a verdict and charge them a whole bunch of money for stuff that doesn’t matter all that much because again, some of the stuff they seem to be really mad about Apple already won on in another trial.
The DOJ is supposed to be about enforcement, not creating the laws. This is not how this process should be working. And as Gruber and others have pointed out, if you have to twist a bunch of hundred plus year-old laws to try to come up with a case to do something that could’ve been done with a single stroke of a pen… maybe that’s what you should’ve done instead.
I haven’t seen anyone saying who is arguing that Apple should 100% get out of all of this and they’re not doing anything wrong. Gruber and many others in the app world have been saying for years that Apple’s blatant greed is going to get them a smack down, and they’ll lose some of their good policies along with the bad.
People are arguing that the lawsuit doesn’t seem well-made and that it shouldn’t how the government accomplishes its goals in the first place anyway.
Laws like you propose tend to age poorly. RCS is incredibly consumer-hostile (e.g., there is no end to end encryption unless you use Google’s data-harvesting stack on both sides).
Similarly, requiring side loading could preclude new classes of devices.
Usually, the laws are written more vaguely for this reason. I think the big change we need to make is to say that anti-trust laws apply whenever N or fewer organizations control over X% of the market. I think N=3 and 75% would be good starting points.
Among other things, this would open up licensing and cell plans on 5G modems.
It would also mean that the google app store and apple app store both have monopolies over cell phone software resale and distribution.
(Google’s “android is open source and supports side loading” argument wouldn’t matter in such a regime, unless that meant that consumers and device manufacturers could reasonably expect degoogled android to actually run android apps and stuff, and that over a quarter of the market actually did so).
There was a court case against IBM over anti trust that started in 1969 and it was finally dropped in 1982 because the world has moved on.
One of the issues in the current case is already irrelevant - Cloud gaming that Apple has addressed.
Another issue was whatever you call the mega apps. Apple has allowed that for years and Microsoft, Google and Facebook all moved away from the mega app into smaller apps.
I think you should reconsider your judgement on the EU ruling being good.
If you can’t argue the EU ruling is bad (and not because Apple is greedy or shortsighted etc), you are missing something.
Apple has a vision - the EU has a vision and they do not align.
The EU is poor. It has been mismanaging itself for years: they should be doing better than they are. Is this caused by outside vectors or the leadership, or maybe the structure (too many cooks in EU kitchen)?
Is the vision of the world the EU wants 15-25 years out strong?
Is the world the EU would create good for the EU - 30 years out? I’d argue it’d be a comfortable one. But a poor and weaker one.
I’m not trying to defend Apple. I’m trying to say that the EU leadership is likely bad - my hunch is anyone truly good would work in the state department of the respective nation.
Kinda like how UN ambassadors for the US are never our best - our best maybe might once in a blue moon take the post like a retirement phase.
Now take the ruling, are you sure they made a smart long term move?
I don't know what "ruling" you're talking about. The DMA is a law, and it will be enforced despite Apple pretending to comply with it. There's nothing like a judicial proceeding as yet, much less a ruling.
This really underscores the point, and it's not just Gruber and random internet commenters opining on EU law while having zero clue about it, it's also Apple fans I respect like John Siracusa and Jason Snell who have a lot of opinions without familiarizing themselves with the facts.
Gruber had Jason as his guest on the last episode of The Talk Show, just to give some context to both of their arguments.
At the very least, they seem to agree that issues with the DMA - and the US DOJ case - stem from the idea that these lawmakers fundamentally misunderstand Apple's approach and why customers choose iOS, macOS, etc.
Tl;dr, the integration is the point and these legal challenges pose the idea that this approach doesn't comport with the law as written and should be disallowed.
1. The EU passed a law that was too complicated for its own good and...
2. Is a law that isn't practically enforceable
3. Lastly, is largely incompatible with how US public companies operate - welcome to Capitalism, it's how the world works...get used to it.
If market forces mean people either choose piracy to get what they want (Napster), that's one thing and regulation can help with that. However, the idea that you can't build a closed ecosystem that operates how you want - before you even get to shareholders in a public company - because this imposes restrictions on citizens, is a weird way to look at the world for a region that is - nominally - still capitalist.
> The EU is poor. It has been mismanaging itself for years: they should be doing better than they are. Is this caused by outside vectors or the leadership, or maybe the structure (too many cooks in EU kitchen)?
> Is the vision of the world the EU wants 15-25 years out strong?
> Is the world the EU would create good for the EU - 30 years out? I’d argue it’d be a comfortable one. But a poor and weaker one.
The EU vision isn't just about economy and making money. This is something that the US will never understand because money and unrestricted capitalism is the only thing that counts there. The US truly doesn't understand that any other model can work, because the only way they measure success is $$$.
Whereas we in Europe care more about quality of life, a safety net etc. Our bank accounts are a means to that end but not a goal in themselves.
Of course Europe is quite different depending on the area with Netherlands and the UK also very neoliberal but most of the other countries are way more moderate.
I often get this disconnect even with my Dutch friends. They don't understand why I won't move back to Holland as I could make twice as much there in the same role. But the cost of living is also higher and more importantly the quality of life is much lower. People in Spain truly enjoy life much more.
For example during lunch a Dutch person would have a quick sandwich at the canteen so they can head off home early and beat the traffic jam. They always want to have the prettiest house and the fanciest car and work hard for it. So hard they lose time to enjoy those things. In Spain we go for lunch to a restaurant to have a three course meal with a glass of wine and after work we often grab a beer or two and sit in the sun. Most of my colleagues don't even own a car.
I don't think "Spanish people get to be alcoholics" is enough proof that a system works where you need to have the same currency as a poorly run country like Greece or, at this point, Germany.
(Germans are psychotically high trust and seem to just believe anything anyone tells them, like "you should shut off all your nuke plants" or "Russians are really nice and it's fine to buy all your energy from them" or "you should sell your robotics companies to China" or "you should never ever run a budget deficit".)
It's not really about the drinks and many people don't have the wine or beer. I just included them as a way to describe the informal nature. At lunch we only ever have one (in France even the canteens serve wine, it's quite normal). And we don't do it every day :)
It's just about enjoying life being the primary goal, not amassment of material goods.
Yeah there's a very big difference between "Apple Pay does this" and "only Apple Pay does this". It seems like Gruber said the former, but the author somehow read the latter.
> 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.
In the US it was uncommon. Contactless payments had been supported in Europe and Asia for a while (2007 in the UK), though with fairly low limits at least in the UK.
Interestingly, it seems like the UK still has a £100 limit, while in the US I've paid well over $2000 with a contactless payment using my Android phone.
The UK's £100 limit only applies for using the actual card, if using a device to pay it's authenticated with your PIN or biometric and you can pay up to £10,000. If you look on the receipt you can see "cardholder device verified"
In Australia it seems like a credit card contactless is limited (was AU$100 or fifty quid if you like) but now might be more.
But the apple pay is way higher I have spent over $1k on it before. Probably because there is at least another layer of security which is a Passcode which is probably a better PIN than the credit card pin itself.
Australian also. I wish for the opposite, I’d like to be able to reduce the tap-no-pin limit down to $50 or so. I only use the physical card in rare emergencies, and increasing the times I have to enter my PIN by once or twice per year is hardly an inconvenience.
I believe when using apple pay with an apple watch, there's no longer a threshold where you need to use a PIN/passcode as the watch is using 'biometric authentication'.
There were one or two other things at the time but I think they were glorified autocomplete. I’m pretty sure there was a version of Google pay that didn’t filling stuff on the website, but I think it gave your real card number in the background somehow. Maybe only directly to the bank so the merchant didn’t see it, but it was still your real number.
Apple is the first one I remember hearing of that used DPANs.
Google Wallet (2011) was the first one, AFAIK, but the initial system also provided a "google" card working as "prepaid wallet", which made it less clear.
I think Capital One had virtual card numbers available before Apple Pay came out, but could be wrong about that. There were definitely a few neobanks offering it.
They did but that’s a bit different as while it’s not your real card number it’s not a tokenized payment in the background. It’s still just a PAN and security code.
For context, MST or magnetic secure transmission, allows a phone to transmit an EM signal that emulates the physical action of swiping a magstripe based card. As in, it works with all the legacy "card swipe" terminals. Samsung phones up to like the S20(?) supported this, allowing them to technically work basically everywhere with no integration needed.
It was I think the last major implementation to enter the market, with first one based on EMV standards being original Google Wallet (which was blocked by Google's typical inability to launch something globally).
USA is just, for various reasons, very very behind on things like card payment technology, to the point that visiting from Poland with card I used worldwide for years I had to first learn special workarounds so cashiers would know how to charge it.
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.
> Same for transit like OMNY in NYC. It tracks my virtual card enough to implement fare capping.
That's per DPAN, though. Capping doesn't work across devices (or people would just add their cards to friends' and family members' iPhones and split the capped fare).
There must be at least some truth to the fact that it makes the process more difficult. In Central Texas the most prominent grocery retailer by far is HEB, who has purposefully and intentionally not supported any sort of NFC payments, presumably because it somehow makes it easier to track people’s purchases over time by preventing NFC.
FWIW they are the only holdout. You can pay with NFC at Walmart, Costco, gas stations, regular retail outlets, etc almost anywhere else in Central Texas. HEB absolutely sticks out like a sore thumb in their lack of NFC support. And it’s not that they aren’t tech savvy - they own and maintain an Uber-Eats like app here called Favor that works pretty well. They clearly understand technology
I wouldn't be surprised they'd just completed an infrastructure upgrade that didn't support NFC prior to it's growth in popularity and now they're unwilling to pay that upgrade toll all over again. But that's just pure uninformed speculation on my part.
I might be wrong but they are acutally differnt CC numbers, with the prefix linked to ApplePay, and then they resolve or proxy to your acutally CC.
You can use NFC Sniffers like the Flipper to see this in action.
Same how ApplePay on the watch works without network, cuz it has already preset the AppleCC prefix on ur watch, and its just emulating that AppleCC to the card receiver.
You'll get every time the same card number, with said card being specific to the device. So they will be able to track that the same buyer is doing the purchase, which is what most POS-based analytics are interested in.
Way more important is the (sometimes filtered) dump of everything on your bill that is passed on to various corporations (Nielsen, sometimes direct to suppliers), and how in-store analytics then build data at neighbourhood or per-store level.
Store analytics need not know that specifically "WirelessGigabit" bought something, store analytics is more interested in "we have repeated customers with such and such spending and purchases" and "in this zip code we have this kind of population with associated types of buyers" and "This is how much people are buying certain products and when, so that suppliers can plan campaigns and production"
> 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.
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".
To continue to use the example of Capital One, you can use their virtual cards with digital wallets; the point is to demonstrate that this is neither a new capability nor something that is exclusive to digital wallet apps.
Cashiers in brick and mortar stores can enter card details manually. You've never had a card reader break and then had the cashier have to type it in by hand?
I have never convinced a cashier to use digits provided by me or off my phone screen. That is fundamentally different from getting them to manually enter a card.
But I understand you’re making irrelevant bad faith comments, because you’re too weak to admit that you were wrong about something unimportant.
They can but they generally won’t. Use of the chip on the card shifts fraud liability from merchant to issuer. Burner card numbers are for card not present transactions.
Sketchiness aside, the fee a merchant pays is different based on the capture method to incentivize using more secure methods. The bank, payment processor, and the merchant know how a PAN was processed.
It’s usually only done when the card reader isn’t working with the particular card. For example back in magstripe when it was the magnetized or if there’s a problem with the chip these days and magstripe fallback fails or the device doesn’t support stripe reading.
>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.
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
> 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.
> 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.
Ah, so it's the integration with issuer banks in the background that requires a lot of effort. That makes sense!
Thanks so much for enlightening me! :)
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.
I've had similar issues at many other merchants
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.
Do their readers do contactless payment at all?
US-based here...
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 can confirm Home Depot accepts tap of physical cards as well as Apple Pay in Canada.
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.
He saying there's no difference between a standard contactless plastic card and using the phone.
I can pay contactlessly with my card, but my bank doesn't support paying with my phone.
My point is that Apple Pay works wherever contactless cards are accepted, but yes, not all card issuers offer Apple Pay in the first place.
> actually breaking Apple Pay/Google Pay support needs a lot of destructive energy on the merchant's/PSP's side.
They do bank whitelisting, not protocol breakage.
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.
Google Pay still supports proxy cards today through PayPal. Only applicable to the US and Germany though.
That’s Paypal providing proxy cards for use in Google Pay though, not the other way around. Curve does that too.
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).
> cashiers expecting to be handed over your card
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.
Fair enough, t̶h̶e̶ ̶t̶e̶r̶m̶i̶n̶a̶l̶s̶ ̶o̶r̶ ̶b̶a̶n̶k̶s̶ ̶m̶u̶s̶t̶ ̶h̶a̶v̶e̶ ̶l̶i̶m̶i̶t̶s̶ ̶t̶h̶a̶t̶ ̶d̶e̶p̶e̶n̶d̶ ̶o̶n̶ ̶t̶h̶e̶ ̶C̶V̶M̶ ̶t̶h̶e̶n̶,̶ ̶b̶e̶c̶a̶u̶s̶e̶ ̶t̶h̶e̶r̶e̶ ̶a̶r̶e̶ ̶d̶e̶f̶i̶n̶i̶t̶e̶l̶y̶ ̶h̶i̶g̶h̶e̶r̶ ̶l̶i̶m̶i̶t̶s̶ ̶f̶o̶r̶ ̶p̶h̶o̶n̶e̶ ̶p̶a̶y̶m̶e̶n̶t̶ ̶c̶o̶m̶p̶a̶r̶e̶d̶ ̶t̶o̶ ̶c̶o̶n̶t̶a̶c̶t̶l̶e̶s̶s̶ ̶c̶a̶r̶d̶s̶
(edit: forgot cards and devices can have their own limits, best ignore this comment)
I thought apple/google only verified payments up to a limit (ever increasing) of e.g. £500/£1000 based on the biometrics? Is that right?
Thanks so much!
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.
Good info here https://blog.bytebytego.com/p/ep25-how-applegoogle-pay-handl...
This is not an ELI5, but it is all the details:
https://www.emvco.com/emv-technologies/payment-tokenisation/
EMVCo is American Express, Discover, JCB, Mastercard, UnionPay and Visa. It’s basically a credit card standardization group.
> 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.
Thanks so much!
> "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.
It’s randomised in a similar way to how iOS creates privacy MAC addresses for each WiFi SSID.
The merchant receives the same ‘random’ card number for transactions from the same device.
The device card number (DPAN) is static after adding a card to a given device. It doesn’t change between transactions or merchants.
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.
Some references: https://support.apple.com/en-au/HT203027 https://developer.apple.com/documentation/passkit_apple_pay_... https://support.apple.com/en-au/guide/security/secc1f57e189/...
> 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 3DS enabled cards, 3DS is optional. Unless you mean 3DS-mandatory cards.
> 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.
I'm not sure, because I haven't been to the US in more than ten years. Last year in Canada everything worked flawlessly
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.
Do the chip / paywave payments with the physical card also use a DPAN generated for that card, or do they use the FPAN that's embossed on the plastic?
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.
Ahh, that makes sense - in fact I just used a credit card to pick up linked online Shinkansen bookings from the JR-West ticket machines.
(Those systems all seem to use either magstripe or chip though, so maybe the wireless transaction could still use a different one, in theory).
have you read the actual article?
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.
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.
Sharing a personal anecdote - when Apple Pay first launched, it only worked in the US. A more accurate statement though was it could only be set up in the US. I very shortly after moved to Australia, where tap-to-pay is the standard.
It was kind of crazy because despite not officially being supported, Apple Pay worked everywhere in Australia. Whereas only a small handful of merchants supported it in the US, 99% of point of sales in Australia supported it because it was based off the standard.
This also worked in reverse. When I was visiting the USA, when I tapped my credit card to pay on terminals that were seemingly set up for Apple Pay, it was mind-blowing for some people. I didn’t realise contactless cards were so rare over there at the time.
I had a similar experience. After it was released in the US, I took a trip to the Netherlands. I had a lot of “how did you do that?” reactions from merchants when I paid for things with my phone.
Depends on country, and how contactless cards being the norm in many places meant there was less push among people for payment with phones, compared to USA where it seems it no modern bits for card payments happened between introduction of magnetic strip and phone-based EMV2 NFC payments.
I remember changing card ~2012, in Poland, because my ancient Visa Electron with magstripe-only was confusing to new cashiers who thought lack of chip meant it's contactless. Around that time phone-based "cards" were also widely promoted though the tech wasn't exactly ready yet so you needed cooperation between banks and telcos to provide secure element.
I had the same experience as you on a trip to the Netherlands. Ironically, the only place where it didn't work was the Apple store in Amsterdam. I don't know if that was an actual technical limitation, or they were aware that it was not yet available in the Netherlands and so didn't even let me try with my phone and its US credit card.
I had a similar experience traveling in Europe! More than one merchant thought I had “hacked” them initially.
Same, I used Apple Pay in Germany before it was officially launched there and people were very surprised that I could just pay with my Watch. Contactless payment was already becoming more prevalent, so it worked in a lot of places.
It was standards based, but the way Apple ran the launch and marketing (kind of genius, actually), they gave the impression that Apple Pay was the only phone-based tap-to-pay around. Merchants would have signs saying "Apple Pay accepted" but not mention Google, leading to confusion over whether non-Apple payments would work.
Part of that is definitely the confusing state of payments on Android. Samsung Pay could refer to either NFC or magstripe-emulation. Google, of course, is terrible at branding stuff, and between Wallet and the many iterations of Google Pay it's still difficult to figure out what's what.
> Samsung Pay could refer to either NFC or magstripe-emulation
Last time I checked, you've got to swipe a magnetic-stripe card (we mainly use C&P/contactless). Unless there's some really cool sci-fi pop-up plastic tab inside the phone / case / a separate re-programmable card, I'm really curious as to how this could work?
I haven't been able to find a detailed explanation of how it works. Somehow it emits a magnetic pulse that simulates the card being swiped, without having to physically swipe the card. Best guess is that it uses some kind of magnetic induction to induce a current in the reader the same way that a swipe would.
I never had a Samsung phone so I can't comment on how it worked in practice or the reliability. Can't find any mention of having to hold your phone a particular way so presumably it's direction-independent, although apparently sometimes it might not be possible to hold your phone close enough for the reader to pick it up.
https://en.wikipedia.org/wiki/Magnetic_secure_transmission
The funniest thing to me is how people forget that Apple Pay was late addition to mobile payment game. Practically the last one to enter the market.
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-...
I would never expect anything to get more private ever again short of acts of government.
Try reading the book Seeing like a State
Not true in Japan, Apple Pay uses anonymous ICOCA (aka Suica) cards which you can delete and recreate if you want.
This is a very weird understanding of what IC cards are in Japan.
Yes, Apple Pay supports them, and they're ephemeral and easily recreated, and semi-anonymous; but Apple Pay over here absolutely still supports "regular" cards here.
And you can't use your IC card for online purchases, which is most of the article was about anyway.
> Yes, Apple Pay supports them, and they're ephemeral and easily recreated, and semi-anonymous
…so what I said, yes.
> but Apple Pay over here absolutely still supports "regular" cards here
But you don't have to use em.
Strange interaction here: you can refill Suica with a foreign credit card, there is no transaction fee for it, and it means you can turn anything you can purchase via IC card into 5x travel spending with the right card.
Maybe it's a non-native speaker thing; but for me when you says "Apple Pay uses XYZ here"; it implies exclusivity, that it underpins the whole system; not that it's one of the available option.
I can see now that's not what you meant.
> But you don't have to use em.
You do, if you want to use it over the internet. You and I might have a good grasp of what IC cards here are; but your comment without that knowledge can be misleading.
> it means you can turn anything you can purchase via IC card into 5x travel spending with the right card.
As long as nothing you buy costs more than 20000 JPY ;)
Sure, you can also add some anonymous prepaid/gift cards to Apple Pay, but my point is that Apple Pay does not add any privacy/anonymity beyond that of the underlying card, contrary to what some people seem to still believe.
The PAR was introduced after Apple Pay (and in a way in response to it and other wallets), and some people might have missed it.
> (and aspirationally even across card number changes on the same underlying account).
My local Australian bank (NAB) does this. I imagine it's pretty normal across most credit cards here.
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.
> hen 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.
They're not generally considered stable in the payments world. They can get rolled periodically, even outside of card addition and removal.
In Apple Pay they are sort of static. Not per merchant, but they don’t cycle by default for any reason. I believe there is a button you can press to have the number changed. I think I’ve seen it before but I’ve never used it.
And of course you could always just remove your card and then re-add it. That would give you a new DPAN.
> I believe there is a button you can press to have the number changed.
That's for the Apple Card's virtual card number, which is just a regular old PAN. There is no such button for the DPAN, to my knowledge.
Ah you’re right, I got those confused.
Thanks.
Different PANS doesn’t make a difference when your bank is selling your credit card data anyway.
It makes a difference for credit card thieves. Not for transaction list privacy.
As long as your bank is involved you’re just going to have to put up with them and trust them.
Credit theft affects the banks and merchants. They are out of the money not me. Its for their benefit. I just suffer the inconvenience of getting a new card.
I noticed that the last 4 digits of the card used with Apple Pay is different every time I pay (I use my Apple Watch mostly). Not use between merchants but also with the same merchant.
Are you sure you're not mixing up phone and watch payments? And is this with a Mastercard or Visa card, or something region-specific?
The DPAN has always been constant in many years of using Apple Pay for me, which is useful to e.g. check which card I've actually used on by comparing the last four digits printed on a receipt to those I can see on my phone or watch (the card details show both the funding and the DPAN last four digits).
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
I believe what you're looking for for SSO is RFC 7591[0], which describes how to register with an oauth IdP on the fly. RFC 8414[1] describes well-known locations to get metadata about the registration process. So the standards are there, and in theory you could have a login form where e.g. someone types their email (or the browser autofills it), and that kicks off an oauth login to that domain, doing client registration on the fly if the server has never talked to that domain before. I've never seen it in the wild though. Would be nice.
[0] https://datatracker.ietf.org/doc/html/rfc7591
[1] https://datatracker.ietf.org/doc/html/rfc8414
I think tailscale supports exactly that? You give them your email address and they check the web finger endpoint of the domain for your configured SSO provider. https://tailscale.com/kb/1240/sso-custom-oidc
Because of "growth & engagement". Somewhere around 2010, technology shifted from being a tool to empower the user to a tool to waste the user's time with spam. Things shifted from offering a service and collecting a fair fee to spamming the user or collecting their data (so it can be used to further spam the user down the line).
An open standard isn't something any of the current providers want since otherwise users can easily substitute them with different alternatives and no longer "engage" with them.
Because user verification varies significantly between businesses, and so they need to vet and trust SSO vendors to uphold the standards they require. If there are a million sso vendors, who knows what standards each upholds.
You could say the same thing about email registration, but people generally don't restrict email-identified accounts to one of 3 providers.
The difference is that you can be reasonably sure that an email will be delivered to the user's address that they specified, and there is a common understanding that sharing your email credentials will result in immediate financial loss. The communication is out-of-band, as SMTP is not an authentication protocol, so the user must perform some affirmative action (such as clicking a link in the email) to authenticate the request.
With SSO, the claim that a user is authentic lies completely with the provider. If there is a bug in the implementation, a user could be authenticated when they should not be, and the actual account owner may never even be notified that such an authentication occurred.
With oauth/oidc, the service that's requesting the token doesn't even specify the username. What would the IdP send back if the user is not authenticated? The concern is it will just issue a token for a random user? Or that someone will break into another account on the IdP's login form?
I don't see any difference with email besides convenience. If an email provider has a bug, they might allow someone else to read your email and click the link without any notification to the actual account owner that such an authentication occurred. In fact, if a provider has oauth and webmail, the two probably use the same authentication system (e.g. they use the same session cookie and login form, or the webmail might use the oauth service as its auth). Even native email clients are using oauth these days. This is a good thing. It lets you store a token with limited permission in your email client instead of storing a password for SMTP that also gives you full permissions to everything the account can do.
Also most oauth implementations I've seen actually do have a dashboard in your user settings where they record which services you've provided tokens to, and what scopes those tokens have.
If you're worried about CSRF, that's what the state parameter is for, and it's the consuming service that needs to use it appropriately, so you don't need to worry about whether the IdP did it right. If the IdP gives the wrong state back, the login will fail when your service checks it.
To support "Login with Google" you have to do some config on the Google side. You have to tell them, this ils my app, this is the URL you have to redirect back to after authenticating, and do on. Otherwise there would be security problems.
Because it’s both a pain in the ass and a magnet for fraud.
Stackoverflow encouraged openid from anywhere and it created problems.
Why do we need SSO?
Passkeys seems perfect to me. Easy sign on anywhere I sign up. No central whoever that knows every time I log in anywhere.
Passkeys are great(-ish) for authentication, but don't offer identification at all.
It's just not in scope (and I think that's a good thing; the two problems are pretty different, and WebAuthN is already extremely overloaded with features serving conflicting goals).
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.
Amusingly, all the Australian banks asked the ACCC for permission to form a cartel and collectively bargain with Apple on Apple Pay terms. They were denied.
https://www.accc.gov.au/media-release/accc-denies-authorisat...
Antitrust usually makes it impossible for smaller companies to combine their market power against the market power of a bigger company.
> 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
Not if the users have anything to say about that.
Canadian banks tried to do their own contactless payment on Android (TD Pay, lol), but nobody wants it. In the end they caved and finally offered Google Pay.
I predict it's gonna be similar. Even if Apple opens up NFC payment, nobody will use them and prefer 1st party support like Apple Pay or Google Pay.
Just see how many people actually use Samsung pay vs Google Pay.
To be part of Apple Pay, banks have to enter into an agreement with Apple. Though the details of this agreement are generally confidential, it's fairly well known that there is an Apple cut, and that that cut is rather high. (It's Apple!)
The moment a bank has the option to extract itself from this arrangement, it will. Not just because there's absolutely no reason to give Apple a cut of the bank's own business if the bank doesn't need to, but also because the bad blood between Aus banks and Apple is very real at this point.
> Even if Apple opens up NFC payment, nobody will use them and prefer 1st party support like Apple Pay or Google Pay.
And since that costs the bank money, it won't be an option. Also, I think the bank would think of itself as a first party in a payment made using their card, and Apple as a parasitic third party.
I'm not saying people won't grumble, but there is no way - unless Apple actually makes Apple Pay somewhat attractive to banks - that the banks will continue to support it if they don't absolutely have to.
(I'm not siding with the banks on this, I'm just trying to lay out their logic.)
I think it's just different math.
The 15 basis points Apple supposedly charges for with card payments from Apple Pay is meant to come from the fraud budget; that a biometric-based authentication is consider both more secure and easier to counter payment disputes. The rest comes from the convenience and hope that actually results in more card payments.
In the US where there's no PIN, fraud is high. Parts of the country are still heavily cash based, so there's a good margin to gain if added convenience results in more card payments.
For heavily credit card based markets with chip-and-pin, you have less fraud concerns and less to gain from convenience.
My take though is that even if apple opens up the NFC chip, they aren't opening up the Secure Enclave. So even if a bank app can take over the NFC chip, they still will have secrets in memory at some point without a new P-256 based payment protocol.
Unless this is a new app backed by a bank cartel, you'll also go from being able to use multiple cards to just one first-party card.
This all leads to my opinion of a pretty wonky situation - opening NFC up probably increases the value of Apple Pay, since it can now be compared to other software-based wallets by users, and Apple Pay support again becomes a differentiator for the payment card.
> My take though is that even if apple opens up the NFC chip, they aren't opening up the Secure Enclave. So even if a bank app can take over the NFC chip, they still will have secrets in memory at some point without a new P-256 based payment protocol.
The NFC chip is itself a secure enclave. (It's called a "secure element" but same thing.)
It does its own key storage, which is why it can work when the phone is turned off.
> Unless this is a new app backed by a bank cartel
Good news - they've already got the cartel ready to go, and it's conveniently already in bed with the regulators! See https://en.wikipedia.org/wiki/BPAY & https://en.wikipedia.org/wiki/New_Payments_Platform
> This all leads to my opinion of a pretty wonky situation
Yep, that's sadly accurate for all the banks' other tech, so I see no reason they'd shy away from it here either.
I feel like you're coming at this from the wrong angle. No one is saying Apple Pay is bad, or that the banks' solutions will be better. The question is: will banks voluntarily give up a cut to a third party intermediary, when they can roll a slightly-less-convenient-but-good-enough tech stack and keep all the money for themselves?
One doesn't exactly become a top 4 bank by handing out a cut to intermediaries willy nilly. Even if the Apple cut were eliminated (unrealistic), the banks would need a very good reason to allow an intermediary between themselves and their customers at all.
The NPP is about removing the Visa/MC networks from the equation. It would also remove the EMV requirements, if I'm identified by my mobile phone number + biometrics linked to a bank account, which can have it's own credit line associated with it, why does the bank need to support Visa/MC?
The new payment platforms with instant settlement effectively remove the branding and merchant agreements that Visa/MC offer.
Person A can transfer money to Merchant M immediately, no intermediaries except the two banks/account provider and the payment platform usually run by the central bank.
Apple should buy a bank and compete on their own turf
Owning a bank is an extreme regulatory headache. You always want someone else to be the bank. Or even better multiple someone elses - in the US, small banks are allowed to do things large ones aren't, so you sometimes gather up a bunch of them and become a single proxy for them.
They probably won’t do that in the current antitrust climate. I hope the DOJ and the EU continue probing the big companies because I’m sick and tired of my non-ecosystem device choices not working well together.
Why would they want to be involved in a highly competitive and low margin business like consumer credit?
What if an alternative is cheaper?
customers end up paying in the end.
edit: in the end. I guess the place I notice it is paying for gas - see the cash vs credit price always shown on the sign.
It is pretty easy to add up when you're spending $100+ on gasoline.
but this affects everything we buy, just hidden.
> customers end up paying in the end.
Not in a transparent way, generally speaking. And at least in Canada you couldn't even (as a business) add a credit card surcharge to a purchase price. Now you can, so long as you're simultaneously complying with the legislation (https://www.canada.ca/en/financial-consumer-agency/services/...) and your contract with your payment processor (e.g. https://www.visa.ca/content/dam/VCOM/regional/na/canada/Supp...).
Apparently, too, merchants aren't actually charged for Apple Pay, it's the banks themselves that are. Merchants apparently pay the regular charge to their payment processor whether I use my Visa-through-Apple Pay or my Visa as a physical card. https://paymentdepot.com/blog/apple-pay-fees-for-merchants/
At any rate, Apple Pay is ridiculously convenient compared to anything my bank has ever come up with. The last time there was a Pay With Bank $X thing on a website that I tried, I ended up getting directed through some kind of Verified by Visa thing where they were asking for some kind of security code that I don't recall ever setting up. Or... I can double-tap the power button on my phone to verify a payment I'm making on my laptop. If the banks are unhappy about giving a cut to Apple, my recommendation to them would be: Suck Less.
> Not in a transparent way, generally speaking
There are ways to get around that.
For example, a bank could offer partial rewards for using their payment system, over Apple's. The effect would be the same as passing on the savings to the consumer.
Given the software that banks generally produce, it’d have to be a sufficiently good reward. If I’m buying a $10 sandwich at a deli counter, I’m going to double tap my power button and tap my phone on the debit machine. A $0.03 cash back isn’t worth the hassle to fish around to find my bank’s app, enter a secure password, and then enter a 2FA code. I had another comment elsewhere in this thread: want me to use the bank app instead of Apple Pay? Make the bank app suck less.
I don’t get charged for using Apple Pay, I get charged for the processing fee for the card I used (which is an entirely separate discussion), and given the option between “just continue using Apple Pay” or “download several janky apps just because the bank wants its own wallet impl”, I’m going to stick with Apple Pay.
The Apple Pay take is 15 bps, which is not a difference customers care about enough to change behavior even slightly.
I don't pay anything extra for using Apple Pay, as a customer, how could it be cheaper?
If Apple is getting 0.15% as stated in a sibling, it's coming from somewhere. Maybe it's added on top of the fees the merchant pays, and like other payment fees gets kind of mixed into the price of everything you buy. Maybe it comes out of the fees your bank gets on purchases, which will reduce their income and then they'll need to increase fees, reduce benefits for depositors, or reduce dividends to investors.
Yeah, I have no interest in keeping 15 digital wallet apps, even if they offer incentives, for the same reason I don’t carry a physical wallet for each physical card.
Now I could see an argument for wallet apps being generic so e.g. the apps for Chase, BofA, SoFi, etc could carry all the user’s cards like Apple/Google wallet should the user want that, but I doubt banks would have much interest in that (at least if it’s privacy respecting and not skimming transaction history) because it’s not prying mindspace away like per-provider apps do.
It should be assumed that if the banks get an opportunity to implement their own NFC payment system on iPhone, they’ll switch off Apple Pay. Otherwise no customer would have any incentive to migrate over. And the incremental cost of Apple Pay is too little to be redirected towards some customer incentive program.
(Of course that doesn’t preclude a bank from making an irrational decision.)
Eh, maybe not in Australia. Remember Australia doesn't have like 5 million banks, we have essentially 4 big ones and they already are pretty cutting edge vs US/Canadian banks. i.e instant transfers are normalized, NFC is the norm, apps and Internet banking have been very good for about 10 years.
If the NFC chips were opened up through regulation I have zero doubt Australian banks would just say "we support contactless with our first party app" and that would be the end of that until Apple asked for a more reasonable cut.
When all your banks suck and Apple seems to be the only people with their shit together, sure but Australia doesn't live in that world.
Canada has essentially 6 big banks, instant transfers using Interac has been the most common way of transferring money for years (it launched in 2003) and payment using NFC has been the norm for a decade.
Heh ok, sorry for assuming Canada would be as bad as the US.
The mobile phone apps are probably just as bad, but e-transfers (Interac, EMT, whatever you want to call it) generally work pretty well. And they're still somewhat of a hassle compared to I guess Venmo or Cashapp or... I've never used those but they seem pretty slick in comparison to having to go into a banking app, set up an EMT Payee using email/phone number, set a password on the transaction, hope that they remember to cash the EMT before it expires, etc.
> When all your banks suck and Apple seems to be the only people with their shit together, sure but Australia doesn't live in that world.
ANZ was too busy charging dead people to bother implementing it. God only knows what westpac was up too, NAB had an implementation on Android, and having used it a bunch, it was _awful_ and I was glad when they gave up and just accepted the alternative. Combank did their own thing, and seemed the furthest along, but support seemed patchy and they ended up junking their solution anyways and going to Android/Apple pay anyways IIRC.
These places can hardly manage to maintain their own apps, I have about zero confidence in them deciding to wander off into the wilderness and trying again.
Not to mention, all the non-big-4, and all the smaller banks probably won’t bother with reimplementing NFC pay as they either don’t have the resources, or can’t rely on institutional-inertia to foist useless changes onto their customers.
The CBA Android app supports contactless, or you can add your card to the Google wallet. It seems to work equivalently well (although the enrolling bit has less friction in CBAs own app).
> […] we have essentially 4 big ones and they already are pretty cutting edge […]
The Big Four are not the cutting edge, it is a delusion. Out of four, only the Commonwealth Wank has transitioned onto a modern core banking platform for retail banking. Business accounts still run on the legacy core banking platform, if my understanding is current and accurate.
The remaining ones are as backward (from the technology POV) as they have always been. Westpac acquired St George Bank in 2008 trumpeting their core banking platform as the reason for the acquisition and the intention to transition onto it. To the best of my knowledge, that has not happened as of 2024, and Westpac contunues to use its own legacy core banking platform disjointly from that of St George's. Moreover, banking is not even integrated between the two even today, and the St George core banking has fell into a state of disrepair – EFT's can take a few days to reach the receipient's account depending on the receipient's bank.
The actual – pretty much only – innovator is Macquarie Bank that has invested a lot into revamping their banking platform from the ground up, plus neo-banks – newcomers to the banking market albeit niche ones.
The Big Four (or, most banks in general) loathe technology and IT as they see both as a liability, not a competitive advantage, due to tech not being their core business and due to being run by old farts with ossified brains. And that was the reason why they started rapidly losing millenials, Gen Z and other young customers to neobanks. It was a wake-up call for them.
> […] instant transfers are normalized […]
… and it has nothing to do with the Big Four. The Big Four, in fact, sabotaged instant payments for many years due to a lack of interest to advance the payment technology, and the instant payments in Australia only succeeded at the third (or at the fourth – I have lost the count) attempt after the Reserve Bank held the Big Four at a gunpoint and threatened them with severe penalties if they pull out again, as they had done every single time before. Instant payments in Australia are done via NPP/Osco, an independent company set up by the RBA, a BPAY subsidiary, and the Big Four as well as other local banks are mere users of it. None of the four control NPP/Osco payments, and that is a very good thing.
> If the NFC chips were opened up through regulation I have zero doubt Australian banks would just say "we support contactless with our first party app" […]
… and users would be left with the atrocious quality banking apps and with banks tracking the users all the way down into the customer's colons.
User tracking was the actual reason behind the spat between the Big Four and Apple – the former wanted to get a way into users' smartphones and all sorts of device and chip ID's – to track the user behaviour to which Apple said no. As a customer, Apple's stance suits me way more.
Of course, banks have found other ways to track the iPhone users courtesy of advances in the big data science, although the attempt has been somewhat hampered. The Big Four are the largest employers of data scientists and for a reason.
You can't be naive and look at the Big Four through the rose tinted glasses – they are in the business of making very big money and treat their customers as acquisition assets and cows to milk. Commonwealth Wank has been onselling the transaction information to Equifax (other than reporting the credit history), and Equifax has been onselling that transaction information to some pretty shady loan shark companies.
> and Westpac contunues to use its own legacy core banking platform disjointly from that of St George's
It's so difficult to do this stuff. I firmly believe they should just start a new tech-focused bank from the ground up, and transition customer to it gradually over the subsequent 10 years. Maintain 2 apps; shift to a new backend gradually. But I think it has to be in-house, and built with this in mind. Mergers don't work with banking tech.
Maybe they're already quietly doing this.
Westpac has been saying just this week that their big transformation will be done in the next few years. I've never worked in banking but having seen some other big transformation projects in my career, I'm not optimistic.
In Switzerland, the banks' own system, Twint, has been and still is a massive success.
To be fair, samsung pay is only avaible in like 10(?) countries.
But yeah, point still stands
Samsung isn't even interested in Samsung Pay. I work at an FI, and have submitted an application repeatedly to integrate the SDK. We have yet to receive a response.
I use Samsung Pay in Spain. I like it because it's better integrated on my phone and more importantly I don't need a Google account for it. I don't even have one set up on my phone.
Of course Samsung does see my data this way but they have less info to correlate with. Also I don't use many of their services.
I do wish there was a truly open payment solution though that doesn't require me to trust a big tech party.
> I do wish there was a truly open payment solution though that doesn't require me to trust a big tech party.
Cash? Everything else needs a relying party of some kind in order to facilitate the transaction. If it's a credit card or digital wallet, the transaction passes through the credit card or debit card networks, and your info is logged and, depending on laws, potentially re-sold.
Don't get me wrong, I sometimes feel like Google shouldn't know my location either, but if my cell carrier already knows my location, I actually trust Google to not resell my location more than my cell carrier - it's worth more to Google if they're the only ones with that information and the same applies to Apple.
Another way of putting it, rules and regulations, strictly enforced and updated, is probably the only way to prevent tracking and abuse by legitimate big actors.
> If it's a credit card or digital wallet, the transaction passes through the credit card or debit card networks, and your info is logged and, depending on laws, potentially re-sold.
The reliance on credit card networks is part of the problem. There's no way to avoid them. And they're all from the US. This causes privacy issues but also moral problems because they tend to block sexually oriented products and services. In Europe a lot of countries are way more progressive than the US.
I was hoping bitcoin would become this system but obviously it's been completely hijacked by speculators and its original purpose of control of ones own money has been perverted.
There really should be a digital alternative for cash though. It's really silly that we still have to drag around pieces of linen and metal.
And no, I don't trust Google for anything at all. I don't want them making money off of me. I also block a lot of ads of course.
> The reliance on credit card networks is part of the problem. There's no way to avoid them. And they're all from the US.
JCB is Japanese, not sure what countries it has issuing banks in; it no longer issues in the US, and US acceptance is through Discover.
There's also a lot of country specific debit/atm networks (including several in the US), if you are ok with debit over credit.
Debit cards don't all have to be processed through credit card networks, it's easier to do it that way. Websites could also take direct bank transfer payments if they felt like it, but it would hard internationally.
You should read Samsung's privacy policy.
Banks want another Interact.
Apple didn’t create contactless payment infra in the US either. The contactless interface was already there, had its own logo, usable by tap cards, etc.
Some retailers eg CVS turned off tap payments when Apple Pay was introduced.
https://www.apple.com/newsroom/2024/01/apple-announces-chang....
I remember pre-Apple pay when banks like NAB offered an NFC sticker you attached to the back of your phone as a “look, just as good as Apple Pay”
Apple strangling the payment API and the App store at the same time is anti-competitive, but as long as noone cares..
Ah yes, the Australian bank impls.
Where each bank had their own janky implementation inside their own specific app, which was both slower and had a worse UX.
Had a credit (a la Amex) that wasn’t from a major bank? Well womp womp no wireless pay for you.
I for one welcome the Australian banks getting put out to the curb on this. The Apple Pay/Wallet experience is genuinely better in just about every single way. I also enjoy the virtualised card number I get with Apple Pay, which I don’t believe any of the Australian banks bothered implementing, presumably because they were all too busy illegally charging dead people, and hiring corrupt ex state PM’s to build anything good.
While I don't exactly disagree, for my own personal selfish reasons, I would prefer to not use the "Big 2" apps.
Mainly because my bank doesn't lock me out just because I chose to ~root~ own my device.
The apps are bad, sure, but it was the banks who heavily pushed contactless EFTPOS terminals out to merchants in Australia. Without those, Apple Pay is a very cute curiosity on your phone, but I hope you remember your PIN because here comes the restaurant's dinosaur card machine. (Or worse, a click-clack card imprinter.)
> Where each bank had their own janky implementation inside their own specific app, which was both slower and had a worse UX.
You obviously understand this is by (Apple's) design.
I had an Android when the banks were doing this before Google pay took off. The banks are capable of jankiness all by themselves.
Similarly a ton of retailers in the US hated what Apple did. They came in right as EMV was starting to be mandated and contactless was being installed everywhere, even if it often wasn’t on or working.
The banks and retailers all try to make their own thing that they work that way. CurrenC was one, it failed horribly and relied on people taking pictures of QR codes to transfer debit payments, thus avoiding card fees.
ApplePay can do debit also. But they didn’t push that. More “we don’t control it so it’s bad” nonsense.
Everyone along the payment food chain takes a cut so was always surprised that people thought Apple wouldn't. Especially when they are adding a value add on top.
And banks are free to drop Apple Pay. Customers will simply move their business to those who do support it. Just like happened when Apple Pay first launched in Australia and banks like Commonwealth Bank held out.
> 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.
For POS payments, usually only the device account number (DPAN) is shared with the merchant. Even the name is usually redacted, similar to contactless and as opposed to chip or magstripe payments.
All of the additional details mentioned in the article are only shared when you pay "online" – but that includes scanning a QR code on your phone and paying in Safari or an App Clip, which is something I've seen in a few restaurants these days.
That way, the restaurant gets as much as they ask for, which can include your name, your address, and your email address. I think this is usually displayed on the payment sheet, but it didn't really register for me the first time I used it in some restaurant. Now I make sure to ask the waiter for an actual terminal to tap or just give them my physical card.
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?
Just think of your phone like a plastic card. It's listening for the request from an NFT reader, at which point it beams out your 'card number', and that is that.
This took me a while to grok. I couldn't understand how Apple Pay could work when my phone was in Airplane mode. But of course it does! Your existing Visa card works just fine without an internet connection.
Fundamentally, they're the same thing. That's why, if everyone is playing by the standards, there's nothing extra to 'support'. See jjcm's sibling comment here. https://news.ycombinator.com/item?id=39846117
So I dare say the NFT reader isn't 'broadcasting' the amount to pay. Why would it be? Your plastic card had no way of dealing with that information. And so your iPhone has no way of receiving it, and telling the NFT reader to hold on a second while you swipe-to-accept.
> So I dare say the NFT reader isn't 'broadcasting' the amount to pay. Why would it be? Your plastic card had no way of dealing with that information.
Ah but it is, and it does :)
You see those four lights that are on contactless readers? I know they're mostly meaningless to laypeople and they more or less just flash in unison to the naked eye, but they show stages of the transaction progress, left to right.
There's a bunch of two-way comms going on there, including the transmission of the transaction amount, date/time, various transaction details, maybe a cryptographic challenge (nonce), and a bunch of other stuff I can't remember, from the terminal to your card.
Your plastic card has an active chip on it, it's not just a dumb NFC tag, it is powered by the field the NFC reader is giving off. It does send a bunch of data to the terminal on request as an early part of the process, then receives transaction data back, arranges it with some internal bits of its own, pads, hashes and encrypts it using a key (usually a session key derived from a stored private key) and sends back the resulting cryptogram to the terminal. In fact your card makes important decisions about whether to allow the transaction to proceed, based on the transaction data, various counters and limits it maintains, etc etc. If the card doesn't approve the transaction (and show that approval in its cryptogram), the terminal cannot approve.
You phone does the same stuff, but obviously without needing to use the power the reader puts out.
The problem with displaying the amount before you validate, is that it would interrupt the process and require running the transaction in two halves, and it would kill the "tap'n'go" aspect of the transaction. But the phone can immediately display the amount afterwards.
Incidentally, this sort of thing is why we have rules that the terminal must display the amount in a way that's visible to the customer, to be compliant.
> It's listening for the request from an NFT reader, at which point it beams out your 'card number', and that is that.
This is definitely not the case, and if it were the case, contactless cards would be trivial to clone!
It actually is most of the time, but it’s often a placeholder amount (some POSes let you tap before the check is finalized), so it’s too unreliable to display in the wallet directly.
The phone would also not have any way to verify if the terminal actually sent the payment online, causing confusion in case of having to tap again (that would then look like a double booking).
> Your plastic card had no way of dealing with that information.
You'd be surprised! Plastic cards can do all kinds of elaborate things, like deduct that amount from an offline transaction balance, replenishing that balance the next time it gets to talk to the issuer during a chip-dipped payment (assuming the card is still in good standing), update currency conversion rate tables used abroad, maybe even play doom – but probably not all of them.
> like deduct that amount from an offline transaction balance, replenishing that balance the next time it gets to talk to the issuer during a chip-dipped payment (assuming the card is still in good standing)
That deserves its own article. Where/why in the world would you need that!?
For offline support! Chip cards were introduced before internet connections were ubiquitous.
Some cards were even explicitly offline-preferring as long as there was any offline balance remaining to save on data transmission and processing bills.
There are even some fully offline chip systems around (where both terminal and card are mostly offline) that take the “offline purse” idea even further, but these are usually separate from the mostly account-based debit and credit schemes popular today, and are often getting phased out.
These days, cards are mostly online-preferring or even online only, with some merchants taking on the risk of accepting cards while offline.
Isn't it mostly obvious? Offline transactions are needed whenever a transaction is made without access to the internet. Like a train in the middle of nowhere or a flight.
Typically the POS just accepts the card, and then when Internet access is restored, sends them all out. So the merchant takes the risk of a customer using a bad card. But with smart functionality in the card, the card itself could make a determination of whether the payment should be approved.
Some transit cards (such as the Bay Area Clipper card) do this. They are actually quite interesting in how they settle balances!
Here’s that article you’re asking for.
Smart Cards originated from pay phones https://computer.rip/2023-09-03-plastic-money.html
> I couldn't understand how Apple Pay could work when my phone was in Airplane mode. But of course it does! Your existing Visa card works just fine without an internet connection.
If you set it as an express card, it also works if the phone is shut off or has a dead battery. (As long as it's not too dead.)
>NFT reader
NFC reader
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.
https://daringfireball.net/linked/2024/03/21/garland-monopol...
[Update: Whoops, I was wrong about that. Matt Birchler, who works in the payments industry, has a great explainer about how this works, and it turns out major banks and credit cards do generate per-merchant “DPAN” numbers for tap-to-pay transactions. I stand by my argument that Apple Wallet is at least as, if not more secure than, any digital payment app provided by a card issuer.]
---
From the original author (Gruber)
The DOJ doesn't have a case, but WOW the last paragraph of that blog is an extraordinary wall of brand fellatio.
Yeah, Gruber is one of the most enthusiastic cheerleaders for Apple outside of Cupertino itself. It comes from a place of deep and abiding love, but he seems to see Apple kind of the way its internal culture also does — as a plucky upstart who has to fight for its very survival against all the big bad industry leaders (IBM and MS, originally). That viewpoint has become more and more absurd the larger and more dominant that Apple has got, leading us to this point where they want to argue that they should be able to simultaneously be an iron-fisted gatekeeper, and a purveyor of apps that “compete” with less-privileged apps on that same platform.
Gruber has always been an Apple fanboy, but in the past few months it's taken a turn into ragebait territory, and i'm this close to stopping reading it
How many things that most people ( within Apple Fans circle ) commonly believes that are plain wrong was started by him?
Apple invented USB-C and turned it over to USB-IF
The original AirPod was sold at cost.
These are the two I remember well, others including Modem, CPU, Unified Memory, and now Payment. Although arguably Payment doesn't count because he did admit he is wrong.
Basically Gruber and Daniel Eran Dilger from AppleInsider have similar traits, they have made their own conclusion and they derived their explanation backwards.
Gruber also lies about having invented markdown, which was actually invented by Aaron Swartz in 2002 (http://www.aaronsw.com/2002/atx/intro.html). Gruber just wrote a little perl script called Markdown.pl in 2004, but after Swartz's suicide in 2013, he pretended that he had come up with the whole thing, and has been using it to market himself ever since. Truly repugnant behavior.
I guess the latest message he is putting out is "Apple can't compete in Europe without anti-competitive practices, so they should get out of there".
Apple has killed the theft industry and the app store is safe
Ah, now that I'm looking closer at the blog, it looks like a one-man MacRumors to me. Out of 21 blog posts this calendar year, all of them either appear to be Apple related, or they appear to be promoting his podcast, which is also about Apple.
Brand fellatio has just become my new favorite concept :D
>any digital payment app provided by a card issuer
from this line, it seems like the author here and gruber are kind of arguing beside each other. Birchler says that google and samsung pay work the same way. gruber says bank's own apps don't work this way. they can both be right.
does anybody here know if the payment apps operated by card issuers work this way? (or else, do card issuers actually have payment apps? my bank doesn't)
Gruber is wrong.
Many bank-specific wallets also use device account numbers. Storing full credit card numbers and the associated cryptographic keys on a device's application processor (like many wallets on Android do, both Google Pay and others) is a big no-go, and even for secure element based solutions like e.g. Apple Pay it's a big advantage being able to lock the number for a lost/stolen device server side without having to reissue the associated physical card and vice versa.
> do card issuers actually have payment apps? my bank doesn't
They've been somewhat popular regionally, especially in countries where Google took their time with rolling out Google Pay support in, or for regional payment schemes that aren't supported in Google Pay. (They're only possible on Android; iOS hasn't traditionally supported the necessary APIs, until very recently when the EU forced them, and still only offers them there).
I don't think they ever were a big thing in the US.
> I highly doubt any banks or credit card issuers would do this themselves if given access to NFC tap-to-pay.
Birchler points out that the banks did do this.
And Gruber has acknowledged his mistake.
Gruber is an open fanboi but for the most part he would at least get his facts straight and would be open about what he didn’t understand and would link to experts in the field.
However, since the EU DMA actions on Apple he seems to have completely lost his objectivity. First by pretending to understand the legalese better than apparently the EC does, then by applying American lawmaking approaches to European ones which are very different and then finally by taking Apple’s bad faith statements at face value (Gruber’s turn has coincided with Apple’s very weird bad faith approach to the EU so maybe the fundamental issue is his trust in Apple).
And he seems to be carrying over that to the U.S. govt’s antitrust action as well.
Also, to be fair, social media is absolutely filled with Apple people pretending to be legal experts but being completely wrong about almost everything. So it might be hard for him to even see opposing viewpoints from legitimate folks.
Gruber never pretends to be objective - he likes what he likes, and he dislikes what he dislikes. Notably, he has a pretty strong "pro-business" streak in him that objects to anything resembeling workers rights or unions, and government regulation/interference in businesses.
The EU tends to do a lot of that, so overall he's very critical of it. And at the moment there's a lot of governments telling Apple what to do, so it's the perfect storm of getting his knickers in a twist constantly.
I don't think I've seen him do opposition to workers rights / unions? He hasn't been constantly yelling about supporting them either, but that's different.
E.g. a quick google for "daring fireball unions" turned up mostly articles like this one which were pro union-demands: https://daringfireball.net/linked/2021/11/24/wirecutter-unio...
Closest to a negative I found in that quick search was him making fun of the Maryland Apple Store union that was asking to be allowed to request tips from Apple Store customers... while also saying that the rest of their demands sounded like good things to ask for.
Oh man I had forgotten about that.
[flagged]
Have you actually looked into the claims of the US case? Some of their statements are completely incorrect and they don’t even try to address what most commenters on HN seem to care about
He and Ben Thompson are very consistent. If the government wants changes in the way that Apple and other tech companies operate - pass laws - like they did in the EU instead of trying to make up definitions and facts based on a law that was passed almost 100 years ago
Yes I have. But that’s completely irrelevant because I’m not a lawyer.
Ben Thompson and Gruber are not lawyers.
Lawyers I’ve followed have not found any mistakes though they do think some stuff is pushing it, but that’s completely normal and how all such cases work.
You have a core case on which you add a bunch of stuff. Because, one, you expect stuff to get thrown out, but more importantly these cases are rarely litigated to the end. They’re settled. So you put more in, even the slightly weaker stuff, so you can compromise on it during negotiations.
I wouldn’t have know this stuff, which is why I don’t pretend to know this stuff. Unlike Gruber and Thomson. Instead I follow lawyers online and speak to friends who are lawyers who have a better idea of what’s going on.
The ridiculous part of Gruber’s assertions is because he hears about these things only when Apple is involved he seems to think they are unique or new. That’s why his insinuations in a couple of posts that the EU actions were to punish American companies and protect European ones. If he had half a clue about this area he would have known that the EU has fined way more European companies than it has companies from the rest of the world put together.
However, Andrew Sharp, Ben’s cohost on SharpTech was a lawyer and he also says that the judicial system is not the way to go and they should pass laws.
But you don’t have to be a lawyer to know the statements of fact are in correct as far as the technology.
They also condemned EUs ruling against Facebook where Facebook can’t even give users a choice of having an ad free experience by paying.
I have no problem paying money for stuff I want. I think that’s an honest transaction.
On Dithering, Gruber commended the EU for actually passing a simple law forcing Apple to open up NFC and the USB C mandate for iPhones instead of dragging it through some arcane legal doctrine. He didn’t necessarily agree with the law. But it was at least straightforward and honest.
But even if you aren’t a lawyer - the things that most HN users care about were not addressed at all in the lawsuit. For instance there is no mention of the App Store at all except concerning NFC, cloud gaming (that Apple has already addressed) and whatever apps are called with other embedded apps.
And no one in the Apple commentary community thinks the anti steering provision for Spotify and Kindle and Netflix etc is legitimate nor the former ban on cloud gaming.
Right now I’m listening to the Talk Show podcast with Gruber and Jason Snell (former editor in chief of Macworld) and they aren’t giving Apple a pass at all for the three items I mentioned
Excellent points.
> For instance there is no mention of the App Store
In fact the DOJ would have likely had issues doing that given Apple’s recent victory in that point against Epic (whatever you think of it).
The fact that the DOJ may be able to win the case does not make an antitrust case like this the correct way to legislate how we want companies to operate.
It would be SO MUCH SIMPLER to just pass a law that says “sideloading has to be legal, easy, and free”. That’s all it would take.
Or maybe “all cell phones must support RCS.”
But not only have we not done that, the lawsuit against Apple for being a monopoly on the App Store was won by Apple. A court said they are legally in the clear. Apple already said they were adding RCS before this whole thing started.
So the DOJ has come up with a bunch of issues, some of which that don’t even seem relevant anymore, in an attempt to draw out concessions from Apple in a settlement to get what they couldn’t get through previous court cases. Or perhaps win a verdict and charge them a whole bunch of money for stuff that doesn’t matter all that much because again, some of the stuff they seem to be really mad about Apple already won on in another trial.
The DOJ is supposed to be about enforcement, not creating the laws. This is not how this process should be working. And as Gruber and others have pointed out, if you have to twist a bunch of hundred plus year-old laws to try to come up with a case to do something that could’ve been done with a single stroke of a pen… maybe that’s what you should’ve done instead.
I haven’t seen anyone saying who is arguing that Apple should 100% get out of all of this and they’re not doing anything wrong. Gruber and many others in the app world have been saying for years that Apple’s blatant greed is going to get them a smack down, and they’ll lose some of their good policies along with the bad.
People are arguing that the lawsuit doesn’t seem well-made and that it shouldn’t how the government accomplishes its goals in the first place anyway.
Laws like you propose tend to age poorly. RCS is incredibly consumer-hostile (e.g., there is no end to end encryption unless you use Google’s data-harvesting stack on both sides).
Similarly, requiring side loading could preclude new classes of devices.
Usually, the laws are written more vaguely for this reason. I think the big change we need to make is to say that anti-trust laws apply whenever N or fewer organizations control over X% of the market. I think N=3 and 75% would be good starting points.
Among other things, this would open up licensing and cell plans on 5G modems.
It would also mean that the google app store and apple app store both have monopolies over cell phone software resale and distribution.
(Google’s “android is open source and supports side loading” argument wouldn’t matter in such a regime, unless that meant that consumers and device manufacturers could reasonably expect degoogled android to actually run android apps and stuff, and that over a quarter of the market actually did so).
> Laws like you propose tend to age poorly.
And court cases don’t?
There was a court case against IBM over anti trust that started in 1969 and it was finally dropped in 1982 because the world has moved on.
One of the issues in the current case is already irrelevant - Cloud gaming that Apple has addressed.
Another issue was whatever you call the mega apps. Apple has allowed that for years and Microsoft, Google and Facebook all moved away from the mega app into smaller apps.
I think you should reconsider your judgement on the EU ruling being good.
If you can’t argue the EU ruling is bad (and not because Apple is greedy or shortsighted etc), you are missing something.
Apple has a vision - the EU has a vision and they do not align.
The EU is poor. It has been mismanaging itself for years: they should be doing better than they are. Is this caused by outside vectors or the leadership, or maybe the structure (too many cooks in EU kitchen)?
Is the vision of the world the EU wants 15-25 years out strong?
Is the world the EU would create good for the EU - 30 years out? I’d argue it’d be a comfortable one. But a poor and weaker one.
I’m not trying to defend Apple. I’m trying to say that the EU leadership is likely bad - my hunch is anyone truly good would work in the state department of the respective nation.
Kinda like how UN ambassadors for the US are never our best - our best maybe might once in a blue moon take the post like a retirement phase.
Now take the ruling, are you sure they made a smart long term move?
I don't know what "ruling" you're talking about. The DMA is a law, and it will be enforced despite Apple pretending to comply with it. There's nothing like a judicial proceeding as yet, much less a ruling.
This really underscores the point, and it's not just Gruber and random internet commenters opining on EU law while having zero clue about it, it's also Apple fans I respect like John Siracusa and Jason Snell who have a lot of opinions without familiarizing themselves with the facts.
Gruber had Jason as his guest on the last episode of The Talk Show, just to give some context to both of their arguments.
At the very least, they seem to agree that issues with the DMA - and the US DOJ case - stem from the idea that these lawmakers fundamentally misunderstand Apple's approach and why customers choose iOS, macOS, etc.
Tl;dr, the integration is the point and these legal challenges pose the idea that this approach doesn't comport with the law as written and should be disallowed.
That sounds like critical understanding failure on what DMA is about, what law is about, what EU is and is about.
If, by that you mean:
1. The EU passed a law that was too complicated for its own good and... 2. Is a law that isn't practically enforceable 3. Lastly, is largely incompatible with how US public companies operate - welcome to Capitalism, it's how the world works...get used to it.
If market forces mean people either choose piracy to get what they want (Napster), that's one thing and regulation can help with that. However, the idea that you can't build a closed ecosystem that operates how you want - before you even get to shareholders in a public company - because this imposes restrictions on citizens, is a weird way to look at the world for a region that is - nominally - still capitalist.
> The EU is poor. It has been mismanaging itself for years: they should be doing better than they are. Is this caused by outside vectors or the leadership, or maybe the structure (too many cooks in EU kitchen)?
> Is the vision of the world the EU wants 15-25 years out strong?
> Is the world the EU would create good for the EU - 30 years out? I’d argue it’d be a comfortable one. But a poor and weaker one.
The EU vision isn't just about economy and making money. This is something that the US will never understand because money and unrestricted capitalism is the only thing that counts there. The US truly doesn't understand that any other model can work, because the only way they measure success is $$$.
Whereas we in Europe care more about quality of life, a safety net etc. Our bank accounts are a means to that end but not a goal in themselves.
Of course Europe is quite different depending on the area with Netherlands and the UK also very neoliberal but most of the other countries are way more moderate.
I often get this disconnect even with my Dutch friends. They don't understand why I won't move back to Holland as I could make twice as much there in the same role. But the cost of living is also higher and more importantly the quality of life is much lower. People in Spain truly enjoy life much more.
For example during lunch a Dutch person would have a quick sandwich at the canteen so they can head off home early and beat the traffic jam. They always want to have the prettiest house and the fanciest car and work hard for it. So hard they lose time to enjoy those things. In Spain we go for lunch to a restaurant to have a three course meal with a glass of wine and after work we often grab a beer or two and sit in the sun. Most of my colleagues don't even own a car.
Life feels way more real to me here.
I don't think "Spanish people get to be alcoholics" is enough proof that a system works where you need to have the same currency as a poorly run country like Greece or, at this point, Germany.
(Germans are psychotically high trust and seem to just believe anything anyone tells them, like "you should shut off all your nuke plants" or "Russians are really nice and it's fine to buy all your energy from them" or "you should sell your robotics companies to China" or "you should never ever run a budget deficit".)
It's not really about the drinks and many people don't have the wine or beer. I just included them as a way to describe the informal nature. At lunch we only ever have one (in France even the canteens serve wine, it's quite normal). And we don't do it every day :)
It's just about enjoying life being the primary goal, not amassment of material goods.
Yeah there's a very big difference between "Apple Pay does this" and "only Apple Pay does this". It seems like Gruber said the former, but the author somehow read the latter.
> 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.
In the US it was uncommon. Contactless payments had been supported in Europe and Asia for a while (2007 in the UK), though with fairly low limits at least in the UK.
Interestingly, it seems like the UK still has a £100 limit, while in the US I've paid well over $2000 with a contactless payment using my Android phone.
The UK's £100 limit only applies for using the actual card, if using a device to pay it's authenticated with your PIN or biometric and you can pay up to £10,000. If you look on the receipt you can see "cardholder device verified"
That makes sense, thanks!
In Australia it seems like a credit card contactless is limited (was AU$100 or fifty quid if you like) but now might be more.
But the apple pay is way higher I have spent over $1k on it before. Probably because there is at least another layer of security which is a Passcode which is probably a better PIN than the credit card pin itself.
Contactless credit card payment limits in Australia (from my experience) are configurable.
I bumped my contactless limit from $100 -> $500 years ago through my bank's app. Leaves friends confused every time I cover a group dinner out
Australian also. I wish for the opposite, I’d like to be able to reduce the tap-no-pin limit down to $50 or so. I only use the physical card in rare emergencies, and increasing the times I have to enter my PIN by once or twice per year is hardly an inconvenience.
I believe when using apple pay with an apple watch, there's no longer a threshold where you need to use a PIN/passcode as the watch is using 'biometric authentication'.
There were one or two other things at the time but I think they were glorified autocomplete. I’m pretty sure there was a version of Google pay that didn’t filling stuff on the website, but I think it gave your real card number in the background somehow. Maybe only directly to the bank so the merchant didn’t see it, but it was still your real number.
Apple is the first one I remember hearing of that used DPANs.
Google Wallet (2011) was the first one, AFAIK, but the initial system also provided a "google" card working as "prepaid wallet", which made it less clear.
Apple marketed it better though
I think Capital One had virtual card numbers available before Apple Pay came out, but could be wrong about that. There were definitely a few neobanks offering it.
They did but that’s a bit different as while it’s not your real card number it’s not a tokenized payment in the background. It’s still just a PAN and security code.
EMVCO specs for contactless was always a tokenized card number. Maybe Samsung Pay was passing the PAN for online payments.
They may be thinking of MST
For context, MST or magnetic secure transmission, allows a phone to transmit an EM signal that emulates the physical action of swiping a magstripe based card. As in, it works with all the legacy "card swipe" terminals. Samsung phones up to like the S20(?) supported this, allowing them to technically work basically everywhere with no integration needed.
That's straight Voodoo shit. Getting that to work with most cheapo POS's sounds immensely challenging.
It was I think the last major implementation to enter the market, with first one based on EMV standards being original Google Wallet (which was blocked by Google's typical inability to launch something globally).
USA is just, for various reasons, very very behind on things like card payment technology, to the point that visiting from Poland with card I used worldwide for years I had to first learn special workarounds so cashiers would know how to charge it.
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.
The merchant's payment service provider receives a unique identifier for the card these days, which was explicitly designed for loyalty and transit use cases: https://www.securetechalliance.org/wp-content/uploads/EMVCo-...
> Same for transit like OMNY in NYC. It tracks my virtual card enough to implement fare capping.
That's per DPAN, though. Capping doesn't work across devices (or people would just add their cards to friends' and family members' iPhones and split the capped fare).
There must be at least some truth to the fact that it makes the process more difficult. In Central Texas the most prominent grocery retailer by far is HEB, who has purposefully and intentionally not supported any sort of NFC payments, presumably because it somehow makes it easier to track people’s purchases over time by preventing NFC.
FWIW they are the only holdout. You can pay with NFC at Walmart, Costco, gas stations, regular retail outlets, etc almost anywhere else in Central Texas. HEB absolutely sticks out like a sore thumb in their lack of NFC support. And it’s not that they aren’t tech savvy - they own and maintain an Uber-Eats like app here called Favor that works pretty well. They clearly understand technology
I wouldn't be surprised they'd just completed an infrastructure upgrade that didn't support NFC prior to it's growth in popularity and now they're unwilling to pay that upgrade toll all over again. But that's just pure uninformed speculation on my part.
No, the readers they install actually have NFC in them, believe it or not. So even the hardware in the POS at the store supports it
Are you sure about Walmart? They’ve always held out because they want you to use Walmart pay I thought.
I guess it could vary by location. My local Walmart is the only place I go to regularly where I have to insert my card instead of tapping.
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?
I might be wrong but they are acutally differnt CC numbers, with the prefix linked to ApplePay, and then they resolve or proxy to your acutally CC.
You can use NFC Sniffers like the Flipper to see this in action.
Same how ApplePay on the watch works without network, cuz it has already preset the AppleCC prefix on ur watch, and its just emulating that AppleCC to the card receiver.
Same for the phone.
It will transmit everything in EMV contactless spec, tokenized like always.
DPAN is just token to represent a combination of device+card.
But it will not contain my address right?
So if I use Apple Pay in store, at say Kroger for 100 times, can they track me? Or do I get a new credit card number every time?
You'll get every time the same card number, with said card being specific to the device. So they will be able to track that the same buyer is doing the purchase, which is what most POS-based analytics are interested in.
Way more important is the (sometimes filtered) dump of everything on your bill that is passed on to various corporations (Nielsen, sometimes direct to suppliers), and how in-store analytics then build data at neighbourhood or per-store level.
Store analytics need not know that specifically "WirelessGigabit" bought something, store analytics is more interested in "we have repeated customers with such and such spending and purchases" and "in this zip code we have this kind of population with associated types of buyers" and "This is how much people are buying certain products and when, so that suppliers can plan campaigns and production"
> That 'though' does not compute.
s/", though"/"though, "
The author should not be using pixilation as a method to redact information from his screenshots.
The proper way is to replace the text you want to redact with some other text, then use pixelation after that. Much more fun to be had. :-D
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.
I submitted the article title and can’t change this amended one, but you can reach @dang at hn@ycombinator.com.
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".
How do I key in a credit card number when I am at a target store checking out?
To continue to use the example of Capital One, you can use their virtual cards with digital wallets; the point is to demonstrate that this is neither a new capability nor something that is exclusive to digital wallet apps.
Because you can’t use those burner numbers to make brick and mortar purchases.
Your assertion was objectively false.
Cashiers in brick and mortar stores can enter card details manually. You've never had a card reader break and then had the cashier have to type it in by hand?
I have never convinced a cashier to use digits provided by me or off my phone screen. That is fundamentally different from getting them to manually enter a card.
But I understand you’re making irrelevant bad faith comments, because you’re too weak to admit that you were wrong about something unimportant.
kibwen, learn to take an L.
They can but they generally won’t. Use of the chip on the card shifts fraud liability from merchant to issuer. Burner card numbers are for card not present transactions.
Sketchiness aside, the fee a merchant pays is different based on the capture method to incentivize using more secure methods. The bank, payment processor, and the merchant know how a PAN was processed.
Never once had that in my life.
It’s usually only done when the card reader isn’t working with the particular card. For example back in magstripe when it was the magnetized or if there’s a problem with the chip these days and magstripe fallback fails or the device doesn’t support stripe reading.
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!