1. Wszystko już działa osobno…
Na tym etapie macie już wyobrażenie, jak kręci się przepływ commerce wokół ChatGPT. Merchant ma produktowy feed, zaimplementowane są endpointy ACP (/checkout_sessions i spółka), Instant Checkout realizuje płatność, a backend odbiera webhooki i tworzy zamówienia. To wszystko może działać nawet bez waszej aplikacji ChatGPT App: wystarczy Product Feed + ACP‑backend.
Osobno potraficie już:
- zbudować Product Feed zgodnie ze specyfikacją OpenAI;
- zaprojektować i zaimplementować Agentic Checkout / Delegated Payment;
- napisać ChatGPT App z widżetem i narzędziami MCP do wyszukiwania prezentów.
Osobno wszystko wygląda świetnie, a razem łatwo zamienia się w „zoo serwisów”. Widżet żyje własnym życiem, serwer MCP — swoim, ACP‑backend jeszcze innym, a logika zamówień i webhooków — kolejnym. Przy pierwszej próbie debugowania realnego zakupu lub naprawy dziwnego buga nagle okazuje się, że nikt tak naprawdę nie widzi pełnego obrazu.
Celem tej lekcji jest wyciągnąć was z tego stanu i dać spójną, a jednocześnie wykonalną architekturę: jak dokładnie Product Feed jest związany z ACP‑backendem, jak oba odnoszą się do ChatGPT App i widżetu, gdzie dokładnie pojawia się dostawca płatności i jak to wszystko zamienia się w zrozumiałe dla zespołu komponenty: serwisy, baza danych, API.
Przy tym będziemy stale podkreślać: co jest twardym standardem (SPEC), a co — jedynie naszym wyborem architektonicznym dla GiftGenius.
Insight: ChatGPT to darmowy Google
ChatGPT pracuje z użytkownikami mniej więcej tak jak Google: za darmo przyprowadza do was relewantny ruch, bo zarabia na czym innym — na samych użytkownikach.
Z perspektywy biznesu oznacza to prostą rzecz: ChatGPT staje się darmowym „kanałem reklamowym” dla waszych produktów, pod warunkiem, że podłączyliście Product Feed i ACP‑backend. Model będzie proponował wasze pozycje, jeśli dobrze odpowiadają na intencję użytkownika, i nie musicie osobno płacić za wyświetlenia czy kliknięcia.
Wynikają z tego dwa praktyczne wnioski:
- Okno możliwości jest TERAZ bardzo tanie. Obecnie konkurencja w ekosystemie ACP jest niewielka, a wejście w wyższe segmenty cenowe można uzyskać bez typowych budżetów reklamowych. To rzadka sytuacja, gdy ruch o wysokiej konwersji na drogie produkty (lotnictwo, nieruchomości, dobra premium, ubezpieczenia) może nic nie kosztować.
- Warto zaczynać od najbardziej marżowych wertykalnych kategorii. Jeśli macie dostęp do kategorii z wysoką wartością koszyka, racjonalnie podłączać je jako pierwsze:
- sprzedaż / wynajem samolotów, jachtów, willi;
- sprzedaż / wynajem domów i nieruchomości premium;
- biżuteria, drogie zegarki, produkty i usługi ubezpieczeniowe.
To nie gwarantuje „szybkich milionów”, ale tworzy asymetrię: ci, którzy jako pierwsi dostarczą jakościowy Product Feed i niezawodny ACP‑backend w drogich segmentach, uzyskają nieproporcjonalnie wysoki zysk z kanału, dopóki pozostaje on niedoszacowany i de facto darmowy.
2. Architektura referencyjna GiftGenius: grubymi pociągnięciami
Zacznijmy widokiem z góry. Przypomnijmy ogólny obraz z poprzednich modułów: użytkownik pisze w ChatGPT, model wywołuje wasze narzędzia, a warstwa commerce żyje w osobnym backendzie.
Sformułujmy główne bloki GiftGenius.
Po pierwsze, ChatGPT UI i model GPT, które prowadzą dialog z użytkownikiem i w razie potrzeby podłączają GiftGenius‑App (albo działają w ogóle bez App — tylko na podstawie Product Feed).
Po drugie, widżet GiftGenius (Next.js + Apps SDK), który pokazuje karty prezentów i, w miarę potrzeby, postęp checkoutu. Działa w piaskownicy window.openai i nie zna żadnych rzeczywistych danych płatniczych.
Po trzecie, warstwa MCP, która daje modelowi narzędzia do wyszukiwania prezentów w katalogu (Product Feed) i ewentualnie do odczytu historii zamówień.
Po czwarte, commerce / ACP‑backend, który:
- czyta Product Feed jako źródło prawdy o produktach i SKU;
- realizuje Agentic Checkout Spec (/checkout_sessions, webhooki, statusy);
- rozmawia z dostawcą płatności (np. Stripe) zgodnie z Delegated Payment Spec.
Po piąte, bazy danych katalogu (jeśli feed powstaje z bazy), zamówień i struktur pomocniczych (użytkownicy, ustawienia).
I wreszcie dostawca płatności, który przechowuje i przetwarza dane płatnicze, a także wysyła webhooki o wynikach płatności.
Szkicowo można to narysować tak:
graph LR U[Użytkownik w ChatGPT] --> GPT[Model GPT] GPT -->|renderuje| W[GiftGenius Widget
Next.js + Apps SDK] GPT -->|MCP tools| MCP[Serwer MCP
wyszukiwanie prezentów] MCP --> PF["Product Feed
(baza danych/JSON)"] GPT -->|ACP HTTP| ACP[GiftGenius Commerce Backend
Agentic Checkout] ACP --> ORDERS[Baza zamówień] ACP --> PSP["Dostawca płatności
(Stripe i inne)"] PSP --> ACP ACP -->|webhooki/zdarzenia| GPT
Ten diagram opisuje architekturę GiftGenius jako przykład implementacji. Format Product Feed, kontrakt /checkout_sessions i protokół Delegated Payment pozostają częścią standardu ACP; umiejscowienie serwisów, schematy baz danych i podział na procesy — to wasz wybór architektoniczny.
3. Jak Product Feed, ACP i widżet są powiązane logicznie
Aby nie utonąć w strzałkach, utrwalmy prostą, ale kluczową myśl: macie dokładnie jedno źródło prawdy o produktach.
W świecie GiftGenius niech będzie to tabela products + skus w PostgreSQL. Na jej podstawie:
- Formujecie Product Feed zgodnie ze specyfikacją OpenAI (bezpośrednio lub przez eksport).
- Budujecie indeks wyszukiwawczy dla narzędzi MCP (np. search_gifts).
- Przeprowadzacie walidację żądań ACP‑backendu — sprawdzacie, że przychodzący sku_id w ogóle istnieje i ma poprawną cenę oraz walutę.
W ten sposób wyszukiwanie MCP i checkout ACP patrzą na te same dane, a widżet jedynie pokazuje wyniki, które pochodzą albo z narzędzi MCP, albo pośrednio z ACP (np. informacje o zamówieniu).
Można to sobie wyobrazić jako dwa „okna” do tego samego katalogu: jedno okno — do wyszukiwania i rekomendacji, drugie — do finalizacji zakupu. Jeśli te okna patrzą w różne bazy, czeka was wesołe życie z rozjazdami.
4. Modelowanie danych: od Product Feed do zamówienia
Zacznijmy od prostych typów TypeScript, które będą żyły w waszym repozytorium GiftGenius (np. w src/domain/commerce.ts). Te typy nie są literalną kopią specyfikacji, ale odzwierciedlają ich główne idee w wygodnej dla aplikacji formie.
// src/domain/commerce.ts
export interface ProductSku {
id: string; // stabilny identyfikator SKU (zgodny z Product Feed)
title: string; // nazwa czytelna dla człowieka
priceCents: number; // cena w centach/groszach
currency: string; // kod ISO, np. "usd"
}
export type CheckoutStatus = "pending" | "succeeded" | "failed";
export interface CheckoutSession {
id: string;
skuId: string;
totalCents: number;
currency: string;
status: CheckoutStatus;
}
Tutaj w CheckoutSession jawnie niesiemy odwołanie do skuId oraz ustaloną walutę/kwotę. To nasz wewnętrzny model; rzeczywista Agentic Checkout Spec jest bogatsza, ale idea jest ta sama: sesja — to „ile, za co i w jakim statusie”.
Dalej potrzebny jest typ zamówienia:
export interface Order {
id: string;
userId: string;
skuId: string;
totalCents: number;
currency: string;
checkoutSessionId: string;
status: "awaiting_payment" | "paid" | "canceled" | "refunded";
}
Tu czuć wpływ ogólnych bytów z poprzedniego modułu: intent, checkout_session, order. W naszym projekcie edukacyjnym lekko spłaszczamy intent i order, by nie mnożyć bytów, ale zachowujemy powiązanie z checkoutSessionId.
5. Jak widżet GiftGenius „podgląda” świat commerce
Ważne: sam widżet nie odwołuje się do systemu płatności i nawet nie musi znać szczegółów ACP; jego rola — pokazywać użytkownikowi stan, który został policzony i zapisany na backendach.
Najprostszy użyteczny scenariusz: po udanym zakupie użytkownik może wrócić do czatu i zapytać „Pokaż moje ostatnie zamówienia w GiftGenius”. GPT wywoła narzędzie MCP w rodzaju get_user_orders, które zwróci się do waszego backendu, a widżet pokaże listę.
Wyobraźmy sobie trasę API Next.js, która zwraca ostatnie zamówienia (uproszczone):
// 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 });
}
Funkcja getRecentOrdersForUser żyje już w waszej warstwie commerce, pracuje z bazą danych i zna strukturę zamówień. Widżet z kolei może wywoływać tę trasę przez window.fetch (robiliśmy tak w poprzednich modułach) i pokazywać karty zakupów.
Kombinacja „narzędzie MCP → wasze API → baza zamówień → widżet” daje użytkownikowi wrażenie, że App ma „pamięć” o zakupach, choć widżet po prostu wyświetla stan backendu.
6. Prosta implementacja ACP‑endpointu w stylu Next.js
Nakreślmy teraz, jak może wyglądać edukacyjna implementacja jednego z kluczowych endpointów ACP — tworzenia checkout_session. Zgodnie ze specyfikacją kontrakt jest dość bogaty, ale na potrzeby kursu zostawimy sedno: przychodzi skuId, weryfikujemy go względem feedu/bazy, tworzymy sesję i zwracamy jej ID oraz kwotę.
Załóżmy trasę 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 not found" },
{ status: 400 },
);
}
const session = await createCheckoutSession(sku);
return NextResponse.json({ session });
}
Tutaj jest kilka ważnych punktów.
Po pierwsze, to właśnie tutaj warstwa commerce porównuje dane z Product Feed/bazą: findSkuById musi patrzeć w to samo źródło, z którego formuje się feed. Nie ufamy niczemu, co przyszło „z powietrza” — ani od GPT, ani od widżetu.
Po drugie, zwracamy tylko to, co potrzebne ChatGPT/klientowi ACP: ID sesji, kwotę, walutę i status (domyślnie pending lub not_ready_for_payment, w zależności od wybranej terminologii). W realnym ACP pól jest więcej, w tym informacje o dostępnych metodach płatności i fulfillment, ale przykład edukacyjny koncentruje się na pierwotnym utworzeniu sesji.
Po trzecie, taką trasę wygodnie pokryć testami kontraktowymi: jeśli jutro struktura Product Feed się zmieni, testy na findSkuById i createCheckoutSession powinny to wychwycić wcześniej, niż ChatGPT zacznie serwować użytkownikom dziwne błędy.
7. Powiązanie sesji ACP z dostawcą płatności
Dotąd nie dotykaliśmy dostawcy płatności. W realnej integracji dzieje się w przybliżeniu tak (uproszczony scenariusz).
Najpierw ChatGPT (przez ACP) wywołuje wasz POST /checkout_sessions. Wasz backend tworzy lokalną sesję w swojej bazie. Gdy użytkownik potwierdza płatność w UI Instant Checkout, platforma żąda u PSP delegowanego tokenu płatniczego (Shared Payment Token) dla konkretnego merchanta i kwoty. Ten token trafia do was w żądaniu complete (lub analogicznym wywołaniu wg Delegated Payment Spec).
Następnie tworzycie płatność u PSP, używając tokenu, bez dostępu do rzeczywistych danych płatniczych. PSP wysyła webhook o wyniku; aktualizujecie status zamówienia i/lub sesji checkout.
W naszym kodzie edukacyjnym możemy ograniczyć się do imitacji tego kroku. Na przykład funkcja completeCheckoutSession może wyglądać tak:
// src/lib/checkout.ts
export async function completeCheckoutSession(sessionId: string, spt: string) {
// W rzeczywistości tutaj wywołujemy API PSP z delegowanym tokenem (SPT)
const paymentOk = await mockChargeWithToken(spt);
return paymentOk
? { status: "succeeded" as const }
: { status: "failed" as const };
}
Wywołanie PSP i użycie Shared Payment Token to część standardu Delegated Payment, a funkcja mockChargeWithToken — nasza edukacyjna warstwa architektoniczna, która to imituje.
8. Przepływ end‑to‑end GiftGenius: od zapytania do opłaconego prezentu
Teraz złóżmy wszystko razem jako sekwencję kroków. To ta „bojowa” historia GiftGenius, dla której łączymy wszystkie warstwy. Ważne, by nie mieszać dwóch różnych światów, dlatego rozpatrzymy je osobno.
Schemat A: bez App, tylko Product Feed + ACP
W tym scenariuszu macie Product Feed i ACP‑backend, ale nie macie ChatGPT App ani widżetu. To klasyczny merchant Instant Checkout.
Użytkownik pisze w ChatGPT coś w rodzaju: „Dobierz cyfrowy prezent do 50 $”. GPT używa waszego Product Feed, by znaleźć odpowiednie SKU i pokazuje je w swoim natywnym UI w postaci kart zakupowych. Tutaj nie ma jeszcze waszego kodu React — karty w pełni rysuje ChatGPT.
Użytkownik klika przycisk „Buy” na jednej z takich kart. Ten klik obsługuje sam ChatGPT. Platforma:
- Formuje line_items na podstawie Product Feed.
- Wywołuje wasz POST /checkout_sessions zgodnie z Agentic Checkout Spec.
- Pokazuje użytkownikowi UI Instant Checkout (metoda płatności, adres itd.).
- Po potwierdzeniu otrzymuje Shared Payment Token od PSP i wywołuje wasz .../complete.
- Otrzymuje od was stan końcowy checkout_session i, w razie potrzeby, czeka na webhook o zamówieniu.
Z punktu widzenia waszego kodu działają tu tylko ACP‑endpointy i Product Feed. Nie ma żadnego Apps SDK, window.openai ani widżetu. I to absolutnie poprawny, „czysty” scenariusz merchantów ACP.
Schemat B: z ChatGPT App i widżetem GiftGenius
Teraz dodajmy na wierzchu ChatGPT App i widżet GiftGenius. Product Feed i ACP‑backend nigdzie nie znikają: wciąż zapewniają wyszukiwanie i płatność. Różnica w tym, że pojawia się nasz własny UI i logika kroków wewnątrz App.
Wyobraźmy sobie dialog: użytkownik pisze w ChatGPT: „Dobierz prezent dla mamy do 50 $”. GPT rozumie, że to zapytanie commerce i proponuje użyć GiftGenius‑App. Widżet zadaje kilka pytań doprecyzowujących: wiek, zainteresowania, kraj. Następnie GPT wywołuje wasze narzędzie MCP search_gifts z filtrami, a serwer MCP odwołuje się do katalogu (baza lub przygotowany indeks), znajduje kilka odpowiednich SKU i zwraca je w ustrukturyzowanej formie.
GPT przekazuje te dane do widżetu, a widżet pokazuje swoje firmowe karty prezentów (komponenty React, karuzele itd.). To już wasz design i UX, a nie standardowy shopping‑UI ChatGPT.
Gdy użytkownik klika w widżecie przycisk „Kup”, dzieje się coś innego niż w schemacie A. Ten klik obsługuje widżet:
- Widżet rozumie, który SKU wybrał użytkownik.
- Swoim API (np. POST /api/checkout-sessions) zwraca się do waszego backendu, aby utworzyć checkout_session (albo pobrać ID już przygotowanej sesji).
- Następnie widżet wywołuje metodę uruchomieniową Apps SDK, podobną do:
// Aktualną sygnaturę metody sprawdzajcie w dokumentacji Apps SDK await window.openai.requestCheckout({ checkoutSessionId: session.id, ... });To wywołanie — inicjatywa widżetu. Dla ChatGPT to sygnał: „Czas otworzyć Instant Checkout dla tej checkout_session”.
Dalej platforma ChatGPT działa już bardzo podobnie do schematu A, ale za kulisami:
- pokazuje użytkownikowi natywny UI Instant Checkout;
- pozyskuje Shared Payment Token u PSP;
- wywołuje wasz endpoint ACP finalizacji sesji (.../complete);
- uczestniczy w odbiorze i obsłudze webhooków od waszego backendu.
Czyli w schemacie B widżet uruchamia checkout przez Apps SDK, a wywołania ACP (utworzenie/zakończenie checkout_session) odbywają się albo przed tym (gdy sami tworzycie sesję w backendzie), albo już po requestCheckout, ale zawsze po stronie serwera.
Widżet może równolegle pokazywać kroki „Finalizacja zakupu”, statusy i podgląd zamówienia, opierając się na waszym API (/api/orders/...) i narzędziach MCP.
Jeśli narysować schemat B diagramem, wyjdzie coś takiego:
sequenceDiagram
participant User as Użytkownik
participant GPT as ChatGPT / GPT
participant W as Widżet GiftGenius
participant MCP as Serwer MCP
participant ACP as Commerce Backend
participant PSP as Dostawca płatności
User->>GPT: "Dobierz prezent do 50 $"
GPT->>MCP: search_gifts(...)
MCP-->>GPT: lista SKU
GPT->>W: dane do renderowania kart
User->>W: klik „Kup”
W->>ACP: POST /api/checkout-sessions (skuId)
ACP-->>W: checkout_session (id, kwota, waluta)
W->>GPT: window.openai.requestCheckout({ checkoutSessionId })
GPT->>User: UI Instant Checkout
User->>GPT: potwierdzenie płatności
GPT->>PSP: żądanie Shared Payment Token
PSP-->>GPT: SPT
GPT->>ACP: complete(sessionId, SPT)
ACP->>PSP: charge(SPT)
PSP-->>ACP: wynik płatności
ACP->>GPT: status zamówienia
GPT->>User: komunikat o udanej/nieudanej płatności
Kluczowa różnica względem schematu A:
- W A karty i przycisk „Buy” rysuje sam ChatGPT i to on bezpośrednio inicjuje wywołanie ACP.
- W B karty i przycisk „Kup” rysuje wasz widżet i to on wywołuje window.openai.requestCheckout(...). A dopiero potem ChatGPT pod spodem rozmawia z waszym ACP‑backendem i PSP.
Insight
W swoim SDK ChatGPT napisał, że wkrótce w aplikacjach pojawi się monetyzacja. I tak właśnie będzie. Widżety mają już dostęp do kilku jeszcze nieogłoszonych metod. Najciekawsza z nich to requestCheckout().
Wygląda to tak:
window.openai.requestCheckout({
id: "checkout_session_123",
payment_provider: {
merchant_id: "stripe",
supported_payment_methods: ["card"]
},
...
}
Otwiera on okno dialogowe pozwalające użytkownikowi sfinalizować płatność. Dlatego projektujcie swoją aplikację tak, jakby monetyzacja była już włączona: kiedy skończycie pracę, tak właśnie będzie.
9. Mini‑implementacja na potrzeby kursu: monolityczny backend
W modułach o architekturze pojawiało się pytanie: robić wszystko jednym serwisem czy od razu dzielić na serwer MCP, commerce‑backend i osobny serwis do integracji płatniczej. Do celów edukacyjnych zwykle wystarczy „prawie monolit”: jedno repozytorium, jeden deploy, ale logika starannie rozdzielona na warstwy.
Wariant edukacyjny GiftGenius może wyglądać tak: aplikacja Next.js, w której:
- widżet żyje w app/widget/page.tsx;
- endpointy ACP — w app/api/checkout-sessions i sąsiednich trasach;
- narzędzia MCP — w app/api/mcp/route.ts albo osobnym katalogu;
- obsługa zamówień — w src/lib/orders.ts, src/lib/checkout.ts i pokrewnych modułach.
Fizycznie to jeden serwer (zwłaszcza na etapie dev/staging), ale logicznie myślicie już w kategoriach trzech ról: UI (widżet), MCP (narzędzia/zasoby dla GPT) i ACP (commerce‑backend).
Później, w modułach o produkcji, zobaczycie, jak ten „monolit” rozkłada się na kilka serwisów i środowisk, a przed nimi pojawia się MCP Gateway. Ale na poziomie modułu 14 taki „monolit z poprawnymi warstwami” daje już bardzo wiarygodną architekturę.
10. Zadanie praktyczne: wasza architektura wokół ACP
Aby wszystko powyższe nie zostało teorią, warto już teraz przyłożyć to do własnej domeny. W ramach lekcji można zrobić dwa mini‑ćwiczenia.
Po pierwsze, wybierzcie własny scenariusz: subskrypcja SaaS, rezerwacja, dostawa jedzenia, kursy online — dowolny przypadek, gdzie jest produkt/usługa, cena i sensowny checkout. Przypomnijcie sobie model fazowy: discovery → decision → checkout → post‑payment.
Po drugie, opierając się na architekturze GiftGenius, opiszcie swobodnie: jak będziecie budować Product Feed (gdzie żyją SKU i ceny, kto je aktualizuje), gdzie zrealizujecie kontrakt ACP (osobny serwis czy część istniejącego backendu), jak podłączycie dostawcę płatności i jak wasz widżet (jeśli jest) będzie współdziałał z tym wszystkim przez MCP i Apps SDK.
Warto wprost określić, czy wasz projekt będzie używał tylko schematu A (Instant Checkout bez App), tylko schematu B (App + widżet), czy obu scenariuszy naraz. Nawet taki szkic tekstowy architektury mocno zmniejsza ryzyko niespodzianek na etapie realnej integracji.
11. Typowe błędy przy integracji Product Feed, ACP i widżetu
Błąd nr 1: dwa różne katalogi — jeden do wyszukiwania, drugi do checkoutu.
Zdarza się, że zespół najpierw podnosi szybki „wyszukiwawczy” feed dla GPT (np. mały JSON), a potem osobno tworzy bazę commerce do zamówień. Jeśli nie zwiążecie ich wspólnymi ID i wspólną logiką aktualizacji, GPT może proponować użytkownikowi produkty, których nie da się już kupić albo w starej cenie. Poprawne podejście — jedno źródło prawdy, z którego powstają i Product Feed, i wewnętrzne tabele dla endpointów ACP.
Błąd nr 2: ufanie danym pochodzącym od GPT lub widżetu.
Gdy do checkout_session trafiają skuId i cena, bardzo kusi, by po prostu im uwierzyć: „przecież GPT nie będzie kłamać”. Ale model może łatwo „pokreatywować” lub pomylić SKU, a użytkownik — spróbować sfałszować żądanie. Jeśli nie weryfikować danych wejściowych względem Product Feed/bazy, ryzykujecie sprzedaż nie tego i nie za te pieniądze. Każdy endpoint ACP powinien zaczynać się od walidacji względem pierwotnego magazynu katalogu.
Błąd nr 3: mieszanie ról widżetu i commerce‑backendu.
Zdarza się, że deweloperzy z przyzwyczajenia z frontendu od razu wywołują SDK płatności, tworzą sesje w Stripe i w ogóle żyją jak na zwykłej stronie. W kontekście ChatGPT Apps to łamie model bezpieczeństwa i kłóci się z ACP: przepływ płatności powinien przechodzić przez ChatGPT i wasz commerce‑backend, a widżet — tylko wyświetlać stan i wysyłać zdarzenia (typu requestCheckout). Jeśli widżet wie zbyt dużo o obszarze płatności, dostajecie i złożoność, i podwyższone ryzyko.
Błąd nr 4: nadmierne uproszczenie kontraktu ACP.
W przykładzie edukacyjnym świadomie zostawiamy tylko skuId, kwotę i status, by nie utonąć w detalach. Problem zaczyna się, gdy taki „demo‑kontrakt” niepostrzeżenie trafia do produkcji. Nagle okazuje się, że brakuje pól na adres, podatki, metody dostawy, kody promocyjne i zaczynacie „doklejać” je chaotycznie. Lepiej od razu projektować wewnętrzne modele z zapasem pod realne scenariusze, nawet jeśli część pól przez pewien czas będzie nieużywana.
Błąd nr 5: brak powiązania między zamówieniami a użytkownikami.
W demo łatwo poprzestać na orderId i skuId, nie myśląc o tym, jak użytkownik wróci za tydzień i zapyta: „Pokaż moje zakupy”. Jeśli od początku nie przewidzicie userId (lub innego stabilnego identyfikatora) w zamówieniu i sesji checkout, później czekają was migracje i trudne mostki. Architektura commerce wokół ChatGPT prawie zawsze zakłada, że GPT będzie mógł powiązać bieżącą rozmowę z historią zamówień użytkownika — warto uwzględnić to z góry.
Błąd nr 6: niedocenianie wagi webhooków i idempotentności.
W lekcji tylko mówimy o webhookach, a głębiej zajmiecie się nimi w kolejnych modułach. Łatwo pomyśleć: „webhook przyjdzie raz, zaktualizujemy zamówienie — i już”. W praktyce systemy płatności lubią ponawiać zdarzenia, a sieć — gubić odpowiedzi. Jeśli nie projektować zamówień i sesji checkout jako struktur idempotentnych (po checkoutSessionId lub paymentId), można dorobić się podwójnych obciążeń, duplikatów zamówień i nieoczywistych rozbieżności między PSP a waszą bazą.
Błąd nr 7: ignorowanie ograniczeń i polityk w Product Feed.
W pogoni za szybkim feedem demo łatwo zapomnieć o ograniczeniach wiekowych, dostępności w krajach, zabronionych kategoriach i innych „drobiazgach”. Później okazuje się, że GPT z radością proponuje użytkownikowi towar, którego nie wolno mu sprzedać w jego regionie albo wieku. Pola związane z polityką i ograniczeniami trzeba projektować i wypełniać od początku, nawet jeśli na razie sprzedajecie tylko niegroźne prezenty cyfrowe.
GO TO FULL VERSION