支付系統(tǒng)設(shè)計:對賬設(shè)計
本文所描述的對賬,非金融機構(gòu)內(nèi)部的對賬場景。適用于公司自研以及采購的類電商系統(tǒng),在此種場景下,平臺背后支付渠道可能對接微信、支付寶亦或者是其他第三方聚合支付公司的通道。
一、支付系統(tǒng)綜述
在如下圖體系中,對賬的目的是保障如下的等式成立:
客戶支付的錢-支付渠道手續(xù)費=應(yīng)結(jié)賬款
有些渠道因為根據(jù)結(jié)算周期不一樣或者其他運營因素,結(jié)算需要手續(xù)費。此種情況:應(yīng)結(jié)賬款-結(jié)算手續(xù)費=到賬金額。
在一個完整的電商交易平臺中,還會涉及折扣、積分兌換、滿減、余額等支付場景,而且其中又夾雜多商戶聚合支付。這種場景會讓新入行的小伙伴手足無措。
以上兩種場景的邏輯不應(yīng)該放支付系統(tǒng)(支付模塊)處理,而是應(yīng)該放在交易模塊的訂單管理子模塊處理。
支付系統(tǒng)只關(guān)注實付金額的處理,一筆訂單的訂單金額、折扣等都不是支付系統(tǒng)關(guān)心的。在一個復(fù)雜的電商系統(tǒng)中(淘寶、京東、亞馬遜),交易模塊的核心工作之一就是處理好業(yè)務(wù)訂單和支付訂單的關(guān)系。
業(yè)務(wù)訂單的核心屬性:業(yè)務(wù)訂單編號、下單日期、訂單金額、訂單狀態(tài)、折扣信息、商戶信息、客戶信息。
支付訂單的核心字段:支付訂單編號、業(yè)務(wù)訂單編號、支付時間、支付金額、商戶信息、支付狀態(tài)。
二、對賬綜述
明白了支付系統(tǒng)的定位和分工,在對賬階段所要關(guān)注的核心工作也就清楚了。
對賬主要是保證三項數(shù)據(jù)的一致性:支付訂單、支付流水、渠道流水。
這三項是分別是業(yè)務(wù)系統(tǒng)、支付系統(tǒng)、支付渠道的支付主數(shù)據(jù),保證三者的ID關(guān)系和狀態(tài)吻合既保證了支付流程的正確性。而渠道需要保障的渠道流水中的應(yīng)結(jié)金額和實際結(jié)算金額的一致性,這個是支付渠道內(nèi)部對賬需要解決的問題。
第一階段對賬中會涉及會員積分的核銷、運營折扣的匹配所以后期會專題分享;第二階段與第三階段很像,都是根據(jù)下游系統(tǒng)生產(chǎn)的對賬文件和本地的訂單或者流水核對。詳細對賬流程看下節(jié)。
三、對賬流程
如下圖,一般對賬文件都是隔日才會生成,因為需要下游系統(tǒng)每日處理完前日的內(nèi)部對賬后才會生成給上游的對賬文件。
- 獲取對賬文件:格式化存儲,原始數(shù)據(jù)所有字段均存儲;
- 創(chuàng)建對賬批次:因為有些系統(tǒng)涉及商戶很多或者對接多個支付渠道,所以可以根據(jù)實際需求創(chuàng)建對賬批次易于分類管理。常見以日期為一批次。但是下游對賬文件出問題時,可能需要當(dāng)日需要再重新創(chuàng)建批次亦或是全量覆蓋;
- 對賬處理:從格式化的對賬文件中抽取六流水號、類型、狀態(tài)、金額、商戶號等關(guān)鍵字段和本系統(tǒng)的訂單匹配;
- 如果 ID+金額+狀態(tài) 一致,則該筆訂單直接核銷,打上對賬標記。
ID 指發(fā)送請求給下游時,下游返回存儲在本系統(tǒng)的唯一主鍵。
對于不一致的場景會有三種情況,分別對應(yīng)不同處理方案:
- 本地有ID,下游有ID;可以匹配但是狀態(tài)不對;調(diào)用狀態(tài)查詢接口同步狀態(tài);
- 本地有ID,下游無ID;根據(jù)ID查下游訂單;
- 本地?zé)oID,下游有ID;根據(jù)ID查本地訂單,或查詢?nèi)罩尽?/li>
差錯處理這一塊,在實際涉及中,建議預(yù)留好人工處理的工具,等運行穩(wěn)定后再根據(jù)實際情況把一些頻繁出現(xiàn)的場景通過系統(tǒng)自動處理。
四、總結(jié)
本文中的對賬針對場景是類電商系統(tǒng)和支付系統(tǒng)以及支付渠道之間的訂單對賬,并沒有涉及錢包、資金托管模式下的財務(wù)對賬。
本文提供的方法也主要是從業(yè)務(wù)需求出發(fā),解決當(dāng)平臺的交易流程比較復(fù)雜的情況下,怎么保證訂單信息、支付信息一致性的問題。
其他關(guān)于資金流水、應(yīng)結(jié)資金、結(jié)算資金設(shè)計和財務(wù)ERP、企業(yè)網(wǎng)銀(通過銀企互聯(lián)獲取賬戶流水)的對賬,后續(xù)文章在一一介紹。
#專欄作家#
俠之大者,微信公眾號:俠之大者(ID:xzdzkamil),人人都是產(chǎn)品經(jīng)理專欄作家。關(guān)注互聯(lián)網(wǎng)金融和企業(yè)信息化轉(zhuǎn)型。
本文原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理,未經(jīng)作者許可,禁止轉(zhuǎn)載
題圖來自Unsplash,基于CC0協(xié)議。
支付渠道是上游系統(tǒng)。。。
看過你的幾篇文章:有業(yè)務(wù)訂單、訂單流水、支付訂單、支付流水、交易流水、資金流水、渠道流水這個多概念。能把人搞暈菜…..然否說明一下這幾個概念場景和異同。
度過你的幾篇文章:有業(yè)務(wù)訂單、訂單流水、支付訂單、支付流水、交易流水、資金流水、渠道流水。能把人搞暈菜…..然后說明一下這幾個概念場景。
整體不錯!
但有兩個地方不大詳細:
1、對日切交易的對賬處理邏輯;一般先存疑,再參與次日對賬。
2、對賬差錯的處理;有些可系統(tǒng)自動處理(如渠道為終態(tài),己方為進行中狀態(tài),可直接更新狀態(tài)…),有些需要人工手動處理(如渠道成功,己方失敗,可人工手動觸發(fā)退款或變更狀態(tài)為成功);
差錯處理的方案中,兩方狀態(tài)不一致,最好不要直接查詢渠道更改訂單狀態(tài);如渠道失敗,己方成功的訂單,需要查看業(yè)務(wù)訂單進程,視情況進行處理。
感謝補充
如果單邊(非緩存賬),我方有單而渠道沒單,這種怎么處理?是我方核銷訂單還是渠道補單呢。?
我方有單而渠道沒有單,正常都是線下人工錄單的場景,應(yīng)該是銷售錄錯單了,這種如果沒有履約的情況下,需要將訂單作廢,重新錄單,如果已履約需要將我方支付流水進行更正。
感謝樓主,我這個小白看的很明白,雖然有時會有個別不懂得,講的很明白,吸收的很好,非常感謝
你是京東的吧???
是不是有個差錯緩存池?另外,支付、撤銷、退款是不是也參與對賬呢?
沒有處理時間差和存疑的差異處理嗎?
另還有幾個問題想討教一下,具體舉個例子,例如電商平臺一般支持的支付方式有微信、支付寶、銀行卡支付,結(jié)算時只要與各平臺提供的api接口對接好,然后根據(jù)當(dāng)日的交易流水總金額對賬,這塊設(shè)計有什么需要注意的問題嗎
我在下一篇文章會分享怎么記賬。其實只要你記錄清楚資金流水,按照商戶、渠道、日期 的維度創(chuàng)建對賬批次即可。
感謝分享,收益良多,不過文章中如果出現(xiàn)錯別字有時候會造成某些誤會
寫的挺棒的,對賬綜述小節(jié)的配圖中,感覺底層還可以加上 對賬本質(zhì)上是信息流和資金流(最接近資金流的信息流)之間的對賬的說明。
歡迎持續(xù)關(guān)注,信息流和資金流這一塊會有專題哦 ??