x402: Brakująca warstwa płatności w internecie

Podsumowanie

Artykuł zawiera trzy części przeznaczone dla różnych typów czytelników:

🟦 Dla ciekawych (poziom początkujący): Dopiero wchodzisz w świat krypto albo po prostu chcesz dowiedzieć się, o co chodzi? Zacznij tutaj.
🟨 Dla fanów krypto (poziom średniozaawansowany): Wiesz, czym różni się staking od slashingu? To część dla Ciebie.
🟥 Dla budowniczych (poziom zaawansowany): Szczegółowe omówienie działania systemu, kompromisów projektowych oraz strategicznego kontekstu,.

Wybierz część, która najlepiej odpowiada Twojemu poziomowi wiedzy i zainteresowaniom, lub przeczytaj wszystkie, aby uzyskać pełniejszy obraz.

🟦 Dla ciekawych (poziom początkujący)

Internet błyskawicznie przesyła informacje, ale z płatnościami radzi sobie tak, jakby utknął w przeszłości. Każda transakcja online opiera się na kontach, platformach i pośrednikach, którzy działają poza natywnymi protokołami sieci. x402 zmienia ten obraz. Przenosi płatności bezpośrednio do HTTP, czyli standardu, który obsługuje niemal cały ruch w internecie.

Jeśli strona lub API chce pobierać opłatę, może odpowiedzieć kodem 402 Payment Required. Klient płaci, ponawia tę samą prośbę, a serwer zwraca rezultat. Ta prosta sekwencja sprawia, że płatność staje się naturalnym elementem komunikacji w sieci.

x402 współpracuje z kryptowalutami i stablecoinami, ale sam nie jest blockchainem. To otwarty standard, który pozwala każdemu portfelowi i każdej aplikacji internetowej wymieniać wartość tak samo jak dane. Celem jest prosty internetowy transfer pieniędzy – równie łatwy jak przesyłanie informacji.

🟨 Dla fanów krypto (poziom średniozaawansowany)

x402 to otwarty standard nadający realne znaczenie kodowi HTTP 402 Payment Required, zarezerwowanemu jeszcze w latach 90. Definiuje on sposób negocjowania płatności między klientem a serwerem: poprzez strukturalne komunikaty, podpisy kryptograficzne i dobrze znany cykl żądanie–odpowiedź.

Gdy klient prosi o zasób objęty opłatą, serwer zwraca Payment Required Response. Klient podpisuje Payment Payload, ponawia żądanie z tym Payloadem w nagłówku, a serwer przeprowadza weryfikację. Settlement może obsłużyć facilitator, ale sam handshake pozostaje czystym HTTP.

Dzięki temu x402 usuwa wiele zbędnej komplikacji spotykanej w tradycyjnych systemach płatności. Nie ma kont, nie ma API-keys, nie ma zewnętrznych procesorów. Każda płatność jest atomowa, samoweryfikowalna i pozbawiona stanu po stronie aplikacji. Ten sam mechanizm, który w HTTP odpowiada za cache czy autoryzację, może teraz obsługiwać płatności.

Ponieważ x402 opiera się na istniejącej infrastrukturze webowej, działa z przeglądarkami, API oraz popularnymi frameworkami. Może wykorzystywać stablecoiny w sieci Ethereum, rollupy takie jak Base, lub dowolny token obsługujący podpisy kryptograficzne. Efekt to uniwersalny płatniczy handshake dla ludzi i maszyn.

🟥 Dla twórców i założycieli (poziom zaawansowany)

x402 dodaje do internetu funkcję, której brakowało od lat: wbudowaną możliwość pobierania opłat za dostęp. Architektura opiera się na dwóch zasadach: minimalizmie i komponowalności. Nie powstaje nowe API ani nowy protokół. Rozszerza się HTTP o jeden kod statusu i dwa standardowe nagłówki. Dzięki temu integracja jest szybka, a kompatybilność z istniejącą infrastrukturą wysoka.

Sam proces płatności jest stateless. Każdy Payment Payload zawiera komplet danych: nonce, datę wygaśnięcia, podpis. Serwer nie musi niczego przechowywać. Facilitator może zapewnić skalowalność, jednocześnie nie mając dostępu do środków użytkowników. Do settlementu x402 wykorzystuje zazwyczaj EIP-712 (podpisywanie danych strukturalnych) i EIP-3009 (delegowane transfery tokenów bez gazu).

W porównaniu z Interledger lub Lightning, x402 nie próbuje być multiplatformowym routerem płatności. Stawia na prostotę bezpośredniej transakcji klient–serwer. To idealne rozwiązanie dla płatności per użycie: API, obliczeń, danych, mikrozasobów, a także dla agentów AI kupujących kontekst czy dane w czasie rzeczywistym.

Ekosystem standardu rozwija się szybko. Coinbase udostępnia implementację referencyjną i publiczny facilitator, Cloudflare integruje x402 ze swoją infrastrukturą edge, a Google wykorzystuje go w Agent Payments Protocol (AP2) dla agentów AI. Razem tworzą one fundament internetu, który nie tylko przesyła dane, lecz także wycenia i rozlicza dostęp do nich.

Dzięki x402 deweloperzy, firmy i autonomiczne systemy otrzymują wspólny, otwarty język wartości dla całego Webu. To brakująca warstwa płatności w sieci.

Brakująca warstwa płatności w sieci

Internet doskonale radzi sobie z przesyłaniem informacji, ale pieniądze nadal poruszają się tak, jakby utknęły w latach dziewięćdziesiątych. Każda płatność online wymaga warstwy pośredników: procesorów, kont użytkowników, subskrypcji i manualnych potwierdzeń. Możemy streamować wideo lub pobierać dane w ułamku sekundy, ale nie jesteśmy w stanie przesłać nawet kilku groszy bez udziału zewnętrznej platformy.
Sieć potrafi przenosić tekst, obrazy i kod natychmiast. Wartości nadal nie.

Współczesne systemy płatności powstały z myślą o ludziach, nie o oprogramowaniu.
Gdy płacimy, logujemy się, zatwierdzamy transakcję lub podpisujemy wiadomość.
Nawet automatyzacje, takie jak billingowe API czy silniki subskrypcyjne, jedynie odtwarzają ludzkie procesy.
Zakładają, że każda płatność odbywa się pomiędzy podmiotami pozostającymi w relacji zaufania, posiadającymi konta lub uzgodnione dane rozliczeniowe.

