摘要：本文主要以筆者自身的工作經曆介紹了一家三方支付公司的産品與系統的演進之路。

筆者在第三方支付行業工作近十年了。本文就以自身的工作經曆為基礎，聊一聊對第三方支付産品、系統以及行業的理解。支付是一個普遍的現象，任何經濟活動都離不開支付，有商業活動就有支付。但正是這種普遍性讓不同的人對支付有不同的看法與認識。一個小商戶與一個電商平台對交易與支付的理解肯定是不同的。而第三方支付公司對支付業務看法與認知又與使用支付的商戶有着很大的差異。下面筆者就站在第三方支付公司的産品經理的角度來講一下我理解的支付産品與系統。

差不多十年前我第一次進入這個行業時對支付産品還沒有什麼概念。但它給我的第一印象就是複雜。當時任職的支付公司還處于初創階段，業務還沒有起量，但研發團隊已有幾百人。經曆了大半年的開發已經搭建了一套比較完整的支付架構。據說當時各種子系統超過100個。以至很少有人能了解公司支付體系的全貌，如何運作的。它帶來的問題是一個新的業務在設計時，不知道它會涉及哪些子系統，它對現有的系統流程會有什麼影響，該如何調整。那時最大的感受就是經常開會，任何一個小需求都可能叫上一屋子的人開會。還好當時公司裡有專業的架構師負責分析業務涉及的子系統，拆分、拍闆決定每個子系統的職責範圍與開發任務。還有專門的項目經理負責推進開發落地，産品經理可以專注業務。後來公司也察覺這個問題，因為這不僅效率低更埋藏了風險。于是由資深的産品經理調研畫了一張公司内部的系統架構圖，并組織重要模塊的leader向産品經理講解每個模塊的職責、功能、運作方式等等。我就是從那時起開始了解三方支付公司的系統架構的。

相比之前我做過的保險核心業務系統、預付費卡系統，第三方支付系統要複雜的多。後來我也總結了三方支付系統之所以複雜的原因。保險核心業務系統隻是面向内部用戶，用于保險公司内部的運營相對封閉。預付費卡系統是個相對專業的系統，面向的場景也是固定的。而第三方支付公司的支付系統面向的是各種交易場景，開放性的場景決定了系統的靈活性。另一方面支付公司的底層連接的是各家銀行，内部稱為通道。打通各銀行并維護其可用，還要考慮各銀行的處理差異、交易成本等等各種因素，也是非常複雜。除了兩頭在外，内部的賬務處理、風控系統、資金的清結算等内部系統邏輯也很複雜。第四個原因是與資金處理相關的系統都有高可靠、高可用、一緻性的要求，這必然導緻系統設計的複雜性。在網上很容易搜到一些支付寶系統架構的介紹，這些介紹可以管中窺豹，也足以感受到支付系統的複雜性。 最後就是交易的規模，這是一個量變到質變的過程。一個小規模的單體應用系統與可以支撐50萬筆/秒的支付寶的單元化分布式系統肯定是不同的。當然這屬于技術層面的問題了，産品經理更關注業務造成的系統設計差異。

我前後呆過兩家支付公司，同樣是做支付由于定位與業務不同支付系統的設計也有着很大的差異。第一家支付公司是一個金融集團下屬的支付子公司。最初定位是做C端錢包，為集團的金融客戶提供服務。由于母公司财大氣粗所以成立之初不急于做業務而是全力開發支付系統，搭好一個完整的支付體系。正如我前面所說業務還沒開始做，研發團隊已有六、七百人。基于底層穩定的架構搭建上層錢包APP，然後從集團接入各類金融服務，包括各子公司的客戶成為用戶，最後從外部引流拓展用戶。盡管中間有一些挫折，但大方向是對的，最終還是取得了成功。

