Toda la infraestructura de pagos digitales existente — tarjetas de crédito, pasarelas, protocolos de autorización — fue construida sobre una premisa fundamental: hay un humano presionando el botón de «Comprar». Ese humano tiene identidad verificable, capacidad legal para contratar y, en última instancia, la responsabilidad sobre la transacción.
Con la proliferación de agentes de inteligencia artificial capaces de navegar, negociar y ejecutar compras de forma autónoma, esa premisa se rompe por completo. Un agente de IA puede iniciar una transacción, elegir un producto, seleccionar un método de pago y completar el checkout sin que el usuario toque nada. Y eso genera tres preguntas críticas que los rails de pago tradicionales no pueden responder:
- Autorización: ¿Cómo verificamos que el usuario autorizó explícitamente esta compra específica, ejecutada por este agente específico?
- Autenticidad: ¿Cómo puede el comerciante estar seguro de que la solicitud del agente refleja fielmente la intención del usuario y no un error de inferencia o una alucinación del LLM?
- Accountability: Si ocurre una transacción fraudulenta o incorrecta, ¿quién responde? ¿El usuario, el desarrollador del agente, el comerciante, el emisor, el PSP o la capa de orquestación?
Esta ambigüedad crea una crisis de confianza que podría limitar seriamente la adopción del comercio agéntico. Sin un protocolo común, el ecosistema se fragmenta en soluciones propietarias incompatibles, confusas para los usuarios, costosas para los merchants y prácticamente imposibles de auditar para las instituciones financieras.
Ahí entra el Agent Payment Protocol (AP2).
¿Qué es el Agent Payment Protocol (AP2)?
El Agent Payment Protocol (AP2) es un protocolo abierto lanzado por Google el 16 de septiembre de 2025, desarrollado en conjunto con más de 60 organizaciones del ecosistema de pagos y tecnología: PayPal, Mastercard, American Express, Adyen, Coinbase, Salesforce, ServiceNow, Worldpay, JCB, UnionPay International y Etsy, entre otras.
Su objetivo es proporcionar un framework agnóstico al método de pago que permita a usuarios, comerciantes y proveedores de servicios de pago realizar transacciones con confianza cuando el iniciador es un agente de IA autónomo. AP2 no reinventa los rails de pago: se posiciona como una capa de autorización y trazabilidad por encima de los sistemas existentes.
Técnicamente, AP2 funciona como una extensión del protocolo Agent2Agent (A2A) y del Model Context Protocol (MCP). Si A2A permite que los agentes se comuniquen entre sí, AP2 les da la capacidad de transaccionar de forma segura y verificable.
«AP2 is an open protocol that gives an AI agent a verifiable, cryptographically signed permission slip from a human before it can spend money on that human’s behalf.»
Arquitectura técnica: los cinco roles de AP2
La especificación AP2 v0.2 define cinco roles con responsabilidades diferenciadas en el proceso de una transacción agéntica:
1. Shopping Agent (SA)
Es el agente principal que ejecuta el flujo de compra: descubrimiento de productos, construcción del carrito y ejecución del pago. Se lo considera el rol inherentemente agéntico del protocolo — opera con un LLM no determinístico y, por tanto, es el principal vector de riesgo que AP2 busca contener.
2. Credential Provider (CP)
Es la fuente de credenciales de pago (por ejemplo, PayPal actuando como wallet). Verifica que el Shopping Agent está autorizado a acceder a ese instrumento de pago y emite la Payment Mandate con el scope correcto. Puede ser agéntico o no agéntico.
3. Merchant (M)
Responsable de proveer y completar el checkout. Verifica que el Shopping Agent tiene aprobación para comprar los ítems específicos del carrito y es responsable de la integridad del inventario, precios y descuentos. También puede ser agéntico.
4. Merchant Payment Processor (MPP)
Procesa el pago efectivo. Verifica que la credencial de pago entregada por el Credential Provider está autorizada para pagar ese checkout específico. Es quien ejecuta el cargo contra los rails de pago tradicionales (tarjetas, real-time payments, stablecoins vía x402).
5. Trusted Surface (TS)
Es la única interfaz de usuario de confianza que puede capturar el consentimiento informado del usuario antes de emitir un mandato firmado. Este rol DEBE ser no agéntico según la especificación: ningún LLM puede estar en el camino entre el usuario y la firma del mandato. Generalmente es la app del usuario (Google Wallet, app del banco, etc.).
El mecanismo central: Verifiable Digital Credentials (VDCs) y Mandatos
AP2 ingenieriza la confianza mediante Verifiable Digital Credentials (VDCs): objetos digitales criptográficamente firmados y a prueba de manipulaciones que siguen el formato W3C Verifiable Credentials. Cada mandato es un VDC que actúa como prueba no repudiable de intención.
El protocolo define dos tipos principales de mandatos, cada uno con dos estados posibles:
Checkout Mandate
Captura qué se está comprando y es compartido con el Merchant.
- Open (Abierto): Registra las restricciones y objetivos del usuario para la transacción antes de que se finalice un carrito específico. Es el punto de partida de la autorización autónoma — el usuario define límites (no gastar más de $X, solo de estas tiendas) sin conocer aún el producto exacto.
- Closed (Cerrado): Captura la autorización del usuario (o del agente, dentro del scope autorizado) para un checkout específico y finalizado. Es el mandato que el Merchant verifica antes de confirmar la orden.
Payment Mandate
Autoriza el pago contra un instrumento de pago específico. Es compartido con el Credential Provider, las redes de pago y el Merchant Payment Processor.
- Open (Abierto): Registra las restricciones del usuario sobre el pago (presupuesto máximo, instrumentos permitidos) para ejecución autónoma.
- Closed (Cerrado): Captura la autorización para un monto específico vinculado a un checkout finalizado. Es el mandato que el MPP valida antes de ejecutar el cargo.
Estos VDCs se encadenan entre sí formando un audit trail criptográfico completo de la transacción. En caso de disputa, cualquier participante puede presentar la cadena de mandatos como evidencia verificable.
Flujos de pago: Human Present vs. Human Not Present
AP2 define dos modos de operación que reflejan el nivel de involucramiento del usuario en tiempo real:
Direct / Human Present
El usuario está activo en la sesión. El agente propone el carrito y el usuario confirma en la Trusted Surface antes de que se emita el Checkout Mandate Closed. Este flujo es conceptualmente similar al checkout tradicional, pero con la capa de autorización agéntica interpuesta. Es el modo recomendado para implementaciones iniciales.
Autonomous / Human Not Present
El agente opera de forma completamente autónoma dentro de los límites predefinidos por el usuario mediante mandatos abiertos. No hay intervención humana en tiempo real. Este es el flujo que habilita casos de uso como reabastecimiento automático, compras recurrentes optimizadas o agentes de negociación B2B.
En el modo autónomo, la especificación introduce el concepto de Agent-to-Agent Delegation: un agente orquestador puede delegar responsabilidades a sub-agentes, siempre que cada delegación esté encadenada en la firma criptográfica. La cadena de custodia no se rompe.
Relación con A2A, MCP y x402
AP2 no existe en el vacío. Se integra en un stack de protocolos agénticos que conviene entender en conjunto:
- MCP (Model Context Protocol): Permite al agente acceder a herramientas y datos externos (catálogos de productos, inventario, historial del usuario). AP2 puede viajar como payload dentro de mensajes MCP.
- A2A (Agent2Agent Protocol): Define cómo los agentes se descubren entre sí y se comunican. AP2 extiende A2A añadiendo la capa de autorización de pagos. Un Shopping Agent se comunica con el Merchant Agent vía A2A; el Payment Mandate viaja dentro de esa comunicación.
- x402 (Coinbase): Rail de liquidación en stablecoins desarrollado por Coinbase. AP2 soporta x402 como carril de pago alternativo a las tarjetas tradicionales, habilitando pagos programáticos 24/7 sin dependencia de los horarios de compensación bancaria.
- UCP (Universal Commerce Protocol): Define la forma completa del checkout end-to-end: descubrimiento, configuración, ensamblado del carrito, finalización. AP2 y UCP se integran de forma nativa; AP2 actúa como la capa de seguridad dentro del flujo UCP.
El stack completo se puede resumir así:
Usuario
└── Trusted Surface (firma mandatos)
└── Shopping Agent (opera via ADK / cualquier framework)
├── MCP (acceso a herramientas y catálogos)
├── A2A (comunicación con Merchant Agent)
└── AP2 (autorización y mandatos de pago)
├── Checkout Mandate → Merchant
└── Payment Mandate → Credential Provider → MPP
├── Rails tradicionales (tarjetas)
└── x402 (stablecoins via Coinbase)
Verificación y modelo de confianza por rol
Una de las partes más críticas de la especificación AP2 es definir quién verifica qué. Las responsabilidades de verificación se distribuyen así:
Merchant
Verifica el Checkout Mandate Closed: que la firma es válida, que los ítems del carrito corresponden exactamente a lo autorizado, y que el agente tiene permiso para operar en nombre del usuario para esa categoría de compra.
Credential Provider y Network
Verifican el Payment Mandate Open y Closed: que el usuario autorizó el uso de ese instrumento de pago, que los límites de gasto no han sido excedidos, y que el Shopping Agent está dentro del scope delegado.
Merchant Payment Processor
Verifica la coherencia entre el Checkout Mandate Closed y el Payment Mandate Closed: que el monto a cobrar coincide con lo autorizado, y que la credencial de pago es legítima y no ha sido reutilizada.
Dispute Resolution
Cuando hay una disputa, la cadena completa de mandatos VDC actúa como evidencia criptográficamente verificable. Cualquier participante puede demostrar que actuó dentro de los límites autorizados (o que otro participante no lo hizo) sin depender de logs centralizados de terceros.
Caso concreto: PayPal + Google Cloud Conversational Commerce Agent
El ejemplo más tangible de AP2 en producción es el Conversational Commerce Agent, lanzado por PayPal y Google Cloud el 27 de octubre de 2025. El flujo técnico es el siguiente:
- Un merchant despliega un agente construido sobre el Agent Development Kit (ADK) de Google.
- El agente usa MCP servers para leer el catálogo de productos e inventario del merchant.
- Usa A2A para comunicarse con el PayPal Agent del usuario.
- Cuando el usuario confirma el carrito, los mandatos AP2 transportan la autorización entre el usuario, el merchant agent y el PayPal Credential Provider.
- PayPal actúa simultáneamente como Credential Provider y como MPP, ejecutando el cargo sobre los rails de PayPal.
Desde la perspectiva del usuario, es una conversación única. Por debajo, son cuatro protocolos (MCP, A2A, AP2, UCP) ejecutándose en coordinación.
Estado actual y roadmap (AP2 v0.2)
AP2 se encuentra en versión 0.2, con la especificación pública disponible en ap2-protocol.org y el código de referencia en el repositorio oficial de GitHub bajo la organización google-agentic-commerce.
El soporte actual cubre pagos pull con tarjetas de crédito y débito (el modelo tradicional). El roadmap incluye:
- E-wallets y pagos push (transferencias bancarias en tiempo real como UPI y PIX)
- Monedas digitales y stablecoins (ya parcialmente implementado vía x402)
- Expansión de los puntos de extensión del protocolo para nuevos tipos de Verifiable Digital Credentials
- Integración con estándares de la FIDO Alliance para autenticación de agentes de IA (anunciado en noviembre 2025)
Al momento de la coalición inicial había más de 60 organizaciones endosando AP2; para finales de octubre de 2025 esa cifra superaba las 100.
Implementación para desarrolladores: puntos de entrada
Si estás evaluando implementar AP2 en un proyecto, estos son los componentes clave:
SDK y tipos core
Los esquemas JSON-LD de los mandatos, las primitivas de firma y la lógica de composición están disponibles en el SDK oficial. Las muestras utilizan el ADK de Google y Gemini Flash Lite Preview, pero el protocolo no requiere esos tools: cualquier framework de agentes compatible puede implementar AP2.
Samples disponibles
- Human Present Cards: Transacción con intervención humana usando tarjetas tradicionales (Python + A2A).
- Human Present x402: Ídem con stablecoins vía Coinbase x402.
- Human Not Present Cards: Transacción autónoma con tarjetas.
- Human Not Present x402: Transacción autónoma con x402.
- Digital Payment Credentials Android: Implementación en Android con Google Wallet como Trusted Surface.
Consideraciones de seguridad críticas
La especificación aclara que cuando la comunicación involucra un rol agéntico, los mecanismos estándar de seguridad web no son suficientes. El agente en sí es un potencial vector de ataque (prompt injection, manipulación del contexto). Por eso, toda verificación y procesamiento de mandatos debe ocurrir en código determinístico, independientemente de si el rol es agéntico o no.
Reflexión final: AP2 como infraestructura crítica del comercio agéntico
El Agent Payment Protocol no es solo una especificación técnica. Es la respuesta a una pregunta que la industria inevitablemente tenía que enfrentar: ¿cómo se transfiere dinero cuando no hay humano en el loop?
La solución de AP2 es elegante en su principio: en lugar de intentar «autenticar al agente» (un problema casi insoluble con LLMs no determinísticos), ancla la confianza en el usuario mediante mandatos criptográficamente firmados en una Trusted Surface no agéntica. El agente puede actuar dentro de esos límites con total autonomía; cualquier desviación queda evidenciada en el audit trail.
Para desarrolladores que trabajamos con stacks agénticos, integrar AP2 va a ser tan fundamental como conocer OAuth2 lo fue para el desarrollo web de los últimos 15 años. Vale la pena familiarizarse con la especificación ahora, mientras el ecosistema todavía está tomando forma.
El repo oficial está en github.com/google-agentic-commerce/AP2 y la documentación completa en ap2-protocol.org.
