Pagamentos com agentes de IA no Android: carteiras, limites e intenção verificável

Por que agentes de IA estão chegando à etapa de pagamento

O que muda quando um agente deixa de apenas encontrar um produto e passa a participar da compra? A questão central já não é somente a qualidade da recomendação. O sistema precisa demonstrar quem pediu a ação, o que foi autorizado, qual comerciante foi escolhido, quanto pode ser gasto e em que momento a transação deve voltar ao usuário para confirmação.

A documentação de pagamentos para agentes da Alipay, atualizada em 23 de julho de 2026, descreve um caminho no qual comerciantes com aplicativo, Mini Program ou site podem tornar produtos e serviços acessíveis a um agente. O pagamento é concluído pela Alipay após a confirmação do usuário. Isso conecta descoberta, seleção e checkout, mas preserva uma etapa explícita entre o plano elaborado pelo agente e a transferência de valor.

Outra mudança aparece no Agent Payments Protocol. Em 28 de abril de 2026, o anúncio da versão 0.2 do AP2 apresentou pagamentos Human Not Present baseados em instruções previamente autorizadas. O mesmo trabalho descreve Verifiable Intent como um registro resistente a alterações das ações que o usuário autorizou o agente a realizar. Em termos práticos, a autorização precisa acompanhar a tarefa e ser verificável, em vez de existir apenas como uma frase solta no histórico da conversa.

Esses sinais deslocam o mercado da ideia de “comprar por conversa” para um problema de autoridade e prestação de contas. Um agente pode pesquisar, comparar e preparar uma compra; o sistema de pagamentos precisa decidir se há autorização suficiente para avançar. No telefone, essa separação é especialmente importante porque aplicativos, carteira, autenticação do aparelho e tela de confirmação podem pertencer a componentes diferentes.

A negociação de produtos continua sendo uma etapa própria. Nosso artigo sobre Agente de compras com IA: o que JD, Tencent e o telefone precisam resolver aborda a seleção e a coordenação comercial. Aqui, o foco começa quando uma escolha precisa ser convertida em autoridade de pagamento comprovável.

Carteira digital, assistente de compras e carteira de agente

Uma carteira de agente de IA não é apenas uma carteira digital com uma janela de conversa. Cada componente responde por uma decisão diferente, e compreender essa divisão evita que conveniência seja confundida com permissão irrestrita.

A carteira digital protege e apresenta o meio de pagamento. O assistente ajuda a decidir o que comprar. O agente de checkout transforma a escolha em uma sessão transacional. Já a carteira de agente precisa relacionar aquela sessão a uma autorização válida: por exemplo, um teto de gasto, um comerciante permitido, uma categoria aprovada e um prazo definido.

O Universal Commerce Protocol apresentado pelo Google amplia esse cenário ao propor um padrão de comércio de código aberto compatível com AP2 e projetado para funcionar por APIs, A2A e MCP. A proposta facilita a comunicação estruturada entre agentes, comerciantes e serviços. Ainda assim, interoperabilidade comercial e autoridade financeira continuam sendo responsabilidades diferentes: descobrir uma oferta não significa possuir autorização para pagá-la.

Também é útil separar a passagem de intenção para serviço da governança da transação. Em OPPO e Alipay AI Agents: intenção, serviço e confirmação, mostramos como um pedido pode chegar a um serviço compatível. Neste guia, avançamos para as regras que definem se, quando e sob quais condições o pagamento pode prosseguir.

Quem pode autorizar cada tipo de pagamento

Um agente pode pagar sem o usuário estar diante da tela? Tecnicamente, protocolos emergentes descrevem transações previamente autorizadas sem a presença humana naquele instante. A decisão responsável, porém, depende de uma autorização específica e verificável, não de uma permissão permanente para “comprar o que for necessário”.