我入職的第二家支付公司是一家老牌的三方支付公司，起步早發展模式完全不同。最早從航空票務領域起家，深耕了這個垂直領域。航空領域成功之後又不斷拓展其它領域，線下POS收單、餐飲、教育、醫美等。由于面向B端提供支付服務，不同行業的差别巨大，所以幾乎每一條業務線都有自己獨立的業務系統。這樣的好處是靈活，可以快速支持業務拓展，壞處是四處冒煙囪、系統、數據相互孤立。最典型的就是線上支付與線下支付是兩套系統，如果一個客戶即要用線上又要用線下收款就要兩個系統都開戶。但引來的問題是兩邊的收款記錄不能統一查詢、賬務、結算是分開的……另一個問題是重複建設，幾乎每套業務系統都有自己的商戶進件、交易、賬務……而且随着業務做大，需求增加系統功能變的越來越複雜，維護成本很高。

如果比較兩家支付公司産品與系統的不同，那麼首先是戰略定位的差異，2C與2B定位差異決定了後來的公司發展路徑。系統的演變是支持公司戰略與業務發展的結果。兩種模式沒有優劣，隻是看誰的戰略更清晰、執行力更強。

2016年公司啟動了一款獨立的線上支付産品的研發。其實當時公司在P2P資金托管領域有非常高的市場占有率，有幾百家的P2P對接了我們的支付托管系統。那時P2P還是合法的。當時我們提供的是一個“賬管家”産品，包含了線上支付接口 虛賬戶 資金沉澱的功能。這應該是公司早期的很成功的支持在線支付地産品。當時不隻是這條業務線有線上支付産品，航旅業務條線也提供了一些對外線上支付接口。另外線下事業部也遇到一些客戶需要線上支付。原本想拉這些客戶對接“财管家”産品，但由于是跨事業部存在一些壁壘，溝通成本高、響應不及時，所以最後我們事業部決定做一款獨立的線上支付産品“支付 ”。一開始資源投入比較少，一個産品經理寫了三四個月的需求，又花了三四個月開發，産品上線已是2017年初了。最初的定位是給中小商戶及APP開發者一套線上收款功能的接口，主要包括快捷、網銀、代扣等支付方式。但當時的接口設計不是很好，聯調的成本高，體驗差。更重要的是中小商戶的交易量小，要有大量商戶接入才能産生效益。公司沒有太多的互聯網基因主要依靠銷售拉客戶，獲客成本高效率低。後來公司做了調整：

1. 由于微信、支付寶的市場占有率擴大，中小企業對這兩種支付方式的接入需求量很大。于是公司調整産品功能，推出了一款以微信、支付寶聚合支付為主的支付産品“Adapay”。借鑒了Stripe面向開發者友好的理念對接口做了對象化的封裝、優化。大大降低了聯調的難度、提高了效率。收費模式上考慮到中小企業交易不會很大，偏重收取接入費而不是交易手續費。這款産品取得了成功，成為拳頭産品。
2. 重新定位“支付 ”産品方向，為大型客戶提供行業解決方案。但大客戶或行業解決方案需要的不隻是支付工具，還要更多服務。線上支付産品逐漸加入聚合支付能力，主要用于日益旺盛的微信、支付寶的線上支付、線下掃碼。活期理财功能對小B增加沉澱資金的收益，對C端則是為了幫助商戶黏住用戶。消費分期則是為滿足美容、家裝等行業的業務場景增加的服務。信貸服務是與保理公司合作提供支付叠加墊資的服務。由于單純地增加增值服務，沒有抓住客戶的痛點，産品推進的并不順利。

随着産品的演化，至2018年下半年我們基于之前線上支付産品的經驗打造了一款新的線上支付産品“企賬通”。當時國家在強化支付行業監管，禁止“二清”行為。很多電商平台沉澱小B資金的行為被禁止。一些大平台開始收購支付牌照合規化自身的經營，但更多小平台沒有實力收購牌照隻能對接支付公司。所以我們以此為切入點提供支付工具叠加賬戶、分賬、資金管理（與銀行合作提供資金監管服務）及一些增值服務。這個産品成為我們承接大客戶與行業解決方案的主要産品。

企賬通産品在推廣的過程中從純線上産品向着線上線下一體化的方向轉變。其間也嘗試與國内的各SAAS服務商、行業龍頭、大型商圈shoppingmall合作。為了加強合作我們還曾調研了餐飲SAAS、寵物行業的SAAS服務商、收銀系統SAAS服務商、生鮮連鎖經營類平台希望能找到深入合作的夥伴。比如通過收購、購買系統源帶碼等方式快速切入一些行業，但效果并不理想。由于接了一些大商戶定制化的功能比較多，所以後續的産品叠代、維護成本會較高。

