I've been thinking too much about NFC payments lately. It would be insane if we could achive card-to-terminal payments one day but I think challenges with storage and coin selection make the naive approach (store nuts on card, terminal takes them out) infeasible in the short term. However, we can still achieve a lot with phones. The naive approach with phones would be to send the nuts directly via NFC form device to device. This is possible in Android through Host Card Emulation (HCE) where one phone can pretend to be an NFC card with data on it (the nuts) and the other phone simply scans it. Unfortunately, Apple will never allow us to use their (your!!) hardware for HCE so we shouldn't depend on it. There is an alternative approach though, which use payment requests. Payment requests are a work-in-progress Cashu NUT protocol update. They are generated by a receiver to tell the sender how to send them nuts. They include information transport methods (how to reach the receiver), optional amount and receiver pubkey. For example, a payment request can say "send 100 sats to this HTTP endpoint, or DM this pubkey on nostr". It can also include instructions to lock the tokens to a pubkey. A payment request can be shared as a QR code, which can be scanned by another cashu wallet that then makes the payment (similar UX like Lightning invoices). We can use payment requests in combination with NFC to make a very good payment UX that works with Android, iPhones, and on the web (webnfc). If we put a payment request onto an NFC card, that card can be scanned by a sender's phone. The sender's phone could then do the coinselection and send the nuts via nostr to the receiver, for example. This would basically be almost instant. A web wallet like cashu.me could even generate payment requests and store them on an NFC card (from the browser) which another cashu.me wallet could scan (also from the browser) to make a payment. A little bit like a cursed PoS system. Should be further explored!