Освободит ли агентный коммерс двухуровневую платежную систему для транзакций, основанных на ИИ?

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

От ориентированных на людей платежей к рельсам, ориентированным на ИИ

В период с сентября 2025 по март 2026 года каждый крупный игрок в глобальных платежах перешёл к AI-ориентированной коммерции. OpenAI и Stripe запустили Agentic Commerce Protocol, а Google представила Universal Commerce Protocol более чем 30 ритейл-и финтех-партнёрам.

В тот же период Visa и Mastercard выпустили платёжные фреймворки, ориентированные на агентов. Coinbase продвинула стандарт x402, проведя более 15 миллионов транзакций в Base. Кроме того, Stripe и Tempo совместно авторизовали Machine Payments Protocol и подали его на стандартизацию в IETF.

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

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

Коммерческая оркестрация: как сходятся агентные транзакции

Уровень оркестрации определяет, как агент находит сервис, управляет сессией и передаёт управление платежу. Появились две distinct категории сценариев использования, и их смешение грозит неправильным пониманием структуры рынка.

1.1 Агенты, действующие от имени потребителей

Для агентов, покупающих от имени людей, главная проблема сегодня не в механике платежей, а в доступе. Большинство платформ электронной коммерции оптимизированы для навигации человеком. Однако агент не должен скроллить страницы товаров, интерпретировать баннеры или нажимать кнопку “add to cart”.

Вместо этого продавцам нужны структурированные, доступные для машинного чтения конечные точки. Они всё ещё редки, что ограничивает нативные взаимодействия агентов. Первая волна протоколов в этом сегменте идёт от OpenAI, Stripe и Google — и каждый предлагает свой подход к контролю и открытости.

OpenAI и Stripe запустили Agentic Commerce Protocol (ACP) в сентябре 2025. Протокол фокусируется на безопасной передаче платежа на этапе оформления: способ оплаты пользователя сохраняется в ChatGPT, а после подтверждения покупки Stripe выпускает Shared Payment Token (SPT) — учётные данные единовременного использования, привязанные к продавцу и общей сумме корзины.

Этот токен доставляется продавцу через API, а продавец сохраняет полный статус Merchant of Record и обрабатывает платеж через существующую инфраструктуру Stripe. SPT Stripe на момент написания этих строк — первая работающая реализация этой модели делегирования, и она совместима со спецификацией Delegated Payment Spec от OpenAI. Другие PSP могут реализовать спецификацию, делая ACP открытым на уровне платежей.

ChatGPT Instant Checkout запустили в сентябре 2025 для пользователей в США, но в марте 2026 его закрыли после почти нулевой конверсии. После этого OpenAI сместилась к обнаружению: ChatGPT теперь показывает продукты и перенаправляет пользователей на сайты продавцов или в их приложения для оформления. ACP сохраняется в более узкой роли, обеспечивая специализированные in-ChatGPT приложения для небольшого набора крупных ритейлеров.

Продавцам нужно подать заявку на участие, а OpenAI контролирует, кто будет показан и в каком рейтинге. Тем не менее, эта курируемая модель даёт OpenAI сквозной контроль над in-assistant experience, при этом делегируя расчёты сторонним процессорам вроде Stripe.

Universal Commerce Protocol (UCP) от Google представляет контрастирующую стратегию. UCP, объявленный Сундаром Пичаи на конференции NRF 11 января 2026 года, разрабатывался совместно с Shopify, Etsy, Wayfair, Target и Walmart, и получил поддержку более чем 20 партнёров, включая Adyen, American Express, Best Buy, Mastercard, Visa, Stripe и The Home Depot.

UCP явно согласован с собственным агентным протоколом платежей Google (AP2), стандартом Agent2Agent (A2A) и Model Context Protocol (MCP). Этот шаг по интероперабельности — намеренная попытка занять высокую позицию по индексации и доступу. Google Pay служит методом оплаты по умолчанию, при этом PayPal анонсирован как опция, которая будет доступна в будущем.

Технически UCP работает через манифест возможностей, известный как UCP profile. Продавцы публикуют структурированный JSON-документ по адресу /.well-known/ucp в своём домене, указывая методы транспорта, возможности оформления и поддерживаемые обработчики платежей. Агенты читают эти манифесты напрямую, без посредников.

Архитектура отражает стратегические приоритеты Google. Google не особо заинтересована в брокерировании транзакций, что могло бы создать давление на маржу, повысить юридическую ответственность и привести к дополнительному регуляторному контролю. Вместо этого она хочет полную видимость в “коммерческом вебе”. UCP позиционирует Gemini как основной уровень обнаружения для агентского шопинга, оставаясь при этом в основном невидимым на уровне расчетов.

