Skip to main content
X402 is an on-chain payment protocol proposed by Coinbase that charges based on HTTP 402: the server returns 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 the 402 Payment Required and accepts returned 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: viem private key mode, browser wallet mode, Python EVMAccountSigner mode
  • Clarifies the preferScheme / prefer_scheme field, which is easy to trip over

I. Protocol Overview (Must Read)

A successful X402 call involves 3 HTTP RTTs:
The X402 envelope is a JSON object that is base64 encoded and placed in the PAYMENT-SIGNATURE header. Structure (excerpt):
The top level of the envelope is 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

Tested version numbers:

createX402PaymentHandler Complete Signature

The return value is a (ctx) => Promise&lt;{ headers: Record<string, string> }> that matches the SDK’s paymentHandler hook signature.

Usage 1: Browser (MetaMask / WalletConnect)

The first call will prompt for two signature approvals in the browser: the first is a one-time approve for USDC via Permit2 (the amount is 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-level signEVMUptoPayment to manually connect accepts → signed envelope → PAYMENT-SIGNATURE header, bypassing the SDK hooks; however, it is still recommended to prioritize createX402PaymentHandler to avoid maintaining protocol upgrades yourself.

Usage 3: Solana

Currently, the Solana chain only exposes the exact scheme, so preferScheme does not work on Solana.

Three, Python: Private Key Mode

The Python acedatacloud-x402 follows the directly signing with the private key approach (without EIP-1193 abstraction), which is more suitable for server-side/task executors.

Installation

Tested version numbers:

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-time MaxUint256 approve to the Permit2 contract for USDC. The acedatacloud-x402 has a built-in approve_permit2:
This transaction only needs to be sent once, after which all X402 EVM payments will use this authorization. Solana does not require this.

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).
Output:
Results explanation:
  • No apiToken was passed, and the SDK construction does not throw an error, proving that X402 mode is indeed a legitimate alternative to the token.
  • createX402PaymentHandler returns 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 side create_x402_payment_handler also performed the same verification — the function return value is callable, and injecting payment_handler=... does not throw an error when constructing AceDataCloud(...). The semantics are aligned on both sides.

Five, Comparison with “Bearer Token Mode”