IOSOR

IOSOR 知識庫

未送達 vs 拒收 vs 過期：產品與計費用狀態詞典

別再為截圖吵架：把產品、支援與預付費計費對齊到 undelivered、rejected、expired——以及每個狀態真正允許的動作。

投遞率下滑時，產品怪管道，支援貼截圖，財務問預付費錢包為何變動。大半熱度是詞彙失敗。Undelivered、rejected 與 expired 不是同義詞；塞進同一個「失敗」桶會發明錯誤重試、錯誤退款與錯誤事件嚴重程度。

IOSOR 希望 B2B 團隊把訊息當作白標預付費營運：一次儲值、讀取持久狀態事件、維持品牌安全的錯誤用語。本詞典是產品 UX、維運與帳本之間的營運契約。

為什麼狀態用詞比宕機製造更多事故

類別 範例 產品應…
Intermediate queued, submitted, sent 顯示進度；勿慶祝已到手持裝置
Terminal success delivered 解鎖下一步 UX；停止自動重送
Terminal fail undelivered, rejected, expired（若定義為終態） 選擇許可動作；永不無限重試

若 UI 把一切壓成紅叉，凌晨兩點沒人能正確行動。

狀態詞典：產品與計費可共識的定義

Undelivered 通常表示任務已進入即時訊息路徑，但下游訊號稱手持裝置未獲成功結果。常見驅動：關機、收件匣滿、走廊短暫壅塞、訂戶不可達。

許可動作：

  1. 僅在政策與走廊證據支持時做有界自動重試
  2. 對使用者顯示「稍後再試」，勿暗示詐欺
  3. 依已公布借記／退款規則處理錢包——勿在聊天串發明靜默退款

勿把每次 undelivered 當成「平台當機」。先依走廊切片，再決定是否全域告警。

Undelivered vs rejected：不同失敗類，不同修復

Rejected 是政策或入場失敗：內容過濾、寄件身分、合規門檻、畸形目的地、餘額不足，或該能力目錄未 live。任務從未取得公平的手持投遞機會。

許可動作：

  • 修好門（範本、註冊、餘額、目錄誠實）
  • 向營運展示可用且品牌安全的原因碼
  • 永不對相同承載重試指望換一個宇宙

Rejected 風暴首先是合規與目錄問題——不是「加吞吐」。

Expired：TTL、佇列與 OTP 時間窗

Expired 表示在終態成功前有效期視窗已關閉。常見於 OTP（TTL）、超過 SLA 的佇列任務或網路有效期。產品須區分 user expired（使用者停滯）與 network expired（管道未及時送達）。

許可動作：

  • 提供帶冷卻的可控重送
  • 在 Verify 流程作廢先前驗證碼
  • 新嘗試再次借記時清楚歸因花費

無冷卻自動重送的過期 OTP 是詐欺與花費放大器。

狀態 UX 文案姿態 典型預付費姿態 維運下一步
Undelivered 短暫／手持不確定 遵循已公布借記／退款政策 走廊切片＋證據包
Rejected 可行動的門失敗 通常無成功投遞嘗試 修門；停止相同重試
Expired 時間窗關閉 依政策為已消耗嘗試借記 重送冷卻；新關聯 ID

接近每月 USD 1,000+ 平台用量時，狀態語言錯配會變成商業糾紛——不是支援趣聞。試點仍可先在兩條走廊驗證詞典。

  1. 產品、支援與財務共享的書面詞典
  2. 帶持久 ID 的 Webhook 或可輪詢事件
  3. 維持白標安全的可區分原因碼
  4. 與每個終態失敗類配對的重試／重送政策
  5. 財務可依狀態結果對帳的錢包匯出
  6. 目錄誠實，使「rejected: not live」說得出口

危險信號

  • 只有「failed」一種狀態
  • 截圖是唯一狀態系統
  • 對 rejected 自動重試風暴
  • 錢包變動無狀態軌跡
  • 面向客戶的失敗原因出現外來品牌文案

從 IOSOR 開始

請在 IOSOR 控制台中對應您的狀態回呼，讓計費整合能清楚區分早期拒絕、下游未送達事件與佇列逾期。稽核您的啟用中網Webhook，確保終端 DLR 狀態碼能將明確的錯誤類別傳遞至內部帳本，而非通訊失敗狀態。接著調整您的發送閘道參數，在遭遇硬拒絕時立即抑制重試，同時微調一次性密碼訊息的存活時間極限。

IOSOR 要點

本指南說明狀態模糊屬於產品設計與會計難題，而非單純的網路故障。區分電信業者拒絕、下游未送達狀態與存活時間逾期，能釐清財務責任，並防止支援團隊在應用程式碼中盲目追查幽靈錯誤。

請將下游 DLR 網Webhook狀態直接對應至您的計費帳本，以確保透明的發票對帳。切勿將所有訊息掉落歸納為二元的已發送或失敗狀態，以免掩蓋訊息究竟是由於格式錯誤、網路過濾或計時視窗逾期而失敗。

這篇指南有幫助嗎？

相關指南