PowerDotNet平臺化軟體架構設計與實現系列（15）：支付平臺

PowerDotNet個人專案中功能全面而強大的一個系統是支付平臺。我對PowerDotNet的自信很大程度上來自於經過PowerDotNet重寫後的支付、財務、結算、CRM等業務型公共服務系統的穩定執行。

使用PowerDotNet和PowerDotNetCore特別開發的業務邏輯型公共服務既有極大的業務價值，又具有很大的技術挑戰，在我個人看來算是技術和業務緊密結合的典範，可按需二次開發。

個人開發支付平臺的歷史比較久遠，投入時間較多，當然用自己的眼光看，早期的支付系統從基礎元件運用到程式設計和編碼實現，很多都不太令人滿意，所以我一直想用PowerDotNet重寫支付平臺。

現在經過PowerDotNet重寫後的支付平臺已經達到生產級別，是PowerDotNet裡最出色的穩定可靠、靈活可延伸、可維護性強且易運維的公共服務之一。

很多人可能會有疑問，PowerDotNet是不是隻能開發一些相對簡單的系統？就像前面介紹的基礎資料平臺，只有CRUD？或者像HCRM人員管理平臺，只有略微複雜點的CRUD而已？

其實我認為所有業務系統都可以抽象出CRUD操作，技術為業務服務，有些系統的CRUD門檻還很高，甚至比萬年不變的框架值錢且難寫多了，在很多業務驅動的公司裡，CRUD才是真正的核心競爭力。

個人開發生涯至今，碰到過很多業務邏輯複雜，可維護性惡劣的CRUD型業務系統，經常有各種各樣的奇葩問題，讓人產生一種程式設計是門面向巧合的玄學的感覺，優質的業務系統程式碼實在是鳳毛麟角。

對如何寫好CRUD這個問題各種方法論層出不窮，仁者見仁智者見智，至今還有很多爭論，務虛和務實的選擇而已，哪一種讓你更喜歡更有成就感就堅持自己的選擇。

你可能理解總結了很多技術原理，精通軟體開發設計模式和架構，人手一個ORM和（或）程式碼生成器，對很多框架和中介軟體如數家珍娓娓道來。。。可CRUD卻總寫不好，這才是人間真實。

在某廠有兩位高人大仙交接給我一份支付閘道器和銀聯支付程式碼，程式碼量不大，但三天兩頭崩可真有你的，看完程式碼我又笑了。魔鬼都在CRUD細節中，能讓所有程式碼都變成魔鬼確實讓人欽佩，咩哈哈。

萬丈高樓平地起，讓CRUD更快捷更輕鬆應對變化更容易擴充套件和維護，這是PowerDotNet出現的一個重要目標，也讓我們多了一個減少出錯的選擇，所謂多一個選擇多一條路，於我心有慼慼焉。

經過PowerDotNet和PowerDotNetCore重構優化後的支付平臺命名規範優雅，分層和系統互動清晰合理，避免抽象能力邏輯能力和程式碼組織能力不強的開發人員陷入程式碼迷宮的泥潭。

重寫後的支付平臺，模組間耦合性大大降低，支付方式比早期支援更多樣，單元測試覆蓋率大幅提高，核心邏輯比原有程式碼量少了一半左右，關鍵是執行極其穩定，PowerDotNet平臺基礎居功至偉。

遵循PowerDotNet規範開發的CRUD型應用，不但功能強大高度複用，同時程式碼的可讀性、可維護性和靈活性也是第一流的，讓開發者更好體會CRUD的樂趣，別問我怎麼知道的，我就是知道^_^。

本文介紹的支付平臺可以認為是目前為止PowerDotNet的最佳實踐中的最佳實踐，主要是因為支付平臺相關的應用比較多，不同系統和應用之間互聯互通關係比較複雜，涉及的專業知識面非常廣泛。

支付平臺的最終目標是將公司資金的出入全部集中到平臺進行統一管理，不論線上還是線下，國內還是國際，B2C還是B2B。

目前PowerDotNet實現的支付平臺API介面初步統計有200多個，這還不包括未接入的支付渠道和輔助工具介面、查詢統計類介面、線下業務介面、使用者資訊和公司虛擬貨幣介面。

支付平臺涵蓋了後端、前端和使用者端的很多方面，主要包括多租戶、分散式快取、訊息佇列、回撥通知、定時任務、設定中心、服務治理、多語言、事務、OLTP、OLAP、頁面跳轉、對賬、證書、檔案、憑證、票據、統計、風控、財務、結算、IoC、AOP、ORM、紀錄檔、安全、互操作、冪等、二維條碼、條碼、監控、報表等。

