x402: код HTTP 402 стал платёжным протоколом

14 июля 2026 года Linux Foundation объявил об операционном запуске x402 Foundation — 40 организаций-участников, среди них Visa, Mastercard, Stripe, Shopify, Google, AWS, Cloudflare и Coinbase. Коротко: статус-код 402 Payment Required, зарезервированный «для будущего использования» ещё на заре веба, получил открытую спецификацию и вендор-нейтральное управление вместо статуса инициативы одной компании.

Проблема: агент умеет вызвать, но не умеет заплатить

Монетизация API сегодня спроектирована под человека. Регистрация, подтверждение почты, панель управления, привязка карты, копирование ключа, счёт в конце месяца. Для разработчика за клавиатурой это логично. И это полностью ломается, когда автономному агенту нужен один источник данных, один раз, посреди задачи.

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

Что изменилось: рукопожатие из трёх заголовков

x402 помещает платёж внутрь цикла HTTP, а не рядом с ним. Спецификация V2 определяет три заголовка, все в base64:

• PAYMENT-REQUIRED — от сервера клиенту, содержит платёжные требования.
• PAYMENT-SIGNATURE — от клиента серверу, содержит подтверждение авторизации платежа.
• PAYMENT-RESPONSE — от сервера клиенту, содержит результат расчёта.

На уровне провода обмен остаётся читаемым:

GET /v1/reports/q3 HTTP/1.1
Host: api.example.com

HTTP/1.1 402 Payment Required
PAYMENT-REQUIRED: <base64>

После декодирования заголовок — это явное описание того, что сервер готов принять:

{
  "x402Version": 2,
  "accepts": [
    {
      "scheme": "exact",
      "network": "eip155:8453",
      "amount": "10000",
      "asset": "0x<usdc-contract>",
      "payTo": "0x<treasury-address>"
    }
  ]
}

Затем клиент повторяет тот же запрос уже с авторизацией:

GET /v1/reports/q3 HTTP/1.1
Host: api.example.com
PAYMENT-SIGNATURE: <base64>

HTTP/1.1 200 OK
PAYMENT-RESPONSE: <base64>

На стороне сервера подключение — это middleware, объявляющий, что принимает каждый маршрут:

import express from "express";
import { paymentMiddleware } from "@x402/express";

const app = express();

app.use(
  paymentMiddleware({
    "GET /v1/reports/:id": {
      accepts: [
        { scheme: "exact", network: "eip155:8453", payTo: process.env.TREASURY },
      ],
      description: "Квартальный отчёт",
    },
  })
);

Три модели тарификации

Спецификация определяет три schemes. exact — фиксированная объявленная цена, которую покупатель авторизует заранее. upto — оплата по факту потребления: покупатель авторизует потолок, а списывается фактически использованное; это подходит для трафика, вычислений или объёма токенов. batch-settlement накапливает повторяющиеся микроавторизации в переиспользуемом канале и погашает их одной пачкой — именно это делает высокочастотный доступ экономически осмысленным.

Проверку и расчёт берёт на себя facilitator — сервис, который верифицирует и проводит платежи от имени сервера ресурса. Существует несколько продакшн-фасилитаторов для сетей EVM и Solana, команда может поднять собственный, а для экспериментов доступен тестовый без настройки.

Что изменилось между v1 и v2

В старых репозиториях названия будут другими. Миграция v1→v2 переименовала заголовки: X-PAYMENT стал PAYMENT-SIGNATURE, X-PAYMENT-RESPONSE — PAYMENT-RESPONSE. Идентификаторы сетей перешли на стандарт CAIP-2: base → eip155:8453, base-sepolia → eip155:84532. Пакеты разделены на более модульную структуру — @x402/core, @x402/express, @x402/evm, @x402/svm — с явной регистрацией схем вместо передачи кошелька напрямую в интерсептор.

Оговорки из практики

Стандарт перспективен, но решение о внедрении — инженерное и финансовое одновременно:

• Ончейн-расчёт стоит денег. Именно поэтому и появился batch-settlement: рассчитывать каждый вызов по отдельности для нагруженного API невыгодно.
• Выбор фасилитатора — вопрос доверия. Сервисы различаются поддерживаемыми сетями и комплаенс-проверками и находятся внутри денежного контура.
• Платёж — это не идентичность. 402 отвечает на вопрос «оплачено ли?», но не «кто вы?». Аутентификация и авторизация остаются отдельным слоем — см. недавнюю спецификацию MCP.
• Спецификация молодая. Переход с v1 на v2 уже сломал имена заголовков и пакетов. Разумно изолировать интеграцию за тонким заменяемым слоем.
• Аналога возвратов и чарджбэков карточных сетей нет. Это требует прописанной политики, а не предположений.

Вывод

x402 не столько даёт агентам новую способность, сколько убирает старое препятствие: запрос теперь может нести свою цену сам. Команды, которые поднимут один тарифицированный маршрут за 402 уже сейчас — пусть даже в тестовой сети — накопят операционный опыт до того, как вопрос станет срочным.

Первоисточник: анонс Linux Foundation об операционном запуске x402 Foundation и официальная документация на docs.x402.org.