Agentic checkout

TL;DR — Agentic checkout to część zakupów AI „kliknij kup za mnie”. Gdy asystent znajduje produkt i finalizuje zakup, ten końcowy etap transakcji jest agentic checkout. W przepływie delegowanej płatności OpenAI agent używa tokenu płatniczego o ograniczonym zakresie zamiast numeru karty, a przy logowaniu lub dodatkowej weryfikacji zatrzymuje się i oddaje stery człowiekowi. To element większych protokołów (ACP i UCP), a nie osobny standard.

Czym jest agentic checkout

Większość „zakupów AI” dotyczy odkrywania: prosisz asystenta o znalezienie produktu, a on czyta feedy produktowe sprzedawców i podsuwa opcje. Agentic checkout jest kolejnym krokiem — etapem, w którym agent tworzy zamówienie, wybiera dostawę, oblicza podatek i koszt wysyłki, przekazuje płatność oraz kończy zakup.

Kluczowe słowo to etap. Agentic checkout nie jest osobnym produktem ani firmą. To możliwość finalizowania transakcji wbudowana w dwa duże standardy handlu agentowego — Agentic Commerce Protocol (ACP) OpenAI i Stripe oraz Universal Commerce Protocol (UCP) Google i Shopify. Ta strona skupia się wyłącznie na mechanice checkoutu.

Trzy częste nieporozumienia

• „AI kupuje bez udziału człowieka”. Niekoniecznie. Oba protokoły mają wbudowany moment „zatrzymaj się i poproś człowieka” — przy logowaniu, dodatkowej weryfikacji karty lub potwierdzeniu. Specyfikacje nie zakładają całkowicie bezobsługowego checkoutu.
• „AI widzi moją kartę kredytową”. Nie. Płatność przechodzi jako token o ograniczonym zakresie, związany z jednym sprzedawcą, kwotą i oknem czasowym, możliwy do użycia tylko raz. Numer karty nie trafia do agenta.
• „To już norma — większość sklepów to ma”. Nie. W połowie 2026 r. było wcześnie: przed ograniczeniem przez OpenAI w marcu 2026 r. wersji zakupów w całości w czacie tylko około tuzina sklepów Shopify uruchomiło checkout ChatGPT.

Kto odpowiada, gdy coś pójdzie nie tak?

Sklep, w którym kupujesz, nadal jest sprzedawcą — to merchant of record. Obsługuje zamówienia, zwroty i spory tak jak przy zwykłym zakupie online. Naprawdę trudne pytanie dotyczy sporu obciążenia, gdy „kupującym” był agent AI. Więcej o tym jest w karcie Advanced.

Chcesz zobaczyć maszynę stanów, zakres tokenów płatniczych, miejsca interwencji człowieka i testy, które sprzedawca musi wykonać przed uruchomieniem? Przejdź do Advanced.

TL;DR — Agentic checkout to możliwość finalizowania transakcji w handlu agentowym: utworzenie, aktualizacja, zakończenie lub anulowanie sesji checkoutu, delegowanie płatności i potwierdzenie zamówienia. To element ACP i UCP, nie samodzielny protokół. Techniczny kręgosłup stanowi maszyna stanów: ACP prowadzi sesję przez not_ready_for_payment → ready_for_payment → (requires_escalation/authentication_required, gdy trzeba) → completed, podobnie jak UCP: incomplete → requires_escalation → ready_for_complete. Stany eskalacji są zaprojektowanym miejscem udziału człowieka. Delegowanie płatności używa tokenów związanych ze sprzedawcą, limitem kwoty, czasem i jednym użyciem, więc agent nie posiada surowej karty. Potwierdzenie zamówienia jest wypychane: sprzedawcy wysyłają podpisane HMAC-em webhooki pełnego obiektu. Sprzedawca pozostaje merchant-of-record, więc rozliczenia, zwroty i chargebacki są po jego stronie i po stronie PSP; nadal nie ma ustalonego sposobu dowodzenia sporów obciążeń AI w połowie 2026 r. Przed uruchomieniem testuj bezpieczne ponowienia idempotentne, podpisy webhooków i ścieżki eskalacji.

Zakres: etap transakcji, nie cały protokół

Agentic checkout to jedna możliwość. W ACP jest dosłownie blokiem Agentic Checkout — jednym z pięciu obok Product Feed, Delegate Payment, Delegate Authentication i Orders/Webhooks. W UCP jest możliwością checkoutu w szerszej specyfikacji negocjującej możliwości. Powiązane artykuły omawiają protokół i kontekst biznesowy, w tym jakość feedu i profil /.well-known/ucp. Ta strona pozostaje przy mechanice finalizowania transakcji: cyklu życia sesji, delegowaniu płatności, interwencji człowieka, potwierdzeniu zamówienia i odpowiedzialności.

Warto zachować jedno założenie z artykułu o ACP: agenci transakcjonują z feedami i API, a nie z crawlowanym HTML-em. Optymalizuje się więc niezawodność checkoutu, a nie tekst strony.

Maszyna stanów sesji checkoutu

Najważniejsze, a często pomijane, jest to, że checkout jest sesją ze statusem, który przechodzi przez zdefiniowaną maszynę.

