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