La escalera de la capacidad de compromiso

Actualización de evidencia · 22 de septiembre de 2026

La escalera de la capacidad de compromiso: donde la verdad del comercio se convierte en un compromiso

Los términos de depósito estructurados, las especificaciones técnicas de protocolo, la validación de endpoints y las reglas definidas por el comercio son capas de evidencia distintas. Esta actualización de agosto de 2026 muestra qué se ha vuelto legible por máquina y qué sigue sin demostrar un compromiso operativo de un servicio local.

Actualización - julio-agosto de 2026

Un protocolo puede describir un compromiso. El sistema del comercio aún tiene que hacerlo realidad.

Cuatro avances precisan la parte central de la escalera.

1. Shopify publicó un mecanismo de depósito acotado. En la versión de API 2026-07, una aplicación autorizada puede definir DraftOrderInput.deposit al crear o actualizar un pedido preliminar. Una integración de Customer Account con el alcance adecuado puede leer el depósito, amountDueNow y amountDueLater. Shopify limita esta función a los pedidos preliminares de Shopify Plus. Es una evidencia útil de que el sistema del comercio puede estructurar cuánto se debe ahora y cuánto después; no es un protocolo universal de depósito, reserva ni compromiso para servicios locales.

1. Shopify también desplazó el patrón de aplicación de reglas fuera de la interfaz del comprador. Para las reglas comerciales, Shopify dirige a los desarrolladores desde el hook obsoleto useBuyerJourneyIntercept hacia Functions de validación de carrito y checkout en el servidor, aplicables a todas las superficies de checkout, incluidas las carteras exprés y el checkout agéntico. Las extensiones existentes siguen funcionando en las versiones actuales y anteriores; su retirada será futura. La lección es arquitectónica: los términos visibles para el cliente y su aplicación en el servidor deben ir juntos. No demuestra que un comercio concreto haya implementado ese patrón.

1. UCP `v2026-08-25` amplió el vocabulario. La versión añade términos y calendarios de pago, incluidos depósitos y cuotas; instantáneas de políticas; contexto de ubicación y cumplimiento; versionado de capacidades; cambios de identidad y consentimiento; acciones y 3DS2 independiente del proveedor. También incluye cambios de esquema incompatibles. Estos campos permiten describir más partes de una transacción, pero una declaración de protocolo no verifica por sí sola la vigencia, el inventario, la disponibilidad, la exactitud de las políticas, la autoridad del comercio, el cumplimiento ni el uso en producción. Tampoco crea por sí sola una retención de reserva o una garantía de cancelación para un servicio local.

1. Google y un censo externo muestran por qué la validación debe permanecer separada de la declaración. La integración UCP de Merchant Center de Google es un piloto limitado en Estados Unidos para comercios participantes y productos vendidos en ese país. Ofrece autoconfiguración, pruebas en entornos sandbox y de producción, validación de endpoints y seguimiento de preparación; la aprobación de Google y la implementación técnica siguen siendo requisitos. Por separado, UCP Checker publicó un censo puntual de las declaraciones públicas de tiendas. Ese censo es un contador en vivo que su editor vuelve a rastrear cada 24 horas, por lo que esta página ya no repite las cifras de agosto como si estuvieran vigentes; la lectura de septiembre que figura más abajo lleva su propia marca de tiempo y las sustituye. Lo que mostró el censo de agosto, y confirma la lectura de septiembre, es la forma y no el tamaño: declaraciones del lado del catálogo que se cuentan con cinco cifras y declaraciones del lado del pago que se cuentan con una sola. Son observaciones publicadas por esa entidad sobre manifiestos públicos, no cuota de mercado auditada, adopción comercial ni prueba de transacción.

La prueba del operador: definir, exponer, aplicar, validar y conservar

Tratar la capacidad de compromiso como cinco comprobaciones conectadas:

1. Definir los términos en el sistema del comercio. Registrar el importe debido ahora, el debido después, el calendario de pago, la política aplicable, el contexto de ubicación y cumplimiento, y cualquier retención o límite de cancelación real. No deducir una retención a partir de un campo de depósito.
2. Exponer los términos exactos al cliente y a la integración autorizada. Configurar correctamente el alcance de acceso. Una declaración pública de capacidades y un registro de pedido autenticado son superficies distintas.
3. Aplicar las reglas relacionadas en el servidor. Aplicar la elegibilidad y la política de checkout más allá de una única interfaz para que las carteras, el checkout humano y el checkout agéntico no reciban reglas diferentes.
4. Validar por separado la declaración y el comportamiento. Comprobar el perfil, las versiones, los endpoints y las respuestas observadas. Un archivo /.well-known/ucp válido no es un checkout completado.
5. Conservar lo aceptado. Guardar los términos, el consentimiento o acuse, la evidencia del pedido y la política de cancelación o reembolso necesarios para resolver la transacción más adelante. Las reglas públicas de Visa son un ejemplo específico de una red para esta disciplina probatoria; no son una implementación compartida entre Shopify y UCP.

Actualización - septiembre de 2026: los dos peldaños que no se han movido