Referencja Checkout ACP wymienia pełny enum: incomplete, not_ready_for_payment, requires_escalation, authentication_required, ready_for_payment, pending_approval, complete_in_progress, completed, canceled, in_progress i expired. Szczęśliwa ścieżka to not_ready_for_payment → ready_for_payment → in_progress → completed, a drugim stanem końcowym jest canceled. Wymagana opcja realizacji zamówienia przenosi sesję z not_ready_for_payment do ready_for_payment; nieudana płatność może cofnąć ją do ready_for_payment w celu ponowienia.

Najciekawsze są stany, które nie należą do szczęśliwej ścieżki:

• requires_escalation/authentication_required — agent nie może działać sam; potrzebny jest człowiek lub dodatkowa weryfikacja.
• pending_approval — oczekiwanie na zgodę, na przykład akceptację zamówienia B2B.
• expired — sesja wygasła (CheckoutSession zawiera expires_at).

To ten sam projekt co checkout UCP: incomplete → requires_escalation → ready_for_complete, przy czym requires_escalation oddaje stery człowiekowi przez continue_url. Dwa protokoły, jeden wzorzec: checkout nie zawsze kończy się bez zatrzymania i poproszenia człowieka o działanie. To nie doczepione ograniczenie, lecz podstawowy kształt projektu.

Praktyczna uwaga dla integrujących ACP: niepoprawne żądanie zwraca obiekt błędu na poziomie HTTP (type z wartościami invalid_request, request_not_idempotent, processing_error albo service_unavailable). Problem logiki biznesowej w poprawnej sesji wraca natomiast jako obiekt MessageError w tablicy messages[], a nie jako błąd HTTP. Trzeba obsłużyć oba przypadki, bo na początku integracji łatwo je pomylić.

Jak działa delegowanie płatności

Celem warstwy delegowania jest to, aby surowe dane karty nigdy nie trafiały do agenta. Zamiast numeru karty kupującego agent otrzymuje token o ograniczonym zakresie.

Zgodnie ze specyfikacją Delegated Payment OpenAI payload delegowanej płatności trafia bezpośrednio do PSP lub vaultu sprzedawcy, a ten zwraca token związany z delegowaną płatnością poza zakresem PCI. Token ma cztery ograniczenia:

• reason — obecnie "one_time": jedno użycie.
• max_amount — ogranicza obciążenie do sumy checkoutu; token nie może posłużyć do zawyżenia kwoty.
• expires_at (RFC 3339) — token ma twardy termin wygaśnięcia.
• merchant_id + checkout_session_id — jest związany z jednym sprzedawcą i jedną sesją.

Token delegowany jest więc związany ze sprzedawcą, ograniczony kwotą, czasem i jednorazowy. Agent może „wydać pieniądze”, nie otrzymując wielokrotnego poświadczenia karty. Po stronie ACP Shared Payment Token Stripe jest pierwszą implementacją zgodną z Delegated Payment Spec, a kolejne PSP mają dołączyć. UCP używa równoległego, rozdzielonego modelu instrumentów i handlerów.

Zakres PCI to realna decyzja architektoniczna. Specyfikacja OpenAI mówi wprost, że bezpośrednia integracja z Delegated Payment Spec oznacza obsługę danych posiadacza karty i może zmienić zakres PCI; bezpośrednia integracja wymaga statusu PCI DSS Level 1. Dla większości sprzedawców tokenizacja przez PSP pozwala pozostawić dane karty poza ich środowiskiem. Decyzję „obsługujemy CHD bezpośrednio czy tokenizuje je PSP?” pomaga podjąć karta Decision.

Gdzie człowiek nadal musi wkroczyć

„Kupujący nadal autoryzuje transakcję” jest prawdą, ale zbyt ogólną. Konkretne wyzwalacze protokołu trzeba nazwać, aby zaprojektować przekazanie zamiast trafić w cichą ślepą uliczkę:

• 3-D Secure / step-up. ACP opisuje to przez InterventionCapabilities (obsługiwane typy obejmują 3ds i address_verification), poziom enforcement (always/conditional/optional) oraz display_context (native/webview/modal/redirect). Wynik wraca jako AuthenticationResult z wartościami authenticated, denied, rejected, abandoned, canceled lub not_supported.
• Stany requires_escalation/authentication_required. Mówią, że przed dalszym krokiem potrzebny jest człowiek albo dodatkowa kontrola.
• B2B approval_required. Obiekt PaymentData zawiera pola B2B (purchase_order_number, payment_terms, due_date, approval_required); agentic checkout nie dotyczy wyłącznie DTC.
• Przekazanie UCP przez continue_url. UCP udostępnia adres, pod którym kupujący sam kończy logowanie, potwierdzenie lub kontrolę wieku.

Wniosek: transakcja, która poprawnie eskaluje, jest znacznie lepsza niż taka, która kończy się cicho. Projektuj ścieżki eskalacji jako pierwszoplanowe przepływy, nie przypadki błędne.

Potwierdzenie zamówienia jest wypychane, nie odpytywane

