La renovación moderna de HTTP 402

25 de septiembre de 2025

Cómo los pagos agénticos están reinventando un estándar de Internet de los años 90

Por Jay Yu, coescrito con Ryan Barney

Introducción

Internet nació con un “pecado original” [1]: aunque HTTP se convirtió en el lenguaje universal para mover información, nunca incorporó una forma nativa de mover dinero. Enterrado en el protocolo había un código de estado reservado – HTTP 402: Payment Required – pensado para que los pagos fueran tan fluidos como cargar una imagen o un video. Pero el 402 quedó sin definir y, en lugar de micropagos nativos del protocolo, la economía de la web se vio empujada por el camino de la publicidad, los jardines amurallados y los incómodos formularios de tarjeta de crédito.

Este artículo rastrea cómo esa reliquia abandonada de los primeros tiempos de la web ha regresado como cimiento de una economía emergente impulsada por agentes. Exploraremos por qué HTTP 402 languideció durante la primera era del comercio electrónico, cómo las stablecoins y la infraestructura blockchain están reviviendo su visión original, y cómo nuevos estándares como x402 y h402 podrían por fin absolver a Internet de su pecado original, haciendo que los pagos sean tan nativos e invisibles como la propia información.

1. El código de pago olvidado de la web

HTTP – HyperText Transfer Protocol (Protocolo de Transferencia de Hipertexto) – es la columna vertebral de la Internet moderna. Dentro del estándar HTTP existen muchos “códigos de estado”, que los servidores utilizan para decirles a los navegadores qué ocurrió cuando intentaron cargar algo. Algunos de los códigos de estado HTTP más famosos son:

HTTP 200 – OK: Todo funcionó y la página se cargó correctamente

HTTP 404 – Not Found: El recurso no existe

HTTP 500 – Internal Server Error: Algo falló en el lado del servidor

Sin embargo, aparte de estos códigos bien conocidos y ampliamente adoptados, hay muchos otros que existen en el estándar pero que rara vez se ven en la navegación cotidiana – como HTTP 402 – Payment Required, que era un código de estado reservado pero nunca estandarizado.

La visión de los años noventa para HTTP 402 era permitir que los servidores web y los navegadores negociaran pagos por contenido premium utilizando una parte estándar del protocolo web. La idea era que los servidores pudieran devolver una respuesta 402 Payment Required y que los navegadores pudieran manejar de forma nativa una etiqueta <payment>, igual que las etiquetas <img> o <video>. Los clientes enviarían entonces al servidor algún tipo de pago en “efectivo digital” para desbloquear el contenido premium.

Detrás de HTTP 402 había una visión económica de Internet que contemplaba:

Pagos nativos del protocolo: HTTP 402 imaginaba una web donde los pagos fueran tan fluidos como cargar imágenes o videos, mediante una hipotética etiqueta <payment> y una negociación entre navegador y servidor.

Economía de micropagos: El objetivo era habilitar pagos por solicitud o por artículo, convirtiendo las transacciones pequeñas y sin fricción en una característica central de la web.

Alternativa a los anuncios: Al incorporar el dinero en el propio HTTP, Internet podría haber evitado la dependencia de los modelos de negocio basados en publicidad.

Una etiqueta HTML hipotética de cómo podrían haberse integrado los pagos
a nivel de protocolo con las respuestas del servidor HTTP 402 [2].

Sin embargo, esta gran visión de la etiqueta <payment> nunca llegó a materializarse del todo. En 1994, cuando el estudiante universitario Dan Kohn realizó la primera transacción de comercio electrónico al vender un CD de Sting por Internet por $12.48, su sitio web NetMarket se basaba en acoplar los datos de la tarjeta de crédito a la web mediante cuadros de texto y un cifrado básico.

A pesar de la gran cantidad de experimentos tempranos con “efectivo digital”, como DigiCash, eCash y Hashcash, la visión original de HTTP 402 de micropagos nativos de Internet nunca se materializó. La pregunta de “qué ocurriría después de hacer clic en ese botón de compra” siguió siendo un problema difícil, con dos grandes obstáculos [1]:

Falta de interés de los actores establecidos – Las redes de pago establecidas, como Visa y Mastercard, carecían de interés y de capacidad técnica para respaldar micropagos a escala de centavos

