如何為 MCP server 加入 x402 付款功能：代理付款建置指南

發布於 2026年8月26日閱讀時間 5 分鐘

大多數 API 的計費方式都要求你先註冊：建立帳號、取得金鑰、之後收費。x402 跳過了這整套流程。伺服器可以改成按請求計費，不需要註冊、金鑰或發票。而且這已經在正式環境中運作：Coinbase 在 2025 年 5 月推出了它、Cloudflare 將它接進了自家的 Agents SDK，而我們的 agent gateway 就用它來向 agent 收取 RPC 與資料存取的費用。

本指南適用於任何要建構這場交易任一方的人：想要按次收費的 MCP server 或 API，或是需要付費的 agent。我們會先說明請求與回應的流程，接著展示實際程式碼，示範如何為工具呼叫收費、以 USDC 按次計量與結算、給 agent 一個可用來付款的錢包，以及像 AP2 這類其他支付協議在其中的定位。

x402 到底做了什麼？

HTTP 402 Payment Required 自 1990 年代起就存在於 HTTP 規格中，但從未真正被實作。x402 就是終於把它用起來的協議：

伺服器對未付款的請求回應 402 狀態碼，並附上機器可讀的價格
客戶端附上已簽署的付款並重新發送請求
伺服器驗證、結算，並在同一次交換中回傳資源

這裡沒有 session、沒有儲存的卡號、沒有儀表板，錢包本身就是帳號。在 x402 v2 中，相關資訊儲存在 HTTP headers 裡：

Header	Direction	Carries
`PAYMENT-REQUIRED`	伺服器至客戶端	價格、目標地址、網路，以及接受的付款方案，以 base64 編碼
`PAYMENT-SIGNATURE`	客戶端至伺服器	已簽署的付款內容，以 base64 編碼
`PAYMENT-RESPONSE`	伺服器至客戶端	結算結果，以 base64 編碼

這三個 header 是固定不變的。會變的是 PAYMENT-REQUIRED 裡承載的 JSON 中的 scheme 欄位，它告訴客戶端這次呼叫使用哪種計費模式。不論哪種方案，負責檢查與轉移款項的都是同一種第三方：facilitator，這是一個負責驗證客戶端已簽署付款、並提交鏈上結算的服務，讓賣方和客戶端都不必自己動手。方案之間的差異只在於 facilitator 檢查的內容以及結算的時機。

大多數呼叫使用 exact：價格是固定且事先已知的，因此客戶端直接針對那個確切金額簽署，也就按那個確切金額結算。以下是精簡至關鍵欄位的內容。amount 是 10,000 個最小單位，也就是 $0.01 USDC：

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

有些呼叫的費用是變動的，只有在工作完成後才知道實際金額，例如按產生 token 數量計費的 LLM 輸出。對這類情況，伺服器會使用 upto。內容看起來幾乎一樣，但 amount 現在代表的是客戶端同意的上限，而不是價格。這裡的上限是 $5.00：

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

客戶端只會針對那個上限簽署一次。伺服器完成工作後，facilitator 會結算實際金額（假設實際用量是 $1.20），並在移動任何款項前確認該金額低於或等於已簽署的上限。客戶端不需要簽署第二次；只有結算這一步才會填入實際數字。

第三種方案 batch-settlement，適用於高頻率、次分計費的場景，此時如果每次呼叫都要付 gas 費，成本反而會超過呼叫本身的費用。在 x402 scheme 中，買方先一次性存入一個 escrow 合約，針對每次請求簽署鏈下憑證，賣方則以批次的方式在鏈上兌現。Circle Gateway 針對同樣的需求採用了類似的 nanopayments 模式。

facilitator 本身從不持有資金，它只負責檢查已簽署的指令並執行。x402.org 提供了一個免費的公開 facilitator，僅供開發與測試網使用，Coinbase 的 CDP 則提供了一個含合規篩查的正式生產環境 facilitator。你可以將程式碼指向其中任何一個。

