Comércio Agente: Visa TAP, Google AP2 e Mastercard Agent Pay Necessitam de uma Camada de Identidade

Principais pontos

• Visa Trusted Agent Protocol (TAP), Google Agent Payments Protocol (AP2) e Mastercard Agent Pay tornam as compras lideradas por agentes mais seguras, mas resolvem diferentes partes do problema de confiança.
• O TAP ajuda os comerciantes a reconhecer agentes aprovados e a verificar a intenção de comércio assinada. O AP2 cria provas do que um utilizador autorizou. O Agent Pay combina agentes registados, credenciais de pagamento tokenizadas, consentimento e visibilidade da rede.
• Nenhum destes mecanismos elimina a necessidade de provar quem é o ser humano ou a empresa, rastrear riscos, aplicar controlos específicos da jurisdição e preservar um registo de auditoria.
• A Didit é uma infraestrutura neutra para identidade e fraude, não uma rede de cartões ou empresa de pagamentos. O seu servidor Model Context Protocol (MCP) alojado expõe 115 ferramentas em 11 categorias, enquanto a Interface de Programação de Aplicações (API) Representational State Transfer (REST) suporta fluxos de produção incorporados.
• Um pacote completo de Know Your Customer (KYC) custa 0,33 USD, cada conta inclui 500 verificações gratuitas por mês e o próprio servidor MCP é gratuito.

O comércio agente começa quando um agente de inteligência artificial (IA) faz mais do que recomendar um produto. Compara ofertas, monta um carrinho, escolhe um método de pagamento e pode concluir uma compra dentro dos limites definidos por uma pessoa ou empresa. Essa mudança cria várias questões de confiança ao mesmo tempo: Que agente fez o pedido? Quem o autorizou? Quem é o ser humano ou a entidade legal por trás dele? A transação é permitida? E que provas existirão se a compra for contestada?

Os padrões de pagamento emergentes respondem a partes importantes dessa sequência. Não respondem todos à mesma parte e não devem ser tratados como intermutáveis. Para os programadores, a questão útil não é qual marca irá “ganhar”. É quais controlos permanecem necessários em todas as arquiteturas credíveis.

Três padrões, três limites de confiança

Visa TAP: o comerciante pode reconhecer e confiar neste agente?

O Visa Trusted Agent Protocol é direcionado ao comerciante. A sua função principal é ajudar um comerciante a distinguir um agente de comércio aprovado de um crawler comum, bot abusivo ou automação desconhecida. Um agente assina um pedido com credenciais vinculadas ao tempo e específicas para o fim. O comerciante ou o seu fornecedor de proteção verifica a assinatura e pode decidir se permite a navegação, o checkout ou uma ação mais restrita.

O TAP descreve três sinais relacionados: uma assinatura de reconhecimento de agente, uma identidade de consumidor ou dispositivo ligada e assinada, e um contentor de pagamento ligado e assinado. Esta é uma separação útil. O reconhecimento de agente estabelece qual agente aprovado está presente; a intenção assinada estabelece que tipo de interação é solicitada; o sinal do consumidor pode ajudar um comerciante a reconhecer um cliente existente.

Esse sinal do consumidor não é automaticamente equivalente a uma nova prova de identidade. O modelo da Visa inclui um papel de provedor de identidade a montante, mas um comerciante ainda precisa de uma política para um cliente novo ou de alto risco: que provas foram verificadas, quão forte é a garantia, se o KYC é exigido e quando a reverificação é necessária. O TAP pode transportar informações de identidade fidedignas sem prescrever todas as decisões de integração jurisdicionais.

Google AP2: o que o utilizador autorizou o agente a comprar?

O Google Agent Payments Protocol foca-se na autorização e nas provas. Utiliza mandatos assinados para ligar a intenção do utilizador, o conteúdo do carrinho e o pagamento. Um mandato aberto pode dar ao agente uma discrição limitada, como restrições do comerciante ou limites de gastos. Um mandato fechado vincula a aprovação a um carrinho e valor específicos. Os recibos completam a cadeia de provas.

