• Tallinn09:57
  • Ljubljana08:57
  • Novi Sad08:57

Por Miloš Duraković

Cómo podemos ayudarte: Agentes de IA e Integración MCPVer el servicio

x402 y los pagos entre máquinas en 2026: cobrar a los agentes de IA por petición y cuánto hay de real

Pórticos de una zona de peaje en la Dulles Toll Road, con carteles de carril para etiquetas electrónicas y para pago en efectivo exacto

HTTP tiene un código de estado para esto desde los primeros tiempos de la web. La RFC 9110 sigue diciéndolo sin rodeos: «El código de estado 402 (Payment Required) está reservado para uso futuro». En 2026 dos protocolos intentan que ese futuro llegue. x402, impulsado por Coinbase y hoy gestionado por un proyecto de la Linux Foundation, responde a una petición con un precio y acepta un pago firmado en stablecoins en el reintento. El Machine Payments Protocol (MPP), de Stripe y Tempo, hace lo mismo a través de las cabeceras de autenticación de HTTP y admite tarjetas además de stablecoins. AWS y Cloudflare venden ya ambas ideas en el edge, de modo que un editor puede cobrar a los rastreadores de IA sin tocar su origen.

La propuesta resulta atractiva para quien vende datos, una API o contenido que leen los agentes de IA: cobrar por llamada, liquidar en segundos, sin cuentas y sin facturas. Los números que hay detrás de la propuesta son otra cuestión. Una medición independiente de x402 en Base encontró que la mayoría de las liquidaciones registradas son autopagos o dinero que se mueve dentro de un mismo grupo de wallets, y una empresa de analítica de blockchain situó en unos USD 5.000 a 11.000 al mes en 2026 el volumen que parece de agentes que compran.

Este artículo es para propietarios y desarrolladores de APIs, servicios de datos y sitios de contenido que están decidiendo si cobrar ya a los agentes. Explica cómo funcionan los protocolos, qué ofrece cada proveedor a 22 de octubre de 2026, qué tendrías que desarrollar, qué muestran de verdad los volúmenes y qué cuestiones regulatorias trae consigo tener stablecoins.

Cómo funciona x402

La especificación está en la versión 2, con fecha de 9 de diciembre de 2025, en un repositorio que pasó de Coinbase a la x402 Foundation. Define tres roles: un servidor de recursos que quiere cobrar, un cliente (a menudo un agente) que paga y un facilitador que «se encarga de la verificación del pago y de la liquidación en la blockchain».

Una petición de pago transcurre así:

  1. El cliente pide el recurso y recibe 402 Payment Required. Una cabecera PAYMENT-REQUIRED lleva un objeto codificado en Base64 que enumera una o varias formas aceptables de pagar, cada una con un scheme, una network en formato CAIP-2 (eip155:8453 es Base), un amount en las unidades más pequeñas del token, un asset, una dirección payTo y un maxTimeoutSeconds.
  2. El cliente firma un pago y repite la petición con una cabecera PAYMENT-SIGNATURE. En las cadenas EVM es una firma EIP-712 sobre una autorización de transferencia EIP-3009 con una ventana de tiempo y un nonce de 32 bytes contra la repetición.
  3. El servidor hace que el facilitador verifique la firma (POST /verify, que «NO DEBE confirmar el estado del pago»), ejecuta su controlador y después hace que el facilitador liquide (POST /settle).
  4. El servidor responde con el recurso y una cabecera PAYMENT-RESPONSE que contiene el hash de la transacción.

Ese es el flujo de «autorización» por defecto: «el pago se verifica antes de que se ejecute el recurso y se liquida después». Hay otros dos flujos definidos: uno que liquida primero y otro que toma un depósito y liquida el importe final después. Si una liquidación se emitió pero no se confirmó, el facilitador puede devolver settlement_pending con el hash, y el servidor debe conciliar antes de que nadie reintente.

Hay dos detalles en los que se tropieza con facilidad. La versión 1, que muestran casi todos los tutoriales antiguos, usaba X-PAYMENT y X-PAYMENT-RESPONSE y nombres de red como base-sepolia; la versión 2 cambió el nombre de las cabeceras y pasó a CAIP-2. Y los mismos mensajes están definidos sobre MCP y sobre el protocolo Agent-to-Agent (A2A): sobre MCP, una herramienta de pago devuelve un resultado con isError: true y el pago viaja en _meta["x402/payment"].

Los cuatro esquemas de pago

