Coinbase подталкивает x402 к нейтральной позиции, Stripe делает ставку по обе стороны вне MPP

Автор: Charlie Liu, партнер Generative Ventures

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

Особенно на прошлой неделе все были заняты тем, чтобы разобраться в MPP от Stripe / Tempo — и вдруг Stripe уже присоединилась к x402 Foundation своего конкурента Coinbase.

Причём Cloudflare теперь поддерживает обе эти версии. Google тоже участвует в этой истории, но у него при этом есть AP2 и UCP.

Пришли и Visa, и Mastercard, но очевидно, что они не собираются поддерживать стейблкоины.

Linux Foundation публично определил x402 как нейтральный, управляемый сообществом «пункт базирования» отраслевого масштаба, а Cloudflare прямо включил x402 и MPP одновременно в свой Agents SDK, Stripe тоже публично написал, что поддерживает и MPP, и x402.

Так кто с кем конкурирует, и кто с кем накладывается?

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

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

Настоящая стратегическая история — кто определит по умолчанию слой контроля paid machine access в agentic web; и, что показательно, ключевые игроки явно находятся в multi-home, потому что все ещё спорят о том, где в будущем окажется главный узкий момент: в авторизации, в дистрибуции или в расчётах.

I. Почему Coinbase отпустила и передала x402 Foundation в Linux?

Если x402 — это просто протокол Coinbase, ему будет сложно стать отраслевым выбором по умолчанию.

Это не фраза из серии политической корректности, а вполне реалистичная логика стандартизации.

На этот раз формулировка Linux Foundation очень ясная: он подчёркивает нейтральность провайдера, управление сообществом и разделяемую базовую инфраструктуру, а не «какая-то компания выпустила продуктовую новую функцию».

Ещё важнее то, что на странице x402 Foundation сейчас написано: проект находится в стадии создания, механизмы управления и совет директоров ещё собираются.

То есть этот шаг — сначала не про то, что «продукт уже зрелый», а про то, что «мы дадим этому протоколу нейтральный дом».

Подтекст за этим на самом деле очень простой.

Если x402 будет всё время развиваться с лицом функциональности продукта Coinbase (например, как сейчас Base), то облачные провайдеры, платёжные компании, карточные организации и платформенные игроки, даже если технически и готовы подключаться, будут колебаться на политическом уровне.

Никто не хочет отдавать будущий paid access layer в руки одной-единственной платформы. Передать его под Linux Foundation — это не потому, что Coinbase не хочет контролировать, а как раз потому что Coinbase, наоборот, очень хочет, чтобы x402 широко приняли, и поэтому нужно сначала снять с него «это протокол Coinbase» как политический багаж.

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

Но в протокольной войне управление — это часть продукта.

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

С другой стороны, если x402 в будущем действительно сможет стать неким HTTP-native paid access baseline, то, возможно, это будет не потому, что его код самый красивый, а потому что** он раньше других сценариев снизил политическую стоимость.**

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

II. Что именно делает Stripe в «левой и правой» борьбе?

Из всех игроков, на которых сейчас больше всего стоит смотреть, безусловно, Stripe — потому что действия Stripe легче всего вызывают недоумение.

С одной стороны, 18 марта она с большим шумом представила MPP, упаковав это как открытый стандарт машинных платежей.

С другой стороны, она же является founding contributor x402 Foundation, и её собственная документация также поддерживает x402 machine payments.

Документация Cloudflare даже прямее: там прямо написано, что core payment flow MPP для x402 backward-compatible, и MPP client может напрямую потреблять существующие сервисы x402.

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

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

Потому что Stripe, возможно, на самом деле хочет удержать не сам handshake 402 как таковой.

Ей важно удержать несколько уровней поверх handshake: credentials, compliance, risk, reporting, tax, refunds, merchant integration.

Stripe выглядит не как истинный «верующий» в каком-то одном протоколе, а скорее как человек, который обеспечивает: независимо от того, какой handshake-стандарт в итоге победит, Stripe останется дефолтным абстрактным слоем для agent payments.

Поддержка x402 — чтобы не выпадать из открытой экосистемы; продвижение MPP — чтобы участвовать в определении базовых семантик; а продвижение ACP и Shared Payment Tokens дальше — чтобы удержать более толстую ценность на уровне рабочих процессов и платежных удостоверений.

Так что самое «странное» в этой истории у Stripe — на самом деле самое честное.

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

III. На самом деле это история про B2B-инфраструктуру

Мне всё больше кажется, что многие медиа смещают фокус в этой истории.

Когда речь заходит об agent payments, в первую очередь обычно вспоминают ритейл: AI поможет купить авиабилет, забронировать отель, оформить заказ, провести checkout.

Но если посмотреть на то, что уже реально публично внедрено и уже имеет «запах инфраструктуры», то первым запускается не checkout в ритейле, а более скучный — и более реальный — B2B paid access: платные API, платные данные, платные инструменты, платные сессии браузера, платные agent workflow.

Cloudflare сейчас публично поддерживает оплату x402 и MPP для HTTP-контента, API и MCP tools.

