> If you consider creating own NFC payment app instead of Google/Apple Pay - that's actually possible
Is it? Last time I checked, Apple & Google were also interfacing with banks on the server side, i.e. banks had to integrate with Apple/Google specifically. I'd love to be wrong, though.
That's not related to ability to create own app - on both ios and Android you can access NFC hardware directly (on iOS it's limited geographically), and send card data as you see fit - Google & Apple do nothing in such case.
I believe that for a long time, Apple was preventing the use of NFC (or was it just for payments?). The EU Digital Markets Act is supposed to prevent them from doing that, as part of the "interoperability" part. And I think the DMA is great in that sense.
True, on iOS access to the NFC chip has been a additional blocker. But on Android apps have been able to use the NFC chip just fine and it's still not that easy to write a generic "wallet" app (that's compatible with all banks & cards), see my previous comment.
Either way, even if apps had full control over the chip, my understanding is that building a wallet app would still amount to much more than just interfacing with the NFC chip.
Could you elaborate? You seem like you know quite a bit about this topic.
While I've known that building a wallet is not as simple as configuring the NFC chip and one would have to interface with banks on the backend etc., I've failed to understand exactly why. What prevents a phone from emulating a regular physical credit card?
On technical level - nothing. Thing is, that payment card is basically private key, that's derived from master key controlled by the bank. This key signs your transactions. Tokenization adds some extra steps (eg. single use keys), but it's fundamentally the same.
What it means - you cannot obtain working card profile if bank doesn't issue it to you. Therefore you need blessing from bank & card scheme to be connected to this ecosystem.
If you want to go deeper into this rabbit hole I can recommend two sources:
* https://developer.verestro.com/books/token-requestor - actual solution. It focuses on offering for single issuer, because market for Google Pay competition is pretty narrow, but technically it's mostly the same + way more red tape.
If you ever decide to try - ping me, I happen to know a few guys there :-)
> If you ever decide to try - ping me, I happen to know a few guys there :-)
Ha, I have actually been entertaining that idea for quite some time, but it seems rather difficult to penetrate that domain as an outsider. The links you shared only seem to confirm that. :-\ I'm not sure I would even want to compete with the Google/Apple Pay duopoly, for now I'd mostly just be interested in an open-source, privacy-preserving solution for contactless payments.
Anyway, you might want to add your contact info to your HN profile – just in case. ;-)
>What prevents a phone from emulating a regular physical credit card?
If this were possible fraudsters would be easily be able to clone people's cards by getting close to them. The protocol was explicitly designed for this to not be possible. There are secrets that live on the card itself and are not exposed
Aren't there several protocols? I understand NFC chips or the old-school "phone card" UICCs are probably quite difficult to clone but at least in the US swiping credit cards (+ physically signing the printout maybe) still seems to be quite common.
Yes, if you want to write an app, that will generate transaction conforming to the protocol & will use your card number it's actually very short programy.
With some luck it will be even routed to your bank. Then it will fail due to invalid authentication. I think there's a defcon talk on YouTube that details the exchange.
No hardware on the phone to emulate swipe :-) But yes, magstripe is easy to clone - main reason why it is dying.
The one you shared is fine, but it's overview on whole ecosystem. Something NFC focused would be probably more helpful like these two https://youtu.be/7ElZBI9PufY
Is it? Last time I checked, Apple & Google were also interfacing with banks on the server side, i.e. banks had to integrate with Apple/Google specifically. I'd love to be wrong, though.