一句 reserved for future use 放了 25 年：x402 把 HTTP 402 變成 agent 的付款握手

1997 年 1 月出版的 RFC 2068，也就是 HTTP/1.1 的第一份規格，替 402 Payment Required 寫的說明只有一行：「This code is reserved for future use.」2022 年 6 月，現行的 HTTP 語意標準 RFC 9110 出版，15.5.3 節還是同一個意思：「The 402 (Payment Required) status code is reserved for future use.」

中間隔了 25 年又 5 個月。這個狀態碼的定義，進度是零。

網路上要錢的地方從來沒少過，付費牆、按次計費的 API、訂閱制的雲端服務都是。要把這 25 年的空白解釋成「沒人需要在網路上收錢」，說不通。

402 這個名字暗示的是一種畫面：伺服器說「這要錢」，你在同一段對話裡把錢補上，東西就給你。這個畫面卡住的地方很單純。付錢的是人，人得離開這一頁去掏卡，付完回來，已經是另一個請求了。

現在，發請求的那一方越來越常不是人。

同一個 402，兩份內容

x402 做的事，就是把 402 當年留白的那一頁填上。README 第一句是這樣講的：

“x402 is an open standard for internet native payments. It aims to support all networks (both crypto & fiat) and forms of value (stablecoins, tokens, fiat).”

把兩個版本的 402 並排，差距一眼就看得出來：

	RFC 2068／RFC 9110 的 402	x402 的 402
規格寫了什麼	一句 reserved for future use	一套 12 步的請求、驗證、結算流程
402 回應裡帶什麼	沒有定義	`PAYMENT-REQUIRED` header，內含 base64 編碼的 `PaymentRequired` 物件
client 收到後做什麼	沒有定義	從伺服器給的多個 `PaymentRequirements` 挑一個，依 `scheme` 與 `network` 組出 `PaymentPayload`
錢怎麼交出去	沒有定義	把 `PAYMENT-SIGNATURE` header 加在同一個 HTTP 請求上重送
付完拿到什麼	沒有定義	`200 OK` 與原本要的資源，`PAYMENT-RESPONSE` header 帶 base64 編碼的結算結果

左邊那欄一路「沒有定義」，是真的沒有。RFC 2068 那一節就只有那一行字。

右邊那欄最關鍵的是第四列。舊的網頁付款流程像去看電影：門口的人說你沒票，請你到隔壁櫃台排隊買，買完再回來重新排一次入場。x402 比較像捷運閘門，閘門自己把票價和收哪幾種卡顯示出來，你在同一道門前刷一下，門就開了。你沒有被帶去任何地方。

對 agent 來說，要緊的就是這一列。「發請求、收到 402、簽一個付款物件、帶著它重送」整串動作，就是一個 HTTP client 的重試迴圈。README 列的技術目標裡有一條寫得很直白：整合成本要壓到 server 端 1 行、client 端 1 個函式。能不能真的壓到這麼低，我沒辦法替它背書。這篇的依據只有 README 跟 Linux Foundation 的新聞稿，官方的 TypeScript、Python、Go SDK 一個都沒有實際跑過，也沒有真的付過一筆錢。但目標設在這裡，設計的重心就清楚了：付款要長得像一次普通的重送。

402 從 HTTP 誕生就在嗎

這一段是我自己的訂正。

站上之前寫 RSL 那篇的時候，我寫了「402 Payment Required 從 HTTP 誕生就掛在規格裡」。這次為了開頭那個年份回頭翻 RFC，RFC 1945（1996 年 5 月，HTTP/1.0）列出的狀態碼是 200、201、202、204、300、301、302、304、400、401、403、404、500、501、502、503。401 後面直接跳 403，沒有 402。

它在 RFC 裡以正式條目出現，我查得到的是 1997 年 1 月的 RFC 2068。更早的 HTTP 草稿我沒有去翻，所以不敢說 402 的概念最早出現在哪一年，只能說「從 HTTP 誕生就在」這句話，拿 RFC 1945 對不起來。開頭用 1997 而不用 1996，原因就在這裡。

中間多了一個 facilitator

x402 的 12 步流程裡，除了 client 和 resource server，還多了一個角色叫 facilitator。README 的定義是「一台替一個或多個網路處理付款驗證與執行的伺服器」。

它出現在兩個位置。第 5 步，resource server 收到付款物件之後要驗證，可以自己在本地驗，也可以把 PaymentPayload 和 PaymentRequirements POST 到 facilitator 的 /verify。第 8 步，要結算的時候，resource server 可以自己去跟區塊鏈打交道，也可以 POST 到 facilitator 的 /settle，由它把付款送上鏈、等鏈上確認、再把執行結果回傳。

兩個位置都寫了「也可以自己來」。facilitator 是選配的。

那它存在的意義是什麼？六條設計原則裡「易用」那一條給了答案：

“This means abstracting as many details of crypto as possible away from the client and resource server, and into the facilitator. This means the client/server should not need to think about gas, rpc, etc.”

有點像超商代收帳單。電力公司不必自己開櫃台收現金，你也不必跑去電力公司，超商把收款跟入帳這段接過去。一個只想賣 API 的開發者，大概不會想為了收錢去研究 gas 費怎麼估、該連哪個 RPC 節點，facilitator 就是讓他可以不用碰這些的那一層。