No modelo com o usuário presente, o agente pesquisa, seleciona e prepara o checkout. Antes da consequência financeira, a tela mostra comerciante, itens, valor, entrega, instrumento e condições relevantes. O usuário revisa, autentica-se quando solicitado e confirma. Essa abordagem é adequada para compras ocasionais, valores variáveis, novos comerciantes e situações em que substituições podem mudar materialmente o pedido.

Uma transação Human Not Present segue outro desenho. O usuário define instruções antecipadamente e o agente atua dentro delas. Um mandato útil pode limitar o valor por compra e por período, restringir comerciantes ou categorias, estabelecer uma data de validade e proibir assinaturas, doações, transferências ou itens sujeitos a condições especiais. O sistema também precisa permitir revogação antes do uso e registrar qual versão da instrução estava ativa.

Exceções devem interromper o avanço automático. Preço acima do limite, item indisponível, comerciante diferente, alteração no prazo de entrega, cobrança recorrente ou mudança relevante nos impostos e taxas são motivos para solicitar nova decisão. Assim, a delegação economiza etapas previsíveis sem apagar o controle sobre mudanças que alteram o compromisso financeiro.

Verifiable Intent acrescenta evidência a essa relação. O registro deve ligar a instrução do usuário à ação proposta pelo agente de maneira resistente a alterações. Ele não substitui todos os controles do comerciante, da carteira ou do emissor, mas ajuda a responder perguntas posteriores: qual era o objetivo, qual limite foi aceito e qual ação o agente estava autorizado a executar?

Para implementar esse modelo no celular, identidade, permissões e histórico precisam trabalhar juntos. A análise em Identidade, permissões e trilhas de auditoria para agentes de IA no telefone aprofunda esses três elementos sem reduzir a autorização a uma caixa marcada uma única vez.

Como a transação percorre o Android

No Android, onde começa e termina a responsabilidade do agente? Um fluxo completo pode envolver sete estágios: intenção, dados do comerciante, sessão de checkout, escolha do instrumento, autenticação do aparelho, comprovante e registro de auditoria. Cada passagem deve transportar apenas os dados necessários e conservar uma forma de conferir o resultado.

1. Intenção: o usuário descreve o objetivo, as preferências e o orçamento. O agente transforma o pedido em um plano e identifica ambiguidades antes de iniciar uma compra.
2. Dados do comerciante: produto, preço, disponibilidade, entrega e identidade do vendedor precisam vir de uma fonte compatível. Alterações relevantes devem retornar ao usuário ou às regras de exceção.
3. Sessão de checkout: o comerciante reúne itens, endereço, taxas e total. Essa sessão deve corresponder à proposta que o usuário viu ou autorizou antecipadamente.
4. Instrumento de pagamento: a carteira apresenta uma opção aceita. O agente não precisa receber o número original do cartão para preparar o fluxo.
5. Autenticação do aparelho: o Android ou a carteira solicita a verificação apropriada quando necessária, mantendo essa decisão no componente responsável.
6. Comprovante: o resultado precisa informar sucesso, falha ou pendência, além de comerciante, valor e referência da transação.
7. Registro: a intenção, a autorização aplicável, as etapas relevantes e o resultado formam a evidência usada para suporte, reembolso ou contestação.

O material do Google sobre tokens de dispositivo no Google Wallet explica que esses tokens substituem o número subjacente do cartão. A autenticação do dispositivo Android protege o uso da carteira. Para aplicativos que precisam confirmar identidade localmente, a orientação oficial sobre autenticação biométrica no Android mostra como integrar mecanismos compatíveis do sistema.

Essas proteções não tornam o agente proprietário da credencial financeira. Elas mantêm carteira e autenticação em seus papéis próprios, enquanto o agente conduz as etapas permitidas. A segurança das capacidades conectadas também precisa ser examinada; consulte Segurança de habilidades de agentes de IA no celular para avaliar o acesso concedido a cada habilidade ou integração.

Como o FoneClaw conduz fluxos que chegam ao checkout

