打造一個不被吐槽的退款系統,看這篇就夠了

產品老司機手把手教寫文檔,10天線上課程,零基礎掌握產品經理必備7大文檔撰寫法。了解一下>

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

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

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

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

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

一、需求背景

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

  1. 只支持訂單全額退款;不支持部分退款;
  2. 退款不退回交易手續費;
  3. 退款請求的成功率超級低,不超過50%;
  4. 上游通道不給力,內部系統也不給力,經常網絡波動就退款失敗,或者當日交易不足就退款失敗,只能打回給商家,讓其二次發起。

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

  • 不提供退款接口;但有通道提供的商戶后臺;
  • 提供退款接口,當日交易金額小于退款金額,則通道退款失敗;有些細分到具體某個支付產品(如微信公眾號)的當日交易金額小于退款金額,就退款失敗;
  • 網絡原因波動,則通道沒接收,則退款失敗;
  • 若風險訂單,通道有時會先行扣款,再通知我們,因此我們需要讓客戶發起,但不經過上游渠道;
  • 通道對賬單與訂單狀態不一致,例如對賬單成功,但是接口返回失敗;
  • 給商戶的退款接口不支持返回失敗原因;
  • 經常性的遭到客戶投訴退款效率問題;
  • 每次退款訂單不支持系統自動審核,均需要人工審核。

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

舉幾個栗子

  • 作為電商平臺,購買兩雙鞋,對其中一雙鞋不滿意進行退款,然后我們不支持;
  • 客戶做秒殺拼團活動,一做拼團,退款的并發不支持;不能退回支付手續費,平臺含淚虧錢;
  • 正常的全額退款訂單,明明在支付公司申請成功,但是莫名之間將退款訂單打回來,原因是支付公司與上游通道不穩定。作為客戶的認知是無法理解的,“明明退款申請成功,卻為何退款失敗回來呢??Are you kidding me?”

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

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

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

  • 對于商戶,最核心的要保證退款成功率、快速到賬,支撐退手續費、部分退款等業務情況;
  • 對于支付公司,主要是滿足商戶需求,以及提高退款的靈活性,能夠支持業務的異常性;
  • 對財務對賬,通道退款手續費與通道保持一致。

二、需求分析

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

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

1. 商戶對退款的訴求

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

1)提供多種手續費模式

  • 需支持不退回手續費;目的是保證公司現有利益,盡量對外不退手續費;
  • 需支持退回手續費。目的是提供優質商戶的客戶體驗。

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

  1. 按比例收費;
  2. 按單筆固定金額收費;
  3. 按固定金額+比例收費。

那么應該如何處理手續費呢?如何才能保障雙方利益呢?盡可能的將手續費退完,并且同時有便于商家理解?

其實有兩種簡單的實現方式:

  1. 按比例退回手續費,即退款手續費=退款金額*支付金額*支付手續費;
  2. 按支付費率退回手續費,即退款手續費=退款金額*支付費率。若固定金額收手續費,則每退一次,退回一次固定金額費率。

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

2)支持任意金額退款

  • 支持訂單全額退款;
  • 支持部分退款。

舉例:在網上買兩雙鞋,然后對其中不滿意只退其中一雙,而不想兩雙都退。

3)支持多次退款

  • 支持一次退款;
  • 支持多次退款。

場景:消費者在網上一次性購買十件衣服,由于是陸續到貨,收到貨物之后不滿意,則進行退款,那么這里就會出現多次的部分退款。

4)提供全面的退款接口

  • 接口的全面性:單筆退款接口、批量退款接口、以及接口里面的請求、應答、異步通知、查詢接口等等均需滿足;
  • 錯誤碼的全面性:對于商戶對接而言,假如出現退款失敗,則需要將具體失敗原因返回,方便進行排查問題,以及聯系消費者。

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

5)支持退款到賬快

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

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

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

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

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

