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.)