EsquemaQué haceDónde está vinculado en la especificaciónReembolsos
exactUn importe fijo que el servidor conoce de antemano18 redes, desde EVM y Solana hasta Stellar, TON y XRPLNinguno definido: «cualquier solución es un acuerdo propio del servidor de recursos»
uptoAutoriza un máximo y cobra el uso real al liquidar (por ejemplo, por token generado)EVM y SolanaNinguno definido
batch-settlementAcepta un compromiso por petición y liquida muchos después de una vez, para cuando «las comisiones de gas superan el valor de cada petición»EVM, Solana y un binding de CloudflareDepende del binding
auth-captureRetención, captura por un importe menor, anulación, reembolso y recuperación por el cliente pasado un plazoSolo EVM; un borrador (v1.1, 18 de agosto de 2026)El único esquema que los tiene

En las cadenas EVM, cualquier token ERC-20 sirve en principio, mediante EIP-3009 (el método de USDC) o Permit2. En la práctica, los SDK de referencia fijan los precios en dólares y asignan "$0.01" a una stablecoin en USD por red: USDC en Base y en la mayoría de las cadenas EVM, varias stablecoins en Solana, USDT en TON. El cliente de referencia solo acepta los activos que reconoce y limita cada pago a USD 1 por defecto. No hay un valor por defecto en euros.

Facilitadores: quién mueve el dinero

El facilitador es «opcional pero recomendado». Comprueba las firmas y envía la transferencia onchain, y la documentación dice que «no custodia fondos ni actúa como depositario»: el dinero llega a tu wallet payTo.

  • El facilitador público x402.org es solo para testnets. La guía de inicio para vendedores es explícita: «No reutilices https://x402.org/facilitator para rutas de mainnet».
  • El facilitador CDP alojado de Coinbase no cobra nada por las primeras 1.000 transacciones onchain al mes y después cobra USD 0,001 por cada una; la verificación es siempre gratuita. Ejecuta comprobaciones de OFAC y de Know Your Transaction en cada pago, necesita una clave de API de CDP y admite Base, Polygon, Arbitrum, Monad, World y Solana. No incluye auth-capture en su lista. La liquidación por lotes reparte la comisión: «una sola transacción onchain puede procesar miles de pagos».
  • La fundación enumera otros facilitadores en producción, entre ellos Fireblocks, Polygon, PayAI, Corbits, Stellar y Celo, y dice que la lista «no es un catálogo exhaustivo».
  • Puedes ser tu propio facilitador, pagando el gas y, en Solana, desarrollando la detección de liquidaciones duplicadas que de otro modo ofrecería un facilitador.

La x402 Foundation empezó a funcionar el 14 de julio de 2026 con 40 miembros. Entre sus miembros premier están Adyen, AWS, American Express, Cloudflare, Coinbase, Google, Mastercard, Shopify, Stripe y Visa; su comité directivo técnico tiene miembros de Coinbase, Cloudflare y Stripe. Ser miembro es apoyar la gobernanza, no haber desplegado nada. El comunicado de lanzamiento menciona «compatibilidad con tipos de pago que van desde las tarjetas tradicionales hasta las stablecoins», pero la especificación no tiene hoy ningún binding para tarjetas.

El Machine Payments Protocol de Stripe y Tempo

Stripe y Tempo lanzaron MPP el 18 de marzo de 2026, el día en que entró en funcionamiento la mainnet de Tempo. Usa el marco de autenticación de HTTP: un 402 con un reto WWW-Authenticate: Payment, una credencial en Authorization: Payment y una cabecera Payment-Receipt si todo sale bien. Sus intents son charge (un pago), session (pago en flujo continuo sobre un canal) y subscription, y sus métodos de pago en producción son las stablecoins de Tempo y los métodos con tarjeta de Stripe. Visa publicó ese mismo día una especificación para tarjetas y un SDK para MPP. El documento del IETF en que se basa es un Internet-Draft individual que «no tiene ninguna condición formal en el proceso de estándares del IETF».

