簽章與重放時窗閘道

未簽章或過期的 webhook 不是狀態真相，絕不能推動預付金流。買家需要在任何事件更新帳本或產品狀態之前，設置一道硬性的閘道：驗證簽章加上具時效的重放時窗。本頁即是該閘道——而非金鑰輪換的泛談，亦非入站 SMS 重試的指南。

相關：回呼簽章與重放時窗、入站 webhook 的重試與冪等、產品與財務的共用狀態語言、同一帳本上的扣款列與送達狀態。

IOSOR 是白牌預付系統。USD 20 可資助單一消費者上的閘道試驗；當使用量接近 USD 1,000/month 時，若略過驗證則會被視為偽造狀態的高風險。客戶僅會看到白牌拒絕巨集。

簽章驗證是金流閘道

金流與狀態真相僅在通過簽章檢查後方告成立。缺少、不符或略過的簽章一律拒絕——沒有帳本列，也沒有「試驗期間照常送達」。Catalog Live 不得略過此閘道。習慣深度：回呼簽章與重放時窗。溫和的 USD 1,000/month 將「在測試環境永遠接受未簽章資料」視為生產債務；USD 20 則證明單一偽造主體絕不會寫入扣款。

狀態真相前的重放時窗

「至少一次」送達機制將會重試。時窗外的延遲重試並非「可能已送達」。請將時窗拒絕與簽章失敗分開記錄。入站重試深度：入站 webhook 的重試與冪等。

閘道拒絕時採取失敗關閉

被拒絕的事件絕不虛構成功。產品與財務共享相同的拒絕字詞——而非英雄主義式的上游代碼：產品與財務的共用狀態語言。扣款列僅與已接受的事件保持一致：同一帳本上的扣款列與送達狀態。副作用僅在 ACK 之後發生；在閘道前進行 CRM 作業只會製造雙重真相。

產品、財務與維運共用同一證明

產品：合法的已簽章且在時窗內的事件是否能更新一次狀態？財務：每筆影響金流的事件是否在同一個 UTC 時窗顯示閘道通過？維運：能否導出簽章失敗與時窗拒絕而不需翻找 Slack 紀錄？在時窗內的重複事件呈現單一帳本線之前，量級語言維持封鎖狀態。

簽章重放閘道的買家檢查清單

1. 在每位付費流量的生產消費者上部署簽章中介軟體？
2. 重放時窗已命名、記錄且受限制——而非「數週」？
3. 閘道拒絕絕不寫入金流或成功狀態？
4. 時窗內的重複事件 ID → 單一最終狀態，無二次扣款？
5. 維運可分別計算簽章失敗與時窗拒絕次數？
6. 閘道關閉時阻斷 USD 1,000/month 的溫和討論？

任何「否」都會將閘道——以及受信任的 webhook 真相——留在草稿階段。

從 IOSOR 開始

請在 IOSOR 主控台中為所有進站 Webhook 啟用簽章驗證中介軟體，然後再將正式流量導向過去。請在重播視窗閘道上設定嚴格的時間戳記邊界，以自動拒絕逾期或未經身份驗證的酬載。請確認閘道拒絕會觸發立即的失敗關閉處理，確保未驗證的 Webhook 絕不會到達您的財務帳本。

IOSOR 要點

本指南確立了簽章驗證與具時間限制的重播視窗，可作為財務與狀態真實性的強制閘道。對無效簽章或過期時間戳記採取失敗關閉處理，能防止重複的狀態處理，並在產品、財務與營運之間維持唯一的證明來源。

請務必在正式上線前，對所有作用中的 Webhook 取用者強制執行簽章驗證與具邊界的重播視窗。切勿針對試驗流量繞過簽章閘道、忽略重複的事件識別碼，或是為被拒絕的進站酬載捏造成功狀態。