AI-агент оформляет заказ: готов ли интернет-магазин отдать ему каталог, остатки и оплату

Покупатель пишет: «Найди мне чёрную куртку без натурального меха, до 20 тысяч рублей, с доставкой к субботе. Если итоговая цена выше 18 тысяч — сначала спроси». Дальше он хочет увидеть готовый заказ, а не восемь вкладок, три почти одинаковые модели и промокод, который оказался недействителен уже перед оплатой.

Для AI-агента такой запрос звучит как маршрут: понять требования, найти подходящий вариант, проверить остаток, посчитать доставку, получить разрешение на списание и оформить покупку. Для интернет-магазина это проверка всей системы: данные о товаре, остатке, цене, доставке и оплате должны совпадать в каталоге, ERP и складском контуре.

Когда покупатель передаёт часть заказа AI-агенту, интернет-магазину приходится пересматривать не только интерфейс, но и саму архитектуру взаимодействия с клиентом. Агенту нужны актуальные данные, понятные правила и безопасный способ выполнять действия от имени покупателя. Поэтому задача начинается не с кнопки «Подключить AI», а с проверки того, готовы ли каталог, остатки, цены, доставка и оплата работать как единая система.

Покупатель уходит из интерфейса. Магазин остаётся продавцом

Первые рабочие стандарты уже показывают, как будет устроен такой заказ. OpenAI и Stripe опубликовали Agentic Commerce Protocol: агент ведёт пользователя через выбор и подтверждение, а магазин принимает или отклоняет заказ, проводит платёж через свою систему и отвечает за доставку, возврат и поддержку.

UCP (Universal Commerce Protocol) создаётся как отраслевой стандарт. Среди соразработчиков — Google, Shopify, Amazon, Microsoft, Meta, Salesforce, Stripe, Walmart, Target и Etsy; в туризме и доставке участвуют Booking.com, Expedia, Marriott, DoorDash и Uber Eats. UCP охватывает поиск, корзину, связь с аккаунтом, оформление и управление заказом. Такой состав показывает, что агентный канал уже развивается на уровне рыночной инфраструктуры.

Для e-commerce это шесть вопросов к бэкенду: что именно продаём, где товар лежит, сколько он стоит сейчас, как его доставить, кто разрешил платёж и что произошло после него. В финале те же вопросы превратятся в шесть контрактов, по которым можно ограничить пилот.

Комиссия — только одна строка в экономике агентного канала

Сейчас для Shopify-магазинов продажи через ChatGPT проходят в checkout продавца, а справка Shopify указывает: дополнительной комиссии нет. В марте OpenAI вернула оформление на сайт магазина. Прежняя модель показывает, почему комиссию всё равно стоит закладывать в расчёт: тариф Instant Checkout начал действовать 2026-01-26 и составлял 4% с каждой завершённой покупки. Вместе с эквайрингом Shopify Payments общая ставка могла доходить до 9,2%; Google AI Mode, Gemini и Microsoft Copilot тогда проводили оформление без дополнительного сбора, сообщали PYMNTS и RetailBrew. Коммерческая схема изменилась примерно за два месяца, поэтому рядом со ставкой фиксируют дату, платформу и платёжный сценарий.

Конверсию в оплату считают как долю завершённых покупок среди заказов, которые агент передал в checkout. Если платформа показывает только оплаченные заказы, магазин не увидит отказы и не поймёт, где теряются покупатели. До пилота нужно согласовать знаменатель метрики и события, доступные в аналитике.

Маржу считают после комиссии канала, эквайринга, возвратов и поддержки. Заказов может стать больше, а прибыли — меньше, если вместе с ними растут возвраты и обращения. Для сравнения берут одинаковые категории, регионы и способы доставки, чтобы состав трафика не исказил вывод.

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

Доля покупателей, с которыми магазин сможет продолжить коммуникацию, зависит от прав на данные. UCP позволяет передавать атрибуцию, но не задаёт модель и окно учёта. Протокол также не гарантирует магазину историю поиска, отклонённые варианты и полный диалог. Право использовать контактные данные в CRM и программе лояльности нужно закрепить в договоре с платформой до пилота.

Комиссия и эти четыре показателя дают пять строк экономики канала. Технически успешный заказ подтверждает работу интеграции; окупаемость покажут все пять строк вместе.

Атрибуты становятся новой витриной для AI-агента

