Como adicionar pagamentos x402 a um servidor MCP: um guia para builders sobre pagamentos de agentes

Escrito por Alchemy

Publicado em 26 de agosto de 202615 min de leitura

A maioria das APIs cobra exigindo que você se cadastre primeiro: criar uma conta, obter uma chave, ser cobrado depois. x402 elimina tudo isso. Um servidor pode cobrar por requisição, sem cadastro, chave ou fatura. E já está rodando em produção: a Coinbase lançou em maio de 2025, a Cloudflare integrou ao seu Agents SDK, e nosso agent gateway usa isso para cobrar de agentes por acesso a RPC e dados.

Este guia é para quem constrói qualquer um dos dois lados dessa troca: um servidor MCP ou API que quer cobrar por chamada, ou um agente que precisa pagar por uma. Vamos percorrer o ciclo de requisição e resposta, e depois mostrar código real para cobrar por uma chamada de tool, medir e liquidar por chamada em USDC, dar a um agente uma wallet para pagar, e onde outros protocolos de pagamento como o AP2 se encaixam.

O que o x402 realmente faz?

O HTTP 402 Payment Required existe na especificação HTTP desde os anos 1990 e nunca foi implementado. O x402 é o protocolo que finalmente o usa:

Um servidor responde a uma requisição não paga com o status 402 e um preço legível por máquina
O cliente anexa um pagamento assinado e tenta novamente
O servidor verifica, liquida e retorna o recurso na mesma troca

Não há sessão, cartão armazenado ou dashboard, e a wallet é a conta. No x402 v2, a informação relevante é armazenada em headers HTTP:

Header	Direction	Carries
`PAYMENT-REQUIRED`	Servidor para cliente	Preço, endereço de destino, network e esquemas de pagamento aceitos, codificados em base64
`PAYMENT-SIGNATURE`	Cliente para servidor	O payload de pagamento assinado, codificado em base64
`PAYMENT-RESPONSE`	Servidor para cliente	O resultado da liquidação, codificado em base64

Os três headers nunca mudam. O que muda é o campo scheme dentro do JSON que PAYMENT-REQUIRED carrega, que informa ao cliente qual modelo de cobrança essa chamada específica está usando. Em todos os esquemas, é o mesmo terceiro que faz a verificação e a movimentação de dinheiro: um facilitator, um serviço que verifica o pagamento assinado do cliente e submete a liquidação onchain, para que nem o vendedor nem o cliente precisem fazer nenhum dos dois por conta própria. O que muda de esquema para esquema é apenas o que o facilitator verifica e quando liquida.

A maioria das chamadas usa exact: o preço é fixo e conhecido de antemão, então o cliente assina por esse valor exato e ele é liquidado por esse valor exato. O payload se parece com isto, reduzido aos campos que importam. amount é 10.000 unidades atômicas, o que equivale a $0,01 USDC:

jsonCopied
{
"accepts": [{
  "scheme": "exact",
  "amount": "10000",
  "asset": "0x036C...F7e",
  "payTo": "0x2096...87C"
}]
}

Algumas chamadas custam um valor variável só conhecido depois que o trabalho é feito, como saída de LLM cobrada por tokens gerados. Para essas, o servidor usa upto. O payload parece quase idêntico, mas amount agora representa um teto que o cliente concorda em pagar, não um preço. Aqui esse teto é $5,00:

jsonCopied
{
"accepts": [{
  "scheme": "upto",
  "amount": "5000000",
  "asset": "0x036C...F7e",
  "payTo": "0x2096...87C"
}]
}

O cliente assina uma vez contra esse teto. Depois que o servidor faz o trabalho, o facilitator liquida o valor real (digamos $1,20 de uso real) e verifica que está no valor do teto assinado ou abaixo dele antes de mover qualquer dinheiro. O cliente nunca assina duas vezes; apenas a etapa de liquidação preenche o número real.

Um terceiro esquema, batch-settlement, é para cobranças de alta frequência e sub-centavo, onde pagar taxas de gas em cada chamada custaria mais do que a própria chamada. No esquema x402, o comprador deposita uma vez em um contrato de escrow, assina vouchers off-chain por requisição, e os vendedores resgatam em lotes onchain. O Circle Gateway usa um padrão de nanopagamentos relacionado para a mesma função.

