Passkeys para proveedores de pago: Cómo crear un SDK de terceros

Las passkeys se están consolidando como el método más eficaz para proteger y autorizar transacciones en línea, mejorando significativamente la seguridad y la comodidad en comparación con la autenticación multifactor (MFA) tradicional. Recientemente, PayPal adoptó las passkeys como su principal solución de MFA autónoma, marcando una clara tendencia para los proveedores de pago de todo el mundo.

Sin embargo, las passkeys se diseñaron originalmente pensando en contextos de primera parte, lo que significa que funcionan de manera óptima cuando los usuarios se autentican directamente en el sitio web o la aplicación propietaria de las credenciales. Los proveedores de pago, por el contrario, suelen operar en contextos de terceros, donde sus servicios (como formularios de pago o SDK) se integran en los sitios web y aplicaciones de los comercios. Este desajuste fundamental entre el diseño de las passkeys y los modelos operativos de los proveedores de pago presenta limitaciones críticas para una integración fluida. Para abordar estos desafíos, debemos explorar dos preguntas cruciales:

1. ¿Cuáles son las limitaciones actuales del uso de passkeys en contextos de terceros para los proveedores de pago? 2. ¿Cómo pueden los proveedores de pago superar estas limitaciones para implementar con éxito integraciones de passkeys de terceros?

Al examinar estas preguntas, revelaremos que los esfuerzos actuales de la industria para adaptar las passkeys a contextos de terceros, en particular a través de estándares web como la Confirmación de Pago Segura (SPC), están bloqueados por barreras estratégicas impuestas implícitamente por Apple. Específicamente, el soporte limitado de Apple para la creación de passkeys de origen cruzado en Safari y la falta de soporte del estándar de Confirmación de Pago Segura representan un obstáculo significativo, complicando la adopción fluida de la autenticación basada en passkeys por parte de proveedores de pago de terceros. Comprender y superar estos obstáculos es esencial para cualquier proveedor que busque ofrecer experiencias de pago seguras y sin fricciones.

Las passkeys aportan un inicio de sesión biométrico y resistente al phishing a cada capa del stack de pagos. A continuación, se detalla cómo cada actor en la cadena de valor de los pagos puede beneficiarse de la integración de la autenticación con passkeys.

Impacto: Checkout más rápido, mayor conversión, menos carritos abandonados.
Oportunidad: Los comercios que ofrecen passkeys a través de SDK o flujos de redirección pueden imitar una experiencia de usuario al nivel de Apple Pay y reducir la dependencia de contraseñas u OTP, lo que genera mayor confianza y ventas.

Impacto: Autenticación sin contraseña fluida en todos los dispositivos.
Oportunidad: Las passkeys ofrecen una mejor experiencia de usuario que los códigos OTP o SMS y eliminan el riesgo de phishing. Una adopción amplia podría convertir las passkeys en el nuevo estándar para la verificación de titulares de tarjetas.

Impacto: Prevención de fraude más sólida.
Oportunidad: Los emisores pueden ofrecer autenticación step-up basada en passkeys en los flujos 3DS, reduciendo los costos de OTP y mejorando la satisfacción del usuario.

Impacto: Mayor aceptación de transacciones y menos autenticaciones fallidas.
Oportunidad: Soportar passkeys a través de PSP puede mejorar los resultados de los comercios y reducir la fricción durante el checkout o los flujos de facturación recurrente.

Impacto: Reducción del fraude, mejor experiencia de usuario para el comercio y mayor cumplimiento normativo.
Oportunidad: Al integrar o redirigir flujos de passkeys, los PSP pueden proporcionar una autenticación de última generación manteniendo la compatibilidad entre navegadores y aplicaciones nativas.

Impacto: Aprobaciones de transacciones optimizadas con menos pagos rechazados.
Oportunidad: Las empresas de procesamiento de pagos pueden integrar la verificación con passkeys en sus API para reducir el riesgo y admitir alternativas de SCA biométricas para flujos que cumplan con la normativa.

Impacto: Almacenamiento seguro de credenciales y reautenticación sin fricciones.
Oportunidad: Los proveedores de wallets como Apple Pay y Google Pay ya utilizan flujos similares a las passkeys.

A continuación, echamos un vistazo a los principales proveedores de pago y tarjetas de crédito y analizamos si han implementado passkeys y cómo lo han hecho:

Mastercard ha lanzado oficialmente su Payment Passkey Service, que proporciona una experiencia de autenticación sin contraseña integrada en los flujos EMV 3DS. Los usuarios pueden crear y usar passkeys vinculadas al dominio de autenticación de Mastercard (p. ej., verify.mastercard.com), lo que permite un inicio de sesión biométrico seguro en los comercios participantes. Este lanzamiento representa un paso importante hacia una autenticación resistente al phishing y compatible con PSD2 en la industria de pagos.
Leer más: Passkeys de Mastercard

Visa ha presentado su Visa Payment Passkey Service, integrando las passkeys en el flujo de "Click to Pay". Al permitir que los usuarios se autentiquen sin problemas mediante datos biométricos en lugar de contraseñas u OTP, Visa busca modernizar la experiencia de pago en línea con una mayor seguridad y comodidad para el usuario.
Leer más: Passkeys de VISA

American Express aún no ha lanzado públicamente una oferta de passkeys. Sin embargo, como miembro a nivel de junta de la FIDO Alliance, es probable que American Express implemente una solución de autenticación basada en passkeys en un futuro próximo, en línea con las tendencias más amplias de la industria.

PayPal fue uno de los primeros proveedores de pago en adoptar las passkeys. Su implementación admite un inicio de sesión biométrico fluido para cuentas personales y de empresa en todos los dispositivos. La passkey está vinculada al dominio de PayPal y ya está disponible en muchas regiones. Sin embargo, su implementación tiene margen de mejora, especialmente en lo que respecta a los flujos multidispositivo y la detección de plataformas.
Leer más: Passkeys de PayPal

Klarna aún no ha introducido oficialmente el soporte para passkeys. Según nuestras observaciones, Klarna depende en gran medida de WebViews embebidos en su aplicación y SDK de checkout. Dado que Safari e iOS restringen la creación de passkeys en iframes / WebViews, esta podría ser una de las razones por las que Klarna no ha implementado las passkeys hasta ahora.

Square ha introducido el inicio de sesión con passkeys para su panel de desarrolladores y su consola de administración, lo que permite un acceso seguro y sin contraseña a las herramientas internas. Sin embargo, no se ha hecho ningún anuncio sobre el soporte de passkeys en los flujos de pago o las API para usuarios finales o comercios.

Stripe ha implementado el inicio de sesión con passkeys para su panel de control, lo que permite a los desarrolladores autenticarse mediante datos biométricos. Las passkeys para Stripe Checkout o Elements aún no están disponibles. Dada la fuerte defensa de Stripe por los flujos basados en redirección, es probable que las passkeys, si se implementan en los pagos, sigan esa misma arquitectura de redirección.

Hasta ahora, BILL no ha realizado ningún anuncio público ni actualización de producto relacionada con las passkeys para la autenticación.

Remitly no ha revelado ningún plan o información pública sobre la implementación de la autenticación con passkeys en sus servicios.

No hay informes públicos ni documentación de producto que indiquen que Payoneer haya adoptado o esté probando el inicio de sesión o los flujos de transacción basados en passkeys.

Adyen aún no ha introducido las passkeys en sus flujos de autenticación o pago. Ninguna declaración pública o documentación para desarrolladores menciona el soporte de passkeys.

Worldpay no ha anunciado ningún soporte para passkeys por el momento. Su stack de autenticación todavía se basa en métodos tradicionales como contraseñas, OTP y flujos basados en 3DS.

Checkout.com no ha implementado públicamente el soporte para passkeys. No hay actualizaciones para desarrolladores, publicaciones de blog o anuncios oficiales sobre la adopción de passkeys.

AliPay no ha lanzado oficialmente las passkeys. Dada la creciente tendencia de la autenticación biométrica en los ecosistemas de pago chinos, es posible que se produzca un lanzamiento en el futuro, pero ninguna documentación actual lo confirma.

