Su agente de compras compra automáticamente un plan profesional de $ 499 en lugar del nivel básico de $ 49, ¿quién está en el gancho: el usuario, el desarrollador del agente o el comerciante? Esta brecha de fideicomiso es un bloqueador principal para el pago dirigido por agentes en los rieles de pago de hoy. Protocolo de pagos del agente de Google (AP2) Lo aborda con una especificación abierta e interoperable para pagos iniciados por el agente, definiendo un lenguaje común criptográficamente verificable para que cualquier agente compatible pueda realizar transacciones con cualquier comerciante compatible a nivel mundial.
El Protocolo de pagos del agente de Google (AP2) es una especificación abierta y neutral de proveedores para ejecutar pagos iniciados por agentes de IA con prueba criptográfica y auditable de intención del usuario. AP2 extiende los protocolos abiertos existentes (Agent2Agent (A2A) y el Protocolo de contexto del modelo (MCP)) para definir cómo los agentes, comerciantes y procesadores de pagos intercambian evidencia verificable en la tubería de “intención → CART → Pago”. El objetivo es cerrar la brecha de confianza en el comercio dirigido por agentes sin fragmentar el ecosistema de pagos.
¿Por qué los agentes necesitan un protocolo de pagos?
Los rieles de hoy suponen que un humano es el único que hace clic en “Comprar” en una superficie confiable. Cuando un agente autónomo o semiautónomo inicia la pago, los comerciantes y los emisores enfrentan tres preguntas no resueltas: (1) fue la autoridad del usuario realmente delegada (autorización), (2) la solicitud refleja lo que el usuario quiso y aprobó (autenticidad) y (3) quién es responsable si algo sale mal (responsabilidad). AP2 formaliza los datos, la criptografía y la mensajería para responder esas preguntas de manera consistente entre los proveedores y los tipos de pago.
¿Cómo establece AP2 la confianza?
AP2 usa Credenciales verificables (VCS)—Enpectores digitales firmados criptográficamente firmados y criptográficamente para llevar evidencia a través de una transacción. El protocolo estandariza tres tipos de mandatos:
- Mandato de intención (humano-no presente): captura las restricciones bajo las cuales un agente puede realizar transacciones (por ejemplo, marca/categoría, límites de precio, ventanas de sincronización), firmadas por el usuario.
- Mandato de carro (presente humano): vincula la aprobación explícita del usuario a un carrito firmado (artículos, montos, moneda), produciendo pruebas no repudiables de “lo que vio es lo que pagó”.
- Mandato de pago: transmite a las redes/emisores que un agente de IA participó, incluida la modalidad (-presente humano frente a no presente) y el contexto relevante para el riesgo.
Estos VC forman una pista de auditoría que vincula inequívocamente la autorización del usuario con la solicitud de carga final.
¿Cuáles son los roles centrales y los límites de confianza?
AP2 define una arquitectura basada en roles para separar las preocupaciones y minimizar la exposición a los datos:
- Usuario Delega una tarea a un agente.
- Usuario/agente de compras (La interfaz con la que el usuario interactúa) interpreta la tarea, negocia carros y recopila aprobaciones.
- Proveedor de credenciales (por ejemplo, billetera) posee métodos de pago y problemas de artefactos específicos del método.
- Punto final comercial Expone el catálogo/cotización y firma carros.
- Procesador de pagos comerciales Construye el objeto de autorización de red.
- Red y emisor evaluar y autorizar el pago.
Presente humano vs humano-no presente: ¿qué cambios en el cable?
AP2 define flujos claros y comprobables:
- Presente humano: El comerciante firma un carrito final; El usuario lo aprueba en una interfaz de usuario confiable, generando una firmada Mandato de carro. El procesador presenta la autorización de la red junto con el Mandato de pago. Si es necesario, el paso hacia arriba (por ejemplo, 3DS) ocurre en una superficie confiable.
- Humano no presente: el usuario pre-autoriza un Mandato de intención (por ejemplo, “Comprar cuando el precio <$ 100"); El agente luego lo convierte en un mandato de carro cuando se cumplen las condiciones, o el comerciante puede forzar la reconfirmación.
¿Cómo se compone AP2 con A2A y MCP?
AP2 se especifica como un extensión a A2A (para mensajes entre agentes) e introduce con MCP (para el acceso a la herramienta) para que los desarrolladores puedan reutilizar las capacidades establecidas para el descubrimiento, la negociación y la ejecución. AP2 especializa la capa de pagos, estandarización de objetos de mandato, firmas y señales de responsabilidad), al tiempo que deja la colaboración y la invocación de herramientas a A2A/MCP.
¿Qué métodos de pago están en alcance?
El protocolo es Agnóstico de método de pago. El enfoque inicial cubre instrumentos comunes basados en pull (tarjetas de crédito/débito), con soporte de hoja de ruta para transferencias de empuje en tiempo real (por ejemplo, UPI, PIX) y activos digitales. Para la ruta web3, Google y los socios han lanzado un Extensión A2A X402 Para operacionalizar los pagos criptográficos iniciados por el agente, alineando X402 con las construcciones de mandatos de AP2.
¿Cómo se ve esto para los desarrolladores?
Google ha publicado un repositorio público (Apache-2.0) con documentación de referencia, tipos de Python y muestras ejecutables:
- Muestras Demuestre flujos de tarjeta de presente humano, una variante X402 y credenciales de pago digital de Android, que muestran cómo emitir/verificar los mandatos y pasar de la negociación de agentes a la autorización de la red.
- Paquete de tipos: Los objetos de protocolo de núcleo están disponibles en
src/ap2/typespara integración. - Elección del marco: Si bien las muestras usan el ADK y Gemini 2.5 Flash de Google, AP2 es de marco-Agnóstico; Cualquier pila de agentes puede generar/verificar mandatos y hablar el protocolo.
¿Cómo aborda AP2 la privacidad y la seguridad?
La separación de roles de AP2 garantiza datos confidenciales (por ejemplo, sartenes, tokens) permanece con el proveedor de credenciales y nunca necesita fluir a través de superficies de agentes de uso general. Los mandatos están firmados con identidades verificables y pueden integrar señales de riesgo sin exponer las credenciales completas a las contrapartes. Esto se alinea con los controles existentes (por ejemplo, autenticación de paso arriba) y proporciona a las redes marcadores explícitos de participación de agentes para respaldar la lógica de riesgo y disputas.
¿Qué pasa con la preparación del ecosistema?
Google cita colaboración con Más de 60 organizacionesque abarcan redes, emisores, puertas de enlace y proveedores de tecnología (por ejemplo, American Express, MasterCard, PayPal, Coinbase, Intuit, ServiceNow, UnionPay International, WorldPay, Adyen). El objetivo es evitar integraciones únicas alinearse en las señales de semántica y responsabilidad del mandato común en todas las plataformas.
Notas de implementación y casos de borde
- Determinismo sobre inferencia: Los comerciantes reciben evidencia criptográfica de lo que el usuario aprobó (CART) o pre-autorizado (intención), en lugar de resúmenes generados por el modelo.
- Disputas: La cadena de credenciales funciona como material probatorio para redes/emisores; La rendición de cuentas se puede asignar en función de qué mandato fue firmado y por quién.
- Desafíos: El emisor o comerciante puede activar un paso adelante; AP2 requiere que se completen los desafíos en superficies confiables y vinculados al sendero del mandato.
- Múltiples agentes: Cuando participa más de un agente (por ejemplo, Travel MetaSearch + Airline + Hotel), A2A coordina las tareas; AP2 asegura que cada carro está firmado y autorizado por el usuario antes de la presentación del pago.
¿Qué viene después?
El equipo de AP2 planea evolucionar la especificación en la apertura y continuar agregando implementaciones de referencia, incluidas integraciones más profundas en redes y Web3, y la alineación con cuerpos de estándares para formatos de VC y primitivas de identidad. Los desarrolladores pueden comenzar hoy ejecutando los escenarios de muestra, integrando tipos de mandatos y validando flujos contra sus pilas de agentes/comerciantes.
Resumen
AP2 le da al ecosistema del agente una forma concreta y criptográfica fundamentada para probar la autorización del usuario, vincularlo a los carros firmados con comerciantes y los emisores actuales con un registro auditable, sin bloquear a los desarrolladores en una sola pila o método de pago. Si los agentes van a comprar cosas en nuestro nombre, este es el tipo de evidencia que el sistema de pagos necesita.
Mira el Página de Github, Página del proyecto y Detalle técnico. No dude en ver nuestro Página de Github para tutoriales, códigos y cuadernos. Además, siéntete libre de seguirnos Gorjeo Y no olvides unirte a nuestro Subreddit de 100k+ ml y suscribirse a Nuestro boletín.
Asif Razzaq es el CEO de MarktechPost Media Inc .. Como empresario e ingeniero visionario, ASIF se compromete a aprovechar el potencial de la inteligencia artificial para el bien social. Su esfuerzo más reciente es el lanzamiento de una plataforma de medios de inteligencia artificial, MarktechPost, que se destaca por su cobertura profunda de noticias de aprendizaje automático y de aprendizaje profundo que es técnicamente sólido y fácilmente comprensible por una audiencia amplia. La plataforma cuenta con más de 2 millones de vistas mensuales, ilustrando su popularidad entre el público.