---
title: "Como adicionar pagamentos x402 a um servidor MCP: um guia para builders sobre pagamentos de agentes"
description: "Proteja um servidor MCP com x402, cobre USDC por chamada, dê a um agente uma wallet para pagar, e veja onde AP2, MPP e ACP se encaixam. Código executável incluído."
---

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

<ImageBlock
  src="https://media.alchemy.com/x402-payments-1.png"
  alt="Adicionando pagamentos x402"
  width={3840}
  height={1800}
  priority
/>

A maioria das APIs cobra exigindo que você se cadastre primeiro: criar uma conta, obter uma chave, ser cobrado depois. [x402](https://docs.x402.org/core-concepts/http-402) 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](https://www.coinbase.com/developer-platform/discover/launches/x402), [a Cloudflare integrou ao seu Agents SDK](https://developers.cloudflare.com/agents/tools/payments/x402/charge-for-mcp-tools/), e [nosso agent gateway](/docs/x402-payments) 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](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402) existe na especificação HTTP desde os anos 1990 e nunca foi implementado. O [x402](https://docs.x402.org/core-concepts/http-402) é 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](https://docs.x402.org/core-concepts/http-402), a informação relevante é armazenada em headers HTTP:

<EmbeddedTable
  table={{
    columns: [
      { key: "header", width: 200, title: "Header", dataType: "object" },
      { key: "direction", width: 180, title: "Direction", dataType: "object" },
      { key: "carries", width: 320, title: "Carries", dataType: "object" },
    ],
    data: [
      {
        header: {
          title: "<p><code>PAYMENT-REQUIRED</code></p>",
          tooltip: "",
          icon: "",
        },
        direction: { title: "<p>Servidor para cliente</p>", tooltip: "", icon: "" },
        carries: {
          title:
            "<p>Preço, endereço de destino, network e esquemas de pagamento aceitos, codificados em base64</p>",
          tooltip: "",
          icon: "",
        },
        id: 0,
      },
      {
        header: {
          title: "<p><code>PAYMENT-SIGNATURE</code></p>",
          tooltip: "",
          icon: "",
        },
        direction: { title: "<p>Cliente para servidor</p>", tooltip: "", icon: "" },
        carries: {
          title: "<p>O payload de pagamento assinado, codificado em base64</p>",
          tooltip: "",
          icon: "",
        },
        id: 1,
      },
      {
        header: {
          title: "<p><code>PAYMENT-RESPONSE</code></p>",
          tooltip: "",
          icon: "",
        },
        direction: { title: "<p>Servidor para cliente</p>", tooltip: "", icon: "" },
        carries: {
          title: "<p>O resultado da liquidação, codificado em base64</p>",
          tooltip: "",
          icon: "",
        },
        id: 2,
      },
    ],
  }}
/>

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](https://docs.x402.org/core-concepts/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:

<CodeSnippet
  language="json"
  code={`{
  "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:

<CodeSnippet
  language="json"
  code={`{
  "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](https://docs.x402.org/core-concepts/network-and-token-support), 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](https://developers.circle.com/gateway/nanopayments) 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](https://docs.x402.org/core-concepts/facilitator) apenas para desenvolvimento e testnet, e a [CDP da Coinbase roda um facilitator de produção hospedado](https://docs.cdp.coinbase.com/x402/core-concepts/how-it-works) 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:

1. O cliente solicita um recurso sem nenhum pagamento anexado.
2. O servidor responde `402 Payment Required` com um preço, um endereço de destino e os esquemas de pagamento que aceita.
3. O cliente assina um pagamento para um dos esquemas aceitos e tenta novamente a requisição com a assinatura anexada.
4. O servidor pede ao facilitator para verificar o pagamento assinado contra seus requisitos declarados.
5. O facilitator retorna um resultado de verificação.
6. O servidor faz o trabalho (executa a consulta, chama o modelo, gera o relatório).
7. O servidor pede ao facilitator para liquidar o pagamento onchain.
8. O facilitator retorna o resultado da liquidação.
9. 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](https://github.com/x402-foundation/x402/blob/main/specs/transports-v2/mcp.md), 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](https://github.com/x402-foundation/x402) 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](/docs/wallets/quickstart) como o endereço que recebe o pagamento.

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

<CodeSnippet
  language="tsx"
  code={`// 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`](https://github.com/x402-foundation/x402) constrói e verifica requisitos de pagamento, o `@x402/evm` implementa o esquema `exact` para chains EVM, e o [`@x402/mcp`](https://github.com/x402-foundation/x402/blob/main/specs/transports-v2/mcp.md) envolve um handler de tool para que uma função simples se torne uma paga:

<CodeSnippet
  language="tsx"
  code={`// 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](/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:

<CodeSnippet
  language="tsx"
  code={`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](/docs/data/transfers-api/transfers-endpoints/alchemy-get-asset-transfers) 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:

<CodeSnippet
  language="tsx"
  code={`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](/docs/alchemy-cli). Ela cria uma sessão de wallet com escopo definido que o agente pode usar sem nunca tocar em uma chave privada:

<CodeSnippet
  language="bash"
  code={`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](/docs/x402-payments) 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`](https://github.com/x402-foundation/x402):

<CodeSnippet
  language="tsx"
  code={`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](https://docs.cdp.coinbase.com/x402/buyer/mcp-payments):

<CodeSnippet
  language="tsx"
  code={`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](/docs/wallets/quickstart) ou uma [sessão de Agent Wallet](/docs/agent-wallets) 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](https://eips.ethereum.org/EIPS/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](https://docs.uniswap.org/contracts/v4/deployments) 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](https://developers.circle.com/gateway/nanopayments) 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](/gasless-transactions) 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](https://docs.x402.org/core-concepts/network-and-token-support) 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](https://stripe.com/blog/machine-payments-protocol) 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](https://openai.com/index/buy-it-in-chatgpt/) cobre uma fatia diferente: checkout para compras conduzidas por IA em vez de pagamentos de API por requisição.
- O [AP2 do Google](https://cloud.google.com/blog/products/ai-machine-learning/announcing-agents-to-payments-ap2-protocol) 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](https://github.com/google-agentic-commerce/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.

<EmbeddedTable
  table={{
    columns: [
      { key: "protocol", width: 100, title: "Protocol", dataType: "object" },
      { key: "steward", width: 180, title: "Steward", dataType: "object" },
      { key: "type", width: 180, title: "Payment type", dataType: "object" },
      { key: "job", width: 240, title: "Primary job", dataType: "object" },
      { key: "settles", width: 180, title: "Settles per request?", dataType: "object" },
    ],
    data: [
      {
        protocol: { title: "<p>x402</p>", tooltip: "", icon: "" },
        steward: {
          title: "<p>x402 Foundation (originalmente Coinbase)</p>",
          tooltip: "",
          icon: "",
        },
        type: { title: "<p>Stablecoins onchain</p>", tooltip: "", icon: "" },
        job: {
          title: "<p>Pagar por chamada de API, chamada de tool ou peça de conteúdo via HTTP ou MCP</p>",
          tooltip: "",
          icon: "",
        },
        settles: { title: "<p>Sim</p>", tooltip: "", icon: "" },
        id: 0,
      },
      {
        protocol: { title: "<p>MPP</p>", tooltip: "", icon: "" },
        steward: { title: "<p>Stripe e Tempo</p>", tooltip: "", icon: "" },
        type: {
          title: "<p>Cartões ou stablecoins, mesmo fluxo</p>",
          tooltip: "",
          icon: "",
        },
        job: {
          title: "<p>Pagar por requisição, agnóstico quanto ao método de pagamento</p>",
          tooltip: "",
          icon: "",
        },
        settles: { title: "<p>Sim</p>", tooltip: "", icon: "" },
        id: 1,
      },
      {
        protocol: { title: "<p>ACP</p>", tooltip: "", icon: "" },
        steward: { title: "<p>OpenAI e Stripe</p>", tooltip: "", icon: "" },
        type: {
          title: "<p>Cartões (via checkout da Stripe)</p>",
          tooltip: "",
          icon: "",
        },
        job: {
          title: "<p>Checkout de compras conduzido por agentes, não pagamento de API por requisição</p>",
          tooltip: "",
          icon: "",
        },
        settles: { title: "<p>Não, um checkout por compra</p>", tooltip: "", icon: "" },
        id: 2,
      },
      {
        protocol: { title: "<p>AP2</p>", tooltip: "", icon: "" },
        steward: {
          title: "<p>Google, com parceiros do setor</p>",
          tooltip: "",
          icon: "",
        },
        type: {
          title: "<p>Agnóstico quanto ao pagamento: cartões, transferências bancárias, stablecoins</p>",
          tooltip: "",
          icon: "",
        },
        job: {
          title:
            "<p>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</p>",
          tooltip: "",
          icon: "",
        },
        settles: {
          title: "<p>Não, autoriza um trilho em vez de liquidar ele mesmo</p>",
          tooltip: "",
          icon: "",
        },
        id: 3,
      },
    ],
  }}
/>

Conforme o panorama de protocolos evolui, o [AgentPay](/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](/overviews/x402-vs-mpp-comparing-agent-payment-protocols). Se você está escolhendo um provedor de infraestrutura, veja nossa [comparação de camada de wallet, gas e dados](/overviews/best-infrastructure-for-agentic-payments) 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](/docs/x402-payments) 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](/docs/data/transfers-api/transfers-endpoints/alchemy-get-asset-transfers) 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](https://docs.x402.org/core-concepts/facilitator) 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](https://docs.x402.org/core-concepts/network-and-token-support) é 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`](https://github.com/x402-foundation/x402/blob/main/specs/transports-v2/mcp.md) 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](https://docs.x402.org/core-concepts/http-402), e um [facilitator](https://docs.x402.org/core-concepts/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](/docs/agent-wallets) ou uma smart account programática através das [nossas Wallet APIs](/docs/wallets/quickstart), e combine com uma biblioteca de cliente x402 como `@x402/fetch` ou o comando `x402 request` da [Alchemy CLI](/docs/x402-payments). Confirme primeiro que seu facilitator alvo de fato suporta a network específica; o x402 v2 [cobre Ethereum](https://docs.x402.org/core-concepts/network-and-token-support), 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](/docs/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`](/docs/wallets/quickstart) 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](https://docs.x402.org/core-concepts/http-402), 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](/docs/data/transfers-api/transfers-endpoints/alchemy-get-asset-transfers), 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](/overviews/best-infrastructure-for-agentic-payments).

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

O [AP2](https://cloud.google.com/blog/products/ai-machine-learning/announcing-agents-to-payments-ap2-protocol) é 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](https://github.com/google-agentic-commerce/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](https://docs.x402.org/core-concepts/http-402) ou [MPP](https://stripe.com/blog/machine-payments-protocol) 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`](https://github.com/x402-foundation/x402), `@x402/axios`, ou o [wrapper de cliente MCP](https://docs.cdp.coinbase.com/x402/buyer/mcp-payments)), 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](https://docs.x402.org/core-concepts/http-402), 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](/docs/alchemy-cli), proteja suas tools com x402, e confirme a liquidação com [nossa Transfers API](/docs/data/transfers-api/transfers-endpoints/alchemy-get-asset-transfers). Ou pule a configuração de facilitator e aceite pagamentos de agentes através do [AgentPay](/agentpay). Para a stack mais ampla (custódia, trilho, gas e dados), comece com [melhor infraestrutura para pagamentos de agentes](/overviews/best-infrastructure-for-agentic-payments).