支付系統設計:對賬設計

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

本文所描述的對賬,非金融機構內部的對賬場景。適用于公司自研以及采購的類電商系統,在此種場景下,平臺背后支付渠道可能對接微信、支付寶亦或者是其他第三方聚合支付公司的通道。

一、支付系統綜述

在如下圖體系中,對賬的目的是保障如下的等式成立:

客戶支付的錢-支付渠道手續費=應結賬款

有些渠道因為根據結算周期不一樣或者其他運營因素,結算需要手續費。此種情況:應結賬款-結算手續費=到賬金額。

在一個完整的電商交易平臺中,還會涉及折扣、積分兌換、滿減、余額等支付場景,而且其中又夾雜多商戶聚合支付。這種場景會讓新入行的小伙伴手足無措。

以上兩種場景的邏輯不應該放支付系統(支付模塊)處理,而是應該放在交易模塊的訂單管理子模塊處理。

支付系統只關注實付金額的處理,一筆訂單的訂單金額、折扣等都不是支付系統關心的。在一個復雜的電商系統中(淘寶、京東、亞馬遜),交易模塊的核心工作之一就是處理好業務訂單和支付訂單的關系。

業務訂單的核心屬性:業務訂單編號、下單日期、訂單金額、訂單狀態、折扣信息、商戶信息、客戶信息。

支付訂單的核心字段:支付訂單編號、業務訂單編號、支付時間、支付金額、商戶信息、支付狀態。

二、對賬綜述

明白了支付系統的定位和分工,在對賬階段所要關注的核心工作也就清楚了。

對賬主要是保證三項數據的一致性:支付訂單、支付流水、渠道流水。

這三項是分別是業務系統、支付系統、支付渠道的支付主數據,保證三者的ID關系和狀態吻合既保證了支付流程的正確性。而渠道需要保障的渠道流水中的應結金額和實際結算金額的一致性,這個是支付渠道內部對賬需要解決的問題。

第一階段對賬中會涉及會員積分的核銷、運營折扣的匹配所以后期會專題分享;第二階段與第三階段很像,都是根據下游系統生產的對賬文件和本地的訂單或者流水核對。詳細對賬流程看下節。

三、對賬流程

如下圖,一般對賬文件都是隔日才會生成,因為需要下游系統每日處理完前日的內部對賬后才會生成給上游的對賬文件。

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

ID 指發送請求給下游時,下游返回存儲在本系統的唯一主鍵。

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

  1. 本地有ID,下游有ID;可以匹配但是狀態不對;調用狀態查詢接口同步狀態;
  2. 本地有ID,下游無ID;根據ID查下游訂單;
  3. 本地無ID,下游有ID;根據ID查本地訂單,或查詢日志。

差錯處理這一塊,在實際涉及中,建議預留好人工處理的工具,等運行穩定后再根據實際情況把一些頻繁出現的場景通過系統自動處理。

四、總結

本文中的對賬針對場景是類電商系統和支付系統以及支付渠道之間的訂單對賬,并沒有涉及錢包、資金托管模式下的財務對賬。

本文提供的方法也主要是從業務需求出發,解決當平臺的交易流程比較復雜的情況下,怎么保證訂單信息、支付信息一致性的問題。

其他關于資金流水、應結資金、結算資金設計和財務ERP、企業網銀(通過銀企互聯獲取賬戶流水)的對賬,后續文章在一一介紹。

#專欄作家#

俠之大者,微信公眾號:俠之大者(ID:xzdzkamil),人人都是產品經理專欄作家。關注互聯網金融和企業信息化轉型。

本文原創發布于人人都是產品經理,未經作者許可,禁止轉載

題圖來自Unsplash,基于CC0協議。

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 支付渠道是上游系統。。。

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

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

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

    來自北京 回復
    1. 感謝補充

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

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

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

    回復
  6. 你是京東的吧???

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

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

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

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

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

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

    來自廣東 回復
    1. 歡迎持續關注,信息流和資金流這一塊會有專題哦 ??

      來自廣東 回復