MPP vs x402: un segundo estándar de pagos agénticos y una sola decisión para quien vende una API

Qué publicó Ripple el 17 de septiembre de 2026

Ripple lanzó la versión 1.1 del XRPL AI Starter Kit. La novedad principal es el soporte del Machine Payments Protocol (MPP) — un estándar abierto co-escrito por Stripe y Tempo, la L1 orientada a pagos que llegó a mainnet en marzo de 2026 — junto al Open Wallet Standard, que permite a un software manejar wallets de distintas cadenas con una sola interfaz.

La mecánica es la que ya conoces de x402: un servicio responde a la petición de un agente con un precio, el agente autoriza el pago y el servicio entrega. La implementación de Ripple corre sobre HTTP 402 con finalidad de 3 a 5 segundos, comisiones fijas por debajo del centavo y conversión nativa en el DEX del ledger.

Jazzi Cooper, responsable de producto de RippleX, lo resumió como lo hace un proveedor de infraestructura: "Nuestro trabajo es que XRP y RLUSD sean opciones de primera clase allí donde los desarrolladores estén construyendo." Ripple ya había añadido soporte de x402 en junio de 2026 — lo cubrimos en Ripple lleva x402 al XRP Ledger —, así que ahora respalda ambos estándares en lugar de apostar por uno.

Circle, por su parte, lanzó su cadena de pagos Arc el día anterior. Dos stacks de pagos agénticos compitiendo con 48 horas de diferencia es un resumen razonable de dónde está este mercado en septiembre de 2026.

El detalle de las notas de versión que le importa a quien cobra

Si pasas de los titulares hay una línea en la que conviene detenerse si eres proveedor de una API.

En XRPL, MPP admite pagos individuales en XRP, en activos emitidos como RLUSD y en Multi-Purpose Tokens. Pero los pagos por sesión — el modo de streaming donde el agente abre un canal, firma vouchers fuera de cadena mientras consume y el proveedor liquida con dos transacciones on-chain — funcionan solo con XRP. Los canales de pago son nativos del sistema de liquidación del XRP Ledger; RLUSD vive encima de ese ledger como token emitido, y extender los canales a tokens emitidos requiere una futura enmienda del XRPL que Ripple no ha calendarizado. La mecánica está en la propia documentación de XRPL.

Tradúcelo a una frase de ingresos. Si eres proveedor de una API y aceptas hoy una sesión en XRPL, el dinero que entra por tu cómputo medido es XRP — un activo volátil —, no un dólar. Puedes convertirlo, en el DEX del ledger o donde prefieras, y puedes cubrirte. Pero el comportamiento por defecto del modo de pago más nuevo y más publicitado te envía algo cuyo precio se mueve mientras sirves la petición.

No es una crítica a la ingeniería de Ripple, que hace exactamente lo que el ledger permite. Es una observación sobre qué significa "soportado" cuando tú eres quien cobra. Que una cadena lo soporte no es lo mismo que un negocio pueda usarlo.

Dos estándares, tres cadenas, y el coste cae del lado del vendedor

Da un paso atrás y mira lo que se publicó en tres semanas.

• 3 de septiembre: la Solana Foundation lanzó Payment Channels, con escrow, vouchers fuera de cadena y un benchmark medido en millones de pagos por segundo.
• 16 de septiembre: salió a público la mainnet de Arc, la cadena de Circle orientada a pagos con stablecoins.
• 17 de septiembre: Ripple conectó MPP y sesiones basadas en canales al XRPL.

Cada anuncio está escrito para quien construye el comprador. Cada uno añade una fila a una matriz que tiene que razonar el vendedor: qué protocolo (x402 o MPP), qué modo (por llamada o por sesión), qué cadena (Base, Solana, XRPL, Tempo, Polygon), qué activo (USDC, USDT, RLUSD, XRP), qué facilitator, qué estándar de wallet.

MPP es una especificación genuinamente bien hecha: define un núcleo agnóstico al método de pago con intents (cobro, autorización, suscripción), methods (implementaciones concretas por red) y extensions para descubrimiento e identidad, con SDKs en TypeScript, Python, Rust, Go y Ruby, y ha sido propuesta al IETF. Las especificaciones son públicas en github.com/tempoxyz/mpp-specs. Nada de esa calidad cambia la aritmética de una empresa de API de cinco personas: cada estándar adicional es otra integración, otra superficie de pruebas, otra cosa que mantener viva a las 3 de la mañana.

