Découvrez ce qu'est Apple Pay dans les applications mobiles, comment il fonctionne en coulisses et comment l'intégrer de façon sécurisée pour accélérer le paiement et améliorer la conversion.
Apple Pay est le portefeuille numérique et le service de paiement d’Apple. Il permet aux utilisateurs de stocker des cartes de crédit, de débit, certaines cartes prépayées et cartes magasin de façon sécurisée sur leur iPhone, Apple Watch, iPad ou Mac, et de payer d’un simple tapotement ou regard.
Au lieu de saisir les numéros de carte et les informations de facturation, l’utilisateur s’authentifie avec Face ID, Touch ID ou le code de l’appareil. Apple génère un jeton spécifique à l’appareil pour que le numéro réel de la carte ne soit pas partagé avec le marchand.
Apple Pay fonctionne dans trois contextes principaux :
Ce guide se concentre sur Apple Pay in‑app, où toute l’expérience de paiement reste à l’intérieur de l’application.
Saisir des données de carte sur un petit écran est lent et source d’erreurs. Apple Pay remplace plusieurs champs par une seule interaction, ce qui :
Comme les cartes et adresses sont déjà stockées sur l’appareil, Apple Pay réduit aussi les frictions pour les nouveaux clients.
Apple Pay fonctionne sur des modèles récents d’iPhone, iPad, Apple Watch et Mac dans les régions prises en charge, avec les principaux réseaux (Visa, Mastercard, American Express) et certains réseaux locaux selon la banque émettrice.
Apple Pay est particulièrement adapté si :
Il doit fonctionner en parallèle des formulaires de carte classiques et d’autres portefeuilles, pas les remplacer entièrement, afin que les utilisateurs non‑éligibles puissent toujours payer.
Apple Pay cache beaucoup de complexité derrière une expérience simple de type « double‑clic pour payer ». Plusieurs acteurs et couches de sécurité se coordonnent pour déplacer l’argent en toute sécurité.
Une transaction Apple Pay typique implique :
Quand un utilisateur ajoute une carte au Wallet, le numéro réel de la carte (le FPAN, Funding Primary Account Number) est envoyé de façon sécurisée au réseau et à l’émetteur. Ils renvoient un DPAN (Device Primary Account Number) et des clés cryptographiques uniques pour cet appareil.
Le DPAN est utilisé par Apple Pay lors des transactions. Votre app et votre backend ne voient jamais le FPAN. C’est le cœur du modèle de tokenisation d’Apple Pay : l’appareil utilise un numéro de carte de substitution et des cryptogrammes à usage unique au lieu d’exposer la vraie carte.
Sur les appareils pris en charge, les identifiants et clés de paiement résident dans le Secure Element (ou sont protégés par le Secure Enclave). Quand l’utilisateur s’authentifie (Face ID, Touch ID ou code), le Secure Element :
Votre app reçoit ce jeton opaque et chiffré via les API Apple Pay et l’envoie à votre backend, qui le transmet au PSP ou à la passerelle.
Le PSP déchiffre le jeton, extrait le DPAN et le cryptogramme, puis soumet une demande d’autorisation via le réseau de carte à la banque émettrice. L’émetteur valide le cryptogramme et l’état de la carte, puis approuve ou refuse.
Plus tard, lors du règlement, le montant autorisé est capturé, agrégé et transféré de la banque émettrice vers la banque acquéreuse du marchand. Pour votre app, cela se traduit par une capture ou l’achèvement d’une vente, mais en coulisses c’est coordonné entre acquéreur, réseau et émetteur en utilisant le DPAN — pas le numéro réel de la carte.
Avant d’ajouter Apple Pay à votre app, vous devez satisfaire des conditions techniques, commerciales et régionales.
Du côté marchand, vous devez avoir :
Beaucoup de marchands créent aussi un certificat d’identité marchand pour la validation lors de flux web ou hybrides.
Apple Pay in‑app est pris en charge sur :
Vérifiez la documentation Apple pour le support minimal si vous comptez utiliser de nouvelles API.
Apple Pay n’est pas disponible dans tous les pays ni pour toutes les banques. Confirmez :
Apple peut restreindre certaines catégories marchandes et cas d’usage (ex. : biens illégaux, certains contenus numériques, secteurs à haut risque). Vérifiez que :
Enfin, vous avez besoin d’un PSP ou d’une passerelle qui prend en charge la tokenisation Apple Pay et le déchiffrement. Confirmez que votre fournisseur :
Un flux Apple Pay fluide est presque invisible pour l’utilisateur. Voici le déroulé type.
Le parcours commence généralement sur une page produit ou l’écran panier. Une fois les options choisies (taille, couleur, quantité), l’utilisateur passe au checkout.
Sur l’écran de paiement ou le panier, affichez le bouton Apple Pay standard fourni par Apple. Il doit :
Quand l’utilisateur appuie sur le bouton, la feuille Apple Pay remonte depuis le bas de l’écran.
La feuille inclut généralement :
L’utilisateur peut ajuster la carte, l’adresse ou les contacts directement dans la feuille avant de confirmer.
Pour autoriser le paiement, l’utilisateur s’authentifie avec :
La feuille invite clairement l’utilisateur, par exemple : « Appuyez deux fois pour payer » sur les appareils Face ID.
Après authentification, la feuille indique la progression puis disparaît pour revenir à votre app.
Votre app doit immédiatement afficher un état clair :
Des états clairs rassurent l’utilisateur et évitent toute ambiguïté sur le statut du paiement.
L’implémentation repose sur le framework PassKit et quelques classes clés. Voici le flux côté app.
Cela lie le bundle de l’app à votre identité marchande pour que les jetons Apple Pay puissent être générés pour votre serveur.
PKPaymentRequestimport PassKit
func createPaymentRequest() -> PKPaymentRequest? {
guard PKPaymentAuthorizationController.canMakePayments() else { return nil }
let request = PKPaymentRequest()
request.merchantIdentifier = "merchant.com.yourcompany.app"
request.countryCode = "US"
request.currencyCode = "USD"
request.supportedNetworks = [.visa, .masterCard, .amex]
request.merchantCapabilities = [.capability3DS]
request.paymentSummaryItems = [
PKPaymentSummaryItem(label: "Pro Subscription", amount: 9.99),
PKPaymentSummaryItem(label: "Your Company", amount: 9.99)
]
return request
}
merchantIdentifier, countryCode et currencyCode doivent correspondre à votre configuration marchande. supportedNetworks reflète les schémas de carte que vous et votre PSP supportez. Incluez au minimum .capability3DS dans merchantCapabilities.
PKPaymentButtonUtilisez PKPaymentButton plutôt que des boutons personnalisés pour respecter les guidelines Apple :
let payButton = PKPaymentButton(paymentButtonType: .buy, paymentButtonStyle: .black)
Placez‑le là où l’intention d’achat est la plus forte : page produit, panier et étape finale de checkout. Désactivez‑le ou masquez‑le si PKPaymentAuthorizationController.canMakePayments() retourne false.
PKPaymentAuthorizationController et gérer les callbacksCréez le contrôleur à partir de la requête et conformez‑vous à PKPaymentAuthorizationControllerDelegate :
func startApplePay() {
guard let request = createPaymentRequest() else { return }
let controller = PKPaymentAuthorizationController(paymentRequest: request)
controller.delegate = self
controller.present(completion: nil)
}
extension CheckoutViewController: PKPaymentAuthorizationControllerDelegate {
func paymentAuthorizationController(_ controller: PKPaymentAuthorizationController,
didAuthorizePayment payment: PKPayment,
handler completion: @escaping (PKPaymentAuthorizationResult) -> Void) {
// Send payment.token to your server for processing
// Then call completion(.init(status: .success, errors: nil)) or .failure
}
func paymentAuthorizationControllerDidFinish(_ controller: PKPaymentAuthorizationController) {
controller.dismiss(completion: nil)
}
}
La méthode didAuthorizePayment est l’endroit où vous transmettez payment.token à votre backend pour facturation. Après la réponse du serveur, appelez .success ou .failure, puis fermez la feuille dans paymentAuthorizationControllerDidFinish.
La logique serveur transforme la feuille Apple Pay en mouvement d’argent réel. L’app collecte l’autorisation utilisateur ; votre backend valide le marchand, traite le jeton et communique avec la passerelle.
Avant d’afficher la feuille, votre app doit obtenir une session marchande d’Apple :
PKPaymentAuthorizationController.Ce flux prouve à Apple que l’app est associée à votre identité marchande et à votre domaine.
Après l’autorisation, l’app reçoit un jeton de paiement chiffré (PKPaymentToken) et l’envoie à votre backend via HTTPS.
Côté serveur :
La passerelle déchiffre le jeton (utilisant tokens réseau ou DPANs) et exécute l’autorisation auprès des réseaux de cartes.
Les gateways proposent généralement deux flux :
Votre backend doit conserver l’ID de transaction du gateway, le montant, la devise et le statut — mais pas les données brutes de carte ni le contenu déchiffré du jeton.
Conservez uniquement ce qui est nécessaire pour la réconciliation, les remboursements et le support :
Ne stockez jamais les numéros de carte complets, le CVV ou les jetons de paiement non chiffrés sur vos serveurs. Externalisez la gestion sensible à des gateways conformes PCI et assurez-vous que toutes les communications passent par TLS avec journaux et contrôles d’accès stricts.
Apple Pay est conçu pour que votre app ne manipule jamais les numéros de carte en clair, mais vous devez comprendre le modèle de sécurité et vos responsabilités.
Quand un utilisateur ajoute une carte, l’émetteur et le réseau remplacent le PAN par un Device Account Number (DAN).
Lors d’un paiement :
Votre app et backend ne voient que des tokens et métadonnées, pas les détails de la carte.
Les clés sensibles et identifiants sont stockés et traités dans le Secure Enclave, un coprocesseur isolé matériellement.
L’autorisation est liée à la vérification utilisateur : Face ID / Touch ID ou le code de l’appareil. Votre app reçoit seulement un signal de succès ou d’échec de la feuille système ; elle n’accède jamais aux données biométriques ni au contenu du Secure Enclave.
Chaque transaction Apple Pay utilise :
Les réseaux et émetteurs valident ces valeurs pour détecter clonage, rejeu et altération.
Apple Pay peut réduire significativement la portée PCI DSS de votre app car :
Cependant :
Pour des conseils formels, consultez votre banque acquéreuse, votre PSP et un évaluateur de sécurité qualifié.
Apple Pay réduit le risque, mais de mauvaises pratiques peuvent réintroduire des expositions.
Conseils pratiques :
En respectant ces limites, vous tirez parti des protections d’Apple Pay tout en gardant votre charge de conformité gérable.
Des tests complets sont nécessaires pour garantir que votre intégration fonctionne correctement pour vos clients. Commencez par un sandbox et un plan de test clair.
Dans Apple Developer / App Store Connect, créez des comptes sandbox sous Users and Access → Sandbox. Ces Apple IDs spéciaux sont utilisés sur des appareils de test pour simuler des utilisateurs sans débit réel.
Sur vos appareils de test :
Utilisez des testeurs sandbox séparés pour différents profils (régions, devises, réseaux) pour reproduire les cas limites de manière fiable.
Le simulateur iOS supporte des tests Apple Pay basiques, utile pour valider l’UI rapidement. Vous pouvez simuler l’autorisation et vérifier le flux PKPaymentAuthorizationController.
Cependant, validez toujours sur appareils physiques car seuls eux fournissent :
Considérez le simulateur comme un outil pratique, pas un remplacement.
Couvrez au minimum les flux suivants bout en bout (client + serveur) :
Utilisez les numéros et triggers de test du gateway pour forcer les refus et codes d’erreur.
Journalisez assez pour tracer les problèmes, mais sans données sensibles. Évitez :
Journalisez plutôt :
created → authorized → captured → failed)Corrélez les logs client et serveur via un ID de corrélation partagé envoyé de l’app au backend.
Pendant les cycles de test, surveillez :
En cas d’erreurs intermittentes ou de lenteurs, vérifiez d’abord l’état du gateway et d’Apple avant d’imputer un bug d’intégration.
Un design réfléchi peut transformer Apple Pay en un vrai moteur de conversion. De petits choix de placement et de libellé ont un grand impact.
Placez Apple Pay là où l’intention d’achat est la plus forte :
Évitez de cacher Apple Pay derrière des taps supplémentaires (« Plus d’options de paiement ») : chaque étape en plus réduit l’utilisation.
Proposez Apple Pay comme checkout express depuis :
Quand Apple Pay est utilisé en express, précisez que la livraison et les contacts seront traités pendant l’autorisation Apple Pay.
Suivez les Human Interface Guidelines d’Apple :
Évitez les couleurs personnalisées ou icônes qui nuisent à la reconnaissance ou violent les règles de marque.
Laissez Apple Pay faire le travail :
L’objectif est un tap décisif, pas un tunnel multi‑écran.
Évitez les états d’échec confus. Préparez :
Journalisez les erreurs pour votre équipe, mais affichez aux utilisateurs uniquement l’essentiel.
La plupart des problèmes viennent d’une mauvaise configuration.
Confirmez que le merchant ID dans le code correspond exactement à celui du compte Apple Developer et des réglages du gateway. Une seule erreur de caractère (ou un merchant ID sandbox en prod) casse le flux.
Vérifiez aussi les entitlements et capacités :
Si le bouton Apple Pay n’apparaît pas ou que la feuille ne se présente pas, la configuration est souvent en cause.
Apple Pay peut être disponible pour certains pays, émetteurs ou appareils mais pas pour d’autres.
Utilisez PKPaymentAuthorizationController.canMakePayments() et canMakePayments(usingNetworks:) avant d’afficher le bouton. Si elles retournent false, cachez le bouton et proposez une explication claire et une méthode alternative.
Quand des utilisateurs signalent que leur carte « n’est pas supportée », vérifiez :
Les échecs de validation marchande se traduisent souvent par une feuille qui se ferme rapidement ou qui ne s’ouvre jamais.
Causés généralement par :
Côté serveur, logguez :
Ces informations pointent souvent directement l’élément mal configuré.
Tous les échecs ne sont pas techniques : beaucoup sont des refus par l’émetteur.
Inspectez la réponse du gateway et distinguez :
Cartographiez ces catégories vers des messages utilisateurs conviviaux : « Votre banque a refusé ce paiement. Essayez une autre carte ou contactez votre banque. » Évitez d’afficher des codes d’erreur bruts.
Pour maintenir Apple Pay en production, investissez dans le logging structuré autour de chaque tentative de paiement :
Mettez en place des tableaux de bord et alertes pour les pics de refus, d’erreurs de validation marchande ou de timeouts. Corrélez les événements client et serveur pour localiser rapidement la source des problèmes.
Cette observabilité réduit fortement le temps de résolution en production.
Une fois Apple Pay déployé, il faut prouver qu’il améliore vraiment le checkout, pas seulement qu’il est moderne. Suivez les bons événements, surveillez les métriques clés et réalisez des expériences structurées.
Loggez le funnel et les étapes :
Corrélez avec le contexte : emplacement du bouton (produit, panier, checkout), plate‑forme, version OS, nouveau vs client récurrent.
Concentrez‑vous sur :
Suivez ces indicateurs par version d’app et device pour évaluer l’impact des modifications.
Expérimentez :
Mesurez adoption, taux de succès, temps de paiement et conversion.
Intégrez les analytics en respectant la confidentialité :
Les plateformes majeures (Mixpanel, Amplitude, Firebase) peuvent gérer ces événements si vous évitez d’y inclure des données de paiement sensibles.
Les insights Apple Pay servent l’ensemble du tunnel :
Avec le temps, ces mesures affineront l’ensemble du parcours de paiement.
Soutenir Apple Pay dépasse rarement une seule app iOS. Les utilisateurs veulent payer de la même façon sur différents canaux.
Les apps natives utilisent PKPaymentAuthorizationController et transmettent les jetons directement au backend, offrant :
Apple Pay sur le web (Safari) utilise JavaScript et Payment Request API. C’est utile si :
Beaucoup d’équipes optent pour : Apple Pay natif dans l’app, Apple Pay web dans Safari, avec une pipeline serveur de paiement partagée.
Si vous supportez aussi Google Pay, PayPal ou autres, alignez le flow global :
Ainsi, changer de device ou de méthode ne demande pas d’apprentissage à l’utilisateur.
Pour React Native, Flutter et autres, vous utiliserez généralement :
Testez sur iPhone, iPad et Apple Watch si pertinent : vérifiez réseaux supportés, options d’expédition et styles de bouton sur chaque appareil.
Visez un système de design et une logique de checkout partagée, avec de petites couches d’intégration par canal.
Garder Apple Pay opérationnel tient plus de la maintenance disciplinée que des réécritures majeures.
Apple Pay repose sur des merchant IDs et des certificats de traitement qui expirent.
Créez une cartographie des propriétaires : qui gère le compte Apple Developer, où résident les certificats, comment ils sont utilisés en CI/CD et sur les serveurs.
Ensuite :
Chaque version majeure d’iOS doit déclencher un cycle de tests Apple Pay sur bêtas et builds finaux. Concentrez‑vous sur :
Surveillez :
Faites une revue design au moins une fois par an pour aligner wording, placement et accessibilité.
Les réseaux et régions changent. Rendez‑les configurables :
Coordonnez‑vous avec votre gateway quand ils ajoutent des réseaux locaux et mettez à jour PKPaymentRequest en conséquence.
Pour changements de gateway, restructure ou nouveau format de token :
Documentez les flux pour que les nouveaux arrivants maintiennent l’intégration sans rétro‑ingénierie.
Attendez‑vous à plus de tokenisation, des reçus et mises à jour d’ordres enrichis dans Wallet, et des liens plus étroits entre in‑app, web et en‑magasin Apple Pay. Des fonctionnalités comme Tap to Pay sur iPhone et des options de financement régionales se développeront : concevez votre intégration pour qu’elle soit pilotée par configuration et prête à adopter de nouvelles capacités sans réécrire le cœur.
Apple Pay est le portefeuille numérique d’Apple qui permet aux utilisateurs de payer avec les cartes stockées sur leur iPhone, iPad, Apple Watch ou Mac.
Dans les applications mobiles, il remplace la saisie manuelle des informations de carte par une feuille système sécurisée où l’utilisateur confirme le paiement via Face ID, Touch ID ou le code de l’appareil. L’application reçoit un jeton de paiement chiffré au lieu des données brutes de la carte, qu’elle envoie ensuite à votre backend et à votre passerelle de paiement pour réaliser la transaction.
Cela accélère le paiement, réduit les erreurs et évite que les numéros de carte transitent par votre infrastructure.
Vous devriez ajouter Apple Pay lorsque :
Apple Pay fonctionne mieux comme une option supplémentaire en parallèle des formulaires de carte, PayPal, etc. Ne supprimez pas les autres méthodes : offrez Apple Pay comme le chemin le plus rapide pour les utilisateurs éligibles.
Au minimum, vous devez disposer de :
Sur iOS, vous :
L’appareil crée un jeton de paiement chiffré qui contient :
Ce jeton est chiffré pour votre processeur de paiement, donc votre application et votre backend le traitent comme un objet opaque. Votre backend le transmet au gateway, qui le déchiffre, envoie la demande d’autorisation au réseau et à la banque émettrice, puis renvoie succès ou échec.
Vous ne voyez jamais le PAN réel ni les clés cryptographiques ; seules les métadonnées et le statut de la transaction vous sont accessibles.
Votre backend doit :
Ne tentez pas de déchiffrer les jetons vous‑même ni de les stocker longtemps. Laissez votre gateway PCI‑compliant traiter les données sensibles.
Les causes fréquentes sont :
Vérifiez d’abord la configuration dans le portail Apple Developer, les entitlements dans Xcode et les réglages du gateway, puis inspectez les logs serveur pour les erreurs de validation marchande et les codes d’erreur du gateway.
Pour tester Apple Pay en toute sécurité :
Le simulateur permet des vérifications UI rapides, mais validez toujours sur des appareils physiques pour tester Wallet, biométrie et conditions réseaux réelles.
Pour améliorer la conversion :
Trackez Apple Pay comme un funnel séparé. Événements utiles :
Vous devez aussi opérer dans des régions et auprès de banques qui supportent Apple Pay et vous assurer que votre catégorie marchande et vos produits sont conformes aux règles d’Apple.
PKPaymentRequest avec l’identifiant marchand, le pays, la devise, les réseaux supportés et les éléments de synthèse.PKPaymentButton à l’endroit où l’utilisateur décide de payer.PKPaymentAuthorizationController avec la requête.didAuthorizePayment, envoyez payment.token à votre backend pour traitement..success ou .failure et fermez la feuille.La majorité du travail lourd (biométrie, création du jeton) est gérée par l’UI système.
PKPaymentButton officiel avec le bon branding et un texte d’accompagnement clair (ex. : « Payer instantanément avec Apple Pay »).Ces pratiques réduisent les frictions et rendent Apple Pay rapide et fiable.
Indicateurs clés : taux d’adoption Apple Pay, taux de succès (captures), temps jusqu’au paiement, AOV comparé aux autres méthodes, et taux de complétion du checkout. Faites des tests A/B sur emplacement et wording pour mesurer l’impact.