Rok temu ruch z asystentów AI był dla e-commerce mniej więcej tym, czym w swoim czasie ruch z Pinteresta: wszyscy go mierzyli, każdy raport go wymieniał, a w zestawieniu konwersji wypadał poniżej średniej. Dało się go zignorować bez konsekwencji i większość sklepów tak właśnie zrobiła.
W maju 2026 to samo źródło, ta sama metodologia – i odwrotny wynik.
Odwrócenie w dwanaście miesięcy jest ciekawe samo w sobie. Ciekawsze jest to, że większość sklepów nadal nie ma czym tego ruchu obsłużyć.
Ruch, który rok temu był wart mniej niż zwykły
Zacznijmy od liczby, która wygląda jak typowa statystyka z prezentacji o sztucznej inteligencji. Według Adobe Analytics ruch detaliczny pochodzący ze źródeł AI wzrósł w maju 2026 o 138% rok do roku. Sama w sobie nie mówi nic – procenty łatwo rosną, gdy baza jest mała.
Ciekawie zaczyna się przy drugiej liczbie. Te same wizyty konwertowały o 54% lepiej niż ruch spoza AI i generowały o 53% wyższy przychód na wizytę, przy współczynniku odrzuceń 17–20% wobec 27% dla pozostałych źródeł.
A teraz punkt odniesienia, bez którego całość jest tylko ładnym słupkiem. Rok wcześniej ruch z AI konwertował mniej więcej o połowę gorzej niż zwykły. W dwanaście miesięcy kanał przeszedł z pozycji „ciekawostka, która nie sprzedaje" do „najlepiej konwertujące źródło w zestawieniu". Nie dlatego, że modele nauczyły się sprzedawać – dlatego, że zmienił się moment, w którym człowiek pyta asystenta. Rok temu pytał z ciekawości, dziś pyta z portfelem w ręku.
Trzeba tu uczciwie zaznaczyć: pomiar konwersji pochodzi z rynku amerykańskiego i porównywalnego badania dla Polski nie ma. Jest za to polski pomiar samego zachowania, i wypada mocniej, niż większość osób by obstawiła. We wrześniowym badaniu Mastercard (zrealizowanym na potężnej grupie 26 tys. respondentów) 85% polskich nastolatków szukało informacji o produkcie przez AI, wobec 72% wśród rodziców. Ponadto 34% badanych ufa rekomendacji AI bardziej niż opinii znajomego.
Odbiorca, który dziś ma trzynaście lat, za 5 lat będzie miał własną kartę. Mastercard prognozuje, że do 2030 roku z agentów przy zakupach będzie regularnie korzystać około 300 mln osób, czyli mniej więcej co dziesiąta na świecie.
Osiem protokołów i jedna liczba, która pokazuje, gdzie jest wąskie gardło
Skoro ruch jest, konwersja jest, to gdzie problem? W warstwie, o której mówi się najmniej, bo jest najnudniejsza: w płatności.
Przez ostatnie dwanaście miesięcy powstał komplet standardów, które mają pozwolić agentowi domknąć transakcję. ACP – Stripe i OpenAI, wrzesień 2025. AP2 – Google, wrzesień 2025, od kwietnia 2026 pod skrzydłami FIDO Alliance. UCP – styczeń 2026, za nim Google, Shopify, Etsy, Wayfair, Target i Walmart. Do tego MCP, czyli warstwa, w której agent w ogóle rozmawia z zewnętrznymi narzędziami, oddana Linux Foundation przez Anthropic w grudniu 2025. Łącznie, według wrześniowego przeglądu, aktywnych protokołów w tym obszarze jest osiem.
Osiem standardów w rok to zwykle sygnał, że branża wie, iż coś jest ważne, ale nie wie jeszcze, jak to zrobić. Pytanie brzmi, ile spod tych standardów przepływa realnego ruchu i akurat tutaj mamy pomiar, a nie szacunek.
Analitycy prześwietlili x402, protokół płatności maszynowych uruchomiony przez Coinbase: 198,9 mln transakcji o wartości 52,7 mln dolarów. Po odsianiu podejrzanej aktywności zostało 25,62 mln dolarów prawdopodobnego handlu. A udział płatności pochodzących faktycznie od agentów AI oszacowano w tym na 0,6% do 7,5%.
Protokół zbudowany po to, żeby maszyny płaciły maszynom, obsługuje więc w przeważającej części ruch, który z agentami nie ma nic wspólnego – zwykły skrypt zostawia na blockchainie ślad nieodróżnialny od agenta. Wniosek autorów jest zwięzły: infrastruktura rośnie szybciej niż sami agenci.
Tę samą proporcję widać gdzie indziej: repozytorium MCP ma ponad 90 tysięcy gwiazdek na GitHubie (stan na wrzesień 2026), repozytorium ACP – około półtora tysiąca. Miernik zgrubny, ale kierunek ten sam: agenty masowo sięgają do narzędzi, a płacą rzadko.
Między niemal połową rynku pytającą asystenta o produkt a kilkoma procentami realnie agentowych płatności w protokole stworzonym do płacenia rozciąga się dokładnie to, czego w układance brakuje.
Warto przy okazji spojrzeć, kto stoi za UCP: Shopify, Etsy, Wayfair, Target, Walmart – firmy, które warstwę API miały gotową, zanim ktokolwiek zaczął mówić o agentach. Dla nich obsługa nowego protokołu to kwartał pracy zespołu, który i tak istnieje. Mniejszy sprzedawca na „pudełkowej” platformie musi najpierw mieć płatność, którą da się wywołać programowo. Część rynku ma do przejścia jeden krok, część trzy – i ta druga część nawet nie wie, że stoi na starcie.
Wąskim gardłem nie jest model. Jest nim to, co sprzedawca wystawia na zewnątrz
Agent, który ma domknąć zakup, potrzebuje po stronie sprzedawcy pięciu rzeczy, a żadna z nich nie wymaga czekania na zwycięstwo któregokolwiek standardu:
Płatność, którą da się utworzyć wywołaniem API, a nie kliknięciem. Jeśli jedyną drogą do rozpoczęcia transakcji jest formularz w przeglądarce, agent musi udawać człowieka – czyli będzie zawodził nieprzewidywalnie.
Sandbox i klucz dostępny od ręki. Jeżeli testowa płatność wymaga rozmowy z handlowcem i tygodnia na weryfikację, nikt nie zbuduje na tym integracji w weekend. A w weekendy powstaje większość rzeczy, które potem okazują się standardem.
Webhook z podpisem, nie przekierowanie. Tu jest miejsce, w którym agentowe integracje psują się najczęściej i najdrożej. Kuszące jest potraktować powrót użytkownika na returnUrl jako dowód zapłaty i to jest błąd, który przy człowieku z przeglądarką wychodzi rzadko, a przy agencie regularnie. Zamówienie realizuje się po zweryfikowanym webhooku, nie po przekierowaniu.
Idempotencja. Agent ponawia zapytania automatycznie – przy timeout'cie, błędzie sieci, niejednoznacznej odpowiedzi – i robi to częściej niż człowiek. Jeżeli powtórzone zapytanie tworzy drugą płatność zamiast zwrócić pierwszą, na końcu łańcucha stoi klient(ka) obciążony(-a) dwa razy. Warto zadać to pytanie dostawcy, zanim zada je za was dział reklamacji.
Zgoda płacącego i decyzja, na co dokładnie jej udzielono. Odruchowo zakłada się, że człowiek zatwierdza każdy zakup w momencie zakupu, a agent tylko przygotowuje transakcję. Pierwsze pilotaże w Polsce (wrzesień 2026, zakup za kilkanaście złotych zlecony agentowi i opłacony BLIK-iem) pokazują model odwrotny: zgoda udzielana z wyprzedzeniem, agent domyka płatność później i sam, gdy produkt wróci do sprzedaży. Wiceprezeska BLIK-a Monika Król mówi o tym wprost: agent może przejąć całą ścieżkę, od monitorowania oferty po finalizację transakcji.
To jest tryb, który AP2 wydziela osobno jako „human-not-present", i miejsce, w którym układanka robi się poważna. Zgoda z wyprzedzeniem rozwiązuje realny problem i jest wygodna. Otwiera też pytania bez dobrych odpowiedzi: na jaką kwotę dokładnie jej udzielono, jak długo jest ważna, co przy wzroście ceny między zleceniem a zakupem, kto odpowiada, jeśli agent kupi nie to, co trzeba. Przy kilkunastu złotych konsekwencja błędu jest żadna. Przy pierwszej rezerwacji wyjazdu za trzy tysiące – już nie.
I tu wraca badanie Mastercard, tym razem stroną, o której mówi się rzadziej. 61% rodziców nie pozwoliłoby AI dokonać zakupu bez potwierdzenia, 43% obawia się utraty kontroli nad wydatkami, 41% oszustwa. Zachowanie zakupowe już się przesunęło, gotowość do oddania maszynie samej płatności – nie. Dla kogoś, kto projektuje checkout, to najważniejsza liczba w całym zestawieniu: ścieżka agentowa bez czytelnego momentu potwierdzenia trafia u sześciu na dziesięciu klientów w barierę, której żaden protokół nie zdejmie.
Polski kontekst akurat tej ostatniej rzeczy sprzyja bardziej, niż się zwykle zauważa. BLIK zamknął pierwszy kwartał 2026 liczbą 756 mln transakcji o wartości 117,3 mld zł, a połowa z nich pochodziła z e-commerce. Model, w którym płatność inicjuje się gdzie indziej, a zatwierdza w aplikacji banku jest tu od lat odruchem, nie nowinką. Infrastruktura zgody udzielanej przez użytkownika(-czkę) jest u nas zaadaptowana szerzej niż na większości rynków, dla których te protokoły projektowano. To przewaga startowa polskiego e-commerce, o której mówi się zdecydowanie za mało.
Skalę warto przy tym trzymać w ryzach: mówimy o pojedynczych pilotażach, nie o działającej usłudze. Jedna transakcja nie jest rynkiem. Jest natomiast sygnałem, że warstwa techniczna po polskiej stronie jest gotowa wcześniej, niż sugerowałyby zagraniczne harmonogramy.
Dokumentacja napisana dla maszyny, nie dla człowieka
Jest w tej układance element, o którym mówi się jeszcze mniej niż o webhookach, a który decyduje o tym, czy agent w ogóle podejmie próbę integracji: czy potrafi przeczytać dokumentację.
Człowiek klika po zakładkach i składa obraz z siedmiu podstron. Agent tego nie robi – potrzebuje dokumentacji w formie, którą wciągnie jednym ruchem: indeksu, pełnego tekstu, specyfikacji OpenAPI, gotowej procedury. To sprzedawca dostaje od swojego dostawcy płatności albo nie dostaje, bez wpływu na sprawę.
Tu wypada powiedzieć, gdzie stoimy, bo bez tego akapit byłby reklamą. W Paymove wystawiliśmy taki zestaw: llms.txt z indeksem, llms-full.txt z całością w jednym pliku, openapi.yaml, skill.md z procedurą krok po kroku i agents.md z regułami do wrzucenia do repozytorium. Sandbox stoi pod osobnym adresem, klucze testowe zaczynają się od sk_test_ i nie trzeba robić calla.
Co z tym zrobić w praktyce?
Jeśli prowadzisz sprzedaż online, jedno pytanie warto sobie zadać jeszcze w tym kwartale: czy transakcję w moim sklepie da się rozpocząć i domknąć bez udziału przeglądarki? Jeśli odpowiedź brzmi „nie", to niezależnie od tego, który protokół wygra, jesteś poza tą grą, a ruch, który konwertuje o 54% lepiej, trafi tam, gdzie da się zapłacić bez problemu.
Jeśli chcesz być gotowy na płatności z AI, zadaj te pięć pytań swojemu dostawcy płatności:
- Czy płatność tworzy się wywołaniem API, czy tylko przez formularz?
- Czy dostanę klucz testowy bez rozmowy z handlowcem?
- Czy webhooki są podpisane i czy da się je zweryfikować po stronie mojego serwera?
- Co się stanie, jeśli to samo zapytanie przyjdzie dwa razy?
- Czy dokumentacja istnieje w formie, którą agent wciągnie w całości – pełny tekst, OpenAPI – czy tylko jako strona do klikania?
Piąte pytanie brzmi najbardziej technicznie i jest najbardziej praktyczne. Jeśli dokumentacja dostawcy nie daje się przeczytać maszynie, integrację napisze człowiek, czyli powstanie wtedy, kiedy ten człowiek będzie miał czas.
