ChatGPT Merchants i ścieżka merchanta: od rejestracji po odpowiedzialność

1. Kim jest merchant ChatGPT i czym różni się od „zwykłego sklepu”

Z perspektywy dewelopera bardzo łatwo pomylić poziomy: mamy aplikację Next.js, serwer MCP, jakiś commerce‑backend i gdzieś tam jeszcze OpenAI, ChatGPT, Stripe i inne „dorosłe” serwisy. Kusi, by powiedzieć: „To wszystko jeden wielki system, byle testy były na zielono”.

Ale w świecie AI‑commerce granice prawne i techniczne są bardzo wyraźnie rozdzielone. ChatGPT nie staje się waszym sklepem ani procesorem płatności. Zapewnia jedynie inteligentny interfejs i wywołuje wasze API zgodnie z otwartymi specyfikacjami. Merchantem pozostaje konkretna firma z konkretnym katalogiem i odpowiedzialnością wobec użytkownika.

Zrozumienie roli merchanta jest potrzebne nie tylko prawnikom. Od tego zależą decyzje architektoniczne: gdzie przechowujecie dane feedu, jak walidujecie zamówienia, co logujecie, jak debugujecie rozbieżności między tym, co pokazano w czacie, a tym, co faktycznie zaszło w waszym systemie.

Przykład

Wyobraźmy sobie klasyczny e‑commerce: macie stronę, koszyk, checkout, integrację z dostawcą płatności. Użytkownik wchodzi przez przeglądarkę, klika myszką, wpisuje dane karty — wszystko jasne.

Merchant ChatGPT to ten sam sklep, tylko nauczony sprzedawać przez dialog AI z wysokim stopniem automatyzacji. Różnica nie polega na tym, co sprzedajecie, lecz na tym, jak użytkownik przechodzi drogę od zapytania do płatności.

Z punktu widzenia OpenAI merchant to organizacja (lub osoba prowadząca działalność gospodarczą), która:

• dostarcza Product Feed zgodny ze specyfikacją OpenAI (CSV/TSV/XML/JSON ze zstrukturoryzowanymi danymi o SKU);
• rejestruje się w portalu ChatGPT Merchants i przechodzi weryfikację kategorii oraz wymagań prawnych;
• w wariancie zaawansowanym implementuje Agentic Checkout i Delegated Payment, aby Instant Checkout w ChatGPT mógł zrealizować płatność bez wychodzenia na waszą stronę.

A więc merchant to nie „osoba, która napisała widget”, lecz właściciel asortymentu i zobowiązań finansowych. W naszym kursie gramy dwie role naraz: jesteśmy i zespołem, który pisze GiftGenius jako ChatGPT App, i zespołem, który tworzy backend merchanta, obsługującego ten App.

2. Portal ChatGPT Merchants: droga od zgłoszenia do merchanta produkcyjnego

OpenAI ma osobną stronę dla sprzedawców — portal ChatGPT Merchants. Przez niego sprzedawcy trafiają do programu Instant Checkout i podłączają swoje feedy oraz backend. Rozbijmy tę drogę na kroki, jeszcze bez głębokich technicznych detali (to w następnym wykładzie).

Wstępne przygotowanie

Zanim ktoś z waszego zespołu kliknie przycisk „Apply”, powinniście mieć już kilka klocków:

Podmiot prawny i strona. Merchant ma domenę i zrozumiały dla użytkownika storefront — nawet jeśli dalej wszystko będzie sprzedawane przez ChatGPT, OpenAI oczekuje publicznej witryny.

Asortyment zgodny z polityką. W poprzednim wykładzie mówiliśmy o Prohibited Products Policy: nie wolno np. broni ani niektórych produktów medycznych. Każdy towar, który chcecie sprzedawać przez ChatGPT, musi mieścić się w liście dozwolonych kategorii.

Podstawowa infrastruktura płatnicza. Choć Delegated Payment zdejmuje z was konieczność pracy bezpośrednio z kartami, musicie mieć integrację z PSP (choćby Stripe) i rozumieć, jak tworzycie zamówienia i zwroty w swoim systemie.

Zgłoszenie w portalu Merchants

Z technicznego punktu widzenia to dość nudny, ale ważny krok: wchodzicie na stronę i składacie wniosek o udział w programie Instant Checkout. Zwykle pytają tam:

• kim jesteście (podmiot, strona, kontakty);
• co sprzedajecie (kategorie, przedziały cen, regiony);
• w jaki sposób gotowi jesteście udostępniać Product Feed (format, URL, częstotliwość aktualizacji).

