Dostawcy płatności agentowych — porównanie: Stripe, PayPal, Visa, Mastercard, Coinbase, Google

Rynek płatności dla agentów AI w 2026 roku nie ma jednego zwycięzcy — ma sześć poważnych obozów, z których każdy rozwiązuje nieco inny problem. Jeśli budujesz agenta, który ma samodzielnie kupować, pierwsze pytanie nie brzmi „który dostawca jest najlepszy”, tylko „gdzie są moi sprzedawcy i czy płacę kartą, stablecoinem, czy przez otwarty protokół”.

W skrócie: Do szybkiego startu w klasycznym e-commerce wybierz Stripe (ACP) lub PayPal — masz gotową infrastrukturę i akceptację. Do płatności maszyna-maszyna i mikropłatności w internecie API sięgnij po Coinbase x402 (stablecoiny). Do interoperacyjnych mandatów między platformami patrz na Google AP2. Do maksymalnego zasięgu kartowego — Visa Intelligent Commerce lub Mastercard Agent Pay. Te podejścia nie są wzajemnie wykluczające: protokół (x402/AP2) zwykle łączysz z konkretnym dostawcą rozliczeń.

Czym właściwie różnią się te podejścia?

Najważniejsze rozróżnienie to warstwa, na której działa rozwiązanie. Stripe, PayPal, Visa i Mastercard to dostawcy rozliczeń — odpowiadają za to, że pieniądze faktycznie zmienią właściciela. x402 i AP2 to otwarte protokoły — opisują, jak agent ma rozmawiać ze sprzedawcą o cenie, mandacie i autoryzacji, niezależnie od tego, kto przetwarza środki. W praktyce protokół i dostawca to dwie warstwy tego samego stosu, a nie konkurenci.

Drugie rozróżnienie to rdzeń płatniczy: karta (sieci Visa/Mastercard, tokenizacja), stablecoin (rozliczenie on-chain) albo neutralny protokół, który dopuszcza i jedno, i drugie. To rozróżnienie decyduje o kosztach, szybkości i o tym, gdzie w ogóle zapłacisz.

Tabela porównawcza: sześć podejść

Podejście	Rdzeń	Dla kogo	Mocna strona
Stripe / ACP (Agentic Commerce Protocol)	Karty, tokenizacja; otwarty protokół ACP	Sklepy i platformy już na Stripe, integracje z asystentami zakupowymi	Dojrzała infrastruktura płatnicza + otwarty standard checkoutu dla agentów
PayPal	Konta PayPal, karty, portfel	Sprzedawcy i kupujący z istniejącymi kontami PayPal, marketplace’y	Zaufana marka konsumencka, ochrona kupującego, gotowy portfel
Visa Intelligent Commerce	Karty Visa, tokeny płatnicze	Wydawcy kart, fintechy, zasięg globalnej akceptacji	Największa sieć akceptacji kartowej, tokenizacja i kontrola wydawcy
Mastercard Agent Pay	Karty Mastercard, tokeny agentowe	Banki, wydawcy, sprzedawcy w sieci Mastercard	Tokeny powiązane z tożsamością agenta i zasięg sieci Mastercard
Coinbase x402 (x402)	Stablecoiny, rozliczenie on-chain	Płatności M2M, API płatne za użycie, mikropłatności	Natywne dla internetu płatności przez kod statusu HTTP 402, niskie minimum kwoty
Google AP2 (AP2)	Neutralny — karty i stablecoiny	Ekosystemy wieloagentowe, interoperacyjne mandaty	Otwarty standard mandatów i autoryzacji niezależny od metody płatności

Stripe i PayPal — najkrótsza droga do działającego agenta

Jeśli Twoi sprzedawcy już przyjmują płatności przez Stripe albo PayPal, masz przewagę: nie budujesz infrastruktury od zera. Stripe współtworzy Agentic Commerce Protocol (ACP) — otwarty standard checkoutu, w którym agent może złożyć zamówienie u sprzedawcy w imieniu użytkownika, a samą płatność obsługuje znana już warstwa kartowa z tokenizacją. To podejście „karta plus protokół”: dostajesz dojrzałe rozliczenie i standaryzowany sposób, w jaki agent komunikuje się ze sklepem.

PayPal gra kartą zaufania konsumenckiego. Tam, gdzie kupujący ma już konto i przyzwyczajenie do ochrony kupującego, agent korzystający z portfela PayPal obniża tarcie i ryzyko sporu. To naturalny wybór dla marketplace’ów i sprzedawców, których klienci płacą portfelem, a nie wyłącznie kartą wpisywaną ręcznie.

Wspólna słabość obu: są zoptymalizowane pod transakcje konsumenckie o typowych kwotach. Do mikropłatności rzędu ułamków grosza za pojedyncze wywołanie API model kartowy bywa nieopłacalny.

Visa i Mastercard — gdy liczy się zasięg akceptacji