x402 的請求與回應流程如何運作？

握手流程分為九個步驟：

客戶端發出未附帶付款的資源請求。
伺服器以 402 Payment Required 回應，附上價格、目標地址，以及接受的付款方案。
客戶端針對其中一種接受的方案簽署付款，並附上簽章重新發送請求。
伺服器請 facilitator 驗證已簽署的付款是否符合其宣告的要求。
facilitator 回傳驗證結果。
伺服器執行工作（跑查詢、呼叫模型、產生報告）。
伺服器請 facilitator 在鏈上結算款項。
facilitator 回傳結算結果。
伺服器回傳資源，並附上結算收據。

在 HTTP 上,這個流程是透過 HTTP headers（PAYMENT-REQUIRED、PAYMENT-SIGNATURE、PAYMENT-RESPONSE）執行的。在 MCP 上，同樣的九個步驟則改以 JSON 執行：

未附帶付款的呼叫會回傳一個帶有 isError: true 及 PaymentRequired 內容的結果（相當於 PAYMENT-REQUIRED）
客戶端在 _meta["x402/payment"] 附上已簽署的付款，重新發送同一個呼叫（相當於 PAYMENT-SIGNATURE）
伺服器在 _meta["x402/payment-response"] 回傳附帶結算資訊的實際結果（相當於 PAYMENT-RESPONSE）

如何為 MCP server 加上 x402 付款？

這個範例對應一個常見的實際情境：一個混合免費與付費工具的 MCP server，例如一個提供免費基本查詢、但深度產生報告需要付費的研究或資料伺服器。

在這個範例中，generate_report 每次呼叫收費 $0.01，而 ping 保持免費，建構於開放的 x402 Foundation SDKs（不綁定特定 facilitator，因此你可以先接上免費公開 facilitator，之後再換成商業版本），並使用 Wallet APIs 的智能帳戶作為收款地址。

首先，準備收款用的錢包。@alchemy/wallet-apis（v5）可以讓你取得一個智能帳戶地址，全程不需要在伺服器上接觸私鑰：

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

接著把這個地址接進一個受 x402 保護的 MCP 工具。@x402/core 負責建構與驗證付款要求，@x402/evm 則為 EVM 鏈實作 exact 方案，而 @x402/mcp 會包裝一個工具處理函式，讓一般函式變成付費函式：

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) 只是把協議接到 transport 上。真正開啟 3000 埠並把 /mcp 轉發到 transport.handleRequest(...)（也就是下方客戶端呼叫的端點）的，是 Node 的 HTTP 監聽器。

任何沒有用 paid(...) 包裝的內容都會維持免費，因此你可以在同一個伺服器上混用付費與免費工具。可以先用 curl 或任何未附帶付款的 MCP 客戶端測試：你應該會收到一個要求付款的結果，而不是報告本身，這可以確認在接上真正付款客戶端之前，這個關卡已經生效。

如果你完全不想自己維護與 facilitator 的關係，又想在不必挑選單一協議的情況下同時支援 x402 及其他新興的 agent 支付協議，那正是 AgentPay 存在的目的：只要把它指向你現有的端點，它就能在單一整合中處理 x402、ACP、MPP 與 AP2 之間的協議轉換。

如何按次計量並向 agent 收費？

單一呼叫收取固定價格是最基本的情況。正式環境的伺服器還需要追蹤是誰付了款、付了多少，也不應該只靠 facilitator 的結算報告作為款項真的有移動的唯一證明。要驗證，需要追蹤：

定價方式。使用 exact 表示每次呼叫的固定價格，也就是上面的模式。當費用依呼叫內容而變動時（較長的報告會比較短的報告消耗更多 token），且你想事先授權一個上限、之後再結算實際用量，就使用 upto。當呼叫頻率高且金額低到逐筆在鏈上結算的成本會超過呼叫本身時，使用 batch-settlement。
歸屬與記帳。客戶端簽署的付款內容中包含付款地址。每次結算成功時，把它連同工具名稱、價格與結算結果一起記錄下來，你就能免費得到一份按 agent 分類的用量帳本：

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(),
    });
  },
},
});

