x402 支付與穩定幣：一個面向智慧體的支付棧還需要什麼

x402 很適合按請求計費的介面和機器呼叫。它把支付協商放進 HTTP 互動本身，讓用戶端先收到 402 Payment Required，再對支付負載簽名並帶著要求的頭部重試請求。這個層次是對的，但它只是協議層，不是完整的生產支付棧。

如果你在經營真實的商戶系統，x402 之後仍然需要訂單模型、鏈與資產策略、最終性策略、事件通知處理和審計恢復。如果智慧體可以代表使用者或某個工作流花錢，你還需要工作區級別的許可權策略，明確誰能發起或批准扣費。x402 負責支付握手，你的應用仍然負責業務判斷。

從協議本身看，目前的 x402 v2 文件把它描述為一個開放的 HTTP 支付流程，使用 PAYMENT-REQUIRED、PAYMENT-SIGNATURE 和 PAYMENT-RESPONSE 這些頭部。資源伺服器可以自行驗證和結算，也可以把這些操作委託給協調服務。你可以把它理解為協商層和傳輸層，不要把它誤解成完整的商戶營運模型。

x402 到協議邊界就結束了

最清楚的理解方式，是把協議、可選的協調服務和商戶營運拆開看。

這個分層很關鍵，因為協議成功不等於業務完成。一次請求可以已經付費、已經結算，但後面仍然要做很多事：寫帳本、扣配額、開通許可權、觸發工作流。那些都屬於商戶側。

如果你的賣方系統也由智慧體操作，就要把智慧體策略和支付機制分開。MCP 伺服器負責把工具暴露給智慧體，而智慧體策略決定哪些工具可用、寫操作是否需要審批。x402 不會替你補上這個護欄。

x402 適合什麼，不適合什麼

x402 最適合的，是那些單次、同步、機器能理解的付費動作。

分界線不在於是不是用穩定幣計價，而在於協議層的支付事件是否已經足以觸發業務副作用。很多產品並不是。

如果某個請求只是解鎖 HTTP 回應，那協議握手可能就夠了。一旦這個請求還會寫入配額、傳送郵件、開通許可權、改客戶資料，或者觸發其他內部流程，你就需要商戶側狀態和恢復能力。這也是 StableOps 仍然重要的原因。

如果你想先對照一個不涉及智慧體的基線，可以看不託管資金的 USDC 收款架構和確認狀態模型。這裡的道理是一樣的：支付事件只是更大營運流程中的一個邊界。

生產裡仍然需要狀態機

就算協議握手很快，智慧體支付棧也仍然需要明確的狀態機。

HTTP 請求
  -> 建立或複用商戶訂單
  -> 以訂單收款地址作為 payTo，返回 402 / PAYMENT-REQUIRED
  -> 用戶端對支付負載簽名
  -> 資源伺服器自行驗證並結算，或委託協調服務處理
  -> 伺服器端返回資源
  -> StableOps 檢測、確認並最終確認匹配的轉帳
  -> payment.finalized 事件通知
  -> 不可逆的下游業務動作

StableOps 提供的是商戶側那些能抵抗重試和重放的部分：付款訂單、事件通知、確認狀態和審計軌跡。這樣你就能把協議層和業務層分開，而不會丟失可追蹤性。

下面是一個簡短的商戶側示例。它會在任何不可逆動作前先把請求記錄成持久化訂單，並保持這個請求的身份在重試之間不變。

import { StableOps } from '@stableops/api-sdk'

const stableops = new StableOps({
  apiKey: process.env.STABLEOPS_API_KEY!,
})

