AP2 і x402: як ШІ-агенти здійснюють авторизацію платежів та автоматизовані розрахунки

AP2 (протокол платежів для агентів) і x402 — це два платіжні протоколи, розроблені для комерції за участю ШІ-агентів. Вони забезпечують інфраструктуру для автономних транзакцій відповідно з погляду авторизації платежів і програмованих розрахунків. AP2 зосереджується на підтвердженні того, що покупку ШІ-агента схвалив користувач, тоді як x402 використовує стандартизовані платіжні взаємодії HTTP, щоб програмні системи могли за потреби купувати API, дані та інші цифрові послуги.

У міру розвитку комерції між агентами ШІ-агенти еволюціонують від інструментів пошуку інформації до автоматизованих систем, здатних здійснювати покупки, керувати підписками та викликати сервіси. Коли Агент починає використовувати кошти від імені користувача або компанії, традиційні платіжні процеси, що ґрунтуються на ручних натисканнях і підтвердженнях, стикаються з новими викликами: як система може визначити, чи має Агент дозвіл на здійснення платежу? Як обмежити суму платежу? Як різні системи можуть автоматично завершувати розрахунки?

AP2 і x402 пропонують два взаємодоповнювальні підходи. У цій статті розглянуто ключові механізми, технічні відмінності та робочі процеси взаємодії двох протоколів, проаналізовано роль стейблкоїнів у платежах ШІ-агентів, а також ризики для безпеки й відповідності вимогам, які можуть супроводжувати автоматизовані транзакції.

Основні висновки

• AP2 (протокол платежів для агентів) — це відкритий протокол для авторизації платежів ШІ-агентів. Він зосереджується на тому, чи може Агент здійснювати платежі від імені користувача та як перевірити, що транзакція відповідає намірам користувача.
• x402 — це протокол програмованих платежів на основі коду стану HTTP 402 Payment Required. Він дає змогу ШІ-агентам автоматично оплачувати API та цифрові послуги відповідно до платіжних вимог, що повертаються сервером.
• AP2 і x402 охоплюють різні рівні: AP2 зосереджується на перевірці авторизації та відповідальності, тоді як x402 — на платіжних запитах, перевірці платіжних даних і розрахунках. Ці два протоколи можна використовувати разом.
• Стейблкоїни надають ШІ-агентам програмовану форму цифрових платежів. Вони підходять для API з оплатою за використання, сервісів даних і транзакцій між машинами, але не є необхідними для кожного сценарію платежів Агентів.
• Автоматичні платежі ШІ-агентів усе ще потребують лімітів бюджету, контролю дозволів гаманця, перевірки контрагентів і обробки нестандартних транзакцій. Автоматизоване виконання не слід вважати необмеженим дозволом на використання коштів.

Що таке AP2 і x402? Чому ШІ-агентам потрібні спеціальні платіжні протоколи?

AP2 і x402 підтримують автоматизовану комерцію ШІ-агентів, але розв’язують різні завдання. AP2 було запущено у вересні 2025 року компанією Google спільно з учасниками платіжної та технологічної галузей. Його мета — створити міжплатформну, незалежну від способу оплати структуру для авторизації платежів Агентів. Протокол зосереджується на підтвердженні того, що користувач дозволив Агенту здійснити конкретну покупку, а також надає платіжним установам можливість перевірити цей дозвіл.

Водночас x402 просуває Coinbase, і він базується на коді стану 402 Payment Required у протоколі HTTP. Він дає вебсайтам, API та іншим цифровим сервісам змогу безпосередньо надсилати клієнтам вимоги щодо оплати. Після отримання платіжної інформації ШІ-Агент може використати контрольований гаманець для створення платіжних даних і отримати доступ до відповідного ресурсу після завершення перевірки та розрахунків.

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

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

AP2 і x402 забезпечують технічну підтримку відповідно для цих двох етапів, проте не кожен платіж ШІ-агента потребує обох протоколів.

Як AP2 перевіряє авторизацію платежів ШІ-агентів?

Основою AP2 є Mandate — криптографічно перевірюваний обліковий документ авторизації. Він фіксує дії, які користувач дозволив виконувати Агенту, і відповідні обмеження, даючи змогу продавцям і постачальникам платіжних послуг визначати, чи відповідає транзакція намірам користувача.

Відповідно до технічної специфікації AP2 v0.2, протокол визначає два основні типи облікових даних: Checkout Mandate і Payment Mandate. Checkout Mandate підтверджує, що Агенту дозволено придбати конкретний товар або послугу. Payment Mandate підтверджує, що Агент може ініціювати платіж за відповідне замовлення. Вони пов’язані через інформацію про замовлення, що зменшує ризик використання платіжних даних для іншої транзакції.

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

