x402 的 payTo 位址變更時，該比較什麼？

五部分比較

先檢查完整要求。

payTo 值必須連同網路、資產、金額、方案與資源來看才有意義。保留用戶端實際收到的挑戰及其時間戳記，才能和已儲存的觀測比較，而不是單獨比較一個位址。

payTo

該付款選項公布的收款對象。出現差異表示用戶端被要求向不同的收款對象值付款。

網路＋資產

結算脈絡。相同的位址文字若位於其他網路，或相同代號指向其他資產識別碼，都不是相同的付款選項。

金額

金額是 IFF 完整選項指紋的一部分。如果方案、網路、資產與收款對象相同而只有金額改變，預檢比較可將其分類為 amount_only。

資源

端點 URL 決定 IFF 記錄與比較範圍。不同主機或路徑應視為不同資源檢查。資源不包含在 IFF 的付款選項指紋內。

先理解脈絡再下結論

變更可能是例行作業。

服務提供者可能輪替資金管理位址、遷移託管服務、變更資產或網路、更新價格，或部署新的資源路徑。快取或延遲的挑戰也可能讓有效的轉換短暫看似不一致。這些都是應調查的可能性，不是 IFF 已證實的解釋。

過期觀測還有另一項限制。IFF 仍會將新要求與最近的觀測時段比較並回報 matches_last_observed，但判定仍為 stale。這能告訴你條件是否符合最後儲存的證據，卻不能讓舊證據成為最新資料。

記錄包含的內容

用歷史記錄確認順序，不推斷動機。

最新的公開證據卡會顯示目前儲存的付款選項與觀測時間。其中 requirements.current 與 requirements.history 區塊會摘要連續的指紋區段，包括首次出現、最後出現與觀測次數。公開歷史記錄能指出正規化後的選項集合發生變更，但不會公開純文字的變更前後說明，也不會把變更歸因於某位操作人員。

1. 比對正確的資源。比較同一個正規化的公開 HTTPS 端點，包括路徑。
2. 檢查時間戳記與新鮮度。較舊的挑戰與較新的觀測可能描述不同但都合理的狀態。
3. 比較所有公布的選項。選項順序與重複項目不會產生不同的正規化集合；方案、網路、資產、收款對象與金額則會。
4. 分開看待所有權與要求。已驗證的所有權維度記錄來源站控制權。它不證明付款位址的控制權，而 observed 層級的卡片可能仍未驗證所有權。
5. 套用自己的暫停付款或升級處理規則。變更超過政策門檻時，請透過另一個可信管道向服務提供者確認。