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

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

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

因此，筆者根據在支付公司獨自負責退款系統的經驗，讓大家避免踩坑，向大家分享如何從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）升級退款能力

① 支持子商戶退款；
② 支持打款退款，若無法原路退款，可采取打款退款處理；
③ 支持分賬退款。允許訂單分賬前退款，以及訂單分賬後退款。

四. 總結

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

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部