Paiement mobile NFC DMA : Apple Pay et Google Pay 2026

Le paiement mobile NFC DMA change surtout une chose en 2026 : sur iPhone, l’accès au paiement sans contact n’est plus réservé à Apple Pay dans l’Espace économique européen. Pour un commerçant, une banque, une fintech ou un éditeur d’application, cela ouvre des options, mais pas un raccourci magique. Les contraintes réglementaires, bancaires, sécurité et certification restent lourdes.

Paiement mobile NFC DMA : ce qui change vraiment en Europe

Le DMA, pour Digital Markets Act, est le règlement européen de 2022 qui encadre les grandes plateformes numériques considérées comme contrôleurs d’accès. Son article 6(7) impose notamment davantage d’interopérabilité, c’est-à-dire la capacité pour des services tiers d’utiliser certaines fonctions matérielles ou logicielles déjà disponibles pour les services de la plateforme.

Dans le cas d’Apple, le sujet sensible était la puce NFC de l’iPhone. NFC signifie Near Field Communication : c’est la technologie de communication à très courte distance utilisée pour payer en approchant un téléphone d’un terminal. Avant les engagements acceptés par la Commission européenne le 11 juillet 2024, Apple Pay était le seul portefeuille mobile autorisé à accéder à cette fonction pour le paiement en magasin sur iOS.

La Commission a rendu juridiquement contraignants les engagements d’Apple pour 10 ans dans l’Espace économique européen. Des applications de paiement tierces peuvent donc accéder gratuitement à la fonction « tap and go » de l’iPhone, sans passer par Apple Pay ni Apple Wallet, sous conditions. Un mandataire indépendant surveille le respect de ces engagements, avec un risque d’amende pouvant atteindre 10 % du chiffre d’affaires annuel mondial en cas de non-respect.

Concrètement, cela ne veut pas dire que n’importe quelle application peut devenir un moyen de paiement du jour au lendemain. En 2026, la documentation Apple indique qu’un développeur doit obtenir un accord avec Apple et un droit technique spécifique, appelé NFC & SE Platform entitlement. SE désigne le Secure Element, un composant sécurisé qui stocke ou traite des éléments sensibles liés au paiement.

Apple Pay, Google Pay et wallets tiers : trois réalités différentes

Apple Pay reste une solution très intégrée : l’utilisateur ajoute une carte dans Apple Wallet, puis paie avec Face ID, Touch ID ou le code de l’appareil. L’ouverture du NFC ne supprime pas Apple Pay. Elle permet plutôt à une banque, un établissement financier ou un prestataire de services de paiement autorisé de proposer sa propre application de paiement sans contact sur iPhone.

Les engagements Apple couvrent les développeurs établis dans l’Espace économique européen et les utilisateurs iOS situés dans cette zone. Le périmètre mentionne les iPhone capables d’utiliser les versions actuelles ou futures d’iOS, à partir de l’iPhone XS. Les applications concernées peuvent utiliser des paiements NFC fondés sur HCE, pour Host Card Emulation, une technique qui permet d’émuler une carte de paiement de manière logicielle avec un environnement sécurisé.

Google Wallet fonctionne depuis longtemps sur Android avec un modèle plus ouvert côté NFC. D’après l’aide Google Wallet en 2026, le paiement sans contact nécessite un téléphone Android équipé du NFC, le NFC activé, un moyen de paiement compatible et, selon les cas, la configuration de Google Wallet ou de l’application de paiement par défaut. La différence historique tient donc moins à la puce elle-même qu’aux règles d’accès à cette puce.

Pour un projet digital, l’arbitrage est simple : si vous vendez en ligne, Apple Pay et Google Pay proposés par votre PSP, c’est-à-dire votre prestataire de services de paiement comme Stripe, Adyen, Worldline ou PayPlug, suffisent souvent. Si vous voulez créer un wallet bancaire, une carte privative ou un parcours de paiement en magasin dans votre propre application, vous entrez dans un sujet beaucoup plus réglementé.

Ce que cela change pour une application mobile

L’ouverture du NFC peut intéresser trois familles de projets. D’abord les banques et fintechs qui veulent maîtriser l’expérience de paiement sans contact. Ensuite les enseignes avec carte de fidélité, carte de paiement privative ou parcours de caisse intégré. Enfin certains acteurs B2B, par exemple dans la mobilité, l’accès ou les titres dématérialisés, même si tout ne relève pas du paiement bancaire.

Sur les projets que nous menons, nous voyons souvent une confusion entre « intégrer Apple Pay » et « créer une application de paiement NFC ». Le premier chantier peut parfois être traité en quelques jours via un PSP déjà en place sur un site e-commerce ou une application. Le second suppose des accords financiers, des contrôles de sécurité, des tests sur appareils réels et une gouvernance produit beaucoup plus solide.

