甚麼是 x402？HTTP 402 支付協議的運作原理

x402 是一個透過普通 HTTP 按次收費的開放支付標準，不需要帳戶或 API 金鑰。伺服器以 402 Payment Required 回應並附上價格，客戶端簽署一筆穩定幣付款後再次發送請求，伺服器隨即回傳結果。x402 由 Coinbase 創建，現時由 Linux Foundation 旗下的 x402 Foundation 負責管理。

由於整個過程只是普通的 HTTP 加上一個簽名，軟件無需有人填寫表格就能付款。x402 文件在可以用它開發的項目中，列出了自行付費取用 API 的智能代理，與按次收費的 API 和付費牆內容並列。

誰創建了 x402，現在由誰營運

2025 年 5 月 6 日。 Coinbase 公布了 x402，這個開放標準把 HTTP 原本的 402 狀態碼用於穩定幣付款。在發布討論串中，付款經由 X-PAYMENT 標頭傳送，伺服器可以自行結算，也可以把結算交給一種稱為結算方（facilitator）的服務。
2025 年 9 月 23 日。 Cloudflare 表示正與 Coinbase 合作成立 x402 Foundation，並在其 Agents SDK 和 MCP 伺服器中加入了 x402 付款。
2025 年 12 月 11 日。 第 2 版推出，@x402/core SDK 的 2.0.0 版在同日發布到 npm。V2 把所有付款資料移到 HTTP 標頭中，棄用舊的 X- 標頭，改用 eip155:84532 這類標準網絡識別碼，而參考 SDK 仍然向後兼容 V1。
2026 年 4 月 2 日。 Linux Foundation 宣布成立 x402 Foundation，由 Coinbase 貢獻這個協議。公告列出 22 個表達初步意向和支持的機構，包括 Visa、Mastercard、Stripe、Google、AWS、Shopify、Circle 和 Cloudflare。
2026 年 7 月 14 日。 Linux Foundation 宣布 x402 Foundation 正式運作：Coinbase 已完成貢獻這個協議，並已有 40 個機構加入成為會員。

程式碼現存放在 x402-foundation/x402 儲存庫，採用 Apache-2.0 授權。常見問題直接回答了與 Coinbase 的關係：標準由 Coinbase 創建，但 x402 不是 Coinbase 的產品，使用它也不需要任何 Coinbase 產品。

有些指南把推出時間定在 2025 年底，也有些說結算方是在 V2 才首次出現。2025 年 5 月的公告和發布討論串顯示，x402 當時已經推出，結算方也從一開始就存在。402 狀態碼本身的歷史則久遠得多，我們的 HTTP 402 指南介紹了它的來龍去脈。

x402 付款如何運作

參與的有三方。客戶端通常是買方，負責提出請求並簽署付款。伺服器是賣方，負責報價、檢查付款並提供結果。結算方可以代伺服器核實和結算付款，讓伺服器無需自行與區塊鏈打交道。

以下是結算方文件列出的流程：

客戶端請求某項資源，例如一個 API 端點。
伺服器以 402 回應，並在 PAYMENT-REQUIRED 標頭列出它接受的條件：付款方案、價格、網絡和收款地址。
客戶端選擇其中一個選項，簽署付款載荷（payload），再以 PAYMENT-SIGNATURE 標頭重新發送同一個請求。
伺服器自行檢查載荷，或把它提交到結算方的 /verify 端點。
如果付款有效，伺服器便執行工作。
伺服器在鏈上結算付款，可以直接進行，也可以透過結算方的 /settle 端點。結算方會提交交易並等待確認。
伺服器回傳 200，附上結果和描述結算情況的 PAYMENT-RESPONSE 標頭。如果結算失敗，則回傳 402 和錯誤詳情。

請留意第 5 步在第 6 步之前。對下文介紹的固定價格、計量和批量方案來說，預設做法是先核實簽名、提供回應，之後才收款。固定價格的伺服器可以選擇先結算，文件稱之為「預付」（upfront）流程；可退款的方案則會在提供服務前先把款項收進託管。

至少有一份指南描述由客戶端把交易發送到區塊鏈。在 x402 中，客戶端只負責簽名；提交付款的是伺服器或其結算方。

標頭	發送方	內容
`PAYMENT-REQUIRED`	伺服器	接受的條件和價格
`PAYMENT-SIGNATURE`	客戶端	已簽署的付款
`PAYMENT-RESPONSE`	伺服器	結算結果

每個標頭都載有 Base64 編碼的 JSON（x402 文件中的 HTTP 402）。想看真實的標頭解碼後是甚麼樣子，可參考我們的 HTTP 402 指南，我們在文中擷取並解碼了一個真實的質詢。

四種付款方案

