Construyendo Comercio Agéntico #4: Pagos Stablecoin x402 — Cuando los Agentes Pagan en USDC
Cómo los agentes IA realizan pagos on-chain en USDC usando el protocolo x402 — liquidación multi-cadena, firmas EIP-712 y checkout con stablecoins listo para producción.
Resumen ejecutivo
Parte 4 de 'Construyendo Comercio Agéntico' explica el protocolo de pagos stablecoin x402 — cómo los agentes IA descubren merchants habilitados para x402, firman autorizaciones EIP-712, liquidan on-chain vía facilitadores y manejan reintentos con backoff exponencial. Cubre 5 cadenas soportadas, conversión de montos USDC, protección SSRF y 197 tests.
Publicado
2026-04-06
14 min
Autoría
AgenticMCPStores Engineering
Core Protocol Team
Categoría
developer-guide
En las tres primeras partes de esta serie, cubrimos checkout multi-protocolo, descubrimiento de agentes vía NLWeb y trust scores. Ahora abordamos el protocolo que hace a los agentes verdaderamente autónomos: x402 — pagos stablecoin donde los agentes pagan directamente on-chain en USDC.
Por Qué los Pagos Stablecoin Importan para Agentes
Los protocolos de pago tradicionales (redes de tarjetas, PayPal) requieren identidad humana — un titular de tarjeta, una cuenta PayPal, una dirección de facturación. Los agentes IA no tienen nada de esto. El protocolo x402 resuelve esto usando autenticación basada en wallets: un agente demuestra que puede pagar firmando una autorización criptográfica, y la liquidación ocurre on-chain sin ningún requisito de identidad humana.
El código de estado HTTP 402 ("Payment Required") fue reservado en la especificación HTTP original pero nunca se estandarizó. El protocolo x402 finalmente le da una implementación concreta: cuando un servidor devuelve HTTP 402, incluye un requisito de pago legible por máquinas que un agente puede cumplir autónomamente.
Cómo Funciona x402: El Flujo Completo
Paso 1: El Agente Solicita un Recurso
PAYMENT-SIGNATURE (formato V2, confianza 0.95) o X-PAYMENT (V1 legacy, confianza 0.90). Un header explícito X-Protocol: X402 da confianza 1.0. POST /api/v1/agent/checkout HTTP/1.1
Host: api.agenticmcpstores.com
Content-Type: application/json
PAYMENT-SIGNATURE: eyJzaWduYXR1cmUiOiIweGFiYy4uLiIsImF1dGhvcml6YXRpb24iOnsiZnJvbSI6IjB4MTExMSIsInRvIjoiMHgyMjIyIiwidmFsdWUiOiI1MDAwMDAwIiwidmFsaWRBZnRlciI6IjE3MTI1MDAwMDAiLCJ2YWxpZEJlZm9yZSI6IjE3MTI1MDM2MDAiLCJub25jZSI6IjB4ZGVhZGJlZWYifSwic2NoZW1lIjoiZXhhY3QiLCJuZXR3b3JrIjoiYmFzZSJ9
{"items": [{"productId": "prod_001", "quantity": 1}]}Paso 2: El Servidor Devuelve HTTP 402
PaymentRequired con la wallet del merchant, red y dirección del token USDC. Se codifica en base64 en el header PAYMENT-REQUIRED: HTTP/1.1 402 Payment Required
PAYMENT-REQUIRED: eyJzY2hlbWUiOiJleGFjdCIsIm5ldHdvcmsiOiJiYXNlIi4uLn0=
{
"paymentRequired": {
"scheme": "exact",
"network": "base",
"maxAmountRequired": "5000000",
"payTo": "0x2222...merchant_wallet",
"maxTimeoutSeconds": 1800,
"extra": {
"tokenAddress": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",
"name": "USDC",
"version": "2"
}
},
"facilitator": {
"verifyUrl": "https://x402.org/facilitator/verify",
"settleUrl": "https://x402.org/facilitator/settle"
}
}El monto 5000000 representa 5 USDC. USDC usa 6 decimales, entonces 1 USDC = 1,000,000 unidades mínimas. La conversión: centavos USD × 10,000 = unidades mínimas USDC.
Paso 3: El Agente Firma y Liquida
PaymentRequired, firma una autorización EIP-712 de datos tipados con su clave privada, y envía al endpoint de liquidación. La autorización V2 incluye protección contra replay (nonce), límites temporales (validAfter, validBefore), y el monto exacto:// Payload PAYMENT-SIGNATURE V2 (decodificado de base64)
{
"signature": "0xabc123...firma_eip712",
"authorization": {
"from": "0x1111...wallet_agente",
"to": "0x2222...wallet_merchant",
"value": "5000000",
"validAfter": "1712500000",
"validBefore": "1712503600",
"nonce": "0xdeadbeef"
},
"scheme": "exact",
"network": "base"
}Paso 4: Liquidación con Backoff Exponencial
x402_pending_payment, (2) verificar la firma vía el endpoint /verify del facilitador — si es inválida, la orden falla inmediatamente sin reintento, (3) intentar liquidación vía /settle con hasta 5 reintentos usando backoff exponencial (5s → 10s → 20s → 40s), y (4) actualizar la orden a completed con el hash de la transacción on-chain, o x402_failed si se agotan todos los reintentos.// Lógica de reintento de liquidación (simplificada)
for (let attempt = 0; attempt < 5; attempt++) {
if (attempt > 0) {
await sleep(5000 * Math.pow(2, attempt - 1)); // 5s, 10s, 20s, 40s
}
const result = await fetch(facilitator.settleUrl, {
method: "POST",
body: JSON.stringify({ paymentPayload, paymentRequired }),
signal: AbortSignal.timeout(15_000) // 15s timeout por solicitud
});
if (result.success) {
return { status: "COMPLETED", txHash: result.txHash };
}
}
return { status: "FAILED" };Cadenas y Tokens Soportados
AgenticMCPStores soporta pagos x402 en 5 redes blockchain, todas usando USDC como token de liquidación:
- 1Base — USDC en
0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913(recomendada: fees más bajos) - 2Ethereum — USDC en
0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48 - 3Polygon — USDC en
0x3c499c542cEF5E3811e1192ce70d8cC03d5c3359 - 4Arbitrum — USDC en
0xaf88d065e77c8cC2239327C5EDb3A432268e5831 - 5Solana — USDC en
EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v
Los merchants pueden sobrescribir la dirección USDC por defecto con un tokenAddress personalizado en su configuración de protocolo. También se soporta un límite de seguridad maxTransactionAmount por transacción.
Conversión de Montos: USDC ↔ Centavos USD
// Inbound: unidades mínimas USDC → centavos USD
// 1 USDC (1,000,000 unidades) = 100 centavos → dividir por 10,000
const cents = parseInt(usdcSmallestUnit) / 10_000;
// Ejemplo: "5000000" (5 USDC) → 500 centavos ($5.00)
// Outbound: centavos USD → unidades mínimas USDC
const usdc = String(Math.round(cents * 10_000));
// Ejemplo: 500 centavos → "5000000" (5 USDC)Validaciones de seguridad previenen errores de precisión sub-centavo (valores deben ser divisibles por 10,000), rechazan montos negativos y aplican límites de enteros seguros IEEE-754 (~$9 mil millones máx.).
Detección de Protocolo: Cómo se Identifica x402
x402 es uno de los 8 protocolos de pago en el sistema de detección de AgenticMCPStores. El detector multi-protocolo asigna scores de confianza para determinar qué adaptador maneja cada solicitud:
- 1Header
X-Protocol: X402→ confianza 1.0 (declaración explícita) - 2Header
PAYMENT-SIGNATURE(V2) → confianza 0.95 - 3Header
X-PAYMENT(V1 legacy) → confianza 0.90 - 4Coincidencia de estructura del body (
paymentPayload,x402, o campospaymentRequired) → confianza 0.85 - 5Sin coincidencia → fallback a ACP con confianza 0.5
Esto significa que x402 coexiste con ACP, UCP, PayPal, Visa VIC, Mastercard Agent Pay y otros protocolos. El adaptador con mayor confianza gana, y el bridge de protocolo enruta el pago a la ruta de liquidación correcta.
Configuración del Merchant
// Almacenado en MerchantProtocol.config (base de datos)
{
"protocol": "X402",
"enabled": true,
"priority": 100,
"config": {
"walletAddress": "0xAbCd...wallet_merchant",
"network": "base",
"facilitatorUrl": "https://x402.org/facilitator",
"supportedTokens": ["USDC"],
"maxTransactionAmount": 100000000 // 100 USDC límite de seguridad
}
}facilitatorUrl. Las direcciones de wallet se validan tanto para formatos EVM (0x + 40 caracteres hex) como Solana.Modelo de Seguridad
- 1Sin datos sensibles en logs de auditoría — direcciones de wallet, firmas y nonces nunca se almacenan en registros OrderEvent. Solo se registra nombre de protocolo, red y referencias de hash de transacción.
- 2Verificación delegada al facilitador — el bridge nunca valida firmas EIP-712 localmente (sin material de claves en el servidor). La verificación se delega al endpoint
/verifydel facilitador. - 3Transiciones de estado atómicas — las actualizaciones de estado de orden usan atomicidad a nivel de base de datos. El job de expiración verifica el estado antes de actualizar para prevenir condiciones de carrera.
- 4Protección SSRF — las URLs de facilitador proporcionadas por merchants se validan contra rangos IP privados y hostnames internos.
- 5Timeout de fetch de 15 segundos — todas las solicitudes al facilitador tienen un timeout duro para prevenir conexiones colgadas.
Máquina de Estados de la Orden
┌──────────┐ verify ┌──────────────────────┐
│ PENDING │ ──────────────→ │ x402_pending_payment │
└──────────┘ └──────────┬───────────┘
│
┌─────────────┼─────────────┐
↓ ↓ ↓
┌───────────┐ ┌───────────┐ ┌─────────┐
│ completed │ │ x402_failed│ │ expired │
└───────────┘ └───────────┘ └─────────┘
Estados terminales no pueden sobreescribirse.
Expiración: job cada 30 minutos captura pagos atascados.Formato de Headers V1 vs V2
nonce, validez temporal (validAfter/validBefore), y datos tipados EIP-712 estructurados. V1 (X-PAYMENT) se mantiene por compatibilidad pero carece de nonce y límites temporales, haciéndolo menos seguro. Nuevas integraciones siempre deben usar V2.Tips de Producción
- 1Elige Base para fees más bajos — los costos de transacción L2 son una fracción de Ethereum mainnet. La mayoría de pagos agente-a-merchant son pequeños (<$100), haciendo Base el default óptimo.
- 2Configura maxTransactionAmount — un límite de seguridad por merchant previene liquidaciones accidentales grandes. Empieza conservador (ej: 100 USDC) y aumenta según se construye confianza.
- 3Monitorea el job de expiración — órdenes atascadas en
x402_pending_paymentpor >30 minutos indican problemas del facilitador o congestión de red. Configura alertas en el OrderEventx402_payment_expired. - 4Usa headers V2 exclusivamente — V1 carece de protección contra replay. Deshabilita soporte V1 en producción si tu ecosistema de agentes soporta V2.
- 5Maneja respuestas 402 gracefully — al construir clientes agente, parsea el header
PAYMENT-REQUIRED, extrae las URLs del facilitador, e implementa el flujo de firma-y-liquidación. El facilitador maneja toda la complejidad on-chain.
Cobertura de Tests
La implementación x402 está respaldada por 197 casos de test en 6 archivos de test (~2,554 líneas de código de test). La cobertura incluye: detección (8 tests), normalización (12 tests), liquidación con backoff (45+ tests), validación de configuración con SSRF (18 tests), integración end-to-end (22 tests), y 92+ casos edge cubriendo errores de precisión, timeouts, fallas de red y actualizaciones de estado concurrentes.
Qué Viene
Preguntas frecuentes
¿Qué es x402 y cómo se relaciona con HTTP 402?
x402 es un protocolo de pago que implementa el largamente reservado código de estado HTTP 402 (Payment Required). Cuando un servidor devuelve 402, incluye un objeto PaymentRequired legible por máquinas que los agentes IA pueden cumplir autónomamente usando pagos stablecoin USDC on-chain.
¿Qué blockchains soporta x402?
AgenticMCPStores soporta x402 en 5 redes: Base (recomendada por fees más bajos), Ethereum, Polygon, Arbitrum y Solana. Todas usan USDC como token de liquidación con direcciones de contrato conocidas por cadena.
¿Cómo maneja x402 las liquidaciones fallidas?
El servicio de liquidación usa backoff exponencial con hasta 5 reintentos (delays de 5s, 10s, 20s, 40s). Cada solicitud al facilitador tiene timeout de 15 segundos. Si todos los reintentos fallan, la orden se marca como x402_failed. Un job en background expira órdenes atascadas después de 30 minutos.
¿Es seguro x402? ¿Cómo se verifican las firmas?
Sí. x402 V2 usa firmas EIP-712 de datos tipados con protección contra replay (nonce) y límites temporales. La verificación de firmas se delega al facilitador — no existe material de claves privadas en el servidor. Las direcciones de wallet y firmas nunca se almacenan en logs de auditoría.
¿Puede x402 funcionar junto con otros protocolos de pago?
Absolutamente. x402 es uno de los 8 protocolos de pago en el sistema de detección de AgenticMCPStores. El detector multi-protocolo asigna scores de confianza, y el adaptador con mayor confianza gana. Si un merchant no tiene x402 habilitado, el bridge recurre a su protocolo preferido (ACP, PayPal, etc.).
Fuentes y referencias
- Especificación del Protocolo x402
x402 Project (Coinbase CDP)
- EIP-712: Hashing y firma de datos estructurados tipados
Ethereum Foundation
- Documentación USDC — Circle
Circle
- HTTP 402 Payment Required — MDN Web Docs
Mozilla
Artículos relacionados
developer-guide
Building Agentic Commerce #1: Checkout Multi-Protocolo — MCP + x402 + ACP en un solo flujo
Un agente, tres protocolos, un checkout. Asi es como MCP, pagos stablecoin x402 y ACP trabajan juntos para que los agentes de IA compren productos, con ejemplos de codigo que puedes ejecutar hoy.
developer-guide
Building Agentic Commerce #3: Trust Scores — Cómo los Agentes Deciden a Quién Comprarle
Cuando un agente IA evalúa merchants, no lee reseñas ni reconoce logos. Lee trust scores — 12 señales verificables por máquina que determinan ranking de búsqueda, elegibilidad de checkout y fricción de pago. Así funciona el sistema.
developer-guide
Building Agentic Commerce #2: Como los agentes de IA descubren tu tienda sin API Key
Antes de que un agente pueda comprar algo, necesita encontrar tu tienda. Asi funciona la cadena de descubrimiento de 6 fases que lleva a un agente de IA de cero conocimiento a listo para checkout en menos de 2 segundos, sin configuracion previa.