Po zakupie platforma agenta nie powinna bez końca odpytywać API sprzedawcy o status zamówienia. Sprzedawca wysyła podpisane webhooki.

Według referencji webhooków ACP sprzedawcy wysyłają zdarzenia zamówień, aby platforma agenta miała aktualny stan realizacji. Są dwa typy: order_create dla nowych zamówień i order_update dla zmian. Statusy obejmują created, manual_review, confirmed, canceled, shipped i fulfilled. W implementacji liczą się trzy rzeczy:

• Żądania muszą być podpisane HMAC-em w nagłówku Merchant-Signature. Niepodpisane lub źle podpisane dostają 401.
• Pole data zawiera pełny obiekt Order, nie przyrostową różnicę. Za każdym razem wysyłasz cały stan.
• Obsługiwane kody: 200 powodzenie, 401 błędny podpis, 429 ograniczenie częstotliwości.

Na pytanie „skąd platforma wie, że zamówienie przeszło?” odpowiedź jest konkretna: Ty jej mówisz — podpisanym POST-em pełnego obiektu — i obsługujesz jej 429 jako sygnał przeciążenia.

Oszustwa, chargebacki i odpowiedzialność — co ustalone, a co otwarte

To najbardziej uczciwa i wyróżniająca sekcja: trzeba jasno oddzielić to, co ustalone, od tego, co nadal otwarte.

Ustalone: merchant of record. Specyfikacja płatności OpenAI mówi, że OpenAI nie jest merchant of record; w ACP sprzedawcy wybierają własnego PSP, a rozliczenia, zwroty, chargebacki i zgodność pozostają po stronie sprzedawcy oraz jego PSP. Niezależnie potwierdza to Arjun Bhargava z Rye: oba protokoły zostawiają sprzedawcę jako merchant of record odpowiedzialny za realizację, chargebacki i spory.

Nieustalone: dowody w sporach obciążeń. Merchant of record mówi, kto domyślnie ponosi spór, ale nie jak go wygrać, gdy „klientem” pośredniczył agent AI. Tradycyjna obrona opiera się na śladach człowieka (IP, urządzenie, przeglądanie, kliknięcie „kup”), a logi autoryzacji agenta są innym rodzajem dowodu. Reguły sieci kart nie powstały dla takiego modelu; specjaliści Chargeflow mówią wprost, że nie ma jeszcze prostych odpowiedzi.

Powstające ramy dopiero powstają. Trusted Agent Protocol Visa ma pozwalać sprzedawcom weryfikować tożsamość i intencję agenta w czasie rzeczywistym. Agent Pay Mastercard (ogłoszony w kwietniu 2025 r.) używa „Agentic Tokens”. Doniesienia Fintech Wrap Up/Finextra przypisują Mastercard zasady odpowiedzialności jak przy zwykłej tokenizacji, lecz traktuj to jako relację, nie potwierdzoną dokumentację Mastercard. Gwarancja zero odpowiedzialności Visa chroni posiadaczy kart przed nieautoryzowanymi obciążeniami, ale nie rozwiązuje sporu po stronie sprzedawcy.

Co sprzedawcy muszą wdrożyć i przetestować

Istniejące materiały radzą, jak przygotować feedy i programy lojalnościowe. Poniżej warstwa operacyjna — co zbudować i sprawdzić przed uruchomieniem:

• Wybierz podejście PCI. Tokenizacja sieciowa/PSP albo bezpośrednia obsługa CHD (Level 1); większość sprzedawców powinna powierzyć delegowanie PSP.
• Zabezpiecz ponowienia idempotencją. Błąd request_not_idempotent istnieje nie bez powodu. Agent lub niestabilna sieć ponowi wywołanie; użyj klucza idempotencji, aby nie podwójnie obciążać ani tworzyć zamówień.
• Weryfikuj podpisy webhooków. Sprawdzaj HMAC Merchant-Signature, odrzucaj rozbieżności i poprawnie zwracaj 200/429.
• Symuluj eskalację w sandboxie. Wymuś requires_escalation/ authentication_required, przejdź 3DS i obsłuż denied/rejected/ abandoned, nie tylko authenticated.
• Wyrównaj ceny feedu i checkoutu. Różne ceny szybko niszczą zaufanie.
• Zbuduj atrybucję zamówień agentowych. Gotowy checkout może nie mieć sesji GA4; śledź go na poziomie zamówienia/OMS.

Karty Testing SOP i Cheat Sheet zamieniają te zalecenia w konkretny przebieg.

Stan w połowie 2026 r.

Trzymaj się realiów adopcji, nie slajdów sprzedażowych. Prezes Shopify Harley Finkelstein wskazał około tuzina sprzedawców Shopify używających narzędzi AI — znikomy odsetek całej bazy. OpenAI w marcu 2026 r. ograniczyło w pełni czatową wersję Instant Checkout do odkrywania i przekierowania po problemach z onboardingiem, dokładnością i koszykami wielopozycyjnymi. Leigh McKenzie z Semrush trafnie opisała tarcie: normalizacja katalogów w czasie rzeczywistym dla dziesiątek milionów SKU to problem na dekadę, a konsumenci nadal wybierają zaufane checkouty, takie jak Apple Pay, Google Wallet i Amazon one-click.

