UCP czy ACP: porównanie protokołów handlu agentowego Google i OpenAI

Czym jest Universal Commerce Protocol i jak działa?

UCP to zestaw specyfikacji, który pozwala agentowi Google rozmawiać ze sklepem w ustandaryzowany sposób, bez osobnej integracji dla każdego sprzedawcy. Google ogłosił go 11 stycznia 2026 roku, a współtwórcami byli m.in. Shopify, Etsy, Wayfair, Target i Walmart; protokół poparło ponad 20 firm z handlu i płatności.

Podstawą jest profil sklepu publikowany pod stałym adresem /.well-known/ucp. Agent odczytuje z niego wersję protokołu i listę możliwości (capabilities), które sklep obsługuje. Dzięki temu sklep nie musi wdrażać wszystkiego naraz – może zacząć od jednego modułu. W Merchant Center Google rozwija od października 2026 hub integracji UCP, w którym sprzedawca wybiera trzy główne ścieżki:

• przeniesienie koszyka (Cart API, możliwość dev.ucp.shopping.cart) – Google tworzy koszyk w sklepie, a klient kończy zakup na stronie sprzedawcy,
• natywny checkout – cała transakcja odbywa się w interfejsie Google, z płatnością Google Pay,
• łączenie kont (identity linking) – klient loguje się kontem ze sklepu przez OAuth 2.0, co pozwala agentowi korzystać np. z programu lojalnościowego i historii zamówień.

Dodatkowo kody promocyjne w Universal Cart wymagają obsługi możliwości rabatowej (dev.ucp.shopping.discount). Cart API wymaga UCP w wersji 2026-04-08 lub nowszej, a uwierzytelnianie obsługuje klucze API i OAuth 2.0.

UCP jest projektowany jako niezależny od transportu: obok klasycznego REST przewiduje współpracę z MCP i protokołem A2A (agent–agent), a w warstwie płatności – z AP2. Jak MCP łączy modele z narzędziami w codziennej pracy marketingowej, pokazujemy w tekście o MCP w marketingu.

Czym jest Agentic Commerce Protocol (ACP)?

ACP to otwarty standard opracowany przez OpenAI i Stripe, ogłoszony 29 września 2025 roku razem z funkcją Instant Checkout w ChatGPT. Protokół opisuje, jak agent prowadzi sesję checkoutu w systemie sklepu: tworzy ją z pozycjami koszyka, aktualizuje o adres i metodę dostawy, a na końcu przekazuje token płatniczy.

Kluczowym elementem jest delegowana płatność. ChatGPT nie przekazuje sklepowi danych karty, tylko token o ograniczonym zakresie (w implementacji Stripe – Shared Payment Token), ważny dla konkretnej kwoty i sprzedawcy. Sklep obciąża go przez swojego operatora płatności, tak jak przy zwykłym zamówieniu. Zamówienie trafia do systemu sklepu, a ten informuje platformę o zmianach statusu.

Drugą częścią ekosystemu jest feed produktowy w specyfikacji OpenAI (pliki JSONL, CSV lub TSV), w którym flagi is_eligible_search i is_eligible_checkout decydują, czy produkt może się pojawiać w wynikach i czy można go kupić w czacie. Standardowy feed jest dziś kierowany na rynek amerykański; inne rynki wymagają potwierdzenia integracji przez OpenAI.

W marcu 2026 OpenAI ogłosiło, że Instant Checkout przechodzi do aplikacji działających w ChatGPT, a firma skupia się na wyszukiwaniu i odkrywaniu produktów. W praktyce zakup zaczęty w ChatGPT kończy się dziś najczęściej przekierowaniem na stronę sklepu albo w aplikacji sprzedawcy działającej w ChatGPT, z checkoutem na infrastrukturze sklepu. ACP pozostaje warstwą techniczną dla tych scenariuszy, a OpenAI zapowiada jego rozszerzanie o kolejne etapy ścieżki zakupowej.

UCP i ACP – porównanie w tabeli

Najkrócej: UCP jest szerszy i mocniej związany z ekosystemem Google (Merchant Center, Google Pay, Shopping Graph), a ACP jest węższy, bardziej skupiony na samej transakcji i niezależny od jednego dostawcy płatności.

Podobną rywalizację standardów widać po stronie zakupu mediów, gdzie agenci AI negocjują kampanie przez AdCP – opisujemy to w tekście o reklamie agentowej w programmatic.

Jak wygląda przepływ zamówienia w obu protokołach?

Różnica jest widoczna w sekwencji wywołań. W ACP agent prowadzi checkout krok po kroku w API sklepu. W scenariuszu przeniesienia koszyka w UCP Google wykonuje jedno wywołanie, a resztę klient kończy na stronie sprzedawcy.

ACP – ChatGPT prowadzi checkout w API sklepu
1. POST /checkout_sessions                  -> sklep zwraca ceny, podatki, opcje dostawy
2. POST /checkout_sessions/{id}             -> aktualizacja adresu i metody dostawy
3. POST /checkout_sessions/{id}/complete    -> przekazanie tokenu płatniczego, utworzenie zamówienia
4. sklep -> platforma: powiadomienia o zmianie statusu zamówienia

UCP – przeniesienie koszyka (Universal Cart)
1. Google odczytuje profil sklepu: /.well-known/ucp
2. CreateCart: POST /carts (jedno wywołanie, gdy klient kliknie przeniesienie)
3. sklep zwraca continue_url -> klient kończy zakup na stronie sklepu
   (brak aktualizacji i synchronizacji koszyka po utworzeniu)

