別人代付的錢退款的話退在哪裡

退款，是一個易造成

負體驗

的業務產品。原因是商戶對於退款的要求務必退款成功、高效、快，而且又得很好地支撐業務，否則就容易招來吐槽。

退款，一個看似簡單，但充滿複雜性的產品。

要想做好退款系統，我們必須深入的瞭解業務發展趨勢，將客戶訴求與現狀業務結合起來；同時還需站在服務客戶的角度，儘可能讓客戶降低操作，這樣才有希望將退款系統打造好。

因此，筆者根據在支付公司獨自負責退款系統的經驗，讓大家避免踩坑，向大家分享如何從0-1打造厲害的退款系統。

本文將從需求背景、需求分析，以及產品設計三個層面來闡述退款系統。

一、需求背景

在我接手退款系統之前，公司的退款系統是這樣的：

1。 只支援訂單全額退款；不支援部分退款；

2。 退款不退回交易手續費；

3。 退款請求的成功率超級低，不超過50%；

4。 上游通道不給力，內部系統也不給力，經常網路波動就退款失敗，或者當日交易不足就退款失敗，只能打回給商家，讓其二次發起。

在以前允許直連模式的情況下，通道會有以下情況：

1）不提供退款介面；但有通道提供的商戶後臺；

2）提供退款介面，當日交易金額小於退款金額，則通道退款失敗；有些細分到具體某個支付產品（如微信公眾號）的當日交易金額小於退款金額，就退款失敗；

網路原因波動，則通道沒接收，則退款失敗；

3）若風險訂單，通道有時會先行扣款，再通知我們，因此我們需要讓客戶發起，但不經過上游渠道；

4）通道對賬單與訂單狀態不一致，例如對賬單成功，但是介面返回失敗；

5。 給商戶的退款介面不支援返回失敗原因；

6。 經常性的遭到客戶投訴退款效率問題；

7。 每次退款訂單不支援系統自動稽核，均需要人工稽核。

所以當時接手這樣的退款系統，內心是有點小崩潰的，感覺舊退款系統真是一無所能。

舉幾個栗子

：

1） 作為電商平臺，購買兩雙鞋，對其中一雙鞋不滿意進行退款，然後我們不支援；

2） 客戶做秒殺拼團活動，一做拼團，退款的併發不支援；不能退回支付手續費，平臺含淚虧錢；

3）正常的全額退款訂單，明明在支付公司申請成功，但是莫名之間將退款訂單打回來，原因是

支付公司與上游通道不穩定。作為客戶的認知是無法理解的，“明明退款申請成功，卻為何退款失敗回來呢？？Are you kidding me？”

儘管知道是個坑，但還得義無反顧，因為作為產品經理，崗位職責就是得解決問題；而且越能體現產品經理的價值就是解決棘手的問題，就是對異常問題的深入思考。

產品經理的核心，不在於原型畫的有多好，不在於需求文件寫的多清晰，而在於對異常問題的深入思考。

因此，在我接到這個需求之後，多次經過需求分析，以及需求調研。最終發現要想做好退款需求，主要是理解好商戶、支付公司，以及財務對賬的需求。

對於商戶，最核心的要保證退款成功率、快速到賬，支撐退手續費、部分退款等業務情況；

對於支付公司，主要是滿足商戶需求，以及提高退款的靈活性，能夠支援業務的異常性；對財務對賬，通道退款手續費與通道保持一致。

二、需求分析

做好需求分析，需要我們換位思考客戶對一個需求的實際訴求；需求分析，也是一個理清思路的過程。

本文從商戶、支付公司、財務三個物件中分別梳理他們對退款的需求。

1。 商戶對退款的訴求

商戶對於退款的需求，主要體現在能夠支撐商戶的業務需求，例如部分退款、多次退款、介面全面性等等，那麼針對以下幾種進行單獨分析。

1）提供多種手續費模式

① 需支援不退回手續費；目的是保證公司現有利益，儘量對外不退手續費；

② 需支援退回手續費。目的是提供優質商戶的客戶體驗。

