如何搭建支付中臺系統?

產品老司機手把手教寫文檔,10天線上課程,零基礎掌握產品經理必備7大文檔撰寫法。了解一下>

中臺的概念在2018年下半年到2019年突然一下子在互聯網圈火起來了,在招聘網站上隨便一搜都是中臺產品經理,那么什么是中臺呢?中臺能解決什么問題,如何去搭建適合公司的中臺系統?支付中臺如何落地?

什么是中臺

中臺其實最早是起源于軍事領域,在二戰時期的美軍在各個戰場上,看起來有打不完的彈藥、耗不完的燃料、充足的食品補給、及時準確的情報……但其資源卻在萬里之遙的美國本土,這一切是如何做到的呢?

就是依靠龐大的中臺體系,支持到世界各戰場。前方戰場上的一名士兵,平均就有12名人員支持,在戰場-基地-本土形成前、中、后臺的效率系統。

國內互聯網最早實行中臺戰略的就是阿里。

由于阿里涉及的業務線非常多,在沒有中臺之前都是每個業務自己去做一套系統,但是每個業務系統都有相同的模塊,例如訂單系統、支付系統、商戶系統、短信系統等。因此就導致各個業務線重復造輪子的現象,業務端不僅需要對業務模塊進行優化和升級,同時也需要維護這些基礎支撐服務。

用一句話概括:中臺就是將所有業務的公共模塊抽象出來,單獨創建一個中臺系統統一對這些公共模塊進行維護,統一輸出服務提供業務方使用,讓業務方能夠集中全力發展業務。

中臺解決什么問題

理解了中臺的概念,那么就需要思考對于互聯網公司,中臺系統的搭建能夠解決什么問題呢?

可以解決你的996問題

中臺是獨立于業務系統而又服務于業務系統的存在,業務系統的前臺和后臺是關聯存在的,但是中臺的定位就是出于整個公司層面,要服務于多條業務線。

因此通過建設中臺系統,能夠極大減少業務系統的工作量,提高業務端的工作效率,業務系統部門就不需要再為了這些基礎服務而進行996了。

提高公司產品靈活性和市場競爭力

通過中臺系統,業務只需要關系業務流程即可,輕裝上陣,將重心配合市場方向去優化業務系統,對于市場上出現的新的業務模式和特殊需求能夠更快的響應,幫助公司快速占領市場。

節約成本,結構清晰

對于中臺最直觀的感受就是提高工作效率和減少人力成本,不僅僅減少業務開發部門,同時也減少商務部門、法務部門等相關職能部門,所有的外部基礎服務統一中臺管理,對于整個產品架構的梳理會更加清晰,在產品設計方面也會更加快速,部門分工也更加合理。

支付中臺如何落地

支付中臺,首先咱們應該最關心的是中臺這個關鍵詞,因為實際每個業務都已經有支付能力了,但是由于每個業務對于支付的單獨開發,導致資源的浪費,讓業務將過多的精力用在基礎支撐服務的維護和開發上,而無法集中精力去針對市場優化業務,不利于業務的沉淀和持續發展。

我認為當企業的業務線數量大,企業的主要業務線穩定情況下應該需要建立中臺系統。

而建立企業的中臺系統則需要首先調研企業的每個業務的場景和特點,然后對每個業務進行拆解,得到每個業務的組成模塊,再分析出每個業務組成模塊的一個合集,這樣就能確定中臺系統的定位和構成。

業務拆分思路

  1. 在設計之初需要確定業務,該業務的核心場景;
  2. 從核心場景往外剝離,確定哪些是基礎服務;
  3. 確定基礎服務與業務的系統分界;
  4. 確定好每個基礎服務的分界后,需要對基礎服務進行建模,以保證整個中臺體系的兼容性和擴展性。

支付中臺建模思路

  • 基于業務,拆分為面向支付業務和面向資金核算兩套體系。
  • 基于場景,例如依據支付流程等進行拆分。
  • 基于技術實現,例如出于對系統的性能等考慮拆分。

支付中臺整體架構