Y hay un segundo coste que se pasa por alto. Cuando los pagos MPP se procesan a través de Stripe, aterrizan en el saldo que el negocio ya tiene en Stripe, en su moneda por defecto, en su calendario de liquidación habitual y con la maquinaria de siempre. Es cómodo, y significa que el pago "nativo para máquinas" hereda el mismo modelo de custodia y de tiempos que un pago con tarjeta. Las cabeceras HTTP son nuevas. El lugar donde tu dinero espera, no.

Antes de construir: qué dicen los datos de demanda

El 9 de septiembre de 2026, TRM Labs publicó "Who's Actually Paying? Measuring AI Agent Payments Onchain", un análisis de aproximadamente 52,7 millones de dólares repartidos en 198,9 millones de transacciones de liquidación x402 en Base, Solana y Polygon desde mayo de 2025.

Tras descartar autopagos, flujos concentrados en uno o dos pagadores y vendedores con menos de diez compradores distintos, desapareció cerca de la mitad del valor liquidado. De los 25,62 millones que sobrevivieron al filtro, TRM estimó la porción realmente agéntica entre el 0,6% y el 7,5% — entre 150.000 y 1,92 millones de dólares. Su modelo estricto exigía pagos transmitidos por un facilitator, con importes variables por debajo de un dólar de media, sostenidos durante meses y con registro público del agente o pagos a varios vendedores; el modelo permisivo contaba todo lo plausible.

TRM es el tercer grupo independiente que llega a una versión de esta conclusión, después de Visa y Artemis en julio y de la auditoría de Bitquery que analizamos este mes. La lectura honesta no es "los pagos de agentes son falsos": es que el riel funciona y la demanda es temprana. La propia conclusión de TRM es que lo que falta es registro, reputación de contraparte que un agente pueda consultar por su cuenta, y monitorización pensada para volumen y no para valor.

Pero hay un número de ese informe que sí debería cambiar cómo eliges: 52,47 de los 52,68 millones liquidados — el 99,6% — fueron USDC, y prácticamente todo vendedor del catálogo declara USDC como el activo que quiere recibir. Cuando los compradores ya votaron con esa contundencia sobre el activo, añadir un riel que te paga en otra cosa es una decisión que conviene tomar a conciencia, no por defecto.

Qué conviene hacer esta semana si vendes una API

La estrategia que sobrevive a tanto ruido de estándares es aburrida y funciona: haz que probar la demanda sea barato.

No necesitas saber si gana MPP o x402, si las sesiones le ganan al cobro por llamada, ni en qué cadena se asienta la economía de agentes. Necesitas saber si algo está dispuesto a pagarte por petición — y necesitas averiguarlo con un coste de ingeniería cercano a cero, para que la respuesta "todavía no" te cueste una semana y no un trimestre.

Eso es exactamente lo que hace Payzum con x402, y conviene ser preciso con el rol, porque la palabra "facilitator" se usa a la ligera.

Payzum es el middleware — el proxy que se pone delante de tu API existente. Payzum no es el facilitator. La liquidación pasa por un facilitator externo (hoy, el de Coinbase). Tú configuras; nosotros publicamos, ponemos precio, controlamos el acceso y hacemos de proxy.

En concreto, y nada más que las capacidades reales:

• Tu API se queda exactamente como está. Sin SDK, sin protocolo que implementar, sin manejar el 402 en tu código, sin librería de wallets. Tu endpoint no aprende un idioma nuevo.
• Configuras tres cosas en un panel: la URL de tu endpoint existente, tu API key o bearer token, y un precio.
• Payzum publica una URL x402, devuelve el 402 con los requisitos de pago, gestiona el cobro a través del facilitator externo y después hace de proxy reenviando la llamada pagada a tu endpoint real con tu key, y te devuelve la respuesta.
• El dinero es USDC sobre Base y va a una wallet que tú controlas. Sin custodia: no hay saldo Payzum, no hay calendario de liquidación, no hay demora. El pago es la liquidación.
• Precios: aproximadamente las primeras 1.000 transacciones al mes son gratis y después ronda los 0,001 USD por transacción más gas.

La confirmación típica en Base ronda los dos segundos. Puedes estar sirviendo a agentes el mismo día que lo configuras, que es justo el punto: el experimento es lo bastante barato como para correrlo antes de que se resuelva la guerra de estándares.

El límite honesto: lo que Payzum no hace

Preferimos escribirlo aquí a que lo descubras en una llamada.

