中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

記得第一次看埃隆·馬斯克（Elon Musk）講第一性原理的視頻時，深受震撼，原來還可以這樣處理復(fù)雜的事務(wù)。

這篇文章也嘗試化繁為簡，探尋支付系統(tǒng)的本質(zhì)，講清楚在線支付系統(tǒng)最核心的一些概念和設(shè)計(jì)理念。

一、十年前各大公司支付系統(tǒng)架構(gòu)圖

看一下十年前各大互聯(lián)網(wǎng)公司支付系統(tǒng)架構(gòu)圖，就會發(fā)現(xiàn)最基礎(chǔ)的偏底層的那部分到現(xiàn)在也很有參考價值，但是性能、可用性、基礎(chǔ)架構(gòu)等已經(jīng)發(fā)生了天翻地覆的變化。

比如根據(jù)公開資料，2019 年雙11 支付寶的支付峰值為54.4 萬筆/秒，真實(shí)承載能力應(yīng)該遠(yuǎn)高于此。創(chuàng)新的業(yè)務(wù)也發(fā)生了極大的變化，比如京東白條的橫空出世，在海外旅游可以直接用支付寶或微信掃碼付款等。

曬幾個網(wǎng)上公開的圖（來源在圖片右下角的水印上有，版權(quán)歸原作者），圖雖然有點(diǎn)老，但基礎(chǔ)的產(chǎn)品功能到現(xiàn)在也適用。

某團(tuán)的：

某Q旅游的：

某東金融的：

某蟻金服的：

二、基本概念

下面描述的概念大部分做了極致簡化，只是用于入門，對于理解概念應(yīng)該是夠用的。真實(shí)的實(shí)現(xiàn)會復(fù)雜非常多。

這些概念如同支付核心系統(tǒng)拼圖的一些小碎片，串起這些小碎片，就是一個完整的支付系統(tǒng)大圖。

另：后面的描述中，經(jīng)?；熘谩爸Ц断到y(tǒng)”、“支付平臺”，“支付機(jī)構(gòu)”，“收單機(jī)構(gòu)”，本質(zhì)是一個東西。在內(nèi)部來說，就是一個支付系統(tǒng)，但從和外部機(jī)構(gòu)交互來說，就是一個支付平臺。對用戶來說是支付，對商戶來說就是幫商戶收單。

2.1. 最簡支付流程

說明：

1. 這是一個最簡化的支付流程。真實(shí)的交互比這個復(fù)雜得多，單收銀臺渲染就可以寫一整篇文章。但對于講清楚支付系統(tǒng)的作用，已經(jīng)足夠。
2. 從圖中可以引申出支付系統(tǒng)最核心的作用：幫商戶收錢。所以有牌照的也稱“收單機(jī)構(gòu)”。如果沒有資質(zhì)，只是做信息轉(zhuǎn)發(fā)，也被稱為“收單轉(zhuǎn)接”。
3. 有支付當(dāng)然就有退款、撤銷等逆向操作，復(fù)雜的跨境支付還會有外匯交易，跨境結(jié)算等業(yè)務(wù)。

2.2. 最簡清結(jié)算流程

說明：

1. 這里畫的是信息流。
2. 銀行和支付平臺之間是機(jī)構(gòu)對機(jī)構(gòu)的關(guān)系，通常使用清算概念，因?yàn)榻鹑跈C(jī)構(gòu)之間大部分情況下會由獨(dú)立的清算機(jī)構(gòu)完成清算服務(wù)。
3. 支付平臺和商戶之間，通常使用結(jié)算概念，由支付平臺直接打款給商戶。（清算與結(jié)算區(qū)別是中文環(huán)境才會有，本質(zhì)是一個東西）
4. 上面畫的是結(jié)算到商戶開在支付平臺的內(nèi)部賬戶余額，所以需要商戶手動提現(xiàn)，支付平臺通常也支持直接結(jié)算到卡，這樣就不需要商戶手動提現(xiàn)。
5. 清結(jié)算三個字還有另外一層含義：清分 + 結(jié)算。前者是把錢算清楚，后者是真實(shí)打款。也有些公司叫清分清償，前者算好錢怎么分，后面完成債權(quán)任務(wù)關(guān)系的完結(jié)。本質(zhì)也是一個東西。

2.3. 最簡本對本收單流程

說明：

1. 所謂本對本收單，就是指商戶的商品標(biāo)價幣種、向支付系統(tǒng)的下單幣種、用戶支付幣種、商戶結(jié)算幣種都是同一個幣種。不涉及到外匯交易。
2. 一個中國人拿著中國招商銀行信用卡在中國境內(nèi)通過多多買了兩斤山東大櫻桃，就是標(biāo)準(zhǔn)的本對本收單。

2.4. 最簡跨境收單流程

說明：

1. 所謂跨境收單，就是結(jié)算給商戶的幣種和用戶支付的幣種不一樣，需要經(jīng)過外匯機(jī)構(gòu)換匯。
2. 在扣款EUR成功后，支付平臺會調(diào)用外部的外匯機(jī)構(gòu)進(jìn)行鎖匯。
3. 在銀行清算后，支付平臺再調(diào)用外部的外匯機(jī)構(gòu)進(jìn)行真正的換匯。
4. 最后支付平臺結(jié)算給商戶USD。
5. 上面也是只是跨境的一個小場景，真實(shí)的跨境場景極為豐富和復(fù)雜。不信你問問這段時間做俄羅斯生意收盧布的朋友們。

如果換成時序圖，如下：

說明：

1. 上面之所以有鎖匯，是因?yàn)橥鈪R時刻在變化，支付平臺不想承擔(dān)匯損風(fēng)險(xiǎn)，直接在支付款里加點(diǎn)手續(xù)費(fèi)。能力強(qiáng)的支付機(jī)構(gòu)也不需要鎖匯，更高風(fēng)險(xiǎn)，但可能有更多收益。
2. 還有些渠道直接提供空中換匯的能力。比如土耳其用戶使用TRY進(jìn)行支付，在支付成功后，由渠道側(cè)直接換匯成USD，然后由渠道直接結(jié)算USD給支付平臺。
3. 一般來說，很多國家的貨幣是受管制的，無法自由出境，如果使用空中換匯直接拿到的就是USD，就比較容易出境。
4. 涉及跨境場景下，往往需要設(shè)計(jì)各種各樣的資金流，最主要是考慮合規(guī)訴求，某次是收益。如果能力強(qiáng)，利用流動性管理，資金量大，收益還是非常可觀的，畢竟外面不像某國要求備付金100%繳存央行，還不給利息。

2.5. 稍復(fù)雜的跨境支付示例

