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, verificacion de firmas y liquidacion deberia ser invisible. Este es el problema que resolvimos con el checkout multi-protocolo, y en este post te mostraremos exactamente como funciona, con codigo que puedes ejecutar contra nuestra demo store hoy.

El ecosistema actual de comercio agentico tiene multiples protocolos de pago, cada uno optimizado para escenarios diferentes. MCP (Model Context Protocol) proporciona la interfaz de herramientas: busqueda, 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 metodos de pago. Un agente comprando en varios comerciantes encontrara los tres. Si cada uno requiere una integracion diferente, los desarrolladores de agentes enfrentan una pesadilla de fragmentacion.

AgenticMCPStores 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 especifica del protocolo. Los comerciantes configuran que protocolos soportan: el agente nunca necesita conocer los detalles.

El middleware de deteccion 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 deteccion 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 estandar. 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 credito, el agente paga on-chain en USDC y envia prueba de pago. El flujo comienza igual que MCP (busqueda, 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 codigo de estado HTTP estandar que fue literalmente disenado para este caso de uso hace decadas y que finalmente se usa como estaba previsto.

La liquidacion es asincrona: el servidor devuelve 202 inmediatamente y procesa la liquidacion en segundo plano. Las ordenes que no se verifican en 30 minutos expiran automaticamente. Toda la verificacion de pago tiene proteccion 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 negociacion. Un agente consulta GET /.well-known/acp.json (publico, 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, negociacion de contexto de display).

El endpoint de descubrimiento ACP devuelve un contrato JSON especificando: 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 negociacion de capacidades incluyendo contextos de display webview y headless, persistencia de carrito y reanudacion de sesion de agente. La autenticacion sigue OAuth 2.1 con metadata de recurso protegido RFC 9728.

Con esta informacion, 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 logica 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 decision de politica.

Puedes probar el flujo completo de checkout MCP ahora mismo contra nuestra demo store. La demo store en agenticmcpstores.com/demo-store tiene 18 productos en multiples categorias. Las herramientas de descubrimiento (search_products, get_product_details, browse_categories) funcionan sin autenticacion. Para herramientas de checkout (create_cart, complete_checkout), usa el Playground en agenticmcpstores.com/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 busqueda semantica 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.