付款重試排程
智能重試邏輯和拒絕恢復工具，將軟性拒絕轉化為您收單網絡中的成功授權。
- 類別
- 復原
- 功能
- 10
- 適用於
- 所有方案
付款重試排程會自動重新提交失敗的交易。 此功能允許商戶根據拒絕代碼、交易歷史記錄和客戶群組配置特定的重試邏輯。
它旨在無需人工干預即可恢復收入，從而提高定期付款和訂閱的整體交易成功率。
重試會遵守計劃規則、發卡機構信號和3DS升級要求，因此恢復的交易量是真正增量的，而不是增加費用或欺詐風險。 報告會顯示具體挽回了多少收入以及來源。
概述
付款重試排程位於支付堆棧的恢復層中，專門處理商戶發起交易 (MIT) 的軟性拒絕。
與因卡片丟失或帳戶關閉導致的硬性拒絕不同，軟性拒絕通常是由於暫時性問題造成的，例如資金不足、技術超時或一般銀行錯誤。
透過對這些失敗應用邏輯，商戶可以在最有可能與帳戶資金或系統穩定性同時發生的間隔重新提交授權請求。
此過程通常涉及固定間隔排程和動態邏輯的組合，該邏輯考慮了發卡機構提供的特定拒絕原因代碼。
對於採用訂閱模式或定期計費的企業，這種自動化最大限度地減少了人工外展的行政負擔，同時減少了被動流失。
該機制依賴於將回應代碼映射到特定的重試路徑，確保進一步的嘗試不會違反卡組織規則或觸發收單機構的過高費用罰款。
運作方式
初始回應代碼分析
當授權請求失敗時，系統會解析發卡機構的特定回應代碼。它區分硬性拒絕（無需進一步操作）和符合恢復條件的軟性拒絕。此步驟確保商戶遵守卡組織關於禁止在特定拒絕類別上重試的規則。
邏輯應用和排程
系統根據失敗原因應用預定義或動態排程。對於資金不足 (NSF) 拒絕，重試可能會暫停，直到典型的發薪日。對於技術錯誤，通常會優先在幾分鐘或幾小時內進行短期重試，以便在系統穩定期間捕捉交易。
透過網關重新提交請求
排程的請求會在指定時間發送回收單機構，通常會利用儲存的憑證和特定指標來表示後續嘗試。此過程在必要時維持與原始交易嘗試的連結，確保支付流程符合 SCA 和 PSD2 對 MIT 的要求。
結果監控和結算
如果重試成功，交易將進入捕捉和結算。結果記錄在恢復日誌中，以評估時間邏輯的效率。如果重試失敗，系統會轉到下一個排程嘗試，或終止循環作為最終拒絕。
重要意義
減少被動流失
被動流失是指客戶無意取消服務，但由於可避免的技術或財務因素導致其付款失敗。自動排程會在後台處理這些失敗。透過恢復這些交易，商戶可以為持卡人維持服務的連續性，防止人工重新輸入的摩擦，並減少客戶因服務中斷而放棄訂閱的可能性。
優化營運效率
手動催款和客戶服務外展以處理失敗的付款是資源密集型任務。實施系統化的重試框架可減少支援團隊處理的工單量。透過在網關或協調層自動化恢復過程，企業可以專注於增長，而基礎設施則處理銀行回應代碼和符合卡組織的定期計費週期間隔管理的複雜性。
使用案例
基於訂閱的 SaaS 平台
SaaS 提供商使用重試排程來處理每月續訂。如果授權在每月 1 日午夜失敗，系統會確保在銀行系統響應最及時時進行後續嘗試。
公用事業和電信計費
對於服務中斷存在風險的基本服務，在軟性拒絕後 14 天內重試付款可確保收入捕捉，同時避免債務催收的法律複雜性。
數字內容和媒體
串流媒體服務在失敗後的最初 48 小時內採用積極但合規的重試邏輯，以確保高交易量、低價值每月交易的內容不間斷訪問。
依據數字
此範圍反映了透過自動化邏輯而非人工外展在訂閱領域恢復軟性拒絕的典型行業結果。
當為二次和三次付款嘗試實施系統恢復時，經常性收入業務的總流失預期會減少。
根據標準支付處理基準，大多數成功的恢復通常發生在初始拒絕後的此時間範圍內。
相關術語
與我們的團隊討論在我們收單合作夥伴的 rails 上進行即時部署。
{{title}} 的優勢 付款重試排程
- 區分軟性拒絕和硬性拒絕，以確保符合卡組織的重試規則。
- 對發卡機構回應代碼進行分類，以優先處理最終成功機率最高的交易。
- 根據發卡機構的正常運行時間和典型的消費者資金週期歷史數據調整重試時間戳。
- 支援可自訂的定期計費週期間隔，以配合特定的業務會計期間。
- 整合邏輯以防止因過度重試未經更改的被拒絕交易而導致過高的卡組織費用。
- 自動將失敗的授權轉換為已恢復狀態，無需人工客戶支援干預。
- 透過代幣化安全地使用儲存的付款憑證進行所有後續的商戶發起交易。
- 提供按拒絕類型和特定重試嘗試次數組織的恢復率詳細報告。
- 透過正確標記定期交易恢復嘗試，保持符合 PSD2 和 SCA 要求。
- 減少對即時催款電郵的需求，傾向於靜默恢復以維持客戶體驗。
A short scoping call, then a written plan for your MIDs.
關於 付款重試排程
在重試邏輯中，軟性拒絕和硬性拒絕有什麼區別？
軟性拒絕，例如資金不足 (NSF) 訊息或暫時性技術錯誤，表示付款可能在稍後嘗試時成功。 硬性拒絕，例如被盜卡或無效帳號，表示永久性失敗，卡組織（如 Visa 和 Mastercard）禁止進一步嘗試。
重試排程僅適用於軟性拒絕。 嘗試重試硬性拒絕可能會導致收單機構處以巨額罰款，並可能導致商戶 ID (MID) 因不合規行為而被標記。
重試排程如何影響商戶費用和卡組織罰款？
在交易情況未改變的情況下過度重試可能會導致卡組織罰款。 例如，Mastercard 和 Visa 對商戶在特定時間範圍內重試單筆交易的次數有具體規定。
有效的排程可以透過錯開嘗試並在達到最大限制後停止流程來避免這些罰款。 正確配置的邏輯可確保恢復成本不會超過正在處理的交易價值。
重試排程可以配置用於 3D Secure 交易嗎？
重試排程主要用於持卡人離線的商戶發起交易 (MIT)。 需要 3D Secure (3DS) 身份驗證的交易通常是客戶發起交易 (CIT)。
為了自動重試這些交易，商戶必須有初始協議（授權），並且第一筆交易必須經過完全身份驗證。 隨後的重試將被標記為 MIT，使用 SCA 下的定期付款豁免，儘管它們仍必須參考原始的已驗證會話。
重試付款會影響我的授權率指標嗎？
首次嘗試失敗會對您的原始授權率產生負面影響。 然而，成功的重試會提高您的淨恢復率和整體收入。
大多數複雜的支付分析會將「首次通過率」與重試後的「最終成功率」分開。 透過單獨分析這些數據，商戶可以了解其初始授權問題是由於流量質量差還是排程邏輯成功緩解的暫時性技術障礙。
失敗的付款應該重試多少次才放棄？
行業標準通常建議在 15 到 30 天內最多嘗試四到六次，具體取決於 MCC 和產品性質。 前幾次重試通常在失敗後的 72 小時內進行，因為這是恢復機率最高的時候。
超過 30 天後，軟性拒絕的成功可能性會顯著下降，如果持卡人忘記訂閱，則發生爭議或退單的風險會增加。
拒絕代碼在重試時間安排中扮演什麼角色？
拒絕代碼是排程的主要數據點。 例如，「51：資金不足」代碼建議重試時間應安排在常見發薪日附近，例如每月 1 日或 15 日，或每個星期五。
「05：請勿授權」或「96：系統故障」可能表示發卡機構出現技術故障，需要更快地重試，可能在數小時內，以便在系統重啟或同步後捕捉到。