ACP, UCP i AP2 w porównaniu: protokoły agentic commerce w październiku 2026 i który z nich jest potrzebny Twojemu sklepowi

Trzy otwarte protokoły opisują dziś, jak agent AI kupuje w sklepie. Agentic Commerce Protocol (ACP) pochodzi od OpenAI i Stripe. Universal Commerce Protocol (UCP) pochodzi od Google i Shopify. Agent Payments Protocol (AP2), który zapoczątkował Google i w kwietniu przekazał FIDO Alliance, w ogóle nie jest protokołem checkoutu: definiuje podpisany dowód tego, że użytkownik autoryzował płatność, i został zaprojektowany tak, by działać wewnątrz UCP. Wszystkie trzy są udostępnione na licencji Apache 2.0.

Na 22 października 2026 każdy z nich jest w zupełnie innym stanie. ACP jest oznaczony jako wersja beta, jego najnowsze wydanie to 2026-04-17, a od 17 lipca nie trafił do niego żaden commit. ChatGPT, jego główny użytkownik, w marcu odszedł od samodzielnego checkoutu i dziś używa ACP głównie do odbierania danych produktowych. UCP opublikował w sierpniu wersję 2026-08-25, niezgodną wstecz, podczas gdy usługi samego Google wciąż działają na 2026-04-08, a jego checkout jest dostępny w programie wczesnego dostępu, tylko w USA. AP2 jest w wersji v0.2 i żaden produkt Google nie dokumentuje jego użycia.

Ten artykuł jest przeznaczony dla CTO i głównych deweloperów sklepów i platform e-commerce, którzy decydują, co wdrożyć. Jeśli chcesz wiedzieć, czego każda platforma AI wymaga od sklepu jako firmy, zacznij od naszego przeglądu agentic commerce.

Zestawienie

ACP: Agentic Commerce Protocol

Zarządzanie i wersje

Repozytorium specyfikacji podaje, że ACP utrzymują OpenAI i Stripe, i oznacza go jako wersję beta. Dokument o zarządzaniu nadaje obu firmom status Founding Maintainers: obsadzają miejsca w komitecie sterującym (do siedmiu) i zachowują weto, z którego mogą skorzystać „w ostateczności”. Meta dołączyła 24 kwietnia 2026 jako trzeci główny opiekun (lead maintainer) i członek komitetu. Dokumentacja Stripe nazywa ACP protokołem „stworzonym przez Stripe, OpenAI i Metę”, ale plik NOTICE w repozytorium wymienia tylko OpenAI i Stripe. Przekazanie protokołu neutralnej fundacji to na razie tylko deklarowany kierunek na przyszłość.

Jest pięć wydań oznaczonych datami: 2025-09-29 (checkout i delegowana płatność), 2025-12-12 (zmiany niezgodne wstecz, wynikające z doświadczeń z adapterami URBN i Etsy), 2026-01-16 (dostawca 3DS wybierany przez sprzedawcę), 2026-01-30 (negocjowanie możliwości, rozszerzenia i niezgodny wstecz framework payment handlerów) oraz 2026-04-17 (koszyk, feed, zamówienia, delegowane uwierzytelnianie, wykrywanie i MCP), które oznaczyło 2026-01-30 jako przestarzałe. Przez sześć miesięcy, które od tego czasu minęły, nie ukazało się żadne nowe wydanie. Folder unreleased/ zawiera drobniejsze zmiany z datami do 17 lipca, na przykład identyfikator aktualizacji feedu i opcjonalny URL produktu w pozycjach checkoutu.

Co sprzedawca wdraża w wersji 2026-04-17

API checkoutu hostuje sprzedawca, a wywołuje je agent:

• POST /checkout_sessions tworzy sesję, POST /checkout_sessions/{checkout_session_id} ją aktualizuje (POST, nie PUT), GET na tej samej ścieżce ją pobiera, a .../complete i .../cancel ją kończą.
• Zapytania zawierają klucz API jako bearer token i wymagany nagłówek API-Version. Od wersji 2026-04-17 każdy POST musi mieć Idempotency-Key, a błędy są zdefiniowane: 400 idempotency_key_required, 409 idempotency_in_flight i 422 idempotency_conflict.
• Zapytanie tworzące sesję zawiera obiekt capabilities. Agent deklaruje, co obsługuje, a sprzedawca zwraca część wspólną, więc niezgodność wychodzi na jaw jeszcze przed płatnością.
• Sprzedawca wysyła metodą POST zdarzenia zamówień do odbiornika hostowanego przez OpenAI pod /agentic_checkout/webhooks/order_events, podpisane HMAC-SHA256 w nagłówku Merchant-Signature. Statusy biegną od created do delivered lub canceled, a adjustments[] przenosi zwroty pieniędzy, zwroty towaru, spory i obciążenia zwrotne (chargebacki).

Wydanie 2026-04-17 dodało też statyczny, publiczny plik /.well-known/acp.json, którego pole transports informuje, czy sklep obsługuje rest, mcp, czy oba. Dodało powiązanie (binding) MCP przez Streamable HTTP z pięcioma narzędziami (create_checkout_session, get_checkout_session, update_checkout_session, complete_checkout_session, cancel_checkout_session), uwierzytelniane w konfiguracji serwera, a nie przy każdym zapytaniu. Dodało wreszcie Feed API, które hostuje agent, a do którego sprzedawca przesyła dane (POST /feeds, PATCH /feeds/{id}/products), koszyk jednego sprzedawcy bez danych płatniczych (POST /carts, PUT /carts/{id}) oraz delegowane uwierzytelnianie 3DS2 (POST /delegate_authentication). Subskrypcji nie ma: RFC dotyczące rozszerzeń wymienia subscription jako „obsługę rozliczeń cyklicznych (w przyszłości)”.

Jak działa płatność w ACP

Pierwotną odpowiedzią ACP jest delegowana płatność. PSP lub sejf kart (card vault) implementuje POST /agentic_commerce/delegate_payment, który zamienia kartę (jedyny typ danych płatniczych) w token, którego PSP sprzedawcy może użyć tylko w ramach ustalonego limitu: reason (wyłącznie one_time), max_amount, currency, checkout_session_id, merchant_id i expires_at. Jak ujmuje to RFC: „Płatności, rozliczenia i zgodność z przepisami pozostają w infrastrukturze sprzedawcy”. Worldpay dokumentuje własną wersję tego wywołania, a PayPal obsługuje ACP przez delegowane tokeny w Braintree.

Od wersji 2026-01-30 akceptowane metody deklaruje się jako handlery w capabilities.payment.handlers. Przykładowe dane płatności z changeloga:

{ "handler_id": "card_tokenized", "instrument": { "type": "card", "credential": { "type": "spt", "token": "spt_123" } } }

spt to Shared Payment Token od Stripe, dostępny „w USA, Kanadzie i wybranych krajach europejskich”. Sprzedawca korzystający ze Stripe obciąża go przez payment_method_data[shared_payment_granted_token] w wersji zapoznawczej (preview) API; sprzedawca korzystający z innego procesora może jednorazowo zamienić go na dane płatnicze sieci kartowej. Kto ponosi ryzyko, opisujemy w artykule o płatnościach agentowych.

Co zmienił marcowy ruch OpenAI

24 marca 2026 OpenAI napisało, że „pierwsza wersja Instant Checkout nie zapewniała takiej elastyczności, jaką chcemy oferować”, pozwoliło sprzedawcom korzystać z ich własnych checkoutów i dodało, że „rozszerza ACP, aby stał się warstwą łączącą sprzedawców i użytkowników na całym etapie odkrywania produktów”. Target, Sephora, Nordstrom, Lowe's, Best Buy, The Home Depot i Wayfair zintegrowały ACP na potrzeby odkrywania produktów, a katalogi sklepów z Shopify trafiają przez Shopify Catalog. Co to oznacza dla dewelopera:

• Działającą częścią jest feed. Strona OpenAI dla sprzedawców podaje, że zakupy „są finalizowane na stronach lub w aplikacjach należących do sprzedawców” i że funkcja zakupów działa dla użytkowników z USA. Dołączenie feedu jest otwarte dla zatwierdzonych partnerów z listy oczekujących: codzienny pełny plik przez SFTP z dziewięcioma polami wymaganymi, aktualizacje przez API w ciągu dnia, promocje wyłącznie przez API. Standardowy plik „jest obecnie przeznaczony dla USA”.
• Checkout wymaga osobnego dopuszczenia. Specyfikacja feedu mówi, że checkout „wymaga osobno włączanej integracji”. W przypadku aplikacji w ChatGPT ogólnie dostępną ścieżką jest zewnętrzny checkout we własnej domenie dewelopera. Arkusz płatności w czacie (payment sheet) to prywatna wersja beta „ograniczona do wybranych marketplace'ów”, która przekazuje token płatności do serwera MCP aplikacji w wywołaniu narzędzia complete_checkout.
• Strony OpenAI nie nadążają za specyfikacją. Dokumentacja referencyjna checkoutu OpenAI wciąż pokazuje API-Version 2025-09-12 i enum provider z wartościami stripe, adyen i braintree. Implementuj według repozytorium i potwierdź w OpenAI, którą wersję przyjmuje.

Strony PSP, które wciąż przedstawiają Instant Checkout jako działający, są nieaktualne.

UCP: Universal Commerce Protocol

Zarządzanie i wersje

Google uruchomił UCP 11 stycznia 2026; protokół powstał we współpracy z firmami Shopify, Etsy, Wayfair, Target i Walmart. Zasady zarządzania dają Google i Shopify po jednym stałym głosie w radzie zarządzającej, do której 28 kwietnia 2026 dołączył Stripe, i stanowią, że „Google dysponuje głosem w zastępstwie wszystkich nieobsadzonych miejsc do grudnia 2028”. 24 kwietnia rada Shopping Tech Council powiększyła się do 16 miejsc: dołączyły do niej Amazon, Meta, Microsoft, Salesforce i Stripe, więc Meta i Stripe zasiadają teraz zarówno w komitecie ACP, jak i w radzie UCP.

Repozytorium ma cztery wydania. 2026-04-08 dodało możliwości koszyka i katalogu, podpisywanie zapytań i odpowiedzi oraz Get Order. 2026-08-25 wprowadza zmiany niezgodne wstecz: signing_keys[] zastąpiono zbiorem JWK (JWK Set) w keys[], rozszerzenia płatności przeniesiono z dev.ucp.shopping.* do dev.ucp.common.payment.*, wspólne schematy zmieniły położenie i adresy URL w $id, a PAN i tokeny sieciowe stały się osobnymi typami danych płatniczych. Wydanie dodało też niezależne od dostawcy 3DS2, płatności dzielone (split payments), warunki płatności i interoperacyjność z Web Bot Auth.

Tu jest pułapka. Przewodnik Google po profilu obejmuje tylko 2026-04-08 i 2026-01-23, własny profil agenta Google pod ucp.goog deklaruje "version": "2026-04-08", a Salesforce B2C Commerce 26.9 obsługuje te same dwie wersje. Tymczasem Checkout MCP od Shopify linkuje do 2026-08-25. Jeśli zbudujesz integrację według najnowszego wydania, zbudujesz wersję, której Google nie dokumentuje. Odpowiedzią specyfikacji jest obiekt supported_versions, który przypisuje każdej starszej wersji osobny URI profilu.

Wykrywanie, transport i uwierzytelnianie