不要只依賴結算回應作為唯一的判斷依據。facilitator 可能回報 settled: true，但請求本身卻回傳非 200 的狀態，反之亦然；在計入營收前應該同時檢查兩者。至於定期的對帳作業，我們的 Transfers API 可以讓你獨立確認實際到達你收款地址的內容，藉此抓出 facilitator 的結算報告與鏈上實際情況不一致的少數情況：

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

如何給 agent 一個可用來付款的 USDC 錢包？

一個需要向設有付費牆的端點付款的 agent，不論是你的還是別人的，都需要一個有資金的錢包，以及能在遇到 402 時進行簽署的程式碼（或 CLI）。

對於由人操作或本機測試的 agent，最快的方式是使用 Alchemy CLI。它會建立一個範圍受限的錢包 session，讓 agent 可以使用，而完全不需要接觸私鑰：

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 設定的是 CLI 最多會支付的金額，伺服器回傳的任何內容都無法把這個數字往上推。如果你在沒有人可以核准的情況下執行這個指令（--no-interactive），又忘了設定 --max-payment，CLI 只會直接停止，而不會付款，因為 402 回應中的價格來自你無法控制的伺服器，在你的限額檢查之前，任何東西都不應該去付這筆款項。完整的指令說明請參閱 x402 payments CLI 文件。

對於需要在沒有人核准每個 session 的情況下自主付款的後端 agent，可以用一個由簽署器支援的付款處理器來包裝 fetch（或你的 MCP 客戶端）。如果 agent 呼叫的是付費 HTTP 端點，使用 @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");

如果 agent 呼叫的是 MCP server 上的付費工具而非一般 HTTP 端點，就改成用同樣的方式包裝 MCP 客戶端,而不是 fetch。CDP 針對 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" },
});

把私鑰直接寫在環境變數中，對於測試網上的第一次測試或許還可以接受，但在正式環境中是不可接受的。對於正式環境的 agent，應該改用 Wallet APIs 的智能帳戶或 Agent Wallet session，將它放在同樣的簽署器介面之後，這樣 agent 就可以依照你設定的規則簽署，而完全不必自己持有私鑰。

如何在不讓 agent 持有 gas 的情況下以 USDC 結算？

每一筆鏈上交易都需要 gas：也就是像 ETH 這樣的原生代幣，由發送交易的一方持有，用來支付網路處理費用。這對按次付費 API 的 agent 來說是個問題。它不可能每次要付 $0.01 之前都先停下來去取得 gas 代幣，而預先囤積一批 gas 代幣以備不時之需，又違背了自動化流程的初衷。

USDC 結算透過 EIP-3009（transferWithAuthorization）繞過了這個問題：它讓 agent 可以簽署一筆轉帳，而不需要自己提交交易或持有任何 gas 代幣。agent 只需要簽署；由 facilitator 負責把該交易提交上鏈並支付其 gas。exact 與 upto 結算通常對 USDC 使用 EIP-3009，對其他不支援 EIP-3009 的 ERC-20 則使用 Permit2。batch-settlement 仍然是由 agent 針對每個請求簽署，之後賣方再於稍後於鏈上批次兌現，而不是逐筆結算。Circle Gateway 針對同樣的高頻率場景採用了類似的 nanopayments 模式。USDC 以美元計價這一點，也讓事情變得更簡單：雙方都不需要為一筆 $0.01 的費用去計算匯率。

