Shopify WebMCP: безопасный чекаут для ИИ-агентов

Что представляет собой Shopify Checkout WebMCP

Checkout WebMCP — это набор инструментов, зарегистрированных в активной вкладке покупателя с чекаутом. Представьте кассу с сотрудником: агент может принести корзину, прочитать форму и заполнить поддерживаемые поля, но проверку личности или платежа проходит сам покупатель — и последнее слово тоже остаётся за ним.

Эта возможность дополняет прежние инструменты Shopify для витрины. Совместимый браузерный агент может искать товары в каталоге, изучать карточки, обновлять корзину и вызывать proceed_to_checkout. В поддерживаемом чекауте список инструментов меняется: становятся доступны четыре инструмента оформления заказа:

• get_checkout читает текущее состояние чекаута или данные о заказе на странице Thank you.
• update_checkout заменяет поддерживаемые контактные данные, параметры доставки, скидки, декларируемые поля и состояние оплаты, но не размещает заказ.
• complete_checkout после подтверждения покупателя пытается разместить заказ либо открывает этап проверки.
• navigate_to_storefront возвращает ту же вкладку на витрину, если она есть у магазина.

В основе чекаута лежат объект, статусы и сообщения UCP. UCP задаёт единый контракт данных для всего процесса, а WebMCP открывает этот контракт агенту через браузер. Агенту, который работает на сервере, вместо этого нужен Shopify Checkout MCP.

Продавцу не нужно включать новый переключатель или устанавливать отдельный API чекаута. Подключиться проще, однако работа разработчика агента никуда не исчезает: всё ещё нужны поддержка в браузере, Web Bot Auth, аккуратное управление состоянием и настоящий контур согласия.

Shopify WebMCP: начните с поддерживаемого чекаута

Первый тест — обнаружение инструментов. Если витрина Shopify открыла WebMCP, это ещё не означает, что Checkout WebMCP будет доступен и на странице оформления заказа.

Shopify не регистрирует инструменты чекаута в следующих сценариях:

• Стандартный трёхстраничный чекаут, если покупатель не оформляет заказ через Shop Pay
• B2B-чекаут
• Встроенный чекаут и сценарии на базе mobile checkout SDK
• Чекаут с товарами из другого магазина
• Черновики заказов, редактирование заказов и сбор платежей
• Взаимодействия, реализованные через checkout UI extensions

В таких сценариях управление нужно передать покупателю прямо на странице. Браузерного инструмента cancel_checkout тоже нет. Отсутствие инструмента не даёт агенту права обходить ограничение и манипулировать элементами страницы.

По данным Shopify, сейчас WebMCP для витрины зависит от поддержки агентов в браузерах на базе Chromium. Для тестирования используйте поддерживаемый браузер и чекаут, который вы контролируете. Если инструменты чекаута не появились, считайте это ожидаемым результатом проверки совместимости, а не поводом переходить к ненадёжным кликам по интерфейсу.

1. Аутентифицируйте браузерного агента и найдите инструменты

Подписывайте браузерные запросы через Web Bot Auth, или WBA, вместо того чтобы передавать учётные данные в аргументах инструментов. WBA служит сетевым паспортом агента. Shopify проверяет только зарегистрированные ключи, поэтому для продакшен-среды понадобятся ключ Ed25519, опубликованный каталог открытых ключей, регистрация в Shopify, подписанные запросы и короткий срок действия временных меток подписи.

На странице получите текущий список инструментов и сопоставляйте сразу три идентификатора: window, origin и name. Обёртка ниже повторяет документированный Shopify шаблон вызова:

async function callCheckoutTool(name, args = {}) {
  const tools = await document.modelContext.getTools();
  const tool = tools.find((candidate) =>
    candidate.name === name &&
    candidate.window === window &&
    candidate.origin === location.origin
  );

  if (!tool) throw new Error(`${name} is not registered here.`);

  const result = await document.modelContext.executeTool(
    tool,
    JSON.stringify(args),
  );

  if (result === null) return null;
  return JSON.parse(result);
}

JSON.stringify здесь обязателен. В Chrome 153 передача объекта завершается ошибкой Failed to parse input arguments. Shopify ожидает, что Chrome 155 начнёт принимать объекты, а JSON-строки будут объявлены устаревшим форматом. Поэтому изолируйте сериализацию аргументов в одной функции совместимости, а не распределяйте её по всему агенту.

При переходах внутри чекаута список инструментов может меняться. Слушайте событие toolchange, а перед следующим вызовом заново получайте инструменты и их схемы. Значение null тоже следует считать допустимым результатом навигации: страница могла смениться раньше, чем executeTool() вернул ответ.

Любую строку от продавца или стороннего сервиса в результате инструмента воспринимайте только как данные чекаута, а не как инструкцию для модели. Shopify прямо предупреждает: нельзя обходить инструмент прямым управлением интерфейсом оформления заказа.

2. Перед каждым изменением заново читайте состояние