Mollie no ha hecho ninguna declaración pública ni actualización de producto sobre la adopción de passkeys en sus sistemas de autenticación o checkout.

Amazon ha implementado el soporte de passkeys para los inicios de sesión de los usuarios en su plataforma principal. Extender esta tecnología a Amazon Pay sería un siguiente paso natural, especialmente porque muchos usuarios ya tienen una passkey registrada en Amazon, lo que simplificaría significativamente la incorporación de usuarios durante el checkout.

Braintree, una empresa de PayPal, aún no ha adoptado oficialmente la autenticación con passkeys. Su documentación actual no menciona las passkeys en el contexto del inicio de sesión de usuarios o las API para comercios.

Link, la solución de checkout en un clic de Stripe, ha implementado passkeys que podrían servir como base para la estrategia de passkeys de Stripe en los pagos al consumidor. Sin embargo, Stripe no ha anunciado oficialmente el soporte de passkeys para Link ni ningún plan específico para su implementación.

Afterpay no ha publicado ninguna declaración o funcionalidad relacionada con el soporte de passkeys. Al igual que Klarna, su integración de checkout se basa en gran medida en la aplicación, lo que puede plantear obstáculos técnicos para la adopción de passkeys debido a las restricciones de los WebView embebidos.

La adopción de passkeys por parte de proveedores de pago de terceros se enfrenta a obstáculos estratégicos, impulsados principalmente por las políticas restrictivas de Apple en Safari. Dos intentos críticos de estandarización han sido obstaculizados constantemente:

• Confirmación de Pago Segura (SPC)

• Creación de passkeys de terceros en iframes

La Confirmación de Pago Segura (SPC) representa el esfuerzo más significativo de la industria, impulsado principalmente por Google, para permitir el uso fluido y de origen cruzado de passkeys diseñadas específicamente para autorizaciones de pago seguras. La SPC estandariza cómo los proveedores de pago autentican a los usuarios en múltiples sitios de comercios sin comprometer la seguridad o la experiencia del usuario. Sin embargo, Apple ha negado sistemáticamente el soporte para SPC en Safari, probablemente como una medida estratégica para garantizar que Apple Pay siga siendo la solución de pago preferida y más fluida dentro de su ecosistema. La negativa de Apple a adoptar la SPC no solo limita el despliegue generalizado de passkeys en contextos de terceros, sino que también retrasa eficazmente una adopción más amplia en la industria de la autenticación de pagos estandarizada.

Lee esta publicación de blog sobre la SPC si quieres aprender más sobre los detalles.

Otra barrera crítica implica la restricción deliberada de Apple a la creación de passkeys dentro de iframes de origen cruzado. Mientras que Safari permite el uso de passkeys existentes para la autenticación (navigator.credentials.get()) en un iframe de terceros, bloquea explícitamente el registro de passkeys (navigator.credentials.create()) en dichos contextos.

Esta limitación restringe severamente a los proveedores de pago que dependen de la creación de nuevas passkeys de forma fluida durante el flujo de pago del comercio. En consecuencia, los proveedores se ven obligados a utilizar enfoques basados en redirección o a depender de passkeys existentes establecidas previamente directamente en sus propios dominios. Esta decisión de Apple afecta directamente la practicidad y fluidez de las integraciones con los comercios, creando un punto de fricción significativo tanto para los consumidores como para los proveedores.

En este enfoque, el comercio incluye tu formulario de pago en un <iframe> servido desde el dominio de tu proveedor de pagos, por ejemplo, https://pay.provider.com. El usuario permanece en el dominio del comercio (p. ej., https://www.mitienda.com), ve tu interfaz de pago en el iframe integrado y se autentica con una passkey vinculada al ID de Relying Party pay.provider.com.

Puntos clave:

• Origen cruzado: Debido a que el iframe está en un dominio diferente, debes configurar políticas de permisos para publickey-credentials-get y publickey-credentials-create para permitir operaciones de passkeys dentro del iframe.

• Limitación en la creación: Algunos navegadores (particularmente versiones antiguas y Safari) todavía no permiten la creación de passkeys en iframes de origen cruzado. La autenticación (navigator.credentials.get()) tiene un soporte más amplio, pero el registro (navigator.credentials.create()) puede fallar en ciertos entornos, especialmente en Safari.

• Activación del usuario: Los flujos de passkeys suelen requerir una "activación transitoria" (p. ej., un clic directo en un botón por parte del usuario). Asegúrate de que tu interfaz de iframe active la ceremonia de la passkey dentro de un evento iniciado por el usuario.

• Seguridad y UX: El enfoque de iframe proporciona una experiencia de pago fluida e integrada, pero si el navegador de un usuario bloquea o restringe las cookies de terceros o el almacenamiento local, puede interrumpir el flujo de la passkey.

Con un flujo basado en redirección, envías al usuario desde el dominio del comercio a tu dominio de pago, o abres una nueva pestaña/ventana que apunta a algo como https://pay.provider.com/checkout. Las passkeys se crean o utilizan directamente en tu dominio en un contexto de primera parte.

Puntos clave:

• Simplicidad de primera parte: Todo el flujo de trabajo de la passkey (creación, autenticación) ocurre en el dominio del proveedor de pagos, por lo que no hay restricciones de origen cruzado. Todos los principales navegadores admiten la creación y el inicio de sesión con passkeys en contextos de primera parte.

• UX de redirección: El usuario abandona la página del comercio (o ve una ventana emergente) para completar la autenticación. Esto puede ser menos fluido, pero simplifica la arquitectura de passkeys y reduce las complejidades del origen cruzado.

• Alternativa para navegadores incompatibles: Puedes degradar la experiencia de forma elegante si las passkeys no están disponibles (p. ej., en navegadores antiguos) proporcionando métodos de inicio de sesión alternativos en tu dominio de pago sin necesidad de un manejo adicional de permisos de origen cruzado.

La integración de passkeys en aplicaciones móviles nativas presenta desafíos únicos en comparación con los escenarios basados en la web. Las aplicaciones nativas para comercios (tanto en iOS como en Android) a menudo integran los flujos de pago dentro de la aplicación utilizando WebViews embebidos para mantener una experiencia de usuario fluida. Sin embargo, implementar la autenticación con passkeys de terceros en estos contextos integrados puede ser problemático debido a las estrictas políticas de origen del navegador y las limitaciones específicas de la plataforma.

Las passkeys están inherentemente vinculadas a un dominio específico (el "ID de Relying Party"), que es un principio de seguridad fundamental que garantiza que las credenciales no se puedan usar indebidamente en sitios web o aplicaciones no relacionadas. Cuando un proveedor de pagos crea passkeys bajo su propio dominio, por ejemplo, pay.provider.com, esas passkeys están estrictamente limitadas a ese dominio tanto en iOS como en Android. Como resultado, la aplicación nativa de un comercio (que naturalmente opera bajo el propio identificador de aplicación y dominio del comercio) no puede invocar directamente las passkeys del proveedor como una credencial de "primera parte". Hacerlo requeriría compartir claves privadas entre orígenes, lo que los sistemas operativos y las especificaciones de WebAuthn prohíben explícitamente para prevenir el phishing y el robo de credenciales.

Desde la perspectiva del dispositivo, la aplicación nativa del comercio es un "origen" diferente al dominio del proveedor de pagos. Intentar autenticarse de forma nativa con credenciales registradas en un origen separado rompería el modelo de seguridad fundamental de las passkeys, que está vinculado al origen. Esta es precisamente la razón por la que el uso de passkeys de terceros en un contexto de comercio depende de un navegador del sistema o de un WebView basado en el sistema (como ASWebAuthenticationSession en iOS o Chrome Custom Tabs en Android). Estos flujos especiales preservan el contexto del dominio original del proveedor, asegurando que las passkeys permanezcan vinculadas de forma segura a su origen, al tiempo que permiten a los usuarios autenticarse con el proveedor de pagos dentro de la aplicación de un comercio. En las siguientes secciones, exploraremos cómo funciona esto.

