Чи відкриє агентський комерційний підхід двошаровий платіжний стек для транзакцій, орієнтованих на ШІ?

У міру того, як транзакції, орієнтовані на ШІ, переходять від концепції до впровадження, агентна комерція змушує кардинально переосмислити те, як працюють цифрові платіжні та інфраструктурні системи розрахунків.

Від платіжних систем, орієнтованих на людей, до рейлів, орієнтованих на ШІ

Між вереснем 2025 року та березнем 2026 року кожен ключовий гравець на глобальному ринку платежів перейшов до AI-керованої комерції. OpenAI та Stripe запустили Agentic Commerce Protocol, тоді як Google представила Universal Commerce Protocol більш ніж 30 роздрібним і fintech-партнерам.

Упродовж того самого періоду Visa та Mastercard оприлюднили платіжні фреймворки, орієнтовані на агентів. Coinbase просунула стандарт x402, здійснивши клиринг понад 15 млн транзакцій у Base. Крім того, Stripe і Tempo спільно авторизували Machine Payments Protocol та подали його на стандартизацію в IETF.

Таймінг не є випадковим. Платіжна інфраструктура минулих трьох десятиліть була створена для людей, які сидять у браузерах, заповнюють форми та проходять покрокову верифікацію. Однак AI-агентам потрібні програмні інтерфейси, майже миттєва авторизація та розрахунки, здатні обробляти транзакції в частках цента.

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

Комерційна оркестрація: як транзакції агентів складаються разом

Шар оркестрації визначає, як агент знаходить сервіс, керує сесією та передає керування платежу. З’явилися дві окремі категорії сценаріїв використання, і змішування їх ризикує призвести до непорозумінь у структурі ринку.

1.1 Агенти, що діють від імені споживачів

Для агентів, які купують від імені людей, сьогодні головна проблема не в механіці платежу, а в доступі. Більшість e-commerce платформ оптимізовані під навігацію людиною. Однак агент не має перегортати сторінки продуктів, інтерпретувати банери або натискати кнопку “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 зберігся у більш вузькій ролі — він живить окремі застосунки в ChatGPT для невеликого набору великих ритейлерів.

Мерчанти мають подати заявку для участі, а OpenAI контролює, хто з’являється і в якому рейтингу. Водночас ця кураторська модель дає OpenAI наскрізний контроль над досвідом “всередині асистента”, делегуючи розрахунки стороннім процесорам на кшталт Stripe.

Universal Commerce Protocol (UCP) від Google представляє контрастну стратегію. Оголошений Sundar Pichai на NRF Conference 11 січня 2026 року, UCP було розроблено спільно з 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 у своєму домені, вказуючи методи транспорту, можливості checkout і підтримувані платіжні обробники. Агенти читають ці маніфести напряму без посередників.

Архітектура відображає стратегічні пріоритети 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 структурує кожну транзакцію як трьохстороннє завдання. Client замовляє роботу, Provider її виконує, а Evaluator засвідчує завершення.

Кошти утримуються в escrow у smart-контракті та вивільняються лише тоді, коли Evaluator дає “добро”. Ні Client, ні Provider не потрібно оцінювати довіру один одного; контракт механічно забезпечує потрібний результат. Паралельно ERC-8004 визначає рівень ідентичності, який підпирає цей механізм.

За ERC-8004 агенти реєструються в on-chain та формують репутаційний скоринг на основі історії транзакцій. Це створює портативний сигнал довіри, що зберігається між взаємодіями. У теорії дизайн є надійним; однак бутстрепінг впровадження в масштабі залишається практичним вузьким місцем.

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

Одна структурна теза випливає напряму. Роздрібна e-commerce може зручно працювати на card rails, бо людські покупці залишаються в контурі. Натомість чиста агент-до-агент комерція, ймовірно, вимагатиме розрахунків у stablecoin, адже комісії карток стають неекономічними для дуже малих сум і високих частот.

Протоколи розрахунків: хто фактично рухає гроші

Якщо оркестрація вирішує “що і де” здійснювати транзакцію, то шар розрахунків визначає, чи насправді рухається вартість. Зараз тут змагаються п’ять основних протоколів, кожен налаштований під різні сценарії використання та економічні обмеження.

2.1 Delegated Payment Spec і SPT (Stripe)

Delegated Payment Spec від Stripe розширює card інфраструктуру, а не замінює її. Коли клієнт авторизує агента, Stripe забезпечує SPT, який агент зберігає. Під час транзакції агент представляє цей токен, обмежений за часом і сумою, мерчанту.

Після цього розрахунки працюють через існуючий card stack Stripe. На бекенді Stripe підключається до Visa Intelligent Commerce та Mastercard Agent Pay, які видають агентні мережеві токени. Мерчанти бачать єдину поверхню інтеграції незалежно від того, яка саме карткова мережа знаходиться “під капотом”.

