常見問題
付款已 confirmed，卻又被回滾了
瞭解已進入 detected 或 confirmed 的付款為何仍可能因區塊重組回退到 reverted，StableOps 如何用交易收據和區塊雜湊識別變化，以及商戶為什麼應等待 payment.finalized 再履約，併為回滾事件準備冪等補償流程。
付款是可能回退的。已經到達 detected 或 confirmed 的訂單仍可能回滾到 reverted 併發出 payment.reverted webhook。這是預期行為，不是 bug。狀態機之所以把 confirmed 和 finalized 分開，正是為此。
訂單為什麼會回滾
當訂單匹配到的轉帳不再有效時，StableOps 會將其標記為 reverted：
- 重組（reorg）：一條競爭鏈成為規範鏈，包含該轉帳的區塊被丟棄。StableOps 透過把即時回執（receipt）的區塊雜湊與事件首次攝入時存下的區塊雜湊做比對來檢測：若兩者不再一致，該事件即無效。
- 回執失敗：交易回執報告失敗（例如合約呼叫 revert），轉帳實際並未轉移資金。
為什麼不能在 confirmed 上履約
各階段含義不同：
detected：在鏈上以 0 確認被看到。不要履約。confirmed：確認數已足夠、回滾不太可能，但尚未達到該鏈的最終性保證，仍存在殘餘的重組風險。finalized：已達最終性，轉帳不可被回滾。這是發貨的推薦時點。
請在 payment.finalized 上履約，除非你的產品已明確接受在 payment.confirmed 上行動所帶來的殘餘重組風險。
如何處理 payment.reverted
把它當作此前任何樂觀處理的逆操作：
- 如果你只在
payment.detected/payment.confirmed上更新了 UI，請回滾這些 UI，並提示客戶重新付款或等待重新確認。 - 如果你在
finalized之前發放了任何有價值的東西，這條事件就是提醒你把它追回。 - 冪等地處理該事件。投遞可能被重試，重複處理一次必須是安全的。
相關
這篇文件怎麼樣？
最後更新