Skip to main content
X402 to protokół płatności on-chain “rozliczany według HTTP 402” zaproponowany przez Coinbase: serwer zwraca 402 Payment Required w odpowiedzi na żądanie bez tokena, dołączając pole accepts: [...], które wymienia akceptowane łańcuchy / aktywa / ceny; klient lokalnie podpisuje autoryzację (na EVM to Permit2 / EIP-712, na Solanie to autoryzacja transferu tokenów SPL), a następnie umieszcza zakodowany w base64 envelope w nagłówku PAYMENT-SIGNATURE i ponownie wysyła. Serwer weryfikuje, a następnie rzeczywiście rozlicza na łańcuchu, zwracając wynik biznesowy.
Klient X402 w Ace Data Cloud bezpośrednio wywołuje docelowe API, a jako podstawę ceny i podpisu wykorzystuje 402 Payment Required oraz accepts, które są zwracane w czasie rzeczywistym. Możliwości płatnicze Facilitatora można zweryfikować w /.well-known/x402.
@acedatacloud/sdk i acedatacloud udostępniają hook paymentHandler: gdy żądanie wysłane przez SDK otrzymuje 402, wywołuje wstrzyknięty handler, aby uzyskać nagłówek PAYMENT-SIGNATURE, a następnie ponownie wysyła oryginalne żądanie. Używając @acedatacloud/x402-client / acedatacloud-x402 w połączeniu z SDK, cały proces jest całkowicie przezroczysty dla kodu biznesowego — wystarczy użyć client.openai.chat.completions.create(...), co wygląda identycznie jak w trybie tokenowym, ale w tle działa na zasadzie płatności za wywołania, bez potrzeby wcześniejszego doładowania. Artykuł:
  • Rzeczywiście przetestowano łańcuch “bez tokena + wstrzyknięcie handlera X402” na końcu TS (zobacz T12 weryfikacja)
  • Wymieniono różnice między dwiema ścieżkami podpisu EVM / Solana
  • Podano trzy sposoby adaptacji: tryb klucza prywatnego viem, tryb portfela przeglądarki, tryb EVMAccountSigner w Pythonie
  • Wyjaśniono pole preferScheme / prefer_scheme, które łatwo może prowadzić do błędów

I. Przegląd protokołu (obowiązkowe)

Udane wywołanie X402 wymaga 3 RTT HTTP:
Envelope X402 to fragment JSON, który po zakodowaniu w base64 jest umieszczany w nagłówku PAYMENT-SIGNATURE. Struktura (wyciąg):
Na najwyższym poziomie envelope znajduje się x402Version: 2, a obiekt accepted deklaruje wybrany scheme i network (identyfikator CAIP-2). preferScheme / prefer_scheme służy do wyboru preferencji, gdy serwer jednocześnie oferuje wiele schematów. Jeśli serwer udostępnia tylko exact, to pole zostanie zignorowane; jeśli ustawiono upto, ale serwer go nie udostępnia, nastąpi powrót do pierwszego pasującego elementu.

II. TypeScript: portfel przeglądarki + serwer viem, dwa sposoby użycia

Instalacja

Testowane numery wersji:

Pełne podpisanie createX402PaymentHandler

Wartością zwracaną jest (ctx) => Promise&lt;{ headers: Record<string, string> }> , co idealnie pasuje do podpisu hooka paymentHandler SDK.

Użycie 1: Przeglądarka (MetaMask / WalletConnect)

Podczas pierwszego wywołania przeglądarka wyświetli dwa razy prośbę o podpis: pierwszy raz to jednorazowe zatwierdzenie Permit2 dla USDC (kwota to MaxUint256, zapisana na łańcuchu); drugi raz to podpis EIP-712 dla envelope X402 (nie jest zapisywany na łańcuchu, tylko do weryfikacji przez facilitatora). Kolejne wywołania wymagają tylko drugiego podpisu, co w praktyce wygląda jak “jedno kliknięcie podpisu → uzyskanie wyniku”.

Użycie 2: Serwer Node + klucz prywatny viem (odpowiednie dla backendu / CLI)

