x402 i MPP pozwalają oprogramowaniu płacić za usługi internetowe, ale klient musi obsługiwać wybrany protokół i metodę płatności. Przed wyborem porównaj sposób rozliczania, obsługiwaną implementację i ścieżkę odzyskiwania płatności.
Wyszukiwanie o stałej cenie i sesja przeglądarki rozliczana według użycia wymagają innego sposobu ewidencji. Ani nazwa protokołu, ani opcja stablecoina nie informują, czy infrastruktura sprzedawcy obsługuje oba scenariusze.
Gdzie pojawia się żądanie płatności
x402 wykorzystuje odpowiedzi HTTP 402 do przekazania wymagań dotyczących płatności za zasób. Zgodny klient dostarcza dane płatności, a sprzedawca je weryfikuje i rozlicza w ramach wybranego schematu. Wersja V2 określa nagłówki związane z płatnością na potrzeby tej wymiany. Przepływ HTTP x402.
MPP również definiuje wyzwanie płatnicze HTTP i odpowiedź klienta, a potwierdzenia dokumentują udaną płatność. W tym projekcie żądana intencja płatnicza jest oddzielona od metody płatności użytej do jej realizacji. Machine Payments Protocol.
Wspólne cele nie zapewniają zgodności na poziomie transmisji. Klient i serwer muszą obsługiwać ten sam protokół, wersję i metodę. Usługa deklarująca obsługę obu musi poprawnie zaimplementować każdy z nich, zamiast zakładać, że jeden nagłówek można po prostu przemianować na drugi.
Framework agenta może obsługiwać kilka klientów płatniczych. To decyzja integracyjna dotycząca produktu, która wiąże się z kosztami testów i utrzymania. Agent nadal potrzebuje zasad określających, które oferty może przyjmować.
Wybierz sposób rozliczania, zanim wybierzesz protokół
Pojedyncze płatne żądanie i ciągła sesja rozliczana według użycia wymagają innego sposobu autoryzacji i ewidencji.
Protokół a operator płatności to różne rzeczy
Protokół opisuje sposób komunikacji uczestników. Integracja sprzedawcy zapewnia działający sposób weryfikacji płatności, transferu środków i ich ewidencjonowania. Opłaty handlowe, uprawnienia klientów i wsparcie operacyjne mogą zależeć od tej integracji.
Stripe współtworzył MPP z Tempo i opisuje integrację za pośrednictwem swojego API PaymentIntents. Ogłoszenie obejmuje opcje płatności stablecoinami i walutami fiducjarnymi, a Shared Payment Tokens służą do obsługiwanych tradycyjnych metod płatności. Ogłoszenie Stripe o MPP.
x402 również obsługuje różne sposoby korzystania z facilitatorów. Sprzedawca może skorzystać z zarządzanej usługi, uruchomić własny komponent facilitator albo realizować funkcje rozliczeniowe na swoim serwerze. Obsługiwane schematy i sieci zależą od wybranych komponentów. Ścieżki facilitatorów x402.
Ma to znaczenie przy porównywaniu opłat. Specyfikacja może być otwarta, a wygodna, zarządzana ścieżka może pobierać opłatę za obsługę usługi. Doświadczenie kupującego „bez opłat za gas” może oznaczać, że koszt sieci ponosi inna strona. Pełna wycena powinna wskazywać te strony.
Sesje zmieniają problem rozliczania
Sesja pozwala usłudze utrzymywać relację handlową w sekwencji interakcji. Może się sprawdzić przy strumieniowaniu wyników, wynajmie infrastruktury lub wielokrotnym użyciu narzędzia. Klient potrzebuje limitu wydatków, sposobu zatrzymania użycia i rejestru naliczonych opłat.
MPP zapewnia ścieżkę płatności zorientowaną na sesje w opisanym ekosystemie metod. Nie należy uogólniać tego na każdą implementację sprzedawcy i zakładać, że obsługuje wszystkie funkcje sesji. Obsługę metod trzeba sprawdzić po stronie klienta i serwera. Dokumentacja sesji MPP.
x402 nie ogranicza się do jednej stałej opłaty za każde wywołanie HTTP. Aktualny zestaw schematów obejmuje exact, up-to, rozliczenie zbiorcze oraz auth-capture. Porównanie przypisujące agregację wyłącznie MPP pomija część obecnych rozwiązań x402. Schematy płatności x402.
Praktyczne pytanie brzmi, jak usługa mierzy pracę. Łatwo zdefiniować opłatę za jeden element danych. Sesja badawcza bez określonego z góry końca wymaga zasad dotyczących anulowanych wywołań, niewykorzystanego budżetu i operacji o zmiennym koszcie.
Porównaj pełny zakup klienta
| Pytanie | Ścieżka x402 | Ścieżka MPP |
|---|---|---|
| Jak serwer żąda płatności? | HTTP 402 z informacją o schemacie i wymaganiach płatniczych | Wyzwanie płatnicze HTTP z informacją o intencji i metodzie |
| Jakie formy rozliczania należy sprawdzić? | Obsługa exact, up-to, rozliczeń zbiorczych i auth-capture | Opłaty jednorazowe i sesje zależne od metody |
| Kto wykonuje operacje płatnicze? | Wybrany facilitator albo implementacja po stronie serwera | Wybrana metoda płatności i integracja usługi |
| Czy kupujący musi korzystać z konkretnego łańcucha? | To zależy od akceptowanych par schemat/sieć | Zależy od wybranej metody, a nie od samej nazwy MPP |
| Co wymaga dodatkowej pracy nad produktem? | Zasady budżetowe, dostarczanie, wykrywanie i potwierdzenia | Zasady budżetowe, dostarczanie, wykrywanie i potwierdzenia |
Tabela przedstawia kwestie projektowe według stanu na 13 października 2026. Nie gwarantuje, że każde SDK lub operator obsługuje wszystkie opcje. Podczas przeglądu integracji należy określić konkretne wersje i obsługiwane ścieżki.
W przypadku wyszukiwania prognozy pogody za stałą cenę obie ścieżki wymagają jasnej oferty i możliwości odzyskania wyniku pojedynczego zakupu. W przypadku przeglądarki wynajmowanej na minuty zakończ sesję wcześniej i sprawdź końcową opłatę oraz niewykorzystaną autoryzację. Ten test ujawnia, czy integracja obsługuje sposób rozliczania oczekiwany przez klienta.
MPP opisuje też adaptery dla istniejących usług x402. Mogą one ograniczyć pracę integracyjną przy zachowaniu różnic między protokołami; nie sprawiają, że każdy klient automatycznie staje się zgodny z każdą metodą. Korzystanie z MPP w połączeniu z x402.
O wyborze zastosowania decydują przypadki błędów
Rozważ autoryzację płatności zaakceptowaną tuż przed przekroczeniem limitu czasu sieci. Kupujący nie wie, czy sprzedawca zrealizował żądanie. Ponowienie z nową płatnością może spowodować podwójne obciążenie, a ponowienie bez wystarczających informacji może pozostawić zadanie nierozstrzygnięte.
Integracja potrzebuje stabilnego identyfikatora zakupu i ścieżki uzgadniania. Potwierdzenie protokołu może pomóc opisać wynik płatności, ale usługa udostępniająca zasób nadal musi powiązać go z dostarczoną pracą. Identyfikatory płatności x402.
W przypadku sesji uwzględnij zawieszonego klienta i sprzedawcę, który nadal nalicza opłaty. Limit wydatków powinien być egzekwowany nawet po utracie połączenia przez agenta. Stwierdzenie „agent zamknie sesję” zapewnia słabą ochronę, jeśli agent uległ awarii.
To typowe operacje handlowe, a nie egzotyczne ataki. Testowanie ich daje lepszy dowód gotowości niż liczenie udanych żądań w bezproblemowej demonstracji.
Metoda płatności nie ocenia oferty
Agent może skutecznie zapłacić za zbiór danych niskiej jakości. Może kupić tę samą odpowiedź w kilku usługach albo zaakceptować cenę przewyższającą wartość zadania. Mechanizm płatniczy nie stwierdzi, że zakup był nieopłacalny.
Za tę decyzję odpowiadają zasady agenta i proces wyboru usługi. Artykuł o portfelu rozdziela limity transakcji od ogólnych budżetów zadań. Artykuł o tożsamości analizuje dowody, z których agent może korzystać przy ocenie innego agenta lub usługi.
Dla sprzedawców przewidywalna jakość odpowiedzi i ceny mogą mieć większe znaczenie niż niewielka różnica w kosztach obsługi płatności. Klient powinien móc ustalić, co otrzyma, zanim zapłaci. Przewodnik dla sprzedawców skupia się na tej ofercie.
Wybierz obsługiwaną ścieżkę, a potem ją porównaj
Zapisz aktywo płatnicze, metodę, jednostkę rozliczeniową i maksymalną kwotę narażoną na ryzyko. Ustal, kto składa transakcję rozliczeniową i w jaki sposób sprzedawca ewidencjonuje brak dostawy. Następnie przetestuj obie rozważane integracje przy tych samych ograniczeniach.
Sprzedawca korzystający już z platformy płatniczej może cenić jej księgowość i wsparcie. Usługa kierowana do klientów korzystających głównie ze stablecoinów może preferować inny model operacyjny. Żadna z tych preferencji nie sprawia, że dany protokół jest uniwersalnie lepszy.
Następnym krokiem jest porównanie finansowe. Nasz kalkulator mikropłatności pokazuje, jak częstotliwość rozliczeń może wpłynąć na wynik, nawet gdy klient płaci tę samą cenę za każde żądanie.
Przydatny test zgodności
Wybierz jeden punkt końcowy o stałej cenie i jedną sesję rozliczaną według użycia. Dla każdej rozważanej integracji zapisz wersję klienta, wersję sprzedawcy, akceptowaną metodę, maksymalną kwotę autoryzacji i sposób anulowania.
Klient, który przejdzie test stałej ceny, wykazał obsługę tej ścieżki. Nie dowodzi to obsługi strumieniowania, zamknięcia sesji ani każdej metody deklarowanej przez protokół. Podobnie adapter obsługujący płatność x402 nie potwierdza ogólnej zgodności z każdym schematem x402. Obsługiwany zakres wspólny to produkt, który możesz wdrożyć. Integracja MPP z x402.