一文搞懂,“退款中心”

0 評論 2549 瀏覽 27 收藏 19 分鐘

在前面文章里,作者從逆向業務說起,詳細分析了退款的場景。這篇文章里,作者接著闡述如何設計退款中心。一起來看看本文的梳理。

在文章《全局視角看,“退款中心”的設計》中從業務層面詳細分析了退款的場景,本文將解析如何設計一款能力強勁的退款中心。

一、退款中心的位置

退款作為原支付的逆向,我們一般認為退款處理和支付處理屬于同一個維度的支付業務。

可能很多企業不會將退款中心獨立成一個系統,或者說一個獨立的產品部門,在這種情況下,退款往往作為正向交易、正向支付的一個子模塊實現,此時的退款處理能力也比較單一,以原路退款為主,付款退回為輔助。

隨著對退款業務處理的要求增加,退款處理模型種類的增加,耦合在原支付處理模塊不能很好的滿足業務對退款的訴求。

逐漸的退款業務獨立出“退款中心”單獨的系統或者產品部門,這在以純支付業務為主的支付機構尤為常見。

獨立出來的退款中心,更能夠按照退款的業務特點進行架構的設計,以及抽象出更加豐富的退款能力。

例如除了原路退以外,還可以實現付款退、線下退、退回余額等方式,以及可以提供接口、MQ、文件等的退款請求方式,并可以實現單筆退款、批量付款等退款模式。

二、退款中心的產品架構

從產品架構上,退款中心以各退款產品為主線進行構建,每一種退款產品在退款處理流程上存在差異。

例如原路退和退轉付,前者是基于原支付調用原支付通道提供的退款服務,而后者是需要基于原退款調用可用付款通道處理退款業務,并且需要進行用戶賬戶的采集等處理環節。

從上圖的架構看得出來,退款中心可以分退款接入層、退款主處理引擎、各退款產品的處理模塊、退款提交和接收層,其中:

(1)退款接入層

提供多種接入方式,如接口、MQ、文件上傳、人工操作等,原路退可以通過接口和MQ接入,同時也會給內部運營人員提供手動操作原支付退回的能力,比如通過填寫原支付單號進行退款操作。

接入層還會提供多種退款方式,就像收款收銀臺的支付方式一樣,如單筆退款、批量退款、POS退款等等。

每一種退款方式其實依賴下層的退款產品實現,例如補償退款僅僅支持退回余額的退款產品,這時候如果業務選擇的退款種類是“補償退款”,那么就只能選擇退回用戶的平臺余額賬戶中。

(2)退款處理引擎

處理和解析退款申請,校驗退款信息是否完整規范,選擇可用的退款方式,創建退款任務,創建退款申請記錄等一系列的退款處理。

(3)退款產品層

該層將并行建立各種退款處理模塊,如原路退模塊、退轉付模塊、網銀退模塊、退回余額模塊、抵扣式退款等。

每一個退款模塊都有獨立的退款處理單據,關聯上層的退款單,有該退款產品獨特的處理環節。

如網銀退款需要生成文件數據,并提供給內部人員下載,這一步可以按照網銀渠道生成直接可用的文件數據,下載下來以后可以直接上傳到網銀渠道進行退款,無需人為進行二次加工,這將極大地提高退款處理效率。

(4)退款渠道處理

為退款產品提供退款處理通道,以及退款處理的提交,退款結果的接收等,完成最終的退款處理。

三、退款產品化,包裝多種退款產品

我們對支付產品都不陌生,同樣的概念適合退款產品,關于退款產品我們應該關注以下幾個維度,在設計一款退款產品時,可以在這幾個維度給于定義和方案的選擇。

(1)退款產品維度

產品維度是最高的一個組合抽象,每一款產品都是一系列方案的組合,比較常見的產品如下:

  • 原路退款:最常見的退款產品,基于原支付進行原路退回;
  • 退轉付:將退款業務轉為付款業務的一款產品;
  • 網銀退款:通過網銀進行線下退的退款模式,系統需要生成用于線下退款的文件;
  • 退回余額:將需要退的款項退回到付款人在平臺的賬戶余額中;
  • 其他價值抵扣:其他用券、卡、積分等抵扣退款的一種退款方式。

總體來說,只要平臺、商家、用戶等多方能夠達成一致,退款方式的可選擇性非常大。

(2)發起方式維度

最常見的是接口發起,也可以通過MQ發起?;蛘咄ㄟ^文件上傳進行退款的發起、后臺操作。

(3)退款類型

如全額退、部分退、按商品退等。

(4)原路退款時效

這部分要有2個限制維度,一個是平臺提供給用戶的退款售后時效,例如7天內可退,另一個是原支付渠道的退款時效,這部分要依賴于渠道的政策,如微信的1年退款時效。

渠道的退款時效相對更重要,平臺的售后時效由業務層控制,而渠道的退款時效是退款中心原路退能夠支撐的最長時效周期。

更長的業務售后承諾需要更強的渠道退款時效,二者是需求和滿足的關系。

(5)退款手續費處理

退款時渠道是否退回手續費,如何退,這部分主要針對原路退的手續費政策。

因此,通過上圖退款方式的模型,可以組合出非常豐富的退款能力,例如下面的退款方式。

四、退款主處理流程

退款主流程是從退款請求提交進來開始到退款中心提交渠道并獲得退款處理結果應答結束的退款全流程。

之所以說是主流程,還是要剔除退款渠道的差異化處理,以標準的退款中心主處理為結構,主流程框架如下圖所示:

將上述的退款框架進行細化,可以得到如下的退款處理流程:

退款請求的接收和解析,接收來自外部系統的退款申請,并解析請求的報文或者推送過來的退款文件。

校驗退款請求是否完整,參數是否符合規范,以及判斷原支付單是否成功,是否有存在的退款記錄,退款是否超過時效等一系列的判斷。

然后生成退款主單據,記錄退款的業務信息。

基于退款單,判斷可用的退款方式,是原路退、退轉付、退回余額還是網銀退款,因為不同的退款方式可用的退款通道和需要補全的數據不一樣,以及生成的該通道下的退款處理記錄也不一樣。

如果退款涉及到了商家結算問題,此時需要先扣除商家結算賬戶余額,然后再發起退款,這里要考慮是否涉及到墊資問題,例如商家賬戶余額不足是否允許繼續退款。

電商平臺往往會執行平臺墊資退款,而如果是支付機構往往不會為商家墊資,商家賬戶余額不足會直接退款失敗。

如上圖所示,電商平臺和支付機構在處理退款時,對商戶的賬戶余額是否充足的處理策略會存在差異,支付機構往往不會為商戶墊資退款,而電商平臺往往會墊資退款給用戶,因為用戶的體驗更加受到重視。

五、退款單據設計

退款中心一個非常重要的單據就是退款單,我們可以將退款單設計成3層,第一層是基礎退款單,記錄退款的業務信息以及退款處理的主要信息。

第2層是選擇的退款方式的差異化退款信息,例如原路退時的退款信息、退轉付的退款單據等。

第3層是請求退款渠道的請求記錄單據,以此形成退款中心最核心的單據結構。

(1)基礎退款單

如下圖所示,記錄最完整的退款信息,包括全部單據號,最終執行的退款產品,退款通道信息,金額信息,時間信息等。

(2)原路退款單

執行原路退回的補充記錄部分,可以更新到基礎單據中,也可以執行單據的按照退款方式設定的子單據中。

(3)退轉付單

退轉付是在原路退超過退款時效,或者就是無法退款成功時選擇的退款方式,建立在原退款單的基礎上。

(4)網銀退款單

網銀退款是一種線下退款方式,線上的退款處理無法實現時,或者某些特殊的支付業務退款,沒有接入通道的線上退款接口,而是通過線下登錄網銀執行退款處理的退款方式。

此時,系統需要將線上的退款請求記錄生成網銀退款批次,并生成網銀退款文件提供給內部人員下載,人工登錄網銀操作執行退款。

網銀退款成功以后需要返回退款中心,進行退款結果的復核和確認。

(4)退回余額單

將要退的金額,直接退回用戶的賬戶余額,這部分要執行請求賬戶中心進行入賬,如果用戶沒有余額賬戶時,需要進行開戶的申請。

(5)資產抵扣單

這是最后的兜底手段,將要退款的金額通過其他資產進行抵扣,例如發給用戶優惠券,一次商品服務等等方式。

該種方式需要優先獲得用戶的確認,對該退款方案無異議以后在線上進行確認,然后平臺進行執行。

六、退款通道屬性與配置

原支付渠道,往往在通道屬性信息中配置“是否支持退款、退款時效、是否退手續費、手續費率”等信息。

七、渠道的退款能力

不同平臺接入的通道不同,那么退款政策也不同,就需要去分析接入的各類通道的退款能力。

當然,不同的組織接入的通道所屬組織也不同,普通電商平臺接入三方支付機構,三方支付機構接入網聯銀聯,網聯銀聯接入人行大小額系統。

那么他們所面臨的渠道的退款能力和退款政策是不同的,這一點要在退款中心的設計上體現出來。

(1)三方支付的退款能力

如果你是一個普通的電商平臺,那么更多關注的是微信支付、支付寶支付、快捷支付的退款能力建設。

微信退款能力:

微信原路退款是絕大部分電商平臺都需要構建的能力,從微信開放平臺可以調研到微信的退款處理政策,其退款時效、退款類型等等。

下圖是退款的接口說明。

下圖是微信退款的部分政策,包含產品層的也包含技術層的內容。

支付寶退款能力:

支付寶退款關于退款時效和手續費的政策。

支付寶退款相關接口:

快捷支付退款:

假如你接入了一款快捷支付產品,那么其原路退的退款能力建設可以看對應機構提供的退款能力,如下圖是易寶支付快捷支付的退款能力。

根據其API的傳參和處理要求,設計退款中心的退款單據和處理流程。

(2)網聯和銀聯等清算機構的退款能力

如果你是一家支付機構,那么通道接入的是網聯或者銀聯,通過網聯或者銀聯執行的支付。

在退款時可以通過請求網聯銀聯提供的退款通道執行退款。

支付機構通過網聯提供的退款申請報文發起退款申請。

這里就不再詳細列舉報文參數要求了,在網聯的結算文件中或者清算文件中可以看到退款的數據。

(3)人行的退款類業務類型和報文

網聯和銀聯怎么處理支付機構的退款業務呢?當然是通過人行最終實現退款資金的清算,這部分就不再詳細介紹了,因為距離大家比較遠,感興趣的朋友可以自己去找一下相關資料。

專欄作家

陳天宇宙,微信公眾號:陳天宇宙,人人都是產品經理專欄作家。多平臺支付領域專欄作者,十年資深產品;專注為10萬支付產品經理和支付機構以及企業提供深度支付內容和服務!

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

題圖來自 Unsplash,基于 CC0 協議。

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

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 目前還沒評論,等你發揮!