Każda firma publikuje pod /.well-known/ucp profil z polami ucp.version, ucp.services i ucp.payment_handlers, a Google wymaga, by był publiczny i dostępny bez uwierzytelniania. Platforma agenta również publikuje swój profil, a każde zapytanie przekazuje jego URI w nagłówku UCP-Agent, przez HTTPS z co najmniej TLS 1.3. Sposób uwierzytelniania wybiera firma: brak, X-API-Key, OAuth 2.0, mutual TLS albo HTTP Message Signatures według RFC 9421. Google wysyła bearer token, a jego FAQ dopuszcza też mTLS. Idempotency-Key ma w specyfikacji tylko status „SHOULD”; serwer, który go przyjmuje, przechowuje go co najmniej 24 godziny i odpowiada kodem 409, gdy klucz zostanie użyty ponownie z inną treścią zapytania.

Podstawowym transportem jest REST, obok MCP, rozszerzenia A2A i trybu osadzonego, do którego prowadzi continue_url. Zamówienia to GET /orders/{id} oraz webhook od firmy do platformy, podpisany zgodnie z RFC 9421. Ścieżki koszyka są takie same jak w ACP. Operacje checkoutu wyglądają podobnie, ale nie są wymienne:

Jeden rdzeń checkoutu może obsłużyć oba protokoły. Jedna tablica routingu już nie.

Jak działa płatność w UCP

UCP nie przesyła pieniędzy. Payment handler to specyfikacja napisana przez dostawcę danych płatniczych, na przykład com.google.pay dla Google Pay albo dev.shopify.shop_pay dla Shop Pay. Firma wymienia handlery, które akceptuje, platforma uruchamia jeden z nich, a przy complete firma otrzymuje nieprzezroczysty token, którym obciąża klienta przez własnego PSP.

W usługach Google jedynym handlerem jest Google Pay, jedyną używaną metodą uwierzytelniania jest PAN_ONLY, a Twój PSP „musi umieć przetwarzać nasze tokeny”. Stripe publikuje com.stripe.payments dla kart i Apple Pay: „Agent wysyła shared payment token (SPT) w zapytaniu Complete Checkout, a sprzedawca go obciąża”. Google Pay pozostaje przy własnym handlerze. PayPal obsługuje handler Google Pay przez Braintree albo przez swoje Orders v2 API.

Czego Google wymaga, zanim zacznie wywoływać Twoje API

Przewodnik Google po natywnym checkoucie wymaga API checkoutu w REST, a krok płatności zostawia po stronie Google: kupujący podaje dane wrażliwe „wyłącznie w interfejsie Google”. Wymagany poziom usług to co najmniej 95% dostępności każdego endpointu oraz opóźnienia p50 i p95 wynoszące 1 i 4 sekundy dla utworzenia, 1 i 5 dla aktualizacji oraz 6 i 10 dla finalizacji. Po złożeniu zamówienia przesyłasz aktualizacje statusu do webhooka Google, używając identyfikatora partnera i klucza wydanych przy dołączaniu. W Merchant Center każdy produkt musi mieć native_commerce(checkout_eligibility) ustawione na true (atrybut „domyślnie ma wartość FALSE”), zasady zwrotów i kontakt do obsługi klienta są obowiązkowe, a wykluczone są subskrypcje, sprzedaż na raty, produkty personalizowane, towary używane i odnowione, przedsprzedaż oraz towary z ograniczeniem wiekowym.

Lżejszą opcją, dostępną od 2026-04-08, jest przekazanie koszyka (cart transfer): implementujesz tylko tworzenie koszyka, Google przekazuje koszyk Twojej stronie i nie potrzebujesz ani payment handlera, ani webhooka zamówień.

Prawdziwym ograniczeniem jest dostęp. Checkout jest „dostępny dla wybranych sprzedawców” przez formularz zgłoszeniowy programu wczesnego dostępu, w którym zobowiązujesz się rozpocząć prace w ciągu 30 dni i akceptujesz, że dostęp „może zostać odebrany”, jeśli nie zrobisz postępów. Warunki UCP Checkout dotyczą „wyłącznie Stanów Zjednoczonych”. Hub w Merchant Center ma trafić do Australii i Kanady „na początku przyszłego roku”; dla żadnego innego kraju Google nie podaje daty uruchomienia checkoutu.

