支付系統功能介紹:退款流程

12 評論 12307 瀏覽 157 收藏 24 分鐘

退款是支付平臺的一個重要業務,退款流程需要具備可視化、自動化和簡約化,幫助提升平臺效率的同時也要減少用戶退款的操作。本文作者對支付平臺的退款流程進行了分析,希望對你有幫助。

一、簡介

退款流程是第三方支付平臺的核心流程,也是支付業務的核心業務;退款流程實現退款流程的可視化、自動化和簡約化,減少商戶的退款操作,降低支付平臺財務的退款工作,提高了退款流程效率,同時降低了退款流程的風險。

1.1?目的

軟件需求是軟件開發的依據,也是軟件工程各項活動的基礎。編寫本PRD的目的就是將退款流程的需求清晰準確地描述清楚,為制定項目開發計劃和后期的概要設計、原型設計、測試等階段的工作提供可靠的依據。

1.2?范圍

本文檔閱讀對象為產品經理、項目經理、UI設計師、開發工程師、測試工程師。

二、客戶端角色描述

三、產品概述

退款流程是支付平臺常見的業務形式,退款流程可以減少商戶管理員和平臺管理員的退款操作步驟,提高退款效率,降低退款風險,減少商戶和平臺運營人員的工作量。

3.1 總體功能架構圖

3.2 系統流程圖

四、?功能需求說明

4.1 商戶端

4.1.1交易記錄

頁面設計:

交易記錄

退款申請

需求說明:

1、商品訂單狀態為“支付成功”且退款狀態為“退款處理中”時,不顯示“退款”按鈕;商品訂單狀態為“支付成功”且退款狀態為“退款成功”時,不顯示“退款”按鈕;商品訂單狀態為“支付成功”且退款狀態為“待審核”時,不顯示“退款”按鈕;

2、商品訂單狀態不為“支付成功”時,不顯示“退款”按鈕;

3、訂單狀態為“支付成功”且退款狀態為空,顯示“退款”按鈕;訂單狀態為“支付成功”且退款狀態為“退款失敗”,顯示“退款”按鈕;訂單狀態為“支付成功”且退款狀態為“審核拒絕”時,顯示“退款”按鈕;

4、點擊“退款”,退款按鈕判斷邏輯詳見業務邏輯圖,邏輯校驗通過后,生成一條新的退款記錄。

5、交易記錄界面,點擊“退款”,出現彈窗,退款原因必填;點擊“確定”,判斷是否可以發起退款,校驗通過后,退款狀態為“待審核”;

4.1.2 退款記錄

頁面設計:

退款記錄

退款詳情

需求說明:

1、將退款記錄放在“交易管理”菜單下;

2、支付退款金額=退款金額-退款退手續費金額+退款收取手續費(注:現有通道,退款均沒有收取傭金,退款收取傭金字段先做預留);

3、退款失敗或審核拒絕的訂單,需備注退款失敗或審核拒絕的原因;

4.1.3 現金賬戶明細

頁面設計:

需求說明:

現金賬戶包含的交易名稱:

退款:用戶發起退款,預扣商戶的可用余額后才能發起的退款,備注中標注“支付退款金額”;若退款失敗,需生成一條新的明細記錄,返回退款失敗的金額,備注中需標注“支付退款金額失敗,返還金額”;

退款調賬:退款為短款時,與商戶協商,通過調賬的方式返已扣的金額,注意備注為“退款訂單號:************,退款交易未達成,調賬返還已扣金額”;

充值:交易狀態只包含“充值成功”的訂單,已提交但是未支付的訂單不顯示;

結算:只顯示結算到可用余額的金額;結算到銀行卡的金額不顯示在賬戶明細中;交易狀態只包含結算成功的記錄;

提現:將現金賬戶的可用余額提現到商戶的銀行賬戶中,交易狀態包含提現的各個狀態;

提現失敗時,需生成一條相同流水號的收入記錄,備注“提現失敗,返還提現金額”

錯賬調賬:后臺調賬到現金賬戶后,前端顯示該筆調賬記錄;交易狀態“成功”

凍結:針對現金賬戶中的金額,后臺執行凍結后,前端顯示該筆記錄;交易狀態包含“成功”