1)盡可能保證退款成功率

  • 更新退款處理:一般通道直接返回退款失敗的訂單,不用直接告訴商戶重新發起,目的是降低對于商戶的體驗干擾。而是支付公司將內部的退款流水號更新,二次請求上游通道,這樣對于上游通道而言,這是一筆新的退款;退款成功之后,再更新告知商戶退款的成功結果。
  • 說明:商戶請求支付公司的單號,一般是商戶訂單號,支付公司會相應生成退款流水號進行標記,同時將退款流水號作為請求上游單號請求銀行,銀行會返回銀行流水號。我們只需將請求銀行的退款流水號進行更新即可,這樣區分退款應答層和請求層,更加層次分明。
  • 打款退款處理:通道無退款接口,或者多次響應失敗;特別是對于快捷支付的產品,可以選擇退款調用代付打款接口,通過接口打款給原消費者卡號中,這樣間接實現退款,保證退款成功率;做到盡一切可能提高體驗。
  • 退回消費者余額:若消費者開立了錢包賬戶,則提供退回消費者錢包余額的功能,這樣將極大提高退款效率。
  • 建立反查機制:在系統內部建立定時反查機制。針對處理中的訂單進行查詢退款狀態,一旦反查結果成功,則更新退款狀態,避免通道沒有退款接口,或者異步應答出現問題的情況。

2)盡可能保證退款安全性

  • 根據通道情況配置是否系統自動審核。由于通道渠道的質量千差萬別的,對于良好運行的上游渠道,則可以配置自動審核,則會降低退款訂單的停留時間;對于質量差的不穩定的渠道,則人工審核。如果出現系統故障時,出現交易堵塞引發批量退款時,也可以緊急關閉自動審核功能,保證安全性;
  • 通道先行扣款,則人工審核。對于有些風險訂單,通道實行先行扣款機制(盡管不合理),為了對賬的一致性,我們需要商戶重新發起,但是需攔截請求通道,因此可以針對這些訂單對應的上游渠道進行人工審核,直接作退款成功處理。

3)盡可能保證退款的靈活性

  • 增加強制退款成功操作:如果和通道對賬發現,訂單在對賬單顯示成功,但是系統中仍為未成功的狀態,因此需要將這些訂單強制更正為退款成功。
  • 增加強制退款失敗操作:由于前面聊到通道退款失敗,我們將不直接置為失敗,而是更新處理,那么假設消費者卡號注銷呢?則只能強制置為失敗。
  • 降低耦合性:由于退款系統屬于支付收單的逆向流程,很容易與收單進行強耦合在一起,因此有必要將收單的關鍵字段同步到退款系統,無需頻繁調用收單數據。降低耦合性有助于為后續的子商戶退款、分賬退款作鋪墊。因此一旦涉及分賬退款,其退款邏輯的復雜性遠遠高于基礎退款。
  • 建立異常訂單機制。 主要有如下情況:一旦發起重復訂單支付,可以系統自動觸發調用退款的模式進行處理;有風控系統主動觸發退款的模式進行處理;有支付金額小于訂單手續費的入賬異常,自動觸發發起退款。

4)盡可能保證退款的易用性

  • 接口返回失敗原因,由于支付公司上游會有很多通道,各家的錯誤碼不一致,甚至現有的銀聯網聯不一致,也不規范,作為普通商家很難看懂。因此需要建立一層錯誤碼轉譯機制,目的是建立支付公司內部統一錯誤碼機制,實現標準化,同時將上游通道難以理解的錯誤碼簡化為簡單易懂的錯誤碼。
  • 失敗訂單自動化處理,前期可以根據通道的返回的錯誤碼,進行人工二次處理,后期則可以根據通道具體的錯誤碼進行自動化處理,目的是在保證退款成功率的同時又降低人工操作成本。

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

3. 財務對于退款的訴求

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

保證退款手續費無誤

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

具體如下圖所示:

產品設計

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

  1. 首先,要進行解耦,各模塊之間可以采取必要的相互調用原則,不影響其他功能模塊的設計,
  2. 其次,退款的賬戶扣款要明確賬戶扣款的路徑;
  3. 第三,要明確退款的各模塊的定義、標準,例如狀態流,審核流、退款方式、退款來源;
  4. 最后,要梳理出各板塊的業務邏輯,并通過產品架構串聯起來。

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

  1. 如何確立退款業務流;
  2. 退款手續費的計算準確;
  3. 更新退款的業務邏輯。

1. 退款業務流

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

1)退款狀態流

2)退款審核流

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

3)退款狀態的變動流程

2. 退款手續費計算邏輯

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

  • 計算公式,剩余可退金額=訂單金額-累計已退款金額;
  • 如果是初次退款,則剩余可退金額=訂單金額,剩余可退手續費=支付手續費-累計已退手續費。

計算邏輯

舉例為證:假設交易金額為100的訂單,其支付手續費為0.5元;交易金額為1000元的訂單,其支付手續費為4元。

字母含義:試算手續費=A,剩余可退手續費=B,此次實際退款的手續費=C;剩余可退金額=D。

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

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

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

3. 更新訂單邏輯

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

所以,更新退款需要基于以下判斷:

  • 先反查通道退款狀態,如果反查通道的狀態實際為“已創建”,即通道未接受,則用原退款流水號重新請求即可;若反查成功,則系統自動更新退款流水號重新請求,直至成功;
  • 不反查直接更新退款,有一種請求屬于通道反查失敗,一直報錯,但是基于通道對賬單發現并未處理成功,可以認定為通道本身的問題,因此可以不反查直接更新,由于這個操作具有風險性,故僅部分退款時需謹慎操作。

4. 其他

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

1)商戶入網

  • 支撐商戶的每個支付產品退手續費、不退手續費;
  • 支持商戶的特殊計費不退手續費,普通計費退手續費。

2)通道入網

  • 支持一個通道的不同規則退手續費與不退手續費;
  • 允許每個通道的退款手續費算法不一樣的配置。

3)對外接口

  • 提供單筆退款接口、批量退款接口、查詢單筆退款接口、查詢所有退款接口;
  • 打造退款響應碼機制。

4)退款邏輯

  • 基于通道情況,可配置自動審核/人工審核;
  • 基于退款失敗訂單,進行更新處理;
  • 打造通道錯誤碼自動化處理機制,降低人工操作;
  • 支持異常訂單的退款處理。

5)升級退款能力

  • 支持子商戶退款;
  • 支持打款退款,若無法原路退款,可采取打款退款處理;
  • 支持分賬退款。允許訂單分賬前退款,以及訂單分賬后退款。

總結

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

 

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

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