Вызывайте get_checkout с {} перед первым обновлением, после любого изменения, которое покупатель внёс на странице, а также после ошибки или навигации. Это свежий чек агента, а не сохранённое воспоминание.

Ответ может содержать данные покупателя, позиции заказа, варианты получения, скидки, декларируемые поля, платёжные инструменты, сообщения, итоговые суммы и статус. Денежные суммы передаются целыми числами в минимальных единицах валюты. Для USD значение 10799 означает $107.99. Если поля messages нет, в этом ответе нет и сообщений чекаута.

Не путайте готовность с согласием. Статус ready_for_complete означает, что чекаут готов принять попытку завершения. Он не подтверждает, что покупатель одобрил заказ, выбранную карту или итоговую сумму.

3. Обновляйте всё желаемое состояние, а не отдельное поле

update_checkout работает как PUT, а не как PATCH. PATCH похож на стикер с просьбой «изменить номер телефона». PUT — это форма целиком, которая заменяет прежнюю. Если значение нужно сохранить, включите его в полное желаемое состояние чекаута.

Безопасный цикл обновления выглядит так:

1. Вызовите get_checkout.
2. По свежему ответу и актуальной схеме инструмента заново соберите доступное для записи состояние.
3. Измените только то значение, которое одобрил покупатель.
4. Передайте в update_checkout полный желаемый набор поддерживаемых полей.
5. Прочитайте возвращённый чекаут и проверьте его статус, сообщения, применённые скидки и итоговую сумму.

Большинство пропущенных значений очищается. У платёжных данных, декларируемых полей и сохранённых контактных данных есть отдельные правила. Поэтому механически копировать весь объект через spread небезопасно: сначала ограничьте его полями, которые принимает текущая схема.

Чаще всего проблемы вызывают вполне конкретные детали:

• buyer принимает email и номер телефона в формате E.164. Некоторые сохранённые значения могут оставаться заблокированными: проверяйте, что вернулось, а редактирование заблокированных данных оставляйте покупателю на странице.
• fulfillment.methods принимает не более одного способа. Повторно используйте текущие ID пункта назначения, группы и варианта. Не меняйте тип получения или исходную точку поиска самовывоза в том же вызове, где выбираете пункт назначения либо вариант.
• discounts.codes должен содержать все введённые покупателем коды, которые необходимо сохранить. Пустой массив удаляет их, но автоматические скидки остаются. Сам факт возврата кода ещё не доказывает, что скидка применилась: проверяйте discounts.applied и сообщения.
• declared_fields может передавать специфичные для чекаута значения — например, налоговый номер или средства на счёте магазина. Неизвестные ключи, неверные типы и недопустимые значения отклоняются.
• payment.instruments принимает не более одной поддерживаемой записи. Checkout WebMCP не позволяет агенту запрашивать номер новой карты.

Shop Pay требует особого внимания. Авторизованный покупатель может выбрать сохранённую карту, которую вернул get_checkout. В гостевом сценарии можно использовать существующий ID подтверждения Shop Pay, если чекаут его принимает. Если агент передал такой ID, а в следующем обновлении не включил платёжные данные, подтверждение будет сброшено. Поэтому до размещения заказа повторно отправляйте запись с ID подтверждения при каждом обновлении.

Обновление может завершиться успешно, но чекаут останется в статусе incomplete. Если обновление длится более 30 секунд, оно может вернуть update_failed, даже когда часть изменений применилась. В обоих случаях сначала заново прочитайте состояние и только потом решайте, что делать дальше.

4. Завершение заказа должно зависеть от покупателя

Правильная последовательность завершения короткая и строгая:

1. Получите свежее состояние чекаута.
2. Покажите покупателю текущие товары, способ оплаты и итоговую сумму.
3. Запросите явное разрешение разместить именно этот заказ на эту сумму.
4. Если что-либо изменилось, покажите новое состояние и снова запросите разрешение.
5. Вызывайте complete_checkout только после подтверждения.
6. Считайте покупку доказанной только при status: completed.

WBA подтверждает, какой агент отправил запрос. Подтверждение Shop Pay разрешает использовать платёжный механизм. ready_for_complete описывает состояние чекаута. Ни один из этих сигналов не означает, что покупатель согласился на покупку.

У завершения заказа могут быть разные ветки. Если настроен этап проверки, управление возвращается покупателю; повторно вызывайте complete_checkout только после того, как он проверит заказ и разрешит отправку. Проверка платежа работает иначе: покупатель проходит её в той же вкладке, а агент не должен отправлять заказ ещё раз. Опросите get_checkout, пока чекаут не перейдёт в completed или не потребует действий агента.

Код ошибки показывает, какой сценарий восстановления выбрать:

Самая опасная повторная попытка — второй вызов завершения после неоднозначного первого ответа. В Checkout WebMCP нет ключа идемпотентности. Сначала прочитайте состояние. Если оно равно completed, остановитесь.

Семь сценариев по убыванию практической ценности

