Агенты ИИ теперь могут заплатить автономно благодаря X402 и HTTP 402

Это январь 1997 года.

АIETF(Целевая группа по интернет -инженерии) только что выпустилаRFC 2068, официально определяяHttp/1.1Полем Спецификация была написана веб -пионерамиРой ФилдингВДжим ГеттисВДжеффри МогольВХенрик Фристик, иТим Бернерс-Ли, архитекторы, которые сформировали то, как интернет общается.

Спецификация вводитПостоянные связи: Ранее каждый HTTP -запрос требовал свежего соединения TCP. Постоянные соединения разрешают это, позволяя нескольким HTTP-запросам проходить через одно долгоживущее соединение TCP. Больше не нужно устанавливать отдельные подключения для каждого изображения, файла CSS или фрагмента JavaScript на веб -странице.

Есть тожеКодировка перевода в кучу, новый способ для веб -серверов транслировать контент, не зная полного размера заранее. Больше не нужно, чтобы сервер не должен вычислять общий размер динамически сгенерированного контента заранее, теперь он свободен доставлять данные постепенно, как его производят.

НоRFC 2068 тихо представляет что -то интригующее, новый код статуса:

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

Это показывает, как отцы -основатели Всемирной паутины предсказали, как деньги в конечном итоге станут большой частью Интернета,Даже если бы у них не было четкого пути в том, как это на самом деле разыграетПолем

Сегодня, 2025 год, почти три десятилетия и несколько версий HTTP позже (HTTP/2в 2015 году,HTTP/3в 2022 году),Status Code 402Все еще сидит там с той же той же нотой: «Зарезервировано для будущего использования».Несмотря на революцию Fintech, рост онлайн -платежей и целую экономику, основанную на интернет -транзакциях, никто не выяснил, что с ним делать.

До настоящего времени.

В прошлом месяце (май 2025),Coinbaseвыпущенныйx402, протокол с открытым исходным кодом, который даетHTTP 402его первая настоящая работа: включение местныхОнчейнПлатежи в рамках HTTP -запросов.

В настоящее время агенты ИИ должны сделатьМ2 м(машины до машины) Платежи по Интернету с уменьшеннымХитл(Человек-в-петли) вмешательства, но традиционные платежные потоки не работают в этом случае. Они требуют нескольких человеческих взаимодействий, перенаправлений и ручных шагов, которые просто не работают, когда агент ИИ должен совершать транзакцию автономно.

x402Заполняет этот пробел. Он предлагает автоматизированный поток платежей в цепочке, внедренный в рамках протокола HTTP,сделать их такими же беспрепятственными, как и любой другой веб -запросПолем

Но как это выглядит на практике?

Архитектура и компонентыx402

x402построен вокруг четырех основных компонентов:

АклиентВыступает в качестве инициатора платежей, обнаружив, что требуется для доступа и создания соответствующей полезной нагрузки платежей. Проще говоря, это то, что делает HTTP-запрос в ресурс с оплатой. Это может быть браузер, который делает запрос на контент премиум -класса, покупатель API API -агента AI, или функции разблокировки мобильного приложения. Клиент обрабатывает криптографическую подпись с использованием закрытого ключа пользователя и автоматически повторно запрашивает запросы, когда требуется оплата.

Асервер ресурсовобеспечивает соблюдение политики оплаты для своих конечных точек, оставаясь при этом сосредоточенной на своей основной бизнес -логике. Это веб -сервер или API, который размещает приобретанный контент или службу. Он поддерживает простые таблицы ценообразования, которые отображают конечные точки с затратами, но делегирует логику проверки платежей для фасилитатора.

Логика блокчейна реализована вфасилитаторКомпонент: проверка криптографических подписей, предотвращение повторных атак посредством отслеживания нера и управление фактическим урегулированием в цепочке. Это позволяет как клиентам, так и серверам работать с платежами в цепочке без понимания деталей реализации блокчейна.

НаблокчейнПропадает окончательный урегулированный уровень, обеспечивая неизменные и прозрачные платежи. Он обеспечивает программируемые деньги через умные контракты и стабильные монеты,но его сложность полностью скрыта от слоя применения фасилитаторомПолем

