Integración de su tienda en el chat de IA con UCP: lo que necesita saber

¿Qué es UCP y por qué debería importarme?

Así que su tienda está considerando integrarse con el Protocolo de Comercio Universal (UCP), que es una forma de que las plataformas de IA y los servicios de chat se conecten con su tienda para el inventario y las ventas. Eso es inteligente: abre nuevos canales de venta. Pero antes de lanzarse, Hablemos con un experto de lo que puede salir mal y de lo que debe tener cuidado.

Piense en el UCP como si le diera a un amigo de confianza acceso a su caja registradora. Usted quiere asegurarse de que

1. Sólo tengan acceso los verdaderos amigos de confianza
2. No pueden cambiar los precios ni robar de la caja
3. Cuando manejan dinero, lo hacen de forma segura

La cuestión es que los "amigos de confianza" pueden verse comprometidos. Una plataforma en la que confía podría ser pirateada. O un usuario malintencionado podría intentar explotar el flujo de caja. Permítame guiarle a través de algunos problemas de seguridad reales.

La configuración básica: Cómo funciona UCP

Cuando se integra con UCP, esencialmente está diciendo: "Eh plataformas, aquí está mi API de pago. Usadla para vender mis cosas".

Esto es lo que ocurre

1. Una plataforma le descubre - Miran su endpoint /.well-known/ucp para ver qué soporta (checkout, pedidos, gestión de pagos, etc.)
2. Acuerdanlas capacidades - Usted y la plataforma negocian qué características soportan ambos
3. Ellos inician el pago - Un cliente añade su producto a su cesta en el chat de Google o en algún agente de IA
4. Usted gestiona el pago - La plataforma le envía la información de pago (como un token, no números de tarjeta en bruto), y usted la procesa
5. Usted envía actualizaciones - Usted indica a la plataforma cuándo se envía el pedido, cuándo llega, etc.

Usted mantiene el control. Usted sigue siendo el comerciante. La plataforma sólo facilita el pago.

Cómo se conectan las plataformas con usted:

UCP admite varios protocolos para que las plataformas se comuniquen con usted:

• REST/HTTPS - API HTTP estándar
• MCP - Para agentes LLM a través de JSON-RPC
• A2A - Comunicación de agente a agente
• Checkoutincrustado (ECP ) - Interfaz de usuario de checkout incrustada directamente en una aplicación host

Todas ellas utilizan autenticación mediante token portador y validan perfiles de plataforma. La diferencia es el formato del protocolo, no el mecanismo de seguridad.

Amenaza 1: Manipulación del flujo de caja

El escenario: Un usuario malintencionado O una plataforma comprometida manipula el flujo de pago y cambia:

• El precio (cobra 5 $ en lugar de 50 $)
• La cantidad (pide 1.000 artículos en lugar de 1)
• La dirección de envío (envía a su dirección en lugar de a la del cliente)
• El total del pedido o los descuentos

Esto podría provocar pérdidas de ingresos, un cumplimiento incorrecto o fraude.

Cómo ayuda UCP:

UCP utiliza un concepto denominado vinculación. Cuando se recopila la información de pago de un cliente, se vincula a una sesión de pago específica con un ID único. Ese ID está incrustado en el token de pago. Cuando se procesa el pago, se verifica que el ID de pago del token coincide con el pedido actual.

Es como un recibo que dice: "Este pago es sólo para el pedido #ABC123. No lo utilice para el pedido #XYZ789".

Este es el flujo

1. La plataforma inicia una sesión de pago con usted
2. Usted devuelve un objeto de pago con gestores de pago y configuración
3. La plataforma recopila las credenciales de pago del cliente a través de un proveedor de credenciales de pago compatible
4. Las credenciales están tokenizadas o encriptadas, vinculadas al checkout_id específico
5. La plataforma envía el token junto con el checkout_id para completar el pedido
6. Usted verifica que la vinculación del token coincide con el pago actual

Lo que debe hacer

1. Verificar lavinculación en cada pago - Comprobar que el checkout_id del token coincide con su checkout actual. Si una plataforma maliciosa intenta utilizar un vale de la caja A para la caja B, debería fallar.
2. Establezca la caducidad de los tokens - Los tokens sólo deberían ser válidos durante 5-30 minutos. Después, caducan y no pueden reutilizarse. Si un token permanece demasiado tiempo, un atacante tiene más tiempo para explotarlo.
3. Imponga el uso único - Lo ideal es que un token sólo funcione una vez. Después del primer uso, no es válido. Esto impide que los atacantes reutilicen un código válido en varios pagos.
4. Valide la configuración del gestor de pagos - Antes de aceptar el pago a través de un gestor (como Google Pay), compruebe que la configuración del gestor coincide con lo que usted anunció. Un gestor mal configurado o suplantado podría redirigir los pagos a la cuenta de un atacante.
5. Verifique que los detalles del pago coinciden - Cuando una plataforma envíe una solicitud de pago completa, verifique que los artículos, precios y totales no han cambiado desde que se creó el pago. Una plataforma o usuario malicioso podría intentar enviar una caja con precios diferentes a los que usted aprobó.

