【Agentic Payment 系列 #1】HTTP 402 沉睡三十年後醒來：x402 如何讓支付成為網際網路的一等公民

1997 年，HTTP/1.1 被標準化的那一天，一群有遠見的架構師在狀態碼列表中悄悄埋下了一顆種子：402 Payment Required。

那是一封寫給未來的信。寄件者包括 Tim Berners-Lee 等人，收件者是「一個擁有原生支付層的網際網路」。信的內容很簡單：這個世界終將需要讓價值交換像資訊傳遞一樣自然地嵌入 HTTP 協議。問題是，這封信等了將近三十年，才終於被拆開。

---

一封等了三十年的信：HTTP 402 的前世今生

如果你寫過任何 HTTP 處理邏輯，你一定對 401、403、404 這些狀態碼瞭如指掌。但夾在 401 和 403 之間的那個 402，多數工程師只知道它「保留供未來使用」，但卻不知道什麼時候會需要用到它。

402 代表的是 Payment Required，代表存取這項資源需要先付款。 它的存在，透露了一個被長期遺忘的野心：網際網路應該內建一個支付層。資訊傳遞有 HTTP，名稱解析有 DNS，通訊加密有 TLS，唯獨價值交換，在網際網路的協議層面完全空白。

缺口的原因不是缺乏遠見（否則 402 就不會存在了），而是當年網際網路出現時基礎設施的缺乏。1997 年沒有去中心化的 Settlement Network（結算網路），沒有可程式化的數位貨幣，更沒有足以支撐微型支付的低成本區塊鏈。於是，電子商務被迫走上了我們都熟悉的替代路線：信用卡、PayPal、Stripe(或是台灣人熟悉的顏色系列：綠界、藍新) —— 每一筆交易都仰賴可信第三方中介。

這套系統支撐了 Web 2.0 時代。但它有一個致命的結構性盲點：手續費有下限。

當 Visa 每筆交易收取 $0.15 + 2.9% 時，任何低於 $1 的支付都不具經濟可行性。你想為一次 API 調用收費 $0.003？抱歉，光是支付手續費就比你的定價高了五十倍。

這正是 Micropayments（微型支付）三十年來始終無法起飛的死穴。

---

Agent 經濟的崛起：為什麼是現在

三十年過去了，兩個結構性變化讓 HTTP 402 重新成為焦點。

變化一：區塊鏈基礎設施的成熟

Ethereum L2（如 Base）與 Solana 等高效能區塊鏈上，單筆交易的 Gas 費用已降至 $0.0001 以下，而 USDC 等 Stablecoin（穩定幣）提供了價格穩定的結算媒介（動區）。

當每筆鏈上結算的成本低於一粒米的價格，Micropayments 的技術條件終於到位。

變化二：AI Agent 的爆發

第二個變化更具顛覆性。AI Agent（AI 代理人）需要在毫秒級的時間內完成 API 調用的發現、談判與支付。它不會填寫信用卡表單，不會點擊「我同意條款」，更不會坐在螢幕前等待人工審核。它需要的是一個能像 HTTP 請求一樣無縫、無人值守的支付通道。

當然，你也可以讓你的 Agent 學會操作瀏覽器、填寫 Stripe Checkout 頁面 —— 就像你也可以讓一台自駕車學會用手指轉方向盤一樣。技術上可行，架構上荒謬。

2025 年 5 月，Coinbase 正式發布了 x402 協議。同年 9 月，Coinbase 與 Cloudflare 聯合成立 x402 Foundation，吸引了 Google、Visa、Circle 與 Anthropic 等巨頭共同維護這一跨鏈、跨代幣且與貨幣無關的支付框架。

而這份會員名單本身，就是一個值得玩味的訊號。在 x402 Foundation 的 Premier Members 中，你會同時看到三股原本壁壘分明的勢力並肩而立：

• 傳統支付巨頭：Visa、Mastercard、American Express、Stripe、Adyen、Fiserv：掌握全球刷卡結算網路的老牌玩家
• 雲端與基礎設施：AWS、Google、Cloudflare、Shopify：網際網路的底層管道與電商入口
• 加密原生陣營：Coinbase、Circle、Ripple、Solana Foundation、Stellar、Monad Foundation、MoonPay：提供 Stablecoin 與鏈上結算的新勢力

耐人尋味的是，這三股勢力在傳統敘事裡本該是彼此的競爭者甚至顛覆對象。加密貨幣曾被視為要「取代」Visa 與銀行，而如今它們卻共同坐上了同一張治理桌。這說明 x402 觸及的不是某個利基市場，而是一個所有玩家都不願缺席的結構性轉變：當支付方從人類變成 Agent，沒有人能確定舊有的護城河還守不守得住。與其被顛覆，不如一起定義新標準。

HTTP 402 的信，終於被拆開了。

---

x402 協議：把支付語義嵌入 HTTP

x402 的設計哲學只有一句話：讓支付成為 HTTP 協議的一等公民。

