JavaRush /Курси /ChatGPT Apps /Інтеграція Product Feed, Merchant і ACP в одному проєкті

Інтеграція Product Feed, Merchant і ACP в одному проєкті

ChatGPT Apps

Рівень 14 , Лекція 4

Відкрита

1. Усе вже працює окремо…

На цьому етапі ви вже розумієте, як вибудовується commerce‑потік навколо ChatGPT. У продавця є продуктовий фід, реалізовано ACP‑ендпоїнти (/checkout_sessions та інші), Instant Checkout проводить оплату, а бекенд отримує вебхуки й створює замовлення. Усе це може працювати навіть без вашого ChatGPT App: достатньо Product Feed + ACP‑бекенда.

Окремо ви вже вмієте:

збирати Product Feed за специфікацією OpenAI;
проєктувати й реалізовувати Agentic Checkout та Delegated Payment;
створювати ChatGPT App із віджетом і MCP‑інструментами для пошуку подарунків.

Окремо все виглядає чудово, а разом легко перетворюється на «зоопарк сервісів». Віджет живе своїм життям, MCP‑сервер — своїм, ACP‑бекенд — іще своїм, а логіка замовлень і вебхуків — окремо. Варто лише спробувати налагодити реальну покупку або виправити якийсь химерний баг — і ви раптом бачите, що цілісної картини до пуття не має ніхто.

Мета цієї лекції — вивести вас із цього стану й дати цілісну, але водночас практичну архітектуру. Розберемо, як саме Product Feed пов’язаний з ACP‑бекендом, як вони обидва співвідносяться з ChatGPT App і віджетом, де в цій схемі з’являється платіжний провайдер і як усе це загорнути в компоненти, зрозумілі команді: сервіси, бази даних, API.

Водночас ми постійно наголошуватимемо: що є жорстким стандартом (SPEC), а що — лише нашим архітектурним вибором для GiftGenius.

Інсайт: ChatGPT — це безкоштовний Google

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

З погляду бізнесу це означає просту річ: ChatGPT стає безкоштовним «рекламним каналом» для ваших товарів, якщо ви під’єднали Product Feed і ACP‑бекенд. Модель пропонуватиме ваші позиції, якщо вони добре закривають запит користувача, і вам не потрібно окремо платити за покази або кліки.

З цього випливають два практичні висновки:

Вікно можливостей тимчасово дуже дешеве. Зараз конкуренція в ACP‑екосистемі невисока, і вийти до верхніх цінових сегментів можна без звичних рекламних бюджетів. Це рідкісна ситуація, коли трафік із високою конверсією в дорогих продуктах (авіація, нерухомість, преміальні товари, страхування) може нічого не коштувати.
Варто починати з наймаржинальніших вертикалей. Якщо у вас є доступ до категорій із високим середнім чеком, їх раціонально підключати першими:
- продаж / оренда літаків, яхт, вілл;
- продаж / оренда будинків і преміальної нерухомості;
- ювелірні вироби, дорогі годинники, страхові продукти та послуги.

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

2. Еталонна архітектура GiftGenius: у загальних рисах

Почнемо з погляду згори. Згадаємо загальну картинку з попередніх модулів: користувач пише в ChatGPT, модель викликає ваші інструменти, а commerce‑шар живе в окремому бекенді.

Сформулюємо основні блоки GiftGenius.

По-перше, ChatGPT UI і модель GPT: вони ведуть діалог із користувачем і за потреби під’єднують застосунок GiftGenius (або взагалі працюють без App — лише через Product Feed).

По-друге, віджет GiftGenius (Next.js + Apps SDK). Він показує картки подарунків і, за потреби, прогрес checkout. Віджет живе в пісочниці window.openai і не знає нічого про реальні платіжні реквізити.

По-третє, MCP‑шар: він дає моделі інструменти для пошуку подарунків за каталогом (Product Feed) і, можливо, для читання історії замовлень.

По-четверте, commerce / ACP‑бекенд, який:

читає Product Feed як джерело правди про товари та SKU;
реалізує Agentic Checkout Spec (/checkout_sessions, вебхуки, статуси);
взаємодіє з платіжним провайдером (наприклад, Stripe) за Delegated Payment Spec.

