“它在標準里沉睡了30年，直到AI開始調用世界。”

文丨張盒子

出品丨支付之家 · 深度

互聯網里有很多狀態碼。

404人人都見過，401、403也經常出現在權限和登錄場景中。但有一個狀態碼，在標準文本里沉睡了近30年，長期沒有真正走到互聯網商業化的前臺。

它就是HTTP 402 Payment Required。

現在，這個老狀態碼被AI支付重新叫醒了。

原因并不復雜，AI可能不是先學會賺錢，而是先學會花錢。

當AI智能體不再只是回答問題，而是開始替用戶執行任務，支付問題就會被重新擺到臺前。它要調用API、購買數據、使用MCP工具、生成圖片視頻、請求其他智能體服務。

每一次調用背后，都可能對應一次資源消耗，也可能對應一筆費用。

“機器”怎么付款？

這里需要補充一下，“機器”并不是指某一臺具體設備，而是指AI智能體、自動化程序、API客戶端等非人工請求方。

互聯網其實很早就給這個問題留過一個位置。

這個位置，就是HTTP 402 Payment Required。

HTTP 402的含義很直白：付款要求。它不是一個完整支付協議，而是HTTP狀態碼。

早在1997年發布的HTTP/1.1早期規范RFC 2068中，402 Payment Required就已經被列出，并被標注為“reserved for future use”。

到了現代HTTP語義規范RFC 9110中，402仍然延續這一基本定位，也就是為未來用途保留。

它不像404那樣成為互聯網用戶熟悉的錯誤提示，也不像401、403那樣進入身份認證和權限管理的日常場景。很長時間里，402更像一個被放在標準文本里的空位。

互聯網知道資源訪問可能需要付款，但并沒有形成一套通用商業路徑。

402不是突然出現的新技術，它更像互聯網早年“資源訪問即付款”理想留下的接口。

互聯網早就想過“訪問即付費”

今天討論HTTP 402，不能只從一個狀態碼講起。

它背后站著一段早期互聯網支付史。

1990年代，互聯網剛進入商業化階段，網頁、電子現金、數字內容和微支付都曾被寄予很高期待。

那時的設想很簡單：用戶讀一篇文章、下載一個文件、訪問一次數據庫、使用一次在線服務，只要金額足夠低、流程足夠輕，就可能形成新的商業模式。

在廣告平臺、超級App、應用商店和成熟收銀臺還沒有接管互聯網之前，很多人相信，數字內容和在線服務可以像水電一樣按次、按量收費。每一次訪問都有價格，每一次點擊都可能是一筆小額交易。

HTTP 402就是在這樣的想象中顯得合理。服務器告訴客戶端，想訪問這個資源，需要先付款。

W3C在1995年已有Micro Payment Transfer Protocol工作草案，試圖通過共同經紀方處理小額支付，讓小額付款適合互動應用。

1999年前后，W3C又有過Micropayment Markup等相關探索，希望把初始化微支付所需的信息嵌入網頁。

DigiCash、CyberCash、First Virtual等早期電子現金或微支付探索，也曾參與過這條路徑，試圖為互聯網提供更輕的付款方式。

但這些嘗試最終沒有讓小額網絡支付成為主流。

那一代創業者和技術機構想解決的問題，與今天討論402時面對的問題有相似之處：數字資源可以被定價，網絡訪問可以觸發付款，交易不一定總要先進入傳統收銀臺。

所以，402不是孤零零的狀態碼。它背后對應的是早期互聯網的一種商業理想——網頁、內容、數據和服務，都可以在訪問時完成付款。

但后來的互聯網沒有沿著這條路走下去。

“微支付”沒有成為主流

從結果看，402沉睡并不是支付需求消失，而是“訪問即付費”沒有成為主流路徑。收銀臺、廣告、訂閱、平臺賬戶和API月結賬單，成為更現實的互聯網商業化方式。

早期微支付最先面對的是人。

幾分錢、幾毛錢看起來不貴，但每一次確認都會消耗用戶注意力。用戶可以接受每月訂閱，也可以接受看廣告換取免費內容，卻很難接受每一次點擊都像一次結賬。

人不怕花幾分錢，人怕每次都被打斷。

商戶也不愿意處理碎片化小賬。一筆幾分錢的交易，也要記錄、對賬、退款、客服、稅務和系統維護。單筆金額越小，單位處理成本越敏感。交易金額可以很小，交易責任不會因此變小。

更現實的商業模式很快勝出。

電商平臺沒有把每一次網頁訪問都變成付款請求，而是把支付放進訂單流程。用戶先選商品，再進入收銀臺，支付成為交易閉環中的一個環節。互聯網沒有放棄支付，而是把支付從協議層推到了收銀臺。

