本篇文章將以錢包業務流程設計為例,分析在面對分散、用戶體驗較差的業務時,該如何設計一個便捷、靈活的錢包業務,接下來,我們看看作者的思考。
(資料圖)
這是一個非常實用的案例,并且,案例涉及面比較廣,可以培養對整個錢包、賬戶、提現業務的認識,同樣,也是一個可以拿來即用的產品方案。
一、一提多戶的局面
很多公司會存在多條業務,這時候有些公司每個業務線都會有一個錢包業務,這樣就造成了商家端錢包的分散。
一個商家在每個業務線都有一個錢包,分別管理余額、提現、綁卡、支付密碼等,資金管理體驗比較差。
此時,就可能要對各業務線的錢包進行統一,統一以后商家僅需管理一個錢包,綁定一張卡、設置一個密碼,一次完成多賬戶的同時提現,提高資金管理效率,提升商家的結算體驗。
此時,錢包的提現就就 2 個核心問題要解決:
有多少:需要有系統告知錢包當前的可提金額是多少,以及這些余額分別來自哪些賬戶,每個賬戶有多少。
怎么提:當商家輸入提現金額時,需要有系統告知錢包,本筆提現要從哪些賬戶出,每個賬戶出多少,所以需要一個分配的策略。
接下來我們做的就是解決這 2 個核心訴求。
二、解決問題前要想明白幾個關鍵
以上的訴求,我們可以轉換為 " 錢包的余額查詢、提現預加工的支持 " 這樣兩個更明確的訴求,其中有幾個關鍵點要想明白。
1)可提余額并不一定等于賬戶可用余額的總和
因為有提現手續費的存在,導致個別賬戶可能不滿足最低提現金額要求,所以說可提金額不一定等于可用余額的總和。
就比如一個賬戶里只有 2 毛錢,而提現手續費要 5 毛,那就無法完成提現。
上表示例中主體 001 的可提余額計算結果 =11.5 元。
因為賬戶 3 中的 0.8 元不滿足最低提現要求,所以不可提。
實際可提金額 =1.5+10.00=11.5 元
因此,錢包余額 12.3 元,可提金額 =11.5 元。
2)可提余額不代表用戶要提的金額
因為他可能只選擇提取其中的一部分,所以要計算這部分金額應該如何分配到賬戶;除非讓用戶選擇那個賬戶提多少,但這樣就失去了統一錢包的意義了。
3 ) 如何制定一個提現金額的分配策略
有很多種方法,可以做得簡單一些,比如就設定一個固定的順序,ABC 的順序進行扣款。
也可以做成綜合的策略,比如如果一個賬戶就夠了,那就只出一個賬戶,如果多個賬戶都夠了,那就按照順序扣款等,不過這樣的算法成本會增高,可能帶來的效果并不明顯。
所以,我們就選擇第一種方法,按照固定順序扣款。
如例:可提金額是 11.5;此時用戶僅提現 "8 元 ",該怎么處理,根據提現扣款順序的設定,如上表所示;順序代表扣款順序。
實際扣款如表最后一列:賬戶 1 扣 1.5,賬戶 2 扣 6.5。
用戶每輸入一次提現金額,就執行一次預計算,并實時反饋給用戶。
三、誰來計算當前的賬戶總余額
因為底層是多個賬戶,每個賬戶都有總余額,可用余額,可提金額等信息。
那么當錢包要查詢賬戶余額信息時,對底層賬戶余額進行加工匯總的任務誰來完成?也就是以下三個公式:
錢包 N 總余額 = 賬戶 A 余額 + 賬戶 B 余額 + 賬戶 C 余額
錢包 N 可用余額 = 賬戶 A 余額 + 賬戶 B 余額 + 賬戶 C 余額
錢包 N 可提余額 = 賬戶 A 余額 + 賬戶 B 余額 + 賬戶 C 余額
無外乎有 3 種處理方法:
錢包進行處理:這種方法有個問題,就是耦合嚴重,錢包受底層賬戶的賬戶設置、制度政策的影響較大。
賬戶系統進行處理:會讓賬戶系統承載更多的計算加工任務,不利于資金管理的純粹性。
清算系統進行處理:對于清算系統來說,進行大量的計算和處理是其最擅長的職能,交給它去完成上下游都釋放出壓力,各自去做自己最純粹的事情。
如上圖所示,箭頭代表余額數據的查詢,123 代表明細數據,N 代表處理過的數據,最后選擇清算系統來做(綠的箭頭),此時清算系統查詢到 123 明細數據,輸出給錢包的是 N 匯總數據,并且包含了明細 123 數據。
所以,為了釋放賬戶的壓力,讓賬戶專心做自己資金管理的職能,將一些處理事務交給清結算系統去做,包括對賬戶余額的加工處理,以及提現余額的分配計算。
四、怎么解決一提多出的問題
因為錢包只發起一筆提現請求,但是,最終要扣多個賬戶,出多筆資金。
那么,這個從一提到多出的處理由誰來實現,也就是一筆提現變多筆提現。
因為是提現業務,所以我們選擇讓提現處理系統來完成對提現的拆分。
也就是錢包發起提現時,會請求清算系統對提現金額進行分配計算,然后得到計算結果,并封裝成提現數據提交給提現系統。
錢包提交的提現請求數據結構如下:
提現請求 ID
提現金額 X
提現明細 { 子提現請求 1,子提現請求 2} 由提現系統對提現請求拆分成兩筆提現:提現 1,提現 2,分別請求清算系統進行提現扣款處理。
這樣我們得到如下的業務流程:
五、把業務架構畫出來,看看全局
我做方案喜歡搞這么個玩意,讓我心有乾坤人不慌,看看整個業務所涉及的范圍,以及每個環節要承載的任務。
通過上圖,我們就可以看清楚做這件事所涉及到的環節,以及要實現的能力有哪些,誰來做什么?
專欄作家
陳天宇宙,微信公眾號:陳天宇宙,人人都是產品經理專欄作家。多平臺支付領域專欄作者,十年資深產品;專注為 10 萬支付產品經理和支付機構以及企業提供深度支付內容和服務!
本文原創發布于人人都是產品經理,未經許可,禁止轉載。
題圖來自 Unsplash,基于 CC0 協議。
頭條 23-07-09
頭條 23-07-08
頭條 23-07-08
頭條 23-07-08
頭條 23-07-08
頭條 23-07-08
頭條 23-07-08
頭條 23-07-08
頭條 23-07-08
頭條 23-07-08
頭條 23-07-08
頭條 23-07-08
頭條 23-07-08
頭條 23-07-08
頭條 23-07-08
頭條 23-07-08
頭條 23-07-08
頭條 23-07-08
頭條 23-07-08
頭條 23-07-08
頭條 23-07-08
頭條 23-07-08
頭條 23-07-08
頭條 23-07-08
頭條 23-07-08
頭條 23-07-07
頭條 23-07-07
頭條 23-07-07
頭條 23-07-07
頭條 23-07-07
頭條 23-07-07
頭條 23-07-07
頭條 23-07-07
頭條 23-07-07
頭條 23-07-07
頭條 23-07-07
頭條 23-07-07
頭條 23-07-07
頭條 23-07-07
頭條 23-07-07
頭條 23-07-07
頭條 23-07-07
頭條 23-07-07
頭條 23-07-07
頭條 23-07-07
頭條 23-07-07
頭條 23-07-07
頭條 23-07-07
頭條 23-07-07
頭條 23-07-07
頭條 23-07-07
頭條 23-07-07
頭條 23-07-07
頭條 23-07-07
頭條 23-07-07