付款方案為一項資源設定付款規則：買方授權多少金額，以及賣方何時收款。截至 2026 年 11 月，文件定義了四種方案。

方案	適用於	款項何時轉移
`exact`	固定價格：一次 API 調用、一個檔案、一個頁面	按次結算，通常即時進行
`upto`	在運行過程中計量的單次請求，例如 LLM 的 token 用量或運算時間	買方簽署一個上限，賣方按實際金額結算
`batch-settlement`	同一買方的大量小額調用	買方存款一次，賣方之後在鏈上分批兌現
`auth-capture`	可能需要退款的購買	款項先存入託管，交付後再扣款、作廢或退款

四種方案中有三種是最近才加入的。upto、batch-settlement 和 auth-capture 的規格分別在 2026 年 3 月、4 月和 5 月加入儲存庫。

batch-settlement 專為小額支付而設。在 EVM 鏈上，買方先一次過把資金存入鏈上託管，之後每次請求都簽署一張鏈下憑證，賣方稍後在一筆交易中兌現多張憑證。閒置的通道可以退款。auth-capture 建基於 Base 的 commerce-payments 託管合約；它適用於 EVM 鏈，截至 2026 年 11 月已加入 TypeScript 和 Go 的 SDK，但 Python 尚未支援。

退款方式取決於付款方案。exact 付款是推送式付款，一經執行便無法撤回，所以退款就是由賣方另發一筆轉帳退回。

Cloudflare 在 2025 年提出過一個「延後」（deferred）方案，舉的例子是爬蟲每天結帳一次。它不在現時的四種方案之列。2026 年 4 月加入 batch-settlement 的拉取請求由 Cloudflare 提案的其中一位作者提交，當中說明這個方案的設計旨在統一各個延後結算的提案，並包含一個 Cloudflare 網絡綁定（network binding）。

我們的建議是按你在甚麼時候知道價格來選擇。回應之前已經定好的價格，適合 exact。費用在單次請求中不斷增加，適合 upto。同一買方的數以千計調用，適合 batch-settlement；有可能無法交付的銷售，則適合 auth-capture。

結算方的作用和收費

文件稱結算方為「可選但建議使用」（optional but recommended）。伺服器可以自行核實簽名並在鏈上結算；有了結算方，它就不需要自己連接區塊鏈。

結算方不持有資金。它只按照買方簽署的載荷行事，而常見問題指出，如果結算方篡改付款，就會通不過簽名檢查，也無法結算。任何人都可以運行結算方。文件列出 19 個正式環境結算方，並表示清單並不完整。

x402.org 上的公共結算方是供測試用的。2026 年 11 月 11 日，它自己列出的支援網絡包括 Base Sepolia、Solana Devnet，以及 Algorand、Aptos、Stellar、Hedera 和 XRPL 的測試網；常見問題亦指出它不支援 Base 主網。

協議本身不收任何費用；文件說這個標準「內置 0 費用」（0 fees built in）。下一層是 gas：在 EVM 鏈上，標準的轉帳方法（EIP-3009，或其他 ERC-20 代幣使用的 Permit2）讓付款方無需支付 gas，因為 gas 由結算方代付。Permit2 還需要一次性的授權（approval），文件指出可以透過兩個代付 gas 的擴展讓這一步也無需 gas。

結算方的收費因服務商而異。Coinbase 的 CDP Facilitator 每月首 1,000 筆鏈上交易免費，之後每筆鏈上交易收費 $0.001。核實永遠免費，而使用 batch-settlement 時，一筆鏈上交易可以處理數以千計的付款。它還會以 OFAC 和 KYT 檢查篩查每一筆付款。

至少有一份指南說結算方收取付款金額的 0.1% 至 1%。Coinbase 的結算方則是按每筆鏈上交易收費，而文件清單上有好幾個結算方標明完全不收費。

x402 有代幣嗎？

截至 2026 年 11 月 11 日，我們沒有找到屬於 x402 協議的代幣。它的文件描述的是 Apache-2.0 授權的軟件，付款使用 USDC 等現有代幣，而 Linux Foundation 的公告講的是貢獻一個協議。

圍繞 x402 推銷的代幣都是第三方項目。開發者從 2025 年開始推出以 x402 為主題的代幣，CoinGecko 在同年新增了「x402 代幣」（x402 tokens）類別。所以如果你想問「可以在 Coinbase 上買 x402 嗎？」，據我們所知並沒有協議代幣可以買，標準的文件中也沒有出現以這個名稱交易的東西。我們不討論代幣價格。

如何實作 x402

參考 SDK 有 TypeScript、Python 和 Go 版本。伺服器中介軟件支援 Express、Hono、Next.js、Fastify、Gin、net/http、Echo、FastAPI 和 Flask；客戶端支援 fetch、Axios、Go 的 net/http、httpx 和 requests（SDK 功能）。