Los WebViews embebidos (p. ej., WKWebView en iOS o el WebView de Android) son muy populares porque permiten a las aplicaciones integrar contenido web directamente en sus interfaces nativas, ofreciendo una integración estrecha y consistencia en la experiencia de usuario. Sin embargo, estos entornos integrados están significativamente restringidos cuando se manejan passkeys de terceros debido a las políticas de origen y seguridad:

• Desajuste de origen: Las passkeys dependen estrictamente de los orígenes de dominio para un manejo seguro de las credenciales. Un WebView embebido opera bajo el dominio del contenido que muestra (a menudo el del comercio), lo que hace que sea difícil o imposible crear o autenticar passkeys vinculadas explícitamente al dominio de un proveedor de pagos de terceros.

• Restricciones de seguridad de la plataforma: Tanto Apple (iOS) como Google (Android) han restringido progresivamente las capacidades de los WebViews embebidos para la autenticación, particularmente cuando se trata de credenciales seguras. Estas restricciones están diseñadas para proteger la privacidad del usuario y la seguridad, pero hacen que la implementación de passkeys de terceros sea notablemente más complicada.

En general, aunque los WebViews embebidos son atractivos para los comercios desde la perspectiva de la experiencia de usuario, introducen limitaciones prácticas significativas para implementar flujos de autenticación con passkeys de terceros robustos.

Dados los límites asociados con los WebViews embebidos, los proveedores de pago suelen adoptar una de dos estrategias alternativas para implementar de manera fiable las passkeys de terceros en aplicaciones móviles nativas:

iOS (ASWebAuthenticationSession):

Apple proporciona ASWebAuthenticationSession como un entorno seguro, similar a un navegador, fuera del contexto de la aplicación anfitriona. Comparte el almacenamiento de cookies con el navegador Safari predeterminado y admite passkeys de terceros de manera fiable porque las credenciales se alinean con el dominio de origen del proveedor de pagos.

El siguiente ejemplo demuestra la funcionalidad "Pagar con PayPal" dentro de la aplicación nativa de BOSS. Muestra cómo se abre un webview del sistema ASWebAuthenticationSession, que comparte su estado con las cookies de Safari, permitiendo que el diálogo de la passkey se inicie inmediatamente.

Android (Chrome Custom Tabs):

De manera similar, las Custom Tabs de Android ofrecen un entorno casi de navegador que permite la creación y autenticación de passkeys de manera consistente. Al igual que ASWebAuthenticationSession, las Custom Tabs se ejecutan por separado del contexto de la aplicación del comercio, garantizando la integridad del dominio y las credenciales.

Observa el mismo ejemplo de la aplicación nativa de BOSS en Android aquí:

Otro enfoque implica redirigir a los usuarios fuera de la aplicación nativa al navegador web predeterminado del dispositivo móvil (Safari en iOS, Chrome en Android). Esto asegura que el flujo de pago, y por lo tanto la gestión de passkeys, ocurra completamente en un contexto de primera parte de confianza asociado con el dominio del proveedor de pagos. Luego, los usuarios regresan a la aplicación del comercio después de una autenticación o pago exitoso. Esta opción es muy inconveniente para los clientes porque tienen que salir de la aplicación.

Ambas soluciones requieren una transición temporal de los usuarios fuera del entorno de la aplicación nativa del comercio. Aunque son un poco menos fluidos en comparación con las soluciones integradas, estos enfoques mejoran significativamente la compatibilidad, la seguridad y la fiabilidad de las operaciones con passkeys de terceros.

En última instancia, los proveedores de pago que desarrollan SDK nativos deben equilibrar cuidadosamente las consideraciones de la experiencia del usuario con las restricciones técnicas prácticas. A pesar de las preferencias de los comercios por experiencias totalmente integradas, aprovechar los WebViews del sistema o la redirección a un navegador externo sigue siendo la mejor práctica para garantizar una autenticación con passkeys de terceros segura y fiable dentro de las aplicaciones nativas.

Elegir entre un enfoque integrado (iframe) y uno basado en redirección para integrar passkeys de terceros en los SDK de pago implica evaluar las compensaciones en la experiencia del usuario, la compatibilidad con navegadores, la complejidad técnica y las preferencias de los comercios.

Ambas soluciones tienen ventajas y desventajas distintas, que los proveedores de pago deben considerar cuidadosamente en función de su mercado objetivo, la experiencia de usuario deseada y la infraestructura técnica.

El enfoque integrado (iframe) ofrece una experiencia de usuario fluida y con la marca del comercio, muy atractiva para estos, pero se ve obstaculizada por una compatibilidad limitada con los navegadores, en particular por la negativa de Safari a permitir la creación de passkeys de origen cruzado. Esta limitación obliga a los comercios y proveedores a adoptar soluciones complejas basadas en alternativas que a menudo comprometen la funcionalidad o conducen a un soporte incompleto para el registro de passkeys.

Por el contrario, el enfoque de redirección ofrece una compatibilidad completa entre navegadores y plataformas móviles nativas al operar en un contexto de dominio de primera parte. Simplifica significativamente la integración, mejora la fiabilidad y garantiza un soporte completo para la creación y autenticación de passkeys. El principal inconveniente es la posible fricción creada al redirigir a los usuarios fuera del sitio web o la aplicación del comercio, aunque esto puede mitigarse con un diseño de UX cuidadoso, expectativas claramente comunicadas o integraciones con plataformas de confianza como Corbado.

Considerando estos factores, un enfoque híbrido suele ser ideal, permitiendo a los proveedores de pago aprovechar el modelo de iframe integrado cuando el navegador del usuario lo admite y recurrir elegantemente a un enfoque de redirección en caso contrario. Esta estrategia combinada maximiza la compatibilidad, el atractivo para el comercio y la satisfacción del cliente en diversos entornos.

Implementar un SDK de pago con passkeys de terceros implica equilibrar la experiencia del usuario, la compatibilidad con navegadores, las restricciones de las aplicaciones nativas, la analítica y la seguridad, especialmente dados los obstáculos específicos de Apple (p. ej., bloqueo de la creación de passkeys de origen cruzado, falta de soporte para SPC). A continuación se presentan recomendaciones clave para garantizar el mejor resultado posible al integrar passkeys en flujos de pago web o nativos.

Debido al soporte variable de los navegadores y a los comportamientos inconsistentes de Apple, es fundamental admitir tanto un enfoque integrado (basado en iframe) como un enfoque de redirección:

• Checkout con Iframe (Integrado)

  • Proporciona una experiencia fluida en la misma página para los navegadores modernos que sí permiten operaciones de passkeys de origen cruzado (principalmente para la autenticación).

  • Debe establecer la Permissions-Policy correcta para publickey-credentials-get/publickey-credentials-create.

  • Ten en cuenta que Safari y algunos navegadores más antiguos bloquean la creación de passkeys de origen cruzado en iframes.

• Flujo de redirección

  • Admite de manera fiable tanto el registro como el inicio de sesión con passkeys en un contexto de primera parte.

  • Un poco más de fricción debido a la redirección o ventana emergente adicional, pero universalmente más seguro para la compatibilidad entre navegadores.

  • Alternativa ideal para Safari, que actualmente no permite la creación de passkeys de terceros en iframes.

Al ofrecer ambos enfoques, puedes decidir dinámicamente, o dejar que los comercios decidan, cuál usar, maximizando la compatibilidad para todos los entornos de usuario.

Detectar las capacidades del navegador con precisión sigue siendo un desafío debido a la reducida granularidad del User-Agent y al soporte inconsistente de los Client Hints en las diferentes plataformas.

El análisis tradicional es cada vez menos fiable a medida que los navegadores reducen el detalle en las cadenas de User-Agent para proteger la privacidad del usuario. Diferenciar detalles esenciales, como Windows 10 vs. Windows 11, versiones precisas de macOS o arquitecturas de CPU, es ahora difícil o imposible usando solo el User-Agent.

Mientras que los Client Hints proporcionan datos de alta entropía de una manera que respeta la privacidad, solo los navegadores basados en Chromium los admiten por completo. Safari y Firefox no ofrecen soporte para Client Hints, lo que restringe severamente la detección precisa de características en los dispositivos de Apple.

