Mapa świata AI‑commerce i rola OpenAI

1. Czym właściwie jest AI‑commerce

Jeśli klasyczny e‑commerce to historia „wszedłem na stronę — otworzyłem katalog — dodałem do koszyka — przeciągnąłem się przez trzy formularze”, to AI‑commerce to sytuacja, w której głównym interfejsem staje się dialog z ChatGPT. Użytkownik formułuje zadanie językiem naturalnym, a agent wewnątrz ChatGPT przejmuje rolę konsultanta, merchandisera i częściowo product managera.

Zapytania wyglądają nie jak „category=skarpetki&price_max=20”, lecz jak „dobierz zabawny, ale nie zbyt cringowy prezent dla kolegi do 20 dolarów, który można wysłać e‑mailem”. Agent interpretuje zadanie, zadaje pytania doprecyzowujące, przegląda katalog produktów, wyjaśnia plusy i minusy opcji, a następnie prowadzi użytkownika do zakupu — i to wszystko bez tego, aby użytkownik w ogóle widział „koszyk” jako osobną stronę.

Z punktu widzenia architektury ChatGPT App w tym momencie zmienia się z „inteligentnego katalogu prezentów” w aplikację commerce, która potrafi:

1. Rozumieć intencję użytkownika i ograniczenia (budżet, typ prezentu, kraj, produkt cyfrowy/fizyczny).
2. Dobierać konkretne SKU z product feed i wyjaśniać wybór.
3. Zainicjować finalizację zakupu poprzez ustandaryzowany protokół ACP (Agentic Commerce Protocol).

Idea AI‑commerce polega na tym, że „catalog + checkout” przestają być osobną stroną, a stają się logicznym przedłużeniem dialogu, który użytkownik już prowadzi z GPT.

2. Klasyczny e‑commerce kontra AI‑commerce

Aby lepiej poczuć różnicę, wygodnie jest położyć oba podejścia obok siebie. Poniżej — uproszczona tabela, która nie rości sobie pretensji do pełnego pokrycia, ale dobrze podkreśla zmianę paradygmatu.

Praktyczna konsekwencja: w AI‑commerce uwaga przesuwa się z wizualnego projektu „katalogu i koszyka” na strukturę i jakość danych, a także na formalny protokół interakcji między ChatGPT, waszym backendem i dostawcą płatności. Product feed i endpointy ACP stają się równie ważnym „UI” jak sam widżet.

Jeśli w klasycznym sklepie można poprawić część UX w przeglądarce, to w AI‑commerce model opiera się niemal w całości na danych i schematach, które jej dostarczyliście: od opisu produktu po statusy sesji checkout.

3. Elementy składowe OpenAI Commerce

OpenAI nie oferuje „magicznego systemu płatności GPTPay”, który wszystko zrobi za was. Zamiast tego jest zestaw specyfikacji i przewodników, które opisują, jak prawidłowo podłączać istniejących merchantów i dostawców płatności do świata ChatGPT. Z tych dokumentów dla nas szczególnie ważne są cztery klocki.

Po pierwsze, Product Feed Specification. To oficjalny format, w którym sprzedawca opisuje swój katalog produktów: id, title, description, cena, waluta, dostępność, obrazy itd. Feed pełni rolę „ustrukturyzowanego źródła prawdy”, które OpenAI waliduje, indeksuje i wykorzystuje do wyszukiwania, rankingowania i checkoutu w ChatGPT.

Po drugie, Agentic Checkout Specification. To kontrakt REST do pracy z encją checkout_session: API opisuje, jak utworzyć sesję płatności, zaktualizować ją (np. przy zmianie adresu lub wariantu dostawy) i zakończyć, a także jakie pola powinien zwrócić backend (kwoty, podatki, opcje fulfillmentu, linki do polityki zwrotów itp.).

Po trzecie, Delegated Payment Specification. To protokół, według którego platforma agenta (ChatGPT) otrzymuje delegowany token płatniczy od dostawcy płatności (np. Stripe Shared Payment Token) i przekazuje go waszemu backendowi, nie ujawniając samych danych płatniczych. Sam token jest ograniczony kwotowo, czasowo i innymi parametrami i jest używany przez wasz backend do utworzenia rzeczywistej płatności u PSP.

I wreszcie, Instant Checkout w ChatGPT — to warstwa UX nad tymi specyfikacjami. W czacie pojawia się kompaktowy interfejs checkout: wybrany produkt, cena, adres, metoda płatności. Pod spodem opiera się on na Product Feed, wywołuje wasze /checkout_sessions zgodnie z Agentic Checkout Spec i używa Delegated Payment, aby przeprowadzić transakcję u PSP.

