詳解 | 支付通道與支付系統功能設計之對賬

1 評論 6231 瀏覽 86 收藏 58 分鐘

這篇文章里,作者結合實際項目案例,對賬戶體系、商戶管理、交易系統等內容都做了一定闡述,想了解支付系統、對賬功能的同學,或許可以來看一下。

本文結合在支付領域工作一年的經驗,結合跨境支付公司的實際業務場景和理論知識,系統闡述一筆資金再支付系統的流轉過程,并結合實際項目,針對對賬模塊中的渠道對賬和賬賬對賬功能搭建進行詳細闡述;供大家學習和參考。

以電商平臺為例,常見電商交易平臺的支付系統有賬戶、支付、記賬、清算、賬務等核心功能。在設計系統功能架構時、要權衡功能范圍、關聯系統、交易規模等因素,基礎系統可以分為“業務、賬務、財務”三個角色。

目錄

一、賬戶體系

支付賬戶是支付機構為客戶開立的具有記錄客戶資金交易及余額功能的點子賬簿。賬戶體系是支付系統的底層基礎,賬戶的類型可以根據用途和會計科目設置。

1. 賬戶的概念

  • 賬戶:可以類比為一本銀行存折;
  • 賬號:與存折保定大哥銀行卡號,是一一對應的關系;
  • 用戶:賬戶的歸屬者,屬于賬戶的個體。
  • 賬戶的基本信息:賬戶號、賬戶類型、余額、幣種、開戶狀態、開戶時間等。

2. 賬戶的類型和功能

1)賬戶類型

支付機構的賬戶管理,其用戶/子商戶都有獨立的賬戶。下圖中跨境匯款系統中的賬戶體系關系。系統層面的賬戶記錄客戶參與交易的賬戶余額的增減和賬務流水歷史,以完成會計記賬與具體金額、借記或貸記等,為用戶提供資金收、付、管的基礎服務。

不同的視角、賬戶的分類不同;具體分類如下圖所示。從業務視角看賬戶可以理解為用于記錄某個主體、某類型資金的余額、以及余額變動明細的數據載體;所以可以理解賬戶的功能功能為:

  • 賬戶余額:這個賬戶還剩多少錢;
  • 賬戶流水:這個賬戶的資金每進每出的詳細明細記錄;
  • 賬戶交易:賬戶資金是怎么放進去和怎么取出來的詳細記錄。

2)賬戶功能

賬戶管理功能包括以賬戶開設、修改、凍結、余額限額設置、受限操作屬性設定和賬戶查詢等。賬戶系統的基本功能主要包括賬戶管理、賬戶權限、賬戶信息管理、配置、支付交易等模塊,具體功能如下圖所示。

3)賬戶體系資金流動

在交易體系中、支付機構是按照平臺、用戶、商戶的收款金額進行分賬的,實際系統層面的結算是各參與方賬戶的數字變動。相應銀行親結算過程是在內部完成資金劃轉、即銀行內部以賬戶為核心的賬務操作,改變資金所屬權。支付機構賬戶體系中的資金流動如圖所示。

4)賬戶系統資金流轉

賬戶系統的核心職能在于財務管理。其首要職責包括向上游客戶中心提供注冊和賬戶信息查詢服務,其中包括銀行卡綁卡鑒權、賬戶余額以及交易流水等查詢功能。在接收來自上游訂單系統和清結算系統的記賬請求時,系統必須遵循規范流程進行入賬處理。

另外,當商戶發出賬戶提現請求后,必須通知下游結算系統,以進行審核和資金劃撥程序。整個用戶、三方支付機構和商戶間的資金流轉路徑如下圖所示。

二、商戶管理

1. 商戶收單及商戶層級管理

支付機構在給商家及渠道簽約的過程中,與通道建立支付協議及清算規則,適應不同場景訂單對應的支付產品、通道、費率等要求。在多商戶收單及商戶層級管理方面,支付系統要根據商戶類型制定入網流程、分賬需求、結算周期、費率階梯、是否可墊資及退款等功能。

入網流程:即商戶自助進件過程,在實際業務中登錄注冊后,走onboard流程進行kyc審核。涵蓋商戶資料審核與簽約,線上入網、建檔、授權、企業資料、合同等信息采集與審查。有時,商戶入住平臺需要繳納保證金,在商戶充值后,平臺方凍結該筆資金。

注意:如果平臺沒有提供商戶入網功能,則商戶入網需要和支付渠道直接簽約,授權平臺方代理自身向支付機構發起交易。

2. 商戶的資金結算規則

在商戶的資金結算規則方面,每筆交易在執行之前,平臺已經清晰地確定了參與方的角色。交易的完成狀態是通過雙方(消費者與商戶)之間達成的,以反映交易是否成功完成,同時在財務層面完成了資金同步,資金流水記錄則代表了真正的財務記賬過程。在每個結算周期結束時,根據資金流水記錄以及相關費率因素,計算應當結算的金額。

1)結算費用涉及內容(以金融產品服務為例)

① 根據金融產品收費模式確定結算模式:包括Blend和IC++兩種模式。

A. blend模式:Blend收費模式是將不同類型的費用(例如,交易手續費、匯率差異費用、固定服務費等)合并或混合在一起,以創建一個綜合費用結構,使費用更加透明和簡化。Blend收費模式適用于小型企業或新興市場,因為它提供了較為簡化的費用結構,降低了計算和預測費用的復雜性。