Amenaza 2: Plataformas maliciosas que envían datos falsos

El escenario: Una plataforma comprometida o maliciosa le envía eventos de pedido falsos (webhooks), alegando que los pedidos se han realizado, enviado o reembolsado cuando no es así. Esto podría dar lugar a

• Recuentos de inventario incorrectos
• Reembolsos fraudulentos
• Registros de clientes confusos
• Pérdida de ingresos

Cómo ayuda UCP:

UCP exige a las plataformas que firmen criptográficamente todas las cargas útiles de los webhooks. Cuando recibe un webhook, puede verificar la firma utilizando la clave pública de la plataforma. Si la firma no es válida, el webhook es falso.

Es como comprobar la firma de un cheque: si no coincide, no lo cobra.

Lo que debe hacer

• Verifique las firmas de cada webhook - No se salte este paso. Si una plataforma maliciosa intenta enviar eventos de pedido falsos, o si un atacante intercepta y modifica un webhook, la firma no será válida. Pruebe con una firma no válida: debería fallar.
• Sólo acepte firmas de una lista permitida de algoritmos admitidos - Defina qué algoritmos admite su sistema para las firmas de webhook y rechace cualquier firma que utilice un algoritmo diferente. Esto evita ataques de confusión de algoritmos y otras vulnerabilidades JWT. Pruebe con un algoritmo no soportado - Debería fallar.
• Utilice la clave correcta para verificar - Compruebe el kid (ID de la clave) en la cabecera de la firma para encontrar la clave pública correcta del perfil de la plataforma. Si utiliza una clave incorrecta, la verificación fallará. Pruebe con una firma de la plataforma incorrecta: debería fallar.
• Rechace las firmas caducadas - Las firmas deben tener una fecha de caducidad. No acepte firmas más antiguas que un umbral razonable. Pruebe con una firma caducada: debería fallar.

Amenaza 3: Operaciones no autorizadas

El escenario: Una plataforma o un usuario malintencionados intentan realizar operaciones en su tienda que no deberían poder realizar:

• Accediendo a sesiones de pago que no han creado
• Solicitando capacidades que usted no admite
• Utilizando credenciales caducadas o no válidas
• Realizando operaciones con el token de otra persona

Cómo ayuda UCP:

UCP utiliza dos mecanismos para evitar operaciones no autorizadas:

1. Autenticación del token de portador: las plataformas deben incluir un token de portador válido con cada solicitud. Los tokens no válidos o caducados son rechazados.

Nota: ECP permite el uso de cualquier formato de autenticación común, no sólo tokens portadores. No obstante, se siguen aplicando las mismas consideraciones de seguridad.

2. Negociación de capacidades - Usted y la plataforma acuerdan qué operaciones están permitidas. Si una plataforma solicita algo que usted no admite, se rechaza.

Usted tiene que

1. Validar los tokens portadores en cada solicitud - Verificar que el token es válido, no ha caducado y pertenece a una plataforma autorizada. Pruebe con un token inválido-debería fallar. Pruebe con un token caducado: debería fallar.
2. Rechace los tokensmalformados - Si un token no coincide con el formato esperado, rechácelo. Pruebe con un token malformado: debe fallar.
3. Utilice sólo HTTPS - Los tokens portadores sólo son seguros a través de HTTPS. Nunca acepte tokens portadores a través de HTTP plano. Esto evita la interceptación de tokens.
4. Valide el perfil de la plataforma - Antes de procesar las solicitudes, obtenga y valide el perfil de la plataforma a partir de la URI que proporcionan. Pruebe proporcionando un perfil malicioso: debería ser rechazado o gestionado de forma segura.
5. Calcule correctamente la intersección de capacidades - Sólo permita operaciones que se encuentren en la intersección de sus capacidades y las de ellos. Pruebe solicitando una operación no admitida: debería fallar.
6. Rechace las operaciones no admitidas - Si una plataforma solicita algo que usted no admite, rechácelo con un error claro. Haga una prueba solicitando una operación que usted no anuncia: debería fallar.
7. Maneje los desajustes de versión - Si una plataforma está utilizando una versión de UCP más reciente que la que usted soporta, manéjelo con elegancia (normalmente rechazando la solicitud). Realice una prueba conectándose con una versión no compatible: debería fallar.

