O comércio agentic desbloqueará uma pilha de pagamentos de duas camadas para transações nativas de IA?

À medida que as transacções nativas de IA passam do conceito à implementação, o comércio agentic está a forçar uma reformulação fundamental de como funcionam as infra-estruturas de pagamentos digitais e de liquidação.

De pagamentos centrados no ser humano a vias nativas de IA

Entre setembro de 2025 e março de 2026, todos os principais intervenientes nos pagamentos globais avançaram para um comércio orientado por IA. A OpenAI e a Stripe lançaram o Agentic Commerce Protocol, enquanto a Google revelou o Universal Commerce Protocol a mais de 30 parceiros de retalho e fintech.

No mesmo período, a Visa e a Mastercard lançaram frameworks de pagamento focados em agentes. A Coinbase avançou com o seu padrão x402, liquidando mais de 15 milhões de transacções na Base. Além disso, a Stripe e a Tempo co-autoraram o Machine Payments Protocol e submeteram-no para normalização na IETF.

O timing não é acidental. A infra-estrutura de pagamentos das últimas três décadas foi construída para humanos a utilizarem browsers, a preencherem formulários e a passarem por verificações faseadas. Contudo, os agentes de IA precisam de interfaces programáticas, autorização quase instantânea e liquidações que consigam lidar com transacções em fracções de um cêntimo.

A stack existente nunca foi concebida para esse ambiente, e a indústria reconhece o desajuste. O que está a emergir, em vez disso, é uma arquitectura em dois níveis: uma camada superior de orquestração para descoberta e iniciação, e uma camada inferior de liquidação para transferência de valor. Estas evoluirão em trajectórias separadas, impulsionadas por incentivos diferentes.

Orquestração comercial: como as transacções de agentes se juntam

A camada de orquestração define como um agente encontra um serviço, gere uma sessão e faz a transferência para o pagamento. Surgiram duas categorias distintas de casos de uso, e confundi-las arrisca mal-entender a estrutura do mercado.

1.1 Agentes a agir em nome dos consumidores

Para agentes que compram em nome de humanos, o principal problema hoje não são os mecanismos de pagamento, mas o acesso. A maioria das plataformas de e-commerce é optimizada para navegação humana. No entanto, um agente não deve percorrer páginas de produtos, interpretar banners, nem clicar num botão “adicionar ao carrinho”.

Em vez disso, os comerciantes precisam de endpoints estruturados e legíveis por máquina. Estes ainda são raros, o que limita interacções nativas com agentes. A primeira vaga de protocolos neste segmento surge da OpenAI, Stripe e Google, cada um com uma abordagem diferente para controlo e abertura.

A OpenAI e a Stripe lançaram o Agentic Commerce Protocol (ACP) em setembro de 2025. O protocolo centra-se na delegação de pagamentos segura no checkout: o método de pagamento de um utilizador é guardado no ChatGPT e, após a confirmação da compra, a Stripe emite um Shared Payment Token (SPT), uma credencial de utilização única limitada ao comerciante e ao total do carrinho.

Este token é entregue ao comerciante via API, que mantém o estatuto completo de Merchant of Record e processa o pagamento através da infra-estrutura Stripe existente. O SPT da Stripe é, nesta data, a primeira implementação em produção desta arquitectura de delegação e é compatível com a Delegated Payment Spec da OpenAI. Outros PSPs podem implementar a especificação, tornando o ACP aberto na camada de pagamento.

O ChatGPT Instant Checkout foi lançado em setembro de 2025 para utilizadores nos EUA, mas foi encerrado em março de 2026 após conversão praticamente nula. Desde então, a OpenAI mudou para a descoberta: o ChatGPT agora apresenta produtos e redirecciona os utilizadores para sites ou aplicações de comerciantes para o checkout. O ACP sobrevive num papel mais estreito, impulsionando aplicações dedicadas no próprio ChatGPT para um pequeno conjunto de grandes retalhistas.

