訂單視角看支付

支付是指為清償商品交換和勞務活動所引起的債權債務，貨幣債權從付款人向收付人的轉移的過程。支付能力是電商產品的核心能力之一，作為訂單同學，有必要了解關聯域支付的流程以及基本概念，同時支付領域的很多設計思路與資損防控經驗對訂單域的系統設計也很有借鑑意義。本文將從支付系統的歷史、基本概念、系統設計、資損防控與訂單與支付互動等方面予以介紹。

一、支付系統歷史與演進

支付的歷史演進可以追溯到現金交易的起源。隨著時間的推移和科技的不斷進步，支付系統經歷了多個階段和變革。

起源：票號與錢莊

票號是應埠際匯兌需求而開設的金融專營機構，主要經營存款、匯款、匯兌三大基本業務，是現代銀行的雛形。客戶在票號交了銀子之後，票號就開出匯票給客戶。客戶可以隨身攜帶匯票而不用攜帶大量的銀子，只要憑票就可以到全國各地的分號兌出銀子。分號給客戶兌換之後先內部記賬，各分號間定期會當面進行對賬。鏢局就專為票號來運送銀子、為商人運送票據。在這種模式下，匯票+賬本（手工記賬）是票號在支付環節的資訊載體，解決了資訊流問題；鏢局替票號運送資金，解決了資金流的問題。

第一階段：手工聯行（1989前）

早期，國內的金融環境沒有達到讓央行推行全國統一結算制度的客觀條件。於是央行當時提出商業銀行要“自成聯行系統，跨行直接通匯，相互發報移卡，及時清算資金”。同一家銀行的總行及分支機構稱為“聯行系統”。同一聯行內的資金結算，由聯行總行自己做。跨行業務可以由央行清算，也可以由商業銀行自己清算。在這種模式下，各銀行需要告知其他行的交易資訊構成了特定的公文，加蓋印鑑後在銀行間傳送。這種公文叫做聯行信件，而當時的郵電局則承擔了收發聯行信件的重要業務。

聯行信件整個過程基本都是手工處理，與明清時期的票號相比，並沒有太大的改進。雖然執行成本較低，但容易出現差錯，且資金匯劃效率依舊不高，導致佔壓在途結算資金較多，如異地間資金的匯劃，少則 10 多天、多則半年才能完成資金到賬。

第二階段：電子聯行（1989~2005）

1990 年，中國人民銀行清算中心建成，專門為金融機構提供支付清算服務。清算中心包括 NPC（National Process Center，國家金融清算總中心）和 CCPC（City Clearing Processing Center，城市處理中心）。1991 年 4 月 1 日，全國電子聯行系統（EIS）開始試執行。EIS 是基於金融衛星通訊網的，它是人民銀行專門用於處理異地（包括跨行和行內）資金清算和資金劃撥的系統。它連線了商業銀行、央行、NPC 和 CCPC。以一位上海招行銀行卡的使用者要給持有北京工行銀行卡的朋友進行匯款，使用 EIS 完成一次支付清算的案例如下圖所示：

藉助全國電子聯行系統，傳票和憑證已變為加密後的電文，與紙質聯行相比，進步巨大。客戶的資金在途時間縮短到了一兩天，大大提高了資金清算的效率，可以說是一個重要的里程碑。

第三階段：現代化支付系統（2005~至今）

中國人民銀行支付清算系統（China National Automatic Payment System）是為我國金融機構之間以及金融機構與人民銀行之間的支付業務提供最終資金清算的重要核心業務系統，整體架構如下圖所示：

簡單介紹下該系統的幾個核心子系統：

在現代化支付系統投產之前，即使是電子聯行系統也需要一到兩天才能能夠到賬，而現代化支付系統將支付後實時到賬變為可能，極大的提高了支付效率，提升了消費者的支付體驗。技術變革往往會帶來新的商業機會和變革，推動企業進行創新。國內的主流電子商務與電子支付平臺起也從 2003 年開始興起，這裡現代化支付系統的投產時間（2002年、2005年）非常接近，很難說兩者之間毫無聯絡。

二、支付系統基本概念

核心概念

支付系統一般指提供支付清算服務、實現支付指令傳送及資金清算的系統，由有支付牌照的支付公司提供。支付系統是連線消費者、商戶（或平臺）和金融機構的橋樑，實現了支付、資金清算、查詢統計等功能。這裡系統的解釋一下涉及到的相關名詞，便於我們後文展開詳細介紹。

