MPP: la respuesta de Stripe y Tempo a x402, auditada desde la spec

Ya existen dos protocolos en producción que convierten HTTP 402 en un rail de pagos para máquinas. Uno lo cubrimos desde hace meses. El otro lo firma Stripe, corre sobre una L1 construida a medida y siguió publicando specs hasta la semana pasada. Clonamos el repo y lo leímos completo.

El Machine Payments Protocol (MPP) es un estándar abierto de pagos machine-to-machine coescrito por Tempo — la L1 de pagos incubada por Stripe y Paradigm — y por el propio Stripe. Se lanzó el 18 de marzo de 2026, el mismo día en que salió a mainnet Tempo y el mismo día en que la versión 01 de su spec core llegó al IETF. Desde entonces solo apareció de pasada en nuestra cobertura: AWS listó a Stripe y MPP como facilitators "coming soon" en su lanzamiento de monetización en WAF, y OSL AgentPay embarcó x402, AP2 y MPP a la vez. Para un protocolo tan bien posicionado, eso no alcanza. Esta es la lectura completa.

Para esta auditoría clonamos tempoxyz/mpp-specs el 10 de agosto de 2026 (HEAD f9506cd, commit del 7 de agosto). El repo contiene 23 documentos de especificación que suman unas 125,000 palabras: una spec core, dos intents, dieciocho documentos de método repartidos en diez familias de pago y dos extensiones. Las specs están dedicadas al dominio público bajo CC0 1.0. Primer commit: 5 de enero de 2026. Lanzamiento público: 18 de marzo. Es un conjunto de documentos joven, y se nota — en aspectos que importan, como vamos a mostrar.

Un scheme de autenticación, no un par de headers

La decisión de diseño más importante de MPP es dónde vive dentro de HTTP. x402 v2 define su propia familia de headers — PAYMENT-REQUIRED, PAYMENT-SIGNATURE, PAYMENT-RESPONSE — que viaja junto al status code pero fuera de la maquinaria de autenticación de HTTP. MPP en cambio registra Payment como scheme de autenticación HTTP, junto a Basic y Bearer en el registro de IANA. El challenge llega en WWW-Authenticate; la prueba vuelve en Authorization.

HTTP/1.1 402 Payment Required
Cache-Control: no-store
WWW-Authenticate: Payment id="x7Tg2pLqR9mKvNwY3hBcZa",
    realm="api.example.com",
    method="tempo",
    intent="charge",
    expires="2026-08-10T12:05:00Z",
    request="eyJhbW91bnQiOiIxMDAwIi4uLg"

// el cliente cumple el pago y reintenta:
GET /resource HTTP/1.1
Authorization: Payment eyJjaGFsbGVuZ2UiOnsuLi59LCJwYXlsb2FkIjp7Li4ufX0

El parámetro request es JSON codificado en base64url, canonicalizado con JCS (RFC 8785) para que toda implementación produzca bytes idénticos. La credencial hace echo del challenge completo más un payload específico del método y un campo opcional source para la identidad del pagador, donde la spec recomienda DIDs del W3C. Las respuestas exitosas llevan un header Payment-Receipt. Los errores usan Problem Details de RFC 9457 con vocabulario registrado (payment-insufficient, verification-failed, invalid-challenge). La semántica de status codes está explícita: 402 para toda barrera de pago incluida la verificación fallida, 401 reservado para autenticación no relacionada con pago, 403 cuando el pago fue válido pero la política deniega el acceso.

