Els agents d'intel·ligència artificial ara poden pagar de forma autònoma gràcies a x402 i HTTP 402

És gener de 1997.

ElIETF(Internet Engineering Task Force) acaba de publicarRGPD 2068Definir oficialmentHTTP/1.1L'especificació va ser creada per pioners webEl Roy Fielding,Jim Gettys,Jeffrey Mogul,Enric Freixà, iTim Berners-LeeEls arquitectes que van modelar com es comunica Internet.

L’especificació introdueixpersistent connections: anteriorment, cada sol·licitud HTTP requeria una nova connexió TCP. Les connexions persistents resolen això, permetent que múltiples sol·licituds HTTP flueixin a través d'una sola connexió TCP de llarga durada.

També hi hachunked transfer encoding, una nova manera per als servidors web de transmetre contingut sense conèixer prèviament la mida completa. ja no necessita calcular la mida total del contingut generat dinàmicament per endavant, ara és lliure per lliurar dades incrementalment, ja que es produeix.

peròRFC 2068 quietly introduces something intriguingUn nou codi d’estat:

HTTP 402 Payment Required
This code is reserved for future use.

Això mostra com els pares fundadors de la World Wide Web van predir com els diners es convertirien finalment en una gran part d'Internet.even if they had no clear path on how it would actually play out.

