預付保留失敗時：自動退款與狀態真相

無法完成的預付 hold，必須把資金與狀態留在財務可辯護的位置。失敗不是「稍後再試」的表演。要麼預留回到可用餘額，要麼對已結算金額做明確退款，要麼進入有名稱的終態並凍結重試，直到證據齊全。資金卡住或消失卻仍顯示成功，產品與財務都會不再信任帳本。

IOSOR 是 white-label prepaid。同一規則覆蓋 messaging、verification、email、voice 以及同一錢包上的 JIT 號碼意圖。公開最低充值 USD 20 是試點底線，不能證明 fail 路徑可用。接近每月 USD 1,000 的 review 只會讓失敗列更顯眼。錢包有餘額、通道 live、fail 路徑誠實，是三件不同的事。試點再小，也要先把失敗列匯出給財務看一眼。

失敗是錢包事件，不是 toast

結帳轉圈與「pending」橫幅不是資金真相。失敗之後，錢包要麼釋放了 hold，要麼退回了 debit，要麼帶著財務可匯出的原因凍結了意圖。若產品顯示成功而預留仍未關閉，帳本在說謊。成功路徑見 首次扣款前的預付資金保留；本文寫的是必須扛住的失敗路徑。

自動退款與釋放必須自動化

「營運稍後處理」不是產品。未使用 hold 的釋放與錯誤 settle 的退款，應由建立預留的同一套規則觸發。相同冪等鍵的重複請求必須複用原資金結果——見 冪等、重試與資金安全。部分批次只結算已完成單位，並在同一匯出中退回未用部分。

Release 恢復未用預留。Refund 沖回已結算 debit。客戶端需要時間戳、原因與業務意圖 ID。沒有帳本列的靜默改餘額一律禁止。號碼購買失敗後的更換體驗見 號碼下單失敗後的退款與更換；本文涵蓋所有通道的資金真相。

財務可匯出的狀態詞彙

要求一份能活在 CSV 裡的短名單：

• funds held
• completed / settled
• released
• refunded
• needs attention
• cancelled

不要給從未分配資源、從未接受可計費單位的意圖發明「Activated」「Delivered」或「Live」。「Needs attention」是工作佇列，不是成功的同義詞。若狀態無法帶著金額、幣別與 correlation ID 匯出，那就是表演。

絕不要偽造 Activated 或 Delivered

虛假成功徽章比空搜尋更快燒毀信任。訊息失敗不得看起來像已送達。從未開啟的 verify 工作階段不得看起來像已驗證。從未分配的 JIT 號碼不得佩戴 Activated。低餘額與超上限拒絕應儘可能發生在 hold 之前——低餘額自動停發——避免資金進入死胡同預留。

買家失敗誠實清單

1. 每次失敗的 hold 是否以 release、refund 或帶負責人的 needs-attention 凍結結束？
2. release 與 refund 是否由產品事件自動觸發，而非聊天工單？
3. 財務能否在不開工單的情況下把失敗列接到原意圖 ID？
4. 相同鍵的重試是否最多只移動一次資金？
5. 客戶端錯誤是否品牌安全且不含上游品牌名？
6. 可用餘額過低時 stop-line 是否阻止新 hold？見 正式流量前的錢包停損線。

從 IOSOR 開始

強行讓一筆無法完成的預付 hold 失敗：上限、拒絕或不足。證明資金回到 available，或出現明確退款列。匯出財務守得住的失敗狀態。用同一把鑰匙重放，不可有第二次移動。這是 hold 失敗的真相，不是死掉指派後的釋放。

Related: 預付費支出控制

IOSOR 要點

失敗的 hold 是錢包事件，不是成功戲碼。

該做：自動釋放或退款，加上具名狀態。別做：發明 Activated 或 Delivered。