AP2 також розрізняє режими транзакцій Human Present і Human Not Present. У першому користувач може підтвердити конкретне замовлення під час оформлення покупки. У другому Агент може виконати транзакцію в межах заздалегідь авторизованих обмежень. У будь-якому режимі ключові перевірки авторизації мають виконуватися через детерміновані процеси, а не лише на основі судження великої мовної моделі.

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

Як x402 забезпечує автоматизовані платежі через HTTP 402?

Основна ідея x402 полягає у вбудовуванні платіжного процесу безпосередньо в HTTP-запити. Традиційні API-сервіси зазвичай вимагають від користувачів зареєструвати акаунт, прив’язати спосіб оплати або заздалегідь придбати кредити для підписки. x402 дає серверу змогу повертати стандартизовані вимоги щодо оплати після отримання запиту, після чого клієнт завершує платіж і повторно отримує ресурс.

Згідно з офіційним протоколом x402, типовий процес починається з надсилання клієнтом HTTP-запиту до сервера ресурсів. Якщо ресурс потребує оплати, сервер повертає 402 Payment Required і надає ціну, підтримувані мережі, платіжні активи та іншу необхідну інформацію. Клієнт обирає підтримуваний спосіб оплати, створює платіжні дані та надсилає їх через HTTP-запит.

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

Зверніть увагу, що різні версії x402 використовують різні назви HTTP-заголовків і структури даних. Наприклад, у ранніх версіях використовувався X-PAYMENT, тоді як новіші специфікації застосовують поля на кшталт PAYMENT-SIGNATURE. Тому розробникам потрібно реалізовувати саме ту версію, яку вони використовують, і не слід безпосередньо змішувати інтерфейси різних версій.

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

У чому відмінності між AP2 і x402?

Найфундаментальніша відмінність між AP2 і x402 полягає в їхніх функціях. AP2 насамперед відповідає на запитання: «Чи авторизовано цю транзакцію?» x402 насамперед відповідає на запитання: «Як завершити платіж програмним способом відповідно до вимог сервера?»

AP2 не залежить від конкретної платіжної валюти або мережі розрахунків. Наприклад, ШІ-Агент може використати AP2, щоб підтвердити авторизацію покупки, а потім завершити транзакцію банківською карткою чи іншим підтримуваним способом оплати. x402 більше зосереджується на технічному виконанні платежів за цифрові послуги й особливо підходить для поєднання платежів у стейблкоїнах із API-запитами.

Ці два протоколи також частково перетинаються за функціями. x402 може перевіряти платіжні дані, надіслані клієнтом, але така перевірка передусім стосується того, чи відповідає платіж вимогам сервера. Вона не є автоматично еквівалентною повній авторизації комерційного наміру користувача. AP2 може фіксувати ширшу інформацію про наміри користувача, товар і умови оплати.

Тому AP2 не слід просто розглядати як вдосконалену версію x402, а x402 не слід вважати заміною всіх механізмів авторизації платежів. Їх можна розгортати незалежно або використовувати разом.

Як AP2 і x402 можуть разом завершити транзакцію між агентами?

Взаємодію AP2 і x402 можна пояснити на прикладі платного сервісу аналізу даних.

Припустімо, що користувач дозволяє дослідницькому Агенту купувати ринкові дані на суму не більш як 20 $ на день. Агент знаходить API іншого постачальника послуг, який відповідає його потребам, і отримує ціну 0,10 $ за виклик. Система має спершу підтвердити, що сервіс входить до авторизованого обсягу покупки, а потім перевірити, що сукупні витрати не перевищують бюджет.

На етапі авторизації AP2 може надати перевірюваний Mandate, який підтверджує, що Агент має відповідні дозволи на покупку та оплату. На етапі платежу x402 може передати Агенту платіжні вимоги сервера та завершити переказ коштів через контрольований гаманець, платіжні дані й сервіс розрахунків. Після успішної оплати сервер повертає дані, а Агент продовжує дослідницьке завдання.

Ця комбінація не обмежується концептуальною моделлю. Пов’язані з Google проєкти з відкритим кодом випустили A2A x402 Payments Extension, яке дає Агентам змогу купувати послуги, що надаються іншими Агентами, через ончейн-платежі. Його специфікація v0.2 також визначає незалежні та вбудовані платіжні потоки. Останні можуть інтегрувати платіжні структури у протоколи вищого рівня, такі як AP2.

Однак описаний вище процес є прикладом, що пояснює можливість поєднання протоколів. Це не означає, що всі реалізації AP2 або x402 уже підтримують абсолютно однакові функції. Фактичним системам усе ще потрібно обробляти такі деталі, як перевірка облікових даних авторизації, дозволи гаманця, невдалі платежі, дублікати запитів і квитанції про транзакції.

Чому стейблкоїни підходять для автоматизованих платежів ШІ-агентів?

Стейблкоїни є одним із провідних варіантів для програмованих платежів ШІ-агентів. Порівняно з криптоактивами з вищою волатильністю цін, стейблкоїни, прив’язані до USD, зазвичай номіновані відносно долара США, що допомагає постачальникам послуг установлювати відносно стабільні ціни на виклики API, доступ до даних і обчислювальні ресурси.

