x402 e pagamentos entre máquinas em 2026: cobrar aos agentes de IA por pedido e quanto disto é real

O HTTP tem um código de estado para isto desde os primeiros tempos da web. A RFC 9110 continua a dizê-lo sem rodeios: «O código de estado 402 (Payment Required) está reservado para utilização futura.» Em 2026, dois protocolos tentam fazer esse futuro chegar. O x402, iniciado pela Coinbase e hoje gerido por um projeto da Linux Foundation, responde a um pedido com um preço e aceita um pagamento assinado em stablecoin na nova tentativa. O Machine Payments Protocol (MPP), da Stripe e da Tempo, faz o mesmo através dos cabeçalhos de autenticação do HTTP e aceita cartões, além de stablecoins. A AWS e a Cloudflare vendem agora as duas ideias no edge, pelo que um editor pode cobrar aos crawlers de IA sem tocar na sua origem.

A proposta é atraente para quem vende dados, uma API ou conteúdos que os agentes de IA leem: cobrar por chamada, liquidar em segundos, sem contas nem faturas. Os números por trás da proposta são outra conversa. Uma medição independente do x402 na Base concluiu que a maior parte das liquidações registadas são autopagamentos ou dinheiro que circula dentro de um único conjunto de carteiras, e uma empresa de análise de blockchain situou o volume com aspeto de agentes a comprar em cerca de USD 5 000 a 11 000 por mês em 2026.

Este artigo destina-se a responsáveis e programadores de APIs, serviços de dados e sites de conteúdos que estão a decidir se devem cobrar já aos agentes. Explica como funcionam os protocolos, o que cada fornecedor oferece a 22 de outubro de 2026, o que teria de desenvolver, o que os volumes mostram realmente e as questões regulamentares que acompanham a detenção de stablecoins.

Como funciona o x402

A especificação está na versão 2, de 9 de dezembro de 2025, num repositório que passou da Coinbase para a x402 Foundation. Define três papéis: um servidor de recursos que quer ser pago, um cliente (muitas vezes um agente) que paga e um facilitador que «trata da verificação do pagamento e da liquidação na blockchain».

Um pedido pago decorre assim:

1. O cliente pede o recurso e recebe 402 Payment Required. Um cabeçalho PAYMENT-REQUIRED transporta um objeto codificado em Base64 que lista uma ou mais formas aceitáveis de pagar, cada uma com um scheme, uma network em formato CAIP-2 (eip155:8453 é a Base), um amount nas unidades mais pequenas do token, um asset, um endereço payTo e um maxTimeoutSeconds.
2. O cliente assina um pagamento e repete o pedido com um cabeçalho PAYMENT-SIGNATURE. Nas cadeias EVM, trata-se de uma assinatura EIP-712 sobre uma autorização de transferência EIP-3009, com uma janela temporal e um nonce de 32 bytes contra a repetição (replay).
3. O servidor pede ao facilitador que verifique a assinatura (POST /verify, que «NÃO PODE confirmar o estado do pagamento»), executa o seu tratador e depois pede ao facilitador que liquide (POST /settle).
4. O servidor responde com o recurso e um cabeçalho PAYMENT-RESPONSE que contém o hash da transação.

Esse é o fluxo de «autorização» por omissão: «o pagamento é verificado antes de o recurso ser executado e liquidado depois». Estão definidos outros dois fluxos, um que liquida primeiro e outro que recebe um depósito e liquida o montante final depois. Se uma liquidação foi difundida mas não confirmada, o facilitador pode devolver settlement_pending com o hash, e o servidor deve reconciliar antes de alguém tentar de novo.

Há dois pormenores que apanham as pessoas desprevenidas. A versão 1, que a maioria dos tutoriais mais antigos mostra, usava X-PAYMENT e X-PAYMENT-RESPONSE e nomes de rede como base-sepolia; a versão 2 mudou o nome dos cabeçalhos e passou a CAIP-2. E as mesmas mensagens estão definidas sobre o MCP e sobre o protocolo Agent-to-Agent (A2A): sobre o MCP, uma ferramenta paga devolve um resultado com isError: true e o pagamento viaja em _meta["x402/payment"].

Os quatro esquemas de pagamento

