Building Agentic Commerce #1: checkout multiprotocolo con 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 y el Comerciante B pueden enrutarse a rails distintos en el mismo checkout —uno a Stripe, otro al adaptador x402— porque la división es por comerciante. Cuál de esos rails puede liquidar de verdad es otra pregunta, y hoy la respuesta son sólo aquellos para los que el comerciante tenga un procesador de pagos configurado: el rail x402 devuelve `x402_not_configured` para todos los comercios, así que esto es la forma que el bridge soporta, no algo corriendo en producción. 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 de checkout MCP ahora mismo contra nuestra demo store. La demo store en trusteed.xyz/demo-store tiene 18 productos en múltiples categorías. Las herramientas de descubrimiento (search_products, get_product_details, browse_categories, get_merchant_profile) funcionan sin autenticación. Todas las herramientas de checkout (create_cart, get_shipping_rates, select_shipping_option, apply_discount, preview_checkout, complete_checkout) necesitan una clave sandbox, create_cart incluida, y todas las tools de checkout que gastan o liquidan piden además la cabecera X-Payment-Mandate; el resto de herramientas de checkout (create_cart y attach_agent_identity y verify_age_over_n y verify_residence_country y verify_legal_person_authorization y apply_discount y get_shipping_rates y select_shipping_option y create_payment_mandate y update_payment_mandate y cancel_payment_mandate y ucp_create_checkout y ucp_update_checkout y ucp_add_items_to_checkout y ucp_get_checkout y ucp_cancel_checkout y get_checkout_state y quote_checkout y get_trust_receipt y verify_trust_receipt) no la necesitan. El Playground en trusteed.xyz/demo-store/playground proporciona un cliente MCP integrado con todo eso preconfigurado.

Trust Score v4.1 combina tres dimensiones ponderadas, un bonus opcional de aseguramiento externo y topes según confianza. Cada respuesta identifica el motor utilizado; algunas recurren a v2. El desglose legacy por componentes no explica una puntuación global producida por v4.1.