正式環境登錄前的閃撥驗證證明

在將閃撥（Flash-call）流量遷移至正式環境之前，進行嚴格的 CLI（來電顯示）驗證至關重要。此過程確保了用戶接收到的來電顯示與預期一致，避免因下游電信商修改 E.164 CLI 格式而導致的驗證失敗。端到端測試是驗證 CLI 完整性的關鍵，直接影響應用程式的轉換率和用戶信任度。

CLI 驗證要求

閃撥 OTP（一次性密碼）流量的路由前置條件是 CLI 在終端用戶手機上的準確呈現。驗證機制依賴於用戶輸入來電號碼的最後幾位數字。若下游電信商在傳輸過程中篡改 CLI，驗證將失效。在啟用正式環境登錄前，必須執行全面的端到端測試，以確認 CLI 的端到端一致性。這能預防因 CLI 變更導致的高失敗率，是維持高轉換率與用戶信任的基石。操作上，需監控 DLR（Delivery Receipt）狀態，並對照預付帳本的扣款記錄，確保每一筆閃撥請求都伴隨著正確的 CLI 資訊傳輸。

預付帳本與 JIT 分配

閃撥服務採用即時（Just-In-Time, JIT）分配模型，並嚴格依賴預付帳本進行資金管理。每次閃撥請求都會觸發預付帳本的預扣款項。帳本狀態的變化直接影響路由的通過與否。CLI 狀態的判定標準如下：

值班交接時，必須明確定義 DLR 監控者、帳本對帳人員以及擁有暫停路由權限的職責。在流量高峰期前，需按清單逐項複核所有路由配置與帳本狀態。對帳或匯出操作必須包含統一的 `intent` 或 `session` 鍵，以便財務團隊進行精確的回溯與審計。確保預付帳本餘額充足是持續服務的基礎，餘額不足將直接導致服務中斷。

測試閃撥交付

針對不同目標網路執行一系列測試呼叫，並密切監控 Webhook 負載以獲取即時狀態更新。當用戶正確輸入驗證碼後，成功的測試應返回 `Verify OK` 狀態。若 DLR 顯示已送達，但實際接收到的 CLI 已被修改，則該路由被視為不穩定。在確認 CLI 的端到端一致性之前，切勿將正式流量導向此路徑。每次測試嘗試都應被詳細記錄，以便分析不同地區電信商的行為模式，從而在正式上線前排除潛在的技術障礙。此階段的測試應包含對 `quiet hours` 的模擬，驗證系統在非工作時間的響應機制。同時，應測試 `corridor` 設置，確保流量在預設的通道內穩定傳輸。

值班交接時，必須將 DLR 狀態判讀、帳本對帳流程以及路由暫停操作的標準化說明納入交接內容。在流量高峰期來臨前，必須依據預設清單完成所有關鍵節點的複核。所有對帳或數據匯出操作，都必須附加相同的 `intent` 或 `session` 鍵，以確保財務團隊能夠輕鬆地進行回溯分析。上線前，務必執行窄走廊（narrow corridor）的冒煙測試，確認閘門機制與回退策略觸發正常後，再逐步放寬目的地限制。

停發線路與 `hold` 狀態的記錄，必須能夠在同一份匯出報告中清晰呈現，以取代口頭交接可能產生的信息遺漏。

轉向正式環境登錄

僅當目標網路的 CLI 匹配率穩定達到 95% 或更高時，才應將應用程式切換至正式環境。若月流量接近 USD 1,000 的軟性審查門檻，合規團隊將審計 Webhook 日誌，以杜絕欺詐行為或未經授權的 OTP 流量。此接近 USD 1,000 的審查機制旨在維護平台完整性，並保護帳戶免受意外流量封鎖。合規性是長期穩定運營的關鍵。

集成護欄與資源

為維持高交付率並預防電信商封鎖，請實施嚴格的重試限制。若用戶頻繁請求驗證碼，應觸發 SMS 備援機制或執行 `STOP` 命令。詳細的設置指南，請參閱：

• 第一天跑道：必須亮綠燈的事項
• 驗證先導週：發送首批代碼後的即時 OTP 檢查
• OTP 濫用、時延與成本護欄。

從 IOSOR 開始

在生產環境登錄前，必須完成閃撥路徑的驗證：包括冒煙測試和預付帳本扣款的可見性檢查。這確保了服務的可靠性和資金流的順暢。相關文檔：day1-runway-what-must-be-green, verify-pilot-week-otp-live-checks。

IOSOR 要點

這是可值班的作業紀律，不是話術填充。確保 CLI 驗證的準確性，並監控預付帳本的動態。要做：點名業主並通過閘門檢查。不要：跳過閘門或匿名覆蓋 CLI 資訊。嚴格執行 `quiet hours` 和 `corridor` 策略，並確保 DLR 和 Webhook 的即時更新。預付帳本的餘額管理是持續服務的關鍵，需定期審核與補充。