Nas cadeias EVM, qualquer token ERC-20 funciona em princípio, através do EIP-3009 (o método do USDC) ou do Permit2. Na prática, os SDKs de referência fixam os preços em dólares e associam "$0.01" a uma stablecoin em USD por rede: USDC na Base e na maioria das cadeias EVM, várias stablecoins na Solana, USDT na TON. O cliente de referência só aceita ativos que reconhece e limita cada pagamento a USD 1 por omissão. Não há nenhuma predefinição em euros.

Facilitadores: quem move o dinheiro

O facilitador é «opcional mas recomendado». Verifica assinaturas e submete a transferência on-chain, e a documentação diz que «não detém fundos nem atua como depositário»: o dinheiro chega à sua carteira payTo.

• O facilitador público x402.org serve apenas para testnets. O arranque rápido para vendedores é explícito: «Não reutilize https://x402.org/facilitator em rotas de mainnet.»
• O facilitador CDP alojado da Coinbase não cobra nada pelas primeiras 1 000 transações on-chain por mês e depois cobra USD 0,001 por transação, sendo a verificação sempre gratuita. Faz verificações OFAC e Know Your Transaction a cada pagamento, exige uma chave de API da CDP e suporta Base, Polygon, Arbitrum, Monad, World e Solana. Não lista o auth-capture. A liquidação em lote dilui a taxa: «uma única transação on-chain pode processar milhares de pagamentos».
• A fundação lista outros facilitadores de produção, entre os quais Fireblocks, Polygon, PayAI, Corbits, Stellar e Celo, e diz que a lista não é «um catálogo exaustivo».
• Pode ser o seu próprio facilitador, pagando o gas e, na Solana, desenvolvendo a deteção de liquidações duplicadas que um facilitador forneceria de outro modo.

A x402 Foundation entrou em funcionamento a 14 de julho de 2026 com 40 membros. Entre os membros premier contam-se a Adyen, a AWS, a American Express, a Cloudflare, a Coinbase, a Google, a Mastercard, a Shopify, a Stripe e a Visa; o seu comité técnico de direção tem membros da Coinbase, da Cloudflare e da Stripe. Ser membro é apoiar a governação, não é uma implementação. O comunicado de lançamento menciona «suporte para tipos de pagamento que vão dos cartões tradicionais às stablecoins», mas a especificação não tem hoje nenhum binding para cartões.

O Machine Payments Protocol da Stripe e a Tempo

A Stripe e a Tempo lançaram o MPP a 18 de março de 2026, o dia em que a mainnet da Tempo entrou em funcionamento. Usa a framework de autenticação do HTTP: um 402 com um desafio WWW-Authenticate: Payment, uma credencial em Authorization: Payment e um cabeçalho Payment-Receipt em caso de sucesso. Os seus intents são charge (um pagamento), session (pagamento em fluxo contínuo sobre um canal) e subscription, e os seus métodos de pagamento em produção são as stablecoins da Tempo e os métodos de cartão da Stripe. A Visa publicou nesse mesmo dia uma especificação de cartões e um SDK para o MPP. O documento do IETF que está por trás é um Internet-Draft individual que «não tem estatuto formal no processo de normalização do IETF».

Na Stripe, o MPP aceita cartões (através de Shared Payment Tokens) e stablecoins, e a Stripe também aceita pagamentos em stablecoin x402 na Base, liquidados através do facilitador da Coinbase para um endereço de depósito da Stripe. De qualquer modo, o resultado chega ao seu saldo Stripe como um PaymentIntent, e as stablecoins enviadas para um endereço de depósito são convertidas: «A Stripe faz automaticamente o offramp destes pagamentos e liquida-os no seu saldo Stripe.» As condições:

• A aceitação de stablecoins está «disponível para empresas em todos os estados dos EUA, exceto Nova Iorque». Noutros locais, envia-se um email à Stripe a pedir acesso, que é analisado; a UE, Hong Kong, o México e a Suíça estão em pré-visualização privada.
• Os mínimos são USD 0,50 para um pagamento com cartão e 0,01 USDC para um pagamento em stablecoin. As sessões MPP podem cobrar em incrementos «tão pequenos como 0,000001 USDC», mas liquidam em cêntimos inteiros, e um resto inferior a um cêntimo perde-se.
• Os pagamentos em stablecoin na Stripe não têm suporte para disputas, os reembolsos regressam sob a forma de stablecoins à carteira original e uma única transação tem o limite de USD 10 000.
• As APIs são versões de pré-visualização (2026-07-29.preview para o MPP, 2026-05-27.preview para o endereço de depósito x402).

