Картина світу AI‑commerce та роль OpenAI

1. Що взагалі таке AI‑commerce

Якщо класичний e‑commerce — це історія «зайшли на сайт — відкрили каталог — додали в кошик — пройшли через три форми», то AI‑commerce — підхід, у якому головним інтерфейсом стає діалог із ChatGPT. Користувач формулює завдання звичайною мовою, а агент усередині ChatGPT бере на себе роль консультанта, мерчандайзера й частково продакт-менеджера.

Запити виглядають не як «category=шкарпетки&price_max=20», а як «підберіть смішний, але не надто недоречний подарунок колезі до 20 доларів, який можна надіслати електронною поштою». Агент інтерпретує завдання, ставить уточнювальні запитання, переглядає каталог товарів, пояснює плюси й мінуси варіантів, а потім веде користувача до купівлі. І все це — без того, щоб користувач узагалі бачив «кошик» як окрему сторінку.

З погляду архітектури в цей момент застосунок ChatGPT перетворюється з «розумного каталогу подарунків» на commerce‑застосунок, який уміє:

1. Розуміти намір користувача та обмеження (бюджет, тип подарунка, країна, цифровий/фізичний товар).
2. Підбирати конкретні SKU з product feed і пояснювати свій вибір.
3. Ініціювати оформлення купівлі через стандартизований протокол ACP (Agentic Commerce Protocol).

Ідея AI‑commerce полягає в тому, що «catalog + checkout» перестають бути окремим сайтом. Натомість це логічне продовження діалогу, який користувач і так веде з GPT.

2. Класичний e‑commerce проти AI‑commerce

Щоб краще відчути різницю, зручно поставити два підходи поруч. Нижче — спрощена таблиця. Вона не претендує на повне охоплення, зате добре показує зміну парадигми.

Практичний наслідок: в AI‑commerce увага зміщується з візуального дизайну «каталогу й кошика» на структуру та якість даних, а також на формальний протокол взаємодії між ChatGPT, вашим бекендом і платіжним провайдером. Product feed і ACP-ендпоїнти стають таким самим важливим «UI», як і сам віджет.

Якщо в класичному магазині частину UX можна «підкрутити» в браузері, то в AI‑commerce модель майже повністю спирається на дані й схеми, які ви їй дали. Це стосується всього: від опису товару до статусів checkout‑сесії.

3. Будівельні блоки OpenAI Commerce

OpenAI не пропонує «магічну платіжну систему GPTPay», яка сама все зробить. Натомість є набір специфікацій і настанов, що описують, як коректно підʼєднувати наявних мерчантів і платіжних провайдерів до світу ChatGPT. Із цих документів для нас особливо важливі чотири «цеглинки».

По‑перше, Product Feed Specification. Це офіційний формат, у якому продавець описує свій каталог товарів: id, title, description, ціна, валюта, наявність, зображення тощо. Фід виступає «структурованим джерелом істини», який OpenAI валідує, індексує та використовує для пошуку, ранжування й checkout усередині ChatGPT.

По‑друге, Agentic Checkout Specification. Це REST‑контракт для роботи з сутністю checkout_session. API описує, як створити платіжну сесію, як оновлювати її (наприклад, коли змінюється адреса або варіант доставки) і як завершувати. Також у ньому визначено, які поля має повертати бекенд (суми, податки, опції fulfillment, посилання на політику повернення тощо).

По‑третє, Delegated Payment Specification. Це протокол, за яким платформа агента (ChatGPT) отримує делегований платіжний токен від платіжного провайдера (наприклад, Stripe Shared Payment Token) і передає його вашому бекенду, не розкриваючи платіжні реквізити. Сам токен обмежений за сумою, часом життя та іншими параметрами. Далі ваш бекенд використовує його, щоб створити реальний платіж у PSP.

І нарешті, Instant Checkout у ChatGPT — це UX‑надбудова над цими специфікаціями. Усередині чату зʼявляється компактний checkout‑інтерфейс: обраний товар, ціна, адреса, метод оплати. «Під капотом» він спирається на Product Feed, викликає ваші /checkout_sessions за Agentic Checkout Spec і використовує Delegated Payment, щоб провести транзакцію в PSP.

