Tecnología de los pagos

El Protocolo Universal de Comercio (UCP) de Google, explicado: ¿Qué significa para los comercios y sus pago?

Alex Saiz Verdaguer | 21 de mayo de 2026
El Protocolo Universal de Comercio (UCP) de Google, explicado: ¿Qué significa para los comercios y sus pago?

El comercio agéntico está pasando del concepto a la infraestructura. En los últimos dieciocho meses ha emergido una nueva capa de protocolos para gobernar cómo los asistentes de IA descubren, negocian y realizan transacciones en nombre de los usuarios.

El Model Context Protocol (MCP) de Anthropic estableció la capa de integración más amplia —conectando sistemas de IA con herramientas externas y fuentes de datos. Sobre esa base, Google ha introducido dos estándares específicos para el comercio: Agent Payments Protocol (AP2), centrado en mandatos de pago delegados, y Universal Commerce Protocol (UCP), una especificación más amplia que se sitúa por encima de los pagos y cubre toda la interacción entre comercio y plataforma de IA. UCP fue codesarrollado con Shopify y lanzado en enero de 2026, con el respaldo de una coalición de más de 20 distribuidores y plataformas.

Si tu tienda vende hoy a través de Shopify, WooCommerce, Magento o una web a medida, la pregunta ya no es si los clientes deberían descubrir y comprar tus productos a través de Gemini, el Modo IA de Google u otras plataformas de IA. La pregunta es cómo —y qué significa eso para tu checkout, tus tokens, tu PSP y tu responsabilidad como comercio de registro.

Este artículo desglosa el protocolo UCP desde la perspectiva de los pagos: ¿Qué resuelve?, ¿Cómo funciona el flujo en la práctica¿, ¿Dónde encaja el proveedor de servicios de pago? y ¿Qué debería estar considerando un comercio europeo mientras el estándar se despliega?

Tabla de contenidos

El problema N×N que el UCP intenta resolver

Sin un protocolo compartido, cada comercio que quiera vender a través de cada plataforma de IA tiene que construir una integración separada con cada una. Tres plataformas significa tres integraciones, cada una con su propia especificación, su propio formato de catálogo de productos, estructura de carrito, API de checkout y superficie de pago. Cinco plataformas significa cinco. El trabajo se multiplica, la carga de mantenimiento se multiplica, y los comercios pequeños quedan fuera del juego por completo.

UCP es un lenguaje común para el comercio agéntico, codesarrollado por Google y Shopify. Una especificación, pública, que cualquier plataforma de IA y cualquier comercio pueden adoptar. Un comercio que expone un endpoint compatible con UCP puede ser descubierto y operar con cualquier plataforma compatible con UCP —sin integración específica para cada una.

Es importante destacar que el tráfico no circula a través de Google. UCP es una especificación, no un marketplace. La comunicación ocurre directamente entre la plataforma de IA y el comercio. Google publica el estándar; los participantes son dueños de la conexión.

Google's Universal Commerce Protocol diagram detail

Fuente: Google  

Los actores

Cuatro entidades aparecen en una transacción UCP:

  • La plataforma. La interfaz impulsada por IA donde el comprador está interactuando —un asistente de chat, un agente, una interfaz de voz.
  • El negocio. (UCP usa la denominación business en todo momento.)
  • El proveedor de credenciales. La parte que almacena y tokeniza las credenciales de pago —Google Pay, Apple Pay, PayPal o equivalente.
  • El proveedor de servicios de pago (PSP). La parte orientada al adquirente que procesa el token de pago resultante. Aquí es donde encaja MONEI.

Una separación clara de responsabilidades. La plataforma de IA gestiona el descubrimiento y la conversación. El negocio gestiona el catálogo, el inventario, el cumplimiento y las obligaciones como vendedor oficial. El proveedor de credenciales gestiona la tokenización y la autenticación. El PSP gestiona el procesamiento, la adquisición y la liquidación.

Cómo funciona realmente una transacción UCP

Google's UCP payment flow example

Fuente: Google. Ejemplo de conversación: "Encuentra una maleta ligera para mi próximo viaje."

Paso 1: Perfiles publicados con antelación

Tanto la plataforma como el negocio publican un perfil UCP —un documento estructurado que declara qué versión de UCP soportan, qué servicios (API REST, MCP, etc.) hablan, qué capacidades ofrecen (catálogo, carrito, checkout, pedidos, vinculación de identidad) y —crítico para los pagos— qué gestores de pago soportan (Google Pay, Apple Pay, tarjeta en bruto, tarjetas guardadas, mandatos AP2, etc.).

El negocio aloja su perfil en una dirección web definida por UCP en sus propios servidores. La plataforma hace lo mismo.

Paso 2: Negociación de capacidades

Cuando una plataforma quiere interactuar con un negocio, obtiene el perfil del negocio, envía el suyo propio y ambos calculan la intersección de servicios y capacidades soportadas conjuntamente. La plataforma elige entonces qué servicio usar de esa intersección.

