Агентні платежі: як делегувати оплату й обмежити повноваження

Покупець просить агента замовити звичні витратні матеріали, але за час пошуку змінюються ціна й доставка. Хто дозволив списати нову суму? Агентні платежі мають починатися з відповіді на це запитання, а не з кнопки оплати в чаті. Для інтернет-магазину ключове рішення — визначити межі делегування: конкретний продавець, валюта, сума, строк і умови повторного підтвердження.

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

Де закінчується допомога з покупкою і починається делегування

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

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

Загальні можливості діалогу й роботи з каталогом — окрема тема ШІ-асистента для інтернет-магазину. У платіжному проєкті предметом приймання стає не якість відповіді бота, а відповідність кожної фінансової дії погодженим параметрам.

Порівнюйте режими за контролем, а не за рівнем автономності

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

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

Що обмежує платіжний токен — і чого він не доводить

Конкретний приклад реалізації — Shared Payment Tokens, або SPT, у Stripe. За офіційною документацією SPT, агент надає визначеному продавцю обмежений доступ до платіжного методу покупця. Для нього задаються валюта, максимальна сума й строк використання. Це приклад механізму, а не універсальна вимога до всіх агентних платежів.

Строк токена не дорівнює строку дозволу

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

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

Не називайте всі токени одноразовими

Stripe описує неперіодичні й періодичні SPT: напис «токен» не означає рівно одне списання. Для разової покупки перевірте обраний режим і відсутність непередбачених повторних платежів. Параметри фіксуйте за документацією фактичної версії інтеграції.

Станом на 11 листопада 2026 року Stripe перелічує підтримувані країни для SPT; України в цьому переліку немає. Це не висновок про всі інші платіжні продукти чи всіх покупців з українськими картками. Доступність перевіряють для конкретних учасників, акаунтів, методів і ринків. Наявність звичайного еквайрингу не підтверджує доступу до агентного продукту.

Умовний приклад: ціна змінилася після погодження

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

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

Якщо сума залишилася в межах, але товар замінено іншим, перевірка також має спрацювати. Ліміт грошей не замінює перевірку складу покупки. Для цього сервер зіставляє версію кошика, продавця й дозволені заміни; модель лише пропонує дію, а не переписує правила погодження.

Окремий виняток — додаткове підтвердження покупця. У Stripe SPT може перейти в стан requires_action, зокрема коли потрібна автентифікація 3D Secure. Сценарій має вміти призупинитися, передати людині потрібний крок і коректно відновитися. Обіцянка «платежів без участі покупця за будь-яких умов» тут некоректна.

Побудуйте контрольований шлях від дозволу до замовлення

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

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

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

Магазин окремо керує резервом товару. Якщо оплата підтвердилася після завершення резерву, не можна автоматично обіцяти відвантаження. Потрібна повторна перевірка й визначений маршрут винятку. Про цей суміжний процес — матеріал про підтвердження доступних залишків ATP.

Як перевірити рішення до запуску

Почніть у тестовому середовищі провайдера з матриці дозволених і заборонених дій. Для кожного тесту потрібні очікувані стани замовлення й платежу та відповідальний за виняток.

1. Підтвердьте доступність продукту для потрібних учасників і методів оплати. Зафіксуйте версію інтеграції та межі тестового доступу.
2. Відтворіть правильну покупку, перевищення суми, іншу валюту, іншого продавця, заміну товару й завершення строку дозволу. Недозволені зміни мають зупиняти дію.
3. Перевірте прострочений і відкликаний токен окремо від відкликаного бізнес-дозволу. Не покладайтеся лише на напис у діалозі.
4. Змоделюйте втрату відповіді після запиту та повторне доставлення повідомлення. Переконайтеся, що повтор не створює нове замовлення чи зайву платіжну спробу.
5. Пройдіть додаткову автентифікацію, відмову, скасування й повернення. Звірте стани в магазині та в провайдера, включно із запізнілими подіями.
6. Перевірте вимкнення агентного каналу, стандартний checkout і роботу підтримки. Команда повинна бачити причину зупинки та мати інструкцію для покупця.

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

Ризики, строки й вартість пілота

Головні ризики — хибно витлумачений дозвіл, підміна умов, повторне виконання, витік доступу та розбіжність оплати й замовлення. Токени, серверні перевірки й журнали зменшують ризики, але не усувають їх. Зовнішній опис товару чи повідомлення агента не можуть змінювати платіжну політику.

Строки визначає готовність ланцюжка

Плануйте етапи: перевірка доступності, опис дозволів, прототип, інтеграція зі станами замовлення, тестування винятків і обмежений запуск. Строки залежать від доступу до продукту, готовності API, резервування, повернень і підтримки. Давайте календарну оцінку після цих перевірок.

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

Починайте з меж повноважень, які можна перевірити, і залишайте звичайний checkout робочою альтернативою. Якщо магазин ще не узгодив стани оплати й замовлення, спершу виправте цей процес. Для предметного наступного кроку передайте GL.ua (Глянець) схему чинної оплати та один сценарій делегування в межах розробки й інтеграцій інтернет-магазину: це основа для оцінки архітектури пілота, його обмежень і складу робіт.