UCP para ecommerce: cómo auditar tu preparación antes del checkout con IA

Un checkout iniciado por un agente de IA no es una nueva página de producto. Es un contrato distribuido entre el catálogo, Merchant Center, el agente, tu API de checkout, el proveedor de pagos y la operación postcompra. Si uno de esos sistemas devuelve una capacidad inexistente, un precio antiguo o un estado ambiguo, el agente no puede improvisar una solución segura.

Universal Commerce Protocol (UCP) propone un lenguaje común para que agentes y comercios descubran capacidades y coordinen una compra. Google lo documenta para experiencias de checkout nativo en AI Mode y Gemini, pero el estándar y la implementación de Google no son equivalentes. UCP puede definir más capacidades de las que una superficie admite hoy, y publicar un perfil no activa automáticamente ninguna integración.

Esta auditoría responde una pregunta más concreta: ¿puede tu ecommerce aceptar, validar, cobrar, crear y mantener un pedido iniciado fuera de su interfaz sin perder control comercial ni evidencia? La guía de GEO para ecommerce cubre descubrimiento y contenido; el feed de productos para ChatGPT cubre un contrato de catálogo con OpenAI; y Shopify Agentic Storefronts cubre la gestión por canales dentro de Shopify. Aquí el objeto de control es una integración UCP propia y su decisión go/no-go.

No atribuimos demanda a una consulta exacta de Search Console. La prioridad procede de la documentación oficial de Google y UCP actualizada en agosto de 2026 y de señales adyacentes sobre productos y comercio asistido por IA.

Separa el estándar de la implementación de Google

Empieza con dos columnas. En la primera, registra lo que permite la especificación UCP. En la segunda, lo que la superficie objetivo soporta y acepta hoy. Una función no pasa a producción porque aparezca en el estándar.

Añade una fecha de revisión a cada afirmación. UCP evoluciona y Google advierte que no todas las funciones de la especificación están disponibles en sus superficies. Una matriz sin versión ni fecha se convierte rápidamente en documentación falsa.

Consulta la visión general de UCP de Google y la especificación del protocolo como fuentes distintas.

Gate 0: confirma acceso, país y propietario

No inicies desarrollo hasta resolver la elegibilidad administrativa. La integración de checkout nativo de Google requiere aprobación y está destinada actualmente a merchants y partners participantes. La documentación de Merchant Center también delimita países y productos elegibles; a fecha de revisión menciona Estados Unidos, Canadá y Australia para la experiencia descrita.

El gate debe dejar evidencia de:

• cuenta de Merchant Center y merchant ID correctos;
• estado de la cuenta y aprobación para free listings;
• país legal, mercados de venta y productos dentro del alcance vigente;
• invitación, aprobación o contacto de integración documentado;
• propietario ejecutivo y responsables de catálogo, API, pagos, seguridad y soporte;
• políticas de devoluciones, reembolsos, soporte y restricciones publicadas;
• entorno de prueba, credenciales y contactos de incidente;
• criterio explícito para detener el proyecto si cambia la elegibilidad.

Resultado válido: PASS, CONDITIONAL con dependencias y fecha, o FAIL. “Estamos preparando UCP” no es un estado auditable. Revisa la preparación de Merchant Center y la ayuda oficial de checkout de Google antes de aprobar inversión.

Gate 1: limpia Merchant Center antes de tocar la API

El agente no corrige un catálogo incoherente. Merchant Center debe ser capaz de identificar el producto, verificar su elegibilidad y representar las condiciones comerciales que luego aplicará el checkout.

Audita al menos:

• identidad estable entre id, variante, landing page y merchant_item_id;
• título, descripción, imagen, marca, GTIN o MPN cuando corresponda;
• precio, sale price, moneda y fechas de promoción;
• disponibilidad, cantidad y latencia de actualización;
• país de destino, idioma, shipping y tiempos de entrega;
• política de devoluciones y enlaces de soporte;
• restricciones por categoría, edad, región o regulación;
• diagnósticos, disapprovals y avisos activos;
• coincidencia entre feed, página, API y backend de pedidos.