O AP2 distingue fluxos com presença humana e sem presença humana. Quando a pessoa está presente, pode aprovar diretamente um mandato de checkout e pagamento fechado. Quando ausente, o agente opera dentro de restrições previamente aprovadas e assina os mandatos fechados finais. Um comerciante ou provedor de credenciais ainda pode trazer a pessoa de volta ao ciclo quando uma restrição não pode ser resolvida.

Este design responde a “Esta pessoa autorizou esta ação sob estas condições?” mais diretamente do que “Como esta pessoa foi originalmente verificada?”. O quadro de autorização AP2 assume que as credenciais de inscrição e de utilizador relevantes existem. Um programador, portanto, ainda precisa de um processo de prova de identidade e ciclo de vida de credenciais antes que esses mandatos possam ter uma garantia significativa.

Mastercard Agent Pay: a rede pode reconhecer e governar um pagamento agente?

O Mastercard Agent Pay baseia-se na tokenização de pagamentos. O quadro de aceitação da Mastercard regista e verifica agentes, atribui uma identidade de agente única e utiliza Tokens Agentes para que as transações sejam rastreáveis e as credenciais de pagamento permaneçam protegidas. O reconhecimento direcionado ao comerciante pode funcionar com a infraestrutura de checkout existente, enquanto integrações mais profundas suportam uma troca de dados mais rica.

O modelo também enfatiza o consentimento do consumidor, a autenticação e a capacidade de emissores, adquirentes e comerciantes reconhecerem que um agente participou. Isso torna a atividade do agente visível dentro de um modelo de risco de rede de cartões familiar, em vez de tornar a automação indistinguível de um pedido comum de cartão não presente.

O Agent Pay é mais forte na segurança de credenciais de pagamento, visibilidade do agente e controlos de rede. Não remove a obrigação do comerciante de decidir quando a verificação de identidade, Know Your Business (KYB), rastreio Anti-Branqueamento de Capitais (AML), verificações de idade ou revisão melhorada se aplicam. Essas decisões dependem do produto, cliente, transação e jurisdição — não apenas do meio de pagamento.

Onde os padrões se sobrepõem — e onde a identidade ainda se encaixa

Todas as três abordagens tentam tornar o comércio delegado legível. Um comerciante deve ser capaz de dizer que a automação está envolvida, verificar se o agente é de confiança, ligar a ação à intenção do utilizador, restringir a compra e reter provas. A sua ênfase difere:

• TAP: reconhecimento de agente e intenção assinada no limite do comerciante, com sinais opcionais de consumidor e pagamento ligados.
• AP2: artefactos de autorização criptográfica que vinculam a intenção do utilizador aos resultados de checkout e pagamento.
• Agent Pay: agentes registados, credenciais de pagamento tokenizadas, consentimento, autenticação e visibilidade em toda a rede de cartões.

A prova de identidade situa-se antes e ao lado destes controlos. Uma autorização assinada só é valiosa se a credencial pertencer à pessoa certa. Um agente aprovado ainda pode ser instruído por uma conta sintética, roubada, sancionada, menor de idade ou de outra forma inelegível. Um token pode proteger as credenciais de pagamento sem estabelecer que um vendedor de mercado ou beneficiário empresarial passou a devida diligência exigida.

A identidade do agente responde a “que software agiu?” A autorização responde a “o que lhe foi permitido fazer?” A verificação de identidade responde a “quem está por trás disso?” Os controlos de fraude e conformidade respondem a “esta ação deve prosseguir?”

O que os programadores têm de construir independentemente da abordagem vencedora

• Inscrição e prova. Verifique a pessoa ou empresa antes de conceder uma credencial reutilizável ou autoridade de gasto delegada. Aplique verificações KYC, KYB, liveness, documento, base de dados ou biométricas de acordo com o risco.
• Vinculação de credenciais. Víncule o sujeito verificado a uma conta, dispositivo, passkey, carteira ou outra credencial que possa participar no fluxo agente.
• Autorização delimitada. Capture limites como comerciante, categoria, valor, frequência, expiração e se um ser humano deve retornar para aprovação.
• Decisões de risco em tempo de execução. Rastreie a pessoa, empresa, carteira e transação no momento da ação. Os controlos Know Your Transaction (KYT) e as verificações AML permanecem relevantes mesmo quando a intenção é assinada.
• Revogação e recuperação. Interrompa a autoridade delegada quando uma credencial é comprometida, o utilizador retira o consentimento ou o risco muda.
• Auditabilidade. Preserve o resultado da verificação, o artefacto de autorização, a identidade do agente, a decisão da transação, os carimbos de data/hora e as ações de revisão posteriores como provas separadas.