O facilitator nunca detém fundos ele mesmo; ele apenas verifica instruções assinadas e as executa. O x402.org roda um facilitator público gratuito apenas para desenvolvimento e testnet, e a CDP da Coinbase roda um facilitator de produção hospedado com triagem de compliance. Você pode apontar seu código para qualquer um dos dois.

Como funciona o ciclo de requisição e resposta do x402?

O handshake tem nove etapas:

O cliente solicita um recurso sem nenhum pagamento anexado.
O servidor responde 402 Payment Required com um preço, um endereço de destino e os esquemas de pagamento que aceita.
O cliente assina um pagamento para um dos esquemas aceitos e tenta novamente a requisição com a assinatura anexada.
O servidor pede ao facilitator para verificar o pagamento assinado contra seus requisitos declarados.
O facilitator retorna um resultado de verificação.
O servidor faz o trabalho (executa a consulta, chama o modelo, gera o relatório).
O servidor pede ao facilitator para liquidar o pagamento onchain.
O facilitator retorna o resultado da liquidação.
O servidor retorna o recurso, junto com o recibo de liquidação.

Sobre HTTP, esse ciclo é executado via headers HTTP (PAYMENT-REQUIRED, PAYMENT-SIGNATURE, PAYMENT-RESPONSE). Sobre MCP, essas mesmas nove etapas rodam em JSON:

Uma chamada sem pagamento retorna um resultado com isError: true e um payload PaymentRequired (equivalente a PAYMENT-REQUIRED)
O cliente tenta novamente a mesma chamada com o pagamento assinado anexado em _meta["x402/payment"] (equivalente a PAYMENT-SIGNATURE)
O servidor retorna o resultado real com informações de liquidação em _meta["x402/payment-response"] (equivalente a PAYMENT-RESPONSE)

Como adiciono pagamentos x402 a um servidor MCP?

Este exemplo reflete um caso comum do mundo real: um servidor MCP com uma mistura de tools pagas e gratuitas, como um servidor de pesquisa ou dados que dá consultas básicas gratuitas mas cobra por um relatório gerado mais aprofundado.

Neste exemplo, generate_report custa $0,01 por chamada e ping permanece gratuito, construído sobre os x402 Foundation SDKs abertos (agnósticos de facilitator, então você pode começar contra o facilitator público gratuito e trocar por um comercial depois) com uma smart account das Wallet APIs como o endereço que recebe o pagamento.

Primeiro, provisione a wallet que recebe o pagamento. O @alchemy/wallet-apis (v5) dá a você um endereço de smart account sem tocar em uma chave privada no seu servidor:

tsxCopied
// wallet.ts
import { createServerSigner } from "@account-kit/signer";
import { createSmartWalletClient, alchemyWalletTransport } from "@alchemy/wallet-apis";
import { baseSepolia } from "viem/chains";

const signer = await createServerSigner({
auth: { accessKey: process.env.ALCHEMY_ACCESS_KEY! },
connection: { apiKey: process.env.ALCHEMY_API_KEY! },
});

const walletClient = createSmartWalletClient({
transport: alchemyWalletTransport({ apiKey: process.env.ALCHEMY_API_KEY! }),
chain: baseSepolia,
signer,
});

export const receiverAccount = await walletClient.requestAccount();
// receiverAccount.address is the payTo address for every quote you issue below

Agora conecte esse endereço a uma tool MCP protegida por x402. O @x402/core constrói e verifica requisitos de pagamento, o @x402/evm implementa o esquema exact para chains EVM, e o @x402/mcp envolve um handler de tool para que uma função simples se torne uma paga:

tsxCopied
// server.ts
import { createServer } from "node:http";
import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StreamableHTTPServerTransport } from "@modelcontextprotocol/sdk/server/streamableHttp.js";
import { x402ResourceServer } from "@x402/core/server";
import { HTTPFacilitatorClient } from "@x402/core/facilitator";
import { createPaymentWrapper } from "@x402/mcp";
import { ExactEvmScheme } from "@x402/evm/exact/server";
import { z } from "zod";
import { receiverAccount } from "./wallet";

// Base Sepolia for testing; swap to eip155:8453 for Base mainnet
const NETWORK = "eip155:84532";

// Start against the free public facilitator, then swap the url for a
// commercial facilitator (compliance screening, higher throughput, an
// SLA) for production.
const facilitator = new HTTPFacilitatorClient({
url: "https://x402.org/facilitator",
});