Comisiones de procesamiento enormes – para una transacción de centavos, se podían enfrentar comisiones de transferencia de varios dólares. Esto significaba que no tenía sentido económico que Internet adoptara los micropagos

Este defecto de diseño dio lugar a lo que se ha denominado el “pecado original de Internet” [2]: que los navegadores de primera generación, como Netscape, nunca lograron incorporar los pagos de forma nativa como una operación en la especificación HTTP [3]. Esta ausencia de una forma de efectivo y de pagos digitalmente nativa influyó directamente en el modelo económico de Internet. En lugar de poder cobrar a los usuarios por el contenido premium con un modelo de “pago por visita”, los sitios se vieron obligados a adoptar un modelo publicitario para monetizar, desplazando el contenido central de la web y degradando no solo la experiencia del usuario, sino exponiendo también a usuarios desprevenidos a ataques de phishing y otras desagradables vulnerabilidades de seguridad.

Por supuesto, con el tiempo el dinero sí alcanzó a Internet. Con el auge del comercio electrónico en la década de 2000, los pagos en línea se volvieron omnipresentes, pero no de la manera en que lo imaginaron los creadores de HTTP 402. En lugar de un mecanismo nativo, a nivel de protocolo, para transferir valor, el pago se redirigió a través de intermediarios centralizados como PayPal, Stripe y, más tarde, Shopify Checkout, utilizando esencialmente el mismo método que Dan Kohn: acoplar los datos de la tarjeta de crédito a cuadros de texto cifrados.

Estos sistemas resolvieron el problema de “cómo mover dinero en línea” encerrando a los usuarios en sus propios “jardines amurallados” de API e integraciones, sorteando HTTP por completo. Cuando un usuario hacía clic en “Comprar” en un sitio web, se le redirigía a una página o widget de pago, donde introducía las credenciales de su tarjeta o de Paypal y esperaba la confirmación mientras Paypal u otro intermediario procesaba su transacción. Si bien este enfoque permitió la explosión del comercio electrónico, tenía contrapartidas evidentes:

Impulsado por personas: Cada pago presuponía a una persona frente al teclado, rellenando formularios y haciendo clic en “Pagar ahora”.

Liquidación por lotes: Los fondos se movían por infraestructuras heredadas de tarjetas y banca, y a menudo tardaban días en liquidarse.

Piso de comisiones: Las tarifas de intercambio de las redes de tarjetas (~$0.30 + un % de comisión) hacían inviables los micropagos.

Jardines amurallados: Cada procesador de pagos controlaba su propio ecosistema, encerrando a comerciantes y consumidores en flujos propietarios.

Si bien estas contrapartidas eran aceptables para comprar un suéter de $50 o un vuelo de $500, resultaron fatales para el sueño del 402 de pagos instantáneos por solicitud para contenido digital, llamadas a API u otros servicios en línea de grano fino. En resumen, el comercio electrónico prosperó, pero los pagos nativos del protocolo murieron. A diferencia del sencillo comando de la etiqueta <payment>, esto es lo que haría falta para realizar la misma compra en PayPal, obligando a los clientes a entrar en el “jardín amurallado” del SDK de Paypal:

Ejemplo de código que integra Paypal en una página HTML a través de su jardín amurallado

Y así, durante más de dos décadas, el código de estado 402 permaneció latente – una reliquia reservada pero sin definir en la especificación HTTP, a la espera de que el sueño del “dinero nativo de Internet” se hiciera realidad.

Esa infraestructura llegó por fin con la revolución de las stablecoins.

2. Stablecoins para agentes de IA: donde el dinero se encuentra con Internet

Lo que HTTP 402 imaginaba era un mundo de micropagos a escala de Internet: un sistema de efectivo entre pares tan fluido como el flujo de información entre pares. Hoy, con el auge global de las stablecoins y de una infraestructura blockchain barata y rápida, ese mundo podría estar por fin aquí. La oferta de stablecoins ha pasado de menos de $2 mil millones en 2019 a más de $246 mil millones en 2025 [4]; solo el USDC de Circle multiplicó por 29 su volumen el año pasado y salió a bolsa en la NYSE [5]. Mientras tanto, la infraestructura blockchain ha madurado, con L1 y L2 que ofrecen comisiones inferiores a un centavo – Solana promedia apenas $0.0048 por transacción – lo que hace por fin factible la visión de HTTP 402 de pagos instantáneos por solicitud.