Los WebViews embebidos suelen restringir el acceso a información detallada del dispositivo y rara vez admiten Client Hints. Esta limitación hace que la detección de la capacidad de las passkeys sea especialmente desafiante en contextos de aplicaciones nativas.

Dados estos límites, detectar de manera fiable el soporte de passkeys de origen cruzado, particularmente en SDK de pago de terceros, requiere una combinación cuidadosa de consultas dinámicas de Client Hints (cuando estén disponibles), heurísticas de User-Agent como alternativa y comportamientos predeterminados conservadores para navegadores como Safari y Firefox.

Las aplicaciones nativas de los comercios a menudo integran contenido web en WKWebView (iOS) o Android WebView, que son muy restrictivos para las passkeys. Las estrategias comunes incluyen:

• Sesiones del navegador del sistema: Usa ASWebAuthenticationSession (iOS) o Custom Tabs (Android) para trasladar la creación/inicio de sesión con passkeys a un contexto de navegador seguro de "primera parte".

• Redirección al navegador predeterminado: Un enfoque menos fluido pero altamente fiable para garantizar la integridad del dominio para las operaciones con passkeys.

Como proveedor de pagos, una seguridad sólida y el cumplimiento normativo (PCI, PSD2 SCA, etc.) son clave:

• Encabezados y seguridad del contenido: Implementa encabezados Permissions-Policy estrictos y reglas CSP robustas para flujos de origen cruzado.

• Registro y monitoreo: Registra exhaustivamente los eventos de creación y uso de passkeys para la prevención de fraudes y auditorías de cumplimiento.

• Almacenamiento mínimo de PII: Asocia a los usuarios con las passkeys mediante identificadores con hash, reduciendo la exposición bajo el GDPR o leyes de protección de datos similares.

• Pistas de auditoría: Registra cada evento de creación y autenticación de passkeys para detectar anomalías y satisfacer las auditorías de cumplimiento.

Las passkeys todavía están evolucionando, por lo que necesitarás verificaciones continuas:

• Pruebas entre navegadores y sistemas operativos: Automatiza las pruebas en Safari, Chrome, Edge, Firefox y las principales versiones de sistemas operativos móviles.

• Actualizaciones frecuentes: Sigue los cambios en las especificaciones de WebAuthn del W3C, las directrices de la FIDO Alliance o las propuestas de SPC.

• Comentarios de los usuarios y tasas de error: Registra los errores de las passkeys (creación o inicio de sesión) para solucionar problemas rápidamente, especialmente para los usuarios de Apple.

Un marco de KPI robusto te ayuda a rastrear si tu integración de passkeys de terceros realmente mejora la seguridad y la experiencia del usuario. Aunque este artículo trata sobre la implementación de SDK, es importante tener en cuenta que la adopción de passkeys también es clave en este caso de uso. La tasa de creación y la tasa de uso de las passkeys necesitan un análisis y una optimización cuidadosos.

• Definición: Porcentaje de usuarios que crean una passkey con éxito cuando se les solicita (p. ej., en el checkout o en la configuración de la cuenta).

• Por qué es importante: Una alta tasa de creación significa que tu flujo de incorporación/incentivo para las passkeys es convincente y sin fricciones.

• Objetivo: Deberías aspirar a una tasa del 50-80%.

• Definición: De los usuarios que inician la ceremonia de creación (hacen clic en "Crear Passkey"), ¿cuántos la finalizan sin abortar o sin errores?

• Por qué es importante: Indica qué tan bien está funcionando tu flujo de origen cruzado o de redirección.

• Objetivo: Idealmente, deberías tener una cifra de ~95–100% una vez que el usuario opta por participar.

• Definición: El porcentaje del total de autorizaciones de pago (o inicios de sesión) realizadas a través de passkeys, en contraposición a los métodos alternativos.

• Por qué es importante: La creación no tiene sentido si los usuarios vuelven a los métodos antiguos por defecto.

• Objetivo: Una tasa del 50–80% indica una fuerte adopción de passkeys.

• Definición: Porcentaje de intentos de inicio de sesión con passkeys que tienen éxito sin errores ni métodos alternativos.

• Por qué es importante: Un reflejo de tu usabilidad en el mundo real.

• Objetivo: Normalmente deberías superar el 90–95% para considerar que las passkeys son "sin fricciones".

• Definición: ¿Con qué frecuencia los usuarios fallan con las passkeys a mitad de la ceremonia y cambian a una contraseña o un OTP?

• Por qué es importante: Un alto uso de métodos alternativos sugiere que hay obstáculos técnicos o de UX que impiden que las passkeys reemplacen a los métodos heredados.

• Objetivo: Idealmente, el uso de métodos alternativos es inferior al 1-5%.

Para los proveedores de pago, mide si las passkeys reducen el fraude, aceleran el checkout o disminuyen el abandono de carritos. Combina los datos de uso de passkeys con la conversión de pagos o las métricas de éxito de 3-D Secure para obtener una visión holística.

Monitorear estos KPI te ayuda a identificar qué entornos o recorridos de usuario necesitan mejorar; por ejemplo, si Safari en iOS tiene una tasa de abandono más alta debido a los bloqueos de origen cruzado, puedes dirigir sistemáticamente a esos usuarios a un flujo de redirección.

Uno de los desafíos más críticos en la construcción de un SDK de passkeys de terceros es orquestar un flujo de creación fluido y consistente, donde los usuarios realmente registren sus passkeys. Ya sea que esto ocurra en el portal de un banco, dentro de la configuración de la cuenta del propio proveedor de pagos o directamente en la página de checkout de un comercio, los pasos principales para el registro de la passkey son muy similares. En consecuencia, el enfoque para la creación de passkeys no cambia fundamentalmente si se integra el flujo en un iframe o se redirige al usuario a una página de primera parte; lo que más importa es proporcionar pantallas claras y fáciles de usar, gestionar las restricciones de origen cruzado y rastrear las métricas esenciales que muestran cuán eficazmente los usuarios adoptan las passkeys. A continuación se presentan los aspectos clave de un flujo de creación de passkeys de mejores prácticas y cómo Corbado los apoya:

Independientemente de dónde se le pida a un usuario que cree una passkey —ya sea en el entorno de banca en línea de un banco, en el sitio web/aplicación del propio proveedor de pagos o en el checkout de un comercio— Corbado proporciona componentes preconstruidos y personalizables para las indicaciones al usuario, las confirmaciones de éxito y el manejo de errores.

Estos componentes aseguran una apariencia consistente al tiempo que permiten el branding de marca blanca para que cada banco o comercio pueda retener sus elementos de diseño únicos si es necesario.

Observa el siguiente componente de UI para la pantalla de creación de passkeys con la marca de VicRoads:

Corbado recopila y unifica datos de todos los puntos de creación:

• Sitios web o aplicaciones de bancos donde se ofrecen inicialmente las passkeys.

• La configuración de la cuenta personal del proveedor de pagos (donde los usuarios pueden gestionar las credenciales).

• Páginas de checkout de comercios que opcionalmente permiten la creación de passkeys "sobre la marcha".

Este enfoque unificado facilita la medición de la tasa de creación de passkeys, la tasa de éxito en la creación, los puntos de abandono del usuario y cualquier error técnico, sin importar qué canal inicie el registro de la passkey.

Corbado ofrece funciones de pruebas A/B para ajustar las instrucciones en pantalla, el texto de los botones y el momento de las indicaciones. Cambios sutiles en la redacción (p. ej., "Crea una passkey ahora, ¡no más contraseñas!" vs. "¡Asegura tu próximo pago con una passkey!") a menudo producen diferencias significativas en la aceptación del usuario.

Basándose en los resultados de la prueba A/B, se pueden optimizar los siguientes KPI:

• Tasa de creación: Porcentaje de usuarios que, una vez se les solicita, configuran una passkey con éxito.

• Tasa de éxito en la creación: La proporción de usuarios que finalizan la ceremonia sin abortar o sin errores.

• Uso de métodos alternativos: La tasa a la que los usuarios omiten la creación de passkeys en favor de métodos de inicio de sesión más antiguos.