export async function openAgentCharge(input: {
  requestId: string
  agentSessionId: string
  resource: string
  amount: string
}) {
  const order = await stableops.paymentOrders.create(
    {
      merchantOrderId: `x402:${input.requestId}`,
      amount: input.amount,
      acceptedAssets: [{ chain: 'base', asset: 'USDC' }],
      expiresAt: new Date(Date.now() + 10 * 60 * 1000).toISOString(),
      metadata: {
        rail: 'x402',
        agentSessionId: input.agentSessionId,
        resource: input.resource,
      },
    },
    { idempotencyKey: `x402:${input.requestId}` },
  )

  const paymentInstruction = order.paymentInstructions.find(
    (item) => item.chain === 'base' && item.asset === 'USDC',
  )

  if (!paymentInstruction) {
    throw new Error('未分配 Base USDC 收款指令')
  }

  return {
    order,
    payTo: paymentInstruction.address,
  }
}

重點不在程式碼長什麼樣，而在身份控制和地址繫結。只要是同一個請求，就要複用同一個請求標識、商戶訂單標識和冪等鍵。讓 x402 賣方整合在建置 PaymentRequirements 時使用這裡返回的 payTo 地址，並確保鏈、資產和金額與 StableOps 訂單一致。把資源資訊和智慧體上下文寫進 metadata，這樣匹配的轉帳就能在審計或對帳時追溯到原始請求。

這裡的地址繫結是必要條件：僅建立 StableOps 訂單，並不會自動接收或關聯一筆無關的 x402 結算。只有當 x402 把精確金額結算到訂單分配的 payTo 地址後，StableOps 才能檢測這筆轉帳並推進訂單狀態。收到最終的 payment.finalized 事件通知後，再把它作為下游副作用的不可逆邊界。事件通知指南解釋了投遞、重試和重放；事件通知驗籤指南說明了如何在處理前驗證原始請求體。

智慧體支付需要策略，不只是支付通道

智慧體會讓營運側變得更重要，而不是更不重要。它們會成批發起請求、積極重試，並且可能在沒人盯著的情況下花錢。這意味著支付棧需要策略，也需要傳輸。

用智慧體策略決定哪些工具或動作可以建立或批准扣費。用付款訂單讓商戶側保持確定性。用事件通知把鏈上進度變成持久化事件流。用確認狀態模型決定在什麼副作用上可以接受什麼級別的支付狀態。

StableOps 負責把這些決定變得可審計、可恢復。x402 負責讓請求本身參與支付。

生產檢查清單

• 在開放 x402 之前，先定義哪些端點或資源需要收費。
• 每次扣費都使用穩定的商戶訂單標識和冪等鍵。
• 把智慧體許可權控制留在智慧體策略裡，不要寫進支付程式碼。
• 除非產品明確接受更高風險，否則把 payment.finalized 作為不可逆邊界。
• 把請求標識、智慧體會話標識、付款訂單標識和交易雜湊一起儲存。
• 保持事件通知處理器短小，並且對重放安全。
• 把協議層成功和商戶側履約分開對帳。
• 上線前先測試重試、重複請求、結算延遲和營運人員重放。

常見問題

做智慧體支付一定要用 x402 嗎？

不一定。x402 只是把 HTTP 互動變成“可支付”的一種方式。更本質的要求還是一樣：要有持久化的商戶訂單、清晰的策略、最終性邊界和恢復流程。如果你已經有這些，x402 可以成為協商層，而不是整個方案本身。

協議結算和業務履約是一回事嗎？

不是。支付可以已經結算，但仍然不足以驅動你自己系統裡的不可逆副作用。如果一次請求會改變 HTTP 回應之外的狀態，最好等商戶側的最終事件，通常就是 payment.finalized。

如果我要安全地支援智慧體自動花錢，應該先看什麼？

先看智慧體策略，再看付款訂單、事件通知和確認狀態模型。如果你想先看一個不涉及智慧體的基礎實現，可以再讀如何在不託管資金的情況下接受 USDC。

從小處開始

如果你要試點 x402，先選一個範圍較小的介面資源、一種商戶訂單結構和一個不可逆副作用。擴充套件之前，先接入事件通知流程和確認模型。協議讓機器支付成為可能，而協議周圍的那一層，才決定它能不能安全進入生產。