Apple Pay et Google Pay : intégrer les wallets à sa passerelle de paiement en 2026

Qu'est-ce qu'un wallet et pourquoi l'activer sur sa passerelle de paiement ?

Un wallet (portefeuille mobile) comme Apple Pay ou Google Pay stocke de manière sécurisée les cartes bancaires d'un utilisateur sur son smartphone, sa montre connectée ou son navigateur. Au moment de payer, le client n'a plus rien à saisir : il valide la transaction d'un simple regard (Face ID), d'une empreinte digitale ou d'un code. Pour un commerçant, activer ces wallets sur sa passerelle de paiement revient à supprimer la principale friction du checkout : la saisie manuelle des 16 chiffres de la carte, de la date d'expiration et du cryptogramme.

Ces wallets couvrent trois contextes d'usage distincts qu'il faut bien distinguer :

• Le paiement en boutique (proximité NFC) : le smartphone est approché d'un terminal de paiement compatible sans contact. C'est l'usage historique, désormais banalisé — voir notre guide sur le paiement sans contact NFC.
• Le paiement in-app : à l'intérieur d'une application mobile (livraison de repas, transport, e-commerce), via les SDK natifs iOS et Android.
• Le paiement sur le web : sur un site marchand, dans un navigateur, via des API standardisées (Payment Request API, Apple Pay JS). C'est ce dernier cas qui concerne le plus directement l'intégration d'une passerelle de paiement e-commerce.

La bascule vers ces moyens de paiement n'est plus un phénomène marginal. Selon les baromètres du secteur, les wallets représentent désormais plus de la moitié des transactions du commerce en ligne à l'échelle mondiale, et leur part continue de croître de plusieurs points chaque année en Europe, portée par l'équipement massif en smartphones et l'habitude prise en boutique.

Il faut bien comprendre que, techniquement, Apple Pay et Google Pay ne sont pas des moyens de paiement à part entière au sens où le serait un virement ou un prélèvement. Ce sont des couches de présentation et de sécurité qui reposent sur une carte bancaire sous-jacente (Visa, Mastercard, CB) enregistrée dans le wallet. Pour la passerelle, pour l'acquéreur et pour la banque, la transaction reste une opération carte. Cette distinction est capitale : elle explique à la fois pourquoi il n'y a pas de contrat séparé à signer avec Apple ou Google pour le web, pourquoi les frais sont identiques à ceux d'une carte, et pourquoi les wallets s'intègrent aussi facilement à une infrastructure de paiement existante.

La part de marché croissante des wallets

L'essor des wallets est l'une des tendances les plus rapides du paiement de la décennie. Plusieurs facteurs se cumulent : la généralisation du sans contact en boutique pendant la période 2020-2022, l'intégration native des wallets dans les systèmes d'exploitation mobiles, et la préférence marquée des générations plus jeunes pour un paiement sans carte physique.

Quelques repères pour situer l'ampleur du mouvement :

• En ligne : à l'échelle mondiale, les portefeuilles numériques (Apple Pay, Google Pay, PayPal et wallets locaux) sont devenus la première méthode de paiement e-commerce, devant la carte saisie manuellement.
• En boutique : dans les pays européens matures, une part significative des paiements sans contact passe désormais par un smartphone ou une montre plutôt que par une carte physique.
• Sur mobile : c'est là que le poids des wallets est le plus fort, précisément parce qu'ils y suppriment la friction la plus lourde — la saisie d'une carte sur un petit écran.

Pour un marchand, la conséquence pratique est simple : ne pas proposer Apple Pay et Google Pay revient aujourd'hui à laisser une part croissante d'acheteurs face à un tunnel plus long que celui de leurs concurrents. L'enjeu n'est plus d'être innovant, mais de rester au niveau de l'attente standard du consommateur.

Comment fonctionnent Apple Pay et Google Pay ?

