支付系統(tǒng)設(shè)計:對賬設(shè)計

16 評論 39593 瀏覽 324 收藏 7 分鐘

本文所描述的對賬,非金融機構(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)部對賬后才會生成給上游的對賬文件。

  1. 獲取對賬文件:格式化存儲,原始數(shù)據(jù)所有字段均存儲;
  2. 創(chuàng)建對賬批次:因為有些系統(tǒng)涉及商戶很多或者對接多個支付渠道,所以可以根據(jù)實際需求創(chuàng)建對賬批次易于分類管理。常見以日期為一批次。但是下游對賬文件出問題時,可能需要當(dāng)日需要再重新創(chuàng)建批次亦或是全量覆蓋;
  3. 對賬處理:從格式化的對賬文件中抽取六流水號、類型、狀態(tài)、金額、商戶號等關(guān)鍵字段和本系統(tǒng)的訂單匹配;
  4. 如果 ID+金額+狀態(tài) 一致,則該筆訂單直接核銷,打上對賬標記。

ID 指發(fā)送請求給下游時,下游返回存儲在本系統(tǒng)的唯一主鍵。

對于不一致的場景會有三種情況,分別對應(yīng)不同處理方案:

  1. 本地有ID,下游有ID;可以匹配但是狀態(tài)不對;調(diào)用狀態(tài)查詢接口同步狀態(tài);
  2. 本地有ID,下游無ID;根據(jù)ID查下游訂單;
  3. 本地?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é)議。

更多精彩內(nèi)容,請關(guān)注人人都是產(chǎn)品經(jīng)理微信公眾號或下載App
評論
評論請登錄
  1. 支付渠道是上游系統(tǒng)。。。

    來自上海 回復(fù)
  2. 看過你的幾篇文章:有業(yè)務(wù)訂單、訂單流水、支付訂單、支付流水、交易流水、資金流水、渠道流水這個多概念。能把人搞暈菜…..然否說明一下這幾個概念場景和異同。

    來自廣東 回復(fù)
  3. 度過你的幾篇文章:有業(yè)務(wù)訂單、訂單流水、支付訂單、支付流水、交易流水、資金流水、渠道流水。能把人搞暈菜…..然后說明一下這幾個概念場景。

    來自廣東 回復(fù)
  4. 整體不錯!
    但有兩個地方不大詳細:
    1、對日切交易的對賬處理邏輯;一般先存疑,再參與次日對賬。
    2、對賬差錯的處理;有些可系統(tǒng)自動處理(如渠道為終態(tài),己方為進行中狀態(tài),可直接更新狀態(tài)…),有些需要人工手動處理(如渠道成功,己方失敗,可人工手動觸發(fā)退款或變更狀態(tài)為成功);
    差錯處理的方案中,兩方狀態(tài)不一致,最好不要直接查詢渠道更改訂單狀態(tài);如渠道失敗,己方成功的訂單,需要查看業(yè)務(wù)訂單進程,視情況進行處理。

    來自北京 回復(fù)
    1. 感謝補充

      來自廣東 回復(fù)
    2. 如果單邊(非緩存賬),我方有單而渠道沒單,這種怎么處理?是我方核銷訂單還是渠道補單呢。?

      來自廣東 回復(fù)
    3. 我方有單而渠道沒有單,正常都是線下人工錄單的場景,應(yīng)該是銷售錄錯單了,這種如果沒有履約的情況下,需要將訂單作廢,重新錄單,如果已履約需要將我方支付流水進行更正。

      來自北京 回復(fù)
  5. 感謝樓主,我這個小白看的很明白,雖然有時會有個別不懂得,講的很明白,吸收的很好,非常感謝

    回復(fù)
  6. 你是京東的吧???

    回復(fù)
  7. 是不是有個差錯緩存池?另外,支付、撤銷、退款是不是也參與對賬呢?

    來自湖北 回復(fù)
  8. 沒有處理時間差和存疑的差異處理嗎?

    來自上海 回復(fù)
  9. 另還有幾個問題想討教一下,具體舉個例子,例如電商平臺一般支持的支付方式有微信、支付寶、銀行卡支付,結(jié)算時只要與各平臺提供的api接口對接好,然后根據(jù)當(dāng)日的交易流水總金額對賬,這塊設(shè)計有什么需要注意的問題嗎

    來自天津 回復(fù)
    1. 我在下一篇文章會分享怎么記賬。其實只要你記錄清楚資金流水,按照商戶、渠道、日期 的維度創(chuàng)建對賬批次即可。

      來自廣東 回復(fù)
  10. 感謝分享,收益良多,不過文章中如果出現(xiàn)錯別字有時候會造成某些誤會

    來自天津 回復(fù)
  11. 寫的挺棒的,對賬綜述小節(jié)的配圖中,感覺底層還可以加上 對賬本質(zhì)上是信息流和資金流(最接近資金流的信息流)之間的對賬的說明。

    來自廣東 回復(fù)
    1. 歡迎持續(xù)關(guān)注,信息流和資金流這一塊會有專題哦 ??

      來自廣東 回復(fù)