使用這些基本 REST API 最佳實踐構建出色的 API
在賬務系統中，通常包含以下幾種賬戶類型：
說明：
DR：用戶余額（負債類賬戶）100
CR：提現過渡戶（負債類賬戶）100
一般來說，客戶賬戶的記賬需要是實時的，比如用戶充值、提現，商家提現，用戶退款等。
這些賬戶如果不做實時記賬，一來有損用戶體驗，二來有資損風險。比如用戶充值100塊，如果延時不到賬，用戶可能會投訴。如果提現不實時記賬，用戶有可能重復提現成功。如果退款不實時記賬，有可能在退款場景下被透支。
假設記賬需要幾十毫秒（數據庫性能決定的），一個賬戶最高也就只支持幾十個TPS的記賬請求，對于一些高并發的賬戶（也稱為熱點賬戶）一定是性能不足的。這個時候一般使用緩沖記賬，以提高性能。開通緩沖記賬的，通常是內部賬戶或允許商戶透支的流出場景。
緩沖記賬通常就是先記錄流水，然后起定時任務去撈取流水，匯總后進行記賬。前提是一定要做好資損防控。
除了緩沖記賬外，還有拆分賬戶的方式來解決熱點賬戶問題。
還沒有畫好，占個坑。
會計科目就是把會計要素進行分類，比如資產、負債等。通常都會有多級分類。
會計科目示例：
說明：
有了賬戶和會計科目，發生一筆交易時，如何讓系統自動去記賬？這個是記賬方案做的事。其中一個解決方案就是給不同的交易場景制定不同的交易碼，通過交易碼來驅動記賬。
下面是一個典型的支付系統的記賬方案示例。
會計日，也稱為會計結算日或賬務結算日，是支付平臺在會計周期中進行賬務處理和結算的特定日期。比如在分布式環境下，各機器可能存在時間差，一筆交易在零點時有可能跨天處理，如何判斷一筆交易歸屬于哪天，就依據會計日來計算。
所謂日切，簡單理解就是切換到下一個會計日。主要做的工作：
日切試算平衡核心邏輯：
對賬一般有幾種結果：
因為我方和渠道之間有一定的時間差，所以長短款在T+1對賬對不上時，往往先進入存疑清單里面，第T+2對賬還是對不上，才會進入差異處理。
還沒有畫好，占個坑。
第一層是信息流明細對賬。我方流水和銀行清算文件的流水逐一核對。可能會存在長短款情況。
第二層是賬單對賬。就是把我方流水匯總生成我方賬單，然后把銀行流水匯總生成銀行賬單，進行對賬。可能會存在銀行賬單和我方賬單不一致的情況，比如共支付100萬，渠道分2次打款，一筆98萬，一筆2萬。
第三層是賬實對賬。就是我方內部記錄的銀行頭寸和銀行真實的余額是否一致。可能存在我方記錄的頭寸是220萬，但是銀行實際余額只有200萬的情況。
我們通常說的記賬，哪怕是一筆簡單的支付，也會有多次記賬。具體在什么節點記什么賬，一般由財務人員決定。
下面是一個典型的使用銀行通道進行支付的記賬，會涉及網關過渡戶，渠道待清算，商戶待結算，手續費，銀行頭寸等多個內部戶。
說明：
商戶結算和用戶支付是兩個獨立流程。
以典型的商戶結算到卡記賬為例，通常涉及商戶待結算戶，網關過渡戶，渠道應清算，渠道已清算，銀行頭寸等內部戶。
說明：
金融機構的記賬一定是基于復式記賬法。下面以用戶通過支付平臺使用銀行支付500塊為例做個簡要說明。
假設：支付平臺使用CMB做為收單行，在CMB開設有備付金賬戶。
涉及的支付平臺內部賬戶：
| 賬戶類型 | 賬戶 | 備注 |
|---|---|---|
| 借記賬戶 | 應收-渠道-CMB | 應收歸屬借記賬戶 |
| 貸記賬戶 | 應付-過渡-網關過渡戶應付-平臺托管-商戶待結算應付-平臺托管-商戶余額手續費收入-商戶-消費 | 應付歸屬貸記賬戶手續費意味著所有者權益增加，歸屬貸記賬戶 |
記賬步驟：
| 階段 | 操作賬戶 | 金額 |
|---|---|---|
| 第一步資金從渠道到網關過渡戶 | 借：應收-渠道-CMB貸：應付-過渡-網關過渡戶 | 500500 |
| 第二步扣除手續費 | 借：應付-過渡-網關過渡戶貸：手續費收入-商戶-消費 | 1010 |
| 第三步網關過渡戶到商戶待結算賬戶 | 借：應付-過渡-網關過渡戶貸：應付-平臺托管-商戶待結算 | 490490 |
| 第四步結算給商戶 | 借：應付-平臺托管-商戶待結算貸：應付-平臺托管-商戶余額 | 490490 |
說明：
【借記類】賬戶：資產，應收款等；
【貸記類】賬戶：負債，所有者權益，應付款等；
2. 借貸簡要公式（不太嚴謹，但是夠用）：
【借記類】賬戶（如資產，應收款），【增加】為【借】，【減少】為【貸】；
【貸記類】賬戶（如負債和所有者權益，應付款），【增加】為【貸】，【減少】為【借】；
3. 復式記賬的專業書籍很多，這里只摘錄幾個重要的說明：
復式記賬法定義：對每項經濟業務按相等的金額在兩個或兩個以上有關賬戶中同時進行登記的方法。
記賬原則：有借必有貸，借貸必相等。
記賬依據：會計恒等式：1. 資產 = 負債 + 所有者權益；2. 利潤 = 收入 – 費用。
賬戶：具有一定格式和結構，能夠用來連續、系統、全面的記錄反映某種經濟業務的增減變化及其結果。
科目：同類財務交易的分類，比如資產、負債、所有者權限、收入或費用等都屬于科目。一般科目會分為多級。
賬戶和科目的區別：科目只有名字，賬戶包括結構和格式，每個賬戶對應一個特定的科目。
支付平臺尤其是持牌的收單機構通過都會提供非常多的服務，除了常見的支付、退款、提現等業務外，還會提供個人賬單查詢，商戶賬單下載等服務。
這里只介紹對客（包括個人客戶和商戶）感知的最核心的幾個服務。
一個持牌支付機構的系統一般會提供以下幾個核心的對客能力：
支付（收單）：幫商戶把用戶的錢從扣到支付平臺的賬戶。
撤銷：沒有支付成功的直接關閉訂單，已經支付成功的錢退回給用戶。
退款：把用戶支付的錢退回給用戶。
清算：外部渠道把錢給到支付平臺。
結算：支付平臺把錢結給商家。
充值：用戶把錢充值到在平臺開的余額賬戶。
轉賬：用戶或商戶賬戶之間進行轉賬。
代發：幫商戶把錢轉到個人用戶的賬戶。有代發到卡和代發到余額。
調撥：支付平臺內部因為流動性管理的需要，在多個銀行賬戶之間轉賬。
提現：用戶把錢從平臺的余額賬戶中提現到外部的銀行卡。
一些跨境場景下，支付系統還需要提供外匯服務，比如中國商家在多多的海外品牌temu賣貨，用戶在美國支付的是美元，但是中國商家需要在中國拿到人民幣。
除此之外，還會有很多輔助能力，比如商戶入駐，商戶自助服務，個人自助服務等。
任何一個業務在支付系統內部都是由多個子域經歷很多操作步驟才能完成。比如支付業務的下單子流程，先是入口網關的驗簽，解密，然后請求商戶平臺的權限校驗，再請求風控系統做風控校驗，產品中心做產品校驗等，最后在收單域保存入庫。
說明：
資金流在后面的賬務章節會詳細介紹，這里只做個簡單說明。
首先是虛擬資金流，也就是支付平臺內部的資金流，以即時到賬模式為例，如下：
說明：
實體資金流就是外部銀行之間的資金流轉。
說明：
說明：
外部渠道支付成功、或退款成功，都會涉及清算流程，簡單地說，就是外部渠道把當天的支付、退款交易數據先進行軋差，然后生成一個清算文件，支付平臺拿到這個文件后，解析并與內部的交易進行對賬，對賬成功后，從待清算戶到應清算戶，在渠道真實打款后，查到賬單，再從應清算到銀行頭寸。
更詳細的可以參考后面的賬務域內容。
說明：
在收單機構（支付平臺）里，結算就是把幫商戶收進來的錢，按約定的結算規則、準確、及時地結算給商戶。
結算前需要先做清分，就是把一筆支付的錢，根據當初簽訂的合約分成若干份。比如支付100塊，平臺手續費1塊，商戶99塊。
根據合約，可以結算到余額，也可以結算到卡，結算還有結算周期，也就是所謂的T+n，其中的T是指交易時間，n指第幾天結算。比如T+0就是當天的交易當天結算，T+2就是當天的交易在第3天才結算。
充值就是把用戶的錢充到支付平臺余額賬戶。余額因為涉及到資金安全，所以無論國內國外基本上都是需要持牌經營。
很多持牌機構都想讓用戶做充值，好處也很明顯，比如：
充值的核心只有2個點：
轉賬、代發、調撥的本質就是把資金從一個賬戶轉到另一個賬戶。三者之間有一些細微的區別：
還有兩種比較特殊的轉賬，就是發紅包和AA收款。一對一的紅包，本質就是一對一的轉賬，一對多的紅包，本質就是一對多轉賬。AA收款的本質就是多對一的轉賬。
以轉賬到銀行卡為例，用戶A把自己的余額100元轉給B用戶在招行的銀行卡，如下：
說明：
提現的本質也是轉賬，只是用戶把支付平臺余額賬戶的錢，轉到自己在外部渠道的賬戶里。
與一般意義上的轉賬的區別在于，通常情況下說的轉賬是不同用戶或商戶之間的轉賬，而提現默認是自己余額賬戶的錢提到自己開設在外部銀行的賬戶。比如支付寶或微信余額提現到自己在招行的賬戶里。
外匯業務表面上只是把一種貨幣換成另外一種貨幣，但是實際情況下是非常復雜的。比如需要區分自由流動貨幣和管制貨幣，交易有即期、遠期、掉期等，涉及跨境電商有結匯入境和入境結匯。另外，外匯市場是全球最大的金融市場。
無收單機構模式
這就是小時候去小賣部買糖的模式，一手交錢一手交貨。
好處：足夠簡單。不足：無法完成線上交易。
行內收單模式
所謂行內收單，就是發行卡和收單是同一家銀行。
好處：手續費低，成功率高。不足：業務比較受限，以線下收單為例，商戶無法部署所有的銀行POS機。
發卡行與收單行分離模式
大部分情況下，用戶的發卡行和商戶的收單行是不同的銀行。
不過，這種情況基本也已經滅絕，因為需要發卡行和收單行兩兩對接，形成一個巨大的網狀結構，維護成本高昂。
清算機構模式
發卡行和收單行之間不再直連，而是通過清算機構。清算機構通常是央行下面的特許經營的金融機構。這樣圍繞清算機構形成一個星形架構，所有銀行只需要和清算機構對接就行。
當前銀行間的交易基本上是這種形態。比如中國的銀聯，國外的VISA，MASTERCARD等，是卡組，也是清算機構。
第三方支付（電子錢包）形態
隨著互聯網支付的興起，以第三方支付為中心形成另外一個星形結構。
上圖做了很大的簡化。在中國因為斷直連的關系，支付寶、微信支付背后的財付通等這些第三方支付機構都是對接銀聯、網聯，而不是直連銀行。但是在國外仍然是允許直連銀行的。
支付前需要調用收銀臺查看用戶可用的支付方式，簡稱支付咨詢，或支付方式咨詢。
上面的圖分別是電商（京東）的收銀臺，支付平臺（微信支付）的收銀臺。說明收銀臺是有多種存在形式的。
支付咨詢階段，需要做以下幾個工作：
最后把支付方式返回給用戶，供用戶在支付時選擇。
用戶選擇好支付方式，點擊“確認支付”，就到了支付受理階段。主要做以下幾個工作：
特別說明一下：為什么輪詢結果是從收單平臺而不是支付引擎？因為對用戶而言，收單的結果代表最終的支付結果。比如用戶支付回來后，支付引擎是成功的，但是收單平臺因為已經訂單過期關閉，就會發起資金退回操作，這樣收單平臺的訂單實際是沒有支付成功的。就會提示用戶：“訂單已關閉，如果已經扣款，支付款項預計在X個工作日內原路退回。”
有些公司稱為通道，有些公司稱為渠道，都是一個意思。下面統一稱為渠道。
渠道類型在各個公司的定義是不一樣的，沒有一個行業標準，且持續在發展。先講幾個當前仍然通用的分類。
從資金流轉的角度，渠道分為四大類：支付渠道、流出渠道、外匯渠道、信息渠道。
支付渠道
這類渠道的核心作用是實現用戶資金的流入。具體來說，它們將用戶在銀行賬戶中的資金轉移到支付平臺在銀行的備付金賬戶。這個過程在我們日常生活中極為常見，典型的場景包括用戶的充值操作和在線支付。
例如，當你使用手機應用進行購物支付時，資金從你的銀行賬戶流向支付平臺的賬戶，最后再結算給商戶，就是通過這類渠道完成的。
流出渠道
相對于資金的流入，流出類渠道則處理資金的流出。這包括兩種主要情形：
流出類渠道確保了資金在用戶和商戶之間的順暢流動，是整個支付系統的重要支撐。
外匯渠道
這類渠道涉及貨幣兌換和跨國資金轉移，支持不同貨幣間的轉換和結算。在跨境電商、國際旅游等場景中，外匯渠道提供了跨幣種資金轉換的關鍵服務。且隨著全球化貿易的增長，跨境支付需求日益增加，外匯渠道的作用變得更加重要。
信息渠道
這類渠道不涉及資金流轉，比如個人實名認證（KYC），銀行卡綁卡（純綁卡）等。
支付類渠道
隨著業務和技術的發展，支付類的渠道定義也是千奇百怪，或者說是與時俱進，下面是一些通用的分類。
卡渠道
借記卡/信用卡支付：這是最傳統且廣泛使用的支付方式之一。用戶通過輸入卡信息進行支付，資金直接從其銀行賬戶扣除。其中信用卡還有預授權、請款，2D、3D等場景。
還有所謂的預付卡，就是提前充值的支付卡，用戶支付時，資金從預付卡余額中扣除。這個在支付平臺一般不感知。
歐美國家的信用卡支付普遍使用得比較多。
除了使用卡明文直接支付外，現在很多渠道還支持先綁定后使用token支付的模式：
支付流程和卡明文支付差不多，只是在發給渠道的報文中使用token替換了卡明文。
卡支付的交易有所謂的四方模式：商戶、收單行、卡組、發卡行。這里的四方指的是四種類型的機構。
網銀渠道
通過跳轉到銀行網站完成支付。這個操作麻煩，可能還需要密碼控件，成功率不高，在中國已經很少使用。國外還有不少。
快捷支付渠道
用戶事先在支付平臺綁定銀行卡，支付時無需重復輸入卡信息，便捷快速。在中國率先被支付寶發明出來并被推廣，支付成功率從網銀的60%左右提升到了96%以上。
國外有些叫“一鍵支付”，差不多一個意思。
代扣渠道
代扣支付是一種銀行或第三方支付平臺在用戶授權的基礎上，直接從用戶的銀行賬戶或關聯的支付賬戶中自動扣除款項的支付方式。
這種方式和快捷支付最大的區別在于：快捷支付是用戶實時參與交易過程，有可能出風控挑戰，比如OTP（短信驗證碼），或者密碼等。代扣是提前授權，交易過程用戶不會實時參與，也就沒辦法出挑戰，要不成功，要不失敗。
代扣廣泛用于周期性支付場景，如水電費自動繳納、會員服務費、訂閱服務等，還有就是滴滴打車這種，下車就走。這種方式免去了用戶每次手動支付的麻煩。
第三方錢包渠道
基于第三方錢包賬戶基礎之上的支付。在中國有支付寶、微信支付等，在國外有PayPal，GCash等。
第三方錢包通常是一個綜合支付工具，除了錢包余額，錢包里面可能還綁定了銀行卡。
錢包通常提供兩種交互模式：
VA渠道
Virtual Account, 虛擬賬戶。用戶通過銀行生成的虛擬賬號進行支付，常用于無卡支付場景。在東南亞用得特別多。
簡單地說，就是用戶沒有銀行卡，但是又要在網上購物，那么支付平臺調用銀行生成一個VA，并把這個VA和訂單綁定，再展示給用戶，用戶拿著這個VA，去銀行的ATM或銀行柜臺把現金存進去，銀行通知支付平臺這個VA入賬成功，支付平臺通知商戶發貨。
VA還會用于商家的收款（VA來賬），這個是另外一個范圍，不歸屬于支付類渠道。
OTC渠道
Over-The-Counter，柜臺支付。在支付場景下，和VA很類似，也是生成一個支付碼，只是這個支付碼是由7-11，肯德基等這些連鎖店生成的，而VA是銀行賬戶。用戶拿著這個OTC碼去線下連鎖店，給店員現金，店員給這個OTC碼充值，連鎖店系統通知支付平臺支付成功，支付平臺通知商戶發貨。
信用付渠道
渠道根據用戶的信用授予一定的額度，可以先消費，后還款。國外通常叫BNPL（Buy Now Pay Later)。
國內有支付寶的花唄，京東的白條。國外也有很多第三方金融機構提供類似的服務。
支付流程和第三方錢包差不多，只是需要先做開戶和額度授權。
信用付與信用卡分期的區別：信用卡分期是以銀行發行的信用卡為基礎，而信用付基于第三方金融機構的賬戶授權（沒有卡，非銀行也能提供服務）。
在一些銀行卡普及率不高的國家地區，信用付很有優勢。
渠道路由核心作用是當有多個渠道同時滿足業務訴求時，綜合支付成功率、支付成本、用戶體驗、渠道狀態等多種因素挑選出最優的一條渠道。具體如下：
說明：
說明：
說明：
說明：
如果換成時序圖，如下：
說明：
我們以最典型的電商購物舉個例子（只是舉例）：小明使用PayPal在拼多多電商（海外）通過多多錢包（海外）支付了50美金。
經過簡化后的交互圖如下：
說明：
說明：
在支付流程中，就是商戶委托收單機構（支付平臺）把用戶的錢收回來，然后再把錢結算給商家。
下面以典型通過外部渠道的卡支付為例說明。
說明：
說明：
說明：
說明：
支付安全核心關注點：
支付安全是一個很大的范疇，但我們一般只需要重點關注以下幾個核心點就夠：
對個人和商戶/渠道的敏感信息進行安全存儲。
個人敏感信息包括身份證信息、支付卡明文數據和密碼等，而商戶/渠道的敏感信息則涉及商戶登錄/操作密碼、渠道證書密鑰等。
確保客戶端與支付系統服務器之間、商戶系統與支付系統之間、支付系統內部服務器與服務器之間、支付系統與銀行之間的數據傳輸安全。這包括采用加密技術等措施來保障數據傳輸過程中的安全性。
確保交易信息的完整性和真實性，防止交易信息被篡改或者被抵賴。一筆典型的交易，通常涉及到用戶、商戶、支付機構、銀行四方，確保各方發出的信息沒有被篡改也無法被抵賴。
識別并防止欺詐交易，包括套現、洗錢等違規操作，以及通過識別用戶信息泄露和可疑交易來保護用戶資產的安全。這一方面通常由支付風控系統負責。
防范DDoS攻擊，確保支付系統的穩定運行和服務可用性。通過部署防火墻、入侵檢測系統等技術手段，及時發現并應對可能的DDoS攻擊，保障支付服務的正常進行。
所有支付公司都對資損（資金損失）看得很重，輕則錢沒了，重則輿論風波，要是引起監管介入，更是吃不了兜著走。
常在河邊走的支付人，如果想少濕鞋，一定要了解資損防控體系建設。
資損本質
資損防控本質
資損防控全生命周期
資損風險分類
資損場景有很多種，但分類只有下面幾大類：
資損場景及應對
過于龐大，略過。
一圖勝千言，希望這精選出來的60張高清大圖對大家學習支付系統設計與實現有所幫助。
內容主要包括支付系統核心業務，支付流程，結算流程，跨境收單，信息流與資金流，賬戶設計，記賬，對賬等。
相關的概念大部分做了極致簡化，用于入門是極好的，對于理解概念也是夠用的。不過真實的實現會復雜非常多。
這些概念如同支付核心系統拼圖的一些小碎片，串起這些小碎片，對理解支付系統大圖是大有裨益的。
文章轉自微信公眾號@隱墨星辰