Todo lo que hay que saber sobre x402 y MPP en un solo artículo: Las dos vías de pago a los agentes

Título original del artículo: MPP de Stripe frente a x402: ¿Qué ha pasado realmente hoy?
Autor del artículo original: Nick Sawinyh, defiprime.com
Traducción: Peggy, Blockbeats

Nota del editor: En lo que respecta a la forma de pago de Agent, x402 y MPP han seguido dos caminos casi opuestos.

x402 optó por la vía de la simplificación del protocolo: integrar los pagos directamente en las solicitudes HTTP, logrando así el proceso «de la solicitud al pago» de la forma más sencilla posible. Sin cuentas ni intermediarios, se asemeja al diseño abierto y sin permisos de los inicios de Internet, ideal para desarrolladores de nicho y escenarios descentralizados.

Por su parte, MPP optimiza el sistema: aborda las transacciones de alta frecuencia, la gestión de riesgos y los problemas relacionados con la integración de monedas fiduciarias mediante sesiones, pagos en tiempo real y un marco de cumplimiento normativo. No busca la pureza, sino que da prioridad a satisfacer las necesidades empresariales del mundo real, lo que lo hace más adecuado para aplicaciones a nivel empresarial y escalables.

La diferencia entre ambas consiste, en esencia, en dos soluciones al mismo problema: si los pagos deben formar parte del protocolo o constituir una capa del sistema.

Por este motivo, no compiten directamente entre sí, sino que más bien ocupan segmentos diferentes: x402 cubre las necesidades de la «long tail» de la red abierta, mientras que MPP se encarga del tráfico comercial y de alta frecuencia. En una economía de agentes que está dando sus primeros pasos, esta diferenciación puede ser inevitable.

A continuación se muestra el artículo original:

Desde finales de la década de 1990, cuando se definió el código de estado HTTP 402 en la especificación HTTP/1.1, ha estado esperando su momento. Significa «Se requiere pago». La idea original era integrar funciones de pago en la capa de protocolo de la web, de modo que las máquinas pudieran adquirir recursos con la misma facilidad con la que solicitan una página web.

Sin embargo, esta visión no se ha hecho realidad en gran medida. A lo largo de los años, este código de estado solo ha aparecido de forma esporádica en algunos casos excepcionales, como la respuesta de limitación de frecuencia de Shopify, los errores de facturación de Apple Mobile Me, etc., pero nadie ha construido realmente el futuro de los micropagos que este código sugiere. En cambio, contamos con tarjetas de crédito, muros de pago basados en suscripciones y mecanismos de claves API, que están diseñados esencialmente para sistemas gestionados por personas.

Hoy, ese futuro se ha materializado en dos vías de implementación que compiten entre sí, ambas lanzadas el mismo día. A continuación, quiero aclarar en qué consisten, cuáles son sus diferencias y por qué Stripe está apostando por ambas vías al mismo tiempo.

x402: Una solución más sencilla

En mayo de 2025, Coinbase lanzó oficialmente x402, cuya idea central puede describirse como casi agresivamente sencilla. Un cliente solicita un recurso; el servidor responde con un código HTTP 402, indicando al cliente el importe de la tarifa, qué token debe utilizar y en qué cadena debe realizar el pago. El cliente realiza el pago en la cadena, adjunta el recibo de pago a una solicitud reenviada y, a continuación, el servidor entrega el recurso.

Eso es todo. Sin sistema de cuentas, sin clave API, sin mecanismo de suscripción. Solo una solicitud HTTP de ida y vuelta, con un pago entre medias.

A partir de hoy, Stripe ha incorporado de forma nativa la compatibilidad con x402 en su sistema de pagos, lo que permite a los comerciantes recibir directamente este tipo de pagos a través de su infraestructura técnica existente. Sin embargo, en esencia, x402 sigue siendo un protocolo liderado por Coinbase, regulado por la Fundación x402, creada conjuntamente por Coinbase y Cloudflare en septiembre de 2025. El protocolo es totalmente de código abierto (bajo licencia Apache 2.0) y ofrece kits de desarrollo de software (SDK) en varios lenguajes, como TypeScript, Go y Python.

En cuanto a la compatibilidad, la documentación oficial de Coinbase indica que, actualmente, los pagos ERC-20 son compatibles con Base, Polygon y Solana. Además, el ecosistema está estudiando la posibilidad de ampliarlo a otras cadenas como Avalanche, Sui y Near, entre otras, aunque con distintos grados de madurez.