Ця модель добре підходить для стандартних роздрібних покупок і багатьох платежів high-value агент-до-агент, де chargeback’и та інші захисти споживачів залишаються бажаними. Однак вона погано пасує для сценаріїв високочастотних, мікроцінностей, таких як машинно-машинний streaming payment.

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

2.2 Visa Intelligent Commerce та Mastercard агентні токени

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

Дозволені мерчанти також вказуються в метаданих токена, що дає змогу реалізувати точні контролі того, де агенти можуть платити. Сам процес розрахунків залишається в legacy card rails, що зберігає звичні шляхи інтеграції та уникає повністю нової інфраструктури.

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

Інфраструктура виглядає здатною, але fee floor є структурним обмеженням. Жодна з мереж не може ефективно підтримувати платежі нижче $1 на щільності, яку може вимагати майбутня агентська комерція. Крім того, регуляторні та комплаєнс-шари ще більше обмежують експерименти на дуже малих сумарних рівнях.

2.3 x402 (Coinbase)

x402, на відміну від цього, починається з HTTP, а не з карт. Він спирається на status code 402 “Payment Required”, який існує в специфікації HTTP з 1997 року, але майже не використовувався. Коли агент запитує платний ресурс, сервер відповідає 402, який містить параметри платежу.

Агент підписує авторизацію, а Facilitator завершує атомарні on-chain розрахунки в USDC або в інших підтримуваних токенах, зазвичай приблизно за дві секунди. Немає налаштування акаунта, немає розподілу API-ключів і немає примусового KYC на рівні протоколу. Довіреності знаходяться в x402 Foundation, заснованому Coinbase та Cloudflare.

До кінця 2025 року x402 обробив понад 100 млн транзакцій на Base, Solana та Polygon. Однак аналітики Artemis у лютому 2026 року оцінили, що значна частина цього обсягу відображає самопослуговування та тестування інфраструктури, а не справжню комерцію.

Щорічний обсяг платежів протоколу становить близько $600 млн, але концентрація та якість обсягу є суттєвими проблемами. Втім, x402 не має структурного fee floor; його явно спроєктували для micropayments. Ключова прогалина — глибина впровадження та щільність реальної комерції, а не технічний дизайн.

2.4 Nanopayments (Circle)

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

Періодичні батчовані розрахунки до blockchain розподіляють витрати gas між багатьма платежами, роблячи трансфери розміром аж до $0.000001 економічно життєздатними. Фактично gas оплачується один раз під час депозиту, а не за кожен платіж — критично важлива оптимізація для сценаріїв із ультрависокою частотою.

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

2.5 MPP Machine Payments Protocol (Tempo і Stripe)

MPP, співавтором якого є Tempo та Stripe, є найбільш амбітним із п’яти дизайнів розрахунків. Він використовує HTTP 402 як тригер і дозволяє мерчантам та агентам обирати серед кількох рейлів розрахунків у межах єдиного фреймворку.

Розробникам більше не потрібно жорстко вбудовувати ані stablecoin, ані fiat інфраструктуру під час розробки. Натомість агент може вирішити під час runtime, який рейл використовувати, виходячи з потреб транзакції. Доступні опції включають stablecoin settlement від Tempo, платежі на основі Stripe SPT, токени карткових мереж і платежі Bitcoin Lightning з підтримкою Lightspark.

Ключове: MPP додає примітив “session”, подібний до OAuth. Агент авторизує один раз і попередньо фінансує акаунт, а далі отримує real-time автоматизовані розрахунки для подальших взаємодій без on-chain транзакції на кожен платіж.

Базову специфікацію подали в IETF як референсну реалізацію HTTP 402. Під час запуску 18 березня 2026 року mainnet Payment Directory вже інтегрував понад 100 сервісів. Проте патерни впровадження все ще перебувають на ранніх стадіях.

Подвійна роль Stripe є стратегічно важливою. Вона співавторила протокол і також виступає одним із платіжних варіантів усередині нього, захоплюючи цінність незалежно від того, чи розробники оберуть MPP насамперед заради гнучкості, чи саме заради карткових можливостей.

Реальність ринку: протоколи попереду впровадження

3.1 Де ринок зараз

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

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

Центральне вузьке місце — фрагментація на рівні оркестрації. Мерчанти стикаються з кількома незалежними стандартами, кожен з яких має різні SDK, потоки автентифікації та правила комплаєнсу. Водночас це підвищує витрати на інтеграцію і відлякує експерименти.

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

Ця ж логіка розгортається і регіонально. Китай, Південно-Східна Азія, Корея та Японія кожна розвивають закриті екосистеми з опорою на super-app або домінуючі платформи. Найімовірніший результат — набір паралельних регіональних закритих систем, а не єдиний відкритий глобальний стандарт.

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

3.2 Де лежать найближчі можливості

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

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

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

