編輯導語：在數(shù)字化時代，企業(yè)是如何進行支付交易？這篇文章從四個方面，詳細闡述了企業(yè)數(shù)字化建設的支付結算產(chǎn)品設計，推薦想要了解數(shù)字化支付結算產(chǎn)品的童鞋閱讀。

之前寫的聊聊企業(yè)數(shù)字化轉型需要建的支付結算產(chǎn)品整體上比較細節(jié)瑣碎，2021年又參與了幾個企業(yè)數(shù)字化轉型項目，并專注于支付結算領域參與了從售前，業(yè)務方案，產(chǎn)品設計開發(fā)到交付運營落地的完整產(chǎn)品周期，在此做個支付結算產(chǎn)品（方案）設計方法的簡單分享（很多東西點到為止哦）。

從產(chǎn)品角度講，支付結算產(chǎn)品核心是解決用戶（企業(yè)/個人，本篇用戶非特別說明，默認為企業(yè)客戶）交易環(huán)節(jié)收付錢的問題，所以你需要了解業(yè)務場景（企業(yè)的業(yè)務模式：有哪些參與方，怎么交易，怎么賺取利潤到怎么做賬），并提供合適的支付結算業(yè)務方案（針對企業(yè)的業(yè)務戰(zhàn)略，切入哪些交易場景，需要哪些業(yè)務模塊，設計匹配的業(yè)務架構），支付結算的資源有哪些（中心化的處理思路，決定了支付結算必須依賴于絕對的資源（比如國內(nèi)資金的清結算規(guī)則），了解這些資源的運行規(guī)則，怎么對接和運營）。

從企業(yè)數(shù)字化角度看，支付結算貫穿交易，財務管理，是企業(yè)交易業(yè)務在線，資源在線，財務在線，資金管理在線的路由器。

一、支付結算概念

術語有專攻，了解專業(yè)術語是提供專業(yè)解決方案/產(chǎn)品的基礎。

1.1術語說明

支付：字面意思就是付錢，基于交易，至少需要買方和賣方2個對象，買方消耗自己擁有的資產(chǎn)，權益或債務（理論上只要賣方認可，一切皆可支付，本質上我理解為是信用憑證），實現(xiàn)交易支付；

清分：一筆交易，可能有多方參與，記錄各方基于這筆交易的應收應付（比如：國內(nèi)金融體系支付結算獨立，需要先清分記賬，再做實際的資金結算）；

結算：交易維度做實際資金結算理解，財務上做債權關系轉移理解；

對賬：賬證實的額對，本質上說是為了確保同一個事務的數(shù)據(jù)描述在不同業(yè)務或系統(tǒng)下記錄一致而進行的相互之間的一致性比對（對比的對象可以是單據(jù)或賬戶，對比的維度可以是明細，總數(shù)或計算后的統(tǒng)計數(shù)據(jù)）；

交易賬：交易維度生成的每一條交易賬務（單式記賬），基于交易賬務生成賬簿；

財務賬：財務維度生成的每一條會計賬務（明確借貸關系做模式記賬），基于會計賬務生成賬簿；

渠道和路由：支付結算需要有處理來源，誰提供處理誰就是渠道，路由基于規(guī)則（靜態(tài)或動態(tài)規(guī)則）明確走哪條渠道實現(xiàn)支付結算。

1.2 產(chǎn)品戰(zhàn)略和戰(zhàn)術

不要用勤奮的產(chǎn)品戰(zhàn)術（埋頭于流程和功能）來掩蓋戰(zhàn)略上的偷懶。

企業(yè)只有通過交易才能賺取利潤，做可持續(xù)的發(fā)展，支付結算產(chǎn)品也需要有戰(zhàn)略規(guī)劃和戰(zhàn)術落地，才能不斷產(chǎn)生客戶價值，做可持續(xù)運營。

企業(yè)戰(zhàn)略：了解企業(yè)戰(zhàn)略（企業(yè)數(shù)字化轉型已經(jīng)作為很多企業(yè)的基礎戰(zhàn)略，以更好的支持業(yè)務戰(zhàn)略），包括業(yè)務模式的演變，核心是規(guī)劃支付結算產(chǎn)品可持續(xù)匹配企業(yè)戰(zhàn)略。

企業(yè)戰(zhàn)術：了解當前交易模式，核心業(yè)務，核心客戶，階段業(yè)務目標，后面的業(yè)務規(guī)劃和核心服務對象，核心是便于切入具體的交易場景，提供支付結算產(chǎn)品支持現(xiàn)有交易的在線化，來打造通用的支付結算服務，完成支付結算產(chǎn)品的服務運營。

