Агентные платежи: как делегировать оплату и ограничить полномочия

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

Речь о сценарии, в котором программный агент инициирует оплату от имени пользователя в пределах предоставленных полномочий. Это не разрешение модели распоряжаться картой. Платёж выполняет соответствующая инфраструктура, а магазин проверяет заказ и результат операции. Ниже — как спроектировать такой процесс, отличить его от обычного 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 (Глянец) схему текущей оплаты и один сценарий делегирования в рамках разработки и интеграций интернет-магазина: это основа для оценки архитектуры пилота, его ограничений и состава работ.