Клиент:

• Основная ответственность: инициация оплаты
• Ключевые функции: EIP-712 Подписание, автоматические повторения, обнаружение платежей
• Что он делает: делает запросы, обрабатывает кошельки, повторно с оплатой

Сервер ресурсов:

• Основная ответственность: обеспечение оплаты
• Ключевые функции: ценовые таблицы, http 402 ответы, интеграция промежуточного программного обеспечения
• Что он делает: устанавливает цены, проверяет платежи, обслуживает контент

Фасилитатор:

• Основная ответственность: проверка оплаты
• Ключевые функции: проверка подписи, отслеживание нера, абстракция газа
• Что он делает: проверяет подписи, разговаривает с блокчейном

Блокчейн:

• Основная ответственность: урегулирование оплаты
• Ключевые функции: передачи USDC, интеллектуальные контракты, неизменные записи
• Что он делает: урегулирует платежи по цепи

Принципы

Эта архитектура демонстрирует несколько фундаментальных принципов разработки программного обеспечения. Наиболее важным являетсяразделение проблемПолем Каждый компонент несет единственную, четко определенную ответственность.Серверы ресурсов сосредоточены исключительно на бизнес -логике, фасилитаторы справляются с сложностью платежей, а клиенты управляют взаимодействием с пользователямиПолем

Система достигаетСвободная связьНалив компоненты взаимодействия только через стандартизированные интерфейсы HTTP и REST.Сервер ресурсов не должен понимать, как работают транзакции блокчейна, и клиенту не нужно знать внутреннюю реализацию сервераПолем Эта изоляция означает, что вы можете заменять компоненты (например, использовать другой блокчейн, изменять поставщиков фасилитаторов или изменить логику сервера), не влияя на остальную часть системы.

Фасилитатор воплощаетПринцип единственной ответственностиИзоляция всей сложности блокчейна в одну специализированную услугу. Это предотвращает проникновение логики платежей в бизнес -заявки и сохраняет проблемы надлежащим образом разделенной.

Последнее, но не менее важноеинверсия зависимостиПолем Компоненты высокого уровня зависят от абстракций, а не конкретных реализаций. Серверы и клиенты зависят от интерфейсов HTTP, а не на конкретных API -интерфейсах блокчейна. Это позволяет тому же коду приложения работать в разных блокчейнах и схемах платежей без модификации.

Поток оплаты

Когда агент ИИ или пользователь попадаетx402-Вывая API, вот четырехэтапный поток, который происходит:

1. Первоначальный запрос: Клиент делает стандартный HTTP -запрос для доступа к некоторым ресурсам
2. Оплата требуется ответ: Если платеж не прилагается, сервер отвечаетHTTP 402и включает в себя данные о платежах
3. Авторизация оплаты: Клиент создает криптографически подписанный платеж и дает запрос
4. Проверка и доступ: Сервер проверяет платеж, транслирует его в блокчейн и предоставляет доступ

Что делает это мощным, так это то, что все это происходит на уровне протокола HTTP. Нет перенаправления на сторонние платежные процессоры, нетOAuthпотоки, нет создания аккаунта.Просто стандартный http с дополнительными заголовками:

• X-PAYMENTтечет от клиента на сервер и содержитПодписанная платежная полезная нагрузкаПолем Это включает в себя платежные сведения (сумма, получатель, токен), а также криптографическую подпись, доказывающая, как клиент уполномочил платеж.
• X-PAYMENT-RESPONSEтечет от сервера к клиенту после успешной оплаты и содержитИнформация о квитанции о транзакции, обеспечивая прозрачность о том, что произошло в цепочке.

Реализация на стороне сервера

Оплата промежуточной архитектуры

Основная реализация на стороне сервера вращается вокруг платежного фильтра (он же средняя склада), которая перехватывает HTTP-запросы и обеспечивает соблюдение требований к оплате. При интеграции в ваш веб-сервер этот средний расход проверяет входящие запросы по ценам, которая отображает конечные точки с их затратами.

