AP2 frente a x402: cómo gestionan los agentes de IA la autorización de pagos y la liquidación automatizada

AP2 (protocolo de pagos de agentes) y x402 son dos protocolos de pago diseñados para el comercio de agentes de IA. Proporcionan infraestructura para transacciones autónomas desde las perspectivas de la autorización de pagos y la liquidación programática, respectivamente. AP2 se centra en demostrar que la compra de un agente de IA ha sido autorizada por el usuario, mientras que x402 utiliza interacciones de pago HTTP estandarizadas para permitir que los sistemas de software adquieran API, datos y otros servicios digitales bajo demanda.

A medida que el comercio entre agentes continúa desarrollándose, los agentes de IA están evolucionando de herramientas de búsqueda de información a sistemas automatizados capaces de realizar compras, gestionar suscripciones y llamar a servicios. Cuando un agente empieza a utilizar fondos en nombre de un usuario o una empresa, los procesos de pago tradicionales que dependen de clics y confirmaciones manuales afrontan nuevos desafíos: ¿cómo puede determinar el sistema si el agente está autorizado a realizar un pago? ¿Cómo se puede limitar el importe del pago? ¿Cómo pueden distintos sistemas completar la liquidación automáticamente?

AP2 y x402 ofrecen dos enfoques complementarios. Este artículo presenta los mecanismos principales, las diferencias técnicas y los flujos de trabajo colaborativos de ambos protocolos, analiza el papel de las stablecoins en los pagos de agentes de IA y explora los riesgos de seguridad y cumplimiento que pueden implicar las transacciones automatizadas.

Puntos clave:

• AP2 (protocolo de pagos de agentes) es un protocolo abierto para la autorización de pagos de agentes de IA. Se centra en determinar si un agente puede realizar pagos en nombre de un usuario y cómo verificar que una transacción refleja la intención del usuario.
• x402 es un protocolo de pago programático basado en el código de estado HTTP 402 Payment Required. Permite que los agentes de IA paguen automáticamente por API y servicios digitales según los requisitos de pago devueltos por el servidor.
• AP2 y x402 abordan capas diferentes: AP2 se centra en la autorización y la verificación de responsabilidad, mientras que x402 se centra en las solicitudes de pago, la verificación de credenciales y la liquidación. Los dos protocolos pueden utilizarse conjuntamente.
• Las stablecoins proporcionan a los agentes de IA una forma programable de pago digital. Son adecuadas para API de pago por uso, servicios de datos y transacciones entre máquinas, pero no son necesarias para todos los escenarios de pago de agentes.
• Los pagos automáticos de agentes de IA siguen requiriendo límites presupuestarios, controles de permisos de billetera, verificación de contrapartes y gestión de transacciones anómalas. La ejecución automatizada no debe tratarse como una autorización ilimitada para utilizar fondos.

¿Qué son AP2 y x402? ¿Por qué los agentes de IA necesitan protocolos de pago específicos?

Tanto AP2 como x402 permiten el comercio automatizado de agentes de IA, pero resuelven problemas distintos. AP2 fue lanzado en septiembre de 2025 por Google junto con participantes de los sectores de pagos y tecnología. Su objetivo es establecer un marco multiplataforma e independiente del método de pago para la autorización de pagos de agentes. Se centra en demostrar que un usuario ha autorizado a un agente a realizar una compra específica y en permitir que las instituciones de pago verifiquen dicha autorización.

Por su parte, x402 fue impulsado por Coinbase y se basa en el código de estado 402 Payment Required del protocolo HTTP. Permite que sitios web, API y otros servicios digitales envíen requisitos de pago directamente a los clientes. Tras recibir la información de pago, un agente de IA puede utilizar una billetera controlada para generar credenciales de pago y acceder al recurso correspondiente una vez completadas la verificación y la liquidación.

La aparición de estos dos protocolos refleja dos desafíos distintos en el comercio de agentes de IA. En primer lugar, un agente puede descubrir productos y servicios de forma autónoma, pero debe demostrar que ha recibido autorización del usuario. En segundo lugar, incluso si un agente dispone de permiso para pagar, sigue necesitando una forma de interactuar con servicios externos y completar pagos automáticamente.