我們以最典型的電商購物舉個例子（只是舉例）：小明使用PayPal在拼多多電商（海外）通過多多錢包（海外）支付了50美金。

經(jīng)過簡化后的交互圖如下：

說明：

1）持牌的第三方支付機(jī)構(gòu)和電商是獨(dú)立的法律主體，所以多多錢包和多多電商是互相獨(dú)立的，需要走獨(dú)立的結(jié)算。

2）為突出重點(diǎn)，中間省略了很多中間機(jī)構(gòu)，比如花旗通過清算網(wǎng)絡(luò)才能轉(zhuǎn)賬到匯豐，清算網(wǎng)絡(luò)先略過。

3）為簡化描述，還有幾個假設(shè)：

• 假設(shè)拼多多電商選擇結(jié)算到銀行卡。還有一個場景是電商選擇結(jié)算到余額，然后自己手動提現(xiàn)。
• 假設(shè)單幣種場景，跨幣種場景還涉及到外匯兌換。

2.6. 最簡信息流與資金流

說明：

1. 用戶在支付平臺充值10元，支付平臺向銀行發(fā)起扣款請求，這些指令操作歸屬于信息交互，屬于信息流。
2. 真實(shí)資金流：銀行賬戶余額的變動。比如：銀行在內(nèi)部把用戶的余額減10元，給支付平臺備付金賬戶加10元。
3. 虛擬資金流：支付平臺內(nèi)部賬戶余額的變動。比如：支付平臺內(nèi)部把銀行應(yīng)收賬戶加10元，給用戶余額賬戶加10元。
4. 為什么會有真實(shí)資金流和虛擬資金流之分？因?yàn)槲覀冋嬲苣玫藉X的地方是銀行，在支付系統(tǒng)內(nèi)看到的只是一個數(shù)字，如果想變成真實(shí)世界的錢，還得發(fā)給銀行提現(xiàn)。

2.7. 加入結(jié)算的極簡信息流與資金流

在支付流程中，就是商戶委托收單機(jī)構(gòu)（支付平臺）把用戶的錢收回來，然后再把錢結(jié)算給商家。

下面以典型通過外部渠道的卡支付為例說明。

說明：

1. 用戶的錢最終會走到商戶的收款銀行賬戶。真實(shí)情況下用戶的支付的錢會分成多份，包括通道收的費(fèi)用，支付平臺收的手續(xù)費(fèi)，稅費(fèi)，營銷分潤，商戶結(jié)算款等。通道費(fèi)用還可以繼續(xù)細(xì)分為發(fā)卡行手續(xù)費(fèi)，收單行手續(xù)費(fèi)，清算機(jī)構(gòu)手續(xù)費(fèi)等。
2. 跨行一般都需要通過清算機(jī)構(gòu)，這里為簡化也沒有畫出來。
3. 支付平臺內(nèi)部的資金流在詳細(xì)版中給出。

2.8. 極簡跨境收單的協(xié)議關(guān)系

說明：

1. 這只是跨境收單的一種協(xié)議關(guān)系，真實(shí)場景存在多種形態(tài)。
2. 上述的收單機(jī)構(gòu)是持牌的，但是沒有跨境結(jié)算的能力，所以需要委托有跨境結(jié)算牌照的金融機(jī)構(gòu)代為處理跨境結(jié)算業(yè)務(wù)。
3. 跨境電商平臺只是一個商戶平臺，沒有收單資質(zhì)，所以需要委托收單機(jī)構(gòu)給它下面的供應(yīng)商結(jié)算打款。
4. 剩下的協(xié)議關(guān)系都是一目了然的，只是我們?nèi)粘]有注意。比如用戶和電商平臺之間在注冊時就會有會員協(xié)議要簽署。
5. 特殊的情況下，一些實(shí)力雄厚的機(jī)構(gòu)，比如螞蟻、財(cái)付通、連連支付、空中云匯等，下面會成立多個實(shí)體，然后用不同的實(shí)體去申請不同的牌照（收單、銀行、外匯、跨境代發(fā)等），這樣表面上全部是一家公司搞定，但是實(shí)際的協(xié)議關(guān)系仍然是上面這樣的，在各實(shí)體之間仍然需要簽署各種協(xié)議。
6. 如果是本對本收單場景就簡單很多，沒有外匯和跨境結(jié)算這一層關(guān)系，如果跨境電商的貨品全部是電商實(shí)體自營的，那就更簡單，沒有供應(yīng)商委托結(jié)算的協(xié)議。
7. 一般電商平臺在沒有牌照情況下是不能開設(shè)余額賬戶的，如果電商想開通余額，可以委托第三方有牌照的公司托管（通常也是收單機(jī)構(gòu)，收單機(jī)構(gòu)一般會同時申請PA、PG牌照），這種情況下，電商平臺和收單機(jī)構(gòu)還會簽署賬戶委托協(xié)議。

2.9. 極簡跨境資金方案

說明：

1. 這是一個典型的跨境資金流案例。用戶支付USD，收單機(jī)構(gòu)收到的是USD，但是需要結(jié)算CNY給中國境內(nèi)的商戶。
2. 收單機(jī)構(gòu)（也就是支付平臺）需要先將USD兌換成CNH（離岸人民幣），再由入境代發(fā)機(jī)構(gòu)把CNY結(jié)算給中國境內(nèi)商戶。這是所謂的“結(jié)匯入境”。
3. 如果采用“入境結(jié)匯”的方式，則收單機(jī)構(gòu)直接結(jié)算USD給商戶在境外的銀行賬戶中，由商戶以USD匯入境內(nèi)，再兌換成CNY?；蛘呤諉螜C(jī)構(gòu)先把USD匯入境內(nèi)備付金賬戶，再兌換成CNY，然后再結(jié)算CNY給中國境內(nèi)商戶。
4. 以上這些不同的資金處理方案，統(tǒng)稱為資金方案。
5. 不同的資金方案，一方面要考慮合規(guī)的訴求，另一方面就是考慮收益最大化，以及資金周轉(zhuǎn)的時效性。

2.10. 渠道路由

渠道路由核心作用是當(dāng)有多個渠道同時滿足業(yè)務(wù)訴求時，綜合支付成功率、支付成本、用戶體驗(yàn)、渠道狀態(tài)等多種因素挑選出最優(yōu)的一條渠道。

具體如下：