随着SAAS服務産品的興起，2021年初公司高層決定做一個SAAS化的支付産品——鬥拱。希望通過對支付業務重構抽象，打造成通用的支付能力對外開放。面向的客戶不隻是企業商戶、平台型客戶，還包括軟件開發商(ISV)、SAAS服務商、銀行、四方支付等合作夥伴。不僅要實現支付還要幫助合作夥伴通過支付及增值服務實現創收，最終實現多赢。我們用了四個月時間醞釀、規劃，五個月的時間開發終于在9月份上線。

以上大緻就是當前公司支付産品的演變過程。

從産品層面看三方公司的支付産品從最初的拼通道、拼成本價格，轉向拼支付能力、拼解決方案、服務。當然這是指為B端服務的支付企業。為了适應産品層面的變化，我們的系統也要相應改造實現對産品的支撐。

系統層面看支付系統從第三方支付公司内部的業務系統，也是對外提供支付服務的系統。這個系統跟随市場與産品的要求逐漸向外擴展，向着提供越來越多不同類型的SAAS服務演變。為了适應這種變化，系統做了很多改造。首先是底層整合，從技術層面的整合開始。比如賬務系統。由于曆史的原因我們先後有三套賬務系統，一些老業務的賬務系統甚至包含了業務功能。我們通過功能兼容、數據打通、新業務使用新賬務系統、曆史數據遷移等多種方式逐步遷移到新的賬務系統。

其次是增加抽象分層。比如對接銀網聯的通道層是統一的，但各業務系統都直接對接通道。由于通道層返回的信息差别很大，各業務系統都各自處理交易之後邏輯比如入賬、返回信息的封裝等等。所以又統一封裝了一層内部使用的收銀台，負責對交易之後的通用邏輯做統一處理。比如交易之後的入賬，返回信息的封裝與透傳。收銀台也按支付方式與通道的不同分為掃碼、之後所有的業務系統都接内部收銀台。

再向上就是交易處理層。原來的交易隻負責資金類的交易，站在三方公司的角度交易處理是連接客戶的業務訂單與内部支付指令的核心樞紐。現代複雜的商業場景、各種利益相關方的利益訴求都要在交易環節處理完成。我們對交易場景的内涵做了擴展，以适應各方的利益訴求。比如一筆交易會涉及電商平台的服務費、渠道的分潤、消費者貨到付款的利益保障、監管法規的要求……我們通過實時與延時的分賬來滿足各方。還有線上平台、線下shoppingMall會搞各種營銷活動，需要打通對方的會員、積分、優惠券等營銷系統，交易時不但要完成資金交易還要查詢會員、核銷積分、優惠券等。現在銀聯、微信、支付寶也會搞各種補貼活動，渠道商、商戶也會有很強的參與需求，我們的系統也要對接各方的營銷活動接口。

最上層是業務系統層。業務層的整合難度就不隻是在技術層面，而是内部業務條線的分割。業務條線的整合并不容易解決，它涉及公司的經營與曆史發展路徑、組織架構調整、各部門銷售的利益等問題。業務方向通常是由公司管理層依據銷售反饋、市場調研決定要拓展哪個行業市場。然後依據這個市場的特點設計合作模式，商業合同條款、招商展業的方式、運營流程設計，新的業務系統搭建或老系統的改造，交易系統的改造。之後才是尋找種子客戶、打磨系統與産品。如果順利打開市場就進入成長期。目前我們除了整合産品功能也在做一些用戶體驗的優化。舉個例子，一開始對外隻提供支付接口，然後提供SDK。SDK是對接口的封裝，比如：将接口聯調必須的加解簽功能封裝到SDK中。将接口功能按應用場景封裝成對象方便開發調用等。SDK提供的是後端的開發服務，對于前端開發我們在控台上提供收銀台的可視化設計。通過拖拉拽控件快速生成頁面及可下載的代碼包，客戶的開發可以将代碼包集成到項目中，進一步提高開發效率。前面這些産品形态都是基于客戶有開發能力來設計的，最後我們還提供了托管支付産品，隻要客戶注冊後完成進件就可以獲取一個收銀台頁面鍊接，通過線上收銀台直接收款不需要開發。我們希望通過這些産品設計逐步向客戶靠攏，滿足各類不同開發能力的客戶。