解除凍結:針對現金賬戶中的金額,后臺執行解除凍結后,前端顯示該筆記錄;交易狀態包含“成功”

交易名稱為“退款”時,交易金額=退款金額-退款退手續費金額;手續費=退款收傭金金額

顯示樣式:

沒有手續費時,手續費顯示為空

4.1.4 代付賬戶明細

頁面設計:

需求說明:

代付賬戶包含的交易名稱:

退款:用戶發起退款,預扣商戶的可用余額后才能發起的退款,備注中標注“支付退款金額”;若退款失敗,需生成一條新的明細記錄,返回退款失敗的金額,備注中需標注“支付退款金額失敗,返還金額”

退款調賬:退款為短款時,與商戶協商,通過調賬的方式返已扣的金額,注意備注為“退款訂單號:************,退款交易未達成,調賬返還已扣金額”

充值:交易狀態只包含“充值成功”的訂單,已提交但是未支付的訂單不顯示

結算:只顯示結算到可用余額的金額;結算到銀行卡的金額不顯示在賬戶明細中;交易狀態只包含結算成功的記錄

提現:將現金賬戶的可用余額提現到商戶的銀行賬戶中,交易狀態包含提現的各個狀態;

提現失敗時,需生成一條相同流水號的收入記錄,備注“提現失敗,返還提現金額”

錯賬調賬:后臺調賬到現金賬戶后,前端顯示該筆調賬記錄;交易狀態“成功”

凍結:針對現金賬戶中的金額,后臺執行凍結后,前端顯示該筆記錄;交易狀態包含“成功”

解除凍結:針對現金賬戶中的金額,后臺執行解除凍結后,前端顯示該筆記錄;交易狀態包含“成功”

交易名稱為“退款”時,交易金額=退款金額-退款退手續費金額;手續費=退款收傭金金額

顯示樣式:

沒有手續費時,手續費顯示為空

4.2 平臺端

4.2.1?支付通道配置

頁面設計:

支持退款

不支持退款

需求說明:

添加通道的默認界面,新增字段(以下新增字段不在通道列表顯示):

  1. 是否支持撤銷:默認為“否”,該字段目前僅用于記錄,不參與判斷;
  2. 是否支持退款:默認為“是且支持當日退”,未勾選“支持當日退”時,表示該業務類型不可在當日退款,如廈門民生的B2B;該字段需參與判斷,該通道是否可以發起退款

支持當日退時,當天的交易可以發起退款;不允許當天退款時,當天的交易不允許退款;

  1. 退款是否退手續費:默認“不退手續費”;“全額全退,部分不退”表示退款金額等于訂單總額時,上游會退還手續費,退款金額小于訂單總額時,上游不會退還手續費;“按比例退還手續費”,表示上游按照“退款金額/訂單金額*交易手續費”退還手續費
  2. 退款收取傭金費率:上游再次收取的退款手續費,該字段作預留,暫時不用,該字段選填

該界面以前判斷邏輯保持不變;

新增字段需同步更新到通道詳情界面、修改通道界面、通道復核界面

不支持退款時,不顯示“支持當日退”,退款退手續費下拉框置灰、退款收取傭金費率置灰

4.2.2 商品訂單管理

頁面設計:

需求說明:

在現有的商品訂單詳情界面,變化如下:

  1. 操作中去掉“退款”按鈕,退款操作只能由商戶從前端發起,后臺不能操作;
  2. 原訂單狀態中去掉退款相關的狀態,在列表中新增字段記錄“退款狀態”,狀態包含退款成功、退款失敗、退款處理中、待審核和審核拒絕;未支付成功的訂單或未申請退款的訂單,退款狀態為空

4.2.3 退款訂單管理

頁面設計

需求說明:

退款退手續費:根據與商戶簽訂協議中明確的退款是否退手續費率計算;

退款狀態:

待審核:

商戶申請退款,系統受理后,自動提交到后臺復核,待審核通過后,才向上游通道發起退款

審核拒絕:

后臺復核拒絕后,退款訂單狀態置為“審核拒絕”

“退款處理中”:

對于使用銀行卡支付的退款訂單 ,系統受理退款,組織交易報文到上游,上游受理但暫未收到上游返回退款成功的消息;對于“退款處理中”的訂單,可以同步訂單狀態

