上篇文章介紹了出款系統(tǒng)的設計思想和整體包括哪些模塊（回顧文章——《如何模塊化設計出款系統(tǒng)（一）》。今天，筆者將與大家講講最上層的出款應用層和出款服務層。

一、出款應用層是做什么的？

什么是出款應用層？

——出款應用層負責面向商戶或用戶，與商戶和用戶發(fā)生實際交互，是出款服務的最前端入口和出口。

我們按時間順序來看，前端和用戶/商戶的交互可分為交易事前（收單前）、交易事中（收單后）和交易事后:

• 事前是指用戶/商戶正在進行交易操作，但出款系統(tǒng)未收單，也就是說，信息流未流到出款服務層，還沒有生成request id。
• 事中是指用戶/商戶正在進行交易操作，且出款系統(tǒng)已收單，也就是說，已經(jīng)流到了出款服務層，已經(jīng)生成了request id。
• 事后是指用戶/商戶已完成所有操作，等待交易結果。

前端入口一般包括三種：

1. 用戶前端：指面向用戶的APP、PC等。
2. 商戶門戶：指支付系統(tǒng)提供給商戶使用的后臺，商戶可在商戶后臺發(fā)起出款交易，如商戶代付、商戶提現(xiàn)等。
3. API：指支付系統(tǒng)給商戶提供的交易接口，商戶通過接口對接，直接發(fā)起交易。

我們一起來看看：這三種入口進來的出款交易，交互流程是怎么樣的？

1. 用戶前端

面向用戶的出款交易主要包括：用戶提現(xiàn)、轉賬到他人賬戶余額、轉賬到他人銀行卡。

下面以用戶提現(xiàn)為例，按交易發(fā)生的順序介紹下交互流程。

收單前：

1. 用戶選擇提現(xiàn)，進入提現(xiàn)流程。
2. 用戶選擇提現(xiàn)到哪張銀行卡：為了簡化用戶的操作流程，前端可直接展示用戶的已綁卡列表讓用戶選擇。另一方面，合規(guī)要求只能提現(xiàn)到本人儲蓄卡，因此，可選擇的已綁銀行卡列表需限制卡類型為儲蓄卡。如果用戶沒有已綁定的儲蓄卡，再引導用戶綁定儲蓄卡。
3. 用戶輸入提現(xiàn)金額：提現(xiàn)金額不能大于賬戶可用余額。因此前端需提前告知用戶當前賬戶余額是多少，當用戶輸入的提現(xiàn)金額超過可用余額，則做相應的提示。
4. 用戶確認提現(xiàn)，出款服務層收單。

收單后：用戶輸入支付密碼/指紋/短信驗證碼等身份校驗信息。使用何種強度的驗證方式根據(jù)風控規(guī)則運算得出的用戶風險等級決定，風險越高，驗證強度越高。

事后：用戶查詢賬單：在賬單中可查看提現(xiàn)進度。

2. 商戶門戶

商戶門戶是專門面向商戶提供服務的后臺，商戶可在后臺發(fā)起商戶代付和商戶提現(xiàn)等。

以商戶批量代付為例，交互流程為：

收單前：

1. 商戶進入商戶后臺，選擇發(fā)起批量代付。
2. 商戶以文件形式上傳批量代付信息，包括賬號、戶名、金額等。
3. 商戶管理員審核交易，出款服務層收單。

收單后：

商戶輸入支付密碼等身份校驗信息，身份校驗方式也是由風控運營同學的規(guī)則決定，目的是對發(fā)起交易方身份進行校驗。

但是，和個人用戶相比，商戶有入網(wǎng)審核流程。有問題的商戶，在審核環(huán)節(jié)一般已經(jīng)被攔截了。

另外，商戶在登陸商戶后臺時，會區(qū)分操作員角色（擁有不同操作權限），且需要證書、登陸密碼等身份校驗后，才能登陸。

所以，相對用戶來說，商戶發(fā)起的交易，風險系數(shù)是比較低的。

事后：商戶門戶后臺查詢交易結果和獲取對賬文件。

3. API

API是指面向商戶提供的接口服務，一般包括以下服務：

• 出款申請
• 出款結果查詢
• 出款結果異步通知
• 對賬文件獲取/推送

接口服務不涉及到前端操作界面交互，但是接口交互時會有技術層面的權限校驗，如商戶秘鑰驗證。校驗通過后，出款服務層收單，進行業(yè)務權限校驗，校驗通過后就可處理后面的出款流程。

有出款結果后，出款服務層會通過API方式回調通知給商戶，商戶也可調用查詢接口主動查詢出款進度。

二、出款服務層是做什么的？

出款應用層往下就是出款服務層，這個層級扮演什么角色呢？

打個比方：出款應用層就好比是面向有需求的訪客打開的門口；而出款服務層就像是負責接待訪客的管家，迎接來客，并對來客的身份進行檢查，沒問題后再領進屋子里。事后，管家還得向訪客反饋處理結果。

也就是說，出款服務層的作用是：接受前端的出款請求，并根據(jù)風控、運營的要求進行身份信息和業(yè)務權限檢查，校驗通過后再發(fā)往出款業(yè)務層；另一方面，交易事后需返回前端交易結果。

出款服務層的主要職責包括：

收單：前端調用出款服務層的付款申請服務后，會對應生成一個request id，完成收單。這就好比是迎接來客這個環(huán)節(jié)。

業(yè)務權限校驗：

對于用戶，出于風控及合規(guī)要求，需調用用戶系統(tǒng)判斷用戶狀態(tài)是否正常，如果是凍結狀態(tài)，則不允許發(fā)起出款交易。

對于商戶，一方面會判斷商戶狀態(tài)；另一方面，會判斷業(yè)務開通狀態(tài)。

從運營的角度看：不同業(yè)務會收取不同的費用；從賬務角度看，不同業(yè)務對應不同的記賬規(guī)則。因此，需調用商戶系統(tǒng)，判斷商戶狀態(tài)，并校驗該商戶是否已開通對應的出款業(yè)務權限。在后續(xù)出款業(yè)務層的邏輯中，也需對不同業(yè)務類型記不同的手續(xù)費和記賬規(guī)則。

身份校驗：

出于風控要求，需對發(fā)起交易的用戶或商戶進行身份校驗。對于用戶，會調用風控系統(tǒng)進行黑名單檢查及風控規(guī)則運算。如果命中黑名單規(guī)則，則會直接拒絕交易；如果不在黑名單范圍，則再根據(jù)規(guī)則運算結果返回前端，需用戶輸入何種身份校驗方式，例如：指紋，或“指紋+短信驗證碼”組合驗證。

用戶輸入后，調用底層鑒權服務，進行指紋/支付密碼/短信驗證碼等校驗。

對于商戶，也是同理。

訂單結果對外輸出：

用戶或商戶發(fā)起交易后還需要隨時了解交易進度，因此出款服務層還承擔對外輸出訂單結果的作用。面向用戶，提供訂單結果查詢服務；面向商戶，提供訂單結果查詢和回調通知服務，以及對賬文件獲取/推送服務。

本文由 @Rebecca 原創(chuàng)發(fā)布于人人都是產品經(jīng)理。未經(jīng)許可，禁止轉載

題圖來自Unsplash，基于CC0協(xié)議