上行 MO 傳送至抑制清單：DID 上的 STOP 指令保護發送信譽

透過上行 MO 自動退訂的架構

當終端使用者對專屬 E.164 DID 上的上行(Mobile Originated, MO)簡訊回覆 STOP、UNSUBSCRIBE 或 QUIT 時，您的 CPaaS 平台必須立即處理此訊號。在 API 層級將號碼儲存在抑制清單(Suppression List)中，可防止後續的下行(Mobile Terminated, MT)流量違反電信業者合規性規則。如果系統試圖向已抑制的接收者發送下行訊息，通訊閘道器必須在進行網路傳輸之前，主動丟棄或將該載荷標記為已跳過(skipped)。此類架構仰賴高可用的記憶體資料庫與持久化儲存層，以確保在多區域節點之間實現毫秒級同步。當訊息到達時，解析引擎會分離出發射方 E.164 號碼，並立即將其寫入該租戶的黑名單資料庫中。此舉能確保任何後續 API 請求均無法將 MT 簡訊推送至電信商網路，徹底避免因頻繁違規而被電信商懲罰或封鎖 DID 號碼。此外，此機制亦能顯著減少無效傳送產生的額外成本，保持整體系統效能與發送信譽。

將上行關鍵字映射至抑制清單

傳入的 MO 載荷會透過 Webhook 抵達系統，內容包含發送者 E.164 號碼、目標 DID、時間戳記以及原始訊息內文。抑制子系統會解析標準合規關鍵字，包括 STOP、CANCEL、END、QUIT 與 OPTOUT。一旦偵測到符合的字串，擷取引擎會清理字串，移除多餘空格與符號、將字元轉換為大寫，並透過正規表示式(Regex)解析器進行過濾。若內文包含獨立的關鍵字或前置關鍵字，引擎將對持久化資料庫觸發原子寫入操作。這意味著無論多租戶架構多麼複雜，該 E.164 號碼都會立刻與該特定子帳戶或全局租戶綁定並列入抑制。此外，系統亦支援反向恢復關鍵字(如 UNSTOP)，當使用者主動發送合規的恢復要求時，引擎會從抑制表中移除該號碼，重新開放下行傳送權限，確保完整的生命週期合規管理與良好的使用者體驗。

Webhook、狀態碼與為何 Skipped 不等於 Failed

當下行發送請求以已抑制的 E.164 目標為對象時，CPaaS 引擎會在將資料傳送到上游路由路徑之前阻斷傳輸。平台會傳回 HTTP 200 OK 回應，並附帶指示為 'skipped_suppressed' 的狀態載荷。針對退訂阻斷傳回 HTTP 4xx 或 5xx 狀態碼屬於反模式(anti-pattern)，因為這意味著基礎設施錯誤或用戶端載荷格式錯誤，進而觸發 API 用戶端 SDK 中不必要的重試邏輯。透過傳回 HTTP 200 OK 以及 'skipped_suppressed'，系統能明確告知用戶端請求已成功接收並按預期規則處理完成，無需進行重試。這不僅大幅降低了 SDK 的重試負擔，也維護了整體系統的穩定度。同時，詳細的狀態載荷能讓企業客戶在自身的 CRM 或分析系統中準確記錄跳過原因，維護兩端資料一致性與透明度。

營運規則與預付餘額控制

管理上行 MO 處理與抑制引擎需要穩定可靠的財務安全機制。CPaaS 平台在嚴格的預付架構下運作，設有 USD 20 的預付底限，以維護不間斷的 Webhook 處理與 DID 路由。如果帳戶餘額降至此最低門檻以下，傳入的 MO Webhook 將會在佇列中暫存緩衝長達 72 小時而非直接丟棄，從而保留關鍵的退訂合規訊號。隨著每月發送量成長並接近每月 USD 1,000 的彈性審查點，客戶經理會評估上行容量需求，確保佇列處理能力與負載平衡保持最佳狀態。在此預付保護機制下，即便遇到短期的資金補充延遲，退訂與合規指令也不會遺失，保障了企業在法規與營運層面的安全性與穩定性。

合規矩陣：上行退訂處理

開始使用 IOSOR

STOP 落到 DID 上，就在下一封 MT 之前把主叫 MSISDN 寫入該租戶的抑制名單。證明後續發送會被拒。匯出 MO 時間戳與名單列。沒有名單寫入的 webhook 2xx 不是這份活；E.164 清洗是另一道閘。

相關: 來電顯示與簡訊傳送者身份辨識：語音上線不等於 SMS 已可正常運作 DID 綁定前的 E.164 正規化：加號、零與空格 首次扣款前的預付資金保留.

IOSOR 要點

DID 上的上行 MO 是名單寫入，不是日誌紀念品。

要做：下一封 MT 之前抑制。不要：把 STOP 標成「已知」卻繼續 MT，或等一週再倒名單。