用具體業務場景說明:假設一家電子商務公司在國際市場上銷售商品。他們使用Blend收費模式,將不同的費用合并為一個統一的費用。這包括每筆交易的固定費用、一定比例的交易金額作為交易手續費以及根據當天的匯率差異計算的費用。這使得商戶和客戶能夠更容易理解和預測他們的費用,而不必關心不同類型的費用。

B. IC++收費模式:IC++收費模式是一種費用結構,其中商戶支付交易的成本,加上支付處理方的固定交易費用。IC++模式通常透明,因為它明確顯示了交易的成本,例如銀行卡發行方的交換費用和支付處理方的固定費用。適用于大型企業或高交易量企業,因為它提供了更多的費用透明度和控制,適用于那些愿意深入了解和管理其交易費用的企業。

一家在線零售商使用IC++收費模式來處理其跨境支付。當客戶使用信用卡付款時,商戶支付基于交易的具體成本的交換費,這包括卡協議費用、交換費和清算費。此外,商戶支付支付處理方的固定費用,以覆蓋服務成本。這種透明的模式允許商戶清楚地了解他們支付的費用是多少,并確保交易的可持續性。

2)結算費用的內容和結算規則

① 收單費:指支付收單機構為處理商戶的支付交易(通常是信用卡或借記卡交易)所收取的費用。通常包括:固定服務費和其他費用。

  • 固定費用:一些支付收單機構可能會收取每月或每年的固定費用,以覆蓋其服務成本。
  • 交易手續費:針對每筆成功交易,商戶通常需要支付一定的費用,這個費用通常是一個百分比,也可能包括最低金額。
  • 3ds費用:3ds是一個為了增加支付安全性而設計的協議,需要額外的身份驗證步驟,通常涉及到消費者提供密碼、驗證碼或其他驗證信息。3DS費用是用于支持和維護3D Secure協議的費用,通常由支付處理方或卡網絡收取。
  • 爭議費:爭議費是支付處理方或銀行機構向商戶收取的費用,用于處理涉及爭議的支付交易。爭議交易是指消費者或持卡人對一筆交易提出異議,通常是因為他們認為交易存在問題、欺詐或其他爭議情況。
  • 授權費:指支付處理方或銀行機構向商戶收取的費用,以獲得交易授權。這個費用通常涵蓋了交易的實時驗證和授權過程,以確??ㄙ~戶的有效性和可用性。
  • 交易費:交易費是指支付給支付處理方或銀行機構的費用,以便處理、促成和結算支付交易。這些費用通常涵蓋了交易處理、清算、結算、風險管理和其他相關服務的成本。
  • 保證金:指一種在金融和商業交易中使用的款項,以確保合同的履行或滿足特定的義務。

注:具體的費用項的費率根據計費規則進行計算。

② 結算周期:影響結算周期的因素有:支付渠道所在國家和結算幣種所在國家。

  • 支付渠道所在國家為美國時,假設結算周期為T+7(T+7個工作日);當結算周期中包含美國節假日時,則需要跨過當地的節假日時間再往后數七個工作日;
  • 當結算的幣種所在地區為香港時,假設結算周期為T+3(T+3個工作日);當結算周期中包含香港節假日時,則需要跨過當地的節假日時間再往后數3個工作日。

三、交易系統+收銀臺

1. 交易系統

在電商交易平臺的設計中,交易系統的主要職責在于連接業務訂單與支付訂單,接收上游的業務訂單,處理交易請求,負責處理業務邏輯、訂單管理、計費等各個方面,并將各種具體的交易類型抽象成下單服務,以完成訂單的完整生命周期管理。

訂單可以單筆支付,也可以合并支付,對于購物車里有不同商家訂單的場景,用戶可基于多筆訂單發起合并付款。

常見支付訂單的幾種狀態如圖所示,交易流水通常不含訂單的內容和狀態,只關注各個賬戶的收款額、退款金額、支付類型和時間等信息。

2. 收銀臺

收銀臺,即交易系統的前端界面,是為用戶在日常支付前選擇支付渠道的界面,通過引導路由確定可供選擇的支付方式,協助業務平臺完成支付交易,以確保用戶能夠獲得一致的支付體驗。

支付機構會根據不同終端類型制定不同的收銀臺,以供外部調用,為業務系統提供收款和付款操作的用戶界面,同時接受并轉發交易請求,并根據不同場景的特定需求呈現不同的支付選項。收銀臺的功能與支付渠道管理相關,每個支付渠道都具備各自的支付產品,以滿足各種不同場景的需求。

  • 用戶:支付行為的發起者,可以理解為電商場景下執行購買行為的消費者。
  • 商戶:收銀臺的商戶或者業務線,可以理解為電商賣家。
  • 聚合收銀臺:提供收付款服務的收銀系統。
  • 支付渠道:提供支付、清結算能力的三方支付機構。

收銀臺的業務流程一般分為付款和充值,功能與界面設計取決于業務流程和支持的支付渠道。

收銀臺的客戶體驗優化一般分為兩種:

  1. 商戶接入開發及生產維護更便捷:支持多種支付渠道及靈活配置,可自動跳轉或在商戶界面以實時接口完成支付;
  2. 用戶操作便捷:需引導用戶快捷方便的完成支付。

