Como agentes de IA pagam por eSIMs com x402 e stablecoins: o fluxo de conectividade pagável por máquinas

Dê a um agente de IA um navegador, um shell e um conjunto de chaves de API e ele consegue planejar, programar e chamar ferramentas o dia inteiro. Mas na primeira vez em que uma tarefa exige que ele pague por algo — um crédito de inferência, um dataset, um proxy, um SIM — ele trava. Os trilhos de pagamento humanos pressupõem um humano: uma página de checkout, um número de cartão, um prompt de 3-D Secure, um login. Agentes não têm nada disso. A distância entre "agente que consegue agir" e "agente que consegue transacionar" é o maior gargalo do comércio agêntico hoje.

O x402 é o padrão emergente criado para fechar essa lacuna, e ele faz isso ressuscitando uma das peças mais antigas e nunca usadas da web: o código de status HTTP 402 Payment Required. Este guia explica o que o x402 realmente é, por que conectividade é a primeira compra canônica de um agente autônomo, e como o fluxo existente de stablecoin + MCP da Roamzy se encaixa de forma limpa no formato do x402 hoje — sem fingir que ele fala x402 nativamente.

O que o x402 realmente é

O HTTP 402 foi reservado na especificação original para "Payment Required" e ficou sem uso por mais de três décadas, porque nunca existiu uma forma nativa da internet de liquidar um pagamento dentro de uma requisição. O x402 — impulsionado pela Coinbase (com a Cloudflare e uma fundação crescente) e rodando em escala desde 2025 — finalmente liga esse código a dinheiro de verdade, liquidando pagamentos em stablecoin diretamente sobre HTTP.

A mecânica é um loop de requisição/resposta entre três partes: o cliente (seu agente), o servidor de recursos (a coisa sendo vendida) e um facilitador (um serviço que verifica e liquida o pagamento on-chain para que o servidor não precise rodar a própria infraestrutura de blockchain). O fluxo:

1. O agente faz uma requisição HTTP normal a um recurso com preço.
2. O servidor responde 402 Payment Required com um header PAYMENT-REQUIRED carregando os requisitos de pagamento estruturados: preço, token aceito, endereço do destinatário e rede.
3. O agente monta um payload de pagamento assinado — tipicamente autorização sem gás via EIP-3009 para USDC, ou Permit2 para outros tokens ERC-20 — e repete a mesma requisição com a prova em um header X-PAYMENT.
4. O facilitador verifica e liquida; o servidor retorna os dados mais um header X-PAYMENT-RESPONSE confirmando a transação.

O ciclo inteiro leva segundos, não exige login e liquida on-chain. O x402 é agnóstico de blockchain (chains EVM, mais Solana e outras), cobra zero taxa de protocolo e, no início de 2026, já tinha processado bem mais de 100 milhões de transações só na Base, com dezenas de milhares de agentes transacionando ativamente. Já não é um experimento mental.

Por que conectividade é o primeiro pagamento canônico

De tudo o que um agente poderia comprar, por que destacar um eSIM? Porque conectividade está a montante de qualquer outra compra. Considere a cadeia de dependências:

• Para pagar por inferência, um dataset ou um proxy, o agente precisa de um caminho de rede até esse recurso.
• Um agente hospedado na nuvem herda a rede do host — mas um agente de borda, robótica, drone, IoT ou de campo se define justamente por precisar adquirir a própria conectividade antes de conseguir fazer qualquer outra coisa.
• Conectividade é naturalmente medida e de baixa denominação — bytes, não assinaturas — exatamente o formato para o qual os micropagamentos do x402 foram desenhados.

Então o momento canônico pagável por máquinas é assim: o agente precisa de dados → encontra um recurso de conectividade com preço → liquida um micropagamento em stablecoin → obtém conectividade → segue com a tarefa real. Um agente que consegue pagar pela própria banda é um agente que consegue se inicializar em qualquer lugar do planeta sem um humano encaixando um chip. Essa é a promessa toda, e é por isso que pensamos no melhor eSIM para agentes de IA primeiro como um problema de pagamentos e só depois como um problema de telecom.

As duas metades: orçamento de dados e pagamento

Um agente que paga precisa raciocinar sobre duas coisas em conjunto. A primeira é de quantos dados ele precisa e quanto isso vai custar — um problema de planejamento coberto no nosso guia de consumo de dados para agentes. A segunda é como ele liquida esse custo — o problema de pagamento de que trata este artigo. O x402 é a metade da liquidação; um produto de conectividade medido por MB é a metade do orçamento. Elas só funcionam juntas: um agente que sabe que precisa de 500 MB mas não consegue pagar, ou que consegue pagar mas é forçado a um pacote fixo de 5 GB, está quebrado numa direção ou na outra.

Mapeando o x402 sobre a Roamzy hoje