最後要提一下其實在做SAAS化支付系統之前，公司就開始升級内部的運維監控系統。實現了對内部核心系統的實時監控，建立了報警、統計、支撐服務。有了這些服務不僅可以實時了解系統運行的狀态，也為異常事件處置提供了快速定位與技術保障。結合運維系統定期報告、故障複盤流程為不斷優化系統提供了機制。使交易系統的可靠性、可用性達到三個9甚至4個9。這些内部支撐服務與監控體系未來将不隻用于對内保障交易的穩定與可持續性，未來SAAS化之後也将成為SAAS化服務的一部分。

以上是系統層級視角的，在産品層面我們也在做整合。這部分的優化包含兩塊：數據整合與流程整合。最初我們做的是業務基礎數據的整合。由于各業務系統都是各自為政的，商戶簽約、進件、聯調、上線、對賬等都有差異，且基礎數據也是各自管理的。我們首先嘗試對商戶、用戶數據做簡單的歸集，公共的數據統一存放，各業務系統特殊的字段數據，比如配置信息、費率信息各自獨立管理。

另一方面我們也對業務運營流程做了分析，了解各業務的運營流程現狀，設計一套兼容各業務條件的運營流程。然後基于這套流程設計系統，準備将各業務系統的流程最終都遷移到新的系統。最終的目标是整合内部流程統一中台，實現統一進件與開戶。

目前來看這部分工作還未完成。

1. 公共基礎數據的統一規範特别重要；它不僅是選擇需要公共管理的字段，按照DDD的方法論，需要對所有字段做含義明确的定義，這樣便于業務、産品、開發做溝通。
2. 盡管我們希望能有一套統一的業務流程與規範，然後再由系統承接統一後的流程與規範。但問題是很多業務流程差别很大，比如标準商戶進件流程是先提交材料、審核通過、開通業務、微信/支付寶入駐、聯調、生産上線。但有些業務為了提高效率與客戶體驗，客戶先提供基本信息，開通業務、微信支付寶入駐、聯調、生産上線，然後在規定期限内補交材料、人工審核。既然完全統一運營流程很難，那就換一種思路通過引入規則引擎實現流程的可配置。目前我們已實現了運營審核流程的可配置，但商戶進件流程比較複雜，涉及跨部門訴求、跨系統落地，需要大量的準備與分析工作。這部分工作還未開始。挑站可能還不隻這些，即使已經在使用運營規則引擎也涉及大量複雜的配置。我希望未來我們可以實現系統可以自動掃描系統中各類主體的信息與狀态自動與業務規則匹配，決定下一步的操作。如果足夠智能這個系統不僅可以提示運營内部操作，還能夠對外向客戶推薦産品與服務。當然這己經超出了簡單的規則引擎的應用。

在業務層面我們嘗試對内部各業務系統的功能做沉澱，比如Adapay系統可以為二級代理商做分潤結算，我們在鬥拱SAAS系統也做了這樣的功能。企賬通系統支持集團、連鎖機構的層級管理、資金歸集，這個功能也沉澱到鬥拱SAAS系統。這樣做一方面是豐富鬥拱的功能與支持的業務場景，另一方面是為以後将所有業務都整合到鬥拱系統做準備。

除了做系統層面的功能沉澱，公司也做了内部組織調整建立一個部門專門對外輸出已有的能力。就是将底層的能力整合為某一特定商戶或行業提供解決方案。通常的定位是通用的需求沉澱為産品能力由底層系統實現，定制化的内容由解決方案部定制化開發實現。

