支付行業中台搭建流程解析

一、行業分析

在搭建業務中台前，首先看一下是否有搭建中台的必要，分析一下支付行業整體的發展方向。

自從2004年支付寶作為第一家第三方支付公司出現至今，支付行業經歷了從藍海到紅海的。以前支付牌照是香餑餑，監管不嚴格，利用牌照特性賺錢非常的容易。

現在央行也被支付公司一次次的套路中，學會如何進行監管，近年來鉅額的罰單接連不斷。監管意味着支付市場的空間被擠壓，中小支付公司更是前有AT兩大巨頭，後有監管。面臨以上種種情況，支付公司目前做的選擇有一下幾種：

1. 深耕支付領域、切入行業

根據艾瑞數據《2020Q2第三方支付行業數據發佈報告》得知，支付行業依舊是支付寶財付通保持領先地位，但是在第二梯隊的情況在垂直的行業蓬勃發展。

例如：平安旗下壹錢包深耕在零售、金融、商旅行業，份額逆勢而上佔到了1.5%。

中小支付公司可以依據自身多年的經營特點，深入商户的支付場景，根據行業特點與商户共同搭建合規的支付系統，共同建立穩固的護城河。

同時還可以深入到平台上下游的廠商、經銷商、品牌商等各個環節，通過支付服務、賬户服務、供應鏈服務，並聯合物流服務平台、金融服務機構幫助企業疏通產業鏈的各個堵塞環節，幫助整個產業鏈實現效能提升，進而達到對交易量、交易效率的改善效果，成功促成交易。

2. 外包服務，轉型輸出支付平台

隨着近年來產業互聯網的推進，普通的產業會升級成數字化、在線化經營，這就伴隨着支付也必須進行線上支付。

這就給第三方支付公司對外輸出支付平台的機會，支付機構可以轉型成為系統服務商，對外輸出技術服務，可以收取相應的技術服務費用。例如可以為政府繳費平台、分銀聯支付平台搭建支付底層服務與完整支付的賬户體系。

根據艾瑞數據查詢的數據得知，目前第三方產業支付市場已經達到了百億級別，中小支付企業可以乘勢而上，加入產業支付升級的互聯網大軍中。

3. 市場下沉，聚焦聚合支付

在面對支付寶、微信兩座大山面前，挑戰是必輸無疑的選。

那麼唯有選擇進行合作。在移動支付還沒有盛行之前，各支付機構主流採用的都是快捷支付、網銀等支付方式。部分商户系統對接能力較差的，無法對接多個支付機構。

但是系統的支付穩定性又沒有保障，這時候就出現了四方支付機構。四方支付機構的特點就是一站式服務，解決商户對接困難問題，保證支付的成功率。對接四方的費率就會高一些。

以前只有沒有牌照的支付企業才做聚合支付項目，稱作是服務商，主要針對的是B端的商户。

但是中小的支付企業目前也是在搶佔聚合支付的市場，依靠自身擁有支付牌照，可以建立支付賬户體系，可以進行清算的特性，搭建一站式聚合支付服務，為商户提供一站式接入雲閃付、支付寶、微信支付、銀行APP等主流支付工具進行收款。

4. 出售牌照，金盆洗手

近期看到字節跳動、攜程、京東、拼多多系列的牌照收購事件，在被央行監管、支付寶、微信多種擠壓下，很多中小型的支付公司已經沒有變現盈利的能力了，只能夠尋找新的變現渠道，那就是出售牌照。

而同時呢，行業巨頭有支付牌照的需求，不希望在自己的場景內，把支付業務的主動權拱手，但卻無法再申請新的支付牌照，兩者的需求交互，產生了一門新的生意——牌照收購。

所以許多擁有牌照的中小企業，可以依附於行業巨頭的樹蔭下，或者直接出售牌照的所有權，直接金盆洗手，不幹支付行業了。

5. 行業分析結果

從目前來看，聚合支付市場以及行業支付領域都是比較飽和的市場，處於一片紅海，唯有外包服務服務，還是市場比較大 ，傳統的企業需要數字化轉型需要大量的外包業務服務。這就給支付公司的業務模式有很大的挑戰性。

一般支付公司的後端的邏輯是比較穩定的，為了契合業務方的需求，不斷的複製同一套代碼，做定製化的業務改造，有些相同的業務也是在重複搭建，維護的時候相當的複雜。

在底層有變更時，需要同步變更多個服務，還需要評估變更對這些業務的影響有多少，可能有的影響多，有的不受影響，這就給中台提供了機會。

二、業務框架梳理

按照業務線的形式，梳理了兩條的業務線的產品架構，具體內容如下：

1. 原業務邏輯説明

根據以上梳理的業務框架可以看出，兩條業務線之間重合部分比較多。這就導致了兩條業務線之間都分別重複搭建業務重合部分，這就造成了很多的資源的浪費。

除此之外並且會造成以下幾個問題點：

1. 後端邏輯有改動時，兩邊業務得同時更改。這就造成後端上線有部分無法兼容所有業務的內容，前端必須反過來兼容後端的業務邏輯。
2. 後台的業務系統日漸趨於成熟，改動點比較難，如果有業務線有新需求接入時，需要兼容的內容太多，會導致迭代的速度非常慢。
3. 商户數據未打通，各業務線容易形成數據孤島，無法聯合進行營銷、風控等。

2. 問題案例