Dobra wiadomość jest taka, że te wszystkie elementy to nie „tajne API ChatGPT”, lecz otwarte specyfikacje ACP (Agentic Commerce Protocol). To znaczy, że ten sam backend może teoretycznie działać także z innymi platformami AI, jeśli również wspierają ACP.

4. Role i granice odpowiedzialności

Tu zaczyna się najciekawsze: gdy w systemie pojawiają się pieniądze, regulatorzy i prawnicy niespodziewanie stają się waszymi najlepszymi przyjaciółmi. Aby się nie pogubić, warto wyraźnie rozdzielać role.

Najważniejszą rolę ma platforma agenta, w naszym przypadku — ChatGPT. To ona zarządza doświadczeniem użytkownika: czat, widżety, Instant Checkout UI. Platforma inicjuje przepływ commerce, wybiera produkty z Product Feed, wywołuje wasze endpointy ACP i pokazuje użytkownikowi wynik. Jednocześnie ChatGPT nie staje się ani właścicielem towaru, ani dostawcą płatności i nie przechowuje waszych danych produktowych jako „własnego katalogu” — używa dokładnie tego feedu, który mu przekazaliście.

W drugiej roli — merchant (seller, merchant‑of‑record). To właściciel towarów lub usług. Merchant odpowiada za sam product feed (struktura, jakość, aktualność cen i dostępności), za poprawną implementację endpointów ACP (/checkout_sessions, webhooki), za tworzenie i przechowywanie zamówień, za dostawę, wsparcie i zwroty. Dokumentacja ACP podkreśla, że to właśnie merchant pozostaje sprzedawcą zapisu w sensie prawnym, a nie platforma agenta.

Trzecia rola — dostawca płatności (PSP), np. Stripe. PSP odpowiada za przetwarzanie płatności, zgodność z PCI DSS i innymi wymaganiami, przechowywanie danych płatniczych, walkę z fraudem i chargebackami. W kontekście Delegated Payment PSP wydaje platformie agenta specjalny token (SPT), który następnie jest używany przez wasz serwer do utworzenia rzeczywistej płatności (np. PaymentIntent w Stripe).

Czwarta i najważniejsza rola — użytkownik. Formułuje on zadanie, podejmuje ostateczną decyzję o zakupie, wyraża zgodę na płatność i, w idealnym świecie, czyta Terms / Privacy Policy, które uczciwie pokazujecie w UI checkout. Product feed może zawierać linki do tych dokumentów i polityki zwrotów, aby zwiększyć zaufanie i przejrzystość.

Dla wygody można to zebrać w małej tabeli:

Rozdzielenie zakresów odpowiedzialności jest ważne nie tylko dla prawników, ale i dla architektury. Na przykład, jeśli jutro podłączycie drugiego PSP, nie musicie przepisywać ChatGPT App: wystarczy dostosować warstwę Delegated Payment w swoim backendzie. A jeśli pojawi się druga platforma AI, która również rozumie ACP, będziecie mogli ponownie wykorzystać zarówno product feed, jak i endpointy checkoutu.

5. Jak wygląda scenariusz zakupu „wszystko w dialogu”

Teraz złóżmy wszystko razem i zobaczmy, jak wygląda end‑to‑end scenariusz zakupu cyfrowego prezentu w ChatGPT z punktu widzenia architektury. To uproszczony scenariusz, ale oddaje sedno.

sequenceDiagram
  participant U as Użytkownik
  participant C as ChatGPT
  participant G as GiftGenius App
  participant B as Backend merchanta
  participant P as PSP (Stripe)

  U->>C: "Kup cyfrowy prezent do $50"
  C->>G: callTool(find_gifts, budget<=50)
  G->>B: GET /catalog?budget_lte=50
  B-->>G: Lista pasujących SKU
  G-->>C: Propozycje prezentów + metadane
  C-->>U: Wyjaśnia wybór, proponuje opcje
  U->>C: "Biorę ten"
  C->>B: POST /checkout_sessions (sku, price...)
  C->>P: Zażądać tokenu płatniczego (SPT)
  C->>B: POST /checkout_sessions/{id}/complete (token)
  B->>P: Zrealizować płatność
  B-->>C: Webhook o utworzeniu zamówienia
  C-->>U: Potwierdzenie zakupu

W suchym języku ACP dzieje się tu następujące:

1. Agent korzysta z Product Feed (przez wasz backend), aby dobrać pasujące SKU.
2. Gdy zapada decyzja „kupujemy”, ChatGPT tworzy checkout_session przez wasz /checkout_sessions zgodnie z Agentic Checkout Spec.
3. W trakcie Instant Checkout ChatGPT prosi PSP o delegowany token płatniczy na konkretną kwotę i merchanta.
4. Token jest przekazywany do POST /checkout_sessions/{id}/complete, wasz backend tworzy płatność u PSP i formuje zamówienie.
5. Gdy zamówienie jest gotowe, wasz serwer powiadamia OpenAI przez webhook, po czym użytkownik widzi finalne potwierdzenie.

W tym wykładzie ważniejsze od zapamiętania nazw endpointów jest dostrzeżenie struktury: feed → dobór SKU → checkout_session → płatność → zamówienie → webhook. W kolejnych wykładach będziemy rozbierać każdy element osobno, w tym pola feedu, pola sesji checkout i format delegowanych płatności.

6. GiftGenius: jak nasza aplikacja wpisuje się w AI‑commerce

Do tej pory GiftGenius pełnił rolę „asystenta doboru prezentów”. Potrafił:

• pytać użytkownika, dla kogo i z jakiej okazji potrzebny jest prezent;
• korzystać z narzędzi MCP do wyszukiwania po własnym katalogu;
• pokazywać karty propozycji w widżecie i wysyłać przyciski follow‑up na czat.

Z perspektywy commerce był to „inteligentny discovery” bez realnego zakupu. W świecie OpenAI commerce taki tryb odpowiada feedowi, w którym dla SKU ustawiono enable_search = true, ale enable_checkout = false: produkty można znajdować i omawiać, ale Instant Checkout jest dla nich wyłączony.

W module AI‑commerce stopniowo przekształcimy GiftGenius w w pełni zintegrowanego merchanta:

• dodamy ustrukturyzowany Product Feed zgodny ze specyfikacją OpenAI;
• zaprojektujemy backend ACP, który potrafi pracować z checkout_sessions;
• podłączymy Delegated Payment przez Stripe Shared Payment Token;
• nauczymy aplikację pokazywać użytkownikowi, że może nie tylko dobrać, ale i kupić prezent prosto w czacie.

Aby to wszystko nie wyglądało jak „czarna magia”, dodajmy do naszego kodu niewielką warstwę techniczną, która wprost modeluje role i kroki przepływu commerce. Przyda się to i do logów, i do wewnętrznych testów.

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

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

Te typy pomagają mentalnie oddzielić „kto co robi” nawet na poziomie TypeScript. Możemy używać ich np. w testach lub w debugowym UI wewnątrz widżetu.

Niewielki przykład tablicy kroków dla scenariusza „cyfrowy prezent do $50”:

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

export const digitalGiftFlow: CommerceStep[] = [
  { id: "intent", role: "user", description: "Sformułować zapytanie i budżet" },
  { id: "search", role: "chatgpt", description: "Dobrać SKU z Product Feed" },
  { id: "checkout", role: "merchant", description: "Utworzyć checkout_session" },
  { id: "payment", role: "psp", description: "Zrealizować płatność tokenem" }
];

Taki kod na razie z nikim nie rozmawia po sieci, ale już tworzy użyteczną „oś współrzędnych”, wokół której będziemy rozbudowywać realny kod ACP w kolejnych wykładach.

7. Mini‑zadanie: rozłóż przepływ „Kup mi cyfrowy prezent do $50”

Na koniec wykładu warto ręcznie przerobić to, o czym właśnie mówiliśmy. Weźcie zapytanie użytkownika:

„Kup mi cyfrowy prezent do $50”.

Zadanie — opisać w 3–5 logicznych krokach, co dzieje się dalej, i dla każdego kroku wskazać, kto go wykonuje: ChatGPT, wasz backend merchanta, dostawca płatności czy sam użytkownik. Można oprzeć się na powyższym diagramie i na tablicy digitalGiftFlow, ale nie trzeba pokrywać się z nimi jeden do jednego.

Na przykład możecie zacząć od kroku, w którym ChatGPT interpretuje zapytanie i doprecyzowuje szczegóły (cyfrowy certyfikat, region odbiorcy, dla kogo dokładnie prezent). Następnie krok, w którym wasz backend po Product Feed szuka pasujących SKU, dalej — utworzenie checkout_session, uzyskanie tokenu płatniczego od PSP i zakończenie zakupu.