不是在 HTTP 之上疊加一個支付 SDK，不是重新發明一個傳輸協議，而是直接利用 HTTP 既有的 Request-Response 循環，將支付證明嵌入 Header。對於任何已經會寫 REST API 的開發者而言，接入 x402 不比加一個 Authorization Header 困難太多。

三方互動模型

x402 的架構建立在三個角色之上：

角色	說明
Client	發起請求的一方，通常是 AI Agent 或自動化腳本
Resource Server/Seller	提供付費內容或 API 的端點
Facilitator（促成者）	關鍵抽象層，負責驗證支付載荷並在鏈上執行結算

Facilitator 的存在是 x402 架構中最巧妙的設計。它讓 Resource Server 不需要自行維護區塊鏈節點、不需要理解 EIP-3009 的簽署邏輯、甚至不需要擁有自己的鏈上錢包。Resource Server 只需要做自己擅長的事 —— 提供內容與服務 —— 把「錢的事」全權委託給 Facilitator。

這就像是餐廳接受信用卡一樣：餐廳不需要理解 Visa 的結算協議細節，它只需要看到刷卡機顯示「已核准」。

---

交易流程：從 402 到 200 的七步之旅

x402 將支付語義直接嵌入 HTTP 的 Request-Response 循環中，其標準化流程在 SDK 層級可濃縮為七個關鍵步驟：

#	步驟	方向	說明
1	初始請求	Client → Server	標準 HTTP 請求（GET /api/premium-data），Header 中不含任何支付資訊
2	402 挑戰	Server → Client	回傳 402 Payment Required，Header 內含價格、受款地址、區塊鏈 ID 與代幣合約 —— 完成 Discovery
3	離線簽署	Client 本地	x402 SDK 以 EIP-3009 授權模式簽署支付授權，無需持有 ETH（Gasless）
4	帶簽名重試	Client → Server	重送原始請求，PAYMENT-SIGNATURE Header 附上授權簽名
5	驗證	Server → Facilitator → Server	Server POST /verify 轉發簽名；Facilitator 確認簽名有效、Nonce 未重送、餘額充足後，回覆 isValid: true
6	結算	Server → Facilitator → Blockchain	Server POST /settle；Facilitator 將交易上鏈，取得區塊鏈確認後回傳 txHash，完成鏈上結算
7	成功回應	Server → Client	回傳 200 OK 與資源內容，PAYMENT-RESPONSE Header 附帶 Transaction Hash —— 完成 Execution

整套流程解決了機器支付的兩個根本問題：Discovery（發現） 與 Execution（執行） —— 機器不僅知道要付多少錢給誰，還能在零人工介入下完成整個 payment loop。

---

Deep Dive 數據結構：精確到合約地址的設計

x402 能讓不同開發者構建的 Agent 與 Server 無縫對接，靠的是對數據結構的嚴格標準化。以下依 x402 v2 規格 拆解 402 Payment Required 回應的 JSON body（PaymentRequired 物件）。

頂層 PaymentRequired 物件描述「這個資源要不要錢、有哪些付法」：

欄位	類型	說明
x402Version	Number	協議版本，v2 固定為 2
error	String	選用，人類可讀的錯誤訊息，說明為何需要付款
resource	Object	資源描述（url、description、mimeType）—— v2 從支付選項中抽離到頂層
accepts	Array	可接受的支付選項列表（PaymentRequirements 陣列），增強 Client 彈性
extensions	Object	選用，協議擴充資料

accepts 陣列中每個 PaymentRequirements 物件則描述「一種具體的付法」：

欄位	類型	說明
scheme	String	結算邏輯：exact（精確轉帳）或 upto（預授權上限，按量計費）
network	String	區塊鏈標識，v2 採 CAIP-2 格式，如 eip155:8453（Base）、solana:...
amount	String	最小單位金額字串（USDC 為 6 位小數，10000 = $0.01）—— v1 的 maxAmountRequired 在 v2 改名為此
asset	String	代幣合約地址（或法幣 ISO 4217 代碼，注意：不是代幣符號）
payTo	String	受款方鏈上錢包地址（或角色常數，如 "merchant"）
maxTimeoutSeconds	Number	完成付款的最長允許時間
extra	Object	選用，scheme 專屬的額外資訊

若你手邊的教學或 SDK 仍寫著 maxAmountRequired、base-sepolia 這類欄位與網路命名，那是 x402 v1 的寫法。v2 把金額欄位改名為 amount、網路識別改用 CAIP-2 格式，並將 resource、description、mimeType 上移到頂層、移除了 outputSchema。

幾個設計細節值得特別注意：

asset 使用合約地址而非代幣符號。 這不是吹毛求疵 —— 同名代幣在不同鏈上可能指向完全不同的合約，用符號辨識會造成嚴重的資金安全漏洞。對於金融協議而言，精確性不是偏好，而是底線。

