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 wykorzystuje402 Payment Requiredorazaccepts, 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, trybEVMAccountSignerw 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:PAYMENT-SIGNATURE. Struktura (wyciąg):
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
Pełne podpisanie createX402PaymentHandler
(ctx) => Promise<{ headers: Record<string, string> }> , co idealnie pasuje do podpisu hooka paymentHandler SDK.
Użycie 1: Przeglądarka (MetaMask / WalletConnect)
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 podstawowegosignEVMUptoPayment, samodzielnie łączącaccepts → 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
exact, więc preferScheme nie działa na Solanie.
Trzy, Python: tryb klucza prywatnego
Pythonacedatacloud-x402 korzysta z bezpośredniego podpisywania kluczem prywatnym (bez abstrakcji EIP-1193), co jest bardziej odpowiednie dla serwerów / wykonawców zadań.
Instalacja
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 zMaxUint256. acedatacloud-x402 zawiera wbudowane approve_permit2:
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).- Nie przekazano
apiToken, SDK konstrukcja nie zgłasza błędu, co dowodzi, że tryb X402 jest rzeczywiście legalnym zamiennikiem tokena. createX402PaymentHandlerzwraca 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 Pythonacreate_x402_payment_handlerrównież przeprowadził tę samą weryfikację — wartość zwracana funkcji jest callable, a wstrzyknięciepayment_handler=...podczasAceDataCloud(...)nie zgłasza błędu. Obie strony są zgodne semantycznie.
Pięć, porównanie z „trybem tokena Bearer”
VI. Częste pułapki
- klasa chat musi mieć
preferScheme=upto: użycieexactspowoduje, że facilitator odliczy USDC wedługmaxAmountRequired(nie rzeczywistego zużycia). - Nie przesyłaj surowego klucza prywatnego do
createX402PaymentHandler: pakiet TS nie akceptuje{ privateKey }, musi być opakowany jako dostawca EIP-1193 (zalecany viemWalletClient). - 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.
- 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. - 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. - Najstabilniejszy sposób dostosowania
viem:evmProvider: walletClient as anystraci sprawdzanie typów, ale ma najlepszą kompatybilność; jeśli chcesz zachować typy, użyj.transport.requestviem, aby osobno opakować obiekt{ request }.