注意:

  • “站內支付”將整個支付頁面內嵌到商家網站,使整個下單支付過程在商家網站一個頁面完成。
  • 常見收銀臺用戶側異常情況:網絡延遲、誤錄賬號、密碼錯誤、限額等,對這些異常要進行友好性提示。

四、支付-清分-結算

  • 支付:所有涉及資金轉移的行為都可視作支付。
  • 清算:清算發生在結算前的預處理環節,等同于“清分+匯算”,是對交易數據依據機構和交易類型進行分類匯總、記賬,并計算應結算金額的過程,不涉及債權/債務的轉移,是對數據流的處理。
  • 結算:結算是資金所有權、債權/債務關系的轉移,根據清分結果對交易數據進行凈額軋差和提交并完成資金劃撥的全過程,分賬、扣費、轉賬等是資金流的動作。

注:清結算屬于后臺系統,消費者和商戶通常不會直接接觸,銀行與銀行之間構成清算關系,銀行、商戶、支付機構之間構成結算關系。

國內第三方支付只能通過中間清算機構間接互連,不能直連銀行,其交易流程如圖2-13所示。其中,銀聯與網聯的區別是:銀聯占據線下市場,覆蓋境內、境外、線上、線下的銀行卡網絡;網聯主要處理支付機構發起的、涉及銀行賬戶的網絡支付業務與各家銀行之間的資金清算,替代此前支付機構與銀行多頭直連。

1. 跨境支付公司收單業務

收單側,當跨境電商進入某個新市場時,首先需要解決的就是收單問題,支付機構要幫助商戶從境外的客戶收錢(Pay-in),并依據交易單據和分賬規則,扣除手續費后打款給商戶(Pay-out)。外卡收單的手續費仍保持較高水平,且有本地化資質門檻;境外收單需要提供本地化支付體驗與結算方案,只有進一步延伸合作鏈條,與本地支付互通合作,才能為消費者帶來便利。

支付機構主要業務環節及盈利點如下圖所示,通道手續費是支付機構穩定的收入來源,可以按照交易規模流水收費或按照支付筆數收費,或將兩種方式混合收費,規定比例與上限。

跨境匯款的收費差異較大,分擋付費、有最低收費;跨境收款、收匯整體費率處于下行狀態,賺取匯差收益風險較高,合規性不足?,F階段,跨境支付行業的集中度還不高,很難獲得費率溢價,快速搶占市場是生存關鍵,要能盡快獲得更多商戶,拓展跨境金融等增值收益;作為商戶,可能會選擇兩家以上支付企業進行合作,如此可便于比較。

2. 支付處理+記賬

支付行為是賬戶資金的流轉,每筆支付訂單對應著一筆甚至多筆指令。

常見支付指令類型包括以下幾種。

3. 渠道網關+前置

支付網關具有通信前置、渠道管理和風險控制等功能,這些功能偏向于對外提供,支付處理的邏輯仍在系統后端各環節完成。

業務類型決定選擇什么支付渠道,從而促成支付。支付渠道由提供支付受理能力的具體提供方來劃分,屬于外部系統。支付渠道具有資金轉移的多種通道,只有先對接渠道才能支付,如卡組織、直連銀行或電子錢包、匯款機構等。

4. 交易對賬

隨著交易鏈條的逐漸延伸,數據在多個系統之間的傳輸過程中,難免會面臨丟失或錯誤的風險。為了保障業務的正常運營,并能夠及時偵測問題,有必要確保不同系統之間數據的一致性。對賬即為完成相關數據核對或復核的過程,以確保數據的準確性和一致性。

交易對賬即核對賬簿記錄,在系統上體現為逐一核對交易明細數據,以此驗證支付過程的準確性。

1)對賬內容

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

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

即對賬的內容包括一下幾個方面:

業務交易狀態核對:當出現支付狀態沒有被前端接收到,或重復支付、支付失敗掉單、金額不等、渠道標識錯誤等異常情況,使交易狀態未實時更新,或各種網絡通信、系統交互異常引起異步漏數時,可通過對賬直接更新狀態。

交易流水對賬:一條交易信息可能有多條賬務流水信息。下載每個渠道的賬單明細,然后按照渠道與交易流水一對一對賬,多賬、少賬的流水根據流水分類進行匯總“掛賬”。創建對賬批次防止重復對賬,正確無誤的交易會結合批次生成結算流水或付款文件。

差錯處理:差錯處理是對賬的關鍵,當發生記錄不一致的情況時,差錯賬記錄匯集成“差錯數據池。若某個扣款渠道的流水文件存在差錯交易,則這個渠道的所有交易都不會生成結算流水文件,等待完成差錯處理后,系統再對該渠道的所有交易生成結算流水文件。

資金對賬:俗稱對銀行賬,核對支付系統與資金賬戶發生額的一致性,記賬的變動流水與賬戶資金出入明細進行逐筆勾核。資金對賬的本質是支付端交易賬戶與扣款端渠道賬戶的一一對照,包括結算劃轉記錄。如果明細及總的金額都無問題,則平賬(對賬一致)。

五、對賬實例

1. 以實際項目來闡述賬賬對賬功能

1)需求背景

財務在進行每月對賬時,核對訂單狀態和支付流水發現有50W元的缺口對不上;財務反饋希望我們將對賬功能線上化,通過自動對賬篩選出異常的訂單并進行差錯處理。