Средний ход следует за простого дерева решений: если запрос достигает защищенной конечной точки без оплаты, он отвечает с помощьюHTTP 402и подробные инструкции по оплате. Если платеж включен вX-PAYMENTЗаголовок, он проверяет платеж с помощью службы фасилитатора, прежде чем разрешить просьбу продолжить.

Вот важная структура из реализации 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);
        }
    }
}

Прелесть этого подхода в том, что он требует минимальных изменений в существующих приложениях.Вы просто добавляете фильтр платежей в свой стек средней площадки и определяете, какие конечные точки требуют оплаты.

PaymentRequirementsОтвет

Когда клиент попадает в защищенную конечную точку без оплаты, сервер строит подробный объект требований к оплате. Это включает в себя сумму оплаты, принятые токены (например,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>")                      // 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));
}

Каждое поле вPaymentRequirementsописывается следующим образом:

• kind: Определяет схему оплаты (exactдля фиксированных сумм) и целевой сети блокчейнов (base-sepoliaдля базовой тестовой сети). Это говорит клиенту точно, как структурировать и выполнить платеж.
• receiver: Адрес кошелька, куда должен быть отправлен. Это ваш деловой кошелек, который получит средства.
• amount: Стоимость доступа к этой конкретной конечной точке, извлеченная из вашей таблицы цен. Для USDC это обычно выражается вwei(наименьшая единица).
• asset: Смарт -контракт адрес токена, который будет использоваться для оплаты. В примере показан USDC на Base Sepolia Testnet.
• expiry: TimeStamp, после которой это требование оплаты становится недействительным. Это предотвращает повторное использование старых запросов на оплату и добавляет безопасность от атак на воспроизведение.
• nonce: Уникальный идентификатор (UUID), который гарантирует, что каждое требование к оплате может быть выполнено только один раз, даже если один и тот же клиент делает несколько запросов в одну и ту же конечную точку.

Реализация на стороне клиента

Автоматическая обработка оплаты

Клиентские библиотеки обертывают стандартные клиенты HTTP для автоматического обработки 402 ответов. Когда клиент получает требование о оплате, (1) он строит полезную нагрузку платежей, (2) подписывает ее с закрытым ключом пользователя и (3) дает исходный запрос с прилагаемым платежом.

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

Процесс подписания используетEIP-712Стандарт, который создает структурированное, читаемое на человеку представление данных о платежах до хэширования и подписания. Это гарантирует, что платеж криптографически безопасен и привязан к конкретному запросу.

Поток проверки оплаты

Интеграция фасилитатора

Служба фасилитатора - это место, где находится сложность блокчейна, абстрагируя ее как от клиентов, так и от серверов. Когда сервер получает платеж, он направляет платежную полезную нагрузку в фасилитатор для проверки.

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

Фасилитатор проверяет несколько вещей:

• Подпись действительна?
• Соответствует ли сумма платежа требованиями?
• Этот платеж использовался ранее?
• Платеж все еще в рамках его истечения срока действия?

Если проверка проходит, фасилитатор также обрабатывает урегулирование, транслируя транзакцию в выбор блокчейна. АFacilitatorClientИнтерфейс определяет контракт, который должен реализовать любой клиент -фасилитатор:

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

Ваше приложение должно обеспечить конкретную реализацию этого интерфейса.

Пример интеграции

Теперь, когда мы видели отдельные компоненты (фильтры платежей, интеграция фасилитатора и обработка клиентов), давайте посмотрим, как эти произведения объединяются в реальном приложении. Вот минимальныйSpring BootПример, который демонстрирует полный поток.

Во -первых, создайте@PaymentRequiredАннотация:

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

Затем изменитьPaymentFilterЧтобы сканировать эти аннотации в Startup:

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

Теперь вы можете напрямую аннотировать методы контроллера:

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

А@PaymentRequiredаннотация обрабатывает конфигурацию ценообразования декларативно, в то время какPaymentFilterАвтоматически обнаруживает эти аннотации при запуске и строит таблицу цен. Ваша существующая бизнес -логика в методах контроллера остается совершенно неизменной. Конфигурация объединяет все вместе, зарегистрировав платежный фильтр и подключив его к службе фасилитатора. После развертывания запросы/weatherстоимость 0,001 USDC и/premium-forecastстоит 0,01 USDC, причем вся обработка платежей происходит прозрачно на уровне HTTP.