以上涵蓋了付款本身。如果你的收款地址是一個普通的外部持有錢包，故事到此就結束了：它只是單純收 USDC，不涉及任何部署步驟。如果它是像本指南前面建立的那種智能帳戶，它在 x402 流程之外還會在另外兩個時刻涉及 gas：第一次收到資金時的鏈上部署，以及之後每次把收到的 USDC 匯出到金庫錢包時。我們的 Gas Manager 可以為這兩個時刻贊助 gas；但不論哪種情況，它都不涉及 x402 付款本身的結算，因為那部分已經由 facilitator 負責。

Base 是大多數工具中預設的網路，因為原始的參考 facilitator 就是在那裡運作，而且現有的 x402 整合大多也建立在那裡，但 x402 v2 並不只限於 Base。它同時涵蓋任何 EVM 鏈（包括 Ethereum 主網與 Polygon），以及 Solana、TON、Algorand、Stellar、Aptos、Hedera、Keeta、NEAR、Concordium 與 XRPL，隨著 facilitator 陸續加入支援，預期還會有更多鏈納入。至於「在 Ethereum 上以 USDC 付款」這個特定需求現在是否可行，取決於你選用的 facilitator 是否已實作該網路，而不是取決於協議本身。

x402 在更廣泛的 agent 支付體系中處於什麼位置？

x402 是這個快速發展領域中的其中一種協議，並非唯一選項。

Stripe 與 Tempo 打造了 MPP，這是同樣 402 模式的一個版本，但不侷限於穩定幣，賣方可以在同一套流程下接受信用卡或穩定幣（而且 MPP 與 x402 的 exact 流程向後相容，因此為其中一方打造的客戶端通常也能與為另一方打造的伺服器溝通）。
OpenAI 與 Stripe 的 ACP 涵蓋的是不同的部分：AI 驅動購物的結帳，而非按請求的 API 付款。
Google 的 AP2 則完全針對另一個問題：不論付款方式是信用卡、銀行轉帳還是穩定幣，都能用已簽署的 Checkout 與 Payment mandate 證明使用者授權了 agent 進行消費。AP2 並非競爭性的結算軌道；當 AP2 流程需要以穩定幣結算時，它會透過 Google 與 Coinbase、Ethereum Foundation 及 MetaMask 共同打造的 A2A x402 extension 來進行，因此 x402 是它底層的加密軌道，而不是它的替代方案。

Protocol	Steward	Payment type	Primary job	Settles per request?
x402	x402 Foundation（原為 Coinbase）	鏈上穩定幣	透過 HTTP 或 MCP 按 API 呼叫、工具呼叫或內容付費	是
MPP	Stripe 與 Tempo	信用卡或穩定幣，同一套流程	按請求付款，不限定付款方式	是
ACP	OpenAI 與 Stripe	信用卡（透過 Stripe checkout）	由 agent 驅動的購物結帳，而非按請求的 API 付款	否，每次購買一次結帳
AP2	Google，與產業合作夥伴	不限付款方式：信用卡、銀行轉帳、穩定幣	證明使用者授權了 agent 進行消費；底層透過 x402 或信用卡／銀行軌道結算	否，授權的是軌道本身，而非自行結算

隨著協議版圖持續演進，AgentPay 作為一個不限協議的代理層，協助商家一次整合就能支援所有這些協議。

如果你正在為特定專案在 x402 與 MPP 之間做選擇，可以參考我們的 x402 vs MPP 比較。如果你正在選擇基礎設施供應商，可以參考涵蓋 Alchemy、Coinbase Developer Platform、Circle、Crossmint、Privy 與 Turnkey 的錢包、gas 與資料層比較。

常見錯誤