Si nos fijamos en los datos de adopción, esta parte es un poco más compleja. Coinbase ha afirmado que x402 ha procesado más de 50 millones de transacciones a través de su infraestructura Agentic Wallet. Aunque esto pueda parecer impresionante, según los datos de análisis en cadena de Artemis citados por CoinDesk el 11 de marzo, el volumen diario de transacciones ronda las 131 000, con un importe total de unos 28 000 dólares, lo que supone un pago medio por transacción de solo unos 0,20 dólares; además, aproximadamente la mitad de ellas parecen más bien pruebas o acciones gamificadas que transacciones comerciales reales.

Sin embargo, puede que esto no sea algo negativo, ya que el protocolo se diseñó para un mercado que aún no existe realmente: un mundo de microtransacciones (incluso por debajo de 1 céntimo) realizadas por agentes de IA para llamadas a la API y consultas de datos. Los comerciantes que abastecen este mercado están empezando a aparecer.

Por ejemplo, el Protocolo de Pagos Agentes (AP2) de Google, que forma parte del marco A2A, ha integrado el estándar x402; Lowe’s Innovation Labs presentó una demostración en la que un agente de IA puede completar todo el proceso, desde el descubrimiento del producto hasta la búsqueda y el pedido, en un solo flujo. Por otra parte, World (fundada por Sam Altman) ha lanzado esta semana AgentKit, que añade funciones de verificación de identidad a las carteras x402.

La idea fundamental que subyace a todo esto es la siguiente: siempre que logremos que los pagos sean tan sencillos como una solicitud HTTP, surgirán casos de uso de forma natural. Queda por ver si esto es cierto.

MPP: Solución integral

Stripe y Tempo optaron por un camino diferente. El Protocolo de Pagos de Máquinas (MPP) se ha lanzado hoy junto con la red principal de Tempo. A diferencia de x402, que actúa como una capa de envoltura ligera sobre una cadena de bloques ya existente, MPP está diseñado específicamente para el escenario de agentes inteligentes en el que se realizan transacciones de alta frecuencia.

Su mecanismo principal son las sesiones. A diferencia de lo que ocurre cuando se inicia una transacción en cadena para cada solicitud de recursos, un agente puede autorizar primero un límite de gasto en una sola transacción y, a continuación, continuar con microtransacciones dentro de ese límite. Si eres una IA que necesita consultar miles de fuentes de datos por hora, seguro que no quieres firmar y transmitir una transacción en cadena cada vez, y las sesiones están diseñadas para resolver este problema.

La cadena Tempo también se ha diseñado teniendo en cuenta esta necesidad. Admite decenas de miles de transacciones por segundo, ofrece tiempos de confirmación inferiores a un segundo y no cuenta con un token de gas nativo. Los usuarios pueden pagar directamente las comisiones de transacción con stablecoins, lo que elimina el engorroso paso de tener que comprar un token cualquiera antes de realizar una transferencia.

Otro aspecto que conviene comprender es: La suite Agentic Commerce de Stripe incluye tokens de pago compartidos (SPT). Esto no forma parte del propio MPP, sino que es un mecanismo de extensión de Stripe que puede funcionar en combinación con él. Los SPT permiten a un agente transmitir de forma segura las credenciales de la tarjeta bancaria o del monedero digital de un usuario a un comerciante sin revelar los datos reales. Estas credenciales se limitan a una sola transacción y tienen una vigencia limitada, por lo que funcionan como una autorización programable y autodestructible. En la práctica, esto significa que un agente que realice pagos a través de MPP puede utilizar el USDC de Tempo, la tarjeta Visa vinculada de un usuario o incluso una combinación de ambas.

Según la entrada del blog sobre el lanzamiento de la red principal de Tempo, entre sus socios se encuentran Anthropic, DoorDash, Mastercard, Nubank, OpenAI, Ramp, Revolut, Shopify, Standard Chartered y Visa. Según «The Block», en el momento del lanzamiento de MPP, el directorio de pagos ya contaba con más de 100 servicios, entre los que se encontraban Alchemy, Dune Analytics, Merit Systems y Parallel Web Systems. En una entrevista concedida a «Fortune», Matt Huang, cofundador de Paradigm y colaborador de Tempo, afirmó que este campo se encuentra aún en una fase inicial, y que MPP está diseñado para poder expandirse en el futuro a más entornos en cadena más allá de Tempo.