支付平臺Power.Payment目前支援B2C（線上和線下）和B2B（線上和線下）主流支付方式，和財務、結算、收銀、風控、賬戶、CRM等都有緊密聯絡，是對接商戶業務系統的直接而重要的橋樑。

請注意，真正完備的支付平臺通常還包括收銀、風控、賬務、會計、清算、安全等重要子系統。本文介紹的偏重於直接涉及金錢出入的支付前置和閘道器部分，它們毫無疑問是支付中最重要的平臺子系統。

幾年前在寫某司支付平臺的時候，PowerDotNet還在開發和完善中，服務治理剛有雛形，不能充分利用很多開源元件功能，所以當時寫的支付平臺用的技術棧很弱，但是上線後也正常穩定執行，充分證明了抽象和邏輯的重要性，咩哈哈。

很慚愧，在支付系統做了一點微小的工作以後，對日常開發談不上多上心，卻堅定了我深度開發PowerDotNet的決心，人吶確實都不知道，自己多麼不可預料，一個人的命運，當然要靠自我奮鬥，但也要考慮到歷史的程序。

經過最近幾年的不斷開發優化和完善，PowerDotNet基礎元件和服務已經非常成熟，支付平臺已經是PowerDotNet裡涉及技術最全面互聯互通最複雜的公共服務了。

和主流的開發框架相比，PowerDotNet開發最複雜最具挑戰的業務邏輯型應用也是毫不遜色。

有了PowerDotNet，讓我們擼程式碼更輕鬆更高效。

有了PowerDotNet，我們要做到業務邏輯型選手中的天花板。

有了PowerDotNet，CRUD也能兼顧設計的藝術和藝術的設計。

有了PowerDotNet，CRUD我們也是最專業的^_-。

言歸正傳。

支付是一個看上去容易，實際上很難深入，一旦深入又讓人感覺非常簡單的專業領域。

猶記得當年去某司剛接手支付系統的時候，被頁面跳來跳去，介面改來改去，回撥通知來通知去，介面調來調去，對賬對來對去，紀錄檔和風控埋點插來插去，各種程式碼分支合併來合併去所支配的恐懼。

後來熟悉了之後，也許自視甚高慣了，覺得這系統除了工作量大而且過度設計效能惡劣以及程式碼稀爛之外（更專業的吐槽請猛擊這裡和這裡），真沒多少技術含量，挑戰性不強，咩哈哈哈^_^。

然後跳到下一家公司，本以為再也不會開發支付相關的東西，不到半年，一個玩票demo型的支付系統就到我手上了，看了原始碼後，我真想說你們還是另請高明吧，我實在也不是謙虛。。。。。。

果然天下烏鴉一般黑，沒有最爛只有更爛，最後我就把demo型支付系統推倒重寫了，間接考驗了我的毅力和技術水平。

寫支付應用，並不是拿到支付SDK和檔案，寫寫接入邏輯拼接下報文就搞定的，這種毫不客氣地說，都是demo水平，咩哈哈。

支付接入，需要抽象和提取，然後才能開發出通用高效、面面俱到、功能強大、接入靈活、穩定可追溯的平臺系統。

我個人有相對豐富的支付平臺的開發經驗，積累的越多越能體會到公共服務設計的強大之處，下面就分享些個人經驗之談，不足或疏漏之處請注意甄別，適合自己的就是最好的。

環境準備

1、（必須）.Net Framework4.5+

2、（必須）關係型資料庫MySQL或SqlServer或PostgreSQL或MariaDB四選一

3、（必須）PowerDotNet資料庫管理平臺，主要使用DBKey功能

4、（必須）PowerDotNet設定中心Power.ConfigCenter

5、（必須）PowerDotNet註冊中心Power.RegistryCenter

6、（必須）PowerDotNet快取平臺Power.Cache

7、（必須）PowerDotNet訊息平臺Power.Message

8、（必須）PowerDotNet檔案平臺Power.File

9、（必須）PowerDotNet個人使用者管理平臺Power.PCRM（後續詳細介紹）

10、（必須）PowerDotNet人員管理平臺Power.HCRM

11、（必須）PowerDotNet基礎資料平臺Power.BaseData

12、（必須）PowerDotNet定時任務排程平臺Power.TaskSchedule

13、（可選）PowerDotNet資料同步平臺Power.DataX

一、支付應用

1、應用劃分

根據經驗，大概可以分出下面截圖這麼多應用，隨著前後端分離的流行，前端還可以分出SPA應用。

業務方使用者端、H5和APP的支付功能主要通過支付閘道器介面接入，屬於業務系統，不屬於支付系統。

