Comercio agéntico: comparativa de identidad en Visa TAP, Google AP2 y Mastercard Agent Pay

Puntos clave

• Visa Trusted Agent Protocol (TAP), Google Agent Payments Protocol (AP2) y Mastercard Agent Pay hacen que las compras dirigidas por agentes sean más seguras, pero resuelven diferentes partes del problema de confianza.
• TAP ayuda a los comerciantes a reconocer agentes aprobados y verificar la intención de comercio firmada. AP2 crea evidencia de lo que un usuario autorizó. Agent Pay combina agentes registrados, credenciales de pago tokenizadas, consentimiento y visibilidad de la red.
• Ninguno de estos mecanismos elimina la necesidad de probar quién es la persona o empresa, evaluar riesgos, aplicar controles específicos de jurisdicción y mantener un registro de auditoría.
• Didit es una infraestructura neutral para la identidad y el fraude, no una red de tarjetas o una empresa de pagos. Su servidor de Model Context Protocol (MCP) alojado expone 115 herramientas en 11 categorías, mientras que la Interfaz de Programación de Aplicaciones (API) REST (Representational State Transfer) soporta flujos de producción integrados.
• Un paquete completo de Know Your Customer (KYC) cuesta $0.33, cada cuenta incluye 500 verificaciones gratuitas al mes, y el propio servidor MCP es gratuito.

El comercio agéntico comienza cuando un agente de inteligencia artificial (IA) hace más que recomendar un producto. Compara ofertas, arma un carrito, elige un método de pago y puede completar una compra dentro de los límites establecidos por una persona o empresa. Ese cambio crea varias preguntas de confianza a la vez: ¿Qué agente hizo la solicitud? ¿Quién la autorizó? ¿Quién es la persona o entidad legal detrás de ella? ¿Está permitida la transacción? ¿Y qué evidencia existirá si se disputa la compra?

Los estándares de pago emergentes responden a partes importantes de esa secuencia. No todos responden a la misma parte, y no deben tratarse como intercambiables. Para los desarrolladores, la pregunta útil no es qué marca “ganará”. Es qué controles siguen siendo necesarios bajo cada arquitectura creíble.

Tres estándares, tres límites de confianza

Visa TAP: ¿puede el comerciante reconocer y confiar en este agente?

Visa Trusted Agent Protocol está orientado al comerciante. Su función principal es ayudar a un comerciante a distinguir un agente de comercio aprobado de un rastreador común, un bot abusivo o una automatización desconocida. Un agente firma una solicitud con credenciales con límite de tiempo y propósito específico. El comerciante o su proveedor de protección verifica la firma y puede decidir si permite la navegación, el pago o una acción más limitada.

TAP describe tres señales relacionadas: una firma de reconocimiento de agente, una identidad de consumidor o dispositivo vinculada y firmada, y un contenedor de pago vinculado y firmado. Esta es una separación útil. El reconocimiento de agente establece qué agente aprobado está presente; la intención firmada establece qué tipo de interacción se solicita; la señal del consumidor puede ayudar a un comerciante a reconocer a un cliente existente.

Esa señal de consumidor no es automáticamente equivalente a una nueva prueba de identidad. El modelo de Visa incluye una función de proveedor de identidad en la parte superior, pero un comerciante aún necesita una política para un cliente nuevo o de alto riesgo: qué evidencia se verificó, qué tan fuerte es la garantía, si se requiere KYC y cuándo es necesaria la reverificación. TAP puede llevar información de identidad confiable sin prescribir cada decisión de incorporación jurisdiccional.

Google AP2: ¿qué autorizó el usuario al agente a comprar?

Google Agent Payments Protocol se centra en la autorización y la evidencia. Utiliza mandatos firmados para conectar la intención del usuario, el contenido del carrito y el pago. Un mandato abierto puede otorgar a un agente discreción limitada, como restricciones de comerciante o límites de gasto. Un mandato cerrado vincula la aprobación a un carrito y un monto específicos. Los recibos completan la cadena de evidencia.

AP2 distingue los flujos con presencia humana y sin presencia humana. Cuando la persona está presente, puede aprobar directamente un mandato de pago y de compra cerrado. Cuando está ausente, el agente opera dentro de las restricciones previamente aprobadas y firma los mandatos cerrados finales. Un comerciante o proveedor de credenciales aún puede volver a involucrar a la persona cuando no se puede resolver una restricción.

