ChatGPT Merchants і шлях мерчанта: від реєстрації до відповідальності

1. Хто такий ChatGPT‑мерчант і чим він відрізняється від «звичайного магазину»

Якщо дивитися очима розробника, дуже легко переплутати рівні. У нас є застосунок Next.js, MCP‑сервер, якийсь бекенд електронної комерції, а десь там іще — OpenAI, ChatGPT, Stripe та інші «дорослі» сервіси. Так і хочеться сказати: «Та це ж одна велика система — аби тести були зелені».

Але у світі AI‑комерції юридичні й технічні межі розмежовано дуже жорстко. ChatGPT не стає вашим магазином і не перетворюється на процесор платежів. Він лише надає інтелектуальний інтерфейс і викликає ваші API за відкритими специфікаціями. Мерчантом лишається конкретна компанія з конкретним каталогом і відповідальністю перед користувачем.

Розуміння ролі мерчанта потрібне не лише юристам. Від нього залежать архітектурні рішення. Де зберігати дані фіда? Як валідувати замовлення? Що саме логувати? Як налагоджувати розбіжності між тим, що показано в чаті, і тим, що насправді сталося у вашій системі?

Приклад

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

ChatGPT‑мерчант — це той самий магазин, тільки навчений продавати через діалог із ШІ та з високим рівнем автоматизації. Різниця не в тому, що ви продаєте, а в тому, як користувач проходить шлях від запиту до оплати.

З погляду OpenAI мерчант — це організація (або ФОП), яка:

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

Тобто мерчант — це не «людина, яка написала віджет», а власник асортименту та фінансових зобовʼязань. У нашому курсі ми поєднуємо дві ролі: ми і команда, яка пише GiftGenius як ChatGPT App, і команда, яка розробляє бекенд мерчанта, що цей App обслуговує.

2. Портал ChatGPT Merchants: шлях від заявки до бойового мерчанта

У OpenAI є окремий сайт для продавців — портал ChatGPT Merchants. Через нього продавці потрапляють у програму Instant Checkout і підʼєднують свої фіди та бекенд. Розберімо цей шлях крок за кроком — поки що без глибоких технічних деталей. Вони будуть у наступній лекції.

Попередня підготовка

Перш ніж хтось із вашої команди натисне кнопку «Apply», у вас уже мають бути кілька «цеглинок»:

Юридична сутність і сайт. У мерчанта є домен і зрозуміла користувачеві вітрина (storefront). Навіть якщо далі все продаватиметься через ChatGPT, OpenAI очікує публічний сайт.

Асортимент у межах політики. У попередній лекції ми говорили про Prohibited Products Policy: не можна продавати, наприклад, зброю або окремі медичні товари. Будь‑який товар, який ви хочете продавати через ChatGPT, має входити до переліку дозволених категорій.

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

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

З технічного погляду це доволі нудний, але важливий крок: ви заходите на сайт і подаєте заявку на участь у програмі Instant Checkout. Там зазвичай запитують:

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

Це мало повʼязано з TypeScript, зате сильно впливає на ваш план робіт. Поки мерчант не пройшов базову перевірку, Instant Checkout не ввімкнуть — навіть якщо у вас ідеальний код.

Підʼєднання Product Feed

Після того як заявку розглянули й загалом погодили, основний технічний фокус зміщується на Product Feed. За документацією фід обовʼязковий для інтеграції: без нього ChatGPT просто не знає, що ви продаєте.

На цьому кроці ви:

1. Визначаєте формат фіда (найчастіше CSV або JSON).
2. Домовляєтеся, як будете його віддавати: це може бути попередньо підписаний 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

Завершальний етап — перевірка того, як ваш бекенд поводиться в реальних сценаріях:

• чи коректно створюються замовлення;
• чи збігаються ціни з фіда та ціни, за якими ви насправді списуєте гроші;
• чи правильно опрацьовуються помилки та повернення;
• чи відповідають ваші сторінки 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 проти кастомного бекенду

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

Якщо ви продаєте через Shopify або Etsy, то схема приблизно така: ви вмикаєте в них опцію на кшталт «Show in ChatGPT», і платформа сама:

• формує та підтримує Product Feed у потрібному форматі;
• реалізує або проксіює ACP‑ендпоїнти;
• стикується зі Stripe або іншим PSP.

Ви як власник магазину більше займаєтеся асортиментом і описами, ніж REST‑ендпоїнтами.

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

Зручно порівняти це у вигляді таблиці:

Для курсу ми свідомо обираємо третій варіант: лише так ми можемо пройти весь шлях — від фіда до вебхуків і надійного продакшену.

4. Відповідальність мерчанта: дані, замовлення, політики, гроші

Коли ви стаєте ChatGPT‑мерчантом, ви берете на себе не лише радість від нових замовлень, а й цілком конкретні зобовʼязання. Розберімо їх пошарово.

Дані каталогу та якість Product Feed

Product Feed — це джерело правди для ChatGPT. Якщо в ньому вказано, що товар коштує 10 USD і є в наявності, саме це й побачить користувач у чаті. Якщо фід «бреше», то в кращому разі ви отримаєте незадоволеного клієнта, а в гіршому — порушення політики та проблеми з OpenAI.

Від мерчанта очікують:

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

Якщо провести паралель зі звичайною електронною комерцією, Product Feed тут — це ваш «експорт на маркетплейс». Тільки маркетплейс у цьому випадку — не сайт, а розумний асистент, який «живе в голові» користувача й легко запамʼятовує нестиковки.

Замовлення, доставка та повернення

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

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

У межах ACP checkout_session після успішного завершення зазвичай містить обʼєкт order зі своїми полями. Але це лише відображення того, що сталося у вашому бекенді. Саме ви вирішуєте, як виглядає запис у таблиці orders, які є статуси та як вони повʼязані з логістикою.

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

У порталі Merchants ви вказуєте, у яких країнах продаєте та які типи товарів пропонуєте. OpenAI зі свого боку перевіряє, що ви:

• не продаєте заборонені категорії;
• дотримуєтеся місцевого права (наприклад, податкових правил і обмежень за віком);
• надаєте зрозумілі Terms of Service і Privacy Policy.

У наступних модулях ми ще говоритимемо про юридичні сторінки, але вже зараз корисно мислити так: «Якщо я не зможу пояснити юристу, що саме продаю і де, ChatGPT навряд чи продаватиме це за мене».

Гроші та платіжний провайдер

Нарешті, найчутливіша тема — гроші. На щастя, ACP і Delegated Payment суттєво спрощують життя розробнику:

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

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

5. Як це лягає на архітектуру GiftGenius

Повернімося до нашого навчального застосунку GiftGenius. В архітектурному плані після модуля 14 ми хочемо, щоб ви могли накреслити схему рівня: «Користувач → ChatGPT → віджет застосунку → MCP Gateway → Product Feed / Agents / ACP 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 випадково піти в бойовий checkout із тестового стенда.

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, а й чудово допомагає налагодженню.

Нарешті, спробуйте текстом розписати, якими кроками ваш конкретний проєкт ітиме від «у нас є сайт і бекенд» до статусу 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, що там складного». Насправді шлях мерчанта складається з безлічі кроків: технічних (фід, бекенд, тести) і нетехнічних (юридичні документи, погодження категорій, регіональні обмеження). Якщо не розписати цей шлях заздалегідь, команда хаотично стрибатиме між завданнями, а дедлайни почнуть «танути» швидше, ніж ваше натхнення від AI‑комерції.