了解完企業(yè)戰(zhàn)略和戰(zhàn)術后，支付結算產(chǎn)品的規(guī)劃一般由：從產(chǎn)品定位上就是支撐企業(yè)完成交易收錢和付錢的閉環(huán)（業(yè)務交易閉環(huán)，財務管理閉環(huán)，此為支撐業(yè)務閉環(huán)）；再往后看就是有效并靈活的支撐交易在線（滿足企業(yè)服務可以靈活的觸達B端和C端用戶，此為產(chǎn)品賦能業(yè)務）；最后就是數(shù)據(jù)賦能，交易通過標準的支付結算不斷產(chǎn)生有效的數(shù)據(jù)賦能業(yè)務（不管是交易，金融維度的客戶畫像；還是業(yè)財一體化，自動化）。重點：規(guī)劃歸規(guī)劃，實際要以企業(yè)數(shù)字化程度和轉型的重點來設計。

二、業(yè)務場景

行業(yè)不同，企業(yè)的業(yè)務模式不同，但抽象的看，無非交易對象（服務方提供服務，消費方獲取服務），產(chǎn)品交易（交易后履約，實體產(chǎn)品有物流，虛擬產(chǎn)品一般為單純的服務），交易結算賺取利潤，做企業(yè)賬。

有了業(yè)務抽象能力，就可以分析業(yè)務，站在用戶的角度，輸出產(chǎn)品方案。

1.1業(yè)務場景分析

從業(yè)務模式的角度看，其實就是業(yè)務參與方的利益分配，我習慣用交易對象的角度來鎖定業(yè)務，分為雙方交易和多方交易（雙方交易的多個組合），雙方交易好理解：就是交易的生命周期中只有買方和賣方2方參與并完成（比如街道上擺菜攤的大媽，我付現(xiàn)金買菜）。

多方交易理解為：交易的生命周期中有多方參與，形成了多個“雙方交易”（比如我在餓了嗎選擇盒馬生鮮使用支付寶下單買菜，蜂鳥配送一個場景，會產(chǎn)生：我和盒馬，盒馬和餓了嗎（假設蜂鳥屬于餓了嗎，交易抽傭和配送費），我和餓了嗎，盒馬和支付寶渠道手續(xù)費（假設支付寶按單直接扣商家收單手續(xù)費）至少個雙方交易。

明確交易對象，可以更好的理解涉完成一個交易場景，涉及多少交易業(yè)務，理解基于交易怎么做支付，清結算，發(fā)票和稅要怎么走。下圖是典型的BBC平臺交易。

1.2 交易模式

任何交易，萬變不離其中就是3種交易模式：一手交錢一手交貨；先款后貨；先貨后款，本質就是信用的不同處理方式。而實際的交易中，可能因為多方交易，在一個業(yè)務場景中，出現(xiàn)多個交易模式并存的情況（比如供應鏈中很多都是以銷定采，企業(yè)和供應商定采購協(xié)議，由企業(yè)面向客戶銷售，但商品由采購商直接發(fā)貨，客戶向企業(yè)支付并同時觸發(fā)企業(yè)向供應商支付，支付方式以上3種都可能存在）。

一手交錢一手交貨：可以說是實物紙幣時代下來的主流交易支付方式，適合在信用體系下交易，不管是現(xiàn)金還是后面發(fā)展的銀企直聯(lián)或企業(yè)網(wǎng)銀支付，都效率有限。

先貨后款：適合在信用體系健全的市場交易，對公端典型的有企業(yè)內(nèi)部的賒銷授信，對私端典型的有個人銀行信用卡，支付寶花唄，京東白條等，交易閉環(huán)后需要使用的信用額度作為債務需要做還款。

先款后貨：對公端適用于有品牌議價權的企業(yè)，下游分銷渠道需要先打款預付，再使用預付款采購，對私端適用于會員充值，預付卡等業(yè)務。

從商業(yè)模式上看，很明顯先款后貨最優(yōu)，但涉及到先款資金監(jiān)管的問題，特別是提供面向C端會員的預付充值。

1.3 交易憑證

基于交易對象，交易模式，只有產(chǎn)生交易過程中不同維度的交易憑證做記錄，才可支撐交易的合規(guī)，有效和可追溯，一般包括：業(yè)務交易憑證（鎖定交易對象和職責，形成訂單或合同明細）；物流憑證（實物交易履約憑證）；發(fā)票流：買方收票，賣方開票；稅務流：交易中產(chǎn)生的各種稅務憑證。