Derrière la simplicité apparente du geste se cache une architecture de sécurité sophistiquée, reposant sur trois piliers : la tokenisation réseau, l'authentification biométrique et le cryptogramme dynamique. Comprendre ces mécanismes est essentiel pour dialoguer avec sa passerelle et rassurer les équipes conformité.

La tokenisation réseau (DPAN)

Lorsqu'un utilisateur ajoute sa carte dans un wallet, le vrai numéro de carte (le PAN, Primary Account Number) n'est pas stocké sur l'appareil. À la place, les réseaux Visa, Mastercard et le Groupement Cartes Bancaires génèrent un numéro de carte de substitution appelé DPAN (Device Primary Account Number), propre à cet appareil. Ce token remplace le PAN dans toutes les transactions. Concrètement, si le téléphone est volé ou si le marchand est piraté, le DPAN exposé est inutilisable ailleurs et peut être révoqué sans réémettre la carte physique. Ce mécanisme est une forme aboutie de tokenisation du paiement, gérée directement au niveau des réseaux de cartes.

L'authentification biométrique

Chaque transaction est validée par l'utilisateur au moyen de Face ID, Touch ID (Apple) ou de l'empreinte digitale / du déverrouillage sécurisé de l'appareil (Google). Cette authentification locale, gérée par une puce sécurisée dédiée (Secure Enclave chez Apple), ne transmet jamais les données biométriques au marchand ni à la banque : elle sert uniquement à débloquer la clé cryptographique stockée dans l'appareil. Cette étape constitue une authentification forte du client au sens de la directive DSP2, un point déterminant que nous détaillons plus loin.

Le cryptogramme dynamique

À chaque paiement, l'appareil génère un cryptogramme à usage unique (cryptogramme dynamique), calculé à partir du DPAN et de données propres à la transaction. Contrairement au cryptogramme statique à trois chiffres imprimé au dos d'une carte, ce code ne peut pas être rejoué. Même intercepté, il est inutilisable pour une seconde transaction. C'est cette combinaison DPAN + cryptogramme dynamique qui explique pourquoi le paiement par wallet est considéré comme nettement plus sûr que la saisie manuelle d'une carte.

Le marchand ne reçoit jamais le numéro de carte réel de son client. Il ne manipule qu'un jeton et un cryptogramme, transmis à sa passerelle de paiement puis à l'acquéreur. Cela réduit considérablement sa surface d'exposition et son périmètre PCI-DSS.

Pourquoi les wallets augmentent le taux de conversion

L'argument commercial des wallets n'est pas la sécurité — invisible pour le client — mais la fluidité. Sur mobile, la saisie d'une carte bancaire reste l'un des principaux points d'abandon du tunnel de commande. Chaque champ à remplir sur un petit écran, chaque code 3DS à récupérer par SMS, fait perdre une fraction des acheteurs. Le wallet supprime tout cela : le client passe de l'intention d'achat au paiement validé en deux à trois secondes.

Les effets mesurés par les marchands qui activent ces boutons sont convergents :

• Réduction de l'abandon de panier : l'absence de saisie élimine la friction la plus coûteuse sur mobile, où le taux d'abandon dépasse souvent 75 %.
• Hausse du taux de conversion : les marchands rapportent fréquemment des gains de conversion à deux chiffres sur les sessions mobiles éligibles, en particulier chez les nouveaux clients qui n'ont pas de carte enregistrée.
• Meilleur taux d'autorisation : les données tokenisées et l'authentification embarquée réduisent les refus bancaires et les faux positifs anti-fraude.
• Moins de saisies erronées : plus aucun numéro de carte mal recopié, plus de date d'expiration oubliée.

Pour aller plus loin sur les leviers de checkout, consultez notre guide dédié à l'optimisation du taux de conversion du checkout, dans lequel l'affichage des wallets figure parmi les actions au meilleur rapport effort/résultat.

