DID 第二個月：UTC 日曆翻轉時的完整月租費 (MRC)

管理虛擬號碼的生命週期需要對計費週期有清晰的認識，特別是從初始獲取階段轉向長期維護階段的過程。與服務首日遵循的 DID 首月開通與按日折算算法 不同，進入第二個月後，系統將引入標準的完整月租費 (Monthly Recurring Charge, MRC)。這一轉變嚴格受到 UTC 日曆的管轄，旨在確保您帳戶下分配的所有全球資產能夠實現同步計費，從而簡化企業級的財務對帳流程。對於在多個時區運營的企業而言，這種統一的計費時間點是確保預算透明度的關鍵。

從按比例折算到完整租金的 UTC 轉換

當號碼首次通過 JIT (Just-In-Time) 供應模式分配給用戶時，系統會根據當前月份剩餘的天數精確計算部分費用。然而，一旦時鐘在每個月的第一天達到 00:00 UTC，DID 發票週：按比例計算與完整日曆月對照 的邏輯就會發生本質上的轉變。此時，系統不再考慮該號碼在月中具體哪一天被激活，而是將其識別為活動資產，並直接應用完整的月租費。這種自動化的轉換機制消除了手動干預的需求，並為大規模號碼庫存的管理提供了極高的預測性，確保您的運營成本與日曆月份保持一致。

每月一日的預付餘額邏輯

IOSOR 採用嚴格的預付模型來維持服務的穩定性。為了確保通信鏈路不中斷，系統必須在 UTC 翻轉的瞬間，擁有足夠的資金來覆蓋帳戶內所有活動 DID 的完整 MRC。如果帳戶餘額低於所需的總額，系統可能會觸發自動化的暫停協議，以防止帳戶出現負資產或欠費情況。我們強烈建議用戶維持至少 USD 20 的預付底線，這是一個基本的安全緩衝，可以確保高流量的號碼塊在午夜轉換期間不會因為瞬間的扣款而導致帳戶餘額耗盡。這種預防性措施對於維持企業級服務的連續性至關重要。

初始設置與循環週期的比較

規模化門檻與餘額審查

隨著您的業務規模擴張，DID 庫存的總 MRC 可能會顯著增加。對於那些每月總循環成本或使用費用接近 USD 1,000 的帳戶，我們的財務團隊會執行例行的軟性審查。此審查並非限制您的使用，而是為了確保預付架構已針對您的特定流量模式(如高頻 SMS 發送、OTP 身份驗證或大規模語音服務)進行了優化。在這種規模下，維持一個遠高於 USD 20 底線的健康餘額緩衝，是防止因突發流量或月度扣款導致服務中斷的最佳實踐。這有助於確保您的全球通信基礎設施在任何情況下都能保持彈性。

技術 Webhook 與號碼狀態

為了實現會計流程的完全自動化，開發者可以利用在 MRC 扣費成功時觸發的 Webhook 通知。當系統在 UTC 時間 1 日處理完整租金扣除時，會同步生成一條詳細的分類帳分錄。您的後端應用程序可以監聽這些 Webhook 事件，以便即時更新內部數據庫中的號碼狀態。這對於維護準確的 DLR (送達報告) 跟踪以及確保 10DLC 或免付費流量的 HB (心跳) 監控保持綠色狀態至關重要。如果某個號碼因餘額不足而未能成功續訂，系統會通過 Webhook 發送警告，讓您的運維團隊能在第一時間採取補救措施，避免業務受損。

開始使用 IOSOR

UTC 1 號 00:00，凡仍指派的 DID，租金列變成全額 MRC。第一個月是開通費加剩餘天數。匯出日曆翻轉，財務別再等同一號碼的另一次按日。

IOSOR 要點

第二個月是整月 MRC，不是剩日算術。

要做：UTC 1 號前備好全額租金。不要：把第二個月當又一次按日。