常用支付形式

平臺支付

使用者提前註冊並登入到第三方支付平臺，並且已經在該平臺上完成綁卡等操作後，透過第三方支付平臺進行支付。

網銀支付

使用者在完成必要的銀行網銀開通手續後，可以透過銀行的網銀系統進行線上支付和轉賬。在進行網銀支付時，使用者需要登入銀行網銀系統，輸入相應的支付資訊並進行身份驗證，然後可以完成線上支付交易，移動網際網路時代較為少用。

快捷支付

一種簡化了支付流程的支付方式。通常情況下，使用者在首次支付時需要繫結銀行卡或者進行一次認證，之後就可以使用該支付方式來完成交易，無需重複輸入銀行卡資訊或進行繁瑣的身份驗證。在後續的支付過程中，使用者只需進行簡單的確認操作或者輸入支付密碼，就能夠快速完成交易。

協議支付

協議支付也稱代收或者代扣，代收指渠道授權商戶可以從使用者的銀行賬戶中扣款，一般用於定期扣款，如水電煤氣、有線電視費、包月/包年會員費等。

虛擬貨幣支付

不少公司會有自己的虛擬幣，這些虛幣也可以作為一種支付方式。一般會有一些金額、品類的限制，如虛擬支付不得超過每筆訂單結算金額的 50%。

餘額支付

為使用者建立本地賬戶並使用賬戶來完成支付，賬戶支援充值、提現等操作。

信用支付

指使用信用賬戶進行透支，類似信用卡支付。需要較強的風控能力。

三、支付系統簡介

整體架構

在瞭解了支付系統相關演進與基本概念後，我們再來看一下支付系統的整體架構。對於訂單同學來說，在實際支付業務的接入過程中，可以接觸到兩類支付系統：

第三方支付系統：即訂單同學理解裡的“支付渠道”。比如我們作為商戶直接對接到微信、支付寶的支付系統中，從而具備支付收款能力。整個系統中的“核心系統”功能往往是大家最為熟悉的部分，它概括了我們平時各種消費支付場景。我們平時進行的電商交易、紅包轉賬等都是“支付應用”的體現形式。

實踐中，三方支付系統往往可以拆分為閘道器、金融交換、收單域、支付域以及賬務域、會員域、營銷域等多個領域。

聚合支付系統：即訂單同學通常理解裡的“支付”。主要功能為遮蔽各種第三方支付系統的差異性，提供統一的接入方式和支付產品，比如得物的匯金系統。

一個比較典型的電商平臺的支付架構

支付流程

使用者支付流程

從流量角度來看，對於一次使用者發起的支付行為，請求首先達到支付閘道器，經過必要的安全驗證和流量限制後，被轉發給對應的支付服務模組。隨後使用者跳轉收銀臺頁面選擇支付方式後確認支付，由支付系統對接銀行/第三方支付機構的支付介面進行後續的支付。

支付介面

以業內某支付產品為例，其提供了多種整合支付能力的方式，其中「手機網頁支付」適用於商戶無獨立 App，透過移動端 H5 網站進行傳播的方式。我們以一次手機網頁支付為例，瞭解支付的核心介面。

如上圖所示，可以從交易支付的幾個環節進行分析。

支付介面

在商戶的 H5 網站下單並確認支付。
商戶系統生成訂單資訊並構造支付請求傳送到該支付產品系統。
系統校驗透過後拼裝本次支付所需引數返回給商戶前端。
商戶前端將頁面跳轉至該支付產品官方中間頁，如果使用者手機上安裝了該支付產品 App，則自動喚起 App；如果未安裝，則繼續在當前頁面進入官方 H5 收銀臺。
使用者完成密碼輸入並支付。
系統內部完成本次支付單處理流程。
處理完成後，以非同步訊息形式通知商戶後臺 Notify_URL，確認此次交易成功。
處理完成後，從官方中間頁跳轉商戶自定義支付結果頁 Return_URL，展示支付結果。
完成本次支付。

交易關閉介面

針對需要的業務場景，支援主動取消訂單（針對未支付訂單，已支付單可走退款流程）。

使用者發起/商戶後臺管理員發起訂單取消申請。
商戶系統向該支付產品系統發起關閉訂單請求。
後臺判斷處理後返回取消結果。

交易查詢介面