Esta negociación puede ocurrir con antelación y almacenarse en caché. Las plataformas no necesitan esperar a la intención de un usuario para consultar los perfiles de los negocios —pueden prenegociar con miles de comercios y tener la conexión activa para cuando un usuario pregunte "encuentra una pizza vegana cerca de la Plaça de Catalunya."

Paso 3: Descubrimiento de producto

Una vez acordados un servicio y las capacidades, la plataforma puede llamar a los endpoints del catálogo del negocio. Dos patrones:

  • Búsqueda —la plataforma envía una consulta ("pizza") y el negocio devuelve productos coincidentes con metadatos, IDs, SKUs, variantes, precios y enlaces.
  • Consulta —la plataforma ya conoce IDs de producto específicos (individual o en lote) y obtiene sus detalles.

El negocio responde con datos estructurados de producto que la plataforma puede renderizar en su propia interfaz.

Paso 4: Sesión de checkout

Cuando el usuario confirma la intención de compra, la plataforma envía una solicitud de sesión de checkout al negocio. Esta llamada lleva los artículos de línea, la dirección de facturación y la dirección de envío.

El negocio valida todo (disponibilidad, precios, compatibilidad con la dirección), genera un ID de checkout y responde con:

  • El ID de checkout
  • Expiración y un enlace de checkout alternativo
  • La lista de gestores de pago soportados para este checkout concreto, junto con su configuración específica del comercio

Es ese último punto el que más importa para los pagos. El negocio le está diciendo a la plataforma: "para esta transacción, acepto Google Pay configurado contra mi ID de cuenta X, con estas redes de tarjetas y estas restricciones de país emisor." Las opciones de pago del comercio se están proyectando en la interfaz de la plataforma de forma estructurada y controlable.

Paso 5: Autorización de pago

La plataforma muestra al usuario solo las opciones de pago que cumplen las restricciones del negocio. El usuario elige una —pongamos Google Pay.

Google Pay (el proveedor de credenciales) autentica al usuario, genera un token de pago específico del negocio basado en la configuración del comercio y entrega ese token a la plataforma. La plataforma nunca ve el PAN en bruto. El token está vinculado a ese comercio; no puede reutilizarse contra otro diferente.

Paso 6: Finalización del checkout

La plataforma envía una solicitud final de checkout al negocio con el token de pago, el ID de checkout y cualquier otro detalle requerido. El negocio entrega el token a su PSP. El PSP procesa el pago —ejecutando las comprobaciones necesarias contra el proveedor de credenciales— y devuelve un resultado al negocio, que a su vez devuelve los detalles del cumplimiento a la plataforma.

La capacidad de pedidos (en la que no profundizaremos aquí) gestiona entonces los enlaces de seguimiento, el estado de la entrega y los eventos posteriores a la compra.

Las variaciones que importan

UCP no es un flujo de pago único —es una estructura que acomoda varios, cada uno apropiado para un escenario diferente.

Introducción de tarjeta en bruto. Cuando el usuario quiere introducir una nueva tarjeta, el iframe compatible con PCI del proveedor de credenciales se renderiza dentro de la interfaz de la plataforma. La plataforma nunca toca datos PAN. El iframe produce un token utilizable posteriormente por el negocio y su PSP.

Tarjeta guardada en el comercio. Si el usuario ya tiene tarjetas guardadas en el negocio, no es necesaria una nueva tokenización. La plataforma muestra las tarjetas guardadas del usuario en ese comercio; el usuario elige una; la plataforma pasa una referencia (un ID de método de pago), no un token nuevo. Esto requiere la capacidad de vinculación de identidad de UCP —la plataforma debe ser capaz de reconocer al usuario como una cuenta conocida en el negocio.

Google Pay. En el lanzamiento, el flujo de checkout de UCP usa PANs de financiación estándar almacenados en Google Wallet. Otras formas de pago —incluyendo Apple Pay y PayPal— forman parte de la especificación más amplia, pero puede que no estén completamente activas en todas las integraciones todavía.

Compras agénticas delegadas (AP2). Cuando el usuario autoriza a la IA a comprar en su nombre bajo condiciones específicas, esas condiciones se capturan como un mandato de pago firmado en el momento de la autorización. Cuando las condiciones se cumplen posteriormente, la plataforma solicita un token al proveedor de credenciales, que genera un token vinculado al mandato y conforme con el comercio. Aquí es donde vive el protocolo AP2 de Google —es el protocolo de pago recomendado (pero no obligatorio) de UCP para escenarios delegados.