Человек может открыть карточку «Куртка North» и сам заметить, что графитовый цвет почти чёрный, размер M закончился, зато L доступен в соседнем магазине. Агенту нужны отдельные сущности: товар, вариант, цвет, размер, состав, цена, идентификатор склада и способы получения.

В спецификации каталога UCP товар отделён от варианта, который действительно можно купить. Вариант имеет свой идентификатор, цену и доступность; этот же идентификатор передаётся в сессию оформления заказа. Такая связка защищает от ситуации, когда агент рекомендует одну куртку, а в корзину отправляет её тёзку другого размера.

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

Изображения, отзывы и редакционные материалы продолжают формировать спрос и доверие. В момент выбора внутри агентного канала видимость и конверсия зависят от полноты и точности товарных данных. Если у конкурента структурированы атрибуты, актуальны остатки и формализованы правила возврата, его товар проще сравнить и безопаснее добавить в заказ. Языковая модель интерпретирует запрос; финальный выбор привязывают к правилам и стабильным ID.

«В наличии» живёт до первого запроса на доставку

Остаток редко равен одному числу. Есть физическое количество на складе, доступный остаток с учётом резервов, витринные экземпляры, возвраты на проверке и товары в корзинах других покупателей. Ещё один слой добавляет логистика: позиция лежит в Казани, но не успевает к субботе в Санкт-Петербург.

Поэтому агенту мало ответа available: true. Ему нужны доступность конкретного варианта, адрес или зона доставки, способ получения, срок и момент, до которого расчёт остаётся действительным. Каталог помогает найти кандидата. Сессия оформления заказа повторно проверяет условия и возвращает состояние, которому магазин готов доверять в транзакции.

В UCP это разделено прямо: ответ каталога отражает текущие условия, но не считается обязательством продать; авторитетным становится ответ сессии оформления заказа. Для архитектуры это означает два правила. Остатки нужно получать из операционного контура, а перед оплатой — перепроверять. Если товар резервируется, у резерва должны быть срок жизни, причина снятия и связь с этой сессией.

Иначе два агента одновременно купят последний размер M. Куртка одна, а система успеет подтвердить её двум покупателям.

Цена меняется быстрее, чем агент дочитывает правила акции

В каталоге агент увидел 17 990 рублей. Затем покупатель назвал адрес, выбрал доставку, применил промокод и вошёл в программу лояльности. Итог зависит от региона, способа получения, налогов, персональной скидки, состава корзины и времени действия акции.

Магазину нужен единый сервис расчёта, который возвращает полную цену по строкам: товар, скидка, доставка, налог и итог. Ответ должен содержать валюту и целые значения в минимальных денежных единицах, чтобы 17 990 рублей не превратились в 17 990 копеек из-за творческого прочтения поля amount.

Сервис оформления заказа обязан возвращать актуальное состояние после каждого изменения. Если сумма выросла выше разрешённых 18 тысяч, агент останавливается и просит подтверждение. Если товара больше нет, предлагает заменить вариант или отменить сессию. Новую сумму нельзя проводить без повторного подтверждения: иначе магазин получает спор с покупателем и банком.

Здесь особенно опасны параллельные калькуляторы. Сайт считает скидку в одном сервисе, мобильное приложение — в другом, маркетплейс получает ночную выгрузку, а агенту собирают четвёртую формулу. Новый канал быстро найдёт все расхождения. Лучше дать ему тот же расчёт, на котором уже живёт основное оформление заказа.

Платёж требует лимита и доказательства полномочий

Фраза «агент оплатит сам» звучит удобно до первого вопроса: кто разрешил ему потратить именно эту сумму именно в этом магазине? Платёжные схемы для агентной торговли заменяют реквизиты карты ограниченными полномочиями.

Например, Shared Payment Tokens от Stripe позволяют выпустить токен для конкретного продавца с ограничением по сумме и сроку действия. SPT находятся в статусе Public preview: механизм доступен для пилота без закрытого приглашения. Это ещё не GA, поэтому интеграция должна учитывать возможные изменения API. Магазин получает платёжный инструмент без исходных реквизитов карты. В сценарии с курткой разрешение может выглядеть так: один платёж этому продавцу, максимум 18 тысяч рублей, токен действует несколько минут.

Есть и задача распознавания самого агента. Протокол Trusted Agent Protocol от Visa описывает подписи, по которым магазин может проверить доверенного агента, связанное с покупателем поручение и платёжный контейнер. Без такой проверки продавец не отличит авторизованного агента от обычного автоматизированного трафика. Цепочку доверия настраивают до выдачи доступа к оплате.