To nie znaczy, że agentic checkout jest fikcją. Możliwość protokołu — programowe tworzenie, aktualizacja i kończenie sesji z delegowaną płatnością oraz podpisanymi webhookami zamówień — jest realna i opisana. Nie jest jednak „już normą”, a to, czy etap końcowy zamknie się w czacie czy na stronie sklepu, jest szczegółem implementacyjnym, który już raz się zmienił i może zmienić się ponownie.

Podsumowanie AI

Skrócona wersja wariantu Advanced:

• Agentic checkout to etap finalizacji transakcji: agent tworzy, aktualizuje, kończy lub anuluje sesję checkoutu za kupującego. To element ACP i UCP, nie samodzielny protokół.
• To maszyna stanów. ACP: not_ready_for_payment → ready_for_payment → (requires_escalation/authentication_required) → completed, a poza ścieżką są canceled, expired, pending_approval. UCP ma incomplete → requires_escalation → ready_for_complete.
• Eskalacja to miejsce udziału człowieka: logowanie, 3DS, kontrola adresu, B2B approval_required, UCP continue_url.
• Płatność = token o ograniczonym zakresie: merchant_id + checkout_session_id, limit max_amount, termin expires_at, jedno użycie (reason: one_time). Agent nie posiada surowej karty; obsługa CHD bezpośrednio wpływa na PCI (Level 1).
• Potwierdzenie zamówienia jest wypychane: podpisane HMAC-em webhooki order_create/order_update, pełny obiekt z nagłówkiem Merchant-Signature, kody 200/401/429.
• Odpowiedzialność: sprzedawca pozostaje merchant-of-record, lecz dowody w sporach obciążeń agentów AI są w połowie 2026 r. nierozstrzygnięte. Visa TAP i Mastercard Agent Pay to ramy dopiero powstające.
• Testuj: bezpieczne idempotentne ponowienia (request_not_idempotent), podpisy webhooków, eskalację/3DS, zgodność cen i atrybucję zamówienia.
• Adopcja jest wczesna: około tuzina aktywnych sprzedawców Shopify przed zmianą OpenAI w marcu 2026 r. na odkrywanie i przekierowanie.

Dokumentacja oficjalna

Dokumentacja źródeł pierwotnych dotycząca mechaniki checkoutu.

ACP — checkout, cykl życia i webhooki

• ACP Checkout API reference — endpointy sesji, pełny enum statusu, pola CheckoutSession, błędy i MessageError, RiskSignals, AuthenticationResult oraz InterventionCapabilities.
• ACP Checkout lifecycle / concepts — przejścia stanów (opcja realizacji → ready_for_payment) i ponowienie nieudanej płatności.
• ACP Order webhooks — order_create/order_update, podpis Merchant-Signature, pełny payload i kody odpowiedzi.
• ACP spec on GitHub — OpenAPI/JSON Schema i wersje datowane.

OpenAI / Stripe — delegowanie płatności

• OpenAI Delegated Payment spec — token, obiekt allowance (max_amount, expires_at, merchant_id, checkout_session_id, reason), zakres PCI i merchant-of-record.
• OpenAI Commerce docs — omówienie integracji sprzedawcy.
• Stripe — Agentic Commerce (ACP) — Shared Payment Token.
• Stripe — ACP protocol specification — budowanie endpointów checkoutu.

UCP (równoległa maszyna checkoutu)

• Google for Developers — przewodnik UCP — model merchant-of-record i kryteria kwalifikacji po stronie Google/Shopify.

Platforma i sieć płatnicza

• Shopify — Agentic Storefronts requirements — Supplemental Terms i status wczesnego dostępu Google AI Mode/Gemini.
• Visa — handel agentowy: zagrożenia i ryzyka — Trusted Agent Protocol.

Cytaty ze źródła

Udokumentowane wypowiedzi o działaniu agentic checkout i nierozstrzygniętych pytaniach. Odnośniki prowadzą do miejsc, w których źródła wspierają cytaty.

ACP / OpenAI — specyfikacja

• “Merchant maintains full control over inventory, pricing, tax calculations, and payment processing.” (tłumaczenie) „Sprzedawca zachowuje pełną kontrolę nad zapasami, cenami, obliczeniami podatków i przetwarzaniem płatności.” — referencja API ACP. Przejdź do cytatu
• Enum statusu checkoutu, dosłownie: “incomplete not_ready_for_payment requires_escalation authentication_required ready_for_payment pending_approval complete_in_progress completed canceled in_progress expired.” (tłumaczenie) „Lista oznacza: niekompletny, niegotowy do płatności, wymagana eskalacja, wymagana autoryzacja, gotowy do płatności, oczekiwanie na akceptację, finalizacja w toku, zakończony, anulowany, w toku i wygasły.” — referencja API ACP. Przejdź do cytatu
• “OpenAI is not the merchant of record.” (tłumaczenie) „OpenAI nie jest merchant of record.” W ACP sprzedawcy wybierają własnego PSP, a rozliczenia, zwroty, chargebacki i zgodność pozostają po ich stronie. — OpenAI Delegated Payment spec. Przejdź do cytatu
• W przepływie tokenu PSP lub vault zwraca “payment token scoped to the delegated payment” (tłumaczenie) „token płatniczy o zakresie ograniczonym do delegowanej płatności” poza zakresem PCI. Przejdź do cytatu