2)需求分析

調研市面上關于對賬功能設計的參考,考慮一下幾點:

① 對賬原則:對的是平臺訂單交易流水和渠道流水的明細;即對明細賬或者對總額的核賬規則進行對賬;包括支付和退款。如果賬賬對賬不能核對匹配,就會對賬單中交易的長款、短款進行差錯處理。

② 處理渠道側和交易側對賬的原理:

  • 不能多收錢;
  • 不能少收錢;
  • 不能收錯錢。

③ 對賬基準:實際中以渠道側流水為基準;

原因:支付通道側的付款規則基于其賬單記錄,不受我方賬單平衡與否的影響。為確保資金入賬后的賬單與資金核對順利進行,即賬證對賬和賬實對賬,我們可在確認對方賬單無差錯后,將其納入批次一并處理。

④ 對賬的內容:對明細和對總賬

  • 對明細:是將自身的賬單與渠道賬單中每一條記錄進行核對。在支付中,根據賬單訂單號或者支付流水號、交易類型、交易金額、交易日期、交易手續費進行比對。
  • 對總額:是將自身交易訂單與渠道流水的總金額、筆數、訂單狀態進行核對。在支付中,根據交易日期與結算日期核對總交易金額、交易筆數等,整體金額一致就算對上。

⑤ 對賬時間和文件獲?。阂匀涨袝r間為準;每日定時任務讀取渠道文件

注:日切時間指的是金融機構或支付系統在每個工作日結束時進行的賬戶結算和交易清算的時間點。這個時間點標志著一天的交易結束,通常用于計算每日的賬戶余額、處理交易、清除未完成的交易和準備下一個工作日的交易。

⑥ 文件解析:判斷渠道-判斷類型-解析文件-轉換入庫。主要是將下載的對賬文件解析成我們可以對賬的數據類型并且入庫

⑦ 對賬結果:對平、長款、短款、金額不一致;

  • 對平:交易側和渠道側的總金額、訂單狀態、支付和退款流水明細一致;
  • 長款:多收了錢;即通道側記錄多收了錢;公司少收錢——平臺無訂單或無有效訂單;
  • 短款:少收了錢;即渠道側無訂單、平臺側有訂單——支付平臺認為支付成功、實際銀行沒有收到請求;
  • 兩邊金額不一致:流水明細可以對賬,但記錄的金額不一致。

⑧ 賬對不平的原因:存在差異和瞬時交易與交易系統的交互存在時間差異

A. 長款:平臺側多收錢,渠道側少收錢;即渠道側記錄20條、平臺側記錄19條,多結算了一筆。

出現長款原因:

  • 系統掉單;
  • 系統BUG;
  • 由于瞬時交易和交易系統交互反應時間過長,系統輪詢時沒有詢到導致查找無結果。

解決方式:

  1. 平臺側進行補單;
  2. 平臺側對所補訂單進行退款;由于找零為退還導致金額不一致;
  3. 設置一定時間范圍定時輪詢,超過此時間范圍返回還是無結果判定失敗,根據具體的對賬詳情判別是否要進行差異處理。

B. 短款:通道側記錄多收了錢;公司少收錢;即渠道對賬生成19條,我方生成20條;

出現短款原因:平臺認為成功了,實際上銀行并沒有收到請求。

解決方式:

  • 去調單:需要判斷是否為渠道側的失誤;去查看渠道側的報文,判斷是否追回。
  • 平臺側發起補償;即重新聯系用戶發起扣款或凍結訂單。

注:若用戶拒絕重新發起支付,會造成掉單;避免此種場景的方式可以免密支付或者快捷交易在支付里不僅能用于改善用戶體驗、提升支付成功率,也能用于事后代扣、避免資損。

C. 雙邊金額不一致:賬單明細可以對上,但是最終顯示的金額不一致。

造成的原因:系統BUG,流水一致但最終總金額輪詢時,沒有詢上。

解決方式:修改金額,且設置輪詢機制。

D. 金額和訂單狀態不一致:流水明細和金額一致,但訂單狀態未更正。

造成原因:

  • 訂單狀態沒有輪詢成功;
  • 找零金額未退還給用戶。

解決方案:找零的錢退還給用戶,對于訂單狀態字段新增輪詢機制。

⑨ 差錯處理:

  1. 修正:上傳校驗記錄;
  2. 訂正差異狀。

3)方案目標

  • 對賬核對渠道側支付和退款流水明細、支付與退款總金額與我方支付&退款流水明細、我方支付與退款總金額及訂單狀態;
  • 對賬完成后,對有差異問題的訂單給予差異處理功能;
  • 系統對賬后,通過給出的差異原因對系統其他功能進行優化迭代。

① 產品方案

頁面信息展示:

A. 信息欄:包含字段業務類型/訂單號/訂單狀態/訂單金額/三方支付流水號/三方支付流水總額/實付金額/三方退款流水號/我方退款流水號/累計退款總額/找零金額/差異金額/差異處理狀態/操作人/操作時間/管理。

  • 找零金額:即用戶實付金額-訂單金額=找零金額;有找零則顯示找零額度,無則顯示“—”;
  • 找零狀態:已找零/未找零;沒有找零金額時,則顯示為“-”;
  • 差異金額:即用戶實際付款-累計退款=差異金額;
  • 三方支付流水號:由于三方支付流水號=我方支付流水號,故我方支付流水號不做展示。