O Intelligent Commerce Connect da Visa, anunciado a 8 de abril de 2026 como piloto, lista o MPP entre os protocolos de agentes que os comerciantes podem aceitar através dele. Não lista o x402.

Cobrar no edge: AWS e Cloudflare

Se o seu conteúdo ou a sua API já estão atrás de uma CDN, o edge pode tratar da cobrança.

O AWS WAF AI traffic monetization (anunciado a 15 de junho de 2026) devolve «uma resposta HTTP 402 Payment Required legível por máquinas, com o protocolo aberto x402» a bots e agentes, e liquida através do facilitador da Coinbase para uma carteira USDC que indica, na Base ou na Solana. A funcionalidade não tem custo adicional, mas aplicam-se as taxas normais do WAF e do Bot Control, e só funciona com o CloudFront. Pode fixar preços diferentes para os crawlers de pesquisa verificados e para os agentes não verificados e os crawlers de treino, e testar antes de entrar em produção. Só liquida quando a sua origem devolve um 2xx e não cobra por 4xx nem 5xx. A documentação é franca quanto aos custos: um mínimo de USD 0,001 por pedido, «vários segundos de latência adicional» nos pedidos pagos, uma deteção de bots que é «probabilística» e um aviso de que uma regra Monetize que não se limite a bots «bloqueará efetivamente o acesso a clientes não automatizados». «A AWS não é parte nem intervém no fluxo de fundos», e concorda com os termos da Coinbase. O suporte para liquidação através da Stripe e para o MPP estava «em breve» no momento do anúncio.

O pay per crawl da Cloudflare é um modelo diferente. Está em beta fechado, o seu domínio tem de estar na Cloudflare, fixa um único preço para todos os crawlers a que cobra e a Cloudflare «atua como Merchant of Record» (quem vende em nome próprio e responde pela venda). Os crawlers identificam-se com o Web Bot Auth e pagam por fatura da Stripe, não a partir de uma carteira. Nunca toca em stablecoins.

Os Cloudflare Workers podem pôr um proxy x402 ou MPP à frente de qualquer backend HTTP, com preço por padrão de rota, e podem cobrar apenas pedidos com uma pontuação de bot baixa, para que as pessoas naveguem de graça. O Agents SDK tem paidTool, que transforma uma ferramenta MCP numa ferramenta paga. Note que os exemplos da Cloudflare usam o facilitador x402.org, orientado para testnets, e nomes de rede da versão 1; em produção, troque-os por um facilitador de produção e identificadores CAIP-2.

Quanto disto é real

Os números de destaque são grandes e não coincidem entre si. A página inicial do x402.org mostra 75,41 milhões de transações e USD 24,24 milhões nos últimos 30 dias, sem data, fonte nem método na página. A Coinbase diz que o seu facilitador processou «mais de 100 milhões de transações e 28 milhões de dólares em volume de pagamentos só na Base e na Solana», sem indicar o período. São contagens de liquidações, e esse é o problema.

Um estudo de medição de investigadores da City University of Hong Kong, da Chinese University of Hong Kong e da Universidade de Zhejiang (um preprint, publicado a 14 de julho de 2026) analisou 280 dias de x402 na Base, de 17 de setembro de 2025 a 23 de junho de 2026: 136 708 672 liquidações no valor de USD 44,1 milhões. Destas, «21,20 % são fictícias e 63,78 % são liquidações internas dentro de um cluster ligado». O valor que «chega de forma demonstrável a um serviço identificável» foi de USD 187 861,35. Dos 624 destinatários que alguma vez foram pagos, 249 ganharam pelo menos USD 10, a mediana da receita ao longo da vida foi de USD 3,96 e apenas 474 dos 910 anfitriões anunciados ainda devolviam um desafio de pagamento ativo. A conclusão dos autores: «A contagem de liquidações mede a possibilidade de as fabricar, não a adoção.»