正常有效的交易一般是信息流，物流，資金流，發(fā)票流和稅務流一致（1:1和N：N關系都有）。

三、領域設計

業(yè)務需要邊界，產(chǎn)品和開發(fā)設計都需要邊界，這是我理解的領域概念，作為支付結算產(chǎn)品，就應該做好支付結算領域內(nèi)的事，什么都做就等于什么都沒做，好的領域設計要確保獨立性和可擴展。

我把領域設計分成2個維度，橫向的業(yè)務領域，通過定義不同的業(yè)務對象做區(qū)分；縱向的架構領域，通過分層來解耦業(yè)務對象處理問題的復雜性（業(yè)務驅動領域設計，so不是業(yè)務領域，分層設計越多越好，比如只通過微信小程序試點自營商城業(yè)務，為了快速驗證業(yè)務，只需要能做微信小程序支付足以）。

1.1領域業(yè)務邊界

經(jīng)歷過幾個大型項目業(yè)務中臺和數(shù)據(jù)中臺設計，理論上以1個業(yè)務對象完成自身業(yè)務閉環(huán)的邊界都可以設計成獨立的領域（行業(yè)內(nèi)更喜歡叫中心，然后多個中心形成1個大的領域：比如交易領域下面一般會有訂單中心（核心業(yè)務對象為業(yè)務訂單），支付中心（核心業(yè)務對象為支付訂單）等）。

當了解了企業(yè)客戶的整體業(yè)務和后面的戰(zhàn)略規(guī)劃后，就可以規(guī)劃需要做哪些業(yè)務領域的設計來支撐當前業(yè)務，又滿足后面的可擴展（需要平衡效率和成本，分的越細，技術上分布式事物的一致性設計越復雜，產(chǎn)品上看新業(yè)務的驗證和打磨更關鍵）。

支付結算領域，正常都會分為支付，清結算，對賬，交易/財務賬務，商戶這幾個常見的中心，基于企業(yè)一筆交易的整體流程形成完整的業(yè)務上下游閉環(huán)。

其中支付核心是支付訂單，主要是明確交易的支付來源，收付款方，金融，支付方式和最終執(zhí)行支付的處理源（支付渠道）；

清結算核心是結算單，主要是明確基于交易的應收應付，結算的渠道做資金結算；

賬務核心是賬戶（一般涉及到金融端的銀行結算戶，支付機構的支付賬戶，交易端的賬簿）；

對賬核心是對賬單，涉及對賬數(shù)據(jù)的接入，清洗，對賬處理，差異處理，賬單輸出；

商戶就是參與到交易的交易對象，基本分為個人，企業(yè)和個體戶，賬戶都需要關聯(lián)到對應的商戶下面（按賬戶權限做商戶認知，比如收單特殊商戶需要做實體認知）。

1.2領域架構設計

我理解的業(yè)務架構，通過層級來定義同1個業(yè)務的輸入和輸出邊界，通過模塊來定義同一層的不同能力或者服務，比如很多架構都會有應用層，邏輯層或物理層等。

對于支付結算領域來說，個人習慣應用層，邏輯層到核心層的3層或2層設計，應用層做服務的輸出，邏輯層做業(yè)務解析和領域內(nèi)的邏輯處理，核心層定義業(yè)務對象的核心能力和屬性。

以聚合支付服務為例，應用層就是標準的聚合支付服務接口輸出，外部應用通過調(diào)用接口獲取聚合支付服務，獲取到支付的業(yè)務訂單數(shù)據(jù)后做業(yè)務解析，明確收付款方，支付方式等信息，通過支付路由規(guī)則明確支付方式對應的渠道。

有些場景（比如組合支付）還涉及邏輯的處理（組合支付需要基于主支付訂單，拆分多條支付渠道流水，并要求所有的支付渠道流水成功才算組合支付成功），核心層就是拿著明確的支付方式，支付渠道，收付款方和金額等信息調(diào)用支付渠道做最終的支付處理。

業(yè)務驅動支付產(chǎn)品設計。

典型的幾個支付產(chǎn)品設計拆分。

四、資源

前面講了，支付方式本質上其實是信用的不同處理方式，資源代表了處理的權利，比如國家發(fā)行法幣，背后就是國家的信用，所以法幣的資金結算由央行統(tǒng)一處理（處理的結果是相對的信任是逐層的，比如電商收單支付資金的流轉：央行清算-商業(yè)銀行清結算-支付機構清結算-交易系統(tǒng)清結算，系統(tǒng)層面就是中心化設計。

1.1 金融資源