有些支付後端應用會直連銀行介面，這樣會產生一些額外的應用，比如安全守護行程、回撥通知工具、支付憑證工具等，這裡也沒有列出來。

又比如說動態可設定的支付收銀臺頁面：

上面收銀臺頁面只是範例參考，對使用者顯示的部分都可以通過後臺動態設定（隨手設定，不要介意圖示重複），甚至樣式模板都可以高度客製化化，如有相似設計，英雄所見略同，咩哈哈。

當然還有常見的H5支付收銀臺，APP、Pad、自動售貨機、一體機等專用的支付閘道器，這些在PowerDotNet支付平臺下都開發了對應應用予以支援，本文不再贅述。

二、支付基礎

我們設計的是一個支付平臺，而不是隻有支付功能。平臺系統的最大特點就是接入的面要非常廣，也就是典型的多商戶或者多租戶系統。

多租戶系統劃分的維度，常見的比如按照國家或區域劃分，如中國，美國等；按照公司劃分，如總公司，分公司等；按照商戶劃分，如內部商戶，合作商戶，外部商戶等。

本文我們以經典的多商戶系統進行分析講解。

1、商戶管理

主要功能是為接入的商戶端分配編碼和祕鑰，安全接入簽名都用到，同時還能按需動態設定顯示支付方式、支付模板等，這些個性化的需求在一個複雜龐大的電商系統裡隨處可見。

 2、支付分類

主流的支付分類包括第三方支付、微信支付、信用卡支付、儲蓄卡支付、網銀支付、ApplePay、POS刷卡、公司自身的虛擬貨幣（如賬戶和積分）支付等等。

其中，信用卡支付又可以根據支付通道的不同，分為直連信用卡支付、銀聯通道信用卡支付等。也可以根據來源地不同，分為境內信用卡和外卡，支付的時候還需要區分DCC和EDC。

網銀支付目前已經沒落，很少有新的商戶直接接入網銀，而是主要通過支付寶通道實現網銀支付。

對於特殊業務場景要考慮做到通用支援，比如常見的門店現金結算，我們還會抽象出Cash這一特殊支付分類，銀企直連（銀行轉賬），我們還可以定義BankTransfer支付分類。

擔保支付是一種獨特形式的支付，和信用卡預授權類似，不同公司有不同的業務形態，擔保邏輯也可能不同。

4、支付方式設定

支付系統的設定是非常多的，我是看過太多人把設定引數都放到組態檔裡，或者寫入設定中心，其實有經驗的人都知道這不是最優選擇，demo開發害死人啊。

腐爛的系統一大特徵就是組態檔特別多，特別特別多的那種，尤其是還有人哼哧哼哧開發自定義的設定格式檔案，真是奇哉怪也。

後設資料設計大法和模板設計大法同時兼顧可維護性和可延伸性，這才是真正的最優解決方案，本文重點介紹支付平臺，不細說這兩種設計方法。

支付方式的設定主要包括實際支付請求的主要協定引數，還有就是回撥通知URL路徑等。支付方式多起來以後，各種支付方式的設定隔離非常重要。

 三、支付單

根據個人開發經驗，業務系統中單據處理最大的難點通常有下面幾種：

1、同一種單據，狀態分類特別多，比如支付狀態、退款狀態、取消狀態、回撥通知狀態等

2、同一種單據，相同狀態分類下，狀態型別多變，中間狀態特別多，比如退款，可能有退款等待，退款申請中，退款稽核中，退款處理中，退款成功，退款失敗等多種狀態型別

3、單據之間處理相互依賴，你中有我，我中有你，流程冗長複雜，難以保證事務性，補償處理較難

傳統的比較常見的業務訂單系統和支付系統之間，通常都是通過支付請求唯一流水號和訂單關聯，找到支付方式和支付金額，然後將支付結果（如支付狀態改為支付成功）寫入業務系統中去。

這種邏輯看似簡單，實際上隨著系統的邏輯變得複雜，變得不易維護。比如引入退款、混合支付等邏輯，業務系統可能也不得不隨著支付系統而改動。

支付單的設計思想是，將業務系統和支付系統解耦，支付的資料由支付平臺來管理，業務系統通過關聯的支付單號或流水號呼叫查詢介面來查詢支付狀態即可。

這樣業務系統只要保留支付流水號或者支付單號，自動就能獲取支付狀態，不用自己去維護支付邏輯。

按照不同公司的不同支付形態，支付單可以抽象為扣款支付單、退款支付單、擔保支付單。

 支付系統裡有大量的回撥和補償操作，定時任務排程平臺Power.TaskSchedule真是功不可沒。