Honestidade em primeiro lugar: a Roamzy não expõe um endpoint nativo HTTP-402 / x402 hoje. Ela não retorna respostas 402 ao vivo e não fala nativamente o handshake de headers do x402. O que ela faz é liquidar em stablecoins através do processador cripto NowPayments e expor o fluxo de compra por um servidor MCP e uma API REST. Esse fluxo é a mesma primitiva do x402 — um recurso de conectividade com preço, liquidado por um pagamento em stablecoin sem checkout humano — o que torna a Roamzy pronta para o x402 na direção, não no formato de wire. Aqui está o mapeamento de conceito para primitiva:

Lidos da esquerda para a direita, os formatos se alinham quase um a um. A diferença é puramente o canal de liquidação: o x402 liquida o pagamento dentro do round-trip HTTP; a Roamzy liquida ao lado da chamada MCP/REST via processador e confirma de forma assíncrona pelo webhook IPN. A primitiva econômica — o agente paga em stablecoin, recebe conectividade medida, sem login, sem KYC — é idêntica.

O que um agente chama na prática

Uma sequência concreta para uma compra na Roamzy hoje:

1. roamzy_status — verifique purchases_paused e recue se estiver ativo.
2. roamzy_estimate — transforme um orçamento de dados em um custo esperado em USDT (só planejamento; o agente não pré-compra volumes).
3. roamzy_payment_options — leia a lista habilitada de stablecoin+rede (o análogo de parsear um header PAYMENT-REQUIRED) e escolha uma chain, ex.: USDC em Solana para taxas quase zero.
4. roamzy_create_order com pay_currency definido explicitamente → liquide o pagamento em stablecoin (recarga mínima de $20).
5. roamzy_order_status — faça polling até o IPN confirmar e o saldo ser creditado.

Como o saldo é medido por MB e nunca expira, uma única recarga financia muitas tarefas subsequentes — o agente recarrega uma vez e vai consumindo enquanto trabalha, que é o padrão sem assinatura, de pagar pelo uso, que os micropagamentos do x402 incentivam. Os formatos completos de requisição/resposta estão na documentação da API e no guia MCP para desenvolvedores.

Os modos de falha a prever

Quem está construindo rumo a pagamentos por máquina deve conhecer as arestas afiadas. Do lado do x402, a patologia clássica é o loop de retry: o agente recebe um 402, assina, reenvia, recebe outro 402 e nunca converge — geralmente por desvio de relógio na janela de validade assinada, um descasamento de chain-ID (assinar contra a chain X enquanto o facilitador verifica na chain Y) ou indisponibilidade intermitente do facilitador. Na Roamzy hoje o análogo é mais sutil, porque a liquidação é assíncrona: as armadilhas são escolher um pay_currency cuja rede a carteira do agente não consegue de fato usar para enviar, mandar menos que o mínimo de $20 ou tratar a resposta do create-order como final em vez de fazer polling em roamzy_order_status pela confirmação do IPN. Nos dois mundos a disciplina é a mesma — fixe a rede explicitamente, respeite o mínimo e confirme antes de prosseguir.

Para onde isso está indo

O x402 transforma conectividade em algo que um agente compra do jeito que compra uma chamada de API — precificado, assinado, liquidado, pronto. A Roamzy é construída sobre a mesma primitiva econômica hoje: conectividade anônima por padrão, liquidada em stablecoin, medida por MB, que um agente alcança via MCP ou REST sem humano no loop. Ainda não é x402 no wire, mas é x402 em espírito — e o fluxo de compra, a escolha de token e o saldo medido já estão todos no ar agora. Veja os preços por MB ao vivo na página de preços ou conecte tudo ao seu agente a partir do hub de agentes de IA.

FAQ

A Roamzy suporta x402 nativamente hoje?

Não. A Roamzy não expõe um endpoint HTTP-402, não retorna respostas 402 ao vivo e não fala o handshake de headers do x402. Ela liquida em stablecoins via processador NowPayments e expõe o fluxo de compra por MCP e REST. Esse fluxo tem o mesmo formato econômico do x402 — conectividade precificada, liquidação em stablecoin, sem login — o que a torna pronta para o x402 na direção, não no formato de wire.

Com quais stablecoins e redes um agente pode pagar?

Onze combinações estão no ar: USDT em TRON, BSC, Polygon, Optimism, Arbitrum e TON, e USDC em Solana, BSC, Polygon, Optimism e Arbitrum. Chame roamzy_payment_options para obter a lista atual com dicas de taxa por rede e então passe o código correspondente como pay_currency. USDC em Solana tem taxa quase zero; USDT em TRON tem o suporte de carteiras mais amplo.

O agente precisa de conta ou KYC para pagar?

Não. A Roamzy é anônima por padrão — um agente pode estimar, pedir e pagar em stablecoin sem registrar conta nem passar por KYC. É a mesma propriedade sem login que torna o x402 atraente para agentes autônomos.

Como o saldo medido por MB funciona com micropagamentos?

O agente recarrega um saldo em USDT/USDC (mínimo de $20) uma vez e depois o consome por MB realmente usado, sem validade. Ele não pré-compra pacotes fixos de dados. Isso casa com o modelo de micropagamentos do x402 — liquidação pequena e baseada em uso, em vez de assinatura fixa — e permite que uma única recarga financie muitas tarefas subsequentes. Veja o guia de consumo de dados para orçar a metade do consumo.