Соображения безопасности и производства

x402это просто и элегантно, скрывает сложность. Это профессионал и мошенник. Это делает интеграцию легкой, но также скрывает важный аспект:Агенты, отвечающие за деньги, создают новые векторы атакиПолем

ПокаEIP-712Подписи и управление, не обрабатывая атаки воспроизведения, что происходит, когда агент подвергается скомпрометированию? Традиционное обнаружение мошенничества зависит от поведенческих моделей человека, ноАгенты ИИ не следуют привычкам расходов на человекаПолем Комплексенный агент может истощать средства быстрее, чем любой человек -мошенник.

Компонент фасилитатора становится еще одной ценной целью, поскольку он проверяет подписи и управление NONCES. В отличие от традиционных обработчиков платежей, которые могут обратить вспять транзакции,Поселения блокчейна являются окончательнымиПолем

Сx402основан на транзакциях на цепь, он наследует операционные риски транзакций блокчейна. Плата за газ колеблется дико, иногда делает микропластики экономически неудобными. Сетевое перегрузка может задержать транзакции. Что должен делать агент ИИ, когда ему нужны данные в реальном времени, но платеж застрял в меморандуме?

Другим важным аспектом является регулирование. Соответствие варьируется в зависимости от юрисдикций с различными правилами об автоматических платежах, использовании криптовалюты и удержании данных. Агент искусственного интеллекта, издающий большой объем микротранзакций по границам, может вызвать оповещения о АМЛ или нарушать местные правила, никто не осознает этого.

Что дальше

Что интересноx402это время. Агенты ИИ нужны возможности автономного платежа, стаблеки обеспечивают программируемый денежный уровень, а инфраструктура блокчейна достаточно созрела для обработки масштабируемых приложений. Эти произведения не выровнялись раньше. Интернет теперь нуждается в новой форме платежей, и традиционные потоки не были созданы для автономных агентов или микропланшетов.

x402убедительно благодаря своему прагматическому подходу. Вместо переосмысления платежей с нуля, он расширяет существующую HTTP -инфраструктуру. Вместо того, чтобы требовать новых интеграций, он работает со стандартными шаблонами, которые мы уже понимаем.

Проблемы безопасности и эксплуатации реальны, но это инженерные проблемы с возможными решениями.

Через почти три десятилетия,HTTP 402Наконец -то может сделать то, для чего он был разработан: сделать оплату за вещи в Интернете, так же простой, как их просить.

Фонд установлен. Теперь пришло время построить.

СпасибоЭрик РеппельВРонни КасперсВКевин ЛеффуВДэнни органи вся команда вCoinbaseДля открытого источника этого протокола.

СпасибоЭрик РеппельиЮга Колердля обзораМой вкладкx402Полем

Ресурсы и дальнейшее чтение

• Http 402 Требуется оплата - RFC 2068- Оригинальная спецификация HTTP 1997 года
• X402 Спецификация протокола- Официальная документация по протоколу
• x402 Репозиторий GitHub- Реализация с открытым исходным кодом Coinbase
• x402 реализация Java- PR, который представил Java реализацию протокола
• EIP-712: ethereum typed структурированное хэширование и подписание данных- Стандарт подписания, используемый в X402
• Базовая сеть документация- Платформа блокчейна уровня 2, используемая в примерах
• Документация USDC- Подробная информация о контракте с Coin Uss Coin StableCoin
• Документация по ботинкам пружины- Реализация промежуточного программного обеспечения Java
• Java http client api- HTTP-обработка на стороне клиента
• Стандарты связи с машиной до машины (M2M)- Общение с автономной системой
• Автономные архитектуры агента ИИ- Исследование по образцам дизайна агента искусственного интеллекта
• Googles подход к защиту агентов ИИ- Предложения Google безопасной, управляемой человеком фреймворком AI Ag Agent