La proliferación de agentes de IA autónomos que interactúan con servicios web ha expuesto una brecha fundamental en la infraestructura de pagos de internet: la ausencia de un mecanismo estandarizado para que las máquinas paguen a otras máquinas. Si bien HTTP/1.1 reservó el código de estado 402 ('Payment Required') hace décadas, nunca se estandarizó formalmente, dejando a los agentes de IA sin una forma nativa y eficiente de monetizar sus interacciones. Los métodos de pago existentes, optimizados para la interacción humana (formularios, CAPTCHAs), son ineficientes y frágiles para la automatización programática.
El Machine Payments Protocol (MPP) aborda este problema al formalizar el uso del código 402, proporcionando una interfaz de pago HTTP diseñada específicamente para agentes. Su objetivo es desacoplar el mecanismo de pago de la lógica de negocio, permitiendo transacciones programáticas seguras y de baja latencia. Esto es crucial para habilitar un ecosistema de "economía de agentes" donde los servicios pueden ser consumidos y pagados a escala de máquina, sin la fricción de los procesos de pago tradicionales.
Arquitectura del Sistema
MPP opera como un esquema de autenticación HTTP, propuesto como draft-httpauth-payment-00. Su arquitectura central se basa en un patrón de desafío-respuesta. Un cliente (agente AI) realiza una solicitud HTTP; si se requiere pago, el servidor responde con un HTTP 402 y un encabezado WWW-Authenticate: Payment que especifica los requisitos de pago. Este encabezado incluye parámetros clave como id (identificador único del desafío, verificado sin estado mediante HMAC-SHA256), realm, method (ej. tempo, stripe, solana, card), intent (ej. charge para pagos únicos, session para streaming) y request (JSON codificado en Base64url con detalles de pago, serializado con JSON Canonicalization Scheme - JCS RFC 8785).
El cliente cumple el desafío (firmando una transacción, pagando una factura, etc.) y reintenta la solicitud original con un encabezado Authorization: Payment que contiene la prueba de pago. Tras la verificación, el servidor entrega el recurso y un encabezado Payment-Receipt con el estado de liquidación. La modularidad es una decisión de diseño clave: el protocolo central es agnóstico al método de pago, definiendo el flujo y el modelo de seguridad. Los métodos de pago concretos (ej. Tempo, Stripe, Card, Solana) se definen en especificaciones IETF separadas, permitiendo la extensión del protocolo sin modificar su núcleo. El session intent es una diferenciación arquitectónica, donde los agentes depositan fondos en un contrato de escrow y emiten vouchers firmados EIP-712 con cada solicitud, verificados vía ecrecover para latencias sub-100ms, permitiendo el batch-settlement de miles de micro-interacciones en una única transacción on-chain.
Flujo de Pago MPP (Challenge-Response)
- 1 Agente AI Envía solicitud HTTP a recurso.
- 2 Servidor Responde HTTP 402 con WWW-Authenticate: Payment (id, method, intent, request).
- 3 Agente AI Cumple el desafío (ej. firma transacción, autoriza tarjeta).
- 4 Agente AI Reintenta solicitud con Authorization: Payment (prueba de pago).
- 5 Servidor Verifica prueba de pago y liquida.
- 6 Servidor Entrega recurso y Payment-Receipt (estado de liquidación).
Flujo de Sesión MPP (Streaming Micropayments)
- 1 Agente AI Deposita fondos en contrato de escrow (on-chain).
- 2 Agente AI Envía solicitud con voucher EIP-712 firmado (off-chain).
- 3 Servidor Verifica voucher vía ecrecover (sin RPC/DB).
- 4 Servidor Entrega recurso.
- 5 Agente AI / Servidor Repite N veces (miles de micropagos).
- 6 Contrato Escrow Batch-settlement on-chain al finalizar sesión. Fondos no usados reembolsados.
| Capa | Tecnología | Justificación |
|---|---|---|
| networking | HTTP/1.1 (RFC 9110) | Protocolo de transporte fundamental, utilizando el código de estado 402 'Payment Required' como base para el mecanismo de desafío-respuesta. |
| security | TLS | Requisito obligatorio para todas las comunicaciones MPP para garantizar la confidencialidad e integridad de los datos de pago. |
| security | HMAC-SHA256 | Utilizado por los servidores para vincular el identificador de desafío (`id`) a los parámetros de pago, permitiendo la verificación sin estado de las credenciales y la protección contra la manipulación. |
| data-processing | JSON Canonicalization Scheme (JCS, RFC 8785) | Asegura una codificación determinista de los objetos JSON en los parámetros de desafío, crucial para la verificación criptográfica consistente entre cliente y servidor. |
| messaging | EIP-712 (Ethereum Improvement Proposal 712) | Estándar para la firma de datos estructurados en Ethereum, utilizado en las sesiones de streaming de MPP para firmar vouchers de micropagos de forma eficiente y segura. |
| compute | ecrecover (Ethereum elliptic curve signature recovery) | Función criptográfica utilizada por los servidores para verificar la autenticidad de los vouchers firmados EIP-712 en las sesiones de streaming, sin necesidad de llamadas RPC o consultas a bases de datos. |
| storage | Contratos de Escrow (on-chain) | Mecanismo para depositar fondos de forma segura al inicio de una sesión de streaming, permitiendo el batch-settlement y el reembolso automático de fondos no utilizados. |
| data-processing | W3C Decentralized Identifiers (DID) | Formato recomendado para identificar al pagador (`source` field) en las credenciales de pago, promoviendo la privacidad y la interoperabilidad. |
Trade-offs
Ganancias
- ▲ Latencia de micropagos
- ▲▲ Costo de micropagos (on-chain)
- ▲ Estandarización de pagos máquina-a-máquina
- ▲ Soporte multi-rail (fiat y crypto)
Costes
- △ Permisionless (vs. x402)
- △ Dependencia de proveedores (Stripe, Tempo)
Fundamentos Teóricos
El problema de los micropagos eficientes y seguros en sistemas distribuidos ha sido un tema recurrente en la investigación de la computación. Conceptos como los canales de pago (payment channels) y las redes de canales de pago (payment channel networks), popularizados en el contexto de las criptomonedas (ej. Lightning Network para Bitcoin), buscan resolver la latencia y el costo de las transacciones on-chain para pagos de bajo valor y alta frecuencia. El session intent de MPP, con su modelo de depósito en escrow y vouchers firmados, es una aplicación directa de estos principios, permitiendo la agregación de múltiples micropagos fuera de la cadena antes de una liquidación final on-chain.
La formalización de un esquema de autenticación HTTP para pagos se alinea con la evolución de los protocolos de seguridad web. El uso de un patrón de desafío-respuesta es un principio fundamental en la autenticación HTTP (RFC 9110), similar a los esquemas Basic o Digest. La necesidad de un identificador de desafío único (id) y su verificación sin estado mediante HMAC-SHA256 para prevenir ataques de replay y garantizar la idempotencia, refleja principios de seguridad de protocolos distribuidos bien establecidos, donde la verificación criptográfica de la integridad de los mensajes es primordial para la confianza en entornos sin estado.