Como o FoneClaw trabalha quando uma tarefa no Android chega a uma tela de checkout ou pagamento? Nossa arquitetura divide entendimento e ação. O modelo compatível configurado pelo usuário interpreta o pedido, raciocina sobre as informações disponíveis e planeja as etapas. O FoneClaw conduz as ações Android suportadas, mantendo o estado visível e respeitando permissões, confirmações e decisões apresentadas pelos aplicativos.

Um fluxo pode começar com a abertura do aplicativo correto, a busca por uma opção, o preenchimento de campos ou a preparação de um carrinho. Durante esse percurso, o usuário consegue acompanhar o resultado na interface. Quando a próxima etapa gera uma consequência financeira, o fluxo chega à confirmação correspondente, com os dados disponíveis para revisão. A carteira, o comerciante e o Android continuam aplicando seus próprios requisitos de autenticação e autorização.

Essa abordagem permite usar o raciocínio do modelo sem transformar o pagamento em uma ação invisível. Preço final, comerciante, item, quantidade, entrega e recorrência são exemplos de informações que devem permanecer perceptíveis antes de uma decisão relevante. Se um aplicativo muda de estado, pede uma permissão adicional ou apresenta uma alternativa fora do plano, o caminho prático é pausar, mostrar a situação e solicitar a escolha necessária.

O FoneClaw também preserva alternativas quando uma etapa não pode continuar da forma planejada. O usuário pode assumir a interação, corrigir uma informação, escolher outro método disponível ou encerrar o fluxo. Esse retorno controlado é parte da experiência: uma tarefa financeira deve terminar com resultado verificável, não com uma suposição de sucesso.

Nosso escopo é o de um agente configurável para ações compatíveis em celulares Android. O artigo Controle do celular por agente de IA: como funciona no Android explica como modelo, interface, permissões e confirmação se combinam em outros tipos de tarefa no telefone.

Checklist para usuários e desenvolvedores

Antes de confiar uma etapa de compra a um agente, o usuário deve conseguir responder a perguntas simples. Qual é o limite máximo? Quais comerciantes e categorias estão incluídos? A autorização vale por uma única transação ou por um período? É possível revogá-la imediatamente? Quem apresentará o recibo e onde ele ficará disponível?

Para quem desenvolve o fluxo, a análise precisa cobrir também falhas e obrigações posteriores. Uma compra não termina na resposta “pagamento aprovado”. Reembolso, entrega parcial, cancelamento, substituição, cobrança duplicada, assinatura e contestação podem exigir a mesma qualidade de identidade e registro usada na autorização inicial.

• Defina o escopo: registre tarefa, comerciante, categoria, valor máximo, frequência e validade.
• Identifique participantes: deixe claro quem é o usuário, o agente, o comerciante, a carteira e o provedor de pagamento.
• Mostre evidências: preserve a instrução autorizada, a proposta final, a confirmação e o comprovante.
• Trate mudanças: solicite nova decisão quando preço, produto, vendedor, entrega ou recorrência sair do escopo.
• Proteja credenciais: mantenha instrumentos e autenticação nos componentes próprios da carteira e do Android.
• Planeje a alternativa: permita que o usuário assuma o fluxo ou escolha outro caminho quando a automação não puder avançar.
• Cubra o pós-pagamento: vincule recibos, suporte, cancelamentos e reembolsos à transação correta.
• Prepare a contestação: registre o que foi autorizado, executado e confirmado, incluindo falhas e tentativas interrompidas.

Para assinaturas, a autorização precisa distinguir claramente a primeira cobrança das seguintes. Um teto para uma compra única não deve ser interpretado como consentimento para cobranças recorrentes. Em reembolsos, o agente pode ajudar a localizar o pedido e preparar a solicitação, enquanto comerciante e sistema de pagamento aplicam o processo correspondente.

A regra prática é proporcionalidade: quanto maior o valor, a duração ou a dificuldade de reversão, mais explícita deve ser a confirmação. Pagamentos com agentes de IA no Android tornam-se úteis quando intenção, limites, autenticação, comprovante e recuperação formam uma cadeia compreensível do início ao fim.