IOSOR 知識庫

帳號存取權不等於正式環境發送權限

控制台登入與沙箱金鑰不代表實際上線流量。在申請存取權後進行任何正式發送前，請確保目錄真實性與第一天跑道閘門運作正常。

帳號存取權意味著您可以開啟控制台、建立專案並取得沙箱憑證，但這絕不代表正式環境發送已獲得授權。這個認知落差往往是團隊損害信任之處：他們將沙箱金鑰直接部署至客戶路徑中，並誤以為這就是已上線狀態(Live)。

IOSOR 堅持嚴格且明確的切換流程。沙箱憑證用於驗證整合架構與流程，而不會引發實際扣款的糾紛。只有透過保險庫背書的正式金鑰、目錄 Live 標籤，以及 Launch 跑道綠燈，才代表您可以開始收取預扣款並離開試播通道。

完成申請後，請在戰術室(War-room)牆上寫下一句話：存取權不等於 Live。每一次的狀態審查都應以此為起點。

預設將沙箱金鑰視為非正式環境資源

沙箱憑證存在的目的是串接 OTP 流程、Webhook 處理程序與錯誤處理路徑，而不是假裝保險庫已經通過驗證。請在密鑰管理器中明確標示沙箱憑證，並嚴禁在獲得存取權後的第一個 Sprint 中將沙箱金鑰貼入正式環境的配置檔(.env)。如果合作夥伴在獲得存取權的第一天就要求提供正式金鑰，請以切換清單進行回應：保險庫項目、目錄 Live 閘門以及跑道冒煙測試。單憑存取權並非完整的檢查清單。

在實際維運中，請確保開發團隊使用獨立的環境變數檔案。針對沙箱金鑰設定嚴格的額度上限與速率限制，避免因誤用而導致非預期的測試失敗。當測試進入端到端階段時，所有模擬請求都應記錄在專用的稽核日誌中，以便日後與正式環境流量進行比對與追蹤。

目錄上線狀態仍須與保險庫一致

目錄的真實性不會因為申請完成而放鬆標準。一個標記為 Live 但缺乏保險庫密鑰的服務卡片，對客戶而言就是一種不誠實的表現。在冒煙測試通過之前，設定中(Setup)與建置中(In setup)的標籤必須保持準確。

取得存取權後，在進行任何展示或演示(Demo)之前，必須先審查目錄狀態。對於未通過保險庫檢查的產品，請維持其為設定中標籤。若銷售簡報在登入後就將所有通道顯示為 Live，將會產生即便儲值錢包也無法解決的客服工單。

將目錄審查與 Launch 跑道語言結合，讓產品展示與營運團隊共享同一個真實狀態，避免因資訊不對稱造成交付延誤與客戶抱怨。

跑道綠燈仍是首次發送的必要關卡

第一天的跑道項目——例如 Webhook 心跳(Heartbeat)、訊息傳輸準備狀態、驗證(Verify)及相關閘門——在獲得存取權後依然屬於 Launch 的範疇。完成 KYC 審核並不會自動讓這些項目變成綠燈。

請將首次正式發送視為跑道里程碑，而非申請里程碑。在金鑰離開沙箱模式之前，必須指定明確的負責人並提供證明(如冒煙日誌、心跳更新時間等)。

如果跑道顯示為紅燈，即使錢包已經完成儲值，也請將流量留在沙箱中。錢包有錢但保險庫未亮綠燈，依然不等於正式上線。

向利益相關者說明三種不同的綠燈狀態

存取權綠燈(Access green)、錢包綠燈(Wallet green)與跑道綠燈(Runway green)是三種完全不同的營運狀態。如果混淆這三者，必然會有人在錯誤的看板上記錄並宣佈正式上線。

每週營運會議應同時展示這三種狀態。「存取權完成 / 錢包已儲值 / 跑道紅燈」是初期非常正常的狀態——此時應慶祝配置進度，而不是宣告正式發送。

當合作夥伴詢問明確的上線日期時，請引導他們關注跑道負責人與目錄 Live 閘門，而不是指向申請通過的通知電子郵件。

從 IOSOR 開始

請審查您的工作區主控台，確認沙盒憑證已明確標示，並與正式環境的密鑰儲存庫區隔。在保險庫密鑰通過驗證且網路鉤子端點回報健康狀態之前，請暫緩正式環境的派送閘道。請檢查您的型錄磚塊是否維持在設定狀態，直到正式金鑰驗證成功為止。

IOSOR 要點

透過身分驗證審查後取得帳戶存取權限，只是一個營運里程碑，並不代表獲得觸發正式發送的許可。沙盒憑證的存在純粹是為了驗證整合，而正式狀態則需要經過驗證的保險庫密鑰與明確的執行核准。

請維持型錄的真實性，在保險庫檢查通過前，讓型錄磚塊保持在設定狀態。切勿將存取權限過關與執行準備就緒混為一談，也切勿憑藉沙盒憑證來推送正式流量。

這篇指南有幫助嗎？