編輯導語:隨着互聯網的不斷髮展,數字化進程也在不斷的進步,各行業都在不停的向數字化轉型,搭建互聯網平台以及新的渠道;比如一些企業會向電商平台發展,在電商平台繼續交易類內容;本文作者分享了關於企業數字化轉型需要的支付結算產品,我們一起來看一下。
2020年的疫情,加速了很多企業的數字化轉型步伐,企業基於各自戰略目標紛紛投入到傳統渠道升級,新零售轉型,電商平台搭建,社區團購及依託於社交網絡的分銷體系建設中,這裏需要搭建1套合適的支付結算產品來支撐企業面向交易和財務的數字化共享。
一、支付結算平台做啥,場景來説話企業除了入駐天貓,京東等三方渠道觸達用户,一般都會自己自建渠道,這條線上角色主要由大的經銷商(渠道分銷),小的零售店(渠道零售)和終端客户;基於各自之間的交易關係,企業往往搭建了對應的交易入口,實現商家(包括自己自營)的收款,付款和財務出入賬。
我們可以從2個維度來定義這些場景,1個是交易維度, 關心的是交易雙方之間怎麼交易(支付結算,利益分配);1個是資金維度,關心的是怎麼收款,付款,和財務做賬(需要符合各種監管)。
基於這2個核心場景,結算平台依託於外部金融資源,實現資金的監管和流通,面向交易提供支付收銀(聚焦C端收款),企業支付(聚焦B端收付),清分結算(聚焦面向交易的分賬)和賬户服務(搭建賬户體系,支持支付結算)。
特別強調:平台搭建必須和各方明確邊界,不然平台搭建過程中由於強依賴於業務或者什麼都做,導致中心定位模糊,能力不穩定,無法標準化,這塊會在後續中心化設計中重點説明。
二、商家收付款場景1)商家線上收款
基於交易對象不同,我們區分2C支付和2B支付,基於交易訂單是否和支付訂單掛鈎,我們區分線上支付和線下支付(線下支付往往需要做資金和訂單的匹配核銷)。
線上收款2C:
商家面向C端用户做線上收款,統一由結算平台的支付收銀模塊提供收款服務,提供的方式主要由2種:收銀台方式和聚合支付API,核心都是1次對接,獲取N種線上支付方式。
特別強調1:門店零售收銀,需要基於收銀是否是基於訂單還是直接收款來區分是線上支付還是線下支付,從收單能力上都是B2C掃碼支付。
特別強調2:數字人名幣已經上線,作為點對點支付渠道還需要不斷優化,當前屬於小白鼠試驗節點,比較適合純收款場景,還不支持基於智能合約的清分做資金分賬。
這裏需要結算平台統一對接外部金融資源獲取支付渠道,並基於支付渠道提供支付方式,核心就是提供支付路由的能力;平台搭建初期,建議從手動路由開始做,有了多渠道,多場景和匹配策略後,逐漸迭代路由模型。
線上收款2B:
B端收款大額為主,支付機構不能做代收代付,無法像C端一樣封裝成快捷支付做線上收單,線上支付還是以企業網銀,銀企直連轉賬等方式實現,統一由結算平台企業支付模塊提供收款服務。
特別注意1:很多企業針對傳統渠道都會有自己的授信體系,政策返利體系,品牌溢價能力高的都需要先款後貨,針對這些企業,搭建統一的企業錢包,通過搭建統一的信用賬户,返利賬户和預付款賬户(預付款賬户往往需要和已有ERP系統對接,或者通過銀行賬户體系解耦ERP)來實現支付結算。
特別注意2:很多企業和外部金融機構合作,建立了以核心企業為交易閉環的供應鏈金融產品,典型的有訂單貸,倉單融資,應收賬款融資等,都可以作為統一的支付方式融入到在線支付當中。
2)商家線下收款
線下收款2C:
前面我們把所有脱離交易訂單的收款定義為線下收款,面向C端用户的線下收款形式主要由商家主動掃碼和用户主動掃碼2種方式,包括已經越來越少見的付現金,和看起來很時髦的數字人名幣支付。
線下收款2B:
基於金融監管和企業出款財務管理需要,當前2B交易絕大部分還是以線下支付為主,但企業收款必須票款一致,所以核心是怎麼讓交易訂單和資金一致,做到資金流,信息流一致(物流先站一邊),有些企業還要考慮和合同的一致性。
特別備註1:大額轉賬的叫法來源於網商銀行,人家網商銀行把線上下單,按單生成唯一的收款賬户,然後線下統一打款給這個賬户的方式叫大額轉賬,可以很好的解決交易訂單和資金的匹配,問題是每次下單都是新的賬號,有點雷人。
特別備註2:很多B端交易是按週期結算,針對這類場景,可以給固定的一些交易企業建專户,專户可以基於某個具體的交易場景;比如AA採購户,CC採購户,按打款到賬户後,做週期自動歸集結算(財務最厭煩,不信任業務手動做訂單核銷)。
特別備註3:當然如果你足夠強大,可以對接N多銀企直聯,就可以直接把業務訂單推送到企業網銀,支付關聯。
3)企業付款場景
純付款:
搭建支付結算平台核心是為了賦能業務系統,很多企業搭建了銀企直連,沒有搭建的基本也開通了企業網銀;面向純付款業務,如果沒有必要,建議不走支付結算平台,資金的事要專門的資金系統負責,特別是很多資金系統還要和企業內部的費用預算體系聯動。
以銷定採付款場景:
很多企業做面向行業的B2B交易平台,會選擇先做自營(但不是先採購後銷售的重模式),會統一和上游企業簽訂採購合作,由企業自己面向買家做銷售,信息流上基於銷售單生成對應的採購單,由供應商直接發貨給買家,企業收買家的錢再給供應商結算,賺中間差價。
特別備註:為了解耦業務做手工訂單核銷,特別是企業沒有統一的訂單中心時,往往會要求結算平台做供應商付款的校驗,校驗邏輯包括2個維度:
- 採購單是否有匹配的銷售單,也就是訂單是否能付錢;
- 基於原來銷售單或總銷售金額做可付金額的校驗。
整體上建議這塊可以做成獨立的訂單核銷模塊,而不是放到結算平台來做,核銷完成後,再給到結算平台調用外部資源渠道做結算劃分。
4)交易分賬場景
不管是2B還是2C場景,在整個交易過程中,為了促成交易閉環,除了買方和賣方,多多少少都會存在其它服務方參與活動獲取服務分潤。
幾個典型的場景:平台引入分銷機制,做社會化分銷,所有通過分銷鏈接成功交易的訂單都需要按一定規則按單獲取分銷佣金;平台提供了交易場所和服務,需要獲取交易佣金;物流提供了物流服務,需要獲得物流費用;支付渠道提供了支付服務,需要獲得渠道額用等等。
當前不管怎麼分賬,資金流上都要是誰提供服務,錢先到誰(誰開發票),再按訂單清分,並基於不同業務規則做結算,可以是一次性結算,也可以做多次結算。
特別備註1:在沒有統一的清結算規則配置能力前,把所有的分賬規則都放到具體業務系統吧,這邊邊界就很清晰,結算平台就是基於業務系統指令做清結算劃分,生成結算單(理論上按單分賬分賬金額不能超過訂單金額)。
特別備註2:做好內部對賬,從支付開始,到各個節點清結算,再到賬户落賬生成賬務流水,都需要有內部對賬,確保內部體系的穩定和正確。
5)財務出入賬
企業交易過程中,所有涉及到收款,付款都需要在財務層面做賬(一般通過ERP做財務賬),而財務做賬不管是記收入,還是出款,都需要有對應的發票,資金流水,業務訂單,包括合同合一才能做賬。這裏的核心是明確2個點:
- 結算平台賬户的定位,你是做面向交易的業務賬(賬户無科目屬性,單式記賬),還是財務賬(有科目屬性,複式記賬),正常情況企業都會有自己的ERP和分錄系統做財務賬;
- 基於整個交易場景,明確哪些場景會涉及到真實資金的變動,有變動,就得有基於場景在分錄系統做分錄模板,按業務需要以固定週期或實時進行拋賬。
針對企業經營多元化,不同的業務獨立發展,需要有針對不同業務的支付結算管理,運營後台孕育而生。
1)渠道管理,支付方式管理
針對支付場景,前面已經明確了2種輸出的方式,收銀台和聚合支付API ,這塊的運營主要就是針對不同業務應用做支付渠道,支付方式或收銀台的配置。
2)看板,報表,對賬
運營後台除了提供支付維度的配置外,還會支持看板,實現按日,月等時間週期展示運營層面的一些統計數據,包括但不限於:支付申請的訂單量,支持成功的筆數,支付成功的金額,開户數等。
報表更多是統計一些明細維度的數據,也可以按賬户和清結算來做大類區分,特別要注意的是一些跨多箇中心維度的數據報表,如果企業有專門的數據中心,可以由數據中心來做統一輸出;對賬,核心對的是和外部金融資源的對賬,包括各支付渠道,賬户金額,賬務流水等,涉及賬單的獲取,軋賬和對差異數據的憑證(本文就不對具體細節進行説明)。
四、支付結算的中心化設計1)能力邊界,中心建設
任何產品脱離了邊界,就是無序,定位不清楚,所以在瞭解了企業的整體支付結算需求後,我們需要在業務層面去框定邊界,以實現邊界範圍內服務的穩定,才能為後面的服務做沉澱和標準化的輸出。
整體邊界上這裏按業務系統,支付,結算,賬户,財務和三方外部資源來劃分的,然後定義好各自的邊界,核心對象,這裏強調1點必須拿幾個實際的交易場景,把流程跑通。
整個結算平台可以分為支付中心,結算中心和賬户中心:
支付中心:基於業務訂單發起收單支付,調用支付渠道,完成支付。
輸入:業務訂單(訂單金額等信息);輸出:支付結果;核心對象:支付訂單
結算中心:基於業務訂單明確的分賬信息,做清結算劃賬,並依託於銀行等外部渠道實現資金的清結算。
輸入:清結算指令(業務訂單,分賬對象和金額);輸出:清結算結果;核心對象:結算單
賬户中心:業務交易過程中,以賬户為載體,記錄現金或現金等價物變動情況及結果(虛擬賬户)
輸出結果:賬户餘額,交易流水;核心對象:賬户。
2)基礎能力+標準服務接入/輸出
支付結算平台作為通用服務中心,核心就是為了賦能企業的不同交易業務場景,做到服務能力的複用,外部資源的快捷對接,交易數據的完整性,是靈活多變的。
作為中心化的能力又應該是基本固定的,穩定的,不會因為幾個場景的對接就做變動,所以在平台搭建的過程中需要考慮服務的分層,核心能力層沉掉支付,結算和賬户的核心能力,之上基於這些核心能力,可以封裝成可標準的服務來統一對接業務系統和外部金融資源。
特別備註1:建議把高複用的,邊界範圍內的服務作為標準服務輸出,後續這些服務就是標準的接口,業務系統統一對接即可,個性化,又不在邊界範圍內的,儘量不接,或以獨立的微服務來承接,而不是直接落到平台上;
特別備註2:理想狀態,外部金融資源也應該是標準化接入,實在有特殊性的做適配層兼容。
五、總結企業的數字化轉型,也是基於企業的戰略目標,把所有可管理的內容逐漸落到數字層面執行,支付結算產品的搭建也不是一撮而就,需要不斷的迭代完善。
不同企業的業務場景不同,資源能力不同,不是越複雜完整的產品就適合自己,還是需要從自身的轉型階段來看,需要發展什麼業務,搭建什麼樣的支付結算產品。
以上內容基於自身企業數字化零售轉賬經歷,內容上主要以整體拉通為主,希望可以給廣大讀者待來幫助,後續會不斷補充具體落地的一些內容,非常感謝。
本文由 @哈哈的鯨魚 原創發佈於人人都是產品經理。未經許可,禁止轉載。
題圖來自Unsplash,基於 CC0 協議