ChatGPT Merchants и путь мерчанта: от регистрации до ответственности

1. Кто такой ChatGPT‑мерчант и чем он отличается от «обычного магазина»

Если смотреть глазами разработчика, очень легко перепутать уровни: у нас есть Next.js‑приложение, MCP‑сервер, какой‑то commerce‑backend, и где‑то там ещё OpenAI, ChatGPT, Stripe и прочие взрослые сервисы. Хочется сказать: «Ну это всё одна большая система, главное, чтобы тесты зелёные».

Но в мире AI‑commerce юридические и технические границы очень жёстко разведены. ChatGPT не становится вашим магазином и не превращается в процессор платежей. Он лишь предоставляет интеллектуальный интерфейс и вызывает ваши API по открытым спецификациям. Мерчантом остаётся конкретная компания с конкретным каталогом и ответственностью перед пользователем.

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

Пример

Представим классический e‑commerce: у вас есть сайт, корзина, checkout, интеграция с платёжным провайдером. Пользователь заходит в браузере, кликает мышкой, вводит данные карты — всё понятно.

ChatGPT‑мерчант — это тот же самый магазин, только научившийся продавать через ИИ-диалог с высокой степенью автоматизации. Разница не в том, что вы продаёте, а в том, как пользователь проходит путь от запроса до оплаты.

С точки зрения OpenAI мерчант — это организация (или индивидуальный предприниматель), которая:

• предоставляет Product Feed по спецификации OpenAI (CSV/TSV/XML/JSON со структурированными данными о SKU);
• регистрируется в портале ChatGPT Merchants и проходит проверку категорий и юридических требований;
• в продвинутом варианте реализует Agentic Checkout и Delegated Payment, чтобы Instant Checkout в ChatGPT мог провести оплату без выхода на ваш сайт.

То есть мерчант — это не «человек, который написал виджет», а владелец ассортимента и финансовых обязательств. В нашем курсе мы играем сразу две роли: мы и команда, которая пишет GiftGenius как ChatGPT App, и команда, которая делает backend мерчанта, который этот App обслуживает.

2. Портал ChatGPT Merchants: путь от заявки до боевого мерчанта

У OpenAI есть отдельный сайт для продавцов — портал ChatGPT Merchants. Через него продавцы попадают в программу Instant Checkout и подключают свои фиды и backend. Разберём этот путь на шаги, без ещё глубоких технических деталей (это будет в следующей лекции).

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

До того, как кто‑то из вашей команды нажмёт кнопку «Apply», у вас уже должны быть несколько кирпичиков:

Юридическая сущность и сайт. У мерчанта есть домен и понятный пользователю storefront — даже если дальше всё будет продаваться через ChatGPT, OpenAI ожидает, что есть публичная витрина.

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

Базовая платежная инфраструктура. Хоть Delegated Payment и снимает с вас необходимость работать напрямую с картами, у вас должна быть интеграция с PSP (тот же Stripe) и понимание, как вы создаёте заказы и возвраты в своей системе.

Заявка в портале Merchants

С технической точки зрения это довольно скучный, но важный шаг: вы заходите на сайт и подаёте заявку на участие в программе Instant Checkout. Там обычно спрашивают:

• кто вы (юридическое лицо, сайт, контакты);
• что вы продаёте (категории, диапазон цен, регионы);
• каким образом вы готовы отдавать Product Feed (формат, URL, периодичность обновления).

Эта часть мало связана с TypeScript, но сильно влияет на ваш roadmap: пока мерчант не прошёл базовую проверку, никакой Instant Checkout включён не будет, даже если у вас идеальный код.

Подключение Product Feed

После того, как заявку посмотрели и в целом согласны, основной технический фокус смещается на Product Feed. По документации фид обязателен для интеграции: без него ChatGPT просто не знает, что вы продаёте.

На этом шаге вы:

1. Определяете формат фида (чаще всего CSV или JSON).
2. Договариваетесь, как будете его отдавать: это может быть pre‑signed URL на S3 или HTTPS‑endpoint, куда вы периодически POST’ите обновления.
3. Готовите минимум полей для каждого SKU: id, title, description, price, currency, availability, link, изображения и флаги enable_search / enable_checkout.

Пока вы ставите enable_checkout = false, мерчант может работать в режиме discovery‑only: ChatGPT находит и рекомендует товары, но при попытке покупки отправляет пользователя на ваш сайт.

Интеграция ACP (подробнее в следующей лекции)

Когда Product Feed стабильный и вы готовы пойти дальше, начинается интеграция Agentic Checkout и Delegated Payment. С точки зрения портала Merchants это отдельный блок требований: нужно реализовать эндпоинты /checkout_sessions, научиться принимать делегированный платёжный токен (Shared Payment Token) и корректно завершать сессии с нужными статусами (not_ready_for_payment, ready_for_payment, completed, canceled).