Os comerciantes têm de se candidatar para participar, e a OpenAI controla quais aparecem e com que ranking. Dito isto, este modelo curado dá à OpenAI controlo ponta a ponta da experiência dentro do assistente, enquanto delega a liquidação para processadores terceiros como a Stripe.

O Universal Commerce Protocol (UCP) da Google representa uma estratégia contrastante. Anunciado por Sundar Pichai na conferência NRF a 11 de janeiro de 2026, o UCP foi desenvolvido em conjunto com a Shopify, Etsy, Wayfair, Target e Walmart, e foi endossado por mais de 20 parceiros, incluindo Adyen, American Express, Best Buy, Mastercard, Visa, Stripe e The Home Depot.

O UCP está explicitamente alinhado com o protocolo de pagamentos de agentes da própria Google (AP2), a norma Agent2Agent (A2A) e o Model Context Protocol (MCP). Este impulso de interoperabilidade é uma tentativa deliberada de ocupar o terreno elevado em indexação e acesso. O Google Pay funciona como método de pagamento predefinido, com PayPal anunciado como opção futura.

Tecnicamente, o UCP opera através de um ficheiro de manifesto de capacidades conhecido como um UCP profile. Os comerciantes publicam um documento JSON estruturado em /.well-known/ucp no seu domínio, especificando métodos de transporte, capacidades de checkout e processadores de pagamento suportados. Os agentes lêem estes manifests directamente, sem intermediários.

A arquitectura reflecte prioridades estratégicas da Google. A Google tem pouco interesse em servir de intermediário em transacções, o que introduziria pressão de margens, responsabilidades e escrutínio regulatório. Em vez disso, quer visibilidade total sobre a teia do comércio. O UCP posiciona o Gemini como a camada primária de descoberta para compras com agentes, mantendo-se maioritariamente invisível na liquidação.

O contraste com o ACP é nítido. O ACP é um ambiente curado em que a OpenAI actua como gatekeeper; os comerciantes têm de se candidatar, e o fluxo é optimizado dentro do ChatGPT. O UCP funciona como um catálogo aberto: os comerciantes publicam por si próprios, qualquer agente compatível pode consumir os perfis, e a Google controla a superfície de descoberta, mas não o pagamento em si.

O atrito de onboarding é menor e o alcance potencial é mais amplo com o UCP, mas os comerciantes recebem menos acompanhamento directo. Na prática, o ACP troca abertura por controlo, enquanto o UCP troca controlo por maior amplitude de índice e normalização a nível de protocolo.

1.2 Agentes a transaccionar com outros agentes

A segunda grande categoria é estruturalmente diferente: ambos os lados da transacção são agentes autónomos, e nenhum comerciante humano participa. Neste ambiente, os tradicionais pilares de confiança desaparecem, deixando poucos protecções familiares.

Não existem estatutos de protecção do consumidor nem direitos de chargeback de cartões para se apoiar. Além disso, as partes podem nunca ter interagido antes, e no entanto têm de trocar valor com segurança. Este é o problema que novas normas da Ethereum estão a tentar endereçar.

Proposto a 10 de março de 2026 pela equipa dAI da Ethereum Foundation em conjunto com a Virtuals Protocol, o ERC-8183 estrutura cada transacção como um trabalho de três partes. Um Client encomenda o trabalho, um Provider entrega-o, e um Evaluator certifica a conclusão.

Os fundos são mantidos em escrow de smart contract e libertados apenas quando o Evaluator dá sinal verde. Nem o Client nem o Provider precisam de avaliar a fiabilidade um do outro; o contrato impõe o resultado de forma mecânica. Em paralelo, o ERC-8004 define a camada de identidade que sustenta este mecanismo.

Sob o ERC-8004, os agentes registam-se on-chain e constroem uma pontuação de reputação a partir do histórico de transacções. Isto cria um sinal portátil de credibilidade que persiste ao longo das interacções. O desenho é robusto em teoria; no entanto, fazer a adopção avançar à escala continua a ser o gargalo prático.