Hoy, los asistentes de IA como ChatGPT y Claude se han filtrado en cada rincón de nuestra vida diaria y pueden ofrecer recomendaciones de productos para una amplia variedad de artículos. Sin embargo, a la hora de pagar de verdad, los procesadores actuales como PayPal y Stripe siguen presuponiendo a una persona en la caja. Por ejemplo, aunque Stripe ha estado experimentando con la emisión de “tarjetas para agentes” temporales, los procesadores de pagos pueden marcar estas tarjetas como de “alto riesgo”, lo que provoca rechazos, y los pagos de agentes de IA siempre parecen estar fuera de alcance por muy poco.

Las stablecoins, en cambio, son programables de forma nativa. Un agente de IA puede elaborar una transacción on-chain, ya sea pidiéndole al usuario que firme o ejecutándola directamente bajo una política preaprobada. De hecho, Visa estima que el 90% del volumen de stablecoins ya proviene de transacciones programáticas, y no de usuarios finales “orgánicos” [7] – una prueba del potencial y la practicidad de los pagos de máquina a máquina. Al fin y al cabo, es mucho más fácil para un agente de IA obtener acceso a una clave privada que a una cuenta bancaria.

Así, es fácil imaginar un mundo en el que los agentes de IA no solo recomienden qué comprar, sino que también lo compren en nuestro nombre, usando stablecoins como USDC como su capa de ejecución. De este modo, ERC20.transfer por fin materializa la funcionalidad que la etiqueta <payment> imaginó originalmente – la de un sistema de dinero abierto y entre pares, tan programático como la propia Internet. En otras palabras, las stablecoins que circulan por infraestructura blockchain resuelven por fin la pregunta de “¿qué ocurre después de hacer clic en el botón de compra?”.

3. Implementaciones técnicas del estándar HTTP 402

Flujo de pago HTTP 402. Fuente: contenido original

Entonces, ¿cómo podría ser la renovación moderna de HTTP 402 en la era de los pagos agénticos? Hoy, varios equipos han propuesto soluciones, entre ellas el estándar x402 de Coinbase, el estándar h402 de BitGPT y EVMAuth de Radius Tech. A grandes rasgos, todas implican los siguientes pasos:

1. El usuario le pide a un agente que realice una acción y financia una política con el monto de la transacción

2. El agente enviará una transacción a un sitio web y recibirá una respuesta 402, también llamada “desafío”.

a. Este desafío incluirá detalles como la billetera del comerciante, las cadenas aceptadas, los activos y el valor del bien o servicio.

3. Al recibir este desafío, el agente lo reenviará a un “facilitador de pagos”, que puede ser el usuario final o un servicio de billetera de custodia. Este “facilitador” comparará la información del desafío con una política de transacciones (p. ej., ¿es <100 USDC?, ¿es un dominio incluido en la lista blanca?)

4. Si el facilitador aprueba la transacción, la enviará a la billetera del comerciante, y el agente enviará el comprobante de pago (p. ej., el hash de la transacción) al comerciante mediante la misma API.

5. El comerciante confirma el pago y entrega el bien o servicio.

Sin embargo, todos estos marcos difieren en los detalles de sus implementaciones, principalmente en tres aspectos [10]:

1. Esquema del desafío – es la “forma” de las respuestas HTTP 402 que reciben en el paso 2.

2. Política del facilitador – las reglas y restricciones que los facilitadores imponen al método y a la política de pago.

3. Forma del comprobante de pago – el tipo de “recibo” que devuelven al servidor

Es importante señalar que no son necesariamente estos estándares en sí los que se monetizan, ya que todos son de código abierto. Más bien, empresas como Coinbase, BitGPT y Radius aspiran a monetizar operando los “facilitadores de pagos” que procesan los flujos de su sistema HTTP 402. Después de todo, la empresa que cree el estándar universal tendrá naturalmente una ventaja para crear el facilitador de pagos dominante. Es similar a cómo HTTP es un protocolo público, pero Chrome y Mozilla se monetizan operando navegadores web que recopilan el tráfico de los usuarios.

