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 fazendo você se cadastrar primeiro: criar uma conta, obter uma chave, receber a fatura depois. x402 elimina tudo isso. Um servidor pode cobrar por requisição, sem cadastro, chave ou fatura. E isso já está 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 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, 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 com ela, e onde outros protocolos de pagamento como o AP2 se encaixam.

O que o x402 realmente faz?

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

Um servidor responde a uma requisição não paga com status 402 e um preço legível por máquina
O cliente anexa um pagamento assinado e refaz a tentativa
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, as informações relevantes ficam em headers HTTP:

Header	Direction	Carries
`PAYMENT-REQUIRED`	Servidor para cliente	Preço, endereço de destino, network e schemes 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 schemes, é a mesma terceira parte que faz a verificação e a movimentação do dinheiro: um facilitator, um serviço que verifica o pagamento assinado do cliente e envia a liquidação onchain, de forma que nem o vendedor nem o cliente precisam fazer nenhuma das duas coisas por conta própria. O que difere de scheme para scheme é apenas o que o facilitator verifica e quando ele liquida.

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

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

Algumas chamadas custam um valor variável que só se conhece depois que o trabalho é feito, como saída de LLM cobrada por tokens gerados. Para essas, o servidor usa upto. O payload é quase idêntico, mas amount agora representa um teto que o cliente aceita, 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 realiza o trabalho, o facilitator liquida o valor real (digamos, $1,20 de uso real) e verifica se está igual ou abaixo do teto assinado antes de movimentar qualquer dinheiro. O cliente nunca assina duas vezes; só a etapa de liquidação preenche o número real.

Um terceiro scheme, batch-settlement, é para cobranças de alta frequência e sub-centavo, em que pagar taxas de gas em cada chamada custaria mais que a própria chamada. No scheme do 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 semelhante para a mesma finalidade.