Lo que un censo de declaraciones puede y no puede decirle a un minorista

Una declaración de protocolo es un comercio que afirma en público, en un formato que una máquina puede leer, que un agente puede operar con él de una manera determinada. El manifiesto es el archivo que contiene esa afirmación: en el Universal Commerce Protocol se encuentra en /.well-known/ucp, una dirección fija en el propio dominio del comercio, igual que robots.txt siempre ha estado en una dirección fija que todo rastreador sabe consultar. Un minorista lo publica igual que publica su página de horarios: colocando un archivo donde cualquiera puede descargarlo.

UCP Checker descarga esos archivos de forma periódica y cuenta lo que dicen. Contar un archivo no es contar una venta. Su metodología publicada indica que sus sondeos funcionales opcionales, que solo se ejecutan cuando alguien lanza una comprobación manual, son «deliberadamente de solo lectura y con límite de frecuencia — no ejecutan el checkout ni escriben ningún estado», y describe la simulación completa de compras por agentes como un producto aparte. Por tanto, el censo es un inventario del lado de la oferta de lo que los comercios han declarado sobre sí mismos. No es adopción, no es cuota de mercado y no demuestra que se haya realizado un solo pedido con ninguna de esas declaraciones.

La lectura

[UCP Checker · 2026-09-22 20:58 UTC] 17.765 tiendas verificadas entre 21.900 dominios rastreados. El 99,6% de las tiendas verificadas declara checkout, el 90% declara gestión del carrito y el 60,3% declara gestión de pedidos. Dos categorías de declaración adicionales que cuenta el mismo censo quedan aparte: Payment Token Exchange, con 8, y Embedded Checkout, con 1.

Lea las dos últimas cifras frente al resto. Miles de tiendas han declarado las partes del recorrido que llevan a un agente hasta el borde de una compra. Solo un puñado ha declarado las partes que harían posible la compra misma dentro de ese recorrido. Esa brecha no es un efecto del redondeo, y no se está cerrando. Desde el censo de agosto, las declaraciones de gestión del carrito han crecido en miles, mientras que las declaraciones de token de pago siguen en una sola cifra; en las lecturas de septiembre tomadas para esta actualización, los recuentos de Payment Token Exchange y Embedded Checkout no se movieron en absoluto.

Por qué los peldaños inmóviles son los que merece la pena publicar

Cada cifra que crece en la página del editor queda desfasada a la mañana siguiente, y por eso esta sección marca el momento en que se leyó. Las dos que no se han movido son precisamente aquellas a las que apunta la escalera de la capacidad de compromiso.

Un grupo de restaurantes ya puede ser encontrado por un agente, que lee su carta y arma un carrito con ella. Las etapas uno y dos se están llenando en público, y el censo es una medida pública de ese avance. Nada de ello responde a la pregunta de la etapa tres (¿se puede cobrar este depósito, retener esta mesa, cancelar esta reserva dentro de este plazo?), y el censo muestra ahora que el peldaño de la etapa cuatro que hay debajo, donde el dinero se movería realmente dentro del recorrido del agente, casi nadie lo declara. En este marco, con capacidad de compromiso es el término para el estado en que ambas cosas son ciertas: el comercio ha definido un compromiso que puede cumplir y existe una vía por la que alguien puede pagar contra él. Con esta evidencia, la oferta declarada va muy por delante de ambas.

La lectura honesta es estrecha, y basta. Una declaración es un comercio diciendo lo que aceptará. No es un comercio que ya haya aceptado algo. La distancia entre esas dos frases es toda la etapa tres, y sigue siendo trabajo del propio comercio.

Actualizaciones concretas del texto actual de la etapa tres

Objeto de compromiso acotado

Un registro explícito y versionado de lo que se compromete: el importe debido ahora y después, cualquier retención real y su vencimiento, la ventana de cancelación, la política aplicable, el contexto de ubicación y cumplimiento, la garantía y sus límites. Un depósito o calendario de pago es un campo de ese objeto; no demuestra una retención, disponibilidad ni cumplimiento.

Términos de aceptación y políticas

Los términos deben ser visibles para el cliente, estar disponibles para la integración autorizada y aplicarse en el sistema del comercio, no solo en una interfaz del comprador. Conservar la versión exacta de la política y lo aceptado por el cliente para que los reembolsos, cancelaciones y disputas se resuelvan con evidencia definida por el comercio.

Panel actualizado para operadores

Hacer ahora

• Separar en la evidencia la capacidad declarada, el endpoint configurado, la respuesta observada y la transacción de producción completada.
• Definir depósitos, calendarios de pago, términos de cancelación, contexto de ubicación y cumplimiento, y cualquier retención de reserva real como campos distintos. Nunca usar uno como sustituto de otro.
• Aplicar la elegibilidad y las reglas de checkout en el servidor, mostrar los importes y términos exactos y conservar el acuse del cliente.

Vigilar

• Si UCP v2026-08-25 se implementa en sistemas comerciales de producción, no solo si se declara en plantillas.
• Si los depósitos y calendarios de pago se vuelven portables entre plataformas y accesibles de forma segura para agentes autorizados.
• Si los sistemas de servicios locales incorporan disponibilidad real, retención de reservas, ejecución de cancelaciones y garantías de cumplimiento con evidencia de pagos en producción.