商戶後臺發起交易查詢請求。
系統判斷交易單存在，並返回交易結果。

退款介面

使用者/商戶發起退款請求
商戶系統稽核處理退款申請是否合法。
合法情況下，商戶系統向該支付產品系統發起退款請求。
系統處理並返回結果。
相關渠道將資金返回（有一定時間延遲）。

退款查詢介面

使用者/商戶發起退款查詢請求。
系統處理後返回結果。

下載對賬單介面

商戶系統根據業務對賬需要，發起對賬申請，查詢最新的對賬單下載地址。
系統返回對賬單下載地址。商戶系統根據對賬單下載地址下載對賬檔案。
系統返回對賬單檔案。

資金流與資訊流

央行在 2017 年 8 月釋出《關於將非銀行支付機構網路支付業務由直連模式遷移至網聯平臺處理的通知》，規定了非金融支付機構受理涉及銀行賬戶的網路支付業務全部透過網聯處理。目前業內採用的都是“間連”模式提供網路收單服務。這裡以一次銀行卡網路收單支付交易流程為例，整體資金流與資訊流如下：

【資訊流】步驟 1 使用者透過電商支付收銀臺下單並支付，電商支付處理支付業務資料，並將支付請求發到第三方支付渠道。
【資訊流】步驟 2 第三方支付將請求轉發至網聯。
【資訊流】步驟 3 網聯將支付扣款請求轉發到髮卡行。
【資金流】步驟 4 髮卡行從使用者銀行卡扣款，使用者銀行卡金額減少，返回支付成功給網聯。
【資訊流】步驟 5 網聯記錄支付成功資料，返回支付成功給三方支付。
【資訊流】步驟 6 三方支付回撥電商支付系統，更新支付狀態和記錄支付資訊。電商支付回撥訂單系統，更新訂單狀態，給使用者返回下單成功。
【資金流】步驟 7 網聯週期性對三方支付業務做清結算，透過央行清算系統做資金清算劃撥到三方支付機構備付金託管所在銀行。
【資訊流】步驟 8 三方清結算服務對貨款商戶支付交易記錄做清算和結算，具體細節如下：

清算服務根據交易要素對商戶主體交易按照約定的計費規則進行清算，記錄商戶主體因為商業交易而產生的債務債權，週期性生成對應的結算憑證。
結算服務按照約定結算週期和方式對商戶主體產生的債權債務進行清償,請求網聯結算打款。

【資金流】步驟 9 網聯透過週期性清結算方式形式做資金劃撥到商戶收款所在銀行。
【資訊流】步驟 10 商戶結算收款銀行賬戶顯示貨款到賬。

從上圖看，步驟 1 到步驟 6 體現了付款方付一筆錢的流程，表示了三方支付一筆收單業務的資訊流和資金流，其中步驟 4 中付款方的銀行卡餘額會被實時扣減，髮卡行側記應付未付。步驟 5 網聯記錄支付交易相關資料作為跨行清結算業務的依據。步驟 6 三方支付側更新支付交易結果並逐層通知至訂單系統，同時把支付成功訊息同步給三方的清結算，清結算依據交易支付的結算要素做清分分錄，記錄商戶應結資金和應收手續費。步驟 7 屬於資金流。由網聯負責跨行週期清算，網聯透過央行清算系統完成資金劃撥後資金到了三方備付金賬戶。步驟 8 屬於資金流。三方支付完成周期性結算憑證生成後透過網聯發起結算打款，最終資金到賬時間依賴於網聯清算+資金劃撥的時間。自此，一筆電商交易經過使用者銀行卡扣款、網聯清結算、三方支付清結算，最終實現錢貨兩清。

資金結算

清結算是對交易支付資料進行全面整理、計算、彙總、檢查核對和最終結算的過程，可拆分為清算和結算兩個子域。清算域服務根據交易推送的資訊，按照約定的計費規則進行清分、彙總，記錄主體因商業交易而產生的債務債權，並定期生成相應的結算憑證。結算域根據約定的結算週期和方式，對商戶主體產生的債權債務進行清償。清結算確保了金融交易的安全性和準確性，保障各方權益。

抽象的來看，支付涉及業務主要可分為收、付、退、提、轉、充等 6 大類（對於訂單同學來說更關心的是收、付、退三大功能，對應訂單的購買、履約、售後三個子域）。資金結算一般分實時結算與定期結算，我們以定期結算為例，分析整體資金結算的簡版流程。