Hoje, a maior parte do uso real está concentrada dentro da plataforma da Virtuals Protocol. Um agente orquestrador chamado Butler decompõe tarefas complexas em sub-jobs e encaminha-as para agentes especialistas. A comunidade alargada de programadores ainda não se envolveu a uma escala comparável. O ERC-8183 é, na prática, uma tentativa de tornar este padrão aberto e sem permissões.

Segue-se directamente um ponto estrutural. O e-commerce retalhista consegue operar com tranquilidade em vias de cartão, porque os compradores humanos continuam no circuito. A contrapartida, o comércio puro de agente para agente, provavelmente exigirá liquidação com stablecoin, já que as taxas de cartões se tornam pouco económicas em tamanhos de transacção muito pequenos e com alta frequência.

Protocolos de liquidação: quem realmente move o dinheiro

Se a orquestração decide o quê e onde transaccionar, a camada de liquidação determina se o valor é efectivamente transferido. Agora há cinco grandes protocolos a competir aqui, cada um afinado para diferentes casos de uso e restrições económicas.

2.1 Delegated Payment Spec e SPT (Stripe)

A Delegated Payment Spec da Stripe estende a infra-estrutura de cartões em vez de a substituir. Quando um cliente autoriza um agente, a Stripe provisiona um SPT que o agente armazena. No momento da transacção, o agente apresenta este token limitado no tempo e com valor máximo ao comerciante.

A liquidação é então executada através da stack de cartões existente da Stripe. No back end, a Stripe liga-se ao Visa Intelligent Commerce e ao Mastercard Agent Pay, que emitem tokens de rede agentic. Os comerciantes veem uma única superfície de integração, independentemente da rede de cartões por baixo.

Este modelo é bem adequado para compras retalhistas padrão e para muitas transacções de alto valor de agente para agente, em que chargebacks e outras protecções do consumidor continuam a ser desejáveis. No entanto, é uma má opção para padrões de micro-valores com alta frequência, como pagamentos de streaming de máquina para máquina.

Nesses cenários, os valores das transacções são frequentemente fracções de um cêntimo, e os volumes podem chegar a milhares de operações por minuto. A economia de taxas de cartões e a sobrecarga de autorização tornam-se rapidamente insustentáveis, mesmo que seja tecnicamente possível.

2.2 Visa Intelligent Commerce e tokens agentic da Mastercard

Tanto a Visa como a Mastercard refizeram as suas camadas de tokenização para lidar com pagamentos iniciados por agentes. Números reais de cartões são substituídos por tokens dinâmicos encriptados que incorporam metadados sobre o agente que autoriza, desde a identidade até limites de gasto e janelas de validade.

Os comerciantes permitidos também são especificados nos metadados do token, permitindo controlos detalhados sobre onde os agentes podem pagar. A liquidação em si permanece nas vias legadas de cartão, o que mantém caminhos de integração familiares e evita totalmente nova infra-estrutura.

Ambas as redes avançaram bem além de prova de conceito. A Mastercard processou a primeira transacção de agente totalmente identificada em setembro de 2025, em conjunto com a Commonwealth Bank na Austrália. A Visa concluiu implementações iniciais em mercados europeus através do seu programa Agentic Ready.

A infra-estrutura aparenta ser capaz, mas o patamar de taxas é uma limitação estrutural. Nenhuma rede consegue suportar eficientemente pagamentos abaixo de 1 dólar na densidade que o futuro comércio de agentes pode exigir. Além disso, camadas regulatórias e de conformidade restringem ainda mais a experimentação na ponta do espectro em que os tickets são extremamente pequenos.

2.3 x402 (Coinbase)

O x402, por contraste, começa no HTTP em vez de cartões. Constrói-se com base no código de estado 402 “Payment Required”, que existe na especificação HTTP desde 1997, mas foi usado apenas com pouca frequência. Quando um agente solicita um recurso pago, o servidor responde com um 402 que contém parâmetros de pagamento.

