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

不同類型的支付，或許會有不同的退款時效，那么如果過了退款時效之后想將錢退回去，可以怎么操作？這篇文章里，作者就闡述了“基于付款能力的退款產品”該如何設計，一起來看看吧。

退款是一個比較常見的逆向業務。

但是退款不是說什么時候想退就能退，不同的渠道不同類型的支付有不同的退款時效。

過了退款時效，還能把錢退出去么？或者說，過了退款時效，怎么樣才能把錢退回去呢？

渠道的退款時效是渠道開放給商戶的權益，而商戶和用戶的退款協議是另一回事，二者難免存在錯配。

比如，某平臺就是敢承諾，永久可退，那么我想沒有任何一個支付渠道可以滿足他這個訴求，怎么辦？

產品經理的神奇魔力就是，交給他，啥事都能給你辦，不就是把超退款時效的款退回去么。

既然原渠道退不了了，那么……就得整點幺蛾子了。

退款的本質就是“把錢給他”，真想退，那就打破原路退的禁錮。

一、基礎性的退款能力

支付的逆向是退款，而退款也有幾種基礎的模式，我們先把這個了解清楚。

1. 怎么退

一筆訂單的內容構成是多樣化的，那么也必然造成一筆退款的構成也是多樣化的。

訂單包含多個商家，多款商品，多種費用，那么退款的花樣就多了。

從退款的基礎能力上來說，一般的渠道會提供以下幾種退款模式，我們可以把每一種退款模式當成一種退款產品。

對于平臺來說，又可以基于渠道的基礎退款模式，封裝出更多場景的退款產品。

比如，可以將按商品退封裝出一個按“商家退”的模式，將一個訂單中的同一個商家的商品打包進行退款，從效果上就是按商家退。

這種處理手段，就是產品經理在設計上的靈活性；沒有出路，也要基于手頭的能力創造出新出路。

2. 從哪里出錢

錢不一定都在一個籃子里，那退款也就不一定從一個賬戶往回退。

退款的本質也不是必須原路退款到指定賬戶，而是將錢從收款者手里退回付款者手里。

那么，對于收款者來說，就沒必要必須從收款的賬戶出。

在渠道簽約產品時，往往會開通多個賬戶，比如基本戶、運營賬戶、手續費賬戶、營銷賬戶等，都屬于該商戶。

而同一個賬戶也可能有多種資金屬性，比如可用余額、凍結余額、待結算余額等；

所以，在退款時，有的渠道會提供指定出款賬戶和資金類型的能力。

當然，對于一個交易體量很大的平臺來說，對這一能力并沒有太強的訴求，從原基本戶退回足夠了。

3. 退回哪里

前面我們講了，退款的本質是退給付款的人，而不一定非得是付款的賬戶；

因為付款人在該平臺可能有多個收款路徑，比如在微信有綁定的銀行卡、也有微信零錢，如果原路退回綁定的卡失敗，那么微信可以決定退回用戶的零錢賬戶。

這樣我們就把退款的基礎能力梳理清楚了。

二、必須退，把退款轉成付款

開頭介紹了，退款有退款時效，過了這個時效，原支付不再支持通過渠道退回。

但是，本身的業務存在這樣的超時效退款場景，比如平臺的退款協議就是比渠道的退款時效長；

比如家政行業，有的客戶一次簽約3年，那么其中的客戶服務費就是在三年內可退，當2年半時要退剩下的半年單子，那么服務費就需要退回半年的。

這個時候很明顯已經過了渠道的退款時效了，但是從業務上來說又必須退款。
怎么辦？

基于退款的本質是退回付款人這一點，我們不難想到——走付款。

構建一個新的退款產品——退轉付。

該退款產品的核心職能就是將超過退款時效的退款申請，轉換成付款，將錢付給付款人。

要想實現這一退款產品能力，還有幾件重要的事情要做，畢竟你要打破常規。

打破常規，往往需要更高的成本。

三、退轉付，賬號采集與狀態聯動

將退款轉為付款的第一個難題就來了，錢付到哪里？