Głosy branży — pytanie o odpowiedzialność

• “Agentic commerce brings efficiency, but also a new layer of fraud and confusion that legacy systems cannot interpret.” (tłumaczenie) „Handel agentowy zwiększa wydajność, ale wnosi też nową warstwę oszustw i zamieszania, której starsze systemy nie potrafią interpretować.” — Ben Herut, Chargeflow.
• Według analizy Chargeflow o ustaleniu zasad: “there are no clean answers yet” (tłumaczenie) „nie ma jeszcze prostych odpowiedzi” — sieci kart, wydawcy i dostawcy platform nadal pracują nad tymi pytaniami.
• “Both protocols keep the merchant as the merchant of record — responsible for fulfillment, chargebacks, and disputes.” (tłumaczenie) „Oba protokoły pozostawiają sprzedawcę jako merchant of record — odpowiedzialnego za realizację, chargebacki i spory.” — Arjun Bhargava, Rye. Przeczytaj relację Przeczytaj relację

Sieci płatnicze — powstające ramy

• O podejściu Visa: Trusted Agent Protocol to “a standards-based framework enabling merchants to verify agent identity and intent in real time, preventing impersonation without degrading user experience.” (tłumaczenie) „oparte na standardach ramy pozwalające sprzedawcom weryfikować tożsamość i intencję agenta w czasie rzeczywistym, zapobiegając podszywaniu się bez pogorszenia doświadczenia użytkownika.” — Visa, handel agentowy: zagrożenia i ryzyka. Przejdź do cytatu

Realność adopcji

• O tym, dlaczego checkout w pełni autonomiczny jest wolniejszy niż nagłówki: “Real-time catalog normalization across tens of millions of SKUs is a decade-scale problem Google already solved with Merchant Center, and consumers still default to checkout flows they trust—Apple Pay, Google Wallet, and Amazon one-click.” (tłumaczenie) „Normalizacja katalogu w czasie rzeczywistym dla dziesiątek milionów SKU to problem na skalę dekady, który Google rozwiązało już w Merchant Center, a konsumenci nadal wybierają zaufane checkouty — Apple Pay, Google Wallet i Amazon one-click.” — Leigh McKenzie, Semrush, przez Search Engine Land. Przeczytaj relację

Którą ścieżkę integracji płatności wybrać?

Pierwsza decyzja architektoniczna dotyczy tego, jak delegować płatność, bo bezpośrednio określa zakres PCI i ilość pracy. Przejdź przez drzewo.

Test przed uruchomieniem agentic checkout

Wykonaj go w trybie sandbox/test przed włączeniem checkoutu agentowego w produkcji. To warstwa operacyjna pomijana przez strategiczne rady o „czystym feedzie”.

1. Utwórz sesję i przejdź szczęśliwą ścieżkę. POST /checkout_sessions, potwierdź 201 i status not_ready_for_payment lub incomplete. Dodaj opcję realizacji i potwierdź przejście do ready_for_payment.
2. Zweryfikuj sumy. totals[] (subtotal, podatek, realizacja, rabaty, total) muszą zgadzać się z backendem i feedem.
3. Zakończ sesję. POST /checkout_sessions/{id}/complete; potwierdź płatność, zamówienie i status completed.
4. Anuluj sesję. POST /checkout_sessions/{id}/cancel; potwierdź zwolnienie zapasu.
5. Wymuś eskalację. Zasymuluj requires_escalation/authentication_required, wykonaj 3DS, potwierdź ścieżkę authenticated i sprawdź AuthenticationResult: denied, rejected, abandoned, canceled, not_supported.
6. Testuj idempotencję. Wyślij ten sam request dwa razy z tym samym kluczem; oczekuj jednego zamówienia, a nie podwójnego obciążenia; błędna próba powinna ujawnić request_not_idempotent.
7. Rozdziel błędy logiki i HTTP. Problem sesji powinien wrócić jako MessageError w messages[], a wadliwe żądanie jako obiekt błędu HTTP.
8. Weryfikuj podpisy webhooków. Poprawny order_create ma przejść z HMAC Merchant-Signature i zwrócić 200; zmieniony ma zostać odrzucony jako 401. Wysyłaj pełny obiekt Order.
9. Testuj back-pressure webhooków. Przy 429 zastosuj ponowienie z backoffem.
10. Potwierdź atrybucję. Oznacz zamówienie jako agentowe na poziomie OMS, bo nie będzie dla niego sesji GA4.

Częste błędy (i właściwe rozwiązania)

Założenie, że agentic checkout oznacza zakup w pełni autonomiczny. Dlaczego to błąd: każda wiarygodna implementacja ma miejsce autoryzacji/eskalacji — requires_escalation, authentication_required, 3DS i B2B approval_required. Zamiast tego projektuj continue_url, 3DS i akceptację jako pierwszoplanowe przepływy, aby transakcja z udziałem człowieka nie kończyła się ślepą uliczką.