給作者打賞,鼓勵TA抓緊創作!
1人打賞
評論
歡迎留言討論~!
  1. 羨慕可以給你一個月時間出方案的老板

    回復
  2. 我們老板說,這個東西還不簡單啊,一個星期還做不完?

    回復
    1. 你們老板很厲害哦! 單純的從正常流程上,退款就是一個信息傳遞的過程,這個是很簡單;
      但退款系統難的是在每個流程流轉出現的問題,我們如何去預防,如何讓系統多跑幾遍而減少用戶的操作;
      我們要知道,任何系統的產品設計核心點均是對異常問題的充分考慮。
      一個星期,單純對接支付退款,沒問題;如要重新設計并開發一套好的退款系統,哈哈哈,基本不可能

      回復
  3. 想做好這個系統會需要多久呢?感覺這么多問題放在一起,只能一步步向前走,我覺得我要做很久啊

    回復
    1. 這個問題,應該花了一個月想清楚具體實現路徑。這類b端需求,主要先把握主要路徑,關鍵角色,進行問題拆解,分而治之。比如對于商戶端,以及通道端就是分開解決,然后通過退款路徑串聯起來

      回復
  4. “1.按比例退回手續費,即退款手續費=退款金額*支付金額*支付手續費;”,請教一下這個算法是怎么來的呀?不太理解 :cry:

    回復
    1. 退款金額/支付金額*支付手續費??

      回復
    2. 這樣的話,差不多就可以理解啦,謝謝作者分享

      回復
    3. 這個錯誤可能是上傳時,弄錯了,不好意思哈

      回復
  5. 認真看完受益匪淺!謝謝大佬分享!【btw退款手續費流程圖,當A>B為否時,應該退回A吧】

    回復
    1. 這樣不行呀,比如訂單支付手續費10元,已經退了9元,那么剩余可退的手續費為1元;然后進行最后一筆退款時進行試算發現為1.2元,那么只能取較小值1元;這樣總的退款手續費才不會超過支付手續費,才不會虧損;如果選擇試算的較大值1.2 元,那么就表明虧了0.2元 了,所以不太可取

      回復
  6. 文章清晰詳細,太厲害了

    回復
    1. 哇撒,超級感謝

      回復
  7. 什么時候改要拆,什么時候要合,是一個值得思考的問題。

    我比較喜歡都拆開來,這樣技術比較好理解。

    這樣的做法對么?

    回復
    1. 拆的方式更加清晰,但也要觀察兩條支線是否重合度高,考慮下合并之后對于體驗是否更好,這些拆與合,都是要權衡的。如果說合著不清晰,就拆開

      回復
  8. 寫的很棒 !
    我有個小小疑問:退款狀態流、退款審核流這兩種狀態是否可以合并,這樣用起來更方便

    回復
    1. 可以合并呀,只不過合并之后狀態值特別多,超過十種狀態,讓很多初學者容易搞混,而且退款狀態流和審核狀態流屬于兩個獨立判斷的,分開之后,表述更清晰

      回復
    2. 也就8個把,多了2個;
      1、退款已創建;(是否不需要,默認創建后就是商戶審核中?)
      2、商戶審核中;
      3、商戶審核不通過;
      4、平臺審核中;(商戶審核通過,更新至此狀態)
      5、平臺審核不通過;
      6、銀行處理中;(平臺審核通過,更新至此狀態)
      7、退款成功;
      8、退款失敗;

      回復
    3. 1. 退款已創建是針對接口API請求來的初始狀態(接口發起無需商戶再次審核);商戶處理中,是通過商戶后臺發起(非接口,需要商戶審核)。
      2. 你這個狀態有幾個問題,退款終態的取值不定:如果商戶審核不通過,那么退款的終態結果是什么呢?平臺審核不通過,退款的終態是什么呢? 對于退款來講,實際上只有兩個終態:退款成功、退款失敗。
      3. 這個單狀態還有個明細的問題,怎么真正確定流程運轉到哪一步,舉個例子,當平臺審核通過之后,請求銀行,但是銀行因為一些原因(當前的資金不足)退回來,這時的狀態為什么狀態呢?平臺審核中吧。 那這一步與之前那步商戶請求支付機構的平臺審核中,通過什么來區分呢? 到底平臺審核中是商戶請求過來,還是銀行退款失敗回來的狀態呢?
      4. 我當時的區分邏輯是,審核,更多的是一種商戶/平臺的操作結果;退款狀態,則是對于退款狀態的顯示

      回復
  9. ??????

    回復
    1. 感謝支持

      回復
  10. 劃重點:產品經理的核心,不在于原型畫的有多好,不在于需求文檔寫的多清晰,而在于對異常問題的深入思考

    回復
  11. 寫得很詳細

    回復
    1. 感謝支持

      回復
  12. 不錯,雖然是以支付平臺的角度出發,但是也很有用

    回復
    1. 感謝支持

      回復
  13. 干貨,已收藏

    回復
  14. 我希望大家積極的發表自己的想法哈

    回復
  15. 突然發現持續發布干貨文章真心不易,要自己不斷回顧且縷清楚以往的工作經驗,也算是整理思路的一個過程。希望這篇有個好的閱讀量以及訂閱量吧!

    回復
    1. 干貨,持續輸出好文章確實很難

      回復
  16. 收藏了 收藏了

    回復
马总会三肖中特