Passkeys pour les prestataires de paiement : comment créer un SDK tiers

Les passkeys s'imposent comme la méthode la plus efficace pour sécuriser et autoriser les transactions en ligne, améliorant considérablement la sécurité et la commodité par rapport à l'authentification multifacteur (MFA) traditionnelle. Récemment, PayPal a adopté les passkeys comme principale solution MFA autonome, lançant une tendance claire pour les prestataires de paiement du monde entier.

Cependant, les passkeys ont été initialement conçus pour des contextes dits « first-party », ce qui signifie qu'ils fonctionnent de manière optimale lorsque les utilisateurs s'authentifient directement sur le site web ou l'application qui détient les informations d'identification. Les prestataires de paiement, en revanche, opèrent généralement dans des contextes tiers, où leurs services (tels que les formulaires de paiement ou les SDK) sont intégrés aux sites web et applications des commerçants. Cette inadéquation fondamentale entre la conception des passkeys et les modèles opérationnels des prestataires de paiement présente des limites critiques pour une intégration transparente. Pour relever ces défis, nous devons explorer deux questions essentielles :

1. Quelles sont les limites actuelles de l'utilisation des passkeys dans des contextes tiers pour les prestataires de paiement ? 2. Comment les prestataires de paiement peuvent-ils surmonter ces limites pour réussir l'implémentation d'intégrations de passkeys tierces ?

En examinant ces questions, nous révélerons que les efforts continus de l'industrie pour adapter les passkeys aux contextes tiers – en particulier via des standards web comme la Secure Payment Confirmation (SPC) – sont bloqués par des barrières stratégiques implicitement imposées par Apple. Plus précisément, le support limité d'Apple pour la création de passkeys cross-origin dans Safari et l'absence de support pour le standard Secure Payment Confirmation représentent un obstacle majeur, compliquant l'adoption transparente de l'authentification basée sur les passkeys par les prestataires de paiement tiers. Comprendre et surmonter ces obstacles est essentiel pour tout prestataire visant à offrir des expériences de paiement fluides et sécurisées.

Les passkeys apportent une connexion biométrique et résistante au phishing à chaque maillon de la chaîne de paiement. Voici une analyse des avantages que chaque acteur de la chaîne de valeur des paiements peut tirer de l'intégration de l'authentification par passkey.

Impact : Paiement plus rapide, conversion plus élevée, moins d'abandons de panier. Opportunité : Les commerçants proposant des passkeys via des SDK ou des flux de redirection peuvent reproduire une expérience utilisateur digne d'Apple Pay et réduire la dépendance aux mots de passe ou aux codes OTP, ce qui renforce la confiance et augmente les ventes.

Impact : Authentification sans mot de passe et transparente sur tous les appareils. Opportunité : Les passkeys offrent une meilleure expérience utilisateur que les codes OTP ou SMS et éliminent le risque de phishing. Une adoption large pourrait faire des passkeys le nouveau standard pour la vérification des titulaires de carte.

Impact : Prévention de la fraude renforcée. Opportunité : Les émetteurs peuvent proposer une authentification forte basée sur les passkeys dans les flux 3DS, réduisant les coûts des OTP et améliorant la satisfaction des utilisateurs.

Impact : Taux d'acceptation des transactions plus élevé et moins d'échecs d'authentification. Opportunité : Le support des passkeys via les PSP peut améliorer les résultats des commerçants et réduire les frictions lors du paiement ou des flux de facturation récurrente.

Impact : Réduction de la fraude, meilleure expérience utilisateur pour les commerçants et conformité améliorée. Opportunité : En intégrant ou en redirigeant les flux de passkeys, les PSP peuvent fournir une authentification de nouvelle génération tout en maintenant la compatibilité entre les navigateurs et les applications natives.

Impact : Approbations de transactions simplifiées avec moins de paiements refusés. Opportunité : Les sociétés de traitement des paiements peuvent intégrer la vérification par passkey dans leurs API pour réduire les risques et supporter des alternatives biométriques à l'authentification forte du client (SCA) pour des flux conformes.

Impact : Stockage sécurisé des identifiants et réauthentification fluide. Opportunité : Les fournisseurs de portefeuilles comme Apple Pay et Google Pay utilisent déjà des flux similaires aux passkeys.

Ci-dessous, nous examinons brièvement les principaux prestataires de paiement et de cartes de crédit et analysons s'ils ont implémenté les passkeys et de quelle manière :

Mastercard a officiellement lancé son Payment Passkey Service, offrant une expérience d'authentification sans mot de passe intégrée aux flux EMV 3DS. Les utilisateurs peuvent créer et utiliser des passkeys liés au domaine d'authentification de Mastercard (par ex. verify.mastercard.com), permettant une connexion biométrique sécurisée chez les commerçants participants. Ce déploiement représente une étape majeure vers une authentification résistante au phishing et conforme à la DSP2 dans l'industrie des paiements. En savoir plus : Les passkeys Mastercard

Visa a introduit son Visa Payment Passkey Service, intégrant les passkeys dans le flux « Click to Pay ». En permettant aux utilisateurs de s'authentifier de manière transparente à l'aide de la biométrie au lieu de mots de passe ou de codes OTP, Visa vise à moderniser l'expérience de paiement en ligne avec une sécurité et une commodité accrues pour l'utilisateur. En savoir plus : Les passkeys VISA

American Express n'a pas encore lancé publiquement d'offre de passkeys. Cependant, en tant que membre du conseil d'administration de la FIDO Alliance, il est probable qu'American Express déploiera une solution d'authentification basée sur les passkeys dans un avenir proche, conformément aux tendances plus larges de l'industrie.

PayPal a été l'un des premiers prestataires de paiement à adopter les passkeys. Leur déploiement prend en charge la connexion biométrique transparente pour les comptes personnels et professionnels sur tous les appareils. Le passkey est lié au domaine de PayPal et est déjà disponible dans de nombreuses régions. Cependant, leur implémentation peut être améliorée, notamment en ce qui concerne les flux multi-appareils et la détection de plateforme. En savoir plus : Les passkeys PayPal

Klarna n'a pas encore officiellement introduit le support des passkeys. D'après nos observations, Klarna s'appuie fortement sur les WebViews intégrées dans son application et ses SDK de paiement. Étant donné que Safari et iOS restreignent la création de passkeys dans les iframes / WebViews, cela pourrait être une raison pour laquelle Klarna n'a pas encore déployé les passkeys.

Square a introduit la connexion par passkey pour son tableau de bord développeur et sa console de gestion, permettant un accès sécurisé et sans mot de passe aux outils internes. Cependant, aucune annonce n'a été faite concernant le support des passkeys dans les flux de paiement ou les API pour les utilisateurs finaux ou les commerçants.

Stripe a déployé la connexion par passkey pour son tableau de bord, permettant aux développeurs de s'authentifier à l'aide de la biométrie. Les passkeys pour Stripe Checkout ou Elements ne sont pas encore disponibles. Compte tenu de la forte promotion par Stripe des flux basés sur la redirection, il est probable que les passkeys, s'ils sont implémentés dans les paiements, suivraient cette même architecture de redirection.

À ce jour, BILL n'a fait aucune annonce publique ni mise à jour de produit concernant les passkeys pour l'authentification.

Remitly n'a divulgué aucun plan ni information publique sur l'implémentation de l'authentification par passkey dans ses services.

Il n'y a aucun rapport public ou documentation de produit indiquant que Payoneer a adopté ou teste la connexion ou les flux de transaction basés sur les passkeys.

Adyen n'a pas encore introduit les passkeys dans ses flux d'authentification ou de paiement. Aucune déclaration publique ou documentation pour les développeurs ne mentionne le support des passkeys.

Worldpay n'a annoncé aucun support pour les passkeys à ce jour. Leur pile d'authentification repose toujours sur des méthodes traditionnelles telles que les mots de passe, les OTP et les flux basés sur 3DS.

Checkout.com n'a pas encore déployé publiquement le support des passkeys. Il n'y a pas de mises à jour pour les développeurs, d'articles de blog ou d'annonces officielles concernant l'adoption des passkeys.

AliPay n'a pas officiellement lancé les passkeys. Compte tenu de la tendance croissante de l'authentification biométrique dans les écosystèmes de paiement chinois, un déploiement pourrait avoir lieu à l'avenir, mais aucune documentation actuelle ne le confirme.