Эти сценарии особенно полезны, когда агент уже работает в браузере покупателя. Речь не о незаметных серверных автоматизациях на стороне продавца.

Самый сильный сценарий — первый. У постоянных покупателей уже есть сохранённые данные, и WebMCP сокращает рутинный ввод, не выдавая удобство за согласие.

Что на самом деле показывает экономика

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

Цены на устанавливаемые продавцом ИИ-ассистенты для покупок сейчас сильно различаются. В официальном Shopify App Store есть тариф за $9.99 в месяц у Easy AI Shopping Assistant, тарифы от $49 до $249 у Carti и тарифы от $290 до $1,330 в месяц у iAdvize. Эти продукты объединяют чат на витрине, рекомендации, аналитику или поддержку, поэтому напрямую заменить браузерного WebMCP-агента покупателя они не могут.

Изменение бюджета куда уже и полезнее: команда браузерного агента может тратить меньше сил на поддержку селекторов для чекаута каждого магазина и больше — на целостность состояния, согласие и обработку исключений. Более широкий взгляд на платформу и компромиссы её эксплуатации даёт обзор Shopify.

Два продукта, которые стоит создать

1. Стенд для QA и проверки согласия в Checkout WebMCP

Это самая сильная возможность. Агентствам Shopify и командам, которые разрабатывают ИИ-агентов для покупок, нужно заранее понимать, поддерживается ли конкретный чекаут и безопасно ли ведёт себя агент, прежде чем доверять ему заказ.

Ближайший измеренный поисковый запрос, shopify checkout customization, получает 170 запросов в месяц в США, вырос на 89% год к году и имеет CPC $10.92. Он шире, чем тестирование WebMCP, но показывает активный спрос на настройку и поведение чекаута.

Минимальная версия, которую уже можно продавать, — Chromium-раннер: он открывает тестовый чекаут, записывает инструменты по origin и window, проверяет аргументы в виде JSON-строк, обнаруживает toolchange, тестирует обновление из свежего состояния, имитирует возврат null при навигации и документированные коды ошибок, а затем формирует обезличенный отчёт о согласии. Реальное завершение платежа оставьте за ручным режимом тестирования.

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

2. ИИ-ассистент для покупок в Shopify на стороне покупателя

Браузерное расширение могло бы провести пользователя от поиска товара до поддерживаемого чекаута в разных магазинах Shopify, предоставляя единый экран подтверждения и строгие правила работы с сохранёнными платёжными данными.

Запрос shopify ai shopping assistant получает 30 поисков в месяц в США, имеет коммерческий интент и CPC $19.43. Конкуренты на стороне продавца предлагают тарифы от $9.99 до $1,330 в месяц. Это показывает, что за ПО, которое помогает с покупками, уже платят, хотя данный продукт работал бы на стороне покупателя.

Для MVP нужны поиск по витрине и инструменты корзины, обнаружение инструментов чекаута, WBA, цикл «прочитать — обновить — прочитать», управляемая покупателем сводка заказа и передача управления для проверки платежа. Начните с заказов в одном магазине и сценариев с сохранёнными данными Shop Pay.

Главное препятствие — дистрибуция. Продавцы не включают Checkout WebMCP, но покупателю всё равно нужен совместимый браузерный агент. B2B, встроенный чекаут, mobile SDK, заказы из разных магазинов и обычный трёхстраничный чекаут без Shop Pay остаются за пределами этого сценария.

Ограничения и определяют границы продукта

Checkout WebMCP — более безопасный интерфейс для поддерживаемого браузерного чекаута, а не универсальный API покупок.

Во время оформления заказа он не может добавлять или удалять позиции, получать номер новой карты, отменять чекаут, управлять интерфейсом расширений приложений или заставлять исключённый чекаут зарегистрировать инструменты. Он не устраняет вход в Shop Pay, 3D Secure, этапы проверки и другие действия покупателя. И он не превращает текст продавца в заслуживающие доверия инструкции для модели.

Честное правило проектирования простое: пока инструменты зарегистрированы, используйте их; источником истины всегда считайте свежее состояние; когда контракт требует действий покупателя, возвращайте ему страницу.

Что сделать в понедельник

В понедельник добавьте в агент одну обёртку для чекаута вместо того, чтобы распределять вызовы по всей кодовой базе. Сосредоточьте в ней сериализацию, сопоставление инструментов, обработку toolchange, возврат null при навигации, классификацию ошибок и чтение свежего состояния. Прогоните восемь локальных сценариев фикстуры, затем получите список document.modelContext.getTools() в поддерживаемом тестовом чекауте, который вы контролируете. Выполните одно обновление, собранное из свежего состояния. Завершайте только поддерживаемый тестовый заказ и только после явного подтверждения. Если безопасного тестового заказа у вас нет, остановитесь на ready_for_complete и пометьте завершение как подтверждённое по источникам, но не проверенное лично.

Если вашей компании нужен торговый ИИ-агент с безопасным контуром согласия, посмотрите услугу разработки ИИ-агентов.