B. 搜索欄:業務類型/訂單號/三方流水號(三方支付流水/三方退款流水/我方退款流水號)/差異類型/核對時間/差異處理狀態。

  • 業務類型:參與對賬的業務線;
  • 訂單號:由于是由數字組成,故對字符串/空格等符號不兼容;
  • 三方流水號:兼容字符串;
  • 差異類型(原因):選項包括訂單狀態和金額不一致/三方流水大于我方流水/實付金額和售價不一致/我方流水大于三方流水/累計退款和退款流水不一致/未找零退款;
  • 核對時間:自動對賬的時間;
  • 差異處理狀態:已處理/待處理/無差異。

詳情頁展示:

A. 基本信息詳情展示:包括業務類型/頂堤干號/訂單金額/實付金額/累計退款/三方支付流水總額/三方退款流水總額/訂單狀態/差異金額/差異凈額凈額/找零金額/找零狀態/差異id/對賬時間/差異處理狀態/差異原因

差異原因:對存在差異的訂單,系統會給出差異原因,方便工作人員更好的排查。

B. 支付流水信息:包括訂單號/三方支付流水號/三方支付流水金額/三方支付方式/我方支付流水號/我方支付流水金額/我方支付方式。

C. 退款流水信息:包括退款訂單號/三方退款流水號/三方退款流水金額/三方退款方式/我方退款流水號/我方退款流水金額/我方退款方式。

差異處理:對存在差異的訂單進行處理。

  1. 根據差異狀態篩選出有差異待處理的訂單;
  2. 在差異處理模塊中提交支付流水號(支付上傳多個流水號);支持上傳支付/退款憑證;系統原因導致的差異,要求處理差異解決的代碼;同時對差異原因進一步說明;
  3. 提交到后臺系統自動審核。

2. 以實際項目來闡述渠道對賬

1)需求背景

目前渠道對賬是資金根據渠道側給的文件腳本生成,為方便資金更快的查看處理對賬結果,上線渠道對賬功能;同時核對渠道側和我方交易側的賬單明細后將,渠道對賬面板功能將結算金額按照計費規則拆解成費用項展示在面板上方便后續計費。

2)需求分析

目的:是確保所有交易都被正確無誤地記錄在賬戶或賬單上,獲取渠道和交易側的匹配情況,方便資金處理對賬結果,同時對無誤的賬單明細渠道對賬后根據計費規則羅列對賬單具體的收費項總的費用。

跨境支付的渠道對賬的內容:對的是賬單明細和總額,由于wechat和alipay渠道目前只有支付,無退款;所以這兩個渠道只對支付明細;對退款不進行對賬。

① 對明細:對的是渠道金融機構拿到的報表(明細)和公司數據庫里的交易明細對賬;最終顯示的條目只展示交易側和渠道側的明細需要匹配多少條,成功匹配了多少條;未匹配多少條。

對賬的條目內容

② 對總額:最終展示在頁面上的是無差異賬單明細中每個收費項的總額;不同的渠道匹配規則不同。主要展示結算總金額信息、和計費相關的具體收費項金額信息。

3)對賬時間和文件獲取

① 文件上傳模式:由于渠道側的賬單明細無法從數據庫直接獲取,是渠道那邊發給我們的excel文件,因此;我們通過上傳文件的形式進行匹配;支持excel\csv文件上傳。

② 對賬時間:由于負責資金的同事在中國,結合工作習慣以北京時間為準進行對賬,每日0點,根據渠道側的不同的幣種,系統自動生成待上傳賬單的基本表頭信息的條目;即根據幣種不同顯示渠道待上傳的條目。

  • 考慮提前生成腳本的好處:由于是對賬文件是人工上傳,系統根據渠道所支持的幣種多少,對應生成多少條目;這樣根據幣種來劃分方便后續資金結算;同時避免上傳的文件有誤;
  • 由于負責資金的同事在中國,所以對賬時間按照中國時間為準,但公司總部在國外的話結算日期按照總部所在國家為準,即當結算周期遇到節假日時,按照國外的節假日為準。

4)文件解析

  • 北京時間0點系統按照渠道的結算幣種數量生成對應的渠道對賬條目,次日資金上傳從渠道那邊獲取的excel文件,通過人工上傳進行對賬;
  • 由于渠道側的文件來源于不同渠道方給的excel文件;文件取名或內容格式不一,因此該功能對上傳的文件名格式不做限定;但是文件中字段的內容需要和渠道方核實,做格式兼容處理;

上傳完成后系統自動解析,解析完成后對應以下幾點:

① 當解析成功時,彈出彈窗【解析成功,是否開始對賬】;

② 當解析失敗時,有幾點原因導致:

  1. 上傳文件內容格式有誤——找渠道側確認文件內容;
  2. 上傳的文件內容重復——需要把歷史上傳的文件刪除后才能二次上傳;
  3. 網絡加載錯誤。

5)對賬匹配規則

① 交易側的匹配賬單以當天賬單的post_time字段為準進行匹配

比如10.17號獲取賬單、其賬單內的post_time記錄的是5.10號,則對應在系統中生成的條目是匹配時間是5.10號;開始對賬時間是10.17號。