Il faut aussi mesurer l'effet sur les nouveaux clients, souvent sous-estimé. Un acheteur récurrent dispose généralement d'une carte enregistrée sur le site marchand ; pour lui, le gain de fluidité du wallet est réel mais limité. En revanche, un visiteur qui découvre une boutique pour la première fois n'a rien enregistré : sans wallet, il doit sortir sa carte physique, la recopier, attendre un code 3DS. C'est exactement le moment où l'abandon est maximal. Le bouton Apple Pay ou Google Pay transforme ce parcours en une validation biométrique de deux secondes, en réutilisant les informations déjà présentes dans le téléphone (adresse, e-mail, téléphone). Le gain de conversion se concentre donc là où il compte le plus commercialement : sur l'acquisition.

Un dernier effet mérite d'être souligné : la réduction des impayés et des litiges. Comme la transaction est fortement authentifiée (possession de l'appareil + biométrie), la charge de la preuve en cas de contestation penche davantage du côté du porteur. Combiné à des taux d'autorisation plus élevés, cela améliore la qualité globale du flux de paiement, un point que les directions financières apprécient autant que les équipes marketing.

Apple Pay vs Google Pay : ce qui les distingue

Du point de vue du marchand, les deux wallets fonctionnent de manière très similaire et s'activent souvent d'un même geste dans la passerelle. Quelques différences techniques et d'écosystème méritent toutefois d'être connues.

Critère	Apple Pay	Google Pay
Éditeur	Apple	Google
Appareils	iPhone, iPad, Mac, Apple Watch	Android, Wear OS, Chrome (tous OS)
Navigateur web	Safari uniquement	Chrome et navigateurs Android
Authentification	Face ID / Touch ID	Empreinte / déverrouillage sécurisé
Tokenisation	DPAN + Secure Enclave	DPAN (cartes tokenisées) ou cryptogramme selon la carte
Vérification de domaine web	Obligatoire	Non requise
API web	Apple Pay JS / Payment Request API	Google Pay API / Payment Request API
Coût pour le marchand	Aucun surcoût wallet	Aucun surcoût wallet

La distinction la plus structurante concerne le web : Apple Pay est strictement limité à Safari et impose une vérification de domaine, tandis que Google Pay s'affiche dans Chrome quel que soit le système d'exploitation et ne demande pas cette étape. En pratique, la passerelle détecte l'appareil et le navigateur du visiteur pour n'afficher que le bouton réellement utilisable — inutile de proposer Apple Pay à un utilisateur Android.

Intégrer les wallets côté passerelle de paiement

La bonne nouvelle pour les marchands est qu'il n'est presque jamais nécessaire d'intégrer directement Apple ou Google. Les grandes passerelles agissent comme intermédiaires : elles gèrent les certificats, la relation avec Apple et Google, le déchiffrement des tokens et la conversion en une transaction carte classique. Le marchand active un bouton, la passerelle fait le reste.

Les passerelles qui supportent les wallets

La quasi-totalité des passerelles modernes proposent Apple Pay et Google Pay en standard : Stripe, Adyen, Mollie, PayPlug, Checkout.com, mais aussi Worldline, Stancer ou Lyra. L'activation se fait généralement depuis le tableau de bord, parfois en une case à cocher. Si vous hésitez encore sur le socle à retenir, notre comparatif Stripe vs Adyen détaille les différences de modèle entre ces deux références.

Les technologies d'intégration web

• Payment Request API : une API web standardisée (W3C) qui expose une interface unifiée. La passerelle s'appuie dessus pour afficher Apple Pay sur Safari et Google Pay sur Chrome via le même code. C'est l'approche recommandée par la plupart des SDK modernes (Stripe Payment Element, par exemple).
• Apple Pay JS : l'API historique et propriétaire d'Apple, plus verbeuse mais offrant un contrôle fin de la feuille de paiement (récapitulatif, options de livraison, contacts).
• Google Pay API : l'équivalent côté Google, avec son propre bouton et sa configuration de méthodes de paiement autorisées.
• SDK natifs in-app : pour les applications mobiles, les kits Apple (PassKit) et Google Pay s'intègrent directement, la passerelle fournissant un wrapper.