amount 以最小單位表示。 USDC 是 6 位小數，所以 10000 代表 $0.01。這是刻意迴避浮點數精度陷阱的設計 —— 電腦用二進位儲存小數時，0.1 和 0.2 在內部都是近似值，相加後的結果可能差了千分之一；這個誤差在顯示溫度時無傷大雅，但放進轉帳金額就會變成帳目對不攏。用整數來表示金額，計算過程中就不存在這個捨入誤差。

accepts 是陣列而非單一物件。 這意味著 Resource Server 可以同時接受 Base 上的 USDC、Solana 上的 USDC、甚至未來的某種新興 Stablecoin。Client 從選項中挑選最適合自己的鏈與幣種，降低了供需雙方的耦合度。

在成本面上，由於 x402 主要運行在 Base 或 Solana 等高效能鏈上，單筆 Gas 費用通常低於 $0.0001 美元。 這意味著一次 API 調用收費 $0.01 甚至 $0.001 的商業模式，在扣除基礎設施成本後仍然有利可圖。

當你的支付基礎設施成本足夠便宜，「每次 API 調用收費 $0.001」就不再是學術論文裡的理論構想，而是一個可以直接寫進產品定價頁面的商業模式。

---

Deferred Payment：為網際網路規模而生的工程折衷

x402 的「每請求結算」模型在邏輯上很漂亮，但面對網際網路規模的流量時 —— 比如 AI Crawler（爬蟲）每秒數百萬次的抓取請求 —— 就撞上了物理限制。即便 L2 鏈的 Gas 費極低，為每一次 HTTP 請求都進行鏈上寫入，在 Throughput（吞吐量）上仍然不切實際。

Cloudflare 在 x402 框架內提出了 Deferred Payment（遞延支付） 模式來解決這個問題（對應官方 batch-settlement scheme，Cloudflare 的產品名為 Pay Per Crawl）：

1. Client 不為每次請求進行鏈上結算，而是用 HTTP Message Signatures（RFC 9421，Ed25519 金鑰） 對請求簽署一份支付承諾（公鑰以 JWK 格式發布於 .well-known/http-message-signatures-directory）
2. Resource Server 確認簽章代理（signature agent）已向 Cloudflare 註冊、驗簽通過後，即時提供服務
3. Cloudflare 以 Merchant of Record 身分在背景持續累積該帳戶的帳單
4. 依週期性帳期（如每日、每週）透過傳統法幣渠道進行批量結算，再拆分給內容方

這個模式，本質上就是機器版的 BNPL（Buy Now, Pay Later，先享後付）。

Klarna 或 Afterpay 讓消費者先拿走商品、分期後付，依靠的是信用評分與帳戶關係作為信任基礎 —— 萬一賴帳，平台能凍結帳號、移交催收。Deferred Payment 做的事情結構上相同：Client 先取得服務，到了帳期再一次結算。差別在於，它的信任基礎不是帳戶關係或信用評分，而是密碼學簽名 —— Client 在每次請求時都預先簽署了一個不可偽造的支付授權，Server 不需要「相信」對方的信用，只需要驗證簽名是否有效。賴帳在數學上不可能，而非法律上不允許（Galaxy Research）。

更進一步，傳統 BNPL 的服務對象是人類消費者，核心摩擦點是「消費者不想現在掏錢」；Deferred Payment 的服務對象是 AI Agent，核心問題是「每筆請求都上鏈在吞吐量上不可行」。前者解決的是意願問題，後者解決的是工程問題 —— 同一套先享後付的外殼，裝的是完全不同的內核。

從工程架構的角度看，Deferred Payment 本質上是引入了一個 Write-Behind Cache 的支付模式：先在記憶體層完成「邏輯支付」，再非同步地將結果寫入區塊鏈這個「持久層」。這種模式在資料庫領域行之有年，現在被複製到了支付基礎設施中。

---

被推開的閘門

x402 不是一個全方位的解決方案 —— 它刻意只做一件事：讓錢能在 HTTP 層流動。

它不處理信任問題（「這個 Agent 真的被人類授權了嗎？」），不處理 Agent 間的協作（「這些 Agent 怎麼分工？」），不處理複雜的商業邏輯（「如果商品沒到，怎麼退款？」）。但正因為它只做一件事，它才能做得極其精簡 —— 而那些它不做的事，正是 AP2 與 A2A 協議要接手的地方。

回顧網際網路的架構史，每一個成功的協議都遵循同一條哲學：做好一件事，然後可組合。TCP 不關心內容格式，HTTP 不關心路由邏輯，TLS 不關心商業語義。x402 延續了這個傳統 —— 它是支付層的 TCP，精簡、通用、可被任何上層協議組合調用。

而當我們思考「AI Agent 能否成為獨立的經濟行為者」這個問題時，x402 給出的答案不是「能」或「不能」，而是：至少，它不會再被支付基礎設施擋在門外了。

---

下一篇：【Agentic Payment 系列 #2】信任的代價：AP2 授權機制、A2A 支付整合與三大協議戰場劃分

如果這篇文章對你有幫助，歡迎分享給對 Agent 經濟與 Web3 支付感興趣的朋友。