計費

計費為透過對應的計費規則將業務流水訊息轉換為清結算的資金語言，生成對應的結算資金明細。

匹配以交易業務的流水資訊路由匹配到相應的計費規則。
清分根據計費規則，將資金劃分給交易中的不同角色，生成對應的計費結果與資金分攤明細。簡單來說就是算清楚哪個費用項，多少錢，誰給誰。
分錄落地計費明細與結算明細變更。

彙總

根據清算明細，按照資金指令以及時間段進行彙總操作。

校驗

主要是對整個結算的模型、指令以及單據、任務的完整性校驗，以及賬務資金核對檢查等，確保最終結算前的資料無誤。

結算

生成賬單並執行相應的資金指令，完成最終的資金轉移。

資金安全

支付業務的資金安全主要可以從準確、合規兩個方面理解：

準確

資訊準確：即資訊不錯不漏不重。應對思路為流程上的容錯機制以及核對來實現。
時機準確：即不早不晚，應對思路為核對以及監控預警。

合規

二清合規

流程容錯

單據關聯

正如某些訂單域內部的多種單據間存在關聯關係一樣，支付設計上也有單據間關聯的設計。例如從流程上來說所有的逆向過程都必須持有正向的單據，因此退款必須要關聯到原來的支付，退款支付單要關聯到原支付單。單據之間的關聯只要有以下用途：

狀態一致性：正如訂單域中的訂單單據如果成功，則訂單關聯的營銷單、支付單一定成功一樣。支付場景的各個單據的狀態也存在關聯關係，例如建立退款支付單的前提是所關聯的原支付單必須成功。
金額一致性：金額控制是退款的一個核心問題，控制不好很容易產生資損。由於支援多次部分退款，金額必須防止退超，這裡包含兩個維度，一個是總金額不能退超，一個是各個維度的資金組成組成不能退超。具體的做法是，每一筆退款的金額，都會在原單上累加記錄到已退金額，記錄已退款的總金額，校驗不可超。

冪等

透過唯一鍵實現冪等是較為常見的實現方式。例如訂單側常見的重複支付退款是以訂單號關聯 PaymentNo 做重複支付校驗的唯一鍵，支付側交易單以外部單號 + 商戶號為唯一鍵，支付單以交易單號 + 操作碼作為唯一鍵。冪等可以有效的防止操作不重複，這裡需要額外注意的是，冪等的可重入問題：例如對於一筆整單退的請求，上游請求退款 200 元，支付域已經處理成功，上游由於超時基於同一筆支付單號進行進行退款重試，此時應該返回成功而非業務校驗異常。

重試

最大努力通知是支付領域常見的流程容錯手段，分散式環境下，網路抖動、服務暫時不可用等都會造成業務流程處理異常，常見的策略為將請求放入 MQ 進行非同步重試，重試間隔逐次拉長，重試如果成功，則回撥交易，如果失敗或者處理中，則繼續重試（所以介面冪等支援可重入很重要，對重試更友好）。

例如訂單收到支付成功回撥後，開始處理訂單流程。如果在下單階段僅鎖定庫存、營銷等資源，需要在支付回撥流程真正扣減資源的話，這裡需要對超時等場景進行重試（呼叫下游需要做好冪等），如資源扣減失敗則關單退款

重試指定次數如業務單據仍未到達終態，則將訂單資訊持久到資料庫中，通知人工進行處理。

例如使用者卡登出，會員銷戶等問題導致退款退不出去，重試一定次數後支付單隻能置為失敗。等待產運聯絡使用者後，在支付層重新生成退款支付單進行退款。

核對

核對是保障資金安全的重要機制。從時效角度來看，主要有（準）實時核對與離線核對（如 T+1 核對），實時核對的準確性不如離線核對，且需要相應的實時核對平臺建設（例如得物的 DCheck 平臺）。離線核對主要的問題是發現問題的時機較為後置，部分場景會影響系統的時效性。例如清結算與賬務側的每日資金核對失敗會影響結算時效性。

從核對維度來看，主要可以有如下幾種核對方式：

一致性核對：

資金在從業務端起點（資料由業務產生）到財務端終點（最終流入財務系統）中，在鏈路中的各個系統/表中都留有相應的憑證。例如交易一筆訂單的實付金額對應著支付的一筆支付單的支付金額，商戶一筆收單或支付退款會在對應的商戶待結算戶發生一筆動賬，對應在清結算會做一筆有資金方向的清分分錄。對這些金額我們可以建設相應的一致性核對任務進行核對驗證。