支付結算一旦涉及到實際資金，就需要對接金融資源，首選需要了解金融資源玩的規(guī)則，個人理解就是中心化管理&專業(yè)化各司其職（不同專業(yè)要有不同的金融牌照），金字塔頂端就是央行，銀監(jiān)會（保監(jiān)會合并）和證監(jiān)會，一筆線上支付的資金整體流程，下面我以在天貓使用支付寶（花唄）支付為例做個簡單說明。

交易場景（天貓交易訂單）—業(yè)務層（生成支付訂單，支付方式花唄，支付渠道支付寶）—支付寶支付處理（1.通知螞蟻小貸要扣我的花唄額度，螞蟻小貸做我的花唄額度查詢并扣減記賬，反饋給支付寶，支付寶反饋支付處理結果，此過程現(xiàn)需要走網(wǎng)聯(lián)）—由網(wǎng)聯(lián)走小額支付系統(tǒng)/超級網(wǎng)銀—央行做資金清算（螞蟻小貸花唄專戶清算給支付寶備付金賬戶，按日軋差一筆處理）——支付寶生成賬單（通過網(wǎng)聯(lián)獲取賬單后做對賬核銷，支付訂單完成資金結算）——業(yè)務層獲取支付寶賬單并做對賬核銷，并等待天貓業(yè)務訂單閉環(huán)觸發(fā)支付訂單資金結算給商戶（一般是我支付成功，商戶就能看到余額的收益資金（凍結資金），但基于天貓貨款結算規(guī)則，需要業(yè)務訂單閉環(huán)后才能提現(xiàn)）。

1.2企業(yè)資源

除了對接金融資源外，也涉及到一些企業(yè)內(nèi)部資源的對接，包括但不限于內(nèi)部授信（賒銷），返利（費用轉化），營銷補貼（費用轉化），價格補貼（費用轉化），預收款（先款后貨）等等?？蛻臬@取到這些企業(yè)內(nèi)部資源，正常都可以在企業(yè)業(yè)務閉環(huán)內(nèi)做交易支付。

正常情況，很多企業(yè)都使用ERP做這些內(nèi)部資源的管理，中間涉及到業(yè)務的解耦，核心是解耦資源的業(yè)務邏輯到獨立的領域模塊中，讓ERP只做核心的記錄核算（解耦的整體方案，數(shù)據(jù)遷移等都不在這細講）。

1.3 運營資源

交易驅動的產(chǎn)品更偏向于是運營驅動的產(chǎn)品，因此產(chǎn)品設計的時候需要考慮企業(yè)的運營能力，有沒有足夠的資源支持產(chǎn)品的運營管理，很多時候真是這塊決定了時間產(chǎn)品的客戶價值（不要到最后產(chǎn)品上線，發(fā)現(xiàn)一直沒什么用，很多項目沒有下文的主要原因）。

五、支付結算數(shù)字化案例

HE集團為國內(nèi)最大的幾家家電企業(yè)之一，企業(yè)戰(zhàn)略上開始做傳統(tǒng)分銷到賦能分銷商，直接觸達終端客戶提供零售服務的轉型，通過企業(yè)數(shù)字化，實現(xiàn)庫存在線，交易在線，資源在線，營銷在線和組織在線，以更好的支撐服務多元的交易場景，嘗試新的服務業(yè)務，通過標準化業(yè)務獲取完整的有效數(shù)據(jù)，并驅動數(shù)據(jù)賦能業(yè)務。

支付結算以開發(fā)平臺的產(chǎn)品形態(tài)，統(tǒng)一對接金融和企業(yè)內(nèi)部資源，輸出標準的支付結算和賬戶服務來滿足2B,2C的不同交易場景（很多細節(jié)有興趣的可以看看差不多去年同一時間的文章聊聊企業(yè)數(shù)字化轉型需要建的支付結算產(chǎn)品）。

具體的產(chǎn)品形態(tài)，可以基于企業(yè)客戶的實際業(yè)務和項目范圍來設計，單一的業(yè)務場景不需要做支付結算開發(fā)平臺，不需要細化領域，能夠快速滿足業(yè)務場景，實現(xiàn)交易的支付結算閉環(huán)即可。

六、繼續(xù)前行

后續(xù)在支付結算領域基本定型的情況下，我會更多往業(yè)財一體，產(chǎn)業(yè)金融產(chǎn)品的落地靠。

以上內(nèi)容基于自身企業(yè)數(shù)字化項目支付結算產(chǎn)品從售前到交付的經(jīng)歷，內(nèi)容上主要以方法論拉通為主，希望可以給廣大讀者待來幫助，后續(xù)會不斷補充具體落地的一些內(nèi)容，非常感謝。

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

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