En Stripe, MPP acepta tarjetas (mediante Shared Payment Tokens) y stablecoins, y Stripe también acepta pagos x402 en stablecoins en Base, liquidados a través del facilitador de Coinbase en una dirección de depósito de Stripe. En ambos casos el resultado llega a tu saldo de Stripe como un PaymentIntent, y las stablecoins enviadas a una dirección de depósito se convierten: «Stripe hace automáticamente el offramp de estos pagos y los liquida en tu saldo de Stripe». Las condiciones:

  • La aceptación de stablecoins está «disponible para empresas de todos los estados de EE. UU., salvo Nueva York». En otros lugares hay que escribir a Stripe para pedir acceso, que se revisa; la UE, Hong Kong, México y Suiza están en private preview.
  • Los mínimos son USD 0,50 para un pago con tarjeta y 0,01 USDC para un pago con stablecoins. Las sesiones de MPP pueden cobrar en pasos «tan pequeños como 0,000001 USDC», pero se liquidan en céntimos enteros, y un resto inferior a un céntimo se pierde.
  • Los pagos con stablecoins en Stripe no tienen soporte de disputas, los reembolsos vuelven como stablecoins a la wallet original, y una sola transacción tiene un tope de USD 10.000.
  • Las API son versiones preview (2026-07-29.preview para MPP, 2026-05-27.preview para la dirección de depósito de x402).

Visa Intelligent Commerce Connect, anunciado el 8 de abril de 2026 como piloto, incluye MPP entre los protocolos de agentes que los comerciantes pueden aceptar a través de él. No incluye x402.

Cobrar en el edge: AWS y Cloudflare

Si tu contenido o tu API ya están detrás de una CDN, el edge puede encargarse del cobro.

AWS WAF AI traffic monetization (anunciado el 15 de junio de 2026) devuelve «una respuesta HTTP 402 Payment Required legible por máquinas mediante el protocolo abierto x402» a bots y agentes, y liquida a través del facilitador de Coinbase en una wallet de USDC que tú indicas, en Base o en Solana. La función no tiene coste adicional, pero se aplican las tarifas normales de WAF y de Bot Control, y solo funciona con CloudFront. Puedes poner precios distintos a los rastreadores de búsqueda verificados, a los agentes no verificados y a los rastreadores de entrenamiento, y probar antes de salir en vivo. Solo liquida cuando tu origen devuelve un 2xx, y no cobra por los 4xx ni los 5xx. La documentación es franca sobre los costes: un mínimo de USD 0,001 por petición, «varios segundos de latencia adicional» en las peticiones de pago, una detección de bots que es «probabilística» y una advertencia de que una regla Monetize que no se limite a los bots «bloqueará de hecho el acceso a los clientes no automatizados». «AWS no es parte ni participa en el flujo de fondos», y aceptas las condiciones de Coinbase. La liquidación con Stripe y la compatibilidad con MPP figuraban como «próximamente» en el anuncio.

Cloudflare pay per crawl es un modelo distinto. Está en beta cerrada, tu dominio tiene que estar en Cloudflare, fijas un único precio para todos los rastreadores a los que cobras y Cloudflare «actúa como merchant of record». Los rastreadores se identifican con Web Bot Auth y pagan con factura de Stripe, no desde una wallet. Nunca tocas stablecoins.

Cloudflare Workers puede poner un proxy de x402 o de MPP delante de cualquier backend HTTP, con precios por patrón de ruta, y puede cobrar solo las peticiones con una puntuación baja de bot, de modo que las personas naveguen gratis. El Agents SDK tiene paidTool, que convierte una herramienta MCP en una de pago. Ten en cuenta que los ejemplos de Cloudflare usan el facilitador x402.org, pensado para testnets, y nombres de red de la versión 1; para producción, cámbialos por un facilitador de producción y por identificadores CAIP-2.

Cuánto hay de real

Las cifras de los titulares son grandes y no coinciden entre sí. La página de inicio de x402.org muestra 75,41 millones de transacciones y USD 24,24 millones en los últimos 30 días, sin fecha, fuente ni método en la página. Coinbase dice que su facilitador ha procesado «más de 100 millones de transacciones y 28 millones de dólares en volumen de pagos solo en Base y Solana», sin indicar el periodo. Son recuentos de liquidaciones, y ese es el problema.

Un estudio de medición de investigadores de la City University of Hong Kong, la Chinese University of Hong Kong y la Zhejiang University (un preprint, publicado el 14 de julio de 2026) analizó 280 días de x402 en Base, del 17 de septiembre de 2025 al 23 de junio de 2026: 136.708.672 liquidaciones por un valor de USD 44,1 millones. De ellas, «el 21,20% son ficticias y el 63,78% son liquidación interna dentro de un grupo vinculado». El valor que «llega demostrablemente a un servicio identificable» fue de USD 187.861,35. De 624 destinatarios que cobraron alguna vez, 249 ganaron al menos USD 10, la mediana de ingresos a lo largo de su vida fue de USD 3,96 y solo 474 de 910 hosts anunciados seguían devolviendo un reto de pago activo. La conclusión de los autores: «El recuento de liquidaciones mide la facilidad de fabricarlas, no la adopción».