這裡的退款手續費計算是一個難點，因為一筆具體的支付金額對外收費存在三種情況

1）按比例收費；

2）按單筆固定金額收費；

3）按固定金額+比例收費。

那麼應該如何處理手續費呢？如何才能保障雙方利益呢？儘可能的將手續費退完，並且同時有便於商家理解？其實有兩種簡單的實現方式：

① 按比例退回手續費

，即退款手續費=退款金額*支付金額*支付手續費；

② 按支付費率退回手續費

，即退款手續費=退款金額*支付費率。若固定金額收手續費，則每退一次，退回一次固定金額費率。

經過權衡，我們選擇了按比例退回手續費模式，更加簡單易懂。

2）支援任意金額退款

① 支援訂單全額退款；

② 支援部分退款。

舉例：在網上買兩雙鞋，然後對其中不滿意只退其中一雙，而不想兩雙都退。

3）支援多次退款

① 支援一次退款；

② 支援多次退款。

場景：消費者在網上一次性購買十件衣服，由於是陸續到貨，收到貨物之後不滿意，則進行退款，那麼這裡就會出現多次的部分退款。

4）提供全面的退款介面

① 介面的全面性

：單筆退款介面、批次退款介面、以及接口裡面的請求、應答、非同步通知、查詢介面等等均需滿足；

② 錯誤碼的全面性

：對於商戶對接而言，假如出現退款失敗，則需要將具體失敗原因返回，方便進行排查問題，以及聯絡消費者。

由於一家支付機構會接入多家上游渠道，而且每家渠道均不一樣，甚至錯誤碼存在問題。因此不能直接將通道錯誤碼返回給商家，必須做到錯誤碼的過濾，建立一套錯誤碼轉譯機制，提高使用者體驗。

5）支援退款到賬快

由於商戶也是為消費者而服務的，對於消費者，一旦申請退款，則系統資金立馬到賬；如果資金遲遲不到賬，而會降低消費者對商家的好感，從而也會降低商家對支付公司的好感。因此基本一旦發起退款，希望分鐘級到賬處理。

首先分析退款的路徑，商戶發起退款後，處於待支付公司稽核，支付公司稽核之後進入其上游銀聯稽核，那麼作為支付公司所能做的就是降低退款訂單在支付公司的滯留時間，簡單系統自動判斷訂單無風險就自動稽核透過。

2。 支付公司對退款的訴求

作為支付公司本身，在基本滿足商戶對於退款訴求之外，還有更高的指標要求；主要表現在要儘可能的提高退款成功率、保證退款安全性、保證退款的靈活性，以及易用性。

接下來從產品視角的來分析應該如何滿足這些需求。

1）儘可能保證退款成功率

① 更新退款處理

：一般通道直接返回退款失敗的訂單，不用直接告訴商戶重新發起，目的是降低對於商戶的體驗干擾。而是支付公司將內部的退款流水號更新，二次請求上游通道，這樣對於上游通道而言，這是一筆新的退款；退款成功之後，再更新告知商戶退款的成功結果。

說明：商戶請求支付公司的單號，一般是商戶訂單號，支付公司會相應生成退款流水號進行標記，同時將退款流水號作為請求上游單號請求銀行，銀行會返回銀行流水號。我們只需將請求銀行的退款流水號進行更新即可，這樣區分退款應答層和請求層，更加層次分明。

② 打款退款處理

：通道無退款介面，或者多次響應失敗；特別是對於快捷支付的產品，可以選擇退款呼叫代付打款介面，透過介面打款給原消費者卡號中，這樣間接實現退款，保證退款成功率；做到盡一切可能提高體驗。

③ 退回消費者餘額

：若消費者開立了錢包賬戶，則提供退回消費者錢包餘額的功能，這樣將極大提高退款效率。

④ 建立反查機制：

在系統內部建立定時反查機制。針對處理中的訂單進行查詢退款狀態，一旦反查結果成功，則更新退款狀態，避免通道沒有退款介面，或者非同步應答出現問題的情況。

2）儘可能保證退款安全性