Mollie n'a fait aucune déclaration publique ni mise à jour de produit concernant l'adoption des passkeys dans ses systèmes d'authentification ou de paiement.

Amazon a déployé le support des passkeys pour les connexions des utilisateurs sur sa plateforme principale. Étendre cette technologie à Amazon Pay serait une prochaine étape naturelle, d'autant plus que de nombreux utilisateurs ont déjà un passkey enregistré auprès d'Amazon, ce qui simplifierait considérablement l'intégration des utilisateurs lors du paiement.

Braintree, une société de PayPal, n'a pas encore officiellement adopté l'authentification par passkey. Leur documentation actuelle ne mentionne pas les passkeys dans le contexte de la connexion des utilisateurs ou des API pour les commerçants.

Link, la solution de paiement en un clic de Stripe, a déployé les passkeys, ce qui pourrait servir de base à la stratégie de passkeys de Stripe dans les paiements grand public. Cependant, Stripe n'a pas officiellement annoncé le support des passkeys pour Link ni de plans spécifiques de déploiement.

Afterpay n'a publié aucune déclaration ou fonctionnalité liée au support des passkeys. Comme Klarna, leur intégration de paiement est fortement basée sur l'application, ce qui peut poser des obstacles techniques à l'adoption des passkeys en raison des contraintes des WebView intégrées.

L'adoption des passkeys par les prestataires de paiement tiers se heurte à des obstacles stratégiques, principalement dus aux politiques restrictives d'Apple dans Safari. Deux tentatives de standardisation critiques ont été constamment entravées :

• Secure Payment Confirmation (SPC)
• La création de passkeys tiers dans les iframes

La Secure Payment Confirmation (SPC) représente l'effort le plus important de l'industrie - principalement mené par Google - pour permettre une utilisation transparente et cross-origin des passkeys, spécifiquement conçue pour les autorisations de paiement sécurisées. La SPC standardise la manière dont les prestataires de paiement authentifient les utilisateurs sur plusieurs sites marchands sans compromettre la sécurité ou l'expérience utilisateur. Cependant, Apple a constamment refusé de prendre en charge la SPC dans Safari, probablement une décision stratégique pour s'assurer qu'Apple Pay reste la solution de paiement préférée et la plus fluide au sein de son écosystème. Le refus d'Apple d'adopter la SPC non seulement limite le déploiement généralisé des passkeys dans des contextes tiers, mais retarde également l'adoption plus large par l'industrie d'une authentification de paiement standardisée.

Lisez cet article de blog sur la SPC si vous voulez en savoir plus sur les détails.

Une autre barrière critique concerne la restriction délibérée par Apple de la création de passkeys dans des iframes cross-origin. Alors que Safari autorise l'utilisation de passkeys existants pour l'authentification (navigator.credentials.get()) dans un iframe tiers, il bloque explicitement l'enregistrement de passkeys (navigator.credentials.create()) dans de tels contextes.

Cette limitation restreint sévèrement les prestataires de paiement qui dépendent de la création transparente de nouveaux passkeys pendant le flux de paiement du commerçant. Par conséquent, les prestataires sont contraints soit d'adopter des approches basées sur la redirection, soit de s'appuyer sur des passkeys existants préalablement établis directement sur leurs propres domaines. Cette décision d'Apple affecte directement la praticité et la fluidité des intégrations marchandes, créant un point de friction important pour les consommateurs et les prestataires.

Dans cette approche, le commerçant inclut votre formulaire de paiement dans un <iframe> servi depuis le domaine de votre prestataire de paiement - par exemple, https://pay.provider.com. L'utilisateur reste sur le domaine du commerçant (par ex. https://www.maboutique.com), voit votre interface de paiement dans l'iframe intégré et s'authentifie avec un passkey lié à l'ID de la Relying Party pay.provider.com.

Points clés :

• Cross-Origin : Comme l'iframe se trouve sur un domaine différent, vous devez configurer des politiques de permission pour publickey-credentials-get et publickey-credentials-create pour autoriser les opérations de passkeys à l'intérieur de l'iframe.

• Limitation de la création : Certains navigateurs (en particulier les anciennes versions et Safari) n'autorisent toujours pas la création de passkeys dans les iframes cross-origin. L'authentification (navigator.credentials.get()) est plus largement supportée, mais l'enregistrement (navigator.credentials.create()) peut échouer dans certains environnements, notamment sur Safari.

• Activation par l'utilisateur : Les flux de passkeys nécessitent généralement une « activation transitoire » (par exemple, un clic direct sur un bouton par l'utilisateur). Assurez-vous que votre interface iframe déclenche la cérémonie du passkey dans le cadre d'un événement initié par l'utilisateur.

• Sécurité et expérience utilisateur : L'approche par iframe offre une expérience de paiement fluide et intégrée, mais si le navigateur d'un utilisateur bloque ou restreint les cookies tiers ou le stockage local, cela peut perturber le flux du passkey.

Avec un flux basé sur la redirection, vous envoyez l'utilisateur du domaine du commerçant vers votre domaine de paiement, ou ouvrez un nouvel onglet/fenêtre pointant vers quelque chose comme https://pay.provider.com/checkout. Les passkeys sont alors créés ou utilisés directement sur votre domaine dans un contexte first-party.

Points clés :

• Simplicité First-Party : L'ensemble du flux de travail du passkey (création, authentification) se déroule sur le domaine du prestataire de paiement, il n'y a donc pas de restrictions cross-origin. Tous les principaux navigateurs supportent la création et la connexion par passkey dans des contextes first-party.

• Expérience utilisateur de la redirection : L'utilisateur quitte la page du commerçant (ou voit une pop-up) pour terminer l'authentification. Cela peut être moins fluide, mais simplifie l'architecture du flux de passkey et réduit les complexités cross-origin.

• Solution de repli pour les navigateurs incompatibles : Vous pouvez dégrader gracieusement si les passkeys ne sont pas disponibles (par ex. navigateurs plus anciens) en fournissant des méthodes de connexion alternatives sur votre domaine de paiement sans avoir besoin de gérer des permissions cross-origin supplémentaires.

L'intégration des passkeys dans les applications mobiles natives présente des défis uniques par rapport aux scénarios web. Les applications natives pour les commerçants (sur iOS et Android) intègrent souvent les flux de paiement dans l'application à l'aide de WebViews intégrées pour maintenir une expérience utilisateur transparente. Cependant, l'implémentation de l'authentification par passkey tiers dans ces contextes intégrés peut être problématique en raison des politiques strictes d'origine du navigateur et des limitations spécifiques à la plateforme.

Les passkeys sont intrinsèquement liés à un domaine spécifique (l'« ID de la Relying Party »), un principe de sécurité fondamental garantissant que les identifiants ne peuvent pas être utilisés de manière abusive sur des sites web ou des applications non liés. Lorsqu'un prestataire de paiement crée des passkeys sous son propre domaine - par exemple, pay.provider.com - ces passkeys sont strictement limités à ce domaine sur iOS et Android. Par conséquent, une application native d'un commerçant (qui fonctionne naturellement sous son propre identifiant d'application et son propre domaine) ne peut pas invoquer directement les passkeys du prestataire en tant qu'identifiant « first-party ». Cela nécessiterait un partage de clés privées cross-origin, ce que les systèmes d'exploitation et les spécifications WebAuthn interdisent explicitement pour empêcher le phishing et le vol d'identifiants.

Du point de vue de l'appareil, l'application native du commerçant est une « origine » différente de celle du domaine du prestataire de paiement. Tenter de s'authentifier nativement avec des identifiants enregistrés pour une origine distincte briserait le modèle de sécurité fondamental des passkeys lié à l'origine. C'est précisément pourquoi l'utilisation de passkeys tiers dans un contexte marchand dépend d'un navigateur système ou d'une WebView système (comme ASWebAuthenticationSession sur iOS ou les onglets personnalisés Chrome sur Android). Ces flux spéciaux préservent le contexte du domaine d'origine du prestataire - garantissant que les passkeys restent solidement liés à leur origine - tout en permettant aux utilisateurs de s'authentifier auprès du prestataire de paiement à l'intérieur de l'application d'un commerçant. Dans les sections suivantes, nous explorerons comment cela fonctionne.