Добра новина в тому, що все це — не «секретний API ChatGPT», а відкриті специфікації ACP (Agentic Commerce Protocol). Тобто той самий бекенд теоретично може працювати й з іншими AI‑платформами, якщо вони теж підтримують ACP.

4. Ролі та межі відповідальності

Далі починається найцікавіше: щойно в системі зʼявляються гроші, регулятори та юристи раптово стають вашими найкращими друзями. Щоб не заплутатися, важливо чітко розділити ролі.

Найголовніша роль — у платформи агента, у нашому випадку це ChatGPT. Вона відповідає за користувацький досвід: чат, віджети, Instant Checkout UI. Платформа запускає commerce‑флоу, обирає товари з Product Feed, викликає ваші ACP‑ендпоїнти та показує користувачу результат. Водночас ChatGPT не стає ні власником товару, ні платіжним провайдером. Так само він не зберігає ваші product‑дані як «свій каталог»: використовує саме той фід, який ви йому надали.

Друга роль — мерчант (seller, merchant‑of‑record). Це власник товарів або послуг. Мерчант відповідає за сам product feed (структуру, якість, актуальність цін і наявності), за коректну реалізацію ACP‑ендпоїнтів (/checkout_sessions, вебхуки), за створення й зберігання замовлень, за доставку, підтримку та повернення. Документація ACP підкреслює: саме мерчант залишається продавцем запису в юридичному сенсі, а не платформа агента.

Третя роль — платіжний провайдер (PSP), наприклад, Stripe. PSP відповідає за обробку платежів, дотримання PCI DSS та інших вимог, зберігання платіжних реквізитів, боротьбу зі шахрайством і чарджбеками. У контексті Delegated Payment PSP видає платформі агента спеціальний токен (SPT), який потім використовує ваш сервер для створення реального платежу (наприклад, PaymentIntent у Stripe).

Четверта й найважливіша роль — користувач. Він формулює завдання, ухвалює остаточне рішення про купівлю, дає згоду на оплату і, в ідеалі, читає Умови / Політику конфіденційності, які ви чесно показуєте в checkout‑UI. Product feed може містити посилання на ці документи та на політику повернень — це підвищує довіру й прозорість.

Для зручності це можна звести в невелику таблицю:

Розділення зон відповідальності важливе не лише для юристів, а й для архітектури. Наприклад, якщо завтра ви підʼєднаєте другого PSP, вам не доведеться переписувати застосунок ChatGPT: достатньо адаптувати шар Delegated Payment на своєму бекенді. А якщо зʼявиться друга AI‑платформа, яка теж розуміє ACP, ви зможете перевикористати і product feed, і checkout‑ендпоїнти.

5. Як виглядає сценарій купівлі «все в діалозі»

Тепер зберемо все докупи й подивимося, як виглядає end‑to‑end сценарій купівлі цифрового подарунка в ChatGPT з погляду архітектури. Це спрощений сценарій, але він добре передає суть.

sequenceDiagram
  participant U as Користувач
  participant C as ChatGPT
  participant G as GiftGenius App
  participant B as Merchant Backend
  participant P as PSP (Stripe)

  U->>C: "Купи цифровий подарунок до $50"
  C->>G: callTool(find_gifts, budget<=50)
  G->>B: GET /catalog?budget_lte=50
  B-->>G: Список відповідних SKU
  G-->>C: Варіанти подарунків + метадані
  C-->>U: Пояснює вибір, пропонує опції
  U->>C: "Беру оцей"
  C->>B: POST /checkout_sessions (sku, price...)
  C->>P: Запросити платіжний токен (SPT)
  C->>B: POST /checkout_sessions/{id}/complete (token)
  B->>P: Провести платіж
  B-->>C: Webhook про створення замовлення
  C-->>U: Підтвердження купівлі

Якщо описати мовою ACP, тут відбувається таке:

1. Агент використовує Product Feed (через ваш бекенд), щоб підібрати відповідні SKU.
2. Коли вирішено «купуємо», ChatGPT створює checkout_session через ваш /checkout_sessions за Agentic Checkout Spec.
3. Під час Instant Checkout ChatGPT запитує в PSP делегований платіжний токен на конкретну суму й для конкретного мерчанта.
4. Цей токен передається в POST /checkout_sessions/{id}/complete. Ваш бекенд створює платіж у PSP і формує замовлення.
5. Коли замовлення готове, ваш сервер повідомляє OpenAI через webhook, після чого користувач бачить фінальне підтвердження.