La vérification de domaine et les certificats Apple Pay

Apple Pay sur le web impose une étape spécifique : le domaine du site marchand doit être enregistré et vérifié. Concrètement, un fichier de vérification (apple-developer-merchantid-domain-association) est déposé dans le répertoire /.well-known/ du site, ou la vérification est gérée automatiquement par la passerelle depuis son propre domaine enregistré. Un certificat de traitement des paiements (Merchant Identity Certificate) est également nécessaire — là encore, Stripe, Adyen ou Checkout.com le fournissent et le renouvellent à votre place lorsque vous passez par leur intégration hébergée. Cette délégation est le principal avantage à passer par une passerelle plutôt que par une intégration Apple directe.

Passerelle	Apple Pay	Google Pay	Vérif. domaine gérée	Effort d'intégration
Stripe	Oui	Oui	Automatique (Payment Element)	Faible
Adyen	Oui	Oui	Certificat fourni	Moyen
Mollie	Oui	Oui	Automatique	Faible
PayPlug	Oui	Oui	Automatique (module e-commerce)	Très faible
Checkout.com	Oui	Oui	Certificat fourni	Moyen

Pour un site sous PrestaShop, WooCommerce ou Shopify, l'activation est souvent réduite à l'installation d'un module et à un interrupteur : le prestataire a déjà réglé la question des certificats. C'est notamment ce que recherchent les marchands lors du choix d'une passerelle pour l'e-commerce.

Le déroulé technique d'une transaction wallet

Pour bien comprendre ce que fait la passerelle, il est utile de dérouler le cheminement complet d'un paiement Apple Pay ou Google Pay sur le web :

• Détection : le script de la passerelle interroge le navigateur pour savoir si le wallet est disponible et si l'utilisateur a une carte enregistrée.
• Affichage : si oui, le bouton normalisé est présenté. Sinon, il est masqué.
• Feuille de paiement : au clic, le système d'exploitation affiche sa propre feuille de paiement (récapitulatif du montant, carte, adresse). Le marchand ne contrôle pas cet écran natif.
• Authentification : le client valide par Face ID, Touch ID ou empreinte.
• Génération du jeton : l'appareil produit un paquet chiffré contenant le DPAN et le cryptogramme dynamique, chiffré à destination de la passerelle.
• Déchiffrement et traitement : la passerelle déchiffre le paquet grâce à son certificat, reconstitue une transaction carte et l'envoie à l'acquéreur puis au réseau.
• Autorisation : la banque émettrice autorise (ou refuse), la réponse remonte, et le marchand reçoit une confirmation classique via son intégration ou son webhook.

Du point de vue du code marchand, l'essentiel de cette mécanique est masqué : le SDK de la passerelle expose un objet de paiement, gère la feuille native et renvoie un identifiant de transaction. C'est cette abstraction qui rend l'intégration accessible même à une petite équipe.

Frais : y a-t-il un surcoût wallet ?

C'est l'une des questions les plus fréquentes, et la réponse est claire : non, il n'y a pas de surcoût pour le marchand. Une transaction réglée via Apple Pay ou Google Pay est facturée par la passerelle exactement comme une transaction carte, puisque techniquement, c'en est une. Le wallet n'est qu'une couche d'habillage sécurisée par-dessus une carte Visa, Mastercard ou CB.

Concrètement, si votre passerelle facture par exemple 1,5 % + 0,25 € par transaction carte européenne (tarif de référence chez Stripe), une transaction Apple Pay ou Google Pay portant sur le même montant coûtera le même 1,5 % + 0,25 €. Contrairement à ce qui existe sur certains marchés hors Europe, Apple et Google ne prélèvent aucune commission sur le commerçant en zone européenne pour ces paiements web et in-app. La structure de coût reste donc gouvernée par les mêmes composantes qu'une carte classique :

