Extension API (developer platform)
Extension API desplegada y disponible. NO se puede afirmar que haya desarrolladores o integraciones de terceros usándola.
Estado del Sistema
Estado del Sistema
Estado operativo en tiempo real de los servicios de Trusteed. Esta página refleja el estado actual de nuestra infraestructura.
Última actualización: 7 de octubre de 2026
Estado por capacidad · leído del registro
Capacidades concretas, con su límite público.
Live confirma que una superficie responde en producción. No significa cobertura completa, disponibilidad comercial universal ni validación de todos sus flujos.
Firmado y verificado en esta carga · JWS EdDSA
Comprueba el mismo hash y la misma clave: registry_hash=9784809ed88d75f6513da7a1676ac63217583559d76a159fe02f78c047f7beec kid=4ed57a24-a48c-4df6-9c8c-f101f1d4bf8d /.well-known/trusteed-capabilities.json · /.well-known/jwks.json
MCP three-bucket tool registry
MCP disponible en producción para todas las tiendas. El split en tres buckets está en canary: NO se puede afirmar que esté activo para todos los comerciantes.
gobernada por bandera: MCP_THREE_BUCKET_ENABLEDUCP — Universal Commerce Protocol
Publicamos capacidades UCP por tienda, con contenido derivado de la configuración real de cada una. NO se puede afirmar transacciones UCP.
llms.txt — descubrimiento para agentes
Publicamos llms.txt para descubrimiento por agentes. NO se puede afirmar tráfico de agentes sobre él.
A2A — agent-to-agent (agent card)
Publicamos agent card A2A. NO se puede afirmar que ningún agente la haya consumido.
FIDO2 / WebAuthn
Soportamos FIDO2/WebAuthn — endpoint desplegado. NO se puede afirmar adopción ni usuarios con passkey.
AG-UI — checkout en tiempo real (SSE)
AG-UI desplegado para checkout en tiempo real. NO se puede afirmar que haya sesiones de agentes reales.
SCP — Shopper Context Protocol
SCP desplegado y habilitado por defecto. NO se puede afirmar que ningún comerciante lo esté usando.
gobernada por bandera: SCP_ENABLEDCapa 1 — firma JWS EdDSA (Ed25519) del receipt
Emitimos Trust Receipts firmados (JWS EdDSA) en producción. NO se puede afirmar que todo checkout genere uno, ni volumen de recibos emitidos.
x402 HTTP-native payments
El rail x402 liquida en pruebas: hay liquidaciones reales verificadas en Base Sepolia (testnet, sin valor real) en la tienda de demostración. NO se puede afirmar que aceptemos pagos x402 con valor real, ni mainnet, ni volumen, ni comerciantes reales usándolo.
Agentic Commerce Protocol
Puente ACP desplegado y configurado para la tienda de demostración (Stripe en modo prueba, sin dinero real). No se puede afirmar liquidación con valor real por este rail, ni comerciantes que liquiden por él, ni volumen.
Agent Payments Protocol (AP2)
el puente corre contra el entorno de demo de AP2 de la propia Google; `GET /api/v1/health` responde demo.protocolBridges.ap2 = sandbox (derivado del registro firmado desde el 2026-08-31), que no es un flujo de mandato de carrito de producción, publicamos por debajo del techo del registro (sandbox)
KYApay
Encendido como verificación de IDENTIDAD, no como rail de pago: es el alcance decidido para esta fase, y el código lo respalda — las claves que el camino KYA auto-provisiona nacen con los ámbitos `search`/`compare`/`cart`/`merchants:read`, sin `checkout`, así que `/api/v1/agent/checkout` responde 403 `MISSING_SCOPE` a un agente autenticado sólo con JWT de Skyfire. `/api/v1/health` responde protocols.kyapay.enabled = true, con chargeCount24h = 0 y lastChargeSuccess = null. El pago por este rail queda para una segunda fase; hoy no se puede afirmar ninguna liquidación.
gobernada por bandera: KYAPAY_ENABLEDTrustReceipt ↔ MPP binding
Vinculación implementada y dormida tras `SPEC056_MPP_BINDING_PROD_READY`: sin la bandera, las cinco rutas responden 503. No se ha emitido ningún recibo vinculado a MPP en producción.
gobernada por bandera: SPEC056_MPP_BINDING_PROD_READYTrustReceipt v1.1 (eIDAS-hardened receipts)
Las transacciones agénticas pueden generar un recibo firmado … diseñado para alineación eIDAS/ESIGN. La emisión v1.1 está tras `TRUST_RECEIPT_EIDAS_HARDENING_ENABLED` (off por defecto): el corpus que existe hoy es v1.0.
gobernada por bandera: TRUST_RECEIPT_EIDAS_HARDENING_ENABLEDeIDAS QTSP timestamping
Diseñado para emitir QES vía un QTSP acreditado (InfoCert) — integración code-complete, pendiente de credenciales de producción
Verificación de identidad de agente por firma HTTP
Verificador RFC 9421 implementado y desplegado en modo `block_spoofed` (el valor por defecto del código es `off`): una petición que trae una firma HTTP que no verifica se rechaza con 403 en los buckets Customer y Checkout; una sin firma pasa, y Discovery no se filtra nunca. Como no hay activo ningún modo `require_verified_checkout` ni `require_verified_authenticated`, no firmar sale gratis y la identidad del agente sigue sin ser una señal en la que se pueda confiar. NO se puede afirmar que los agentes que nos llegan estén identificados, ni cuántos rechazos ha habido: no se mide.
gobernada por bandera: AGENT_IDENTITY_VERIFICATION_MODENLWeb natural-language discovery
NLWeb está desplegado (ruta y pgvector presentes). NO se puede afirmar que indexe, que responda consultas, ni que la tool `nlweb_ask` esté disponible para agentes: medido el 2026-09-01, la ruta devuelve VECTOR_DB_UNAVAILABLE y la tool no responde en ninguna superficie MCP.
WebMCP — bridge de navegador (W3C CG)
Los cuatro bundles del puente se sirven y su sha256 cuadra con el build. El modo NATIVO no está verificado: los E2E inyectan un `navigator.modelContext` simulado y no hay ninguna ejecución contra un Chrome con soporte real. No se puede afirmar que funcione en un navegador nativo.
MCP Apps — widgets de confianza (SEP-1865)
Servimos widgets MCP Apps que llevan la evidencia de confianza del comercio. NO se puede afirmar que ningún cliente los haya renderizado.
Capa 2 — encadenado hash de receipts + checkpoints firmados
Encadenado y checkpoints implementados y ARMADOS en producción: `TRUST_RECEIPT_CHAIN_ENABLED` está puesta y hay génesis declarada (2026-08-06). Los recibos anteriores a esa génesis no están encadenados, y no se ha contado cuántos posteriores lo están: no se puede ofrecer inmutabilidad de secuencia sobre el corpus, ni afirmar una cadena continua.
gobernada por bandera: TRUST_RECEIPT_CHAIN_ENABLEDW3C Payment Request API — hoja de pago del navegador
El camino de pago confirmado por humano está implementado y su ruta desplegada. NO se puede afirmar que se cobre por él: ninguna tienda tiene procesador configurado, y ningún pago real ha pasado por esta ruta.
gobernada por bandera: BROWSER_PAYMENT_REQUIRE_SETTLEMENTVerificación de comerciante por Digital Credentials API
Aceptamos verificación de identidad de comerciante por Digital Credentials API — endpoint desplegado. NO se puede afirmar que ningún comerciante se haya verificado por esa vía ni que el bonus de confianza se haya concedido.
gobernada por bandera: EUDI_WALLET_ACCEPTANCE_ENABLEDKYA — verificación del operador del agente
La verificación de identidad del operador del agente está implementada y su ruta desplegada. NO se puede afirmar que haya operadores verificados: las únicas identidades en producción son datos de demostración sembrados.
gobernada por bandera: AGENT_IDENTITY_VERIFICATION_MODEMastercard Agent Pay
Sin liquidación, y con una advertencia de procedencia: la observación `MCAP_ENABLED="true"` de esta entrada se leyó en el panel de Railway, que es otro despliegue. Medido el 2026-09-10 en `trusteed.xyz` y en `api.trusteed.xyz` —los dos con huella `deployment: 55f23abf`, que es quien atiende—, `/api/v1/health` NO publica el bloque `protocols.mcap`, y ese bloque sólo aparece cuando la bandera vale `"true"`: en el host que sirve, por tanto, el adaptador de pago entrante no llega a registrarse. La superficie de credenciales está registrada sin bandera (`/api/v1/mcap/keys`, `/consent`, `/verifiable-intent`). No se puede afirmar ninguna liquidación por este rail, ni que el rail esté disponible en el host que atiende.
gobernada por bandera: MCAP_ENABLEDIXOPAY payment trust
Opt-in por comercio vía `MerchantPspConfig` y sin configurar en producción (`/api/v1/health` → payment_trust.ixopay = unconfigured). El enrutado y la bóveda son consultivos: por esta capa no se ejecuta ninguna liquidación real.
VIC — Visa Intelligent Commerce
Adaptador completo y sin ninguna ruta registrada: no hay superficie por la que llamarlo. Bloqueado por acceso externo al pilot de Visa, no por trabajo pendiente nuestro.
gobernada por bandera: VIC_RECONCILIATION_ENABLEDPayPal
Implementado y sin configurar: `/api/v1/health` de producción no publica el bloque `paypal`, lo que prueba que faltan las credenciales. No se puede afirmar liquidación por PayPal.
gobernada por bandera: PAYPAL_ENABLEDCapa 3 — sellado de tiempo RFC 3161 contra QTSA
Sellado RFC 3161 implementado, con validación de EU Trusted List, y sin proveedor provisionado: `/api/v1/health` responde qtsp.enabled = false. Ningún recibo lleva hoy un sello de tiempo cualificado.
Cribado de sanciones
Sin proveedor OFAC/UE/RU integrado en producción: hoy no se ejecuta ningún cribado de sanciones. Un comercio no debe contar con este control para su cumplimiento.
gobernada por bandera: SANCTIONS_SCREENING_MODEA2-UI
Sin implementación en el árbol de código. No hay nada desplegado ni tras bandera: es un plan, no una capacidad.
Capa 4 — sello cualificado (QES verificado contra cadena de confianza)
No disponible. Ninguna ruta de código produce hoy un sello VERIFIED: la firma se persiste siempre como SIGNED_UNVERIFIED, incluso con la bandera encendida. Bloqueado por credenciales de sandbox del QTSP.
gobernada por bandera: QES_CADES_VERIFY_ENABLEDEstado del Sistema
Algunos sistemas están degradados: el endpoint de health de abajo dice cuáles y por qué
Los agentes y sistemas de monitorización pueden consultar el endpoint de health para obtener un informe de estado legible por máquina.
Sobre los pagos, dos cosas que suenan contradictorias y no lo son: el papel de Trusteed es iniciar y evidenciar flujos de pago sobre varios rails, no procesarlos. No somos un procesador de pagos ni el comerciante registrado. El dinero se mueve por el procesador del propio comercio. El «no procesamos pagos» del pie y cualquier «aceptamos <rail>» de arriba describen esos dos papeles distintos. Hoy ningún rail liquida dinero real: ningún comercio tiene procesador de pagos configurado y x402 sólo liquida transferencias de prueba en Base Sepolia en la tienda de demostración, así que lo desplegado es el camino de inicio y evidencia, no pagos completados.
GET /api/v1/healthHealth endpoint
- MCP Gateway
- Degradado
- API v1
- Degradado
- Dashboard
- Operacional
- Integración Shopify
- Degradado
- Integración WooCommerce
- Degradado
Estas filas dicen si el servicio responde ahora mismo, no hasta dónde ha llegado el despliegue de la integración. Sólo la integración de Shopify tiene sonda propia (salud de sus tokens); MCP Gateway, API v1 e Integración WooCommerce comparten la salud agregada del mismo proceso, y Dashboard queda probado por el hecho de que esta página se esté pintando. Esa salud agregada sale del despliegue que sirve este dominio, que es al que llega un visitante o un agente; el despliegue residual de Railway que aparece en las dependencias es otro proceso distinto y no es lo que miden estas filas. Para saber en qué fase de despliegue está cada plataforma, mira connectedPlatforms en /.well-known/agent-commerce.json: los conectores están en beta guiada o en pruebas.
Estado del Sistema
Flujo de compra (tienda demo)
Cada 15 minutos se ejecuta una compra sintética contra la tienda demo pública. Cada fila es una etapa de esa compra, de modo que un fallo aparece en la etapa que se rompió y no queda escondido tras un proceso que sigue respondiendo.
Es la tienda de demostración con una clave sandbox. El inicio del pago se detiene en el enlace de aprobación y no cobra nada, y en este modo no se recoge el recibo, así que una ejecución en verde no demuestra que se pueda cobrar ningún pago. Una fila «Sin medir» no se llegó a ejecutar: la compra se detiene en el primer paso que falla.
Flujo de compra (tienda demo)
- Descubrimiento
- Operacional
- Carrito y envío
- Operacional
- Vista previa del pago
- Operacional
- Aprobación
- Operacional
- Inicio del pago (sin cobro)
- Operacional
- Recibo
- Sin medir
- Búsqueda NLWeb
- Degradado
Función opcional. Se informa en su propia fila y no cuenta para el flujo de compra.
Estado del Sistema
Dependencias upstream
La disponibilidad de Trusteed depende de un pequeño conjunto de proveedores. Cada uno de abajo dice qué lleva de verdad; se enlaza su página de estado cuando el proveedor publica una.
Arsys (España, UE)
Sirve trusteed.xyz y api.trusteed.xyz: el sitio público, el panel del comercio y el despliegue de la API que responde en esos dos dominios, con su propia base de datos de producción. Si esta página se ha cargado, la ha servido este proveedor.
Este proveedor no publica página de estado pública.
Railway (cómputo y Postgres)
Corre un segundo despliegue de la API, residual, con la otra base de datos de producción, accesible por su propio hostname de railway.app. No recibe el tráfico de trusteed.xyz ni de api.trusteed.xyz, así que una caída de Railway no tumba las superficies que aparecen encima.
https://railway.com/statusAuth0 (auth.trusteed.xyz)
Proveedor de identidad para la autenticación de comercios y agentes.
https://status.auth0.com/Stripe
Facturación de las suscripciones y el rail de tarjeta disponible para los comercios.
https://status.stripe.com/x402 facilitator
Rail de stablecoin. Mira la nota de pagos de arriba: hoy no liquida ningún rail.
https://x402.org/Medido el 8 de septiembre de 2026: trusteed.xyz y api.trusteed.xyz resuelven a la misma dirección y los sirve el mismo despliegue. Los dos publican la huella deployment 55f23abf en /api/v1/health, sobre nginx. El despliegue de Railway publica otra distinta (154994f4) por su propio hostname. Ésa es la comprobación que hay que repetir antes de dar por hecho que un cambio de proveedor afecta a esta página: dos hostnames que publican la misma huella son el mismo despliegue, diga lo que diga el panel del proveedor.
Objetivos de nivel de servicio
Objetivos informativos por tier. SLAs contractuales solo aplican a planes Enterprise.
Objetivos de nivel de servicio
- Uptime (STARTER): 99,5%
- Uptime (GROWTH / PRO): 99,9%
- Uptime (ENTERPRISE): 99,95%
- Latencia p95 (tools de lectura): < 500 ms
- Latencia p95 (escritura/checkout): < 2 s
- RTO / RPO: 4 h / 24 h
Degradado ahora mismo
- acp-rest-canonical-signature-enforced: ACP checkout runs in demo mode: agent request signatures are observed, not required.
- Búsqueda NLWeb: la ruta de consulta de la búsqueda no responde
- No se han reportado incidentes en los últimos 90 días.
- Una incidencia es una superficie que deja de responder. Una comprobación de readiness degradada no es una incidencia por sí sola: se publica aquí abajo, en vivo, en cuanto el endpoint de salud la reporta.
Incidencias urgentes