1. 提高支付成功率：通過選擇最合適的渠道，可以提高支付的成功率，減少支付失敗帶來的用戶流失。原因在于不同的渠道在其內(nèi)部的風(fēng)險(xiǎn)偏好是不一樣的，同一個請求在A渠道會失敗，但在B渠道會成功。
2. 優(yōu)化成本：不同渠道的費(fèi)用可能不同，通過合理的路由，可以降低支付成本。一些渠道還有階梯收費(fèi)，需要通過分流不同的渠道，保持整體成本最優(yōu)。
3. 提升用戶體驗(yàn)：快速、穩(wěn)定的支付體驗(yàn)?zāi)茉鰪?qiáng)用戶的滿意度和忠誠度。用戶如果經(jīng)常在A渠道支付，新的請求過來后，仍然發(fā)給A渠道支付的成功率往往會更高。
4. 負(fù)載均衡：將支付請求合理分配到不同的渠道，避免某個渠道過載，提升整體系統(tǒng)的穩(wěn)定性。

2.11. 簡明復(fù)式記賬

金融機(jī)構(gòu)的記賬一定是基于復(fù)式記賬法。下面以用戶通過支付平臺使用銀行支付500塊為例做個簡要說明。

假設(shè)：支付平臺使用CMB做為收單行，在CMB開設(shè)有備付金賬戶。

涉及的支付平臺內(nèi)部賬戶：

記賬步驟：

說明：

1. 持牌支付機(jī)構(gòu)的記賬一定是復(fù)式記賬法。內(nèi)部開設(shè)了很多賬戶和科目。

• 【借記類】賬戶：資產(chǎn)，應(yīng)收款等；
• 【貸記類】賬戶：負(fù)債，所有者權(quán)益，應(yīng)付款等；

2. 借貸簡要公式（不太嚴(yán)謹(jǐn)，但是夠用）：

• 【借記類】賬戶（如資產(chǎn)，應(yīng)收款），【增加】為【借】，【減少】為【貸】；
• 【貸記類】賬戶（如負(fù)債和所有者權(quán)益，應(yīng)付款），【增加】為【貸】，【減少】為【借】；

3. 復(fù)式記賬的專業(yè)書籍很多，這里只摘錄幾個重要的說明：

• 復(fù)式記賬法定義：對每項(xiàng)經(jīng)濟(jì)業(yè)務(wù)按相等的金額在兩個或兩個以上有關(guān)賬戶中同時進(jìn)行登記的方法。
• 記賬原則：有借必有貸，借貸必相等。
• 記賬依據(jù)：會計(jì)恒等式：1. 資產(chǎn) = 負(fù)債 + 所有者權(quán)益；2. 利潤 = 收入 – 費(fèi)用。
• 賬戶：具有一定格式和結(jié)構(gòu)，能夠用來連續(xù)、系統(tǒng)、全面的記錄反映某種經(jīng)濟(jì)業(yè)務(wù)的增減變化及其結(jié)果。
• 科目：同類財(cái)務(wù)交易的分類，比如資產(chǎn)、負(fù)債、所有者權(quán)限、收入或費(fèi)用等都屬于科目。一般科目會分為多級。
• 賬戶和科目的區(qū)別：科目只有名字，賬戶包括結(jié)構(gòu)和格式，每個賬戶對應(yīng)一個特定的科目。

2.12. 賬戶分類

在賬務(wù)系統(tǒng)中，通常包含以下幾種賬戶類型：

1. 客戶賬戶：對客可見。包括：對私的個人客戶賬戶，對公的商戶賬戶。
2. 內(nèi)部賬戶：對客不可見。包括：頭寸、手續(xù)費(fèi)收入、過渡戶（也稱中間戶）等。

2.13. 記賬方向

說明：

1. 賬戶類型與借貸方向，相同為加，相異為減，也就是所謂的：DD+，DC-，CC+，CD-。
2. 示例：用戶提現(xiàn)100元，記賬如下：

DR：用戶余額（負(fù)債類賬戶）100

CR：提現(xiàn)過渡戶（負(fù)債類賬戶）100

2.14. 實(shí)時記賬與緩沖記賬

一般來說，客戶賬戶的記賬需要是實(shí)時的，比如用戶充值、提現(xiàn)，商家提現(xiàn)，用戶退款等。

這些賬戶如果不做實(shí)時記賬，一來有損用戶體驗(yàn)，二來有資損風(fēng)險(xiǎn)。比如用戶充值100塊，如果延時不到賬，用戶可能會投訴。如果提現(xiàn)不實(shí)時記賬，用戶有可能重復(fù)提現(xiàn)成功。如果退款不實(shí)時記賬，有可能在退款場景下被透支。

假設(shè)記賬需要幾十毫秒（數(shù)據(jù)庫性能決定的），一個賬戶最高也就只支持幾十個TPS的記賬請求，對于一些高并發(fā)的賬戶（也稱為熱點(diǎn)賬戶）一定是性能不足的。這個時候一般使用緩沖記賬，以提高性能。開通緩沖記賬的，通常是內(nèi)部賬戶或允許商戶透支的流出場景。

緩沖記賬通常就是先記錄流水，然后起定時任務(wù)去撈取流水，匯總后進(jìn)行記賬。前提是一定要做好資損防控。

除了緩沖記賬外，還有拆分賬戶的方式來解決熱點(diǎn)賬戶問題。

2.15. 會計(jì)科目與會計(jì)分錄

會計(jì)科目就是把會計(jì)要素進(jìn)行分類，比如資產(chǎn)、負(fù)債等。通常都會有多級分類。

會計(jì)科目示例：

說明：

1. 一般支付系統(tǒng)使用三級科目就已經(jīng)足夠。部分特別復(fù)雜的系統(tǒng)，可能會用到五級科目。
2. 為便于理解，上面的示例做了很大的精簡，各公司內(nèi)部對科目的編制差異可能會比較大。

2.16. 記賬方案

有了賬戶和會計(jì)科目，發(fā)生一筆交易時，如何讓系統(tǒng)自動去記賬？這個是記賬方案做的事。其中一個解決方案就是給不同的交易場景制定不同的交易碼，通過交易碼來驅(qū)動記賬。

下面是一個典型的支付系統(tǒng)的記賬方案示例。

2.17. 會計(jì)日與日切

會計(jì)日，也稱為會計(jì)結(jié)算日或賬務(wù)結(jié)算日，是支付平臺在會計(jì)周期中進(jìn)行賬務(wù)處理和結(jié)算的特定日期。比如在分布式環(huán)境下，各機(jī)器可能存在時間差，一筆交易在零點(diǎn)時有可能跨天處理，如何判斷一筆交易歸屬于哪天，就依據(jù)會計(jì)日來計(jì)算。

所謂日切，簡單理解就是切換到下一個會計(jì)日。主要做的工作：

1. 借貸試算平衡：也就是所謂“有借必有貸，借貸必相等”這條會計(jì)恒等式的落地。
2. 父子科目試算平衡。
3. 總賬試算平衡。
4. 日、月、季度、年匯總。
5. 會計(jì)日變更。

