Building Agentic Commerce #1: Checkout Multi-Protocolo — MCP + x402 + ACP en un solo flujo

Cuando un agente de IA decide comprar un producto, no le importa que protocolo de pago usa el comerciante. Le importa: puedo descubrir productos, agregarlos a un carrito y pagar? La complejidad del enrutamiento de protocolos, verificación de firmas y liquidación deberia ser invisible. Este es el problema que resolvimos con el checkout multi-protocolo, y en este post te mostraremos exactamente como funciona, con código que puedes ejecutar contra nuestra demo store hoy.

El ecosistema actual de comercio agéntico tiene multiples protocolos de pago, cada uno optimizado para escenarios diferentes. MCP (Model Context Protocol) proporciona la interfaz de herramientas: búsqueda, carrito, checkout. x402 habilita pagos stablecoin on-chain (USDC en Base, Ethereum, Solana). ACP (Agentic Commerce Protocol) define como los agentes descubren capacidades de comerciantes y negocian métodos de pago. Un agente comprando en varios comerciantes encontrara los tres. Si cada uno requiere una integración diferente, los desarrolladores de agentes enfrentan una pesadilla de fragmentacion.

Trusteed usa un Protocol Bridge que normaliza cada peticion entrante a un AgentPaymentIntent unificado, independientemente del protocolo que hable el agente. El bridge detecta el protocolo desde headers HTTP (X-Protocol: X402, X-Protocol: ACP) o la forma del body, enruta al adaptador de entrada apropiado y devuelve una respuesta específica del protocolo. Los comerciantes configuran que protocolos soportan: el agente nunca necesita conocer los detalles.

El middleware de detección de protocolo se ejecuta en cada peticion de checkout y asigna una puntuacion de confianza. El header X-Protocol obtiene 1.0 de confianza. La detección por forma del body (presencia de 'cartId' para ACP, 'network' para x402) obtiene 0.9. Si no se detecta protocolo, la peticion pasa al checkout MCP estándar. Esto significa que los agentes MCP existentes funcionan sin cambios: la conciencia de protocolo es aditiva, no rompe nada.

El flujo de checkout mas simple usa herramientas MCP directamente. Un agente llama cuatro herramientas en secuencia: search_products para encontrar productos, create_cart para construir un carrito, preview_checkout para ver totales y envio, y complete_checkout para finalizar la compra. Cada herramienta es idempotente: segura de reintentar ante fallos de red.

x402 anade una capa de pago para agentes que poseen criptomoneda. En lugar de un token de tarjeta de crédito, el agente paga on-chain en USDC y envia prueba de pago. El flujo comienza igual que MCP (búsqueda, carrito, preview) pero diverge en el paso de pago. Cuando el agente envia X-Protocol: X402, el servidor responde con HTTP 402 Payment Required, un código de estado HTTP estándar que fue literalmente diseñado para este caso de uso hace decadas y que finalmente se usa como estaba previsto.

La liquidación es asincrona: el servidor devuelve 202 inmediatamente y procesa la liquidación en segundo plano. Las ordenes que no se verifican en 30 minutos expiran automaticamente. Toda la verificación de pago tiene protección BOLA: los agentes solo pueden liquidar ordenes que ellos crearon.

ACP no reemplaza a MCP ni x402: se situa por encima como capa de descubrimiento y negociación. Un agente consulta GET /.well-known/acp.json (público, sin auth, cache 1 hora) y aprende que soporta la plataforma: que handlers de pago estan disponibles (Stripe, x402, PayPal, UCP), que transportes funcionan (REST, MCP) y que capacidades ofrece (persistencia de carrito, reanudacion de sesion de agente, negociación de contexto de display).

El endpoint de descubrimiento ACP devuelve un contrato JSON específicando: spec_version '2026-01-30', transportes soportados (REST y MCP), cuatro handlers de pago (Stripe para USD/EUR, x402 para USDC, PayPal para USD/EUR, UCP para USD/EUR), y opciones de negociación de capacidades incluyendo contextos de display webview y headless, persistencia de carrito y reanudacion de sesion de agente. La autenticación sigue OAuth 2.1 con metadata de recurso protegido RFC 9728.

Con esta información, un agente inteligente puede tomar decisiones de protocolo automaticamente: usar x402 si tiene USDC, recurrir a Stripe si tiene un token de tarjeta, o usar UCP si el comerciante soporta el Universal Commerce Protocol de Shopify. El agente nunca necesita hardcodear lógica de protocolo: lee el contrato ACP y se adapta.

El verdadero poder emerge con ordenes multi-comerciante. Cuando un carrito contiene productos de diferentes comerciantes, el Protocol Bridge divide la orden en intents por comerciante y enruta cada uno independientemente via Promise.allSettled(). El Comerciante A puede liquidar via Stripe mientras el Comerciante B liquida via x402, en el mismo checkout. El fallo de un comerciante no bloquea a los otros. Cada uno recibe su propio ProcessedIntent con estado, protocolo origen/destino y decisión de política.

Puedes probar el flujo completo de checkout MCP ahora mismo contra nuestra demo store. La demo store en trusteed.xyz/demo-store tiene 18 productos en multiples categorías. Las herramientas de descubrimiento (search_products, get_product_details, browse_categories) funcionan sin autenticación. Para herramientas de checkout (create_cart, complete_checkout), usa el Playground en trusteed.xyz/demo-store/playground que proporciona un cliente MCP integrado con auth pre-configurado.

En la Parte 2, cubriremos como los agentes de IA descubren tu tienda antes de llamar a ninguna API, a traves de búsqueda semántica NLWeb, archivos llms.txt y el protocolo de descubrimiento agent-card.json. En la Parte 3, profundizaremos en trust scores: el sistema de puntuacion de 8 componentes que determina cuanta autonomia tiene un agente al comprar en tu tienda.