Avui, 2025, gairebé tres dècades i múltiples versions HTTP després (HTTP/2El 2015,HTTP/3El 2022Status Code 402 still sits there with the exact same note: 'reserved for future use.'Malgrat la revolució de les fintech, l'augment dels pagaments en línia i una economia sencera basada en les transaccions d'Internet, ningú no havia pensat què fer amb això.

Until now.

El mes passat (Maig de 2025),Coinbasealliberatx402, an open source protocol that gives HTTP 402El seu primer treball real: habilitar els nadiusonchainPagament de sol·licituds HTTP.

Actualment, els agents han deM2M(Màquina a màquina) pagaments a través de la web amb reduccióHITLIntervencions (human-in-the-loop), però els fluxos de pagament tradicionals no funcionen bé en aquest cas. Requereixen múltiples interaccions humanes, redireccions i passos manuals que simplement no funcionen quan un agent d'IA necessita fer una transacció de forma autònoma.

x402Proposa un flux de pagaments automatitzat en cadena implementat nativament dins del protocol HTTP,making them as seamless as any other web request.

Però com es veu això en la pràctica?

Arquitectura i components dex402

x402Està construït al voltant de quatre components bàsics:

El

aclientactua com a iniciador de pagament, descobrint el que es requereix per accedir i construir la càrrega de pagament adequada. En poques paraules, això és el que està fent la sol·licitud HTTP a un recurs de paret de pagament. Podria ser un navegador fent una sol·licitud de contingut premium, un agent de compra d'API d'AI o una aplicació mòbil desbloquejant característiques. El client gestiona la signatura criptogràfica utilitzant la clau privada de l'usuari i retira automàticament les sol·licituds quan es requereix el pagament.

Elresource serverImplementa les polítiques de pagament per als seus punts finals mentre es manté centrat en la seva lògica empresarial bàsica. Aquest és el servidor web o l'API que allotja el contingut o el servei que es compra. Manté taules de preus simples que mapen els punts finals als costos, però delega la lògica de verificació de pagament al facilitador.

La lògica blockchain s'implementa en lafacilitatorComponent: Verificació de signatures criptogràfiques, prevenció d'atacs de repetició a través del rastreig noce, i gestió de la liquidació real en cadena. permet als clients i servidors treballar amb pagaments en cadena sense entendre els detalls de la implementació de la blockchain.

Ésblockchainresideix la capa final de liquidació, assegurant que els pagaments són immutables i transparents.Permet diners programables a través de contractes intel·ligents i monedes estables,but its complexity is completely hidden from the application layer by the facilitator.

Client:

• Responsabilitat principal: Iniciació del pagament
• Característiques clau:EIP-712 signatura, retries automàtiques, descobriment de pagaments
• Què fa: realitza sol·licituds, gestiona carteres, retires amb pagament

Resource Server:

• Responsabilitat principal: Execució de pagaments
• Característiques clau: taules de preus, respostes HTTP 402, integració de middleware
• Què fa: Estableix preus, comprova pagaments, serveix contingut

Facilitator:

• Responsabilitat principal: Verificació de pagaments
• Característiques clau: Verificació de signatura, rastreig de noces, abstracció de gasos
• Què fa: Verifica les signatures, parla amb blockchain

Blockchain:

• Responsabilitat principal: liquidació de pagaments
• Característiques clau: transferències USDDC, contractes intel·ligents, registres immutables
• Què fa: liquida els pagaments a la cadena

Principis

Aquesta arquitectura demostra diversos principis fonamentals de l'enginyeria de programari.separation of concernsCada component té una responsabilitat única i ben definida.Resource servers focus purely on business logic, facilitators handle payment complexity, and clients manage user interaction.

El sistema aconsegueixloose couplingEls components només interactuen a través d'interfícies HTTP i REST estandarditzades.A resource server doesn't need to understand how blockchain transactions work, and a client doesn't need to know the server's internal implementationAquest aïllament significa que podeu intercanviar components (per exemple, utilitzar una blockchain diferent, canviar proveïdors de facilitadors o modificar la lògica del servidor) sense afectar la resta del sistema.

El facilitador incorpora elsingle responsibility principleaïllant tota la complexitat de la blockchain en un servei especialitzat. Això impedeix que la lògica de pagament s'escapi a les aplicacions empresarials i manté les preocupacions adequadament separades.

Finalment, però no menys important, aquesta arquitecturadependency inversionEls components d'alt nivell depenen d'abstraccions en lloc d'implementacions concretes. Els servidors i els clients depenen d'interfícies HTTP, no d'API específiques de blockchain. Això permet que el mateix codi d'aplicació funcioni a través de diferents blockchains i esquemes de pagament sense modificació.

Flux de pagament

Quan un agent o un usuari de l'IA colpeja unx402-enabled API, aquí està el flux de quatre passos que passa:

1. Sol·licitud inicial: El client fa una sol·licitud HTTP estàndard per accedir a algun recurs
2. Si no s'afegeix cap pagament, el servidor respon amb HTTP 402 i inclou les dades de pagament
3. Autorització de pagament: El client crea un pagament signat criptogràficament i retorna la sol·licitud
4. Verification and access : The server validates the payment, broadcasts it to the blockchain, and grants access

El que fa que això sigui potent és que tot passa al nivell del protocol HTTP. No redirigeix a processadors de pagaments de tercers, noOAuth flows, no account creation. Just standard HTTP with extra headers:

• X-PAYMENT flueix de client a servidor i conté la càrrega de pagament signada. Això inclou els detalls de pagament (import, destinatari, token) més una signatura criptogràfica que demostra que el client ha autoritzat el pagament.
• X-PAYMENT-RESPONSE flueix del servidor al client després d'un pagament reeixit i conté informació de recepció de transaccions, proporcionant transparència sobre el que va succeir en la cadena.

El

Implementació de servidors

Arquitectura de middleware

La implementació del servidor central gira al voltant d'un filtre de pagament (AKA middleware) que intercepta les sol·licituds HTTP i imposa els requisits de pagament. Quan s'integra al vostre servidor web, aquest middleware controla les sol·licituds entrants contra una taula de preus que mapes els terminis als seus costos.

El producte mitjà segueix un simple arbre de decisió: si una sol·licitud arriba a un punt final protegit sense pagament, respon ambHTTP 402i instruccions de pagament detallades. Si el pagament està inclòs en elX-PAYMENTHeader, verifica el pagament amb un servei de facilitador abans de permetre que la sol·licitud procedeixi.

Aquí teniu l'estructura essencial de la implementació de Java:

public class PaymentFilter implements Filter {
    private final String payTo;
    private final Map<String, BigInteger> 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);
        }
    }
}

The beauty of this approach is that it requires minimal changes to existing applications.Simplement afegir el filtre de pagament a la pila de productes mitjans i definir quins punts finals requereixen pagament.

PaymentRequirementsResposta

Quan un client arriba a un punt final protegit sense pagament, el servidor construeix un objecte de requisits de pagament detallat.USDC), l'adreça de cartera de recepció, la xarxa blockchain i un temps d'expiració per evitar atacs de replay.

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>")                      // 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 un dels camps de laPaymentRequirementsEs descriu de la següent manera:

• tipus: Defineix l'esquema de pagament (exacte per a quantitats fixes) i la xarxa de blockchain de destinació (base-sepolia per Base testnet). Això diu al client exactament com estructurar i executar el pagament.
• receptor: L'adreça de cartera on s'ha d'enviar el pagament. Aquesta és la cartera de la seva empresa que rebrà els fons.
• quantitat: El cost d'accés a aquest punt final específic, obtingut de la taula de preus. Per USDC, això s'expressa normalment en wei (unitat més petita).
• actiu: L'adreça de contracte intel·ligent del token que s'utilitza per al pagament. L'exemple mostra USDC a Base Sepolia testnet.
• expiració: un timestamp després del qual aquest requisit de pagament esdevé nul. Això impedeix que es reutilitzin les velles sol·licituds de pagament i afegeix seguretat contra atacs de replay.
• Un identificador únic (UUID) que garanteix cada requisit de pagament només es pot complir una vegada, fins i tot si el mateix client fa múltiples sol·licituds al mateix punt final.

Implementació client

Processament automàtic de pagaments

Les biblioteques de clients embolcallen clients HTTP estàndard per processar automàticament les respostes 402.Quan un client rep una sol·licitud de pagament, (1) construeix una càrrega útil de pagament, (2) la signa amb la clau privada de l'usuari i (3) retorna la sol·licitud original amb el pagament adjunt.

public HttpResponse<String> makeRequest(String url, String method) throws Exception {
    HttpRequest request = HttpRequest.newBuilder()
        .uri(URI.create(url))
        .method(method, HttpRequest.BodyPublishers.noBody())
        .build();

    HttpResponse<String> 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 procés de signatura utilitza elEIP-712estàndard, que crea una representació estructurada, llegible per l'home de les dades de pagament abans d'haxar-les i signar-les. Això garanteix que el pagament sigui criptogràficament segur i vinculat a la petició específica.

Verificació de flux de pagament

Facilitar la integració

El servei de facilitador és on viu la complexitat de la blockchain, abstractant-la de clients i servidors.Quan un servidor rep un pagament, remet la càrrega de pagament al facilitador per a la verificació.

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);
    }
}

The facilitator checks several things:

• És vàlida la signatura?
• La quantitat de pagament es correspon amb els requisits?
• Ha estat utilitzat aquest pagament abans?
• El pagament encara està dins de la finestra d'expiració?

Si la verificació passa, el facilitador també gestiona el règim mitjançant la transmissió de la transacció a la blockchain de la seva elecció.FacilitatorClientLa interfície defineix el contracte que qualsevol client facilitador ha d'implementar:

public interface FacilitatorClient {
    VerificationResponse verify(String paymentHeader, PaymentRequirements requirements);
    SettlementResponse settle(String paymentHeader, PaymentRequirements requirements);
}

La seva aplicació ha de proporcionar una implementació concreta d'aquesta interfície.

Exemple d’integració

Ara que hem vist els components individuals (filtres de pagament, integració de facilitadors i maneig del client), anem a veure com aquestes peces es reuneixen en una aplicació real.Spring BootExemple que demostra el flux complet.

En primer lloc, crear una@PaymentRequiredAnàlisi :

@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
public @interface PaymentRequired {
    String price();
    String currency() default "USDC";
    String network() default "base-sepolia";
}

Després es modifiquen elsPaymentFilterper escanejar per aquestes anotacions a l'inici:

@Component
public class PaymentFilter implements Filter {
    private final Map<String, BigInteger> 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<String, BigInteger> buildPriceTableFromAnnotations(ApplicationContext context) {
        Map<String, BigInteger> prices = new HashMap<>();

        // Scan all @RestController beans for @PaymentRequired annotations
        Map<String, Object> 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;
    }
}

Ara podeu anotar directament els mètodes del controlador:

@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,
            "<WALLET_ADDRESS>", // Your wallet address
            new HttpFacilitatorClient("<FACILITATOR_URL>")
        );
    }

    @Bean
    public FilterRegistrationBean<PaymentFilter> paymentFilterRegistration(PaymentFilter filter) {
        FilterRegistrationBean<PaymentFilter> registration = new FilterRegistrationBean<>();
        registration.setFilter(filter);
        registration.addUrlPatterns("/*");
        registration.setOrder(1);
        return registration;
    }
}