對于使用支付賬戶支付的的退款訂單,實時返回到支付賬戶

“退款失敗”:

系統受理退款,組織交易報文到上游,上游返回“退款失敗“,從商戶前端可再次發起退款

“退款成功”:

上游返回“退款成功”的消息(或與上游在T+1清結算時,該筆訂單的對賬狀態為對賬一致)

對于使用支付賬戶支付的的退款訂單,實時返回到用戶支付賬戶,實時增加用戶的支付賬戶余額,退款成功

退款訂單與商戶清結算:

由于退款訂單在發起時已經從商戶的可用余額中扣款,故已完成結算,只需要向下游商戶提供退款的對賬文件即可

對賬狀態:

包含“未對賬“、“對賬成功”和“對賬存疑”3個狀態;提供到下游商戶的退款對賬文件中,取退款狀態為“退款成功”的訂單,包含退款到虛擬賬戶和退款到銀行賬戶的訂單

退款詳情

頁面設計:

需求說明:

退款訂單號由下游商戶生成或與退款受理流水號一致;

退款受理流水號,系統的唯一性標識;

“商品訂單號”改為“原商品訂單號”;

“退款退手續費”指支付機構為商戶受理退款,將原始交易的手續費退給商戶,根據業務類型配置的退款退手續費的方式,計算金額;不退手續費時,值為0;手續費精度:截取小數點后3位,四舍五入到小數點第2位;

退款收傭金:根據設置的費率,計算傭金,未收取時,值為0;傭金精度:截取小數點后3位,四舍五入到小數點第2位;

退款渠道流水號:退款成功后,支付渠道返回的流水號;

通道退手續費:根據通道設置的信息,由程序計算;

通道收取傭金:根據通道設置的信息,由程序計算;

“退款原因”是商戶上送的針對該筆訂單的退款說明;

4.2.4 商戶開戶

頁面設計:

需求說明:

商戶結算設置:

當商戶結算周期為T+1時,聯動出新增字段“退款模式:從結算賬戶中扣減”,目前只有一種模式,此處預留,待后期擴展;

退款退手續費

包含不退手續費、全額退手續費、按比例退。

選擇不退手續費時,當該商戶的該業務類型發生退款時,不退手續費;

選擇全額退手續費時,當該商戶的該業務類型的訂單發生全額退款時,退交易手續費;

退款收傭金費率:

費率為比例時,退款收取的傭金=退款金額*費率比例

費率為定額時,退款收取的傭金=設置的定額費用

業務和運營可根據商戶需要配置退款手續費。

4.2.5 商戶服務列表

頁面設計:

需求說明:

所有的業務類型,在主通道或備通道選擇彈窗中,在原有查詢條件基礎上,新增查詢條件“是否支持退款”、“退款是否退手續費”,可按照設置的條件查詢相應的通道

查詢邏輯:

  1. “是否支持退款”選擇“是”時,可按照“退款是否退手續費”繼續細分查詢
  2. “是否支持退款”選擇“否”時,選擇“退款是否退手續費”中的任意一項都不用篩選
  3. “是否支持退款”為“請選擇”時,可按照“退款是否退手續費”中的選項進行篩選

4.2.6 退款復核管理

頁面設計:

復核列表

待審核

需求說明:

點擊“通過”或“拒絕”后,更新復核狀態、復核人和復核時間;

若原支付方式為虛擬賬戶支付,點擊通過時,執行退款邏輯校驗,校驗通過后,退款成功,退款金額實時返回到用戶的支付賬戶;校驗失敗時,后臺頁面展示相應提示;

若原支付方式為銀行卡、掃碼等支付方式,點擊通過時,執行退款邏輯校驗,校驗通過后,,將退款請求上送到上游通道,退款訂單狀態置為“退款處理中”;校驗失敗時,后臺頁面展示相應提示

退款審核,點擊“拒絕”時,出現彈窗,需輸入拒絕原因;

拒絕操作后,退款訂單狀態置為“審核拒絕”;

審核拒絕:

頁面設計:

需求說明:

點擊“通過”或“拒絕”后,更新復核狀態、復核人和復核時間;

  • 若原支付方式為虛擬賬戶支付,點擊通過后,退款成功,退款金額實時返回到用戶的支付賬戶;
  • 若原支付方式為銀行卡、掃碼等支付方式,點擊通過時,判斷上游通道是否支持退款且通道是否為開啟,若通道支持退款且通道開啟,將退款請求上送到上游通道,退款訂單狀態置為“退款處理中”;
  • 若原支付方式為銀行卡、掃碼等支付方式,點擊通過時,判斷上游通道是否支持退款且通道是否為開啟,若通道不支持退款或上游通道關閉,提示文案“上游通道不支持退款或通道已關閉,請核對通道狀態”;

退款審核,點擊“拒絕”時,出現彈窗,需輸入拒絕原因;

拒絕操作后,退款訂單狀態置為“審核拒絕”;

4.2.7 退款訂單對賬

頁面設計:

需求說明:

界面變化:

  1. 搜索條件和列表字段,詳見頁面設計
  2. 對賬成功歷史管理菜單下,分拆為2個子菜單“收款對賬”和“退款對賬”

退款訂單:

交易手續費=退款收傭金總和

通道費用=上游收取傭金總和(取對賬文件中收取的費用)

收單收益=交易手續費-通道費用

退款退手續費=取對賬文件中的退款退手續費金額

4.2.9 財務調賬

頁面設計:

賬戶調賬記錄

調賬登記

調賬流程圖

需求說明:

退款的對賬出現短款后,確定上游的對賬文件不包含該筆退款訂單后,可進入調賬中,通過“退款調賬”的方式將已扣的商戶可用余額返回

退款調賬:

賬戶類型默認“調賬登記”

客戶編號為必填:輸入客戶編號,一般商戶調賬到現金賬戶;平臺商戶調賬到代付賬戶

退款訂單號:輸入退款訂單號,鼠標市區焦點時,判斷邏輯如調賬流程圖

調賬金額:退款訂單號校驗通過后,自動獲取調賬金額,無需手動輸入,調賬金額=退款金額-退款退手續費金額+退款收取傭金金額

調賬類型:只有“增加”

備注:存儲時,需在此處備注的內容前拼接“退款訂單號:******? ”,如在備注中輸入“返回退款抵扣的金額”,保存的備注信息為“退款訂單號:******,返回退款抵扣的金額”

點擊“確定”,需要對該退款訂單號再次判斷,判斷通過后,調賬成功后的處理:

賬戶明細中生成一條退款調賬記錄,商戶的可用余額增加;

4.2.9 退款設置

頁面設計:

需求說明:

程序默認可退款訂單時長為90天,該時間可根據市場需要修改。

專欄作家

小胖紙,人人都是產品經理專欄作家。九年產品經驗,橫跨多個行業和領域,專注金融和市場營銷,擅長產品需求分析,平凡的外表下有顆不平凡的心。

本文原創發布于人人都是產品經理。未經許可,禁止轉載

題圖來自Unsplash,基于 CC0 協議

該文觀點僅代表作者本人,人人都是產品經理平臺僅提供信息存儲空間服務。

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 請問為什么流轉到支付平臺審核的時候,要把商戶之前判斷過的邏輯要再判斷一遍呢?比如說是否超過可退款時長等。

    來自江蘇 回復
    1. 保證資金安全以及數據實時有效性

      來自山東 回復
  2. 訂單使用虛擬賬戶和微信合并支付,部分退款,退款時要如何處理

    來自廣東 回復
    1. 正常情況優先退款虛擬賬戶支付的金額,退款金額大于虛擬賬戶支付的金額時,請求微信支付的訂單金額;

      來自山東 回復
  3. 退款流程不涉及商品庫存數量變更嗎,直接輸入退款金額沒有關聯退款商品,庫存數量怎么監控

    來自廣東 回復
    1. 這個退款流程是第三方支付平臺的,商戶收到退款結果會進行相關庫存的處置

      來自山東 回復
    2. 其實支付屬于一個單獨個體存在,俗稱支付中臺,嚴格來講不應該和業務關聯起來的,應當業務流程完成后才能流轉退款到支付中臺來,以上為個人見解

      來自四川 回復
    3. 你說的很對

      來自山東 回復
  4. Good Good

    來自河北 回復
    1. 感謝肯定

      來自山東 回復
  5. 想問下退款失敗商戶可以二次發起申請嗎

    來自上海 回復
    1. 可以的

      來自山東 回復