以上圖框架中以雲閃付產品舉個例子，分別對應以上的問題點：

1. 例如銀聯雲閃付業務變更，此時後端的邏輯邏輯進行了變更，需要必傳參數增多，此時需要同時聚合支付業務線和快捷業務線都得相應的進行改造。
2. 聚合支付業務線向後台業務提了一個需求，希望後端更新雲閃付的紅包功能，但是這個業務功能並不是快捷業務線所需要的，此時後台就需要兼容快捷線做兼容考慮，可能會導致迭代的效率較慢。
3. 由於聚合支付業務線剛起步，希望針對雲閃付的商户做補貼。需要精準的找到補貼用户有些，這些用户在快捷業務線才有。此時聚合支付業務線只能依賴線下傳輸方式才能完成此時的補貼，用户數據不斷變化的，每次做營銷活動都得進行線下活動整合數據形式才能完成，並且數據並非是實時數據，還不能和自身業務進行相匹配。

以上的三個案例充分説明了，當有多條業務共用一個後台時，此時就會陷入多方同時維護同一個功能的地步，造成資源極大的損耗。同時會在公司內部不同業務線之間存在極大的信息孤島，不利於公司的後續發展。

三、中台業務梳理

通過上面的數據分析完成後，説明還是很有必要構建業務中台，在構建之前需要考慮清楚什麼業務的才能成中台業務，這些業務如何才能體現中台價值。搭建業務中台最終目的是為了節約成本，包括人力成本、資源成本、時間成本等。

即當公司需要發展多條業務線時，這幾個業務有高度重合部分時，可以快速的進行迭代，並且所使用的資源是最少，簡單來説就是做一個產品需要性價比高，或者ROI（投入產出比）高。

1. 功能在各業務線使用的頻次

在計算業務線使用的頻次之前，得先梳理系統的業務邏輯，需要具體到每個業務流程都使用了哪些功能。

以收銀為例梳理整個過程所用到的功能：

• 登錄商家賬號使用的模塊：商户管理（商家狀態校驗、商户信息查詢）；
• 選擇收款方式：商户管理（商户開通產品）；
• 掃碼用户二維碼：商户管理（商户信息查詢、商户狀態校驗）、賬務管理（賬户狀態）、路由管理（路由查詢可用支付渠道）、訂單管理（創建訂單、優惠信息計算）、通道管理（往上游上傳交易相關信息，獲取用户支付信息）；
• 用户確認支付：無（PS:用户端輸入支付密碼，屬於微信、支付寶、銀聯等客户端輸入支付密碼，與B端商家側系統無關，此處是為了流程更加暢通，方便閲讀）；
• 收款完成：商户管理（校驗商户信息）、訂單管理（更新訂單狀態）、賬務管理（計算手續費、計算分潤、生成賬務流水）、賬户管理（更新商户賬户餘額、更新手續費賬户餘額、更新代理商分潤賬户餘額）。

整理上述的功能模塊複用情況如下：

根據上圖可以得知，聚合支付業務線商户管理、訂單管理的複用次數最多，同時將其他行業線也一同梳理，最終將不同行業，相同功能模塊的模塊整理成一個表。

例如下圖展示：

以上表可以得出商户管理、訂單管理佔據在整體比重較大，可以優先抽取至業務中台，剩餘的模塊需要根據公司業務進行評估處理。

2. 公司戰略目標

在設計業務中台時，還需要和公司的整體戰略目標相一致，中台的威力才能完全體現。

因為中颱最大的作用就是複用能力，當公司業務重心在某一領域時，業務中台應該契合公司業務重心，才能發揮作用，不然又是陷入重複建設的陷阱。

公司想把所有的賬户進行打通，讓商户接入不同業務線時，資金可以在不同業務線之間共用，而每個業務都有賬户管理模塊，此時就可以將賬户管理模塊統一化，建立統一的賬户體系。當一個商户對接多條業務線，資金不需要重複的進行提現充值動作，可以直接在不同業務線之間劃轉。

四、新業務框架

根據業務梳理的情況，構建了新的業務框架，具體如下：

將前台相同模塊的業務進行抽取，簡化前端的業務邏輯，將大量的運算放置在中台，同時前端業務不直接對接到後端。

後端有變動時，只需要中台進行修改兼容就可以，而不需要每個業務線都進行相應的整改，並且將業務數據進行打通，便於前端進行推廣或冷啓動時提供更多的商户數據。

五、總結

關於業務中台是否需要搭建，主要還是根據公司業務情況而定，總結一下幾點：

1. 如果企業業務是橫向拓展，並且相互之間沒有太大的關聯性，同時公司戰略也不是同時多業務線並行開發的，這種搭建中台的必要性就不高。
2. 如果業務集中在某一個領取或者業務之間的功能重合度比較高，此時可以考慮先抽取重合部分抽取組成業務中台。
3. 搭建中台還需要關注行業動態，必須的捕捉行業的發展趨勢，因為中颱建立後，所有的前台的業務都對接中台，相關的業務承接方變成中台。得中台建立完成後，前台才能完成相關動作，所以中台尤為關鍵的就是捕捉行業的動態。不然跟不上發展趨勢，前台業務可能會另起爐灶，自己重新建立業務系統。

本文由 @TOM 原創發佈於人人都是產品經理，未經作者許可，禁止轉載。

題圖來自Unsplash，基於CC0協議。