Traktowanie tego jako normy, bo nagłówki są głośne. Dlaczego to błąd: przed wycofaniem wersji czatowej przez OpenAI w marcu 2026 r. aktywny checkout ChatGPT miało tylko około tuzina sklepów Shopify. Zamiast tego buduj na realnej możliwości protokołu i planuj jak wczesny użytkownik.

Założenie, że odpowiedzialność za oszustwa jest rozwiązana, bo merchant-of-record jest ustalony. Sprzedawca jest stroną rozliczeń, zwrotów i zgodności, ale dowody w sporze o zakup wykonany przez agenta AI pozostają nierozwiązane. Zbieraj logi autoryzacji i sygnały ryzyka; Visa TAP i Mastercard Agent Pay są dopiero powstającymi ramami.

Założenie, że agent omija witrynę, więc checkout na stronie nie ma znaczenia. Hasło „zawsze omija stronę sprzedawcy” było pierwotną obietnicą Instant Checkout, ale ACP w marcu 2026 r. przeszedł do odkrywania i przekierowania. Utrzymuj dobry checkout hostowany u siebie i obsługuj przepływ sesji programowej.

Założenie, że agent obsługuje numer karty klienta. Surowe dane karty celowo do niego nie trafiają — tokeny delegowane oraz model oddzielonych instrumentów i handlerów UCP są istotą delegowania. Kieruj delegowanie przez PSP, aby token był związany ze sprzedawcą, ograniczony kwotą i jednorazowy.

Ponowienia bez idempotencji. Agenci i sieci ponawiają żądania, a ACP ma typ błędu request_not_idempotent właśnie dlatego, że naiwne ponowienie może podwójnie obciążyć lub utworzyć zamówienie. Wymagaj kluczy idempotencji przy tworzeniu i kończeniu sesji oraz bezpiecznie obsługuj ten sam klucz.

Agentic checkout — ściąga

Enum statusów sesji checkoutu ACP

Równoległa maszyna UCP: incomplete → requires_escalation (człowiek przez continue_url) → ready_for_complete.

Endpointy checkoutu (ACP)

• POST /checkout_sessions — utworzenie (201)
• GET /checkout_sessions/{id} — pobranie
• POST /checkout_sessions/{id} — aktualizacja
• POST /checkout_sessions/{id}/complete — płatność i utworzenie zamówienia
• POST /checkout_sessions/{id}/cancel — anulowanie i zwolnienie zapasu

Token płatniczy — cztery ograniczenia

• merchant_id + checkout_session_id → związanie ze sprzedawcą i sesją
• max_amount → limit kwoty
• expires_at (RFC 3339) → limit czasu
• reason: "one_time" → jedno użycie

Webhooki zamówień (ACP)

• Zdarzenia: order_create, order_update
• Podpis: wymagany nagłówek HMAC Merchant-Signature
• Payload: pełny obiekt Order, nie różnice
• Odpowiedzi: 200 OK · 401 błędny podpis · 429 limit częstotliwości
• Statusy: created · manual_review · confirmed · canceled · shipped · fulfilled

Wyzwalacze interwencji człowieka

• stany requires_escalation/authentication_required
• InterventionCapabilities (3ds, address_verification; always/conditional/optional)
• wyniki AuthenticationResult (authenticated/denied/rejected/abandoned/…)
• B2B approval_required; UCP continue_url

Odpowiedzialność w skrócie

• Merchant = merchant-of-record → rozliczenia/zwroty/chargebacki ze sprzedawcą i PSP ✅ ustalone
• Dowody w sporach obciążeń agentów ⚠️ nierozstrzygnięte (połowa 2026 r.)
• Visa TAP / Mastercard Agent Pay → ramy powstające, nieukończone

Fragmenty do pracy z agentic checkout

Służą do inspekcji i testowania własnej integracji, nie do wykonywania prawdziwych zakupów. Używaj danych sandbox/test.

Weryfikacja podpisu webhooka (Node.js, HMAC)

Odrzuć wszystko, czego Merchant-Signature nie można dopasować. Porównuj w czasie stałym.

import crypto from "node:crypto";

// secret = your shared webhook signing secret; rawBody = the exact bytes received
function verifyMerchantSignature(rawBody, signatureHeader, secret) {
  const expected = crypto
    .createHmac("sha256", secret)
    .update(rawBody)          // sign the raw body, not the parsed JSON
    .digest("hex");
  const a = Buffer.from(expected);
  const b = Buffer.from(signatureHeader || "");
  return a.length === b.length && crypto.timingSafeEqual(a, b);
}
// In your handler: if (!verify) return res.status(401).end();  // else 200

Odpytanie statusu sesji checkoutu (shell)

Obserwuj, jak testowa sesja sandbox przechodzi przez maszynę stanów.

# Retrieve a session and print just its status field (needs jq)
SESSION_ID="cs_test_123"
curl -s "https://api.example.com/checkout_sessions/$SESSION_ID" \
  -H "Authorization: Bearer $ACP_TEST_KEY" \
  | jq -r '.status'          # e.g. not_ready_for_payment → ready_for_payment → completed