@acedatacloud/x402-client w TS przyjmuje tylko dostawcę EIP-1193 — nie zarządza bezpośrednio kluczem prywatnym. W scenariuszu Node / CLI standardową praktyką jest użycie viem do opakowania klucza prywatnego w WalletClient, a następnie użycie @ethereumjs/util lub wewnętrznego adaptera EIP-1193 viem.
Jeśli uważasz, że dostosowanie EIP-1193 w viem nie jest wystarczająco stabilne, możesz również skorzystać z bardziej podstawowego signEVMUptoPayment, samodzielnie łącząc accepts → signed envelope → PAYMENT-SIGNATURE header, omijając haki SDK; jednak zaleca się, aby najpierw wybrać createX402PaymentHandler, aby nie musieć samodzielnie utrzymywać aktualizacji protokołu.

Użycie 3: Solana

Na łańcuchu Solana obecnie udostępniony jest tylko schemat exact, więc preferScheme nie działa na Solanie.

Trzy, Python: tryb klucza prywatnego

Python acedatacloud-x402 korzysta z bezpośredniego podpisywania kluczem prywatnym (bez abstrakcji EIP-1193), co jest bardziej odpowiednie dla serwerów / wykonawców zadań.

Instalacja

Wersja testowa:

EVM (Base / Skale)

Solana

Jednorazowe zatwierdzenie (tylko EVM przy pierwszym użyciu)

Na EVM Base X402 korzysta z Permit2, co wymaga, aby portfel zatwierdził USDC dla kontraktu Permit2 raz z MaxUint256. acedatacloud-x402 zawiera wbudowane approve_permit2:
Ta transakcja musi być wysłana tylko raz, a następnie wszystkie płatności X402 EVM będą korzystać z tego upoważnienia. Solana nie wymaga tego.

Cztery, rzeczywiste testy

Cel testowy: SDK TS nie przekazuje tokena, wstrzykuje handler X402, może normalnie skonstruować i zainicjować żądanie (nie zużywając prawdziwego USDC na łańcuchu).
Wynik:
Wyniki wskazują:
  • Nie przekazano apiToken, SDK konstrukcja nie zgłasza błędu, co dowodzi, że tryb X402 jest rzeczywiście legalnym zamiennikiem tokena.
  • createX402PaymentHandler zwraca funkcję (hook), a SDK wywołuje ją tylko, gdy otrzyma 402.
  • Rzeczywiste testy płatności na łańcuchu, ponieważ dotyczą prawdziwego pobierania USDC, nie zostały uwzględnione w tym przewodniku; można odwołać się do przewodnika integracji X402 w celu uzyskania przykładów e2e.
Po stronie Pythona create_x402_payment_handler również przeprowadził tę samą weryfikację — wartość zwracana funkcji jest callable, a wstrzyknięcie payment_handler=... podczas AceDataCloud(...) nie zgłasza błędu. Obie strony są zgodne semantycznie.

Pięć, porównanie z „trybem tokena Bearer”

VI. Częste pułapki

  1. klasa chat musi mieć preferScheme=upto: użycie exact spowoduje, że facilitator odliczy USDC według maxAmountRequired (nie rzeczywistego zużycia).
  2. Nie przesyłaj surowego klucza prywatnego do createX402PaymentHandler: pakiet TS nie akceptuje { privateKey }, musi być opakowany jako dostawca EIP-1193 (zalecany viem WalletClient).
  3. Pierwsze wywołanie to podwójne podpisanie: pierwsze podpisanie Permit2 approve (na łańcuchu, z gazem), drugie podpisanie X402 envelope (nie na łańcuchu). Kolejne wywołania to tylko drugie.
  4. Solana nie ma koncepcji Permit2: bezpośrednie podpisanie autoryzacji transferu tokenów SPL, nie wymaga approve; ale obecnie na łańcuchu Solana wspiera tylko exact.
  5. Rozróżnienie błędów biznesowych i błędów płatności: 402 → błąd handlera rzuca X402SignError (konkretna typ w zależności od łańcucha); późniejsze ponowne wysyłanie błędów interfejsu biznesowego (401 / 422 / 5xx) nadal klasyfikowane są jako zwykłe wyjątki SDK.
  6. Najstabilniejszy sposób dostosowania viem: evmProvider: walletClient as any straci sprawdzanie typów, ale ma najlepszą kompatybilność; jeśli chcesz zachować typy, użyj .transport.request viem, aby osobno opakować obiekt { request }.

Dowiedz się więcej