HTTP 402 Payment Required 表示伺服器要先收到付款才會回應。標準只是保留了這個狀態碼，所以它的含義取決於由誰發出。好幾個大型 API 用它來表示你的帳戶出現帳單問題。x402 等支付協議則用它來給出機器可讀的價格，讓程式或智能代理付款後再重試。
標準怎麼說
RFC 9110 是 2022 年 6 月發布的現行 HTTP 標準，它對 402 的完整定義只有一句：「402（Payment Required）狀態碼保留供日後使用。」IANA 登記冊指向這一節，而標準裡再沒有其他地方說明 402 回應應包含甚麼。
MDN 稱它為非標準狀態碼，並指出「並無標準的使用慣例」。瀏覽器不會對它作任何特別處理：402 和其他 4xx 錯誤一樣顯示。各種程式語言仍然為它命名，例如 Python 的 HTTPStatus.PAYMENT_REQUIRED 和 Go 的 StatusPaymentRequired，所以任何伺服器都可以發出 402。
402 從何而來
這個狀態碼比保留它的 RFC 還要早出現。
- 1992 年，一份早期的 HTTP 狀態碼清單（現由 W3C 存檔）已列出「PaymentRequired 402」：回應會列明「可接受的收費方案」（charging schemes acceptable），客戶端可以「附上合適的 ChargeTo 標頭」重試。
- 1996 年 5 月，HTTP/1.0（RFC 1945）沒有收錄 402，清單由 401 直接跳到 403。
- 1997 年 1 月，第一份 HTTP/1.1 規範 RFC 2068 把它重新加入，寫明「保留供日後使用」。1999 年的 RFC 2616 和 2022 年的 RFC 9110 沿用了同樣的措辭。
- 2025 年 5 月 6 日，Coinbase 公布了 x402，這個開放協議把原本的 402 用於穩定幣付款。2026 年 4 月 2 日，Linux Foundation 以 x402 Foundation 的形式接手了它。
有些指南說 402「自 1995 年起」就被保留，或「在 1996 年」定義。根據 RFC 的紀錄，它出現在 1997 年 1 月，即 HTTP/1.0 把它排除在外的八個月後。我們認為，1992 年那個構想（伺服器報出價格，客戶端在重試時付款）和現在建基於 402 的協議的運作方式很接近。
你會遇到的兩種 402
由於標準一直沒有補上細節，兩種用法並行發展起來。一種用 402 報告你現有帳戶的帳單問題。另一種把 402 當作這一次請求的報價，並寫成軟件可以直接支付的格式。
| 由誰發出 | 含義 | 解決方法 |
|---|---|---|
| Stripe | 請求有效但失敗，例如銀行卡無法扣款 | 換另一張卡或另一種付款方式 |
| Shopify | 店鋪因未付清的結欠被凍結 | 店主繳清結欠 |
| Google API | 達到預算或配額上限，或有款項到期 | 提高上限或付款 |
| DeepSeek、OpenRouter | 餘額或點數用完 | 增值 |
| x402 和 MPP 服務 | 這次請求要收費，並附上價格 | 付款後重試 |
前四行來自各公司自己的錯誤文件（Stripe、Shopify、Google、DeepSeek、OpenRouter）。Stripe 把它的 402 稱為「Request Failed」（請求失敗）：參數有效，但請求失敗。MDN 對這種做法有更概括的描述：一些支付 API 把 402「當作付款請求失敗時的通用代碼」。
如何分辨你收到的是哪一種
先看標頭，再看正文。
- 有
PAYMENT-REQUIRED標頭，代表這是 x402 伺服器。在 x402 V2 中，這個標頭以 Base64 編碼的 JSON 載明價格：可接受的付款方案、金額、網絡和收款地址（x402 文件）。 - 有
WWW-Authenticate: Payment標頭，代表 Machine Payments Protocol（MPP），由 Tempo 和 Stripe 於 2026 年 3 月 18 日推出。它的「Payment」身份驗證方案以個人名義寫成一份 Internet-Draft，在 IETF 並無正式地位；截至 2026 年 11 月 4 日，IETF 把這份草案列為已過期。 WWW-Authenticate標頭附帶一個令牌和一張 Lightning 發票，代表 L402。- 以上皆無，而正文是一個 JSON 錯誤，例如銀行卡過期或點數不足，代表這是帳單類 402。讀取正文裡的錯誤代碼，然後處理帳戶問題。
以下是我們在 2026 年 11 月 4 日從一個小型報價服務擷取的真實 x402 質詢（challenge），標頭已解碼並刪減：
HTTP/2 402
payment-required: eyJ4NDAyVmVyc2lvbiI6Mi... (Base64)
decoded:
{
"x402Version": 2,
"accepts": [{
"scheme": "exact",
"network": "eip155:8453",
"amount": "5000",
"asset": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",
"payTo": "0x589a...B3d8",
"maxTimeoutSeconds": 60
}]
}
eip155:8453 是 Base 主網，而這個資產是 USDC，在 Base 上有 6 位小數（x402 網絡清單）。所以 5000 代表一次調用收費 $0.005。JSON 正文也用文字說了同一件事：「PAYMENT-SIGNATURE header is required.」（需要 PAYMENT-SIGNATURE 標頭）。
如何處理 402
做法取決於你身處哪個位置。
在網站或應用程式上
找找帳單問題：銀行卡過期、計劃已失效，或有未付清的結欠。到帳戶設定更新付款方式或計劃；如果帳戶不由你管理，就聯絡該服務。
調用 API 時
先讀取正文裡的錯誤代碼。它通常會指明原因，解決方法就在你的帳單設定裡：增值、提高預算或更換銀行卡。不要不斷重試。OpenRouter 的文件指出，沒有 Retry-After 標頭的 402「不屬於等待後重試的情況」，而 OpenAI、Anthropic、Vercel AI 和 OpenRouter 的 SDK 都不會自動重試 402。
開發會付款的智能代理時
把質詢類 402 當作一份報價。解碼後，對照你給智能代理的預算檢查金額和網絡，付款，再以 PAYMENT-SIGNATURE 標頭重新發送同一個請求。也要預計會遇到較舊的伺服器：x402 V1 使用 X-PAYMENT 標頭和 base-sepolia 這類網絡名稱，而 V2 使用 eip155:84532 這類 CAIP-2 識別碼（遷移指南）。款項能否在同一次往返內在鏈上結算，取決於伺服器選用的付款方案。
營運 API 時
我們建議只在付款能解決問題時才發出 402。憑證缺失或無效時用 401，伺服器拒絕而付款也改變不了結果時用 403，速率限制則用 429（RFC 6585）。在正文裡放上機器可讀的原因。如果你想讓軟件按次向你付款，採用客戶端已經會解析的格式（例如 x402）發出 402 質詢，每個客戶端就不用再猜。
運行中的 x402 服務會回傳甚麼
為了看看實際的付款質詢類 402 是甚麼樣子，我們在 2026 年 11 月 4 日抽查了 Coinbase 公開的 x402 Bazaar 目錄。目錄當時列出 112,162 項資源。我們在 25 個平均分布的位置各取 20 項（共 500 項），向每一項發送一次未付款的請求：一般用 GET；目錄註明用 POST 的，就用 POST 並附上空的 JSON 正文。
| 結果 | 項數 |
|---|---|
| 主機無法連接（同一部主機） | 340 |
| 回應 402 | 157 |
| 其他（403 或沒有回應） | 3 |
那 340 項無法使用的項目全部屬於同一部主機，它回傳 HTTP 530 或完全沒有回應。目錄裡的一個項目只是一項聲稱，不能證明服務正在運行。
回應 402 的 157 項分布在 33 部主機上，每一項都帶有 V2 的 PAYMENT-REQUIRED 標頭。其中 40 項（位於兩個域名下的 8 部主機）還在同一個回應的 JSON 正文裡附上 V1 格式的副本（"network": "base"、maxAmountRequired），讓新舊客戶端都能讀取。包括搜尋 API Exa 在內的 6 部主機，還在同一個 402 上提供 MPP 的 WWW-Authenticate: Payment 質詢，讓一個回應同時服務兩種協議的客戶端。
這是一個由服務自行登記的目錄，所以這些數字只描述我們在某一天看到的情況，並不代表整個網絡。不過其中的模式仍然有參考價值：客戶端應先讀取標頭，接受 V1 格式的正文，並留意同一個回應裡可能有不止一種協議。
QDay 的角色
QDay 是為智能代理按次付款而建、兼容 EVM 的網絡，並預留了遷移到後量子 ML-DSA-65 簽名的路徑。Aevum 測試網現已上線，x402 支援和智能代理支付功能即將推出，主網計劃於 2027 年推出。想了解智能代理付款的全貌，請看〈智能代理如何付款〉。