iOS NFC in the EEA — tap-to-pay without Apple Pay

What changed — and why only in Europe

For fifteen years the iPhone's NFC chip was Apple Pay's private property: banks could tap only by enrolling in Apple's wallet, on Apple's terms. The European Commission investigated that lock under case AT.40452, and in July 2024 accepted commitments from Apple — binding for ten years — that open the NFC interface to third-party wallet and banking apps via Host Card Emulation (HCE), free of charge. The APIs shipped with iOS 17.4.

The scope is the point: the commitments bind Apple in the European Economic Area only. Not the US, not the UK, not Switzerland. A feature born of an EU antitrust remedy became something a European issuer can ship and an American one cannot — the mirror image of the usual sovereignty story, and the reason this page sits in the digital sovereignty framework.

It is not theoretical. Vipps MobilePay launched iPhone tap-to-pay on its own wallet in Norway in December 2024 — the first large-scale alternative to Apple Pay on iPhone anywhere — and is in this catalogue as a verified provider.

What HCE on iPhone lets an issuer do

• Own-brand tap-to-pay — the customer opens your app (or holds the phone to the terminal with Field Detect) and pays; card credentials live in your app's secure cloud setup, not in Apple's Secure Element.
• Default-wallet status — users can set a third-party wallet as the default NFC app, so the double-click-to-pay reflex belongs to your brand, not Apple's.
• Full UX and lifecycle control — onboarding, authentication, card art, receipts and engagement stay in your product instead of being flattened into the Apple Pay sheet.
• No Apple Pay dependency — the commitments route is fee-free; whether you also offer Apple Pay becomes a product choice, not a prerequisite.

Android has allowed HCE since 2013, which is why issuer wallets existed there for a decade. iOS 17.4 completed the pair: for EEA users, an issuer wallet can finally cover both platforms.

The fine print

• Geography: EEA users only. Outside the EEA, Apple separately offers a Secure Element API in selected markets (iOS 18.1+) on commercial terms — a different mechanism with different economics. In the EEA, HCE access is a right; elsewhere it is a negotiation.
• Eligibility: the HCE entitlement requires an EEA establishment and meeting industry requirements — PCI DSS, EMVCo specifications, GDPR.
• Tokenisation still applies: credentials must be provisioned as network tokens (Visa VTS / Mastercard MDES) or issuer tokens — the same layer behind X-Pays provisioning and issuer-wallet (HCE) tokenization. In practice you buy this from a specialist rather than build it.
• The scheme layer is unchanged: an HCE wallet is sovereign at the wallet layer; the card underneath still issues on Visa or Mastercard — see European card schemes — the honest map.

Verified providers that can deliver it

The catalogue flags iPhone HCE capability only where it is documented — 7 providers verified at source, from the card-and-wallet technology arms of Europe's card manufacturers to issuer-wallet specialists (MeaWallet is flagged as likely pending confirmation — and one verified entrant, Entrust, is US-owned; its profile carries the ownership flag). Delivery requires the provider stack and your EEA entity together — confirm the split of entitlement, certifications and tokenisation in the RFP.

Three questions for your RFP

1. Which route fits my product — own HCE wallet, X-Pays, or both — and what does each add to time-to-market?
2. Who holds the Apple entitlement and certifications (PCI DSS, EMVCo) — you, the provider, or a partner — and who owns the relationship if terms change?
3. How is tokenisation handled (VTS / MDES / issuer TSP), and how does the wallet behave for users who leave the EEA?

Score your stack with the sovereignty scorecard, or filter the catalogue by “iOS NFC (EEA)” under advanced filters.