絕對不要簽署一個你沒有自己檢查過的報價。402 回應只是一個由你無法控制的伺服器送出的數字；在簽署前先確認網路、資產與金額，就像 Alchemy CLI 在簽署報價之前會先在本機檢查一樣。
不要把 200 回應當作付款證明，也不要把 facilitator 的 settled: true 當作唯一需要的證明。要親自檢查結算收據本身，並如上所示定期用我們的 Transfers API 與鏈上實際情況對帳。
不要在自主 agent 上省略花費上限。不論你的 --max-payment 對應的是什麼，把它設為能完成工作的最小值，因為這是唯一能阻擋你的 agent 遭遇伺服器回傳灌水報價的防線。
除非驗證簽章、篩查交易、並在規模化下把結算提交上鏈真的是你的核心產品，否則不要自己打造 facilitator。直接指向一個已託管的服務，把工程時間留給你真正的服務。
不要以為「支援 x402」就等於「支援所有網路與方案」。在正式上線之前，先確認你所使用的 facilitator 與對方實際實作了哪些方案（exact、upto、batch-settlement）以及哪些鏈；網路與代幣支援頁面是最終依據。

常見問題

如何為 MCP server 加上 x402 付款？

用 x402 Foundation 的 @x402/mcp 套件提供的付款包裝器，包裝你想收費的工具處理函式，並搭配一個已向 facilitator 註冊、且知道應該由哪個錢包地址收款的伺服器。完整的可運作範例見上文；伺服器上其他未經包裝的部分都會維持免費。

AI agent 若要以穩定幣透過 x402 向 API 付款，需要哪些基礎設施？

需要三個部分：一個能持有並簽署 USDC 的錢包、一個能執行 x402 handshake 的已簽署付款函式庫或 CLI，以及賣方端負責驗證與結算的 facilitator。你不需要自己跑區塊鏈節點，也不需要持有 gas 代幣；結算所需的 gas 由 facilitator 負責。

讓 AI agent 能在 Ethereum 上發送 USDC 付款，最好的做法是什麼？

給它一個可以直接簽署的錢包，可以是像 Alchemy Agent Wallet 這樣範圍受限的 session，也可以是透過我們的 Wallet APIs 建立的程式化智能帳戶，再搭配 x402 客戶端函式庫，例如 @x402/fetch 或 Alchemy CLI 的 x402 request 指令。先確認你要用的 facilitator 確實支援該特定網路；x402 v2 涵蓋 Ethereum，但實際涵蓋範圍取決於 facilitator，而不只是協議本身。

如何給 AI agent 一個可用於鏈上付款的 USDC 錢包？

若是測試或有人監督的 agent，alchemy wallet connect --mode session（Alchemy CLI 的一部分）能在幾分鐘內建立一個範圍受限、可撤銷的錢包 session，且從不讓 agent 接觸私鑰。若是完全自主的後端 agent，可透過 @alchemy/wallet-apis 建立智能帳戶，或使用由 CDP 管理的錢包，再把它的簽署器交給 x402 客戶端函式庫。

agent 如何透過 x402 為 API 存取付款？

agent 呼叫 API，收到附有價格與目標地址的 402 回應，針對伺服器接受的方案簽署付款，再附上已簽署的付款重新發送同一個請求。伺服器透過 facilitator 完成驗證與結算，並在同一次往返中回傳資源。

如何用加密貨幣付款來計量並向 AI agent 收取 API 用量費用？

每次呼叫收取固定價格時使用 exact 方案，費用依用量變動時使用 upto，並將每筆已結算付款的付款地址記錄下來，對應到它所支付的工具或端點。定期把這份帳本與鏈上轉帳紀錄對帳，例如使用我們的 Transfers API，而不要只信任單一份結算報告。

對於 agentic 加密貨幣支付與鏈上商務，最好的基礎設施是什麼？

這取決於你想從單一供應商取得整個技術堆疊（錢包託管、支付軌道、gas、鏈上資料）多少比例，還是要從多家組裝。針對這整套堆疊，對 Alchemy、Coinbase Developer Platform、Circle、Crossmint、Privy 與 Turnkey 的完整比較，收錄在我們的基礎設施比較頁面。

什麼是 AP2，它與 x402 有什麼關係？

