Agentes de compras pessoais como o Instinct, o Muse da Meta e o Dots da OpenAI estão conquistando usuários reais, e os comerciantes querem saber como funcionam a prevenção de fraudes e a gestão de chargebacks quando um agente faz a compra. Este artigo apresenta essa lacuna e a proposta da Sardine para eliminá-la: um protocolo que vincula a identidade humana aos agentes de compras para que os comerciantes possam aprovar compras legítimas.
Por que os agentes têm baixas taxas de conversão
Os agentes de compras costumam ter baixas taxas de conversão porque os comerciantes os identificam como bots. Um agente geralmente faz compras por meio de um navegador na nuvem, de modo que o comerciante vê o dispositivo e o endereço IP da nuvem em vez dos dados do comprador. Um agente legítimo pode usar a mesma infraestrutura de nuvem e automação de navegador que um bot malicioso, o que deixa o comerciante com menos sinais para distinguir um do outro. Além disso, cada pedido recusado afasta ainda mais o comprador das compras por meio de agentes.
O protocolo Know Your Human (KYH) que propomos ajuda agentes e comerciantes a aumentar a conversão e fornece aos comerciantes provas mais sólidas para responder quando um comprador se esquece de uma compra feita pelo seu agente ou fica confuso com ela. Complementa outros protocolos de comércio agêntico: o KYH fornece os sinais de identidade do cliente que esses protocolos não abrangem, nomeadamente os da pessoa por trás do agente.
Onde os protocolos atuais para agentes ficam aquém
Cada um dos principais protocolos de comércio agêntico resolve um problema real, mas todos deixam as pessoas de fora ou deixam trabalho por fazer aos comerciantes.
Protocolo | O que faz | Onde termina |
WebBotAuth (Cloudflare) | Confirma que um pedido provém realmente de um agente como a OpenAI, verificando as chaves na pasta .well-known na rede do agente. | Verifica o agente. Não diz nada sobre a pessoa por trás dele. |
Protocolo de Agente de Confiança da Visa | Uma especificação «conheça o seu agente» (KYA) desenvolvida a pensar nos emissores, para que lhes possa ser transmitida a intenção por detrás de uma compra. | Centrado nos emissores, pelo que oferece menos aos comerciantes na sua parte da transação. |
Protocolo de Agente Pessoal da Sierra (Poppy) | Ajuda os comerciantes a prepararem-se para receber agentes. A especificação assemelha-se às APIs de Open Banking, em que os utilizadores concedem permissões específicas aos agentes, e oferece uma forma de obter o dispositivo e o endereço IP através de | Mais orientado para obter dados de bancos e empresas de negociação financeira do que para transações de comércio eletrónico. O comerciante vê o endereço IP de rede do navegador do agente, não o do comprador. |
OpenAI ACP | Uma especificação robusta para comerciantes de grande dimensão. Pode transmitir sinais de risco, como o endereço IP, o agente do utilizador e a impressão digital do dispositivo no momento do pagamento. | Exige que cada comerciante desenvolva uma API dedicada para agentes, o que pode dificultar a adoção por comerciantes de menor dimensão. |
O que se perde quando um agente faz uma compra
Muitos agentes de compras pessoais ocultam os identificadores do dispositivo, a impressão digital do dispositivo e o endereço IP do comprador, e não os transmitem ao comerciante. Isso cria problemas para a gestão da fidelização, da fraude e dos estornos.
Em primeiro lugar, os comerciantes não conseguem associar um pagamento assistido por um agente aos pagamentos efetuados pela própria pessoa. Se essa pessoa se esquecer da compra feita pelo agente e solicitar um estorno junto da rede de cartões, o comerciante não terá as melhores provas para contestar o pedido: identificadores do dispositivo, impressão digital do dispositivo e endereço IP.
Em segundo lugar, os sinais que os comerciantes conseguem ver não correspondem aos que o comprador normalmente utiliza. O endereço IP, o identificador e a impressão digital do dispositivo pertencem ao agente, pelo que o comerciante pode recusar a encomenda.
CE 3.0 e VAMP da Visa e Mastercard First Party Trust
A regra Compelling Evidence 3.0 (CE 3.0) da Visa permite que um comerciante conteste um estorno solicitado por engano por uma pessoa, desde que consiga demonstrar a correspondência dos dados do cliente entre a compra contestada e duas transações anteriores elegíveis, incluindo uma correspondência de dispositivo ou endereço IP. Aplicam-se requisitos de elegibilidade e de apresentação de provas, e o navegador na nuvem de um agente pode ocultar os dados de dispositivo e endereço IP de que o comerciante precisa como prova.
O Programa de Monitorização de Adquirentes da Visa (VAMP) aumenta os riscos. Tanto os relatos de fraude como as contestações contribuem para o rácio VAMP de um comerciante:
Rácio VAMP = (Fraude (TC40) + Contestações (TC15)) ÷ Transações liquidadas (TC05)
O KYH recolhe sinais do dispositivo e do endereço IP da pessoa para fundamentar contestações elegíveis, incluindo alegações ao abrigo da CE 3.0 que possam ser excluídas das métricas do VAMP.
O Mastercard First Party Trust exige sinais do dispositivo, juntamente com dados de entrega e de identidade. O navegador na nuvem de um agente pode ocultar as informações do dispositivo do cliente, e o KYH recolhe os sinais do dispositivo e do endereço IP da pessoa para ajudar os comerciantes a fornecer as provas relativas ao dispositivo exigidas pelo programa.
Atualmente, os dados básicos de que os comerciantes precisam para lidar com fraudes comuns ou combater a fraude amigável muitas vezes não estão disponíveis nos pagamentos assistidos por agentes. A recolha de um sinal, por si só, não garante uma resposta bem-sucedida a uma contestação, mas, sem ele, os comerciantes dispõem de muito menos elementos para se defenderem.
A proposta de KYH da Sardine
O KYH é um protocolo simples e leve com dois fluxos. No fluxo do agente, o agente envia alguns cabeçalhos HTTP adicionais para que o comerciante possa consultar os sinais do dispositivo e do IP do comprador. No fluxo do comerciante, o comerciante recorre a um link de verificação de curta duração quando precisa de confirmar que existe uma pessoa por trás do agente. O consentimento vem em primeiro lugar. Antes de o agente partilhar qualquer informação, o comprador aprova os dados que este pode transmitir, como o nome, os dados de envio e de faturação e as informações do dispositivo para prevenção de fraude.
Inteligência de dispositivos através de um SDK
Os comerciantes devem poder alojar a sua própria solução de inteligência de dispositivos. Inspiramo-nos no conceito de URL de método que os emissores utilizam no 3D Secure (3DS). O comerciante publica o seu URL de método numa localização predefinida, por exemplo /.well-known/methodUrl.
Se o agente conhecer o comerciante e esse URL existir, o agente invoca-o. Caso contrário, o agente invoca o JavaScript de inteligência de dispositivos da Sardine. Quando o URL do método do comerciante existe, a chamada tem o seguinte aspeto:
Transmissão de dados do cabeçalho ao comerciante
Os agentes atuam como um servidor proxy durante uma compra, pelo que podem adicionar cabeçalhos HTTP ao pedido, da mesma forma que se utiliza atualmente o cabeçalho X-Forwarded-For. Propomos que todos os agentes transmitam estes campos:
A solicitação também inclui a assinatura do agente, o que permite ao comerciante verificar a identidade do agente (WebBotAuth é uma opção). Há duas limitações. Primeiro, os comerciantes só podem confiar nas informações de IP quando o agente é verificado. Segundo, nem todas as informações de identificação pessoal (PII) podem ser transmitidas nos cabeçalhos. Ainda assim, os cabeçalhos oferecem aos comerciantes uma forma útil de filtrar solicitações na borda da rede. Para os agentes, isso exige apenas alguns cabeçalhos HTTP adicionais, e os comerciantes podem verificá-los por meio de um provedor de KYH, como a Sardine, sem precisar criar uma API específica para agentes.
É por isso que os agentes também enviam Agent-KYH-Provider. Este indica ao comerciante onde obter mais informações, como a impressão digital do dispositivo e o endereço IP do comprador. A Agent-Context-Key é criada quando o dispositivo do cliente é verificado, associando a sessão do agente à pessoa por trás dela. O processo funciona assim:
- O agente envia a solicitação com os três cabeçalhos acima.
- O comerciante lê
Agent-KYH-Providerpara saber quem detém os dados. - O comerciante faz uma chamada de back-end a esse fornecedor de KYH (Sardine, o próprio comerciante ou o agente) com a
Agent-Context-Key. - O fornecedor de KYH devolve informações sobre o dispositivo e o endereço IP dessa sessão.
Uma resposta tem o seguinte formato:
Outros campos, como dados de KYC ou de verificação de identidade, podem ser adicionados à resposta.
Fluxo do comerciante: Reforçar a autenticação com uma ligação de verificação
Nem todos os agentes os enviarão. Em vez de recusar o pedido, o comerciante pode recorrer ao KYH: envia ao comprador um link com um prazo de validade curto. O comprador abre-o no seu próprio telemóvel, a Sardine recolhe os sinais do dispositivo e do comportamento do comprador e integra-os na sessão do comerciante, e a página apresenta um código de utilização única para o comprador fornecer ao agente.
Ajude-nos a testar isto
Os agentes continuarão a fazer compras em nome das pessoas, e os comerciantes precisam dos mesmos sinais que obtêm quando uma pessoa finaliza uma compra para impedir fraudes e contestar estornos. Procuramos programadores de agentes e comerciantes para desenvolver e testar a proposta. Veja as demonstrações acima, saiba mais na nossa página Know Your Human, ou contacte-nos sobre uma integração para agentes ou comerciantes.