一致性核對包括雙向一致性核對和單向一致性核對兩種，單向一致性核對無法發現單邊資料缺失問題。

業務正確性核對：

在特定的業務場景下，業務有自身的業務規則，可以針對這些業務規則進行校驗。常見有以下四種方式：

一般正確性校驗：例如某些支付業務只能用於特定的商品型別，則可以透過自定義SQL校驗規則來進行校驗。
總分校驗：各個子金額彙總應當等於總金額。
順序性核對：業務流程中有依次執行的處理流程，則可以校驗是否有流程缺失。
冪等性核對：校驗是否有業務被異常的重複處理，如重複退款等。

時效性核對：

主要核對時效相關，如未支付的支付單在超時後是否及時關閉，結算時機是否滿足時效要求等。

風險額度核對：

對一些可能有高風險的關鍵配置與金額相關額度進行校驗，如分賬比例 <=30%、不能負傭、總營銷金額不能超過每日上限等。

總的來說，對實時性較高的任務採用實時核對，而日終檢查等採用離線核對，透過對支付全過程的監控預警以及失敗 case 產研及時介入處理，從而保證了資金安全的準確性。

資損攻防

也就是我們業內常說的混沌工程，透過注入故障可以有效的驗證我們的系統是否足夠健壯以及監控核對是否及時有效，常見的實現方式有：

透過模擬核心依賴超時等異常場景，驗證容錯重試流程是否可以正常工作。
模擬資損核心欄位落庫異常的場景，驗證監控核對是否可以及時發現。當然也可以透過旁路攻擊的方式，如修改資料庫的binlog欄位而非直接修改資料來檢視是否觸發告警，這樣對線上業務的影響會更小一些。

二清

對訂單同學來說，二清就是在下單時查詢商戶對應的支付二級商戶資訊並傳遞到支付與結算。那麼什麼是二清？二清合規問題是如何解決的？

什麼是二清？

首先我們透過幾個案例來了解下什麼是二清。

二清問題實際上可以分為“資金二清”與“資訊二清”：

資金二清：指無證機構透過平臺或大商戶模式截留沉澱了應直接結算給二級商戶的資金，再透過其他方式完成二次清算，實質性的控制整體結算資金。
資訊二清：資訊二清層面，監管不僅要求平臺不能進行“資金二清”，同樣也要求其提供的交易資訊真實可追溯，且分賬資訊是商戶真實意願。

資訊二清主要為了避免平臺使用了合規的三方支付機構，雖然不觸碰具體的資金結算，但掌握了原始的交易訂單資料、分潤資訊和商戶資金結算的入賬規則，使銀行或支付機構根據其提供的分賬規則、指令為商戶入賬，實質上透過平臺分賬指令傳輸主導了結算資金的方向。

電商公司早期求生存是更主要的問題，在整體支付系統演進過程中，往往都採用二清的模式。這裡面用於公司統一收款的賬號我們稱之為“大賬戶”。資金透過使用者流向公司的大賬戶，在透過結算最終流向賣家。這裡存在一定的合規風險：

資金挪用風險：平臺代為幾種收款，有擅自挪用的風險
資金監管風險：無證機構向平臺入駐的商家結算資金，遊離於監管體系之外
交易資訊風險：無法保證平臺提供交易資訊的真實性，有偽造的風險

近些年隨著監管越發成熟，電商公司因為支付不合規被責令整改的新聞屢見不鮮，隨著公司業務規模的發展，二清合規問題也愈發迫切的需要得到解決。

二清解決方案

對於二清問題，通常有兩種解決方式：

透過申請或收購的方式獲得支付牌照，使平臺獲得合法的資金清算能力（牌照較昂貴，成本較高）。
接入三方支付公司的二清解決方案（聚合支付系統需配合接入改造）。

目前得物採用的是第二種方案，我們以某寶的二清解決方案為例，簡單介紹得物是如何透過某寶的網際網路平臺直付通產品解決二清問題。簡單來說，得物平臺上的二級商戶需要入駐某寶成為某寶的商家，買家在得物的訂單支付成功（支援多個商家的訂單合併支付）後，某寶記錄對應商家待結算資金，待平臺確認可結算時，某寶將資金直接結算至商家指定的收款賬號。同時支援平臺按訂單靈活抽取佣金（也就是我們常說的分賬）。