const resourceServer = new x402ResourceServer(facilitator);
resourceServer.register(NETWORK, new ExactEvmScheme());
await resourceServer.initialize();

const accepts = await resourceServer.buildPaymentRequirements({
scheme: "exact",
network: NETWORK,
payTo: receiverAccount.address,
price: "$0.01",
});

const paid = createPaymentWrapper(resourceServer, { accepts });

const server = new McpServer({
name: "paid-report-server",
version: "1.0.0",
});

server.tool(
"generate_report",
"Generate a research report on a topic. Costs $0.01 in USDC.",
{ topic: z.string() },
paid(async ({ topic }) => ({
  content: [
    {
      type: "text",
      text: "Report on " + topic + ": trending up, no anomalies.",
    },
  ],
})),
);

server.tool("ping", "Free health check", {}, async () => ({
content: [{ type: "text", text: "pong" }],
}));

const transport = new StreamableHTTPServerTransport({
sessionIdGenerator: undefined,
});
await server.connect(transport);

createServer((req, res) => {
const path = new URL(req.url ?? "/", "http://localhost").pathname;
if (path === "/mcp") {
  void transport.handleRequest(req, res);
  return;
}
res.writeHead(404).end();
}).listen(3000);

O server.connect(transport) apenas anexa o protocolo ao transport. O listener HTTP do Node é quem de fato abre a porta 3000 e encaminha /mcp para transport.handleRequest(...), que é o endpoint que o cliente abaixo chama.

Tudo o que você não envolveu em paid(...) permanece gratuito, então você pode misturar tools pagas e não pagas no mesmo servidor. Teste com o curl ou qualquer cliente MCP sem pagamento anexado primeiro: você deve receber de volta um resultado de pagamento necessário em vez do relatório, o que confirma que o gate está ativo antes de você conectar um cliente pagante.

Se você preferir não gerenciar uma relação com facilitator por conta própria, e quiser aceitar x402 junto de outros protocolos de pagamento de agentes emergentes sem escolher apenas um, é para isso que serve o AgentPay: aponte-o para seu endpoint existente e ele cuida da tradução de protocolo entre x402, ACP, MPP e AP2 a partir de uma única integração.

Como meço e cobro agentes por chamada?

Um preço fixo único por chamada é o caso base. Servidores de produção também precisam rastrear quem pagou e quanto, e não devem depender do relatório de liquidação do facilitator como única prova de que o dinheiro realmente se moveu. Para verificar, mantenha o controle de:

Formato de precificação. Use exact para um preço fixo por chamada, o padrão acima. Use upto quando o custo varia por chamada (um relatório mais longo custa mais tokens que um curto) e você quer autorizar um teto antecipadamente mas liquidar o uso real. Use batch-settlement quando as chamadas são frequentes e baratas o suficiente para que liquidar cada uma individualmente onchain custaria mais do que a própria chamada.
Atribuição e registro contábil. O payload de pagamento que o cliente assina inclui o endereço pagador. Registre-o junto com o nome da tool, o preço e o resultado de liquidação toda vez que uma chamada é liquidada, e você tem um livro-razão de uso por agente de graça:

tsxCopied
const paid = createPaymentWrapper(resourceServer, {
accepts,
hooks: {
  onAfterSettlement: async ({ toolName, settlement }) => {
    await usageLedger.record({
      payer: settlement.payer,
      tool: toolName,
      amountUsd: 0.01,
      txHash: settlement.transaction,
      settledAt: new Date(),
    });
  },
},
});

Não pare em confiar na resposta de liquidação como seu único sinal. Um facilitator pode reportar settled: true enquanto uma requisição ainda retorna um não-200, ou vice-versa; verifique ambos antes de contabilizar receita. Para uma passagem de reconciliação periódica, nossa Transfers API permite confirmar independentemente o que de fato chegou ao seu endereço receptor, o que captura o caso raro em que o relatório de liquidação de um facilitator e a realidade onchain divergem:

tsxCopied
const res = await fetch("https://base-sepolia.g.alchemy.com/v2/" + apiKey, {
method: "POST",
headers: { "Content-Type": "application/json" },
body: JSON.stringify({
  jsonrpc: "2.0",
  method: "alchemy_getAssetTransfers",
  params: [{
    toAddress: receiverAccount.address,
    category: ["erc20"],
    contractAddresses: [USDC_ADDRESS],
    withMetadata: true,
  }],
  id: 1,
}),
});
const { result } = await res.json();
// result.transfers is the ground truth for what actually arrived onchain,
// independent of what any single facilitator reported settling