• Payzum no soporta MPP hoy. Ni en Tempo, ni en XRPL, ni vía Stripe. Nuestro soporte agéntico es x402.
• Payzum no hace canales de pago ni pagos por sesión. El modelo es por llamada: una petición, un precio, una liquidación. No ofrecemos streaming ni esquemas medidos tipo upto.
• Payzum no es un facilitator de x402. Somos el middleware delante de tu API; la liquidación pasa por un facilitator externo. Nos gustaría ser facilitator en el futuro. Hoy no lo somos.
• Payzum es crypto-only. Aceptamos cripto y liquidamos en cripto, con auto-conversión opcional a USDC o USDT. No liquidamos a cuentas bancarias.
• No tenemos relación comercial con Ripple, Stripe, Tempo, Circle ni la Solana Foundation. Escribimos sobre sus lanzamientos porque afectan a los mismos vendedores a los que servimos.

Las redes soportadas para aceptación de pagos habitual son Bitcoin, Ethereum, Solana, Polygon, Base, Arbitrum, Optimism, BNB Chain y Avalanche — así que un negocio puede cobrar stablecoins en Solana hoy aunque no implementemos los canales de pago de Solana.

Cómo volverte pagable por agentes, paso a paso

1. Elige un endpoint. El que tenga una unidad de valor clara: una consulta, un scrape, una generación, un score. No empieces por toda tu superficie. Empieza por la llamada que podrías tarifar en una frase.
2. Sé dueño de la wallet de destino. Crea o conecta la dirección donde deben llegar los USDC en Base. Esa dirección es la cuenta; todo lo que viene después hereda su modelo de custodia. Activa 2FA.
3. Configura el proxy. En el panel de Payzum: URL del endpoint, tu API key o bearer, y un precio por llamada. Payzum publica la URL x402.
4. Pruébalo como lo haría un agente. Llama a la URL publicada, recibe el 402, paga, reintenta y comprueba que la respuesta proxificada coincide con la de tu origen. El playground de integración y los webhooks firmados te dejan conectar el resultado a lo que ya usas.
5. Publica y mide. Lista la URL donde los agentes buscan y vigila dos números durante un mes: pagadores distintos e ingreso por pagador distinto. Esos dos te dicen si vale la pena invertir en rieles — y si se mueven, llegarás a la decisión MPP-contra-x402 con datos reales en lugar de una apuesta de roadmap.

Para quién deja esto de ser teoría

Los vendedores a los que esto les toca de cerca:

• Una API de datos o de scraping cuyos clientes humanos se registran, queman el free tier y se van. El ingreso por llamada de un agente no tiene registro, ni tarjeta, ni evento de churn: el agente paga la llamada o no la recibe. Repasamos la economía en x402 vs facturación con API key.
• Un servidor MCP al que ya llaman asistentes y que no gana nada. Cobrar por llamada a herramienta es el mismo problema de configuración que cobrar por llamada a API: lo vimos en monetizar un servidor MCP con x402.
• Un endpoint de modelo o inferencia donde un riel por sesión suena atractivo hasta que notas que te pagaría en un activo volátil. El USDC por llamada es menos elegante y muchísimo más fácil de meter en un P&L.
• Una API B2B de nicho — tarifas de flete, citas legales, propiedades químicas — cuyo mercado direccionable siempre fue pequeño en humanos y podría ser grande en agentes. Averiguarlo debería costarte una tarde.

MPP vs x402 vs Payzum: qué estás eligiendo en realidad

Objeciones frecuentes

"¿No debería esperar a que gane un estándar?"

Esperar es una postura defendible para una reconstrucción. Es una postura cara para un experimento. La razón para actuar ahora no es que x402 vaya a ganar — puede que no —, sino que el coste de ser pagable por x402 es una configuración en un panel, así que el argumento de "esperar" responde a una pregunta que nadie te pidió financiar. Si MPP termina siendo el idioma de tus compradores, habrás perdido una tarde y ganado un mes de datos reales de demanda.

"Los números de volumen dicen que no hay demanda."

Hoy, en buena medida es cierto, y lo dijimos arriba: TRM sitúa la porción realmente agéntica del valor filtrado entre el 0,6% y el 7,5%. Pero los vendedores que estuvieron vivos durante el período tranquilo son los que tienen datos, presencia en catálogo y una vía de cobro que funciona cuando llegue la demanda. La asimetría importa: llegar temprano cuesta una tarde; llegar tarde cuesta la primera camada de compradores agénticos, que encontró a otro.

"¿No es un problema contable cobrar en cripto?"

Es una pregunta legítima, y se está volviendo menos incómoda, no más: la propuesta del FASB sobre qué tenencias de stablecoins cuentan como equivalentes de efectivo sigue su proceso de comentarios, y la cubrimos en stablecoins como equivalentes de efectivo. En la práctica: USDC sobre Base, a una dirección que controlas, con registro de auditoría de cada evento, se concilia más fácil que la mayoría de los extractos de un procesador. Esto no es asesoría contable: lleva los detalles a tu contador.