Los sistemas de pago en línea tradicionales suelen asumir que los consumidores revisarán personalmente los productos, harán clic para confirmar y completarán la verificación de identidad. Sin embargo, un agente de IA puede ejecutar tareas sin la participación del usuario en tiempo real. Por tanto, los sistemas de pago deben determinar no solo si una transacción es válida, sino también si el comportamiento del agente cumple los permisos predefinidos.

AP2 y x402 proporcionan soporte técnico para estas dos etapas, respectivamente, pero no todos los pagos de agentes de IA requieren ambos protocolos.

¿Cómo verifica AP2 la autorización de pago de un agente de IA?

El núcleo de AP2 es el Mandate, una credencial de autorización verificable criptográficamente. Registra las acciones que un usuario ha permitido realizar a un agente y las restricciones aplicables, lo que permite a comerciantes y proveedores de servicios de pago determinar si una transacción refleja la intención del usuario.

Según la especificación técnica AP2 v0.2, el protocolo define dos tipos principales de credenciales: Checkout Mandate y Payment Mandate. Un Checkout Mandate demuestra que un agente ha sido autorizado a comprar un producto o servicio específico. Un Payment Mandate demuestra que el agente puede iniciar el pago del pedido correspondiente. Ambos están vinculados mediante la información del pedido, lo que reduce el riesgo de que una credencial de pago se utilice para otra transacción.

Por ejemplo, supongamos que un usuario quiere que un agente de IA compre un servicio de datos con un precio máximo de 50 $. El sistema puede registrar la categoría del producto, el presupuesto y las condiciones de autorización en las credenciales correspondientes. Después de que el agente encuentre un servicio que cumpla los requisitos, el comerciante verifica la autorización de compra y el proveedor de servicios de pago verifica después la autorización de pago. La transacción solo debe avanzar a la siguiente etapa de pago cuando se cumplan las condiciones pertinentes.

AP2 también distingue entre los modos de transacción Human Present y Human Not Present. En el primero, el usuario puede confirmar el pedido específico durante el proceso de pago. En el segundo, el agente puede ejecutar la transacción dentro de las restricciones autorizadas previamente. En ambos modos, las comprobaciones de autorización clave deben completarse mediante procesos deterministas, en lugar de depender únicamente del criterio de un modelo de lenguaje de gran tamaño.

Por tanto, AP2 no pretende sustituir las tarjetas bancarias, las cuentas bancarias ni las stablecoins. Su valor reside en establecer una base de autorización verificable para diferentes métodos de pago y proporcionar registros para auditorías posteriores y la resolución de disputas.

¿Cómo permite x402 los pagos automatizados mediante HTTP 402?

La idea central de x402 es incorporar el proceso de pago directamente en las solicitudes HTTP. Los servicios de API tradicionales suelen requerir que los usuarios registren una cuenta, vinculen un método de pago o compren créditos de suscripción por adelantado. x402 permite que un servidor devuelva requisitos de pago estandarizados al recibir una solicitud, tras lo cual el cliente completa el pago y vuelve a solicitar el recurso.

Según el protocolo oficial x402, el proceso típico comienza cuando un cliente envía una solicitud HTTP a un servidor de recursos. Si el recurso requiere pago, el servidor devuelve 402 Payment Required y proporciona el precio, las redes compatibles, los activos de pago y otra información necesaria. El cliente selecciona un método de pago compatible, genera las credenciales de pago y las envía mediante una solicitud HTTP.

A continuación, el servidor de recursos verifica las credenciales de pago y completa la liquidación mediante una transacción en cadena o un Facilitator, un servicio de verificación y liquidación de pagos. Un Facilitator puede realizar la verificación de firmas y la liquidación en cadena en nombre del servidor, lo que reduce la complejidad de mantener infraestructura de pagos basada en blockchain. Una vez que la verificación y la liquidación se completan correctamente, el servidor devuelve los datos solicitados o el resultado del servicio.

