--- url: 'https://www.corbado.com/es/blog/credenciales-digitales-pagos' title: 'Credenciales digitales y pagos: la estrategia de Apple Wallet frente a la de Google Wallet' description: 'Descubre cómo las credenciales digitales afectan a los pagos y las estrategias que pueden seguir los emisores para competir eficazmente con Apple Pay y Google Wallet.' lang: 'es' author: 'Vincent Delitz' date: '2025-07-25T06:59:58.254Z' lastModified: '2026-03-27T07:04:16.155Z' keywords: 'credenciales digitales pago' category: 'Passkeys Strategy' --- # Credenciales digitales y pagos: la estrategia de Apple Wallet frente a la de Google Wallet ### Resumen: una guía estratégica para emisores | Fase | Tu estrategia principal | Acciones clave | | :------------------- | :--------------------------------------------------------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **1. Ahora** | 📱 **Impulsa la app, domina las passkeys** | Impulsa la adopción de la app nativa sin descanso. Usa passkeys para una experiencia de pago con un solo clic que compita con Apple Pay y PayPal. | | **2. A corto plazo** | 🆔 **Usa las VC para la identidad, no para los pagos** | Integra credenciales digitales para tareas de alta seguridad como el KYC y la recuperación de cuentas. Supervisa, pero no te precipites a adoptar, las credenciales de pago verificables. | | **3. A futuro** | ⚖️ **Evalúa las VC frente a la evolución de las passkeys** | Compara cualquier flujo de pago con VC con los mejores. Adóptalas para los pagos solo cuando sea obligatorio o si aportan un valor neto superior. Presta atención a las mejoras de las passkeys, como las señales de dispositivo en banda. | ## 1. Introducción Los [pagos](https://www.corbado.com/passkeys-for-payment) digitales están en constante cambio. Queremos que sean más rápidos, seguros y fáciles de usar. Al mismo tiempo, las herramientas de identidad digital, como las credenciales verificables (VC) y los documentos de identidad móviles (mdocs), están mejorando. Ofrecen nuevas formas para que las personas demuestren quiénes son. Por lo tanto, la gran pregunta es: ¿pueden estas nuevas identificaciones digitales mejorar o simplificar significativamente los [pagos](https://www.corbado.com/passkeys-for-payment) digitales? Este artículo analiza cómo las [credenciales digitales](https://www.corbado.com/es/blog/digital-credentials-api) (incluidos los mdocs ISO y las VC enviadas mediante [OpenID4VC](https://www.corbado.com/glossary/open-id-4-vc)) se conectan con el mundo de los [pagos](https://www.corbado.com/passkeys-for-payment). Cubriremos: - Cómo los wallets de teléfono actuales (Apple [Wallet](https://www.corbado.com/blog/digital-wallet-assurance), [Google Wallet](https://www.corbado.com/blog/how-to-use-google-pay)) manejan la información de identidad frente a las tarjetas de [pago](https://www.corbado.com/passkeys-for-payment). - Por qué los estándares de [identidad digital](https://www.corbado.com/es/blog/digital-credentials-api) actuales como los mdocs [ISO 18013-5](https://www.corbado.com/glossary/iso-18013-5)/7 no son realmente adecuados como herramientas de [pago](https://www.corbado.com/passkeys-for-payment) directo. - Qué papel podrían desempeñar protocolos como [OpenID4VC](https://www.corbado.com/glossary/open-id-4-vc) en los futuros métodos de [pago](https://www.corbado.com/passkeys-for-payment). - Cómo otras aplicaciones de [wallet](https://www.corbado.com/blog/digital-wallet-assurance) (de terceros) podrían manejar las funciones de pago. - Los principales problemas y lo que podría suceder en el futuro al intentar usar credenciales verificables en los sistemas de pago. Este texto complementa nuestro otro debate sobre [credenciales digitales](https://www.corbado.com/es/blog/digital-credentials-api) y passkeys centrándose únicamente en los pagos. ## 2. Entendiendo el panorama actual: pilas de identidad vs. de pago Para ver cómo se podrían usar las [credenciales digitales](https://www.corbado.com/es/blog/digital-credentials-api) en los pagos, primero debemos entender cómo las principales plataformas móviles de hoy y sus wallets integrados (Apple [Wallet](https://www.corbado.com/blog/digital-wallet-assurance), [Google Wallet](https://www.corbado.com/blog/how-to-use-google-pay)) mantienen la información de identidad separada de cómo se procesan los pagos. ### 2.1 Wallets de plataforma nativa: silos separados para identidad y pagos Los wallets de plataforma nativa se han convertido en centros sofisticados para los usuarios, pero generalmente mantienen una clara distinción entre las credenciales de identidad y los instrumentos de pago: - **Credenciales de identidad (p. ej., mDL):** - **Apple Wallet:** Admite principalmente licencias de conducir móviles (mDL) y documentos de identidad estatales compatibles con ISO/IEC 18013-5. A partir de [WWDC25](https://www.corbado.com/blog/wwdc25-passkeys-os26), Apple ha confirmado que Safari 26 (en [iOS 26](https://www.corbado.com/blog/ios-26-passkeys)) admitirá la [API de credenciales digitales](https://www.corbado.com/es/blog/digital-credentials-api) de W3C para la presentación en línea, con un enfoque exclusivo en el protocolo `org.iso.mdoc`. Esto es para verificar atributos de identidad (p. ej., nombre, edad, dirección), no para pagos. - **Google Wallet y Android Credential Manager:** [Google Wallet](https://www.corbado.com/blog/how-to-use-google-pay) también admite [mDL](https://www.corbado.com/blog/mobile-drivers-license) basados en [ISO 18013-5](https://www.corbado.com/glossary/iso-18013-5). El Credential Manager subyacente de [Android](https://www.corbado.com/blog/how-to-enable-passkeys-android) proporciona un marco más flexible. Si bien su implementación de la [API de credenciales digitales](https://www.corbado.com/es/blog/digital-credentials-api) es independiente del protocolo, [Android](https://www.corbado.com/blog/how-to-enable-passkeys-android) proporciona una implementación predeterminada que utiliza [OpenID4VP](https://www.corbado.com/glossary/open-id-4-vp) como mecanismo de transporte. - **Instrumentos de pago (p. ej., tarjetas de crédito/débito):** - Tanto [Apple Pay](https://www.corbado.com/blog/how-to-use-apple-pay) (dentro de Apple Wallet) como [Google Pay](https://www.corbado.com/blog/how-to-use-google-pay) (dentro de Google Wallet) utilizan tecnologías de pago establecidas y altamente reguladas. Estas se basan principalmente en los estándares EMV (Europay, [Mastercard](https://www.corbado.com/blog/mastercard-passkeys), [Visa](https://www.corbado.com/blog/visa-passkeys)), que incluyen la tokenización (PAN de dispositivo o DPAN que reemplazan los números de tarjeta reales para las transacciones), elementos seguros o [seguridad](https://www.corbado.com/es/blog/como-eliminar-contrasenas-por-completo) respaldada por hardware para almacenar tokens de pago y criptogramas dinámicos para la [seguridad](https://www.corbado.com/es/blog/como-eliminar-contrasenas-por-completo) de las transacciones. - Estos sistemas de pago interactúan directamente con las redes de pago existentes (Visa, [Mastercard](https://www.corbado.com/blog/mastercard-passkeys), Amex, etc.) y los bancos adquirentes. **Conclusión clave:** Los wallets de plataforma nativa actualmente operan con «pilas» o tecnologías separadas para las credenciales de identidad frente a las tarjetas de pago. Se presenta un [mdoc](https://www.corbado.com/glossary/mdoc) para probar un atributo de identidad; se presenta una tarjeta tokenizada para realizar un pago. No hay un uso directo de un [mdoc](https://www.corbado.com/glossary/mdoc) _como_ instrumento de pago dentro de estos ecosistemas nativos. ### 2.2 Por qué los mdocs ISO 18013-5 no son instrumentos de pago El estándar ISO/IEC 18013-5 define la estructura de datos para los [mDL](https://www.corbado.com/blog/mobile-drivers-license) y otras identificaciones móviles (mdocs). Aunque es excelente para la [verificación](https://www.corbado.com/es/blog/verificacion-de-identidad-digital) de identidad, su diseño no es adecuado para el uso directo como instrumento de pago: | Característica | Lo que especifica ISO 18013-5 (para mdocs de identidad) | Por qué esto es un problema para los pagos | | :-------------------------------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Alcance principal** | Licencias de conducir móviles y otros documentos de identidad. | Las redes de tarjetas necesitan elementos de datos y criptogramas específicos para los pagos. | | **Modelo de datos** | Elementos de datos fijos relacionados con la identidad (p. ej., retrato, nombre, fecha de nacimiento). Extensible, pero aún vinculado a un espacio de nombres de «identidad». | Los PAN de tarjeta, los DPAN tokenizados, los CVM y los criptogramas dinámicos no se corresponden claramente con estos elementos de identidad. | | **Modelo de amenaza y seguridad** | Verificación con el titular presente («atendida»); «tocar para verificar» sin conexión con divulgación selectiva de atributos de identidad. Recuperación segura de datos del mdoc. | Los pagos requieren mecanismos robustos para la autorización en línea, la generación de criptogramas dinámicos (estilo EMV), la prevención de fraudes específicos para transacciones financieras y los vínculos con las fuentes de financiación. La seguridad del mdoc es para la integridad de la identidad, no para el procesamiento de transacciones financieras. | | **Reconocimiento del estándar** | ISO 18013-5 se limita explícitamente a la identificación en persona. ISO/IEC 18013-7 e ISO/IEC 23220 especifican mecanismos de presentación en línea para mdocs (p. ej., para la verificación de identidad basada en la web a través de la API de credenciales digitales), pero estos todavía se centran en la _verificación de identidad remota_, no en los sistemas de pago. | Los pagos, especialmente en línea, permanecen fuera del alcance de los propios estándares de mdoc. | Incluso si un [mdoc](https://www.corbado.com/glossary/mdoc) _pudiera_ teóricamente tener campos de datos personalizados agregados para contener un [PAN](https://www.corbado.com/glossary/pan) o un token de pago (ya que [ISO 18013-5](https://www.corbado.com/glossary/iso-18013-5) permite espacios de nombres personalizados), el estándar mdoc en sí no define: - Cómo generar o procesar criptogramas de pago dinámicos. - Cómo realizar la autorización en línea con una red de pago. - Los mecanismos de [seguridad](https://www.corbado.com/es/blog/como-eliminar-contrasenas-por-completo) necesarios específicos para las transacciones de pago (más allá de la integridad de los datos de identidad). Por lo tanto, actualmente no hay forma de usar un mdoc ISO 18013-5 como instrumento de pago directo. ### 2.3 Autenticación reforzada: uso de mdocs para la verificación de identidad, no para el pago Aunque un mdoc no es una herramienta de pago, puede desempeñar un papel en un flujo de «[autenticación](https://www.corbado.com/es/glossary/jwks) reforzada», donde la identidad de un usuario debe verificarse explícitamente para una acción de alto riesgo. Esto es distinto de usarlo para ejecutar el pago en sí. El flujo normalmente se vería así: 1. **Autenticación primaria:** El usuario inicia sesión en un servicio, a menudo con un método de baja fricción como una passkey. 2. **Activador para el refuerzo:** Para una acción de alta seguridad (p. ej., una gran transferencia bancaria, actualizar datos personales), el servicio requiere una [verificación](https://www.corbado.com/es/blog/verificacion-de-identidad-digital) de identidad explícita. 3. **Presentación del mdoc:** El servicio solicita una presentación del mdoc del usuario (p. ej., licencia de conducir). El usuario presenta los atributos requeridos desde su wallet. 4. **Verificación:** El servicio verifica criptográficamente los datos del mdoc contra una fuente confiable o una identidad previamente registrada. En este modelo, el mdoc proporciona una prueba de identidad fuerte y resistente al [phishing](https://www.corbado.com/glossary/phishing) para un momento específico de alto riesgo. Sin embargo, la transacción financiera que sigue todavía utiliza los sistemas de pago establecidos. El mdoc verifica a la _persona_, no al _método de pago_. ## 3. El papel de OpenID4VC en posibles escenarios de pago Aunque los mdocs en sí mismos no son instrumentos de pago, protocolos como OpenID for [Verifiable Credentials](https://www.corbado.com/glossary/microcredentials) (OpenID4VC, que abarca [OpenID4VP](https://www.corbado.com/glossary/open-id-4-vp) para la presentación y [OpenID4VCI](https://www.corbado.com/glossary/openid4vci) para la emisión) ofrecen una capa de transporte más flexible. **Características clave de OpenID4VC:** - **Protocolo, no carga útil:** OID4VC define cómo solicitar y presentar VC, pero es en gran medida agnóstico sobre el formato de la carga útil de la VC en sí. Puede transportar mdocs, VC estándar de W3C (p. ej., en formato [JWT](https://www.corbado.com/es/glossary/jwks) o SD-[JWT](https://www.corbado.com/es/glossary/jwks)) u otros tipos de credenciales personalizadas. - **Amplitud de casos de uso:** Esta flexibilidad permite que plataformas como [Android](https://www.corbado.com/blog/how-to-enable-passkeys-android) (a través de su Credential Manager) admitan solicitudes de varios tipos de credenciales a través de un mecanismo común. - **Compatibilidad futura para VC de pago:** Si la industria de pagos estandarizara un formato de credencial de «token de pago» o «autorización de pago» verificable, OID4VC podría teóricamente transportar dicha credencial entre el wallet de un usuario y un comerciante/[PSP](https://www.corbado.com/blog/payment-provider-passkeys-third-party-sdk). **Sin embargo, OID4VC en sí mismo no es una solución de pago:** - El papel de OID4VC es facilitar el intercambio de una credencial. No define el contenido de la credencial de pago, sus características de seguridad ni cómo interactúa con los sistemas de procesamiento de pagos. - Para que OID4VC sea útil para los pagos, primero sería necesario desarrollar y respaldar un _formato de credencial de pago verificable_ ampliamente adoptado, seguro y estandarizado por el ecosistema de pagos (emisores, adquirentes, redes). Esto no existe actualmente. ## 4. Wallets de terceros y pagos Más allá de los wallets de plataforma nativa, está surgiendo un ecosistema creciente de wallets de terceros (p. ej., EUDI Wallet, wallets proporcionados por bancos, wallets especializados de la industria). Estos wallets deben navegar por la diferencia fundamental entre la [autenticación](https://www.corbado.com/es/glossary/jwks) rápida y de baja fricción y la [verificación](https://www.corbado.com/es/blog/verificacion-de-identidad-digital) de atributos de alta seguridad, especialmente en contextos de pago. El consenso emergente es que [las passkeys son ideales para la _autenticación_ principal en un servicio de pago](https://www.corbado.com/blog/digital-credentials-passkeys#34-payment-scenarios-low-friction), ya que son resistentes al [phishing](https://www.corbado.com/glossary/phishing) y están diseñadas para una experiencia de usuario fluida. Inyectar una presentación de credencial digital en el paso crítico de confirmación del pago agregaría una fricción significativa y probablemente perjudicaría las tasas de conversión. Por lo tanto, el papel principal de las credenciales digitales está en la fase única de alta seguridad de incorporación y [KYC](https://www.corbado.com/blog/iso-18013-7-mdl-bank-kyc-onboarding) que habilita las capacidades de pago, en lugar de en la transacción en sí. ¿Cómo podrían estos wallets abordar los pagos, especialmente en conjunto con las funciones de [identidad digital](https://www.corbado.com/es/blog/digital-credentials-api)? ### 4.1 Modelos de interacción actuales para pagos Para que un wallet de terceros autorice un pago, necesita una forma de ser invocado por la aplicación o el sitio web del comerciante. Existen varios modelos de interacción establecidos para esto, cada uno con diferentes niveles de integración de plataforma y experiencia de usuario: - **Deep Linking de aplicación a aplicación:** Este es un método universal donde la aplicación del comerciante (nativa o web) redirige al usuario a la aplicación del wallet de terceros utilizando un esquema de URL personalizado (p. ej., `eudi-wallet://...`). Los detalles de la transacción se pasan como parámetros en la URL. Después de que el usuario confirma el pago en la aplicación del wallet, esta lo redirige de nuevo a la aplicación del comerciante usando otro deep link. Esto funciona tanto en [iOS](https://www.corbado.com/blog/how-to-enable-passkeys-ios) como en Android, pero implica un cambio de contexto visible entre aplicaciones. - **Selección de wallet nativo:** Con la selección de wallet nativo, una aplicación puede invocar un servicio genérico del sistema que muestra todos los manejadores de pago o wallets registrados. El usuario puede entonces seleccionar su wallet preferido desde una interfaz de usuario proporcionada por el sistema. Esto ofrece una sensación más integrada que el simple deep linking (API de credenciales digitales). - **Pagos simples basados en códigos QR:** Este modelo es ideal para flujos de escritorio a móvil. El sitio web del comerciante muestra un [código QR](https://www.corbado.com/es/blog/inicio-sesion-codigo-qr-autenticacion) que contiene los detalles de la transacción o una URL. El usuario escanea este código con su aplicación de wallet móvil, que luego maneja de forma independiente la confirmación en el teléfono. El backend del wallet luego comunica la aprobación al sistema del comerciante. - **Flujos estandarizados entre dispositivos (FIDO CTAP):** Una evolución del método de [código QR](https://www.corbado.com/es/blog/inicio-sesion-codigo-qr-autenticacion), utiliza protocolos como el Protocolo de Cliente a Autenticador (CTAP) de [FIDO](https://www.corbado.com/es/blog/servidor-control-acceso-emv-3ds-passkeys-fido-spc) para crear un canal directo, seguro y cifrado entre el navegador de escritorio (cliente) y el wallet móvil (actuando como un autenticador). Esto es más seguro que los simples códigos QR, ya que el navegador y el teléfono se comunican directamente, un modelo fuertemente respaldado por Google tanto para passkeys como para credenciales digitales. - **Integración directa de backend:** En algunos sistemas de circuito cerrado, la aplicación de wallet de terceros podría interactuar directamente con un [Proveedor de Servicios de Pago](https://www.corbado.com/es/blog/passkeys-proveedores-pago-sdk-terceros) (PSP) o el backend de una institución financiera para procesar pagos, a menudo utilizando API propietarias. Estos modelos proporcionan la «capa de transporte» para iniciar una confirmación de pago, dentro de la cual puede tener lugar un flujo criptográfico (como el detallado para el EUDI Wallet). ### 4.2 Integración del navegador: la identidad primero, los pagos por separado Con los anuncios en [WWDC25](https://www.corbado.com/blog/wwdc25-passkeys-os26), el panorama de cómo los navegadores manejan las credenciales digitales se ha vuelto mucho más claro, solidificando la separación entre la verificación de identidad y el procesamiento de pagos. Las plataformas están permitiendo que los wallets de terceros interactúen con los navegadores para la _verificación de identidad_ a través de la [API de credenciales digitales](https://www.corbado.com/es/blog/digital-credentials-api) de W3C, pero los enfoques están divergiendo: - **La postura de Apple (confirmada en WWDC25):** Apple anunció oficialmente el soporte para la API de credenciales digitales en Safari 26 (que se enviará con [iOS 26](https://www.corbado.com/blog/ios-26-passkeys)). Como se detalla en su sesión [«Verificar documentos de identidad en la web»](https://developer.apple.com/videos/play/wwdc2025/232/), la implementación **admite exclusivamente el protocolo `org.iso.mdoc`**. Esto permite que los sitios web soliciten información verificable de los mdocs en Apple Wallet u otras aplicaciones de proveedores de documentos de terceros registradas, pero no admite el protocolo de propósito más general [OpenID4VP](https://www.corbado.com/glossary/open-id-4-vp). Con el creciente soporte para credenciales digitales y las integraciones web mejoradas, mantener el rendimiento y la seguridad del sistema se vuelve aún más crucial; herramientas como [CleanMyMac](https://cleanmymac.com/) ayudan a garantizar que tu Mac funcione sin problemas a medida que estas tecnologías evolucionan. - **La postura de Google:** El Credential Manager de Android permite que los wallets de terceros se registren como manejadores de solicitudes de credenciales. Su implementación de la API de credenciales digitales en Chrome se centra en el uso de **OpenID4VP** como el protocolo de transporte principal. Aunque OpenID4VP puede llevar un mdoc como carga útil, el protocolo en sí es diferente del enfoque directo `org.iso.mdoc` de Apple. **Crucialmente, estas integraciones de navegador son para atributos de identidad, no para tratar el mDoc o la VC presentada como un instrumento de pago.** Si un usuario presenta un [mDL](https://www.corbado.com/blog/mobile-drivers-license) desde su wallet a un sitio web a través de la API de credenciales digitales del navegador, ese sitio web podría usar la información para rellenar automáticamente la dirección o para la verificación de edad durante el pago. Sin embargo, el paso de pago real aún requeriría una interacción separada con un método de pago (p. ej., [Apple Pay](https://www.corbado.com/blog/how-to-use-apple-pay), [Google Pay](https://www.corbado.com/blog/how-to-use-google-pay) o ingresar los detalles de la tarjeta). La API del navegador en sí no está diseñada para iniciar o procesar una transacción financiera utilizando una credencial de identidad. ## 5. El wallet de identidad digital de la UE en la práctica El wallet de [identidad digital](https://www.corbado.com/es/blog/digital-credentials-api) de la UE (EUDI) sirve como un excelente caso de estudio de cómo un wallet de terceros debe navegar por el complejo panorama del mundo real de los sistemas operativos y la disponibilidad de API. Entre sus muchas funciones, dos de los casos de uso más prominentes son la verificación de identidad y la confirmación de pagos, y las vías técnicas para lograr estas dos tareas son diferentes, especialmente al comparar el marco flexible de Android con la implementación más rígida de Apple. ### 5.1 Comparación del modelo de interacción: identidad vs. pago La siguiente tabla desglosa cómo se puede invocar el EUDI Wallet para la verificación de identidad o la autorización de pago, destacando el soporte diferente entre plataformas. | Modelo de integración | Identidad (Android) | Identidad (iOS) | Pago (Android) | Pago (iOS) | | :------------------------------------------ | :-----------------: | :-------------: | :------------: | :--------: | | **API de credenciales digitales** | ✅ | ✅ | ✅\* | ❌ | | **Selector de wallet nativo** | ✅ | ✅ | ✅ | ❌ | | **Deep Linking de aplicación a aplicación** | ✅ | ✅ | ✅ | ✅ | | **Estandarizado entre dispositivos** | ✅ | ❌ | ✅ | ❌ | **Conclusiones clave de la comparación:** - **API de credenciales digitales:** Este estándar emergente de W3C es independiente del protocolo y está bien soportado para la **identidad** en ambas plataformas. Para su implementación, Android proporciona un flujo predeterminado utilizando el flexible protocolo OpenID4VP, que puede transportar varios formatos de credenciales. La implementación de Apple, en cambio, es estrictamente para el formato `org.iso.mdoc`. Crucialmente, los navegadores limitan esta API a casos de uso de identidad, no para iniciar pagos. - **Selector de wallet nativo:** Ambos sistemas operativos proporcionan una interfaz de usuario nativa para seleccionar un wallet, pero con diferentes limitaciones. Android ofrece un selector tanto para aplicaciones de identidad como de pago. [iOS](https://www.corbado.com/blog/how-to-enable-passkeys-ios) proporciona un selector para aplicaciones registradas de «Proveedor de documentos» de identidad, pero no ofrece uno para aplicaciones de pago de terceros. - **Deep Linking de aplicación a aplicación:** Este es el caballo de batalla universal, que funciona de manera fiable tanto para casos de uso de identidad como de pago en ambas plataformas. Sigue siendo el método principal para invocar un wallet de terceros para pagos en [iOS](https://www.corbado.com/blog/how-to-enable-passkeys-ios). - **Estandarizado entre dispositivos:** Este flujo basado en [FIDO](https://www.corbado.com/es/blog/servidor-control-acceso-emv-3ds-passkeys-fido-spc) CTAP es actualmente una característica del ecosistema de Google/Android y no es compatible con iOS. **(\*) Nota sobre los pagos a través de la API de DC:** Aunque el uso de OpenID4VP por parte de Android hace que un flujo de pago sea _técnicamente_ factible a través de la API de credenciales digitales, este no es su enfoque de diseño principal. La integración fluida para los pagos a través de esta API específica, en lugar de otros métodos nativos, aún está por verse y requeriría un soporte explícito de los proveedores de navegadores. Esta comparación deja claro que, si bien la verificación de identidad se está estandarizando cada vez más a través de la API de credenciales digitales, la autorización de pagos para wallets de terceros como el EUDI Wallet todavía depende en gran medida de patrones de integración nativos más tradicionales como el deep linking de aplicación a aplicación, especialmente en iOS. ### 5.2 Bajo el capó: el flujo de confirmación de pago de EWC Independientemente del modelo de integración de pago que se utilice para invocar el wallet, el núcleo de la confirmación de pago del wallet EUDI se basa en un flujo criptográfico estandarizado detallado en [`EWC RFC008`](https://github.com/EWC-consortium/eudi-wallet-rfcs/blob/main/payment-rfcs/ewc-rfc008-payment-data-confirmation.md). A continuación se muestra un recorrido de alto nivel de este proceso: | Paso | Acción | Artefactos clave | | ---- | ----------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 1 | **Solicitud de autorización** | El comerciante o PSP envía una solicitud OpenID4VP al wallet que contiene una `presentation_definition` que hace referencia a una _Atestación de wallet de pago_ **y** un objeto `transaction_data` codificado en base64url (importe, moneda, beneficiario). | | 2 | **Revisión y consentimiento del usuario** | El wallet muestra los detalles del pago legibles por humanos (p. ej., 23,58 € a _Comerciante XYZ_) y le pide al usuario que apruebe con un gesto biométrico o PIN. | | 3 | **Presentación verificable** | El wallet devuelve una presentación verificable que incluye (a) la atestación de wallet de pago seleccionada (como una VC SD-JWT) y (b) un JWT de vinculación de clave cuya declaración `transaction_data_hashes` demuestra que el usuario firmó la carga útil exacta del paso 1. | | 4 | **Verificación** | El PSP valida la presentación, comprueba que el hash de los `transaction_data` originales coincide con el del JWT y se asegura de que la marca de tiempo sea reciente. | | 5 | **Movimiento de fondos** | Habiendo cumplido con la SCA, el PSP procede con el pago normal con tarjeta o cuenta, seguro de que el usuario confirmó explícitamente los detalles de la transacción. | #### Ejemplo: carga útil de datos de transacción Este es un ejemplo no normativo del objeto `payment_data` que se envía al wallet, detallando la transacción para que el usuario la confirme. ```json { "payee": "Merchant XYZ", "currency_amount": { "currency": "EUR", "value": "23.58" }, "recurring_schedule": { "start_date": "2024-11-01", "expiry_date": "2025-10-31", "frequency": 30 } } ``` #### Ejemplo: declaraciones del JWT de vinculación de clave Después de que el usuario aprueba, el wallet crea un [JWT](https://www.corbado.com/es/glossary/jwks) de vinculación de clave. Sus declaraciones demuestran que el usuario confirmó los datos específicos de la transacción. ```json { "nonce": "n-0S6_WzA2Mj", "aud": "https://example.com/verifier", "iat": 1709838604, "sd_hash": "Dy-RYwZfaaoC3inJbLslgPvMp09bH-clYP_3qbRqtW4", "transaction_data_hashes": ["fOBUSQvo46yQO-wRwXBcGqvnbKIueISEL961_Sjd4do"] } ``` ## 6. La respuesta de la industria: convergiendo pagos e identidad Mientras los estándares técnicos evolucionan, la industria de pagos no se queda quieta. Los actores clave están explorando activamente cómo fusionar la seguridad de las credenciales digitales con la funcionalidad de los pagos. ### 6.1 Paralelismos con la tokenización de pagos Una forma poderosa de entender el potencial de las credenciales verificables (VC) es compararlas con los exitosos sistemas de tokenización de pagos de red (como el servicio de tokens de [Visa](https://www.corbado.com/blog/visa-passkeys) o el MDES de [Mastercard](https://www.corbado.com/blog/mastercard-passkeys)). - La **tokenización de pagos** reemplazó el sensible número de cuenta principal (PAN) por un token seguro y un criptograma de un solo uso. Esto protege el activo principal —el número de la tarjeta— durante las transacciones. - Las **credenciales verificables** tienen como objetivo hacer por los datos personales lo que la tokenización hizo por los [PAN](https://www.corbado.com/glossary/pan). En lugar de compartir datos brutos (nombre, fecha de nacimiento, dirección), el usuario presenta una credencial firmada criptográficamente de un emisor de confianza. En esencia, **una VC es para los datos personales lo que un token de pago y un criptograma son para los datos de la tarjeta**: un sustituto seguro y verificable que reduce el riesgo y mejora la privacidad. ### 6.2 El auge de las credenciales de pago verificables A partir de este paralelismo, los organismos de la industria están trabajando en el concepto de una «credencial de pago verificable». Esta sería una credencial, emitida por un banco, que empaqueta un instrumento de pago (como una tarjeta tokenizada) y puede usarse para autorizar transacciones. - [**EMVCo**](https://www.corbado.com/blog/emv-3ds-acs-passkeys-fido-and-spc), el organismo de estándares para pagos seguros, está integrando activamente los estándares [FIDO](https://www.corbado.com/es/blog/servidor-control-acceso-emv-3ds-passkeys-fido-spc) en el protocolo EMV [3-D Secure](https://www.corbado.com/glossary/3d-secure). Esto permite que las autenticaciones previas con passkeys se utilicen como una señal fuerte para aprobaciones sin fricción, mientras que también se prepara para que la [Confirmación de Pago Segura](https://www.corbado.com/es/blog/vinculacion-dinamica-passkeys-spc) (SPC) sirva como una alternativa moderna y resistente al [phishing](https://www.corbado.com/glossary/phishing) a los desafíos tradicionales de OTP. También hay discusiones en curso sobre cómo las credenciales verificables podrían incorporarse en estos flujos en el futuro. - **Visa** ha anunciado el [**Servicio de Passkey de Pago de Visa**](https://www.corbado.com/blog/visa-passkeys), que vincula de forma segura un autenticador FIDO a las credenciales de pago. Este servicio está diseñado para confirmar la identidad y autorizar pagos en un solo paso sin fricción y sin interrumpir la experiencia de pago. - **Mastercard** está siguiendo una estrategia paralela con su [**Servicio de Passkey de Pago de Mastercard**](https://www.corbado.com/blog/mastercard-passkeys), que aprovecha su Servicio de [Autenticación](https://www.corbado.com/es/glossary/jwks) de Tokens (TAS) para reemplazar contraseñas y OTP con [autenticación biométrica](https://www.corbado.com/es/blog/mastercard-passkeys) basada en passkeys, estrechamente integrada con sus servicios de tokenización (MDES). Esto muestra una tendencia clara: la industria se está moviendo hacia un futuro en el que un wallet puede presentar una prueba criptográficamente verificable tanto de la identidad como de la autorización de pago en un único flujo estandarizado. ## 7. El panorama regulatorio: Europa como catalizador Gran parte de esta innovación está siendo acelerada por fuertes vientos regulatorios a favor, particularmente de la Unión Europea. ### 7.1 El papel del EUDI Wallet en la autenticación reforzada de clientes (SCA) La [regulación eIDAS 2.0](https://digital-strategy.ec.europa.eu/en/policies/eidas-regulation) de la UE no se trata solo de proporcionar a los ciudadanos una identificación digital; prevé explícitamente que el [EUDI Wallet](https://commission.europa.eu/strategy-and-policy/priorities-2019-2024/europe-fit-digital-age/european-digital-identity_en) sea un método para realizar la [SCA](https://www.corbado.com/es/blog/psd2-passkeys) en los pagos en línea. Esto significa que, en el futuro, los bancos y proveedores de pago en la UE podrían estar obligados a aceptar el EUDI Wallet como una forma para que los usuarios confirmen las transacciones en línea, proporcionando una alternativa basada en estándares a las aplicaciones de [banca](https://www.corbado.com/passkeys-for-banking) propietarias o los códigos SMS. ### 7.2 El jardín vallado del NFC de Apple ahora está abierto (en Europa) Un histórico [acuerdo antimonopolio en la UE](https://ec.europa.eu/commission/presscorner/detail/en/ip_24_3706) ya ha obligado a Apple a abrir su interfaz NFC previamente cerrada en los iPhones. A partir de [iOS 17](https://www.corbado.com/blog/apple-passkeys-integration).4 (lanzado el 5 de marzo de 2024), Apple ha implementado las API necesarias y ha permitido a los usuarios seleccionar una aplicación de pago sin contacto predeterminada, cumpliendo con el plazo vinculante de la Comisión Europea del 25 de julio de 2024. Esto ya no es una perspectiva futura; es la realidad actual en el Espacio Económico Europeo (EEE). Este cambio significa que las aplicaciones de wallet de terceros ahora pueden ofrecer sus propias soluciones de «tocar para pagar» en iOS, poniendo fin al monopolio de larga data de [Apple Pay](https://www.corbado.com/blog/how-to-use-apple-pay). Las capacidades clave ahora disponibles para los desarrolladores incluyen: - **Elección de wallet predeterminado:** Los usuarios en el EEE pueden establecer una aplicación de terceros elegible como su aplicación de pago sin contacto predeterminada, que puede ser invocada mediante un doble clic en el botón lateral. - **Integración completa:** Estos wallets pueden usar las funciones de seguridad nativas del iPhone, incluyendo [Face ID](https://www.corbado.com/faq/is-face-id-passkey) y Touch ID, para la autorización de pagos. - **Adopción en el mundo real:** Varios actores importantes ya han lanzado sus soluciones, incluyendo **Vipps MobilePay** en Noruega y **PayPal** en Alemania. Las implicaciones de esta apertura son significativas y ya se están desarrollando: - **Mayor competencia:** Los bancos y las fintechs ahora pueden competir directamente con Apple Pay en su propia plataforma, lo que se espera que reduzca las tarifas de los emisores e impulse la innovación. - **Uso más amplio de credenciales:** Las mismas API se pueden usar para más que solo pagos, incluyendo credenciales corporativas, pases de transporte y llaves de hotel, sin necesidad de estar en Apple Wallet. - **Un camino para las credenciales estandarizadas:** Esto sienta un precedente crucial. La misma lógica regulatoria que abrió la interfaz NFC para las aplicaciones de pago podría eventualmente usarse para exigir el soporte de «credenciales de pago verificables» estandarizadas y neutrales (como las que se están probando para el EUDI Wallet), permitiéndoles funcionar junto con soluciones propietarias. - **Precedente global:** Aunque el cambio se limita actualmente al EEE, sienta un poderoso precedente global. Los reguladores de otras regiones, incluido EE. UU., están observando de cerca, y esto podría acelerar aperturas similares en todo el mundo. ## 8. Una guía para emisores: una estrategia práctica para pagos verificables Para los emisores de pagos (bancos, esquemas, fintechs), navegar el cambio hacia las credenciales digitales requiere una estrategia pragmática y por fases. El objetivo es construir sobre los activos que controlas hoy para prepararte para el ecosistema del mañana. Esta guía describe esa estrategia, pasando de acciones inmediatas y de bajo riesgo a evaluaciones más estratégicas y a largo plazo. ### Fase 1: Ampliar la cobertura y asegurar los pagos con passkeys (hoy) La base de cualquier estrategia de wallet futura es una [aplicación nativa](https://www.corbado.com/es/blog/passkeys-aplicaciones-nativas-webview) segura y ampliamente adoptada. La prioridad inmediata es maximizar el alcance de tu aplicación y fortalecer su autenticación tanto para el inicio de sesión como para los pagos. 1. **Impulsa la adopción de la aplicación nativa:** Tu aplicación móvil es tu futuro wallet. El objetivo principal es convertirla en una herramienta indispensable para tus clientes. Esta distribución y compromiso es la base fundamental para cualquier futura emisión de credenciales o funcionalidad de wallet. 2. **Usa passkeys para pagos, siguiendo el modelo de PayPal:** Despliega passkeys de inmediato, no solo para iniciar sesión, sino para la autorización de pagos. Apunta a una experiencia con una paridad cercana a las soluciones de plataforma nativa como Apple Pay. Para entornos regulatorios que requieren la [Autenticación Reforzada de Clientes](https://www.corbado.com/blog/psd2-sca-requirements) (SCA), adopta el enfoque pragmático de [PayPal](https://www.corbado.com/blog/paypal-passkeys): - Aprovecha las passkeys como un factor de autenticación principal. - Combínalas con señales de dispositivo de confianza (p. ej., «dispositivos recordados» gestionados a través de tu aplicación o cookies seguras) para cumplir con el factor de «posesión» de la [SCA](https://www.corbado.com/es/blog/psd2-passkeys). - Esta combinación te permite proporcionar una experiencia de confirmación de pago fluida y de baja fricción que es a la vez altamente segura y compatible, sin esperar el soporte universal de las VC. ### Fase 2: Evolucionar las capacidades con tecnología emergente (próximos 24-36 meses) Con una aplicación segura y protegida con passkeys como base, puedes comenzar a integrar selectivamente nuevas tecnologías de credenciales donde ofrezcan un valor claro. 3. **Supervisa el auge de las credenciales de pago verificables:** El concepto de una VC que lleva un token de pago es poderoso pero aún no está estandarizado. Tu papel aquí es ser un observador y participante activo. - **Acción:** Sigue de cerca el progreso dentro de los organismos de estándares como EMVCo y el W3C. Prepárate para aprovechar las credenciales de pago verificables estandarizadas si y cuando proporcionen una clara ventaja sobre los flujos existentes basados en passkeys. 4. **Integra credenciales digitales para casos de uso de identidad:** A medida que los wallets de identidad digital (como el EUDI Wallet) ganen tracción, integra la API de credenciales digitales para tareas _relacionadas con la identidad_, no para pagos. - **Acción:** Usa presentaciones de VC para procesos de alta seguridad donde sobresalen: - **Incorporación y KYC:** Agiliza la configuración de nuevas cuentas. - **Autenticación reforzada:** Verifica la identidad para acciones de alto riesgo. - **Recuperación de cuenta:** Proporciona una ruta segura para los usuarios que han perdido sus dispositivos. ### Fase 3: Mantener un punto de referencia sin fricción y supervisar la evolución de las passkeys La barrera final para la adopción de cualquier nueva tecnología de pago es la fricción del usuario. Antes de desplazar un simple flujo de passkey, una alternativa basada en VC debe demostrar que no solo es más segura, sino igualmente fluida. 5. **Compara implacablemente con la experiencia de un solo clic:** El estándar para una experiencia de pago moderna lo establecen líderes como Apple Pay y su seguidor cercano en la web, [PayPal](https://www.corbado.com/blog/paypal-passkeys). Cualquier nuevo flujo que introduzcas debe competir con su confirmación casi instantánea de un solo clic. Todas las señales actuales indican que para la gran mayoría de las transacciones, la resistencia al phishing de las passkeys proporciona un nivel suficiente de protección y una experiencia de usuario superior. No agregues un paso de presentación de VC a un flujo de pago si introduce alguna fricción perceptible. 6. **Presta atención a las señales de dispositivo en banda dentro de WebAuthn:** La evolución de las passkeys no es estática. Aunque los primeros intentos de proporcionar señales específicas del dispositivo se descontinuaron, los organismos de estándares están trabajando activamente en la integración de señales de confianza de vinculación de dispositivos más fuertes directamente en el protocolo WebAuthn. Esto permitiría a un RP identificar un dispositivo de confianza durante una autenticación con passkey, fortaleciendo aún más la señal para los motores de riesgo sin requerir una presentación de VC separada y fuera de banda. Supervisa este espacio de cerca, ya que es el camino más probable hacia una seguridad mejorada sin sacrificar la experiencia sin fricción de la passkey. Siguiendo esta guía por fases, un emisor puede construir una estrategia robusta y práctica que maximice la seguridad y mejore la experiencia del usuario hoy, mientras se prepara para adoptar cuidadosamente las tecnologías de pago verificables del mañana. ## 9. Desafíos y perspectivas futuras para las VC en los pagos Para que las credenciales digitales se conviertan en parte integral de los procesos de pago más allá de simplemente apoyar el [KYC](https://www.corbado.com/blog/iso-18013-7-mdl-bank-kyc-onboarding) o autenticar a los usuarios en las cuentas de pago, se deben abordar varios desafíos significativos: 1. **Estandarización de VC específicas para pagos:** Es necesario desarrollar un formato de credencial verificable dedicado, seguro y ampliamente aceptado para los pagos. Esto necesitaría encapsular tokens de pago, datos específicos de la transacción y potencialmente elementos de seguridad dinámicos, superando con creces el alcance de los mdocs actuales centrados en la identidad o las VC genéricas. 2. **Integración con redes de pago:** Cualquier solución de pago basada en VC debe integrarse sin problemas con las redes de pago globales existentes (Visa, Mastercard, etc.) o proponer nuevos sistemas viables. Esto implica complejas alineaciones técnicas, de seguridad y de modelo de negocio. 3. **Cumplimiento normativo:** Los pagos están fuertemente regulados (p. ej., [PSD2](https://www.corbado.com/blog/psd2-passkeys)/[SCA](https://www.corbado.com/es/blog/psd2-passkeys) en Europa, [PCI DSS](https://www.corbado.com/blog/pci-dss-4-0-authentication-passkeys) a nivel mundial). Un sistema de pago basado en VC necesitaría cumplir con todas las regulaciones financieras pertinentes, incluidas las de seguridad, protección del consumidor y antifraude. 4. **Adopción por parte de emisores y adquirentes:** Los bancos, las instituciones financieras (como emisores de VC de pago) y los adquirentes de comerciantes necesitarían invertir en la [infraestructura](https://www.corbado.com/passkeys-for-critical-infrastructure) para soportar dicho sistema. 5. **Modelo de seguridad:** Sería esencial un modelo de seguridad robusto específicamente para las VC de pago, que cubra la emisión, el almacenamiento (idealmente en elementos seguros respaldados por hardware), la presentación y la revocación en un contexto financiero. 6. **Experiencia de usuario:** Aunque las VC pueden ofrecer control al usuario, la experiencia de pago debe seguir siendo rápida, intuitiva y fiable para obtener una adopción generalizada. **Posibilidades futuras:** - **VC como comprobantes de autorización de pago:** Las VC podrían representar una «autorización» firmada criptográficamente para pagar desde una cuenta vinculada, presentada a través de OpenID4VP, mientras que la transferencia de fondos real seguiría ocurriendo a través de los sistemas tradicionales. - **VC que contienen tokens de pago:** Se podría definir una VC estandarizada para contener de forma segura un token de pago (similar a un DPAN de EMV), que luego es procesado por las [infraestructuras](https://www.corbado.com/passkeys-for-critical-infrastructure) de pago existentes. - **VC de pago de circuito cerrado:** Emisores o comunidades específicas podrían crear VC para pagos dentro de sus propios sistemas de circuito cerrado. Sin embargo, estas son en gran medida conceptuales en la actualidad. El impulso principal detrás del desarrollo actual de VC y mdoc, ahora solidificado por las implementaciones concretas de las API de los navegadores, sigue centrado en la verificación de identidad y la [atestación](https://www.corbado.com/es/glossary/attestation) de atributos, no en la ejecución de pagos. ## 10. Conclusión: un camino pragmático para los emisores La convergencia de la identidad digital y los pagos presenta un panorama complejo pero navegable. Si bien la promesa de una única y universal «credencial de pago verificable» es atractiva, este artículo concluye que la estrategia más efectiva y práctica para los emisores de pagos hoy en día se basa en una realidad diferente: **la batalla por la mejor experiencia de usuario es primordial, y las passkeys son el arma más poderosa.** La guía estratégica es clara. El movimiento inmediato y de bajo riesgo es centrarse en establecer una [aplicación nativa](https://www.corbado.com/es/blog/passkeys-aplicaciones-nativas-webview) imbatible, usándola como vehículo para desplegar pagos basados en passkeys que puedan competir con el estándar de «un solo clic» sin fricción establecido por Apple Pay y [PayPal](https://www.corbado.com/blog/paypal-passkeys). Este enfoque aborda las necesidades básicas de seguridad (a través de la resistencia al phishing) y la experiencia del usuario hoy, utilizando tecnología madura y ampliamente adoptada. En este modelo, las credenciales verificables encuentran su papel crucial, pero distinto. Todavía no son la herramienta para el acto de pago en sí, sino que son indispensables para las tareas de identidad de alta seguridad que lo rodean: incorporación segura, [recuperación de cuenta](https://www.corbado.com/es/blog/como-eliminar-contrasenas-por-completo) robusta y [KYC](https://www.corbado.com/blog/iso-18013-7-mdl-bank-kyc-onboarding) regulatorio. El futuro de los pagos no será determinado por una sola tecnología, sino por un enfoque implacable en el usuario. El éxito llegará a los emisores que dominen primero la experiencia impulsada por passkeys en sus propias aplicaciones, mientras supervisan cuidadosamente la evolución de las credenciales verificables y las señales de confianza de passkeys en banda. Deben estar listos para integrar estas nuevas tecnologías no cuando simplemente estén disponibles, sino solo cuando puedan cumplir con el formidable punto de referencia de una experiencia de pago verdaderamente fluida, segura y superior.