Контраст с ACP резкий. ACP — это курируемая среда, где OpenAI выступает привратником, продавцы должны подать заявку, а поток оптимизирован внутри ChatGPT. UCP работает как открытый каталог: продавцы публикуются сами, любой совместимый агент может потреблять профили, а Google контролирует поверхность обнаружения, но не сам платеж.

Снижение трения при подключении ниже, и потенциальный охват шире в рамках UCP, но продавцы получают меньше прямого “ведения за руку”. По сути, ACP меняет открытость на контроль, а UCP меняет контроль на широту индекса и стандартизацию на уровне протокола.

1.2 Агенты, совершающие транзакции с другими агентами

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

Нет законов о защите потребителей или прав на chargeback по картам, на которые можно опереться. Более того, стороны могли вообще никогда не взаимодействовать прежде, но им всё равно нужно безопасно обменяться ценностью. Именно эту проблему и пытаются решить новые стандарты Ethereum.

Предложенный 10 марта 2026 года командой dAI Ethereum Foundation вместе с Virtuals Protocol, ERC-8183 структурирует каждую транзакцию как job из трёх сторон. Client заказывает работу, Provider её выполняет, а Evaluator подтверждает завершение.

Средства удерживаются в smart-contract escrow и освобождаются только после того, как Evaluator ставит подпись. Ни Client, ни Provider не нужно оценивать доверительность друг друга; контракт механически закрепляет итог. Параллельно ERC-8004 определяет слой идентичности, на котором держится этот механизм.

В рамках ERC-8004 агенты регистрируются on-chain и строят скоринговую репутацию на основе истории транзакций. Это создаёт переносимый сигнал доверия, который сохраняется между взаимодействиями. В теории дизайн надёжен; однако масштабирование принятия (bootstrapping) остаётся практической “узкой горловиной”.

Сегодня большая часть реального использования сосредоточена внутри платформы Virtuals Protocol. Оркестратор-агент по имени Butler декомпозирует сложные задачи на sub-jobs и маршрутизирует их к специализированным агентам. Более широкое сообщество разработчиков пока не подключилось на сопоставимом масштабе. ERC-8183 по сути является попыткой сделать этот паттерн открытым и permissionless.

Один структурный момент следует напрямую. Розничная e-commerce может комфортно работать на карточных рельсах, потому что в контуре остаются люди-покупатели. Чистая agent-to-agent коммерция, напротив, вероятно потребует расчетов в стейблкоинах, поскольку комиссии по картам становятся невыгодными при очень маленьких размерах чеков и высокой частоте.

Протоколы расчетов: кто на самом деле двигает деньги

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

2.1 Delegated Payment Spec и SPT (Stripe)

Delegated Payment Spec от Stripe расширяет инфраструктуру карт, а не заменяет её. Когда клиент авторизует агента, Stripe выделяет SPT, который агент хранит. Во время транзакции агент предъявляет этот токен с ограниченным сроком действия и ограничением по сумме продавцу.

Дальше расчёты идут через существующий карточный стек Stripe. На бэкенде Stripe подключается к Visa Intelligent Commerce и Mastercard Agent Pay — они выпускают agentic network tokens. Продавцы видят единую поверхность интеграции независимо от того, какая именно карточная сеть находится “под капотом”.

Эта модель хорошо подходит для стандартных розничных покупок и многих платежей agent-to-agent высокой ценности, где chargeback и другие защиты потребителей остаются желательными. Но она плохо подходит для высокочастотных микрозначимых паттернов, например streaming-платежей machine-to-machine.

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

2.2 Visa Intelligent Commerce и Mastercard agentic tokens

И Visa, и Mastercard переработали свои токенизационные слои, чтобы поддерживать платежи, инициируемые агентами. Настоящие номера карт заменяются динамическими зашифрованными токенами, которые встраивают метаданные об авторизующем агенте — от идентичности до лимитов расходов и окон действительности.

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

Обе сети ушли далеко за пределы proof-of-concept. Mastercard обработала первую полностью идентифицированную агентную транзакцию в сентябре 2025, работая с Commonwealth Bank в Австралии. Visa завершила первые развертывания на европейских рынках через свою программу Agentic Ready.

Инфраструктура выглядит способной, но “fee floor” — структурное ограничение. Ни одна из сетей не может эффективно поддерживать платежи меньше одного доллара с плотностью, которую может потребовать будущая агентная коммерция. Кроме того, регуляторные и комплаенс-слои ещё сильнее ограничивают эксперименты на самом “мелком” конце спектра.