Apple indique en 2026 que les développeurs d’applications de paiement utilisant NFC & SE Platform doivent être des institutions financières ou travailler avec un PSP licencié ou autorisé dans les territoires éligibles. Autre point peu visible pour les non-techniciens : les applets du Secure Element doivent être examinées et validées par un laboratoire tiers indépendant accrédité avant livraison à Apple pour installation. C’est rarement compatible avec un calendrier improvisé.

Ce changement rend aussi plus stratégique le choix de l’architecture mobile. Une application native iOS et Android donne le meilleur accès aux fonctions de paiement, biométrie et sécurité, mais coûte plus cher à maintenir. Une approche hybride peut être pertinente pour un parcours commercial classique, moins pour un wallet très intégré au système. Si ce choix est encore ouvert, un cadrage entre développement mobile natif ou hybride évite de reconstruire trop tôt.

Combien prévoir en budget et en délais ?

Les coûts varient fortement selon que vous acceptez un paiement mobile ou que vous créez un moyen de paiement. Pour un dirigeant, c’est l’écart le plus important à comprendre. Ajouter Apple Pay et Google Pay à un tunnel de paiement existant n’a rien à voir avec développer un wallet NFC compatible iPhone et Android.

Ces ordres de grandeur ne remplacent pas un devis, mais ils évitent une erreur classique : comparer un bouton de paiement en ligne avec une infrastructure de paiement. À 10 000 €, mieux vaut presque toujours utiliser les briques d’un PSP reconnu plutôt que tenter de posséder toute la chaîne. Honnêtement, créer son propre wallet NFC ne se justifie que si le paiement est au cœur du modèle économique ou de la relation client.

Le calendrier dépend aussi des validations externes. Un PSP peut imposer sa propre revue. Apple et Google ont leurs critères de publication. Le RGPD, applicable depuis 2018, ajoute des obligations sur les données personnelles : finalité claire, minimisation, sécurité, durée de conservation. Dans le paiement, chaque donnée en trop devient un risque en plus.

Comment accepter le paiement mobile côté commerçant ?

Pour la majorité des PME, le bon sujet n’est pas d’ouvrir le NFC de l’iPhone, mais d’accepter correctement les moyens de paiement mobiles là où le client achète. Sur un site, cela passe par Apple Pay, Google Pay et les cartes bancaires dans un tunnel fluide. En boutique, cela passe par un terminal compatible sans contact ou par des solutions de type Tap to Pay on iPhone selon les pays et les PSP disponibles.

Apple Tap to Pay on iPhone permet à des applications de paiement d’accepter des cartes sans contact, Apple Pay, Apple Watch et d’autres wallets numériques directement sur un iPhone, sans terminal additionnel. Mais il faut intégrer un PSP pris en charge. Là encore, l’absence de matériel supplémentaire ne supprime pas le besoin d’un contrat de paiement, d’une application fiable et d’un support en caisse.

Le meilleur parcours dépend souvent du canal principal. Une boutique locale qui vend aussi en ligne aura plus d’impact en raccordant stock, commande et paiement qu’en cherchant une innovation NFC complexe. Le sujet rejoint directement les stratégies de click and collect pour une boutique locale, quand l’objectif est de réduire les frictions entre web et magasin.

• Si vous vendez surtout en ligne, priorisez un PSP solide, Apple Pay, Google Pay, 3-D Secure et une page de paiement rapide.
• Si vous vendez surtout en magasin, vérifiez la compatibilité sans contact de votre terminal ou l’intérêt d’une solution Tap to Pay selon votre volume.
• Si vous avez une application fidélité, demandez-vous si le paiement intégré améliore vraiment la fréquence d’achat ou s’il complique le support.
• Si vous envisagez un wallet propriétaire, validez d’abord le partenaire financier, le cadre réglementaire et le budget de certification.

Côté agence, le réflexe est de partir du geste client le plus fréquent : payer une commande web, régler au comptoir, retirer une réservation, partager une note, recharger un compte. La technologie vient après. C’est moins séduisant sur une slide, mais beaucoup plus fiable pour tenir un budget.

Les pièges que les non-techniciens sous-estiment

Le premier piège concerne la disponibilité réelle. L’ouverture du NFC s’applique dans l’Espace économique européen, pas automatiquement partout dans le monde. Elle concerne des iPhone compatibles, à partir de l’iPhone XS, avec les versions iOS adéquates. Une application européenne peut donc nécessiter des règles différentes si elle vise aussi le Royaume-Uni, la Suisse, l’Amérique du Nord ou l’Asie.