• Impacto en la conversión: Para los comercios, medir si la creación de passkeys en el checkout reduce el abandono de carritos.

Los usuarios pueden crear passkeys en los siguientes contextos:

• Contexto bancario: Flujos de creación activados después de que un usuario inicie sesión en su banco, aprovechando la confianza y familiaridad del entorno bancario.

• Configuración de la cuenta del proveedor de pagos: Los usuarios configuran las passkeys directamente en la configuración de "Mi perfil" o "Seguridad" del dominio del proveedor de pagos.

• Checkout del comercio: Indicación en el paso final del pago, especialmente si el usuario no ha creado previamente una passkey. Esto puede ser integrado (iframe) o mediante redirección.

En cada escenario, la ceremonia de la passkey subyacente sigue los mismos pasos: confirmación del usuario, indicación biométrica/PIN y registro de la credencial. El SDK de Corbado asegura que las restricciones de origen cruzado (si está integrado) o el contexto de dominio de primera parte (si se redirige) se manejen sin problemas en segundo plano.

Corbado adjunta cada nueva passkey al identificador de usuario apropiado, ya sea "prefijoBanco_idUsuario" o una referencia de usuario interna en el sistema del proveedor de pagos, para que todo uso posterior sea rastreable a la cuenta de usuario correcta.

Estos metadatos también son cruciales para análisis avanzados: por ejemplo, ver cómo se desempeñan las campañas de creación de passkeys de RBC en comparación con las de TD, o cómo difieren las tasas de creación entre los checkouts de los comercios y los flujos directos de "configuración de cuenta".

La misma lógica del SDK de Corbado puede adaptarse a si se permite la creación de passkeys de origen cruzado (en Chrome o Edge modernos) o si debe cambiar elegantemente a una redirección para Safari.

El informe de errores incorporado ayuda a identificar si algún subconjunto de usuarios falla consistentemente en la creación de passkeys (p. ej., versiones antiguas de iOS, dispositivos corporativos de Windows), para que el equipo de producto pueda refinar las instrucciones o las estrategias de fallback.

Nuestro equipo ha realizado extensos experimentos de creación de passkeys con clientes empresariales, aprendiendo qué frases, ubicaciones de botones y tiempos producen las mejores tasas de adopción.

Incorporamos estas mejores prácticas en cada pantalla de creación, al tiempo que permitimos una personalización completa para las necesidades de marca y cumplimiento.

En general, la creación de passkeys es la fase más importante para garantizar una alta adopción: incluso el flujo de inicio de sesión con passkeys más elegante no importará si los usuarios nunca registran las credenciales en primer lugar. Al ofrecer pantallas de creación uniformes y rastreables en todos los canales posibles (banco, dominio del proveedor de pagos o checkout del comercio) e instrumentarlas con análisis de KPI y pruebas A/B, Corbado ayuda a los proveedores de pago a impulsar una adopción de passkeys verdaderamente escalable, reflejando la experiencia de usuario de soluciones nativas como Apple Pay.

Una vez que un usuario ha creado una passkey, el siguiente paso es asegurarse de que realmente la utilice para pagos rápidos y sin fricciones, como el flujo de pago que presenta Apple Pay.

En Corbado, hemos desarrollado un mecanismo de "Passkey Intelligence" que detecta automáticamente cuándo es probable que el entorno de un usuario contenga una passkey válida, permitiendo una verdadera experiencia de pago con un solo toque. A continuación se presentan los elementos centrales que lo hacen posible.

Cuando se reconoce a un usuario recurrente, el front-end de Corbado muestra un botón dedicado (p. ej., "Pagar con Passkey") en lugar de forzar la entrada de credenciales alternativas.

Un solo toque en este botón activa el flujo get() de WebAuthn (o la indicación de passkey nativa), permitiendo al usuario autenticarse instantáneamente mediante datos biométricos/PIN, sin pasos adicionales ni campos de formulario.

El SDK de Corbado recopila señales (p. ej., cookies de almacenamiento local, uso exitoso previo de passkeys, detecciones del entorno) para predecir si el dispositivo + navegador actual probablemente tiene una passkey válida para este usuario.

Si las cookies se eliminan o no están disponibles, Corbado recurre a heurísticas adicionales (p. ej., entorno conocido existente del usuario, pistas de usuario proporcionadas por el comercio) para decidir si es seguro iniciar automáticamente un flujo de passkey.

Si no hay suficiente evidencia que sugiera la presencia de una passkey, la interfaz de usuario ofrece elegantemente flujos alternativos o le pide al usuario que confirme que tiene una passkey.

Corbado no almacena información de identificación personal (PII) como correos electrónicos completos o nombres.

En su lugar, el comercio puede pasar un identificador con hash o enmascarado (p. ej., un hash de correo electrónico o un ID de usuario interno). Corbado lo utiliza para buscar posibles registros de passkeys y luego decide si iniciar una autenticación con passkey o volver a un enfoque más genérico. Si el proveedor de pagos lo admite, podemos buscar la información proporcionada por el comercio para encontrar el ID de usuario interno.

Esto garantiza la privacidad del usuario al tiempo que permite una coincidencia de entorno de alta precisión.

En escenarios donde la passkey del usuario podría haber existido pero no se puede detectar (p. ej., se borraron las cookies, dispositivo nuevo), la Passkey Intelligence de Corbado analiza cuidadosamente si tiene sentido iniciar automáticamente una indicación de passkey.

En su lugar, el usuario vería flujos de fallback alternativos o una opción de "escanear passkey desde otro dispositivo", preservando al mismo tiempo un camino rápido de regreso al uso de passkeys si el usuario puede confirmar manualmente que tiene una.

Cada vez que Corbado elige iniciar u omitir una indicación de passkey de un solo toque, esa decisión se registra. Con el tiempo, puedes ver con precisión qué navegadores o tipos de dispositivos producen la mayor cobertura de passkeys frente a aquellos que con frecuencia recurren a métodos alternativos.

Este ciclo de retroalimentación analítica te permite identificar entornos de bajo rendimiento (p. ej., versiones específicas de iOS o Android) o segmentos de usuarios donde el uso de passkeys sigue siendo bajo, para que puedas refinar las estrategias de incorporación o educación.

Independientemente de si el usuario llega desde una campaña de creación de passkeys de un banco o directamente al checkout de un comercio, la lógica de un solo toque sigue siendo consistente.

Corbado asegura que si se encuentra una passkey (basándose en cookies de dominio, tokens de almacenamiento local o señales de passkey intelligence), al usuario se le presenta inmediatamente el flujo de inicio de sesión/pago más fluido.

Resumen

En resumen, el uso de passkeys con un solo toque es la recompensa final por haberlas creado en primer lugar. Al aprovechar la Passkey Intelligence —una mezcla de detección de entorno, uso mínimo de PII y lógica de fallback— Corbado asegura que a los usuarios se les presente la autenticación con passkeys solo cuando es realmente probable que tenga éxito. Esto reduce drásticamente los intentos fallidos, evita la frustración del usuario y fomenta el uso habitual de passkeys, culminando en un flujo de pago de un solo toque que rivaliza con la comodidad de Apple Pay u otras experiencias de pago nativas.

Más allá de simplemente habilitar las passkeys, es crucial comprender cuán eficazmente se adoptan y utilizan en diferentes dispositivos, navegadores y recorridos de usuario. Los proveedores de pago necesitan datos concretos sobre si las passkeys realmente reducen la fricción, disminuyen el fraude y mejoran la conversión. Basándose en las mejores prácticas de la Guía de Comprar vs. Construir Passkeys, Corbado ofrece una capa de analítica enriquecida que te permite rastrear, segmentar y optimizar el rendimiento de las passkeys en tiempo real.

A continuación se presentan los aspectos más destacados.

Corbado organiza todos los eventos de passkeys en un embudo: desde el momento en que se le solicita a un usuario que cree una passkey, pasando por el registro exitoso, hasta los inicios de sesión/pagos posteriores (uso de passkeys).

