在支付系統中，資金對賬，在對賬中心進行，將系統保存的賬務流水與銀行返回的清算流水和清算文件進行對賬，核對系統賬務數據與銀行清算數據的一致性，保證支付機構各備付金銀行賬戶每日的預計發生額與實際發生額一致。
清算對賬系統
支付公司提供的所有金融服務是建立在銀行資金體系之上的，支付公司賬務系統內賬戶的資金都與其在銀行的存款資金一一對應，為了保證真實的資金賬戶和虛擬賬戶的資金轉換正確，支付公司必須及時與銀行進行各類業務的資金核對，所有資金核對都依賴於銀行的系統。
1. 資金流入與銀行的對賬
從銀行流入的資金是由銀行側控制資金結轉清算與對賬時間，即每日客戶通過銀行向支付機構充值的資金是由銀行實時通知支付機構充值指令的發生，銀行在每日晚間經過彙總後向支付機構的銀行收款賬戶入賬，同時提供入賬清算文件。支付機構獲取該文件後，與業務數據進行核對。
對賬結果若相符，則沒有問題。若出現對賬結果不符，很有可能是系統或者業務在某些環節發生問題，存在兩種情況：
銀行充值明細多，支付機構充值明細少；即銀行向支付機構入賬資金多於支付機構業務發生情況，一般採取臨時掛賬處理，查出原因後再具體解決；
銀行充值明細少，支付充值明細多；即銀行向支付機構入賬資金少於支付機構業務發生情況，則可能對支付機構產生資金損失，一般採取臨時掛賬處理，查出原因後再具體解決。
2. 資金流出與銀行的對賬
從支付公司流出的資金是由銀行側控制資金結轉清算與對賬時間，即每日客戶向支付機構申請提現的資金是在每日支付公司批量向銀行發起提現請求時，從支付公司銀行存款賬戶扣轉，但扣轉的結果一般需要一段時間才能從銀行側得到反饋。
當銀行側提供扣轉成功和失敗的清算文件，支付公司獲取這些文件進行明細核對，對於提現失敗的申請，由支付公司後臺發起直接將資金回充入客戶賬戶，不在對賬中心進行對賬處理。
什麼是對賬？
什麼是資金對賬？
在會計上的概念：指為了保證賬簿記錄的正確性而進行的有關賬項的核對工作，做到賬證相符、賬賬相符、賬實相符。
在支付機構的概念：資金對賬，在對賬中心進行，將系統保存的賬務流水與銀行返回的清算流水和清算文件進行對賬，核對系統賬務數據與銀行清算數據的一致性，保證支付機構各備付金銀行賬戶每日的預計發生額與實際發生額一致。即核對銀行實際清算資金如充值、充退、提現等業務的銀行處理結果是否一致。
對賬中心的作用？
是主要處理對賬的系統模塊，主要業務是清算對賬。對賬中心部署於工作平臺，分別接受會計系統和清算系統的數據輸入進行對賬處理。
對賬中心最主要的職責是勾兌銀行清算流水與支付系統入賬流水，用以檢查反映銀存實際賬戶的餘額變化與支付系統內部戶餘額變化是否平衡。對於已經核對無誤的銀行清算流水和支付系統入賬流水，分別進入相應的歷史銀行流水庫和歷史入賬流水庫。
對於勾兌結果中銀行清算流水多於系統入賬流水的，而操作人員不明確資金的來源，需要根據所設定的分類規則將暫不明確的資金進行掛賬處理。而後我們認為該部分資金已經系統入賬，可以入歷史流水庫。
因為此時的銀存實際賬戶的餘額增加，與之對應的是支付系統內部戶餘額也增加了，比如： T 日的掛賬可能會在 T+N 日後進行銷賬確認，而後續的銷賬行為是對明細流水的業務分流處理，我們不應將 T+N 日的銷賬所產生的賬務流水作為入賬流水，不再需要到對賬中心體現。
對賬內容和數據來源
第一步
入賬流水和清算流水進行核對，目的是保證對每一筆訂單銀行的處理結果和我們系統的業務處理結果一致。
第二步
對賬彙總確認單和銀行對賬單進行核對，目的是通過軋餘額等方式，核對各類業務的銀行處理結果是否與銀行實際清算給我們的資金一致。
1. 對賬業務流程
對賬業務流程圖
2. 對賬中心主要功能
銀行發生資金變動的入賬流水，包括：充值、提現、提現失敗、充退、充退失敗、退票、購匯、信貸放款、信貸還款、還貸失敗一系列業務引起的賬務變動信息。這些業務流水在賬務系統入賬後，會計核心接收到登記分錄請求並處理完畢，發送該流水至對賬中心，對賬中心對於某個業務的反向資金變動所產生入賬流水也同步至對賬中心。
這樣做的目的是讓待清算與入賬流水在日切點保持等額，比如：提現 T 日會員申請提現，生成文件後會員賬戶提現金額轉入待清算提現款項，與此同時發送流水到對賬中心，此時待清算與對賬中心入賬流水是保持平衡的。
而 T+1 日銀行處理失敗，系統會回充帶清算提現款，如果此時不發送失敗流水到對賬中心與其對應的流水進行購銷的話，則入賬流水就會不變，和帶清算提現不平衡。
完整的日結流程支持：銀行清算流水入庫 → 流水對賬 → 流水分類 → 彙總確認單 → 自動掛賬 → 銷賬確認 → 操作員軋賬 → 總賬日結以及登記銀行餘額等。
完善的報表模型輸出：如按入賬日期 / 銀行日期 / 清算日期等的統計報表、銀行賬戶餘額報表、未達款項報表等；
提供日切服務：在經確認後進入歷史清算流水的，同步彙總該部分數據進入歷史流水彙總表中保存，所以在日切時，只需直接將該彙總數據再次彙總即可。
外圍業務功能支持：提供對於銀行賬戶（ 獨立於對賬中心之外，不參與處理邏輯 ）的管理功能，支持與內部戶的映射管理，用以滿足部分報表需求；提供基於賬務核心所提供的業務代碼查詢功能；提供對於財務系統的交互支持，包括與財務科目的對應關係管理、通知流水數據等；提供用以校驗訂單與清算流水匹配狀態的錯賬核實功能。
對賬流程圖
對賬中心功能模塊分析
獲取資金對賬數據：
獲取方式：需要進行清算流水導入的文件一般通過人工在頁面上導入，另外有些業務的流水文件通過系統自動匹配或者定時獲取的方式得到。
清算流水導入渠道非常多：需要統一各清算流水導入功能到一個頁面入口， 同時引入清算通道對賬的邏輯，將清算流水導入過程需要映射清算通道（ 包含新增清算流水等 ）。
各類業務的清算流水文件的解析和導入邏輯不一樣。
清算流水對賬：
對賬邏輯：
一對一對賬：入賬流水只可能存在一條，銀行入賬流水也僅存在一條，然後一對一去對。目前按照一對一對賬的業務涉及到：網銀 B2C 充值、網銀 B2B 充值、VISA、網匯E、卡通充值、正常提現、認證提現、銀企互聯提現、卡通提現、賣家信貸、信用卡還款提現、COD、網點支付。
對賬標準：清算通道 + 訂單號 + 金額 Or 銀行名稱 + 業務代碼 + 訂單號 + 金額。
滿足一對一的業務如下：
提現成功：500401
認證提現：500402
還貸：500404
卡通提現：500403
個人網銀充值：400301
企業網銀充值：400302
VISA：400314
網匯e：400315
卡通充值：400304
貸款：400307
銀企互聯提現：500405
信用卡還款提現：500407
後臺強制提現500406
COD
網點支付
Tips：
清算流水有，入賬流水也有，金額一致，對賬成功，清算流水、對賬流水打上 ‘對賬成功’ 標誌，記錄對賬日期為系統當日；
清算流水有，入賬流水也有，金額不一致，清算流水記金額不等，記錄對賬日期為系統當日，入賬流水不變；
-
清算流水有，入賬流水該訂單號沒有，清算流水打上 ‘銀行多帳’ 的標誌，記錄對賬日期為系統當日；
清算流水有，入賬流水沒有該業務代碼初始狀態的，清算流水打上 ‘銀行多帳’ 的標誌，記錄對賬日期為系統當日；
清算流水有，入賬流水沒有該銀行的初始狀態的記錄，清算流水打上 ‘銀行多帳’ 的標誌，記錄對賬日期為系統當日；
對賬之前需要判斷 1 對 1 的流水中是否有重複，有重複的返回失敗不進行後續對賬。
多對多對賬：入賬流水裡相同訂單號，相同清算渠道，相同，金額相同業務代碼的流水存在對條（比如充退）；而銀行清算流水也可能是存在多條的情況的，這種情況下是多對多去對賬的，遵循先到的先對的原則。
滿足多對多的業務如下：
-
充退：410401
銀企互聯充退：410402
Motopay 充退：410403
Tips：
清算流水有，入賬流水有，滿足對賬標準，則對賬成功，清算流水、對賬流水打上 ‘對賬成功’ 標誌，記錄對賬日期為系統當日；
清算流水有，入賬流水有，金額不等，清算流水打上 ‘金額不等’ 的標誌，記錄對賬日期為系統當日，入賬流水不變；
清算流水有，入賬流水沒有該訂單號，清算流水打上‘銀行多帳’ 的標誌，記錄對賬日期為系統當日；
清算流水有，入賬流水沒有初始狀態 410401 的流水，清算流水打上 ‘銀行多帳’ 的標誌，記錄對賬日期為系統當日；
清算流水有，入賬流水沒有這個銀行初始狀態 410401 的流水，清算流水打上 ‘銀行多帳’ 的標誌，記錄對賬日期為系統當日；
清算流水有，入賬流水沒有初始狀態的 ‘410401’ 的流水，清算流水打上 ‘銀行多帳’ 的標誌，記錄對賬日期為系統當日。
一對多對賬：入賬流水有多條，和銀行的一條去對賬。
對賬標準：清算通道 + 訂單號 + 金額 Or 銀行名稱 + 業務代碼 + 訂單號 + 金額
涉及的業務：境外收單
境外收單購匯扣款（520101）
購匯益回補購匯賬戶（400319）
Tips：
入賬流水存在 2 條 520101 的，清算流水存在 1 條 520101 的，將入賬流水的 2 條加和後的金額和清算流水的進行對賬，一致的為對賬成功；
入賬流水存在 1 條 520101 的，1 條 400319 的，那麼要將 2 條金額之差和清算流水的 1 條 520101 的進行對賬。不會出現 3 條 520101 或者 2 條 400319 的情況。
內部流水購銷 ：內部流水購銷是針對那種有入賬流水錶來說的，比如提現業務，提現文件生成就會扣款此時會同步一筆入賬流水；而回導失敗之後又會回充，此時也會同步一筆反向的業務流水，這兩條流水不用再去和銀行的資金流水進行對賬，直接在入賬流水這邊進行購銷即可。
需要購銷的業務如下：
購銷的規則：非已勾銷狀態下，同一銀行同一訂單號，金額一致而業務代碼相反的正向流水進行勾銷，而且一條反向流水只勾銷一條；
日終軋賬時候的購銷：日終軋賬的時候會對未購銷的流水再次進行購銷確保當天的流水都購銷完全。（這個情況是為了解決反向流水先於正向流水先出現的邏輯錯誤情況而加的並提示流水號）；
如果業務代碼相反，而金額不等的情況，就無法進行購銷，這種情況原來是作為違反邏輯規則來進行標記的。這部分數據進行查明之後，可以修改流水之後，在日終軋賬的時候從新進行購銷；
購銷分 ‘一對一’（提現）和 ‘多對多’ （充退）的購銷；
勾銷的流水不入歷史庫。
對賬彙總確認單：
顯示對賬結果，選擇後續的相應的處理界面，複核員在此模塊進行流水的確認，還有的功能就是對於已經對賬處理的銀行清算流水與系統入賬流水進行後續業務分流推進。
對於大部分對賬成功的數據，可以將這些流水確認，確認後該部分流水將進入歷史清算流水，只有進入歷史清算流水的才認為銀行與支付系統數據對平。對賬成功的銀行清算流水、賬務入賬流水全部進入各自歷史清算流水錶保存，相應的銀行清算流水與入賬流水同步刪除。
金額不等的流水，可能是銀行清算流水文件有誤，也可能是錯賬，採取的做法是操作員手工修改金額，在銀行清算流水管理裡操作或直接刪除，將其推進到下一輪的對賬處理環節，對賬是可以重複對的，只要滿足初始狀態要求的流水即可。
多賬部分，由於各種已明確/未明確的原因，銀行已經實際清算給支付公司了，但支付公司的賬務系統並沒有入賬，需要提供一個流水分類和分類彙總掛賬的操作入口。系統默認多賬的流水給出的菜單是流水分類，金額不等的流水給出的流水管理頁面。區別在於，在點流水分類時，只允許修改業務類型、銀行日期，而且改完後不改變多賬狀態；流水管理，修改狀態後，流水的對賬狀態將變成初始狀態，需要進行重新對賬。
流水進入歷史庫的校驗規則。
舉例說明：A 操作員導入了一筆流水，系統對賬成功，銀行清算流水與賬務入賬流水狀態都被置為成功狀態；B 操作員再次導入該相同流水，由於入賬流水處於成功狀態的可以繼續對賬，所以再次對賬成功。系統在對賬環節認為正常，但在入歷史清算流水時必須做每組流水數據的平衡檢查：必須是清算流水總額與入賬流水總額匹配才可以進歷史數據。
對於上述的場景，如複核員針對 B 操作員的對賬成功流水確認後，可以正常進入歷史流水，對賬批次號認最後操作的批次。而繼續對 A 操作員的成功對賬流水確認，則系統將認為是不合法的入歷史流水行為。或者不對特定操作員的彙總確認，系統必須檢驗出所存在的重複銀行清算流水，並將對應的明細數據顯示覆核員。此時可將該重複對賬的清算流水刪除即可。
流水分類和分類彙總掛賬：
對於多賬的流水對賬中心提供一個單獨的處理入口，首先在此處進行分類，然後進行彙總掛賬處理。操作人員可以根據多賬流水的未確認類型修改成對應的業務代碼，允許修改成業務類型為 7 的可掛賬的類型（其他業務代碼不允許掛賬）；流水可以重複分類，系統不做控制；但已申請掛賬的除外，分類完畢的多賬流水可直接提供分類彙總掛賬操作。
系統根據既定的業務代碼判斷是待查收入或待查支出掛賬，頁面跳轉至相關憑證登記頁面，此處業務規則同待查收支掛賬；另一部分比如退票，因為不經過對賬環節，所以需要直接在清算流水查詢裡面新增，業務代碼 700106 未確認退票，不需要經過對賬，直接去彙總確認單裡將流水掛賬。允許掛賬的業務代碼如下 ：700101 其他應付款，700102 其他應收款，700103 銀行錯賬，700104 未確認結匯款，700105 線下匯款，700106 未確認退票，700107 未確認收款，700108 未確認支出款。
提交憑證登記申請相關校驗：流水此刻狀態是否是 ‘多帳’ ，申請提交人是否是當時的對賬人，憑證登記成功，清算流水記錄憑證號，流水狀態改為 ‘已掛賬’ ；
彙總掛賬的反交易同步入賬流水，金額是負值，系統在清算流水裡在做一條數據，自動對賬。
清算/入賬/歷史流水管理：
清算流水管理
對於所有的清算流水，都可以在此模塊下進行查詢、修改、刪除，同時也可以新增流水。
查詢功能，銀行名稱、業務代碼、銀行日期不能為空，業務代碼和銀行可以多選。
修改功能，處於未對賬（初始）、金額不等、多賬、對賬成功狀態的流水可以進行單筆、批量修改操作，這裡的批量修改動作與流水分類功能類似，只是該功能入口不僅支持對批量流水的業務代碼、銀行日期更新，也支持其他要素信息批量修改，作為提供給操作員在未對賬前批量修改已知流水的手段之一；對已掛賬的流水，不允許更新。
流水刪除：處於未對賬（初始）、金額不等、多賬、對賬成功狀態的流水可以進行單筆、批量刪除操作，已掛賬狀態不允許刪除。
入賬流水管理
入賬流水管理功能提供對賬務入賬流水的查詢以及下載功能；為了杜絕對入賬流水的人為變更操作，禁止支持對入賬流水進行修改或刪除處理。
查詢時銀行名稱、業務代碼、入賬日期不能為空，業務系統流水號：針對某類業務的業務流水號，如充值業務就是充值流水號；賬務流水號：賬務處理的流水號，即賬務操作記錄數據的序號，在賬戶明細查詢裡可以獲取。
對於提現類失敗回充的流水，在操作員進行對賬動作後，系統自動進行購銷，在入賬流水查詢時，將對賬狀態選為已購銷可以查到，這些不進入歷史庫，根據數據量，系統定時清理這些數據。
歷史流水管理
分為歷史入賬流水和歷史清算流水，查詢功能在同一頁面，查詢時可以一起查詢，也可以單獨查詢。歷史流水只供查詢和下載，不允許進行修改和刪除操作。選擇歷史銀行流水和歷史清算流水（清算日期的時間間隔不能超過 7 天）進行查詢，歷史入賬流水中無銀行日期，歷史銀行流水中無入賬日期。
銀行餘額錄入功能：
在該模塊下，實現對每個銀行賬戶的實際餘額錄入，以此來和內部賬戶餘額進行匹配校驗。分為銀行餘額登記，銀行餘額導入（複核），以及銀行餘額查詢功能。
銀行餘額登記：選擇對應日期以及銀行賬戶錄入後，保存，此時去銀行餘額查詢是看不到錄入餘額的，需要複核導入核對完畢後才能看到，保證核對的有效性。登記後系統記錄一個臨時餘額。系統每天凌晨 1:15 的時候會跑批，取上一日已複核過的餘額自動帶入下日臨時餘額，如果不登記的話，就取上日餘額。
銀行餘額導入：標準格式是一個填寫銀行餘額的 excle 模板，導入後的核對邏輯，對複核員導入的數據進行檢測該帳戶是否有臨時餘額。根據銀行賬號、銀行日期、銀行餘額等條件查詢銀行餘額表。
判斷 1 ：如果查詢出結果為空那麼將返回給用戶：“這個銀行帳號找不到對應的銀行臨時餘額！”。
判斷 2 ：如果查詢結果大餘一條，將返回給用戶：“這個銀行帳號的一天有多個銀行臨時餘額，不正常！”
判斷 3 ：檢測該銀行帳號對應的銀行餘額是否相等。如果不相等將返回給用戶：“臨時餘額和實際餘額不相等，核對失敗！”當餘額核對成功後，將複核員導入的餘額寫入該對應帳戶的實際餘額，並修改餘額狀態為已複核。實際餘額更新成功後，將刪除當天日期的臨時餘額。
銀行餘額查詢：對操作員登記餘額的信息，以及複核員複核過的餘額進行查詢，查詢條件：銀行名稱、銀行帳戶、帳戶狀態、銀行日期、餘額狀態。帳戶狀態：分為正常、廢除、和銷戶三個狀態，默認為正常狀態。餘額狀態：分為未錄入（N）、已錄入（A）、已複核（Y）三個狀態，默認為全部。
內部賬戶登賬：
業務簡述
針對日常結算工作中非銀行待查類的內部賬戶進行登記，如：清算款、利息、手續費等；該業務登記不產生後續業務登記行為，即不具有作為初始憑證號的使用功能。對於批量銷帳類業務處理中，多會員轉帳失敗的，導致過渡戶上有剩餘金額情況的，可通過此處進行內部戶登賬，將過渡戶（負債）和銀存（資產）餘額同時減少，再通過待查收入掛帳實現平衡。
業務校驗規則
必須登記的是一借一貸帳戶信息；
借貸方帳戶不能一致；
金額必須大於 0 ；
不允許任意一方是銷帳帳戶。
是否同步對帳中心流水：不需要同步對帳中心流水。
待查收入掛賬：
業務簡述
應用於結算操作員針對日常結算工作中的銀行待查收入進行登記，所產生的業務憑證號作為後續銷帳業務的原業務憑證號，並且作為所有該登記所引發的後續業務登記的初始憑證號。其中待查收入掛帳業務憑證的借方（銀存帳戶）所對應的銀行名稱作為後續銷帳業務的銀行名稱，包括差額重新掛帳部分再銷帳的業務憑證，都遞沿該銀行名稱。
業務校驗規則：
必須登記的是一借一貸帳戶信息；
借貸方帳戶不能一致；
金額必須大於 0 ；
借方帳戶必須是銀存帳戶；
貸方帳戶必須是銷帳帳戶。
是否同步對帳中心流水：不需要同步對帳中心流水。
待查收入確認：
業務簡述
針對銀行待查收入登賬的掛帳，可以通過本模塊進行銷帳。此處採取銷帳確認方式進行處理，需要選擇相應的待查收入掛帳業務憑證進行銷帳業務登記。該業務登記可能產生後續業務登記行為，如差額銷帳情況下，系統會自動做不足額部分的重新掛帳並複核通過，所產生的掛帳憑證作為後續銷帳憑證的銷帳卡片號。
業務校驗規則：
所銷的原待查收入掛帳憑證必須合法；
所銷的原待查收入掛帳憑證必須已複核通過，處理完畢；
所銷的原待查收入掛帳憑證不能已被銷帳；
銷帳總額(貸方發生額之和不得大於原待查收入掛帳憑證發生額)並大於 0 ；
貸方必須是內部戶。
待查支出掛賬：
業務簡述：
針對日常結算工作中的銀行待查支出進行登記，所產生的業務憑證號作為後續銷帳業務的原業務憑證號，並且作為所有該登記所引發的後續業務登記的初始憑證號。其中待查收入掛帳業務憑證的貸方（ 銀存帳戶）所對應的銀行名稱作為後續銷帳業務的銀行名稱，包括差額重新掛帳部分再銷帳的業務憑證，都遞沿該銀行名稱。
業務校驗規則：
必須登記的是一借一貸帳戶信息；
借貸方帳戶不能一致；
金額必須大於 0 ；
貸方帳戶必須是銀存帳戶；
借方帳戶必須是銷帳帳戶 。
是否同步對帳中心流水：不需要同步對帳中心流水。
待查支出確認：
業務簡述
針對銀行待查支出登賬的掛帳，可以通過本模塊進行銷帳。此處採取銷帳確認方式進行處理，需要選擇相應的待查支出掛帳業務憑證進行銷帳業務登記。該業務登記可能產生後續業務登記行為，如差額銷帳情況下系統會自動做不足額部分的重新掛帳並複核通過，所產生的掛帳憑證作為後續銷帳憑證的銷帳卡片號。
業務校驗規則：
所銷的原待查支出掛帳憑證必須合法；
所銷的原待查支出掛帳憑證必須已複核通過，處理完畢；
所銷的原待查支出掛帳憑證不能已被銷帳；
銷帳總額(借方發生額之和不得大於原待查收入掛帳憑證發生額)並大於0 ；
借方必須是內部戶。
意外數據恢復邏輯
1. 意外數據恢復邏輯
重複支付：對同一內部訂單號進行了二次或二次以上的支付。
支付失敗，金額不等：買家實際支付的金額與交易金額不等。一般產生的原因是，買家在支付時，產生了掉單，賣家隨後修改了交易價格。 在進行網銀對賬的時候，即會出現訂單金額和交易金額不等的情況，且是一筆掉單。2、3 兩類情況只發生在支付上。
支付成功，金額不等（這一類異常，偶爾有發生）：商戶訂單狀態為成功，後臺訂單狀態也為成功，並且交易狀態是買家已付款，等待賣家發貨。
（金額不等，支付成功，是因為會員對一個交易進行支付，但由於網絡或銀行系統等原因支付公司未接收到銀行扣款信息，支付側交易狀態未予以變更，後賣家對該交易修改了價格，買家又對該修改過的價格進行了支付。但該支付成功的信息仍然沒有被支付側接收到，該交易狀態仍未變更，後支付側後臺人員先對後面的那筆意外數據進行了恢復，後再對前面那筆意外數據恢復，就會出現這種“金額不等，支付成功”的數據）
2. 對帳及異常恢復邏輯
以商戶成功訂單為準：
用商戶上的成功訂單與後臺的訂單來核對：
若商戶訂單為成功，後臺為初始或者失敗，則更改後臺狀態為成功；
若後臺為成功，商戶成功訂單中無該訂單（時間差），則不更改後臺狀態；
若後臺為初始或失敗，商戶成功訂單中無該訂單，則不更改後臺狀態。
不重複恢復：
T+1 日恢復T 日的訂單，並且在 T+1 日後不再下載 T 日的訂單進行二次或多次恢復。（為考慮會員感受，T 日下班前恢復 T 日 0 點到下班時點的訂單）
時間性差異：
由於各家銀行系統日切點均不同，並且大多不會在每日的 24 點（或早或晚），所以下載到的 T 日的訂單流水與後臺T日（ 0:00－24:00 ）的訂單流水並不能全部對應上。將商戶訂單流水與後臺訂單流水核對，會出現商戶有，後臺無；商戶無，後臺有；商戶有，後臺有三種情況。對於 1、2 兩種情況為我們所說的時間性差異。
商戶數據與後臺數據的關係為：
商戶數據－（商戶有，後臺無）＋（商戶無，後臺有）＝ 後臺數據
友情提示
支付圈將與支付學院展開進一步合作，支付學院將建立支付學習型社群和線下培訓平臺，分享交流支付技術最新前言，更多有料請及時關注支付圈或者加入支付圈產品技術交流群
請添加客服二維碼由客服拉入添加好友請備註否則不予通過
公司+姓名+技術崗位
本群只加支付技術人員和產品或者欲從事相關技術開發人員，其他人員不加！
你會喜歡
閱讀更多 支付圈 的文章