No dar por hecho

• No dar por hecho que los depósitos de pedidos preliminares de Shopify Plus sean una capa universal de reservas o compromiso para servicios locales.
• No dar por hecho que el piloto limitado de Google en Estados Unidos esté disponible de forma general ni que validar un endpoint demuestre una transacción de producción.
• No dar por hecho que un manifiesto UCP, una puntuación de preparación, una declaración de identidad o una declaración de token de pago demuestre un checkout configurado, autorizado y completo.

Disciplina de evidencia

Observado

Las API 2026-07 de Shopify exponen un depósito escribible para pedidos preliminares de Plus e importes debidos ahora y después legibles por clientes con el alcance adecuado. Shopify dirige la aplicación de reglas de checkout hacia la validación en el servidor. UCP v2026-08-25 añade términos, políticas, ubicaciones, contexto de cumplimiento, identidad, consentimiento, acciones de autenticación adicional y versionado, con cambios incompatibles explícitos. Google documenta un piloto limitado de Merchant Center en Estados Unidos con herramientas de validación de endpoints. UCP Checker publica un censo puntual de declaraciones, rastreado de nuevo cada 24 horas, cuyos recuentos del lado del catálogo han aumentado en lecturas sucesivas mientras que sus recuentos de Payment Token Exchange y Embedded Checkout siguen en una sola cifra. Según su propia metodología publicada, sus sondeos son de solo lectura y no ejecutan el checkout.

Inferido

Nuestra lectura es que los términos legibles por máquina solo adquieren significado operativo cuando el comercio los define, el cliente puede verlos, las reglas se aplican en el servidor, los endpoints declarados se comportan como se afirma y los términos aceptados se conservan. Este patrón entre fuentes es una inferencia arquitectónica. Shopify, UCP, Google, Visa y UCP Checker no afirman compartir una única implementación.

En observación

Si los sistemas comerciales de producción implementan las especificaciones UCP de agosto; si los términos de depósito específicos de una plataforma se vuelven portables; si los agentes autorizados pueden usarlos de forma segura; y si los sistemas de servicios locales incorporan disponibilidad, retención, cancelación y garantía reales con evidencia de pago en producción verificable de manera independiente; y si los recuentos de declaraciones de Payment Token Exchange y Embedded Checkout salen alguna vez de una sola cifra.

Lo que esta actualización no afirma

1. No afirma que UCP v2026-08-25, las API de Shopify o el piloto de Google estén disponibles de forma general entre comercios, países, plataformas o categorías de servicio.
2. No afirma que un depósito cree una retención de reserva, disponibilidad del servicio, garantía de cancelación o cumplimiento.
3. No afirma que un perfil UCP público o un endpoint validado haya completado un pago en producción.
4. No afirma que los cambios incompatibles de UCP sean retrocompatibles sin migración y pruebas específicas de la implementación.
5. No afirma que la API obsoleta de interceptación del recorrido del comprador de Shopify ya haya sido retirada.
6. No afirma que el censo de UCP Checker sea cuota de mercado auditada, adopción comercial, ingresos, volumen de pedidos o evidencia de compra completa.
7. No trata los recuentos de declaraciones de Payment Token Exchange o Embedded Checkout de la lectura con marca de tiempo anterior como capacidad de pago en producción, como sistemas comerciales configurados ni como prueba de que se haya cobrado algún pago.
8. No afirma que Shopify, UCP, Google, Visa o UCP Checker compartan una arquitectura ni implementen los campos de los demás.
9. No afirma que Obenan tenga asociación, respaldo, certificación, piloto, acceso especial ni relación comercial con ninguna entidad nombrada.
10. No afirma que este trabajo sea una implementación de producto de Obenan ni una capacidad actual para clientes.
11. No afirma clasificación, recomendación, inclusión en plataformas, finalización de transacciones, ingresos ni resultados para comercios.
12. No presenta el censo de UCP Checker como cuota de mercado, adopción, penetración ni recuento de compras completadas; el censo cuenta declaraciones de manifiestos públicos, y sus sondeos son de solo lectura y no ejecutan el checkout.
13. No afirma que ninguna cifra de la lectura con marca de tiempo esté vigente en el momento en que usted lee esta página. Las cifras son lo que mostraba el censo público en el momento indicado y en ningún otro.

Fuentes de la actualización acotada

1. Versión UCP `v2026-08-25`
2. Registro de cambios de depósitos de pedidos preliminares de Shopify
3. Shopify Admin GraphQL `DraftOrderInput`
4. Shopify Customer Account `draftOrder`
5. Migración de Shopify a validación en el servidor
6. Piloto UCP de Google Merchant Center
7. Censo de agosto y metodología de UCP Checker: https://ucpchecker.com/blog/state-of-agentic-commerce-august-2026 y https://ucpchecker.com/methodology
8. Reglas públicas de Visa
9. Estadísticas de declaraciones en vivo de UCP Checker, leídas en el momento indicado arriba.