Coinbase просуває x402 у нейтральну позицію, Stripe робить ставки обох сторін поза MPP

Автор: Чарлі Лю, партнер у Generative Ventures

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

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

Ба більше, Cloudflare тепер підтримує обидві ці системи. У цій історії також є Google, але в нього самого є AP2 і UCP.

Прийшли також Visa і Mastercard, але очевидно, що вони не для того, щоб підтримати стейблкоїни.

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

То хто з ким конкурує, і з ким хто накладається?

Але що більше я дивлюся останніми днями, тим більше відчуваю: цей «хаос» не тому, що ринку бракує напряму, а тому, що ринок уже дуже чітко все розуміє — і, як я згадував раніше, з першого дня це ніколи не буде вирішено одним протоколом, який повністю уніфікує все.

Це радше схожа на дуже типову ситуацію в інтернет-інфраструктурі — різні рівні одночасно «ростуть», різні компанії роблять ставки на різних рівнях, а в підсумку все запускається завдяки інтероперабельності.

Справжня стратегічна історія — хто визначить у agentic web paid machine access типовий рівень контролю; і ключові гравці явно працюють у режимі 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, оформивши це як відкритий стандарт машинних платежів.

З іншого боку, Stripe — founding contributor x402 Foundation, і її власна документація також підтримує x402 machine payments.

Документація Cloudflare навіть пряміша: там чітко написано, що core-платіжний потік MPP для x402 є backward-compatible, тож MPP client може напряму споживати наявні сервіси x402.

Якщо дивитися лише через рамку «конкуренції протоколів», Stripe справді виглядає так, ніби вона робить взаємні рухи «зліва направо» — то туди, то сюди.

Але якщо підняти перспективу ще трохи вище, то виявляється: у цього підходу навпаки є дуже чітка комерційна логіка.

Бо Stripe насправді хоче захистити не обов’язково сам handshake 402.

Stripe справді хоче втримати те, що знаходиться поверх handshake: креденшали, комплаєнс, ризики, репортинг, податки, refund-и, інтеграцію мерчантів.

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, встановити ліміти, зробити звірку, а потім уже обробити дозволи на платежі.

Для людей це вже досить докучливо; для agent — тим паче.

Найпривабливіше в x402 — не те, що він більш crypto, і не те, що він більш AI; а те, що він намагається повернути «платний доступ» прямо в HTTP, так щоб контроль доступу й узгодження платежу відбувалися так само природно, як звичайний request-response.

Сервер повертає 402 — каже, скільки коштує цей запит; клієнт оплачує; після цього він повторює той самий запит уже з платіжним посвідченням.

Якщо дивитися на цю модель з позиції B2B софту та machine-to-machine access, вона буде значно доречнішою, ніж з позиції роздрібу.

І що далі в бік B2B, то сильнішими стають переваги x402 і тим менш фатальними — її слабкі сторони.

Бо в consumer commerce повернення грошей, чарджбеки, 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 one winner» — вони, з одного боку, приєднуються до x402, а з іншого продовжують нарощувати agent token, автентифікацію, валідацію інструкцій та dispute signals.

Багатосторонні ставки «гігантів» — це раціональне рішення, а не комерційна лицемірність.

Чому так? Бо ці протоколи взагалі не лежать в одному й тому самому шарі.

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

AP2 більше про авторизацію та довірені наміри: він вирішує «чи має агент взагалі право витратити ці гроші».

UCP і ACP натомість більше схожі на рівень workflow: вони беруться за питання discovery, checkout, мерчантських відносин, передавання посвідчень — це вже більш верхні проблеми.

Багато компаній одночасно підтримують x402, MPP, AP2, UCP не тому, що вони «не можуть розібратися»; а тому, що** архітектура, яка в підсумку виграє, дуже ймовірно буде перетинатися через кілька рівнів — і навіть потребуватиме спільної роботи кількох протоколів.**

Тож якщо підсумувати однією фразою моє попереднє припущення, то зараз я ще більше переконаний: без interoperability ця екосистема взагалі не піднялася б.

Зараз ринок активно підтверджує саме це.

Якщо ще точніше: це припущення важливе і для відмінності B2B vs роздріб.

Бо в роздрібному світі, можливо, справді все зрештою буде втягнуто в меншу кількість великих платформ і великих workflow; але в B2B це не так.

Компанії живуть у реальності, де співіснують мультихмари, різні способи платежу, різні системи робочих процесів і різні системи ідентифікації/прав доступу.

Хто спробує одним новим протоколом «знести» всю корпоративну лінійку й почати з нуля, той найімовірніше першими й збанкрутує.

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

Ця логіка якраз і робить interoperability у корпоративних сценаріях більш «твердою» вимогою, ніж у consumer-сценаріях.

V. Це не просто конкуренція протоколів, а конкуренція stack після розшарування

Як тільки ви почнете розуміти це як layered stack, багато з того, що раніше виглядало як хаос, одразу складається в логіку.

Нижній рівень — це paid access handshake.

Тут важливо: як HTTP-запит виражає «тут потрібна оплата», і як після оплати клієнт повертає платіжні креденшали назад.

x402 і MPP головним чином змагаються на цьому рівні. MPP намагається «підтягнути» 402 ближче до більш офіційних HTTP auth semantics; а x402 більше схоже на те, що «платформує» 402 — через власні заголовки, facilitator-и, абстракцію on-chain розрахунків і інтеграцію в екосистему, щоб це спершу запрацювало.

Один шлях більш схожий на стандартизацію семантики; інший — на платформу й дистрибуцію.

Вищий рівень — authority to spend, тобто «хто авторизував ці гроші».

Це ключова річ, яку багато хто ще не до кінця усвідомив.

