終端使用者發送訊息仍扣除單一預付總帳

嵌入式訊息傳送對終端使用者而言感覺就像免費功能：他們在 SaaS 介面中按下「發送」按鈕，並看到綠色的成功勾選圖示。然而在底層系統中，每一次成功的發送請求，最終都會扣除由 ISV 所擁有的單一預付總帳金額。不會因為產品嵌入了 API，就自動憑空出現第二個資金錢包。若 ISV 未能提供預估扣款所需的預付資金，發送請求就必須失敗並回傳真實的產品錯誤狀態，而不是偽造一個顯示為「已送達」的虛假狀態。系統必須確保每一筆 API 請求與總帳中的扣款記錄有著一對一的明確映射關係。

虛構會計是常見的故障模式：例如應用程式內的點數計量表未獲得 IOSOR 錢包真實資金支援、SaaS 平台在預付總帳不斷消耗的同時發給使用者退款，或者缺少冪等性防護的重試機制導致同一筆 OTP 驗證碼被重複扣款。嵌入式介面雖然隱藏了後台控制台，但 ISV 依然是唯一的資金提供者。

架構文件核心原則：終端使用者發送 ≡ ISV 預付金額扣除。所有設計審查都應以此原則為起點。

即使 UI 顯示產品點數，仍維持單一總帳

售予租戶的訊息套裝方案是 ISV 的商業定價層。這些套裝點數必須精確對映至 ISV 所資助的單一 IOSOR 錢包上的預留(Hold)與實際扣款(Debit)。如果租戶餘額無法與總帳明細行核對，將會成為未來的支援債務炸彈。每週應將租戶的使用量導出並對比錢包帳目明細，確保財務團隊與產品團隊看到相同的額度消耗速度與真實成本。

除非合作夥伴隔離(Partner isolation)屬於明確簽署的合約條款，否則切勿為每個租戶單獨開立第二個 IOSOR 帳號。嵌入式試行專案幾乎總是維持在單一 ISV 帳號下，並配合內部的公平分攤上限與配額控制。

預留與冪等性在嵌入路徑中依然具約束力

伺服器端的發送流程針對 OTP 與交易型 SMS 必須強制使用冪等金鑰(Idempotency Key)。使用者在 SaaS UI 中的一次雙擊操作，絕不能因為重複請求而造成單一使用者意圖被扣款兩次。在連線超時或網路抖動後的重試機制必須沿用相同的金鑰，直到取得終端 DLR(送達報告)或被對映的明確失敗狀態為止。

當錢包餘額不足以建立預留額度時，系統必須回傳產品原生的「餘額不足」或「發送暫停」狀態碼。當預留失敗時，絕不能回傳 HTTP 200 並帶有已送達語意，否則將導致前台介面與後台總帳發生嚴重的資料不一致。

將產品錯誤精確對映至總帳事實

請培訓客服團隊理解中間欄位的總帳真實狀態。針對「UI 顯示綠色成功，但總帳無對應明細行」的客戶工單，會嚴重消耗試行階段的寶貴運營時間。

跨通道交接維持在同一個錢包

如果產品日後在 SMS 之外新增電子郵件或語音服務，除非您在取得財務團隊簽署認可後執行了第二通道交接流程，否則所有支出依然會記錄在同一個預付總帳中。嵌入式架構並不會創造出免費的旁路通道。在 SaaS 設定中開啟另一個 Live 圖磚前，請務必先閱讀錢包相鄰性規範與多通道預算配置與管控說明。

相關運營路徑

• 錢包上的第二通道：支出交接
• 冪等、重試與資金安全
• 安全地跨多租戶帳戶執行速率限制

從 IOSOR 開始

請開啟 IOSOR 主控台，將您的租戶信用額度系統直接對應至主要預付錢包總帳。請確保所有伺服器端的嵌入請求在對主錢包進行保留之前，皆已通過決定性的冪等金鑰。同時，請設定您的網頁鉤端點來處理傳入的發送狀態回報，讓開啟的保留額度能夠順利結算為最終的總帳扣款或釋放。

IOSOR 要點

嵌入式軟體即服務介面可以向終端使用者呈現自訂訊息額度，但每一次的實際發送皆繫結至由獨立軟體開發商資助的單一預付總帳。重試機制、通道擴展以及使用者狀態訊號必須直接與錢包保留額度進行對帳，而非依賴缺乏後端支撐的介面抽象層。

請務必強制執行嚴格的伺服器端冪等金鑰，並將每一個租戶的使用者介面狀態對應至真實的總帳發送狀態回報回應。切勿發明缺乏後端支撐的次要錢包，亦不得允許租戶介面重試在沒有具體總帳保留的情況下執行。