Como dou a um agente uma wallet USDC para pagar?

Um agente que precisa pagar um endpoint com paywall, seu ou de qualquer outra pessoa, precisa de uma wallet financiada e de código (ou uma CLI) que possa assinar um pagamento quando encontrar um 402.

Para um agente operado por humano ou testado localmente, o caminho mais rápido é a Alchemy CLI. Ela cria uma sessão de wallet com escopo definido que o agente pode usar sem nunca tocar em uma chave privada:

bashCopied
npm i -g "@alchemy/cli@latest"
alchemy auth
alchemy wallet connect --mode session --instance-name "my-agent"

# decode a quote without paying anything, useful for a first look at an unfamiliar endpoint
alchemy x402 request "https://api.example.com/report" --estimate

# pay it for real, with a hard spend cap; required for any non-interactive run
alchemy --json --no-interactive x402 request "https://api.example.com/report" --max-payment 0.01

--max-payment define o máximo que a CLI jamais pagará, e nada que o servidor devolver pode empurrar esse número para cima. Se você executar o comando sem nenhum humano lá para aprová-lo (--no-interactive) e esquecer de definir --max-payment, a CLI simplesmente para em vez de pagar, porque o preço em uma resposta 402 vem de um servidor que você não controla, e nada deveria pagá-lo sem que seu limite o verifique primeiro. Veja a documentação da CLI de pagamentos x402 para a superfície completa de comandos.

Para um agente de backend totalmente autônomo que precisa pagar sem um humano aprovando cada sessão, envolva fetch (ou seu cliente MCP) com um handler de pagamento apoiado por um signer. Se o agente está chamando endpoints HTTP pagos, use o @x402/fetch:

tsxCopied
import { x402Client } from "@x402/core/client";
import { wrapFetchWithPayment } from "@x402/fetch";
import { registerExactEvmScheme } from "@x402/evm/exact/client";
import { privateKeyToAccount } from "viem/accounts";

const signer = privateKeyToAccount(process.env.AGENT_WALLET_KEY as `0x${string}`);
const client = new x402Client();
registerExactEvmScheme(client, { signer });

const fetchWithPayment = wrapFetchWithPayment(fetch, client);
const response = await fetchWithPayment("https://api.example.com/report");

Se o agente está chamando tools pagas em um servidor MCP em vez de um endpoint HTTP simples, envolva o cliente MCP da mesma forma em vez de fetch. A CDP documenta o mesmo padrão para compradores MCP:

tsxCopied
import { Client } from "@modelcontextprotocol/sdk/client/index.js";
import { StreamableHTTPClientTransport } from "@modelcontextprotocol/sdk/client/streamableHttp.js";
import { x402Client } from "@x402/core/client";
import { wrapMCPClientWithPayment } from "@x402/mcp";
import { registerExactEvmScheme } from "@x402/evm/exact/client";
import { privateKeyToAccount } from "viem/accounts";

const signer = privateKeyToAccount(
process.env.AGENT_WALLET_KEY as `0x${string}`,
);
const paymentClient = new x402Client();
registerExactEvmScheme(paymentClient, { signer });

const mcp = wrapMCPClientWithPayment(
new Client(
  { name: "my-agent", version: "1.0.0" },
  { capabilities: {} },
),
paymentClient,
{ autoPayment: true },
);

await mcp.connect(
new StreamableHTTPClientTransport(
  new URL("http://localhost:3000/mcp"),
),
);

const report = await mcp.callTool({
name: "generate_report",
arguments: { topic: "USDC on Base" },
});

Uma chave privada em texto puro em uma variável de ambiente pode ser aceitável para um primeiro teste em testnet, mas é inaceitável em produção. Para um agente de produção, coloque uma smart account das Wallet APIs ou uma sessão de Agent Wallet atrás da mesma interface de signer, para que o agente possa assinar sob regras que você define sem nunca deter a chave privada.

Como liquido em USDC sem exigir que agentes detenham gas?

