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 el402 Payment Requiredyacceptsdevueltos 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, modoEVMAccountSignerde 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:PAYMENT-SIGNATURE. Estructura (extracto):
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
Firma completa de createX402PaymentHandler
(ctx) => Promise<{ headers: Record<string, string> }> que coincide exactamente con la firma del gancho paymentHandler del SDK.
Uso 1: Navegador (MetaMask / WalletConnect)
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 bajosignEVMUptoPayment, conectando tú mismoaccepts → signed envelope → PAYMENT-SIGNATURE header, saltándote los ganchos del SDK; sin embargo, se recomienda seguir utilizandocreateX402PaymentHandlerpara evitar tener que mantener las actualizaciones del protocolo.
Uso 3: Solana
exact, por lo que preferScheme no tiene efecto en Solana.
Tres, Python: Modo de clave privada
Elacedatacloud-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
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 deMaxUint256 para el contrato Permit2 de USDC. acedatacloud-x402 incluye approve_permit2:
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).- 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. createX402PaymentHandlerdevuelve 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 Pythoncreate_x402_payment_handlertambién realizó la misma verificación: el valor de retorno de la función es callable, y al inyectarpayment_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
- La clase chat debe tener
preferScheme=upto: usarexacthará que el facilitador deduzca USDC segúnmaxAmountRequired(no según el uso real). - No pasar la clave privada en bruto al
createX402PaymentHandleren el lado del nodo: el paquete TS no acepta{ privateKey }, debe estar empaquetado como un proveedor EIP-1193 (se recomienda viemWalletClient). - 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.
- 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. - 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. - La forma más estable de adaptar
viem:evmProvider: walletClient as anyperderá la verificación de tipos pero tendrá la mejor compatibilidad; si se desea mantener el tipo, se debe usar.transport.requestde viem para empaquetar por separado un objeto{ request }y pasarlo.

