訂閱扣款失敗不等於顧客想取消。餘額不足、卡片過期、3DS/驗證、銀行拒絕、payment method 不可用、provider timeout 和 App bug 需要不同處理。盲目每天重試可能增加費用與顧客困擾，立即取消又會失去可恢復關係。
Dunning 先分類原因，再設定重試、通知、寬限與終止。
保存 billing attempt 證據
每次嘗試記 contract、order、scheduled/attempted time、payment method、provider code、status、retry number 和 correlation ID。錯誤碼正規化成 insufficient funds、expired、authentication、hard decline、technical 和 unknown。
不在 log 保存卡號或敏感支付資料。Timeout 後先查結果，避免重複扣款。
依原因設重試
Soft decline 可在幾天內分散重試，考慮發薪日與品類週期；expired/invalid card 需先請顧客更新；hard decline 或 fraud 不持續撞。Technical failure 使用短退避重試和 provider incident 處理。
每個 provider/market 規則和費用不同，使用實際資料調整，不能套固定「三次就成功」假設。
提供安全付款更新
Email/SMS/帳戶連結到受控 payment update flow，使用短時效、單次 token 和正確 customer/contract。訊息不要求回覆卡號，不把完整訂單敏感資料放 URL。
更新成功後確認 payment method 已套到正確 contract，再安排重試。顧客有多個訂閱時清楚顯示受影響方案。
設定寬限和服務狀態
寬限期內是否出貨、保留會員權益、庫存和優惠，由商品成本與服務風險決定。實體商品在付款成功前不要無限制出貨；數位/會員可有限寬限並清楚告知截止。
Pending、past due、paused、cancelled 和 recovered 的前台、客服、ERP 與 fulfillment 狀態一致。
通知節奏尊重顧客
第一次失敗說明原因可用程度、下一次重試、更新方式和客服；重試前/後依策略通知；最後通知說明暫停或取消日期。語氣清楚，不用羞辱、假倒數或隱藏取消。
Email、SMS 使用 consent/transactional 規則，避免多系統重複發送。已更新、已付款或已取消立即停止催收。
庫存和價格重新確認
重試成功前，商品可能缺貨、價格/稅/運費改變。Subscription contract 和 billing attempt 按平台規則處理，任何需要顧客同意的重大變更先通知。不能成功扣款後才說無法履約。
缺貨可 skip、替代（需同意）、延後或退款，保留原因和客服狀態。
取消和再啟用
超過最大重試/寬限後依政策 pause 或 cancel，停止建立新訂單和通知。顧客可在條件允許時 reactivate，重新確認商品、價格、頻率、付款與 consent。
不要用無限 past-due contract 累積待扣款。財務和報表明確區分 active、recoverable 和 churned。
衡量增量而非 recovered 數
看 failure rate、reason、recovery、time to recovery、attempts、fee、involuntary churn、complaint 和 duplicate charge。比較策略需設 holdout/歷史基準，因部分顧客可能自行更新。
扣除折扣、客服、重試費和後續退貨，連到 訂閱單位經濟。
演練故障與供應商事件
測 expired、soft/hard decline、3DS、provider timeout、webhook duplicate/out-of-order、付款更新、缺貨、cancel 和恢復。Provider outage 時可暫停重試與通知，恢復後分批執行。
Dunning 做得好，顧客知道問題、能安全修正，品牌不重複扣款，真正無法恢復的訂閱也能乾淨結束。