全栈工程师?
嗯.....目前并不是!

如何模塊化設計出款系統(二)

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

一、出款應用層是做什麼的?

什麼是出款應用層?

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

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

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

前端入口一般包括三種:

乾貨!如何設計出款系統(二)

  1. 用戶前端:指面向用戶的APP、PC等。
  2. 商戶門戶:指支付系統提供給商戶使用的後台,商戶可在商戶後台發起出款交易,如商戶代付、商戶提現等。
  3. API:指支付系統給商戶提供的交易接口,商戶通過接口對接,直接發起交易。

我們一起來看看:這三種入口進來的出款交易,交互流程是怎麼樣的?

1. 用戶前端

面向用戶的出款交易主要包括:用戶提現、轉賬到他人賬戶餘額、轉賬到他人銀行卡。

下面以用戶提現為例,按交易發生的順序介紹下交互流程。

收單前:

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

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

事後:用戶查詢賬單:在賬單中可查看提現進度。

2. 商戶門戶

商戶門戶是專門面向商戶提供服務的後台,商戶可在後台發起商戶代付和商戶提現等。

以商戶批量代付為例,交互流程為:

收單前:

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

收單后:

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

但是,和個人用戶相比,商戶有入網審核流程。有問題的商戶,在審核環節一般已經被攔截了。

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

所以,相對用戶來說,商戶發起的交易,風險係數是比較低的。

事後:商戶門戶後台查詢交易結果和獲取對賬文件。

3. API

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

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

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

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

二、出款服務層是做什麼的?

出款應用層往下就是出款服務層,這個層級扮演什麼角色呢?

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

也就是說,出款服務層的作用是:接受前端的出款請求,並根據風控、運營的要求進行身份信息和業務權限檢查,校驗通過後再發往出款業務層;另一方面,交易事後需返回前端交易結果。

乾貨!如何設計出款系統(二)

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

收單:前端調用出款服務層的付款申請服務后,會對應生成一個request id,完成收單。這就好比是迎接來客這個環節。

業務權限校驗:

對於用戶,出於風控及合規要求,需調用用戶系統判斷用戶狀態是否正常,如果是凍結狀態,則不允許發起出款交易。

對於商戶,一方面會判斷商戶狀態;另一方面,會判斷業務開通狀態。

從運營的角度看:不同業務會收取不同的費用;從賬務角度看,不同業務對應不同的記賬規則。因此,需調用商戶系統,判斷商戶狀態,並校驗該商戶是否已開通對應的出款業務權限。在後續出款業務層的邏輯中,也需對不同業務類型記不同的手續費和記賬規則。

身份校驗:

出於風控要求,需對發起交易的用戶或商戶進行身份校驗。對於用戶,會調用風控系統進行黑名單檢查及風控規則運算。如果命中黑名單規則,則會直接拒絕交易;如果不在黑名單範圍,則再根據規則運算結果返回前端,需用戶輸入何種身份校驗方式,例如:指紋,或“指紋+短信驗證碼”組合驗證。

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

對於商戶,也是同理。

訂單結果對外輸出:

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

 

版权声明:本文采用知识共享 署名4.0国际许可协议 [BY-NC-SA] 进行授权
文章名称:《如何模塊化設計出款系統(二)》
文章链接:https://www.pmbear.com/%e5%a6%82%e4%bd%95%e6%a8%a1%e5%a1%8a%e5%8c%96%e8%a8%ad%e8%a8%88%e5%87%ba%e6%ac%be%e7%b3%bb%e7%b5%b1%ef%bc%88%e4%ba%8c%ef%bc%89/
本站资源仅供个人学习交流,请于下载后24小时内删除,不允许用于商业用途,否则法律问题自行承担。

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址

大前端WP主题 更专业 更方便

联系我们联系我们