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: 8 de septiembre 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=49d15885fa73443e9f5e58da08810748701fd196fb83a855daf54313b18ef431 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 está desplegado y ningún comercio tiene hoy una configuración liquidable: el constructor del 402 y el settle devuelven `x402_not_configured`. NO se puede afirmar que aceptemos pagos x402, ni volumen, liquidaciones ni comerciantes usándolo.
Agentic Commerce Protocol
Puente ACP desplegado y configurable por comercio. No hay ninguno configurado en producción: `/api/v1/health` responde demo.protocolBridges.acp = unconfigured. No se puede afirmar liquidación por este rail.
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, corriendo hoy en modo permisivo (OBSERVE): el gate fail-closed que exigiría una liquidación real antes de completar el pedido no está activo en el proceso que sirve producción. 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 sin desplegar en el proceso que sirve producción: `MCAP_ENABLED` no está puesta en el VPS (que es quien responde en `trusteed.xyz`/`api.trusteed.xyz`), así que el adaptador de pago entrante NO se registra y `/health` no publica el bloque `protocols.mcap`. El código soporta encenderlo, pero hoy no está encendido donde importa. No se puede afirmar ninguna liquidación por este rail.
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
Todos los sistemas operativos
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 no liquida ningún rail: ningún comercio tiene procesador de pagos configurado y x402 responde x402_not_configured, así que lo desplegado es el camino de inicio y evidencia, no pagos completados.
GET /api/v1/healthHealth endpoint
- MCP Gateway
- Operacional
- API v1
- Operacional
- Dashboard
- Operacional
- Integración Shopify
- Operacional
- Integración WooCommerce
- Operacional
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. 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.
Dependencias upstream
Objetivos de nivel de servicio
La disponibilidad de Trusteed depende de un pequeño conjunto de proveedores upstream. Ante dudas, consulta sus status pages.
Auth0 (auth.trusteed.xyz)
https://status.auth0.com/Stripe
https://status.stripe.com/Railway (compute & Postgres)
https://railway.com/statusx402 facilitator
https://x402.org/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
- Ninguna comprobación de readiness está fallando ahora mismo.
- 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