Google recomienda un feed suplementario para atributos UCP cuando no conviene alterar el feed principal. Si una categoría exige un consumer_notice, define el texto, el momento en que se presenta y la evidencia de aceptación. No uses campos suplementarios para ocultar una inconsistencia estructural del catálogo.

Crea una cohorte inicial pequeña: productos simples, con stock estable, una sola unidad comercial y reglas de envío conocidas. Excluye temporalmente suscripciones, personalizaciones, bundles complejos, productos regulados o cualquier artículo cuyo precio final dependa de una conversación manual.

Gate 2: publica un perfil que describa la realidad

El agente descubre el contrato del comercio en /.well-known/ucp. Ese recurso debe ser público, estable y accesible sin autenticación. Su función es declarar lo que el comercio sabe hacer, no lo que espera construir.

El inventario de auditoría debe recoger:

Declara explícitamente native_commerce(checkout_eligibility) cuando el comercio esté aprobado y preparado. Si falta o vale false, la integración no debe asumir elegibilidad para checkout nativo.

Prueba el perfil desde una red externa, sin cookies y con caché vacía. Verifica código 200, tipo de contenido, JSON válido, certificado, DNS, latencia, ausencia de redirecciones inesperadas y coincidencia con el entorno productivo. Un WAF que devuelve un challenge HTML con 200 sigue siendo un fallo.

Gate 3: negocia versión y capacidades

En la arquitectura server-selects, el agente comunica su perfil y el comercio selecciona la intersección compatible. No basta con aceptar cualquier cliente que diga UCP.

La función de negociación debe:

1. validar la estructura y versión del perfil recibido;
2. comparar servicios y capacidades por identificador y versión;
3. rechazar extensiones obligatorias desconocidas;
4. seleccionar solo handlers de pago compatibles;
5. devolver la configuración elegida de forma determinista;
6. registrar la decisión sin almacenar secretos ni datos personales;
7. mantener compatibilidad durante una ventana de migración;
8. fallar de forma explícita cuando no exista intersección segura.

Prepara una tabla de compatibilidad con versiones soportadas, fecha de alta, fecha de retirada, superficie probada y owner. Añade pruebas de contrato para perfiles antiguos, futuros, incompletos, duplicados y malformados. El peor resultado es aceptar una combinación y fallar después de que el usuario haya confirmado la compra.

Gate 4: modela el checkout como una máquina de estados

Google documenta tres operaciones REST principales: crear una sesión, actualizarla y completarla. La implementación debe tratar cada respuesta como un estado de negocio, no como un formulario remoto.

Create

POST recibe la cesta y el contexto inicial. El comercio debe resolver productos y variantes, comprobar cantidades, aplicar restricciones, crear una sesión con identificador estable y devolver los datos que necesita el siguiente paso.

No bloquees inventario indefinidamente al crear. Documenta si existe reserva, cuánto dura y qué ocurre cuando caduca.

Update

PUT incorpora dirección, opción de envío, promociones u otros cambios. Cada actualización debe recalcular disponibilidad, impuestos, shipping, descuentos y total. La respuesta sustituye al cálculo anterior; no obligues al agente a sumar parches ambiguos.

Complete

POST completa el checkout con el instrumento autorizado. Debe verificar el estado más reciente, impedir dobles cargos, procesar el pago, crear el pedido una sola vez y devolver una referencia inequívoca.

Usa idempotency keys y una política de reintentos conocida. Prueba timeouts en el punto exacto donde el pago puede haberse autorizado pero la respuesta no llega al agente. La reconciliación debe distinguir “no procesado”, “procesado sin respuesta” y “estado desconocido”.

Define estados permitidos y transiciones. La interfaz del agente necesita saber si debe pedir una dirección, seleccionar shipping, corregir una línea, volver a autorizar o mostrar confirmación. No devuelvas un mensaje genérico cuando existe una acción concreta.

Gate 5: valida reglas comerciales en tiempo real

Merchant Center ayuda a descubrir y elegir, pero el checkout es la autoridad final. En cada transición, el comercio valida:

• producto y variante aún vendibles;
• cantidad disponible y límites por pedido;
• dirección completa y entregable;
• opciones, precio y plazo de envío;
• impuestos y tasas aplicables;
• promociones, cupones y exclusiones;
• edad, región y restricciones de producto;
• moneda y redondeo;
• total final antes del pago.

Devuelve errores estructurados y accionables. out_of_stock debe identificar la línea afectada y, si existe, la cantidad disponible. address_undeliverable debe permitir corregir la dirección o elegir otra. No sustituyas el producto, el shipping o el total sin consentimiento.

Construye casos de prueba alrededor de cambios reales: última unidad vendida en otro canal, promoción expirada, código inválido, dirección no servida, impuesto recalculado, producto retirado y shipping que cambia al modificar la cesta.

Gate 6: separa token, cobro y merchant of record

El comercio sigue siendo merchant of record. UCP coordina la transacción; no traslada automáticamente responsabilidad sobre cobro, fraude, impuestos, cumplimiento o soporte.

Si usas Google Pay, confirma que el payment handler anunciado produce un token que tu PSP o infraestructura puede procesar. El flujo debe cubrir:

• configuración y merchant identifiers correctos;
• dominios y entornos autorizados;
• tokenización y descifrado según el PSP;
• autorización, captura y posibles capturas diferidas;
• rechazo, autenticación adicional y fraude;
• idempotencia entre pago y creación del pedido;
• cancelación, devolución y reembolso;
• conciliación entre PSP, pedidos y eventos UCP;
• minimización de datos PCI y secretos en logs.

Prueba con instrumentos aprobados para sandbox y con escenarios de éxito, rechazo, timeout y reintento. Nunca pongas datos reales de tarjeta en fixtures, prompts o trazas.

El checkout como invitado debe funcionar como base. Identity linking es opcional: úsalo solo si aporta una función concreta y existe un fallback. Una sesión de cuenta caducada no debe convertir una compra válida en un callejón sin salida.

Gate 7: autentica y protege cada operación

El perfil es público; los endpoints transaccionales no. Google admite API key y recomienda OAuth 2.0. Elige el mecanismo acordado con el partner y aplica controles equivalentes a cualquier API de pago.

Incluye:

• TLS vigente y política de rotación de certificados;
• secretos fuera del código y rotación probada;
• scopes y audiencias mínimos;
• validación de issuer, audience, expiración y firma en OAuth;
• rate limiting que distinga tráfico válido de abuso;
• protección contra replay e idempotencia;
• allowlists solo cuando estén documentadas y mantenibles;
• registros con IDs de correlación, sin tokens ni datos personales;
• alertas de autenticación fallida y anomalías;
• runbook de revocación y respuesta a incidentes.

No autentiques una compra por User-Agent, Origin, Referer, nombre DNS inverso o cualquier header fácil de copiar. Esas señales pueden ayudar a observar tráfico, no a autorizar una operación comercial.

Evita geobloquear la infraestructura válida de Google. Las comprobaciones de salud pueden identificarse como Google-UCP-Prober/1.0; permite que lleguen al endpoint correspondiente sin tratarlas como órdenes ni usar el header como credencial.

Gate 8: cierra el ciclo postcompra

Una respuesta de complete no termina la experiencia. El agente necesita una referencia estable y el usuario necesita saber qué ocurrió después. El comercio debe emitir los estados postcompra obligatorios y conservar el sistema de pedidos como fuente de verdad.

El contrato operativo debe contemplar:

• pedido creado con identificador y líneas finales;
• preparación y envío con carrier y tracking cuando exista;
• entrega;
• cancelación total o parcial;
• devolución y reembolso;
• ajustes de cantidad, importe o estado;
• fallos de fulfillment;
• soporte y enlace a la política aplicable.

Define quién publica cada evento, cómo se reintenta, qué clave evita duplicados y cómo se repara un evento perdido. Compara periódicamente los pedidos del backend con los eventos enviados. Un pedido cobrado que no aparece en el canal es un incidente, aunque el ERP esté correcto.

Gate 9: mide SLO, errores y trazabilidad

Google publica como referencia mínima al menos 95 % de disponibilidad y latencias P95 de 4 segundos para create, 5 segundos para update y 10 segundos para complete. Un promedio rápido no compensa una cola de fallos en el percentil alto.