Самый сильный путь внедрения x402 — это developer-to-developer платные API и tools, потому что «no account + pay-per-request» здесь не рекламный трюк, а вполне практическое, рабочее решение.

Изменение, которое стоит за этим, на самом деле очень большое.

Раньше, чтобы API было платным, обычно сначала нужно пройти целую цепочку «дружелюбных для человека» шагов: открыть аккаунт, привязать billing, выпустить API key, задать лимиты, сверить отчёты, а затем уже разбираться с правами на платежи.

Для людей и так достаточно раздражающе; для агентов — ещё менее удобно.

Самая привлекательная часть x402 — не в том, что он более crypto, и не в том, что он более AI, а в том, что он пытается вернуть «оплачиваемый доступ» обратно в сам HTTP, так чтобы контроль доступа и платёжные переговоры происходили примерно так же, как обычный request-response.

Сервер возвращает 402, сообщая, сколько стоит этот запрос; клиент оплачивает, а затем повторяет тот же запрос, используя платежное удостоверение.

Если смотреть на эту модель с точки зрения B2B software и machine-to-machine access, она оказывается более естественной, чем с точки зрения ритейла.

И чем дальше в сторону B2B, тем сильнее преимущества x402 и тем менее критичны его слабые места.

Потому что в consumer commerce такие вещи — как возвраты, chargeback, merchant-of-record, consumer protection, распределение ответственности — это настоящие «жёсткие проблемы»; но в B2B API и вызовах инструментов значимость этих проблем заметно падает.

Напротив, реальная потребность — это «без аккаунта, платишь за вызов, получил результат — и ушёл».

Ритейл, конечно, больше, шумнее и, как правило, сильнее цепляет внимание; но то, как именно выглядит протокол, чаще всего определяется не самым шумным сценарием, а самым ранним, в котором реально проявляются настоящие потребности.

Для этой волны agent payments с высокой вероятностью ключевой сценой становится не корзина, а всё больше paid access между разными программами, агентами и рабочими процессами.

IV. Динамика отрасли подтверждает мою прежнюю оценку про interoperability

В моей предыдущей статье ключевая мысль — interoperability.

Тогда это звучало немного так, будто «так и должно быть с архитектурной точки зрения».

Теперь это всё больше похоже на реальные ограничения, потому что публичные рынки уже «голосуют ногами».

Cloudflare не выбрал одну сторону: он одновременно поддерживает x402 и MPP и при этом чётко делает совместимые мэппинги.

Google участвует в x402 и параллельно продолжает продвигать AP2 и UCP.

Visa и Mastercard тоже не выражают стратегию в духе «all in на единственного победителя»: с одной стороны они подключаются к x402, с другой продолжают усиливать агентские токены, аутентификацию, валидацию инструкций и dispute signals.

Многополюсные ставки гигантов — рациональное решение, а не коммерческая лицемерность.

Почему так? Потому что эти протоколы вообще не лежат на одном и том же уровне.

По крайней мере на сегодня **x402 и MPP ** ближе всего к уровню paid HTTP handshake: они решают вопрос, «как запросу принести в себе платежеспособность».

**AP2 ** ближе всего к авторизации и проверке доверенных намерений: он отвечает на вопрос, «есть ли у этого агента право потратить эти деньги».

**UCP и ACP ** же больше похожи на слой workflow: они разбираются с discovery, checkout, отношениями с мерчантом, передачей удостоверений и другими вопросами более верхнего уровня.

То, что многие компании поддерживают x402, MPP, AP2, UCP одновременно, не потому, что они сами не понимают, а потому что** в итоге выигрышная архитектура с высокой вероятностью окажется кросс-уровневой и даже потребует, чтобы несколько протоколов работали вместе.**

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

Сейчас это ещё и активно подтверждается рынком.

Ещё точнее: эта оценка важна и для различия B2B vs ритейл.

Потому что в мире ритейла, возможно, всё-таки всё в конце концов втянется в несколько крупных платформ и несколько крупных рабочих процессов; но в мире B2B всё иначе.

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

Кто пытается новым протоколом «снести» весь стек предприятия и переделать всё с нуля, тот с высокой вероятностью сначала умрёт.

То, за что B2B-клиенты действительно готовы платить, обычно не «единственно правильный протокол», а «возможность заставить существующие системы работать в среде из нескольких протоколов».

И эта логика как раз делает interoperability в сценариях предприятия более жёсткой, чем в consumer-сценариях.

V. Это не просто конкуренция протоколов, а конкуренция stack после расслоения

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

Самый нижний слой — paid access handshake.

Здесь важны вопросы: как HTTP-запрос выражает «нужна оплата» и как после оплаты клиент возвращает платежное удостоверение.

x402 и MPP в основном конкурируют именно здесь. MPP пытается подтянуть 402 к более формальным HTTP auth semantics; а x402 больше похож на «платформизацию» 402: через кастомные header’ы, facilitator, абстракции ончейн-расчётов и интеграции с экосистемой, чтобы оно сначала запустилось.

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

Следующий слой — authority to spend, то есть «кто разрешил потратить эти деньги».

Именно этот слой — критически важный, но многие сейчас ещё до конца не осознают.