A TRM Labs, que vende monitorização de blockchain, contou USD 52,7 milhões em 198,9 milhões de liquidações na Base, na Solana e na Polygon desde maio de 2025. Cerca de metade desapareceu depois de retirados os autopagamentos, os fluxos em bloco e os vendedores com poucos compradores. Dos USD 25,62 milhões que restaram, estimou que entre 0,6 % e 7,5 % «parecem ser agênticos» e que o volume movimentado por agentes se manteve em cerca de USD 5 000 a 11 000 por mês ao longo de 2026. A sua leitura para os vendedores é útil: «atrair tráfego de agentes exige um desenho diferente. Tem de ser legível por máquinas e ter preços por chamada num endpoint que um comprador consiga descobrir sem que um humano alguma vez veja a página.»

Nada disto diz que a ideia está errada. Diz que, em outubro de 2026, um endpoint que cobre aos agentes por chamada deve esperar receitas da ordem de uma experiência e que não se deve planear em função das contagens de destaque.

Quem detém o dinheiro e que regras se aplicam

Com o x402, o pagamento vai diretamente para a sua carteira. Isso significa que a sua empresa detém as chaves, tem USDC na contabilidade e converte-o para a sua própria moeda, a menos que um fornecedor como a Stripe o converta por si. O rastreio do facilitador (as verificações OFAC e KYT da Coinbase) é algo que o facilitador faz; a especificação x402 não define nenhum. Os reembolsos ficam por sua conta: o exact «não define nenhum reembolso», e os pagamentos em stablecoin da Stripe não têm disputas.

Dois regimes são relevantes para quem se encontra no fluxo de fundos.

• Estados Unidos: o GENIUS Act. A Lei Pública 119-27, aprovada a 18 de julho de 2025, entra em vigor 18 meses após a promulgação ou 120 dias após os regulamentos finais, consoante o que ocorrer primeiro. A proposta de regra do Tesouro dos EUA, de 18 de agosto de 2026, diz que a data de entrada em vigor «deverá ser 18 de janeiro de 2027». A partir dessa data, um prestador de serviços de ativos digitais não pode disponibilizar nos EUA a stablecoin de um emitente estrangeiro, a menos que o emitente possa cumprir ordens legais. A partir de 18 de julho de 2028, um prestador de serviços de ativos digitais não pode oferecer nem vender uma stablecoin de pagamento a uma pessoa nos EUA, a menos que tenha sido emitida por um emitente autorizado. A lei define um prestador de serviços de ativos digitais por atividades como trocar, transferir ou deter ativos digitais por conta de terceiros, feitas «mediante remuneração ou com fins lucrativos».
• União Europeia: o MiCA. O período transitório para os prestadores de serviços de cripto-ativos terminou a 1 de julho de 2026. A declaração da ESMA: «qualquer entidade que preste serviços de cripto-ativos a clientes da UE sem licença MiCA estará em violação do direito da UE e tem de deixar de oferecer esses serviços», e as empresas de fora da UE não podem servir clientes da UE, «também ... num contexto entre empresas». As stablecoins em USD são tokens de moeda eletrónica ao abrigo do MiCA. O conselho da ESMA aos utilizadores é que verifiquem se um prestador consta do seu registo provisório.

O que nenhuma destas fontes esclarece é a posição de uma empresa que apenas recebe stablecoins como pagamento da sua própria API ou dos seus conteúdos. As restrições do GENIUS Act foram escritas para prestadores de serviços de ativos digitais, e as do MiCA para prestadores de serviços de cripto-ativos; saber se o seu arranjo faz de si um deles, ou depende de fornecedores que têm de o ser, é uma questão para um advogado em cada jurisdição onde opera. Somos engenheiros, não advogados, e desenvolvemos de acordo com a resposta que o seu consultor der. Na prática, pergunte a cada fornecedor da sua cadeia se tem licença onde estão os seus clientes.

Quatro maneiras de o desenvolver

Do menos código para o mais:

1. Deixe a CDN cobrar. O AWS WAF no CloudFront: uma configuração de monetização com a sua carteira e os seus preços, regras Monetize limitadas a etiquetas de bots, modo de teste primeiro, sem alterações à origem. O pay per crawl da Cloudflare: se estiver no beta, um preço e as definições de pagamento, com a Cloudflare como merchant of record.
2. Deixe um fornecedor de pagamentos cobrar. O MPP da Stripe: um perfil Stripe, a biblioteca mppx, uma chamada charge no seu tratador e um endereço de depósito Tempo. Cartão e stablecoin, liquidados em moeda fiduciária no seu saldo Stripe. Ou o x402 na Stripe, com uma conta CDP e um endereço de depósito na Base, apenas stablecoin.
3. Execute o x402 no seu próprio servidor com o middleware do SDK para a sua framework (Express, Hono, Next.js, Fastify; existem SDKs de Python e Go), um facilitador alojado e uma configuração de rota com esquema, preço, rede, payTo e descrição.
4. Seja o seu próprio facilitador, se precisar de controlo total ou de uma rede que ninguém serve.

Qualquer que seja o caminho, algumas decisões continuam a ser suas: que esquema serve o trabalho (exact para preços fixos, upto para trabalho medido, liquidação em lote quando as chamadas valem menos do que o gas), quem vê o paywall (um 402 mostrado a um utilizador num navegador é um beco sem saída), como reconcilia o settlement_pending, as repetições idempotentes se os clientes enviarem um identificador de pagamento, os reembolsos, a custódia da carteira de receção e como contabiliza os recebimentos em USDC. Os agentes também têm de conseguir pagar: um cliente x402 precisa de uma carteira com a stablecoin certa na rede certa, um cliente MPP de uma carteira Link ou Tempo, um crawler do pay per crawl de uma identidade Web Bot Auth e de uma relação de faturação com a Stripe. Não pode presumir que um dado agente tem alguma destas coisas.

Deve cobrar aos agentes já?

• Vende uma API ou dados que os agentes já chamam: uma experiência é barata. Ponha um ou dois endpoints atrás do MPP ou do x402, a par das suas chaves e planos existentes, fixe preços acima dos mínimos (USD 0,001 na AWS, 0,01 USDC na Stripe) e meça quem paga. Mantenha os planos pagos existentes: o canal de pagamentos de agentes será pequeno por agora.
• Publica conteúdos que os crawlers de IA já leem: as opções no edge existem para isto. O AWS WAF, se estiver no CloudFront e se sentir à vontade a deter USDC; o pay per crawl da Cloudflare, se estiver na Cloudflare, quiser liquidação por cartão e conseguir entrar no beta. Nenhum é ainda um plano de receitas; ambos lhe dão um preço e um registo de quem se recusou a pagá-lo.
• Quer que os agentes comprem bens na sua loja: não é este o problema. As redes de cartões, os Shared Payment Tokens da Stripe e os protocolos de checkout da Google e da OpenAI cobrem os agentes que compram a comerciantes, e tratamo-los no nosso artigo sobre pagamentos agênticos.

O que pode mudar

• A entrada em vigor do GENIUS Act a 18 de janeiro de 2027 (mais cedo, se os regulamentos finais chegarem primeiro), e a restrição de 2028 que se lhe segue.
• A AWS acrescentar a liquidação através da Stripe e o MPP, anunciados como «em breve».
• O auth-capture amadurecer, o que daria ao x402 reembolsos fora dos drafts.
• O Internet-Draft do MPP avançar, ou não, para um grupo de trabalho do IETF.
• O Intelligent Commerce Connect da Visa alargar-se para lá dos seus parceiros piloto, o que levaria os pagamentos de agentes financiados por cartão a mais comerciantes através do MPP.

Onde obter ajuda

Desenvolvemos o lado do servidor do acesso pago por máquinas: medição e preços por endpoint, desafios x402 ou MPP à frente de APIs e ferramentas MCP existentes, reconciliação das liquidações nos sistemas que a sua equipa financeira já usa e a identificação de bots que decide quem vê um preço. O nosso serviço de desenvolvimento de agentes de IA e integração de servidores MCP é onde esse trabalho começa.

Se está a ponderar se deve cobrar aos agentes pela sua API ou pelos seus conteúdos, e através de que fornecedor, escreva para office@c9group.dev.