HTTP 狀態碼的變化很慢。200 與 404 幾十年來意思沒變，整個註冊表穩定到開發者平常根本不會去想它。除了 402。

402 Payment Required 從 1997 年就寫在 HTTP 規範裡，標註為保留未來使用，而這二十多年幾乎沒有人用它。2025 年，兩個方向同時改變了這件事：Cloudflare 開始回傳 402，向 AI 爬蟲收取讀取內容的費用；x402 標準則在同一個代碼上，蓋出一整套機器付款協定。

01HTTP 402 為什麼閒置了二十五年

最初的 HTTP/1.1 規範保留了 402，卻沒有定義回應內容。沒有共識格式的狀態碼，等於沒有用戶端能據此動作：瀏覽器不知道錢要匯到哪裡，代理也不知道該不該重試。

這個缺口沒有聽起來那麼嚴重，因為網上付款長在 HTTP 之外。結帳頁、卡片表單、跳轉到付款服務商、webhook 回呼，全都疊在協定之上。真正送到你 API 的請求早就付過錢，缺的只是「讓直接呼叫 API 的機器付款」這一塊，而那正是沒有結帳頁的情境。

402 是標準代碼，不是硬幹。

pay-per-crawl 與 x402 都維持 HTTP 語意：資源存在、用戶端身分被理解，伺服器只是拒絕在付款完成前交付內容。

02x402 如何把 402 變成付款握手

x402 是一套以 Apache-2.0 發布的公開標準，讓服務直接在 HTTP 上對 API 呼叫與內容收費。它沒有帳號、session 或憑證管理，付款指示就放在回應標頭裡。

官方說明的流程是五步：

1. 用戶端請求資源，例如 GET /weather。
2. 若需要付款，伺服器回 402 Payment Required，並附上付款指示。
3. 用戶端準備付款資料，重新送出請求。
4. 伺服器自行或透過 x402 facilitator 驗證並結算付款。
5. 付款有效後，伺服器才提供資源。

在 x402 公開的 v2 標頭中，這個握手用到三個名稱：

每個標頭值都是 Base64 編碼的 JSON 字串，既能避開標頭字元限制，任何 HTTP 用戶端也都能讀。

# 第一次請求沒有付款，伺服器回 402
curl -i https://api.example.com/weather

# 回來的內容
HTTP/1.1 402 Payment Required
PAYMENT-REQUIRED: eyJhY2NlcHRzIjpbXX0=
content-length: 0

關鍵設計是付款發生在正常的請求循環裡面。網址不變、不會跳轉到代管結帳頁，自發性的代理可以不必讓人介入，就完成整段交換。

03Cloudflare pay-per-crawl 實際回傳什麼

Cloudflare 在 2025 年 7 月推出的 pay-per-crawl，把同一個代碼用在另一個問題上：內容擁有者想在 AI 爬蟲讀取網站時收到錢。

公開的行為很直接。每個爬蟲請求會得到站方選定的三種結果之一：免費允許、依全站價格收費，或完全封鎖。當決定是收費、而請求又沒有付款時，Cloudflare 回傳 402 Payment Required，並用 crawler-price 標頭寫明價格。

兩個細節讓它不只是付費牆：

• Cloudflare 擔任 merchant of record，站方不必自己收一筆筆小額付款。
• 爬蟲要用 Web Bot Auth 的簽章請求證明身分，隨機用戶端無法冒充某個爬蟲來談價格。

換句話說，402 在這裡的用途是「向機器報價」，而那台機器未來可能與營運方有帳務關係。這跟 401、403 平常處理的瀏覽器付費牆，是兩件不同的事。

04402 回應該包含什麼

因為原始規範從未定義回應內容，每個實作都得自己發明細節。如果你要在 API 加上 402，請給到讓用戶端不必猜就能動作的資訊：

• 價格與計價單位。 每次請求、每千次請求，還是每次爬取，講清楚。
• 在哪裡、怎麼付。 付款端點、網絡與收款地址，或方案名稱。
• 如何證明付過款。 用戶端重試時要帶哪個標頭，格式是什麼。
• 優惠有效多久。 沒有期限的價格無法安全緩存。
• 機器可讀的內容。 JSON 比散文更容易讓代理處理，也同時對人和腳本有用。

{
  "error": "payment_required",
  "price": { "amount": "0.002", "currency": "USDC", "per": "request" },
  "accepts": ["exact"],
  "retry_header": "PAYMENT-SIGNATURE",
  "expires_in": 300
}

05402 與 401、403、429 的差別

付費端點還很新，團隊常常挑錯代碼。只要講清楚「缺的是什麼」，四個候選代碼就很好分。

兩條規則能保持乾淨。人類只是沒登入，請回 401，不要回 402。呼叫方只要等一下就能解決的流量限制，請用 429 搭配 Retry-After，不要用 402。

402 是叫用戶端付錢，不是叫它盲目重試。

如果 API 回 402 卻沒有任何指示，守規矩的用戶端會把它當成一般 4xx 就停住。價值在標頭與內容裡，不在那個數字。

06實作 402 而不弄壞用戶端

新增一個狀態碼是相容性決定，就該用相容性的方式處理：

1. 代碼留給機器用戶端。 瀏覽器流量請導向付款頁，或回 401 加上清楚訊息；未知的 4xx 對用戶只有困擾。
2. 第一次 402 不該有成本。 回報價格的那次請求絕不能收費或扣額度，否則重試循環可能為根本沒收到的內容計費。
3. 重試要能冪等。 用戶端付費後重試，如果第一次重試在傳輸中遺失，不能又被收一次錢。
4. 402 要與 4xx 錯誤分開記錄。 付費端點回 402 是健康的，回 404 不是。兩者混在同一個「用戶端錯誤」儀表板裡，訊號就消失了。
5. 公開標頭契約。 代理猜不出 PAYMENT-SIGNATURE、PAYMENT-REQUIRED 或 crawler-price，沒有文件就沒有人接得上。

07對內容方與 API 經營者的意義

二十年來最冷門的狀態碼，終於有了工作。這份工作很窄、很具體：標記 HTTP 請求變成交易的那一刻，並讓機器在不需人類介入的情況下完成交易。

無論你經營的是付費 API，還是看著 AI 爬蟲讀你的內容，該做的第一步都一樣。先確認你的伺服器現在回什麼，再決定用戶端遇到每個代碼該做什麼，最後讓回應明確告訴它下一步。