Además, estos estándares HTTP 402 también son componibles con marcos de comunicación agéntica más amplios. Por ejemplo, Google anunció recientemente su protocolo Agent-to-Agent (A2A), un sistema que permite a los agentes de IA comunicarse entre sí y completar pasos de múltiples tareas [19], en colaboración con el protocolo x402 de Coinbase. Mientras que A2A ofrece una capa común de interoperabilidad para que los agentes compartan datos y flujos de trabajo, x402 se integra como una extensión de pago dentro del Agentic Payments Protocol (AP2) de Google. Con x402 sobre el marco A2A de Google, los usuarios pueden comprar un refrigerador en Lowes con solo conversar con un agente de IA [20], lo que marca el comienzo de una nueva era del comercio electrónico

4. El futuro de la adopción de HTTP 402

Con lo anterior, vemos que en cada una de estas implementaciones del estándar HTTP 402 existe una disyuntiva entre la componibilidad (tipos de cadenas y activos) y la distribución (integración con proveedores). Pero ¿cuáles son los ingredientes fundamentales necesarios para que esto realmente despegue y se convierta en el estándar de referencia para los pagos agénticos? Creo que la adopción de HTTP 402 depende del mayor crecimiento de cuatro componentes entrelazados: 1) integraciones del lado del cliente, 2) adopción por parte de los proveedores, 3) proveedores de facilitadores, 4) infraestructura subyacente de stablecoins.

Integraciones del lado del cliente – ¿cómo es la interfaz de usuario para el usuario final?

Aunque HTTP 402 se posiciona como un sistema “de agente a agente”, la demanda o la intención final tiene que provenir de algún lugar. Volviendo al caso en que decido comprar unos jeans en Amazon, tiene que haber alguna interfaz (como la interfaz de chat de Claude) que capture lo que necesito o quiero. Estas interfaces de usuario pueden instanciarse de múltiples maneras. La más común es probablemente un servidor MCP (como el servidor MCP de x402 que ofrece CDP) con un chatbot popular como Claude o ChatGPT. Alternativamente, podría darse como un navegador web potenciado con IA, similar al Dia Browser de The Browser Company, o quizá una interfaz de hardware, como un reloj inteligente o un dispositivo vestible potenciado con IA. Openmind, por ejemplo, lleva la visión de pagos agénticos de x402 al ámbito de la robótica, permitiendo que los robots se paguen entre sí por servicios colaborativos [14].

Adopción por parte de los proveedores – ¿qué pueden comprar realmente estos agentes habilitados para HTTP 402?

Este es quizá uno de los componentes en los que más cuesta ganar tracción, pues para que estos agentes de pago realmente la ganen, deben poder comprar servicios a proveedores tradicionales de comercio electrónico, como Amazon, o a proveedores de contenido por suscripción, como el New York Times. Esto requiere una cantidad monumental de adhesión por parte de proveedores establecidos que pueden mostrarse reacios a adoptar con rapidez las criptomonedas y los pagos agénticos. De hecho, muchos de los proveedores existentes integrados en x402 son empresas cercanas al mundo cripto, como Pinata para la carga y descarga en IPFS, Heurist para la investigación agéntica profunda e Hyperbolic para la inferencia de LLM [15] [16]. No obstante, a medida que los pagos con criptomonedas se vuelvan masivos, es probable que esta lista se amplíe con el tiempo. x402 también tiene una “página de descubrimiento” que señala muchos de los proyectos del ecosistema y destaca integraciones en vivo como Prodia para generación de imágenes, firecrawl para rastreo web y diversos wrappers comunitarios de LLM, búsqueda web y datos bursátiles.

Proveedores de facilitadores – ¿quién controla los cordones de la bolsa?

Los facilitadores desempeñan un papel clave en el flujo de trabajo de HTTP 402, ya que pueden decidir si se autoriza o no una solicitud de pago de un agente. De hecho, podría decirse que los facilitadores tienen el papel más lucrativo, ya que pueden monetizar mediante (1) el cobro de tarifas fijas de servicio a usuarios y agentes por custodiar fondos y mantener la seguridad de las políticas, y (2) la obtención de una parte del flujo de órdenes de transacciones. Dado que HTTP 402 es, en esencia, un protocolo de código abierto, muchas de las empresas que impulsan su adopción, como Coinbase, BitGPT y Radius, obtienen beneficios de este sistema operando el facilitador de estos pagos.

