Картина мира AI‑commerce и роль OpenAI

1. Что вообще такое AI‑commerce

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

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

С точки зрения архитектуры ChatGPT App в этот момент превращается из «умного каталога подарков» в commerce‑приложение, умеющее:

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

Идея AI‑commerce в том, что «catalog + checkout» становятся не отдельным сайтом, а логичным продолжением диалога, который уже и так ведёт пользователь с GPT.

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

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

Практическое следствие: в AI‑commerce внимание смещается с визуального дизайна «каталога и корзины» на структуру и качество данных, а также на формальный протокол взаимодействия между ChatGPT, вашим backend’ом и платёжным провайдером. 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 описывает, как создать payment‑сессию, обновить её (например, при смене адреса или варианта доставки) и завершить, а также какие поля должен вернуть backend (суммы, налоги, fulfillment‑опции, ссылки на политику возврата и т.п.).

В‑третьих, Delegated Payment Specification. Это протокол, по которому платформа агента (ChatGPT) получает делегированный платёжный токен от платёжного провайдера (например, Stripe Shared Payment Token) и передаёт его вашему backend’у, не раскрывая сами платёжные реквизиты. Сам токен ограничен по сумме, времени жизни и другим параметрам и используется вашим backend’ом для создания реального платежа у PSP.

И наконец, Instant Checkout в ChatGPT — это UX‑надстройка над этими спецификациями. Внутри чата появляется компактный checkout‑интерфейс: выбранный товар, цена, адрес, метод оплаты. Под капотом он опирается на Product Feed, вызывает ваши /checkout_sessions по Agentic Checkout Spec и использует Delegated Payment, чтобы провести транзакцию у PSP.

Хорошая новость в том, что все эти штуки — это не «секретный API ChatGPT», а открытые спецификации ACP (Agentic Commerce Protocol). Это значит, что тот же backend может теоретически работать и с другими AI‑платформами, если они также поддерживают ACP.

4. Роли и границы ответственности

Дальше начинается самое интересное: когда в систему попадают деньги, регуляторы и юристы внезапно становятся вашими лучшими друзьями. Чтобы не запутаться, важно чётко разделять роли.

Самая главная роль у платформы агента, в нашем случае — ChatGPT. Она владеет пользовательским опытом: чат, виджеты, Instant Checkout UI. Платформа инициирует commerce‑флоу, выбирает товары из Product Feed, вызывает ваши ACP‑эндпоинты и показывает пользователю результат. Но при этом ChatGPT не становится ни владельцем товара, ни платёжным провайдером и не хранит ваши product‑данные как «свой каталог» — он использует именно тот фид, который вы ему отдали.

Во второй роли — мерчант (seller, merchant‑of‑record). Это владелец товаров или услуг. Мерчант отвечает за сам product feed (структура, качество, актуальность цен и наличия), за правильную реализацию ACP‑эндпоинтов (/checkout_sessions, webhooks), за создание и хранение заказов, за доставку, поддержку и возвраты. Документация по ACP подчёркивает, что именно мерчант остаётся продавцом записи в юридическом смысле, а не платформа агента.

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

Четвёртая и самая важная роль — пользователь. Он формулирует задачу, принимает финальное решение о покупке, даёт согласие на оплату и, в идеале, читает Terms / Privacy Policy, которые вы честно показываете в checkout‑UI. Product feed может содержать ссылки на эти документы и политику возвратов, чтобы повысить доверие и прозрачность.

Для удобства можно свести это в маленькую таблицу:

Разделение зон ответственности важно не только для юристов, но и для архитектуры. Например, если завтра вы подключите второй PSP, вам не нужно переписывать ChatGPT App: достаточно адаптировать Delegated Payment‑слой на своём backend’е. А если появится вторая 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 (через ваш backend) чтобы подобрать подходящие SKU.
2. При решении «покупаем» ChatGPT создаёт checkout_session через ваш /checkout_sessions по Agentic Checkout Spec.
3. Во время Instant Checkout ChatGPT запрашивает у PSP делегированный платёжный токен на конкретную сумму и мерчанта.
4. Этот токен передаётся в POST /checkout_sessions/{id}/complete, ваш backend создаёт платёж у 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‑backend, который умеет работать с checkout_sessions;
• подключим Delegated Payment через Stripe Shared Payment Token;
• научим App показывать пользователю, что он может не только подобрать, но и купить подарок прямо в чате.

Чтобы это всё не выглядело как «чёрная магия», давайте добавим в наш код небольшой технический слой, который явно моделирует роли и шаги 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, ваш мерчантский backend, платёжный провайдер или сам пользователь. Можно опираться на диаграмму выше и на массив digitalGiftFlow, но не обязательно совпадать с ним один в один.

Например, вы можете начать со шага, где ChatGPT интерпретирует запрос и уточняет у пользователя детали (цифровой сертификат, регион получателя, кому именно подарок). Затем шаг, где ваш backend по 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("Planned AI-commerce flow:", 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 внутрь backend’а и общаться с ним так же, как с любым REST‑API, забывая, что платёжный слой живёт по своим правилам (PCI, фрод, чарджбэки, лимиты). В ACP‑подходе не случайно выделена отдельная Delegated Payment Spec: платформа агента общается с PSP на своём уровне, получает SPT‑токен и передаёт его вам, а вы уже создаёте платёж. Если пытаться обойти эту схему и напрямую принимать реквизиты карт в App, вы быстро выстрелите себе в ногу требованиями compliance.

Ошибка №4: воспринимать product feed как «настройку маркетинга», а не как API для LLM.
Многие приходят с бэкграундом Google Shopping и думают о фиде как о чём‑то, что важнее для рекламного кабинета, чем для кода. В мире AI‑commerce фид — это, по сути, база знаний вашего ассортимента для модели. Если там битые ссылки на изображения, несогласованные атрибуты, странные единицы измерения и маркетинговые преувеличения вместо фактов, модель будет предлагать не то, что вам нужно, а конверсия уйдёт в минус.

Ошибка №5: пытаться внедрить Instant Checkout «в один шаг».
Соблазн велик: «давайте сразу включим enable_checkout, пусть пользователи покупают из чата». Но без хорошего discovery (качественный фид), без надёжного checkout‑backend’а и без продуманной интеграции с PSP вы рискуете получить хрупкую систему, где половина заказов зависает посередине. Гораздо разумнее идти по ступенькам, которые предлагает OpenAI: сначала качественный Product Feed, затем отладка ACP‑эндпоинтов, затем Delegated Payment и только потом включение Instant Checkout в боевом режиме.