沙箱與正式金鑰：避免雙重計費的切換清單

留在正式組建裡的測試金鑰，會把壓測變成真發票。把正式金鑰貼進預發環境「只是檢查一下」，會讓預發的漏洞打到真實收件人。本指南面向在預付白標整合上需要乾淨 沙箱→正式切換 的工程負責人——既不雙倍帳單，也不雙倍爆炸半徑。

IOSOR 在設計上把沙箱與正式放在不同金鑰、不同信用姿態、不同 webhook 目標上——下面的切換清單，是讓這種隔離在真正上線日寫進日曆後依然站得住。接近每月 USD 1,000+ 平台用量時，搞砸的切換不是缺陷報告，而是一場對帳專案。

為何沙箱/正式混淆會變成計費事故

沙箱金鑰與正式金鑰如何區分

• 獨立的憑證身分，絕不是用「environment」查詢參數共用一把金鑰；在 IOSOR 主控台，沙箱金鑰應有明確的前綴，例如 `sandbox_`。
• 不同的速率限制；在相關場景下，可達目的地範圍也不同，例如沙箱金鑰可能僅限於測試號碼或特定網域，而正式金鑰則無此限制。
• 獨立的 webhook/回調目標，讓測試事件永遠到不了正式監聽器；在 IOSOR 的 webhook 設定中，為沙箱和正式環境配置不同的 URL，並啟用簽章驗證以確保安全。
• 儀表板上有明確不同的前綴或標籤——不要靠盯著字串猜測；IOSOR 的日誌和儀表板應清晰標示金鑰的來源環境。
• 預付錢包配置：沙箱金鑰不應關聯真實的預付錢包，或僅關聯極少量測試用餘額；正式金鑰則需確保有充足的預付餘額以支應預期流量。

避免雙重計費的切換順序

1. 凍結沙箱流量：在切換前，暫停所有由沙箱金鑰發起的自動化測試或流量，確認正式程式碼不再引用沙箱憑證。
2. 簽發最小權限正式金鑰：按實際在用的發送類型（例如 SMS、Voice、OTP），以最小權限範圍簽發正式金鑰；在 IOSOR 主控台，為正式金鑰配置必要的權限，避免不必要的風險。
3. 配置正式 webhook 與 DLR：在第一次真實發送前，將 webhook 與 DLR 回調 URL 指向正式端點；確保 DLR 狀態更新能被正確接收和處理。
4. 執行單次驗證發送：使用新的正式金鑰做一次真實、有意的發送（例如發送一個測試 OTP 或短訊），並精確核對該帳本行，確認費用、狀態和 DLR 回調均符合預期。
5. 驗證並切換：確認單次發送無誤後，正式將應用程式指向正式金鑰。吊銷或降低沙箱金鑰觸達真實目的地的能力，例如將其設定為僅能發送至測試號碼，或完全停用。

無停機的金鑰輪換與吊銷

按計畫輪換，並在懷疑洩露後立即輪換——但錯開吊銷：先簽發新金鑰，確認其上有真實流量，再吊銷舊金鑰。同時簽發並吊銷，會讓中途部署的真實客戶流量失去鑑權。

• 兩個環境都啟用 webhook 簽章校驗，不只是正式；IOSOR 支援簽章驗證，務必在沙箱和正式環境都啟用。
• 沙箱目的地可達性受限（僅測試號碼/網域），讓洩露的沙箱金鑰無法產生真實支出；在 IOSOR 中配置沙箱金鑰的目標限制。
• 沙箱速率限制更低，讓失控的測試腳本盡快暴露；在 IOSOR 主控台為沙箱金鑰設定較低的速率限制。
• 每條日誌與儀表板檢視都顯示環境名，而不是僅靠金鑰前綴推斷；確保 IOSOR 的日誌記錄包含環境標識。

切換後，拉取切換週的每筆扣款，並按金鑰 ID 打上沙箱或正式標籤。對真實收件人的沙箱標籤扣款，或凍結沙箱視窗內的正式標籤扣款，正是倉促切換留下的訊號。

正式金鑰存取預設應窄於沙箱——更少的人、有日誌的簽發、每把金鑰有具名負責人。合約結束三個月後仍持有正式金鑰的承包商不是假想；任何切換稽核都該先查這一點。

危險訊號

• 用環境變數切換的一把共用金鑰，而不是兩把真實憑證；IOSOR 應提供獨立的金鑰管理。
• 沙箱 webhook 簽章校驗被關掉「方便測試」；這會讓測試流量的安全性降低。
• 沒有記錄誰在何時

簽發了哪把金鑰；確保 IOSOR 的金鑰管理有詳細的操作日誌。

• 正式切換沒有沙箱路徑的回滾計畫；應準備好在出現問題時快速切換回沙箱環境。
• 壓測對著正式金鑰跑「就這一次」；這類行為極易導致意外支出。
• 預付錢包餘額不足以支應預期流量，導致正式訊息發送失敗。
• 未正確配置 DLR 回調，導致訊息狀態更新不即時，影響監控與除錯。

從 IOSOR 開始

請開啟 IOSOR 主控台憑證面板以稽核現有的 API 金鑰，並確認測試環境使用獨立的沙盒前綴。在正式部署程式碼前，請於入口網站更新回呼路由，確保正式網頁鉤子指向正式端點，並配置 DLR 回調 URL。在撤銷舊版沙盒憑證之前，請先使用新的正式金鑰執行單一零費率 Ping 測試，並確認預付錢包餘額充足。

將此切換流程標準化為運維清單的一部分，並在每次 Live 操作前進行嚴格審核。確保所有測試流量都經過適當的速率限制和目的地限制，以防止意外支出。在正式環境中，應啟用所有安全功能，包括 webhook 簽章驗證和 DLR 狀態監控。對於 OTP 發送，應設定專門的「quiet hours」或流量控制，以避免在非工作時間觸發大量註冊或驗證流程，從而節省預付費用。

• API 第二個月：管理第一階段後的冪等性債務
• 解析 DLR 狀態碼以識別電信商過濾機制
• 錢包與用量覆盤治理

IOSOR 要點

跨環境使用相同的憑證，或僅透過簡單的旗標切換行為，勢必會導致模擬負載打入正式通道並產生未預期的帳單。透過獨立前綴與專屬網頁鉤子落實清晰的憑證隔離，可確保測試流量絕不會消耗真實餘額或觸發正式事件。

建議採取階段式金鑰輪替，先發行新的正式憑證並確認訊息流正常運作後，再撤銷舊金鑰。請勿依賴由查詢參數切換的共用 API 金鑰，亦切勿為了便宜行事而關閉 staging 測試的網頁鉤子簽章驗證。在預付白標平台上，精確的流量控制和環境隔離是避免雙重計費和意外支出的關鍵。配置 DLR 回調以監控訊息狀態，並在必要時設定「quiet hours」以管理 OTP 發送高峰。確保預付錢包始終有足夠餘額，並對沙箱環境的金鑰設定嚴格的速率和目的地限制。