Misunderstanding about the details of how Apply Pay works

Original Article ↗ Hacker News Discussion ↗

Confusion over how Apple Pay works has prompted a deep dive into card tokenization, device-specific numbers (DPANs), and how closely Apple’s system actually follows EMV industry standards shared with Google Pay, Samsung Pay, and bank wallets. Commenters highlight that while Apple popularized mobile tap‑to‑pay and adds some security and UX benefits, its approach is neither unique nor inherently more private now that schemes like PAR let processors link wallet transactions back to the underlying card. The thread broadens into regulatory and antitrust questions around Apple’s control of NFC on iOS, the EU’s DMA, and whether privacy and competition should be enforced by platform design or by law.

Scope of the “Apple Pay is unique” Claim

  • Several commenters note a misreading: saying “Apple Pay does X” became “only Apple Pay does X.”
  • Many emphasize that Apple Pay is largely standards-based EMV contactless and not technically unique; Google Pay, Samsung Pay, and issuer wallets can use similar mechanisms (tokenization, device numbers).

Technical Mechanics: DPAN, PAR, and Tokenization

  • DPAN (device account number) is a tokenized card number stored in the secure element.
  • Consensus:
    • One DPAN per device per card, not per merchant.
    • It’s mostly static unless the card is removed/re‑added; some issuers can roll it.
  • Newer infrastructure can expose a PAR (Payment Account Reference) to merchants/payment processors, which links all DPANs (and often card reissues) for the same underlying account.
  • Net effect: wallets improve security (less useful to thieves, easier server‑side revocation) more than privacy.

Privacy and Trackability

  • DPANs hinder simple merchant-side tracking by raw card number but do not prevent it: PAR and other identifiers allow cross‑merchant and cross‑transaction linkage.
  • Banks and processors still see full transaction data; if they sell data, DPAN doesn’t stop that.
  • In-person Apple/Google Pay generally share only payment info; web/QR flows can pass name, email, address, depending on what the merchant requests.
  • Some argue EU GDPR already constrains secondary use of card data; others are skeptical that technical measures from Apple meaningfully change the data-broker landscape.

Regulation, DMA, and Antitrust

  • Strong debate over whether EU’s DMA and US antitrust suits reflect misunderstanding of integrated platforms or are necessary checks on gatekeepers.
  • One side: if governments want side‑loading, NFC access, RCS, etc., they should legislate clearly rather than stretch century‑old antitrust laws.
  • Other side: antitrust cases routinely bundle strong and weak points to reach negotiated remedies; critics outside law underestimate this and often see EU enforcement as anti‑US, despite many EU firms being fined too.

Banks, Retailers, and Competing Wallets

  • Banks in several regions built contactless and even their own NFC or app-based wallets before Apple Pay; resentment exists over Apple taking a per‑transaction cut on top of their infrastructure.
  • In places like Australia and Canada, banks’ own Android wallets were seen as clunky; users gravitated to platform wallets once available.
  • Some merchants disable NFC (especially in the US) to preserve tracking methods or favor proprietary payment/loyalty systems.

User Experience and Limits

  • Contactless limits and liability vary by country and by whether the transaction is authenticated (biometrics/PIN) or not.
  • Confusion exists about why phones/watches don’t show the transaction amount pre‑confirmation; commenters explain that the EMV flow and terminal behavior make this unreliable.