日切試算平衡核心邏輯：

1. 借方發(fā)生額 = 貸方發(fā)生額
2. 借方余額 = 貸方余額
3. 期末余額 = 期初發(fā)生額 + 發(fā)生額
4. 父科目累積額 = 子科目累積額

2.18. 對賬差異處理

對賬一般有幾種結(jié)果：

1. 對平：雙方交易類型、單號、狀態(tài)、幣種、金額都是一致的。
2. 長款：我方多錢。支付長款：支付90塊，渠道清算100塊，或我方失敗，渠道成功。退款長款：退款100塊，渠道清算90塊。充值長款、提現(xiàn)長款類比。
3. 短款：我方少錢。支付短款：支付00塊，渠道清算90塊。退款長款：退款90塊，渠道清算100塊。充值短款、提現(xiàn)短款類比。

因?yàn)槲曳胶颓乐g有一定的時間差，所以長短款在T+1對賬對不上時，往往先進(jìn)入存疑清單里面，第T+2對賬還是對不上，才會進(jìn)入差異處理。

2.19. 銀行通道三層對賬體系

第一層是信息流明細(xì)對賬。我方流水和銀行清算文件的流水逐一核對?？赡軙嬖陂L短款情況。

第二層是賬單對賬。就是把我方流水匯總生成我方賬單，然后把銀行流水匯總生成銀行賬單，進(jìn)行對賬?？赡軙嬖阢y行賬單和我方賬單不一致的情況，比如共支付100萬，渠道分2次打款，一筆98萬，一筆2萬。

第三層是賬實(shí)對賬。就是我方內(nèi)部記錄的銀行頭寸和銀行真實(shí)的余額是否一致?？赡艽嬖谖曳接涗浀念^寸是220萬，但是銀行實(shí)際余額只有200萬的情況。

2.20. 支付記賬

我們通常說的記賬，哪怕是一筆簡單的支付，也會有多次記賬。具體在什么節(jié)點(diǎn)記什么賬，一般由財(cái)務(wù)人員決定。

下面是一個典型的使用銀行通道進(jìn)行支付的記賬，會涉及網(wǎng)關(guān)過渡戶，渠道待清算，商戶待結(jié)算，手續(xù)費(fèi)，銀行頭寸等多個內(nèi)部戶。

說明：

1. 圖中只畫了正常場景，像明細(xì)對賬出現(xiàn)差異（長短款）、賬單對不平（渠道少打款或多打款）等場景沒有畫出來。
2. 上面只是一個典型的記賬方案，真實(shí)的場景有些更簡單，有些更復(fù)雜。
3. 開多個中間賬戶，什么場景下記到哪個賬戶，一般都是由財(cái)務(wù)團(tuán)隊(duì)決定。

2.21. 商戶結(jié)算記賬

商戶結(jié)算和用戶支付是兩個獨(dú)立流程。

以典型的商戶結(jié)算到卡記賬為例，通常涉及商戶待結(jié)算戶，網(wǎng)關(guān)過渡戶，渠道應(yīng)清算，渠道已清算，銀行頭寸等內(nèi)部戶。

說明：

1. 上述是商戶結(jié)算到卡場景。
2. 各公司的內(nèi)部戶編制可能有所不同。

三、簡明產(chǎn)品架構(gòu)圖

所謂產(chǎn)品架構(gòu)圖，簡單的理解，就是站在產(chǎn)品角度，提供什么樣的服務(wù)能力。下面是一個典型的支付系統(tǒng)的產(chǎn)品架構(gòu)圖。實(shí)際實(shí)現(xiàn)時差異會很大，尤其是上面的產(chǎn)品或應(yīng)用層，有很多機(jī)構(gòu)為特殊的行業(yè)提供一些特殊的能力，比如攜程的支付就會有航空方面的B2B業(yè)務(wù)。但基礎(chǔ)的能力基本也就這些。

說明：

1. 這個圖畫得比較簡單，但是已經(jīng)涵養(yǎng)一個支付系統(tǒng)最核心的產(chǎn)品能力。
2. 上面部分是會員或商戶感知的產(chǎn)品能力，包括門戶、收銀臺，收單產(chǎn)品，資金產(chǎn)品等。下面部分是支付系統(tǒng)最核心的服務(wù)，用于支撐對外的產(chǎn)品能力。
3. 如果多跳幾家公司，就會發(fā)現(xiàn)基礎(chǔ)的部分大家都差不太多。

四、極簡支付系統(tǒng)架構(gòu)圖

說明：

1. 這個圖很精簡，但是基本已經(jīng)夠用，應(yīng)付本對本交易這種簡單的業(yè)務(wù)是完全沒有問題的。
2. 一些復(fù)雜的支付系統(tǒng)可能還有外匯、額度中心、產(chǎn)品中心、卡中心等，甚至一個子系統(tǒng)可能會拆分為多個應(yīng)用獨(dú)立部署，比如收單結(jié)算就可以拆成收單和結(jié)算兩個獨(dú)立的應(yīng)用。

五、完整支付系統(tǒng)架構(gòu)圖及各子系統(tǒng)簡介

跳過幾個支付公司，這些基礎(chǔ)的概念在幾家公司都差不太多，區(qū)別是底層技術(shù)實(shí)現(xiàn)。比如RPC框架，數(shù)據(jù)庫，業(yè)務(wù)流程，部署架構(gòu)等。

說明：

1. 這是一比較完整的系統(tǒng)架構(gòu)圖，屬于邏輯劃分。在單體應(yīng)用中，就是一些模塊，在分布式應(yīng)用中，就是一些子域、子應(yīng)用或子系統(tǒng)。
2. 下面針對各子系統(tǒng)/子模板做些簡單介紹。

5.1. 核心系統(tǒng)依賴圖

說明：

1. 簡化起見，只畫了部分系統(tǒng)，比如額度中心、計(jì)收費(fèi)等就沒有畫出來。
2. 同樣簡化起見，部分調(diào)用關(guān)系沒有畫出來，否則交叉起來太亂，比如收銀核心也會調(diào)用卡中心查詢用戶的綁卡信息，且收銀核心也會調(diào)用渠道網(wǎng)關(guān)查詢可用渠道信息等。

5.2. 開放網(wǎng)關(guān)

主要對接商戶，比如下單、支付等接口入口。通常要求有比較高的安全性。部分公司可能會把移動端網(wǎng)關(guān)、PC門戶網(wǎng)關(guān)、商戶通知等能力集成在開放網(wǎng)關(guān)，也可能會單獨(dú)拆出部署。

5.3. 收單結(jié)算

