5 ms·

Banks do that for p2p payments and e-commerce (like iDeal mentioned by sibling comment or BLIK in Poland). For physical transactions there's barrier of hardwar

Banks do that for p2p payments and e-commerce (like iDeal mentioned by sibling comment or BLIK in Poland). For physical transactions there's barrier of hardware and network effect - everybody has card terminal. Users expect near 100% acceptance for them to use payment method daily. If you consider creating own NFC payment app instead of Google/Apple Pay - that's actually possible, but more expensive and often disliked by the users due to inability to easily switch between cards issued by different apps.

codethief 2y ago
> 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.
- palata 2y ago
  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.
  - codethief 2y ago
    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.
    - charcircuit 2y ago
      >But on Android apps have been able to use the NFC chip just fine The last time I looked at it, it was not possible because Android doesn't let apps control the uid that gets used for NFC.
      - codethief 2y ago
        Ah right, good point. I did forget about that. 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.
        dzikimarian 2y ago
        You need connection to card scheme, which means you need ton of paperwork, which means you need ton of money. That's biggest issue :-) For technical side - there are companies selling complete SDKs.
        codethief 2y ago
        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?
        dzikimarian 2y ago
        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.mastercard.com/product/mdes https://developer.mastercard.com/product/mdes - Mastercards framework for tokenization * https://developer.verestro.com/books/token-requestor 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 :-)
- dzikimarian 2y ago
  It's optional if you want "add to wallet button". 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.
palata 2y ago
As mentioned in the sibling comment, Twint goes with QR code. It just works. It's even better than NFC because a small store can print their QR code on a piece of paper and not need to buy a terminal. Most stores just have the normal card terminal print the QR code and people scan it.
- andrewaylett 2y ago
  NFC, for payments, has bidirectional communications and limited scope for MITM. It's a bit too easy to cover a sticker. The TWINT app says -- if their promo videos are to be trusted -- "Scan only QR codes from trusted sources and check the receiver of the payment in the next step". That doesn't fill me with confidence :(. A dynamic QR code could be fine -- they have their app, you're able to bootstrap what is effectively a secure channel between the PoS machine and the app to give the vendor confidence their device has received payment and the consumer confidence that they're paying the right vendor. A static QR code is more challenging, and it sounds like they're putting more weight into social protections than I'm comfortable with -- especially considering a technical solution is possible and exists. I'm especially wary of the warning that individuals can't have QR codes. Why not? Unless it's part of the social protection. But I can personally accept NFC contactless payments (having opened an account with a suitable provider), and indeed I bought a device which means I can accept chip and PIN payments too.
  - palata 2y ago
    Multiple things here. * The vast majority of the payments (almost all of them) are done with dynamic QR codes. * The static QR code is mostly used by very, very small entities. Like the person asks you to scan their code, enter the amount and show them the confirmation. It is in their interest to show the right QR code. * Sending money to a friend is done with the phone number as an id. It works, but you need to enter the mobile phone number of the receiver. * There is one situation where static codes are printed and where phishing has been reported (it's not MITM, it's really just a QR code that sends you to a bad website): when paying for parking. You don't have to use it if you don't feel comfortable, and it is possible to feel comfortable because it actually just opens a website (so if you use it regularly you can learn to check that you are on the legit website before you make the payment). Overall, it is super popular and it works really well. No need for NFC, and no need to install the Google Play Services \o/.

codethief 2y ago

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

palata 2y ago
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.
- codethief 2y ago
  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.
  - charcircuit 2y ago
    >But on Android apps have been able to use the NFC chip just fine The last time I looked at it, it was not possible because Android doesn't let apps control the uid that gets used for NFC.
    - codethief 2y ago
      Ah right, good point. I did forget about that. 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.
      - dzikimarian 2y ago
        You need connection to card scheme, which means you need ton of paperwork, which means you need ton of money. That's biggest issue :-) For technical side - there are companies selling complete SDKs.
        codethief 2y ago
        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?
        dzikimarian 2y ago
        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.mastercard.com/product/mdes https://developer.mastercard.com/product/mdes - Mastercards framework for tokenization * https://developer.verestro.com/books/token-requestor 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 :-)
dzikimarian 2y ago
It's optional if you want "add to wallet button". 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.

palata 2y ago

As mentioned in the sibling comment, Twint goes with QR code. It just works. It's even better than NFC because a small store can print their QR code on a piece of paper and not need to buy a terminal. Most stores just have the normal card terminal print the QR code and people scan it.

andrewaylett 2y ago
NFC, for payments, has bidirectional communications and limited scope for MITM. It's a bit too easy to cover a sticker. The TWINT app says -- if their promo videos are to be trusted -- "Scan only QR codes from trusted sources and check the receiver of the payment in the next step". That doesn't fill me with confidence :(. A dynamic QR code could be fine -- they have their app, you're able to bootstrap what is effectively a secure channel between the PoS machine and the app to give the vendor confidence their device has received payment and the consumer confidence that they're paying the right vendor. A static QR code is more challenging, and it sounds like they're putting more weight into social protections than I'm comfortable with -- especially considering a technical solution is possible and exists. I'm especially wary of the warning that individuals can't have QR codes. Why not? Unless it's part of the social protection. But I can personally accept NFC contactless payments (having opened an account with a suitable provider), and indeed I bought a device which means I can accept chip and PIN payments too.
- palata 2y ago
  Multiple things here. * The vast majority of the payments (almost all of them) are done with dynamic QR codes. * The static QR code is mostly used by very, very small entities. Like the person asks you to scan their code, enter the amount and show them the confirmation. It is in their interest to show the right QR code. * Sending money to a friend is done with the phone number as an id. It works, but you need to enter the mobile phone number of the receiver. * There is one situation where static codes are printed and where phishing has been reported (it's not MITM, it's really just a QR code that sends you to a bad website): when paying for parking. You don't have to use it if you don't feel comfortable, and it is possible to feel comfortable because it actually just opens a website (so if you use it regularly you can learn to check that you are on the legit website before you make the payment). Overall, it is super popular and it works really well. No need for NFC, and no need to install the Google Play Services \o/.