Машина может заплатить — это не так сложно; сложно другое: чтобы машина могла быть доверенно уполномочена заплатить.

AP2 важен как раз потому, что он решает не только «как платить», а вопросы mandates, verifiable credentials, authenticity, accountability.

Усиление со стороны Visa и Mastercard — агентские токены, instruction validation, passkeys, dispute signals — по сути тоже находится здесь.

Ещё выше — workflow и distribution.

То есть discovery, checkout, отношения с мерчантом, sharing credentials, AI surface integration — всё то, что ближе к тому, «кто управляет трафиком и оркестрацией транзакций».

UCP и ACP больше похожи на борьбу за этот слой.

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

Потому что если всё больше корпоративного софта будет агентами координироваться, вызываться, закупаться и оплачиваться, то тот, кто владеет workflow language, будет управлять не одной оплатой, а всем рабочим процессом.

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

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

И именно поэтому многополюсные ставки — это не метания, а рациональность.

VI. Настоящий риск x402 — возможно, не регуляторика, а экономика при параллелизме

Если мы просто осознаем «многопротокольность», этого ещё недостаточно.

Главный риск x402 может быть не в первую очередь в регулировании, а в time-of-check/time-of-use экономике, возникающей из-за разбиения verify–settle на два шага.

Упрощённо: если верификация платежа и финальный расчёт — не одно и то же, то в условиях высокой конкуренции, ретраев, агентского слоя, кэширования и других реалий настоящего интернета появляется окно для сценария «заплатил один раз — доступ получил много раз».

Экосистема x402 сейчас тоже «затыкает дыры»: settlement cache, idempotency extension, payment identifier — но именно это и показывает, что проблема не надуманная.

Почему это особенно важно для B2B-читателей?

Потому что B2B больше всего боится не того, что красивый demo не получится, а того, что edge case’ов слишком много и в проде всё начнёт протекать.

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

Поэтому если x402 действительно когда-нибудь сможет закрепиться в B2B, важное условие будет не в narrative, а в том, что эти default-safe механизмы должны быть сделаны настолько «без мозгов», чтобы ими можно было пользоваться безопасно; иначе предприятия не будут доверять подключению реального трафика.

VII. Протоколы могут быть бесплатными, но КПП/платные ворота не исчезнут

Есть ещё один момент, который я считаю важным проговорить здесь до конца.

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

x402 — то же самое.

Стандарт, конечно, подчёркивает открытость, нейтральность и отсутствие 0 fees built into the standard, но это не означает, что value capture исчезнет.

Если x402 добьётся успеха, основная ценность не останется в самом протоколе, а будет мигрировать в соседние слои: facilitator, кошельки и key management, discovery, policy engine, trust wrapper и т.п.

Для B2B это особенно важно.

Потому что корпоративные клиенты не будут платить большие деньги просто ради нового протокола и не будут массово переделывать весь стек. Они действительно будут готовы платить тому, кто поможет им навести порядок со всем этим в среде нескольких протоколов: orchestration, policy, risk, compliance, audit, settlement, границы разрешений.

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

Вот почему я считаю, что при взгляде на x402 сегодня нельзя ограничиваться тем, кто больше похож на «главного героя» — Coinbase, Cloudflare или Stripe.

Реально стоит следить за тем, у кого больше всего шансов занять эти соседние слои.

У Cloudflare есть позиция на edge и в распределении трафика; у Stripe — позиция в платежной инфраструктуре и отношениях с мерчантами; у Visa и Mastercard — позиция в удостоверениях, сетевых token’ах и в consumer trust; у Google — позиция в workflow и в discovery surface.

Где именно произойдёт захват ценности, может зависеть не от того, «кто определил 402», а скорее от того, «кто подключил 402 в более крупную корпоративную систему».

VIII. Заключение

История с x402 Foundation — это не заявление о том, что x402 уже победил во всех agentic commerce протоколах.

Это публичное признание того, что это поколение agent payments с самого первого дня не будет миром одного-единственного протокола.

Передача Coinbase x402 в Linux Foundation нужна, чтобы сделать его больше похожим на нейтральный общественный слой, а не на эксклюзивный продукт.

Продвижение Stripe MPP параллельно с подключением к x402 — это не колебания, а потому что Stripe знает: сейчас нельзя делать ставку только на одну сторону.

Поддержка Cloudflare обеих версий — потому что он находится ближе всего к реальному трафику.

Действия Google, Visa, Mastercard, Adyen и других игроков тоже показывают одно и то же: сначала пусть система сможет быть взаимосвязанной, а потом уже обсуждать, кому в итоге достанется слой «последнего владения».

А если сместить перспективу от ритейла, это понимание становится ещё более логичным.

Потому что в первую очередь эти протоколы нужны не столько корзинам, сколько всё большему числу B2B софта и сервисов, которые берут оплату за вызов, за задачу, за результат.

Ритейл, конечно, больше по объёму, но B2B часто раньше раскрывает реальные требования и раньше определяет, как именно в итоге будет выглядеть инфраструктура.

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

В этом смысле x402 Foundation — не концовка этой истории.

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