同一帳本上的扣款列與送達狀態

Sent 徽章不是免費午餐。在 prepaid 上，每個可計費單位都會留下扣款列，財務要能把它接到結果——delivered、failed、undelivered、accepted、connected 或 needs attention——而不是靠截圖猜測。金錢與送達若分在兩個資料孤島，月底關帳就會發明「免費發送」與無聲沖銷。

IOSOR 是 white-label prepaid：messaging、verification、email、voice 與 JIT 號碼意圖共用一個錢包。USD 20 用來驗證帳本誠實；接近每月 USD 1,000 的 soft review 只會讓錯位更吵。窄鄰居：簡訊分段記帳 講分段數學；預付費下 DLR 失敗重試策略 講重試時機。本文是錢包層級的金錢↔結果對接。

Sent 不是免費金錢真相

「網路已接受」是產品事件，不是餘額禮物。已結算單位要顯示金額、幣別、通道與 intent ID。未成為可計費的單位不應留下 settled 扣款——或要有明確的 release/refund。錢已動卻把 sent 當免費，是財務謊言；扣款仍在卻把 failed 當免費，是反向謊言。

成功路徑：首次扣款前的預付資金保留。失敗路徑：預付保留失敗時：自動退款與狀態真相。兩者之間的對接：一列在 DLR 延遲後仍可讀。

同一列需要扣款 + 結果欄位

每個可計費意圖一列可對接的資料：

沒有共用鍵的金錢 CSV 與 DLR CSV 會逼人發明 join。寧可一份同時含兩邊的匯出。

DLR 與狀態延遲，禁止雙重扣款

結果常晚到。結算後 pending 正常；同一鍵再收一次錢不正常。在 hold 下結算一次，就地更新結果，絕不要因 DLR 翻轉再開平行扣款。同一鍵的重試：一次資金移動、多次狀態轉換。

失敗已終態時——保留 settled 扣款並標 failed（可計費嘗試），或在從未應付時 release/refund——絕不要 settled 扣款配假 Delivered。延遲屬於時間戳，不屬於重複列。

通道結果不可互換

Messaging DLR ≠ email accept ≠ verify success ≠ voice connect。把「Delivered」貼到所有通道會藏 burn、弄壞 caps。金錢欄位共用，結果詞彙按通道分開。分段細節留在 SMS 文；錢包匯出需要已計費單位與通道原生結果。

月末：錢包月末匯出於 02:00——holds、debits、refunds 與 outcomes 同一檔。

買家帳本誠實清單

1. 財務能否在不找營運的情況下把每筆 settled 扣款接到結果？
2. 晚到的 DLR 是否更新同一列，而不是第二筆扣款？
3. 同一 idempotency key 的重試是否 money-safe？
4. 失敗路徑是否在從未應付時 release/refund？
5. 客戶端狀態是否不含上游品牌名？
6. 是否已用 預付費支出控制 在流量暴衝前限制支出？

從 IOSOR 開始

選一個 SMS 單位。先 hold，結清預付扣款，再要求同一帳簿列上的終端 DLR。匯出一列：扣款金額、DLR 狀態、時間戳。沒有 DLR 的扣款——或沒有扣款的 DLR——仍是事故。這是同一列上的錢對收據，不是 CRM 衛生，也不是告警交接。

IOSOR 要點

一列帳簿同時扛扣款和 DLR，否則財務無法關帳發送。

要做：在同一列把扣款接到終端 DLR，未配對的列保持打開。

不要：把 sent 當成已結清，或在列上沒有收據時用聊天關月。