Dos detalles merecen atención porque x402 carece de ambos. Primero, el challenge binding: la spec recomienda computar el id del challenge como un HMAC-SHA256 sobre siete slots posicionales fijos (realm, method, intent, request, expires, digest, opaque), lo que da al servidor challenges stateless y a prueba de manipulación sin lookup en base de datos — el mismo truco del binding de batch de Cloudflare, pero especificado normativamente con un layout de slots diseñado para sobrevivir extensiones futuras. Segundo, Accept-Payment: un header de request con semántica completa de negociación de contenido — q-values, wildcards como tempo/* y exclusiones con q=0 — que permite a un agente declarar qué combinaciones de método e intent puede pagar antes de que el servidor elija qué challenges emitir. x402 no tiene nada comparable; el buyer recibe el array accepts que el seller haya configurado. Para un cliente con una wallet y una tarjeta, la pre-negociación elimina un round trip y toda una clase de challenges incumplibles.

También notable: la spec core exige Cache-Control: no-store en todo 402 y Cache-Control: private en respuestas con receipt. Cuando auditamos los despliegues de x402 en el edge a principios de agosto, encontramos que las specs de x402 tenían cero ocurrencias de Cache-Control mientras los SDKs convergían en exactamente este comportamiento vía PRs de parche. MPP lo tuvo como MUST en el documento core desde el inicio. Eso es lo que compra escribir en la capa HTTP, al estilo IETF.

Intents y methods en lugar de schemes y networks

La modularidad de MPP corta distinto que la de x402. Donde x402 tiene schemes (exact, upto, batch-settlement) cruzados con network bindings, MPP separa intents — qué tipo de pago: charge (único), session (streaming), subscription (recurrente, mergeado el 29 de julio con implementaciones de Stripe y Tempo) — de methods, los rails concretos. El directorio de methods cubre hoy diez familias: tempo, stripe, card, usdc, evm, solana, lightning, nearintents, stellar y hedera. Las últimas adiciones son del 7 de agosto: un session intent para Hedera, soporte de confidential transfers de Solana en el flujo de charge, y un endurecimiento del modo operator-signed de las sessions de Solana.

Vuelve a leer esa lista. Card. Lightning. Stripe. Es el corte filosófico más profundo con x402, que es stablecoin-only por construcción. El core de MPP es agresivamente agnóstico al método de pago — su principio de diseño declarado es "no implicit advantages for any currency or asset" — y el mismo array de challenges de un 402 puede ofrecer una transferencia de stablecoin en Tempo junto a un cobro con tarjeta junto a un invoice de Lightning, dejando elegir al cliente. El Agentic Commerce Protocol resolvió el fiat para agentes en la capa de checkout; MPP lo resuelve en la capa HTTP, por request.

La otra diferencia estructural: MPP no tiene facilitator. x402 externaliza verificación y settlement en un rol de API dedicado que generó un mercado de proveedores hosteados. En MPP el servidor liquida directo — contra el API de Stripe, contra un RPC de Tempo, contra un nodo Lightning. Eso elimina un intermediario de confianza y un choke point de metadata, pero también significa que cada seller integra cada rail que quiera aceptar. El mercado de facilitators es la respuesta de x402 a esa carga de integración; la de MPP, por ahora, son SDKs en TypeScript, Python, Rust, Go y Ruby, más samples oficiales de Stripe.

Sessions: payment channels como primitivo de primera clase

El documento técnicamente más interesante del repo es la spec de session de Tempo. Define payment channels de streaming unidireccionales: el cliente deposita en un escrow on-chain y luego firma vouchers EIP-712 off-chain con montos acumulativos monotónicamente crecientes a medida que consume el servicio. El servidor verifica cada voucher por HTTP — sin tocar la chain — y liquida periódicamente o al cierre, recibiendo cumulativeAmount − settled en una sola transacción. El caso de uso estrella de la propia spec es un API de inferencia LLM que cobra por token de salida, con unidad de precio llm_token en el challenge.

// request del challenge para una session (decodificado)
{
  "amount": "25",              // precio por unidad, base units
  "unitType": "llm_token",
  "suggestedDeposit": "10000000",
  "currency": "0x20c0…",        // token TIP-20
  "recipient": "0x742d…",
  "methodDetails": { "escrowContract": "0x1234…", "chainId": 4217, "sessionProtocol": "v2" }
}

El ciclo de vida corre por cuatro acciones de payload — open, topUp, voucher, close — todas enviadas a la misma URI del recurso, así que no existen rutas dedicadas de control de pago. Los channels no expiran; la salida del cliente es un forced close con un periodo de gracia de 15 minutos que da al servidor tiempo de aterrizar su último voucher. Hay dos backends: v1 con escrow por contrato (dominio EIP-712 "Tempo Stream Channel", montos uint128) y v2 sobre un precompile de channels TIP-20 (dominio "TIP20 Channel Reserve", uint96), con patrocinio de fees donde el servidor co-firma la transacción de fondeo del cliente usando el formato de transacción de doble firma de Tempo. Para respuestas en streaming la spec define incluso un evento SSE, payment-need-voucher, que pausa la entrega a mitad del stream hasta que el cliente firme un voucher mayor — inferencia medida con flow control in-band.

Compara esto con lo que ofrece x402 para el mismo problema. El scheme upto autoriza un máximo y liquida el uso real vía Permit2 — una autorización, un settlement, por ciclo de request. Los Nanopayments de Circle agrupan miles de firmas off-chain contra un balance compartido en Gateway, con el TEE de Circle como operador del batching. Las sessions de MPP son la tercera arquitectura: escrow por relación, vouchers acumulativos, sin operador entre pagador y cobrador. Es capital-backed como el diseño de Circle — los fondos se bloquean antes del servicio — pero bilateral y sin operador, como un state channel clásico. El costo es la fragmentación de capital (cada par pagador-cobrador necesita su propio channel fondeado) y la carga contable que la spec documenta con honestidad: el servidor MUST persistir el estado de vouchers y los contadores de gasto en almacenamiento durable antes de entregar servicio, o pierde fondos ante un crash.

El rail fiat: Shared Payment Tokens

El método Stripe es donde MPP deja de parecer un protocolo cripto. El cliente crea un Shared Payment Token de un solo uso (spt_…) vía el API de Stripe, con límites de uso en moneda, monto máximo y expiración. La credencial lleva el id del SPT; el servidor lo redime creando un PaymentIntent con shared_payment_granted_token y confirm: true, y devuelve 200 cuando el estado del intent es succeeded. Tarjetas, Link y por extensión BNPL — todo lo que procesa Stripe — fluye por el mismo intercambio 402 que una transferencia de stablecoin, y aterriza en el dashboard de Stripe existente del merchant con su calendario de payouts habitual. Ambos lados necesitan cuenta de Stripe, y la spec soporta settlement con Stripe Connect (fees de plataforma, destinos de transfer) como política server-side que MUST NOT aparecer en el challenge.

Es el mismo patrón custodial-tokenizado del Delegated Payment Spec de ACP — un token con allowance acotada en lugar de una tarjeta — pero sin la maquinaria de checkout sessions y embebido a nivel de request. Para operadores de agentes la implicación es real: un agente que paga por MPP no necesita tener cripto en absoluto. Necesita una cuenta de Stripe y un método de pago. Eso amplía enormemente la base direccionable, al precio de cuentas, KYC y reversibilidad — todo lo que el modelo walk-up de x402 fue diseñado para evitar.

Discovery, escrito por el equipo de x402scan

La extensión de discovery es corta y pragmática: los servicios publican un documento OpenAPI 3.x en /openapi.json anotado con x-service-info (categorías, links de docs, llms.txt) y arrays de ofertas x-payment-info por operación — intent, method, amount (con null para pricing dinámico), currency. El challenge del 402 sigue siendo autoritativo; el discovery es orientativo. Un apéndice informativo especifica el comportamiento de registries: re-crawl al menos cada 24 horas, delist tras 7 fallos consecutivos, límite de 64 KB.

La autoría es la parte interesante. Junto a dos autores de Tempo, la spec está coescrita por Ryan Sproule y Sam Ragsdale de Merit Systems — el equipo detrás de x402scan, el mayor explorador independiente de x402. El documento acredita explícitamente el enfoque OpenAPI-first de x402scan como prior art, y x402 acumula 8 de las citas del repo. La gente que construyó la capa de discovery de facto de x402 escribió la oficial de MPP. Contrasta con la respuesta propia de x402, el Bazaar, que rankea por actividad de settlement observada: el discovery de MPP es auto-declarado y crawleado, el Bazaar está evidenciado por settlements. El argumento de resistencia Sybil favorece a x402; el de funcionar sin facilitator favorece a MPP.

Transporte MCP: error −32042

MPP también especifica cómo viaja el scheme Payment sobre JSON-RPC y MCP. Un tool call pago falla con el código de error -32042 ("Payment Required") llevando un array challenges en error.data — como JSON nativo, no base64url, con canonicalización JCS y hashing que preservan el challenge binding. El cliente reintenta con la credencial bajo _meta["org.paymentauth/credential"], y el receipt vuelve bajo _meta["org.paymentauth/receipt"]. La verificación fallida es -32043 con challenge fresco. Tool calls, lecturas de resources y fetches de prompts están cubiertos, y las notificaciones con pago requerido se descartan explícitamente.

Es un diseño in-band más limpio que la historia MCP de x402, que enhebra el pago por _meta en respuestas por lo demás exitosas. Pero también es donde la spec muestra su edad, como explica la sección de auditoría.

Qué encontró la auditoría

Leímos las specs como leímos x402-rs y el repo del TAP de Visa: sin asumir nada, decodificando todo. Tres hallazgos sobrevivieron la verificación.

Ninguno es un defecto arquitectónico. Son las huellas de una spec escrita rápido por un grupo chico: el historial de git muestra 68 commits de 17 contribuyentes humanos, con un solo ingeniero de Tempo (Brendan Ryan) firmando 20. Compara los números: mpp-specs tiene 87 stars, 52 forks y 17 issues abiertos; el repo de x402 que auditamos la semana pasada supera los mil commits con SDKs en 2.20.0. Brecha de madurez, no techo de calidad.

Gobernanza: dos empresas y un draft individual

La postura ante el IETF merece precisión, porque "IETF draft" hace trabajo de marketing en casi toda la cobertura de MPP. draft-ryan-httpauth-payment es una individual submission — cinco autores, tres de Tempo Labs y dos de Stripe — con intended status Standards Track, sin adopción por working group, sin stream del IETF y con expiración el 19 de septiembre de 2026. Es un primer paso legítimo en la ruta de estándares, el mismo que recorrió Web Bot Auth antes de que se formara su working group. Pero hoy tiene exactamente el standing de cualquier draft personal que expira en seis meses, y el hogar normativo de la especificación sigue siendo un repo gobernado por dos empresas. x402 eligió el trade-off opuesto: headers custom sin bendición de IANA, pero un hogar en la Linux Foundation con 40 organizaciones miembro. Un protocolo tiene forma de estándar sin gobernanza neutral; el otro tiene gobernanza neutral sin forma de organismo de estándares.

La adopción refleja la diferencia de edad. El post de lanzamiento de Stripe nombra adoptantes tempranos — Browserbase cobrando por sesión de headless browser, Parallel Web Systems vendiendo acceso web por llamada de API — y Tempo aporta un peso institucional inusual: una Serie A de $500 millones a una valuación reportada de $5,000 millones antes de mainnet, finalidad determinista sub-segundo, sin token de gas nativo (fees pagados en stablecoins vía un AMM del protocolo), y Stripe, Visa y Zodia Custody como primeros validadores externos de una red aún permisionada. Pero los números de throughput de x402 — cientos de millones de transacciones acumuladas, sea cual sea la fracción orgánica — siguen un orden de magnitud por encima de lo que MPP haya reportado. La lectura realista de 2026: x402 es dueño de la economía de agentes cripto-nativa; MPP es el primer puente creíble de esa economía hacia la base instalada de las redes de tarjetas, y Stripe soporta ambos.

Qué significa para LLM4Agents

LLM4Agents vende inferencia a través de un gateway OpenAI-compatible liquidado por llamada sobre x402 y EIP-3009. MPP toca esa posición por tres lados.

Primero, el session intent apunta exactamente a nuestro workload. El billing de streaming por token con flow control de vouchers in-band calza mecánicamente mejor con inferencia LLM que el settlement exact por request, y el ejemplo insignia de la spec es un API de LLM. Si las sessions de MPP ganan tracción entre vendedores de inferencia, "pagar por token de salida sobre un channel" se vuelve una forma de pricing que los buyers esperan, y nuestro billing reserve-then-settle — que ya mide uso real — mapea sobre ella con más naturalidad que sobre el upto de x402. Segundo, Accept-Payment y los challenges multi-método significan que un solo 402 puede ofrecer rails de stablecoin y tarjeta a la vez. Un gateway que respondiera con un challenge x402 y un challenge MPP sería pagable por cualquier agente, con fondos cripto o con tarjeta. Nada en ninguno de los dos protocolos prohíbe emitir ambas familias de headers en una misma respuesta. Tercero, la amenaza: MPP con rails de Stripe reintroduce cuentas, KYC y chargebacks en los pagos de máquinas. Si los compradores enterprise se estandarizan en agentes con tarjeta, el modelo walk-up sin cuenta que nos diferencia pasa a ser nicho en lugar de default. El árbol de decisión bearer versus walk-up gana una tercera rama, y es propiedad del procesador de pagos más grande de internet.

Cómo mantenerse en la frontera

Movimientos concretos, en orden. Primero, prototipar respuestas de doble challenge: emitir nuestro header x402 PAYMENT-REQUIRED existente y un challenge MPP WWW-Authenticate: Payment en el mismo 402 para una ruta de prueba, y medir qué se rompe en clientes reales. Segundo, implementar el charge intent de MPP como receptor usando el método Tempo en testnet — la verificación de credenciales es más simple que el round trip del facilitator de x402, y la superficie de SDK (TypeScript vía mppx) es chica. Tercero, mapear nuestro pipeline reserve-proxy-settle sobre el modelo contable del session intent (acceptedCumulative / spent / settled) y publicar la comparación; si algún día lanzamos billing por channels, ese documento se convierte en el diseño. Cuarto, subir upstream los tres hallazgos de arriba — los desajustes de ejemplos decodificados y el anclaje a la revisión de MCP son exactamente los issues que un repo de specs joven quiere recibir, y el standing de contribuyente en una spec de dos empresas es barato ahora y caro después. Quinto, vigilar dos fechas: el 19 de septiembre, cuando el draft actual del IETF expira y o se refresca o se adopta, y el momento en que el transporte MCP migre al framework de extensiones de 2026-07-28 — porque la primera extensión de pago bendecida en el registro oficial de MCP, descienda del -32042 de MPP o del flujo _meta de x402, va a fijar el default para todo host de agentes que venga después.