UCP poza Google

Microsoft Merchant Center przyjmuje w USA feedy przygotowane pod UCP od 21 kwietnia 2026. Copilot Checkout wymaga feedu zgodnego z UCP, przyjmuje anglojęzycznych sprzedawców, którzy sprzedają kupującym z USA w dolarach, każdego z jednym PSP, a ustawienie sklepu jest oznaczone jako „Pilotaż tylko dla wybranych klientów”. Shopify udostępnia UCP przez MCP pod https://{shop}/api/ucp/mcp i usunął swoje starsze narzędzia katalogu i koszyka. Możliwość rezerwacji noclegów została scalona jako wersja robocza 24 września 2026 i nie weszła do żadnego wydania.

AP2: Agent Payments Protocol

AP2 nie jest trzecim sposobem finalizacji zakupu. Jego specyfikacja mówi, że „działa jako funkcja bezpieczeństwa wewnątrz protokołu handlowego” i jest „zaprojektowany wprost z myślą o zgodności z Universal Commerce Protocol (UCP)”. Wersja 0.1.0 ukazała się 16 września 2025, a v0.2 28 kwietnia 2026, w dniu, w którym Google przekazał AP2 FIDO Alliance. Komunikat FIDO wymienia grupę roboczą Agentic Authentication oraz grupę roboczą Payments, której przewodniczą przedstawiciele firm Mastercard i Visa, i mówi, że przekazane materiały „zostaną przejrzane i dalej rozwinięte”. FIDO nie opublikowała żadnej specyfikacji AP2. Repozytorium na GitHubie przyjmuje teraz tylko przykłady i zmiany w SDK, a ostatni commit trafił do niego 29 kwietnia.

Wersja 0.2 definiuje Checkout Mandate (co jest kupowane) i Payment Mandate (płatność, z ograniczeniami takimi jak payment.amount_range, payment.budget i payment.allowed_payees). Każdy z nich jest tokenem SD-JWT w formie zamkniętej i otwartej (na przykład mandate.payment.1 i mandate.payment.open.1). W trybie Human Present użytkownik zatwierdza mandaty zamknięte. W trybie Human Not Present użytkownik zatwierdza mandaty otwarte, które wyznaczają ograniczenia i zawierają klucz publiczny agenta w claimie cnf, a agent składa w tych granicach mandaty zamknięte. Poradniki o Intent Mandates i Cart Mandates opisują v0.1; w v0.2 tych pojęć już nie ma.

Wewnątrz UCP AP2 jest rozszerzeniem dev.ucp.common.payment.ap2_mandate (przed 2026-08-25: dev.ucp.shopping.ap2_mandate). Po jego wynegocjowaniu firma podpisuje swoje odpowiedzi checkoutu, platforma przedstawia przy complete obiekty checkout_mandate i payment_mandate, a sesja ma status „Security Locked”: żadna ze stron nie może wrócić do zwykłego checkoutu.

Na razie nikt go nie wymaga. FAQ Google nazywa AP2 „szczególnie przydatnym w przyszłych scenariuszach obejmujących transakcje autonomicznych agentów AI”. Własny profil agenta Google wymienia Google Pay jako jedyny payment handler i nie deklaruje możliwości AP2, a jego profil 2026-08-25 również nie ma wpisu AP2. Żaden produkt Google nie dokumentuje korzystania z AP2, więc sprzedawca nie ma czego budować, dopóki jakaś platforma go nie wynegocjuje.

Protokoły pokrewne

MCP

