Los agentes de compras personales como Instinct, Muse de Meta y Dots de OpenAI están ganando usuarios reales, y los comercios se preguntan cómo funcionan la prevención del fraude y la gestión de contracargos cuando es un agente quien realiza la compra. Este artículo expone esa carencia y la propuesta de Sardine para subsanarla: un protocolo que vincula la identidad humana con los agentes de compras para que los comercios puedan aprobar compras legítimas.
Por qué los agentes tienen bajas tasas de conversión
Los agentes de compra suelen tener tasas de conversión bajas porque los comercios los identifican como bots. Un agente suele realizar compras desde un navegador en la nube, por lo que el comercio ve el dispositivo y la dirección IP de la nube en lugar de los del comprador. Un agente legítimo puede utilizar la misma infraestructura en la nube y las mismas herramientas de automatización del navegador que un bot malicioso, por lo que el comercio dispone de menos señales para distinguirlos, y cada pedido rechazado aleja aún más al comprador de las compras mediante agentes.
El protocolo Know Your Human (KYH) que proponemos ayuda a los agentes y a los comercios a aumentar las conversiones y ofrece a los comercios mejores pruebas para responder cuando un comprador olvida una compra realizada por su agente o se confunde al respecto. Complementa otros protocolos de comercio mediante agentes: KYH aporta las señales de identidad del cliente que estos no contemplan, es decir, las de la persona que está detrás del agente.
Hasta dónde llegan los protocolos actuales para agentes
Cada uno de los principales protocolos de comercio basado en agentes resuelve un problema real, pero todos dejan fuera a las personas o dejan tareas pendientes para los comerciantes.
Protocolo | Qué hace | Dónde se detiene |
WebBotAuth (Cloudflare) | Confirma que una solicitud proviene realmente de un agente como OpenAI comprobando las claves en la carpeta .well-known de la red del agente. | Verifica al agente. No dice nada sobre la persona que está detrás. |
Protocolo de agentes de confianza de Visa | Una especificación de «conoce a tu agente» (KYA) diseñada pensando en los emisores, para que se les pueda transmitir la intención detrás de una compra. | Se centra en los emisores, por lo que ofrece menos ventajas a los comercios en su parte de la transacción. |
Protocolo de agente personal de Sierra (Poppy) | Ayuda a los comerciantes a prepararse para recibir agentes. La especificación se asemeja a las API de Open Banking, en las que los usuarios conceden permisos específicos a los agentes, y ofrece una forma de obtener el dispositivo y la dirección IP mediante | Está más orientado a obtener datos de bancos y empresas de inversión que a realizar transacciones de comercio electrónico. El comerciante ve la dirección IP de la red del navegador del agente, no la del comprador. |
OpenAI ACP | Una especificación sólida para comercios de gran tamaño. Permite transmitir señales de riesgo, como la dirección IP, el agente de usuario y la huella digital del dispositivo durante el proceso de pago. | Requiere que cada comerciante desarrolle una API específica para agentes, lo que puede dificultar su adopción por parte de los comerciantes más pequeños. |
Qué información se pierde cuando un agente realiza una compra
Muchos agentes de compra personales ocultan los identificadores del dispositivo, la huella digital del dispositivo y la dirección IP del comprador, y no los transmiten al comercio. Esto dificulta la fidelización y la gestión del fraude y de las devoluciones de cargos.
En primer lugar, los comercios no pueden vincular un pago asistido por un agente con los pagos realizados directamente por esa misma persona. Si esa persona olvida la compra realizada por el agente y solicita una devolución del cargo a través de la red de tarjetas, el comercio carece de las mejores pruebas para impugnarla: los identificadores del dispositivo, su huella digital y la dirección IP.
En segundo lugar, los datos que sí reciben los comercios no coinciden con los que utiliza habitualmente el comprador. La dirección IP, el identificador del dispositivo y la huella digital del dispositivo pertenecen al agente, por lo que el comercio puede rechazar el pedido.
CE 3.0 y VAMP de Visa y First Party Trust de Mastercard
La norma Compelling Evidence 3.0 (CE 3.0) de Visa permite a los comercios impugnar un contracargo que una persona haya solicitado por error, siempre que puedan demostrar la coincidencia de los datos del cliente entre la compra en disputa y dos transacciones anteriores que cumplan los requisitos, incluida una coincidencia de dispositivo o dirección IP. Se aplican requisitos de elegibilidad y de presentación de pruebas, y el navegador en la nube de un agente puede ocultar los datos del dispositivo y de la dirección IP que el comercio necesita como prueba.
El Programa de Monitoreo de Adquirentes de Visa (VAMP) eleva el riesgo para los comercios. Tanto los reportes de fraude como las disputas contribuyen al índice VAMP de un comercio:
Ratio VAMP = (Fraude (TC40) + Disputas (TC15)) ÷ Transacciones liquidadas (TC05)
KYH recopila señales del dispositivo y de la dirección IP de la persona para respaldar la defensa ante disputas que cumplan los requisitos, incluidas las reclamaciones CE 3.0 que podrían quedar excluidas de las métricas de VAMP.
Mastercard First Party Trust requiere señales del dispositivo, además de datos de entrega e identidad. El navegador en la nube de un agente puede ocultar la información del dispositivo del cliente, y KYH recopila las señales del dispositivo y de la dirección IP de la persona para ayudar a los comerciantes a aportar las pruebas del dispositivo que exige el programa.
Hoy en día, los pagos asistidos por agentes suelen carecer de los datos básicos que los comercios necesitan para gestionar el fraude habitual o combatir el fraude amistoso. Recopilar una señal por sí sola no garantiza que se pueda responder con éxito a una disputa, pero, sin ella, los comercios cuentan con muchos menos recursos para hacerlo.
La propuesta KYH de Sardine
KYH es un protocolo sencillo y ligero con dos flujos. En el flujo del agente, este envía unas pocas cabeceras HTTP adicionales para que el comercio pueda consultar las señales del dispositivo y de la IP del comprador. En el flujo del comercio, este recurre a un enlace de verificación de corta duración cuando necesita confirmar que hay una persona detrás del agente. El consentimiento es lo primero. Antes de que un agente comparta cualquier dato, el comprador autoriza qué información puede transmitir, como el nombre, los datos de envío y facturación, y la información del dispositivo para prevenir el fraude.
Inteligencia de dispositivos mediante un SDK
Los comercios deberían poder alojar su propia solución de inteligencia de dispositivos. Tomamos como referencia la idea de la URL de método que utilizan los emisores en 3D Secure (3DS). El comercio publica su URL de método en una ubicación conocida, por ejemplo, /.well-known/methodUrl.
Si el agente conoce al comercio y esa URL existe, el agente la invoca. De lo contrario, el agente ejecuta el JavaScript de inteligencia de dispositivos de Sardine. Cuando existe la URL del método del comercio, la llamada tiene este aspecto:
Envío de datos de cabecera al comercio
Los agentes actúan como un servidor proxy durante una compra, por lo que pueden añadir encabezados HTTP a la solicitud, del mismo modo que se utiliza X-Forwarded-For actualmente. Proponemos que todos los agentes transmitan estos campos:
La solicitud también incluye la firma del agente, lo que permite al comerciante verificar su identidad (WebBotAuth es una opción). Hay dos limitaciones. En primer lugar, los comerciantes solo pueden confiar en la información de IP si el agente está verificado. En segundo lugar, no toda la información de identificación personal (PII) puede transmitirse en las cabeceras. Aun así, estas ofrecen a los comerciantes una forma útil de filtrar las solicitudes en el perímetro de la red. Para los agentes, esto solo requiere unas pocas cabeceras HTTP adicionales, y los comerciantes pueden verificarlas a través de un proveedor de KYH como Sardine sin tener que desarrollar una API específica para agentes.
Por eso los agentes también envían Agent-KYH-Provider. Este encabezado indica al comercio dónde obtener más información, como la huella digital del dispositivo del comprador y su dirección IP. Agent-Context-Key se crea cuando se verifica el dispositivo del cliente, lo que vincula la sesión del agente con la persona que hay detrás. El proceso funciona así:
- El agente envía la solicitud con los tres encabezados anteriores.
- El comerciante consulta
Agent-KYH-Providerpara saber quién tiene los datos. - El comerciante realiza una llamada desde el back-end a ese proveedor de KYH (Sardine, el propio comerciante o el agente) con la clave
Agent-Context-Key. - El proveedor de KYH devuelve la información del dispositivo y de la dirección IP correspondiente a esa sesión.
La respuesta tiene este aspecto:
Se pueden añadir otros campos a la respuesta, como datos de KYC o de verificación de identidad.
Flujo del comerciante: verificación adicional mediante un enlace
No todos los agentes los enviarán. En lugar de rechazar el pedido, el comercio puede recurrir a KYH para reforzar la verificación: envía al comprador un enlace de corta duración. El comprador lo abre en su propio teléfono, Sardine recopila las señales de su dispositivo y de su comportamiento y las incorpora a la sesión del comercio, y la página le muestra un código de un solo uso para que se lo facilite al agente.
Ayúdanos a probarlo
Los agentes seguirán comprando en nombre de las personas, y los comercios necesitan las mismas señales que obtienen cuando una persona realiza el pago para frenar el fraude y defenderse ante las devoluciones de cargo. Buscamos desarrolladores de agentes y comercios para desarrollar y probar la propuesta. Mira las demostraciones de arriba, obtén más información en nuestra página Know Your Human o ponte en contacto con nosotros para integrar un agente o un comercio.
