Los agentes de IA ahora pueden pagar de forma autónoma gracias a x402 y HTTP 402

Es enero de 1997. El (Internet Engineering Task Force) acaba de lanzar Definido oficialmente La especificación fue creada por los pioneros web , de , de , de , y Los arquitectos que formaron la forma en que Internet se comunica. IETF RFC 2068 HTTP/1.1 por Roy Fielding Jim Gettys Jeffrey Mogul HENRIK FRYSTYK por Tim Berners-Lee IETF RFC 2068 por Roy Fielding Jim Gettys Jeffrey Mogul HENRIK FRYSTYK por Tim Berners-Lee La especificación introduce : previously, every single HTTP request required a fresh TCP connection. Persistent connections resolve this, allowing multiple HTTP requests to flow through a single, long-lived TCP connection. No more establishing separate connections for every image, CSS file, or JavaScript snippet on a web page. persistent connections También hay No más necesita un servidor para calcular el tamaño total de contenido generado dinámicamente de antemano, ahora es libre para entregar datos incrementalmente, ya que se produce. chunked transfer encoding pero Un nuevo código de estado: RFC 2068 quietly introduces something intriguing HTTP 402 Payment Required This code is reserved for future use. This shows how the founding fathers of world wide web predicted how money would eventually become a big part of internet, . even if they had no clear path on how it would actually play out Hoy, 2025, casi tres décadas y varias versiones de HTTP después ( En el 2015, En el año 2022, A pesar de la revolución de las fintech, el auge de los pagos en línea y una economía entera basada en las transacciones en Internet, nadie había decidido qué hacer con ello. HTTP/2 HTTP/3 Status Code 402 still sits there with the exact same note: 'reserved for future use.' Until now. Last month (May 2025), Liberación Un protocolo de código abierto que permite su primer trabajo real: capacitar a los nativos Pagos dentro de solicitudes HTTP. Coinbase x402 HTTP 402 onchain Hoy en día, los agentes necesitan (máquina a máquina) pagos a través de la web con reducida Intervenciones (human-in-the-loop), pero los flujos de pago tradicionales no funcionan bien en este caso. requieren múltiples interacciones humanas, redirecciones y pasos manuales que simplemente no funcionan cuando un agente de IA necesita realizar una transacción de forma autónoma. M2M HITL Se propone un flujo de pago automatizado en cadena implementado nativamente dentro del protocolo HTTP, . x402 making them as seamless as any other web request Pero, ¿cómo se ve esto en la práctica? Arquitectura y componentes de El X402 El X402 Está construido en torno a cuatro componentes principales: x402 y a actúa como el iniciador del pago, descubriendo lo que se requiere para el acceso y construyendo la carga de pago adecuada. En pocas palabras, esto es lo que está haciendo la solicitud HTTP a un recurso de pared de pago. Puede ser un navegador haciendo una solicitud de contenido premium, un agente de compra de API de IA, o una aplicación móvil desbloqueando características. El cliente gestiona la firma criptográfica usando la clave privada del usuario y retira automáticamente las solicitudes cuando se requiere el pago. client El ejecuta las políticas de pago para sus puntos finales mientras permanece enfocado en su lógica de negocio principal. Este es el servidor web o API que aloja el contenido o servicio que se compra. Mantiene tablas de precios simples que mapean los puntos finales a los costes, pero delega la lógica de verificación de pagos al facilitador. resource server La lógica de Blockchain se implementa en la Componente: Verificación de firmas criptográficas, prevención de ataques de reproducción a través del seguimiento de noce, y gestión de la liquidación real en cadena. Permite a los clientes y servidores trabajar con pagos en cadena sin comprender los detalles de la implementación de la blockchain. facilitator es reside la capa final de liquidación, asegurando que los pagos sean inmutables y transparentes. . blockchain but its complexity is completely hidden from the application layer by the facilitator : Client Responsabilidad primaria: Iniciación al pago Características clave: firma de EIP-712, retiros automáticos, descubrimiento de pagos Lo que hace: hace solicitudes, maneja carteras, retries con pago : Resource Server Primary Responsibility: Payment enforcement Características clave: Tablas de precios, respuestas HTTP 402, integración de middleware Lo que hace: Establece precios, verifica pagos, sirve contenido : Facilitator Responsabilidad principal: Verificación de pagos Características clave: Verificación de firma, noce tracking, abstracción de gases Lo que hace: Verifica las firmas, habla con blockchain : Blockchain Responsabilidad principal: liquidación de pagos Características clave: Transferencias USD, contratos inteligentes, registros inmutables Lo que hace: liquida los pagos en la cadena Principios Esta arquitectura demuestra varios principios fundamentales de la ingeniería de software. Cada componente tiene una responsabilidad única y bien definida. . separation of concerns Resource servers focus purely on business logic, facilitators handle payment complexity, and clients manage user interaction El sistema consigue interactúan únicamente a través de interfaces HTTP y REST estandarizadas. Este aislamiento significa que puede intercambiar componentes (por ejemplo, usar una blockchain diferente, cambiar proveedores de facilitadores o modificar la lógica del servidor) sin afectar al resto del sistema. loose coupling A resource server doesn't need to understand how blockchain transactions work, and a client doesn't need to know the server's internal implementation El facilitador facilita el aislando toda la complejidad de la blockchain en un servicio especializado, lo que evita que la lógica de pago se infiltre en las aplicaciones empresariales y mantiene las preocupaciones adecuadamente separadas. single responsibility principle Por último, pero no menos importante, la arquitectura Los componentes de alto nivel dependen de abstracciones en lugar de implementaciones concretas.Los servidores y los clientes dependen de interfaces HTTP, no de APIs de blockchain específicas. Esto permite que el mismo código de aplicación funcione en diferentes blockchains y esquemas de pago sin modificación. dependency inversion Flujo de pago When an AI agent or user hits an API habilitado, aquí está el flujo de cuatro pasos que ocurre: x402 Solicitud inicial: El cliente hace una solicitud HTTP estándar para acceder a algún recurso Respuesta requerida: Si no se adjunta ningún pago, el servidor responde con HTTP 402 e incluye detalles de pago Autorización de pago: El cliente crea un pago firmado criptográficamente y retira la solicitud Verificación y acceso: El servidor valida el pago, lo transmite a la blockchain y otorga acceso Lo que hace que esto sea poderoso es que todo sucede a nivel de protocolo HTTP. Sin redirecciones a procesadores de pago de terceros, no flujos, sin creación de cuenta. OAuth Just standard HTTP with extra headers: X-PAYMENT fluye de cliente a servidor y contiene la carga de pago firmada. Esto incluye los detalles de pago (importe, destinatario, token) más una firma criptográfica que demuestra que el cliente autorizó el pago. X-PAYMENT-RESPONSE fluye de servidor a cliente después de un pago exitoso y contiene información de recibo de transacción, proporcionando transparencia sobre lo que sucedió en la cadena. Implementación de servidores Arquitectura de Middleware La implementación del lado del servidor central gira en torno a un filtro de pago (AKA middleware) que intercepta las solicitudes HTTP y aplica los requisitos de pago. Cuando se integra en su servidor web, este middleware controla las solicitudes entrantes contra una tabla de precios que mapea los puntos finales a su costo. El medio sigue un árbol de decisión simple: si una solicitud llega a un punto final protegido sin pago, responde con y instrucciones de pago detalladas. Si el pago está incluido en el Header, verifica el pago con un servicio de facilitador antes de permitir que la solicitud continúe. HTTP 402 X-PAYMENT Aquí está la estructura esencial de la implementación de Java: public class PaymentFilter implements Filter { private final String payTo; private final Map priceTable; // path → amount private final FacilitatorClient facilitator; public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException { String path = req.getRequestURI(); String paymentHeader = req.getHeader("X-PAYMENT"); if (!priceTable.containsKey(path)) { chain.doFilter(request, response); // Free endpoint return; } if (paymentHeader == null) { send402Response(resp, path); // Request payment return; } // Verify payment, process request, then settle VerificationResponse verification = facilitator.verify(paymentHeader, requirements); if (verification.valid) { chain.doFilter(request, response); facilitator.settle(paymentHeader, requirements); } } } Simplemente añade el filtro de pago a su pila de productos intermedios y define qué puntos finales requieren pago. The beauty of this approach is that it requires minimal changes to existing applications. Respuesta PaymentRequirements Cuando un cliente llega a un punto final protegido sin pago, el servidor construye un objeto de requisitos de pago detallado. ), la dirección de la cartera de recepción, la red blockchain y un tiempo de caducidad para evitar ataques de repetición. USDC private void send402Response(HttpServletResponse response, String path) throws IOException { response.setStatus(HttpStatus.PAYMENT_REQUIRED); response.setContentType("application/json"); PaymentRequirements requirements = PaymentRequirements.builder() .paymentRequirement(List.of( PaymentRequirement.builder() .kind(new Kind("exact", "base-sepolia")) // Payment scheme + blockchain network .receiver(payTo) // Wallet address to receive payment .amount(priceTable.get(path)) // Cost for this specific endpoint .asset(" ") // USDC token contract .expiry(Instant.now().plus(Duration.ofMinutes(5))) // Payment window .nonce(UUID.randomUUID().toString()) // One-time use identifier .build() )) .build(); response.getWriter().write(Json.MAPPER.writeValueAsString(requirements)); } Cada campo en el Se describe de la siguiente manera: PaymentRequirements Tipo: Define el esquema de pago (exacto para cantidades fijas) y la red blockchain de destino (base-sepolia para Base testnet). Esto le dice al cliente exactamente cómo estructurar y ejecutar el pago. receptor: La dirección de la cartera a la que se debe enviar el pago.Esta es su cartera de negocios que recibirá los fondos. cantidad: El costo de acceder a este punto final específico, obtenido de su tabla de precios. Para USDC, esto se expresa por lo general en wei (unidad más pequeña). Activo: La dirección de contrato inteligente del token que se utilizará para el pago.El ejemplo muestra USDC en la base Sepolia testnet. expiración: Una marca de tiempo después de la cual este requisito de pago se vuelve inválido. Esto evita que las solicitudes de pago antiguas sean reutilizadas y agrega seguridad contra ataques de replay. Un identificador único (UUID) que asegura que cada requisito de pago sólo puede ser cumplido una vez, incluso si el mismo cliente hace múltiples solicitudes al mismo punto final. Implementación del cliente Procesamiento automático de pagos Las bibliotecas de clientes envuelven los clientes HTTP estándar para procesar automáticamente las respuestas 402.Cuando un cliente recibe una solicitud de pago, (1) construye una carga útil de pago, (2) la firma con la clave privada del usuario y (3) retoma la solicitud original con el pago adjunto. public HttpResponse makeRequest(String url, String method) throws Exception { HttpRequest request = HttpRequest.newBuilder() .uri(URI.create(url)) .method(method, HttpRequest.BodyPublishers.noBody()) .build(); HttpResponse response = httpClient.send(request, HttpResponse.BodyHandlers.ofString()); // Handle 402 Payment Required if (response.statusCode() == 402) { PaymentRequirements requirements = Json.MAPPER.readValue( response.body(), PaymentRequirements.class); // Create payment payload matching the requirements PaymentPayload payment = PaymentPayload.builder() .receiver(requirements.getPaymentRequirement().get(0).getReceiver()) .amount(requirements.getPaymentRequirement().get(0).getAmount()) .asset(requirements.getPaymentRequirement().get(0).getAsset()) .nonce(requirements.getPaymentRequirement().get(0).getNonce()) .expiry(requirements.getPaymentRequirement().get(0).getExpiry()) .build(); // Sign using EIP-712 structured data signing String signature = signer.sign(payment.toSigningMap()); // Retry with payment header String paymentHeader = encodePaymentHeader(payment, signature); HttpRequest paidRequest = HttpRequest.newBuilder() .uri(URI.create(url)) .method(method, HttpRequest.BodyPublishers.noBody()) .header("X-PAYMENT", paymentHeader) .build(); return httpClient.send(paidRequest, HttpResponse.BodyHandlers.ofString()); } return response; } El proceso de firma utiliza el estándar, que crea una representación estructurada, legible por el hombre de los datos de pago antes de hasharlo y firmarlo. EIP-712 Verificación de flujo de pagos Facilitar la integración El servicio de facilitador es donde vive la complejidad de la cadena de bloques, abstractándolo lejos de los clientes y los servidores.Cuando un servidor recibe un pago, envía la carga útil del pago al facilitador para la verificación. public class HttpFacilitatorClient implements FacilitatorClient { private final HttpClient http; private final String baseUrl; @Override public VerificationResponse verify(String paymentHeader, PaymentRequirements requirements) throws Exception { // Construct verification request with payment and requirements VerifyRequest body = VerifyRequest.builder() .paymentHeader(paymentHeader) // The X-PAYMENT header from client .requirements(requirements) // What the server expects .build(); HttpRequest request = HttpRequest.newBuilder() .uri(URI.create(baseUrl + "/verify")) .POST(HttpRequest.BodyPublishers.ofString(Json.MAPPER.writeValueAsString(body))) .header("Content-Type", "application/json") .build(); String json = http.send(request, HttpResponse.BodyHandlers.ofString()).body(); return Json.MAPPER.readValue(json, VerificationResponse.class); } @Override public SettlementResponse settle(String paymentHeader, PaymentRequirements requirements) throws Exception { // Settlement happens after successful verification SettleRequest body = SettleRequest.builder() .paymentHeader(paymentHeader) .requirements(requirements) .build(); HttpRequest request = HttpRequest.newBuilder() .uri(URI.create(baseUrl + "/settle")) .POST(HttpRequest.BodyPublishers.ofString(Json.MAPPER.writeValueAsString(body))) .header("Content-Type", "application/json") .build(); String json = http.send(request, HttpResponse.BodyHandlers.ofString()).body(); return Json.MAPPER.readValue(json, SettlementResponse.class); } } El facilitador verifica varias cosas: ¿Es válida la firma? ¿El importe de pago se ajusta a los requisitos? ¿Ha sido utilizado este pago antes? ¿Está el pago todavía dentro de su ventana de caducidad? Si la verificación pasa, el facilitador también maneja la liquidación transmitiendo la transacción a la blockchain de su elección. La interfaz define el contrato que cualquier cliente facilitador debe implementar: FacilitatorClient public interface FacilitatorClient { VerificationResponse verify(String paymentHeader, PaymentRequirements requirements); SettlementResponse settle(String paymentHeader, PaymentRequirements requirements); } Su aplicación debe proporcionar una implementación concreta de esta interfaz. Ejemplo de integración Ahora que hemos visto los componentes individuales (filtros de pago, integración de facilitadores y manejo de clientes), echemos un vistazo a cómo estas piezas se unen en una aplicación real. ejemplo que demuestra el flujo completo. Spring Boot En primer lugar, crear una La anotación: @PaymentRequired @Target(ElementType.METHOD) @Retention(RetentionPolicy.RUNTIME) public @interface PaymentRequired { String price(); String currency() default "USDC"; String network() default "base-sepolia"; } Entonces modifica el para escanear para estas anotaciones en el inicio: PaymentFilter @Component public class PaymentFilter implements Filter { private final Map priceTable; private final String payTo; private final FacilitatorClient facilitator; public PaymentFilter(ApplicationContext context, String payTo, FacilitatorClient facilitator) { this.payTo = payTo; this.facilitator = facilitator; this.priceTable = buildPriceTableFromAnnotations(context); } private Map buildPriceTableFromAnnotations(ApplicationContext context) { Map prices = new HashMap<>(); // Scan all @RestController beans for @PaymentRequired annotations Map controllers = context.getBeansWithAnnotation(RestController.class); for (Object controller : controllers.values()) { Method[] methods = controller.getClass().getMethods(); for (Method method : methods) { PaymentRequired payment = method.getAnnotation(PaymentRequired.class); if (payment != null) { String path = extractPathFromMapping(method); BigInteger amount = new BigInteger(payment.price().replace(".", "")); prices.put(path, amount); } } } return prices; } } Ahora puede anotar sus métodos de controlador directamente: @RestController public class WeatherController { @GetMapping("/weather") @PaymentRequired(price = "0.001", currency = "USDC", network = "base-sepolia") public WeatherData getWeather(@RequestParam String city) { // Your existing business logic return weatherService.getWeatherForCity(city); } @GetMapping("/premium-forecast") @PaymentRequired(price = "0.01", currency = "USDC", network = "base-sepolia") public ExtendedForecast getPremiumForecast(@RequestParam String city) { return weatherService.getExtendedForecast(city); } } @Configuration public class PaymentConfig { @Bean public PaymentFilter paymentFilter(ApplicationContext context) { return new PaymentFilter( context, " ", // Your wallet address new HttpFacilitatorClient(" ") ); } @Bean public FilterRegistrationBean paymentFilterRegistration(PaymentFilter filter) { FilterRegistrationBean registration = new FilterRegistrationBean<>(); registration.setFilter(filter); registration.addUrlPatterns("/*"); registration.setOrder(1); return registration; } } El La anotación trata la configuración de precios declarativamente, mientras que la Descubre automáticamente estas anotaciones en el inicio y crea la tabla de precios. Su lógica de negocio existente en los métodos del controlador permanece completamente inalterada. La configuración lo conecta todo al registrar el filtro de pago y conectarlo a un servicio de facilitador. costos de 0.001 USDC y cuesta 0.01 USDC, con todo el procesamiento de pagos ocurriendo de forma transparente en la capa HTTP. @PaymentRequired PaymentFilter /weather /premium-forecast Consideraciones de seguridad y producción es simple y elegante, esconde la complejidad. Este es un pro y un con. Facilita la integración, pero también esconde un aspecto importante: . x402 putting AI agents in charge of money creates new attack vectors Mientras Los ataques de repetición de las firmas y la gestión de las nociones, ¿qué sucede cuando un agente se compromete?La detección tradicional de fraudes se basa en patrones de comportamiento humano, pero Un agente comprometido podría drenar fondos más rápido que cualquier estafador humano. EIP-712 AI agents don't follow human spending habits El componente facilitador se convierte en otro objetivo de alto valor ya que verifica firmas y gestiona nonces. . blockchain settlements are final Desde Se basa en transacciones en cadena, hereda los riesgos operativos de las transacciones de blockchain. Las tarifas de gas fluctúan volátilmente, a veces haciendo que los micropagos sean económicamente incómodos. La congestión de la red puede retrasar las transacciones. ¿Qué debe hacer un agente de IA cuando necesita datos en tiempo real pero el pago está atrapado en un mempool? x402 Otro aspecto importante es la regulación.El cumplimiento varía entre jurisdicciones con diferentes reglas sobre pagos automatizados, uso de criptomonedas y retención de datos.Un agente de IA que realiza un gran volumen de microtransacciones a través de las fronteras podría desencadenar alertas de AML o violar las regulaciones locales sin que nadie se diera cuenta. ¿Qué es lo siguiente ¿Qué es interesante sobre Los agentes de IA necesitan capacidades de pago autónomos, las stablecoins proporcionan una capa de dinero programable, y la infraestructura de blockchain ha madurado lo suficiente para manejar aplicaciones escalables.Estas piezas no se han alineado antes. x402 es convincente gracias a su enfoque pragmático. En lugar de reinventar los pagos desde cero, expande la infraestructura HTTP existente. En lugar de requerir nuevas integraciones, funciona con patrones estándar que ya entendemos. x402 Los desafíos de seguridad y operacionales son reales, pero son problemas de ingeniería con posibles soluciones. Después de casi tres décadas, Finalmente podría hacer lo que estaba diseñado para: hacer que pagar por las cosas en Internet sea tan sencillo como solicitarlas. HTTP 402 The foundation is set. Now it's time to build. gracias de Erik Reppel, de Ronnie Caspers, por Kevin Leffew, Danny Organ, y todo el equipo en Coinbase abierto de este protocolo. Erik Reppel Ronnie Caspers por Kevin Leffew El órgano Coinbase . gracias Erik Reppel y Yuga Cohler Para la revisión mis contribuciones Dos x402 Erik Reppel Yuga Cohler mis contribuciones Recursos y Leer más Requiere pago HTTP 402 - RFC 2068 - Especificación HTTP original de 1997 Especificación del protocolo x402 - Documentación oficial del protocolo x402 GitHub Repository - Implementación de código abierto de Coinbase x402 implementación de Java - El PR que introdujo la implementación de Java del protocolo EIP-712: Ethereum Tipado Hashing y firma de datos estructurados - estándar de firma utilizado en x402 Documentación de la red de base - Plataforma blockchain de la capa 2 utilizada en ejemplos Documentación USDC - Detalles del contrato USD Coin Stablecoin Documentación de filtro de inicio de primavera - implementación de Java middleware Java HTTP Client API - Gestión de HTTP del lado del cliente Normas de Comunicación Máquina-Máquina (M2M) - Comunicación de sistemas autónomos Arquitecturas autónomas de agentes de IA - Investigación sobre patrones de diseño de agentes de IA Google Approach to Secure AI Agents: las propuestas de Google de un marco de agentes de IA seguro y guiado por el hombre