紅魔電競平板評測：大屏幕硬實力
前言：三年的疫情因為要上網課的原因激活了平板市場，如今網課的時代已經過去，大家的生活都恢復到了正軌，這也就意味著，真正考驗平板電腦生存的環境來了。也就是面對著這種殘酷的
支付是指為清償商品交換和勞務活動所引起的債權債務，貨幣債權從付款人向收付人的轉移的過程。支付能力是電商產品的核心能力之一，作為訂單同學，有必要了解關聯域支付的流程以及基本概念，同時支付領域的很多設計思路與資損防控經驗對訂單域的系統設計也很有借鑒意義。本文將從支付系統的歷史、基本概念、系統設計、資損防控與訂單與支付交互等方面予以介紹。
支付的歷史演進可以追溯到現金交易的起源。隨著時間的推移和科技的不斷進步，支付系統經歷了多個階段和變革。
票號是應埠際匯兌需求而開設的金融專營機構，主要經營存款、匯款、匯兌三大基本業務，是現代銀行的雛形。客戶在票號交了銀子之后，票號就開出匯票給客戶。客戶可以隨身攜帶匯票而不用攜帶大量的銀子，只要憑票就可以到全國各地的分號兌出銀子。分號給客戶兌換之后先內部記賬，各分號間定期會當面進行對賬。鏢局就專為票號來運送銀子、為商人運送票據。在這種模式下，匯票+賬本（手工記賬）是票號在支付環節的信息載體，解決了信息流問題；鏢局替票號運送資金，解決了資金流的問題。
早期，國內的金融環境沒有達到讓央行推行全國統一結算制度的客觀條件。于是央行當時提出商業銀行要“自成聯行系統，跨行直接通匯，相互發報移卡，及時清算資金”。同一家銀行的總行及分支機構稱為“聯行系統”。同一聯行內的資金結算，由聯行總行自己做。跨行業務可以由央行清算，也可以由商業銀行自己清算。在這種模式下，各銀行需要告知其他行的交易信息構成了特定的公文，加蓋印鑒后在銀行間傳送。這種公文叫做聯行信件，而當時的郵電局則承擔了收發聯行信件的重要業務。
聯行信件整個過程基本都是手工處理，與明清時期的票號相比，并沒有太大的改進。雖然運行成本較低，但容易出現差錯，且資金匯劃效率依舊不高，導致占壓在途結算資金較多，如異地間資金的匯劃，少則 10 多天、多則半年才能完成資金到賬。
1990 年，中國人民銀行清算中心建成，專門為金融機構提供支付清算服務。清算中心包括 NPC（National Process Center，國家金融清算總中心）和 CCPC（City Clearing Processing Center，城市處理中心）。1991 年 4 月 1 日，全國電子聯行系統（EIS）開始試運行。EIS 是基于金融衛星通訊網的，它是人民銀行專門用于處理異地（包括跨行和行內）資金清算和資金劃撥的系統。它連接了商業銀行、央行、NPC 和 CCPC。以一位上海招行銀行卡的用戶要給持有北京工行銀行卡的朋友進行匯款，使用 EIS 完成一次支付清算的案例如下圖所示：
圖片
借助全國電子聯行系統，傳票和憑證已變為加密后的電文，與紙質聯行相比，進步巨大。客戶的資金在途時間縮短到了一兩天，大大提高了資金清算的效率，可以說是一個重要的里程碑。
中國人民銀行支付清算系統（China National Automatic Payment System）是為我國金融機構之間以及金融機構與人民銀行之間的支付業務提供最終資金清算的重要核心業務系統，整體架構如下圖所示：
圖片
簡單介紹下該系統的幾個核心子系統：
圖片
在現代化支付系統投產之前，即使是電子聯行系統也需要一到兩天才能能夠到賬，而現代化支付系統將支付后實時到賬變為可能，極大的提高了支付效率，提升了消費者的支付體驗。技術變革往往會帶來新的商業機會和變革，推動企業進行創新。國內的主流電子商務與電子支付平臺起也從 2003 年開始興起，這里現代化支付系統的投產時間（2002年、2005年）非常接近，很難說兩者之間毫無聯系。
支付系統一般指提供支付清算服務、實現支付指令傳送及資金清算的系統，由有支付牌照的支付公司提供。支付系統是連接消費者、商戶（或平臺）和金融機構的橋梁，實現了支付、資金清算、查詢統計等功能。這里系統的解釋一下涉及到的相關名詞，便于我們后文展開詳細介紹。
圖片
圖片
用戶提前注冊并登錄到第三方支付平臺，并且已經在該平臺上完成綁卡等操作后，通過第三方支付平臺進行支付。
用戶在完成必要的銀行網銀開通手續后，可以通過銀行的網銀系統進行在線支付和轉賬。在進行網銀支付時，用戶需要登錄銀行網銀系統，輸入相應的支付信息并進行身份驗證，然后可以完成在線支付交易，移動互聯網時代較為少用。
一種簡化了支付流程的支付方式。通常情況下，用戶在首次支付時需要綁定銀行卡或者進行一次認證，之后就可以使用該支付方式來完成交易，無需重復輸入銀行卡信息或進行繁瑣的身份驗證。在后續的支付過程中，用戶只需進行簡單的確認操作或者輸入支付密碼，就能夠快速完成交易。
協議支付也稱代收或者代扣，代收指渠道授權商戶可以從用戶的銀行賬戶中扣款，一般用于定期扣款，如水電煤氣、有線電視費、包月/包年會員費等。
不少公司會有自己的虛擬幣，這些虛幣也可以作為一種支付方式。一般會有一些金額、品類的限制，如虛擬支付不得超過每筆訂單結算金額的 50%。
為用戶建立本地賬戶并使用賬戶來完成支付，賬戶支持充值、提現等操作。
指使用信用賬戶進行透支，類似信用卡支付。需要較強的風控能力。
在了解了支付系統相關演進與基本概念后，我們再來看一下支付系統的整體架構。對于訂單同學來說，在實際支付業務的接入過程中，可以接觸到兩類支付系統：
第三方支付系統：即訂單同學理解里的“支付渠道”。比如我們作為商戶直接對接到微信、支付寶的支付系統中，從而具備支付收款能力。整個系統中的“核心系統”功能往往是大家最為熟悉的部分，它概括了我們平時各種消費支付場景。我們平時進行的電商交易、紅包轉賬等都是“支付應用”的體現形式。
圖片
實踐中，三方支付系統往往可以拆分為網關、金融交換、收單域、支付域以及賬務域、會員域、營銷域等多個領域。
一個比較典型的電商平臺的支付架構
從流量角度來看，對于一次用戶發起的支付行為，請求首先達到支付網關，經過必要的安全驗證和流量限制后，被轉發給對應的支付服務模塊。隨后用戶跳轉收銀臺頁面選擇支付方式后確認支付，由支付系統對接銀行/第三方支付機構的支付接口進行后續的支付。
圖片
以業內某支付產品為例，其提供了多種集成支付能力的方式，其中「手機網頁支付」適用于商戶無獨立 App，通過移動端 H5 網站進行傳播的方式。我們以一次手機網頁支付為例，了解支付的核心接口。
圖片
如上圖所示，可以從交易支付的幾個環節進行分析。
在商戶的 H5 網站下單并確認支付。
商戶系統生成訂單信息并構造支付請求發送到該支付產品系統。
系統校驗通過后拼裝本次支付所需參數返回給商戶前端。
商戶前端將頁面跳轉至該支付產品官方中間頁，如果用戶手機上安裝了該支付產品 App，則自動喚起 App；如果未安裝，則繼續在當前頁面進入官方 H5 收銀臺。
用戶完成密碼輸入并支付。
系統內部完成本次支付單處理流程。
處理完成后，以異步消息形式通知商戶后臺 Notify_URL，確認此次交易成功。
處理完成后，從官方中間頁跳轉商戶自定義支付結果頁 Return_URL，展示支付結果。
完成本次支付。
針對需要的業務場景，支持主動取消訂單（針對未支付訂單，已支付單可走退款流程）。
用戶發起/商戶后臺管理員發起訂單取消申請。
商戶系統向該支付產品系統發起關閉訂單請求。
后臺判斷處理后返回取消結果。
商戶后臺發起交易查詢請求。
系統判斷交易單存在，并返回交易結果。
用戶/商戶發起退款請求
商戶系統審核處理退款申請是否合法。
合法情況下，商戶系統向該支付產品系統發起退款請求。
系統處理并返回結果。
相關渠道將資金返回（有一定時間延遲）。
用戶/商戶發起退款查詢請求。
系統處理后返回結果。
商戶系統根據業務對賬需要，發起對賬申請，查詢最新的對賬單下載地址。
系統返回對賬單下載地址。
商戶系統根據對賬單下載地址下載對賬文件。
系統返回對賬單文件。
央行在 2017 年 8 月發布《關于將非銀行支付機構網絡支付業務由直連模式遷移至網聯平臺處理的通知》，規定了非金融支付機構受理涉及銀行賬戶的網絡支付業務全部通過網聯處理。目前業內采用的都是“間連”模式提供網絡收單服務。這里以一次銀行卡網絡收單支付交易流程為例，整體資金流與信息流如下：
圖片
清算服務根據交易要素對商戶主體交易按照約定的計費規則進行清算，記錄商戶主體因為商業交易而產生的債務債權，周期性生成對應的結算憑證。
結算服務按照約定結算周期和方式對商戶主體產生的債權債務進行清償,請求網聯結算打款。
從上圖看，步驟 1 到步驟 6 體現了付款方付一筆錢的流程，表示了三方支付一筆收單業務的信息流和資金流，其中步驟 4 中付款方的銀行卡余額會被實時扣減，發卡行側記應付未付。步驟 5 網聯記錄支付交易相關數據作為跨行清結算業務的依據。步驟 6 三方支付側更新支付交易結果并逐層通知至訂單系統，同時把支付成功消息同步給三方的清結算，清結算依據交易支付的結算要素做清分分錄，記錄商戶應結資金和應收手續費。步驟 7 屬于資金流。由網聯負責跨行周期清算，網聯通過央行清算系統完成資金劃撥后資金到了三方備付金賬戶。步驟 8 屬于資金流。三方支付完成周期性結算憑證生成后通過網聯發起結算打款，最終資金到賬時間依賴于網聯清算+資金劃撥的時間。自此，一筆電商交易經過用戶銀行卡扣款、網聯清結算、三方支付清結算，最終實現錢貨兩清。
清結算是對交易支付數據進行全面整理、計算、匯總、檢查核對和最終結算的過程，可拆分為清算和結算兩個子域。清算域服務根據交易推送的信息，按照約定的計費規則進行清分、匯總，記錄主體因商業交易而產生的債務債權，并定期生成相應的結算憑證。結算域根據約定的結算周期和方式，對商戶主體產生的債權債務進行清償。清結算確保了金融交易的安全性和準確性，保障各方權益。
抽象的來看，支付涉及業務主要可分為收、付、退、提、轉、充等 6 大類（對于訂單同學來說更關心的是收、付、退三大功能，對應訂單的購買、履約、售后三個子域）。資金結算一般分實時結算與定期結算，我們以定期結算為例，分析整體資金結算的簡版流程。
圖片
計費為通過對應的計費規則將業務流水消息轉換為清結算的資金語言，生成對應的結算資金明細。
根據清算明細，按照資金指令以及時間段進行匯總操作。
主要是對整個結算的模型、指令以及單據、任務的完整性校驗，以及賬務資金核對檢查等，確保最終結算前的數據無誤。
生成賬單并執行相應的資金指令，完成最終的資金轉移。
資金安全
支付業務的資金安全主要可以從準確、合規兩個方面理解：
信息準確：即信息不錯不漏不重。應對思路為流程上的容錯機制以及核對來實現。
時機準確：即不早不晚，應對思路為核對以及監控預警。
正如某些訂單域內部的多種單據間存在關聯關系一樣，支付設計上也有單據間關聯的設計。例如從流程上來說所有的逆向過程都必須持有正向的單據，因此退款必須要關聯到原來的支付，退款支付單要關聯到原支付單。單據之間的關聯只要有以下用途：
冪等
通過唯一鍵實現冪等是較為常見的實現方式。例如訂單側常見的重復支付退款是以訂單號關聯 PaymentNo 做重復支付校驗的唯一鍵，支付側交易單以外部單號 + 商戶號為唯一鍵，支付單以交易單號 + 操作碼作為唯一鍵。冪等可以有效的防止操作不重復，這里需要額外注意的是，冪等的可重入問題：例如對于一筆整單退的請求，上游請求退款 200 元，支付域已經處理成功，上游由于超時基于同一筆支付單號進行進行退款重試，此時應該返回成功而非業務校驗異常。
最大努力通知是支付領域常見的流程容錯手段，分布式環境下，網絡抖動、服務暫時不可用等都會造成業務流程處理異常，常見的策略為將請求放入 MQ 進行異步重試，重試間隔逐次拉長，重試如果成功，則回調交易，如果失敗或者處理中，則繼續重試（所以接口冪等支持可重入很重要，對重試更友好）。
重試指定次數如業務單據仍未到達終態，則將訂單信息持久到數據庫中，通知人工進行處理。
核對
核對是保障資金安全的重要機制。從時效角度來看，主要有（準）實時核對與離線核對（如 T+1 核對），實時核對的準確性不如離線核對，且需要相應的實時核對平臺建設（例如得物的 DCheck 平臺）。離線核對主要的問題是發現問題的時機較為后置，部分場景會影響系統的時效性。例如清結算與賬務側的每日資金核對失敗會影響結算時效性。
從核對維度來看，主要可以有如下幾種核對方式：
資金在從業務端起點（數據由業務產生）到財務端終點（最終流入財務系統）中，在鏈路中的各個系統/表中都留有相應的憑證。例如交易一筆訂單的實付金額對應著支付的一筆支付單的支付金額，商戶一筆收單或支付退款會在對應的商戶待結算戶發生一筆動賬，對應在清結算會做一筆有資金方向的清分分錄。對這些金額我們可以建設相應的一致性核對任務進行核對驗證。
圖片
一致性核對包括雙向一致性核對和單向一致性核對兩種，單向一致性核對無法發現單邊數據缺失問題。
在特定的業務場景下，業務有自身的業務規則，可以針對這些業務規則進行校驗。常見有以下四種方式：
一般正確性校驗：例如某些支付業務只能用于特定的商品類型，則可以通過自定義SQL校驗規則來進行校驗。
總分校驗：各個子金額匯總應當等于總金額。
順序性核對：業務流程中有依次執行的處理流程，則可以校驗是否有流程缺失。
冪等性核對：校驗是否有業務被異常的重復處理，如重復退款等。
圖片
主要核對時效相關，如未支付的支付單在超時后是否及時關閉，結算時機是否滿足時效要求等。
對一些可能有高風險的關鍵配置與金額相關額度進行校驗，如分賬比例 <=30%、不能負傭、總營銷金額不能超過每日上限等。
圖片
總的來說，對實時性較高的任務采用實時核對，而日終檢查等采用離線核對，通過對支付全過程的監控預警以及失敗 case 產研及時介入處理，從而保證了資金安全的準確性。
資損攻防
也就是我們業內常說的混沌工程，通過注入故障可以有效的驗證我們的系統是否足夠健壯以及監控核對是否及時有效，常見的實現方式有：
二清
對訂單同學來說，二清就是在下單時查詢商戶對應的支付二級商戶信息并傳遞到支付與結算。那么什么是二清？二清合規問題是如何解決的？
首先我們通過幾個案例來了解下什么是二清。
圖片
二清問題實際上可以分為“資金二清”與“信息二清”：
信息二清主要為了避免平臺使用了合規的三方支付機構，雖然不觸碰具體的資金結算，但掌握了原始的交易訂單數據、分潤信息和商戶資金結算的入賬規則，使銀行或支付機構根據其提供的分賬規則、指令為商戶入賬，實質上通過平臺分賬指令傳輸主導了結算資金的方向。
電商公司早期求生存是更主要的問題，在整體支付系統演進過程中，往往都采用二清的模式。這里面用于公司統一收款的賬號我們稱之為“大賬戶”。資金通過用戶流向公司的大賬戶，在通過結算最終流向賣家。這里存在一定的合規風險：
近些年隨著監管越發成熟，電商公司因為支付不合規被責令整改的新聞屢見不鮮，隨著公司業務規模的發展，二清合規問題也愈發迫切的需要得到解決。
對于二清問題，通常有兩種解決方式：
目前得物采用的是第二種方案，我們以某寶的二清解決方案為例，簡單介紹得物是如何通過某寶的互聯網平臺直付通產品解決二清問題。簡單來說，得物平臺上的二級商戶需要入駐某寶成為某寶的商家，買家在得物的訂單支付成功（支持多個商家的訂單合并支付）后，某寶記錄對應商家待結算資金，待平臺確認可結算時，某寶將資金直接結算至商家指定的收款賬號。同時支持平臺按訂單靈活抽取傭金（也就是我們常說的分賬）。
圖片
這里面有幾個核心的概念：
簡版流程：
當然這里還有一些撤銷分賬、補差等細節流程，這里就不做過多的展開了，感興趣的同學可以閱讀三方支付公司的二清解決方案相關文檔。
由于監管 KYC 的要求，一筆支付單不僅需要支付相關信息的如支付方式、支付金額、支付有效時間等，也需要訂單的買家信息、賣家信息、商品信息等等。這些信息客戶端無法全部給到，且基于安全的角度，也不能由客戶端通過公網傳參的方式傳遞，需要訂單域與支付域進行交互傳遞相關信息。目前得物支付提供了下單模式（業務方調用支付系統創建支付單）和反查模式（業務方實現 PayInfo SPI，支付系統反查業務方獲取支付信息）兩種模式，目前訂單是按照反查模式與支付交互。
圖片
微信/支付寶等常見三方支付文檔里有說明，支付金額 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
本文鏈接：http://www.www897cc.com/showinfo-26-58991-0.html訂單視角看支付，你明白了嗎？
聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
上一篇： Python基礎：格式化輸出
下一篇： 六個必知的PyCharm實用技巧
Copyright ? 2016-2023 天津谷騏科技有限公司 版權所有 sitemap.xml
違法及侵權請聯系：2376512515@qq.com 津ICP備18001702號
津公網安備 12010102000574號