402 Payment Required on requests without a token, along with the accepts: [...] field listing acceptable chains / assets / prices; the client locally signs an authorization (Permit2 / EIP-712 on EVM, SPL token transfer authorization on Solana), puts the base64-encoded envelope into the PAYMENT-SIGNATURE header, and resends. The server verifies and then settles on-chain, returning the business result.
The X402 client of Ace Data Cloud directly calls the target API and uses the402 Payment Requiredandacceptsreturned in real-time as the basis for pricing and signatures. The payment capability of the Facilitator can be verified at/.well-known/x402.
@acedatacloud/sdk and acedatacloud both expose a paymentHandler hook: when a request made by the SDK receives a 402, it calls your injected handler to get the PAYMENT-SIGNATURE header and then resends the original request. Using @acedatacloud/x402-client / acedatacloud-x402 with the SDK, the entire process is completely transparent to the business code—you only need to use client.openai.chat.completions.create(...), which looks exactly like the token model, but under the hood, it is pay-per-call without needing to pre-charge.
This article:
- Walks through the TS side of the “no token + X402 handler injection” link (see T12 Verification)
- Lists the differences between the EVM / Solana signature links
- Provides three adaptations:
viemprivate key mode, browser wallet mode, PythonEVMAccountSignermode - Clarifies the
preferScheme/prefer_schemefield, which is easy to trip over
I. Protocol Overview (Must Read)
A successful X402 call involves 3 HTTP RTTs:PAYMENT-SIGNATURE header. Structure (excerpt):
x402Version: 2, and the accepted object declares the chosen scheme and network (CAIP-2 identifier).
preferScheme / prefer_scheme is used to select a preference when the server provides multiple schemes simultaneously. If the server only exposes exact, this field will be ignored; if upto is set but the server does not expose it, it will fall back to the first matching item.
II. TypeScript: Browser Wallet + Server viem Two Usage Methods
Installation
createX402PaymentHandler Complete Signature
(ctx) => Promise<{ headers: Record<string, string> }> that matches the SDK’s paymentHandler hook signature.
Usage 1: Browser (MetaMask / WalletConnect)
MaxUint256, written to the chain); the second is the EIP-712 signature of the X402 envelope (not written to the chain, just for facilitator verification). Subsequent calls only require the second signature, making the experience “click once to sign → get result.”
Usage 2: Node Server + viem Private Key (suitable for backend / CLI)
@acedatacloud/x402-client on the TS side only accepts EIP-1193 providers—it does not directly manage private keys. In Node / CLI scenarios, the standard practice is to use viem to wrap the private key in a WalletClient, and then use @ethereumjs/util or viem’s internal EIP-1193 adapter.
If you find that the EIP-1193 adaptation of viem is not stable enough, you can also use the lower-levelsignEVMUptoPaymentto manually connectaccepts → signed envelope → PAYMENT-SIGNATURE header, bypassing the SDK hooks; however, it is still recommended to prioritizecreateX402PaymentHandlerto avoid maintaining protocol upgrades yourself.
Usage 3: Solana
exact scheme, so preferScheme does not work on Solana.
Three, Python: Private Key Mode
The Pythonacedatacloud-x402 follows the directly signing with the private key approach (without EIP-1193 abstraction), which is more suitable for server-side/task executors.
Installation
EVM (Base / Skale)
Solana
One-time approve (only for EVM first time)
On EVM Base, X402 uses Permit2, requiring the wallet to make a one-timeMaxUint256 approve to the Permit2 contract for USDC. The acedatacloud-x402 has a built-in approve_permit2:
Four, Real Operation Verification
Test objective: TS SDK does not pass token, inject X402 handler, can normally construct and initiate requests (lightweight verification without consuming real USDC on the chain).- No
apiTokenwas passed, and the SDK construction does not throw an error, proving that X402 mode is indeed a legitimate alternative to the token. createX402PaymentHandlerreturns a function (hook), which the SDK will only call when it receives a 402.- Actual end-to-end testing of payment on the chain is not included in this tutorial due to real USDC deductions; you can refer to the X402 Integration Guide for e2e examples.
The Python sidecreate_x402_payment_handleralso performed the same verification — the function return value is callable, and injectingpayment_handler=...does not throw an error when constructingAceDataCloud(...). The semantics are aligned on both sides.