負(fù)責(zé)把商戶的單收下來，并給商戶發(fā)起結(jié)算。承擔(dān)的收單產(chǎn)品包括有：線上收單，線下收單，擔(dān)保交易、即時到賬等，每個公司的商業(yè)策略不同，開出的收單產(chǎn)品會有差異。

有些公司把結(jié)算劃到出款中心，對接銀企直連的渠道。

5.4. 資金產(chǎn)品

承擔(dān)無買賣標(biāo)的的純資金轉(zhuǎn)移能力。典型的有：充值、轉(zhuǎn)賬、提現(xiàn)、代發(fā)。和支付的區(qū)分在于支付是有買賣標(biāo)的，而資金產(chǎn)品沒有。也就是在系統(tǒng)中沒有買賣記錄發(fā)生，但在線下可能有。

資金產(chǎn)品一般需要獨(dú)立的牌照。

5.5. 收銀核心

渲染可用支付方式。包括查詢賬戶是否有余額，查詢營銷是否有營銷券，查詢渠道網(wǎng)關(guān)是否有可用的外部渠道，最后組合成可用支付方式，供前端渲染。

收銀核心就像一個大內(nèi)總管，收到請求后，找商戶平臺核實(shí)身份，找合約平臺核實(shí)權(quán)限，找會員平臺核實(shí)用戶身份，找收單看一下這筆單是否可以繼續(xù)支付，找賬務(wù)中心獲取余額信息，營銷看看有沒有可用的券，找渠道網(wǎng)關(guān)看看沒有可用的渠道，找額度中心看看是否超限額了，找風(fēng)控問一下當(dāng)前支付是否安全，找會員平臺校驗(yàn)支付密碼 … …

5.6. 支付引擎

負(fù)責(zé)真正的扣款或轉(zhuǎn)賬。有些公司叫支付核心。

如果是余額就調(diào)賬務(wù)扣減余額，如果是紅包就調(diào)營銷做核銷，如果是外部銀行通道就調(diào)渠道網(wǎng)關(guān)。

5.7. 渠道網(wǎng)關(guān)

負(fù)責(zé)去外部渠道扣款。通常還會提供渠道路由、渠道咨詢等能力，做得細(xì)的公司可能會把渠道核心和報(bào)文/文件網(wǎng)關(guān)單獨(dú)拆出來。其中渠道核心就提供渠道路由、渠道咨詢、渠道開關(guān)等服務(wù)，報(bào)文/文件網(wǎng)關(guān)負(fù)責(zé)報(bào)文轉(zhuǎn)換、簽名驗(yàn)簽等。

5.8. 會員平臺

管理會員的生命周期，比如注冊、注銷、登錄等。同時還提供核身服務(wù)（比如登錄密碼，支付密碼，短信驗(yàn)證碼等）、實(shí)名認(rèn)證服務(wù)等。

5.9. 商戶平臺

管理商戶的入駐簽約、KYB、交易管理等。

5.10. 產(chǎn)品中心

管理對外提供的產(chǎn)品能力，比如快捷支付，代扣等。一般大的支付系統(tǒng)才會獨(dú)立成一個子系統(tǒng)。

5.11. 賬務(wù)中心

負(fù)責(zé)賬戶開立，記賬等。

5.12. 會計(jì)中心

會計(jì)科目管理、分錄管理、日切管理等。

監(jiān)管報(bào)表有時候也放在這里，有些公司也會獨(dú)立出去。

很多集團(tuán)公司往往有一套獨(dú)立的專業(yè)財(cái)務(wù)系統(tǒng)，這個時候往往需要會計(jì)中心做完日切后，要把記賬信息合并到集團(tuán)公司的財(cái)務(wù)系統(tǒng)中去，簡稱并賬。

5.13. 對賬中心

負(fù)責(zé)明細(xì)對賬和資金對賬。

5.14. 營銷平臺

提供滿減、紅包等營銷工具。

5.15. 風(fēng)控平臺

針對賬戶和交易，提供實(shí)時、離線風(fēng)控，控制交易的風(fēng)險(xiǎn)。反洗錢、反欺詐是基本要求。

通常各公司對風(fēng)控規(guī)則看成是機(jī)密，研發(fā)也可能看不到運(yùn)營配置的規(guī)則。經(jīng)?？吹接芯W(wǎng)友問：“有xx公司的人在嗎？我有xxx場景下的支付總是提示風(fēng)控不過，是否知道是什么原因，怎么才能通過？”，完全是浪費(fèi)口舌，誰會對外公布自己的風(fēng)控規(guī)則，讓人去鉆空子呢？

5.16. 運(yùn)營平臺

訂單管理、渠道管理、產(chǎn)品管理等綜合運(yùn)營工具。

5.17. 數(shù)據(jù)平臺

主要用于數(shù)據(jù)匯總和分析。當(dāng)前各支付公司基本都是分布式部署N多個應(yīng)用，數(shù)據(jù)都在散落在各子系統(tǒng)中，需要匯總到數(shù)據(jù)平臺用于經(jīng)營分析。

5.18. 卡中心

負(fù)責(zé)管理用戶的綁卡信息。需要經(jīng)過PCI認(rèn)證。

5.19. 額度中心

累計(jì)用戶、商戶的額度，通常有日、月、年，單卡等各種分類。

5.20. 外匯平臺

負(fù)責(zé)外匯報(bào)價和兌換。

5.21. 流動性與調(diào)撥中心

一些跨境支付公司，在多個國家多個銀行有頭寸，各頭寸之間經(jīng)常需要做流動性管理，提高資金利用率。

畢竟在國外不需要把備付金強(qiáng)制存到央行還不給利息。當(dāng)資金量大的時候，這筆收益可不少。

5.22. 差錯中心

負(fù)責(zé)差錯處理。比如渠道退款失?。ㄣy行賬號銷戶，過了銀行的退款有效期等），需要通過其它的方式退給用戶。

5.23. 拒付中心

處理用戶的拒付和舉證。在跨境支付場景下，信用卡用戶聯(lián)系發(fā)卡行說卡被盜刷或商品沒有收到，或商品有問題等，拒絕支付給商戶。

國內(nèi)基本沒有看到拒付場景。

六、一些拓展知識

6.1. 技術(shù)風(fēng)險(xiǎn)與資損防控

一般來說，技術(shù)風(fēng)險(xiǎn)主要包含穩(wěn)定性和資損兩個方面。其中穩(wěn)定性風(fēng)險(xiǎn)就是大家經(jīng)常說的幾個9，比如99.999%可用，就是5個9。資損風(fēng)險(xiǎn)就是平臺或用戶的資金損失。

