一、什麼是支付系統
自古以來，所有的商業活動都會産生貨币的收款與付款行為。在人類漫長的曆史長河中，記錄收付款行為的方式不斷疊代：古代的賬房先生通過手工記賬，工業社會通過收銀機機械記賬……
今天，進入了網際網路時代的我們，商業行為也一同進行了數字化與資訊化的演變，成為今天的「電子商務」。
支付系統伴随着電子商務的出現而出現，為各類電子商務經營活動實作線上收付款交易以及管理交易資金等功能，是具有一定獨立性的内部系統子產品。
（1）、平台：開展電子商務經濟活動的主體。 （2）、業務系統：實作平台使用者注冊、商品定價、營銷活動等相關功能。 平台與業務系統的關系：業務系統将使用者購買行為通過各種交易訂單的形式進行記錄，并傳遞支付系統進行處理，最終由支付系統完成收款與付款。
根據央行的現行規定，人民币交易處理僅限于銀行及第三方持牌支付機構，是以支付系統在實作上述功能時，需要通過外部銀行、第三方持牌支付機構完成交易資金處理。是以，支付系統需要具備：
（1）、統一封裝處理的交易接口，以對接外部交易管道，為業務系統實作交易訂單處理的功能。 （2）、根據業務系統設定的資金配置設定規則，在一筆交易有多個收款方參與的情況下根據資金配置設定規則完成交易資金的自動化清分與結算，而後通過已對接的外部交易管道完成劃付。 （3）、賬務資料記錄功能，上述的交易、清分、結算形成的資金變動資訊，需要支付系統通過賬務資料記錄功能加以記錄，對交易資金進行統計并完成交易資金核對等财會工作。
二、支付系統架構
支付系統的主要職責是處理業務系統發起的所有交易請求，包含收銀台、交易系統、支付核心等子產品，根據各子產品不同的功能職責，可以将支付系統分為業務層和支付層兩部分。
（1）、業務層：負責業務系統提供收付款的操作界面以及處理業務系統送出的交易請求； （2）、支付層：負責通過支付管道實時處理完成資金的收付款、記錄參與交易的賬戶間資金流轉情況并按照預定規則對賬戶所屬資金進行拆分與合并。
業務層包含收銀台、交易系統以及會員系統三個功能子產品：
收銀台即使用者日常付款前選擇管道的頁面，是支付平台提供的基本功能之一，主要職責是協助業務平台完成支付交易，向使用者提供一緻的交易體驗。一般情況下，根據不同終端類型定制标準化的收銀台給到外部進行調用，保證各終端體驗一緻且針對各端特定需求、場景來展現不同的支付方式。
收銀台的業務場景（邊界）一般分為付款與充值兩部分：
（1）、付款即通過各類支付方式針對業務訂單發起付款，例如：使用者在天貓店購買一件衣服，确認訂單後自動跳轉至支付寶，引導使用者選擇對應的方式（餘額、花呗、銀行卡等）進行付款。 （2）、充值即使用者對賬戶進行餘額充值，例如：使用者登入支付寶、微信或其他商戶自有錢包系統對賬戶餘額進行充值。
支付管道的服務模型，分為以下幾個要點：
（1）、服務模型的概念：從支付公司角度來看，服務模型是決定商戶可以使用的交易形式（擔保收單、即時到賬等）、支付産品（快捷、網銀、代扣、POS 等）、簽約方式、階段周期（T+0、T+1、T+N 等）以及費率等核心問題的綜合體；
從電商平台角度來看，電商公司内部使用的支付系統與支付機構相比複雜度較低，可通過參考支付公司服務模型，梳理不同業務、不同交易類型、不同結算周期以及不同支付管道等複雜需求，搭建合理且滿足業務需求的服務模型，例如充值類交易，具有商城屬性的業務可配置擔保收單或即時到賬等交易類型。
（2）、服務模型的次元：
行業/服務次元：即從業務角度出發對支付産品進行劃分。
例如：螞蟻金融面向行業輸出交易、結算、會員、安全等服務，且為不同的服務等級劃定标準，貫穿所有内部系統；普通非支付公司（以電商為例），提供即時到賬、擔保收單等，基本上能滿足大多數的業務場景。
商品次元：針對不同行業的交易标的，由于交易價格、成本與利潤差異大，是以在業務層面不同的支付管道要有不同的可用性标準。
一般情況下，商品本身與市場或行業挂鈎，例如喜馬拉雅在接入微信/支付寶時，業務所在行業為視訊影音屬于虛拟商品，是以接入費率為 1%，結算周期為 T+7。
由此可得，支付公司針對不同商品本身的特性（例如風險等因素）在費率和結算周期上會進行一定的控制；同時，針對高風險行業會在支付方式、管道層進行限制。
市場次元：此處「市場」指的是指引客戶使用支付産品服務的場所，它可能是支付産品本身，亦可能為相關公司或平台的網站。例如某集團子公司、某公司投資的公司以及與該公司無關的外部公司等等，可分為集團、内部以及外部等次元。
客戶次元：此處「客戶」指的是服務的具體使用者。可分為個人客戶及企業客戶，通過支付系統内的會員系統進行區分。
付款方次元：付款方在整個業務過程中未核心角色，針對付款方使用者的特征應建立以支付管道收款方次元的模型，例如付款方的賬戶模型、安裝是否正式、證書等級等要素都決定着付款方的付款流程。
支付管道次元：在電商平台，跳轉到支付系統是，收銀台根據付款方的參數規則，進而對該筆支付在收銀台内可使用的支付管道進行選擇。例如充值賬戶餘額不允許使用信用卡時，收銀台在付款方付款時僅可展現借記卡等支付方式，喜馬拉雅在于支付寶等第三方支付公司互動式，下單接口裡一般含有做借貸分離的參數，該參數起到的作用就是可以指定付款方即使用者不可使用借記卡或信用卡。
業務管道次元：業務端使用的入口，代表着客戶或者業務方和支付系統的互動方式。例如通過 PC 端跳轉到收銀台、通過 App 跳轉到收銀台以及純接口形式跳轉等等。
支付管道各類配置：
（1）、管道配置：抽象收銀台支付方式大類（第三方、網銀儲蓄卡、網銀信用卡、信用類（花呗、白條）等），對應每個大類下配置對應的落地管道，再分别對适用場景進行比對（ App、H5、PC 端、公衆号等等），不同的場景下應對應不同的支付方式。 （2）、管道參數配置：在業務進行中根據公司的具體情況，部分業務可能獨立營運，是以在獨立營運過程中财務需要就獨立業務傳入各支付管道對應的密鑰及商戶 ID 等關鍵參數資訊，以滿足業務方需要支付系統根據不同商戶資訊調用對應管道收款主體的需求。
交易系統本身是作為支付系統外部處理業務邏輯的外圍系統。由于支付核心系統本身并非面向業務端且業務邏輯的多變性與複雜性，支付系統為了兼顧穩定并能夠為業務端提供靈活支援，是以需要在支付系統外層搭建面向業務端處理交易邏輯的交易系統。交易系統處理業務端的各種交易類型後，将業務資訊轉化為支付系統可識别的支付訂單并導入。
以擔保交易為例，C 端使用者在天貓購買一件商品，成功支付後商家進行發貨，使用者确認收貨後平台将貨款結算給商家。此處設計到「擔保交易支付」以及「确認收貨」環節，與支付系統内部的支付與結算步驟一一對應：
（1）、使用者付款成功後對應交易的付款成功狀态； （2）、使用者确認收貨後對應交易的成功狀态。
從支付和收貨緩解可以看出，擔保收單交易就是講支付系統的支付基礎能力包裝後對外支援業務的一款産品。
交易系統的職責：
交易系統作為支付系統的入口：
（1）、首先需要對接上層業務系統； （2）、其次将支付系統的支付能力抽象出來，對外提供各類交易方式，例如下單、支付、修改金額、确認結算、退款、關閉交易以及查詢等能力； （3）、最後，交易系統需要對各種交易類型進行定義，例如擔保交易、即時到賬、充值、提現等類型。
交易系統的場景（邊界）：
（1）、下單：生成交易訂單，确定交易參與； （2）、退款：針對已支付的訂單進行退款，退款金額不得大于實際支付金額，積分的退款退回原積分賬戶，同時針對退款交易類型，會生成交易訂單号，關聯入款訂單； （3）、修改金額：修改交易金額，對應生成新的支付訂單； （4）、查詢：查詢交易結果、支付結果； （5）、通知：通知上層業務系統交易狀态； （6）、算費：通過算費子系統計算每筆訂單的手續費。
交易系統的交易類型：
（1）、即時到賬交易：買家在電商平台選擇購買商品下單，付款成功後金額直接入賣家支付賬戶或者賣家銀行賬戶； （2）、擔保收單交易：買家在電商平台選擇購買商品下單，有部分金額為擔保金額，買家付款成功後，擔保部分進入平台方中間擔保賬戶，未擔保金額直接入賣家支付賬戶或者賣家銀行賬戶； （3）、收單退款交易：買賣雙方在達成退款協定後，可針對及時到賬交易，訂金下定等已支付交易由商戶平台發起退款請求； （4）、普通轉賬交易：當平台方需要對會員進行轉賬時，通過此接口實作金額的轉移； （5）、合并支付交易：多筆交易訂單合并（并筆）付款，适用于購物車針對不同商家生成訂單的場景； （6）、下訂交易：賣家和買家達成購買協定，先行支付部分訂金，該部分訂金在最終付款的時候可以被使用； （7）、提現：客戶将支付賬戶的餘額提到客戶綁定的銀行卡賬戶，基于支付賬戶單筆或者批量付款； （8）、當機解凍：在交易前通過當機能力将使用者的部分資金當機，保障交易能正常進行，也可以由于某些原因（賬戶被盜、司法案件、反洗錢等），當機使用者資金操作，保證使用者的資金安全； （9）、充值：基于支付賬戶做餘額充值，将使用者的銀行卡賬戶資金充到使用者的支付賬戶餘額。
交易系統的交易特性歸類：
①實效性：
（1）、全額實時到賬：即時到賬類交易，付款後實時到賬； （2）、部分确認支付、部分即時到賬：擔保收單類交易，這裡分為部分擔保的場景，隻有指定金額部分需要确認結算； （3）、全額确認支付：全額擔保交易，電商交易場景下需使用者确認收貨後才會将全部貨款結算給賣家。
②交易系統的支付形式：
（1）、單筆支付交易：單筆支付行為，使用者基于一筆訂單發起付款； （2）、合并支付交易：多筆合并支付行為，使用者基于多筆訂單發起合并付款；
③業務類型：
（1）、收單交易：支付入款類型交易，付款人收款人分别是兩個角色； （2）、充值交易：賬戶充值類交易，付款人和收款人都是同一個人，由外部賬戶到内部賬戶； （3）、出款交易：基于賬戶做提現，付款人和收款人都是同一個人，由内部賬戶到外部賬戶； （4）、退款交易：收單入款交易的反向流程。
會員系統是完整的支付平台内極其重要的基礎子產品之一，負責管理支付系統内部的交易主體。會員系統儲存了客戶在支付系統内部賬号的實體資訊，為客戶建立了統一的、以會員 ID 為辨別的會員基本資訊、關系資訊（會員和賬戶、會員和操作人、會員與銀行卡）視圖。
一般情況，會員在支付系統内部分為個人會員和企業會員（預設企業會員有商戶權限），以電商平台為例，C 端使用者為個人會員，B 端商戶為企業會員：
通常，企業會員會配置一定的業務參數，比如結算周期、接口權限、支付方式配置等（開通商戶權限的情況下）；
在大多數網際網路公司，支付系統僅需要對接支付管道的子產品，在沒有獨立平台化的情況下，不太會出現需要獨立的賬戶體系。
支付層包含支付核心、賬務核心以及清算核心三個部分。
下方的内容介紹了支付核心的職責、邊界以及系統架構三個部分。
支付核心的職責：
支付系統的職責為通過支付核心與後端清結算、會計、賬務等系統的統一協作，讓前端支付産品可以更關注産品本身的邏輯，而減少對清分、對賬、儲值等後端服務的考量及動作；同時通過标準化的支付指令定義，統一前端支付産品的支付請求接口，提供适應各類産品使用的基礎支付服務。
支付核心的邊界：
（1）、支付服務：負責對後端支付系統的接口進行業務包裝，同時實作使用多個支付方式進行組合支付的功能； （2）、支付服務流程：對各支付類型的支付服務流程進行定義，具體定義為充值、提現、内轉支付（轉賬）、退款等原子類型，并實作對基礎服務的流程編排； （3）、支付指令：發起訂單後，通過協定和協定明細項加工得出支付指令，需具備進行後續操作處理的全部要素資訊； （4）、支付協定：根據産品設立支付協定，是以支付協定的關鍵要素包含産品碼及支付編碼，定義着産品的處理流程、收付款資訊、對應的支付管道資訊。
支付核心的系統架構：
如圖，将交易和支付分開，主要是為了展現出支付系統的核心支付功能，能夠為會員提供豐富的支付服務：支付核心定義原子支付類型；服務層提供支付業務能力，例如出款、轉賬、紅包、代金券、餘額、現金等；産品層能夠更加關注産品本身的邏輯，将後端标準化的邏輯交由支付層和清算層來處理，這樣就能做到靈活和标準兼顧。
賬務核心的功能為，根據前端業務系統的要求設計相比對的賬戶類型、管理各類賬戶、記錄賬戶資金變動等，同時，按照公司内部的财會規範提供反映各賬戶間交易資金變化情況的會計資料；并且負責将自身記錄賬務流水與支付管道結算資金和結算流水進行核對，對對賬結果中出現的差錯交易進行差錯處理。
清算核心負責維護客戶參與交易時的清分、結算規則，并按照已配置的規則完成交易資金的清分與結算操作。