① 根據通道情況配置是否系統自動稽核

。由於通道渠道的質量千差萬別的，對於良好執行的上游渠道，則可以配置自動稽核，則會降低退款訂單的停留時間；對於質量差的不穩定的渠道，則人工稽核。如果出現系統故障時，出現交易堵塞引發批次退款時，也可以緊急關閉自動稽核功能，保證安全性；

② 通道先行扣款，則人工稽核

。對於有些風險訂單，通道實行先行扣款機制（儘管不合理），為了對賬的一致性，我們需要商戶重新發起，但是需攔截請求通道，因此可以針對這些訂單對應的上游渠道進行人工稽核，直接作退款成功處理。

3）儘可能保證退款的靈活性

① 增加強制退款成功操作

：如果和通道對賬發現，訂單在對賬單顯示成功，但是系統中仍為未成功的狀態，因此需要將這些訂單強制更正為退款成功。

② 增加強制退款失敗操作

：由於前面聊到通道退款失敗，我們將不直接置為失敗，而是更新處理，那麼假設消費者卡號登出呢？則只能強制置為失敗。

③ 降低耦合性

：由於退款系統屬於支付收單的逆向流程，很容易與收單進行強耦合在一起，因此有必要將收單的關鍵欄位同步到退款系統，無需頻繁呼叫收單資料。降低耦合性有助於為後續的子商戶退款、分賬退款作鋪墊。因此一旦涉及分賬退款，其退款邏輯的複雜性遠遠高於基礎退款。

④ 建立異常訂單機制

。 主要有如下情況：一旦發起重複訂單支付，可以系統自動觸發呼叫退款的模式進行處理；有風控系統主動觸發退款的模式進行處理；有支付金額小於訂單手續費的入賬異常，自動觸發發起退款。

4）儘可能保證退款的易用性

① 介面返回失敗原因

，由於支付公司上游會有很多通道，各家的錯誤碼不一致，甚至現有的銀聯網聯不一致，也不規範，作為普通商家很難看懂。因此需要建立一層錯誤碼轉譯機制，目的是建立支付公司內部統一錯誤碼機制，實現標準化，同時將上游通道難以理解的錯誤碼簡化為簡單易懂的錯誤碼。

② 失敗訂單自動化處理

，前期可以根據通道的返回的錯誤碼，進行人工二次處理，後期則可以根據通道具體的錯誤碼進行自動化處理，目的是在保證退款成功率的同時又降低人工操作成本。

舉個例子：通道錯誤碼返回：“該卡為作廢卡，訂單狀態：01”，則說明卡號本身為廢卡，因此無論怎麼處理都將失敗，可以自動化置為失敗；又例如返回：“你的操作過於頻繁，請稍後再試”，這可以系統自動化的更新退款流水號重新處理。

3。 財務對於退款的訴求

財務的日常工作之一，是進行通道對賬，目的是將上游通道的訂單計費情況，與內部系統保持一致。由於支付公司的上游-銀聯/網聯，在通道退款介面不會返回退款手續費的值，因此需要支付公司自行計算退款手續費，以保持與通道一致性。

1）保證退款手續費無誤

上游的訂單計費，對於支付公司來講就是支出的成本，因此每個渠道入網，都會有個成本規則配置（這個規則要有很強的靈活性來支撐不同收費模式），需要根據通道情況，增加“是否退回手續費，以及手續費規則”。這樣的目的是保證雙方規則的統一性，降低對賬的障礙。

具體如下圖所示：

三。 產品設計

在進行產品設計的時候，我們需要確立產品設計的原因，以退款系統為例：

首先，要進行解耦，各模組之間可以採取必要的相互呼叫原則，不影響其他功能模組的設計；

其次，退款的賬戶扣款要明確賬戶扣款的路徑；

第三，要明確退款的各模組的定義、標準，例如狀態流，稽核流、退款方式、退款來源；

最後，要梳理出各板塊的業務邏輯，並透過產品架構串聯起來。