雖然資損也是技術(shù)風(fēng)險(xiǎn)的一種，但是因?yàn)閷τ趯I(yè)的持牌支付公司來，資損是一種非常嚴(yán)重的事故，容易引發(fā)客訴、網(wǎng)絡(luò)事件、甚至監(jiān)管介入，所以又較一般的風(fēng)險(xiǎn)更為嚴(yán)重，常常把資損防控單獨(dú)拿出來說。

技術(shù)風(fēng)險(xiǎn)體系過于龐大，這里只談幾點(diǎn)通用知識。

識別風(fēng)險(xiǎn)來自哪里

我們通常先需要知道風(fēng)險(xiǎn)來自哪里，才知道如何去防控。而風(fēng)險(xiǎn)往往來自變化。舉幾個例子，拋磚引玉：

• 流量變化：大促場景下，流量會暴增。
• 代碼變化：引入了新的代碼。
• 業(yè)務(wù)變化：修改了業(yè)務(wù)流程，或引入了新的業(yè)務(wù)。
• 外部變化：外部新的攻擊手段。

應(yīng)對風(fēng)險(xiǎn)

根據(jù)變化去應(yīng)對風(fēng)險(xiǎn)。比如大促引入了流量變化，那就做壓測、擴(kuò)容、限流、降級非核心業(yè)務(wù)等應(yīng)對。比如原來只有支付，這些有了用戶提現(xiàn)，針對用戶提現(xiàn)，內(nèi)部多個子域可能狀態(tài)/金額不一致，和銀行渠道的狀態(tài)/金額也可能不一致，那就加入各種對賬手段，以及對應(yīng)的應(yīng)急預(yù)案。

內(nèi)部系統(tǒng)實(shí)時與離線對賬

對賬是資損防控中最效的手段之一。

前面講過的三層對賬主要是和銀行渠道對賬，除了這個之外，一般的支付平臺還會有內(nèi)部系統(tǒng)之間的兩兩核對，這種核對主要是信息流層面的核對，主要核對狀態(tài)、金額的一致性。

說明：

1. 可以拆成離線核對和實(shí)時核對。
2. 離線核對一般就是把生產(chǎn)數(shù)據(jù)庫的數(shù)據(jù)定時清洗到離線庫（一般還可以分為天表和小時表）。
3. 實(shí)時核對一般就是監(jiān)聽數(shù)據(jù)庫的binlog，當(dāng)數(shù)據(jù)有變動時，延時幾秒后請求雙方系統(tǒng)的查詢接口，查到數(shù)據(jù)后進(jìn)行核對。

6.2. 冪等

冪等是針對重復(fù)請求的，支付系統(tǒng)一般會面臨以下幾個重復(fù)請求的場景：

1. 用戶多次點(diǎn)擊支付按鈕：在網(wǎng)絡(luò)較差或系統(tǒng)過載情況下，用戶由于不確定交易是否完成而重復(fù)點(diǎn)擊。
2. 自動重試機(jī)制：系統(tǒng)在超時或失敗時重試請求，可能導(dǎo)致同一支付多次嘗試。
3. 網(wǎng)絡(luò)數(shù)據(jù)包重復(fù)：數(shù)據(jù)包在網(wǎng)絡(luò)傳輸過程中，復(fù)制出了多份，導(dǎo)致支付平臺收到多次一模一樣的請求。
4. 異?；謴?fù)：在系統(tǒng)升級或崩潰后，未決事務(wù)需要根據(jù)已有記錄恢復(fù)和完成。內(nèi)部系統(tǒng)重發(fā)操作。

冪等解決方案

所謂業(yè)務(wù)冪等，就是由各域自己把唯一性的交易ID作為數(shù)據(jù)庫唯一索引，這樣可以保證不會重復(fù)處理。

在數(shù)據(jù)庫前面可以加一層緩存來提高性能，但是緩存只用于查詢，查到數(shù)據(jù)認(rèn)為就返回冪等成功，但是但不到，需要嘗試插入數(shù)據(jù)庫，插入成功后再刷新數(shù)據(jù)到緩存。

為什么要使用數(shù)據(jù)庫的唯一索引做為兜底，是因?yàn)榫彺媸强赡苁У摹?/p>

在面臨時經(jīng)常有同學(xué)只回答到“使用redis分布式鎖來實(shí)現(xiàn)冪等”，這是不對的。因?yàn)?strong>緩存有可能失效，分布式鎖只是用于防并發(fā)操作的一種手段，無法根本性解決冪等問題，冪等一定是依賴數(shù)據(jù)庫的唯一索引解決。

大部分簡單的支付系統(tǒng)只要有業(yè)務(wù)冪等基本也夠用了。

6.3. 分庫分表

當(dāng)數(shù)據(jù)量大的時間，分庫分表是再所難免的。一個經(jīng)典的面試題是：如果分了100張表，按商戶來分表，還是按商戶訂單號來分表？如果按商戶分表怎么解決各表流水?dāng)?shù)據(jù)量平衡問題？如果是按商戶訂單號來分表，商戶想按時間段查詢怎么辦？

解法有很多種。一種典型的解法，就是線上數(shù)據(jù)庫按商戶訂單號分表，同時有一個離線庫冗余一份按商戶號分表的數(shù)據(jù)，甚至直接使用離線數(shù)據(jù)平臺的能力，把商戶的按時間段查詢需求從在線庫剝離出來。

6.4. 分布式事務(wù)

分布式事務(wù)是個好東西，但是復(fù)雜度也高，還經(jīng)常出現(xiàn)所謂的事務(wù)懸掛問題，且雖然各家都號稱簡單易用，對業(yè)務(wù)代碼侵入少，但事實(shí)并非如此。

所以我個人更傾向于避免使用分布式事務(wù)解決方案，而是采用最終一致性來解決。對大部分中小公司來說，最終一致性已經(jīng)夠用。

6.5. 金額處理規(guī)范

對于研發(fā)經(jīng)驗(yàn)不足的團(tuán)隊(duì)而言，經(jīng)常會犯以下幾種錯誤：

1. 沒有定義統(tǒng)一的Money類，各系統(tǒng)間使用BigDecimal、double、long等數(shù)據(jù)類型進(jìn)行金額處理及存儲。
2. 定義了統(tǒng)一的Money類，但是寫代碼時不嚴(yán)格遵守，仍然有些代碼使用BigDecimal、double、long等數(shù)據(jù)類型進(jìn)行金額處理。
3. 手動對金額進(jìn)行加、減、乘、除運(yùn)算，單位（元與分）換算。

帶來的后果，通常就是資金損失，再細(xì)化一下，最常見的情況有下面3種：