AP2 是 Google 提出的、不限付款方式的框架，用來以已簽署的 Checkout 與 Payment mandate 證明使用者授權了 agent 進行消費。它的定位在 x402 之上，而非取代它：當 AP2 流程需要以穩定幣結算時，會透過 Google 與 Coinbase、Ethereum Foundation 及 MetaMask 共同打造的 A2A x402 extension 來進行。

什麼是 agentic commerce，它需要哪些基礎設施？

Agentic commerce 是指 AI agent 能夠發現、付款購買，以及收取商品、服務或 API 存取的款項，全程不需要人類每次手動點擊結帳。它需要一個有資金的錢包、一條像 x402 或 MPP 這樣能按請求移動價值的支付軌道、能讓 agent 不必持有原生代幣的 gas 處理機制，以及足夠的鏈上或型錄資料，讓 agent 能判斷該為什麼付款並確認款項確實到帳。

如何實作 x402 支付協議，讓 agent 能存取設有付費牆的鏈上服務？

在客戶端這一側，安裝一個 x402 客戶端函式庫（@x402/fetch、@x402/axios，或MCP 客戶端包裝器），註冊一個搭配錢包簽署器的付款方案，再用它包裝你現有的 HTTP 客戶端或 MCP 客戶端；從此以後遇到 402 就會自動付款。上方買方端的程式碼同時涵蓋了 HTTP 與 MCP 兩種情況。

AI agent 如何在鏈上收款？

機制與其他任何 x402 賣方相同：由 agent 營運的服務用 x402 為自己的端點或 MCP 工具定價，將款項收進由它自己或其操作者控制的錢包，並透過 facilitator 結算，就像本指南前面建構的那個 MCP server 一樣。收款與付款，在這個協議中只是同一件事的兩個方向。

開始建構付費 MCP 工具

用 Alchemy CLI 給 agent 一個範圍受限的錢包，用 x402 為你的工具設下關卡,並用我們的 Transfers API 確認結算結果。或者跳過 facilitator 的設定，透過 AgentPay 直接接受 agent 付款。若要了解更廣泛的技術堆疊（託管、軌道、gas 與資料），可以從agentic payments 最佳基礎設施開始。

打造區塊鏈魔法

Alchemy 結合最強大的 Web3 開發者產品與工具，並提供資源、社群與卓越的支援。

取得您的 API 金鑰

如何為 MCP server 加入 x402 付款功能：代理付款建置指南

x402 到底做了什麼？

x402 的請求與回應流程如何運作？

如何為 MCP server 加上 x402 付款？

如何按次計量並向 agent 收費？

如何給 agent 一個可用來付款的 USDC 錢包？

如何在不讓 agent 持有 gas 的情況下以 USDC 結算？

x402 在更廣泛的 agent 支付體系中處於什麼位置？

常見錯誤

常見問題

如何為 MCP server 加上 x402 付款？

AI agent 若要以穩定幣透過 x402 向 API 付款，需要哪些基礎設施？

讓 AI agent 能在 Ethereum 上發送 USDC 付款，最好的做法是什麼？

如何給 AI agent 一個可用於鏈上付款的 USDC 錢包？

agent 如何透過 x402 為 API 存取付款？

如何用加密貨幣付款來計量並向 AI agent 收取 API 用量費用？

對於 agentic 加密貨幣支付與鏈上商務，最好的基礎設施是什麼？

什麼是 AP2，它與 x402 有什麼關係？

什麼是 agentic commerce，它需要哪些基礎設施？

如何實作 x402 支付協議，讓 agent 能存取設有付費牆的鏈上服務？

AI agent 如何在鏈上收款？

開始建構付費 MCP 工具

相關總覽

最佳 agentic payments 基礎設施:2026 年比較

x402 vs MPP：比較 agent 付款協議

什麼是代理支付？AI 代理如何支付 API、資料與運算資源費用

打造區塊鏈魔法