• L'interchange, plafonné en Europe à 0,2 % pour les cartes de débit et 0,3 % pour les cartes de crédit grand public ;
• Les commissions réseau (Visa, Mastercard, CB) ;
• La marge de la passerelle / de l'acquéreur.

Autrement dit, activer les wallets améliore la conversion sans détériorer la marge. C'est précisément ce qui en fait un des rares leviers « gratuits » du paiement en ligne. Pour comprendre la composition détaillée de ces coûts, notre article sur les frais de passerelle est un bon point de départ.

Une nuance mérite d'être posée pour éviter les malentendus. Le fait qu'Apple et Google ne prélèvent pas de commission commerçant en Europe sur ces paiements ne signifie pas qu'ils ne se rémunèrent pas du tout : sur certains marchés, notamment aux États-Unis, ils perçoivent une fraction de l'interchange auprès des banques émettrices (et non du marchand). Pour un commerçant européen, cela reste sans effet : le tarif affiché par sa passerelle est le tarif final, wallet ou pas. Il ne faut donc pas confondre le modèle économique global de ces géants avec ce que paie réellement le marchand, qui, lui, ne voit aucune ligne supplémentaire sur sa facture.

Attention en revanche à un point souvent négligé : si votre passerelle applique une tarification différenciée selon le type de carte (modèle interchange++), le coût d'une transaction wallet dépendra de la carte sous-jacente exactement comme pour une saisie manuelle. Un paiement Apple Pay adossé à une carte corporate premium coûtera plus cher qu'un paiement adossé à une carte de débit grand public — non pas à cause du wallet, mais à cause de la carte. Le wallet est neutre sur le prix ; c'est toujours la carte qui le détermine.

Compatibilité 3DS, SCA et DSP2

Depuis l'entrée en vigueur complète de la DSP2, la plupart des paiements en ligne européens doivent faire l'objet d'une authentification forte du client (SCA), combinant au moins deux facteurs parmi : ce que le client possède (l'appareil), ce qu'il est (biométrie) et ce qu'il sait (code). Or, un paiement par wallet coche naturellement ces cases : l'appareil (possession) + Face ID ou empreinte (inhérence).

Conséquence directe et très avantageuse : dans la majorité des cas, un paiement Apple Pay ou Google Pay est considéré comme déjà authentifié, ce qui permet d'éviter l'écran 3D Secure supplémentaire (redirection vers la banque, code par SMS). L'authentification est réputée effectuée localement sur l'appareil. Cela supprime une étape supplémentaire d'abandon et explique en partie les meilleurs taux de conversion et d'autorisation observés.

Quelques nuances subsistent : selon l'émetteur de la carte et le niveau de risque estimé, une banque peut occasionnellement exiger un 3DS complémentaire. Les passerelles gèrent ce repli automatiquement. Sur l'ensemble des enjeux de conformité et de protection des données de paiement, consultez notre dossier sur la sécurité du paiement en ligne.

Bonnes pratiques d'affichage du bouton

Activer techniquement les wallets ne suffit pas : encore faut-il que le client les voie et les utilise. L'affichage du bouton obéit à des règles de marque strictes (Apple et Google imposent des chartes) et à des principes d'ergonomie éprouvés.