Наприклад, ШІ-Агенту може знадобитися щодня сотні разів викликати платний інтерфейс даних. Якщо кожен виклик потребує ручного підтвердження оплати банківською карткою, автоматизувати процес транзакції буде складно. За допомогою x402 і підтримуваної мережі стейблкоїнів платіжні вимоги, підписи та операції розрахунків можна інтегрувати в програмовані запити, даючи Агенту змогу автоматично оплачувати послуги в межах свого бюджету.

Стейблкоїни також є цифровими за своєю природою та програмованими. Розробники можуть поєднувати платіжну логіку з дозволами API, лімітами використання й обмеженнями гаманця, даючи програмним системам змогу переказувати кошти між різними платформами. Представляючи x402, Coinbase назвала автоматизовані платежі між API, програмними сервісами та ШІ-агентами однією з ключових сфер застосування.

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

З якими ризиками безпеки та технічними обмеженнями стикаються AP2 і x402?

Перший ризик — зловживання авторизацією. ШІ-Агент може неправильно зрозуміти запит користувача або зазнати впливу шкідливих вебсторінок, відповідей інструментів чи ін’єкцій промптів, що призведе до ініціювання покупок поза межами фактичних намірів користувача. Якщо система покладається лише на модель для визначення обґрунтованості платежу та не має незалежних перевірок бюджету й дозволів, можуть виникнути ненавмисні витрати.

AP2 зменшує цей ризик завдяки Mandate і детермінованим механізмам перевірки, але його безпека все одно залежить від того, як видаються, зберігаються та перевіряються облікові дані авторизації. Системи також мають уникати надання надто широких дозволів і запроваджувати додаткове підтвердження для високоризикових транзакцій.

Другий ризик пов’язаний із виконанням платежу. x402 охоплює клієнта, сервер, гаманець і сервіс розрахунків, а помилка реалізації на будь-якому етапі може вплинути на результат транзакції. Наприклад, повторне надсилання запитів може призвести до дубльованих платежів, успішна оплата з подальшим ненаданням послуги може спричинити спір, а збій Facilitator може затримати розрахунок. Тому розробникам потрібно передбачити ідемпотентну обробку, повторні спроби невдалих платежів, звірку квитанцій і процедури повернення коштів у разі виняткових ситуацій.

Третій ризик стосується перевірки контрагентів і особи. Навіть якщо Агент правильно надсилає платіжні дані, одержувач не обов’язково є надійним. Шкідливий сервер може неправдиво вказувати ціни, надавати недійсну послугу або фальсифікувати інформацію про товар. A2A і x402 можуть покращити комунікацію між Агентами та платіжні потоки, але вони не можуть автоматично гарантувати достовірність особи продавця або відповідність якості послуги очікуванням.

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

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

Висновок

AP2 і x402 забезпечують інфраструктуру для комерції ШІ-агентів відповідно з погляду авторизації платежів і програмованих розрахунків. Завдяки Mandate та перевірюваним обліковим даним AP2 допомагає продавцям і постачальникам платіжних послуг підтвердити, чи відповідає транзакція Агента авторизації користувача. Завдяки HTTP 402 і процесам перевірки платежів x402 дає ШІ-агентам змогу автоматично купувати API, дані та інші цифрові послуги.

Ці два протоколи не замінюють один одного. AP2 може працювати з різними способами оплати, тоді як x402 може слугувати механізмом виконання для ончейн-платежів. У міру розвитку таких технологій, як A2A x402 Payments Extension, перевірка авторизації та автоматизовані розрахунки формують тісніші взаємозв’язки.

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

Поширені запитання

У чому основна відмінність між AP2 і x402?

AP2 переважно перевіряє авторизацію покупки та платежу ШІ-агента, тоді як x402 переважно забезпечує програмовані платежі через HTTP-запити. Перший зосереджується на авторизації, а другий — на виконанні платежу.

Чи є AP2 протоколом блокчейн-платежів?

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

Чи може x402 використовувати лише USDC?

Ні. Платіжні можливості x402 залежать від конкретної платіжної схеми, мережі та підтримки, яку надає сервер. USDC є поширеним платіжним активом у реалізаціях, але його не слід вважати єдиним активом, який підтримує протокол.

Чи можна використовувати AP2 і x402 разом?

Так. AP2 можна використовувати для перевірки авторизації транзакції Агента, тоді як x402 можна використовувати для виконання відповідного програмованого ончейн-платежу. A2A x402 Extension уже досліджувало способи поєднання x402 із протоколами вищого рівня, такими як AP2.

Чи потрібне ШІ-агенту ручне підтвердження для здійснення платежу через x402?

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

Чи гарантується надання послуги після успішного платежу через x402?

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