Misunderstanding about the details of how Apply Pay works
birchtree.me
birchtree.me
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?
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.
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.
The merchant receives the same ‘random’ card number for transactions from the same device.
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
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/...
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.
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.
(Those systems all seem to use either magstripe or chip though, so maybe the wireless transaction could still use a different one, in theory).
IIRC in some countries this means it's accepted more or has higher payment limits.
where I live it happened exactly this way since a few years. Online is 3DS only and in person is chip/EMV only
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.
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.
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.
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).
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).
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).
Fortunately she took my explanation well and wanted me to demo it in front of a co-worker.
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.
(edit: forgot cards and devices can have their own limits, best ignore this comment)
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.
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! :)
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.
> 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
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.
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).
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.
They do bank whitelisting, not protocol breakage.
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.
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.
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.
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.
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.
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.
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?
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.
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.
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.
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.
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 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.
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-...
My local Australian bank (NAB) does this. I imagine it's pretty normal across most credit cards here.
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.
…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.
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 ;)
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.
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.
As long as your bank is involved you’re just going to have to put up with them and trust them.
They're not generally considered stable in the payments world. They can get rolled periodically, even outside of card addition and removal.
And of course you could always just remove your card and then re-add it. That would give you a new DPAN.
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.
Thanks.
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).
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
Passkeys seems perfect to me. Easy sign on anywhere I sign up. No central whoever that knows every time I log in anywhere.
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).
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.
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.
Stackoverflow encouraged openid from anywhere and it created problems.
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.
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.
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.
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.
But yeah, point still stands
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.
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.
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.
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.
(Of course that doesn’t preclude a bank from making an irrational decision.)
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.
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 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.
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.
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.
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.
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.
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.
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 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.
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.
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.
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.
https://www.accc.gov.au/media-release/accc-denies-authorisat...
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.
Mainly because my bank doesn't lock me out just because I chose to ~root~ own my device.
You obviously understand this is by (Apple's) design.
Some retailers eg CVS turned off tap payments when Apple Pay was introduced.
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.
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.
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.
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.
That deserves its own article. Where/why in the world would you need that!?
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.
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.
Smart Cards originated from pay phones https://computer.rip/2023-09-03-plastic-money.html
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!
NFC reader
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.)
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.
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.
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.
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?
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.
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.
> 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.
(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 just about enjoying life being the primary goal, not amassment of material goods.
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
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.
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
> 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).
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.
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).
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.
[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)
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.
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 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.
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.
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.
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
Apple is the first one I remember hearing of that used DPANs.
Apple marketed it better though
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.
Same for transit like OMNY in NYC. It tracks my virtual card enough to implement fare capping.
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
> 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).
> 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?
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.
DPAN is just token to represent a combination of device+card.
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?
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"
s/", though"/"though, "
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.
EDIT: Would someone like to explain why this is downvoted? This statement is objectively true; for example, Capital One calls these "virtual card numbers".
Your assertion was objectively false.
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.
>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.