Wywołanie tworzenia z kluczem idempotencji (Python)

Sprawdź, że ponowienie z tym samym kluczem daje jedno zamówienie, a nie dwa.

import uuid, requests

key = str(uuid.uuid4())  # reuse this SAME key on retry
headers = {
    "Authorization": f"Bearer {ACP_TEST_KEY}",
    "Idempotency-Key": key,
    "Content-Type": "application/json",
}
payload = {"line_items": [{"id": "sku_1", "quantity": 1}]}
r1 = requests.post(f"{BASE}/checkout_sessions", json=payload, headers=headers)
r2 = requests.post(f"{BASE}/checkout_sessions", json=payload, headers=headers)  # retry
print(r1.json().get("id") == r2.json().get("id"))  # expect True — same session, no dupe

Fragment konsoli — wyszukaj profil UCP .well-known na wyrenderowanej stronie

Szybka kontrola w DevTools, czy sprzedawca udostępnia odkrywanie UCP (wklej w konsoli przeglądarki na originie sprzedawcy):

fetch("/.well-known/ucp")
  .then(r => (console.log("status:", r.status), r.ok ? r.json() : null))
  .then(p => console.log("capabilities:", p && p.capabilities));

Bookmarklet — przejdź do enumu statusu checkoutu w dokumentacji ACP

Wklej to jako zakładkę, aby otworzyć referencję ACP Checkout na liście statusów:

javascript:location.href='https://www.agenticcommerce.dev/docs/reference/checkout#:~:text=incomplete';

Typowe awarie agentic checkout

Ponowienie tworzy dwa zamówienia lub obciążenia

Objaw: ta sama sesja tworzy duplikaty po limicie czasu lub ponowieniu sieci. Prawdopodobna przyczyna: wywołania create/complete nie mają klucza i nie są bezpieczne przy ponowieniu. Naprawa: wymagaj klucza idempotencji, zwracaj pierwotny wynik dla tego samego klucza i potwierdź, że dwa identyczne wywołania sandbox tworzą jedną sesję i jedno zamówienie.

Checkout nigdy nie staje się gotowy do płatności

Objaw: sesja pozostaje w not_ready_for_payment albo incomplete. Prawdopodobna przyczyna: brak wymaganej opcji realizacji, adresu lub reguły biznesowej. Naprawa: sprawdź wymagane pola i messages[], uzupełnij brak i potwierdź przejście do ready_for_payment lub ready_for_complete.

Poprawne żądanie przechodzi, ale koszyk nie może się zakończyć

Objaw: żądanie HTTP kończy się powodzeniem, ale sesja zawiera brak zapasu lub inny błąd biznesowy. Prawdopodobna przyczyna: klient obsługuje tylko błędy HTTP i ignoruje wpisy MessageError. Naprawa: przetwarzaj błędy transportu i wiadomości sesji, aby użytkownik lub agent zobaczył konkretny problem.

Weryfikacja człowieka kończy się ślepą uliczką

Objaw: checkout wchodzi w requires_escalation albo authentication_required i nie wraca. Prawdopodobna przyczyna: przekazanie 3DS, logowania, akceptacji albo continue_url potraktowano jak wyjątek zamiast obsłużyć jako wspierany stan. Naprawa: zachowaj sesję podczas przekazania, obsłuż każdy wynik autoryzacji i sprawdź zarówno przepływ udany, jak i porzucony.

Status zamówienia przestaje się aktualizować po płatności

Objaw: sprzedawca ma zamówienie, ale powierzchnia agenta nadal pokazuje oczekiwanie. Prawdopodobna przyczyna: błędny podpis webhooka, wysłana tylko różnica albo pominięte 429. Naprawa: podpisuj dokładny payload, wysyłaj pełny obiekt Order, ponawiaj ograniczone zdarzenia z backoffem i potwierdź odbiór.

Modele mentalne dla agentic checkout

Checkout to maszyna stanów, nie pojedyncze wywołanie API

Każda odpowiedź powinna przenieść sesję do znanego stanu albo ujawnić znany powód, dla którego nie może przejść dalej. Projektuj klienta wokół przejść, stanów końcowych, ponowień i eskalacji, a nie pojedynczego żądania „kup”.

Władza pozostaje po stronie sprzedawcy

Agent wyraża intencję, ale sprzedawca pozostaje źródłem prawdy dla ceny, zapasu, podatku, realizacji, stanu zamówienia i obowiązków merchant-of-record. Koszyk żądany przez agenta traktuj jako wejście, a koszyk zwrócony przez sprzedawcę jako fakt.

Delegowanie zawęża uprawnienia

Token jest bezpieczniejszy, bo jest związany ze sprzedawcą i sesją, ograniczony kwotą i czasem oraz jednorazowy. Każdą delegowaną możliwość oceniaj pytaniami: co może zrobić, dla kogo, za ile i jak długo.

Eskalacja jest udaną gałęzią

Interwencja człowieka nie oznacza nieudanego checkoutu autonomicznego. Udane przekazanie 3DS, logowania, adresu lub akceptacji B2B jest działaniem protokołu zgodnym z projektem.