根據產品設計原則，同時基於以上的需求分析的情況，本文只挑選三個重要板塊進行產品設計分析：

1）如何確立退款業務流；

2）退款手續費的計算準確；

3）更新退款的業務邏輯。

1。 退款業務流

一個好的退款狀態流能夠很好的體現退款訂單所進行的步驟。而且，退款又是一個非常有嚴謹的業務，有時又特別需要稽核環節，因此為了將退款流程更加清晰，將流程分為退款狀態流和稽核流。

1）退款狀態流

2）退款稽核流

這裡稽核狀態之所以不加入銀行稽核狀態，是因為完全沒有必要，作為下游機構無需知道其稽核機構，只需知道處理狀態即可。

3）退款狀態的變動流程

2. 退款手續費計算邏輯

由於允許多次退款，因此需要標記一筆退款訂單的剩餘可退的金額，以及剩餘可退手續費，避免商戶鑽空子導致公司虧錢，因此邏輯必須嚴謹。

計算公式，

剩餘可退金額=訂單金額-累計已退款金額；

如果是初次退款，則剩餘可退金額=訂單金額‘’

剩餘可退手續費=支付手續費-累計已退手續費。

計算邏輯

舉例為證：假設交易金額為100的訂單，其支付手續費為0。5元；交易金額為1000元的訂單，其支付手續費為4元。

字母含義：試算手續費=A，剩餘可退手續費=B，此次實際退款的手續費=C；剩餘可退金額=D。

從中我們可以知道，由於退款存在近似值的情況，會存在一定的誤差。

例如下表中100元的訂單，在未完全退款之前，就存在把退款手續費扣完的情況；因此我們要設定剩餘可退金額與試算的退款手續費比較，避免虧損。

但也存在下表中1000元訂單的情況，在完全退款之後，其手續費存在退不了的情況，而這種情況對於支付公司並未有過多損失，因此允許這種發生。

3. 更新訂單邏輯

當通道返回退款失敗的結果之後，往往並不是這筆訂單一定不能再處理的，而是在這次的請求是不能處理失敗的。因此，我們需要千方百計儘可能重新處理，但是更新訂單並未盲目，否則會造成超額退款的情況。

所以，更新退款需要基於以下判斷：

1) 先反查通道退款狀態

，如果反查通道的狀態實際為“已建立”，即通道未接受，則用原退款流水號重新請求即可；若反查成功，則系統自動更新退款流水號重新請求，直至成功；

2) 不反查直接更新退款

，有一種請求屬於通道反查失敗，一直報錯，但是基於通道對賬單發現並未處理成功，可以認定為通道本身的問題，因此可以不反查直接更新，由於這個操作具有風險性，故僅部分退款時需謹慎操作。

4。 其他

在產品設計中，需要將退款各種情況考慮全面，因此為了讓大家更好的理解設計退款的全貌，我將剩餘的產品功能核心部分展示一下，方便理解。

1）商戶入網

① 支撐商戶的每個支付產品退手續費、不退手續費；

② 支援商戶的特殊計費不退手續費，普通計費退手續費。

2）通道入網

① 支援一個通道的不同規則退手續費與不退手續費；

② 允許每個通道的退款手續費演算法不一樣的配置。

3）對外介面

① 提供單筆退款介面、批次退款介面、查詢單筆退款介面、查詢所有退款介面；

② 打造退款響應碼機制。

4）退款邏輯

① 基於通道情況，可配置自動稽核/人工稽核；

② 基於退款失敗訂單，進行更新處理；

③ 打造通道錯誤碼自動化處理機制，降低人工操作；

④ 支援異常訂單的退款處理。

5）升級退款能力

① 支援子商戶退款；

② 支援打款退款，若無法原路退款，可採取打款退款處理；

③ 支援分賬退款。允許訂單分賬前退款，以及訂單分賬後退款。

四。 總結

打造好退款系統，不僅要支撐現有客戶對於部分退款、退手續費等功能的需求；而且要升級思維，加強對異常情況的考慮——這樣才能夠讓產品持續屹立不倒，打造出一個厲害的退款系統。