Un protocolo no crea un canal listo por sí solo
Universal Commerce Protocol, UCP, es un estándar abierto para que superficies de consumo, comercios y proveedores de pago compartan capacidades de descubrimiento, checkout y gestión de órdenes. Puede usar REST, MCP o A2A. El negocio conserva su lógica y permanece como merchant of record.
Eso no significa que cualquier pyme aparecerá de inmediato en todas las experiencias de IA. La implementación de Google tiene requisitos de elegibilidad e integración. UCP también evoluciona. Conviene prepararse corrigiendo fundamentos que sirven en cualquier canal, no apostando toda la operación a una promesa futura.
El primer trabajo está en catálogo, inventario, políticas, checkout, consentimiento y recibos.
El perfil declara qué puede hacer el comercio
UCP usa un perfil de descubrimiento para publicar servicios, capacidades, extensiones, endpoints y opciones de pago. Un agente puede consultar ese perfil en lugar de depender de una integración codificada para cada negocio.
Declara sólo capacidades implementadas. Si soportas consulta de productos pero no checkout, el perfil debe reflejarlo. Versiona el contrato y valida que los endpoints cumplen el esquema. Una extensión de descuentos no debe aparecer si el backend calcula promociones de otra forma.
Prueba el perfil desde fuera del servidor y monitorea disponibilidad. Un archivo correcto que apunta a un endpoint roto no permite comprar.
El perfil es una promesa técnica. Una discrepancia entre lo que declara y lo que el comercio ejecuta se convierte en carritos fallidos y confianza perdida.
Catálogo: identidad estable antes que descripción brillante
Cada producto necesita identificador estable, título claro, variante, precio, moneda, disponibilidad, imágenes autorizadas y políticas aplicables. Separa campos estructurados de texto comercial. Un agente no debería inferir talla, stock o plazo desde un párrafo.
Define actualización y fuente canónica. Si el ecommerce, ERP y planilla discrepan, UCP sólo hará visible el conflicto. Valida duplicados, variantes huérfanas, precios sin moneda e imágenes rotas.
Incluye estado y fecha de cada dato temporal. Un precio promocional necesita inicio y término; un producto descontinuado no debe reaparecer por una caché antigua. Conserva una regla clara para variantes que comparten fotos o descripción, pero difieren en disponibilidad.
Mantén el contenido útil para personas: materiales, dimensiones, compatibilidad, cuidado y restricciones. La estructura facilita intercambio; la calidad reduce preguntas y devoluciones.
Inventario, precio y políticas deben responder en tiempo real
La búsqueda puede tolerar datos con cierta demora. El checkout no. Revalida precio, disponibilidad, envío, impuestos y devolución antes de completar. Devuelve errores estructurados cuando algo cambie y permite que la persona confirme la alternativa.
Publica políticas completas y coherentes con el canal propio. Define territorios, transportistas, tiempos estimados, retiro, devoluciones y soporte. No escondas condiciones esenciales en una página que el flujo no consulta.
Separa reserva de inventario y orden confirmada. Una sesión abandonada debe liberar la reserva según una política visible. Una orden pagada necesita transición atómica o reconciliación con el proveedor, no dos fuentes que puedan afirmar estados distintos.
Prueba carreras: dos agentes intentan comprar la última unidad, un precio cambia entre carrito y pago, o una dirección queda fuera de cobertura. La respuesta correcta preserva stock y explica el siguiente paso.
El consentimiento debe ser explícito y verificable
El agente puede preparar carrito, aplicar capacidades permitidas y mostrar opciones. La persona debe ver artículos, cantidades, total, entrega y método antes de autorizar el pago. Una preferencia general no sustituye consentimiento para una transacción concreta.
UCP contempla pagos tokenizados y se integra con protocolos de autorización. Mantén datos de tarjeta fuera del agente y usa manejadores de pago aprobados. El comercio sigue responsable de la relación, la orden y las obligaciones aplicables.
Conserva un recibo que vincule carrito, versión de precio, consentimiento, pago y orden sin almacenar secretos.
Identifica solicitudes y evita compras duplicadas
La implementación de Google permite distinguir tráfico mediante encabezados y perfil del agente. Verifica identidad y firma según el contrato efectivo; no confíes sólo en un User-Agent fácil de copiar.
Exige request-id e idempotency-key en operaciones de efecto. Si la conexión se corta después de crear una orden, consulta el estado antes de repetir. La misma clave y el mismo payload deben devolver el resultado anterior; una clave reutilizada con otro contenido debe generar conflicto.
Define cuánto tiempo conservas las claves según la ventana real de reintento y reclamo. Una expiración demasiado corta puede permitir duplicados tardíos; una retención indefinida acumula datos sin propósito. Guarda hash del payload y resultado, no información de pago.
Registra origen, capacidad, clave, estado y recibo. Una demora de red nunca debe convertirse en dos pagos.
Prueba con una tienda ficticia
La documentación oficial ofrece servidor y datos de muestra. Úsalos en local para recorrer descubrimiento, creación de checkout, actualización y error. Sustituye después el catálogo por diez productos sintéticos con variantes y políticas parecidas a tu negocio.
Ejecuta casos de producto agotado, precio cambiado, código inválido, pago rechazado, repetición y consentimiento ausente. Comprueba estado final de inventario y orden. No conectes el laboratorio al procesador real.
Captura solicitud, respuesta y transición sin nombres ni datos de pago. Repite desde una base limpia y confirma que la misma idempotency-key no crea una segunda orden. Fuerza un corte después de aceptar checkout para ensayar reconciliación.
El objetivo es validar tu adaptación y tus fallas antes de solicitar integración con una superficie externa.
Checklist de preparación
1. Existe una fuente canónica de catálogo e inventario.
2. Productos y variantes tienen identificadores estables.
3. Precio, moneda y disponibilidad se revalidan.
4. Envío, devoluciones y soporte están estructurados.
5. El perfil declara sólo capacidades reales.
6. El agente y cada solicitud pueden identificarse.
7. Checkout exige consentimiento concreto.
8. Pago usa tokenización y proveedor aprobado.
9. Escrituras son idempotentes y reconciliables.
10. La tienda ficticia pasa fallas y repeticiones.
Aunque la integración externa tarde, este trabajo mejora el ecommerce actual. Un comercio listo para agentes empieza por ser un comercio con datos y contratos confiables.