這裡面有幾個核心的概念：

分賬抽傭：可根據實際業務場景將交易資金分賬到其他業務參與方的支付產品賬號（例如：平臺抽取佣金、其他方服務費等）。目前支援單個平臺最多 20000 個參與方的分賬，單筆交易訂單最高分賬比例 30%。
結算：買家確認收貨後，得物透過資金確認結算功能，將整筆訂單結算給二級商戶收款賬號，最長賬期支援 365 天，超過 365 天訂單自動結算。
營銷補差：平臺舉行平臺出資的營銷活動，如跨店滿減、全場通用券等營銷手段，資金結算後，平臺向該支付產品發起補差指令，將營銷資金補到二級商戶的賬號。

簡版流程：

買家支付訂單，訂單觸發分賬，將錢轉入賣家待結算戶，此賬戶金額對賣家不可見
使用者確認收款，得物平臺發起結算指令，該支付產品將賣家待結算戶的錢按照事先在該產品後臺配置的分成規則進行分賬。分別流入得物的該支付產品賬戶與二級商家已結算戶，此時賣家就可以看到自己的賬戶餘額增加了。
賣家將二級商家已結算賬戶的錢提現等操作。

當然這裡還有一些撤銷分賬、補差等細節流程，這裡就不做過多的展開了，感興趣的同學可以閱讀三方支付公司的二清解決方案相關文件。

四、訂單與支付

得物訂單與支付互動

由於監管 KYC 的要求，一筆支付單不僅需要支付相關資訊的如支付方式、支付金額、支付有效時間等，也需要訂單的買家資訊、賣家資訊、商品資訊等等。這些資訊客戶端無法全部給到，且基於安全的角度，也不能由客戶端透過公網傳參的方式傳遞，需要訂單域與支付域進行互動傳遞相關資訊。目前得物支付提供了下單模式（業務方呼叫支付系統建立支付單）和反查模式（業務方實現 PayInfo SPI，支付系統反查業務方獲取支付資訊）兩種模式，目前訂單是按照反查模式與支付互動。

訂單開發中常見支付相關問題

0 元訂單

微信/支付寶等常見三方支付文件裡有說明，支付金額 Total_amount 欄位取值最小為 1（1 分錢）。因此如果 0 元訂單還建立預支付單的話會失敗。之前有訂單域透過註冊定時回撥任務，偽裝成一個收銀臺支付回撥的方式來實現 0 元單回撥，實踐下來會踩坑（與實際業務流程不符，偽裝的回撥需要不停適配支付回撥的改動）。正確做法是對於 0 元訂單，只走建立商戶訂單的流程，並直接更新訂單狀態，不走支付回撥流程。

支付訂單過期時間設計

在電商交易系統中有兩個過期時間的概念：訂單過期時間和支付單過期時間。這兩個時間會產生時間差的原因在於：使用者在「確認訂單頁」點選「提交訂單」就會建立訂單並跳轉至收銀臺，此時開始鎖定庫存並計時；而使用者在收銀臺停留的時間是不確定的，這部分不確定時間造成了時間差。具體來講，如果使用者點選「去支付」建立預支付單時傳遞的過期時間是個固定值，那麼就有可能會出現一種情況：在訂單系統該訂單已經過期失效了，但使用者在支付平臺內還能支付該筆訂單（而此時支付成功回撥訂單系統，訂單已取消，系統是不會進行後續發貨流程的）。因此，支付單的過期時間要結合支付單建立當前時間和訂單建立時間一起動態計算得出，保持一致，從而給平臺使用者提供更好的消費體驗。

五、總結

總的來看，瞭解支付系統有助於訂單交易方向的同學理清上下游，更加全面理解電子商務四流中的資金流。同時支付系統在資金核對、流程容錯方面有著非常經典的設計，值得我們去學習借鑑。

參考文章：

1.銀行、票號興替與清末民初金融變革
2.https://baijiahao.baidu.com/s?id=1774618341934674551&wfr=spider&for=pc
3.https://download.csdn.net/blog/column/9276612/108820800
4.https://www.sohu.com/a/314762715_348231

*文/申堯

本文屬得物技術原創，更多精彩文章請看：得物技術官網

未經得物技術許可嚴禁轉載，否則依法追究法律責任！