Машинные платежи и решения на основе HTTP 402 набирают популярность и вокруг них появляется всё больше хайпа.

Если отбросить весь шум вокруг AI-агентов и посмотреть на это просто как на платежи, идея довольно простая:

• у пользователя (или агента) есть кошелёк с балансом (крипто или фиат — неважно)
• он платит за фактическое использование (запрос к сервису), а не за подписку
• сервисы становятся доступнее, их проще получить и использовать

Простой пример:

• сегодня: 5 подписок по $20 → это всего 5 сервисов, и:
  • нужно регистрироваться и оформлять подписку
  • иногда создавать API-ключи или разбираться с авторизацией
  • возможно, вы даже не используете подписку на всю её стоимость
• с машинными платежами по модели pay-per-request:
  • можно потратить $0.5 на 1–2 запроса и понять, нужен ли вам сервис
  • использовать сервис на $3–5 вместо полноценной подписки
  • пробовать и использовать больше разных сервисов в целом

Это довольно сильно меняет UX.

И именно здесь появляются два разных подхода: x402 от Coinbase и MPP (Machine Payment Protocol) от Stripe и Tempo.

Оба протокола по-своему хороши и у каждого есть свои сильные стороны и ограничения.

Общая модель: HTTP 402 как транспорт

Оба протокола используют один и тот же базовый механизм — HTTP 402 Payment Required.

Раньше HTTP-запрос был просто запросом данных.

Теперь он становится чем-то вроде запроса с платёжным условием.

Поток (или модель выполнения) в обоих случаях одинаковый:

1. клиент делает запрос
2. сервер отвечает: «заплати» (HTTP 402)
3. клиент платит
4. повторяет запрос
5. получает результат

На этом уровне сходство в основном заканчивается.

Где начинаются отличия

Если копнуть чуть глубже, различия проявляются в философии и реализации:

• x402
  • более конкретный, crypto-native подход
  • готовый к использованию платёжный метод
• MPP
  • более общий, гибкий подход
  • способ описать, как должен происходить платёж

Разница тонкая, но фундаментальная.

Платёжная модель

x402: встроенный платёжный метод

x402 изначально проектировался как crypto-native решение.

• платежи через ERC-20
• используются подписи (ERC-3009, Permit2)
• клиент отправляет подписанную транзакцию
• транзакция коммитится ончейн через фасилитатора

Клиент просто подписывает транзакцию и отправляет её.

Это даёт прозрачность, проверяемость и децентрализацию (фасилитаторов может быть несколько).

В то же время это создаёт ограничения — только криптоактивы, зависимость от блокчейна, задержки и комиссии.

MPP: intent-based модель

MPP вводит более абстрактную модель:

• сервер возвращает payment intent / challenge
• клиент выполняет его
• сервер валидирует результат

Важно:

• протоколу всё равно, каким именно является платёж
• он определяет только как проверить, что платёж произошёл

Это позволяет реализовывать разные платёжные методы:

• Stripe / обычные карты
• крипто
• кастомные схемы

В то же время вся логика валидации переносится на сторону сервера.

Здесь отличие фундаментальное:

И это становится заметно уже на этапе интеграции.

Обработка платежей

x402: фасилитатор как отдельный слой

Здесь x402 старается следовать децентрализации и криптофилософии.

x402 вводит отдельную сущность — фасилитатора.

Он нужен потому что:

• кто-то должен отправить транзакцию в блокчейн
• кто-то должен подтвердить, что она прошла

Сервер обычно не делает это самостоятельно и делегирует задачу фасилитатору.

Поэтому поток выглядит так:

• клиент → сервер → фасилитатор → блокчейн

В криптоконтексте это имеет смысл, но добавляет дополнительный слой.

С одной стороны:

• можно использовать несколько фасилитаторов
• не нужно поднимать собственную инфраструктуру

С другой:

• появляется зависимость
• часть логики уходит за пределы вашей системы

MPP: абстракция валидации

MPP следует другой философии — это прежде всего протокол, сфокусированный инструкциях и проверках.

Здесь используется модель challenge / validation:

• challenge — инструкции для клиента, как заплатить
• validation — серверная проверка того, что платёж был успешным

Сервер не говорит: «отправь именно такую транзакцию», он говорит:

«вот платёжные условия — выполни их».

Именно здесь MPP даёт гибкость.

Функция валидации на сервере может:

• проверить платёж локально
• или делегировать это внешнему сервису — блокчейну, платёжному процессору, фасилитатору

То есть архитектура не навязывается.

Это даёт больше свободы, но одновременно требует больше усилий и времени на реализацию.

Stateless vs Sessions

x402

Работает строго в модели один запрос — один платёж.

Это просто и предсказуемо.

Но если у вас, например, 100 запросов подряд — нужно 100 платежей.

MPP

Добавляет ещё один слой — сессии, при этом сохраняя поддержку разовых платежей.

Это уже ближе к реальному биллингу:

• вы открываете сессию
• делаете внутри неё несколько запросов
• платёж списывается позже или рассчитывается по фактическому использованию

Это существенно меняет UX:

• меньше операций
• ниже задержки
• проще работать с high-load сценариями

И здесь MPP даёт больше гибкости.

Сложность интеграции

x402

С x402 всё довольно прямолинейно.