總體上講這部分工作隻是部分達到了預期。首先是存量業務如果處于衰退期的業務我們可以停止納新維持現狀等待正常退出。如果是比較成熟的業務就很難遷移，特别是涉及需要商戶配合改動的會比較困難。如果不能遷移那就隻能正常叠代維護，唯一可以做的就是在新系統實現所有業務功能，業務上将新客戶引導至新系統。但如果存量的商戶長期不能遷移，那就需要維護新老兩套甚至多套系統，維護成本會不斷升高。新系統堆疊老系統的功能并不是一個最好的方案。

當前仍聚焦于流程優化與系統整合。舉個例子商戶進件，按商戶來源分：渠道商進件商戶、業務直銷商戶、自主進件商戶。按進件的方式分：渠道商控台進件、運營内控台進件、網站自助進件、接口進件（可細分為純接口進件、帶網頁的進件，封裝了完整的流程方便SAAS商戶做集成）。按進件流程分：标準進件（提交材料、審核、簽約、聯調、生産上線做交易），後補進件（先聯調、上線交易、後補材料審核）。還有為了提高進件效率提供費率模闆、電子簽約流程……不同的場景對系統的設計都會有影響。而且這些場景也是不斷叠代與演化出來的，系統的調整伴随着演化的過程。 還有進件的運營流程中所有操作環節都可以優化，比如：補交材料、後審、電子簽約、業務配置模闆、分潤結算、電子發票、OCR識别……每個環節的優化都會提升的進件的效率。

除了對現有的流程最優化，也會有新的功能與流程需要設計，比如原來支付公司隻向渠道商結算分潤，渠道商下屬的代理商的分潤都是渠道商自己負責。後來代理商也希望支付公司直接結算分潤給他們不通過渠道商結算。這裡不隻是流程變化，首先法律關系上如果支付公司直接向代理商提供了結算服務，與代理商之間有了直接的資金往來就需要協議條款支撐。其次因為有了新的簽約條款，代理商的進件需要調整運營審核流程。

流程的優化與新增需要修改的不僅是系統，更需要設計出合理的業務模型與系統模型。由于第三方支付公司有很多不同類型的客群與服務主體。比如：付款的個人用戶，收款的商戶、合作銀行、清結算機構（銀聯、網聯），幫助拓展商戶的渠道商、代理商……不同類型的主體在整個支付業務中訴求是不同的，有些是支付公司提供服務，有些是提供服務給支付公司，也有相互依賴的。需要根據業務流程中他們的角色與職責設計好業務模型。業務流程會不斷變化，業務模型既要穩定又要能适應變化的流程。 比如在标準的交易場景中支付流程隻關注用戶付款給收款商戶，這個場景中業務模型很簡單隻有兩個主體。但在電商平台這樣的場景中，由于平台主導了業務場景提供了交易撮合的服務，也會有收費服務費的訴求。所以每筆交易都會有抽成。這時交易就從兩方變成了三方。在業務模型設計時就要考慮如何支持這樣的場景？什麼樣的主體可以參與交易的分賬？是實時還是延時分賬？分賬金額或比例的限制……更複雜的是交易時的營銷補貼。在模型設計時就要考慮，誰來補貼？資金從哪裡來，流到哪裡去？手續費由誰來承擔？退款時手續費與營銷費用的處理方式，不同的場景處理方式可能是不同的，是否每種方式都要支持……這些問題首先要業務确認，之後按照前面DDD的方法論需要通過事件風暴描述整個業務流程、規則将業務問題拆分到系統的域模型中。DDD是領域驅動設計的方法論，它将業務與系統劃分為不同的域分而治之。比如核心域（交易、賬戶、資金、商戶）、通用域、支撐域（增值、會員）等等。其實就是劃分邊界，然後分析業務描述中的名詞、動詞轉換為聚合根、命令、事件、實體等模型，并根據模型來設計系統。在一個有清晰邊界的限界上下文内分析出值對象、實體對象、聚合根、領域事件。系統的改造并未完全使用這套方法論，但至少按域對系統做了劃分。分而治之的方式對底層做優化。

中台本質是業務模型，通過DDD這樣一種設計思想，它可以指導中台業務建模轉換成微服務設計，從而實現系統的落地。個人認為SAAS系統好壞很大程度上取決于模型的構建。構建好的業務模型不僅有助于理解與溝通，也是構建穩定的系統模型的基礎。這裡的關鍵是構建領域知識與模型是需要持續不斷的投入資源維護的，包括統一的術語字典、模型文檔的維護、多方參與的事件建模流程……這是一個需要長期堅持不斷叠代的過程，堅持往往很難。