TRM Labs, que vende monitorización de blockchain, contó USD 52,7 millones en 198,9 millones de liquidaciones en Base, Solana y Polygon desde mayo de 2025. Cerca de la mitad desapareció al eliminar los autopagos, los flujos masivos y los vendedores con muy pocos compradores. De los USD 25,62 millones que quedaron, estimó que entre el 0,6% y el 7,5% «parece agéntico», y que el volumen que movieron los agentes se mantuvo en torno a USD 5.000 a 11.000 al mes durante 2026. Su lectura para los vendedores es útil: «atraer tráfico de agentes exige un diseño distinto. Tiene que ser legible por máquinas y tener precios por llamada en un endpoint que un comprador pueda descubrir sin que ninguna persona vea nunca la página».

Nada de esto dice que la idea sea errónea. Dice que, en octubre de 2026, un endpoint que cobra a los agentes por llamada debe esperar unos ingresos propios de un experimento, y que no conviene planificar a partir de los recuentos de los titulares.

Quién tiene el dinero y qué normas se aplican

Con x402 el pago va directamente a tu wallet. Eso significa que tu empresa tiene las claves, lleva USDC en su contabilidad y lo convierte a su propia moneda, salvo que un proveedor como Stripe lo convierta por ti. El control del facilitador (las comprobaciones de OFAC y KYT de Coinbase) es algo que hace el facilitador; la especificación de x402 no define ninguno. Los reembolsos corren de tu cuenta: exact «no define ningún reembolso», y los pagos con stablecoins de Stripe no tienen disputas.

Dos regímenes afectan a quien se sitúe en el flujo de fondos.

  • Estados Unidos: la GENIUS Act. La Public Law 119-27, aprobada el 18 de julio de 2025, entra en vigor 18 meses después de su promulgación o 120 días después de las normas definitivas, lo que ocurra primero. La propuesta de norma del Tesoro del 18 de agosto de 2026 dice que la fecha de entrada en vigor «se espera que sea el 18 de enero de 2027». A partir de esa fecha, un proveedor de servicios de activos digitales no podrá poner a disposición en EE. UU. la stablecoin de un emisor extranjero salvo que el emisor pueda cumplir órdenes legales. A partir del 18 de julio de 2028, un proveedor de servicios de activos digitales no podrá ofrecer ni vender una stablecoin de pago a una persona en EE. UU. salvo que la haya emitido un emisor autorizado. La ley define a un proveedor de servicios de activos digitales por actividades como cambiar, transferir o custodiar activos digitales para otros, realizadas «a cambio de una compensación o con ánimo de lucro».
  • Unión Europea: MiCA. El periodo transitorio para los proveedores de servicios de criptoactivos terminó el 1 de julio de 2026. La declaración de la ESMA: «cualquier entidad que preste servicios de criptoactivos a clientes de la UE sin una licencia MiCA incumplirá el Derecho de la UE y deberá dejar de ofrecer tales servicios», y las empresas de fuera de la UE no pueden atender a clientes de la UE, «también ... en un contexto entre empresas». Las stablecoins en USD son tokens de dinero electrónico según MiCA. El consejo de la ESMA a los usuarios es comprobar que un proveedor figure en su registro provisional.

Lo que ninguna de estas fuentes resuelve es la situación de una empresa que solo recibe stablecoins como pago por su propia API o su propio contenido. Las restricciones de la GENIUS Act están redactadas para proveedores de servicios de activos digitales, y las de MiCA para proveedores de servicios de criptoactivos; si tu planteamiento te convierte en uno de ellos, o depende de proveedores que tienen que serlo, es una cuestión para un asesor jurídico en cada jurisdicción donde operes. Somos ingenieros, no abogados, y desarrollamos según la respuesta que te dé tu asesor. En la práctica, pregunta a cada proveedor de tu cadena si tiene licencia donde están tus clientes.

Cuatro formas de desarrollarlo