A medida que este estándar madure, es posible que otros actores del espacio de wallet-as-a-service y de custodia, como Privy y Turnkey, desempeñen un papel mayor en la facilitación de estos sistemas, así como sistemas de billeteras nativos de IA como Circuit AI y sistemas académicos como Liquefaction. Curiosamente, casi todos estos motores de políticas se basan en Entornos de Ejecución de Confianza (TEE) para la gestión de claves y la ejecución de políticas.

Infraestructura subyacente de stablecoins – ¿cómo se procesa el pago?

Como se ha reiterado a lo largo de este artículo, las stablecoins son esenciales para el renacimiento y el crecimiento futuro de HTTP 402. Las mejoras en la infraestructura subyacente de stablecoins y en la pila de pagos acelerarán sin duda la adopción de HTTP 402 como estándar y catalizarán un mayor crecimiento. En los últimos años, la pila de pagos con stablecoins ha madurado enormemente, con muchos actores que tienden puentes entre las infraestructuras de pago tradicionales y las stablecoins.

Por ejemplo, Coinflow ofrece un servicio de un clic para que los comerciantes reciban pagos y desembolsos en stablecoins. BVNK, Bridge (adq. por Stripe) y otros facilitan la orquestación de pagos entre stablecoins y los sistemas financieros tradicionales. OpenFX permite pagos transfronterizos con liquidaciones de divisas en tiempo real. Gateway y CCTP de Circle permiten que USDC se mueva sin fricciones entre las distintas blockchains con las que está integrado [17], y NEAR Intents también permite lógica de negocio entre cadenas para los flujos de trabajo de HTTP 402 [18]. Las mejoras en todas estas infraestructuras subyacentes harán que los pagos HTTP 402 impulsados por stablecoins sean más rápidos, más baratos y más interoperables, reduciendo en última instancia la fricción tanto para desarrolladores como para usuarios finales.

Conclusión

Han pasado más de 30 años desde que se propuso por primera vez HTTP 402, y durante ese tiempo el código de estado ha servido como marcador de posición de una forma de dinero nativa de Internet que nunca llegó del todo. Pero hoy las piezas podrían por fin estar encajando: las stablecoins aportan efectivo programable, los agentes de IA se convierten en consumidores autónomos de contenido, y nuevos estándares como x402 y h402 lo cosen todo.

Entonces, ¿qué podría significar todo esto para el usuario cotidiano?

Imagine que le pide a su asistente impulsado por Claude que elabore un informe de investigación. En silencio, este consulta diez API distintas – bases de datos de noticias, generadores de imágenes, endpoints de inferencia de modelos – y paga a cada una unos pocos centavos mediante una billetera de políticas que usted ha preaprobado. Sin caja. Sin formularios de tarjeta de crédito. Sin cookies que lo rastreen por la web. Solo una intención limpia y programática, ejecutada sin fricciones.

O piense en una plataforma de desarrollo empresarial donde las aplicaciones ya no se facturan mensualmente por usuario, sino de forma dinámica por ciclo de cómputo o por llamada de inferencia. Los agentes miden el uso y autorizan los pagos en su nombre. Los presupuestos se convierten en políticas. Las suscripciones se convierten en flujos. Las finanzas se convierten en código. En este mundo, HTTP 402 se convierte en un medio de intercambio agéntico, parte de un flujo de trabajo más amplio que permite a los agentes de IA no solo generar recomendaciones, sino también realizar transacciones con valor del mundo real.

Y un día, quizá su primo abra un panel de depuración y comente con naturalidad: “Ah sí, mi IA se topó con un 402 hace un rato y recargó los créditos”, sin pensarlo dos veces. Igual que “404 Not Found”, “402 Payment Required” podría por fin entrar en el léxico cultural, no como una reliquia de la web primitiva, sino como un verbo nativo de la siguiente.

Y quizá ese sea el día en que Internet por fin se absuelva de su “pecado original”.

Muchas gracias a Mason Nystrom de Pantera, Daniel Lev de Coinflow, Lia Muller Pena de BitGPT y Lincoln Murr de Coinbase Developer Platform por sus comentarios y sugerencias.

Si está construyendo una red de pagos de última generación, ¡póngase en contacto con jay@panteracapital.com!