Zarówno ACP, jak i UCP mogą działać przez MCP, którego aktualna specyfikacja, 2026-07-28, usuwa sesje i nagłówek Mcp-Session-Id, rezygnuje z handshake'u initialize, wymaga server/discover i każe klientowi ponowić zapytanie pod nowym ID, gdy jego strumień się zerwie. Powiązanie ACP wciąż linkuje do transportu 2025-11-25. Identyfikator sesji checkoutu to dokładnie taki uchwyt wydawany przez serwer, jakiego oczekuje nowa specyfikacja, a complete utracone w połowie strumienia wraca jako nowe zapytanie: traktuj klucze idempotencji jako obowiązkowe w obu protokołach.

WebMCP

WebMCP to proponowany standard sieciowy do udostępniania własnych funkcji strony agentom działającym w przeglądarce. Shopify oferuje checkout UCP zarówno jako Checkout MCP, jak i jako Checkout WebMCP, z tym samym obiektem checkoutu, i zaleca Checkout MCP. Obecny stan WebMCP opisuje nasz przewodnik po WebMCP.

x402 i MPP

x402 i zaprojektowany przez Tempo i Stripe Machine Payments Protocol pobierają od agenta opłatę za każde zapytanie HTTP do API, danych lub treści. Nie są to protokoły checkoutu sklepu. Więcej w naszym artykule o x402.

Visa Trusted Agent Protocol i Mastercard Agent Pay

Działają obok ACP i UCP, a nie zamiast nich. Trusted Agent Protocol organizacji Visa daje agentowi „ustandaryzowaną, kryptograficzną metodę” potwierdzenia wobec sprzedawców swojej tożsamości i upoważnienia, a Mastercard Agent Pay to program tokenizacji dla agentic commerce. Przewodnik dla sprzedawców organizacji Mastercard umieszcza UCP i ACP na najwyższym poziomie gotowości, zaznacza, że „Pierwsi wdrażający są obecnie w trakcie integracji”, i radzi sprzedawcom zacząć od dwóch prostszych poziomów. Oba programy opisuje nasz artykuł o płatnościach agentowych.

Personal Agent Protocol

Sierra podaje, że 6 października 2026 ogłosiła wspólnie z Metą Personal Agent Protocol („Poppy”), a 9 października opublikowała jego wersję roboczą. Firma publikuje jeden plik pod /.well-known/poppy.json; protokół wykorzystuje OAuth, JWT, HTTPS, OpenAPI i MCP, aby osobisty agent mógł się przedstawić i uzyskać zgodę klienta na dowolny rodzaj zadania, a Sierra określa go jako uzupełnienie UCP. Strona protokołu pokazuje wersję 0.2 i informuje: „To wersja robocza”. W serwisie prasowym samej Mety nie znaleźliśmy żadnego wpisu na ten temat.

Który protokół jest Ci potrzebny?

Na Shopify

Nie musisz nic budować. Funkcja agentic storefronts w Shopify jest „domyślnie aktywna w kwalifikujących się sklepach”. ChatGPT otrzymuje Twój katalog przez Shopify Catalog i kieruje kupujących do Twojego sklepu. Bezpośredni checkout Google jest domyślnie włączony dla sklepów z siedzibą w USA, które sprzedają do USA, a Copilot zapisał sprzedawców z Shopify automatycznie. Do Ciebie należą decyzje o danych produktowych i o tym, czy zostawić bezpośredni checkout włączony, ze świadomością, że niestandardowe piksele (custom pixels) nie uruchamiają się w checkoucie Google.

Na Salesforce, commercetools lub innej platformie

Salesforce B2C Commerce 26.9 obsługuje UCP w wersjach 2026-01-23 i 2026-04-08: /.well-known/ucp z mapą supported_versions oraz endpointy sesji checkoutu za tokenem SLAS. Salesforce wymienia checkout UCP w Google jako ogólnie dostępny w październiku 2026. Sesja to widok koszyka w trybie headless, a przewodnik audytowy Salesforce ostrzega, że kontrolery SFRA i SiteGenesis oraz „inne zasoby SCAPI, których dziś używasz, nie działają w tym przepływie”, więc przypiętą do nich logikę trzeba skopiować albo połączyć mostkiem z hookami sesji checkoutu UCP. Feed musi być przeznaczony dla en-US, a Salesforce „nie omija listy oczekujących Google”. W przypadku ChatGPT Salesforce jest jedną ze ścieżek dostarczania feedów ACP, które wymienia OpenAI.

