Skip to main content
X402 es un protocolo de pago en cadena “facturado por HTTP 402” propuesto por Coinbase: el servidor devuelve 402 Payment Required en solicitudes sin token, junto con el campo accepts: [...] que enumera las cadenas / activos / precios aceptables; el cliente firma localmente una autorización (en EVM es Permit2 / EIP-712, en Solana es la autorización de transferencia de token SPL), coloca el envelope codificado en base64 en el encabezado PAYMENT-SIGNATURE y lo reenvía. El servidor verifica y luego realiza el ajuste en la cadena, devolviendo el resultado del negocio.
El cliente X402 de Ace Data Cloud llama directamente a la API objetivo y utiliza el 402 Payment Required y accepts devueltos en tiempo real como base para el precio y la firma. La capacidad de pago del Facilitador se puede verificar en /.well-known/x402.
@acedatacloud/sdk y acedatacloud exponen un gancho paymentHandler: cuando una solicitud emitida por el SDK recibe un 402, se llama a tu manejador inyectado para obtener el encabezado PAYMENT-SIGNATURE, y luego se reenvía la solicitud original. Al combinar @acedatacloud/x402-client / acedatacloud-x402 con el SDK, todo el proceso es completamente transparente para el código de negocio: solo necesitas usar client.openai.chat.completions.create(...), que se ve igual que el modo token, pero en el fondo se paga por uso, sin necesidad de recarga previa. Este artículo:
  • Realizó una prueba completa del enlace “sin token + inyección de manejador X402” en el lado de TS (Verificación T12)
  • Enumeró las diferencias entre los enlaces de firma de EVM / Solana
  • Proporcionó tres adaptaciones: modo de clave privada viem, modo de billetera de navegador, modo EVMAccountSigner de Python
  • Aclaró el campo preferScheme / prefer_scheme, que es fácil de confundir

I. Visión general del protocolo (imprescindible)

Una llamada exitosa a X402 implica 3 RTT HTTP:
El envelope de X402 es un JSON que se codifica en base64 y se coloca en el encabezado PAYMENT-SIGNATURE. Estructura (extracto):
El nivel superior del envelope es x402Version: 2, y utiliza el objeto accepted para declarar el scheme y network seleccionados (identificación CAIP-2). preferScheme / prefer_scheme se utiliza para seleccionar una preferencia cuando el servidor ofrece múltiples schemes al mismo tiempo. Si el servidor solo expone exact, este campo será ignorado; si se establece upto pero el servidor no lo expone, se retrocederá al primer elemento coincidente.

II. TypeScript: uso de billetera de navegador + viem en el servidor

Instalación

Números de versión probados:

Firma completa de createX402PaymentHandler

El valor de retorno es un (ctx) => Promise&lt;{ headers: Record<string, string> }> que coincide exactamente con la firma del gancho paymentHandler del SDK.

Uso 1: Navegador (MetaMask / WalletConnect)

La primera vez que se llama, el navegador mostrará dos solicitudes de firma: la primera es la aprobación única de Permit2 para USDC (la cantidad es MaxUint256, escrita en la cadena); la segunda es la firma EIP-712 del envelope X402 (no se escribe en la cadena, solo se proporciona para la verificación del facilitador). Las llamadas posteriores solo requieren la segunda firma, la experiencia es “un clic para firmar → obtener resultado”.

Uso 2: Servidor Node + clave privada viem (adecuado para backend / CLI)

@acedatacloud/x402-client en el lado de TS solo acepta proveedor EIP-1193: no maneja directamente la clave privada. En escenarios de Node / CLI, la práctica estándar es usar viem para empaquetar la clave privada en un WalletClient, y luego usar @ethereumjs/util o la adaptación EIP-1193 interna de viem.
Si sientes que la adaptación de EIP-1193 de viem no es lo suficientemente estable, también puedes optar por un nivel más bajo signEVMUptoPayment, conectando tú mismo accepts → signed envelope → PAYMENT-SIGNATURE header, saltándote los ganchos del SDK; sin embargo, se recomienda seguir utilizando createX402PaymentHandler para evitar tener que mantener las actualizaciones del protocolo.

Uso 3: Solana

La cadena de Solana actualmente solo expone el esquema exact, por lo que preferScheme no tiene efecto en Solana.

Tres, Python: Modo de clave privada

El acedatacloud-x402 de Python sigue el camino de firmar directamente con la clave privada (sin abstracción EIP-1193), siendo más adecuado para servidores / ejecutores de tareas.

Instalación

Versión comprobada:

EVM (Base / Skale)

Solana

Aprobación única (solo EVM la primera vez)

En EVM Base, X402 utiliza Permit2, lo que requiere que la billetera haga una aprobación de MaxUint256 para el contrato Permit2 de USDC. acedatacloud-x402 incluye approve_permit2:
Esta transacción solo necesita enviarse una vez, después de lo cual todos los pagos X402 EVM utilizarán esta autorización. Solana no lo necesita.

Cuatro, Verificación de ejecución real

Objetivo de prueba: SDK de TS sin pasar token, inyectar el controlador X402, puede construir y enviar solicitudes correctamente (verificación ligera que no consume USDC en la cadena real).
Salida:
Resultados:
  • No se pasó apiToken, el SDK se construyó sin errores, lo que demuestra que el modo X402 es efectivamente un reemplazo legítimo del token.
  • createX402PaymentHandler devuelve una función (gancho), que el SDK solo llamará al recibir un 402.
  • La prueba de extremo a extremo de pago en la cadena real, debido a la implicación de deducción real de USDC, no se incluyó en este tutorial; se puede consultar el Guía de integración X402 para ejemplos e2e.
El lado de Python create_x402_payment_handler también realizó la misma verificación: el valor de retorno de la función es callable, y al inyectar payment_handler=..., AceDataCloud(...) se construye sin errores. La semántica está alineada en ambos lados.

Cinco, Comparación con el “Modo de token Bearer”

Seis, trampas comunes

  1. La clase chat debe tener preferScheme=upto: usar exact hará que el facilitador deduzca USDC según maxAmountRequired (no según el uso real).
  2. No pasar la clave privada en bruto al createX402PaymentHandler en el lado del nodo: el paquete TS no acepta { privateKey }, debe estar empaquetado como un proveedor EIP-1193 (se recomienda viem WalletClient).
  3. La primera llamada es una doble firma: la primera vez se firma el permiso 2 (en la cadena, con gas), la segunda vez se firma el sobre X402 (sin estar en la cadena). Las llamadas posteriores solo requieren la segunda firma.
  4. Solana no tiene el concepto de Permit2: se autoriza directamente la transferencia de tokens SPL, no se necesita aprobar; pero actualmente, en la cadena de Solana solo se admite exact.
  5. Diferenciación entre errores de negocio y errores de pago: 402 → el manejador falla y lanza X402SignError (el tipo específico varía según la cadena); los errores de la interfaz de negocio tras un reenvío posterior (401 / 422 / 5xx) se clasifican como excepciones normales del SDK.
  6. La forma más estable de adaptar viem: evmProvider: walletClient as any perderá la verificación de tipos pero tendrá la mejor compatibilidad; si se desea mantener el tipo, se debe usar .transport.request de viem para empaquetar por separado un objeto { request } y pasarlo.

Conocer más