內容行業也沒有普遍走向“單篇微支付”。廣告把用戶注意力變成收入，訂閱把零散訪問打包成周期付費，平臺賬戶把支付封裝在更大的生態內。內容付費沒有消失，但它沒有沿著402想象中的按次訪問路徑發展。

API經濟同樣如此。

API早就收費，只是收費方式長期圍繞賬號和賬單，而不是圍繞單次HTTP請求。開發者注冊賬號，申請API Key，綁定付款方式，購買套餐，按量統計，月度結算。對企業客戶和開發者來說，這套流程雖然偏重，但可以接受。

互聯網早期曾經想讓“訪問即付費”成為一條路，但后來的商業世界選擇了更容易規模化、更適合用戶習慣和商戶經營的路徑。

收銀臺贏了，402繼續等待。

Web支付繼續演進，但主角仍然是人

互聯網支付沒有停止標準化探索。

后來，瀏覽器、商戶網站和支付服務商一直在試圖讓用戶付款更順暢。W3C Web Payments、Payment Request API等方向，核心目標都是降低網頁支付的接入和使用成本，讓瀏覽器、商戶與支付方式之間更好協同。

但這些努力大多仍然圍繞人展開。

人看見訂單，人選擇支付方式，人確認付款。

無論是銀行卡、錢包、瀏覽器支付接口，還是電商收銀臺，主角仍然是人類用戶。支付體驗被優化了，但付款動作依然發生在頁面、App和收銀臺里。

402路徑的差異在于，它不是繼續優化人的收銀臺，而是把付款要求放進資源訪問過程。

過去的Web支付，重點是讓人更順暢地付款；智能體時代的402，重點是讓機器讀懂價格、提交付款、獲得資源。

也正因為過去的支付體系主要圍繞人設計，當智能體開始成為任務執行者，舊問題才以新方式重新出現。

如果訪問資源的不再是人，而是機器，付款流程還要不要繼續圍繞收銀臺展開？

AI讓微支付換了對象

早期微支付失敗，很大程度上是因為它讓人頻繁為小額資源付款。

人會猶豫，會嫌麻煩，會覺得幾分錢確認一次不值得。

AI智能體改變了這個前提。

機器不會因為“點擊一次太麻煩”而反感流程，但機器需要清晰的價格、權限、預算和回執。它要知道付多少錢，付給誰，用什么方式付，付款后獲得什么，是否符合用戶授權，是否超過預算。

AI不是重新發明微支付，而是把微支付的對象從“人點擊網頁”換成了“機器調用資源”。

這是理解HTTP 402重新被關注的關鍵。

一個智能體可能調用搜索API，查詢企業數據，訪問風控評分，使用MCP工具，生成一張圖片，完成一次模型推理，或者請求另一個智能體執行子任務。這些調用有幾個共同特征：單次金額可能不高，調用頻次可能很高，服務結果可以計量，交付過程可以自動化，交易記錄可以留痕。

人不適合為每一次點擊付款，機器卻適合為每一次調用計賬。

早期微支付等不到用戶習慣，402等到了智能體調用。

HTTP 402等來的不是網頁微支付，而是機器資源計費。

x402把402從狀態碼變成流程

402本身只是狀態碼。

嚴格說，HTTP 402是狀態碼，x402是圍繞這個狀態碼形成的一種代表性實現。本文討論的“402路徑”，指的是把付款要求嵌入資源訪問流程的這一類思路。

真正讓402重新進入產業視野的，是圍繞它形成的新協議和新實現，最典型的是x402。

Coinbase在2025年5月推出x402，稱其為一種讓API、應用和AI智能體通過HTTP直接完成即時穩定幣支付的支付協議。

隨后，Cloudflare、Stripe、Circle等機構圍繞x402推出或接入相關能力，AWS等云服務生態也開始把智能體支付納入企業智能體和云服務討論中。

2026年4月，Linux Foundation宣布成立x402 Foundation，并接收Coinbase貢獻的x402協議，將其置于開放治理框架下。

x402做的事情，是給402補上了一套能執行的支付流程。

智能體請求一個付費資源，服務器返回402 Payment Required，同時給出金額、幣種、收款方和付款方案。客戶端根據要求生成付款授權，再帶著憑證重新請求。服務端或facilitator驗證付款，驗證通過后放行資源。

過去402只能說“需要付款”，x402試圖說明付多少、怎么付、誰驗證、何時放行資源。

它不是多了一個付款按鈕，而是讓付款進入資源訪問流程。

402真正重要的地方，不是重新定義一種支付工具，而是重新定義付款發生的位置。過去付款大多發生在收銀臺、App和支付頁面，402路徑則把付款推進到資源請求、工具調用和機器協作過程中。