八、信用卡支付

信用卡支付分類和支付方式可以單獨拎出來說一整篇。

每家銀行的信用卡服務介面都會有差異，我們需將最通用的指令抽象設計提取出來，以應對信用卡介面的差異。當然SDK還得一家一家對接，所以直連信用卡服務開發是一項枯燥繁瑣極需耐心的工作。

信用卡預授權在很多業務場景下被廣泛使用，支付平臺開發的信用卡預授權相關的主要功能和通用核心指令包括：

1、預授權（PreAuth）

2、預授權復原（PreAuthCancel）

3、預授權完成（PreAuthComplete）

4、預授權完成復原（CompleteRevert）

5、退貨或退（PreAuthRefund）

6、衝正（Reversal）

在支付分類裡已經說過，其中信用卡還要區分內卡和外卡、DCC和EDC、直連還是銀聯等，還有部署環境的搭建，比如有無加密狗或U盾、銀行信用卡使用者端SDK對接等等事情需要費力操心。

九、財務對賬

做過支付和財務的開發人員應該都知道，銀行、第三方支付（如支付寶、財付通等）、微信、銀聯等都有完善的商戶管理後臺，業務人員（通常是財務）會定期按天或月將支付結果匯出為Excel來對賬。

對於常見的B2C或者B2B線下支付場景，如POS刷卡支付、支票、現金或者銀企直連等，也需要定期呼叫銀行提供的查詢介面或者直接匯出Excel檔案並解析POS結算資料進行業務和支付資料對賬。

根據個人開發經驗，嚴格來說，對賬應該劃歸到財務系統處理，但PowerDotNet的支付平臺認為支付Excel解析以及銀行、第三方支付、微信、銀聯、POS等的遠端查詢功能都應該由支付平臺來完成。

這樣做的最大好處是外部支付、退款、查詢等功能集中統一，否則財務系統也需要設定各種支付方式的應用Id、金鑰、證書等進行介面呼叫，通俗點講就是讓專業的人幹專業的事情，保證系統「純潔性」。

財務對賬的主要目的是找出賬目金額不準、或者缺少入賬收支項、或者單號錯誤等等業務錯誤，通常對賬都由公司財務人員來完成，解析Excel或者直接呼叫查詢介面主要目標也是得到支付結果差異。

支付平臺會定時按照時間範圍或商戶進行支付和退款資料解析和比較，生成差異結果並持久化儲存，當然還要開發查詢差異結果介面，供財務系統呼叫，雖然都是體力活，但系統邊界更清晰更易維護。

每到財務月結的時候，通常也是開發人員人心惶惶的時候。完善的支付平臺就應該有全面良好的所見即所得的對賬工具，讓時間寶貴的開發人員告別被大量Excel支配的恐懼，讓財務對賬更順利更輕鬆。

 

 

3、支付資料結轉與備份

自從用了DataX資料同步平臺，這一塊幾乎不用寫任何程式碼了，咩哈哈。

4、敏感資料脫敏處理

支付資料太敏感，尤其是信用卡CVV2和卡號後四位這些，支付好以後爭取「閱後即焚」及時銷燬，不要讓人接觸到。

在資訊保安和個人資訊保護越來越重視的當今社會，安全性是合格的支付平臺必須要具備的基本特性。

5、銀行卡號處理

包括信用卡、儲蓄卡等卡號規則校驗，卡號黑白名單校驗，銀行卡號通過卡BIN自動獲取銀行名稱等，這些對於安全性和提升使用者體驗有很大幫助。

6、支付監控

根據實際業務和部署情況，抽象出支付業務正常指標，按需動態設定監控和預警引數，可進行簡訊、郵件、釘釘、微信等方式進行業務告警。

支付監控功能主要基於支付資料包表統計和定時結轉功能，定時任務排程平臺和DataX資料同步平臺真是幫了大忙，這也是我們要辛苦開發平臺基礎公共服務的原因。

7、支付介面安全

支付平臺所有資訊敏感的（尤其是和錢、餘額、積分、資金、流水等相關的）介面必須經過嚴格的授權、鑑權、認證（校驗token）、驗籤等操作，當然這些都是服務治理平臺分內的事情，可以在服務治理平臺後臺管理系統點點按鈕輕鬆搞定，所謂工欲善其事必先利其器，此之謂也。

8、審計紀錄檔

支付資料的後臺人工變更必須有審計紀錄檔，對於支付財務這樣複雜的系統，因為業務需要，紅衝等後臺操作可能幾乎不可避免，所以必須做充足的審計準備。