Jeśli chcecie, możecie ująć to bezpośrednio w kodzie, dodając jeszcze kilka kroków do digitalGiftFlow i renderując je w małym debugowym komponencie w widżecie. Takie ćwiczenie dobrze wyrabia nawyk myślenia nie tylko „o kodzie”, ale też o rolach w protokole.

Przykład prostego endpointu API, który mógłby przyjmować taki „plan przepływu” i go logować (na razie bez prawdziwego commerce):

// 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 });
}

W prawdziwym życiu zamiast console.log będziecie pisać zestrukturyzowane logi i być może przechowywać takie scenariusze jako część dokumentacji lub testów. Ale nawet tak mały przykład pomaga połączyć abstrakcyjną architekturę z konkretnym kodem TypeScript w waszej aplikacji Next.js.

Jeśli będziemy mieć w głowie obraz ról, który omówiliśmy w tym wykładzie, dalsze szczegóły techniczne — pola Product Feed, schemy sesji checkout i struktura delegowanych płatności — będą układać się znacznie łatwiej i bez zbędnego romantyzmu wokół „wszechmocnego GPT”.

8. Typowe błędy w rozumieniu AI‑commerce i ról

Błąd №1: zakładać, że „ChatGPT zrobi wszystko sam”.
Czasem deweloperzy myślą, że wystarczy „podłączyć Stripe” i jakoś „dać modelowi dostęp do API”, a dalej GPT sobie poradzi. W rzeczywistości AI‑commerce wokół ChatGPT opiera się na formalnych specyfikacjach: Product Feed, Agentic Checkout, Delegated Payment. Jeśli nie opisaliście produktów w postaci ustrukturyzowanego feedu, nie zaimplementowaliście /checkout_sessions i nie skonfigurowaliście Delegated Payment, żadna model nie wymyśli tego za was.

Błąd №2: mylić role ChatGPT i merchanta.
Inne częste nieporozumienie — uważać, że ChatGPT staje się „sklepem”, a wy jedynie „podpinacie katalog”. W rzeczywistości jest odwrotnie: to wy pozostajecie merchantem, przechowujecie product feed, tworzycie i obsługujecie zamówienia, przetwarzacie zwroty. ChatGPT odpowiada tylko za UX dialogu i za poprawne wywołanie waszych endpointów ACP. Jeśli spróbujecie zaprojektować system tak, jakby „GPT sam rozdawał subskrypcje i wysyłał produkty”, prędzej czy później znajdziecie się w ślepym zaułku prawnym i technicznym.

Błąd №3: ignorować dostawcę płatności jako odrębną jednostkę.
Czasem kusi, by „schować” PSP wewnątrz backendu i rozmawiać z nim jak z dowolnym REST‑API, zapominając, że warstwa płatności rządzi się własnymi zasadami (PCI, fraud, chargebacki, limity). W podejściu ACP nieprzypadkowo wydzielono osobną Delegated Payment Spec: platforma agenta komunikuje się z PSP na swoim poziomie, otrzymuje token SPT i przekazuje go wam, a wy dopiero tworzycie płatność. Jeśli próbować obchodzić ten schemat i bezpośrednio przyjmować dane kart w aplikacji, szybko „strzelicie sobie w stopę” wymaganiami compliance.

Błąd №4: postrzegać product feed jako „ustawienie marketingowe”, a nie jako API dla LLM.
Wielu przychodzi z backgroundem Google Shopping i myśli o feedzie jako czymś ważniejszym dla panelu reklamowego niż dla kodu. W świecie AI‑commerce feed to w istocie baza wiedzy o waszym asortymencie dla modelu. Jeśli są tam uszkodzone linki do obrazów, niespójne atrybuty, dziwne jednostki miary i marketingowe przesady zamiast faktów, model będzie proponował nie to, czego potrzebujecie, a konwersja spadnie.

Błąd №5: próbować wdrożyć Instant Checkout „za jednym zamachem”.
Pokusa jest duża: „włączmy od razu enable_checkout, niech użytkownicy kupują z czatu”. Ale bez dobrego discovery (jakościowy feed), bez niezawodnego backendu checkout i bez przemyślanej integracji z PSP ryzykujecie kruchy system, w którym połowa zamówień zawiesza się w połowie. Znacznie rozsądniej iść krokami, które proponuje OpenAI: najpierw jakościowy Product Feed, potem dopracowanie endpointów ACP, następnie Delegated Payment i dopiero na końcu włączenie Instant Checkout w trybie produkcyjnym.