Les WebViews intégrées (par ex., WKWebView sur iOS ou la WebView d'Android) sont très appréciées car elles permettent aux applications d'intégrer du contenu web directement dans leurs interfaces natives, offrant une intégration étroite et une cohérence de l'expérience utilisateur. Cependant, ces environnements intégrés sont considérablement restreints lorsqu'il s'agit de gérer des passkeys tiers en raison des politiques d'origine et de sécurité :

• Incompatibilité d'origine : Les passkeys reposent strictement sur les origines de domaine pour une gestion sécurisée des identifiants. Une WebView intégrée fonctionne sous le domaine du contenu qu'elle affiche (souvent celui du commerçant), ce qui rend difficile, voire impossible, la création ou l'authentification de passkeys liés explicitement au domaine d'un prestataire de paiement tiers.

• Contraintes de sécurité de la plateforme : Apple (iOS) et Google (Android) ont progressivement restreint les capacités des WebViews intégrées pour l'authentification, en particulier lorsqu'il s'agit d'identifiants sécurisés. Ces contraintes sont conçues pour protéger la confidentialité des utilisateurs et la sécurité, mais rendent l'implémentation de passkeys tiers nettement plus compliquée.

Dans l'ensemble, bien que les WebViews intégrées soient attrayantes pour les commerçants du point de vue de l'expérience utilisateur, elles introduisent des limitations pratiques importantes pour la mise en œuvre de flux d'authentification par passkey tiers robustes.

Compte tenu des limitations associées aux WebViews intégrées, les prestataires de paiement adoptent généralement l'une des deux stratégies alternatives pour implémenter de manière fiable les passkeys tiers dans les applications mobiles natives :

iOS (ASWebAuthenticationSession) :

Apple fournit ASWebAuthenticationSession comme un environnement sécurisé de type navigateur, en dehors du contexte de l'application hôte. Il partage le stockage des cookies avec le navigateur Safari par défaut et prend en charge les passkeys tiers de manière fiable car les identifiants s'alignent sur le domaine d'origine du prestataire de paiement.

L'exemple suivant montre la fonctionnalité « Payer avec PayPal » dans l'application native BOSS. Il montre comment une WebView système ASWebAuthenticationSession est ouverte, partageant son état avec les cookies de Safari, ce qui permet au dialogue du passkey de démarrer immédiatement.

Android (Onglets personnalisés Chrome) :

De même, les onglets personnalisés d'Android offrent un environnement quasi-navigateur permettant une création et une authentification de passkeys cohérentes. Comme ASWebAuthenticationSession, les onglets personnalisés s'exécutent séparément du contexte de l'application du commerçant, garantissant l'intégrité du domaine et des identifiants.

Voici le même exemple de l'application native BOSS sur Android :

Une autre approche consiste à rediriger les utilisateurs de l'application native vers le navigateur web par défaut de l'appareil mobile (Safari sur iOS, Chrome sur Android). Cela garantit que le flux de paiement - et donc la gestion des passkeys - se déroule entièrement dans un contexte first-party de confiance associé au domaine du prestataire de paiement. Les utilisateurs retournent ensuite à l'application du commerçant après une authentification ou un paiement réussi. Cette option est très peu pratique pour les clients car ils doivent quitter l'application.

Les deux solutions nécessitent de faire transiter temporairement les utilisateurs hors de l'environnement de l'application native du commerçant. Bien que légèrement moins fluides par rapport aux solutions intégrées, ces approches améliorent considérablement la compatibilité, la sécurité et la fiabilité des opérations de passkeys tiers.

En fin de compte, les prestataires de paiement développant des SDK natifs doivent soigneusement équilibrer les considérations d'expérience utilisateur avec les contraintes techniques pratiques. Malgré les préférences des commerçants pour des expériences entièrement intégrées, l'utilisation de WebViews système ou de redirections vers un navigateur externe reste la meilleure pratique pour garantir une authentification par passkey tiers sécurisée et fiable dans les applications natives.

Choisir entre une approche intégrée (iframe) et une approche basée sur la redirection pour l'intégration de passkeys tiers dans les SDK de paiement implique d'évaluer les compromis en matière d'expérience utilisateur, de compatibilité des navigateurs, de complexité technique et de préférences des commerçants.

Les deux solutions présentent des avantages et des inconvénients distincts, que les prestataires de paiement doivent examiner attentivement en fonction de leur marché cible, de l'expérience utilisateur souhaitée et de l'infrastructure technique.

L'approche intégrée (iframe) offre une expérience utilisateur transparente et à l'image du commerçant, très attrayante pour ces derniers, mais elle est entravée par une compatibilité limitée des navigateurs, en particulier le refus de Safari d'autoriser la création de passkeys cross-origin. Cette limitation contraint les commerçants et les prestataires à des solutions complexes basées sur des contournements qui compromettent souvent la fonctionnalité ou conduisent à un support incomplet de l'enregistrement des passkeys.

Inversement, l'approche par redirection offre une compatibilité complète sur les navigateurs et les plateformes mobiles natives en fonctionnant dans un contexte de domaine first-party. Elle simplifie considérablement l'intégration, améliore la fiabilité et garantit un support complet de la création et de l'authentification des passkeys. Le principal inconvénient est la friction potentielle créée par la redirection des utilisateurs hors du site web ou de l'application du commerçant, bien que cela puisse être atténué par une conception UX soignée, des attentes clairement communiquées ou des intégrations avec des plateformes de confiance comme Corbado.

Compte tenu de ces considérations, une approche hybride est souvent idéale, permettant aux prestataires de paiement de tirer parti du modèle d'iframe intégré lorsque le navigateur de l'utilisateur le prend en charge et de basculer gracieusement vers une approche de redirection dans le cas contraire. Cette stratégie combinée maximise la compatibilité, l'attractivité pour les commerçants et la satisfaction des clients dans divers environnements.

L'implémentation d'un SDK de paiement tiers avec des passkeys implique de trouver un équilibre entre l'expérience utilisateur, la compatibilité des navigateurs, les contraintes des applications natives, l'analytique et la sécurité - en particulier compte tenu des obstacles spécifiques à Apple (par ex. blocage de la création de passkeys cross-origin, absence de support SPC). Vous trouverez ci-dessous des recommandations clés pour garantir le meilleur résultat possible lors de l'intégration des passkeys dans les flux de paiement web ou natifs.

En raison de la prise en charge variable des navigateurs et des comportements incohérents d'Apple, il est essentiel de prendre en charge à la fois une approche intégrée (basée sur un iframe) et une approche par redirection :

• Paiement par Iframe (intégré)

  • Fournit une expérience transparente sur la page pour les navigateurs modernes qui autorisent les opérations de passkeys cross-origin (principalement pour l'authentification).

  • Doit définir la bonne Permissions-Policy pour publickey-credentials-get/publickey-credentials-create.

  • Notez que Safari et certains navigateurs plus anciens bloquent la création de passkeys cross-origin dans les iframes.

• Flux de redirection

  • Prend en charge de manière fiable l'enregistrement et la connexion par passkey dans un contexte first-party.

  • Légèrement plus de friction en raison de la redirection ou de la pop-up supplémentaire, mais universellement plus sûr pour la compatibilité entre navigateurs.

  • Solution de repli idéale pour Safari, qui n'autorise actuellement pas la création de passkeys tiers dans les iframes.

En proposant les deux approches, vous pouvez décider dynamiquement - ou laisser les commerçants décider - laquelle utiliser, maximisant ainsi la compatibilité pour tous les environnements utilisateur.

La détection précise des capacités du navigateur reste difficile en raison de la granularité réduite du User-Agent et du support incohérent des Client Hints sur les différentes plateformes.

L'analyse traditionnelle est de moins en moins fiable car les navigateurs réduisent les détails dans les chaînes User-Agent pour protéger la confidentialité des utilisateurs. Différencier les détails essentiels - tels que Windows 10 vs. Windows 11, les versions précises de macOS ou les architectures de CPU - est maintenant difficile, voire impossible, en utilisant uniquement le User-Agent.

Bien que les Client Hints fournissent des données à haute entropie d'une manière respectueuse de la vie privée, seuls les navigateurs basés sur Chromium les prennent entièrement en charge. Safari et Firefox n'offrent aucun support pour les Client Hints, ce qui restreint sévèrement la détection précise des fonctionnalités sur les appareils Apple.

Les WebViews intégrées restreignent généralement l'accès aux informations détaillées de l'appareil et prennent rarement en charge les Client Hints. Cette limitation rend la détection des capacités de passkey particulièrement difficile dans les contextes d'applications natives.

Compte tenu de ces contraintes, la détection fiable du support des passkeys cross-origin - en particulier dans les SDK de paiement tiers - nécessite une combinaison minutieuse de requêtes dynamiques de Client Hints (lorsqu'elles sont disponibles), d'heuristiques de User-Agent en solution de repli et de comportements par défaut conservateurs pour les navigateurs comme Safari et Firefox.

Les applications marchandes natives intègrent souvent du contenu web dans WKWebView (iOS) ou Android WebView, qui sont très restrictives pour les passkeys. Les stratégies courantes incluent :

• Sessions de navigateur système : Utilisez ASWebAuthenticationSession (iOS) ou les onglets personnalisés (Android) pour déplacer la création/connexion par passkey vers un contexte de navigateur « first-party » sécurisé.

• Redirection vers le navigateur par défaut : Une approche moins transparente mais très fiable pour garantir l'intégrité du domaine pour les opérations de passkeys.

En tant que prestataire de paiement, une sécurité forte et la conformité réglementaire (PCI, DSP2 SCA, etc.) sont essentielles :

• En-têtes et sécurité du contenu : Implémentez des en-têtes Permissions-Policy stricts et des règles CSP robustes pour les flux cross-origin.

• Journalisation et surveillance : Journalisez minutieusement les événements de création et d'utilisation des passkeys pour la prévention de la fraude et les audits de conformité.

• Stockage minimal de PII : Associez les utilisateurs aux passkeys à l'aide d'identifiants hachés, réduisant ainsi l'exposition en vertu du RGPD ou de lois similaires sur la protection des données.

• Pistes d'audit : Journalisez chaque événement de création et d'authentification de passkey pour détecter les anomalies et satisfaire les audits de conformité.

Les passkeys sont encore en évolution, vous aurez donc besoin de vérifications continues :

• Tests multi-navigateurs et multi-OS : Automatisez les tests sur Safari, Chrome, Edge, Firefox et les principales versions d'OS mobiles.

• Mises à jour fréquentes : Suivez les changements dans les spécifications WebAuthn du W3C, les directives de la FIDO Alliance ou les propositions SPC.

• Commentaires des utilisateurs et taux d'erreur : Journalisez les erreurs de passkey (création ou connexion) pour résoudre rapidement les problèmes, en particulier pour les utilisateurs basés sur Apple.

Un cadre de KPI robuste vous aide à suivre si votre intégration de passkeys tiers améliore réellement la sécurité et l'expérience utilisateur. Même si cet article porte sur l'implémentation de SDK, il est important de garder à l'esprit que l'adoption des passkeys est également essentielle dans ce cas d'utilisation. Le taux de création et le taux d'utilisation des passkeys nécessitent une analyse et une optimisation minutieuses.

• Définition : Pourcentage d'utilisateurs qui créent un passkey avec succès lorsqu'on le leur propose (par ex. lors du paiement ou de la création de compte).

• Pourquoi c'est important : Un taux de création élevé signifie que votre flux d'intégration/incitation pour les passkeys est convaincant et sans friction.

• Cible : Vous devriez viser un taux de 50 à 80 %.

• Définition : Parmi les utilisateurs qui commencent la cérémonie de création (cliquent sur « Créer un passkey »), combien la finalisent sans abandonner ni rencontrer d'erreur ?

• Pourquoi c'est important : Indique à quel point votre flux cross-origin ou de redirection fonctionne bien.

• Cible : Idéalement, vous avez un chiffre d'environ 95 à 100 % une fois qu'un utilisateur a choisi de participer.

• Définition : Le pourcentage total d'autorisations de paiement (ou de connexions) effectuées via des passkeys, par opposition aux méthodes de repli.

• Pourquoi c'est important : La création n'a pas de sens si les utilisateurs reviennent par défaut aux anciennes méthodes.

• Cible : Un taux de 50 à 80 % signale une forte adoption des passkeys.

• Définition : Pourcentage de tentatives de connexion par passkey qui réussissent sans erreur ni repli.

• Pourquoi c'est important : Un reflet de votre convivialité en conditions réelles.

• Cible : En général, vous devriez dépasser 90 à 95 % pour considérer les passkeys comme « sans friction ».

• Définition : À quelle fréquence les utilisateurs échouent-ils avec les passkeys en pleine cérémonie et passent-ils à un mot de passe ou un OTP ?

• Pourquoi c'est important : Une utilisation élevée du repli suggère que des obstacles techniques ou d'expérience utilisateur empêchent les passkeys de remplacer les méthodes héritées.

• Cible : Idéalement, l'utilisation du repli est inférieure à 1-5 %.

Pour les prestataires de paiement, mesurez si les passkeys réduisent la fraude, accélèrent le paiement ou diminuent l'abandon de panier. Combinez les données d'utilisation des passkeys avec les métriques de conversion de paiement ou de succès de 3-D Secure pour une vue d'ensemble.

La surveillance de ces KPI vous aide à identifier les environnements ou les parcours utilisateur qui nécessitent une amélioration - par exemple, si Safari sur iOS a un taux d'abandon plus élevé en raison des blocages cross-origin, vous pouvez systématiquement diriger ces utilisateurs vers un flux de redirection.

L'un des défis les plus critiques dans la création d'un SDK de passkeys tiers est d'orchestrer un flux de création fluide et cohérent - où les utilisateurs enregistrent réellement leurs passkeys. Que cela se produise dans le portail d'une banque, dans les paramètres de compte du prestataire de paiement ou directement sur la page de paiement d'un commerçant, les étapes fondamentales de l'enregistrement d'un passkey sont très similaires. Par conséquent, l'approche de la création de passkeys ne change pas fondamentalement selon que vous intégrez le flux dans un iframe ou que vous redirigez l'utilisateur vers une page first-party ; ce qui compte le plus, c'est de fournir des écrans clairs et conviviaux, de gérer les contraintes cross-origin et de suivre les métriques essentielles qui montrent avec quelle efficacité les utilisateurs adoptent les passkeys. Voici les aspects clés d'un flux de création de passkeys exemplaire et comment Corbado les prend en charge :

Peu importe où un utilisateur est invité à créer un passkey - que ce soit dans l'environnement de banque en ligne d'une banque, sur le site web/l'application du prestataire de paiement ou lors du paiement d'un commerçant - Corbado fournit des composants pré-construits et personnalisables pour les invites utilisateur, les confirmations de succès et la gestion des erreurs.

Ces composants garantissent une apparence cohérente tout en permettant un marquage en marque blanche afin que chaque banque ou commerçant puisse conserver ses propres éléments de conception si nécessaire.

Voir le composant d'interface utilisateur suivant pour l'écran de création de passkey avec la marque VicRoads :

Corbado collecte et unifie les données de tous les points de terminaison de création :

• Les sites web ou applications des banques où les passkeys sont initialement proposés.

• Les paramètres de compte personnels du prestataire de paiement (où les utilisateurs peuvent gérer leurs identifiants).

• Les pages de paiement des commerçants qui permettent éventuellement la création de passkeys « à la volée ».

Cette approche unifiée facilite la mesure du taux de création de passkeys, du taux de réussite de la création, des points d'abandon des utilisateurs et de toute erreur technique - quel que soit le canal qui initie l'enregistrement du passkey.

Corbado propose des fonctionnalités de test A/B pour affiner les instructions à l'écran, le texte des boutons et le moment des invites. Des changements subtils dans la formulation (par exemple, « Créez un passkey maintenant - plus de mots de passe ! » contre « Sécurisez votre prochain paiement avec un passkey ! ») produisent souvent des différences significatives dans l'acceptation par les utilisateurs.

Sur la base des résultats du test A/B, les KPI suivants peuvent être optimisés :

• Taux de création : Pourcentage d'utilisateurs qui, une fois invités, configurent avec succès un passkey.

• Taux de réussite de la création : La part des utilisateurs qui terminent la cérémonie sans abandonner ni rencontrer d'erreur.

• Utilisation du repli : Le taux auquel les utilisateurs ignorent la création de passkey au profit d'anciennes méthodes de connexion.

• Impact sur la conversion : Pour les commerçants, mesurez si la création de passkey lors du paiement réduit l'abandon de panier.

Les utilisateurs peuvent créer des passkeys dans les contextes suivants :

• Contexte bancaire : Flux de création déclenchés après qu'un utilisateur se connecte à sa banque, tirant parti de la confiance et de la familiarité de l'environnement bancaire.

• Paramètres de compte du prestataire de paiement : Les utilisateurs configurent les passkeys directement dans leurs paramètres « Mon profil » ou « Sécurité » du domaine du prestataire de paiement.

• Paiement du commerçant : Invite à la dernière étape du paiement, surtout si l'utilisateur n'a pas créé de passkey auparavant. Cela peut être intégré (iframe) ou via une redirection.

Dans chaque scénario, la cérémonie de passkey sous-jacente suit les mêmes étapes - confirmation de l'utilisateur, invite biométrique/PIN et enregistrement de l'identifiant. Le SDK de Corbado garantit que les contraintes cross-origin (si intégré) ou le contexte de domaine first-party (si redirigé) sont gérés de manière transparente en arrière-plan.

Corbado attache chaque nouveau passkey à l'identifiant utilisateur approprié - que ce soit « préfixeBanque_idUtilisateur » ou une référence utilisateur interne dans le système du prestataire de paiement - afin que toute utilisation ultérieure soit traçable jusqu'au bon compte utilisateur.

Ces métadonnées sont également cruciales pour l'analytique avancée : par exemple, voir comment les campagnes de création de passkeys de RBC se comparent à celles de TD, ou comment les taux de création diffèrent entre les paiements des commerçants et les flux directs de « paramètres de compte ».

La même logique du SDK Corbado peut s'adapter selon que la création de passkeys cross-origin est autorisée (dans les versions modernes de Chrome ou Edge) ou doit basculer gracieusement vers une redirection pour Safari.

Le rapport d'erreurs intégré aide à identifier si un sous-ensemble d'utilisateurs échoue systématiquement à la création de passkeys (par ex., anciennes versions d'iOS, appareils d'entreprise Windows), afin que l'équipe produit puisse affiner les instructions ou les stratégies de repli.

Notre équipe a mené de nombreuses expériences de création de passkeys avec des clients entreprises, apprenant quelles phrases, quels emplacements de boutons et quel timing donnent les meilleurs taux d'adoption.

Nous intégrons ces meilleures pratiques dans chaque écran de création, tout en permettant une personnalisation complète pour les besoins de marque et de conformité.

Dans l'ensemble, la création de passkeys est la phase la plus importante pour garantir une adoption élevée : même le flux de connexion par passkey le plus élégant n'aura pas d'importance si les utilisateurs n'enregistrent jamais d'identifiants en premier lieu. En offrant des écrans de création uniformes et traçables sur tous les canaux possibles - banque, domaine du prestataire de paiement ou paiement du commerçant - et en les instrumentant avec des analyses de KPI et des tests A/B, Corbado aide les prestataires de paiement à stimuler une adoption de passkeys véritablement évolutive, reproduisant l'expérience utilisateur de solutions natives comme Apple Pay.

Une fois qu'un utilisateur a créé un passkey, l'étape suivante consiste à s'assurer qu'il utilise réellement ce passkey pour des paiements rapides et fluides, comme le présente Apple Pay dans un flux de paiement Apple Pay.

Chez Corbado, nous avons développé un mécanisme de « Passkey Intelligence » qui détecte automatiquement lorsque l'environnement d'un utilisateur contient probablement un passkey valide, permettant une véritable expérience de paiement en un clic. Voici les éléments essentiels qui rendent cela possible.

Lorsqu'un utilisateur connu est reconnu, le front-end de Corbado affiche un bouton dédié (par ex. « Payer avec Passkey ») plutôt que de forcer la saisie d'identifiants de repli.

Un seul clic sur ce bouton déclenche le flux WebAuthn get() (ou l'invite de passkey native), permettant à l'utilisateur de s'authentifier instantanément via la biométrie/PIN - sans étapes supplémentaires ni saisie de formulaire.

Le SDK de Corbado recueille des signaux (par ex. cookies de stockage local, utilisation antérieure réussie de passkey, détections d'environnement) pour prédire si l'appareil + le navigateur actuels ont probablement un passkey valide pour cet utilisateur.

Si les cookies sont supprimés ou indisponibles, Corbado se rabat sur des heuristiques supplémentaires (par ex., environnement connu existant de l'utilisateur, indices utilisateur fournis par le commerçant) pour décider s'il est sûr de démarrer automatiquement un flux de passkey.

Si les preuves sont insuffisantes pour suggérer la présence d'un passkey, l'interface utilisateur propose gracieusement des flux de repli ou invite l'utilisateur à confirmer qu'il a un passkey.

Corbado ne stocke pas d'informations personnellement identifiables (PII) comme les e-mails complets ou les noms.

Au lieu de cela, le commerçant peut passer un identifiant haché ou masqué (par ex. un hachage d'e-mail ou un ID utilisateur interne). Corbado l'utilise pour rechercher des enregistrements de passkeys potentiels, puis décide de démarrer une authentification par passkey ou de revenir à une approche plus générique. Si le prestataire de paiement le prend en charge, nous pouvons rechercher les informations fournies par le commerçant pour trouver l'ID utilisateur interne.

Cela garantit la confidentialité de l'utilisateur tout en permettant une correspondance d'environnement de haute précision.

Dans les scénarios où le passkey de l'utilisateur aurait pu exister mais ne peut pas être détecté (par ex., cookies effacés, nouvel appareil), la Passkey Intelligence de Corbado analyse soigneusement s'il est judicieux de démarrer automatiquement une invite de passkey.

Au lieu de cela, l'utilisateur verrait des flux de repli alternatifs ou une option « scanner le passkey depuis un autre appareil » tout en préservant un chemin rapide vers l'utilisation du passkey si l'utilisateur peut confirmer manuellement qu'il en a un.

Chaque fois que Corbado choisit d'initier ou d'ignorer une invite de passkey en un clic, cette décision est enregistrée. Au fil du temps, vous pouvez voir précisément quels navigateurs ou types d'appareils offrent la plus grande couverture de passkeys par rapport à ceux qui reviennent fréquemment au repli.

Cette boucle de rétroaction analytique vous permet d'identifier les environnements sous-performants (par ex., des versions spécifiques d'iOS ou d'Android) ou les segments d'utilisateurs où l'utilisation des passkeys reste faible - afin que vous puissiez affiner les stratégies d'intégration ou d'éducation.

Que l'utilisateur arrive d'une campagne de création de passkeys d'une banque ou directement au paiement d'un commerçant, la logique en un clic reste cohérente.

Corbado garantit que si un passkey est trouvé (basé sur les cookies de domaine, les jetons de stockage local ou les signaux de passkey intelligence), l'utilisateur se voit immédiatement présenter le flux de connexion/paiement le plus fluide.

Résumé

En bref, l'utilisation des passkeys en un clic est la récompense ultime de la création de passkeys. En tirant parti de la Passkey Intelligence - un mélange de détection d'environnement, d'utilisation minimale de PII et de logique de repli - Corbado garantit que les utilisateurs se voient proposer l'authentification par passkey uniquement lorsqu'il est vraiment probable qu'elle réussisse. Cela réduit considérablement les tentatives infructueuses, évite la frustration des utilisateurs et favorise une utilisation habituelle des passkeys, aboutissant à un flux de paiement en un clic qui rivalise avec la commodité d'Apple Pay ou d'autres expériences de paiement natives.

Au-delà de la simple activation des passkeys, il est crucial de comprendre avec quelle efficacité ils sont adoptés et utilisés sur différents appareils, navigateurs et parcours utilisateur. Les prestataires de paiement ont besoin de données concrètes pour savoir si les passkeys réduisent réellement les frictions, diminuent la fraude et améliorent la conversion. S'appuyant sur les meilleures pratiques du Guide Acheter ou Construire des Passkeys, Corbado offre une couche d'analyse riche qui vous permet de suivre, segmenter et optimiser les performances des passkeys en temps réel.

Voici les points forts.

Corbado organise tous les événements de passkeys dans un entonnoir : depuis le moment où un utilisateur est invité à créer un passkey, en passant par l'enregistrement réussi, jusqu'aux connexions/paiements ultérieurs (utilisation du passkey).

Cette visualisation de l'entonnoir vous permet de voir où les utilisateurs abandonnent - par exemple, combien ne commencent jamais la création, combien abandonnent en cours de cérémonie, ou combien reviennent aux méthodes de repli lors de la connexion.

Sur la base de notre vaste expérience à aider les entreprises à implémenter les passkeys, nous nous concentrons sur les métriques qui ont un impact direct sur le retour sur investissement et la satisfaction des utilisateurs :

• Taux d'acceptation des passkeys : Combien d'utilisateurs qui voient une invite de création terminent réellement l'enregistrement du passkey ?

• Taux de réussite de la création de passkeys : Parmi ceux qui commencent la cérémonie (cliquent sur « Créer un passkey »), quel pourcentage finalise sans erreur ni abandon ?

• Taux d'utilisation des passkeys : À quelle fréquence les utilisateurs connus choisissent-ils réellement les passkeys pour l'authentification ou le paiement quotidiens, plutôt que les mots de passe ou les OTP ?

• Taux de réussite de la connexion par passkey : Le pourcentage de tentatives de passkey qui réussissent sans repli ni frustration de l'utilisateur.

• Utilisation du repli : Combien d'utilisateurs initient un flux de passkey mais reviennent à d'anciennes méthodes ? Cela signale des barrières potentielles d'UX ou techniques.

Corbado tague automatiquement chaque événement avec le système d'exploitation (Windows, macOS, iOS, Android) et le navigateur (Chrome, Safari, Edge, Firefox, etc.).

Avec cette segmentation, vous pouvez voir si, par exemple, Safari sur iOS a un taux d'abandon de passkey plus élevé, ou si Chrome sur Windows donne une meilleure adoption des passkeys.

Ces données vous aident également à affiner les stratégies de repli - surtout si les restrictions cross-origin d'Apple affectent votre base d'utilisateurs plus que prévu.

Nous fournissons des vues de tableau de bord pour chaque étape de l'entonnoir de passkey : invites de création, enregistrements réussis, connexions des utilisateurs, utilisation du repli.

Les graphiques en temps réel permettent aux chefs de produit de repérer rapidement les tendances (par exemple, si une nouvelle mise à jour de l'OS casse les flux de passkeys).

Des alertes automatisées peuvent notifier votre équipe si les taux de réussite des passkeys chutent de manière significative - afin que vous puissiez rapidement enquêter sur un nouveau bogue de navigateur ou un problème de configuration.

Chaque flux de passkey (de la création à la connexion) est enregistré avec des événements étape par étape horodatés, permettant une analyse forensique approfondie.

Vous pouvez rapidement rechercher par hachage d'utilisateur, ID de session ou signature de l'appareil pour voir exactement où un utilisateur a eu des difficultés ou quel code d'erreur a été retourné.

Ceci est essentiel pour les déploiements à grande échelle, où vous ne pouvez pas vous fier à des tickets de support anecdotiques mais avez besoin de données précises pour résoudre les problèmes des utilisateurs.

La plateforme d'analyse de Corbado prend en charge les tests A/B intégrés à l'entonnoir de passkey : testez différents textes de CTA, invites de création, messages de repli ou placement des boutons « Créer un passkey » dans le flux de paiement.

Des métriques comme le « Taux d'acceptation des passkeys » ou le « Taux de repli » peuvent être mesurées côte à côte pour chaque variante.

Cette approche garantit une amélioration continue, à l'image du succès des principaux adopteurs de passkeys qui affinent les flux au fil du temps.

Bien que les tableaux de bord de Corbado fournissent une interface visuelle prête à l'emploi, vous pouvez également exporter ou utiliser des webhooks pour les points de données clés (par ex., succès de la création de passkeys, connexions) dans vos outils de BI ou SIEM.

Cela permet aux prestataires de paiement d'intégrer les KPI des passkeys dans des suites d'analyse plus larges - en suivant le retour sur investissement des passkeys aux côtés d'autres métriques de sécurité, de marketing ou opérationnelles.

Résumé

En mesurant et en visualisant chaque étape du parcours du passkey - à travers les combinaisons OS/navigateur, les flux de création et les scénarios de connexion - Corbado vous donne les informations nécessaires pour affiner continuellement votre offre de passkeys. Ces analyses ne confirment pas seulement que les passkeys sont activés ; elles prouvent si les utilisateurs les adoptent réellement à grande échelle, identifient les points de friction et vous aident à augmenter les taux d'utilisation au point où les passkeys remplacent véritablement les mots de passe pour des paiements sécurisés et fluides.

Pour les prestataires de paiement, la simple création d'un passkey par utilisateur ne suffit souvent pas à offrir une expérience d'authentification véritablement transparente. En réalité, les utilisateurs changent fréquemment d'appareil - des ordinateurs portables au travail aux smartphones personnels, tablettes et même aux ordinateurs familiaux partagés. S'assurer que chaque appareil dispose d'un passkey valide pour le même compte est essentiel pour réduire les frictions et éviter le recours aux mots de passe. Apple Pay y parvient en pouvant exploiter le compte iCloud sur tous les appareils connectés à iCloud.

Voici comment Corbado aide à maintenir une couverture multi-appareils tout au long du cycle de vie de l'utilisateur.

• Écrans de création de passkey principal : Corbado se concentre initialement sur l'incitation de chaque utilisateur à enregistrer au moins un passkey - le passkey « principal » - là où il rencontre pour la première fois votre flux de paiement (par exemple, lors du paiement, sur le portail en ligne d'une banque ou dans les paramètres de votre compte).

• Écrans de création de passkey secondaire : Après qu'un utilisateur a enregistré avec succès son premier passkey, les connexions ultérieures sur d'autres appareils peuvent automatiquement déclencher un court flux « Ajouter cet appareil ». Cela garantit que l'utilisateur obtient rapidement un accès fluide par passkey sur tous les appareils pertinents sans avoir à ressaisir un mot de passe ou à basculer vers des méthodes de repli.

Même si un utilisateur a un passkey sur un appareil, il peut apparaître sans passkey local sur un deuxième appareil (en raison de nouvelles installations d'OS, de la suppression de cookies ou simplement de n'avoir jamais créé de passkey sur cet appareil).

L'approche de Corbado utilise souvent une étape hybride : l'utilisateur peut se connecter avec un passkey existant sur son téléphone ou une méthode de repli, puis « réparer » instantanément la lacune en créant un passkey sur l'appareil actuel.

Ce processus d'auto-réparation aide à maintenir une couverture élevée et élimine l'utilisation répétée du repli à l'avenir.

Grâce à des signaux inter-appareils et à la « Passkey Intelligence » de Corbado, le système peut détecter quand un utilisateur avec un passkey existant est passé à un appareil non enregistré.

Si votre stratégie UX vise une couverture maximale, Corbado peut automatiquement proposer : « Souhaitez-vous ajouter un passkey sur cet appareil pour ne pas avoir à utiliser une solution de repli la prochaine fois ? »

Les utilisateurs peuvent ignorer cette étape s'ils sont sur un appareil ponctuel, mais apprécient généralement la commodité de la connexion biométrique par passkey une fois qu'elle est expliquée.

Le SDK de Corbado fournit des flux d'écran distincts pour la « première création de passkey » (c'est-à-dire la toute première fois que l'utilisateur enregistre un identifiant) et la création sur un « appareil secondaire ».

Le message peut différer : par exemple, « Sécurisez ce nouvel appareil avec un passkey » contre « Configurez votre premier passkey ».

Cela garantit la clarté pour les utilisateurs finaux, qui comprennent la différence entre l'inscription initiale et l'extension de la couverture à des appareils supplémentaires.

Parfois, la création d'un passkey peut échouer en cours de cérémonie ou le système d'exploitation de l'utilisateur est obsolète. Dans ces scénarios, Corbado enregistre la tentative partielle et suggère gracieusement des remèdes possibles (redirection, repli manuel ou flux QR inter-appareils).

L'utilisateur peut toujours réessayer d'ajouter un passkey sur cet appareil lors de la prochaine tentative de connexion, ou s'appuyer sur un passkey existant d'un autre appareil.

Les analyses de Corbado montrent non seulement combien d'utilisateurs ont créé un passkey initialement, mais aussi combien ont étendu les passkeys à plusieurs appareils.

Vous pouvez suivre les taux de couverture des appareils (par exemple, 1 appareil contre 2 ou plus) et voir comment cela est corrélé avec une utilisation réduite du repli ou une meilleure réussite des paiements.

Cela aide votre équipe à prioriser l'éducation des utilisateurs, les invites dans l'application ou les flux d'inscription basés sur la banque pour augmenter la pénétration des passkeys multi-appareils.

Résumé : Pourquoi la couverture multi-appareils est importante

Sans une couverture cohérente sur tous les appareils de l'utilisateur, vous risquez que les utilisateurs soient contraints de revenir à des mesures d'authentification de repli chaque fois qu'ils sont sur un appareil « sans passkey ». Cela brise l'expérience fluide et maintient des coûts opérationnels élevés (par exemple, frais de SMS, frais de support). En proposant des écrans de création de passkey secondaires, une réparation par repli hybride et des invites basées sur l'environnement, Corbado garantit que chaque utilisateur peut éventuellement maintenir des passkeys sur tous les appareils qu'il utilise - ce qui entraîne une adoption globale plus élevée et minimise ces moments de repli frustrants.

L'une des plus grandes idées fausses lors de la création d'un SDK de passkeys tiers est que la partie la plus difficile est d'implémenter les appels WebAuthn (par exemple, navigator.credentials.create() ou navigator.credentials.get()).

En réalité, c'est la partie « facile » - un ou deux appels d'API pour déclencher la cérémonie de base. La véritable complexité, et le véritable déterminant du succès, réside dans la garantie d'une adoption à grande échelle et la construction d'un écosystème complet autour de ces appels d'API.

Voici les points clés - renforcés par le Guide Acheter ou Construire des Passkeys - qui soulignent pourquoi les implémentations minimales, axées uniquement sur la cérémonie, ne parviennent souvent pas à produire des résultats concrets.

• Implémentation de la cérémonie : La création ou l'authentification d'un passkey implique généralement quelques lignes de JavaScript pour appeler navigator.credentials.create() ou navigator.credentials.get().

• Complexité réelle : S'assurer que le flux de passkey fonctionne sur de nombreux navigateurs, gère gracieusement les échecs et offre une solution de repli pour les systèmes plus anciens. Vous aurez également besoin d'une gestion de session robuste, d'une journalisation des erreurs, d'analyses, de stratégies de couverture des appareils, et plus encore.

• Pièges imprévus : Une fois que vous dépassez une « démo technique » des passkeys, vous découvrez des cas limites comme les blocages cross-origin, les restrictions des WebView intégrées et les complexités de la synchronisation multi-appareils. Ce sont les inconnues qui font dérailler les constructions internes naïves.

• Cérémonie vs. Adoption : Même si vous avez une cérémonie WebAuthn parfaite, une faible adoption par les utilisateurs (par exemple, un taux d'utilisation des passkeys <5 %) ne produira que des avantages minimes en matière de sécurité ou d'expérience utilisateur.

• Approche holistique : Un déploiement de passkeys réussi exige tout, des invites utilisateur convaincantes et une rédaction testée par A/B aux flux de couverture multi-appareils, à la gestion des solutions de repli et à des analyses continues - bien au-delà des appels de cérémonie de base.

• Enseignements du Guide Acheter ou Construire : Le guide souligne que stimuler l'adoption des passkeys - et pas seulement les activer - détermine en fin de compte le retour sur investissement. Si les utilisateurs ne s'inscrivent pas et n'utilisent pas activement les passkeys, le projet est effectivement bloqué à « MFA 2.0 » sans amélioration du taux de conversion.

• Gestion incomplète des solutions de repli et des erreurs : L'absence d'une logique de repli avancée ou d'un débogage en temps réel peut entraîner des blocages d'utilisateurs et des coûts de support plus élevés.

• Couverture multi-appareils fragmentée : Sans un plan pour synchroniser des appareils supplémentaires ou « réparer » les lacunes de passkeys, les utilisateurs reviennent aux mots de passe chaque fois qu'ils changent de plateforme.

• Analyses et tests A/B limités : Le manque de données sur les entonnoirs de création de passkeys ou l'utilisation de l'environnement signifie que vous ne pouvez pas améliorer systématiquement l'adoption ou dépanner rapidement les nouvelles bizarreries des navigateurs.

• Interface utilisateur pré-construite et meilleures pratiques : Au lieu de simplement exposer les points de terminaison de la cérémonie, une solution appropriée (comme Corbado) regroupe des écrans en marque blanche, des flux de repli, la gestion des erreurs et la couverture inter-appareils.

• Intelligence adaptative et journalisation : Détection automatique de la présence probable de passkeys, guidage des utilisateurs pour créer ou corriger les passkeys manquants, et capture de journaux d'événements granulaires.

• « Inconnues » axées sur l'adoption : De nombreux détails - comme le repli par e-mail ou la manière de gérer les appareils d'entreprise - ne sont pas évidents jusqu'à ce que les utilisateurs commencent à les rencontrer dans des déploiements réels.

• Plongée plus profonde dans la stratégie d'adoption : Le Guide Acheter ou Construire des Passkeys met en évidence comment équilibrer le coût, le temps de mise sur le marché et les complexités cachées d'une solution de passkeys robuste.

• Benchmarks du monde réel : Apprenez comment les déploiements à grande échelle de grandes banques et de fournisseurs de commerce électronique ont surmonté les inconnues qui surgissent après que vous ayez codé la logique « simple » de la cérémonie.

• Succès durable : Investir dans une plateforme établie avec des modèles d'adoption éprouvés vous assure de ne pas être coincé à réinventer la roue - et à découvrir des surprises coûteuses en cours de route.

En résumé

Le simple fait de connecter la cérémonie WebAuthn ne suffit pas pour obtenir une adoption significative des passkeys. Le véritable succès dépend de l'orchestration de flux de bout en bout - comme les solutions de repli, les analyses, les extensions multi-appareils et les parcours utilisateur testés par A/B. En abordant les complexités nuancées au-delà de « juste la cérémonie », vous pouvez transformer votre projet de passkeys d'une curiosité technique en une solution d'authentification véritablement fluide, largement utilisée et économique.

En plus des complexités liées aux flux cross-origin, à l'adoption par les utilisateurs et à la gestion du cycle de vie des passkeys, les considérations d'hébergement et de déploiement sont essentielles pour toute solution de passkeys à grande échelle. Les prestataires de paiement sont souvent confrontés à des exigences strictes en matière de conformité, de résidence des données et de résilience qui peuvent varier considérablement d'une région à l'autre. Voici comment Corbado (ou des solutions tout aussi robustes) répond à ces préoccupations :

Pour se conformer à la souveraineté des données ou aux cadres réglementaires (par ex. le RGPD en Europe, la LPRPDE au Canada ou le NIST/HIPAA aux États-Unis), certains fournisseurs doivent conserver les données à l'intérieur de frontières géographiques spécifiques.

Une architecture agnostique à la région garantit que le service de passkeys peut être déployé dans n'importe quelle région AWS souhaitée, répondant aux mandats de conformité locaux sans sacrifier les performances ou l'évolutivité.

Cette flexibilité est particulièrement importante si votre base d'utilisateurs s'étend sur plusieurs pays, chacun appliquant des règles de traitement des données différentes.

Pour les flux d'authentification de paiement critiques, les temps d'arrêt ne sont pas une option. Corbado emploie des déploiements multi-AZ, distribuant les composants clés sur plusieurs zones de disponibilité.

Cette configuration aide à garantir que si une zone de disponibilité subit une panne ou un problème de connectivité, votre infrastructure de passkeys dans les autres zones reste en ligne - afin que les utilisateurs puissent continuer à s'authentifier.

Le résultat est un système plus résilient qui respecte des SLA stricts pour les services financiers et les sites de commerce électronique, où même une brève interruption peut entraîner un impact significatif sur les revenus.

Certains prestataires de paiement préfèrent un cluster privé dédié - que ce soit pour une isolation plus stricte des données, des contrôles de conformité personnalisés ou un contrôle plus approfondi des correctifs et des mises à jour.

Une solution flexible peut prendre en charge les deux extrêmes :

• SaaS / Multi-locataire : Rapide à mettre en œuvre, coût inférieur, bien adapté à de nombreux déploiements de taille moyenne.

• Instance cloud dédiée : Un compte et une instance de base de données distincts dans la région de votre choix, pour ceux qui ont besoin d'une isolation ou d'une conformité supplémentaires.

Les passkeys doivent gérer des charges de travail en dents de scie : d'énormes pics de trafic (par ex., les pics d'achats des fêtes ou la vente de billets d'événements) peuvent submerger les systèmes à capacité fixe.

Un back-end de passkeys moderne s'adapte horizontalement en temps réel, ajoutant ou supprimant des instances de calcul en fonction des modèles d'utilisation. Cette mise à l'échelle automatique garantit des performances constantes sans intervention manuelle.

Les normes de l'industrie comme PCI-DSS, DSP2 SCA ou ISO 27001 s'appliquent souvent aux prestataires de paiement. Un fournisseur de passkeys robuste s'intègre généralement aux cadres de conformité connus dès le départ :

• Chiffrement au repos et en transit : Sécurisez les données avec un TLS fort et un chiffrement côté serveur ou côté client pour les informations d'identification stockées.

• Journalisation et pistes d'audit : Journaux détaillés pour chaque opération de passkey, adaptés aux régulateurs ou aux enquêtes sur les incidents.

• Application régulière de correctifs de sécurité : Application automatique de correctifs pour l'OS et les conteneurs afin de tenir les vulnérabilités à distance, particulièrement pertinent dans un environnement multi-AZ fluide.

La véritable résilience s'étend au-delà d'une seule région. Certains fournisseurs exigent une réplication inter-régionale pour maintenir la continuité des activités lors de catastrophes à grande échelle.

La géo-redondance peut répliquer les données de passkeys dans une région ou un continent différent, garantissant que l'indisponibilité d'une région entière n'arrête pas les flux d'authentification.

Résumé : Multi-AZ et indépendant de la région

Choisir une solution de passkeys qui s'adapte facilement, s'adapte géographiquement et résiste à la fois aux pannes locales et aux catastrophes à grande échelle est essentiel pour les prestataires de paiement modernes - en particulier ceux qui opèrent dans plusieurs pays ou sous une conformité stricte. En prenant en charge les déploiements multi-AZ et les configurations agnostiques à la région, Corbado (ou des solutions comparables) garantit que les services de passkeys de paiement restent à la fois disponibles et conformes, peu importe où se trouvent vos utilisateurs ou vos données.

Les passkeys représentent en effet la prochaine génération d'authentification sécurisée et conviviale. Pourtant, les prestataires de paiement sont confrontés à des défis uniques que la conception traditionnelle de WebAuthn n'aborde pas directement. Ces limitations sont les plus prononcées dans :

1. Le refus de Safari d'autoriser la création de passkeys cross-origin (en particulier dans les iframes), forçant soit une approche basée sur la redirection, soit une dépendance à des passkeys créés précédemment.

2. Le manque de support d'Apple pour la Secure Payment Confirmation (SPC), empêchant un flux de paiement standardisé et sans friction sur les navigateurs et les plateformes.

Néanmoins, les passkeys restent essentiels pour les prestataires de paiement qui cherchent à offrir une expérience de paiement de type Apple Pay : simplifiée, sécurisée et délicieusement simple pour les utilisateurs finaux. Voici comment ces défis peuvent être relevés et comment Corbado aide.

1. Quelles sont les limites actuelles de l'utilisation des passkeys dans des contextes tiers pour les prestataires de paiement ?

• Restrictions cross-origin : Safari (et certains navigateurs plus anciens) bloquent navigator.credentials.create() lorsqu'il est intégré via un iframe. Cela signifie que vous ne pouvez pas créer de nouveaux passkeys de manière transparente dans un flux intégré chez un commerçant sur ces navigateurs.

• Absence de support SPC : Le refus d'Apple d'adopter la SPC limite la capacité à standardiser les confirmations de paiement cross-origin, forçant les fournisseurs à maintenir des approches distinctes pour Safari par rapport à Chrome/Edge.

• Contraintes des WebView et des applications natives : Les WebViews intégrées cassent souvent les flux de passkeys, nécessitant des sessions de navigateur système ou d'autres approches spécialisées pour gérer l'alignement de l'origine du domaine.

• Couverture fragmentée des appareils : Même si l'utilisateur crée un passkey sur un appareil ou un navigateur, il peut manquer de couverture sur d'autres, ce qui entraîne une utilisation de repli.

2. Comment les prestataires de paiement peuvent-ils surmonter ces limitations pour réussir l'implémentation d'intégrations de passkeys tiers ?

• Utiliser une stratégie hybride (Iframe + Redirection) :

  • Iframe pour les navigateurs qui prennent entièrement en charge les passkeys cross-origin, offrant une interface utilisateur intégrée transparente.

  • Redirection comme solution de repli pour Safari ou les configurations incompatibles, garantissant qu'une création de passkey robuste est toujours possible.

• WebView système ou redirection de navigateur dans les applications natives :

  • Plutôt que d'intégrer des iframes dans les applications des commerçants, passez à ASWebAuthenticationSession (iOS) ou aux onglets personnalisés Chrome (Android) pour préserver la continuité du domaine.

  • Boîte à outils axée sur l'adoption : Fournissez des invites de création de passkeys convaincantes, des flux de couverture multi-appareils et des étapes de « réparation » de repli pour maintenir une utilisation élevée.

  • Analyses avancées et tests A/B :

    • Mesurez en continu les taux de réussite/repli des passkeys, la couverture de l'environnement et les commentaires des utilisateurs pour affiner vos flux.

    • Utilisez l'intelligence des passkeys pour présenter automatiquement les passkeys uniquement lorsque le succès est probable.

Tout au long de ce guide, nous avons souligné que le simple fait de connecter navigator.credentials.create() ne suffit pas. Le véritable succès repose sur une adoption élevée des passkeys, une expérience utilisateur cohérente et une couverture multi-appareils résiliente. C'est là que Corbado excelle :

• Support unifié pour Iframe et Redirection : Le SDK de Corbado détecte automatiquement si un flux de passkey intégré est réalisable (par exemple, sur Chrome ou Edge) ou si une redirection est nécessaire (par exemple, Safari). Cela maximise la compatibilité sans obliger les commerçants à maintenir plusieurs chemins de code.

  • Expérience de paiement en un clic : Avec la Passkey Intelligence, Corbado détecte instantanément si l'environnement d'un utilisateur a probablement un passkey valide - déclenchant un flux « payer avec passkey » sans friction. Cette approche s'inspire du paiement en un clic d'Apple Pay, stimulant l'utilisation quotidienne des passkeys plutôt que de la reléguer à une étape MFA rarement utilisée.

  • Couverture multi-appareils robuste : Corbado fournit des flux spéciaux pour la création initiale de passkeys par rapport aux extensions de passkeys secondaires, afin que chaque utilisateur puisse rapidement ajouter une couverture pour de nouveaux appareils après s'être connecté via un repli ou un QR inter-appareils.

  • Approche d'adoption complète : Grâce à des analyses intégrées, des tests A/B et une gestion des erreurs, Corbado aide les fournisseurs à identifier les points de friction et à optimiser systématiquement l'acceptation des passkeys. Cela s'étend des premières invites de passkey des banques aux expériences de paiement des commerçants.

  • Hébergement flexible et conforme : Les déploiements multi-AZ et agnostiques à la région de Corbado s'alignent sur la conformité stricte de l'industrie des paiements (PCI DSS, DSP2 SCA, etc.), garantissant la disponibilité et le respect des règles de résidence des données dans le monde entier.

Bien que les politiques restrictives d'Apple créent des frictions inévitables, les prestataires de paiement peuvent toujours implémenter avec succès des passkeys tiers en :

1. Combinant une approche intégrée (iframe) avec une solution de repli par redirection.

2. Adoptant des webviews système spécialisées ou des flux de navigateur externes pour les applications natives.

3. Se concentrant sur des stratégies d'adoption robustes : couverture multi-appareils, « réparation » par repli, analyses avancées et tests A/B.

Corbado rassemble tous ces éléments, offrant une plateforme de passkeys d'entreprise qui couvre l'inscription aux passkeys, l'utilisation en un clic, l'optimisation basée sur les analyses et l'hébergement à l'échelle mondiale. Le résultat : une expérience véritablement fluide comme Apple Pay pour votre propre service de paiement, offrant à la fois une sécurité accrue et un parcours utilisateur supérieur.