Deuxième piège : la sécurité ne se résume pas à Face ID. Une application de paiement mobile manipule des sessions, des jetons, parfois des données bancaires indirectes et des droits d’accès. Les API, c’est-à-dire les interfaces par lesquelles l’application échange avec vos serveurs, deviennent une zone sensible. Une revue de sécurité des API mobiles est souvent moins visible qu’un écran de paiement, mais elle protège directement le chiffre d’affaires.

Troisième piège : l’expérience par défaut. Les engagements Apple prévoient que les applications tierces couvertes puissent être définies comme application de paiement sans contact par défaut et accéder à certaines fonctions d’expérience utilisateur comme Field Detect, Double-click, Touch ID, Face ID et le code de l’appareil. C’est essentiel, car un moyen de paiement qui demande trois gestes de trop ne sera pas utilisé.

Dernier point, la recette ne se fait pas seulement dans un simulateur. La documentation Apple précise que certains tests NFC & SE nécessitent du matériel NFC et un iPhone XS ou ultérieur avec une version iOS compatible ; CredentialSession n’est pas pris en charge dans le simulateur pour l’émulation de carte ISO 7816. En clair : prévoyez des appareils réels, des cartes de test, des terminaux et du temps terrain.

Si votre application manipule authentification, paiement et données personnelles, une checklist de sécurité avant publication mobile aide à trier les risques avant la mise en production. Mieux vaut corriger une faiblesse d’authentification pendant la recette que lors d’un incident client.

Le bon arbitrage pour 2026

Pour une PME, le paiement mobile NFC DMA doit être vu comme une ouverture de marché, pas comme une obligation de développement. L’opportunité est réelle pour les acteurs financiers et les grandes enseignes capables d’investir dans un wallet. Pour un e-commerçant ou une application métier, le meilleur retour sur investissement reste souvent d’intégrer proprement Apple Pay, Google Pay et un PSP robuste.

Android garde une logique plus familière pour les wallets tiers, tandis qu’iOS devient plus accessible en Europe sous surveillance réglementaire. La Commission européenne a d’ailleurs publié en mai 2026 une fiche sur l’interopérabilité et la portabilité des données indiquant qu’Apple avait déjà publié des solutions partielles, dont le NFC. Le contexte DMA reste actif, comme le montrent aussi les mesures contraignantes adressées à Google en juillet 2026 sur d’autres sujets d’interopérabilité Android et de partage de données.

Le choix technique doit donc rester proportionné. Pour un parcours e-commerce, concentrez-vous sur le taux de conversion, la confiance et la compatibilité mobile. Pour une application bancaire ou une carte privative, préparez un programme produit complet, avec juristes, PSP, sécurité, design d’expérience et exploitation. Un socle d’ingénierie mobile iOS et Android devient alors indispensable, pas accessoire.

Cadrer ce type de projet en amont évite la plupart des mauvaises surprises : périmètre DMA, choix du PSP, sécurité des API, budget de certification et expérience en caisse. C’est souvent là qu’un regard extérieur fait gagner du temps, avant même la première ligne de code.

FAQ sur le paiement mobile NFC DMA

Le DMA oblige-t-il Apple à ouvrir le NFC de l’iPhone ?

Oui, en pratique dans l’Espace économique européen, via des engagements rendus contraignants par la Commission européenne le 11 juillet 2024. Ils permettent à certaines applications de paiement tierces d’accéder au NFC « tap and go » de l’iPhone sans utiliser Apple Pay ou Apple Wallet.

Une PME peut-elle créer son propre Apple Pay ?

Pas au sens simple du terme. Une PME peut intégrer Apple Pay via un PSP, mais créer un wallet NFC propriétaire demande généralement un partenaire financier autorisé, des validations de sécurité et un budget bien supérieur.

Google Pay est-il concerné par la même ouverture NFC ?

Android permet déjà l’usage du NFC par des applications de paiement selon les conditions du système, du téléphone et du moyen de paiement. Le débat européen a surtout porté sur l’accès au NFC de l’iPhone, historiquement réservé à Apple Pay pour le paiement en magasin.

Tap to Pay on iPhone remplace-t-il un terminal bancaire ?

Il peut remplacer un terminal additionnel dans certains cas, si votre pays, votre PSP et votre application sont compatibles. Cela ne supprime pas le contrat monétique, les frais de paiement ni les besoins de support en point de vente.

Quel est le meilleur choix pour un site e-commerce en 2026 ?

Dans la plupart des cas, utilisez un PSP fiable qui propose cartes bancaires, Apple Pay, Google Pay et 3-D Secure. C’est plus rapide, moins risqué et généralement moins coûteux qu’un développement de paiement propriétaire.