過去支付發生在頁面上，未來一部分支付會發生在調用里。

402更適合資源調用付款

402不是AI替人買東西的第一答案，而是AI為一次資源調用付款的更直接路徑。

它最先成熟的地方，大概率不是普通消費者購物，而是API、MCP、數據接口、AI內容生成和機器服務。

API、MCP工具、AI內容生成、專業數據訪問和智能體協作，都是402路徑更容易先跑通的場景。它們有一個共同點：服務可以被清楚計量，結果可以被自動交付，付款可以和一次調用對應起來。

搜索、數據查詢、模型推理、合規核驗、風控評分、企業信息查詢，都可能從套餐和月結之外，增加更細顆粒度的調用計費。生成一張圖片、一次音頻、一段視頻、一次文本處理，本質上都是資源消耗，也可以成為一次計費單元。

不是所有數據都適合訂閱，有些數據只需要被調用一次。企業信息、市場數據、風險名單、研究報告，如果每次調用都能定價、付款、回執，資源服務商就有新的商業化方式。

更遠一點看，智能體之間的協作，可能同時也是智能體之間的交易。一個智能體調用另一個智能體的能力，一個自動化服務購買另一個服務的結果，機器對機器服務交易會自然產生付款需求。

402的吸引力，在于讓一次性資源訪問不必先變成長期賬戶關系。

過去，API和數據服務往往要先把用戶納入賬號體系，再通過Key、套餐和賬單實現收費。402路徑提供了另一種可能：資源先被請求，價格隨請求返回，付款完成后再放行資源。

這對長期服務關系不是替代，對臨時調用、低頻調用、跨平臺調用卻有價值。

402不能替代收銀臺

402的價值很清楚，邊界也同樣清楚。

它更像智能體經濟中的資源計費協議，不是銀行卡、錢包、收單和清算體系的替代品。

普通電商交易不只是一筆付款，還涉及訂單、庫存、地址、物流、退換貨、發票、客服和平臺規則。402可以處理付款要求，但處理不了完整訂單履約。

線下支付也不是一次資源訪問，而是一整套受理、清算和責任體系。商戶管理、終端受理、用戶確認、交易憑證、清算對賬、投訴處理、收單合規，都不是一個HTTP狀態碼能夠覆蓋的內容。

大額交易、金融產品購買和跨境資金服務還涉及身份核驗、適當性、反洗錢、外匯、稅務和監管報備。一條HTTP付款路徑，不能替代支付業務里的全部制度安排。

對中國市場而言，402和x402的技術邏輯可以觀察，但當前國際實踐中常見的穩定幣結算、鏈上錢包和跨境資金安排，不能直接等同于境內可推廣的支付產品。

在國內語境下，402更應關注協議思想和資源計費邏輯，而不是簡單照搬穩定幣收付路徑。

技術可以把付款做輕，合規不會因此變輕。

支付行業不能只看技術跑通

402路徑越接近真實資金流，越需要回答支付行業熟悉的問題。

對支付行業來說，402的關鍵不在于機器能不能完成付款，而在于付款動作被自動化之后，原本由人、商戶和支付機構共同承擔的責任如何重新分配。

授權邊界：AI憑什么付款？

用戶授權的是單次付款、單個任務、固定額度，還是長期授權？智能體支付的第一道問題，不是怎么扣款，而是誰授權它扣款。

限額管理：機器能花多少錢？

單次多少錢，每天多少錢，一個任務最多花多少錢，一個工具最多調用多少次，超過金額是否需要人工確認。沒有預算邊界的智能體支付，本質上是在把支付風險自動化。

憑證驗證：錢、資源和回執能否對上？

付款憑證是否有效，是否綁定具體資源、金額、商戶、時間和請求上下文，是否會被復用或重放。支付行業最怕的不是流程復雜，而是錢、授權、資源和回執對不上。

交易風控：誰識別異常調用？

惡意MCP工具、虛假API、提示詞注入、連續小額扣款、偽裝服務商收款，都可能把智能體的自動執行能力變成資金損失。當付款從人點擊按鈕變成機器自動請求，風控必須前移到智能體決策之前。

合規約束：自動化不能繞過規則。

x402與穩定幣、鏈上錢包結合后，會涉及穩定幣監管、資金來源識別、制裁篩查、反洗錢、跨境資金流、商戶準入和稅務處理。越是跨境、自動化、小額高頻，越不能忽視合規鏈路。

責任歸屬：機器付錯錢之后誰負責？

付了錢沒拿到服務，AI花錯錢，工具惡意收費，服務質量不達標，重復扣款，退款爭議，最終都要有人處理。機器能付款只是第一步，機器付錯錢之后誰負責，才是支付行業真正關心的問題。