Amenaza 4: Exploit de checkout incrustado

El escenario: Imagine que incrusta un formulario de pago directamente en una aplicación host, por ejemplo, un quiosco, una aplicación móvil o un sitio web. La aplicación host se comunica con su caja a través de mensajes. Un usuario o atacante malintencionado podría

• Activar el pago sin que el cliente pulse "confirmar".
• Escapar de la caja de arena y acceder a datos confidenciales
• Inyectar scripts maliciosos
• Robar credenciales de pago o información del cliente

Esto podría dar lugar a cargos no autorizados, robo de datos o fraude.

Cómo ayuda UCP:

El protocolo de pago integrado (ECP) de UCP está diseñado para estar en un entorno aislado, es decir, restringido a gestionar únicamente el pago, sin acceder a otros datos ni desencadenar acciones sin permiso. Pero esto requiere una cuidadosa configuración.

Lo que debe hacer

1. Restringir lo que puede hacer la caja integrada. Sólo debe gestionar el pago, no navegar por la web ni acceder a otros datos. Haga una prueba intentando acceder a datos ajenos a la caja: debería bloquearse.
2. Utilice la política de seguridad de contenidos (CSP) - Indique al navegador qué recursos puede cargar la caja y qué puede hacer. Esto evita que se ejecuten scripts inyectados. Haga una prueba intentando inyectar un script -debería ser bloqueado por la CSP.
3. Exija la confirmación del anfitrión antes del pago - La aplicación anfitriona debe confirmar antes de liberar la información de pago. Nada de pagos silenciosos. Si la caja integrada intenta activar el pago sin la aprobación del anfitrión, debería fallar. Pruébelo haciendo que la caja integrada intente activar el pago de forma silenciosa: debería fallar.
4. Valide los orígenes de los mensajes - Sólo acepte mensajes de orígenes de confianza. Si un mensaje procede de un origen inesperado, rechácelo. Haga una prueba enviando un mensaje desde un origen que no sea de confianza: debería ser rechazado.

Amenaza 5: Fraude de agente autónomo

El escenario: Un agente de IA realiza una compra en nombre de un cliente sin la debida autorización, o un atacante manipula una compra autónoma para:

• Cobrar un importe erróneo
• Hacer un pedido a una dirección incorrecta
• Cambiar artículos después de la autorización
• Falsificar la prueba del consentimiento del cliente

Cómo ayuda UCP:

La extensión AP2 Mandates de UCP añade una prueba criptográfica de la autorización. Tanto usted como el agente firman las condiciones de pago, creando un registro a prueba de manipulaciones de lo que se autorizó.

Es como obtener un contrato firmado por ambas partes: si alguien intenta cambiar los términos, las firmas ya no coinciden.

Lo que debe hacer

1. Verifique que las firmas utilizan el algoritmo correcto - Sólo acepte ES256, ES384, o ES512 según lo especificado por UCP. Rechace cualquier firma que utilice un algoritmo diferente, incluido alg:"ninguno". Esto evita ataques de confusión de algoritmos y otras vulnerabilidades JWT. Pruebe con un algoritmo no soportado: debería fallar.
2. Rechazar firmas no válidas - Si una firma no coincide, rechace el pago. Pruebe con una firma no válida: debería fallar.
3. Asegúrese de que la firma cubre los datos correctos - Verifique que la firma cubre las condiciones de pago y que no ha sido eliminada o modificada. Realice la prueba modificando los datos del pago después de firmar: la verificación debería fallar.
4. Gestione la rotación de claves con elegancia - Cuando actualice sus claves de firma, asegúrese de que las firmas antiguas siguen verificándose durante un periodo de gracia. Pruebe con una clave caducada: debería fallar (o tener éxito si está dentro del periodo de gracia, dependiendo de su política).
5. Valide la configuración del manipulador - Antes de aceptar el pago a través de un manipulador utilizado por un agente autónomo, verifique que la configuración del manipulador es legítima. Un manipulador mal configurado podría redirigir los pagos a la cuenta de un atacante. Pruebe con una configuración de gestor maliciosa: debería ser rechazada.

Tratamiento de los datos de pago: Conozca su modelo

UCP está diseñado para que usted nunca toque números de tarjeta en bruto. En su lugar, usted trabaja con tokens. Pero existen diferentes modelos, y cada uno de ellos tiene diferentes implicaciones de seguridad y complejidad para su empresa:

Opción 1: Su procesador de pagos (PSP) ejecuta el tokenizador

• Su PSP gestiona los números de tarjeta sin procesar y la tokenización (el PSP debe cumplir la norma PCI-DSS)
• Usted sólo recibe tokens, nunca credenciales en bruto
• Ni usted ni la plataforma necesitan cumplir la normativa PCI-DSS
• Esta es la carga de cumplimiento más baja para su empresa

Opción 2: La plataforma cifra por usted

• La plataforma cifra la tarjeta utilizando su clave pública
• Usted la descifra localmente (pasa a cumplir la normativa PCI-DSS)
• Usted gestiona las claves de cifrado de forma segura y las rota periódicamente

Opción 3: La plataforma ejecuta el tokenizador

• El proveedor de pagos de la plataforma maneja los números de tarjeta en bruto
• Usted llama a su punto final /detokenize para obtener la información de la tarjeta cuando necesita cobrar
• Debe cumplir la normativa PCI-DSS para recibir la información de la tarjeta
• El proveedor de credenciales de la plataforma debe cumplir con PCI-DSS
• Sólo las empresas incorporadas pueden llamar a /detokenize-verifiqueque esto se cumpla

Opción 4: Usted ejecuta el tokenizador (la más compleja)

• Usted recibe los números de tarjeta en bruto (se convierte en cumplidor de PCI-DSS, lo que es caro y complejo)
• Usted genera tokens para que las plataformas los utilicen
• Los tokens deben ser de un solo uso o de corta duración para evitar su reutilización

Acción a tomar: Comprenda qué modelo está utilizando y qué obligaciones de cumplimiento conlleva. Si maneja datos de tarjetas sin procesar, el cumplimiento de la norma PCI-DSS es obligatorio. Si su PSP se encarga de la tokenización, es posible que pueda evitar por completo el cumplimiento del PCI-DSS.

Su lista de comprobación previa al lanzamiento

Antes de ponerse en marcha con UCP, asegúrese de haber comprobado

Verificación de firmas

• Verifique las firmas en cada solicitud/webhook entrante
• Rechace las firmas no válidas, caducadas o malformadas
• Rechace las firmas con alg: "ninguna"
• Prueba con una firma falsa: debe fallar
• Prueba con una firma caducada: debe fallar.

Validación de enlace

• Verificar que los ID de la caja coinciden entre el vale y el pago
• Pruebe el uso de un código de una caja para otra: debe fallar.
• Pruebas con tokens caducados - deben fallar
• Verificar que los detalles de la caja (artículos, precios, totales) no han cambiado

Caducidad de los tokens

• Los tokens caducan después del tiempo documentado (normalmente de 5 a 30 minutos)
• Los tokens caducados son rechazados
• Pruebe con un token antiguo-debería fallar

Configuración del gestor

• Valide los gestores de pago antes de aceptarlos
• Compruebe que la configuración del gestor se ajusta a sus expectativas
• Pruebe con un gestor falso: debería fallar.
• Pruebe con una configuración de gestor maliciosa: debería fallar.

Negociación de capacidades

• Valide el perfil de la plataforma antes de procesar las solicitudes
• Compute correctamente la intersección de capacidades
• Rechace las operaciones no compatibles
• Maneje adecuadamente los desajustes de versión
• Realice pruebas con capacidades no admitidas: deben fallar

Comprobación integrada (si se utiliza)

• Las restricciones de la caja de arena evitan el escape
• Se aplican las directivas CSP
• La aplicación anfitriona confirma antes de liberar la información de pago
• Pruebe los intentos de pago silenciosos: deberían fallar
• Pruebe los intentos de escape de la caja de arena: deberían fallar

Agentes autónomos / Mandatos AP2 (si se utilizan)

• Las firmas se verifican correctamente
• Las firmas no válidas son rechazadas
• Se rechazan los ataques de confusión de algoritmos
• Prueba con comprobación manipulada-la verificación de la firma debería fallar
• Prueba con claves caducadas-debería fallar (o tener éxito si está dentro del periodo de gracia)

Conclusión

UCP está bien diseñado, pero hace recaer sobre usted la responsabilidad de la seguridad.

Las buenas NOTICIAS: la mayoría de las comprobaciones de seguridad son sencillas.

Las malas NOTICIAS: si se las salta, estará expuesto tanto a plataformas maliciosas como a usuarios malintencionados.

¿Tiene preguntas sobre su implementación específica? Antes de lanzarse, analice estos escenarios con su equipo de seguridad y un tercero como Bureau Veritas Cybersecurity. Le ahorrará dolores de cabeza más adelante.