O facilitator nunca detém fundos; ele apenas verifica instruções assinadas e as executa. O x402.org opera um facilitator público gratuito apenas para desenvolvimento e testnet, e o CDP da Coinbase opera um facilitator de produção hospedado com verificação 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 schemes de pagamento que aceita.
O cliente assina um pagamento para um dos schemes aceitos e refaz 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 realiza o trabalho (executa a query, 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 sobre JSON em vez disso:

Uma chamada sem pagamento retorna um resultado com isError: true e um payload PaymentRequired (equivalente a PAYMENT-REQUIRED)
O cliente refaz 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 espelha um caso real comum: um servidor MCP com uma mistura de tools pagas e gratuitas, como um servidor de pesquisa ou dados que oferece buscas básicas gratuitas, mas cobra por um relatório gerado mais aprofundado.

Neste exemplo, generate_report custa $0,01 por chamada e ping continua gratuito, construído sobre os x402 Foundation SDKs abertos (agnósticos a 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. @alchemy/wallet-apis (v5) fornece 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. @x402/core constrói e verifica os requisitos de pagamento, @x402/evm implementa o scheme exact para chains EVM, e @x402/mcp envolve um tool handler 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);

server.connect(transport) apenas conecta o protocolo ao transport. O listener HTTP do Node é o que 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 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 pagador.

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

Como medir e cobrar 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 apenas do relatório de liquidação do facilitator como única prova de que o dinheiro realmente se movimentou. Para verificar, acompanhe:

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 de antemão, 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 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 da 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 confie apenas na resposta de liquidação como seu único sinal. Um facilitator pode reportar settled: true enquanto uma requisição ainda retorna um status diferente de 200, ou vice-versa; verifique ambos antes de contabilizar a receita. Para uma passagem de reconciliação periódica, nossa Transfers API permite confirmar de forma independente o que de fato chegou ao seu endereço receptor, o que detecta 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 com ela?

Um agente que precisa pagar um endpoint com paywall, seu ou de terceiros, precisa de uma wallet financiada e de código (ou uma CLI) que consiga assinar um pagamento ao 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 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 devolva pode aumentar esse número. Se você executar o comando sem um humano ali 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 verificasse 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 payment handler apoiado por um signer. Se o agente está chamando endpoints HTTP pagos, use @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. O 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 crua 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 por trás da mesma interface de signer, para que o agente possa assinar sob as regras que você definir sem nunca deter a chave privada em si.

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 que paga 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 dele só 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 enviar uma transação ou deter nenhum token de gas. O agente apenas assina; o facilitator é quem envia essa transação onchain e paga seu gas. 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 semelhante para esse mesmo caso de alta frequência. O USDC ser precificado em dólares também simplifica as coisas além disso: nenhum dos lados precisa fazer cálculo de taxa de câmbio para uma cobrança de $0,01.

Isso cobre o pagamento em si. Se seu endereço receptor é uma wallet externa simples, essa é toda a história: ele apenas recebe USDC, sem etapa de deploy envolvida. Se for uma smart account como a construída anteriormente neste guia, ela ainda toca 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ê transferir o USDC acumulado para uma treasury wallet. Nosso Gas Manager pode patrocinar gas para esses dois momentos; de todo modo, 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 os facilitators adicionem 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 pilha mais ampla de pagamentos entre 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á presa a stablecoins, em que um vendedor pode aceitar cartões ou stablecoins sob o mesmo fluxo (e o MPP é compatível com versões anteriores do fluxo exact do x402, então um cliente construído para um geralmente consegue 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 do 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, então o x402 é o trilho cripto por baixo dele, em vez de 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 ao método de pagamento	Sim
ACP	OpenAI e Stripe	Cartões (via checkout da Stripe)	Checkout de compras conduzidas por agente, não pagamento de API por requisição	Não, um checkout por compra
AP2	Google, com parceiros do setor	Agnóstico 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 por conta própria

À medida que o panorama de protocolos evolui, o AgentPay existe como um proxy agnóstico a protocolo que ajuda comerciantes a integrar uma única vez e dar suporte a todos eles.

Se você está escolhendo entre x402 e MPP para uma construção específica, veja nossa comparação x402 vs MPP. Se você está escolhendo um provedor de infraestrutura, veja nossa comparação da 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ê mesmo não verificou. 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 periodicamente contra a realidade onchain com nossa Transfers API, como mostrado acima.
Não deixe de definir o limite de gastos de um agente autônomo. Seja qual for o seu equivalente a --max-payment, defina-o com o menor valor que realiza a tarefa, já que é a única coisa 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 enviar 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 real.
Não presuma que "suporta x402" signifique "suporta toda network e todo scheme". Confirme quais schemes (exact, upto, batch-settlement) e quais chains seu facilitator específico e sua contraparte realmente implementam antes de lançar contra eles; a página de suporte de network e token é a fonte da verdade.

Perguntas frequentes

Como adiciono pagamentos x402 a um servidor MCP?

Envolva o tool handler que você quer cobrar com um payment wrapper do pacote @x402/mcp da x402 Foundation, apoiado por um servidor registrado com um facilitator e que 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 fale 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 nem deter tokens de gas; o facilitator cobre o gas da 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 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 se o facilitator escolhido 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, alchemy wallet connect --mode session (parte da Alchemy CLI) cria uma sessão de wallet com escopo e revogável em minutos, sem nenhuma chave privada jamais exposta ao agente. Para um agente de backend totalmente autônomo, provisione uma smart account através de @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 scheme que o servidor aceita, e refaz a mesma requisição com o pagamento assinado anexado. O servidor verifica e liquida através de um facilitator e retorna o recurso no mesmo round trip.

Como medir e cobrar agentes de IA pelo uso de API com pagamentos em cripto?

Use o scheme 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 com a tool ou endpoint pelo qual 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 entre agentes e comércio onchain?

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

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

AP2 é o framework agnóstico a 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 do 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 entre agentes e que infraestrutura ele exige?

Comércio entre agentes é a descoberta, o pagamento e o recebimento por agentes de IA de bens, serviços e acesso a APIs sem um humano passar pelo checkout a cada vez. Isso exige uma wallet financiada, um trilho de pagamento como x402 ou MPP para movimentar valor por requisição, tratamento 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 acesse serviços onchain com paywall?

Do lado do cliente, instale uma biblioteca de cliente x402 (@x402/fetch, @x402/axios, ou o wrapper de cliente MCP), registre um scheme 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 do comprador acima cobre tanto os casos HTTP quanto 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 e pagar são o mesmo protocolo visto de lados opostos da requisição.

Comece a construir tools MCP pagas

Dê ao agente uma wallet com escopo com 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 pilha mais ampla (custódia, trilho, gas e dados), comece com melhor infraestrutura para pagamentos agênticos.

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 wallets de agente, 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 fluxos de trabalho de agentes 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