У цій лекції для нас важливо не стільки запамʼятати назви ендпоїнтів, скільки побачити структуру: фід → підбір SKU → checkout_session → платіж → замовлення → webhook. У наступних лекціях ми розбиратимемо кожен блок окремо — зокрема поля фіда, поля checkout‑сесії та формат делегованих платежів.

6. GiftGenius: як наш App вписується в AI‑commerce

До цього моменту GiftGenius відігравав роль «асистента з підбору подарунків». Він умів:

• ставити користувачу запитання: кому і з якого приводу потрібен подарунок;
• використовувати інструменти MCP для пошуку у своєму каталозі;
• показувати картки варіантів у віджеті та надсилати кнопки follow‑up у чат.

З погляду commerce це був «розумний discovery» без реальної купівлі. У світі OpenAI Commerce такий режим відповідає фіду, у якому для SKU виставлено enable_search = true, але enable_checkout = false: товари можна знаходити й обговорювати, але Instant Checkout для них вимкнено.

У модулі AI‑commerce ми поступово перетворимо GiftGenius на повноцінно інтегрованого мерчанта:

• додамо структурований Product Feed за специфікацією OpenAI;
• спроєктуємо ACP‑бекенд, що вміє працювати з checkout_sessions;
• підʼєднаємо Delegated Payment через Stripe Shared Payment Token;
• навчимо застосунок показувати користувачеві, що він може не лише підібрати, а й купити подарунок прямо в чаті.

Щоб усе це не виглядало як «чорна магія», додаймо в наш код невеликий технічний шар, який явно моделює ролі та кроки commerce‑флоу. Це знадобиться і для логів, і для внутрішніх тестів.

// app/commerce/types.ts
export type CommerceRole = "user" | "chatgpt" | "merchant" | "psp";

export interface CommerceStep {
  id: string;
  role: CommerceRole;
  description: string;
}

Ці типи допомагають подумки відділяти «хто що робить» навіть на рівні TypeScript. Ви можете використовувати їх, наприклад, у тестах або в налагоджувальному UI всередині віджета.

Невеликий приклад масиву кроків для сценарію «цифровий подарунок до $50»:

// app/commerce/exampleFlow.ts
import type { CommerceStep } from "./types";

export const digitalGiftFlow: CommerceStep[] = [
  { id: "intent", role: "user", description: "Сформулювати запит і бюджет" },
  { id: "search", role: "chatgpt", description: "Підібрати SKU з Product Feed" },
  { id: "checkout", role: "merchant", description: "Створити checkout_session" },
  { id: "payment", role: "psp", description: "Провести платіж за токеном" }
];

Такий код поки ні з ким не спілкується мережею, але вже створює корисну «вісь координат», довкола якої ми нарощуватимемо реальний ACP‑код у наступних лекціях.

7. Міні‑завдання: розкладіть флоу «Купи мені цифровий подарунок до $50»

Наприкінці лекції корисно вручну розібрати те, що ми щойно проговорили. Візьміть запит користувача:

«Купи мені цифровий подарунок до $50».

Завдання — описати у 3–5 логічних кроках, що відбувається далі. Для кожного кроку вкажіть, хто його виконує: ChatGPT, ваш мерчантський бекенд, платіжний провайдер чи сам користувач. Можна спиратися на діаграму вище та на масив digitalGiftFlow, але не обовʼязково збігатися з ним один в один.

Наприклад, ви можете почати з кроку, де ChatGPT інтерпретує запит і уточнює в користувача деталі (цифровий сертифікат, регіон отримувача, кому саме подарунок). Далі — крок, де ваш бекенд через Product Feed шукає відповідні SKU. Потім — створення checkout_session, отримання платіжного токена від PSP і завершення купівлі.

За бажання можете оформити це прямо в коді: додати ще кілька кроків до digitalGiftFlow і відрендерити їх у невеликому налагоджувальному компоненті у віджеті. Така вправа тренує звичку думати не лише «про код», а й про ролі в протоколі.