Po zakończeniu dostawa jest asynchroniczna

Zakończenie płatności nie kończy integracji. Podpisane webhooki pełnego obiektu przenoszą prawdę o zamówieniu po checkoutcie, więc weryfikacja podpisu, odporność na replay i obsługa ponowień należą do niezawodności.

Metryki agentic checkout

Finalizacja checkoutu według stanu końcowego

• Metryka: sesje zakończone, anulowane lub wygasłe jako udział w sesjach rozpoczętych.
• Co mówi: gdzie kończy się maszyna stanów i ile intencji gubi się przed utworzeniem zamówienia.
• Jak pobrać: agreguj zmiany stanu sesji z API commerce lub platformy zamówień, dzieląc je według protokołu i powierzchni sprzedawcy.
• Benchmark / zakres: ustal własną bazę i porównuj porównywalne przepływy; na tym etapie adopcji nie ma uniwersalnej obronnej wartości.
• Częstotliwość: monitoring codzienny, przegląd trendu co tydzień.

Wskaźnik powrotu po eskalacji

• Metryka: sesje po eskalacji, które wracają i kończą się po interwencji 3DS, logowaniu, kontroli adresu lub akceptacji.
• Co mówi: czy przekazanie człowiekowi jest użyteczne, czy prowadzi donikąd.
• Jak pobrać: połącz zdarzenia eskalacji z późniejszymi przejściami po identyfikatorze sesji checkoutu.
• Benchmark / zakres: ustal bazę osobno dla każdego typu interwencji.
• Częstotliwość: co tydzień i po zmianie przepływu przekazania.

Duplikaty zamówień i błędy webhooków

• Metryka: duplikaty z ponowień z tym samym kluczem oraz odrzucone lub wyczerpane dostawy webhooków.
• Co mówi: czy idempotencja i asynchroniczna synchronizacja zamówień są bezpieczne przy awarii.
• Jak pobrać: porównuj klucze idempotencji, ID zamówień, błędy podpisu, 401, 429, ponowienia i zdarzenia dead-letter w logach.
• Benchmark / zakres: duplikaty powinny wynosić zero; ustal normalny poziom chwilowych ponowień i badaj trwałe odchylenia.
• Częstotliwość: alarm natychmiast, podsumowanie co tydzień.

Zasoby warte uwagi

Moje powiązane teksty

• Dwa protokoły, w których mieści się agentic checkout, omawiają artykuły Agentic Commerce Protocol (ACP) i Universal Commerce Protocol (UCP); ta strona jest pogłębieniem mechaniki checkoutu.
• The Beginner’s Guide to Ecommerce SEO — miejsce checkoutu agentów w szerszym obrazie e-commerce.

Moje wystąpienia

• How Search Works (SlideShare) — omówienie odkrywania, indeksowania i rankingu; kontekst dla warstwy transakcji obsługiwanej przez agenta. (Stałe zastrzeżenie: „To moje rozumienie systemów… nie będzie w 100% kompletne ani dokładne”).

Z branży

• Agentic Commerce Protocol — referencja checkoutu (OpenAI/Stripe) — enum statusów, pola sesji i obiekty interwencji.
• OpenAI Delegated Payment spec — tokeny ograniczone zakresem i język merchant-of-record/PCI.
• ACP Order webhooks reference (OpenAI/Stripe) — podpisane HMAC-em webhooki pełnego obiektu.
• Chargebacki w handlu agentowym: kto odpowiada, gdy kupuje AI? (Chargeflow) — nierozstrzygnięty problem dowodów.
• Handel agentowy: zagrożenia i ryzyka (Visa) — Trusted Agent Protocol.
• OpenAI’s big ChatGPT Instant Checkout plan just changed — pivot z marca 2026 r.
• What Is Agentic Checkout? (Rye) — definicja i merchant-of-record.
• Deep Dive: Mastercard Verifiable Intent vs Visa Trusted Agent Protocol (Fintech Wrap Up / Finextra) — porównanie ram; konkretne przypisanie odpowiedzialności traktuj jako relację.

Statystyki warte cytowania

Liczby pokazują, gdzie naprawdę jest agentic checkout. Dane od sprzedawców i relacjonowane traktuj kierunkowo i weryfikuj przed użyciem.

• Około tuzina sprzedawców Shopify używało aktywnie narzędzi checkoutu AI — według relacji Search Engine Land ze zmiany z marca 2026 r. Relacja
• Marzec 2026: pivot. OpenAI zmieniło Instant Checkout z pełnego zakupu w czacie na odkrywanie i przekierowanie. Relacja
• Zakres tokenu = 4 ograniczenia. Token delegowanej płatności ma max_amount, expires_at, merchant_id/checkout_session_id i reason: one_time. Źródło
• Webhook zawsze pełnym obiektem. Pole data webhooka ACP zawiera pełny obiekt Order, a każde żądanie musi być podpisane HMAC-em. Źródło

Sprawdź się: Agentic Checkout

Pięć krótkich pytań o mechanice checkoutu. Wybierz odpowiedź przy każdym pytaniu, a potem sprawdź wynik.

Dziennik zmian