Ten en cuenta que las distintas versiones de x402 utilizan diferentes nombres de encabezados HTTP y estructuras de datos. Por ejemplo, las versiones anteriores utilizaban X-PAYMENT, mientras que las especificaciones más recientes utilizan campos como PAYMENT-SIGNATURE. Por tanto, los desarrolladores deben implementar la versión específica que utilicen y no deben combinar directamente interfaces de versiones diferentes.

Para los agentes de IA, la ventaja de x402 es que el pago puede convertirse en parte de una solicitud web ordinaria. Si un agente necesita comprar datos de pago o llamar a un modelo de IA, puede completar el pago dentro de un presupuesto autorizado sin ser redirigido cada vez a una página de pago manual independiente.

¿Cuáles son las diferencias entre AP2 y x402?

La diferencia más fundamental entre AP2 y x402 reside en sus responsabilidades. AP2 responde principalmente a la pregunta: “¿Está autorizada esta transacción?”. x402 responde principalmente a la pregunta: “¿Cómo se puede completar el pago programáticamente según los requisitos del servidor?”.

AP2 no depende de una moneda de pago ni de una red de liquidación específica. Por ejemplo, un agente de IA puede utilizar AP2 para demostrar que una compra ha sido autorizada y completar después la transacción con una tarjeta bancaria u otro método de pago compatible. x402 se centra más en la ejecución técnica de los pagos de servicios digitales y es especialmente adecuado para combinar pagos con stablecoins y solicitudes de API.

Los dos protocolos también presentan cierto solapamiento funcional. x402 puede verificar las credenciales de pago enviadas por un cliente, pero esta verificación se refiere principalmente a si el pago cumple los requisitos del servidor. No equivale necesariamente a una autorización completa de la intención comercial del usuario. AP2 puede registrar información más amplia sobre la intención del usuario, el producto y las condiciones de pago.

Por tanto, AP2 no debe considerarse simplemente una versión mejorada de x402, ni x402 debe considerarse un sustituto de todos los mecanismos de autorización de pagos. Pueden implementarse de forma independiente o utilizarse conjuntamente.

¿Cómo pueden AP2 y x402 trabajar juntos para completar una transacción entre agentes?

La colaboración entre AP2 y x402 puede entenderse mediante un ejemplo de un servicio de análisis de datos de pago.

Supongamos que un usuario autoriza a un agente de investigación a comprar datos de mercado por un importe máximo de 20 $ en un solo día. El agente descubre que otro proveedor de servicios ofrece una API que satisface sus necesidades y recibe una cotización de 0,10 $ por llamada. El sistema debe confirmar primero que el servicio se encuentra dentro del alcance de compra autorizado y comprobar después que el gasto acumulado no supera el presupuesto.

Durante la etapa de autorización, AP2 puede proporcionar un Mandate verificable que demuestre que el agente tiene los permisos de compra y pago correspondientes. Durante la etapa de pago, x402 puede comunicar los requisitos de pago del servidor al agente y completar la transferencia de fondos mediante una billetera controlada, credenciales de pago y un servicio de liquidación. Después de que el pago se complete correctamente, el servidor devuelve los datos y el agente continúa la tarea de investigación.

Esta combinación no se limita a un modelo conceptual. Los proyectos de código abierto relacionados con Google han lanzado la A2A x402 Payments Extension, que permite a los agentes comprar servicios proporcionados por otros agentes mediante pagos en cadena. Su especificación v0.2 también define flujos de pago independientes e integrados. Estos últimos pueden integrar estructuras de pago en protocolos de nivel superior como AP2.

Sin embargo, el proceso anterior es un ejemplo utilizado para explicar cómo se pueden combinar los protocolos. No significa que todas las implementaciones de AP2 o x402 ya admitan exactamente las mismas funciones. Los sistemas reales aún deben gestionar detalles como la verificación de credenciales de autorización, los permisos de billetera, los pagos fallidos, las solicitudes duplicadas y los recibos de transacción.