Приклад простого API‑ендпоїнта, який міг би приймати такий «план флоу» і логувати його (поки що без справжньої комерції):

// app/api/commerce/flow/route.ts
import { NextRequest, NextResponse } from "next/server";
import type { CommerceStep } from "@/app/commerce/types";

export async function POST(req: NextRequest) {
  const steps = (await req.json()) as CommerceStep[];
  console.log("Запланований AI-commerce флоу:", steps);
  return NextResponse.json({ ok: true, stepsCount: steps.length });
}

У реальному житті замість console.log ви писатимете структуровані логи й, можливо, зберігатимете такі сценарії як частину документації або тестів. Але навіть цей невеликий приклад допомагає повʼязати абстрактну архітектуру з конкретним TypeScript‑кодом у вашому Next.js‑застосунку.

Якщо тримати в голові картину ролей, яку ми розібрали в цій лекції, подальші технічні деталі — поля Product Feed, схеми checkout‑сесій і структура делегованих платежів — ляжуть значно легше, без зайвого романтизму довкола «всемогутнього GPT».

8. Типові помилки в розумінні AI‑commerce і ролей

Помилка № 1: вважати, що «ChatGPT усе зробить сам».
Інколи розробники думають, що достатньо «підʼєднати Stripe» й якось «дати моделі доступ до API», а далі GPT усе владнає. Насправді AI‑commerce навколо ChatGPT спирається на формальні специфікації: Product Feed, Agentic Checkout, Delegated Payment. Якщо ви не описали товари як структурований фід, не реалізували /checkout_sessions і не налаштували Delegated Payment, жодна модель не вигадає це за вас.

Помилка № 2: плутати ролі ChatGPT і мерчанта.
Інша поширена плутанина — думати, що ChatGPT стає «магазином», а ви лише «підʼєднуєте каталог». Насправді все навпаки: ви залишаєтеся мерчантом, зберігаєте product feed, створюєте й обслуговуєте замовлення, обробляєте повернення. ChatGPT відповідає лише за UX діалогу та коректні виклики ваших ACP‑ендпоїнтів. Якщо спроєктувати систему так, ніби «GPT сам роздасть підписки та надішле товари», рано чи пізно ви опинитеся в юридичному й технічному глухому куті.

Помилка № 3: ігнорувати платіжного провайдера як окрему сутність.
Іноді хочеться «сховати» PSP усередині бекенду та спілкуватися з ним так само, як із будь‑яким REST‑API, забуваючи, що платіжний шар живе за своїми правилами (PCI, шахрайство, чарджбеки, ліміти). В ACP‑підході не випадково виділено окрему Delegated Payment Spec: платформа агента спілкується з PSP на своєму рівні, отримує SPT‑токен і передає його вам, а ви вже створюєте платіж. Якщо спробувати обійти цю схему й напряму приймати реквізити карт у App, ви швидко «вистрелите собі в ногу» вимогами відповідності.

Помилка № 4: сприймати product feed як «маркетингове налаштування», а не як API для LLM.
Багато хто приходить із досвіду Google Shopping і думає про фід як про щось важливіше для рекламного кабінету, ніж для коду. У світі AI‑commerce фід — це, по суті, база знань вашого асортименту для моделі. Якщо там биті посилання на зображення, неузгоджені атрибути, дивні одиниці вимірювання й маркетингові перебільшення замість фактів, модель пропонуватиме не те, що вам потрібно. У результаті конверсія просяде.

Помилка № 5: намагатися впровадити Instant Checkout «в один крок».
Спокуса велика: «давайте одразу ввімкнемо enable_checkout, і хай користувачі купують із чату». Але без якісного discovery (тобто якісного фіда), без надійного checkout‑бекенду й без продуманої інтеграції з PSP ви ризикуєте отримати крихку систему, де половина замовлень зависає посередині. Значно розумніше рухатися сходинками, які пропонує OpenAI: спочатку якісний Product Feed, потім налагодження ACP‑ендпоїнтів, далі Delegated Payment — і лише після цього ввімкнення Instant Checkout у бойовому режимі.