Model ten działa, ale jest ciężki.
Czytelniczka, która chce zapłacić 2 zł za jeden artykuł, musi założyć konto, podać kartę i pamiętać o anulowaniu subskrypcji.
Deweloper chcący zmonetyzować API musi integrować usługę płatności, śledzić limity i radzić sobie z chargebackami.
A mały sklep internetowy, który chce przyjmować kryptowaluty, szybko odkrywa, że to wcale nie jest takie proste.
Do wyboru są bramki custodial z ograniczeniami regionalnymi, samodzielnie utrzymywane serwery płatności wymagające opieki lub dostawcy zewnętrzni, którzy przywracają te same koszty i tarcia, które krypto miało znieść.

Co więcej, nie istnieje żaden standard protokołowy, który umożliwiałby przyjmowanie płatności kryptowalutami bezpośrednio w przeglądarce czy w API.
Każdy merchant, każda aplikacja i każdy integrator wdraża swoje własne, zupełnie inne rozwiązania: jedni stosują QR kody, inni widgety, jeszcze inni monitorują transakcje on-chain ręcznie.
Nie ma odpowiednika HTTP czy SMTP dla płatności kryptowalutowych.

To luka o charakterze systemowym.
Internet ma protokoły do przesyłania informacji: HTTP, DNS, TLS.
Nie ma protokołu do przesyłania wartości.
Pieniądze są nadal „zewnętrzne”, obsługiwane przez aplikacje i pośredników, a nie przez sieć jako taką.
Każda płatność wymaga konta, tożsamości i infrastruktury zaufania.
Gdy oprogramowanie staje się coraz bardziej autonomiczne, ta luka staje się coraz bardziej widoczna.

Agent AI może już czytać, analizować i podejmować decyzje.
Ale nie może zapłacić.
Może wywołać endpoint API, ale nie może odblokować płatnego zasobu.
Może polecić produkt, ale nie dokona zakupu.
Autonomia kończy się tam, gdzie zaczyna się cennik.

To nie jest tylko problem agentów.
Dotyka wszystkich obszarów gospodarki internetowej: mediów, SaaS, treści, e-commerce.
Maszyny jedynie uwidaczniają słabości systemu, które ludzie odczuwają codziennie w postaci subskrypcji, platformowej zależności i braku sensownego wsparcia mikrotransakcji.

Rezultat: Web, który daje powszechny dostęp do informacji, ale pozostawia płatny dostęp uwikłany w infrastrukturę sprzed epoki internetu.

x402 powstało właśnie po to, aby tę lukę wypełnić.
Nie traktuje płatności jako funkcji aplikacji, ale jako pierwszej klasy prymityw sieciowy.

HTTP jako warstwa płatności

W specyfikacji HTTP od lat dziewięćdziesiątych znajduje się status, który nigdy nie doczekał się realnego zastosowania: 402 Payment Required. Zarezerwowano go jako element przyszłego systemu płatności, lecz taki system nigdy nie powstał. Przeglądarki, API i platformy zbudowały własne, od siebie różne rozwiązania, a kod 402 pozostał pustą przestrzenią.
x402 nadaje mu wreszcie praktyczne znaczenie.

Standard nie tworzy nowej sieci ani nowego systemu finansowego.
Rozszerza jedynie to, co już istnieje: HTTP jako bazowy protokół internetu.
Gdy klient wywołuje zasób, który wymaga opłaty, serwer może odpowiedzieć strukturą 402 zawierającą:

• cenę (`maxAmountRequired),
• akceptowany token lub stablecoin (asset or assetAddress),
• adres odbiorcy (payTo),
• sieć blockchain (network),
• opcjonalny opis transakcji.

Jeśli klient akceptuje te warunki, podpisuje kryptograficzną autoryzację i ponawia dokładnie to samo żądanie. Serwer weryfikuje podpis, wykonuje rozliczenie i zwraca odpowiedź 200 OK wraz z daną treścią.

W praktyce wygląda to jak zwykłe wywołanie HTTP.
Programista dodaje do endpointu middleware x402 i ustala cenę.
Jeśli klient wywoła zasób bez płatności, dostanie 402 z jasnymi instrukcjami. Po dołączeniu Payment Payload, endpoint działa już normalnie.

Bez zewnętrznych API płatniczych.
Bez zakładania kont.
Bez subskrypcji.

Cały proces podąża za znaną logiką HTTP:
żądanie → odpowiedź → ponowienie → sukces.

Można ująć to prościej:
x402 jest dla płatności tym, czym HTTP jest dla danych, wspólną, zrozumiałą gramatyką wymiany.

Architektura w praktyce

x402 opiera się na bardzo prostym, intuicyjnym podziale ról. Cały system działa dzięki trzem elementom:

• Client: Każdy, kto inicjuje żądanie HTTP. Może to być użytkownik z portfelem kryptowalutowym lub agent działający autonomicznie na podstawie klucza prywatnego.
• Server: Usługa, która udostępnia zasób i określa, czy dana operacja wymaga opłaty oraz jak wysoka ta opłata jest.
• Facilitator: Opcjonalny serwer pomocniczy, który odpowiada za weryfikację podpisanych płatności i wykonanie transakcji na blockchainie w imieniu serwera, bez uzyskiwania kontroli nad środkami.

Typowy przebieg wygląda tak, jak opisano w dokumencie:

1. Klient wysyła żądanie, na przykład GET /api/data.
2. Serwer odpowiada statusem HTTP 402 i podaje cenę (na przykład 0.10 USDC) wraz z adresem odbiorcy i siecią.
3. Klient podpisuje autoryzację płatności, wykorzystując standard EIP-712, i ponawia żądanie z podpisem w nagłówku.
4. Serwer lub Facilitator sprawdza podpis, wykonuje transfer on-chain lub na sieci warstwy drugiej i zwraca HTTP 200 OK z właściwą treścią.

Wszystkie autoryzacje budowane są z użyciem strukturalnych danych EIP-712. Dzięki polom takim jak nonce, paymentId czy expiresAt każdy Payment Payload jest odporny na powtórne użycie, jednoznaczny i weryfikowalny.

Jeśli chodzi o settlement, x402 pozostawia pełną swobodę. Serwer lub Facilitator może:

• wykonać transfer bezpośrednio na sieci blockchain,
• użyć rollupu,
• zastosować kanały płatności,
• połączyć wiele mikrotransakcji w jeden batch.

Ta elastyczność sprawia, że x402 da się dopasować do bardzo różnych środowisk i modeli kosztowych.

Największą zaletą tej architektury jest jej prostota.
x402 nie zastępuje istniejących sieci blockchain ani systemów finansowych.
Łączy je z siecią Web poprzez uniwersalny, zrozumiały interfejs.

Każdy portfel, który potrafi wygenerować podpis, może zapłacić.
Każdy serwer, który rozumie HTTP, może przyjąć płatność.
A wszystko działa z użyciem tych samych mechanizmów, które definiują internet od trzech dekad.

Dlaczego to ma znaczenie dla sprzedawców

Dla sprzedawców i deweloperów x402 zmienia sposób myślenia o płatnościach.
Płatność przestaje być elementem produktu, a staje się kwestią konfiguracji.

Serwer nie musi już ręcznie zarządzać adresami portfeli, monitorować sieć blockchain ani dopasowywać transakcji do zamówień. Każde pojedyncze żądanie niesie w sobie kompletny dowód płatności: źródło, kwotę, poprawność i ważność. Cała weryfikacja odbywa się w tym samym cyklu HTTP, który służy do wysyłania i odbierania danych.

W porównaniu z bezpośrednimi płatnościami kryptowalutowymi różnica jest ogromna.
Bezpośrednie transfery często działają, ale nie są w żaden sposób zunifikowane. Każdy sprzedawca stosuje inny przepływ: różne formaty adresów, różne sposoby potwierdzania płatności, różne integracje z portfelami.

x402 rozwiązuje to wprowadzając jednolity proces.
Każdy klient wie, jak odpowiedzieć na 402 Payment Required.
Każdy serwer wie, jak sprawdzić Payment Payload.
Znika konieczność tworzenia niestandardowych integracji płatności.

Typowe problemy w płatnościach kryptowalutowych i jak rozwiązuje je x402

*Nie w każdym przypadku, ale to typowe problemy, wynikające z braku wspólnego standardu HTTP dla płatności.

Różnica to nie tylko wygoda. To zakres możliwości.
x402 standaryzuje to, co wcześniej było improwizacją.
Sprzedawcy mogą wyceniać dostęp do treści, API czy mocy obliczeniowej:

• za zapytanie,
• za sekundę,
• za bajt.

Bez subskrypcji.
Bez platform pośredniczących.
Bez budowania własnego systemu płatności.

Po raz pierwszy Web otrzymuje otwarty, natywny sposób wyrażania wartości w samym protokole.

x402 nie tworzy nowej sieci płatności.
Rozszerza istniejącą infrastrukturę o brakujący element: możliwość przesyłania pieniędzy tak naturalnie, jak przesyłamy dane.

Decyzje projektowe i kompromisy

Filozofia protokołu: minimalizm i komponowalność

x402 świadomie wybiera minimalizm. Zamiast tworzyć nowe sieci, nowe warstwy transportu czy dedykowane mechanizmy, standard rozszerza protokół, który już definiuje internet: HTTP.
Zasięg decyduje o skuteczności, a HTTP ma największy zasięg, jaki istnieje.

Zamiast wymyślać nowe węzły, własne message-busy czy specjalne interfejsy przeglądarek, x402 przywraca do życia zapomniany kod 402 Payment Required i nadaje mu jednoznaczną, techniczną semantykę.
Każdy przepływ jest znajomy: klient wysyła żądanie, serwer odpowiada 402 z informacją o płatności, klient ponawia żądanie z podpisaną autoryzacją. Reszta to czyste HTTP.

To przykład minimalizmu protokołowego.
x402 dodaje możliwie niewiele:

• znaczenie dla kodu 402,
• małe, strukturalne JSON z wymaganiami płatności,
• określony cykl powtórzeń po błędzie.

Nie próbuje stać się nową warstwą blockchain, tożsamości czy globalnego routingu wartości.
Pozostając w świecie HTTP, x402 korzysta z całego dorobku internetu: reverse proxy, load balancerów, TLS, CDN-ów, systemów cache, narzędzi do monitoringu i logowania.

Efekt to wysoka komponowalność.
x402 da się osadzić za Nginxem, wewnątrz Expressa lub FastAPI, obok REST-a i GraphQL-a.
Nie wymaga nowych demonów, nowych portów, nowych zależności. Obniża koszt wdrożenia i ryzyko operacyjne.

Oczywiście istnieje kompromis.
HTTP nie wspiera natywnie strumieniowania płatności, tras wieloetapowych ani escrow.
Protokół nadaje się idealnie do pojedynczych transakcji punkt-do-punktu, ale nie do bardziej złożonych przepływów.
x402 świadomie optymalizuje pod najczęstszy przypadek w internecie, czyli jednorazowe płatności za dane, treści lub obliczenia.

To wybór uniwersalności ponad specjalizację.
Standard nie zastępuje istniejących sieci płatności.
Daje im wspólny język, dzięki któremu można je w prosty sposób podłączyć do Webu.

Bezstanowy handshake płatniczy i rozliczenia per użycie

W x402 każda płatność jest samodzielnym handshake’iem.
Każdy request zawiera wszystkie dane niezbędne do weryfikacji i rozliczenia: kwotę, sieć, odbiorcę, unikalne identyfikatory i podpis. Serwer nie musi trzymać żadnego dodatkowego stanu dotyczącego płatności.

Ważne: „bezstanowość” dotyczy samej płatności, nie całej aplikacji.
Serwer może korzystać z sesji, logowania czy kontroli dostępu, ale handshake płatniczy nie zależy od żadnego przechowywanego stanu. Weryfikacja odbywa się w pełni na podstawie podpisanego Payloadu.

Daje to prostotę operacyjną.
Nie ma otwartych faktur, nie ma sald do synchronizowania, nie ma miesięcznych cykli rozliczeń.
Request jest albo opłacony, i wtedy wraca 200 OK, albo nie, i wtedy wraca 402 Payment Required.

Model ten idealnie pasuje do mikrotransakcji.
Deweloperzy mogą rozliczać zapytania per bajt, per sekundę, per wywołanie, bez budowania własnego systemu billingowego. Rozliczenie staje się elementem konfiguracji, a nie dodatkową usługą w architekturze.

Wadą może być obciążenie przy bardzo dużej liczbie requestów. Każdy z nich wymaga podpisania i weryfikacji. Standard dopuszcza jednak rollupy, kanały płatności i batchowanie, dzięki czemu część kosztów można rozłożyć na warstwę settlement.
Nawet jeśli wiele autoryzacji jest rozliczanych w jednym batchu, każda z nich pozostaje jednoznaczna i zgodna z zasadami bezpieczeństwa.

W przeciwieństwie do systemów strumieniowych, które utrzymują stan przez dłuższy czas, x402 tworzy izolowane transakcje.
To upraszcza wdrożenia i ogranicza powierzchnię ataku.

Facilitatorzy i granica zaufania

Każdy system płatności potrzebuje warstwy wykonawczej. W x402 odpowiada za nią facilitator: lekki serwer, który łączy logikę Webu z logiką blockchaina.

Facilitator:

• weryfikuje podpisane Payment Payloads,
• sprawdza zgodność z Payment Requirements,
• wykonuje transakcje na blockchainie,
• zwraca serwerowi informację o statusie. To rozwiązanie praktyczne. Nie każdy sprzedawca chce utrzymywać pełne węzły, monitorować mempool lub optymalizować gaz. Facilitator odciąża ich operacyjnie.

Najważniejsze jest to, że facilitator nie ma kontroli nad środkami.
Wykonuje tylko to, co znajduje się w podpisanym Payloadzie.
Jakakolwiek zmiana unieważniłaby podpis.
To minimalizuje ryzyko i czyni facilitatorów pomocnikami, a nie pośrednikami wartości.

Facilitator przypomina bramkę lub proxy: pomaga technicznie, ale nie przejmuje relacji ekonomicznej.

Ryzyko pojawia się wtedy, gdy większość ruchu zacznie przepływać przez kilku dużych facilitatorów. Mogłoby to stworzyć koncentrację podobną do tradycyjnych procesorów płatności. x402 łagodzi to tym, że facilitatorów można łatwo wymieniać, a standard pozostaje otwarty.

W praktyce są oni mostem między światem blockchain a Webem, umożliwiając szybkie płatności bez rezygnacji z otwartości protokołu.

Dlaczego HTTP, a nie nowy protokół

Wybór HTTP jako fundamentu wynika z prostego faktu: to najpowszechniejszy protokół w historii ludzkości. Każda infrastruktura, każdy język programowania, każdy framework go rozumie.

Dodanie jednego kodu statusu nie wymaga nowych protokołów, portów czy modeli bezpieczeństwa.
x402 działa w dokładnie tym samym środowisku, które obsługuje resztę internetu.

Standard dobrze współgra z nowoczesnymi modelami podpisywania wiadomości, szczególnie EIP-712.
Dzięki temu Payment Payload jest:

• czytelny,
• strukturalny,
• łatwy do zweryfikowania.

Gdyby twórcy x402 zaprojektowali nowy protokół od zera, musieliby rozwiązywać problemy, które HTTP rozwiązuje od lat: routing, błędy, TLS, obsługa połączeń. Wykorzystując istniejący protokół, oszczędzają ogrom pracy i otrzymują od razu światowej klasy infrastrukturę.

HTTP nie jest idealne. Nie obsługuje naturalnie strumieni wartości czy trasowania płatności. Dlatego systemy takie jak Interledger lub Lightning będą zawsze lepsze w wieloetapowych płatnościach.
Jednak w ogromnej większości przypadków Webu, zapytanie, odpowiedź, dostęp do treści,HTTP jest miejscem naturalnym.

Właśnie dlatego x402 zdobywa przewagę: jest natychmiast wdrażalne i współpracuje ze wszystkim, co już działa.

Krajobraz porównawczy

Próby standaryzacji płatności w internecie od lat zmagają się z tym samym problemem: jak połączyć otwartość z praktyczną użytecznością. Niektóre projekty tworzyły całkowicie nowe protokoły, inne próbowały rozszerzać istniejące. Wiele z nich nigdy nie osiągnęło szerokiej adopcji, bo wymagały zbyt dużego wysiłku wdrożeniowego albo były zbyt wąsko wyspecjalizowane.
x402 podchodzi do tematu inaczej. Nie buduje nowych „szyn płatniczych”, lecz definiuje wspólną warstwę sygnalizacyjną, która pozwala łączyć istniejące systemy z Webem.

Interledger (ILP) i Web Monetization

Interledger (ILP) oraz jego przeglądarkowy wariant Web Monetization były ambitnymi próbami stworzenia uniwersalnej warstwy do przekazywania wartości między różnymi ledgerami. ILP wprowadził koncepcję packetized payments, czyli płatności przesyłanych w małych pakietach, które mogą przechodzić przez różne sieci. Web Monetization wykorzystywał ten model do strumieniowego wynagradzania twórców.

Problemem była jednak złożoność operacyjna.
ILP wymagał specjalnych węzłów, konektorów, systemu routingu i niekiedy dedykowanego wsparcia w przeglądarkach.
To wszystko znacząco ograniczyło adopcję.

x402 unika tych barier, ponieważ działa całkowicie w obrębie HTTP.
Nie wymaga nowych uczestników sieci ani dodatkowych komponentów.
Każdy serwer potrafiący zwrócić 402 Payment Required jest kompatybilny.

Ograniczeniem jest jednak zakres: x402 obsługuje wyłącznie płatności bezpośrednie, bez wieloetapowego routingu między różnymi ledgerami.
Priorytetem jest zasięg, a nie szeroko rozumiana wymiana między sieciami.

Lightning L402 i LSAT

Sieć Lightning wprowadziła szybkie i tanie mikropłatności off-chain. Standard LSAT łączył Lightning z HTTP, wysyłając w odpowiedzi 402 fakturę Lightning i przyznając po opłaceniu dostęp za pomocą tokenu.

x402 nawiązuje do tej koncepcji, ale w sposób bardziej ogólny.
Zamiast opierać się na jednej technologii (Lightning + Macaroons), używa uniwersalnych podpisów i strukturalnych payloadów, które pasują do stablecoinów, tokenów i dowolnych aktywów umożliwiających podpisy kryptograficzne.

Lightning działa świetnie, ale wymaga kanałów, zarządzania płynnością, działalności node’ów i ekosystemu Bitcoin.
x402 działa od razu z istniejącymi portfelami, serwerami webowymi i dowolnym blockchainem zgodnym z podpisami.

W ten sposób protokół przenosi ideę „płać, aby uzyskać dostęp” na cały internet.

Stripe, PayPal i systemy API-fiata

Stripe i PayPal ustanowiły wysoki standard wygody w integracji płatności, ale działają jako zamknięte platformy. Są pośrednikami, ustalają własne zasady i pobierają opłaty. Integracja z ich API oznacza integrację z ich modelem biznesowym.

x402 odwraca tę zależność.
Standaryzuje sam handshake płatności, a nie platformę.
To serwer sprzedawcy określa warunki i inicjuje płatność. Płatność przebiega bezpośrednio między klientem a sprzedawcą, nawet jeśli facilitator technicznie obsługuje settlement.

Innymi słowy, x402 jest tym, czym byłby Stripe… gdyby Stripe był otwartym, zdecentralizowanym standardem.

ERC-4337 i Account Abstraction

ERC-4337 wprowadził smart-wallety i mechanizmy takie jak sponsorowane gas fees czy bundling transakcji.
Poprawia on UX portfeli, ale nie definiuje, w jaki sposób aplikacje webowe mają żądać płatności.

x402 i ERC-4337 współpracują idealnie:

• x402 odpowiada za warstwę Web, czyli handshake płatności,

• ERC-4337 odpowiada za warstwę blockchainową, czyli wykonanie transakcji przez smart-wallet.

Razem tworzą płynny kanał od żądania w HTTP do wykonania na blockchainie.

Tabela porównawcza

Podsumowanie

x402 nie zastępuje tych systemów.
Zapewnia brakującą warstwę sygnalizacyjną, dzięki której można je ze sobą łączyć.
Jest najmniejszą możliwą abstrakcją płatności w HTTP.
Tam gdzie inne projekty budowały nowe „szyny”, x402 definiuje sposób, w jaki te szyny komunikują się z Webem.

Napięcia projektowe i otwarte pytania

Każdy protokół jest zbiorem kompromisów. x402 maksymalizuje prostotę wdrożenia i komponowalność, ale ta sama prostota tworzy obszary napięć, które w przyszłości będą wymagały uwagi społeczności, firm i zespołów wdrożeniowych.

Bezstanowość kontra efektywność

Zaletą x402 jest bezstanowy charakter płatności. Każdy Payment Payload zawiera wszystkie dane potrzebne do weryfikacji i rozliczenia, bez konieczności utrzymywania sesji czy śledzenia sald.

Dla większości aplikacji to idealne rozwiązanie, ale przy bardzo wysokim obciążeniu pojawia się koszt:
każdy request musi zostać osobno podpisany, przesłany i zweryfikowany.
Przy strumieniach danych lub intensywnych API może to prowadzić do zauważalnych opóźnień. Rollupy, kanały płatności czy batchowanie łagodzą problem, ale przenoszą złożoność na warstwę settlement.

Otwarte pytanie brzmi:
Jak zachować prostotę bezstanowego modelu, a jednocześnie zwiększyć przepustowość?

Otwartość kontra odporność na spam

Jedną z największych zalet x402 jest pełna otwartość.
Każdy klient może wysłać żądanie i zapłacić za dostęp.
To jednak może stać się wektorem nadużyć.

Atakujący mógłby wysyłać masowo 402-requests, wymuszając alokację zasobów lub obciążając facilitatorów.
Klasyczna architektura HTTP radzi sobie z tym przez rate limiting i uwierzytelnianie, lecz wprowadzenie płatności dodaje nowe czynniki ryzyka.

Wciąż nie ma jednoznacznej odpowiedzi, jakie mechanizmy powinny stać się częścią standardu, a jakie pozostaną decyzją implementacji.

Decentralizacja kontra praktyczność

Facilitatorzy znacząco ułatwiają wdrożenie x402, nie trzeba uruchamiać pełnych nodów, monitorować mempoola czy optymalizować kosztów gazu.
Ale ta wygoda może prowadzić do koncentracji.

Jeśli większość ruchu będzie przechodzić przez kilku dużych operatorów, rynek zacznie przypominać tradycyjnych pośredników płatności, od których Web3 próbował się uwolnić.

Standard projektuje facilitatorów jako role otwarte i łatwe do wymiany, ale prawdziwym testem będzie praktyka.
Powstaje pytanie:
Czy możliwa jest trwała decentralizacja warstwy facilitatorów?

Minimalizm kontra funkcjonalność

Minimalizm x402 jest jego największą siłą — ale również ograniczeniem.
Standard doskonale radzi sobie z pojedynczymi, bezpośrednimi płatnościami.

Nie wspiera jednak natywnie:

• escrow,
• strumieniowania płatności,
• płatności warunkowych,
• złożonych modeli subskrypcyjnych,
• zwrotów i tipów.

Dodanie zbyt wielu rozszerzeń mogłoby zagrozić prostocie protokołu, ale brak pewnych funkcji może ograniczyć adopcję w bardziej złożonych przypadkach.
W przyszłości trzeba będzie znaleźć balans między rozszerzalnością a minimalizmem.

Interoperacyjność kontra różnorodność

x402 wspiera wiele sieci, aktywów i sposobów settlementu.
To ogromna zaleta, ale istnieje ryzyko fragmentacji.

Dla pełnej interoperacyjności potrzebne są:

• jednolite nazwy sieci,
• spójne reprezentacje aktywów,
• wspólne reguły zachowania facilitatorów. Bez tego implementacje mogą się różnić, co utrudni współprace między usługami.

Użyteczność kontra self-custody

x402 zakłada, że użytkownicy lub agenci mają własne portfele i mogą podpisywać transakcje.
Dla agentów to naturalne.
Dla ludzi, już mniej.

Większość portfeli nie jest przystosowana do częstych mikropłatności ani automatycznych zgód.
Rozwiązaniem mogą być smart-wallety i mechanizmy delegowania, takie jak ERC-4337, ale to nadal rozwijająca się technologia.

Pytanie brzmi:
Jak zapewnić doskonałe UX przy zachowaniu modelu self-custody?

Regulacje i nadzór

Sam protokół x402 nie przechowuje środków i nie dotyka danych osobowych.
Ale facilitatorzy, którzy wykonują transakcje na blockchainie, mogą podlegać lokalnym regulacjom finansowym.

Różnice prawne między krajami mogą prowadzić do fragmentacji i niejednolitej dostępności usług.
W dłuższej perspektywie konieczne będą jasne wytyczne dotyczące zgodności facilitatorów z przepisami.

Podsumowanie

x402 istnieje na granicy dwóch światów: Webu i blockchaina.
Łączy je w minimalny, elegancki sposób, ale jednocześnie odziedzicza ograniczenia obu.

Największym wyzwaniem na przyszłość jest to, czy uda się:

• zachować prostotę,
• wspierać coraz bardziej złożone przypadki użycia,
• a przy tym utrzymać protokół otwarty, neutralny i łatwy do wdrożenia.

Jak działa x402

x402 działa prosto, bo wykorzystuje wzorzec, który zna każdy, kto pracuje z HTTP. Cały proces płatności wpisuje się w typowy cykl: żądanie, odpowiedź, ponowienie, wynik.
Protokołowi nie potrzeba nic więcej niż to, co już rozumie każda aplikacja webowa.

W praktyce płatność składa się z trzech ról i dwunastu kroków:

Client
Użytkownik lub agent, który wysyła żądanie HTTP.

Resource Server
Serwer, który udostępnia zasób i określa warunki płatności.

Facilitator Server
Opcjonalny serwer pomocniczy, który sprawdza podpisy i wykonuje transakcje na blockchainie w imieniu serwera.

Poniżej znajduje się oficjalny przepływ transakcyjny z dokumentacji.

Oficjalny przebieg płatności

1. Żądanie klienta

Klient wysyła żądanie HTTP do Resource Server, na przykład GET /api.
Jeśli zna już warunki płatności, może pominąć krok drugi.

2. Odpowiedź 402 Payment Required

Serwer zwraca 402 Payment Required wraz z JSON-em zawierającym Payment Requirements.
JSON może definiować kilka opcji płatności, różniących się tokenem, siecią lub ceną.

3. Utworzenie Payment Payload

Klient wybiera jedną z opcji i tworzy Payment Payload, który zawiera m.in.:

• paymentId
• asset
• to
• value
• nonce
• expiresAt

Payload jest zgodny ze schematem określonym w Payment Requirements.

4. Ponowienie żądania z nagłówkiem X-PAYMENT

Klient wysyła to samo żądanie HTTP ponownie, dodając nagłówek X-PAYMENT z podpisanym payloadem.

5. Weryfikacja Payment Payload

Serwer waliduje Payload lokalnie lub wysyła go do Facilitatora pod endpoint /verify.

6. Odpowiedź weryfikacyjna

Facilitator sprawdza podpis, parametry, ważność i zwraca odpowiedź weryfikacyjną.
Jeśli walidacja jest nieudana, serwer ponownie zwraca 402 Payment Required.

7. Wykonanie pracy

Po udanej weryfikacji Resource Server wykonuje żądane działanie: generuje dane, przetwarza zapytanie lub pobiera zasób.

8. Inicjacja rozliczenia

Po zakończeniu pracy serwer inicjuje settlement, albo bezpośrednio na blockchainie, albo wysyłając Payload do Facilitatora pod /settle.

9. Przesłanie transakcji

Facilitator wysyła transakcję do sieci blockchain, zgodnie ze schematem i siecią określoną w Payloadzie.

10. Oczekiwanie na potwierdzenie

Facilitator czeka na finalne potwierdzenie transakcji w sieci.

11. Payment Execution Response

Po potwierdzeniu Facilitator zwraca do serwera status wykonania transakcji oraz np. hash transakcji.

12. Finalna odpowiedź HTTP

Serwer odpowiada klientowi kodem 200 OK i dostarcza właściwy zasób.
W nagłówku X-PAYMENT-RESPONSE umieszcza Base64 zakodowany wynik rozliczenia.

Oficjalny diagram przepływu

Rysunek 2: Pełna sekwencja płatności x402 z oficjalnego GitHuba. Serwer może zdecydować się na nieoczekiwanie na ostateczne rozliczenie w łańcuchu, aby zmniejszyć opóźnienie; w takim przypadku czas reakcji jest równy czasowi weryfikacji facylitatora.

Na diagramie w specyfikacji widać pełny przebieg:

• klient żąda zasobu,
• serwer zwraca 402,
• klient podpisuje i ponawia żądanie,
• facilitator weryfikuje i rozlicza,
• serwer zwraca 200 OK. Serwer może odpowiedzieć jeszcze przed finalnością on-chain, jeśli zależy mu na niskiej latencji.
  Wtedy jedynym źródłem opóźnienia jest komunikacja z Facilitatorem.

Podpisy kryptograficzne

x402 opiera się na EIP-712, który pozwala podpisywać strukturalne, czytelne komunikaty.
Każdy Payment Payload jest jasny i jednoznaczny — wszystkie parametry są objęte podpisem, więc nie można ich zmodyfikować.

Dla delegowanych i bezgazowych płatności wiele wdrożeń używa EIP-3009, który pozwala facilitatorowi wykonać transfer środków bez tego, by klient musiał inicjować transakcję na blockchainie.

Ta kombinacja sprawia, że x402 doskonale nadaje się do automatycznych, częstych i małych płatności.
Agent AI może wykonywać setki drobnych transakcji, nie angażując użytkownika.

Weryfikacja i bezpieczeństwo

Każde Payment Payload zawiera:

• unikalny identyfikator,
• czas wygaśnięcia,
• podpis powiązany z każdym parametrem.

Weryfikacja obejmuje:

• autentyczność podpisu,
• aktualność payloadu,
• ochronę przed powtórnym użyciem.

Serwer nie musi utrzymywać żadnych sesji ani stanów.
Z punktu widzenia bezpieczeństwa jest to ogromna zaleta, minimalna powierzchnia ataku.

Elastyczność rozliczania

x402 nie narzuca, jak należy wykonywać płatność.
Możliwe jest:

• settlement on-chain,
• użycie rollupów,
• kanały płatności,
• batchowanie wielu mikropłatności. Standard dopasowuje się do dowolnej architektury blockchainowej.

Latenacja i doświadczenie użytkownika

Serwer decyduje, czy ma czekać na finalność transakcji, czy odpowiedzieć natychmiast po weryfikacji.
W pierwszym przypadku latencja zależy od blockchaina, w drugim — wyłącznie od szybkości komunikacji z Facilitatorem.

Wybór zależy od potrzeb aplikacji:

• systemy finansowe mogą wymagać finalności,
• API wrażliwe na opóźnienia mogą preferować natychmiastową odpowiedź.

Dlaczego to podejście działa

x402 nie tworzy nowej ścieżki komunikacji, rozszerza tę, która istnieje od początku Webu.
Ten sam cykl, który odpowiada za autoryzację i cache, obsługuje teraz także płatności.

W rezultacie wartość może poruszać się przez internet dokładnie tak, jak dane:
lekko, przewidywalnie i w oparciu o standard, który zna każda aplikacja.

Ekosystem i adopcja

x402 został przedstawiony w maju 2025 roku jako otwarty standard Coinbase Developer Platform. Od tego czasu rozwija się szybko, wspierany przez duże firmy technologiczne i pierwsze wdrożenia deweloperskie. Ekosystem jest jeszcze młody, ale kierunek rozwoju jest wyraźny: x402 zaczyna przenikać zarówno tradycyjną infrastrukturę webową, jak i rosnący świat autonomicznych agentów.

Coinbase Developer Platform

Coinbase tworzy i utrzymuje referencyjną implementację x402, która obejmuje:

• middleware do popularnych frameworków (np. Express),
• biblioteki klienckie,
• gotowy kod integracyjny,
• przykładowe aplikacje.

Dostępna jest również publiczna instancja Managed Facilitatora, który obsługuje:

• weryfikację podpisów,
• realizację transakcji,
• płacenie za gaz,
• monitorowanie blockchaina.

Deweloperzy mogą aktywować x402, dodając kilka linijek kodu do istniejącego endpointu HTTP. Facilitator dba o całą resztę. Na start obsługiwane są płatności w USDC na Base (L2 Coinbase).

Ważne jest to, że mimo tego wygodnego punktu wejścia protokół pozostaje otwarty i neutralny. Każdy może uruchomić swojego własnego facilitatora i korzystać z x402 bez zależności od Coinbase.

Cloudflare i x402 Foundation

We wrześniu 2025 roku Coinbase i Cloudflare ogłosiły wspólnie powstanie x402 Foundation — fundacji odpowiedzialnej za rozwój specyfikacji, testy kompatybilności oraz edukację techniczną.

Wejście Cloudflare ma duże znaczenie, bo firma ta obsługuje znaczną część globalnego ruchu HTTP. Ich zaangażowanie otwiera drogę do:

• wsparcia x402 w Cloudflare Workers,
• integracji na warstwie edge,
• płatnych API z wbudowaną obsługą 402,
• dynamicznego przydzielania zasobów zgodnie z zapłatą.

Cloudflare bada również użycie x402 jako mechanizmu rate limiting za pomocą płatności.
Zamiast blokować ruch, serwer może zwrócić 402 i pozwolić klientowi wykupić wyższy limit zapytań.
Pasuje to idealnie do ich roli jako warstwy skalującej dla całego internetu.

Google i Agent Payments Protocol (AP2)

Google rozwija standard AP2, który definiuje sposób, w jaki agenci AI otrzymują pozwolenia, zarządzają swoim budżetem i wykonują transakcje.
x402 został jednym z pierwszych oficjalnych rozszerzeń płatności obsługiwanych w AP2.

Agent działający w ekosystemie Google może:

• wykryć 402 Payment Required,
• przeczytać Payment Requirements,
• stworzyć Payment Payload,
• podpisać go,
• i ponowić żądanie, całkowicie autonomicznie.

AP2 zajmuje się warstwą uprawnień użytkownika i kontrolą wydatków, a x402 dostarcza natywny mechanizm płatniczy na poziomie Webu.

W ten sposób x402 staje się podstawową metodą płatności nie tylko dla ludzi, ale także dla agentów AI, którzy muszą opłacać dostęp do danych, kontekstu lub mocy obliczeniowej.

Wczesne wdrożenia deweloperskie

Społeczność open source szybko zaczęła tworzyć projekty wspierające x402.
Wśród pierwszych inicjatyw pojawiają się:

• x402-Express i x402-Next - wtyczki do frameworków Node.js,
• x402-MCP Adapter - integracja z Model Context Protocol,
• x402-Bazaar - indeks usług i API obsługujących x402,
• lekkie implementacje facilitatorów w Pythonie i Go.

Wszystkie bazują na tym samym założeniu: integracja x402 wymaga minimalnego wysiłku i nie wymusza zmiany stosu technologicznego.

Zainteresowanie firm i instytucji

Firmy z różnych branż widzą w x402 możliwość tworzenia nowych modeli rozliczeń:

• dostawcy danych mogą sprzedawać metadane per zapytanie,
• wydawcy mogą sprzedawać pojedyncze artykuły bez subskrypcji,
• API infrastrukturalne mogą pobierać opłaty za każdy request lub za jednostkę przetwarzania,
• platformy AI mogą wyceniać dostęp do kontekstu lub obliczeń.

Ponieważ x402 definiuje jedynie handshake, a nie platformę, nadaje się zarówno do projektów enterprise, jak i małych, niezależnych usług.

Perspektywy ekologii x402

Ekosystem x402 jest młody, ale rośnie szybko w trzech kierunkach:

1. Web Infrastructure
Możliwe wsparcie w CDN-ach, reverse proxy i narzędziach edge.

2. Blockchain Settlement
Wsparcie dla kolejnych L2 i tokenów zwiększy zasięg standardu.

3. Agentic AI
x402 może stać się domyślną płatnościową warstwą dla sztucznych agentów.

Połączenie wysiłków Coinbase, Cloudflare i Google stawia x402 w wyjątkowej pozycji.
Jeśli trend się utrzyma, protokół może stać się fundamentem nowej generacji sieci, w której płatności działają tak naturalnie, jak przesyłanie danych.

Ryzyka i otwarte pytania

Każdy protokół, który dotyka pieniędzy, musi mierzyć się z pytaniami o zaufanie, bezpieczeństwo i sposób, w jaki zachowa się w realnych wdrożeniach. x402 nie jest wyjątkiem. Jego projekt celowo stawia na prostotę i integrację z istniejącym Webem, ale równocześnie tworzy obszary napięć, które będą wymagały dopracowania wraz z dojrzewaniem ekosystemu.

Governance i standaryzacja

Obecnie x402 jest utrzymywany przez x402 Foundation, inicjatywę Coinbase i Cloudflare. Fundacja odpowiada za rozwój specyfikacji, testy interoperacyjności i kierunek rozwoju standardu. Jest to otwarta struktura, ale wciąż zależna od kilku kluczowych podmiotów.

Aby x402 mogło stać się prawdziwym standardem internetowym, konieczna będzie szersza, bardziej neutralna governance, w stylu W3C lub IETF.
Bez tego adopcja może ograniczyć się do ekosystemów zbudowanych przez obecnych sponsorów.

Wyzwanie: jak zapewnić neutralność i otwartość, nie hamując jednocześnie rozwoju i innowacji?

Koncentracja w warstwie facilitatorów

Facilitatorzy są praktycznym fundamentem x402. Zapewniają weryfikację podpisów, wykonują transakcje i pokrywają koszt gazu. Choć każdy może uruchomić własny serwer, naturalne efekty skali mogą prowadzić do koncentracji.

Ryzyko jest inne niż w przypadku tradycyjnych procesorów płatności, bo facilitatorzy nie mają dostępu do środków użytkowników, a jedynie wykonują podpisane instrukcje. Mimo to nadmierna zależność od kilku operatorów może stworzyć punkty centralne.

Społeczność będzie musiała zadbać o to, aby warstwa facilitatorów pozostała otwarta, różnorodna i wymienialna.

Bezpieczeństwo i ochrona przed powtórzeniami

x402 opiera się na podpisanych, jednoznacznych komunikatach. To ogromna przewaga, ale wymaga poprawnej implementacji.
Błędy w obsłudze nonce, expiresAt lub paymentId mogą prowadzić do:

• ataków replay,
• podwójnych rozliczeń,
• niepoprawnych walidacji.

Specyfikacja opisuje dobre praktyki, ale to implementacje zdecydują o rzeczywistym bezpieczeństwie.
W dłuższej perspektywie ekosystem będzie potrzebował test-suite, walidatorów i certyfikowanych bibliotek.

Ekonomika i koszty sieci

Model x402 zakłada tanie warstwy settlementu.
Jeśli koszt transakcji w sieci gwałtownie wzrośnie, mikrotransakcje przestaną mieć sens.

Rollupy, batchowanie i kanały płatności mogą pomóc, ale protokół nadal zależy od:

• niskich opłat sieciowych,
• stabilnych stablecoinów,
• dostępności tanich sieci L2.

x402 musi więc pozostać elastyczny i potrafić korzystać z różnych sieci i mechanizmów, aby przetrwać fluktuacje ekonomiczne.

Prywatność i ochrona danych

Payment Payloads ujawniają adresy, kwoty i szczegóły płatności.
Na publicznej sieci blockchain dane są widoczne dla każdego.

Aplikacje enterprise czy użytkownicy indywidualni mogą oczekiwać większej prywatności.
Standard nie definiuje natywnych mechanizmów ukrywania danych, ale przyszłe rozszerzenia mogłyby wprowadzać:

• nagłówki zaszyfrowane,
• dowody oparte na ZK,
• prywatne kanały settlementu.

Na razie prywatność musi być rozwiązana na poziomie aplikacji.

Regulatory i wymogi prawne

x402 sam w sobie nie dotyka środków i nie pełni roli instytucji finansowej.
Ale facilitator, który wysyła transakcje w imieniu użytkownika, może w zależności od jurysdykcji:

• podlegać wymogom KYC,
• być traktowany jako dostawca usług finansowych,
• podlegać obowiązkom raportowania.

Brak jasności regulacyjnej może prowadzić do powstania silnie zróżnicowanych rynków.
W przyszłości standard będzie potrzebował wytycznych, które pomogą operatorom facilitatorów działać legalnie i w sposób przewidywalny.

Doświadczenie użytkownika i przyjęcie standardu

Dla agentów i systemów Machine to Machine x402 jest naturalny. Dla ludzi — nie zawsze.
Większość portfeli nie jest przystosowana do częstych mikropłatności. Brakuje:

• limitów wydatków,
• automatycznych zgód,
• bezpiecznego delegowania podpisów.

Smart-wallety, takie jak te oparte na ERC-4337, mogą to zmienić, ale to dopiero początek tej technologii. Najważniejsze pytanie brzmi:
Jak sprawić, aby x402 był tak samo wygodny dla użytkownika, jak jest dla agenta AI?

Podsumowanie

x402 działa na styku dwóch światów: internetu i blockchaina.
Jest elegancki w swojej prostocie, ale musi jeszcze wykazać się w praktyce.
Największym wyzwaniem będzie utrzymanie równowagi między:

• prostotą,
• rozszerzalnością,
• decentralizacją,
• bezpieczeństwem,
• a zgodnością regulacyjną.

Od tego zależy, czy x402 stanie się trwałym fundamentem Webu, czy jedynie pierwszym krokiem w stronę bardziej zaawansowanych standardów płatności w sieci.

Wnioski i TL;DR

x402 jest niewielkim protokołem o dużym znaczeniu.
Dodaje do internetu coś, czego brakowało od początku jego istnienia: natywny sposób przesyłania wartości. Wykorzystuje do tego najprostszy i najbardziej rozpowszechniony mechanizm, jaki oferuje sieć, czyli HTTP. Status 402 Payment Required przestaje być martwym miejscem w specyfikacji i staje się funkcjonalnym elementem ekonomii Webu.

Najważniejsze jest to, czego x402 nie robi.
Nie tworzy nowego systemu finansowego.
Nie próbuje zastąpić istniejących sieci blockchain.
Nie zmusza do migracji infrastruktury.

Zamiast tego wypełnia brakującą warstwę sygnalizacyjną:
wspólny, otwarty handshake, który mówi „ta treść kosztuje”, „to żądanie zostało opłacone” i „ta transakcja jest ważna”.

Wszystko inne, settlement, automatyzacja agentów, stabilność portfeli, modele płatności, można zbudować na tej bazie.
Właśnie ta powściągliwość jest siłą x402. Protokół łączy prostotę HTTP z bezpieczeństwem podpisów kryptograficznych, sprawiając, że informacja i wartość mogą podróżować w jednym rytmie.

Proste wdrożenie sprawia, że x402 działa już dziś.
Dodanie płatnego endpointu wymaga tylko kilku linijek kodu.
Facilitatorzy pozwalają na wygodę i automatyzację, a zespoły o wyższych wymaganiach mogą samodzielnie prowadzić własną infrastrukturę.
Po wprowadzeniu 402 Payment Required na serwerze relacja klient–serwer przestaje być wyłącznie wymianą danych. Staje się wymianą wartości.

Przyszłość przyniesie nowe pytania o governance, decentralizację facilitatorów i doświadczenie użytkownika.
Jednak fundament już istnieje.
HTTP zyskało język płatności.
I działa zarówno dla ludzi, jak i dla maszyn oraz agentów AI.

Jeśli HTTP sprawiło, że Web stał się czytelny, a REST sprawił, że stał się programowalny, to x402 może być tym elementem, który uczyni go płatnym.

Źródła i literatura

X402. x402: An Open Standard for Internet–Native Payments, Whitepaper, 6 maja 2025.
https://www.x402.org/x402-whitepaper.pdf

Coinbase Developer Platform. x402 GitHub Repository, 2025.
https://github.com/coinbase/x402

Fielding, R. i in. Hypertext Transfer Protocol (HTTP/1.1) RFC 2616, IETF, 1999.
https://www.rfc-editor.org/rfc/rfc2616

Buterin, V. i in. EIP-712: Ethereum Typed Structured Data Hashing and Signing, 2017.
https://eips.ethereum.org/EIPS/eip-712

Interledger Foundation. Interledger Protocol Specification (IL-RFC-0001), 2017.
https://interledger.org/rfcs/0001-interledger-protocol/

Lightning Labs. LSAT: Lightning Service Authentication Tokens Overview, 2020.
https://lightning.engineering/posts/2020-03-30-lsat/

Stripe. API Overview, dokumentacja, 2024.
https://stripe.com/docs/api

Ethereum Foundation. ERC-4337: Account Abstraction via Entry Point Contract Specification, 2023.
https://eips.ethereum.org/EIPS/eip-4337

Cloudflare. Introducing the x402 Foundation, 2025.
https://blog.cloudflare.com/

Google. Agent Payments Protocol (AP2) Overview, 2025.
https://developers.google.com/agent-payments