Este diseño responde a la pregunta “¿Esta persona autorizó esta acción bajo estas condiciones?” de manera más directa que a “¿Cómo se verificó originalmente a esta persona?”. El marco de autorización de AP2 asume que existen las credenciales de inscripción y de usuario relevantes. Por lo tanto, un desarrollador aún necesita un proceso de prueba de identidad y ciclo de vida de las credenciales antes de que esos mandatos puedan ofrecer una garantía significativa.

Mastercard Agent Pay: ¿puede la red reconocer y gobernar un pago agéntico?

Mastercard Agent Pay se basa en la tokenización de pagos. El marco de aceptación de Mastercard registra y verifica agentes, asigna una identidad de agente única y utiliza Agentic Tokens para que las transacciones sean rastreables y las credenciales de pago permanezcan protegidas. El reconocimiento orientado al comerciante puede funcionar con la infraestructura de pago existente, mientras que las integraciones más profundas admiten un intercambio de datos más rico.

El modelo también enfatiza el consentimiento del consumidor, la autenticación y la capacidad de los emisores, adquirentes y comerciantes para reconocer que un agente participó. Esto hace que la actividad del agente sea visible dentro de un modelo de riesgo de red de tarjetas familiar en lugar de hacer que la automatización sea indistinguible de una solicitud normal de tarjeta no presente.

Agent Pay es más fuerte en seguridad de credenciales de pago, visibilidad de agentes y controles de red. No elimina la obligación de un comerciante de decidir cuándo se aplica la verificación de identidad, Know Your Business (KYB), el cribado Anti-Money Laundering (AML), las verificaciones de edad o la revisión mejorada. Esas decisiones dependen del producto, el cliente, la transacción y la jurisdicción, no solo de la vía de pago.

Dónde se superponen los estándares y dónde sigue encajando la identidad

Los tres enfoques intentan hacer que el comercio delegado sea legible. Un comerciante debería poder saber que hay automatización involucrada, verificar que el agente es de confianza, conectar la acción con la intención del usuario, restringir la compra y conservar la evidencia. Su énfasis difiere:

• TAP: reconocimiento de agentes e intención firmada en el límite del comerciante, con señales opcionales de consumidor y pago vinculadas.
• AP2: artefactos de autorización criptográfica que vinculan la intención del usuario con los resultados de la compra y el pago.
• Agent Pay: agentes registrados, credenciales de pago tokenizadas, consentimiento, autenticación y visibilidad en toda la red de tarjetas.

La prueba de identidad se sitúa antes y al lado de estos controles. Una autorización firmada solo es valiosa si la credencial pertenece a la persona correcta. Un agente aprobado aún puede ser instruido por una cuenta sintética, robada, sancionada, menor de edad o inelegible. Un token puede proteger las credenciales de pago sin establecer que un vendedor del mercado o beneficiario de la empresa pasó la debida diligencia requerida.

La identidad del agente responde “¿qué software actuó?”. La autorización responde “¿qué se le permitió hacer?”. La verificación de identidad responde “¿quién está detrás?”. Los controles de fraude y cumplimiento responden “¿debe proceder esta acción?”.

Lo que los desarrolladores deben construir independientemente de qué enfoque gane

• Inscripción y verificación. Verifique a la persona o empresa antes de otorgar una credencial reutilizable o una autoridad de gasto delegada. Aplique verificaciones KYC, KYB, de vivacidad, de documentos, de bases de datos o biométricas según el riesgo.
• Vinculación de credenciales. Vincule al sujeto verificado a una cuenta, dispositivo, clave de acceso, billetera u otra credencial que pueda participar en el flujo agéntico.
• Autorización con alcance. Capture límites como comerciante, categoría, monto, frecuencia, vencimiento y si un humano debe regresar para su aprobación.
• Decisiones de riesgo en tiempo de ejecución. Examine a la persona, empresa, billetera y transacción en el momento de la acción. Los controles Know Your Transaction (KYT) y las verificaciones AML siguen siendo relevantes incluso cuando la intención está firmada.
• Revocación y recuperación. Detenga la autoridad delegada cuando una credencial se vea comprometida, el usuario retire el consentimiento o cambie el riesgo.
• Auditabilidad. Conserve el resultado de la verificación, el artefacto de autorización, la identidad del agente, la decisión de la transacción, las marcas de tiempo y las acciones de revisión posteriores como evidencia separada.