這個類比有個地方要特別小心，不然會把它想成另一種東西。超商代收的時候，錢確實經過超商的手。x402 的設計原則明文不允許這件事：

“Trust minimizing: all payment schemes must not allow for the facilitator or resource server to move funds, other than in accordance with client intentions”

也就是說，facilitator 的工作範圍被規定在「照 client 的意思」之內，這條限制對 resource server 一樣適用。至於它在每一種 scheme 裡具體靠什麼機制守住，要讀 specs/schemes/ 底下的個別規格（README 指向 scheme_exact_evm.md 當 EVM 上 exact 的完整規格），我沒有讀到那一層，這篇就不替它下結論。

scheme 本身也是可以擴充的欄位。README 舉了三種：exact 是轉一筆固定金額，例子是「付 1 美元讀一篇文章」；upto 是每次請求授權一個上限，賣方事後照實際用量結算，不超過那個上限；batch-settlement 限 EVM，用託管加鏈下憑證，讓賣方把很多筆小額收費累積起來分批上鏈兌現，不必每個 HTTP 請求各結一次。

第三種最能看出這個協定在想像什麼樣的客人。假設一個 agent 短時間內要打很多次 API，每次都各自上鏈結算，每一筆都得等確認，這樣的節奏很難撐住高頻呼叫。批次結算看起來就是替「高頻、小額、沒有人盯著」的付款方準備的，這是我從它的描述推回去的讀法，README 沒有這樣講。

我會盯著的地方

我的立場是：x402 最值得抄的設計，是讓付款搭同一個請求的便車，重試就是付款。這讓付款可以塞進任何既有的 HTTP client 裡，不需要 session、不需要跳轉、不需要一個人坐在螢幕前。facilitator 做成選配，也讓它不至於變成一道必經的收費站。

這個判斷有個前提，我會一直拿它來檢查。README 設計原則的第一條寫著它「will never force reliance on a single party」，而流程上 facilitator 確實可以不用。但選配不代表實際上沒人依賴，要是哪天看到公開數據顯示絕大多數交易都走同一兩家 facilitator，這條原則就只剩紙面，我對這個協定「中立」的評價會跟著往下修。目前我手上沒有 facilitator 分布的數據，這一點只能先記著。

另一個讓我多看了兩眼的數字，來自 Linux Foundation 的新聞稿。Solana 基金會在裡面說自己「driving nearly 65% of x402 transaction volume this year」。這是 Solana 基金會的自述，統計期間是新聞稿發布當年，不是 Linux Foundation 或 Coinbase 的官方統計。就算照單全收，它說的也是交易量集中在某一條鏈，跟 facilitator 集不集中是兩回事，不能混在一起看。

從一家公司的 repo，變成一個基金會

x402 的規範倉庫現在是 x402-foundation/x402。依 GitHub API 在 2026 年 9 月 27 日的資料，Apache-2.0 授權，6,650 顆星、2,081 個 fork、581 個 open issue，最後一次 push 在 9 月 25 日。它的建立時間戳是 2025 年 2 月 21 日，那是原本 Coinbase repo 建立的時間，轉到基金會名下時保留了下來。

Coinbase 帳號底下的 coinbase/x402 還在，README 開頭掛著一段聲明：

“We’ve moved the x402 repo under the x402 Foundation repo. All issues and PRs were transferred here… Our repo (coinbase/x402) is now a development fork.”

原作者自己的帳號，降格成開發用的 fork。治理權是實際移交了，不只是掛名。

移交的公開時間點是 2026 年 4 月 2 日。Linux Foundation 在紐約的 MCP Dev Summit North America 上宣布成立 x402 Foundation，新聞稿說這個協定「initially developed by Coinbase, Cloudflare, and Stripe」。GitHub 上 x402-foundation 這個組織的建立時間是 4 月 1 日，比宣布早一天。

那天列出的是表達初步意向的支持組織，還不是正式會員。名單裡最讓我停下來的，是這幾個名字排在一起：Visa、Mastercard、American Express，旁邊是 Circle、Solana Foundation、Base。傳統卡組織和加密貨幣基礎設施，簽在同一份支持名單上。

把這份名單跟 README 那條「網路、代幣、貨幣不可知」的原則對著讀，會讀到一個有意思的句子：

“x402 may extend support to fiat based networks, but will never deprioritize onchain payments in favor of fiat payments.”

卡組織簽了名，規格卻白紙黑字寫著鏈上支付的優先度不會為法幣讓路。這兩件事現在可以並存，因為法幣網路的支援還停在「may extend」。哪一天真的有卡組織的 scheme 送進 specs/schemes/，這句話會不會被重新討論，是這個基金會第一個值得看的治理考題。這一段是我的推測。

順帶交代一下它跟站上另外兩篇的位置。AP2 那篇談的是 agent 有沒有被你授權去付這筆錢、授權鏈長什麼樣，x402 在那篇只出現在一句話裡：AP2 規格標明跟它接得起來，sample 目錄下有一條 human-not-present/x402/ 路徑。RSL 那篇談的是內容授權條款怎麼寫給機器讀，x402 在那裡只是 <accepts> 欄位的一個範例值。x402 管的是更底下那一層：錢在一來一回的 HTTP 之間，具體怎麼轉手。