2.3 x402 (Coinbase)

x402, в отличие от этого, начинается с HTTP, а не с карт. Он опирается на статус-код 402 “Payment Required”, который есть в HTTP spec с 1997 года, но почти не использовался. Когда агент запрашивает платный ресурс, сервер отвечает ответом 402, содержащим параметры платежа.

Агент подписывает авторизацию, и Facilitator завершает атомарный on-chain settlement в USDC или в других поддерживаемых токенах — обычно примерно за две секунды. Нет настройки аккаунта, нет распределения API key и нет enforcement KYC на уровне протокола. Управление находится у x402 Foundation, созданного Coinbase и Cloudflare.

К концу 2025 x402 обработал более 100 миллионов транзакций на Base, Solana и Polygon. Однако аналитики из Artemis, писавшие в феврале 2026, оценили, что значительная часть этого объёма отражает self-dealing и тестирование инфраструктуры, а не реальную коммерцию.

Годовой объём платежей по протоколу составляет порядка $600 миллионов, но концентрация и проблемы качества объёма существенны. При этом у x402 нет структурного “fee floor”; его явно проектировали для micropayments. Главный пробел — глубина принятия и плотность реальной коммерции, а не технический дизайн.

2.4 Nanopayments (Circle)

Nanopayments от Circle намеренно совместим с x402: используется HTTP 402 как триггер, но добавляется batched слой расчетов. Вместо того чтобы рассчитывать каждую оплату on-chain по отдельности, покупатели заранее пополняют аккаунт Circle Gateway и подписывают off-chain сообщения EIP-3009 для каждой транзакции.

Периодические batched расчёты с блокчейном распределяют стоимость газа по множеству платежей, делая переводы размером до $0.000001 экономически жизнеспособными. Фактически газ платится один раз при депозите, а не за каждый платеж — это критическая оптимизация для ультра-высокочастотных сценариев использования.

Компромисс в том, что оба контрагента должны депонировать в Circle Gateway, что создаёт полузакрытую сеть в текущей архитектуре. Nanopayments запустили на testnet в марте 2026 на 12 поддерживаемых цепочках. Кроме того, fee model выглядит убедительно для интенсивных потоков микроплатежей, если Circle сможет снизить трение при onboarding.

2.5 MPP Machine Payments Protocol (Tempo и Stripe)

MPP, соавтором которого выступают Tempo и Stripe, — самый амбициозный из пяти дизайнов расчетов. Он использует HTTP 402 как триггер и позволяет продавцам и агентам выбирать среди нескольких расчетных рельсов в рамках единой унифицированной среды.

Разработчикам больше не нужно жёстко вшивать в момент сборки ни инфраструктуру стейблкоинов, ни инфраструктуру фиата. Вместо этого агент может решить в runtime, какой рельс использовать, исходя из потребностей транзакции. Доступные варианты включают стабилькоин-расчёты Tempo, платежи Stripe SPT, токены карточных сетей и платежи Bitcoin Lightning, работающие на Lightspark.

Ключевым образом MPP добавляет примитив “session”, похожий на OAuth. Агент авторизуется один раз и заранее пополняет аккаунт, а затем получает real-time автоматизированные расчёты для последующих взаимодействий — без on-chain транзакции на каждый платеж.

Базовая спецификация отправлена в IETF как reference implementation HTTP 402. На момент запуска 18 марта 2026 mainnet Payment Directory уже интегрировал более 100 сервисов. Однако паттерны принятия всё ещё находятся на ранней стадии.

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

Реальность рынка: протоколы опережают развертывание

3.1 Где сейчас стоит рынок

Несмотря на быстрые запуски протоколов за последние шесть месяцев, коммерческое закрепление остаётся ограниченным. На уровне расчетов x402 лидирует по числу транзакций, но реальный ежедневный объём коммерции держится около $28,000. На уровне оркестрации Instant Checkout от ACP закрыли после исчезающе малых конверсий.

Новые стандарты вроде ERC-8183 и MPP показывают похожий паттерн: нарратив опережает фактическое внедрение. Отрасль достигла переломной точки, где большая часть протокольной архитектуры уже существует, но масштабированное коммерческое применение пока не началось.

Центральная “узкая горловина” — фрагментация на уровне оркестрации. Продавцам приходится работать с несколькими независимыми стандартами, каждый со своими distinct SDK, цепочками аутентификации и правилами комплаенса. Однако это повышает стоимость интеграции и снижает мотивацию к экспериментам.