Toda transação onchain precisa de gas: um token nativo como ETH, detido por quem envia a transação, para pagar a network para processá-la. Isso é um problema para um agente pagando por chamada de API. Ele não pode parar e ir adquirir um token de gas antes de cada pagamento de $0,01, e manter um estoque disso apenas por precaução anula o propósito de um fluxo automatizado.

A liquidação em USDC contorna isso com o EIP-3009 (transferWithAuthorization): ele permite que o agente assine uma transferência sem ele mesmo submeter uma transação ou deter qualquer token de gas. O agente apenas assina; o facilitator é quem submete essa transação onchain e paga o gas dela. Liquidações exact e upto tipicamente usam EIP-3009 para USDC e Permit2 para qualquer outro ERC-20 que não suporte EIP-3009. batch-settlement ainda faz o agente assinar por requisição, mas o vendedor resgata um lote onchain depois em vez de liquidar cada chamada isoladamente. O Circle Gateway usa um padrão de nanopagamentos relacionado para esse mesmo caso de alta frequência. O USDC ser precificado em dólares também mantém as coisas simples além disso: nenhum dos lados precisa fazer cálculo de taxa de câmbio em uma cobrança de $0,01.

Isso cobre o pagamento em si. Se seu endereço receptor for uma wallet externa simples, essa é toda a história: ela apenas recebe USDC, sem etapa de deploy envolvida. Se for uma smart account como a construída anteriormente neste guia, ela ainda toca em gas em outros dois momentos fora do fluxo x402: uma vez para fazer o deploy onchain na primeira vez que recebe fundos, e novamente sempre que você transfere o USDC coletado para uma wallet de tesouraria. Nosso Gas Manager pode patrocinar gas para esses dois momentos; de qualquer forma, ele não está envolvido na liquidação do pagamento x402 em si, já que o facilitator já cobre isso.

Base é a network padrão na maioria das ferramentas, já que é onde o facilitator de referência original roda e onde a maioria das integrações x402 existentes já vive, mas o x402 v2 não é exclusivo da Base. Ele também cobre qualquer chain EVM (incluindo Ethereum mainnet e Polygon) além de Solana, TON, Algorand, Stellar, Aptos, Hedera, Keeta, NEAR, Concordium e XRPL, com mais chains esperadas conforme facilitators adicionam suporte. Se "pagar em USDC no Ethereum" especificamente funciona para você hoje depende de se o facilitator escolhido implementou essa network, não do protocolo em si.

Onde o x402 se encaixa na stack mais ampla de pagamentos de agentes?

O x402 é um protocolo em um campo em rápida evolução, não o único.

Stripe e Tempo construíram o MPP como uma versão do mesmo padrão 402 que não está preso a stablecoins, onde um vendedor pode aceitar cartões ou stablecoins sob o mesmo fluxo (e o MPP é retrocompatível com o fluxo exact do x402, então um cliente construído para um geralmente pode conversar com um servidor construído para o outro).
O ACP da OpenAI e da Stripe cobre uma fatia diferente: checkout para compras conduzidas por IA em vez de pagamentos de API por requisição.
O AP2 do Google cobre um problema totalmente diferente: provar que um usuário autorizou um agente a gastar, usando mandatos assinados de Checkout e Payment, independentemente de o método de pagamento ser um cartão, uma transferência bancária ou uma stablecoin. O AP2 não é um trilho de liquidação concorrente; quando um fluxo AP2 precisa liquidar em stablecoins, ele faz isso através da extensão A2A x402 que o Google construiu com a Coinbase, a Ethereum Foundation e a MetaMask, de modo que o x402 é o trilho cripto por baixo dele, e não uma alternativa a ele.

Protocol	Steward	Payment type	Primary job	Settles per request?
x402	x402 Foundation (originalmente Coinbase)	Stablecoins onchain	Pagar por chamada de API, chamada de tool ou peça de conteúdo via HTTP ou MCP	Sim
MPP	Stripe e Tempo	Cartões ou stablecoins, mesmo fluxo	Pagar por requisição, agnóstico quanto ao método de pagamento	Sim
ACP	OpenAI e Stripe	Cartões (via checkout da Stripe)	Checkout de compras conduzido por agentes, não pagamento de API por requisição	Não, um checkout por compra
AP2	Google, com parceiros do setor	Agnóstico quanto ao pagamento: cartões, transferências bancárias, stablecoins	Provar que um usuário autorizou um agente a gastar; liquida através do x402 ou de um trilho de cartão/banco por baixo	Não, autoriza um trilho em vez de liquidar ele mesmo