Instrumenta por operación, versión, mercado y resultado:

• volumen y tasa de éxito;
• P50, P95 y P99;
• errores de validación, autenticación, negocio y dependencia;
• timeouts y reintentos;
• idempotency conflicts;
• discrepancias de precio o inventario;
• autorizaciones de pago frente a pedidos creados;
• eventos postcompra pendientes;
• disponibilidad del perfil y endpoints;
• synthetic checks sin crear pedidos reales.

Usa un correlation ID común entre gateway, checkout, PSP, pedidos y eventos. Redacta direcciones, tokens y datos personales. Define alertas por impacto y no solo por error HTTP: una respuesta 200 con total incorrecto es un incidente más grave que un 400 bien explicado.

Ejecuta una matriz de pruebas antes del go-live

No certifiques la integración con un happy path. Prueba el contrato y la operación.

Incluye productos agotados, dirección no entregable, impuesto variable, shipping desaparecido, cambio de precio entre pasos, cupón no combinable, sesión expirada y dependencia caída. Ejecuta también una prueba de recuperación: corrige el dato y confirma que el usuario puede continuar sin reconstruir toda la compra.

Puntúa la readiness con gates, no con sensaciones

Asigna 0, 1 o 2 puntos a cada dominio: 0 sin evidencia, 1 parcial o manual, 2 probado y operable.

Un total alto no compensa un cero en acceso, pagos, seguridad o idempotencia. Define esos dominios como bloqueantes. La salida de la auditoría debe incluir score, evidencia, owner, fecha límite y decisión: NO-GO, PILOTO LIMITADO o GO.

Plan de 30 días para una cohorte controlada

Días 1-5: alcance y catálogo

Confirma acceso, país, merchant ID, equipo y fuentes de verdad. Selecciona una cohorte simple. Corrige diagnósticos y crea un snapshot de Merchant Center.

Días 6-10: contrato y perfil

Versiona servicios y capacidades. Publica /.well-known/ucp en un entorno accesible, implementa negociación y añade pruebas de contrato.

Días 11-18: checkout y pagos

Implementa create, update y complete sobre las reglas existentes. Añade estados, errores, idempotencia, Google Pay o el handler aprobado y reconciliación con pedidos.

Días 19-23: seguridad y postcompra

Configura autenticación, rotación, límites y logs seguros. Implementa eventos de pedido y ajustes. Ejecuta escenarios de cancelación y reembolso.

Días 24-27: carga y recuperación

Mide percentiles, fuerza timeouts y dependencias caídas, prueba reintentos y confirma que no aparecen cargos ni pedidos duplicados.

Días 28-30: decisión

Reúne evidencias, puntúa gates y documenta riesgos aceptados. Solicita go-live solo para la cohorte y mercados probados. Programa revisión a 7, 14 y 30 días.

Checklist de salida

• [ ] Aprobación, países y alcance vigentes están documentados.
• [ ] Merchant Center está en buen estado y aprobado para free listings.
• [ ] La cohorte tiene IDs, variantes, precio, stock, shipping y políticas coherentes.
• [ ] merchant_item_id reconcilia con el sistema de pedidos.
• [ ] consumer_notice se muestra y registra cuando corresponde.
• [ ] /.well-known/ucp es público, válido, versionado y monitorizado.
• [ ] Solo se declaran servicios y capacidades implementados.
• [ ] native_commerce(checkout_eligibility) refleja el estado real.
• [ ] La negociación acepta y rechaza perfiles de forma determinista.
• [ ] Create, update y complete tienen estados y errores accionables.
• [ ] Precio, stock, dirección, shipping, impuestos y promociones se revalidan.
• [ ] Complete es idempotente ante timeout y reintento.
• [ ] El PSP procesa el token aprobado y existe conciliación.
• [ ] Guest checkout funciona; identity linking tiene fallback.
• [ ] OAuth 2.0 o API key están protegidos, rotados y monitorizados.
• [ ] Ningún header de procedencia se usa como autenticación.
• [ ] El comercio conserva responsabilidades de merchant of record.
• [ ] Eventos postcompra y ajustes se reconcilian con pedidos.
• [ ] Disponibilidad y P95 cumplen los gates publicados.
• [ ] Logs y trazas excluyen secretos y datos personales.
• [ ] La decisión go/no-go cita evidencia, owners y riesgos abiertos.