De menos a más código:

  1. Que cobre la CDN. AWS WAF en CloudFront: una configuración de monetización con tu wallet y tus precios, reglas Monetize limitadas a las etiquetas de bots, primero en modo de prueba, sin cambios en el origen. Cloudflare pay per crawl: si estás en la beta, un precio y los ajustes de cobro, con Cloudflare como merchant of record.
  2. Que cobre un proveedor de pagos. Stripe MPP: un perfil de Stripe, la biblioteca mppx, una llamada charge en tu controlador y una dirección de depósito de Tempo. Tarjeta y stablecoins, liquidadas en moneda fiat en tu saldo de Stripe. O x402 en Stripe con una cuenta de CDP y una dirección de depósito en Base, solo con stablecoins.
  3. Ejecutar x402 en tu propio servidor con el middleware del SDK para tu framework (Express, Hono, Next.js, Fastify; existen SDK de Python y de Go), un facilitador alojado y una configuración de ruta con esquema, precio, red, payTo y descripción.
  4. Ser tu propio facilitador, si necesitas control total o una red que nadie atiende.

Elijas la vía que elijas, hay decisiones que siguen siendo tuyas: qué esquema encaja con el trabajo (exact para precios fijos, upto para trabajo medido, liquidación por lotes cuando las llamadas valen menos que el gas), quién ve el paywall (un 402 mostrado a una persona en un navegador es un callejón sin salida), cómo conciliar settlement_pending, los reintentos idempotentes si los clientes envían un identificador de pago, los reembolsos, la custodia de la wallet receptora y cómo contabilizar los cobros en USDC. Los agentes también tienen que poder pagar: un cliente x402 necesita una wallet con la stablecoin correcta en la red correcta, un cliente MPP una wallet de Link o de Tempo y un rastreador de pay per crawl una identidad Web Bot Auth y una relación de facturación con Stripe. No puedes dar por hecho que un agente concreto tenga ninguna de estas cosas.

¿Conviene cobrar ya a los agentes?

  • Vendes una API o datos que los agentes ya llaman: hacer un experimento sale barato. Pon uno o dos endpoints detrás de MPP o x402 junto a tus claves y planes actuales, fija precios por encima de los mínimos (USD 0,001 en AWS, 0,01 USDC en Stripe) y mide quién paga. Conserva los planes de pago que ya tienes: el canal de pagos de agentes va a ser pequeño por ahora.
  • Publicas contenido y los rastreadores de IA ya lo leen: las opciones del edge existen para esto. AWS WAF si estás en CloudFront y te sientes cómodo teniendo USDC; Cloudflare pay per crawl si estás en Cloudflare, quieres liquidación con tarjeta y puedes entrar en la beta. Ninguna es todavía un plan de ingresos; ambas te dan un precio y un registro de quién se negó a pagarlo.
  • Quieres que los agentes compren productos de tu tienda: este no es ese problema. Las redes de tarjetas, los Shared Payment Tokens de Stripe y los protocolos de checkout de Google y de OpenAI cubren la compra de agentes a comerciantes, y los tratamos en nuestro artículo sobre pagos agénticos.

Qué podría cambiar

  • La entrada en vigor de la GENIUS Act el 18 de enero de 2027 (antes, si las normas definitivas llegan primero), y la restricción de 2028 que viene después.
  • Que AWS añada la liquidación con Stripe y MPP, anunciada como próximamente.
  • Que auth-capture madure, lo que daría a x402 reembolsos fuera de los borradores.
  • Que el Internet-Draft de MPP avance, o no, hacia un grupo de trabajo del IETF.
  • Que Visa Intelligent Commerce Connect se amplíe más allá de sus socios piloto, lo que llevaría los pagos de agentes con tarjeta a más comerciantes a través de MPP.

Dónde conseguir ayuda

Desarrollamos la parte de servidor del acceso de pago para máquinas: medición y precios por endpoint, retos x402 o MPP delante de las APIs y herramientas MCP existentes, conciliación de las liquidaciones en los sistemas que ya usa tu equipo de finanzas y la identificación de bots que decide quién ve un precio. Nuestro servicio de desarrollo de agentes de IA e integración MCP es donde empieza ese trabajo.

Si estás valorando si cobrar a los agentes por tu API o tu contenido, y a través de qué proveedor, escribe a office@c9group.dev.

Pagos

Nuevas guías y cambios normativos por correo

Cuando cambia una norma, se mueve un plazo o publicamos una guía nueva, te lo enviamos por correo.

Primero te enviamos un enlace de confirmación. Puedes darte de baja cuando quieras. Política de privacidad