Sinal — pagamentos por agentes
As redes de pagamentos estão a aprender a identificar o agente
O software começou a comprar em nome de um cliente. Para que um pagamento assim mereça confiança, alguém tem de conseguir estabelecer que software está a agir, por que pessoa age e o que essa pessoa lhe permitiu fazer. Um prestador de serviços de pagamento publicou agora um protocolo destinado a transportar essa informação e afirma que começou o trabalho num quadro de interoperabilidade com duas redes de cartões.
Fonte primária publicada a 11 de setembro de 2026Prova verificada a 19 de setembro de 2026
Numa frase
O pagamento de um agente só é tão fiável quanto a resposta que dá a “quem és, de quem é este dinheiro e em que te foi permitido gastá-lo” — e um prestador publicou um protocolo que pretende transportar essa resposta, descrevendo o quadro entre redes como um trabalho que começou.
A encomenda por que ninguém ao balcão pode responder
Ilustração — ficcional
Lucia e os seus restaurantes foram inventados para esta página. Nenhuma parte da cena que se segue é o relato de um comerciante real, de uma encomenda real ou de um resultado real; existe apenas para enunciar o problema do operador em termos correntes.
Imagine Lucia, uma operadora fictícia com onze trattorias em três cidades. Numa quinta-feira à noite, entra uma encomenda no tablet de um dos seus espaços: oito lugares, dois menus fixos. Ninguém da sua equipa falou com um cliente. Ninguém preencheu um formulário. Nesta cena inventada, a encomenda foi feita por software que compra em nome de alguém — um agente, na linguagem que o setor dos pagamentos adotou.
O seu gestor de sala não tem forma de distinguir essa encomenda de outra feita por software confuso, mal configurado ou a agir por alguém que nunca aprovou a despesa. A caixa foi concebida para um mundo em que era uma pessoa a segurar o cartão, pelo que só consegue comunicar que um débito passou e mais nada. Esta página não afirma com que frequência qualquer um desses casos acontece de facto; é precisamente esse o número que ninguém tem ao balcão.
A lacuna não é inventada, ainda que Lucia o seja. É a lacuna que um protocolo de pagamentos por agentes já publicado se propõe resolver: quando o comprador é software, um pagamento só pode ser examinado depois se transportar algo que um número de cartão nunca transportou — um registo de quem estava a agir, por quem e dentro de que limite.
O que o pagamento não lhe diz hoje
- Que software fez esta encomenda e se é algum que o seu canal de reservas já tenha visto.
- Por que cliente estava a agir e se alguém pode depois ser chamado a confirmá-lo.
- O que o cliente permitiu realmente — uma encomenda esta noite ou um acordo permanente que o agente interpretou com generosidade.
- Com quem fala quando o grupo não aparece e o débito é contestado três semanas depois.
O que mudou
Por palavras simples
- Agente
- Software que age por uma pessoa — a procurar, a escolher e, neste caso, a pagar — em vez de ser a própria pessoa a percorrer o processo de pagamento.
- Carteira
- A aplicação de pagamento do consumidor de onde sai o dinheiro, como aquelas que as pessoas já usam para pagar pelo telemóvel.
- Adquirente
- A empresa que processa pagamentos com cartão por conta do comerciante e liquida o dinheiro na conta deste.
- Know Your Agent
- Uma verificação do próprio software: que agente é, quem o opera, por quem age e o que lhe é permitido fazer — à imagem das verificações de identidade que os bancos já fazem a pessoas e empresas. No anúncio citado é descrito como objeto de uma colaboração que começou, não como uma norma publicada.
A 11 de setembro de 2026, a Ant International anunciou a primeira fase do seu Agentic Mobile Protocol (AMP) — um conjunto de regras publicado abertamente sobre a forma como um agente se identifica quando tenta pagar. Um protocolo, aqui, é um formato acordado e documentado que qualquer implementador pode ler e sobre o qual pode construir. O que cada participante implementa, por que ordem e com que grau de completude é matéria de cada implementador; esta página não afirma sabê-lo, e o anúncio não o expõe.
Duas partes desse anúncio interessam a um operador. A primeira é quem nele é nomeado: carteiras digitais (as aplicações com que os consumidores já pagam) e adquirentes (as empresas que processam pagamentos com cartão por conta do comerciante — o lado do comerciante na infraestrutura). A Ant International afirma que as dez carteiras parceiras nomeadas irão suportar o AMP durante a Fase I. A segunda é o que diz vir a seguir: a Ant International afirmou ter iniciado uma colaboração com a Mastercard e a Visa num quadro de interoperabilidade para Know Your Agent, a contraparte, do lado do agente, das verificações de identidade que os bancos já fazem a pessoas e empresas.
A direção é a notícia, e a direção é tudo o que a prova citada sustenta. Identificar o agente é uma questão em torno da qual um prestador publicou agora um protocolo e que descreve como objeto de colaboração com duas redes de cartões. Perante esta prova, não está incorporado na infraestrutura de pagamentos, não está normalizado entre redes e não é pré-requisito de nada; é uma intenção anunciada que um operador pode acompanhar.
A Fase I nomeia dez carteiras digitais — Alipay, AlipayHK, DANA, GCash, KakaoPay, MPay, TNG eWallet, TrueMoney, Toss e Starryblu — que, segundo a Ant International, irão suportar o AMP durante a Fase I, a par de sete parceiros adquirentes: Adyen, Allinpay, Checkout.com, Fiserv, Global Payments, Nuvei e Worldline.
Um participante nomeado é um participante nomeado num anúncio de implementação. Não é uma afirmação de que a funcionalidade esteja ativa para um dado comerciante, mercado ou processo de pagamento, nem de que alguma das partes nomeadas tenha concluído a sua parte.
FonteAnt International11 de setembro de 2026
A Ant International descreve essas dez carteiras como carteiras que servem 1,5 mil milhões de contas de utilizador.
Isto conta contas de carteira, não agentes, nem encomendas, nem compras concluídas. Descreve alcance potencial, não atividade.
FonteAnt International11 de setembro de 2026
O AMP foi disponibilizado em código aberto no GitHub, com código-fonte, SDK para programadores e documentação técnica publicados para plataformas, carteiras, adquirentes e instituições financeiras.
Código publicado é um convite a implementar. Não é prova de que alguém tenha terminado de o implementar, e esta página não auditou o que a especificação publicada exige.
FonteAnt International11 de setembro de 2026
A Ant International, a Mastercard e a Visa iniciaram uma colaboração num quadro de interoperabilidade Know Your Agent destinado a simplificar o registo e a identificação de agentes entre redes.
O que se afirma é que a colaboração começou. Não é declarada qualquer norma concluída, data de lançamento ou compromisso de cobertura.
FonteAnt International11 de setembro de 2026
Quatro perguntas que um operador pode fazer sobre uma encomenda feita por um agente
Um pagamento com cartão responde há muito a uma pergunta: este cartão cobre este montante? Uma encomenda feita por software levanta outras três que um operador quereria ver respondidas antes de tratar o débito como prova assente do que quer que seja.
De quem é esta lista
Esta é a lista de verificação conceptual da Obenan para operadores, escrita para tornar o problema discutível. Não é a ordem de mensagens implementada do AMP e não descreve campos, sequência nem formato de transmissão de protocolo algum. O anúncio citado não expõe uma ordem de mensagens implementada, pelo que nada aqui deve ser lido como tal. Se um dado pagamento consegue responder a alguma destas perguntas depende do que o prestador e o canal à frente do comerciante fornecem de facto.
Pergunta 1 de 4
Que agente é este?
Um operador quereria que a encomenda transportasse algum identificador duradouro do software que a fez, em vez de chegar indistinguível do tráfego web comum.
Sem ele, todos os agentes se parecem, e um que se comporte mal não pode ser distinguido de um que se comporte bem — nem bloqueado sem bloquear todos.
Pergunta 2 de 4
Por quem está a agir?
Um operador quereria uma forma de chegar a quem o agente representou, seja uma conta, um registo de cliente ou um contacto do lado do canal.
Sem um caminho de regresso a uma parte responsável, uma contestação não tem outra contraparte além do próprio comerciante.
Pergunta 3 de 4
O que lhe era permitido fazer?
Um operador quereria que o âmbito da permissão do cliente ficasse registado num sítio que possa examinar, em vez de existir apenas dentro da configuração do próprio agente.
Sem isso, o limite é aquele que o agente julga ser, e “o cliente aprovou” não pode ser confirmado por mais ninguém.
Pergunta 4 de 4
E o que estabeleceu de facto a autorização?
Um operador quereria tratar uma autorização concedida como prova sobre fundos e manter as três primeiras perguntas como factos distintos, registados em separado.
Reduzir as quatro a “o cartão passou” é o que empurra o risco para quem atendeu o cliente.
As quatro perguntas são: que agente fez isto, por quem agiu, o que lhe era permitido fazer e o que a própria autorização estabeleceu. São a formulação da Obenan para o problema de um operador, não uma sequência de protocolo. Servir o cliente é uma quinta coisa, inteiramente distinta, e nenhum pagamento a prova.
Cada pergunta é mais barata de responder antes de o dinheiro se mover do que depois. Quais delas uma dada encomenda consegue responder depende do prestador e do canal por onde chegou.
Onde isto se encaixa e onde não
Juntar estas fases num único acontecimento pode esconder onde está o risco. São sete, e cada uma pode acontecer sem a seguinte. O anúncio citado descreve um protocolo dirigido a duas delas — como fases que pretende suportar, não como fases que se tenha demonstrado que cumpre.
Descoberta orgânica
Um assistente, um mapa ou um resultado de pesquisa mostra o restaurante, sem que ninguém tenha pago por esse posicionamento.
Não abordada
Exposição paga
O restaurante aparece porque foi comprado um posicionamento. Aparecer não é ser escolhido.
Não abordada
Encaminhamento
Algo passa o cliente adiante — um clique, uma passagem para um canal de reservas, uma ligação direta para uma aplicação.
Não abordada
Contacto
Chega um pedido sobre o qual uma pessoa ou um sistema poderia agir: um pedido de mesa, um orçamento, um cesto retido.
Não abordada
Aprovação do cliente
Uma pessoa real concorda com esta compra concreta, a este preço, nas condições que viu. O protocolo pretende tornar isto examinável; a prova citada não mostra que o cumpra.
Objetivo do protocolo
Pagamento
O dinheiro é autorizado e liquidado. O protocolo pretende anexar um registo de quem estava a agir e em nome de quem; a prova citada não mostra qualquer registo desses em produção.
Objetivo do protocolo
Cumprimento
A mesa é reservada, o grupo chega, a comida é servida. Nada num protocolo de pagamentos prova que isto aconteceu.
Não abordada
- Objetivo do protocolo
- O anúncio descreve a intenção de transportar identidade e permissão junto com o pagamento. A intenção é o que a prova estabelece; o cumprimento não.
- Não abordada
- Se um agente encontra o restaurante, o recomenda, envia um cliente, ou se esse cliente é servido, decide-se noutro lugar.
FonteAnt International11 de setembro de 2026
O que esta prova não demonstra
Esta página assenta num anúncio de um único participante. Isso é boa prova de uma implementação anunciada e de uma intenção de a concretizar. Não é prova de nada a jusante, e lê-la assim é o erro que mais provavelmente custará tempo a um operador.
- Não mostra que algum comerciante tenha ativado isto, nem que uma carteira ou um adquirente nomeado tenha concluído a sua parte.
- O anúncio citado não reporta qualquer volume de transações. Não indica número de compras, valor nem crescimento, e nada disso deve ser inferido dos totais de contas de carteira.
- O anúncio citado nada reporta sobre se encomendas feitas desta forma foram servidas, canceladas ou contestadas.
- Não é uma declaração de disponibilidade universal. A prova citada estabelece apenas os participantes nomeados da Fase I; não estabelece que a opção venha a aparecer num dado processo de pagamento, num dado mercado ou para um dado comerciante.
- Não estabelece uma norma entre redes. O quadro Know Your Agent é descrito como uma colaboração que começou, sem especificação publicada, calendário ou verificação independente a acompanhá-la.
- Não estabelece qualquer efeito sobre fraude, estornos ou contestações. O anúncio citado não reporta dados de resultados desse tipo, e esta página não os procurou noutro lado.
Mantido dentro desse limite, o sinal continua útil: diz a um operador em torno de que pergunta um prestador está a construir, o que chega para nos prepararmos sem tratar um anúncio como uma infraestrutura acabada.
Independência
A Ant International, a Mastercard, a Visa e todas as carteiras e adquirentes nomeados nesta página são objeto de apuramento em fontes públicas. A Obenan não tem com nenhum deles parceria, apoio, certificação, piloto, integração ou acesso privilegiado, e esta página não o reclama. Tudo aqui provém do anúncio publicado listado em Fontes e não foi verificado de forma independente.
O que fazer a seguir
Nada disto exige um projeto. Exige saber as respostas antes de alguém as pedir sob pressão.
Faça ao seu prestador de pagamentos uma pergunta por escrito.
Se participa em trabalhos de identificação de agentes e que metadados lhe mostrará sobre um pagamento iniciado por um agente quando chegar um. Guarde a resposta; fica desatualizada depressa.
Descubra se já lhe chegam encomendas feitas por agentes.
Pergunte a cada canal de reservas, marketplace e prestador de pagamentos que metadados ao nível da encomenda disponibilizam — identificador de canal ou de origem, ID de cliente de API ou de integração, user-agent e classificação de bots, e qualquer indicador de agente ou automatização — e procure depois encomendas com essas marcas. Conte-as durante um mês antes de decidir que não importam.
Registe a aprovação separadamente do pagamento.
O sistema que guarda a encomenda deve conseguir dizer quem aprovou esta compra, e não apenas que um débito passou. São factos diferentes e serão contestados em separado.
Dê aos responsáveis uma regra para a encomenda ambígua.
Uma linha chega: o que aceitar, o que confirmar com uma pessoa e a quem escalar. A coerência entre espaços vale mais do que o limiar exato.
Mantenha corretos os dados que um agente lê sobre cada espaço.
Horário, morada, área de serviço, ementa e rigor dos preços são aquilo sobre o que um agente comprador age. Isto é trabalho de descoberta, não de pagamentos — mas é a parte que um operador controla hoje.
Volte a olhar quando for publicada uma norma, não quando for anunciada uma.
O que há a esperar é um quadro Know Your Agent com especificação publicada e adotantes nomeados na sua própria infraestrutura — não mais declarações de intenção.
Se amanhã chegar a um dos seus balcões uma encomenda feita por um agente, a pergunta útil já não é “o cartão passou?”. É “o que é que este pagamento nos disse sobre quem está a comprar, e registámo-lo?”.
Ler a seguir
O pagamento é a última fase. Os dados que um agente lê antes sequer de chegar a um pagamento são a parte que um comerciante controla hoje.
Porque é que os dados publicados pelo próprio comerciante têm de estar corretos antes de os pagamentos por agentes contaremHorário, disponibilidade, condições e preço são aquilo sobre o que um agente comprador age. Este briefing expõe porque é que essa camada decide o resultado muito antes de entrar em jogo qualquer infraestrutura de pagamentos.Fontes
Uma fonte primária, citada para cada número desta página. Os números e as listas de participantes são os publicados pela parte que fez o anúncio e não foram verificados de forma independente.