通過上圖,可以看出支付系統可以拆分為:收銀臺、交易核心、支付核心、渠道網關、賬務系統、會計系統、清算系統、合規系統等。

  • 收銀臺:主要應用于業務的提交結算場景,可以根據不同的業務配置不同的收銀臺模板。
  • 交易核心:業務發起支付時,支付系統與業務方的前置模塊,主要用于對業務的校驗、接單、查詢請求等處理。
  • 支付核心:對于業務發起的交易進行支付處理,生成支付訂單,可以根據不同的交易類型匹配不同的支付工具,支付核心根據渠道返回的支付結果,請求賬務系統、清結算系統、數據中心、交易系統等邏輯處理。
  • 渠道網關:主要是對接渠道,處理渠道報文,渠道接口請求,支付路由處理等。
  • 賬務系統:支付系統的賬務處理中心,賬務的凍結、解凍、出金、入金,根據不同的交易類型對賬戶進行記賬,并將賬務流水通知到會計系統,會計系統進行復式記賬。
  • 會計系統:會計系統可以作為公司的業財中臺,主要是根據賬務系統流水將業務數據轉化為財務數據,如果公司有用友、金蝶等財務系統,可以將生成的會計分類同步到財務系統中。
  • 清算系統:針對不同的業務類型,進行清分結算。
  • 合規系統:對接反洗錢系統、反詐騙系統,保證支付安全合規。

支付鏈路

由業務方發起交易,通過收銀臺或者API發起,進入到交易系統,交易系統請求支付系統,支付系統接收到支付請求向渠道網關發起,渠道網關請求銀行或支付公司;支付系統接收到結果后異步通知數據中心、清結算系統和合規系統。

異常處理機制

1)如何保證數據統一性?

支付系統最重要的就是數據的統一性,因為涉及到真實的資金情況,因此對于訂單統一性的要求是最高的,否則會導致資損的情況產生。

我們可以針對每個業務設置一個業務代碼,通過業務代碼+訂單號的方式,在每筆訂單生成一個業務跟蹤號。通過這個業務跟蹤號能夠將交易訂單、支付訂單、渠道訂單、資金流水進行關聯和約束,防止訂單數據差異以及對整個訂單生命周期的追溯。

每個系統的訂單可以定義規則,例如:日期+系統代碼+序號。

2)如何保證業務支付的穩定性和擴展性?

首先需要深入了解每個業務對于基礎服務的應用場景,根據業務的應用場景包裝出不同的交易產品(交易類型、例如充值場景、提現場景、擔保場景等)。在支付核心系統中,通過支付能力的組合形成支付工具,根據支付工具在組合成不同的交易產品,例如通過鑒權+代扣的支付能力,可以組合成支付工具快捷支付,快捷支付可以與交易場景的充值對應。這樣就能實現插件化開發,能夠根據業務的需要完成不同的組合場景,提供支付系統的擴展性。

3)如何處理部分支付的異常流程?

例如用戶的組合支付(紅包、優惠券、支付寶支付)紅包和優惠券扣款成功、支付寶支付失敗,我們建立了一個異常管理組件,這種組合支付都需要報送到異常管理組件,通過異常處理組件的規則,對該異常情況發起反向退款流程。異常處理組件會向支付系統發起紅包退款、優惠券退款,保證整體訂單的狀態一致性。

4)代付拆單,部分成功的情況

對于代付交易,如果拆單后,出現2筆子單成功,1筆子單失敗,出現這種異常會將該異常子單發送到異常處理組件,異常處理組件發送到調度中心,可以重發;如果無法重發,可以人工支付后更新狀態。

 

本文由 @極光 原創發布于人人都是產品經理。未經許可,禁止轉載

題圖來自 Unsplash,基于 CC0 協議4

給作者打賞,鼓勵TA抓緊創作!
評論
歡迎留言討論~!
  1. 給支付中臺提供了一個明確的定義,公共模塊抽象出來 ,提供各個業務以支持,不同重復造輪子, 后面會是如何做的問題了。 1.如何研發公共模塊 2.各個前臺系統如何調用 3.中臺系統如何整合數據

    回復
  2. 一直沒理解,為什么交易系統在收銀臺之后而不是在收銀臺之前

    回復
  3. 點贊

    回復
福彩开奖直播去哪看