В этой лекции мы об этом только говорим как о «следующем уровне сложности». Все детали протокола и схемы запросов мы разберём в следующей лекции.

3.5. Сертификация и включение Instant Checkout

Завершающий этап — проверка того, как ваш backend ведёт себя в реальных сценариях:

• корректно ли создаются заказы;
• совпадают ли цены из фида и цены, по которым вы реально списываете деньги;
• правильно ли обрабатываются ошибки и возвраты;
• соответствуют ли ваши страницы ToS/Privacy ожиданиям OpenAI и локального права.

После этого мерчант получает статус «готов к Instant Checkout» и его товары с enable_checkout = true реально становятся покупаемыми прямо в ChatGPT.

Всё это можно мысленно представить в виде простой диаграммы:

flowchart TD
  A[Есть продукт и сайт] --> B[Заявка в ChatGPT Merchants]
  B --> C[Подключён Product Feed]
  C --> D["Реализован ACP backend
(checkout_sessions + delegated payment)"]
  D --> E[Сертификация
и включение Instant Checkout]

3. Варианты мерчанта: Etsy/Shopify vs кастомный backend

Хорошая новость: не все мерчанты обязаны сами писать весь ACP‑backend. Для некоторых платформ (Shopify, Etsy и др.) уже существуют интеграции, которые берут техническую реализацию на себя.

Если вы продаёте через Shopify или Etsy, то схема примерно такая: вы включаете у них опцию вроде «Show in ChatGPT», и платформа сама:

• формирует и поддерживает Product Feed в нужном формате;
• реализует или проксирует ACP‑ендпоинты;
• стыкуется со Stripe или другим PSP.

Вы, как владелец магазина, больше занимаетесь ассортиментом и описаниями, чем REST‑эндпоинтами.

Если же вы, как в нашем курсе с GiftGenius, строите кастомный мерчант со своим backend’ом, то у вас гораздо больше свободы, но и больше работы: вы сами пишете код, который реализует фид, checkout и интеграцию с платёжным провайдером.

Удобно это сравнить в виде таблицы:

Для курса мы сознательно выбираем третий вариант: только так мы можем пройти весь путь от фида до webhook‑ов и надёжного продакшена.

4. Ответственность мерчанта: данные, заказы, политика, деньги

Когда вы становитесь ChatGPT‑мерчантом, вы подписываетесь не только на радость от новых заказов, но и на набор очень конкретных обязательств. Разберём их по слоям.

Данные каталога и качество Product Feed

Product Feed — это источник истины для ChatGPT. Если в нём указано, что товар стоит 10 USD и есть в наличии, то именно это увидит пользователь в чате. Если фид врёт, то в лучшем случае вы получите недовольного клиента, в худшем — нарушение политики и проблемы с OpenAI.

От мерчанта ожидается:

• корректность обязательных полей (правильный формат цены, ISO‑коды валют, валидные HTTPS‑ссылки, рабочие изображения);
• обновление фида достаточно часто, чтобы не продавать призрачный товар;
• консистентность идентификаторов: id SKU в фиде должен совпадать с ID в вашей базе и в системе заказов, чтобы вы могли однозначно понять, что именно купили.

Если провести параллель с обычным e‑commerce, Product Feed здесь — это ваш «экспорт в маркетплейс», только маркетплейс в данном случае — не сайт, а умный ассистент, который живёт в голове пользователя и легко запоминает нестыковки.

Заказы, доставка и возвраты

ChatGPT не превращается в службу поддержки вашего магазина. Пользователь, конечно, общается с ним, но юридически он покупает товар у мерчанта, а не у OpenAI. Значит:

• вы отвечаете за то, что заказ будет создан в вашей системе и дойдёт до склада;
• вы отвечаете за то, что отправление придёт по адресу, указанному пользователем в Instant Checkout;
• вы отвечаете за обработку возвратов, отмен, частичных возвратов и т.п.

В рамках ACP checkout_session после успешного завершения обычно содержит объект order со своими полями. Но это лишь отражение того, что произошло у вас в backend’е — именно вы решаете, как выглядит запись в таблице orders, какие статусы есть, как они связаны с логистикой.

Политика и география

В портале Merchants вы указываете, в каких странах вы продаёте и какие типы товаров. OpenAI со своей стороны проверяет, что вы:

• не продаёте запрещённые категории;
• соблюдаете местное право (например, налоговые правила и ограничения по возрасту);
• предоставляете понятные Terms of Service и Privacy Policy.

В последующих модулях мы ещё будем говорить про юридические страницы, но уже сейчас полезно мыслить в терминах: «Если я не смогу объяснить юристу, что именно я продаю и где, ChatGPT вряд ли будет это продавать за меня».

Деньги и платёжный провайдер

Наконец, самое страшное — деньги. К счастью, ACP и Delegated Payment сильно упрощают жизнь разработчика:

• ChatGPT и платёжный провайдер (например, Stripe) договариваются о Shared Payment Token для конкретной суммы и мерчанта;
• ваш backend получает этот токен в complete-запросе и использует у себя в PSP, не видя «сырые» данные карты.

То есть вы не превращаетесь в PCI‑совместимое чудовище, не храните номера карт и не внедряетесь в кошмары по аудиту. Ваша ответственность — корректно использовать делегированный токен (создать платёж, списать деньги, сделать возврат) и аккуратно вести учёт.

5. Как это ложится на архитектуру GiftGenius

Вернёмся к нашему учебному приложению GiftGenius. В архитектурном плане после модуля 14 мы хотим, чтобы студент мог нарисовать схему уровня: «Пользователь → ChatGPT → App widget → MCP Gateway → Product Feed / Agents / ACP backend».

В этой схеме роль мерчанта реализуется в нашем backend’е, а виджет и App выступают лишь «лицом» этого мерчанта в ChatGPT.

Конфигурация мерчанта в коде

Начнём с простого шага: заведём в коде структуру конфигурации мерчанта. Пусть это будет TypeScript‑модуль lib/merchantConfig.ts в нашем Next.js‑проекте:

// lib/merchantConfig.ts
export type MerchantConfig = {
  id: string;                // ID мерчанта в ACP/Stripe
  name: string;              // Человекочитаемое имя
  feedUrl: string;           // Где лежит Product Feed
  instantCheckoutEnabled: boolean;
};

export const giftGeniusMerchant: MerchantConfig = {
  id: process.env.MERCHANT_ID ?? "dev-merchant",
  name: "GiftGenius",
  feedUrl: process.env.PRODUCT_FEED_URL ?? "https://example.com/feed.json",
  instantCheckoutEnabled: false, // включим позже
};

Здесь, во‑первых, мы явно фиксируем границы: это мерчант, а не «виджет». Во‑вторых, выносим важные значения в переменные окружения — в модулях про деплой и окружения мы ещё не раз вспомним, почему не стоит хардкодить такие вещи.

Для удобства можно добавить простую функцию, которая будет говорить нашему коду, можно ли сейчас использовать Instant Checkout:

// lib/merchantConfig.ts
export function canUseInstantCheckout(cfg: MerchantConfig) {
  // На dev и staging всегда отключаем Instant Checkout
  if (process.env.NODE_ENV !== "production") return false;
  return cfg.instantCheckoutEnabled;
}

Так мы заранее готовим архитектуру к тому, что на разных окружениях поведение будет разным, и не даём себе (и GPT) случайно уйти в боевой чекаут с тестового стенда.

MCP‑tool для получения информации о мерчанте

Часто удобно дать модели и виджету возможность узнать, в каком режиме сейчас работает мерчант. Например, чтобы GPT не предлагал Instant Checkout, если он отключён.

В MCP‑сервере (который мы поднимали в прошлых модулях) можно завести простой инструмент:

// mcp/tools/merchant.ts
import { giftGeniusMerchant, canUseInstantCheckout } from "../lib/merchantConfig";

export const getMerchantInfoTool = {
  name: "get_merchant_info",
  description: "Возвращает базовую информацию о мерчанте GiftGenius",
  inputSchema: { type: "object", properties: {}, additionalProperties: false },
  async handler() {
    return {
      id: giftGeniusMerchant.id,
      name: giftGeniusMerchant.name,
      instantCheckout: canUseInstantCheckout(giftGeniusMerchant),
    };
  },
};

Этот инструмент не делает ничего невероятного, но создаёт явное место, где модель может спросить: «А можно ли сейчас купить прямо в чате или только перейти по ссылке?».

Использование информации о мерчанте в виджете

На стороне виджета, используя уже знакомые нам хуки Apps SDK, можно вызвать get_merchant_info и поменять UI в зависимости от режима. Простейший пример компонента:

// components/MerchantBadge.tsx
"use client";

import { useEffect, useState } from "react";
import { useCallTool } from "../lib/use-call-tool";

type MerchantInfo = { name: string; instantCheckout: boolean };

export function MerchantBadge() {
  const callTool = useCallTool();
  const [info, setInfo] = useState<MerchantInfo | null>(null);

  useEffect(() => {
    callTool("get_merchant_info", {}).then((res) => {
      setInfo(res?.result as MerchantInfo);
    });
  }, [callTool]);

  if (!info) return null;
  return (
    <span>
      {info.name} · {info.instantCheckout ? "Instant Checkout" : "Discovery only"}
    </span>
  );
}

Такой небольшой компонент приятно подчёркивает пользователю (и вам самим в dev‑режиме), в каком именно состоянии сейчас находится интеграция с ChatGPT.

6. Практическое мини‑задание

Чтобы лекция не осталась только на уровне «слов и диаграмм», попробуйте проделать следующие шаги в своём проекте GiftGenius (или аналогичном):

Во‑первых, добавьте модуль конфигурации мерчанта, похожий на merchantConfig.ts, и вынесите MERCHANT_ID и PRODUCT_FEED_URL в переменные окружения. Для локальной разработки можно использовать .env.local, а для production — настройки Vercel или другой платформы.

Во‑вторых, реализуйте в MCP‑сервере простой инструмент get_merchant_info, который возвращает хотя бы name и instantCheckout. Подумайте, какие ещё поля могут быть полезны модели: например, список поддерживаемых валют или стран доставки.

В‑третьих, добавьте в виджет небольшой UI‑элемент (бейдж, строку статуса, подпись на карточке товара), который использует этот tool и показывает пользователю, в каком режиме сейчас работает ваш мерчант: только рекомендации или уже полноценный Instant Checkout. Это не только полезно для UX, но и отлично помогает отладке.

Наконец, попробуйте текстом расписать, какими шагами ваш конкретный проект будет идти от «у нас есть сайт и backend» до статуса ChatGPT‑мерчанта. Где именно вы подключите Product Feed, когда будете включать enable_checkout, когда начнёте реализацию ACP‑эндпоинтов. Такое упражнение хорошо дисциплинирует и помогает не забыть важные нелюбимые вещи вроде политики возвратов.

7. Типичные ошибки на пути к ChatGPT‑мерчанту

Ошибка №1: «ChatGPT — это и есть мой магазин».
Иногда разработчики мысленно «переносят» всё на сторону ChatGPT: будто бы он и каталог хранит, и цены считает, и заказы исполняет. В реальности ChatGPT — это интерфейс и оркестратор, а не ваш ERP. Если забыть об этом, легко построить архитектуру, где нет нормальной собственной модели заказов, все данные живут «где‑то в промптах», и любое изменение в поведении модели грозит потерей консистентности.

Ошибка №2: ожидание Instant Checkout без отдельной регистрации и ACP.
Факт, что вы написали отличный виджет и настроили Product Feed, ещё не включает автоматически Instant Checkout. Нужны заявка в портале Merchants, проверка категорий, реализация Agentic Checkout и Delegated Payment, прохождение тестов. Попытка заложиться на Instant Checkout «по умолчанию» обычно заканчивается тем, что GPT начинает предлагать пользователю то, чего на самом деле нет, или давать ссылки вместо ожидаемых платёжных экранов.

Ошибка №3: жёсткий хардкод идентификаторов и URL мерчанта.
Классическая история: MERCHANT_ID = "prod-123" прописан прямо в коде, URL фида — строкой в компоненте виджета. Как только у вас появляется staging или необходимость завести второго мерчанта, начинается массовый поиск‑и‑замена. Гораздо безопаснее вынести такие вещи в конфигурацию и переменные окружения и использовать их через небольшой слой абстракции, как мы сделали с MerchantConfig.

Ошибка №4: Product Feed живёт своей жизнью, не связанной с заказами.
Если в фиде SKU GIFT_RED_MUG стоит 10 USD, а в базе заказов на тот же идентификатор вы по каким‑то причинам списываете 12 USD, рано или поздно это всплывёт. Источник правды о ценах и наличии должен быть либо фидом, собираемым из ваших внутренних данных, либо общей прослойкой, которой доверяют и фид, и checkout. Попытка вести «двойную бухгалтерию» (одно для ChatGPT, другое для своего сайта) очень быстро выходит боком.

Ошибка №5: игнорирование роли платёжного провайдера и хранения платёжных данных.
Иногда возникает соблазн «подглядеть» в токен платёжного провайдера или даже дополнительно просить у пользователя платёжные реквизиты в своём UI. Это не только нарушает модель Delegated Payment, но и может втянуть вас в мир PCI DSS и тяжёлого комплаенса. Правильная практика — относиться к Shared Payment Token как к непрозрачной строке, использовать его только в SDK платёжного провайдера и нигде не логировать и не кэшировать.

Ошибка №6: недооценка многошаговости онбординга и отсутствия плана.
Наконец, частая организационная ошибка — думать, что «ну мы же просто подключимся к ChatGPT, что там сложного». По факту путь мерчанта состоит из множества шагов: технических (фид, backend, тесты) и нетехнических (юридические документы, согласование категорий, региональные ограничения). Если не расписать этот путь заранее, команда будет хаотично прыгать между задачами, а дедлайны начнут «таять» быстрее, чем ваше вдохновение от AI‑commerce.