大部分公司，只要想賺錢，就得上支付系統，讓使用者或者客戶有地方交錢。 當然，公司發展的不同階段，對支付系統的定位和架構也不同。整體上來說，我們可以把乙個公司的支付系統發展分為三個階段：
支付系統：支付作為乙個（封閉）的、獨立的應用系統，為各系統提供支付功能支援。一般來說，這個系統僅限於為公司內部的業務提供支付支援，並且和業務緊密耦合。
支付服務：支付作為乙個開發的系統，為公司內外部系統、各種業務提供支付服務。支付服務本身應該是和具體的業務解耦合的。
支付平台：支付作為乙個可擴充套件的平台， 公司內外部的使用者可以在此基礎上定製開發自己的服務。
這個劃分有點勉強。簡單說，支付系統是僅供內部使用的， 支付服務是支援公司內外部來呼叫的，支付平台是可以在服務的基礎上定製各種場景支援的。
區分兩個概念:支付和交易。支付是交易的一部分。乙個簡單的交易過程包括:客戶下訂單，客戶完成支付，商家接收訂單，商家出貨。這裡僅考慮下訂單的流程。從軟體工程的角度， 我們首先需要明確下幾個參與者。
支付系統，可以是電商系統的乙個模組，或者是個獨立的系統。這是本文的主角，用來完成支付過程。
使用者，在電商系統中敗家的那位。如果使用銀行卡做交易，那也被稱為持卡人。
使用者使用銀行卡交易時，發行這個銀行卡的機構稱為發卡行，或者發卡機構。
商家也需要一張卡，就是大家在**開**的時候要登記的銀行卡，最終需要把使用者給的錢打到這張卡上。
主演都有了，下面就是如何演出支付這場大戲了。正常的流程應該是這樣：
使用者提交訂單到電商系統，電商系統對訂單進行檢驗，無問題則調起支付介面執行支付。注意這裡支付介面是在伺服器端調起的。一般支付介面很少從客戶端直接調起。為了安全，支付介面一般要求用https來訪問，並對介面做簽名。關於支付介面的設計，我將另起博文介紹。
2.支付系統檢查引數有效性，特別是簽名的有效性。
5.呼叫收單介面執行支付。這是支付系統的核心。每個公司的收單介面都不一樣，接入一兩個收單機構還好，接入的多了，如何統一這些介面，就是乙個設計難點。
6.支付成功，收單機構把錢打到商戶的賬戶上了。 商家就準備發貨了。 怎麼發貨，不是本文的重點。 這裡關注的要點是， 商家能收到多少錢？ 比如100塊錢的商品，使用者支付了100塊錢（運費、打折等另算），這100塊錢，還要刨去電商系統的佣金、支付通道的手續費，才能最終落到商家手裡。
和錢打交道，在任何公司，都跑不掉財務部門。 那財務部門會關注哪些內容？ 當然，最重要的是賬務資訊。 所有的交易都要記賬，按要求公司都需要定期做審計，每一筆帳都不能出錯。這當然不能等到審計的時候再去核對，而是每天都需要對賬，確保所有的交易支出相抵，也就是所說的把賬給平了。 這就有三種情況： 電商系統和商家對賬；電商系統和支付系統對賬；支付系統和收單機構對賬。最為支付系統，我們僅關注後兩者的情況。
從軟體開發角度， 還有一些非功能性需求需要實現：
所以支付的坑還不少，我們先看看網際網路的頭牌們是如何設計支付系統的？ 先看看某團的：
再看某q旅遊公司的的：
對比下某東金融的：
最後看看業界最強的某金服金融的：
整體上來說， 從分層的角度，支付系統和普通的業務系統並沒有本質的區別，也是應用、服務、介面、引擎、儲存等分層。 在應用層，支付系統一般會提供如下子系統：
支付應用和產品.(應用層)： 這是針對各端（pc web端、android、ios)的應用和產品。 為各個業務系統提供收銀台支援，同時支付作為乙個獨立的模組，可以提供諸如銀行卡管理、理財、零錢、虛擬幣管理、交易記錄查閱、卡券等功能；
支付運營系統(應用層)： 支付系統從安全的角度來說，有乙個重要的要求是，懂**的不碰線上，管運營的不碰**。這對運營系統的要求就很高，要求基本上所有線上的問題，都可以通過運營系統來解決。
支付bi系統(應用層): 支付中產生大量的資料，對這些資料進行分析， 有助於公司老闆們了解運營狀況，進行決策支援。
風控系統(應用層)：這是合規要求的風險控制、反洗錢合規等。
信用資訊管理系統(應用層)：用來支援對信用演算法做配置，對使用者的信用資訊做管理。
其他各層功能：
支付服務層：為上述各端系統提供api。這些api也可以提供給業務系統直接使用。
引擎層： 包括統計分析、風控、反洗錢、信用評估等在後台執行的各個系統。
儲存層： 各種持久化的資料庫支援。
這其實也是普通網際網路應用系統架構，沒有什麼特別之處。比如微服務如何體現，如何滿足效能需求等，在這個檢視中無法體現出來。這只是個軟體角度的高層檢視，後續我們對各個主要模組進行分解，從分解檢視中可以知道如何滿足非功能性需求。
支付系統整體架構
支付產品模組是按照支援場景來為業務放提供支付服務。這個模組一般位於支付閘道器之後，支付渠道之前。它根據支付能力將不同的 支付渠道封裝成統一的藉口，通過支付閘道器對外提供服務。所以，從微服務的角度，支付產品本身也是乙個 模式的微服務，它透 過支付閘道器響應業務放請求，進行一些統一處理後，分發到不同的支...
支付公司系統架構概述
2.後台系統 每個前置系統都會對應不同後台系統。用來處理一些邏輯。3.交易引擎 支付閘道器 支付公司會有乙個統一的交易引擎來處理支付請求。對請求做一些處理，如核實風控資訊。賬戶訊息等，然後根據使用者選擇的資金平台，呼叫不同系統。如選擇了銀行卡快捷支付，則銀行閘道器 支付路由會選擇適合的通道完成交易。...
第三方支付系統架構
工作已四年，接觸了銀行和第三方支付行業，根據現公司的情況梳理了一下我自己認為的關於第三方支付系統的架構。如下圖 關於第三方支付系統，涉及到的系統大概有以下幾部分 2 業務處理 應該提供業務處理系統，儲存相應的業務資訊，即訂單資訊 4 財務系統 對商戶進行結算 打款 退款 5 客服系統 處理客戶投訴 ...