Na commercetools lub innej platformie zapytaj dostawcę, które wersje i możliwości UCP obsługuje, które z Twoich hooków działają w checkoucie agenta i czy wysyła feedy do OpenAI.

Na własnym oprogramowaniu

1. Najpierw feedy. Google Merchant Center, a gdy OpenAI Cię przyjmie, także jego feed produktowy. Dzisiejsze komercyjne zastosowanie ACP w ChatGPT to właśnie to.
2. UCP dla Google, jeśli sprzedajesz w USA i Google Cię przyjmie. Implementuj wersję 2026-04-08: profil z com.google.pay, operacje checkoutu mieszczące się w docelowych czasach odpowiedzi Google, PSP, który przetwarza tokeny Google Pay, webhook zamówień i atrybut feedu. Albo zacznij od samego przekazania koszyka.
3. Checkout ACP tylko wtedy, gdy masz powód, na przykład aplikację w ChatGPT przyjętą do wersji beta arkusza płatności. Implementuj wersję 2026-04-17 z repozytorium.
4. AP2: na razie nic.
5. Jeden rdzeń checkoutu. Oba protokoły wymagają sesji, którą można przez API utworzyć, aktualizować, sfinalizować i anulować oraz bezpiecznie ponowić. Zbuduj ją raz na bazie swojej logiki zamówień, podatków i płatności, z cienkimi adapterami ACP i UCP na wierzchu i MCP tam, gdzie potrzebują go agenci.

Żaden z protokołów nie daje dziś firmie subskrypcyjnej natywnego checkoutu dla agentów.

Sprzedaż wyłącznie poza Stanami Zjednoczonymi

Żaden z trzech protokołów nie daje Ci dziś checkoutu dla agentów. Zakupy w ChatGPT i standardowe przesyłanie feedu do OpenAI dotyczą USA; warunki UCP Checkout od Google obejmują wyłącznie USA; Copilot Checkout obsługuje kupujących z USA płacących w dolarach. Następnym zapowiedzianym krokiem Google jest hub w Merchant Center w Australii i Kanadzie „na początku przyszłego roku”, bez daty dla Wielkiej Brytanii ani UE.

Dbaj o kompletność feedu w Merchant Center, a jeśli i tak przebudowujesz checkout, zbuduj opisany wyżej rdzeń sterowany przez API, żeby adapter był niewielką pracą, gdy Twój rynek zostanie otwarty. Sprzedajesz do USA z zagranicy? Sprawdź, gdzie według każdego programu musi mieć siedzibę sprzedawca; bezpośredni checkout Google przez Shopify wymaga na przykład sklepu z USA.

Gdzie szukać pomocy

Budujemy warstwę protokołów dla sklepów, które nie działają na Shopify: profil /.well-known/ucp i endpointy sesji checkoutu na bazie Twojej istniejącej logiki zamówień, podatków i płatności, webhooki zamówień do Google, feedy produktowe dla Google Merchant Center i OpenAI oraz serwery MCP, które udostępniają agentom ten sam checkout. Ta praca zaczyna się od naszej usługi tworzenia agentów AI i integracji z serwerami MCP.

Napisz na office@c9group.dev, na jakiej platformie działasz, z jakiego operatora płatności korzystasz i w jakich krajach sprzedajesz, a powiemy Ci, który protokół Cię dotyczy i czego wymagałoby jego wdrożenie. Warunki programów Google i OpenAI to umowy: jesteśmy inżynierami, nie prawnikami, więc zanim je podpiszesz, daj je do przeczytania doradcy.