在賣方這一邊，每條路由都要設定價格和收款地址。以下內容節錄自賣方快速入門：

import { paymentMiddleware, x402ResourceServer } from "@x402/express";
import { ExactEvmScheme } from "@x402/evm/exact/server";
import { HTTPFacilitatorClient } from "@x402/core/server";

// Create facilitator client (testnet)
const facilitatorClient = new HTTPFacilitatorClient({
  url: "https://x402.org/facilitator"
});

app.use(
  paymentMiddleware(
    {
      "GET /weather": {
        accepts: [
          {
            scheme: "exact",
            price: "$0.001",
            network: "eip155:84532", // Base Sepolia
            payTo: evmAddress,
          },
        ],
        description: "Weather data",
        mimeType: "application/json",
      },
    },
    new x402ResourceServer(facilitatorClient)
      .register("eip155:84532", new ExactEvmScheme()),
  ),
);

在買方這一邊，買方快速入門會包裝 fetch，所以讀取 402、付款和重試都無需額外的程式碼：

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

const signer = privateKeyToAccount(process.env.EVM_PRIVATE_KEY as `0x${string}`);
const client = new x402Client();
client.register("eip155:*", new ExactEvmScheme(signer));

const fetchWithPayment = wrapFetchWithPayment(fetch, client);
const response = await fetchWithPayment("https://api.example.com/paid-endpoint", {
  method: "GET",
});

過程中要注意幾件事：

USDC 是最常用的資產，但賣方可以接受 EVM 網絡上的任何 ERC-20 代幣，或 Solana 上的任何 SPL 代幣。
上主網時，要更改網絡識別碼（Base 主網是 eip155:8453），並從公共結算方轉用正式環境的結算方，或自行結算。
較舊的 V1 伺服器使用 X-PAYMENT 標頭和 base-sepolia 這類名稱。參考 SDK 仍然能讀取 V1，遷移指南列出了各項改動。
客戶端一旦發送了 PAYMENT-SIGNATURE，逾時並不代表付款失敗。客戶端與伺服器文件指出，應把結果視為未知，絕不自動再付一次；settlement_pending 狀態也不代表失敗。
想讓智能代理找到你的服務，可以看看 x402 的發現層 Bazaar。支援它的結算方會列出經它們登記的服務，任何結算方也可以運行自己的 Bazaar。

開發前要知道的限制

付款和交付是兩個獨立的步驟。2026 年 3 月，一位開發者在一個 GitHub issue 中指出，伺服器可以結算後甚麼也不回傳，「協議層面沒有託管、沒有條件放款、沒有爭議機制」（no escrow, no conditional release, no dispute mechanism at protocol level）。兩個月後加入、帶有託管和退款功能的 auth-capture，就是針對這個風險而設的方案。
x402 沒有原生的入金或出金通道連接銀行資金；常見問題指出，結算方或閘道可以加入這項功能。
使用量數字都是公司自己的說法。V2 公告稱 x402 在推出後的頭幾個月處理了超過 1 億筆付款。截至 2026 年 11 月，Coinbase 的結算方頁面表示，它在 Base 和 Solana 上已處理超過 1 億筆交易和 2,800 萬美元的付款額。
發現機制仍處於初期：文件形容 Bazaar「仍在早期開發階段」（in early development）。

一條鏈支援 x402 需要甚麼，QDay 又處於哪個位置

網絡頁面把兩件事分開來談。協議層面的支援範圍很廣：任何 EVM 鏈都可以憑其 eip155 識別碼接入，此外還有 Solana、TON、Algorand、Stellar、Aptos、Hedera、NEAR、XRPL 等。正式環境的支援要求更多：在該網絡上要有一個可行的結算方式，可以是由服務商營運的結算方、你自己的結算方，或在你自己的伺服器上結算。

文件為新 EVM 網絡列出的檢查清單很短。要知道你會接受哪種代幣，以及它支援 EIP-3009 還是需要 Permit2。要有正式環境的結算路徑。要決定是以明確的代幣數量定價，還是貢獻一個預設資產，讓 "$0.001" 這類美元價格可以運作。自行運行結算方需要該網絡的 RPC 端點，以及一個持有原生代幣、用來代付 gas 的錢包。

QDay Aevum 兼容 EVM，鏈 ID 為 44005，所以在協議層面，x402 會以 eip155:44005 來識別它。QDay 的路線圖涵蓋結算這一邊：x402 結算方和 QDay 上的 x402 付款都即將推出。Aevum 測試網現已上線，QDay 的簽名已有一條遷移到後量子 ML-DSA 的路徑，主網計劃於 2027 年推出。想了解智能代理付款的全貌，請看〈智能代理如何付款〉。

甚麼是 x402？HTTP 402 支付協議如何運作