¿Por qué las stablecoins son adecuadas para los pagos automatizados de agentes de IA?

Las stablecoins son una de las principales opciones para los pagos programáticos de agentes de IA. En comparación con los activos cripto con mayor volatilidad de precios, las stablecoins vinculadas al USD suelen estar denominadas en dólares estadounidenses, lo que ayuda a los proveedores de servicios a establecer precios relativamente estables para llamadas de API, acceso a datos y recursos informáticos.

Por ejemplo, un agente de IA puede necesitar llamar a una interfaz de datos de pago cientos de veces al día. Si cada llamada requiere la confirmación manual de un pago con tarjeta bancaria, el proceso de transacción será difícil de automatizar. Con x402 y una red de stablecoins compatible, los requisitos de pago, las firmas y las operaciones de liquidación pueden integrarse en solicitudes programáticas, lo que permite al agente pagar automáticamente por servicios dentro de su presupuesto.

Las stablecoins también son digitales por naturaleza y programables. Los desarrolladores pueden combinar la lógica de pago con permisos de API, límites de uso y restricciones de billetera, lo que permite a los sistemas de software transferir fondos entre distintas plataformas. Al presentar x402, Coinbase identificó los pagos automatizados entre API, servicios de software y agentes de IA como un área de aplicación clave.

Sin embargo, los pagos con stablecoins también tienen limitaciones. Las transferencias en cadena pueden generar comisiones de red, algunas transacciones pueden requerir tiempo para alcanzar la finalidad y las direcciones incorrectas o las transferencias irreversibles pueden provocar la pérdida de fondos. Las stablecoins también implican riesgos relacionados con el emisor, las reservas, el reembolso y la regulación. Por tanto, las stablecoins deben entenderse como una opción de liquidación para el comercio de agentes, no como una solución universal para todos los problemas de pago.

¿Qué riesgos de seguridad y limitaciones técnicas afrontan AP2 y x402?

El primer riesgo es el abuso de autorización. Un agente de IA puede malinterpretar la solicitud de un usuario o verse influido por páginas web maliciosas, respuestas de herramientas o inyección de instrucciones, lo que puede hacer que inicie compras que excedan la intención real del usuario. Si el sistema depende únicamente del modelo para determinar si un pago es razonable y carece de comprobaciones independientes de presupuesto y permisos, pueden producirse gastos no deseados.

AP2 reduce este riesgo mediante Mandates y mecanismos de verificación deterministas, pero su seguridad sigue dependiendo de cómo se emiten, almacenan y verifican las credenciales de autorización. Los sistemas también deben evitar conceder permisos excesivamente amplios e introducir confirmación adicional para transacciones de alto riesgo.

El segundo riesgo es la ejecución del pago. x402 implica al cliente, el servidor, la billetera y el servicio de liquidación, y un error de implementación en cualquier etapa puede afectar al resultado de la transacción. Por ejemplo, el envío repetido de solicitudes puede provocar pagos duplicados, un pago correcto seguido de una entrega fallida del servicio puede dar lugar a una disputa y un fallo de un Facilitator puede retrasar la liquidación. Por tanto, los desarrolladores deben diseñar procesamiento idempotente, reintentos de pagos fallidos, conciliación de recibos y procedimientos de reembolso basados en excepciones.

El tercer riesgo se refiere a la verificación de la contraparte y la identidad. Incluso si un agente envía correctamente las credenciales de pago, el destinatario no es necesariamente fiable. Un servidor malicioso puede falsear los precios, proporcionar un servicio no válido o falsificar la información del producto. A2A y x402 pueden mejorar la comunicación entre agentes y los flujos de pago, pero no pueden garantizar automáticamente la autenticidad de la identidad de un comerciante ni que la calidad del servicio cumpla las expectativas.

