x402 to protokół umożliwiający płacenie za zasoby internetowe przez HTTP. Serwer zwraca wymagania płatności wraz z HTTP 402; zgodny klient autoryzuje płatność i ponawia żądanie, dołączając dane płatności.
W przypadku agenta AI może to sprawić, że pojedynczy płatny odczyt API stanie się częścią wykonywanego zadania. Portfel nadal musi mieć zgodę na wydanie środków, a usługa nadal musi dostarczyć wynik.
HTTP 402 staje się ofertą cenową
HTTP 402 to kod statusu „Payment Required” (wymagana płatność). x402 dodaje do niego zdefiniowany proces wymiany płatności; zwykłe przeglądarki nie stają się automatycznie autonomicznymi nabywcami tylko dlatego, że witryna zwraca ten status.
W obecnym przebiegu V2 serwer przekazuje wymagania przez PAYMENT-REQUIRED. Klient odpowiada ładunkiem danych płatniczych w PAYMENT-SIGNATURE. Serwer przekazuje wynik rozliczenia przez PAYMENT-RESPONSE. Nazwy nagłówków opisują odrębne etapy, a nie trzy płatności. HTTP 402 i nagłówki V2.
Wyobraź sobie agenta badawczego, który kupuje pojedynczą obserwację pogody na potrzeby planowania trasy. Fikcyjna oferta żąda $0.001 w USDC, podaje adres odbiorczy sprzedawcy i określa obsługiwaną sieć oraz schemat płatności dokładną kwotą. Zanim klient płatniczy będzie mógł kontynuować, musi rozpoznać te warunki. Ta cena jest przykładowa i nie stanowi rzeczywistej oferty usługi.
Oferta cenowa nie oznacza zgody na wydanie środków. Polityka portfela lub aplikacji powinna sprawdzić, czy kwota, sprzedawca i żądany zasób pasują do zadania. Serwer może podać nieuzasadnioną cenę, tak jak może to zrobić sprzedawca w kontakcie z człowiekiem.
Od bezpłatnego żądania do płatnej odpowiedzi
Agent autoryzuje płatność, a sprzedawca decyduje, kiedy udostępnić zasób.
Prześledź jedno płatne żądanie
Klient żąda zasobu. Serwer odpowiada, przedstawiając wymagania płatności. Klient wybiera obsługiwaną opcję i tworzy autoryzację lub ładunek płatności dla tej opcji. Następnie ponawia żądanie zasobu, dołączając te dane.
Serwer sprawdza płatność i obsługuje rozliczenie zgodnie z wybranym schematem i przepływem płatności. Domyślna autoryzacja jest weryfikowana przed uruchomieniem obsługi zasobu, a rozliczenie następuje później; w przepływie z płatnością z góry rozliczenie odbywa się przed uruchomieniem obsługi. Przepływy oparte na escrow wymagają zasilonych sald, a później pobrania środków lub ich wykupu. Sama dokładna cena nie mówi, kiedy rozpoczyna się obliczanie względem rozliczenia. Przegląd schematów i przepływów płatności.
To rozdzielenie pomaga zrozumieć awarię. Odrzucona autoryzacja oznacza, że usługa nie zaakceptowała proponowanej płatności. Transakcja wysłana do sieci i oczekująca na potwierdzenie może nadal przenieść środki. Zrealizowana płatność bez dostarczonego zasobu oznacza problem z dostawą.
Interfejs, który łączy te stany pod etykietą „płatność nieudana”, zachęca do kosztownych ponowień. Klient powinien zachować identyfikator żądania i uzgodnić status poprzedniej próby przed autoryzacją kolejnego zakupu. Oprogramowanie może znacznie szybciej niż człowiek powtórzyć błędny zakup.
Facilitator obsługuje techniczną stronę płatności
Facilitator może weryfikować ładunki płatnicze, wysyłać transakcje rozliczeniowe i przekazywać ich status. Serwer zasobu może korzystać z zarządzanego dostawcy produkcyjnego, prowadzić własną usługę lub samodzielnie obsługiwać te funkcje. Nie należy zakładać, że facilitator z publicznego quickstartu jest rozwiązaniem produkcyjnym dla każdej sieci. Dokumentacja facilitatora.
Wybrany facilitator wpływa na zależności operacyjne usługi. Sprzedawca potrzebuje obsługi swojej sieci, tokena i schematu płatności. Potrzebuje też działającej procedury na wypadek spowolnienia lub niedostępności dostawcy.
Weryfikacja bez powiernictwa nad środkami nie sprawia, że każda część działalności działa niezależnie. Dostawca może nie być w stanie wysłać transakcji, nie przechowując środków klienta. Brama API może przestać dostarczać zasoby, nie mając kontroli nad portfelem. Takie awarie powinny być ujęte w różnych częściach planu reagowania na incydenty.
Przed uruchomieniem płatnego endpointu przetestowałbym ścieżkę z produkcyjnym dostawcą i rzeczywistą konfiguracją kontraktu. Udana płatność testnetowa potwierdza, że integracja może działać w tym środowisku. Nie dowodzi jednak dostępności płynności, właściwego poziomu cen ani niezawodności w produkcji.
Schemat decyduje, kiedy przemieszczają się środki
Płatność dokładną kwotą określa z góry ustaloną sumę. Płatność „do kwoty” autoryzuje limit dla użycia, którego końcowy koszt może być niższy. Rozliczenie zbiorcze grupuje należności do późniejszego wykupu on-chain, a auth-capture obsługuje zwrotny model oparty na escrow. Są to różne opcje dla sprzedawcy naliczającego opłatę za żądanie lub jednostkę pracy. Schematy płatności.
Wyszukiwanie danych za stałą cenę rozwiązuje inny problem rozliczeniowy niż generowanie odpowiedzi, której koszt obliczeń zależy od długości wyniku. W tym drugim przypadku potrzebny jest jasny limit maksymalny i mierzalna opłata końcowa. Kupujący powinien wiedzieć, jak sprzedawca ją oblicza.
W udokumentowanym schemacie zbiorczych płatności EVM kupujący zasila escrow i podpisuje kupony z narastającą wartością. Sprzedawca może później je zrealizować i wypłacić środki w oddzielnej operacji rozliczeniowej. Wyjaśnia to, jak odroczone opłaty mogą pozostać możliwe do pobrania, a jednocześnie wprowadza dodatkowe zasady finansowania i wykupu, które trzeba sprawdzić. Mechanizm rozliczeń zbiorczych.
Dlatego miliona płatnych żądań nie należy automatycznie opisywać jako miliona transakcji blockchainowych. Artykuł o ekonomice mikropłatności analizuje koszty na poszczególnych warstwach zamiast używać liczby żądań jako przybliżenia przychodów sieci.
Model AI nie podpisuje płatności
Model może uznać, że zasób jest przydatny, i przekazać narzędziu żądanie zakupu. Usługa portfela lub komponent podpisujący tworzy zatwierdzone działanie finansowe. Te role powinny być widoczne w projekcie systemu.
Polecenie dla modelu, takie jak „wydawaj rozsądnie”, zapewnia słabszą ochronę niż egzekwowany limit transakcji. Lepsza konfiguracja sprawdza sprzedawcę, walutę, maksymalną kwotę i pozostały budżet, zanim osoba lub komponent podpisujący zatwierdzi żądanie.
Czym innym jest pojedynczy zakup, a czym innym stałe upoważnienie do wydawania środków. Płatność za jeden zasób nie powinna po cichu przyznawać sprzedawcy dostępu do nieograniczonego salda. Nasz artykuł o portfelach agentów wyjaśnia, jak powiernictwo i uprawnienia do wydawania środków wyznaczają tę granicę.
Tożsamość agenta jest osobną kwestią. Płatność potwierdza działanie finansowe w ramach danego mechanizmu. Nie dowodzi, że kupującym jest unikalny, kompetentny lub uczciwy agent AI. ERC-8004 dotyczy identyfikacji agentów i sygnałów zaufania wokół nich, a nie zastępuje wymiany płatniczej.
Płatność i użyteczne dostarczenie wymagają potwierdzeń
Usługa powinna jasno określać zasób i jednostkę rozliczeniową. „Jedna odpowiedź” może oznaczać wynik wyszukiwania, pełny zbiór danych albo stronę rekordów. Niejednoznaczne rozliczanie utrudnia porównywanie ofert zarówno ludziom, jak i agentom.
Podpisane oferty i potwierdzenia mogą pomóc powiązać zakup z zadeklarowanymi warunkami oraz zarejestrowanym wynikiem. Nadal nie dowodzą, że wszystkie fakty w dostarczonym zbiorze danych są prawidłowe. Kupujący potrzebuje sposobu oceny aktualności, pochodzenia i przydatności odpowiedzi do zadania. Podpisane oferty i potwierdzenia.
W przypadku kosztownej lub zmiennej pracy należy określić, co uznaje się za sukces podlegający opłacie. Pusty wynik może być prawidłową odpowiedzią na zapytanie, ale tę zasadę należy podać przed zakupem. To samo dotyczy nieudanego obliczenia lub niedostępnego źródła zewnętrznego.
Problem dystrybucji po stronie sprzedawcy pozostaje. Włączenie x402 nie sprawia, że endpoint staje się łatwy do znalezienia ani wart zapłaty. Sprzedaż danych agentom omawia tę stronę działalności.
Co sprawdzić w demonstracji x402
Szukaj widocznej wyceny, ograniczonej autoryzacji i osobnego wyniku rozliczenia. Poproś zespół, by ponowił żądanie po symulowanym przekroczeniu limitu czasu i pokazał, że pierwotny zakup nie jest obciążany dwukrotnie. Następnie zapytaj, co dzieje się, jeśli płatność zostanie zrealizowana, ale odpowiedź zaginie.
Dobra demonstracja kończy zadanie klienta w takich warunkach. Zrzut ekranu z eksploratora transakcji dowodzi znacznie mniej. Oprogramowanie kupujące zasób potrzebuje niezawodnej wymiany handlowej wokół transakcji.
Opis alternatywnego protokołu i podejścia do integracji sprzedawców znajdziesz w artykule x402 vs MPP. Wybór zaczyna się od modelu rozliczeń usługi i metod płatności dostępnych dla jej klientów.
Jeden timeout wymaga dwóch osobnych odpowiedzi
Załóżmy, że sprzedawca zaakceptował płatność za obserwację pogody, ale klient nigdy nie otrzymał odpowiedzi. Kolejny krok zależy od dwóch informacji: czy zakup został rozliczony i czy obserwacja została dostarczona?
Rozliczony zakup bez odpowiedzi wymaga ścieżki odzyskania dostawy. Odrzucona przed akceptacją autoryzacja wymaga wyjaśnienia niepowodzenia płatności. Jeśli wynik płatności pozostaje nieznany, przed kolejną autoryzacją trzeba uzgodnić status poprzedniej.
Jeśli rozszerzenie jest wdrożone, identyfikator płatności może pomóc powiązać ponowioną próbę z pierwotnym zakupem. Sprzedawca nadal musi określić zasady ponownego udostępnienia lub odzyskania zakupionego zasobu. Rozszerzenie Payment-Identifier.