Исторически такая фрагментация решалась агрегационным слоем, который унифицирует доступ через конкурирующие стандарты. Этот цикл может быть иным. Платформы с существенным трафиком агентных операций, включая OpenAI, Google и Microsoft, мотивированы поддерживать закрытые поверхности, а не передавать пользователей где-то ещё.

Эта же логика разворачивается регионально. Китай, Юго-Восточная Азия, Корея и Япония — каждая — развивают закрытые контурные экосистемы, опирающиеся на super-apps или доминирующие платформы. Более вероятный исход — набор параллельных региональных закрытых систем, а не единый открытый глобальный стандарт.

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

3.2 Где лежат возможности в ближайшей перспективе

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

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

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

Это формулирует конкретное требование к продукту: multi-rail wallet для агентов. Карточные рельсы, такие как SPT, токены агентов Visa и токены агентов Mastercard, продолжат поддерживать традиционную коммерцию продавцов. Рельсы стейблкоинов, такие как x402 и платежи session в MPP, будут закрепляться на on-chain API и agent-to-agent переводах.

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

Затем предприятия обеспечивают своих агентов стейблкоинами и делегированными картами. Агент платит, используя тот рельс, который принимает контрагент. Кошелёк, который бесшовно обрабатывает оба варианта в рамках одной интеграции, становится enabling layer для универсальных агентов, работающих в разных экосистемах.

Ценность такой интеграции накапливается с каждой транзакцией и с каждой новой платформой, формируя глубину инфраструктуры, которую сложно вытеснить, когда она уже создана. Кроме того, это позиционирует провайдера кошелька как нейтральный слой клиринга между фрагментированными средами оркестрации.

Agent-to-agent commerce: недостаточно развитая возможность

Вторая возможность находится на уровне приложений в agent-to-agent коммерции. Сегодня большинство A2A активности остаётся внутри крипто-ориентированных сценариев: агенты запрашивают on-chain данные, взаимодействуют с DeFi протоколами и выполняют транзакции в блокчейне.

Рынок пока не расширился до широкого набора реальных сервисов. Тем не менее, с точки зрения протокола агенты уже могли бы заказывать задачи вроде анализа данных, генерации контента, юридических исследований или code review, оплачивая их по принципу “за вызов”.

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

Этот сегмент ограничен проблемой cold-start. Системы идентичности вроде ERC-8004 требуют значительной плотности транзакций, чтобы сформировать убедительные скоринговые оценки доверия. Агенты без истории не имеют репутационного веса, поэтому контрагенты неохотно будут с ними транзакционировать.

Microsoft оценивает примерно 1.3 миллиарда активных AI агентов к 2028 году. Текущая установленная база на порядки меньше. Пропасть не закроется автоматически; именно это поддерживает низкую конкуренцию в ближайшей перспективе и делает раннее занятие позиций привлекательным.

Последствия выходят за рамки платежей и затрагивают бизнес-модели. Доминирующие модели интернета — реклама и подписки — исходят из наличия human buyers. Агенты не убеждаются через ads и им не нужны ежемесячные пакеты доступа; они платят за результат конкретных вызовов.

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

Насколько A2A экономика расширится за пределы крипто и станет ли HTTP 402 общей ценовой прослойкой для ПО — по сути один и тот же вопрос. Оба зависят от того, станут ли агенты регулярными экономическими акторами, совершающими сделки в масштабе по богатым сервисным каталогам “за вызов”.

Заключение: двухслойный стек и отсутствующие примитивы

Взгляд вперёд: агентная коммерция будет продолжать развиваться по двум отдельным трекам. Потребительские агенты, которые покупают товары для людей, в основном будут полагаться на карточные рельсы, развиваясь в темпе enterprise authorisation frameworks и доверия пользователей к новым платежным поверхностям.

В то же время протокольный стек агентной коммерции для программных платежей уже технически реализуем на стейблкоин рельсах. Он сейчас ждёт развертывания агентов и сервисов, которые требуют высокочастотных, программируемых расчетов в масштабе.

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

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

Триггер коммерческого масштаба — не “лучшие протоколы”. Это момент, когда предприятия делегируют агентам полномочия на расходы с аудируемыми следами, бюджетными контролями и чёткой ответственностью за ошибочные покупки. Когда этот порог будет пройден, две инфраструктурные позиции станут критическими.

Во-первых, multi-rail агентный кошелёк, поддерживающий как стейблкоины, так и платежи карт в рамках одной интеграции. Во-вторых, доступный каталог сервисов “за вызов”, позволяющий разработчикам без крипто-опыта выставлять API для агентных покупателей. Оба варианта — открытые возможности уже сегодня, и оба станут необходимыми, когда spending agents начнут работать в масштабах.