站在産品的角度下一階段要思考的問題是：如何将支付更靈活地嵌入客戶的業務流程中。支付天生就是商戶活動的一個環節，而且是閉環的最關鍵的環節。它的天然屬性就是要嵌入商戶的業務流程中的。這裡的差别是嵌入有多深。舉個例子，傳統POS的功能隻有收款，并未與商戶的業務系統打通。如果将POS與商戶的業務系統打通，那麼業務系統的訂單信息自動傳送到POS上。完成收款後再通知商戶的财務系統、倉儲、物流……那就實現了系統層面的閉環效率就高了很多。目前我們已實現的webhook功能就是基于這種想法的一種嘗試。如果再與商戶的會員、營銷系統打通，在收款的同時支持打折、銷券等操作，那嵌入的領域就更深了。如果支付環節還支持銀行的消費分期、花呗分期、提供交易流水數據作為流水貸的依據，那支付所提供的附加價值就更高了。在我看來将簡單的支付擴展為複雜交易的處理是必然的趨勢。支付隻是資金處理，交易包含了客戶業務屬性、流程。做B端的支付産品就是在幫B端解決交易問題。

另一個更重要的問題是：如何快速地維護各種商業關系？這個問題有點抽象，它的提出是基于以下的判斷。三方公司之間的支付能力的差異正在縮小，以前看誰接的銀行通道多，成本低。斷直聯後大家的通道能力差異大大縮小。後面2C類支付比拼的場景，基本被微信、支付寶占領。2B類的支付場景由商戶主導，支付公司能做的是對商戶業務場景的支持。支付本質是商業主體之間利益關系的體現，所以支付的基礎是兩點：商業主體在系統中的創建，然後是商業主體之間利益關系的維護。不管是交易、分賬、營銷活動等等這些商業行為的處理，本質都是利益關系的反映。所以交易是利益關系的最終體現，隻是目前是通過交易系統來實現數字化處理。目前我們關注的業務流程還是如何快速高效地在系統中創建各種類型的商戶，如前所述，不管是渠道商進件、直銷進件、自助進件都是将商戶主體數字化。下一階段我們将關重點關注這些主體之間的商業關系的構建。商戶與商戶之間的利益關系這是兩種完全不同的業務實體。商業主體的信息多是靜态的，創建好了就很少變化，而商業主體之間的關系可能是動态的，而且關系的類型是多樣的。比如簡單的買賣關系、渠道代理與商戶的關系、供應鍊的上下遊、連鎖機構總部與加盟店之間的關系……兩個不同的主體之間的資金往來都是由它們的商業關系決定的。我們現在決定一筆交易涉及到哪些主體依賴的是主體進件時所決定的角色與審核過的業務場景。比如一個平台下面有一個小B商戶、一個C用戶，業務場景多是C用戶付款給小B，平台獲取傭金。之後如果商業關系發生變化，有一個代理商進駐平台，它可以從一筆交易中抽取傭金。如果是基于商業關系來設計，隻要增加一個關系實體，比如一份合同，描述了平台、代理、商戶、用戶之間的關系，系統就會自動按合同來完成交易。

當然基于關系來設計系統模型會變的更靈活但也會增加複雜性。不隻是交易系統、商戶管理子系統，可能風控系統也要大改造。現在風控是基于主體的角色來控制交易，而之後會依賴商業關系來進行風控，這些都是巨大的變化。更重要的是從公司戰略層面看，第三方支付公司的主業從支付、交易轉向了商業關系的維護。支付從物物交換到貴金屬、紙币、電子貨币、數字貨币，支付形态不斷變化處理方式也不斷變化。相比支付形态的變化，支付背後的商業關系永遠存在。這也是我個人認為這種轉型重要的原因。