Por qué Stripe admite ambas opciones

Si ya estás integrado con Stripe, la respuesta más práctica es: no tienes que elegir entre los dos.

Stripe admite x402 y MPP a través de dos vías de integración independientes, en lugar de integrarlas en una interfaz unificada. En el caso de x402, su documentación aborda principalmente el proceso de generación de una dirección de recarga, la supervisión en cadena y la liquidación de fondos en la cuenta de Stripe: tú te encargas de devolver una respuesta 402, mientras que Stripe se ocupa de la infraestructura de pago cifrada subyacente. Actualmente, Base admite USDC, y hay previstas ampliaciones futuras. En el caso de MPP, los comerciantes pueden utilizar la misma API de PaymentIntents para recibir pagos en tiempo real basados en sesiones.

Sobre la base de estas dos plataformas de pago se asienta la suite Agentic Commerce de Stripe, lanzada en diciembre de 2025. Los comerciantes solo tienen que subir su catálogo de productos y elegir los agentes de IA que deseen integrar; Stripe se encargará de la búsqueda de productos, los procesos de pago, la prevención del fraude y la gestión de los impuestos. En la actualidad, URBN, Etsy, Coach, Kate Spade y Ashley Furniture ya lo están utilizando, y plataformas como Wix, WooCommerce, BigCommerce, Squarespace y commercetools han completado sus integraciones.

Su estrategia es bastante clara: controlar la capa de abstracción y dejar que los protocolos subyacentes compitan libremente.

Sobre la comparación

En términos generales, estos dos protocolos hacen lo mismo: permiten a las máquinas pagar por recursos a través de HTTP. Sin embargo, las verdaderas diferencias están en los detalles.

x402 (liderado por Coinbase) frente a MPP (Stripe + Tempo)

Normalización
x402: Totalmente de código abierto (Apache 2.0), impulsado por la Fundación x402 para la participación de múltiples partes (Coinbase, Cloudflare, Visa, Google).
MPP: Estándar abierto desarrollado conjuntamente por Stripe y Tempo, que forma parte de la suite Stripe Agentic Commerce.

Mecanismo HTTP
x402: Reactiva el código HTTP 402, inicia las solicitudes mediante el encabezado PAYMENT-REQUIRED y completa los reintentos utilizando PAYMENT-SIGNATURE.
MPP: También utiliza un mecanismo de desafío-respuesta, pero emplea el esquema de autenticación HTTP para pagos (un borrador de la IETF) y vincula el identificador del desafío con HMAC.

Capa de pago (Rails)
x402: Diseñado para ser independiente de la cadena de bloques, actualmente es compatible con Base, Polygon y Solana, y se están estudiando otras cadenas.
MPP: Desarrollado sobre la cadena de bloques Tempo —una capa 1 optimizada para pagos, con una capacidad de más de 10 000 TPS, confirmación en menos de un segundo y sin token de gas nativo—; su objetivo a largo plazo es la compatibilidad entre cadenas.

Forma de pago
x402: Stablecoins puras, totalmente en cadena.
MPP: Admite USDC + SPT en Tempo (el mecanismo de Stripe), lo que permite combinar criptomonedas y dinero fiduciario (tarjetas de crédito, monederos electrónicos, BNPL).

Método de liquidación
x402: Liquidación en cadena (entre unos 200 ms y unos segundos), validada y liquidada por facilitadores como Coinbase.
MPP: Finalidad en menos de un segundo en Tempo; liquidación automática de Stripe con cumplimiento normativo garantizado.

Incorporación de comerciantes
x402: El middleware de código abierto (Express, Hono, Next.js, etc.) puede alojarse en un servidor propio o estar alojado en un servicio externo.
MPP: Integración directa con la API PaymentIntents de Stripe, gestión de riesgos integrada, gestión fiscal, devoluciones y generación de informes.

Innovación fundamental
x402: Extremadamente sencillo, independiente del proveedor, similar a la filosofía de Unix en el ámbito de los pagos.
MPP: Alto rendimiento + integración de monedas fiduciarias, lo que permite pagos en tiempo real, la agregación de microtransacciones a lo largo de sesiones y un control programable del gasto basado en SPT.

Socios clave
x402: Coinbase, Cloudflare, Google (A2A/AP2), Visa, World, Anthropic (MCP).
MPP: Stripe, Visa, Lightspark, Anthropic, DoorDash, Mastercard, OpenAI, Shopify, Revolut, Standard Chartered Bank.