Esta visualización del embudo te permite ver dónde abandonan los usuarios; por ejemplo, cuántos nunca comienzan la creación, cuántos abandonan a mitad de la ceremonia o cuántos recurren a métodos alternativos en el inicio de sesión.

Basándonos en nuestra amplia experiencia ayudando a las empresas a implementar passkeys, nos centramos en métricas que impactan directamente en el ROI y la satisfacción del usuario:

• Tasa de aceptación de passkeys: ¿Cuántos usuarios que ven una indicación de creación completan realmente el registro de la passkey?

• Tasa de éxito en la creación de passkeys: De aquellos que comienzan la ceremonia (hacen clic en "Crear Passkey"), ¿qué porcentaje finaliza sin errores ni abandonos?

• Tasa de uso de passkeys: ¿Con qué frecuencia los usuarios recurrentes eligen realmente las passkeys para la autenticación o el pago diario, en lugar de contraseñas u OTP?

• Tasa de éxito en el inicio de sesión con passkeys: El porcentaje de intentos de passkey que tienen éxito sin recurrir a métodos alternativos o frustrar al usuario.

• Uso de métodos alternativos: ¿Cuántos usuarios inician un flujo de passkey pero vuelven a métodos más antiguos? Esto señala posibles barreras técnicas o de UX.

Corbado etiqueta automáticamente cada evento con el sistema operativo (Windows, macOS, iOS, Android) y el navegador (Chrome, Safari, Edge, Firefox, etc.).

Con esta segmentación, puedes ver si, por ejemplo, Safari en iOS tiene una tasa de abandono de passkeys más alta, o si Chrome en Windows produce una mejor adopción de passkeys.

Estos datos también te ayudan a ajustar las estrategias de fallback, especialmente si las restricciones de origen cruzado de Apple afectan a tu base de usuarios más de lo previsto.

Proporcionamos vistas de panel para cada etapa del embudo de passkeys: indicaciones de creación, registros exitosos, inicios de sesión de usuarios, uso de métodos alternativos.

Los gráficos en tiempo real permiten a los gerentes de producto detectar tendencias rápidamente (p. ej., si una nueva actualización del sistema operativo rompe los flujos de passkeys).

Las alertas automáticas pueden notificar a tu equipo si las tasas de éxito de las passkeys caen significativamente, para que puedas investigar rápidamente un nuevo error del navegador o un problema de configuración.

Cada flujo de passkey (desde la creación hasta el inicio de sesión) se registra con eventos paso a paso con marca de tiempo, lo que permite un análisis forense profundo.

Puedes buscar rápidamente por hash de usuario, ID de sesión o firma del dispositivo para ver exactamente dónde tuvo dificultades un usuario o qué código de error se devolvió.

Esto es fundamental para implementaciones a gran escala, donde no puedes depender de tickets de soporte anecdóticos, sino que necesitas datos precisos para resolver los problemas de los usuarios.

La plataforma de análisis de Corbado admite pruebas A/B integradas en el embudo de passkeys: prueba diferentes textos de CTA, indicaciones de creación, mensajes de fallback o la ubicación de los botones "Crear Passkey" en el flujo de pago.

Métricas como la "Tasa de aceptación de passkeys" o la "Tasa de fallback" se pueden medir una al lado de la otra para cada variante.

Este enfoque garantiza una mejora continua, reflejando el éxito de los principales adoptantes de passkeys que refinan los flujos con el tiempo.

Aunque los paneles de Corbado proporcionan una interfaz visual lista para usar, también puedes exportar o enviar mediante webhook puntos de datos clave (p. ej., éxito en la creación de passkeys, inicios de sesión) a tus herramientas de BI o SIEM.

Esto permite a los proveedores de pago incorporar los KPI de las passkeys en suites de análisis más amplias, rastreando el ROI de las passkeys junto con otras métricas de seguridad, marketing u operativas.

Resumen

Al medir y visualizar cada paso del recorrido de la passkey —a través de combinaciones de SO/navegador, flujos de creación y escenarios de inicio de sesión— Corbado te brinda la información necesaria para refinar continuamente tu oferta de passkeys. Estos análisis no solo confirman que las passkeys están habilitadas; demuestran si los usuarios realmente las están adoptando a escala, identifican puntos de fricción y te ayudan a impulsar las tasas de uso hasta el punto en que las passkeys reemplacen genuinamente a las contraseñas para pagos seguros y sin fricciones.

Para los proveedores de pago, simplemente crear una passkey por usuario a menudo no es suficiente para ofrecer una experiencia de autenticación verdaderamente fluida. En realidad, los usuarios cambian de dispositivo con frecuencia: desde portátiles en el trabajo hasta smartphones personales, tabletas e incluso ordenadores familiares compartidos. Asegurar que cada dispositivo tenga una passkey válida para la misma cuenta es fundamental para reducir la fricción y evitar recurrir a las contraseñas. Apple Pay logra esto al poder aprovechar la cuenta de iCloud en todos los dispositivos conectados a iCloud.

A continuación se explica cómo Corbado ayuda a mantener la cobertura multidispositivo a lo largo del ciclo de vida del usuario.

• Pantallas de creación de la passkey principal: Corbado se centra inicialmente en conseguir que cada usuario registre al menos una passkey, la passkey "principal", dondequiera que se encuentren por primera vez con tu flujo de pago (p. ej., en el checkout, en el portal en línea de un banco o en la configuración de tu cuenta).

• Pantallas de creación de passkeys secundarias: Después de que un usuario haya registrado con éxito su primera passkey, los inicios de sesión posteriores en otros dispositivos pueden solicitar automáticamente un breve flujo de "Añadir este dispositivo". Esto asegura que el usuario obtenga rápidamente un acceso sin fricciones con passkey en todos los dispositivos relevantes sin tener que volver a introducir una contraseña o recurrir a métodos alternativos.

Incluso si un usuario tiene una passkey en un dispositivo, puede aparecer sin una passkey local en un segundo dispositivo (debido a instalaciones nuevas del sistema operativo, eliminación de cookies o simplemente por no haber creado nunca una passkey en ese dispositivo).

El enfoque de Corbado a menudo utiliza un paso híbrido: el usuario puede iniciar sesión con una passkey existente en su teléfono o un método alternativo, y luego "reparar" instantáneamente la brecha creando una passkey en el dispositivo actual.

Este proceso de autorreparación ayuda a mantener una alta cobertura y elimina el uso repetido de métodos alternativos en el futuro.

A través de señales entre dispositivos y la "Passkey Intelligence" de Corbado, el sistema puede detectar cuándo un usuario con una passkey existente ha cambiado a un dispositivo no registrado.

Si tu estrategia de UX busca la máxima cobertura, Corbado puede preguntar automáticamente: "¿Te gustaría añadir una passkey en este dispositivo para no tener que recurrir a un método alternativo la próxima vez?"

Los usuarios pueden omitir esto si están en un dispositivo de un solo uso, pero generalmente aprecian la comodidad del inicio de sesión biométrico basado en passkeys una vez que se les explica.

El SDK de Corbado proporciona flujos de pantalla distintos para la "creación de la primera passkey" (es decir, la primera vez que el usuario registra una credencial) y la creación en un "dispositivo secundario".

El mensaje puede diferir: p. ej., "Asegura este nuevo dispositivo con una passkey" vs. "Configura tu primera passkey".

Esto garantiza la claridad para los usuarios finales, que entienden la diferencia entre la inscripción inicial y la ampliación de la cobertura a dispositivos adicionales.

A veces, la creación de la passkey puede fallar a mitad de la ceremonia o el sistema operativo del usuario está desactualizado. En esos escenarios, Corbado registra el intento parcial y sugiere elegantemente posibles soluciones (redirección, fallback manual o flujo QR entre dispositivos).

El usuario siempre puede volver a intentar añadir una passkey en ese dispositivo en el siguiente intento de inicio de sesión, o confiar en una passkey existente de otro dispositivo.

Los análisis de Corbado no solo muestran cuántos usuarios crearon una passkey inicialmente, sino también cuántos han expandido las passkeys a múltiples dispositivos.