Машини платять — це не так складно; складно, щоб машину можна було достовірно авторизувати витратити гроші.

AP2 важливий саме тому, що це не просто «як платити», а те, що він вирішує mandates, verifiable credentials, authenticity, accountability.

Ті агентні токени, instruction validation, passkeys і dispute signals, на які нещодавно додатково зробили ставку Visa і Mastercard, по суті теж лежать тут.

Ще вище — workflow і distribution.

Тобто discovery, checkout, merchant relationship, credential sharing, інтеграція AI на поверхні — це вже ближче до того, хто контролює потік і оркестрацію транзакцій.

UCP і ACP більше схожі на конкуренцію саме на цьому рівні.

Для B2B зараз це менш «шумно», але в довгу може бути дуже цінно.

Бо якщо в майбутньому все більше корпоративного софту буде координувати агентами, викликати, закуповувати й оплачувати, то хто володіє workflow language — той керуватиме не однією оплатою, а всім робочим процесом.

Коли ви розділяєте ці три рівні, стає зрозумілою дуже проста істина: не варто очікувати, що один протокол закриє всі питання.

Більш реалістичний шлях — щоб ці три рівні спочатку виросли кожен окремо, а потім через взаємодію вони повільно «зчепляться».

І саме тому багатосторонні ставки — це не хитання, а раціональність.

VI. Справжній ризик x402 — можливо, не регуляторика, а економіка при конкуренції

Якщо ми лише визнаємо факт «багатопротокольного співіснування», це ще недостатньо глибоко.

Найбільший ризик x402, можливо, навіть не регуляторний, а економіка, що виникає через розділення verify–settle на два кроки: time-of-check/time-of-use.

Просто кажучи: якщо верифікація оплати і фінальний розрахунок — це не одне й те саме, то в середовищі реального інтернету з високою паралельністю, ретраями, на рівні агентів і кешування з’являється «вікно» pay once, access multiple times.

Екосистема x402 зараз теж лататиме дірки: settlement cache, idempotency extension, payment identifier, але якраз той факт, що це робиться, показує: проблема не є лише теоретичною.

Чому це особливо важливо для B2B-читачів?

Бо у B2B світі найстрашніше — це не те, що красивий демо-варіант не зробити, а те, що edge case-ів забагато, і в кінці, коли все виходить у продакшн, починає «підтікати».

API монетизація виглядає як «копійка за запит»; але якщо ваш продукт стягує плату за виклик, за результат або за робочий процес, то питання «оплатив — отримав один раз» проти «оплатив — отримав багато разів» перестає бути деталлю продукту й стає лінією життя/смерті.

Тому якщо в майбутньому x402 справді зможе запуститися в B2B, важливо не те, який наратив, а те, щоб ці default-safe механізми були зроблені настільки безболісно, «без розуму», що підприємства не боялися б підключити реальний трафік.

VII. Протоколи можуть бути безкоштовними, але платіжний пункт не зникне

Ще один момент, який я вважаю варто проговорити до кінця.

Багато відкритих протоколів у фіналі доходять до дуже знайомого місця: сам протокол стає дедалі дешевшим, навіть безкоштовним, але поруч виростає справжній платний «пункт» — збирання цінності.

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

Сам стандарт, безумовно, підкреслює відкритість, нейтральність і 0 fees built into the standard, але це не означає, що value capture зникне.

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

Це особливо важливо для B2B.

Бо корпоративним клієнтам не вартує заради нового протоколу масово перебудовувати всю систему. Те, за що вони реально готові платити — це хто допоможе їм у середовищі з багатьма протоколами «прибрати» такі клопіткі речі, як оркестрація, policy, risk, compliance, audit, settlement, межі дозволів.

Інакше кажучи, протокол буде все більше схожий на мову низького рівня, але шар, який переводить ці мови в здатність «безпечно запускати в підприємстві», з більшою імовірністю стане новою платформою і новим платним «пунктом».

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

По-справжньому важливо — у кого є шанс зайняти саме ці сусідні рівні.

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

Справжнє захоплення цінності не обов’язково станеться там, де «хто визначив 402»; скоріше це станеться там, де «хто інтегрує 402 у більшу корпоративну систему».

VIII. Підсумок

Історія з x402 Foundation — це не про те, що x402 вже перемогла у всіх протоколах агентного комерсу.

Це публічне визнання того, що це покоління agent payments з першого дня не буде світом одного протоколу.

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

Stripe одночасно просуває MPP і приєднується до x402 — це не хитання, а тому що вона знає: зараз не можна ставити лише на одну сторону.

Cloudflare підтримує обидві системи, бо вона максимально близька до реального трафіку.

Дії Google, Visa, Mastercard, Adyen та інших також вказують на те саме: спершу дати системам бути сумісними, а вже потім говорити, хто врешті займе який рівень.

І якщо відсунути фокус від роздрібу, це припущення стає ще логічнішим.

Бо найпершими в цих протоколах можуть бути не кошики, а дедалі більше B2B софту і сервісів, які стягують оплату за виклики, за задачі, за результати.

Роздріб, звісно, більший, але B2B часто раніше розкриває реальні потреби й раніше визначає, як виглядатиме інфраструктура в кінцевому підсумку.

У моїй попередній статті я поставив interoperability у центр, і я вважаю, що відповідь, яку дає ринок сьогодні, дуже чітка: так — і навіть раніше, ніж тоді здавалося.

У цьому сенсі x402 Foundation — це не фінал цієї історії.

Це лише допомагає нам побачити раніше: справжня тема цієї історії — не «хто переможе», а «цьому світу заздалегідь призначено спочатку стати взаємопов’язаним, і хто після цього зможе зайняти найцінніший шар».