---
url: 'https://www.corbado.com/es/blog/passkeys-proveedores-pago-sdk-terceros'
title: 'Passkeys para proveedores de pago: Cómo crear un SDK de terceros'
description: 'Descubre cómo crear passkeys de origen cruzado como proveedor de pagos. Comparamos iframes vs. redirecciones, cómo ofrecer una UX al nivel de Apple Pay y usar analíticas para una mayor adopción.'
lang: 'es'
author: 'Vincent Delitz'
date: '2025-07-15T13:24:43.431Z'
lastModified: '2026-04-14T06:02:43.713Z'
keywords: 'psp, proveedor de servicios de pago, passkeys para proveedores de pago'
category: 'Passkeys Strategy'
---

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

## 1. Introducción: ¿Por qué los proveedores de pago necesitan passkeys?

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](https://www.corbado.com/es/blog/como-eliminar-contrasenas-por-completo) y la comodidad en comparación
con la [autenticación](https://www.corbado.com/es/glossary/jwks) multifactor (MFA) tradicional. Recientemente,
[PayPal adoptó las passkeys como su principal solución de MFA autónoma](https://www.forbes.com/sites/daveywinder/2025/03/01/paypal-security-2fa-codes-to-be-replaced-by-single-step-login/),
marcando una clara tendencia para los proveedores de [pago](https://www.corbado.com/passkeys-for-payment) 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](https://www.corbado.com/passkeys-for-payment), por el contrario, suelen operar en contextos
de terceros, donde sus servicios (como formularios de [pago](https://www.corbado.com/passkeys-for-payment) 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](https://www.corbado.com/es/blog/vinculacion-dinamica-passkeys-spc) (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](https://www.corbado.com/es/blog/como-lograr-alta-adopcion-passkeys-flujos-creacion) de
[origen cruzado](https://www.corbado.com/es/blog/passkeys-e-iframes-webauthn) en Safari y la falta de soporte del
estándar de [Confirmación de Pago Segura](https://www.corbado.com/es/blog/vinculacion-dinamica-passkeys-spc)
representan un obstáculo significativo, complicando la adopción fluida de la
[autenticación](https://www.corbado.com/es/glossary/jwks) 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.

## 2. Beneficios de las passkeys en todo el ecosistema de pagos

Las passkeys aportan un inicio de sesión biométrico y resistente al
[phishing](https://www.corbado.com/glossary/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](https://www.corbado.com/es/glossary/jwks) con passkeys.

### 2.1 Passkeys para comercios

**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](https://www.corbado.com/blog/how-to-use-apple-pay) y reducir la dependencia de contraseñas u OTP, lo
que genera mayor confianza y ventas.

### 2.2 Passkeys para titulares de tarjetas / clientes

**Impacto:** [Autenticación sin contraseña](https://www.corbado.com/es/faq/passkeys-sin-biometria) 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](https://www.corbado.com/glossary/phishing). Una adopción amplia podría
convertir las passkeys en el nuevo estándar para la
[verificación](https://www.corbado.com/es/blog/verificacion-de-identidad-digital) de titulares de tarjetas.

### 2.3 Passkeys para emisores (banco emisor)

**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.

### 2.4 Passkeys para adquirentes (banco adquirente)

**Impacto:** Mayor aceptación de transacciones y menos autenticaciones fallidas.\
**Oportunidad:** Soportar passkeys a través de
[PSP](https://www.corbado.com/blog/payment-provider-passkeys-third-party-sdk) puede mejorar los resultados de los
comercios y reducir la fricción durante el checkout o los flujos de facturación
recurrente.

### 2.5 Passkeys para proveedores de servicios de pago (PSP) / pasarelas de pago

**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](https://www.corbado.com/blog/payment-provider-passkeys-third-party-sdk) pueden proporcionar una
autenticación de última generación manteniendo la compatibilidad entre navegadores y
aplicaciones nativas.

### 2.6 Passkeys para procesadores de pago

**Impacto:** Aprobaciones de transacciones optimizadas con menos
[pagos](https://www.corbado.com/passkeys-for-payment) rechazados.\
**Oportunidad:** Las
[empresas de procesamiento de pagos](https://dashdevs.com/blog/best-payment-processing-companies/)
pueden integrar la [verificación](https://www.corbado.com/es/blog/verificacion-de-identidad-digital) con passkeys
en sus API para reducir el riesgo y admitir alternativas de [SCA](https://www.corbado.com/es/blog/psd2-passkeys)
biométricas para flujos que cumplan con la normativa.

### 2.7 Passkeys para proveedores de tokenización y wallets

**Impacto:** Almacenamiento seguro de credenciales y reautenticación sin fricciones.\
**Oportunidad:** Los proveedores de wallets como [Apple Pay](https://www.corbado.com/blog/how-to-use-apple-pay) y
[Google Pay](https://www.corbado.com/blog/how-to-use-google-pay) ya utilizan flujos similares a las passkeys.

## 3. ¿Qué proveedores de pago han implementado 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:

### 3.1 Passkeys de Mastercard

![using mastercard payment passkey](https://www.corbado.com/website-assets/using_mastercard_payment_passkey_7f8121856f.png)

[Mastercard](https://www.corbado.com/blog/mastercard-passkeys) ha lanzado oficialmente su **Payment Passkey
Service**, que proporciona una experiencia de
[autenticación sin contraseña](https://www.corbado.com/es/faq/passkeys-sin-biometria) integrada en los flujos
[EMV 3DS](https://www.corbado.com/es/blog/servidor-control-acceso-emv-3ds-passkeys-fido-spc). Los usuarios pueden
crear y usar passkeys vinculadas al dominio de autenticación de
[Mastercard](https://www.corbado.com/blog/mastercard-passkeys) (p. ej.,
verify.[mastercard](https://www.corbado.com/blog/mastercard-passkeys).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](https://www.corbado.com/glossary/phishing) y
[compatible con PSD2](https://www.corbado.com/es/blog/psd2-passkeys) en la industria de pagos.\
Leer más: [Passkeys de Mastercard](https://www.corbado.com/es/blog/mastercard-passkeys)

### 3.2 Passkeys de Visa

[Visa](https://www.corbado.com/blog/visa-passkeys) 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](https://www.corbado.com/blog/visa-passkeys) busca modernizar la experiencia de pago en línea con una mayor
[seguridad](https://www.corbado.com/es/blog/como-eliminar-contrasenas-por-completo) y comodidad para el usuario.\
Leer más: [Passkeys de VISA](https://www.corbado.com/es/blog/passkeys-de-visa)

### 3.3 Passkeys de American Express

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](https://www.corbado.com/glossary/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.

### 3.4 Passkeys de PayPal

![paypal login passkeys](https://www.corbado.com/website-assets/paypal_login_passkeys_3c664c9248.png)

[PayPal](https://www.corbado.com/blog/paypal-passkeys) 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](https://www.corbado.com/blog/paypal-passkeys) 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](https://www.corbado.com/es/blog/passkeys-paypal)

### 3.5 Passkeys de Klarna

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](https://www.corbado.com/blog/how-to-enable-passkeys-ios) restringen la
[creación de passkeys](https://www.corbado.com/es/blog/como-lograr-alta-adopcion-passkeys-flujos-creacion) en
iframes / WebViews, esta podría ser una de las razones por las que Klarna no ha
implementado las passkeys hasta ahora.

### 3.6 Passkeys de Block (Square)

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.

### 3.7 Passkeys de Stripe

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](https://www.corbado.com/passkeys-for-payment), sigan esa misma arquitectura de redirección.

### 3.8 Passkeys de BILL

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

### 3.9 Passkeys de Remitly

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.

### 3.10 Passkeys de Payoneer

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.

### 3.11 Passkeys de Adyen

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.

### 3.12 Passkeys de Worldpay

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.

### 3.13 Passkeys de Checkout.com

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](https://www.corbado.com/es/blog/caso-negocio-adopcion-passkeys).

### 3.14 Passkeys de AliPay

AliPay no ha lanzado oficialmente las passkeys. Dada la creciente tendencia de la
[autenticación biométrica](https://www.corbado.com/es/blog/mastercard-passkeys) en los ecosistemas de pago
chinos, es posible que se produzca un lanzamiento en el futuro, pero ninguna documentación
actual lo confirma.

### 3.15 Passkeys de Mollie

Mollie no ha hecho ninguna declaración pública ni actualización de producto sobre la
[adopción de passkeys](https://www.corbado.com/es/blog/caso-negocio-adopcion-passkeys) en sus sistemas de
autenticación o checkout.

### 3.16 Passkeys de Amazon Pay

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.

### 3.17 Passkeys de Braintree

Braintree, una empresa de [PayPal](https://www.corbado.com/blog/paypal-passkeys), 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.

### 3.18 Passkeys de Link

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](https://www.corbado.com/passkeys-for-payment) 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.

![link passkeys login](https://www.corbado.com/website-assets/link_passkeys_login_88b6b731dd.png)

### 3.19 Passkeys de Afterpay

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](https://www.corbado.com/es/blog/caso-negocio-adopcion-passkeys) debido a las restricciones
de los [WebView](https://www.corbado.com/blog/native-app-passkeys) embebidos.

## 4. ¿Por qué los esfuerzos de la industria para estandarizar las passkeys están bloqueados por Apple?

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](https://www.corbado.com/es/blog/vinculacion-dinamica-passkeys-spc) (SPC)

- [Creación de passkeys](https://www.corbado.com/es/blog/como-lograr-alta-adopcion-passkeys-flujos-creacion) de
  terceros en iframes

### 4.1 ¿Dónde bloquea Apple la Confirmación de Pago Segura (SPC)?

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](https://www.corbado.com/blog/dynamic-linking-passkeys-spc) estandariza cómo los proveedores de pago
autentican a los usuarios en múltiples sitios de comercios sin comprometer la
[seguridad](https://www.corbado.com/es/blog/como-eliminar-contrasenas-por-completo) o la experiencia del usuario.
Sin embargo, Apple ha negado sistemáticamente el soporte para
[SPC](https://www.corbado.com/blog/dynamic-linking-passkeys-spc) en Safari, probablemente como una medida
estratégica para garantizar que [Apple Pay](https://www.corbado.com/blog/how-to-use-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](https://www.corbado.com/blog/dynamic-linking-passkeys-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.

### 4.2 Cómo las restricciones de iframe de Safari afectan la creación de passkeys de terceros

Otra barrera crítica implica la restricción deliberada de Apple a la creación de passkeys
dentro de iframes de [origen cruzado](https://www.corbado.com/es/blog/passkeys-e-iframes-webauthn). Mientras que
Safari permite el uso de passkeys existentes para la autenticación
(`navigator.credentials.get()`) en un [iframe](https://www.corbado.com/blog/iframe-passkeys-webauthn) de
terceros, bloquea explícitamente el
[registro de passkeys](https://www.corbado.com/es/blog/como-lograr-alta-adopcion-passkeys-flujos-creacion)
(`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.

## 5. Cómo construir un SDK de pago con passkeys de terceros para la web

### 5.1 Estrategia A: Integrar un iframe de origen cruzado (Ventajas y desventajas)

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](https://www.corbado.com/blog/iframe-passkeys-webauthn) integrado y se autentica con una
passkey vinculada al ID de [Relying Party](https://www.corbado.com/glossary/relying-party) `pay.provider.com`.

Puntos clave:

- **Origen cruzado**: Debido a que el [iframe](https://www.corbado.com/blog/iframe-passkeys-webauthn) está en un
  dominio diferente, debes configurar políticas de permisos para
  [publickey-credentials-get](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Permissions-Policy/publickey-credentials-get)
  y
  [publickey-credentials-create](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Permissions-Policy/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](https://www.corbado.com/es/blog/passkeys-e-iframes-webauthn). 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"](https://developer.mozilla.org/en-US/docs/Glossary/Transient_activation)
  (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.

![Cross origin iframe](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/embedding_cross_origin_iframe_8b52f6996e.png)

### 5.2 Estrategia B: Enfoque basado en redirección para una mayor compatibilidad

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](https://passkeys.eu/device-support)
  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.

![Redirect approach for broader compatibility](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/redirect_approach_for_broader_compatibility_701166520a.png)

## 6. SDK de pago con passkeys de terceros para aplicaciones nativas

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](https://www.corbado.com/blog/how-to-enable-passkeys-ios) como en
[Android](https://www.corbado.com/blog/how-to-enable-passkeys-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.

### 6.1 Por qué las passkeys de proveedores de passkeys no se pueden usar directamente en las aplicaciones nativas de los comercios

Las passkeys están inherentemente vinculadas a un dominio específico (el "ID de
[Relying Party](https://www.corbado.com/glossary/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](https://www.corbado.com/blog/how-to-enable-passkeys-ios) como en
[Android](https://www.corbado.com/blog/how-to-enable-passkeys-android). Como resultado, la
[aplicación nativa](https://www.corbado.com/es/blog/passkeys-aplicaciones-nativas-webview) 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](https://www.corbado.com/es/blog/passkeys-aplicaciones-nativas-webview) 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](https://www.corbado.com/blog/native-app-passkeys) basado en el sistema
(como [ASWebAuthenticationSession](https://www.corbado.com/blog/native-app-passkeys) en iOS o Chrome Custom Tabs
en [Android](https://www.corbado.com/blog/how-to-enable-passkeys-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.

### 6.2 Desafíos con los WebViews embebidos: Por qué rompen las passkeys

Los WebViews embebidos (p. ej., [WKWebView](https://www.corbado.com/blog/native-app-passkeys) en iOS o el
[WebView](https://www.corbado.com/blog/native-app-passkeys) 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.

### 6.3 Uso de WebView del sistema o redirección para passkeys de terceros

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:

#### 6.3.1 Usar WebView del sistema

**iOS (ASWebAuthenticationSession):**

Apple proporciona [ASWebAuthenticationSession](https://www.corbado.com/blog/native-app-passkeys) 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](https://www.corbado.com/blog/native-app-passkeys), que comparte su estado con las
cookies de Safari, permitiendo que el diálogo de la passkey se inicie inmediatamente.

![ios asweb passkeys e-commerce](https://www.corbado.com/website-assets/ios_asweb_passkeys_e_commerce_34ecd03796.jpeg)

**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](https://www.corbado.com/es/blog/passkeys-aplicaciones-nativas-webview) de BOSS en Android
aquí:

![android asweb passkeys paypal](https://www.corbado.com/website-assets/android_asweb_passkeys_paypal_5eb366dce2.jpeg)

#### 6.3.2 Redirigir al navegador predeterminado

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.

![Redirect to default browser](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/redirect_to_default_browser_48b9e771a3.png)

## 7. Iframe vs. Redirección: ¿Qué enfoque para el checkout con passkeys?

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.

### 7.1 Tabla comparativa detallada de los enfoques integrado y de redirección

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](https://www.corbado.com/passkeys-for-critical-infrastructure) técnica.

| **Aspecto**                                  | **Enfoque integrado (Iframe)**                                                                                                                                                                                                                                                                                               | **Enfoque de redirección**                                                                                                                                                                                                                                                                                                                                 |
| -------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Experiencia de usuario**                   | ✅ Muy fluida; los usuarios permanecen en el sitio del comercio durante todo el proceso de pago, lo que mejora la consistencia de la marca del comercio.                                                                                                                                                                     | ⚠️ Potencialmente disruptiva; los usuarios abandonan el sitio del comercio o se encuentran con ventanas emergentes/nuevas pestañas, lo que introduce fricción.                                                                                                                                                                                             |
| **Compatibilidad con navegadores**           | ⚠️ Limitada debido al bloqueo de Safari de Apple a la creación de passkeys de origen cruzado y a las restricciones de navegadores más antiguos; soporte parcial, principalmente para flujos de autenticación.                                                                                                                | ✅ Robusta; ampliamente compatible con todos los principales navegadores, ya que opera en un contexto de dominio de primera parte.                                                                                                                                                                                                                         |
| **Soporte en apps nativas**                  | ⚠️ Soporte deficiente; se rompe en webviews embebidos debido a estrictas políticas de origen y restricciones de seguridad.                                                                                                                                                                                                   | ✅ Fuerte soporte; se maneja fácilmente a través de webviews del sistema o navegadores externos, alineándose con las directrices de la plataforma (iOS y Android).                                                                                                                                                                                         |
| **Atractivo para el comercio**               | ✅ Mayor; los comercios prefieren experiencias totalmente integradas, ya que retienen el control sobre la UX y la marca.                                                                                                                                                                                                     | ⚠️ Medio; la redirección puede causar fricción, afectando potencialmente las tasas de conversión del comercio y la satisfacción del cliente, a menos que se maneje con elegancia.                                                                                                                                                                          |
| **Complejidad de la implementación técnica** | ⚠️ Mayor complejidad; requiere una configuración precisa de las Políticas de Permisos y el manejo de diversas peculiaridades de los navegadores con límites en las aplicaciones nativas.                                                                                                                                     | ✅ Menor complejidad; sencillo de implementar debido a la simplicidad de primera parte, lo que reduce los posibles escollos de integración.                                                                                                                                                                                                                |
| **Compatibilidad con passkeys**              | ⚠️ Parcial; la autenticación es ampliamente compatible, pero la creación de passkeys es notablemente problemática debido a las limitaciones de origen cruzado.                                                                                                                                                               | ✅ Completa; soporte total para el registro y la autenticación de passkeys sin restricciones de origen cruzado.                                                                                                                                                                                                                                            |
| **Mantenimiento y soporte**                  | ⚠️ Mayor sobrecarga debido a las frecuentes actualizaciones de los navegadores y los desafíos de compatibilidad.                                                                                                                                                                                                             | ✅ Menor sobrecarga; mantenimiento más simple, se requieren menos actualizaciones de compatibilidad de origen cruzado.                                                                                                                                                                                                                                     |
| **Ejemplo de buena práctica**                | Klarna: Klarna siempre se ha centrado extremadamente en las experiencias de usuario integradas y ha desaconsejado el uso de WebViews del sistema. Por esta razón, Klarna está teniendo dificultades para ofrecer una experiencia completa de passkeys de terceros a sus clientes hasta el momento de escribir este artículo. | PayPal: PayPal siempre ha llevado a los usuarios a su sitio web, imponiendo un enfoque basado en la redirección debido a su poder de mercado y su larga historia. Por lo tanto, la integración de passkeys en los flujos de pago ha sido sencilla y rápida de lograr, incluso en contextos de terceros, ya que los WebViews del sistema ya estaban en uso. |

### 7.2 Resumen: Elegir el mejor flujo para tu SDK de pago

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.

## 8. Mejores prácticas y recomendaciones para SDK de passkeys de origen cruzado

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.

### 8.1 Cómo configurar un enfoque de SDK para flujos de passkeys

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](https://www.corbado.com/faq/enable-passkeys-iframe) 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.

### 8.2 Detección de las capacidades del navegador (Safari vs. Chrome vs. Edge vs. Firefox)

Detectar las capacidades del navegador con precisión sigue siendo un desafío debido a la
reducida granularidad del
[User-Agent](https://www.corbado.com/blog/client-hints-user-agent-chrome-safari-firefox) y al soporte
inconsistente de los [Client Hints](https://www.corbado.com/blog/client-hints-user-agent-chrome-safari-firefox)
en las diferentes plataformas.

#### 8.2.1 Complejidad del análisis del User-Agent

El análisis tradicional es cada vez menos fiable a medida que los navegadores reducen el
detalle en las cadenas de
[User-Agent](https://www.corbado.com/blog/client-hints-user-agent-chrome-safari-firefox) para proteger la
privacidad del usuario. Diferenciar detalles esenciales, como Windows 10 vs.
[Windows 11](https://www.corbado.com/blog/passkeys-windows-11), versiones precisas de macOS o arquitecturas de
CPU, es ahora difícil o imposible usando solo el
[User-Agent](https://www.corbado.com/blog/client-hints-user-agent-chrome-safari-firefox).

#### 8.2.2 Soporte inconsistente de Client Hints

Mientras que los [Client Hints](https://www.corbado.com/blog/client-hints-user-agent-chrome-safari-firefox)
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](https://www.corbado.com/blog/client-hints-user-agent-chrome-safari-firefox), lo que
restringe severamente la detección precisa de características en los dispositivos de
Apple.

#### 8.2.3 Restricciones en aplicaciones integradas y nativas:

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.

### 8.3 Manejo cuidadoso de las aplicaciones nativas: WebView embebido vs. WebView del sistema

Las aplicaciones nativas de los comercios a menudo integran contenido web en
[WKWebView](https://www.corbado.com/blog/native-app-passkeys) (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.

### 8.4 Garantizar la seguridad y el cumplimiento (PCI)

Como proveedor de pagos, una seguridad sólida y el cumplimiento normativo (PCI,
[PSD2](https://www.corbado.com/blog/psd2-passkeys) [SCA](https://www.corbado.com/es/blog/psd2-passkeys), etc.) son clave:

- **Encabezados y seguridad del contenido**: Implementa encabezados
  [Permissions-Policy](https://www.corbado.com/faq/enable-passkeys-iframe) 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.

### 8.5 Pruebas y monitoreo continuos de las passkeys

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](https://www.corbado.com/glossary/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.

### 8.6 KPI esenciales de las passkeys: Cómo rastrear la creación y el inicio de sesión

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.

#### 8.6.1 Tasa de aceptación de passkeys

- **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%.

#### 8.6.2 Tasa de éxito en la creación de passkeys

- **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.

#### 8.6.3 Tasa de uso de passkeys

- **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.

#### 8.6.4 Tasa de éxito en el inicio de sesión con 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".

#### 8.6.5 Uso de métodos alternativos (fallback)

- **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%.

#### 8.6.6 Métricas de conversión y fraude

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](https://www.corbado.com/glossary/3d-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.

## 9. Cómo Corbado ayuda a los proveedores de pago a alcanzar el éxito con las passkeys

### 9.1 Creación fluida de passkeys: Entornos de banco, plataforma y comercio

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:

#### 9.1.1 Pantallas de creación y componentes de UI uniformes

Independientemente de dónde se le pida a un usuario que cree una passkey —ya sea en el
entorno de [banca](https://www.corbado.com/passkeys-for-banking) 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](https://www.corbado.com/blog/vicroads-passkeys):

![Corbado optimized ux passkeys](https://www.corbado.com/website-assets/Corbado_optimized_ux_passkeys_e5deec9ed9.png)

#### 9.1.2 Seguimiento y analítica centralizados

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.

#### 9.1.3 KPI y pruebas A/B

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.

#### 9.1.4 Contexto de creación flexible: Banco, proveedor de pagos o comercio

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](https://www.corbado.com/passkeys-for-banking).

- **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.

#### 9.1.5 Metadatos consistentes y vinculación de identificadores

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".

#### 9.1.6 UI adaptable y manejo de errores

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.

#### 9.1.7 La profunda experiencia de Corbado en flujos de creación de passkeys

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.

### 9.2 Maximiza el uso de passkeys para un checkout similar a 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.

![apple pay passkeys checkout](https://www.corbado.com/website-assets/apple_pay_passkeys_checkout_f63fb27017.jpeg)

En Corbado, hemos desarrollado un mecanismo de
"[Passkey Intelligence](https://docs.corbado.com/corbado-connect/features/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](https://docs.corbado.com/corbado-connect/features/one-tap-login). A
continuación se presentan los elementos centrales que lo hacen posible.

#### 9.2.1 Flujo de un solo toque: Sin necesidad de reingresar credenciales

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.

![A screenshot of a login page AI-generated content may be incorrect.](bc386dced8be285ec3788060ed5cdb7b.png)

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.

#### 9.2.2 Passkey Intelligence: Detección y puntuación del entorno

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.

#### 9.2.3 Sin almacenamiento de PII, pero consciente del contexto

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.

#### 9.2.4 Lógica de fallback y recuperación automática

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](https://docs.corbado.com/corbado-connect/features/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.

#### 9.2.5 Seguimiento avanzado e información de cobertura

![process events trigger overview](https://www.corbado.com/website-assets/process_events_trigger_overview_e101d943f1.png)

Cada vez que Corbado elige iniciar u omitir una indicación de passkey de
[un solo toque](https://docs.corbado.com/corbado-connect/features/one-tap-login), 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.

#### 9.2.6 Experiencia unificada de un solo toque en todos los casos de uso

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](https://docs.corbado.com/corbado-connect/features/one-tap-login) 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](https://docs.corbado.com/corbado-connect/features/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.

### 9.3 Analítica enriquecida para KPI de creación e inicio de sesión con passkeys

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.

#### 9.3.1 Embudo unificado de passkeys: Creación → Uso

![passkeys funnel analysis](https://www.corbado.com/website-assets/passkeys_funnel_analysis_436af30b87.png)

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.

#### 9.3.2 KPI principales de la Guía de Comprar vs. Construir Passkeys

Basándonos en nuestra amplia experiencia ayudando a las empresas a
[implementar passkeys](https://www.corbado.com/es/blog/tutorial-passkeys-como-implementar-en-aplicaciones-web),
nos centramos en métricas que impactan directamente en el ROI y la satisfacción del
usuario:

![core kpis passkey guide](https://www.corbado.com/website-assets/core_kpis_passkey_guide_e37543f9f2.png)

- **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.

#### 9.3.3 Segmentación granular por sistema operativo y navegador

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.

#### 9.3.4 Informes dinámicos y paneles en tiempo real

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.

#### 9.3.5 Depuración y registros de procesos

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.

#### 9.3.6 Optimización del embudo con pruebas A/B

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.

#### 9.3.7 Acceso flexible a datos e integración

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.

### 9.4 Sincronización multidispositivo e "inteligencia" para una alta adopción

Para los proveedores de pago, simplemente
[crear una passkey](https://www.corbado.com/es/blog/como-lograr-alta-adopcion-passkeys-flujos-creacion) 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.

#### 9.4.1 Creación de la primera passkey vs. dispositivos adicionales

- **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.

#### 9.4.2 Autenticación híbrida para la "reparación" de dispositivos

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.

#### 9.4.3 Detección y guía a los usuarios para añadir dispositivos faltantes

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?"

![ux strategy passkeys corbado](https://www.corbado.com/website-assets/ux_strategy_passkeys_corbado_9884e5167c.png)

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.

#### 9.4.4 Flujos de UI adaptables

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.

#### 9.4.5 Manejo de desajustes y errores

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.

#### 9.4.6 Métricas de cobertura continuas

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.

### 9.5 Tiempo de comercialización acelerado: Por qué las soluciones holísticas importan

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.

#### 9.5.1 Incógnitas desconocidas y más allá de la ceremonia

- **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.

#### 9.5.2 La adopción es el verdadero objetivo

- **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 &lt;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.

#### 9.5.3 Riesgos de una implementación mínima "hecha por uno mismo"

- **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.

#### 9.5.4 Soluciones holísticas: Más que solo una API

- **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.

#### 9.5.5 Recomendación de leer la Guía de Comprar vs. Construir

- **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](https://www.corbado.com/passkeys-for-e-commerce)
  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.

### 9.6 Alojamiento y despliegue flexibles (Multi-AZ, agnóstico a la región)

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:

#### 9.6.1 Despliegues en la nube agnósticos a la región

Para cumplir con la soberanía de datos o los marcos regulatorios (p. ej., GDPR en Europa,
[PIPEDA](https://www.corbado.com/blog/pipeda) en Canadá o [NIST](https://www.corbado.com/blog/nist-passkeys)/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](https://www.corbado.com/blog/passkeys-amazon-cognito) 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.

#### 9.6.2 Alta disponibilidad Multi-AZ (Zona de Disponibilidad)

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](https://www.corbado.com/passkeys-for-critical-infrastructure) 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](https://www.corbado.com/passkeys-for-banking) y los sitios de
[comercio electrónico](https://www.corbado.com/passkeys-for-e-commerce), donde incluso un breve tiempo de
inactividad puede llevar a un impacto significativo en los ingresos.

#### 9.6.3 Alojamiento gestionado independiente o híbrido

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.

#### 9.6.4 Infraestructura escalable y elástica

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.

#### 9.6.5 Herramientas de seguridad y cumplimiento

Estándares de la industria como [PCI](https://www.corbado.com/blog/pci-dss-4-0-authentication-passkeys)-DSS,
[PSD2](https://www.corbado.com/blog/psd2-passkeys) [SCA](https://www.corbado.com/es/blog/psd2-passkeys) o
[ISO 27001](https://www.corbado.com/blog/cybersecurity-frameworks) a menudo se aplican a los proveedores de pago.
Un [proveedor de passkeys](https://www.corbado.com/es/blog/proveedores-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.

#### 9.6.6 Recuperación ante desastres y georredundancia

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.

## 10. Conclusión: Superar las barreras de Apple y adoptar las passkeys

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.

### 10.1 Preguntas clave respondidas: Limitaciones de origen cruzado y SPC

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.

### 10.2 Cómo Corbado cierra la brecha para los proveedores de pago

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](https://www.corbado.com/blog/psd2-passkeys) SCA, etc.), garantizando el tiempo de
      actividad y la adhesión a las normas de residencia de datos en todo el mundo.

### 10.3 Conclusión final: Construir una experiencia de passkeys escalable y sin fricciones

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.