大約十年前我還在國内一家專業做預付卡交易處理的公司做開發。當時支付寶的一位總監來我們公司談合作。他說：支付寶的未來目标是要取代現金。我當時覺得他的口氣好大，現在十年過去了，電子支付已經非常普及，錢包已成了過時的東西。所以十年之後數字貨币或許可以取待現在的電子支付，這種轉變對當下的三方支付公司而言影響是巨大的。因為數字貨币的本質就是要取代中心化的交易，這是要革三方支付公司的命。目前中國的數字貨币并不是完全去中心化的，按現在央行對數字貨币運營流程的設計，是央行與金融機構雙層運營體系。央行把數字貨币發給金融機構，金融機構再兌換給公衆。支付公司屬于準金融機構能否獲得這一資格難講。可能微信、支付寶這樣頭部的支付機構還有機會。而現在的數字貨币的費率是萬幾，不可能支撐現在支付公司的運營成本，個人認為未來支付公司一定會轉型。這可能就是未來第三方支付公司一個發展方向，成為商戶關系維護機構，幫助商業機構快速解決交易場景問題。在交易的同時完成各種商業關系與利益的計算分配然後獲取服務費，而不是依靠交易規模收取手續費。

這種模式需要在支付環節能夠關聯更多的服務。支付公司提供能力越多，可以接入的商業關系越多優勢也就越大。比如：銀聯、銀行的營銷活動……尋找各種可以合作的商業夥伴，比如銀行、基金、消費金融機構、SAAS服務商……SAAS服務商即是我們的客戶也可以是我們的合作夥伴。支付公司可能會轉變為各種資源的整合機構。這或許就是支付公司的轉型方向，當然也會成為産品、系統設計的方向。

最後談一些我所經曆的經驗與教訓。

客群定位要準确支付SAAS面臨最大的挑戰就是客群的定位。SAAS服務是要挑客戶的，因為SAAS的價值就是提供通用産品與服務，可以複制拓展給一批同類客戶使用，以降低前期開發成本提高邊際收益最終實現盈利。如果客戶比較散産品就很難聚焦，這是一個比較頭大的事情。

不要貪多求快剛上線階段要保障基礎功能有很好的體驗，不要堆疊新功能。比如提供了對外的API接口，但沒有人維護站點商戶對接一步一坑。如果不能保證功能的體驗會影響産品的口碑，2B的産品這一點很重要。體驗差這還是小事，我之前任職的支付公司系統剛上線，就試圖全面開花接入各種場景，開發人員爆增開發成本爆長，攤子鋪的太大虧損嚴重。但剛上線的系統難免有各種問題，一時又沒有找到好的場景打造出爆款産品，結果公司人事動蕩。投入太大成本快速增長會影響到公司的運營，即使你有充足的資源也會有很大的風險。

需求管理個人認為對需求的統一管理分析是有助于産品叠代的一項好措施。這裡的需求不僅是指商戶需要的功能，更重要的是需求背後的利益訴求。相比功能的變化，利益的訴求要穩定的多而且更普遍。比如：電商場景中有大量的交易需要延時分賬，我們的實現方式是為商戶建立中間賬戶，管理延時分賬交易的資金。這種中間賬戶不對外開放也不可見，但電商的财務說他們要能查看延時賬戶中的資金餘額。我們增加了餘額查詢接口的功能，支持了中間賬戶。其實更深層的分析這個需求，背後是對電商這樣的擁有大量在途資金的客戶都會有在途資金管理的訴求，我們應該如何深挖這樣的場景把體驗做好。再舉個例子，一些平台需要我們提供電子回單用于證明一筆交易發生或存在。平台需要向他的小商戶提供這些電子回單。對商戶而言這是鬥拱系統提供的一個功能，而這個功能的背後是第三方支付公司對交易背書與證明，與銀行提供的回單是同樣的性質。支付公司不隻是提供交易還要提供交易甚至資産的證明，這也是可以深挖的需求。當我們深度分析這些需求之後就可以在産品規劃、系統設計中做預留，而不是不斷地打補丁。

内部培訓支付系統是龐大複雜的，很多産品、開發leader各管一攤，很少有人能把控全局，更别說銷售了。所以需要有系統架構圖、産品能力地圖，以及不斷地内部培訓，包括銷售、産品、運營、運維等各角色的專門培訓。

以上就是這些年工作經驗的簡單總結吧。