Saltar al contenido
Volver al blog
developer-guide14 min

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

x402stablecoinUSDCpagos criptoEIP-712Basecomercio agénticoMCPliquidaciónmulti-cadena

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

El flujo de pago x402 involucra tres partes: el agente (comprador con wallet cripto), el merchant (vendedor con wallet receptora), y el facilitador (verificador de firmas y liquidador on-chain). Este es el flujo paso a paso:

Paso 1: El Agente Solicita un Recurso

El agente envía una solicitud HTTP al endpoint de checkout del merchant. El detector de protocolos identifica x402 vía headers — 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

Si el merchant tiene x402 habilitado, el adaptador outbound construye un objeto 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.

Idea clave

Paso 3: El Agente Firma y Liquida

El agente lee el 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

El servicio de liquidación orquesta un proceso multi-fase: (1) marcar la orden como 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:

  • 1
    Base — USDC en 0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913 (recomendada: fees más bajos)
  • 2
    Ethereum — USDC en 0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48
  • 3
    Polygon — USDC en 0x3c499c542cEF5E3811e1192ce70d8cC03d5c3359
  • 4
    Arbitrum — USDC en 0xaf88d065e77c8cC2239327C5EDb3A432268e5831
  • 5
    Solana — 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.

Idea clave

Conversión de Montos: USDC ↔ Centavos USD

El bridge convierte entre centavos USD (usados internamente para compatibilidad multi-protocolo) y unidades mínimas USDC (representación on-chain). La matemática es directa:
// 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:

  • 1
    Header X-Protocol: X402 → confianza 1.0 (declaración explícita)
  • 2
    Header PAYMENT-SIGNATURE (V2) → confianza 0.95
  • 3
    Header X-PAYMENT (V1 legacy) → confianza 0.90
  • 4
    Coincidencia de estructura del body (paymentPayload, x402, o campos paymentRequired) → confianza 0.85
  • 5
    Sin 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

Los merchants habilitan x402 agregando una configuración de protocolo con su dirección de wallet y red preferida:
// 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
  }
}
El validador de configuración aplica protección SSRF — URLs privadas/internas (127.0.0.1, 10.x.x.x, localhost) son rechazadas para el facilitatorUrl. Las direcciones de wallet se validan tanto para formatos EVM (0x + 40 caracteres hex) como Solana.

Modelo de Seguridad

  • 1
    Sin 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.
  • 2
    Verificació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 /verify del facilitador.
  • 3
    Transiciones 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.
  • 4
    Protección SSRF — las URLs de facilitador proporcionadas por merchants se validan contra rangos IP privados y hostnames internos.
  • 5
    Timeout 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

Las órdenes x402 siguen una máquina de estados estricta:
┌──────────┐     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

La implementación x402 soporta dos formatos de headers. V2 (PAYMENT-SIGNATURE) es el estándar actual con seguridad completa: protección contra replay vía 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

  • 1
    Elige 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.
  • 2
    Configura maxTransactionAmount — un límite de seguridad por merchant previene liquidaciones accidentales grandes. Empieza conservador (ej: 100 USDC) y aumenta según se construye confianza.
  • 3
    Monitorea el job de expiración — órdenes atascadas en x402_pending_payment por >30 minutos indican problemas del facilitador o congestión de red. Configura alertas en el OrderEvent x402_payment_expired.
  • 4
    Usa headers V2 exclusivamente — V1 carece de protección contra replay. Deshabilita soporte V1 en producción si tu ecosistema de agentes soporta V2.
  • 5
    Maneja 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

En la Parte 5, exploraremos UCP — el Protocolo de Comercio Universal de Shopify y cómo habilita comercio impulsado por agentes en el ecosistema Shopify. Mantente atento.

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

Artículos relacionados

Pagos Stablecoin x402 para Agentes IA | Construyendo Comercio Agéntico #4 | AgenticMCPStores