Seis cosas que debes interiorizar

  1. Cada método de pago define su propia especificación dentro de UCP. UCP estandariza la estructura —los perfiles, la negociación, la apariencia del checkout— pero las reglas de cómo se comporta un token de Google Pay, un token de Apple Pay o un mandato AP2 siguen definidas por la autoridad correspondiente. UCP no reemplaza los estándares de métodos de pago; armoniza cómo se anuncian y consumen.
  2. UCP resuelve el problema N×N también en la capa de pagos. Al mantener la arquitectura de pago desacoplada, UCP permite que nuevos métodos de pago se incorporen sin que cada par plataforma-comercio tenga que reintegrarse.
  3. UCP es agnóstico respecto al protocolo de pago. Google promueve AP2 para escenarios de compra delegada, pero UCP funciona con otros protocolos de pago agénticos. Un negocio puede soportar cualquier superficie de pago que quiera, siempre que esté expuesta en el perfil.
  4. El negocio sigue siendo el comerciante de registro. Esta es la frase más importante de toda la especificación para la relación regulada PSP-comercio. La plataforma de IA no absorbe las obligaciones de comerciante de registro. El ámbito PCI, los reembolsos, los contracargos, la responsabilidad en disputas, las obligaciones AML —todo sigue donde estaba. UCP es infraestructura, no un cambio de modelo a marketplace.
  5. Las verificaciones adicionales se mantienen en el dominio del comercio. Cuando se requiere 3D Secure, SCA o KYC, el usuario es transferido mediante una vista web a la URL que proporcione el negocio. La autenticación reforzada de cliente según PSD2 sigue viviendo donde siempre ha vivido.
  6. El descubrimiento no está en el scope. Cada plataforma de IA decide cómo clasifica, recomienda o presenta los productos. UCP define el lenguaje de comunicación entre la plataforma y el negocio —no la lógica editorial de la IA.

¿Qué significa esto si eres un comercio europeo?

Tres cosas para las que prepararse:

  • Tu PSP necesita operar dentro de este modelo. Cuando el negocio entrega el token de pago a su procesador, ese procesador necesita aceptar tokens de los proveedores de credenciales que tus clientes realmente usan —Google Pay, Apple Pay, tarjeta en bruto vía iframe PCI y, cada vez más, mandatos de estilo AP2. Si tu PSP no está en camino de soportar flujos de comercio agéntico de forma nativa, esa es una pregunta que conviene hacerse ahora, no en 2027.
  • La configuración de tu checkout necesita ser detallada. Los perfiles UCP llevan restricciones —redes de tarjetas aceptadas, normas de país emisor, métodos de pago soportados por región. Si tu PSP actual no te permite configurar el checkout de forma granular por canal, te costará proyectar una experiencia de pago limpia en las plataformas de IA.
  • La SCA, los reembolsos y las disputas no desaparecen. Se vuelven más interesantes. Una compra AP2 delegada donde el usuario preautorizó un mandato hace cuatro días no tiene el mismo registro probatorio que un checkout con usuario presente. Si llega un contracargo, el mandato, las condiciones y el registro de auditoría del lado de la plataforma pasan a ser parte de la representación. Los PSPs y los comercios necesitan pensar ahora en cómo se captura y almacena esa prueba.

Dónde encaja MONEI

La apuesta de MONEI es que los comercios europeos necesitarán una capa de pagos fluida en cada protocolo agéntico que importe —UCP, MCP, AP2 y lo que venga después— sin delegar su condición de comerciante de registro, su cumplimiento PCI ni su posición regulatoria a la plataforma de IA.

Ya hemos lanzado un MCP Server público que permite a los asistentes de IA interactuar directamente con cuentas MONEI, y llevamos una investigación en paralelo sobre el Machine Payments Protocol —la pregunta más amplia de ¿Cómo se liquidan las transacciones entre máquinas, dentro del perímetro regulatorio europeo? UCP encaja limpiamente en esa tesis: es el lenguaje comercio-plataforma, MCP y AP2 son los estándares del lado de los pagos, y un PSP con licencia del Banco de España es lo que hace que la transacción resultante sea legal, liquidada y conforme con la SCA bajo PSD2.

El comercio agéntico va a ser un mundo de múltiples protocolos. Los comercios que ganen son los que tengan su portfolio de pagos listo para eso desde el primer día —no los que todavía estén construyendo integraciones a medida cuando se lance el tercer protocolo principal.

Si quieres hablar sobre cómo debería ser tu hoja de ruta, estamos aquí.

Blog post author image

Alex Saiz Verdaguer

Alex Saiz Verdaguer es fundador y CEO de MONEI. Cuando no está cerrando alianzas, supervisando el desarrollo de productos o pensando en nuevas formas de revolucionar el sector de los pagos, lo encontrarás esquiando, pasando tiempo con su hija o trabajando en un nuevo proyecto artístico.

Rocket

Aumenta la satisfacción de tus clientes y tus ventas al aceptar más métodos de pago.

Únete a MONEI sin compromiso para probar integraciones y pagos.

Abrir una cuenta

Sin compromiso. Date de baja en cualquier momento

Rocket

Aumenta la satisfacción de tus clientes y tus ventas al aceptar más métodos de pago.

Únete a MONEI sin compromiso para probar integraciones y pagos.

Abrir una cuenta

Sin compromiso. Date de baja en cualquier momento