Puedes rastrear las tasas de cobertura de dispositivos (p. ej., 1 dispositivo vs. 2 o más) y ver cómo se correlaciona eso con un menor uso de métodos alternativos o un mayor éxito en los pagos.

Esto ayuda a tu equipo a priorizar la educación del usuario, las indicaciones en la aplicación o los flujos de inscripción basados en el banco para aumentar la penetración de passkeys multidispositivo.

Resumen: Por qué es importante la cobertura multidispositivo

Sin una cobertura consistente en todos los dispositivos del usuario, corres el riesgo de que los usuarios se vean obligados a recurrir a medidas de autenticación alternativas cada vez que estén en un dispositivo "sin passkey". Esto rompe la experiencia sin fricciones y mantiene altos los costos operativos (p. ej., tarifas de SMS, sobrecarga de soporte). Al ofrecer pantallas de creación de passkeys secundarias, reparación de fallback híbrida e indicaciones impulsadas por el entorno, Corbado asegura que cada usuario pueda eventualmente mantener passkeys en todos los dispositivos que utiliza, impulsando una mayor adopción general y minimizando esos frustrantes momentos de fallback.

Uno de los mayores conceptos erróneos al construir un SDK de passkeys de terceros es que la parte más difícil es implementar las llamadas de WebAuthn (p. ej., navigator.credentials.create() o navigator.credentials.get()).

En realidad, esta es la parte "fácil": una o dos llamadas a la API para activar la ceremonia básica. La verdadera complejidad, y el determinante real del éxito, radica en asegurar la adopción a gran escala y construir un ecosistema completo alrededor de esas llamadas a la API.

A continuación se presentan los puntos clave, reforzados por la Guía de Comprar vs. Construir Passkeys, que destacan por qué las implementaciones mínimas, centradas solo en la ceremonia, a menudo no logran resultados en el mundo real.

• Implementación de la ceremonia: Crear o autenticar una passkey generalmente implica solo unas pocas líneas de JavaScript para llamar a navigator.credentials.create() o navigator.credentials.get().

• Complejidad real: Asegurar que el flujo de la passkey funcione en muchos navegadores, maneje los fallos con elegancia y ofrezca alternativas para sistemas más antiguos. También necesitarás una gestión de sesiones robusta, registro de errores, análisis, estrategias de cobertura de dispositivos y más.

• Escollos imprevistos: Una vez que vas más allá de una "demostración técnica" de passkeys, descubres casos límite como bloqueos de origen cruzado, restricciones de WebView embebidos y complejidades de sincronización multidispositivo. Estas son las incógnitas desconocidas que descarrilan las construcciones internas ingenuas.

• Ceremonia vs. Adopción: Incluso si tienes una ceremonia de WebAuthn perfecta, una baja adopción por parte de los usuarios (p. ej., una tasa de uso de passkeys <5%) producirá beneficios mínimos de seguridad o UX.

• Enfoque holístico: Un despliegue exitoso de passkeys exige todo, desde indicaciones de usuario convincentes y textos probados con A/B hasta flujos de cobertura multidispositivo, manejo de fallbacks y análisis continuos, mucho más allá de las llamadas básicas de la ceremonia.

• Perspectivas de la Guía de Comprar vs. Construir: La guía enfatiza que impulsar la adopción de passkeys, no solo habilitarlas, determina en última instancia el ROI. Si los usuarios no se inscriben y no usan activamente las passkeys, el proyecto se estanca efectivamente en "MFA 2.0" sin una mejora en la tasa de conversión.

• Manejo incompleto de fallbacks y errores: La falta de una lógica de fallback avanzada o de depuración en tiempo real puede llevar a bloqueos de usuarios y mayores costos de soporte.

• Cobertura multidispositivo fragmentada: Sin un plan para sincronizar dispositivos adicionales o "reparar" las brechas de passkeys, los usuarios vuelven a las contraseñas cada vez que cambian de plataforma.

• Análisis y pruebas A/B limitados: La falta de datos sobre los embudos de creación de passkeys o el uso del entorno significa que no puedes mejorar sistemáticamente la adopción o solucionar rápidamente nuevas peculiaridades de los navegadores.

• UI preconstruida y mejores prácticas: En lugar de solo exponer los puntos finales de la ceremonia, una solución adecuada (como Corbado) incluye pantallas de marca blanca, flujos de fallback, manejo de errores y cobertura multidispositivo.

• Inteligencia adaptativa y registro: Detección automática de la probable presencia de una passkey, guía a los usuarios para crear o arreglar passkeys faltantes y captura de registros de eventos granulares.

• "Incógnitas desconocidas" centradas en la adopción: Muchos detalles, como el fallback basado en correo electrónico o cómo manejar los dispositivos corporativos, no son obvios hasta que los usuarios comienzan a encontrarlos en implementaciones reales.

• Análisis profundo de la estrategia de adopción: La Guía de Comprar vs. Construir Passkeys destaca cómo equilibrar el costo, el tiempo de comercialización y las complejidades ocultas de una solución de passkeys robusta.

• Benchmarks del mundo real: Aprende cómo los despliegues a gran escala de los principales bancos y proveedores de comercio electrónico superaron las incógnitas desconocidas que surgen después de haber codificado la lógica "simple" de la ceremonia.

• Éxito sostenido: Invertir en una plataforma establecida con patrones de adopción probados asegura que no te quedes reinventando la rueda y descubriendo sorpresas costosas en el camino.

En resumen

Simplemente conectar la ceremonia de WebAuthn no es suficiente para lograr una adopción significativa de passkeys. El verdadero éxito depende de orquestar flujos de extremo a extremo, como fallbacks, análisis, expansiones multidispositivo y recorridos de usuario probados con A/B. Al abordar las complejidades matizadas más allá de "solo la ceremonia", puedes transformar tu proyecto de passkeys de una curiosidad técnica a una solución de autenticación genuinamente sin fricciones, ampliamente utilizada y que ahorra costos.

Además de las complejidades en torno a los flujos de origen cruzado, la adopción del usuario y la gestión del ciclo de vida de las passkeys, las consideraciones de alojamiento y despliegue son críticas para cualquier solución de passkeys a gran escala. Los proveedores de pago a menudo se enfrentan a estrictos requisitos de cumplimiento, demandas de residencia de datos y requisitos de resiliencia que pueden variar significativamente entre regiones. A continuación se explica cómo Corbado (o soluciones igualmente robustas) aborda estas preocupaciones:

Para cumplir con la soberanía de datos o los marcos regulatorios (p. ej., GDPR en Europa, PIPEDA en Canadá o NIST/HIPAA en los Estados Unidos), algunos proveedores deben mantener los datos dentro de límites geográficos específicos.

Una arquitectura agnóstica a la región garantiza que el servicio de passkeys se pueda desplegar en cualquier región de AWS deseada, cumpliendo con los mandatos de cumplimiento locales sin sacrificar el rendimiento o la escalabilidad.

Esta flexibilidad es particularmente importante si tu base de usuarios abarca varios países, cada uno con diferentes reglas de manejo de datos.

Para los flujos críticos de autenticación de pagos, el tiempo de inactividad no es una opción. Corbado emplea despliegues multi-AZ, distribuyendo componentes clave en múltiples zonas de disponibilidad.

Esta configuración ayuda a garantizar que si una AZ experimenta una interrupción o un problema de conectividad, tu infraestructura de passkeys en otras zonas permanezca en línea, para que los usuarios puedan seguir autenticándose.

El resultado es un sistema más resiliente que cumple con los estrictos SLA para los servicios financieros y los sitios de comercio electrónico, donde incluso un breve tiempo de inactividad puede llevar a un impacto significativo en los ingresos.

Algunos proveedores de pago prefieren un clúster privado dedicado, ya sea para un mayor aislamiento de datos, comprobaciones de cumplimiento personalizadas o un control más profundo sobre los parches y las actualizaciones.

Una solución flexible puede admitir ambos extremos:

• SaaS / Multi-Tenant: Rápido de implementar, menor costo, bien adaptado para muchos despliegues de tamaño mediano.

• Instancia de nube dedicada: Una cuenta e instancia de base de datos separadas en la región que elijas, para aquellos que necesitan aislamiento o cumplimiento adicional.

