中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

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

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

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

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

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

一、需求背景

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

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

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

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

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

舉幾個栗子：

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