El@PaymentRequiredl’anotament gestiona la configuració de preus declarativament, mentre que elPaymentFilterdescobreix automàticament aquestes anotacions a l'inici i construeix la taula de preus. La lògica de negoci existent en els mètodes del controlador es manté completament inalterada. La configuració ho connecta tot registrant el filtre de pagament i connectant-lo a un servei de facilitador./weathercost 0,001 USDC i/premium-forecastcost 0,01 USDC, amb tot el processament de pagament es produeix de manera transparent a la capa HTTP.

Consideracions de seguretat i producció

x402és simple i elegant, amaga la complexitat. Això és un pro i un con. Facilita la integració, però també amaga un aspecte important:putting AI agents in charge of money creates new attack vectors.

Mentre queEIP-712Les signatures i la gestió de nocions tracten els atacs de repetició, què passa quan un agent es veu compromès?La detecció tradicional de fraus es basa en patrons de comportament humans, peròAI agents don't follow human spending habitsUn agent compromès podria esborrar fons més ràpid que qualsevol estafador humà.

El component facilitador es converteix en un altre objectiu d'alt valor ja que verifica signatures i gestiona nocions.blockchain settlements are final.

Des dex402es basa en les transaccions en cadena, hereta els riscos operatius de les transaccions de blockchain. Les tarifes del gas fluctuen molt, de vegades fent que els micropagaments siguin econòmicament incòmodes. La congestió de la xarxa pot retardar les transaccions. Què ha de fer un agent d'IA quan necessita dades en temps real però el pagament està atrapat en un mempool?

Un altre aspecte important és la regulació. El compliment varia entre jurisdiccions amb diferents regles sobre els pagaments automatitzats, l'ús de criptomonedes i la retenció de dades.Un agent d'IA que realitza un gran volum de microtransaccions a través de les fronteres podria desencadenar alertes AML o violar les regulacions locals sense que ningú s'adoni.

Què és el següent

Què és interessant sobrex402Els agents d'IA necessiten capacitats de pagament autònoms, els stablecoins proporcionen una capa de diners programable, i la infraestructura de blockchain ha madurat prou per gestionar aplicacions escalables. Aquestes peces no s'han alineat abans. Internet ara necessita una nova forma de pagaments, i els fluxos tradicionals no es van construir per a agents autònoms o micropagaments.

x402és convincent gràcies al seu enfocament pragmàtic. En comptes de reinventar els pagaments des de zero, amplia la infraestructura HTTP existent. En comptes de requerir noves integracions, funciona amb patrons estàndard que ja entenem.

Els reptes de seguretat i operatius són reals, però són problemes d'enginyeria amb possibles solucions.

Després de gairebé tres dècades,HTTP 402Finalment podria fer el que estava dissenyat per fer: fer que pagar per les coses a Internet sigui tan simple com sol·licitar-les.

The foundation is set. Now it's time to build.

Gràcies de l’Eric Reppel, de Ronnie Caspers, Joan Leffew, Danny Organ, i tot l'equip de Coinbase per a l’obertura d’aquest protocol.

Gràcies Erik Reppel i Yuga Cohler Per a la revisió Les meves contribucions Dues x402.

Recursos i més lectura

• HTTP 402 Pagament requerit - RFC 2068 - Especificació HTTP original de 1997
• Especificació del protocol x402 - Documentació oficial del protocol
• x402 GitHub Repository - Implementació de codi obert de Coinbase
• x402 implementació de Java - El PR que va introduir la implementació de Java del protocol
• EIP-712: Ethereum Typeed Structured Data Hashing and Signing - estàndard de signatura utilitzat en x402
• Documentació de la xarxa base - Plataforma blockchain de la capa 2 utilitzada en exemples
• Documentació USDC - Detalls del contracte de l'USD Coin Stablecoin
• Spring Boot Filter Documentation - Implementació de middleware de Java
• Java HTTP Client API - Gestió d'HTTP al costat del client
• Normes de comunicació màquina a màquina (M2M) - Comunicació de sistemes autònoms
• Arquitectures autònomes d'agents d'IA - Recerca sobre patrons de disseny d'agents d'IA
• Google Approach to Secure AI Agents: les propostes de Google d'un marc d'agents d'IA segur i guiat per l'home