Los riesgos finales están relacionados con la privacidad y la regulación. El comercio de agentes puede implicar preferencias de consumo de los usuarios, información de adquisiciones empresariales y datos de pago. Aunque los pagos en cadena proporcionan registros de transacciones verificables públicamente, también pueden exponer direcciones y flujos de fondos. Los pagos transfronterizos también requieren considerar los requisitos aplicables de prevención de blanqueo de capitales, sanciones y protección del consumidor.

Como resultado, las aplicaciones prácticas de AP2 y x402 deben construirse sobre una arquitectura de seguridad multicapa que incluya autorización del usuario, controles de permisos de agentes, verificación de credenciales de pago, supervisión de transacciones y gestión de excepciones. Solo combinando estos mecanismos los sistemas pueden controlar los riesgos relacionados con los fondos mientras aumentan el nivel de automatización.

Conclusión

AP2 y x402 proporcionan infraestructura para el comercio de agentes de IA desde las perspectivas de la autorización de pagos y la liquidación programática, respectivamente. Mediante Mandates y credenciales verificables, AP2 ayuda a los comerciantes y proveedores de servicios de pago a confirmar si la transacción de un agente cumple la autorización del usuario. Mediante HTTP 402 y procesos de verificación de pagos, x402 permite a los agentes de IA comprar automáticamente API, datos y otros servicios digitales.

Los dos protocolos no son sustitutos entre sí. AP2 puede funcionar con distintos métodos de pago, mientras que x402 puede servir como mecanismo de ejecución para pagos en cadena. A medida que se desarrollan tecnologías como la A2A x402 Payments Extension, la verificación de autorización y la liquidación automatizada están estableciendo una relación de colaboración más estrecha.

Para el comercio entre agentes, la cuestión clave no es simplemente permitir que los agentes de IA realicen pagos. Cada transacción debe tener límites de autorización claramente definidos, resultados de pago verificables y mecanismos fiables de gestión de excepciones. Las stablecoins y Web3 proporcionan nuevas herramientas de liquidación en esta dirección, pero la adopción generalizada del comercio de agentes dependerá, en última instancia, de la seguridad, la interoperabilidad y las necesidades empresariales reales.

Preguntas frecuentes

¿Cuál es la diferencia principal entre AP2 y x402?

AP2 verifica principalmente la autorización de compra y pago de un agente de IA, mientras que x402 permite principalmente pagos programáticos mediante solicitudes HTTP. El primero se centra en la autorización, mientras que el segundo se centra en la ejecución del pago.

¿Es AP2 un protocolo de pago basado en blockchain?

No. AP2 es un marco de autorización independiente del método de pago que puede admitir distintos sistemas de pago, incluidas las tarjetas bancarias y las stablecoins. No requiere que las transacciones se liquiden en una blockchain.

¿x402 solo puede utilizar USDC?

No. Las capacidades de pago de x402 dependen del esquema de pago específico, la red y la compatibilidad proporcionada por el servidor. USDC es un activo de pago habitual en las implementaciones, pero no debe entenderse como el único activo compatible con el protocolo.

¿Se pueden utilizar AP2 y x402 conjuntamente?

Sí. AP2 puede utilizarse para verificar la autorización de transacción de un agente, mientras que x402 puede utilizarse para ejecutar el pago programático en cadena correspondiente. La A2A x402 Extension ya ha explorado formas de combinar x402 con protocolos de nivel superior como AP2.

¿Un agente de IA necesita confirmación manual para realizar un pago con x402?

No necesariamente. Si el usuario ha proporcionado una autorización válida y la transacción cumple el presupuesto, el destinatario y otras restricciones aplicables, el sistema puede permitir que el agente realice el pago automáticamente. Las transacciones fuera del alcance autorizado deben requerir confirmación de nuevo.

¿Se garantiza la entrega del servicio después de que un pago x402 se complete correctamente?

No. El pago correcto y la prestación del servicio son etapas independientes. Aún pueden producirse fallos de API, servicios no disponibles o disputas sobre la entrega. Por tanto, los riesgos deben gestionarse con recibos de transacción, gestión de excepciones y mecanismos de reembolso cuando sea necesario.