② 渠道側和商戶側的賬單明細按照PI號進行匹配

“PI號”是指付款信息號碼(Payment Instruction Number),通常用于跟蹤和匹配交易。PI號的達標意味著PI號字段的信息是準確、一致和完整的,這使得渠道側和交易側的賬單能夠按照PI號進行匹配。

③ 幣種和對賬條目一一對應

由于渠道涉及多幣種;考慮到不同幣種匯率差異會導致對賬金額不一致;隨意不同渠道的對賬條目按照幣種劃分;即以wechat為例,涉及到結算幣種由GBP、HK和USD;即0點時系統準備拉取交易對賬腳本,按照幣種數量生成對應的條目,當天資金上傳渠道側文件時,同一份文件按照幣種不同上傳三次,每一次只解析和對賬幣種所對應的賬單。

6)對賬結果

① 匹配無差異:平賬;無需處理。

② 匹配有差異:對賬金額不一致即交易或渠道的某一側少錢。

由于具體的收費項是根據計費規則確定的;影響最終收費項金額的因素由:費率、匯率、費用計算公式,結算金額、和系統等因素組成。

A. 時間差導致:由于不同地區和國家之間的時差和時區差異,會導致交易日期和時間的不匹配。

解決方案:對上傳的渠道側的數據,該日未對平的數據在數據庫中回溯七天;并在差異處理中記錄該條數據,如果七天內對平了該數據最終,則差異處理中該條數據自動刪除;如果七天后仍未對平,則系統不再回溯,差異處理功能中仍會顯示該條信息,對賬結果顯示有差異;狀態顯示待處理。

B. 通信問題:由于渠道對賬涉及多個系統和平臺之間的數據傳輸,會存在通信問題,可能導致交易數據未能正確傳遞或同步,從而引起不平賬。

解決方案同上。

C. 匯率差異:在跨境支付中,涉及不同貨幣的交易可能會受到匯率波動的影響。如果匯率不一致或不準確地應用于交易,可能會導致金額不匹配,從而引起不平賬。

上線匯率面板功能,將匯率和計費系統聯動;匯率面板中的數據每日從從中國銀行和海云匯中直接拉取。當發掘拉去的匯率不合適時,支持人工修改。

7)對賬完成后的結果處理

對賬完成后,會在【對賬筆數】字段中顯示匹配結果,即交易側和渠道側的各自明細要匹配多少條;在【匹配結果】字段中顯示成功匹配了多少條;有差異的有多少條;需要回溯的有多少條。

注:需要回溯的數據是指渠道側或交易側某一側有這條數據;另一側沒有獲取。

  • 由于對賬時間是以的post_time時間為準;獲取的是post_time當天的渠道側賬單明細數據;當對賬完成后,功能頁面顯示改天各收費項明細的總金額;方便內部人員知道公司在渠道這邊計費相關的財務狀況;
  • 對賬完成后,支持系統對渠道側和交易側對賬結果賬單的下載;同時系統會把對賬結果的excel文件自動推送的到通知群里,文件包括渠道側、交易側的對賬結果明細以及差異處理的文件。

注意:下載的文件中除了包括原始的賬單明細外,還要加上對賬的匹配結果字段,以及對需要回溯的數據,后面加上回溯天數。

差異處理:對賬完成后,對有差異的賬單明細系統推送給到差異處理功能中;去處理差異;同時也會生成excel文件自動發送到通知群里;提醒工作人員去處理。

  • 對由于時間差異導致交易側數據未錄入,需要等待回溯的訂單,回溯完成后渠道自動對賬,對平后,差異處理面板中該條數據系統自動刪除,如未對平則保留該條;等待差異處理。
  • 差異處理面板中的數據處理完成后,數據重新進入對賬流程和交易側數據進行對賬,直到賬單對平為止。進入對賬流程還是以該渠道的post_time時間為準。

8)下載與推送文件格式

  • 渠道側的文件命名:渠道名_matched_report_年_月_日
  • 交易側的文件命名:渠道名_Merchant_matched_report_年_月_日
  • 差異明細的文件命名:渠道名_差異明細_年_月_日

產品方案:

渠道對賬涉及到的渠道:不同渠道匹配規則不同,現以wechat和Alipay+渠道為例。

頁面信息展示:

A. 信息欄

① 渠道:可選擇wechat 和Alipay+

② 結算幣種:來源于渠道側給到的結算幣種,我方從賬單報表中進行提取可得:

  • Wechat結算幣種對應GBP/USD/EUR
  • Alipay的結算幣種對應HKD/GBP/USD/EUR

③ 交易幣種:客戶通常使用其本地貨幣(交易幣種)進行支付,但商家或供應商可能需要以另一種貨幣(結算幣種)來收款。

  • Wechat交易幣種有CNY/GBP
  • Alipay+交易貨幣有CNY/GBP

注:即根據前面【對賬時間】中關于對賬條目獲取的規則描述,可知,在次日0點時,系統根據渠道對應幣種數量自動生成對應的條目;每一個條目需要上傳一次渠道對賬文件;待此時工作時間資金上傳渠道報表,按照比重條目生成對應的對賬結果數據。

④ 時間:由于渠道側和交易側的對賬是根據匹配對應時間進行對賬,所以時間按照匹配對應時間獲取相應的條目

⑤ 賬單解析狀態:解析成功&解析中&解析失敗

