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