По-п’яте, бази даних каталогу (якщо фід формується з БД), замовлень і допоміжних структур (користувачі, налаштування).

І нарешті, платіжний провайдер: він зберігає й обробляє платіжні дані, а також надсилає вебхуки про результати платежів.

Схематично це можна намалювати так:

graph LR
  U[Користувач у ChatGPT] --> GPT[GPT‑модель]
  GPT -->|відображає| W[GiftGenius Widget
Next.js + Apps SDK]
  GPT -->|інструменти MCP| MCP[MCP‑сервер
пошук подарунків]
  MCP --> PF["Product Feed
(БД/JSON)"]
  GPT -->|ACP HTTP| ACP[GiftGenius Commerce Backend
Agentic Checkout]
  ACP --> ORDERS[База замовлень]
  ACP --> PSP["Платіжний провайдер
(Stripe та ін.)"]
  PSP --> ACP
  ACP -->|webhooks/події| GPT

Ця діаграма описує архітектуру GiftGenius як приклад реалізації. Формат Product Feed, контракт /checkout_sessions і протокол Delegated Payment залишаються частиною стандарту ACP; розташування сервісів, схеми БД і поділ на процеси — ваш архітектурний вибір.

3. Як Product Feed, ACP і віджет пов’язані логічно

Щоб не губитися у стрілках, зафіксуємо просту, але принципову думку: у вас є рівно одне джерело правди про товари.

У світі GiftGenius нехай це буде таблиця products + skus в PostgreSQL. З неї ви:

Формуєте Product Feed за специфікацією OpenAI (безпосередньо або через вивантаження).
Будуєте пошуковий індекс для MCP‑інструментів (наприклад, search_gifts).
Валідуєте запити ACP‑бекенда — перевіряєте, що вхідний sku_id справді існує та має коректні ціну й валюту.

Таким чином, MCP‑пошук і ACP‑checkout дивляться на одні й ті самі дані, а віджет лише показує результати, які надходять або з MCP‑інструментів, або опосередковано з ACP (наприклад, інформацію про замовлення).

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

4. Моделюємо дані: від Product Feed до замовлення

Почнемо з простих TypeScript‑типів, які житимуть у вашому репозиторії GiftGenius (наприклад, у src/domain/commerce.ts). Ці типи не є буквальною копією специфікацій, але передають їхні ключові ідеї у зручній для застосунку формі.

// src/domain/commerce.ts

export interface ProductSku {
  id: string;          // стабільний ідентифікатор SKU (збігається з Product Feed)
  title: string;       // назва, зрозуміла людині
  priceCents: number;  // ціна в центах/копійках
  currency: string;    // ISO-код, наприклад "usd"
}

export type CheckoutStatus = "pending" | "succeeded" | "failed";

export interface CheckoutSession {
  id: string;
  skuId: string;
  totalCents: number;
  currency: string;
  status: CheckoutStatus;
}

Тут ми явно додаємо в CheckoutSession посилання на skuId і фіксовані валюту та суму. Це наша внутрішня модель; реальна Agentic Checkout Spec багатша, але базова ідея та сама: сесія — це «скільки, за що і в якому статусі».

Далі потрібен тип замовлення:

export interface Order {
  id: string;
  userId: string;
  skuId: string;
  totalCents: number;
  currency: string;
  checkoutSessionId: string;
  status: "awaiting_payment" | "paid" | "canceled" | "refunded";
}

Тут відчувається вплив загальних сутностей із попереднього модуля: intent, checkout_session, order. У нашому навчальному проєкті ми трохи об’єднуємо intent і order, щоб не множити сутності, але зберігаємо зв’язок із checkoutSessionId.

5. Як віджет GiftGenius «підглядає» у commerce‑світ

Важливий момент: віджет сам по собі не звертається до платіжної системи й навіть не зобов’язаний знати деталі ACP. Його роль — показувати користувачу стан, який обчислено й зафіксовано на бекенді.

Найпростіший корисний сценарій: після успішної покупки користувач може повернутися в чат і запитати: «Покажи мої останні замовлення в GiftGenius». GPT викличе MCP‑інструмент на кшталт get_user_orders, який звернеться до вашого бекенда, а віджет покаже список.

Уявімо Next.js API‑маршрут, який повертає останні замовлення (спрощено):

// app/api/orders/recent/route.ts

import { NextRequest, NextResponse } from "next/server";
import { getRecentOrdersForUser } from "@/lib/orders";

export async function GET(req: NextRequest) {
  const userId = req.headers.get("x-giftgenius-user-id")!;
  const orders = await getRecentOrdersForUser(userId);
  return NextResponse.json({ orders });
}

Функція getRecentOrdersForUser уже живе у вашому commerce‑шарі, працює з БД і знає про структуру замовлень. Віджет, своєю чергою, може викликати цей маршрут через window.fetch (ми вже робили так у попередніх модулях) і показувати картки покупок.

Комбінація «MCP‑інструмент → ваш API → БД замовлень → віджет» дає користувачеві відчуття, що в App є «пам’ять» про покупки, хоча насправді віджет просто відображає стан бекенда.

6. Проста реалізація ACP‑ендпоїнта у стилі Next.js

Тепер окреслимо, як може виглядати навчальна реалізація одного з ключових ACP‑ендпоїнтів — створення checkout_session. За специфікацією там доволі багатий контракт, але для курсу можна залишити лише суть: приходить skuId, ми перевіряємо його за фідом/БД, створюємо сесію і повертаємо її ID та суму.

Нехай у нас є маршрут POST /api/checkout-sessions:

// app/api/checkout-sessions/route.ts

import { NextRequest, NextResponse } from "next/server";
import { findSkuById, createCheckoutSession } from "@/lib/checkout";

export async function POST(req: NextRequest) {
  const body = await req.json();          // { skuId: string }
  const sku = await findSkuById(body.skuId);

  if (!sku) {
    return NextResponse.json(
      { error: "SKU не знайдено" },
      { status: 400 },
    );
  }

  const session = await createCheckoutSession(sku);
  return NextResponse.json({ session });
}

Тут є кілька важливих моментів.

По-перше, саме тут commerce‑шар звіряється з Product Feed/БД: findSkuById зобов’язаний працювати з тим самим джерелом, з якого формується фід. Ми не довіряємо нічому, що прийшло «з повітря» — ані від GPT, ані від віджета.

По-друге, ми повертаємо лише те, що потрібно ChatGPT/ACP‑клієнту: ID сесії, суму, валюту і статус (за замовчуванням pending або not_ready_for_payment, залежно від обраної термінології). У реальному ACP полів більше: зокрема інформація про доступні методи оплати й fulfillment. Але навчальний приклад зосереджується на первинному створенні сесії.

По-третє, такий маршрут зручно покривати контрактними тестами. Якщо завтра структура Product Feed зміниться, тести на findSkuById і createCheckoutSession мають це спіймати раніше, ніж ChatGPT почне показувати користувачам дивні помилки.

7. Зв’язок ACP‑сесій і платіжного провайдера

Досі ми жодним чином не торкалися платіжного провайдера. У реальній інтеграції все відбувається приблизно так (спрощений сценарій).

Спочатку ChatGPT (через ACP) викликає ваш POST /checkout_sessions. Ваш бекенд створює локальну сесію у своїй БД. Коли користувач підтверджує оплату в UI Instant Checkout, платформа запитує у PSP делегований платіжний токен (Shared Payment Token) для конкретного продавця й суми. Цей токен надходить до вас у запиті complete (або в аналогічному виклику за Delegated Payment Spec).

Після цього ви створюєте платіж у PSP, використовуючи токен, без доступу до реальних платіжних даних. PSP надсилає вебхук про результат; ви оновлюєте статус замовлення та/або checkout‑сесії.

У нашому навчальному коді ми можемо обмежитися імітацією цього кроку. Наприклад, функція completeCheckoutSession може виглядати так:

// src/lib/checkout.ts

export async function completeCheckoutSession(sessionId: string, spt: string) {
  // Тут насправді викликається PSP API з делегованим токеном (SPT)
  const paymentOk = await mockChargeWithToken(spt);

  return paymentOk
    ? { status: "succeeded" as const }
    : { status: "failed" as const };
}

Виклик PSP і використання Shared Payment Token — це частина стандарту Delegated Payment, а функція mockChargeWithToken — наш навчальний архітектурний шар, який імітує цю специфіку.

8. Наскрізний потік GiftGenius: від запиту до оплаченого подарунка

Тепер зберемо все разом у вигляді послідовності кроків. Це та сама «робоча» історія GiftGenius, заради якої ми поєднуємо всі шари. Важливо не змішувати два різні світи, тож розглянемо їх окремо.

Схема A: без App, лише Product Feed + ACP

У цьому сценарії у вас є Product Feed і ACP‑бекенд, але немає ChatGPT App і віджета. Це класичний Instant Checkout‑продавець.

Користувач пише в ChatGPT щось на кшталт: «Підбери цифровий подарунок до 50 $». GPT використовує ваш Product Feed, щоб знайти відповідні SKU, і показує їх у своєму нативному UI у вигляді шопінг‑карток. Тут іще немає жодного вашого React‑коду — картки повністю малює ChatGPT.

Користувач натискає кнопку «Buy» на одній із таких карток. Цю дію обробляє сам ChatGPT. Платформа:

Формує line_items на основі Product Feed.
Викликає ваш POST /checkout_sessions за Agentic Checkout Spec.
Показує користувачу UI Instant Checkout (спосіб оплати, адреса тощо).
Після підтвердження отримує Shared Payment Token від PSP і викликає ваш .../complete.
Отримує від вас фінальний стан checkout_session і, за потреби, чекає вебхука про замовлення.

З погляду вашого коду тут працюють лише ACP‑ендпоїнти та Product Feed. Жодних Apps SDK, window.openai і віджета взагалі не існує. І це абсолютно коректний, «чистий» сценарій ACP‑продавця.

Схема B: з ChatGPT App і віджетом GiftGenius

Тепер додамо зверху ChatGPT App і віджет GiftGenius. Product Feed і ACP‑бекенд нікуди не діваються: вони, як і раніше, забезпечують пошук та оплату. Різниця в тому, що з’являється власний UI і логіка кроків усередині App.

Уявімо діалог: користувач пише в ChatGPT: «Підбери подарунок для мами до 50 $». GPT розуміє, що це commerce‑запит, і пропонує використати GiftGenius‑App. Віджет ставить кілька уточнювальних запитань: вік, інтереси, країна. Після цього GPT викликає ваш MCP‑інструмент search_gifts із фільтрами, а MCP‑сервер звертається до каталогу (БД або підготовленого індексу), знаходить кілька відповідних SKU і повертає їх у структурованому вигляді.

GPT передає ці дані у віджет, і віджет показує свої фірмові картки подарунків (React‑компоненти, каруселі тощо). Це вже ваш дизайн і ваш UX, а не стандартний шопінг‑UI ChatGPT.

Коли користувач натискає у віджеті кнопку «Купити», відбувається не те саме, що у схемі A. Цю дію обробляє віджет:

Віджет розуміє, який SKU обрав користувач.
Через свій API (наприклад, POST /api/checkout-sessions) звертається до вашого бекенда, щоб створити checkout_session (або отримати ID уже підготовленої сесії).
Потім віджет викликає рантайм‑метод Apps SDK на кшталт:
```
// Актуальну сигнатуру методу дивіться в документації Apps SDK
await window.openai.requestCheckout({
  checkoutSessionId: session.id, ...
});
```
Цей виклик — ініціатива віджета. Для ChatGPT це сигнал: «Час відкрити Instant Checkout для ось цієї checkout_session».

Далі платформа ChatGPT працює дуже схоже на схему A, але за лаштунками:

показує користувачу нативний Instant Checkout UI;
отримує Shared Payment Token у PSP;
викликає ваш ACP‑ендпоїнт завершення сесії (.../complete);
бере участь в отриманні й обробці вебхуків від вашого бекенда.

Тобто у схемі B віджет запускає checkout через Apps SDK, а виклики по ACP (створення/завершення checkout_session) відбуваються або до цього (коли ви самі створюєте сесію в бекенді), або вже після requestCheckout, але завжди на серверному боці.

Віджет при цьому може паралельно показувати кроки «Оформлення покупки», статуси та попередній перегляд замовлення, спираючись на ваш API (/api/orders/...) і MCP‑інструменти.

Якщо зобразити схему B діаграмою, вийде щось на кшталт:

sequenceDiagram
  participant User as Користувач
  participant GPT as ChatGPT / GPT
  participant W as GiftGenius Widget
  participant MCP as MCP‑сервер
  participant ACP as Commerce Backend
  participant PSP as Платіжний провайдер

  User->>GPT: "Підбери подарунок до $50"
  GPT->>MCP: search_gifts(...)
  MCP-->>GPT: список SKU
  GPT->>W: дані для рендеру карток
  User->>W: клік «Купити»
  W->>ACP: POST /api/checkout-sessions (skuId)
  ACP-->>W: checkout_session (id, сума, валюта)
  W->>GPT: window.openai.requestCheckout({ checkoutSessionId })
  GPT->>User: UI Instant Checkout
  User->>GPT: підтвердження оплати
  GPT->>PSP: запит Shared Payment Token
  PSP-->>GPT: SPT
  GPT->>ACP: complete(sessionId, SPT)
  ACP->>PSP: charge(SPT)
  PSP-->>ACP: результат платежу
  ACP->>GPT: статус замовлення
  GPT->>User: повідомлення про успішну/неуспішну оплату

Ключова відмінність від схеми A:

У схемі A картки й кнопку «Buy» малює сам ChatGPT, і саме він ініціює виклик ACP напряму.
У схемі B картки й кнопку «Купити» малює ваш віджет, і саме він викликає window.openai.requestCheckout(...). А вже після цього ChatGPT «під капотом» розмовляє з вашим ACP‑бекендом і PSP.

Інсайт

У своєму SDK команда ChatGPT зазначила, що незабаром у застосунках з’явиться монетизація. Так воно і є: віджетам уже доступні кілька ще не анонсованих методів. І найцікавіший із них — це requestCheckout().

Ось як виглядає його виклик:

window.openai.requestCheckout({
  id: "checkout_session_123",

  payment_provider: {
    merchant_id: "stripe",
    supported_payment_methods: ["card"]
  },
   ...
}

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

9. Міні‑реалізація для курсу: монолітний бекенд

У модулях про архітектуру вже порушували питання: робити все одним сервісом чи одразу ділити на MCP‑сервер, commerce‑бекенд і окремий сервіс для платіжної інтеграції. Для освітніх цілей найчастіше достатньо «майже моноліту»: один репозиторій, одне розгортання, але логіка акуратно рознесена по шарах.

Навчальний варіант GiftGenius може виглядати так: Next.js‑застосунок, у якому:

віджет живе в app/widget/page.tsx;
ACP‑ендпоїнти — в app/api/checkout-sessions і сусідніх маршрутах;
інструменти MCP — в app/api/mcp/route.ts або в окремій папці;
робота із замовленнями — у src/lib/orders.ts, src/lib/checkout.ts і близьких модулях.

Фізично це один сервер (особливо на етапі dev/staging), але логічно ви мислите вже в термінах трьох ролей: UI (віджет), MCP (інструменти/ресурси для GPT) і ACP (commerce‑бекенд).

Пізніше, у модулях про продакшен, ви побачите, як цей «моноліт» розноситься по кількох сервісах і середовищах, а перед ними з’являється MCP Gateway. Але на рівні модуля 14 такий «моноліт із правильними шарами» вже дає дуже правдоподібну архітектуру.

10. Практичне завдання: ваша архітектура навколо ACP

Щоб усе описане вище не лишилося теорією, варто вже зараз приміряти це до свого домену. У межах лекції можна зробити дві міні-вправи.

По-перше, оберіть власний сценарій: SaaS‑підписка, бронювання, доставка їжі, онлайн‑курси — будь‑який випадок, де є продукт/послуга, ціна і зручний checkout. Згадайте фазну модель: discovery → decision → checkout → post‑payment.

По-друге, спираючись на архітектуру GiftGenius, опишіть у вільній формі: як ви будуватимете Product Feed (де живуть SKU і ціни, хто їх оновлює), де реалізуєте ACP‑контракт (окремий сервіс чи частина наявного бекенда), як підключите платіжного провайдера і як ваш віджет (якщо він є) взаємодіятиме з усім цим через MCP і Apps SDK.

Корисно прямо проговорити, чи використовуватиме ваш проєкт лише схему A (Instant Checkout без App), лише схему B (App + віджет), чи обидва сценарії одночасно. Навіть такий текстовий нарис архітектури суттєво знижує ризик несподіванок на етапі реальної інтеграції.

11. Типові помилки під час інтеграції Product Feed, ACP і віджета

Помилка № 1: два різні каталоги — один для пошуку, інший для checkout.
Іноді команда спочатку розгортає швидкий «пошуковий» фід для GPT (наприклад, невеликий JSON), а потім окремо розробляє commerce‑БД для замовлень. Якщо їх не пов’язати спільними ID і спільною логікою оновлення, GPT може пропонувати користувачу товари, які вже не можна купити, або за старою ціною. Правильний підхід — одне джерело правди, з якого формуються і Product Feed, і внутрішні таблиці для ACP‑ендпоїнтів.

Помилка № 2: довіра даним, що прийшли від GPT або віджета.
Коли в checkout_session надходить skuId і ціна, дуже хочеться просто повірити цим значенням: «ну GPT же не брехатиме». Але модель легко може щось «вигадати» або переплутати SKU, а користувач — спробувати зламати запит. Якщо не звіряти вхідні дані з Product Feed/БД, ви ризикуєте продавати не те й не за ті гроші. Будь‑який ACP‑ендпоїнт має починатися з валідації за первинним сховищем каталогу.

Помилка № 3: змішування ролей віджета і commerce‑бекенда.
Іноді розробники за звичкою з фронтенда одразу викликають платіжний SDK, створюють сесії в Stripe і загалом працюють так, ніби це звичайний сайт. У контексті ChatGPT Apps це ламає модель безпеки й суперечить ACP: платіжний потік має проходити через ChatGPT і ваш commerce‑бекенд, а віджет — лише відображати стан і надсилати події (на кшталт requestCheckout). Якщо віджет знає занадто багато про платіжний контур, ви отримуєте і зайву складність, і підвищені ризики.

Помилка № 4: надмірне спрощення ACP‑контракту.
У навчальному прикладі ми свідомо залишаємо тільки skuId, суму і статус, щоб не тонути в деталях. Проблема починається, коли такий «демо‑контракт» непомітно переноситься в продакшен. Ви раптом виявляєте, що не вистачає полів для адреси, податків, методів доставки, промокодів — і починаєте додавати їх хаотично. Краще відразу проєктувати внутрішні моделі із запасом під реальні сценарії, навіть якщо частина полів перший час буде невикористаною.

Помилка № 5: відсутність зв’язку між замовленнями і користувачами.
У демо легко обмежитися orderId і skuId, не думаючи про те, як користувач повернеться за тиждень і запитає: «Покажи мої покупки». Якщо від самого початку не закласти userId (або інший стабільний ідентифікатор) у замовлення і checkout‑сесію, пізніше доведеться робити міграції та вигадувати складні обхідні рішення. Commerce‑архітектура навколо ChatGPT майже завжди передбачає, що GPT зможе пов’язувати поточний діалог з історією замовлень користувача — це варто врахувати заздалегідь.

Помилка № 6: недооцінка важливості вебхуків та ідемпотентності.
У лекції ми про вебхуки лише говорили, а глибше розбиратимете їх у наступних модулях. Легко подумати: «ну вебхук прийде один раз — оновимо замовлення, і все». На практиці платіжні системи люблять повторно надсилати події, а мережа — втрачати відповіді. Якщо не проєктувати замовлення і checkout‑сесії як ідемпотентні структури (за checkoutSessionId або paymentId), можна отримати подвійні списання, дублікати замовлень і неочевидні розбіжності між PSP і вашою БД.

Помилка № 7: ігнорування обмежень і політик у Product Feed.
У погоні за швидким демо‑фідом легко забути про вікові обмеження, доступність за країнами, заборонені категорії та інші «дрібниці». Потім з’ясовується, що GPT радісно пропонує користувачу товар, який йому не можна продати в його регіоні або з огляду на вік. Поля, пов’язані з політикою й обмеженнями, потрібно проєктувати і заповнювати від самого початку, навіть якщо ви поки торгуєте лише безпечними цифровими подарунками.

Попередня Попередня лекція

Наступна Наступна лекція

Коментарі

ЩОБ ПОДИВИТИСЯ ВСІ КОМЕНТАРІ АБО ЗАЛИШИТИ КОМЕНТАР,
ПЕРЕЙДІТЬ В ПОВНУ ВЕРСІЮ