Ta część ma niewiele wspólnego z TypeScriptem, ale bardzo wpływa na waszą mapę drogową: dopóki merchant nie przejdzie podstawowej weryfikacji, Instant Checkout nie będzie włączony, nawet jeśli macie idealny kod.

Podłączenie Product Feed

Po tym, jak wniosek przejrzą i wstępnie zaakceptują, główny fokus techniczny przesuwa się na Product Feed. Według dokumentacji feed jest obowiązkowy: bez niego ChatGPT po prostu nie wie, co sprzedajecie.

Na tym etapie:

1. Określacie format feedu (najczęściej CSV lub JSON).
2. Ustalaćie, jak będziecie go udostępniać: może to być pre‑signed URL na S3 albo HTTPS‑endpoint, na który okresowo wysyłacie aktualizacje metodą POST.
3. Przygotowujecie minimum pól dla każdego SKU: id, title, description, price, currency, availability, link, obrazy oraz flagi enable_search / enable_checkout.

Dopóki ustawicie enable_checkout = false, merchant może działać w trybie discovery‑only: ChatGPT znajduje i rekomenduje produkty, ale przy próbie zakupu odsyła użytkownika na waszą stronę.

Integracja ACP (szczegóły w następnym wykładzie)

Gdy Product Feed jest stabilny i chcecie iść dalej, zaczyna się integracja Agentic Checkout i Delegated Payment. Z punktu widzenia portalu Merchants to osobny blok wymagań: trzeba zaimplementować endpointy /checkout_sessions, nauczyć się przyjmować delegowany token płatniczy (Shared Payment Token) i poprawnie kończyć sesje z odpowiednimi statusami (not_ready_for_payment, ready_for_payment, completed, canceled).

W tym wykładzie nazywamy to jedynie „następnym poziomem trudności”. Wszystkie szczegóły protokołu i schematy zapytań omówimy w kolejnym wykładzie.

3.5. Certyfikacja i włączenie Instant Checkout

Etap końcowy — weryfikacja, jak wasz backend zachowuje się w realnych scenariuszach:

• czy zamówienia tworzą się poprawnie;
• czy ceny z feedu pokrywają się z cenami, po których faktycznie pobieracie środki;
• czy błędy i zwroty są obsługiwane prawidłowo;
• czy wasze strony Regulaminu/Polityki prywatności odpowiadają oczekiwaniom OpenAI i lokalnym przepisom.

Po tym merchant otrzymuje status „gotowy do Instant Checkout”, a jego produkty z enable_checkout = true stają się realnie możliwe do zakupu bezpośrednio w ChatGPT.

Wszystko to można wyobrazić sobie jako prosty diagram:

flowchart TD
  A[Mamy produkt i stronę] --> B[Wniosek w ChatGPT Merchants]
  B --> C[Podłączony Product Feed]
  C --> D["Zaimplementowany backend ACP
(checkout_sessions + delegated payment)"]
  D --> E[Certyfikacja
i włączenie Instant Checkout]

3. Warianty merchanta: Etsy/Shopify vs. własny backend

Dobra wiadomość: nie wszyscy merchanci muszą sami pisać cały backend ACP. Dla niektórych platform (Shopify, Etsy i in.) istnieją już integracje, które biorą techniczną implementację na siebie.

Jeśli sprzedajecie przez Shopify lub Etsy, schemat wygląda mniej więcej tak: włączacie u nich opcję w rodzaju „Show in ChatGPT”, a platforma sama:

• formuje i utrzymuje Product Feed w wymaganym formacie;
• implementuje lub proxy’uje endpointy ACP;
• spina się ze Stripe lub innym PSP.

Wy, jako właściciel sklepu, bardziej zajmujecie się asortymentem i opisami niż REST‑endpointami.

Jeśli jednak, jak w naszym kursie z GiftGenius, budujecie customowego merchanta z własnym backendem, macie znacznie więcej swobody, ale i więcej pracy: sami piszecie kod, który implementuje feed, checkout i integrację z dostawcą płatności.

Wygodnie porównać to w tabeli:

Na potrzeby kursu świadomie wybieramy trzeci wariant: tylko tak możemy przejść całą drogę od feedu po webhooki i solidny production.

4. Odpowiedzialność merchanta: dane, zamówienia, polityka, pieniądze

Gdy stajecie się merchantem ChatGPT, podpisujecie się nie tylko pod radością z nowych zamówień, lecz także pod zestawem bardzo konkretnych zobowiązań. Rozbijmy je na warstwy.

Dane katalogowe i jakość Product Feed

Product Feed jest źródłem prawdy dla ChatGPT. Jeśli wskazuje, że produkt kosztuje 10 USD i jest dostępny, to właśnie to zobaczy użytkownik w czacie. Jeśli feed „kłamie”, to w najlepszym razie dostaniecie niezadowolonego klienta, w najgorszym — naruszenie polityk i problemy z OpenAI.

Od merchanta oczekuje się:

• poprawności pól obowiązkowych (właściwy format ceny, kody walut ISO, prawidłowe linki HTTPS, działające obrazy);
• odświeżania feedu wystarczająco często, by nie sprzedawać „widmowego” towaru;
• spójności identyfikatorów: id SKU w feedzie musi odpowiadać ID w waszej bazie i systemie zamówień, abyście mogli jednoznacznie zrozumieć, co dokładnie kupiono.

Jeśli porównać to ze zwykłym e‑commerce, Product Feed tutaj to wasz „eksport na marketplace”, tylko że marketplace’em jest nie strona, a inteligentny asystent, który „pamięta” niespójności.

Zamówienia, dostawa i zwroty

ChatGPT nie staje się działem wsparcia waszego sklepu. Użytkownik oczywiście rozmawia z nim, ale prawnie kupuje towar u merchanta, a nie u OpenAI. Zatem:

• odpowiadacie za to, że zamówienie zostanie utworzone w waszym systemie i trafi na magazyn;
• odpowiadacie za to, że przesyłka dotrze pod adres wskazany przez użytkownika w Instant Checkout;
• odpowiadacie za obsługę zwrotów, anulacji, częściowych zwrotów itp.

W ramach ACP checkout_session po pomyślnym zakończeniu zwykle zawiera obiekt order ze swoimi polami. Ale to jedynie odzwierciedlenie tego, co zaszło u was w backendzie — to wy decydujecie, jak wygląda rekord w tabeli orders, jakie macie statusy i jak wiążą się z logistyką.

Polityka i geografia

W portalu Merchants wskazujecie, w jakich krajach sprzedajecie i jakie typy produktów. OpenAI ze swojej strony sprawdza, że:

• nie sprzedajecie kategorii zabronionych;
• przestrzegacie lokalnego prawa (np. zasady podatkowe i ograniczenia wiekowe);
• dostarczacie zrozumiały Regulamin i Politykę prywatności.

W kolejnych modułach jeszcze porozmawiamy o stronach prawnych, ale już teraz warto myśleć kategoriami: „Jeśli nie potrafię wyjaśnić prawnikowi, co dokładnie sprzedaję i gdzie, ChatGPT raczej nie będzie sprzedawał tego za mnie”.

Pieniądze i dostawca płatności

Wreszcie to, co najstraszniejsze — pieniądze. Na szczęście ACP i Delegated Payment mocno upraszczają życie dewelopera:

• ChatGPT i dostawca płatności (np. Stripe) uzgadniają Shared Payment Token dla konkretnej kwoty i merchanta;
• wasz backend otrzymuje ten token w żądaniu complete i wykorzystuje go u siebie w PSP, nie widząc „surowych” danych karty.

Czyli nie zamieniacie się w potwora zgodnego z PCI, nie przechowujecie numerów kart i nie wchodzicie w koszmary audytowe. Wasza odpowiedzialność — poprawnie użyć delegowanego tokena (utworzyć płatność, pobrać środki, zrobić zwrot) i dokładnie prowadzić rozliczenia.

5. Jak to przekłada się na architekturę GiftGenius

Wróćmy do naszej aplikacji szkoleniowej GiftGenius. W ujęciu architektonicznym po czternastym module chcemy, by student potrafił narysować schemat: „Użytkownik → ChatGPT → App widget → MCP Gateway → Product Feed / Agents / ACP backend”.

W tym schemacie rola merchanta realizowana jest w naszym backendzie, a widget i App są jedynie „twarzą” tego merchanta w ChatGPT.

Konfiguracja merchanta w kodzie

Zacznijmy od prostego kroku: wprowadźmy w kodzie strukturę konfiguracji merchanta. Niech to będzie moduł TypeScript lib/merchantConfig.ts w naszym projekcie Next.js:

// lib/merchantConfig.ts
export type MerchantConfig = {
  id: string;                // ID merchanta w ACP/Stripe
  name: string;              // Czytelna nazwa
  feedUrl: string;           // Gdzie znajduje się Product Feed
  instantCheckoutEnabled: boolean;
};

export const giftGeniusMerchant: MerchantConfig = {
  id: process.env.MERCHANT_ID ?? "dev-merchant",
  name: "GiftGenius",
  feedUrl: process.env.PRODUCT_FEED_URL ?? "https://example.com/feed.json",
  instantCheckoutEnabled: false, // włączymy później
};

Po pierwsze, wyraźnie zaznaczamy granice: to jest merchant, a nie „widget”. Po drugie, wynosimy ważne wartości do zmiennych środowiskowych — w modułach o deploymencie i środowiskach jeszcze nie raz wrócimy do tego, dlaczego nie warto hardkodować takich rzeczy.

Dla wygody można dodać prostą funkcję, która powie naszemu kodowi, czy można teraz użyć Instant Checkout:

// lib/merchantConfig.ts
export function canUseInstantCheckout(cfg: MerchantConfig) {
  // Na dev i staging zawsze wyłączamy Instant Checkout
  if (process.env.NODE_ENV !== "production") return false;
  return cfg.instantCheckoutEnabled;
}

W ten sposób z góry przygotowujemy architekturę na to, że w różnych środowiskach zachowanie będzie inne i nie pozwalamy sobie (ani GPT) przypadkiem wejść w produkcyjny checkout z testowego środowiska.

Narzędzie MCP do pobierania informacji o merchancie

Często wygodnie jest dać modelowi i widgetowi możliwość sprawdzenia, w jakim trybie aktualnie działa merchant. Na przykład, by GPT nie proponował Instant Checkout, jeśli jest wyłączony.

W serwerze MCP (który stawialiśmy w poprzednich modułach) można dodać proste narzędzie:

// mcp/tools/merchant.ts
import { giftGeniusMerchant, canUseInstantCheckout } from "../lib/merchantConfig";

export const getMerchantInfoTool = {
  name: "get_merchant_info",
  description: "Zwraca podstawowe informacje o merchancie GiftGenius",
  inputSchema: { type: "object", properties: {}, additionalProperties: false },
  async handler() {
    return {
      id: giftGeniusMerchant.id,
      name: giftGeniusMerchant.name,
      instantCheckout: canUseInstantCheckout(giftGeniusMerchant),
    };
  },
};

To narzędzie nie robi nic niesamowitego, ale tworzy jawne miejsce, w którym model może zapytać: „Czy można teraz kupić prosto w czacie, czy tylko przejść do linku?”.

Wykorzystanie informacji o merchancie w widgetcie

Po stronie widgetu, używając znanych nam hooków Apps SDK, można wywołać get_merchant_info i zmienić UI w zależności od trybu. Najprostszy przykład komponentu:

// components/MerchantBadge.tsx
"use client";

import { useEffect, useState } from "react";
import { useCallTool } from "../lib/use-call-tool";

type MerchantInfo = { name: string; instantCheckout: boolean };

export function MerchantBadge() {
  const callTool = useCallTool();
  const [info, setInfo] = useState<MerchantInfo | null>(null);

  useEffect(() => {
    callTool("get_merchant_info", {}).then((res) => {
      setInfo(res?.result as MerchantInfo);
    });
  }, [callTool]);

  if (!info) return null;
  return (
    <span>
      {info.name} · {info.instantCheckout ? "Instant Checkout" : "Discovery only"}
    </span>
  );
}

Taki niewielki komponent przyjemnie podkreśla użytkownikowi (i wam samym w trybie dev), w jakim dokładnie stanie jest integracja z ChatGPT.

6. Praktyczne mini‑zadanie

Aby wykład nie pozostał tylko na poziomie „słów i diagramów”, spróbujcie wykonać następujące kroki w swoim projekcie GiftGenius (lub analogicznym):

Po pierwsze, dodajcie moduł konfiguracji merchanta, podobny do merchantConfig.ts, i wynieście MERCHANT_ID oraz PRODUCT_FEED_URL do zmiennych środowiskowych. Do lokalnego developmentu możecie użyć .env.local, a do production — ustawień Vercel lub innej platformy.

Po drugie, zaimplementujcie w serwerze MCP proste narzędzie get_merchant_info, które zwraca co najmniej name i instantCheckout. Pomyślcie, jakie inne pola mogą być użyteczne dla modelu: na przykład lista obsługiwanych walut lub krajów dostawy.

Po trzecie, dodajcie w widgetcie niewielki element UI (badge, wiersz statusu, podpis na karcie produktu), który używa tego toola i pokazuje użytkownikowi, w jakim trybie działa teraz wasz merchant: tylko rekomendacje czy już pełnoprawny Instant Checkout. To nie tylko dobre dla UX, ale też świetnie pomaga w debugowaniu.

Na koniec spróbujcie opisać tekstowo, jakimi krokami wasz konkretny projekt będzie przechodził od „mamy stronę i backend” do statusu merchanta ChatGPT. W którym miejscu podłączycie Product Feed, kiedy włączycie enable_checkout, kiedy zaczniecie implementację endpointów ACP. Takie ćwiczenie dobrze dyscyplinuje i pomaga nie zapomnieć o ważnych (choć nielubianych) sprawach jak polityka zwrotów.

7. Typowe błędy na drodze do merchanta ChatGPT

Błąd nr 1: „ChatGPT to mój sklep”.
Czasem deweloperzy myślowo „przenoszą” wszystko na stronę ChatGPT: jakby to on trzymał katalog, liczył ceny i realizował zamówienia. W rzeczywistości ChatGPT to interfejs i orkiestrator, a nie wasz ERP. Jeśli o tym zapomnieć, łatwo zbudować architekturę bez sensownego własnego modelu zamówień, gdzie wszystkie dane żyją „gdzieś w promptach”, a każda zmiana w zachowaniu modelu grozi utratą spójności.

Błąd nr 2: oczekiwanie Instant Checkout bez osobnej rejestracji i ACP.
Sam fakt, że napisaliście świetny widget i skonfigurowaliście Product Feed, nie włącza automatycznie Instant Checkout. Potrzebne są zgłoszenie w portalu Merchants, weryfikacja kategorii, implementacja Agentic Checkout i Delegated Payment, przejście testów. Próba założenia, że Instant Checkout jest „domyślnie”, zwykle kończy się tym, że GPT zaczyna proponować użytkownikowi to, czego w rzeczywistości nie ma, albo podaje linki zamiast oczekiwanych ekranów płatności.

Błąd nr 3: twarde hardcodowanie identyfikatorów i URL merchanta.
Klasyczna historia: MERCHANT_ID = "prod-123" zapisany wprost w kodzie, URL feedu — jako string w komponencie widgetu. Gdy tylko pojawia się staging lub potrzeba dodać drugiego merchanta, zaczynają się masowe „znajdź i zamień”. Znacznie bezpieczniej wynieść takie rzeczy do konfiguracji i zmiennych środowiskowych i używać ich przez cienką warstwę abstrakcji, jak zrobiliśmy z MerchantConfig.

Błąd nr 4: Product Feed żyje swoim życiem, niepowiązanym z zamówieniami.
Jeśli w feedzie SKU GIFT_RED_MUG kosztuje 10 USD, a w bazie zamówień dla tego samego identyfikatora z jakiegoś powodu pobieracie 12 USD, prędzej czy później to wypłynie. Źródłem prawdy o cenach i dostępności powinien być albo feed budowany z waszych wewnętrznych danych, albo wspólna warstwa, której ufają i feed, i checkout. Próba prowadzenia „podwójnej księgowości” (jedno dla ChatGPT, drugie dla własnej strony) bardzo szybko się mści.

Błąd nr 5: ignorowanie roli dostawcy płatności i przechowywania danych płatniczych.
Czasem kusi, by „zajrzeć” w token dostawcy płatności albo nawet dodatkowo prosić użytkownika o dane płatnicze we własnym UI. To nie tylko narusza model Delegated Payment, ale może wciągnąć was do świata PCI DSS i ciężkiego compliance’u. Właściwa praktyka — traktować Shared Payment Token jako nieprzezroczysty string, używać go wyłącznie w SDK dostawcy płatności i nigdzie go nie logować ani nie keszować.

Błąd nr 6: niedocenianie wieloetapowości onboardingu i brak planu.
I wreszcie częsty błąd organizacyjny — myślenie, że „przecież po prostu podłączymy się do ChatGPT, co w tym trudnego”. Faktycznie droga merchanta składa się z wielu kroków: technicznych (feed, backend, testy) i nietechnicznych (dokumenty prawne, uzgodnienie kategorii, ograniczenia regionalne). Jeśli nie rozpisać tej ścieżki z wyprzedzeniem, zespół będzie chaotycznie skakał między zadaniami, a terminy zaczną „topnieć” szybciej niż wasz entuzjazm do AI‑commerce.