Есть хорошая документация, SDK и готовые примеры. Протокол уже определяет:

• как платить
• как валидировать
• какие форматы использовать

Благодаря этому интеграция быстрая — особенно если вы уже работаете с EVM / Solana и USDC.

Также есть стандартизация: если токен поддерживает ERC-3009 или Permit2, можно просто добавить новую сеть — остальная логика остаётся прежней. Для этой сети нужен только фасилитатор.

MPP

С MPP ситуация другая.

Если вы используете готовые платёжные методы (например, Stripe, Tempo или другие готовые решения), базовая интеграция тоже простая.

Но после этого вы начинаете принимать решения, которые x402 уже принял за вас.

Например, нужно решить:

• работаете ли вы в режиме разового платежа (charge)
• или используете сессии

А если хочется чего-то кастомного (другая сеть, токен или процессор), придётся реализовать:

• собственные payment intents / challenges
• собственную логику валидации платежей

Технически это требует больше времени и архитектурных решений.

И здесь становится понятен главный компромисс:

в MPP сложность — это цена, которую вы платите за гибкость

В итоге:

• x402 — быстрее старт, меньше работы
• MPP — больше контроля, больше работы

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

Совместимость

x402 появился раньше и уже используется со своими правилами и экосистемой.

MPP — более новый протокол, но он проектировался с учётом существующих подходов, включая x402.

Ключевая мысль:

MPP можно реализовать так, чтобы он был совместим с x402

Другими словами, если вы строите систему на MPP, вы всё равно можете работать с серверами, которые используют x402.

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

Масштабируемость

Если смотреть на реальный мир, существует много платёжных методов: разные типы карт, банковские переводы, локальные системы, крипто (с разными сетями и токенами).

И пользователи в разных регионах будут использовать разные варианты.

Поэтому для сервиса важно:

• поддерживать несколько платёжных методов
• не ограничивать пользователя
• масштабироваться по мере роста сервиса

x402

У x402 есть определённые ограничения.

Да, его можно обернуть через процессоры вроде Stripe, но на практике платёж всё равно в итоге становится блокчейн-транзакцией.

То есть: даже если пользователь «платит картой», под капотом это всё равно крипто

MPP

MPP не привязан к конкретному платёжному методу.

Он позволяет:

• использовать разные платёжные рельсы
• адаптироваться под регионы
• использовать сессии вместо оплаты каждого запроса

Это уже ближе к реальным биллинговым системам.

MPP даёт больше гибкости для масштабирования и в этом выглядит сильнее.

Можно спорить о разных реализациях — что проще, что сложнее и так далее.

Но на самом абстрактном уровне протокол — это просто:

набор заголовков + правила их обработки

А фактическую обработку можно реализовать по-разному.

Тем не менее я лично придерживаюсь описаний протоколов и стараюсь не отклоняться от их оригинальных спецификаций.

И с этой точки зрения у MPP явно есть преимущество.

Discovery и машиночитаемое описание

Ещё одна очень важная тема — discovery в обоих протоколах.

Не просто «как заплатить», а как найти нужный сервис и понять, что он умеет.

x402

В x402 это решается через bazaar discovery layer.

Он реализован на уровне фасилитатора:

• сервер объявляет discovery metadata (описание своих маршрутов и endpoints)
• фасилитатор извлекает и агрегирует эту информацию
• клиент запрашивает фасилитатор для обнаружения доступных сервисов

По сути:

фасилитатор становится API-маркетплейсом

Это особенно полезно для AI-агентов, которые могут использовать фасилитатор как источник для поиска доступных инструментов.

И это открывает сильный use case:

много сервисов агрегируются в одном месте, и с ними можно сразу начинать взаимодействовать.

MPP

MPP использует другой подход.

Единой точки входа нет, но есть спецификация:

• каждый сервер должен отдавать openapi.json
• в нём описываются endpoints и pricing

Это более классический подход.

Но есть компромисс:

клиенту (или агенту) нужно опрашивать каждый сервис и собирать эту информацию самостоятельно

В отличие от x402, где фасилитатор может вернуть всё сразу.

В итоге здесь нет «правильного» ответа.

• x402 → централизованный discovery через фасилитатора
• MPP → децентрализованный discovery через OpenAPI

Оба подхода валидны и практичны.

Но лично для меня: discovery через фасилитатора — очень сильная и недооценённая возможность x402

И в этом аспекте он выглядит заметно удобнее.

Что выбрать

Итак, что в итоге выбрать и для каких сценариев?

На мой взгляд, оба протокола полезны, просто они находятся на разных уровнях абстракции.

x402 — хороший выбор, если:

• вам нужны только криптоплатежи
• важен быстрый и простой запуск
• вам интересна экосистема фасилитаторов и bazaar discovery

Это хороший вариант, когда нужно быстро запустить pay-per-request в криптосреде без лишней сложности.

MPP лучше подходит, если:

• вы планируете масштабироваться
• вам нужны разные платёжные методы (не только крипто)
• ожидается высокая нагрузка
• важны сессии и гибкий биллинг

Это ближе к построению полноценной платёжной инфраструктуры.

На мой взгляд:

• x402 — быстрый и прямолинейный вход
• MPP — фундамент для более сложных и масштабируемых систем