⑥ 賬單筆數:分別顯示渠道側和交易側對賬文件中各自有多少條目;即顯示渠道側:200條;交易側:200條

⑥對賬結果:顯示:對平:XX條;待回溯:XX條;差異處理:XX條

待回溯指的是交易側由于匯率時間差或其他原因還沒有接收到對應的賬單條目;需要等待一段時間才會顯示。

⑦ 渠道側總額:由于匹配的賬單明細都是同一天,故渠道側總額等于當天渠道側賬單明細的所有條目交易總額;同理交易側總額等于交易側賬單明細所有條目的交易總額=tran_amount字段之和

⑧ 文件上傳時間:為資金開始操作對賬時間;

⑨ 操作人:操作對賬對應的工作人員名稱

⑩ 管理:詳情/差異處理/下載賬單/重新解析/刪除

  • 詳情:由于渠道除了為將賬對平,方便資金人員了解財務狀況及后續審計外,對公司側我們該環節的目的是將公司渠道計費涉及到的費用項提出,方便老板了解渠道側財務狀況;故詳情中重點羅列
  • 差異處理:同一匹配對應時間下,同一渠道下上傳渠道文件后,按照渠道下幣種數量生成條目,對應幣種下有差異的賬單明細進行差異處理;
  • 下載賬單:對賬完成后,支持下載對賬后的渠道賬單和交易賬單 i 下載的渠道賬單和交易賬單在原文件的基礎上新增對賬結果字段以及回溯天數字段(需要回溯的顯示回溯天數,不需要的顯示—)
  • 重新解析:由于網絡加載錯誤等原因導致需要重新上傳解析的,可以點擊重新解析按鈕,避免二次上傳文件;
  • 刪除:資金會出現對同一天的渠道文件進行二次上傳的場景,二次上傳時必須把前一條上傳的文件數據刪除,才能二次上傳;

B. 搜索欄

① 頁面信息展示:頁面一開始展示所有渠道的數據,按照渠道名稱首字母和匹配對應時間兩個條件倒敘配列;

② 渠道:支持Wechat 和Alipay+搜索;

③ 結算幣種:包括HKD/GBP/USD/EUR;

④ 時間:選擇時間后對應【匹配對應時間】字段的的檢索結果。

每日0點系統按照渠道對應貨幣拉取條目:

比如wechat渠道,對應結算貨幣有GBP/USD/EUR,即系統自動拉取三個條目。

上傳解析:

上傳渠道文件后解析過程提示分為解析成功和解析失敗。

① 解析成功:上傳—上傳中—正在解析—解析成功并判斷是否開始對賬—開始對賬—對賬成功/對賬失敗。

  • 對賬成功后,即可在對應條目上顯示計費信息;同時需要差異處理的賬單條目顯示在差異處理模塊中;
  • 對賬失敗后,請重新上傳;——解析結果欄中顯示解析失敗。

② 解析失敗:上傳—上傳中—正在解析—解析失?。?/p>

  • 解析失敗,請重新上傳;
  • 網絡加載超時,解析失敗請重新上傳;
  • 文件內容格式錯誤,解析失敗請重新上傳。

對賬完成后頁面展示的信息如上圖所示。

詳情:

詳情中主要展示計費相關的信息條目;主要包括:

① 對賬信息:渠道名稱/匹配對應時間/結算幣種/文件上傳時間/賬單筆數/對賬結果

② 渠道側賬單明細:即展示post_time當天從渠道側獲取的賬單中計費項的總金額,包括Total Settlement Amount/Total Acq_fee/Total Ic_fee/Total Scheme_fee/Total Other_fee/Total 3ds_fee/Total Settlement net Amount;

③ 交易側賬單明細:即展示post_time當天交易側(即公司數據庫中)獲取的賬單中計費項的總金額,包括Total Settlement Amount/Total Acq_fee/Total Ic_fee/Total Scheme_fee/Total Other_fee/Total 3ds_fee/Total Settlement net Amount;

④ 具體的費用項根據計費規則系統進行計算

部分渠道相關費用項,渠道側會算好給我們;有的渠道需要我們自己按照計費規則,系統進行計算。

差異處理:

差異處理頁面展示信息:

① 信息欄:展示字段包括渠道名稱/匹配對應時間/訂單號/未匹配天數/訂單金額/渠道流水總金額/交易流水總金額/差異處理狀態/操作時間/差異原因/操作人/管理。

訂單號:用于標識商戶或支付發起方系統中特定訂單或交易的唯一標識符。

注:如何根據訂單號追蹤PI號:

獲取訂單號和相關支付信息:首先,您需要獲取包含訂單號的商戶或支付發起方的相關交易信息。這可能是從您的系統中提取訂單號,或者從商戶或客戶提供的相關信息中獲取。

查找相關支付交易:使用訂單號,您可以聯系相關的支付渠道或銀行來查找與該訂單號相關的支付交易。這通常涉及與支付渠道或銀行的客戶支持或運營團隊進行聯系。

確認PI號:一旦找到相關支付交易,您可以請求支付渠道或銀行提供與訂單號相關的PI號。PI號通??梢栽谒麄兊闹Ц吨噶罨蚪Y算文件中找到。它是用于跟蹤國際支付和結算的重要標識符。