• Afficher le bouton haut dans le tunnel : proposer le wallet en express checkout, dès la page panier ou en haut de la page de paiement, avant même la saisie d'adresse. Le wallet peut remonter l'adresse de livraison et l'e-mail, court-circuitant plusieurs étapes.
• Ne montrer que le bouton pertinent : Apple Pay uniquement aux utilisateurs Safari/iOS éligibles, Google Pay aux utilisateurs Chrome/Android. Un bouton non fonctionnel dégrade la confiance.
• Respecter les chartes graphiques : logo, libellé (« Payer avec Apple Pay »), couleurs et coins arrondis sont normalisés. Les SDK fournissent des boutons conformes prêts à l'emploi.
• Détecter la disponibilité avant d'afficher : les API exposent une méthode (canMakePayments) qui indique si l'utilisateur a bien une carte enregistrée. N'affichez le bouton que si le paiement est réellement possible.
• Ne pas cannibaliser le formulaire carte : le wallet est un raccourci, pas un remplacement. Gardez le paiement carte classique disponible pour les clients sans wallet.

La règle d'or : le bouton wallet doit apparaître le plus tôt possible, uniquement quand il est utilisable, et ne jamais imposer de saisie préalable. C'est cette combinaison qui capte le gain de conversion.

Pensez enfin à tester le parcours sur de vrais appareils. Le comportement d'Apple Pay sur un iPhone récent, sur un Mac avec Touch ID ou via un iPhone appairé à un Mac diffère subtilement, tout comme Google Pay entre Android et Chrome desktop. Un recette réalisée uniquement sur un émulateur ou un navigateur de bureau passe souvent à côté de cas réels. De même, surveillez vos indicateurs après activation : taux d'affichage du bouton, taux de clic, taux de conversion post-clic et taux d'autorisation. Ces métriques, remontées par la plupart des tableaux de bord de passerelle, permettent de vérifier que le levier produit bien l'effet attendu et d'ajuster l'emplacement du bouton si nécessaire.

Questions fréquentes

Apple Pay et Google Pay coûtent-ils plus cher qu'un paiement par carte ?

Non. Pour un commerçant, une transaction Apple Pay ou Google Pay est facturée au même tarif qu'une transaction carte classique par la passerelle de paiement. Il n'existe pas de surcoût wallet répercuté sur le marchand en Europe : Apple et Google ne prélèvent pas de commission commerçant sur ces paiements web et in-app.

Faut-il vérifier son domaine pour activer Apple Pay sur le web ?

Oui, pour Apple Pay uniquement. Le domaine doit être enregistré et validé, soit par le dépôt d'un fichier de vérification dans le répertoire /.well-known/, soit automatiquement par la passerelle qui gère la vérification depuis son propre domaine enregistré. Google Pay n'impose pas cette étape.

Apple Pay et Google Pay sont-ils compatibles avec l'authentification SCA/3DS ?

Oui. L'authentification biométrique du wallet (Face ID, Touch ID, empreinte) constitue une authentification forte reconnue au titre de la DSP2. Dans la plupart des cas, cela permet d'éviter l'écran 3D Secure supplémentaire, tout en restant conforme. Une banque émettrice peut toutefois occasionnellement exiger un 3DS complémentaire selon le niveau de risque.

Quels navigateurs et appareils supportent ces wallets ?

Apple Pay fonctionne sur Safari (macOS, iOS, iPadOS) et les appareils Apple. Google Pay fonctionne sur Chrome et les navigateurs Android, ainsi que sur Chrome desktop quel que soit le système. La passerelle détecte l'environnement du visiteur et affiche automatiquement le bouton pertinent.

Le numéro de carte est-il transmis au marchand ?

Non. Le wallet transmet un numéro tokenisé (DPAN) propre à l'appareil et un cryptogramme dynamique à usage unique. Le vrai numéro de carte (PAN) n'est jamais communiqué au commerçant ni stocké sur son site, ce qui réduit fortement son exposition et son périmètre PCI-DSS.

Faut-il un développeur pour activer les wallets ?

Pas nécessairement. Sur un CMS e-commerce (Shopify, WooCommerce, PrestaShop) avec un module de passerelle comme PayPlug, Stripe ou Mollie, l'activation se résume souvent à cocher une option. Une intégration sur mesure (site headless, application) demande en revanche un développeur pour brancher la Payment Request API ou les SDK natifs.