因為原渠道退回本身就有一個隱藏屬性，那就是我們知道用戶用哪個賬戶付的款，渠道就會退回這個已知的賬戶。

但是，付款給用戶，難度就大了，因為我們不一定知道用戶的收款賬戶信息。

將退款業務轉換成付款要做的第一件事就是“采集用戶的收款賬戶信息”。

如此，就將第一個難題轉換成了一個可落地的需求，采集用戶收款信息。

有了目標，實現起來就容易多了；

可以客戶人工采集銀行卡信息；

也可以在用戶訂單中心增加一個提示：已超原路退款的時效，需要您提交銀行卡信息，平臺將在3個工作日以內將款項打到該卡中；

以上的問題就變成了“采集入口”問題。

一個真正的產品難題會被一層層的分解，直到找到了答案，產品設計的過程其實就是這樣一個過程。

那么怎么發起上述的采集動作呢？就是當后臺點擊“退轉付”時，當然這個發起動作可以是人為觸發，也可以是系統自動觸發。

當退款失敗的原因是“超過退款時效”同時用戶退款協議約定又可退時，自動觸發該退款路徑。

當然了，在發起采集時可以先判斷平臺有沒有用戶的收款卡信息，如果有的話可以選擇合適的付款通道將錢支付出去。

觸發以后，在原退款訂單基礎之上生成一筆付款單。

該付款單是明確的“退轉付”，與原退款單關聯，付款類型定義為“退款轉付款”。

還有非常重要的一個問題需要解決，就是付款與原退款在信息上的強關聯，特別是狀態的聯動。
為什么？

因為退款業務是受到原支付單強制性限制，就是總退款金額不能超過原支付金額，而且，退款付的付款發起的前提是原退款單失敗是由于超時效了。

如果退轉付的付款業務不受上述條件的強制約，那么就可能發生資金損失，產生超額退款。

基于上述的控制鏈，那么退款狀態和付款狀態之間應該構建起聯動性，退轉付的狀態去更新原退款失敗的退款單的狀態，原退款單的狀態開始了新的流轉。

四、退轉付，流程解析

基于退轉付的業務規則和模型，梳理整個退轉付的核心流程，一步步展開，得到最后的流程圖

先定全局流程

整個流程圖有三個泳道組成，左邊是退款業務發起方，右邊是退款渠道，中間是支付核心的退款處理流程

再定退款流程的分支

退款處理流程部分也包含三部分，超過退款時效的退款處理、退款主流程、正常退款處理

其中兩個子流程之間有一條通路，通過退款失敗是否超時效鏈接

對流程圖進行細化

基于上面的設計框架進行細化，即可以得到完整的流程圖，如下圖所示

• 退款發起：業務系統發起退款申請，用戶取消了訂單、申請退貨、售后等一系列業務操作，產生了退款業務；退款請求發往支付核心
• 退款主流程：支付核心接收到退款請求，在主流程上退款模塊創建退款單，然后判斷退款時效是否超期，該判斷是分化出兩個子流程的關鍵節點
• 正常退款的處理子流程：在沒有超期的情況下判定為正常退款，請求原付款通道申請退款即可，不過這里要特別注意，對于退款失敗的情況，要再次判斷是否因為超過退款時效，從而有一條從正常退款流程轉入退轉付流程的通路
• 超過退款時效的退轉付處理子流程：如果最初的退款判斷出，超過了退款時效則創建退轉付訂單，完成收款賬號信息獲取以后發起付款申請
• 退款結果通知：對于成功的退款或者付款結果通知業務方
• 失敗業務的處理：對于失敗的付款或者退款根據失敗原因進行處理，是調整后繼續發起或者將失敗結果通知業務方；比如退轉付失敗原因是收款賬戶信息有誤，則返回用戶進行修改后重新發起；如果是付款賬戶余額不足，則進行充值后再次發起
• 最后要說明的是，退轉付的付款業務應該歸屬于“退款”模塊，或者說退款業務，而不是付款業務。

更精確的描述這個能力，我覺得應該是“基于付款能力的退款產品”。