支付產業正圍繞一個引人入勝的理念形成共識：AI代理應該能自行為API與數據付費，而無需等待人類輸入信用卡號碼。「按次計費」（pay-per-call）是實現此目標的有效方式之一，特別是在代理首次接觸新服務供應商時。然而，這僅是其中一個選項。另一種對使用者而言既熟悉又偏好的模式是：預先儲值、按用量計費，事後再結算累計金額。以下將從數位支付領域共同創辦人的視角，探討支付產業處理此議題的不同途徑。
AI請求的價格為何往往尚不存在
以大型語言模型API為例，當請求啟動時，供應商雖然能計算輸入的token數量，但此時仍無法預知輸出長度、模型將進行多少推理、是否會呼叫工具，或是否需要重試。雖然供應商可以透過設定輸出上限來框定最壞情況，但該上限本身即是產品設計上的妥協。真實的價格只有在工作完成後才會揭曉。
因此，一次性固定價格的設計迫使開發商面臨尷尬的選擇：以通常不正確的價格收費、以最壞情況計價，或嚴格限制輸出以維持初始報價的有效性。無論選擇哪種方案，都會削弱基於用量計費的承諾價值。
還存在第三種選項：先授權一個最高額度，事後僅扣取實際計量金額。然而，隨著服務演進，此模式的問題也隨之浮現。供應商可能新增高階模型、改變輸入與輸出的比例關係、推出快取token折扣，或將工具執行獨立計費。倘若支付協定假設在請求前即存在精確價格，產品設計便不得不屈就於支付機制的限制。
有三項職能遭到合併，但實際上應保持分離：「授權」（買方核准的金額上限）、「計量」（實際消耗量）以及「結算」（價值何時以最終確定的方式移轉）。
小額支付的經濟學與使用者體驗並非同一回事
像x402這樣的協定確實為解決這些挑戰做出了實質貢獻。在此模型中，伺服器會回傳一個HTTP「402 Payment Required」（需要付款）狀態碼；接著客戶端會附加支付憑證並重新發送請求。這對於代理首次接觸新賣家、購買離散專案或在沒有帳戶的情況下進行低頻呼叫等情境，運作得相當優雅。
然而，x402定義的是「如何請求付款」，而非「必須多久在鏈上結算一次」，後者屬於架構與實作層面的選擇。
能夠結算10美分，並不意味著買方希望將每一筆10美分的交易都視為獨立的購買行為。我們早已習慣儲值交通卡、購買雲端點數、保有應用程式商店餘額，並按月檢視一張行動電話帳單。我們在意的是預算邊界——10美元、100美元、1000美元——同時期望系統能精準計量更小的單位。
為滿足此需求，代理理應能接收一筆10美元的預算、執行數百次呼叫，並公開一份使用者可隨時檢視或撤銷的即時用量紀錄。相對地，使用者很可能不願意每發起一次請求就經歷一場新的支付流程。
「會話」何以成為更佳的基礎單元
對於反覆使用的情境而言，更佳的心智模型或許是「酒吧記帳」，而非「旋轉門」：買方預先存入款項或授權一個最高額度，服務端計量實際消耗量，每筆承諾會更新累計金額。在結尾時——或在供應商自行設定的時間或風險閾值——雙方一次性結算，未動用的款項則歸還買方。
此模式已有若干實例：
Stripe與Tempo推出的「機器支付協定」（Machine Payments Protocol）支援兩種模式：一次性收費意圖，以及會話意圖——後者讓買方一次性注資一個單向支付通道，並隨用量成長簽署累計的鏈下承諾。
比特幣閃電網路（Lightning Network）則展示了雙重特性：最終結算前可發生多筆支付，且路由機制意味著付款方無需與每個收款方都建立直接通道。然而，流動性、運作時間與通道狀態仍是實際的營運負擔。
Cashu引入了預付的 bearer 電子現金：這使許多小額支付能在無傳統個人帳戶紀錄的情況下完成，但其代價是必須信任發行機構（mint），並承擔相應的失竊風險。通道與電子現金都是優化手段，而非無狀態支付的通用替代方案。
這些架構契合成本變動的AI服務，因為價格發現是與交付同步發生的。模型在串流輸出時，計量器同步推進；數據服務按回傳位元組計費。賣方仍可透過設定上限、增量承諾或關閉通道來控制風險。
動態定價需要私有記憶
另一個巨大的商機——也是筆者公司及該領域其他業者正試圖解決的問題——是讓支付關係能隨時間優化，同時無須將每個代理變成監控目標。
一個已購買數千次數據服務的代理，理應享有更低的單價、更高的上限，或更低的結算頻率。如今，辨識此類客戶的最簡易方式是將每筆請求連結至同一帳戶或錢包，但爭取忠誠度的代價，是曝露無關的活動紀錄。
更理想的系統，或許是讓代理僅證明賣方所需的事項：它已跨越某個用量門檻、維持著一筆有資金挹注的關係，並且過往結算紀錄可靠。Cashu解決了私有支出的問題，卻移除了商家用以辨識忠誠度的訊號。
尚未解決的難題，在於將私有 bearer 支付與選擇性的關係證明相結合——保有足夠的延續性以爭取折扣，又不致產生過多的可連結性以重建每一筆購買紀錄。會話與通道是建構此機制的良好起點，而落實此機制也將催生一種新的商業模式：從無狀態起步，進階至計量會話，再隨時間換取更佳的條件。
為三種模式而設計，而非僅為一種
一個實用的技術堆疊至少應支援以下三種模式：
針對離散、價格明確的購買，或與陌生供應商的首次互動，採用即時扣款——這正是x402的主戰場。針對一次性請求但最終成本未知的情境，採用「授權上限、實際扣款」模式。針對推論、運算、儲存、數據服務等經常性且變動的成本，則採用預付會話或支付通道。
會話模式不應被無限上綱：預付資金會凍結資本並造成供應商的曝險。支付模式應當隨著關係演進而調整。政策層面的設計與支付軌道同等重要——包括每次會話的最高消費額、頻率限制、核准商家、自動加值，以及即時撤銷機制。
最優秀的系統將在人類所關切的層級進行授權，在機器所消耗的層級進行計量，僅揭露關係所要求的資訊，並在經濟效益足以支撐的層級完成結算。