x402 (HTTP 402 Payment Protocol)

x402 是什麼，跟一般的線上支付方式有什麼不同？

x402 是 Coinbase 於 2025 年 5 月推出的開放協議，核心是重新啟用 HTTP 協議裡一個長期閒置的狀態碼「402 Payment Required」——這個狀態碼早在 1991 年 HTTP/1.0 規格裡就被保留，但三十多年來從未被標準化用於任何實際的支付系統，一直是規格書裡的一個空位。

跟信用卡、Stripe 訂閱制這類傳統線上支付方式最大的不同，在於 x402 沒有帳號、沒有訂閱、沒有人工核准這些環節。伺服器在拒絕未付款請求時，直接在 HTTP 402 回應裡附上機器可讀的付款要求（網路、代幣、金額、收款地址），客戶端（通常是 AI Agent 或自動化程式）用鏈上簽署完成一筆穩定幣付款，帶著付款憑證重新發送請求即可拿到資源，整個流程在幾秒內完成，且是專門為「機器對機器」（M2M）的高頻小額交易設計的，不是給人類手動操作用的。

x402 為什麼會被發明出來，解決了什麼問題？

傳統支付軌道（信用卡、銀行轉帳）的成本結構有一個隱形下限：手續費、風控審核、對帳流程的固定成本，往往遠遠超過小額交易本身的金額，導致「單次呼叫付費幾分錢」這種商業模式在網路上幾乎不存在。開發者即使只想讓使用者呼叫一次 API，也被迫設計成訂閱制或免費增值，這對真正的按次計費場景是一種扭曲。

這個問題在 AI Agent 大量出現後變得更急迫：一個自主運作的 Agent 可能需要在一次任務裡呼叫成千上百次不同的 API（取得資料、呼叫工具、存取內容），如果每次呼叫都要走信用卡授權或人工核准，Agent 的自主性根本無法成立。x402 讓開發者能把 API 直接變成「付費資源」——買方看到價格、付款、在同一個請求循環裡拿到存取權，不管買方是人類還是機器都適用，這正是它被設計出來解決的核心問題。

x402 具體怎麼運作，各個角色扮演什麼職能？

x402 的付款流程可以拆成四步：第一步，客戶端（通常是 AI Agent）對某個資源伺服器發出 HTTP 請求；第二步，如果該資源需要付費，伺服器回傳 HTTP 402 狀態碼，並在標頭裡附上機器可讀的付款要求（支援的網路、代幣、金額、收款地址）；第三步，客戶端根據這些要求，用自己的鏈上錢包簽署一筆付款授權（技術上採用 EIP-3009 這類免 Gas 的授權轉帳標準），並帶著簽署憑證重新發送原本的請求；第四步，伺服器驗證這筆付款是否有效——可以自行驗證，也可以委託給第三方「Facilitator」（例如 Coinbase 或 Cloudflare 提供的服務）代為驗證與結算，確認無誤後才回傳原本要求的資源。

目前 x402 支援多條鏈（以 EVM 相容鏈與 Solana 為主），計價資產以 USDC 為絕大多數，實際落地場景包括 AI Agent 呼叫工具鏈、開發者對市場數據 API 按次計費、以及部分社群嘗試把它跟 MCP（Model Context Protocol）等 Agent 工具協議做更深度的整合。

x402 對一般人有什麼影響，使用或觀察這個協議時要注意什麼？

對一般穩定幣持有者而言，x402 目前的直接影響還很有限——絕大多數轉帳金額落在幾美分等級，尚未構成穩定幣的主要需求來源。但這個協議代表了「機器對機器經濟」正在從概念走向基礎設施，值得放進中長期觀察清單：如果未來 Agent 開始為真正有價值的服務（不只是測試性質的 API 呼叫）付費，穩定幣作為 M2M 結算工具的角色會顯著強化。

需要留意的一點是，x402 的轉帳次數是一個容易被高頻測試行為灌高的指標——因為協議本身把單筆成本壓得極低，開發者可以用機器人反覆呼叫測試端點刷出漂亮的次數曲線，這在傳統支付軌道（每筆都有實質手續費）裡幾乎不可能發生。判斷這個賽道是否真的在成長，比較可靠的方式是同時觀察轉帳次數與轉帳總金額是否同步上升，而不是只看單一個創新高的次數指標。