Este diseño en capas es deliberadamente neutral en cuanto a estándares. Un equipo puede adoptar TAP en el borde del comerciante, mandatos AP2 en un flujo de trabajo de agente, Agent Pay para la liquidación de tarjetas o una combinación. La decisión de identidad y fraude sigue siendo portátil porque no está incrustada en una única red de pago.

Cómo Didit cubre la mitad de la identidad hoy

Didit proporciona infraestructura para identidad y fraude utilizada por más de 2,000 empresas en producción. Las mismas capacidades están disponibles a través de un servidor MCP alojado para operaciones impulsadas por agentes y una API REST para flujos controlados por aplicaciones. Para una visión general de la arquitectura más amplia, consulte cómo un servidor MCP maneja la verificación de identidad y cómo MCP conecta las verificaciones de identidad y fraude para agentes de IA.

El punto final del MCP alojado es https://mcp.didit.me/mcp. Utiliza Streamable Hypertext Transfer Protocol (HTTP), con Open Authorization (OAuth) 2.1, Proof Key for Code Exchange (PKCE) y Dynamic Client Registration. Un usuario inicia sesión a través de la Consola de Negocios de Didit y otorga acceso con alcance; el punto final del MCP alojado no utiliza autenticación con clave API.

Después de la autorización, un agente puede llamar a 115 herramientas en 11 categorías. Una secuencia de verificación práctica puede usar:

didit_context_get
didit_session_create
didit_verify_id
didit_verify_passive_liveness
didit_verify_face_match
didit_session_get_decision

Esas herramientas pueden crear una sesión de verificación, ejecutar las verificaciones seleccionadas y recuperar una decisión estructurada. Otras herramientas reales incluyen didit_verify_aml, didit_verify_kyb_search, didit_verify_kyb_select y didit_transaction_screen_wallet. Las escrituras de alta consecuencia siguen sujetas a los permisos y el comportamiento de confirmación del usuario conectado.

La API REST cubre la ruta de la aplicación: cree sesiones desde su backend, envíe a los usuarios a través de la verificación alojada o incrustada, consuma webhooks y almacene decisiones en su propio sistema. Las solicitudes de servidor a servidor REST utilizan un encabezado x-api-key; esto es independiente de la conexión MCP alojada autenticada con OAuth. Lea la descripción general de MCP, la guía de autenticación y la referencia de herramientas para obtener detalles de implementación.

El precio es independiente del estándar de pago agéntico. El servidor MCP es gratuito. Un paquete completo de KYC (Verificación de Identidad, Detección de Vida Pasiva, Coincidencia Facial y Análisis de IP) cuesta $0.33, y cada cuenta incluye 500 verificaciones gratuitas al mes.

Una ruta de implementación neutral en cuanto a estándares

Comience por definir la garantía requerida para cada acción, no eligiendo un logotipo de red. La navegación de bajo riesgo puede necesitar solo reconocimiento de agente. La creación de cuentas puede requerir identidad verificada. Una compra regulada puede requerir KYC o KYB más cribado AML. Una transferencia de criptomonedas puede agregar cribado de billetera. Montos más altos o un riesgo cambiado pueden devolver al humano al ciclo.

Luego, conecte el artefacto de pago a la decisión de identidad con identificadores internos estables. Mantenga la firma del agente, la autorización del usuario, la evidencia de verificación y el resultado del pago distintos para que cada uno pueda ser revocado, revisado y actualizado de forma independiente a medida que evolucionan los estándares.

Explore la página de desarrolladores de Didit MCP o inspeccione el repositorio público de GitHub con licencia permisiva. Los usuarios de Claude pueden agregar el conector de Didit y completar el inicio de sesión de OAuth.

La arquitectura duradera está en capas: los estándares de pago prueban la participación y autorización del agente; la infraestructura de identidad y fraude prueba quién está involucrado y si la acción es aceptable. Esa división permite a los desarrolladores admitir los estándares actuales sin codificar la confianza a uno solo.