Conforme o panorama de protocolos evolui, o AgentPay existe como um proxy agnóstico de protocolo que ajuda comerciantes a integrar uma vez e suportar todos eles.

Se você está escolhendo entre x402 e MPP para um projeto específico, veja nossa comparação x402 vs MPP. Se você está escolhendo um provedor de infraestrutura, veja nossa comparação de camada de wallet, gas e dados entre Alchemy, Coinbase Developer Platform, Circle, Crossmint, Privy e Turnkey.

Erros comuns a evitar

Nunca assine uma cotação que você não verificou você mesmo. Uma resposta 402 é apenas um número enviado por um servidor que você não controla; confirme a network, o ativo e o valor antes de assinar, da mesma forma que a Alchemy CLI verifica uma cotação localmente antes de assinar contra ela.
Não trate uma resposta 200 como prova de pagamento, nem o settled: true de um facilitator como a única prova de que você precisa. Verifique o próprio recibo de liquidação, e reconcilie contra a realidade onchain periodicamente com nossa Transfers API como mostrado acima.
Não pule o teto de gasto em um agente autônomo. Seja qual for seu equivalente de --max-payment, defina-o como o menor valor que cumpre o trabalho, já que é a única coisa que fica entre seu agente e um servidor que retorna uma cotação inflada.
Não construa seu próprio facilitator a menos que verificar assinaturas, filtrar transações e submeter liquidação onchain em escala seja de fato o seu produto. Aponte para um hospedado e gaste o tempo de engenharia no seu serviço de fato.
Não presuma que "suporta x402" significa "suporta toda network e esquema." Confirme quais esquemas (exact, upto, batch-settlement) e quais chains seu facilitator específico e sua contraparte de fato implementam antes de colocar isso em produção; a página de suporte de network e token é a fonte oficial.

Perguntas frequentes

Como adiciono pagamentos x402 a um servidor MCP?

Envolva o handler de tool que você quer cobrar com um wrapper de pagamento do pacote @x402/mcp da x402 Foundation, apoiado por um servidor que está registrado com um facilitator e sabe qual endereço de wallet deve receber o pagamento. O exemplo completo funcional está acima; tudo o mais no servidor permanece gratuito a menos que você também o envolva.

Que infraestrutura os agentes de IA precisam para pagar por APIs via x402 usando stablecoins?

Três peças: uma wallet que detém e pode assinar por USDC, uma biblioteca de pagamento assinado ou CLI que fala o handshake x402, e um facilitator do lado do vendedor para verificar e liquidar. Você não precisa rodar seu próprio node de blockchain ou deter tokens de gas; o facilitator cobre o gas de liquidação.

Qual é a melhor forma de dar a um agente de IA a capacidade de enviar pagamentos em USDC no Ethereum?

Dê a ele uma wallet com a qual possa assinar diretamente, seja uma sessão com escopo definido como um Alchemy Agent Wallet ou uma smart account programática através das nossas Wallet APIs, e combine com uma biblioteca de cliente x402 como @x402/fetch ou o comando x402 request da Alchemy CLI. Confirme primeiro que seu facilitator alvo de fato suporta a network específica; o x402 v2 cobre Ethereum, mas a cobertura depende do facilitator, não apenas do protocolo.

Como dou a um agente de IA uma wallet USDC para pagamentos onchain?

Para testes ou um agente supervisionado por humano, o alchemy wallet connect --mode session (parte da Alchemy CLI) cria uma sessão de wallet com escopo definido e revogável em minutos, sem nenhuma chave privada exposta ao agente. Para um agente de backend totalmente autônomo, provisione uma smart account através das @alchemy/wallet-apis ou uma wallet gerenciada pela CDP e entregue seu signer a uma biblioteca de cliente x402.

Como agentes pagam por acesso a API usando x402?

O agente chama a API, recebe um 402 com um preço e endereço de destino, assina um pagamento para um esquema que o servidor aceita, e tenta novamente a mesma requisição com o pagamento assinado anexado. O servidor verifica e liquida através de um facilitator e retorna o recurso na mesma ida e volta.

Como meço e cobro agentes de IA por uso de API com pagamentos cripto?