這些問題不是理論擔憂。

已有研究對x402的安全問題進行分析，指出其把同步HTTP授權與異步區塊鏈結算結合后，可能帶來授權綁定、重放保護、Web層處理等攻擊面，并造成“未付款獲取服務”或“已付款但服務被拒”等結果。另有研究從交易原子性、上下文綁定、并發競態等角度討論x402生態中的邏輯缺陷和狀態同步問題。

能跑通協議，不等于已經形成支付業務閉環。

機器支付越自動化，支付責任越不能后置。

支付機構不會被繞開

402降低了資源服務商表達付款要求的門檻，但沒有消滅支付行業的責任。真實交易仍然需要準入、驗證、風控、留痕、結算和爭議處理。

402看似讓資源服務商可以更直接地收費，但只要交易開始規模化，支付行業熟悉的準入、風控、清算、留痕、退款和爭議處理就會重新回到中心。機器支付不是去支付機構化，而是把支付機構的能力推向更早的交易環節。

支付機構服務的對象，可能從傳統商戶和收銀臺，延伸到API、MCP工具、智能體平臺和機器錢包。

它們可以做facilitator服務，幫助資源服務商驗證付款、提交結算、返回回執；可以做智能體支付風控，識別智能體身份、工具風險、資源風險和調用異常；可以做預算和限額管理，為用戶、企業和平臺設置支付邊界；也可以做商戶和工具準入，對API、MCP工具、數據服務和智能體服務進行認證。

交易留痕、審計、合規結算、退款和爭議處理，同樣會成為機器支付時代的基礎能力。

402不會讓支付機構消失。

它會把支付服務從收銀臺延伸到API、MCP工具、智能體和機器錢包。未來支付機構不只服務商戶，也可能服務工具、模型、數據接口和智能體。

對支付機構而言，智能體支付不是把原有收單能力簡單搬到AI場景，而是要重新理解交易發生的位置。過去的交易入口在商戶頁面、收銀臺、POS和錢包App里；未來一部分交易入口會藏在工具調用、模型請求、數據查詢和自動化任務中。

識別這些調用關系，把授權、限額、風控和回執接進去，支付機構才有機會在機器支付時代找到位置。

402在智能體支付版圖中的位置

402路徑不是智能體支付的全部。

銀聯APOP更關注智能體在卡組織和收單網絡中的身份、意圖、用戶和授權管理；京東A2P2更關注平臺生態內智能體自主支付的任務委托、運行環境和自主等級；Visa、Mastercard更關注在現有卡組織網絡中讓智能體使用受控支付能力；螞蟻國際AMP更關注移動錢包、銀行App、超級App與智能體服務連接。

相比之下，402和x402更靠近資源調用層，處理的是AI為一次資源訪問付款的問題。

APOP、A2P2、卡組織方案更多處理AI替人消費；402更像解決AI為資源調用付款。

智能體支付不會只有一條路。

購物有購物的協議，資源調用有資源調用的協議，錢包和卡組織也會有自己的授權體系。

這恰恰說明，智能體支付已經開始分層。

一層是消費支付，解決AI替用戶買商品、訂服務、付賬單時的授權、訂單和履約問題。

一層是資源計費，解決AI調用API、MCP工具、數據接口、模型服務時如何按次付款。

還有一層是風險和責任，解決智能體身份、預算、留痕、風控、合規和爭議處理問題。

402更靠近資源計費這一層。

它不是全部答案，但它補上了智能體支付版圖里很關鍵的一塊：機器調用數字資源時，如何識別價格、提交付款、獲取服務。

機器成為新的付款發起方

HTTP 402等了近30年，等來的不是網頁微支付的簡單復活，而是交易發起方式的改變。

過去，互聯網支付大多發生在頁面、App和收銀臺。

而在智能體時代，支付開始嵌入API請求、MCP工具調用、模型推理與機器之間的協作過程。

變化的關鍵不在于“多了一種支付方式”，而在于付款動作的發起主體正在變化。

HTTP 402被重新叫醒，正是這一變化在資源調用層的信號。

AI開始自己花錢，并不意味著機器可以不受約束地付款。

智能體支付真正要解決的，也不只是“能不能付款”，而是機器憑什么付款、替誰付款、能花多少錢、誰來驗證、出錯由誰負責。

當支付從人的點擊進入機器的調用，授權、風控、合規與責任邊界，也必須同步前移。

HTTP 402被叫醒的真正含義并不是支付變了，而是——

交易的起點，從人，開始轉向機器。

這里是支付之家。我們關注支付表象之下的規則差異與邏輯變化，提供支付科技領域增量信息。觀點內容僅供參考。