Uproszczony fragment profilu UCP może wyglądać tak (szkic poglądowy – pełną, aktualną strukturę weź z dokumentacji protokołu):

{
  "ucp": {
    "version": "2026-04-08",
    "capabilities": [
      { "name": "dev.ucp.shopping.cart" },
      { "name": "dev.ucp.shopping.discount" }
    ]
  }
}

Z przepływu wynikają konsekwencje praktyczne. W ACP sklep musi w czasie rzeczywistym liczyć koszt dostawy i podatki dla sesji, bo agent pokazuje je klientowi przed płatnością. W Cart API UCP koszyk jest przekazywany jednokierunkowo: późniejsze zmiany ceny lub stanu po stronie sklepu nie wracają do Google, więc dane w Merchant Center muszą być aktualne. Google zaleca odpowiedź na CreateCart w czasie poniżej sekundy i ograniczanie ruchu kodem HTTP 429.

Płatności: tokeny, AP2 i rola operatora płatności

W obu protokołach agent nie widzi pełnych danych karty, a płatność przetwarza operator, z którym sklep już współpracuje. Różni się źródło tokenu.

W UCP płatność natywna opiera się na Google Pay: klient płaci kartą zapisaną w Google Wallet, a operator płatności sklepu musi akceptować token Google Pay. Na listach produktów kwalifikujących się do przycisku zakupu wymagany jest atrybut native_commerce. UCP jest też zgodny z AP2 – protokołem Google z września 2025 roku, w którym klient wydaje agentowi podpisane cyfrowo upoważnienia: na zamiar zakupu (np. „kup, gdy cena spadnie poniżej X”) i na konkretny koszyk. To fundament przyszłych zakupów autonomicznych, choć przy starcie Universal Cart Google nie eksponował tej funkcji.

W ACP token wydaje operator płatności zgodny ze specyfikacją delegowanej płatności – w pierwszej kolejności Stripe. Sklep spoza ekosystemu Stripe musi sprawdzić, czy jego operator obsługuje ten model.

Dla polskiego sklepu wniosek jest prosty: pytanie „czy wdrożyć UCP czy ACP” w dużej mierze sprowadza się do pytania, co obsługuje Twój operator płatności i platforma sklepowa.

Który protokół wybrać: decyzja dla sklepu z Polski

Według stanu na październik 2026 żaden z protokołów nie daje polskiemu sklepowi natywnego checkoutu na rynku krajowym. Decyzja dotyczy więc przygotowania, a nie natychmiastowego wdrożenia.

1. Sprawdź, gdzie sprzedajesz. Jeśli wysyłasz do USA i masz tam ofertę w Merchant Center, UCP ma realne zastosowanie już teraz. Jeśli działasz tylko w Polsce, zacznij od danych.
2. Zapytaj dostawcę platformy. Sklepy Shopify w USA zostały we wrześniu 2026 automatycznie włączone do natywnego checkoutu Google. Dla platform popularnych w Polsce zapytaj o harmonogram obsługi UCP i ACP.
3. Zapytaj operatora płatności o obsługę tokenów Google Pay w modelu UCP i o delegowaną płatność ACP.
4. Uporządkuj feed w obu formatach. Merchant Center dla Google i feed w specyfikacji OpenAI wymagają podobnych danych. Wspólne źródło atrybutów ułatwia feed wielokanałowy z mapowaniem atrybutów, a braki można uzupełniać regułami feedu w Merchant Center.
5. Zaprojektuj pomiar przed integracją. Zamówienia z agentów powinny mieć w systemie sklepu znacznik kanału. Jak przesłać je do analityki, opisujemy w tekście o pomiarze sprzedaży z agentów AI.
6. Przygotuj API na ruch agentów. Endpointy koszyka i checkoutu muszą odpowiadać szybko i obsługiwać limity zapytań.

Szczegóły dotyczące koszyka Google dla sprzedawców spoza USA omawiamy w artykule o Universal Cart i checkoucie w AI Mode, a przygotowanie danych – w poradniku o feedzie i katalogu pod agentów AI.

Typowe błędy przy przygotowaniu integracji

Najczęstsze problemy nie wynikają z samych protokołów, tylko z danych i procesów po stronie sklepu.

Rozjazd cen między feedem a API. Agent pokazuje klientowi cenę z danych, a sesja checkoutu zwraca inną. W ACP transakcja zatrzyma się na etapie aktualizacji sesji, w UCP klient zobaczy inną cenę po przeniesieniu koszyka.

Brak informacji o dostawie i zwrotach w danych. W feedzie OpenAI puste pole kosztu dostawy oznacza „nieznany”, a nie „darmowy”. Polityki zwrotów warto podawać w atrybutach, a nie wyłącznie w regulaminie.

Zamówienia bez źródła. Jeśli system sklepu nie oznacza, że zamówienie przyszło przez agenta, w raportach trafi ono do ruchu bezpośredniego albo nie pojawi się w GA4 wcale. Dane zamówień warto wzbogacać po stronie serwera, co opisujemy w tekście o wzbogacaniu zdarzeń server-side.

Traktowanie integracji jako jednorazowej. Obie specyfikacje są wersjonowane i szybko się zmieniają. Wyznacz osobę, która śledzi nowe wersje i aktualizuje profil sklepu.

Jeśli zastanawiasz się, gdzie inwestować budżet reklamowy w asystentach AI, zestawienie formatów znajdziesz w porównaniu reklam w ChatGPT i Google AI Mode. Podstawy tematu, w tym poziomy autonomii agentów, wyjaśnia tekst czym jest agentic commerce, a wszystkie poradniki zebraliśmy w podtemacie Agentic commerce.