進行對賬或差異處理:一旦獲得了PI號,您可以將其用于對賬或差異處理。通過將訂單號與相關PI號關聯,您可以驗證支付是否已經成功處理,或者解決可能存在的不匹配或差異。

  • 未匹配天數:由于交易側數據獲取滯后導致部分數據未匹配,故允許在數據庫中回溯7天;當回溯時間為第四天匹配成功時,未匹配天數=4;
  • 訂單金額:即交易金額;
  • 渠道結算凈額:由于該渠道只對支付,不含退款;且僅對訂單狀態處于成功時的訂單進行對賬;所以渠道結算凈額=結算金額-手續費
  • 交易結算凈額:交易結算凈額=結算金額-手續費;
  • 差異處理狀態:已處理、待處理和處理中;
  • 操作時間:等于差異處理時間;
  • 差異原因:差異取決于交易側金額、渠道側金額于訂單金額不一致和訂單狀態;故差異原因包括:交易側金額與訂單金額不一致/渠道側金額與訂單金額不一致/金額與訂單狀態不一致/渠道側與交易側金額不一致/匯率差異/交易側無數據;
  • 管理:【差異處理】按鈕提交證據進行差異處理。

差異處理功能:

  • 訂單號:自動獲??;
  • 上傳憑證:支持上傳原始交易記錄/三方支付渠道或銀行記錄/我方訂單和交易記錄/匯率信息/手續費信息等截圖;要求上傳JPG//PNG/JPEG格式,文件不超過20M;
  • 差異處理記錄日志:上傳差異處理過程的操作日志/處理代碼等;
  • 差異原因:系統自動給出的原因有交易側金額與訂單金額不一致/渠道側金額與訂單金額不一致/金額與訂單狀態不一致/渠道側與交易側金額不一致/匯率差異/交易側無數據;該字段需要在系統給定的基礎上加以補充。

注:差異處理中的數據包括:渠道側和交易側確實存在差異(即賬沒有對平)和交易側數據由于時間差未及時獲取而無法和渠道側匹配對賬造成的差異。

① 渠道側和交易側確實存在差異:給出差異原因并進一步追溯解決;

  • 金額導致的差異:修改金額并提交支付憑證截圖;
  • 系統導致的差異:迭代BUG后,提交差異處理證明;
  • 匯率導致的差異:系統目前是每日線上從官方渠道拉取匯率值,若匯率不是想要的數值,后期支持手動修改,修正匯率。

② 時間差未及時獲取而無法和渠道側匹配對賬造成的差異:系統預留出7天的回溯時間,七天內如果該明細和交易側對平了,則差異處理中該條記錄自動刪除,同時渠道對賬中的相關費用隨著也要變化——具體根據匹配的PI號和匹配時間確定對應條目。

下載:支持下載渠道側和交易側的對賬結果明細。

對賬完成后,下載按鈕由置灰狀態變成可點擊狀態;同時選擇想要下載的賬單(支持多選)。

對賬成功后,除了頁面支持下載外,系統自動將交易和渠道側的對賬單明細以及差異明細文件發送到通知群中。

下載與發送:

  • 渠道側的文件命名:渠道名_matched_report_年_月_日
  • 交易側的文件命名:渠道名_Merchant_matched_report_年_月_日
  • 差異明細的文件命名:渠道名_差異明細_年_月_日

總結復盤:

① 明確目標—明確對賬業務邏輯和計費數據邏輯后:最后進行功能設計。

② 目標拆解:

A. 確保渠道提供商提供的賬單與實際交易記錄一致:

  • 渠道側賬單明細和交易側賬單明細具體涉及的金額由哪些,進行對賬;
  • 跨境國際對賬需要考慮幣種問題,不同的結算幣種對應的匯率不同,最終的結算金額也不同;
  • 如何展示最終對賬結果——遵從交互邏輯簡單,清晰展示涉及到的信息。

B. 跟蹤和解決渠道側和交易側之間的不平賬或差異,并解決:

  • 差異處理:展示差異和設計差異處理功能;
  • 搞清楚造成差異的原因:多收錢/少收錢/訂單狀態和金額不一致/兩邊金額不一致。

③ 對賬方法歸納總結為:

3. 清結算

清分:在清分階段,資金與賬單的計算和核對是核心任務。這一過程涉及對資金流動的準確計算,以及核實賬單的一致性。清分確保了在交易中的所有各方都得到了應有的款項,而且交易記錄得到了妥善處理。上述實際對賬案例就是清分的內容。

結算:結算階段是在清分后進行的,它涉及資產的實際轉移和完成交割。結算根據事先約定的結算方式和結算周期,將資金劃撥給涉及的各方,如商戶、用戶和支付通道。這一步驟確保了資金的真正轉移和歸屬。

結算規則:

影響結算周期的因素有:

  • 商戶進行結算時所在的國家;
  • 結算幣種所在國家。

本文由@月月有??吃 原創發布于人人都是產品經理,未經許可,禁止轉載。

題圖來自 Unsplash,基于CC0協議

該文觀點僅代表作者本人,人人都是產品經理平臺僅提供信息存儲空間服務。

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 大佬你好,請問渠道側對賬和賬賬對賬有沒更明顯的區別?我的理解成都是商家平臺的訂單流水數據和支付渠道類似支付寶給的賬單數據進行對帳,對比每一筆訂單的流水,和所有訂單的總流水數據。

    來自廣東 回復