1. 手動做單位換算導(dǎo)致金額被放大或縮小100倍。
   1. 比如大家規(guī)定傳的是元，但是其中有位同學(xué)忘記了，以為傳的是分，外部渠道要求傳元，就手動乘以100。或者反過來。
   2. 還有一種情況，部分幣種比如日元最小單元就是元，假如系統(tǒng)約定傳的是分，外部渠道要求傳元，就可能在網(wǎng)關(guān)處理時手動乘以100。
2. 1分錢歸屬問題。比如結(jié)算給商家，或計(jì)算手續(xù)費(fèi)時，碰到除不盡時，使用四舍五入，還是向零舍入，還是銀行家舍入？這取決于財(cái)務(wù)策略。
3. 精度丟失。在大金額時，double有可能會有精度丟失問題。

最佳實(shí)踐：

1. 制定適用于公司業(yè)務(wù)的Money類來統(tǒng)一處理金額。
2. 在入口網(wǎng)關(guān)接收到請求后，就轉(zhuǎn)換為Money類。
3. 所有內(nèi)部應(yīng)用的金額處理，強(qiáng)制全部使用Money類運(yùn)算、傳輸，禁止自己手動加減乘除、單位換算（比如元到分）。
4. 數(shù)據(jù)庫使用DECIMAL類型保存，保存單位為元。
5. 在出口網(wǎng)關(guān)外發(fā)時，再根據(jù)外部接口文檔要求，轉(zhuǎn)換成使用指定的單位。有些是元，有些是分（最小貨幣單位）

6.6. 業(yè)務(wù)ID生成規(guī)則

數(shù)據(jù)庫一般都會設(shè)計(jì)一個自增ID作為主鍵，同時還會設(shè)計(jì)一個能唯一標(biāo)識一筆業(yè)務(wù)的ID，這就是所謂的業(yè)務(wù)ID（也稱業(yè)務(wù)鍵）。比如收單域的收單單號。

也有人采用所謂雪花算法，但其實(shí)不適用于支付場景。

下面以32位的支付系統(tǒng)業(yè)務(wù)ID生成為例說明。實(shí)際應(yīng)用時可靈活調(diào)整。

第1-8位：日期。通過單號一眼能看出是哪天的交易。

第9位：數(shù)據(jù)版本。用于單據(jù)號的升級。

第10位：系統(tǒng)版本。用于內(nèi)部系統(tǒng)版本升級，尤其是不兼容升級的時候，老業(yè)務(wù)使用老的系統(tǒng)處理，新業(yè)務(wù)使用新系統(tǒng)處理。

第11-13位：系統(tǒng)標(biāo)識碼。支付系統(tǒng)內(nèi)部每個域分配一段，由各域自行再分配給內(nèi)部系統(tǒng)。比如010是收單核心，012是結(jié)算核心。

第14-15位：業(yè)務(wù)標(biāo)識位。由各域內(nèi)部定，比如00-15代表支付類業(yè)務(wù)，01支付，02預(yù)授權(quán)，03請款等。

第16-17位：機(jī)房位。用于全球化部署。

第18-19位：用戶分庫位。支持百庫。

第20-21位：用戶分表位。支持百表。

第22位：預(yù)發(fā)生產(chǎn)標(biāo)識位。比如0代表預(yù)發(fā)環(huán)境，1代表生產(chǎn)環(huán)境。

第23-24位：預(yù)留。各域根據(jù)實(shí)際情況擴(kuò)展使用。

第24-32位：序列號空間。一億規(guī)模，循環(huán)使用。一個機(jī)房一天一億筆是很大的規(guī)模了。如果不夠用，可以擴(kuò)展到第24位，到十億規(guī)模。

6.7. 狀態(tài)機(jī)設(shè)計(jì)

狀態(tài)機(jī)，也稱為有限狀態(tài)機(jī)（FSM, Finite State Machine），是一種行為模型，由一組定義良好的狀態(tài)、狀態(tài)之間的轉(zhuǎn)換規(guī)則和一個初始狀態(tài)組成。它根據(jù)當(dāng)前的狀態(tài)和輸入的事件，從一個狀態(tài)轉(zhuǎn)移到另一個狀態(tài)。

下圖就是收單子域設(shè)計(jì)中交易單的狀態(tài)機(jī)設(shè)計(jì)。

從圖中可以看到，一共4個狀態(tài)，每個狀態(tài)之間的轉(zhuǎn)換由指定的事件觸發(fā)。

常見代碼實(shí)現(xiàn)誤區(qū)

經(jīng)?？吹焦ぷ鲙啄甑耐聦?shí)現(xiàn)狀態(tài)機(jī)時，仍然使用if else或switch case來寫。這是不對的，會讓實(shí)現(xiàn)變得復(fù)雜，且容易出現(xiàn)問題。

甚至直接在訂單的領(lǐng)域模型里面使用String來定義，而不是把狀態(tài)模式封裝單獨(dú)的類。

還有就是直接調(diào)用領(lǐng)域模型更新狀態(tài)，而不是通過事件來驅(qū)動。

限于篇幅，這里就不給正確的示例了。有興趣的可以去網(wǎng)上看看，良好的示例有很多。

6.8. 日志規(guī)范

只要在公司寫過代碼，就一定打印過日志，但經(jīng)常發(fā)現(xiàn)一些工作多年的工程師打印的日志也是亂七八糟的。我曾經(jīng)在一家頭部互聯(lián)網(wǎng)公司接手過一個上線一年多的業(yè)務(wù)，相關(guān)日志一開始就沒有設(shè)計(jì)好，導(dǎo)致很多監(jiān)控?zé)o法實(shí)現(xiàn)，出了線上問題也不知道，最后只能安排工程師返工改造相關(guān)的日志。

我們要明白日志是用來做什么的。只是先弄明白做事的目的，我們才能更好把事情做對。在我看來，日志有兩個核心的作用：1）監(jiān)控，診斷系統(tǒng)或業(yè)務(wù)是否存在問題；2）排查問題。

對于監(jiān)控而言，我們需要知道幾個核心的數(shù)據(jù)：業(yè)務(wù)/接口的請求量、成功量、成功率、耗時，系統(tǒng)返回碼、業(yè)務(wù)返回碼，異常信息等。對于排查問題而言，我們需要有出入?yún)?、中間處理數(shù)據(jù)的上下文、報(bào)錯的上下文等。

接下來，基于上面的分析，我們就清楚我們應(yīng)該有幾種日志：