O agente assina uma autorização, e um Facilitator completa uma liquidação atómica on-chain em USDC ou noutros tokens suportados, tipicamente em cerca de dois segundos. Não há configuração de conta, distribuição de chave de API, nem imposição de KYC a nível de protocolo. A governação reside na x402 Foundation, estabelecida pela Coinbase e pela Cloudflare.

No final de 2025, o x402 já tinha processado mais de 100 milhões de transacções em Base, Solana e Polygon. No entanto, analistas da Artemis, a escrever em fevereiro de 2026, estimaram que grande parte desse volume reflecte auto-negócio e testes de infra-estrutura, em vez de comércio genuíno.

O volume de pagamentos anualizado do protocolo fica em torno de 600 milhões de dólares, mas a concentração e as questões de qualidade do volume são relevantes. Ainda assim, o x402 não enfrenta um patamar de taxas estrutural; foi concebido explicitamente para micropagamentos. A principal lacuna é a profundidade de adopção e a densidade do comércio real no mundo, não o desenho técnico.

2.4 Nanopayments (Circle)

O protocolo Nanopayments da Circle é intencionalmente compatível com o x402, usando o HTTP 402 como gatilho enquanto adiciona uma camada de liquidação em lote. Em vez de liquidar cada pagamento on-chain individualmente, os compradores pré-financiam uma conta Circle Gateway e assinam mensagens off-chain EIP-3009 para cada transacção.

A liquidação periódica em lote para a blockchain distribui o custo de gas por muitos pagamentos, tornando transferências tão pequenas como 0,000001 dólares economicamente viáveis. O gas é efectivamente pago uma vez no depósito, e não por pagamento, uma optimização crucial para casos de uso de ultra-alta frequência.

O trade-off é que ambas as contrapartes devem depositar na Circle Gateway, criando uma rede semi-fechada na arquitectura actual. O Nanopayments foi lançado em testnet em março de 2026 em 12 cadeias suportadas. Além disso, o modelo de taxas é atraente para fluxos intensivos de micro-pagamentos se a Circle conseguir reduzir o atrito de onboarding.

2.5 MPP Machine Payments Protocol (Tempo e Stripe)

O MPP, co-autoria de Tempo e Stripe, é o mais ambicioso dos cinco desenhos de liquidação. Usa HTTP 402 como gatilho e permite que comerciantes e agentes escolham entre múltiplas vias de liquidação dentro de um quadro unificado.

Os programadores já não precisam de “hard-wire” qualquer infra-estrutura de stablecoin ou fiat no momento de construção. Em vez disso, o agente pode decidir em tempo de execução qual via usar com base nas necessidades da transacção. As opções disponíveis incluem liquidação com stablecoin da Tempo, pagamentos com Stripe SPT, tokens de redes de cartões e pagamentos de Bitcoin Lightning impulsionados pelo Lightspark.

O mais importante é que o MPP introduz uma primitiva de “sessão” semelhante ao OAuth. Um agente autoriza uma vez e pré-financia uma conta; em seguida, beneficia de liquidação automatizada em tempo real para interacções subsequentes sem uma transacção on-chain por pagamento.

A especificação central foi submetida à IETF como implementação de referência do HTTP 402. No lançamento a 18 de março de 2026, o Payment Directory principal já integrava mais de 100 serviços. Contudo, os padrões de adopção ainda estão numa fase inicial.

O papel duplo da Stripe é estrategicamente importante. Ela co-autorou o protocolo e também aparece como uma das opções de pagamento dentro dele, capturando valor quer os programadores escolham o MPP principalmente por flexibilidade, quer especificamente por capacidades de cartão.

Realidade do mercado: protocolos à frente da implantação

3.1 Onde o mercado está

Apesar de lançamentos rápidos de protocolos nos últimos seis meses, a tração comercial continua limitada. Na liquidação, o x402 lidera em número de transacções, mas o volume diário real de comércio ronda perto de 28 mil dólares. Na orquestração, o Instant Checkout do ACP foi encerrado após conversões negligenciáveis.