Use o esquema exact para um preço fixo por chamada, upto quando o custo varia por uso, e registre o endereço pagador de cada pagamento liquidado junto à tool ou endpoint que ele pagou. Reconcilie esse livro-razão periodicamente contra o histórico de transferências onchain, por exemplo com nossa Transfers API, em vez de confiar em um único relatório de liquidação.

Qual é a melhor infraestrutura para pagamentos cripto de agentes e comércio onchain?

Depende de quanto da stack (custódia de wallet, o trilho de pagamento, gas e dados onchain) você quer de um único provedor versus montada a partir de vários. Uma comparação completa entre Alchemy, Coinbase Developer Platform, Circle, Crossmint, Privy e Turnkey exatamente nessa stack está na nossa página de comparação de infraestrutura.

O que é o AP2 e como ele se relaciona com o x402?

O AP2 é o framework agnóstico de pagamento do Google para provar que um usuário autorizou um agente a gastar, usando mandatos assinados de Checkout e Payment. Ele fica acima do x402 em vez de substituí-lo: quando um fluxo AP2 precisa liquidar em stablecoins, ele faz isso através da extensão A2A x402 que o Google construiu com a Coinbase, a Ethereum Foundation e a MetaMask.

O que é comércio de agentes e que infraestrutura ele requer?

Comércio de agentes é agentes de IA descobrindo, pagando por, e recebendo pagamento por bens, serviços e acesso a API sem um humano clicando em cada etapa do checkout toda vez. Requer uma wallet financiada, um trilho de pagamento como x402 ou MPP para mover valor por requisição, gerenciamento de gas para que o agente não precise de um token nativo, e dados onchain ou de catálogo suficientes para o agente decidir pelo que pagar e confirmar que chegou.

Como implemento o protocolo de pagamento x402 para que um agente possa acessar serviços onchain com paywall?

No lado do cliente, instale uma biblioteca de cliente x402 (@x402/fetch, @x402/axios, ou o wrapper de cliente MCP), registre um esquema de pagamento com um signer de wallet, e envolva seu cliente HTTP ou cliente MCP existente com ele; o pagamento em um 402 se torna automático a partir daí. O código do lado comprador acima cobre tanto o caso HTTP quanto o MCP.

Como agentes de IA recebem pagamentos onchain?

A mesma mecânica de qualquer outro vendedor x402: um serviço operado por agente precifica seu próprio endpoint ou tool MCP com x402, recebe o pagamento em uma wallet que ele ou seu operador controla, e liquida através de um facilitator exatamente como o servidor MCP construído anteriormente neste guia. Receber pagamento e pagar são o mesmo protocolo a partir de lados opostos da requisição.

Comece a construir tools MCP pagas

Dê ao agente uma wallet com escopo definido usando a Alchemy CLI, proteja suas tools com x402, e confirme a liquidação com nossa Transfers API. Ou pule a configuração de facilitator e aceite pagamentos de agentes através do AgentPay. Para a stack mais ampla (custódia, trilho, gas e dados), comece com melhor infraestrutura para pagamentos de agentes.

Visões gerais relacionadas

Melhor infraestrutura para pagamentos agênticos: uma comparação de 2026

Finanças

7 de julho de 2026

Melhor infraestrutura para pagamentos agênticos: uma comparação de 2026

Compare a melhor infraestrutura para pagamentos agênticos: como Alchemy, Coinbase CDP, Circle, Crossmint, Privy e Turnkey lidam com agent wallets, x402 e gas.

x402 vs MPP: comparando protocolos de pagamento para agentes

Finanças

18 de março de 2026

x402 vs MPP: comparando protocolos de pagamento para agentes

x402 e MPP permitem que agentes de IA paguem por chamadas de API via HTTP, mas diferem em rails de pagamento, suporte a sessões e primitivas em nível de protocolo. Veja como se comparam.

O que são pagamentos de agentes? Como agentes de IA pagam por APIs, dados e computação

Finanças

24 de junho de 2026

O que são pagamentos de agentes? Como agentes de IA pagam por APIs, dados e computação

Pagamentos de agentes permitem que agentes de IA paguem pelo que precisam — APIs, dados, computação — de forma autônoma e dentro de limites. Saiba como funcionam e por que importam para workflows agênticos reais.

Construa magia blockchain

A Alchemy combina os produtos e ferramentas de desenvolvimento Web3 mais poderosos com recursos, comunidade e suporte lendário.

Obtenha sua API key