Це визначає чітку вимогу до продукту: multi-rail wallet для агентів. Card rails на кшталт SPT, Visa agentic tokens і Mastercard agentic tokens і надалі підтримуватимуть традиційну мерчантську комерцію. Stablecoin rails на кшталт x402 і MPP session payments будуть якоритися на on-chain API та агент-до-агент трансферах.

Обидві категорії вже “вживу” і в найближчій перспективі не зійдуться на єдиному рейлі. Витрати за гнучкість лежать на боці агента, а не мерчанта. Мерчанти обирають, які рейли вони підтримують — це відносно стабільне, контрольоване рішення.

Далі ентерпрайзи забезпечують своїх агентів stablecoins і делегованими картами. Агент платить, використовуючи той рейл, який приймає контрагент. Гаманець, який безшовно опрацьовує обидва варіанти в межах однієї інтеграції, стає enabling-layer для агентів загального призначення, що працюють у різноманітних екосистемах.

Цінність такої інтеграції нарощується з кожною транзакцією та кожною новою платформою, створюючи “глибину інфраструктури”, яку важко витіснити після закріплення. Крім того, це позиціонує провайдера гаманця як нейтральний clearing-layer між фрагментованими середовищами оркестрації.

Agent-до-агент комерція: недорозвинена можливість

Друга можливість знаходиться на рівні застосунків у агент-до-агент комерції. Сьогодні більшість активності A2A лишається обмеженою кріпто-native сценаріями: агенти запитують on-chain дані, взаємодіють із DeFi-протоколами та виконують blockchain транзакції.

Ринок ще не розширився до широких сервісів у реальному світі. Втім, з точки зору протоколів, агенти вже можуть замовляти задачі на кшталт аналізу даних, генерації контенту, юридичних досліджень або рев’ю коду, сплачуючи за кожен виклик окремо.

Брак — у девелоперському екосистемі сервісів. Розробники сервісів ще не пакують пропозиції як agent-payable APIs із точковим, використання-орієнтованим ціноутворенням. Це справжня прогалина, і на сьогодні це одна з найменш оскаржуваних зон у стеку.

Цей простір обмежений проблемою cold-start. Системи ідентичності на кшталт ERC-8004 потребують значної щільності транзакцій, щоб сформувати достовірні репутаційні скорингові оцінки. Агенти без історії не мають репутаційної ваги, що зменшує кількість контрагентів, готових здійснювати з ними транзакції.

Microsoft прогнозує близько 1.3 млрд активних AI-агентів до 2028 року. Наявна сьогодні база — на порядки менша. Прогалина не закриється автоматично; саме це тримає конкуренцію в найближчій перспективі низькою та робить раннє зайняття позицій привабливим.

Наслідки виходять за межі платежів у бізнес-моделі. Домінуючі моделі інтернету — реклама та підписки — припускають наявність людських покупців. Агенти не переконуються рекламою і їм не потрібні пакети місячного доступу; вони платять за результат конкретних викликів.

У цьому контексті платежі http 402 створюють інший економічний примітив. Провайдери продають результати, а не доступ, стягують високі суми з “важких” користувачів пропорційно фактичному споживанню і припиняють субсидувати легких користувачів або over-provisioning для рідкісних пікових навантажень.

Чи розшириться економіка A2A за межі кріпто, і чи стане HTTP 402 загальним рівнем ціноутворення для софту — по суті одне й те саме питання. Обидва залежать від того, чи агенти стануть звичними економічними акторами, що в масштабі проводять транзакції через багаті, per-call каталоги сервісів.

Висновок: двошаровий стек і відсутні примітиви

Надалі агентна комерція розвиватиметься за двома окремими треками. Агенти, орієнтовані на споживача, які купують товари для людей, здебільшого покладатимуться на card rails, просуваючись у темпі фреймворків авторизації ентерпрайзів і довіри користувачів до нових “платіжних поверхонь”.

Паралельно, протокольний стек агентної комерції для платежів software-to-software вже технічно життєздатний на stablecoin rails. Тепер він чекає на розгортання агентів і сервісів, яким потрібні високочастотні, програмні розрахунки в масштабі.

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

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

Тригер для комерційного масштабу — не “кращі протоколи”. Це момент, коли ентерпрайзи делегують агентам повноваження на витрати з аудитними слідами, бюджетними контролями та чіткою відповідальністю за помилково спрямовані покупки. Коли цей поріг буде перетнуто, критичними стануть дві позиції інфраструктури.

По-перше, multi-rail агентний гаманець, який підтримує і stablecoin, і карткові платежі в межах однієї інтеграції. По-друге, доступний per-call сервісний каталог, який дозволяє розробникам без кріпто-фону експонувати APIs для покупців-агентів. Обидві можливості відкриті вже сьогодні, і обидві стануть необхідними, коли агентів для витрат почнуть працювати в масштабі.