最近接到了一個來自公司內(nèi)部通訊軟件產(chǎn)品組需求，即在通訊軟件內(nèi)嵌轉(zhuǎn)賬到賬戶的SDK。
再此之前，已打通通訊賬戶和支付平臺賬戶。為什么會有這樣的需求？因為我們內(nèi)部的通訊APP打算外放，作為通訊軟件推向市場，同時我們的第三方支付平臺在部分地區(qū)已經(jīng)有一定的用戶基礎(chǔ)。以上就是這個需求的簡單背景，下面具體說一下在聊天軟件內(nèi)置轉(zhuǎn)賬SDK的處理邏輯。
轉(zhuǎn)賬到賬戶需要涉及哪些模塊？
首先是訂單處理系統(tǒng)，用戶發(fā)起一筆轉(zhuǎn)賬即生成一筆轉(zhuǎn)賬訂單，來記錄轉(zhuǎn)賬的金額、流程狀態(tài)、訂單號、付收款人信息等等。其次因為涉及到資金安全，轉(zhuǎn)賬尤其是大額轉(zhuǎn)賬必須要求用戶實名，所以會用到會員信息系統(tǒng)，來查詢用戶的實名狀態(tài)和實名等級（初級實名、高級實名等，和轉(zhuǎn)賬限額有關(guān)）。確認了用戶已實名，我們就可以根據(jù)付款方的意愿，調(diào)用收銀臺，給用戶選擇支付渠道進行支付扣款。然后會進入資金系統(tǒng)和清結(jié)算系統(tǒng)，進行資金扣取，結(jié)算，記賬等操作。最后收款方就會收到一條通知，【收到一筆轉(zhuǎn)賬】。通知是訂單處理系統(tǒng)同步通訊軟件訂單狀態(tài)以后，做的通知。當然，在整個流程里面還會穿插風控系統(tǒng)，來驗證賬戶是否安全，轉(zhuǎn)賬是否符合風控規(guī)則等等。
關(guān)鍵詞：訂單處理系統(tǒng)、會員信息系統(tǒng)、收銀臺、資金系統(tǒng)、清結(jié)算系統(tǒng)、風控系統(tǒng)、通訊軟件
通訊軟件內(nèi)實現(xiàn)轉(zhuǎn)賬的處理流程？
大家可能對微信轉(zhuǎn)賬的流程比較熟悉，A給B轉(zhuǎn)賬一筆錢，首先是點擊轉(zhuǎn)賬按鈕，輸入轉(zhuǎn)賬金額，確認轉(zhuǎn)賬，選擇支付方式（零錢、零錢通、銀行卡支付、添加新的銀行卡），支付密碼校驗，點擊支付，付款方的這筆轉(zhuǎn)賬就生成了，但是需要收款方點擊收款，這筆金額才會結(jié)算到收款用戶的零錢里面，如果24小時內(nèi)未收款，資金會被退回。當收款用戶領(lǐng)取轉(zhuǎn)賬以后，付款方也會收到一個提醒。如果，付款用戶在收款用戶還未領(lǐng)取上一筆轉(zhuǎn)賬就進行第二次轉(zhuǎn)賬時，微信也會提醒付款方已有一筆轉(zhuǎn)賬還未領(lǐng)取，是否需要繼續(xù)執(zhí)行第二筆轉(zhuǎn)賬。整體來說，體驗還是一如既往的不錯。
我們和微信的情況不太一樣，我們希望在不對原有的支付平臺內(nèi)的轉(zhuǎn)賬流程做較大改動的情況下，完成通訊軟件內(nèi)轉(zhuǎn)賬SDK的開發(fā)。所以，這里討論的轉(zhuǎn)賬處理流程可能就會比較直接。（錢我給你了，你就拿著吧，別不好意思！）
轉(zhuǎn)賬流程其實分為兩個子流程，比較大的子流程自然是轉(zhuǎn)賬流程，比較小的是不滿足轉(zhuǎn)賬條件時的退款流程。先來詳細說一下轉(zhuǎn)賬流程，轉(zhuǎn)賬流程會把上述的所有系統(tǒng)全部涵蓋，簡單的幾步轉(zhuǎn)賬操作，背后卻都是大系統(tǒng)在支撐。
1）A想要向B進行轉(zhuǎn)賬，首先A會在B的聊天界面內(nèi)，點擊轉(zhuǎn)賬按鈕。
2）我們的主系統(tǒng)知道了A的指令，首先需要驗證一下A是否已經(jīng)綁定支付賬戶，如果沒有，麻煩先去綁定，綁定了支付賬戶，我們還要驗證A是否已經(jīng)實名，如果沒有，請去實名。對付款用戶，要求就是這么嚴苛！我們必須知道A是誰，是你本人在操作，才能放心幫你轉(zhuǎn)賬。
3）然后我們也會查看B是否已經(jīng)綁定支付賬戶，如果沒有綁定，我們會讓A邀請B趕緊去綁定支付賬戶。這邊并不需要B一定要實名，當然最后想拿到這筆錢還是必須要實名的。
4）A已綁定已實名，B已綁定，我們還需要調(diào)用風控系統(tǒng)查一下你們的賬戶是否都安全，是否存在異地登錄，不常用的設(shè)備登錄等等一系列的規(guī)則驗證（各家的風控介入時機和驗證規(guī)則都不一樣，這邊只做參考）。一旦發(fā)現(xiàn)異常，首先通知A，您的這筆轉(zhuǎn)賬有風險，再根據(jù)風險等級判斷轉(zhuǎn)賬操作是否還能夠繼續(xù)。
5）假設(shè)A和B都是正常的，主系統(tǒng)會返回收款方的支付賬戶信息，在通訊軟件內(nèi)就對應(yīng)轉(zhuǎn)賬頁面，A能夠看到B支付賬戶的頭像、用戶名、賬戶（隱位處理）等等信息，來確認一下這就是我要轉(zhuǎn)賬的賬戶。
6）然后A會輸入轉(zhuǎn)賬金額和備注，主系統(tǒng)收到信息，調(diào)用收銀臺SDK。
7）收銀臺給出A支付賬戶下綁定的支付渠道還有不同渠道的限額說明（一般就是零錢賬戶、理財賬戶、銀行卡賬戶），如果A發(fā)現(xiàn)這幾個支付渠道的錢都不夠用，也可以綁定新的銀行卡進行支付。這邊就屬于支付收銀臺SDK的范疇了，不做詳細描述。
8）此外，收銀臺也會調(diào)用風控系統(tǒng)，對限額和轉(zhuǎn)賬次數(shù)等做風控規(guī)則的校驗，有可能會需要用戶進行短信密碼校驗啊什么的。。。風控真的是時不時就要來一下~
9）收銀臺最后會把支付結(jié)果返回給主系統(tǒng)，用來更新訂單狀態(tài)，同時通知資金系統(tǒng)進行支付賬戶的扣款操作，再由清結(jié)算系統(tǒng)結(jié)算至B的收款賬戶。
10）結(jié)算到收款賬戶時，還會判斷B的收款賬戶是否已經(jīng)實名，如果已經(jīng)實名，那么沒問題，轉(zhuǎn)賬成功！如果還沒有實名，那么這筆錢會被凍結(jié)一段時間，需要B在這段時間內(nèi)完成實名，否則錢會被退回到A的扣款賬戶。
11）結(jié)算系統(tǒng)把轉(zhuǎn)賬結(jié)果告訴主系統(tǒng)，主系統(tǒng)更新了訂單狀態(tài)，再告訴通訊軟件，通訊軟件同時通知A和B。
上述就是目前我們在做轉(zhuǎn)賬時的處理邏輯，可能還比較粗糙，沒有太注重用戶體驗。尤其是在一款通訊軟件內(nèi)做的轉(zhuǎn)賬功能，必須注重體驗。但是，畢竟我們還是完成了轉(zhuǎn)賬功能的開發(fā)，原來支付平臺內(nèi)的這個轉(zhuǎn)賬流程的轉(zhuǎn)賬成功率也一直保持在99%以上，對于用戶體驗的提升，還是希望通過市場驗證來有針對性的做一下提升。
關(guān)于B賬戶的實名問題？
B想要拿到這筆錢，必須實名，但是什么時候進行實名，在很大程度上影響著雙方的用戶體驗，也關(guān)乎這我們一些運營同事的KPI。如果我們在A進行轉(zhuǎn)賬之前就要求B實名，那么B可能會這么想【好麻煩，錢還沒拿到呢，先要我綁定身份信息（初級實名），還要綁定銀行卡（高級實名），算了算了，支付寶吧~】那么，我們可能會失去2個用戶。
作為我們，必須要求A在轉(zhuǎn)賬之前就實名，確認A的身份，確認是本人在操作，我們才放心進行扣款和后面的轉(zhuǎn)賬。但是對于B，我們大可以在B收到這筆錢以后進行凍結(jié)，然后B可以通過實名來解凍這筆轉(zhuǎn)賬。這時候B可能會想【我賬戶上有筆錢被凍結(jié)了？不行不行，我得趕緊實名解凍！】這樣的話，既不影響A的轉(zhuǎn)賬體驗，也能提高B的實名動力同時完成KPI。