1. 接口摘要日志。監(jiān)控接口的請求量、成功量、耗時、返回碼等。使用固定格式，需要打?。簳r間、接口名稱、結(jié)果（成功/失敗)、返回碼、耗時等基本信息就足夠。
2. 業(yè)務(wù)摘要日志。監(jiān)控業(yè)務(wù)的請求量、成功量、核心業(yè)務(wù)信息、返回碼等。使用固定格式，需要打印：時間、業(yè)務(wù)類型、上一步狀態(tài)、當(dāng)前狀態(tài)、返回碼、核心業(yè)務(wù)信息（不同業(yè)務(wù)有不同的核心業(yè)務(wù)信息，比如流入，就有支付金額/退款金額，卡品牌，卡BIN等)。
3. 詳細(xì)日志。用于排查問題，不用于監(jiān)控。格式不固定。主要包括時間、接口、入?yún)?、出參、中間處理數(shù)據(jù)輸入、異常的堆棧信息等。
4. 系統(tǒng)異常日志。同時用于監(jiān)控。格式固定。需要打印：時間、錯誤碼、錯誤信息、堆棧信息等。

6.9. 支付安全

支付安全核心關(guān)注點(diǎn)

支付安全是一個很大的范疇，但我們一般只需要重點(diǎn)關(guān)注以下幾個核心點(diǎn)就夠：

1）敏感信息安全存儲。

對個人和商戶/渠道的敏感信息進(jìn)行安全存儲。

個人敏感信息包括身份證信息、支付卡明文數(shù)據(jù)和密碼等，而商戶/渠道的敏感信息則涉及商戶登錄/操作密碼、渠道證書密鑰等。

2）交易信息安全傳輸。

確?？蛻舳伺c支付系統(tǒng)服務(wù)器之間、商戶系統(tǒng)與支付系統(tǒng)之間、支付系統(tǒng)內(nèi)部服務(wù)器與服務(wù)器之間、支付系統(tǒng)與銀行之間的數(shù)據(jù)傳輸安全。這包括采用加密技術(shù)等措施來保障數(shù)據(jù)傳輸過程中的安全性。

3）交易信息的防篡改與防抵賴。

確保交易信息的完整性和真實(shí)性，防止交易信息被篡改或者被抵賴。一筆典型的交易，通常涉及到用戶、商戶、支付機(jī)構(gòu)、銀行四方，確保各方發(fā)出的信息沒有被篡改也無法被抵賴。

4）欺詐交易防范。

識別并防止欺詐交易，包括套現(xiàn)、洗錢等違規(guī)操作，以及通過識別用戶信息泄露和可疑交易來保護(hù)用戶資產(chǎn)的安全。這一方面通常由支付風(fēng)控系統(tǒng)負(fù)責(zé)。

5）服務(wù)可用性。

防范DDoS攻擊，確保支付系統(tǒng)的穩(wěn)定運(yùn)行和服務(wù)可用性。通過部署防火墻、入侵檢測系統(tǒng)等技術(shù)手段，及時發(fā)現(xiàn)并應(yīng)對可能的DDoS攻擊，保障支付服務(wù)的正常進(jìn)行。

極簡支付安全大圖

支付安全是一個綜合性的系統(tǒng)工程，除了技術(shù)手段外，還需要建立健全的安全制度和合規(guī)制度，而后兩者通常被大部分人所忽略。

下圖是一個極簡版的支付安全大圖，包含了支付安全需要考慮的核心要點(diǎn)。

說明：

1）制度是基礎(chǔ)。

哪種場景下需要加密存儲，加密需要使用什么算法，密鑰長度最少需要多少位，哪些場景下需要做簽名驗(yàn)簽，這些都是制度就明確了的。制度通常分為行業(yè)制度和內(nèi)部安全制度。行業(yè)制度通常是國家層面制定的法律法規(guī)，比如《網(wǎng)絡(luò)安全法》、《支付業(yè)務(wù)管理辦法》等。內(nèi)部安全制度通常是公司根據(jù)自身的業(yè)務(wù)和能力建立的制度，小公司可能就沒有。

2）技術(shù)手段主要圍繞四個目標(biāo)：

1. 敏感數(shù)據(jù)安全存儲。
2. 交易安全傳輸。
3. 交易的完整性和真實(shí)性。
4. 交易的合法性（無欺詐）。

對應(yīng)的技術(shù)手段有：

• 敏感信息安全存儲：采用加密技術(shù)對個人和商戶/渠道的敏感信息進(jìn)行加密存儲，限制敏感信息的訪問權(quán)限，防止未授權(quán)的訪問和泄露。
• 交易信息安全傳輸：使用安全套接字層（SSL）或傳輸層安全性協(xié)議（TLS）等加密技術(shù)，確保數(shù)據(jù)在傳輸過程中的機(jī)密性和完整性。
• 交易的完整性和真實(shí)性：采用數(shù)字簽名技術(shù)和身份認(rèn)證技術(shù)確保交易信息的完整性和真實(shí)性，對交易信息進(jìn)行記錄和審計(jì)，建立可追溯的交易日志，以應(yīng)對可能出現(xiàn)的交易篡改或抵賴情況。
• 防范欺詐交易：通過支付風(fēng)控系統(tǒng)，及時識別和阻止可疑交易行為。
• 服務(wù)可用性：部署流量清洗設(shè)備和入侵檢測系統(tǒng)，及時發(fā)現(xiàn)并阻止惡意流量，確保支付系統(tǒng)的穩(wěn)定運(yùn)行和服務(wù)可用性，抵御DDoS攻擊。

七、結(jié)束語

所謂提綱挈領(lǐng)，就是先掌握核心主干，有了這個前提，再去深入了解細(xì)節(jié)，才不至于“亂花漸欲迷人眼”，解決問題時才能如庖丁解牛，行云流水。偉人鄧公提倡的“抓住主要矛盾”，也是這個道理。

本文主要講了一些支付核心系統(tǒng)相關(guān)的基本概念，希望能為大家在學(xué)習(xí)在線支付系統(tǒng)相關(guān)知識時能提供一些有益的參考。

猶記得N年前那天早上，我穿上最帥的襯衣、筆挺的西裝褲、賊亮的皮鞋，推開房門，清風(fēng)徐來，朝陽燦爛，一如我的心情，意氣風(fēng)發(fā)。那是我進(jìn)入正值蓬勃發(fā)展的第三方支付行業(yè)的第一天。

入職當(dāng)天老板扔了很多文檔給我，看了一周，沒看懂。想起老祖宗說的“讀書百遍，其義自見”，繼續(xù)苦讀一周，仍然是霧里看花。不幸中的萬幸，是挺過了試用期。直到多年后的一天，整理老舊硬盤的資料，才發(fā)現(xiàn)一方面是自己愚鈍，另一方面也是那些資料寫得過于晦澀難懂。于是萌發(fā)一個念頭：要不我自己也總結(jié)總結(jié)？這是其中的一篇。

斗轉(zhuǎn)星移，外面的陽光依然燦爛，襯衣、西裝褲、皮鞋卻已不知何處去了。