У автономности должен быть стоп-кран. В правилах задают продавца, категорию, лимит, срок, допустимость замены и условия обязательного подтверждения. Дорогая покупка, первая транзакция, изменение цены или невозвратный товар возвращают управление человеку. Поручение и применённые правила связывают с заказом, чтобы лимит можно было доказать после транзакции.

Повторный запрос не должен заказать две куртки

Агенты будут повторять запросы. Сеть оборвалась после отправки платежа, ответ задержался, клиент не понял, создался ли заказ, и попробовал ещё раз. Для обычной страницы это неприятный крайний случай. Для программного клиента — штатное поведение.

Поэтому операции с последствиями должны поддерживать идемпотентность. Агент отправляет уникальный ключ, а магазин при повторе возвращает прежний результат вместо второго списания и нового заказа. В актуальной спецификации ACP такой ключ обязателен для создания, обновления, завершения и отмены сессии оформления заказа.

Сессию оформления заказа полезно хранить как конечный автомат с понятными состояниями: собирается, ждёт данных, готова к оплате, требует подтверждения, завершена, отменена. Переходы проверяет сервер. Агент не может перескочить от подбора товара к оплате, если адрес не прошёл валидацию или магазин ещё не подтвердил итог.

Логи тоже меняются. Для каждого действия нужны идентификаторы пользователя, агента, поручения, сессии оформления заказа, заказа и платежа. Тогда спор «я просил до 18 тысяч, откуда взялось 21 400?» разбирается по цепочке событий с точными состояниями и временем.

После оплаты агенту понадобятся статусы и возврат

После успешной оплаты заказ могут собирать частями, переносить между складами, отменять из-за брака, выдавать в пункте или отправлять курьером. Покупатель захочет спросить того же агента: «Где куртка?» Через неделю — «Как вернуть размер?»

Магазину нужен API жизненного цикла заказа: стабильный ID, состав, статусы, трекинг, документы, правила отмены и возврата. События лучше передавать асинхронно, а текущий статус всегда уметь получить повторным запросом. Агент может объяснить событие человеческим языком, но факт «передан в доставку» приходит из системы управления заказами, складом или самой службы доставки.

Поддержка тоже остаётся в контуре продавца. Агент должен знать, в каких случаях он может отменить заказ по поручению, когда запросить подтверждение и когда передать диалог оператору. Передача оператору вместе с контекстом становится частью контракта, который проверяют до запуска.

Шесть вопросов к бэкенду становятся шестью контрактами

Для пилота сначала проходим путь заказа и проверяем шесть границ системы. Выбор большой языковой модели остаётся следующим шагом. Агент работает через версионируемый API-слой с идентификаторами запросов и логами; каталог, WMS, расчёт цены, платёжный и заказной контуры остаются источниками данных:

1. Каталог. У товара и каждого покупаемого варианта есть стабильные ID, структурированные атрибуты, ограничения и ссылки на правила продажи.

2. Доступность. Система отвечает по варианту, складу, региону и способу получения, умеет перепроверить остаток и поставить ограниченный по времени резерв.

3. Цена. Один расчёт собирает товары, скидки, доставку и налоги; сервис оформления возвращает авторитетный итог после любого изменения.

4. Полномочия и оплата. Магазин распознаёт агента, проверяет согласие покупателя и принимает ограниченный платёжный токен без доступа к исходным реквизитам.

5. Заказ. Повторный запрос безопасен, сессия оформления и заказ проходят по формализованным состояниям, каждое действие оставляет след в аудите.

6. Дальнейший путь. Агент может получить статус, запустить разрешённую отмену или возврат и передать исключение человеку вместе с контекстом.

Пилот ограничивают одним продающим маршрутом

Стартовый сценарий — одна категория с понятными вариантами, один регион, один способ доставки и верхний лимит заказа. Пользователь подтверждает состав и итоговую сумму; нестандартная скидка, замена товара, частичная доставка или ошибка интеграции передают заказ оператору. Если остатки обновляются раз в сутки, маршрут заканчивается передачей корзины человеку. Автономную оплату подключают после резервов, правил, токенов и аудита.

На таком маршруте быстро видны реальные разрывы: каталог не различает товар и SKU, ERP отдаёт остаток без резервов, промокод рассчитывается только во фронтенде, платёж создаётся отдельно от заказа. После стабильного цикла добавляют по одному измерению — категорию, регион, способ получения, программу лояльности или более высокий лимит. Так команда понимает, какой контракт изменился и где искать ошибку.