Normas novas como o ERC-8183 e o MPP mostram um padrão semelhante: a narrativa ultrapassa a implantação efectiva. A indústria atingiu um ponto de inflexão em que grande parte da arquitectura de protocolo existe, mas a aplicação comercial escalada ainda não começou.

O principal obstáculo é a fragmentação na camada de orquestração. Os comerciantes enfrentam múltiplos padrões independentes, cada um com SDKs distintos, fluxos de autenticação e regras de conformidade. No entanto, isto aumenta os custos de integração e desencoraja a experimentação.

Historicamente, essa fragmentação é resolvida por uma camada de agregação que unifica o acesso entre padrões concorrentes. Este ciclo pode ser diferente. Plataformas com tráfego agentic relevante, incluindo OpenAI, Google e Microsoft, são incentivadas a manter superfícies fechadas em vez de transferir utilizadores para outros locais.

A mesma lógica está a desenrolar-se regionalmente. A China, Sudeste Asiático, Coreia e Japão estão, cada um, a desenvolver ecossistemas fechados em ciclo fechado, ancorados por super-apps ou plataformas dominantes. O resultado mais provável é um conjunto de sistemas fechados paralelos por região, e não uma única norma global aberta.

A camada de agregação que os comerciantes desejam é, portanto, mais provável que venha de fornecedores de infra-estrutura terceiros que atendem directamente os comerciantes, e não das plataformas que competem por controlar o tráfego de agentes. Os incentivos para abertura e alcance entre plataformas simplesmente não se alinham na camada de plataformas.

3.2 Onde estão as oportunidades de curto prazo

Deste panorama emergem dois conjuntos distintos de oportunidades: infra-estrutura de liquidação e serviços de agente para agente na camada de aplicação. A primeira parece ser o negócio mais certo no curto prazo, enquanto a segunda, embora menos desenvolvida, pode ser potencialmente a mais transformadora.

Na liquidação, a fragmentação na orquestração contrasta fortemente com a pressão de consolidação na camada de pagamento. Cada agente, independentemente da plataforma, enfrenta, no final, o mesmo problema: como pagar contrapartes de forma eficiente entre vias diferentes.

Os programadores não conseguem, realisticamente, manter integrações de pagamento separadas para cada superfície onde os seus agentes possam operar. À medida que as plataformas se multiplicam, a pressão económica intensifica-se em direção a uma integração de pagamento única e unificada que abstraia a complexidade subjacente da via.

Isto define um requisito de produto concreto para uma carteira multi-vias para agentes. Vias de cartões como SPT, tokens agentic da Visa e tokens agentic da Mastercard continuarão a suportar o comércio tradicional de comerciantes. Vias de stablecoin como pagamentos de sessão x402 e MPP vão ancorar APIs on-chain e transferências de agente para agente.

Ambas as categorias já estão em funcionamento e não vão convergir para uma única via no curto prazo. A carga de flexibilidade fica do lado do agente, e não do lado do comerciante. Os comerciantes escolhem quais vias suportar, uma decisão relativamente estável e controlável.

As empresas, então, providenciam aos seus agentes stablecoins e cartões delegados. O agente paga usando qualquer via que a contraparte aceite. Uma wallet que trate ambos de forma transparente, numa única integração, torna-se a camada habilitadora para agentes de propósito geral a operar em ecossistemas diversos.

Esse valor de integração acumula-se com cada transacção e com cada nova plataforma, criando profundidade de infra-estrutura difícil de substituir uma vez estabelecida. Além disso, posiciona o fornecedor da wallet como uma camada neutra de compensação entre ambientes de orquestração fragmentados.

Comércio de agente para agente: a oportunidade pouco desenvolvida

A segunda oportunidade situa-se na camada de aplicação do comércio de agente para agente. Hoje, a maior parte da actividade A2A permanece confinada a fluxos nativos de cripto: agentes consultando dados on-chain, interagindo com protocolos DeFi e executando transacções blockchain.

