Credenciales digitales y pagos: la estrategia de Apple Wallet frente a la de Google Wallet

Los pagos 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 digitales?

Este artículo analiza cómo las credenciales digitales (incluidos los mdocs ISO y las VC enviadas mediante OpenID4VC) se conectan con el mundo de los pagos. Cubriremos:

• Cómo los wallets de teléfono actuales (Apple Wallet, Google Wallet) manejan la información de identidad frente a las tarjetas de pago.
• Por qué los estándares de identidad digital actuales como los mdocs ISO 18013-5/7 no son realmente adecuados como herramientas de pago directo.
• Qué papel podrían desempeñar protocolos como OpenID4VC en los futuros métodos de pago.
• Cómo otras aplicaciones de wallet (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 y passkeys centrándose únicamente en los pagos.

Para ver cómo se podrían usar las credenciales digitales en los pagos, primero debemos entender cómo las principales plataformas móviles de hoy y sus wallets integrados (Apple Wallet, Google Wallet) mantienen la información de identidad separada de cómo se procesan los 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, Apple ha confirmado que Safari 26 (en iOS 26) admitirá la API de credenciales digitales 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 también admite mDL basados en ISO 18013-5. El Credential Manager subyacente de Android proporciona un marco más flexible. Si bien su implementación de la API de credenciales digitales es independiente del protocolo, Android proporciona una implementación predeterminada que utiliza OpenID4VP como mecanismo de transporte.
• Instrumentos de pago (p. ej., tarjetas de crédito/débito):
  • Tanto Apple Pay (dentro de Apple Wallet) como 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, Visa), 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 respaldada por hardware para almacenar tokens de pago y criptogramas dinámicos para la seguridad de las transacciones.
  • Estos sistemas de pago interactúan directamente con las redes de pago existentes (Visa, Mastercard, 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 para probar un atributo de identidad; se presenta una tarjeta tokenizada para realizar un pago. No hay un uso directo de un mdoc como instrumento de pago dentro de estos ecosistemas nativos.

El estándar ISO/IEC 18013-5 define la estructura de datos para los mDL y otras identificaciones móviles (mdocs). Aunque es excelente para la verificación de identidad, su diseño no es adecuado para el uso directo como instrumento de pago:

Incluso si un mdoc pudiera teóricamente tener campos de datos personalizados agregados para contener un PAN o un token de pago (ya que 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 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.

Aunque un mdoc no es una herramienta de pago, puede desempeñar un papel en un flujo de «autenticación 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 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 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.

Aunque los mdocs en sí mismos no son instrumentos de pago, protocolos como OpenID for Verifiable Credentials (OpenID4VC, que abarca OpenID4VP para la presentación y 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 o SD-JWT) u otros tipos de credenciales personalizadas.
• Amplitud de casos de uso: Esta flexibilidad permite que plataformas como 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.

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.

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 rápida y de baja fricción y la verificación 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, ya que son resistentes al 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 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?

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 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 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, utiliza protocolos como el Protocolo de Cliente a Autenticador (CTAP) de FIDO 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 (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).

Con los anuncios en WWDC25, 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 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). Como se detalla en su sesión «Verificar documentos de identidad en la web», 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. 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 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 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, 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.

El wallet de identidad digital 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.

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.

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 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.
• Estandarizado entre dispositivos: Este flujo basado en FIDO 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.

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.

A continuación se muestra un recorrido de alto nivel de este proceso:

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.

{
    "payee": "Merchant XYZ",
    "currency_amount": {
        "currency": "EUR",
        "value": "23.58"
    },
    "recurring_schedule": {
        "start_date": "2024-11-01",
        "expiry_date": "2025-10-31",
        "frequency": 30
    }
}

Después de que el usuario aprueba, el wallet crea un JWT de vinculación de clave. Sus declaraciones demuestran que el usuario confirmó los datos específicos de la transacción.

{
    "nonce": "n-0S6_WzA2Mj",
    "aud": "https://example.com/verifier",
    "iat": 1709838604,
    "sd_hash": "Dy-RYwZfaaoC3inJbLslgPvMp09bH-clYP_3qbRqtW4",
    "transaction_data_hashes": ["fOBUSQvo46yQO-wRwXBcGqvnbKIueISEL961_Sjd4do"]
}

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.

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 o el MDES de Mastercard).

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

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, el organismo de estándares para pagos seguros, está integrando activamente los estándares FIDO en el protocolo EMV 3-D 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 (SPC) sirva como una alternativa moderna y resistente al 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, 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, que aprovecha su Servicio de Autenticación de Tokens (TAS) para reemplazar contraseñas y OTP con autenticación biométrica 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.

Gran parte de esta innovación está siendo acelerada por fuertes vientos regulatorios a favor, particularmente de la Unión Europea.

La regulación eIDAS 2.0 de la UE no se trata solo de proporcionar a los ciudadanos una identificación digital; prevé explícitamente que el EUDI Wallet sea un método para realizar la SCA 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 propietarias o los códigos SMS.

Un histórico acuerdo antimonopolio en la UE ya ha obligado a Apple a abrir su interfaz NFC previamente cerrada en los iPhones. A partir de iOS 17.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. 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 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.

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.

La base de cualquier estrategia de wallet futura es una aplicación nativa 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 (SCA), adopta el enfoque pragmático de PayPal:

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

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.

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

Para que las credenciales digitales se conviertan en parte integral de los procesos de pago más allá de simplemente apoyar el KYC 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/SCA en Europa, PCI DSS 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 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 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 de atributos, no en la ejecución de pagos.

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 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. 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 robusta y KYC 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.