FAQ

¿Publicar /.well-known/ucp basta para activar el checkout en Google?

No. El perfil público permite descubrir versiones, servicios, capacidades, endpoints, payment handlers y claves, pero no concede acceso ni sustituye la aprobación de Google. La cuenta de Merchant Center, los productos y la integración deben cumplir los requisitos vigentes, y Google limita el checkout nativo a merchants y partners participantes.

¿Qué debe declarar el perfil UCP de un ecommerce?

Debe declarar una versión compatible, los servicios ofrecidos, capacidades y extensiones, endpoints, mecanismos de autenticación, payment handlers y las claves públicas necesarias. Publica solo lo implementado y probado. En una arquitectura server-selects, el comercio compara ese contrato con el perfil del agente y selecciona únicamente la intersección compatible.

¿Cuáles son las operaciones mínimas del checkout nativo de Google?

Google documenta tres operaciones REST principales: crear una sesión de checkout con POST, actualizarla con PUT y completarla con POST. El comercio debe recalcular inventario, dirección, envío, impuestos, descuentos y total en cada transición, devolver estados y errores accionables, y proteger la finalización frente a duplicados.

¿Google procesa el pago y pasa a ser merchant of record?

No. El comercio continúa siendo merchant of record. Cuando se usa Google Pay, el handler entrega un token que debe procesar el proveedor de pagos o la infraestructura del comercio. El merchant conserva la responsabilidad sobre autorización, captura, fraude, impuestos, cumplimiento, soporte, cancelaciones, devoluciones y reembolsos.

¿Qué rendimiento debe demostrar una integración UCP antes de lanzar?

Como gate mínimo, Google publica al menos 95 % de disponibilidad y latencias P95 de 4 segundos para create, 5 segundos para update y 10 segundos para complete. Mide por endpoint, mercado y tipo de error, prueba cargas realistas y conserva trazas sin datos sensibles para explicar cualquier fallo.

¿Implementar UCP mejora el ranking de productos?

No hay una garantía de ranking. UCP habilita un contrato transaccional para experiencias compatibles, mientras que la elegibilidad y la visibilidad dependen de Merchant Center, políticas, datos de producto y los sistemas de cada superficie. Evalúa por separado descubrimiento, elegibilidad para checkout, inicio de sesión, finalización y resultado del pedido.

Si el recorrido continúa en la interfaz de tu tienda, prueba también la preparación de la web para agentes de IA. Esa auditoría evalúa navegación, formularios y recuperación, no sustituye el contrato transaccional UCP.

Decide con evidencia antes de exponer el checkout

UCP reduce la necesidad de construir contratos diferentes para cada agente, pero no reduce la responsabilidad del comercio. El perfil, la negociación y la API deben describir exactamente lo que el catálogo, el PSP y la operación pueden cumplir en ese momento.

Empieza con una cohorte pequeña, convierte acceso, catálogo, seguridad, pagos e idempotencia en gates bloqueantes y conserva evidencia por transición. Un piloto está preparado cuando el equipo puede explicar y reparar un fallo, no solo cuando completa una compra de prueba.

Mentio ayuda a observar qué marcas y productos aparecen en respuestas de IA antes y después de los cambios de distribución. Empieza a medir tu visibilidad en IA y separa esa señal de la elegibilidad y la ejecución transaccional de UCP.

Fuentes oficiales revisadas el 3 de septiembre de 2026: visión general de UCP de Google, preparación de Merchant Center, perfil UCP, checkout nativo, ciclo de vida del pedido, FAQ de UCP de Google, ayuda de Merchant Center y especificación UCP.

¿Quieres saber si la IA menciona tu marca?

Descubre tu visibilidad en ChatGPT, Claude y Gemini en minutos.

Analiza tu marca gratis

Artículos relacionados