O mercado ainda não se expandiu para serviços amplos e reais no mundo. No entanto, do ponto de vista do protocolo, os agentes já poderiam encomendar tarefas como análise de dados, geração de conteúdo, pesquisa jurídica ou revisão de código, pagando por chamada.

A peça que falta é o ecossistema de programadores. Os construtores de serviços ainda não estão a empacotar ofertas como APIs pagáveis por agentes, com preços finamente calibrados por utilização. Essa é a verdadeira lacuna, e actualmente é uma das áreas menos contestadas na stack.

Este espaço é limitado por um problema de arranque a frio. Sistemas de identidade como o ERC-8004 exigem densidade significativa de transacções para gerar pontuações de confiança credíveis. Agentes sem histórico carecem de peso reputacional, o que limita contrapartes dispostas a transaccionar com eles.

A Microsoft projeta cerca de 1,3 mil milhões de agentes de IA activos até 2028. A base instalada actual é, em ordem de grandeza, muito menor. A lacuna não se fecha automaticamente; é precisamente isso que mantém a competição de curto prazo baixa e torna a tomada de posições iniciais atraente.

As implicações vão além dos pagamentos, estendendo-se a modelos de negócio. Os modelos dominantes na internet, publicidade e assinaturas, assumem compradores humanos. Os agentes não são persuadíveis por anúncios nem precisam de pacotes de acesso mensais; pagam pelo resultado de chamadas específicas.

Nesse contexto, pagamentos HTTP 402 criam um primitivo económico diferente. Os fornecedores vendem resultados em vez de acesso, cobram utilizadores intensivos em proporção ao consumo real e deixam de subsidiar utilizadores leves ou de sobreprovisionar para picos raros.

Se a economia A2A se expandir para além da cripto e se o HTTP 402 se tornar uma camada geral de preços para software, essa é, efectivamente, a mesma questão. Ambas dependem de agentes se tornarem actores económicos de rotina, transaccionando em escala contra directórios de serviços ricos, por chamada.

Conclusão: uma stack em dois níveis e as primitivas em falta

Olhando para o futuro, o comércio agentic continuará a evoluir em dois trilhos separados. Agentes voltados para consumidores, que compram bens para humanos, irão, na sua maioria, depender de vias de cartões, avançando ao ritmo dos frameworks de autorização empresarial e da confiança dos utilizadores em novas superfícies de pagamento.

Em paralelo, a stack de protocolos de comércio agentic para pagamentos de software para software já é tecnicamente viável em vias de stablecoin. Agora, aguarda a implementação de agentes e serviços que exijam liquidação programática de alta frequência, em escala.

O estado final provável é uma stack em dois níveis a evoluir em paralelo: uma camada de orquestração que governa a descoberta e a iniciação, e uma camada de liquidação que governa a transferência de valor. Para os construtores, a prioridade estratégica é a amplitude de integração em ambas as camadas.

Infra-estruturas capazes de encaminhar qualquer transacção de agente através do protocolo que a contraparte exigir, enquanto escondem essa complexidade das aplicações, ocuparão uma posição estruturalmente forte à medida que o mercado se expanda. Esta camada será invisível para os utilizadores finais, mas a sua importância continuará a crescer.

O gatilho para uma escala comercial não são protocolos melhores. É o momento em que as empresas delegam autoridade de gasto a agentes com trilhos auditáveis, controlos de orçamento e responsabilidade clara por compras mal direccionadas. Quando esse limiar for ultrapassado, duas posições de infra-estrutura tornam-se críticas.

Primeiro, uma carteira multi-vias para agentes que suporte tanto pagamentos em stablecoin quanto em cartão numa única integração. Segundo, um directório de serviços acessível por chamada que permita a programadores sem background em cripto expor APIs a compradores de agentes. Ambas são oportunidades abertas hoje, e ambas se tornam essenciais quando agentes com capacidade de gasto operam em escala.