支付系統功能介紹:退款流程
退款是支付平臺的一個重要業務,退款流程需要具備可視化、自動化和簡約化,幫助提升平臺效率的同時也要減少用戶退款的操作。本文作者對支付平臺的退款流程進行了分析,希望對你有幫助。
一、簡介
退款流程是第三方支付平臺的核心流程,也是支付業務的核心業務;退款流程實現退款流程的可視化、自動化和簡約化,減少商戶的退款操作,降低支付平臺財務的退款工作,提高了退款流程效率,同時降低了退款流程的風險。
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?支付通道配置
頁面設計:
支持退款
不支持退款
需求說明:
添加通道的默認界面,新增字段(以下新增字段不在通道列表顯示):
- 是否支持撤銷:默認為“否”,該字段目前僅用于記錄,不參與判斷;
- 是否支持退款:默認為“是且支持當日退”,未勾選“支持當日退”時,表示該業務類型不可在當日退款,如廈門民生的B2B;該字段需參與判斷,該通道是否可以發起退款
支持當日退時,當天的交易可以發起退款;不允許當天退款時,當天的交易不允許退款;
- 退款是否退手續費:默認“不退手續費”;“全額全退,部分不退”表示退款金額等于訂單總額時,上游會退還手續費,退款金額小于訂單總額時,上游不會退還手續費;“按比例退還手續費”,表示上游按照“退款金額/訂單金額*交易手續費”退還手續費
- 退款收取傭金費率:上游再次收取的退款手續費,該字段作預留,暫時不用,該字段選填
該界面以前判斷邏輯保持不變;
新增字段需同步更新到通道詳情界面、修改通道界面、通道復核界面
不支持退款時,不顯示“支持當日退”,退款退手續費下拉框置灰、退款收取傭金費率置灰
4.2.2 商品訂單管理
頁面設計:
需求說明:
在現有的商品訂單詳情界面,變化如下:
- 操作中去掉“退款”按鈕,退款操作只能由商戶從前端發起,后臺不能操作;
- 原訂單狀態中去掉退款相關的狀態,在列表中新增字段記錄“退款狀態”,狀態包含退款成功、退款失敗、退款處理中、待審核和審核拒絕;未支付成功的訂單或未申請退款的訂單,退款狀態為空
4.2.3 退款訂單管理
頁面設計
需求說明:
退款退手續費:根據與商戶簽訂協議中明確的退款是否退手續費率計算;
退款狀態:
待審核:
商戶申請退款,系統受理后,自動提交到后臺復核,待審核通過后,才向上游通道發起退款
審核拒絕:
后臺復核拒絕后,退款訂單狀態置為“審核拒絕”
“退款處理中”:
對于使用銀行卡支付的退款訂單 ,系統受理退款,組織交易報文到上游,上游受理但暫未收到上游返回退款成功的消息;對于“退款處理中”的訂單,可以同步訂單狀態
對于使用支付賬戶支付的的退款訂單,實時返回到支付賬戶
“退款失敗”:
系統受理退款,組織交易報文到上游,上游返回“退款失敗“,從商戶前端可再次發起退款
“退款成功”:
上游返回“退款成功”的消息(或與上游在T+1清結算時,該筆訂單的對賬狀態為對賬一致)
對于使用支付賬戶支付的的退款訂單,實時返回到用戶支付賬戶,實時增加用戶的支付賬戶余額,退款成功
退款訂單與商戶清結算:
由于退款訂單在發起時已經從商戶的可用余額中扣款,故已完成結算,只需要向下游商戶提供退款的對賬文件即可
對賬狀態:
包含“未對賬“、“對賬成功”和“對賬存疑”3個狀態;提供到下游商戶的退款對賬文件中,取退款狀態為“退款成功”的訂單,包含退款到虛擬賬戶和退款到銀行賬戶的訂單
退款詳情
頁面設計:
需求說明:
退款訂單號由下游商戶生成或與退款受理流水號一致;
退款受理流水號,系統的唯一性標識;
“商品訂單號”改為“原商品訂單號”;
“退款退手續費”指支付機構為商戶受理退款,將原始交易的手續費退給商戶,根據業務類型配置的退款退手續費的方式,計算金額;不退手續費時,值為0;手續費精度:截取小數點后3位,四舍五入到小數點第2位;
退款收傭金:根據設置的費率,計算傭金,未收取時,值為0;傭金精度:截取小數點后3位,四舍五入到小數點第2位;
退款渠道流水號:退款成功后,支付渠道返回的流水號;
通道退手續費:根據通道設置的信息,由程序計算;
通道收取傭金:根據通道設置的信息,由程序計算;
“退款原因”是商戶上送的針對該筆訂單的退款說明;
4.2.4 商戶開戶
頁面設計:
需求說明:
商戶結算設置:
當商戶結算周期為T+1時,聯動出新增字段“退款模式:從結算賬戶中扣減”,目前只有一種模式,此處預留,待后期擴展;
退款退手續費:
包含不退手續費、全額退手續費、按比例退。
選擇不退手續費時,當該商戶的該業務類型發生退款時,不退手續費;
選擇全額退手續費時,當該商戶的該業務類型的訂單發生全額退款時,退交易手續費;
退款收傭金費率:
費率為比例時,退款收取的傭金=退款金額*費率比例
費率為定額時,退款收取的傭金=設置的定額費用
業務和運營可根據商戶需要配置退款手續費。
4.2.5 商戶服務列表
頁面設計:
需求說明:
所有的業務類型,在主通道或備通道選擇彈窗中,在原有查詢條件基礎上,新增查詢條件“是否支持退款”、“退款是否退手續費”,可按照設置的條件查詢相應的通道
查詢邏輯:
- “是否支持退款”選擇“是”時,可按照“退款是否退手續費”繼續細分查詢
- “是否支持退款”選擇“否”時,選擇“退款是否退手續費”中的任意一項都不用篩選
- “是否支持退款”為“請選擇”時,可按照“退款是否退手續費”中的選項進行篩選
4.2.6 退款復核管理
頁面設計:
復核列表
待審核
需求說明:
點擊“通過”或“拒絕”后,更新復核狀態、復核人和復核時間;
若原支付方式為虛擬賬戶支付,點擊通過時,執行退款邏輯校驗,校驗通過后,退款成功,退款金額實時返回到用戶的支付賬戶;校驗失敗時,后臺頁面展示相應提示;
若原支付方式為銀行卡、掃碼等支付方式,點擊通過時,執行退款邏輯校驗,校驗通過后,,將退款請求上送到上游通道,退款訂單狀態置為“退款處理中”;校驗失敗時,后臺頁面展示相應提示
退款審核,點擊“拒絕”時,出現彈窗,需輸入拒絕原因;
拒絕操作后,退款訂單狀態置為“審核拒絕”;
審核拒絕:
頁面設計:
需求說明:
點擊“通過”或“拒絕”后,更新復核狀態、復核人和復核時間;
- 若原支付方式為虛擬賬戶支付,點擊通過后,退款成功,退款金額實時返回到用戶的支付賬戶;
- 若原支付方式為銀行卡、掃碼等支付方式,點擊通過時,判斷上游通道是否支持退款且通道是否為開啟,若通道支持退款且通道開啟,將退款請求上送到上游通道,退款訂單狀態置為“退款處理中”;
- 若原支付方式為銀行卡、掃碼等支付方式,點擊通過時,判斷上游通道是否支持退款且通道是否為開啟,若通道不支持退款或上游通道關閉,提示文案“上游通道不支持退款或通道已關閉,請核對通道狀態”;
退款審核,點擊“拒絕”時,出現彈窗,需輸入拒絕原因;
拒絕操作后,退款訂單狀態置為“審核拒絕”;
4.2.7 退款訂單對賬
頁面設計:
需求說明:
界面變化:
- 搜索條件和列表字段,詳見頁面設計
- 對賬成功歷史管理菜單下,分拆為2個子菜單“收款對賬”和“退款對賬”
退款訂單:
交易手續費=退款收傭金總和
通道費用=上游收取傭金總和(取對賬文件中收取的費用)
收單收益=交易手續費-通道費用
退款退手續費=取對賬文件中的退款退手續費金額
4.2.9 財務調賬
頁面設計:
賬戶調賬記錄
調賬登記
調賬流程圖
需求說明:
退款的對賬出現短款后,確定上游的對賬文件不包含該筆退款訂單后,可進入調賬中,通過“退款調賬”的方式將已扣的商戶可用余額返回
退款調賬:
賬戶類型默認“調賬登記”
客戶編號為必填:輸入客戶編號,一般商戶調賬到現金賬戶;平臺商戶調賬到代付賬戶
退款訂單號:輸入退款訂單號,鼠標市區焦點時,判斷邏輯如調賬流程圖
調賬金額:退款訂單號校驗通過后,自動獲取調賬金額,無需手動輸入,調賬金額=退款金額-退款退手續費金額+退款收取傭金金額
調賬類型:只有“增加”
備注:存儲時,需在此處備注的內容前拼接“退款訂單號:******? ”,如在備注中輸入“返回退款抵扣的金額”,保存的備注信息為“退款訂單號:******,返回退款抵扣的金額”
點擊“確定”,需要對該退款訂單號再次判斷,判斷通過后,調賬成功后的處理:
賬戶明細中生成一條退款調賬記錄,商戶的可用余額增加;
4.2.9 退款設置
頁面設計:
需求說明:
程序默認可退款訂單時長為90天,該時間可根據市場需要修改。
專欄作家
小胖紙,人人都是產品經理專欄作家。九年產品經驗,橫跨多個行業和領域,專注金融和市場營銷,擅長產品需求分析,平凡的外表下有顆不平凡的心。
本文原創發布于人人都是產品經理。未經許可,禁止轉載
題圖來自Unsplash,基于 CC0 協議
該文觀點僅代表作者本人,人人都是產品經理平臺僅提供信息存儲空間服務。
請問為什么流轉到支付平臺審核的時候,要把商戶之前判斷過的邏輯要再判斷一遍呢?比如說是否超過可退款時長等。
保證資金安全以及數據實時有效性
訂單使用虛擬賬戶和微信合并支付,部分退款,退款時要如何處理
正常情況優先退款虛擬賬戶支付的金額,退款金額大于虛擬賬戶支付的金額時,請求微信支付的訂單金額;
退款流程不涉及商品庫存數量變更嗎,直接輸入退款金額沒有關聯退款商品,庫存數量怎么監控
這個退款流程是第三方支付平臺的,商戶收到退款結果會進行相關庫存的處置
其實支付屬于一個單獨個體存在,俗稱支付中臺,嚴格來講不應該和業務關聯起來的,應當業務流程完成后才能流轉退款到支付中臺來,以上為個人見解
你說的很對
Good Good
感謝肯定
想問下退款失敗商戶可以二次發起申請嗎
可以的