DID 分配失敗時釋放預付保留金

理解 JIT 號碼配置與預付保留

當租戶透過 API 發起號碼取得請求時，IOSOR 避免持有實體庫存或假裝營運倉庫庫存。相反地，號碼是透過 JIT (Just-In-Time) 上游介面進行配置。為了防範競爭條件，平台會在作用中的錢包上放置暫時的授權保留，這類似於在執行複雜交易前暫時鎖定信用卡額度。此保留的金額會根據預期的月租費 (MRC) 或一次性設定費用計算，確保帳戶有足夠的預付資金來覆蓋潛在的扣款。如果操作成功，此保留會轉變為確認的 MRC 扣款，並從預付錢包中實際扣除。然而，網路逾時、無效的 E.164 格式、上游供應商的內部錯誤或電信商拒絕等因素，都可能中斷此流程。失敗的分配必須立即清除保留，以便資金保持可訪問狀態，供後續路由邏輯或替代配置嘗試使用，避免資金被不必要的凍結。

分配失敗情境解析

考慮一個自動化子帳戶為 OTP (One-Time Password) 或 SMS 行銷活動購買 E.164 DID。API 發送配置負載，觸發針對 USD 20 預付底線的標準餘額檢查。閘道放置保留，但電信商因區域路由故障或號碼不可用而拒絕分配。如果沒有強健的狀態管理和即時回饋機制，這個未連結的預留可能會滯留，鎖定資本並停止自動化流量，導致客戶無法接收重要的驗證碼或訊息。IOSOR 透過監聽負面 DLR (Delivery Report) 回饋，例如 `failed` 或 `rejected` 狀態，或是透過 webhook 逾時訊號 (表示上游未在預期時間內回應)，確保對帳引擎能夠立即識別分配失敗。一旦偵測到失敗，系統會自動放棄預留，並將資金完全恢復到租戶的預付錢包中，同時更新儀表板以反映準確的可用餘額。

自動退款與對帳循環

當配置交易失敗時，不需要人工介入。對帳引擎觸發自動釋放序列，這是一個高度自動化的流程。此機制運作類似於我們指南中詳細說明的流程：預付保留失敗時：自動退款與狀態真相，確保資金絕不會懸而未決。如果訂單在管道後續遇到複雜情況，例如上游供應商在分配後才回報錯誤，營運商也可以參考 號碼下單失敗後的退款與更換 來了解備份與交換狀態。這個自動化循環保證預付餘額反映即時營運現實，無需提交支援工單，從而顯著降低了營運負擔並提高了客戶滿意度。

防止高容量營運中的靜默餘額凍結

靜默餘額凍結會破壞租戶信任，特別是在管理快速規模化的自動化行銷活動時。如果資金被幽靈保留困住，下游任務（如 HB (Health Check) 檢查、webhook 發送、緊急號碼交換或新的 DID 購買請求）將會停滯，導致服務中斷和潛在的收入損失。透過將保留釋放直接與負面 HB 回饋和閘道錯誤代碼掛鉤，IOSOR 保護了平台流動性。每月營運接近 USD 1,000 軟審查門檻的租戶極度依賴這種透明度和即時性，以在語音和訊息通道維持不間斷的通訊流，確保關鍵業務流程的順暢運行。

保留狀態與解決結果比較

從 IOSOR 開始

指派回傳 reject 或 timeout 時，釋放該 order id 上的授權保留。同一列匯出 hold-dropped 與失敗原因。死指派後的幽靈保留會凍住錢包，下次試不了。這確保了預付錢包的準確性，並允許客戶立即重新嘗試購買或使用資金進行其他操作。系統會記錄每次保留釋放的事件，並提供失敗原因，以便進行事後分析和流程優化。

IOSOR 要點

指派失敗必須放保留，否則錢包在說謊。透過即時監控 DLR 和 webhook 回饋，確保失敗的分配不會導致資金被不當凍結。我們實施了嚴格的「安靜時間」規則，以防止在非工作時間或系統維護期間觸發不必要的保留釋放，同時確保在關鍵失敗情況下能夠迅速響應。

要做：reject 或 timeout 就自動釋放。不要：死指派後留下無聲凍結。這確保了預付錢包的準確性，並允許客戶立即重新嘗試購買或使用資金進行其他操作。系統會記錄每次保留釋放的事件，並提供失敗原因，以便進行事後分析和流程優化。我們還支援透過 webhook 通知客戶保留釋放的狀態更新，以提高透明度。