x402 parece ser la solución más habitual a la hora de crear sistemas abiertos: API para desarrolladores independientes, mercados de datos descentralizados o cualquier servicio que prefiera no depender de procesadores de pagos. Su especificación cabría en un solo documento técnico y solo requeriría un middleware y una dirección de monedero. Esta pureza resulta muy atractiva, aunque las limitaciones que conlleva el hecho de ser una plataforma exclusivamente criptográfica también implican que su público es más reducido.

El MPP, por su parte, es un paradigma completamente diferente. Si tu agente necesita realizar cientos o incluso miles de transacciones en una sola sesión y no quieres que cada transacción se registre en la cadena de bloques cada vez, entonces es una opción más razonable. El mecanismo de sesión mantiene la mayoría de las interacciones fuera de la cadena hasta la liquidación final; el sistema de cumplimiento normativo de Stripe se encarga de gestionar los riesgos y la fiscalidad; y el modo híbrido de SPT permite que el agente no se limite a las monedas estables, sino que también pueda acceder directamente a la tarjeta Visa del usuario u otros métodos de pago. No es tan elegante, pero se acerca más a la realidad.

Curiosamente, no son totalmente compatibles entre sí. x402 cubre el escenario de «long tail» abierto, mientras que MPP cubre el tráfico de alta frecuencia a nivel empresarial. La estrategia de Stripe también es clara: no apostar por un único protocolo, sino asegurarse de que, independientemente de cuál sea la opción ganadora, los fondos acaben fluyendo hacia el sistema de cuentas de Stripe.

Una mirada realista: ¿En qué punto nos encontramos ahora en cuanto al desarrollo?

Para ser sinceros, en este momento casi no se están produciendo transacciones a gran escala.

Según las notas de la versión x402 de Coinbase, entre los primeros socios se encuentran Hyperbolic (GPU Inference Pay) y Anthropic (integración del protocolo MCP). El blog de Stripe menciona casos de uso de agentes que se pagan mediante llamadas a la API (como CoinGecko). Cuando se lanzó Tempo, el directorio contaba con más de 100 servicios. El SDK de Agents de Cloudflare es compatible de forma nativa con x402, y algunos proyectos pequeños en Base L2 también están intentando utilizar x402 como pasarela de pago.

Pero, en general, el volumen de transacciones es bajo, el número de comerciantes es limitado y la mayoría de las actividades se encuentran todavía en fase experimental.

No es de extrañar. Cualquier nueva infraestructura de pago pasa por esto en sus inicios. La denominada «lista de socios» a veces presenta una gran diferencia entre la firma de un memorando de entendimiento y la puesta en marcha efectiva, y estos comunicados no suelen hacer esa distinción.

Más destacables son los pesos pesados que hay detrás de la infraestructura. En 2025, Stripe procesó 19 billones de dólares en pagos, con un volumen total que creció un 34 % respecto al año anterior. Al mismo tiempo, han entrado en escena Coinbase, Cloudflare, Visa, Google y toda una red de colaboraciones con Tempo.

En otras palabras, ya está todo preparado. La única pregunta que queda por responder es: ¿en 2026, será realmente necesario que un agente de IA realice transacciones a gran escala en este canal? ¿O se trata más bien de algo parecido a tender cables de fibra óptica en 1998: construir la infraestructura antes de que surja la demanda?

¿Cuál deberías elegir?

Si estás creando un sistema abierto y sin permisos, x402 es la opción más lógica. No hace falta una plataforma registrada, ni integrarse con procesadores de pagos; solo tienes que importar el middleware, conectar tu monedero y empezar a recibir pagos. La contrapartida es que tienes que encargarte tú mismo del cumplimiento normativo, la gestión de riesgos y la liquidación en moneda fiduciaria.

Si ya formas parte del ecosistema de Stripe y quieres aprovechar el tráfico de los agentes, MPP es la opción más adecuada. Las sesiones, los pagos por streaming, la combinación de monedas fiduciarias y criptomonedas, y un sistema de cumplimiento normativo completo se asemejan, en esencia, más a una actualización de la configuración que a una revisión completa del sistema.

Si lo único que te importa es poder recibir pagos independientemente del protocolo que utilice el agente, la respuesta es, en realidad: utiliza Stripe. Sirve para ambos lados.

El código HTTP 402 por fin ha encontrado su razón de ser. Solo han hecho falta unos 27 años.

[Enlace al artículo original]