Este design em camadas é deliberadamente neutro em relação aos padrões. Uma equipa pode adotar o TAP na extremidade do comerciante, os mandatos AP2 num fluxo de trabalho de agente, o Agent Pay para liquidação de cartões, ou uma combinação. A decisão de identidade e fraude permanece portátil porque não está incorporada numa única rede de pagamentos.

Como a Didit cobre a metade da identidade hoje

A Didit fornece infraestrutura para identidade e fraude usada por mais de 2.000 empresas em produção. As mesmas capacidades estão disponíveis através de um servidor MCP alojado para operações controladas por agentes e uma API REST para fluxos controlados por aplicações. Para uma visão geral da arquitetura mais ampla, veja como um servidor MCP lida com a verificação de identidade e como o MCP liga verificações de identidade e fraude para agentes de IA.

O endpoint MCP alojado é https://mcp.didit.me/mcp. Utiliza Streamable Hypertext Transfer Protocol (HTTP), com Open Authorization (OAuth) 2.1, Proof Key for Code Exchange (PKCE) e Dynamic Client Registration. Um utilizador inicia sessão através da Didit Business Console e concede acesso delimitado; o endpoint MCP alojado não utiliza autenticação por chave de API.

Após a autorização, um agente pode chamar 115 ferramentas em 11 categorias. Uma sequência de verificação prática pode usar:

didit_context_get
didit_session_create
didit_verify_id
didit_verify_passive_liveness
didit_verify_face_match
didit_session_get_decision

Essas ferramentas podem criar uma sessão de verificação, executar as verificações selecionadas e recuperar uma decisão estruturada. Outras ferramentas reais incluem didit_verify_aml, didit_verify_kyb_search, didit_verify_kyb_select e didit_transaction_screen_wallet. As escritas de alta consequência permanecem sujeitas às permissões e ao comportamento de confirmação do utilizador conectado.

A API REST cobre o caminho da aplicação: crie sessões a partir do seu backend, envie utilizadores através de verificação alojada ou incorporada, consuma webhooks e armazene decisões no seu próprio sistema. As solicitações REST de servidor para servidor usam um cabeçalho x-api-key; isso é separado da conexão MCP alojada autenticada por OAuth. Leia a visão geral do MCP, o guia de autenticação e a referência de ferramentas para detalhes de implementação.

O preço é independente do padrão de pagamento agente. O servidor MCP é gratuito. Um pacote completo de KYC — Verificação de Identidade, Liveness Passiva, Face Match e Análise de IP — custa 0,33 USD, e cada conta inclui 500 verificações gratuitas por mês.

Um caminho de implementação neutro em relação aos padrões

Comece por definir a garantia exigida para cada ação, não por escolher um logótipo de rede. A navegação de baixo risco pode precisar apenas de reconhecimento de agente. A criação de contas pode exigir identidade verificada. Uma compra regulamentada pode exigir KYC ou KYB mais rastreio AML. Uma transferência de cripto pode adicionar rastreio de carteira. Valores mais altos ou risco alterado podem fazer com que o ser humano retorne ao ciclo.

Em seguida, ligue o artefacto de pagamento à decisão de identidade com identificadores internos estáveis. Mantenha a assinatura do agente, a autorização do utilizador, as provas de verificação e o resultado do pagamento distintos para que cada um possa ser independentemente revogado, revisto e atualizado à medida que os padrões evoluem.

Explore a página de programadores Didit MCP ou inspecione o repositório público do GitHub, com licença permissiva. Os utilizadores do Claude podem adicionar o conector Didit e concluir o login OAuth.

A arquitetura duradoura é em camadas: os padrões de pagamento provam a participação e autorização do agente; a infraestrutura de identidade e fraude prova quem está envolvido e se a ação é aceitável. Essa divisão permite que os programadores suportem os padrões atuais sem codificar a confiança para um único.