Las passkeys deben manejar cargas de trabajo con picos: enormes aumentos de tráfico (p. ej., picos de compras navideñas o ventas de entradas para eventos) pueden sobrecargar los sistemas de capacidad fija.

Un backend de passkeys moderno escala horizontalmente en tiempo real, añadiendo o eliminando instancias de cómputo según los patrones de uso. Este autoescalado garantiza un rendimiento constante sin intervención manual.

Estándares de la industria como PCI-DSS, PSD2 SCA o ISO 27001 a menudo se aplican a los proveedores de pago. Un proveedor de passkeys robusto generalmente se integra con marcos de cumplimiento conocidos de fábrica:

• Cifrado en reposo y en tránsito: Asegura los datos con TLS fuerte y cifrado del lado del servidor o del cliente para las credenciales almacenadas.

• Registros y pistas de auditoría: Registros detallados para cada operación de passkey, adecuados para reguladores o investigaciones de incidentes.

• Parches de seguridad regulares: Parches automáticos del sistema operativo y de los contenedores para mantener a raya las vulnerabilidades, especialmente relevante en un entorno multi-AZ fluido.

La verdadera resiliencia se extiende más allá de una sola región. Algunos proveedores exigen la replicación entre regiones para mantener la continuidad del negocio durante desastres a gran escala.

La georredundancia puede replicar los datos de las passkeys en una región o continente diferente, asegurando que el tiempo de inactividad de toda una región no detenga los flujos de autenticación.

Resumen: Multi-AZ e independiente de la región

Elegir una solución de passkeys que escale fácilmente, se adapte geográficamente y resista tanto las interrupciones locales como los desastres a gran escala es esencial para los proveedores de pago modernos, especialmente aquellos que operan en varios países o bajo un estricto cumplimiento. Al admitir despliegues multi-AZ y configuraciones agnósticas a la región, Corbado (o soluciones comparables) garantiza que los servicios de passkeys para pagos permanezcan disponibles y cumplan con la normativa, sin importar dónde residan tus usuarios o datos.

Las passkeys representan, de hecho, la próxima generación de autenticación segura y amigable para el usuario. Sin embargo, los proveedores de pago se enfrentan a desafíos únicos que el diseño tradicional de WebAuthn no aborda directamente. Estas limitaciones son más pronunciadas en:

1. La negativa de Safari a permitir la creación de passkeys de origen cruzado (particularmente en iframes), forzando un enfoque basado en redirección o la dependencia de passkeys creadas previamente.

2. La falta de soporte de Apple para la Confirmación de Pago Segura (SPC), lo que impide un flujo de pago estandarizado y sin fricciones entre navegadores y plataformas.

No obstante, las passkeys siguen siendo esenciales para los proveedores de pago que buscan ofrecer una experiencia de pago similar a la de Apple Pay: optimizada, segura y deliciosamente simple para los usuarios finales. A continuación se explica cómo se pueden abordar estos desafíos y cómo ayuda Corbado.

1. ¿Cuáles son las limitaciones actuales del uso de passkeys en contextos de terceros para los proveedores de pago?

• Restricciones de origen cruzado: Safari (y algunos navegadores más antiguos) bloquean navigator.credentials.create() cuando se integra a través de un iframe. Esto significa que no puedes crear nuevas passkeys de forma fluida en un flujo integrado en el comercio en esos navegadores.

• Falta de soporte para SPC: La negativa de Apple a adoptar la SPC limita la capacidad de estandarizar las confirmaciones de pago de origen cruzado, obligando a los proveedores a mantener enfoques separados para Safari frente a Chrome/Edge.

• Restricciones de WebView y aplicaciones nativas: Los WebViews embebidos a menudo rompen los flujos de passkeys, requiriendo sesiones de navegador del sistema u otros enfoques especializados para gestionar la alineación del origen del dominio.

• Cobertura de dispositivos fragmentada: Incluso si el usuario crea una passkey en un dispositivo o navegador, puede que no tenga cobertura en otros, lo que provoca el uso de métodos alternativos.

2. ¿Cómo pueden los proveedores de pago superar estas limitaciones para implementar con éxito integraciones de passkeys de terceros?

• Aprovechar una estrategia híbrida (Iframe + Redirección):

  • Iframe para navegadores que admiten completamente las passkeys de origen cruzado, ofreciendo una interfaz de usuario integrada y fluida.

  • Redirección como alternativa para Safari o configuraciones incompatibles, asegurando que la creación robusta de passkeys sea siempre posible.

• WebView del sistema o redirección al navegador en aplicaciones nativas:

  • En lugar de integrar iframes en las aplicaciones de los comercios, cambiar a ASWebAuthenticationSession (iOS) o Chrome Custom Tabs (Android) para preservar la continuidad del dominio.

  • Kit de herramientas centrado en la adopción: Proporcionar indicaciones de creación de passkeys convincentes, flujos de cobertura multidispositivo y pasos de "reparación" de fallback para mantener un alto uso.

  • Analítica avanzada y pruebas A/B:

    • Medir continuamente las tasas de éxito/fallback de las passkeys, la cobertura del entorno y los comentarios de los usuarios para refinar tus flujos.

    • Usar la inteligencia de passkeys para presentar automáticamente las passkeys solo cuando el éxito es probable.

A lo largo de esta guía, hemos destacado que simplemente conectar navigator.credentials.create() no es suficiente. El verdadero éxito depende de una alta adopción de passkeys, una experiencia de usuario consistente y una cobertura multidispositivo resiliente. Ahí es donde Corbado sobresale:

• Soporte unificado para Iframe y Redirección: El SDK de Corbado detecta automáticamente si un flujo de passkey integrado es factible (p. ej., en Chrome o Edge) o si es necesaria una redirección (p. ej., Safari). Esto maximiza la compatibilidad sin requerir que los comercios mantengan múltiples rutas de código.

  • Experiencia de pago con un solo toque: Con Passkey Intelligence, Corbado detecta instantáneamente si es probable que el entorno de un usuario tenga una passkey válida, activando un flujo de "pagar con passkey" sin fricciones. Este enfoque es paralelo al checkout de un solo toque de Apple Pay, impulsando el uso diario de passkeys en lugar de relegarlo a un paso de MFA raramente utilizado.

  • Cobertura multidispositivo robusta: Corbado proporciona flujos especiales para la creación inicial de passkeys frente a las expansiones de passkeys secundarias, para que cada usuario pueda añadir rápidamente cobertura para nuevos dispositivos después de iniciar sesión mediante fallback o QR entre dispositivos.

  • Enfoque de adopción Full-Stack: A través de análisis integrados, pruebas A/B y manejo de errores, Corbado ayuda a los proveedores a identificar puntos de fricción y a optimizar sistemáticamente la aceptación de passkeys. Esto se extiende desde las primeras indicaciones de passkeys de los bancos hasta las experiencias de checkout de los comercios.

  • Alojamiento flexible y compatible: Los despliegues multi-AZ y agnósticos a la región de Corbado se alinean con el estricto cumplimiento de la industria de pagos (PCI DSS, PSD2 SCA, etc.), garantizando el tiempo de actividad y la adhesión a las normas de residencia de datos en todo el mundo.

Aunque las políticas restrictivas de Apple crean una fricción inevitable, los proveedores de pago aún pueden implementar con éxito passkeys de terceros mediante:

1. La combinación de un enfoque integrado (iframe) con una alternativa de redirección.

2. La adopción de webviews de sistema especializados o flujos de navegador externos para aplicaciones nativas.

3. El enfoque en estrategias de adopción robustas: cobertura multidispositivo, "reparación" de fallback, análisis avanzados y pruebas A/B.

Corbado reúne todos estos elementos, ofreciendo una plataforma de passkeys empresarial que cubre la inscripción de passkeys, el uso con un solo toque, la optimización impulsada por análisis y el alojamiento a escala global. El resultado: una experiencia verdaderamente sin fricciones como la de Apple Pay para tu propio servicio de pago, que ofrece tanto una seguridad reforzada como un recorrido de usuario superior.