Sieci kartowe podeszły do tematu od strony swojej największej przewagi: niemal wszechobecnej akceptacji. Visa Intelligent Commerce i Mastercard Agent Pay to programy, które pozwalają wydawać i autoryzować płatności agenta w ramach istniejącej sieci kartowej, z tokenami powiązanymi z konkretnym agentem oraz kontrolami po stronie wydawcy.

Dla zespołu, który myśli o skali globalnej, to mocny argument: jeśli agent ma kupować u dowolnego sprzedawcy przyjmującego karty, zasięg sieci robi różnicę. Tokenizacja oznacza też, że agent nie operuje surowym numerem karty, a wydawca może nałożyć limity i reguły. To podejście kartowe w czystej postaci — z całą dojrzałością i regulacyjnym obyciem kart, ale i z ich modelem kosztowym.

x402 — płatności maszyna-maszyna i mikropłatności

x402, rozwijany w orbicie Coinbase, to inna filozofia. Wykorzystuje zarezerwowany, lecz historycznie nieużywany kod statusu HTTP 402 „Payment Required”: serwer odpowiada „zapłać”, agent dołącza płatność w stablecoinie, serwer udostępnia zasób. Rozliczenie odbywa się on-chain, więc minimalna sensowna kwota transakcji jest znacznie niższa niż przy karcie.

To czyni x402 naturalnym wyborem do płatności maszyna-maszyna (M2M) i scenariuszy, w których agent płaci za pojedyncze wywołania API, dostęp do danych czy moc obliczeniową — często ułamki dolara, wielokrotnie. Gdzie model kartowy się dławi prowizją i minimum, tam mikropłatność stablecoinem ma sens. Cena: wchodzisz w świat aktywów cyfrowych, portfeli i zarządzania kluczami, co niesie własne wymogi techniczne i zgodności.

AP2 — wspólny język mandatów

AP2 (Agent Payments Protocol), inicjowany przez Google, celuje w warstwę, której nie pokrywa żaden pojedynczy dostawca: interoperacyjny mandat. Chodzi o standardowy, weryfikowalny sposób, w jaki użytkownik upoważnia agenta do zapłaty — co, u kogo, do jakiej kwoty i na jakich warunkach — tak, aby to upoważnienie było czytelne dla różnych platform i metod płatności.

Co istotne, AP2 jest neutralny wobec rdzenia: ma współpracować i z kartami, i ze stablecoinami. To nie konkurent Stripe czy x402, lecz wspólny szkielet autoryzacji, który może spinać różnych dostawców. Dla ekosystemów wieloagentowych, gdzie agent jednego dostawcy płaci sprzedawcy obsługiwanemu przez innego, taka warstwa mandatów jest brakującym ogniwem.

Jak to poukładać u siebie?

Najczęstszy praktyczny wzorzec to łączenie warstw. Protokół lub bramkę (Stripe, PayPal, x402, AP2) zestawia się z wirtualną kartą jednorazową lub limitowaną, która działa jak twardy bezpiecznik wydatków agenta — nawet jeśli logika zawiedzie, karta nie przepuści więcej, niż na to pozwolisz. To pas bezpieczeństwa niezależny od inteligencji agenta.

Kilka zasad projektowych, które warto przyjąć od początku:

• Trzymaj warstwę płatności wymiennie. Logika agenta nie powinna wiedzieć, czy pod spodem jest karta, czy stablecoin. Zmiana dostawcy ma być konfiguracją, nie przepisywaniem kodu.
• Najpierw odpowiedz na pytanie „gdzie są moi sprzedawcy”. Jeśli kupujesz w klasycznym e-commerce — karta lub portfel. Jeśli płacisz za API i zasoby maszynowe — rozważ x402.
• Oddziel autoryzację od rozliczenia. Mandat (kto i na co pozwolił) trzymaj jako osobną, audytowalną warstwę; AP2 zmierza dokładnie w tę stronę.
• Zakładaj wielość, nie monolit. Większość poważnych wdrożeń skończy z więcej niż jednym dostawcą.

Szerszy obraz tego, jak te podejścia układają się w cały rynek, opisaliśmy w przeglądzie ekosystemu agentic commerce na 2026 rok. Jeśli wahasz się między rdzeniem kartowym a stablecoinowym, pomoże zestawienie zalet i wad obu modeli rozliczeń. A samą mechanikę otwartych standardów rozkładamy na części w omówieniu protokołów x402 i AP2.

Czego ta tabela nie rozstrzyga

Świadomie nie podajemy tu prowizji ani cenników — w połowie 2026 roku część programów jest na wczesnym etapie, a warunki handlowe różnią się między rynkami i wydawcami. Wybór dostawcy to też decyzja zgodności i ryzyka, nie tylko techniczna: model kartowy niesie inne obowiązki niż rozliczenie on-chain. Traktuj powyższe jako mapę podejść, a nie ranking — bo właściwa odpowiedź prawie zawsze brzmi „to zależy od tego, gdzie i za co płaci Twój agent”.