為了可以更好地解釋支付結算系統對賬過程，我們先把業務從頭到尾串起來描述一下場景，幫助大家理解：
一個可能得不能再可能的場景，請大家深刻理解里面每個角色做了什么，獲取了哪些信息：
某日陽光燦爛，支付寶用戶小明在淘寶上看中了暖腳器一只，價格100元。猶豫再三后小明使用支付寶網銀完成了支付，支付寶顯示支付成功，淘寶賣家通知他已發貨，最近幾日注意查收。
我們來看看這個過程中有幾個相關方，分別做了什么。我語文不好，寫得饒口，如果看不懂請多看幾次：
小明：持卡人，消費者，淘寶和支付寶的注冊會員，完成了支付動作，自己的銀行賬戶資金減少，交易成功。
銀行：收單銀行，接受來自支付寶的名為“支付寶BBB”的100元訂單，並引導持卡人小明支付成功，扣除小明銀行卡賬戶余額后返回給支付寶成功通知，並告訴支付寶這筆交易在銀行流水號為“銀行CCC”
支付寶：支付公司，接收到淘寶發來的訂單號為“淘寶AAA”的商戶訂單號，並形成支付系統唯一流水號：“支付寶BBB”發往銀行系統。然后獲得銀行回復的支付成功信息，順帶銀行流水號“銀行CCC”
淘寶：我們支付公司稱淘寶這類電商為商戶，是支付系統的客戶。淘寶向支付系統發送了一筆交易收單請求，金額為100，訂單號為:“淘寶AAA”，支付系統最后反饋給淘寶這筆支付流水號為“支付BBB”
以上流程貌似大家都達到了預期效果，但實際上仍然還有一個問題：
對支付公司（支付寶）而言，雖然銀行通知了它支付成功，但資金實際還要T+1后結算到它銀行賬戶，所以目前只是一個信息流，資金流還沒過來。
Tips:插一句話，對支付系統內部賬務來說，由於資金沒有能夠實時到賬，所以此時小明的這筆100元交易資金並沒有直接記入到系統資產類科目下的“銀行存款”科目中，而是掛在“應收賬款”或者“待清算科目”中。大白話就是，這100元雖然答應給我了，我也記下來了，但還沒收到，我掛在那里。
對商戶（淘寶）而言，雖然支付公司通知了它支付成功，他也發貨了，但資金按照合同也是T+1到賬。如果不對賬確認一下，恐怕也會不安。
倒是對消費者（小明）而言：反正錢付了，你們也顯示成功了，等暖腳器呀等暖腳器~
基於支付公司和商戶的困惑，我們的支付結算系統需要進行兩件事情：一是資金渠道對賬，通稱對銀行帳；二是商戶對賬，俗稱對客戶帳。對客戶帳又分為對公客戶和對私客戶，通常對公客戶會對對賬文件格式、對賬周期、系統對接方案有特殊需求，而對私客戶也就是我們一般的消費者只需要可以后台查詢交易記錄和支付歷史流水就可以了。
我們先聊銀行資金渠道對賬，由於支付公司的資金真正落地在商業銀行，所以資金渠道的對賬顯得尤為重要。
在一個銀行會計日結束后，銀行系統會先進行自己內部扎帳，完成無誤后進行數據的清分和資金的結算，將支付公司當日應入賬的資金結算到支付公司賬戶中。於此同時，目前多數銀行已經支持直接系統對接的方式發送對賬文件。
於是，在某日臨晨4點，支付寶系統收到來自銀行發來的前一會計日對賬文件。根據數據格式解析正確后和前日支付寶的所有交易數據進行匹配，理想情況是一一匹配成功無誤，然后將這些交易的對賬狀態勾對為“已對賬”。
Tips:此時，對賬完成的交易，會將該筆資金從“應收賬款”或者“待清算賬款”科目中移動到“銀行存款”科目中，以示該交易真正資金到賬。
以上太理想了，都那么理想就不要對賬了。所以通常都會出一些差錯，那么我總結了一下常見的差錯情況：
1.支付時提交到銀行后沒有反饋，但對賬時該交易狀態為支付成功
這種情況很正常，因為我們在信息傳輸過程中，難免會出現掉包和信息不通暢。消費者在銀行端完成了支付行為，銀行的通知信息卻被堵塞了，如此支付公司也不知道結果，商戶也不知道結果。如果信息一直沒法通知到支付公司這邊，那么這條支付結果就只能在日終對賬文件中體現了。這時支付公司系統需要對這筆交易進行補單操作，將交易置為成功並完成記賬規則，有必要還要通知到商戶。
此時的小明：估計急的跳起來了……付了錢怎么不給說支付成功呢！坑爹！
TIPS：通常銀行系統會開放一個支付結果查詢接口。支付公司會對提交到銀行但沒有回復結果的交易進行間隔查詢，以確保支付結果信息的實時傳達。所以以上情況出現的概率已經很少了。
2.我方支付系統記錄銀行反饋支付成功，金額為100，銀行對賬金額不為100
這種情況已經不太常見了，差錯不管是長款和短款都不是我們想要的結果。通常雙方系統通訊都是可作為糾紛憑證的，如果銀行在支付結果返回時確認是100元，對賬時金額不一致，可以要求銀行進行協調處理。而這筆賬在支付系統中通常也會做對應的掛賬處理，直到糾紛解決。
3.我方支付系統記錄銀行反饋支付成功，但對賬文件中壓根不存在
這種情況也經常見到，因為跨交易會計日的系統時間不同，所以會出現我們認為交易是23點59分完成的，銀行認為是第二天凌晨0點1分完成。對於這種情況我們通常會繼續掛賬，直到再下一日的對賬文件送達后進行對賬匹配。
如果這筆交易一直沒有找到，那么就和第二種情況一樣，是一種短款，需要和銀行追究。
以上情況針對的是一家銀行資金渠道所作的流程，實際情況中，支付公司會在不同銀行開立不同銀行賬戶，用以收單結算（成本會降低），所以真實情況極有可能是：
臨晨1點，工行對賬文件丟過來（支行A）
臨晨1點01分，工行又丟一個文件過來（支行B）
臨晨1點15分，農行對賬文件丟過來
。 。 。
臨晨5點，興業銀行文件丟過來
。。。
不管什么時候，中國銀行都必須通過我方業務員下載對賬文件再上傳的方式進行對賬，所以系統接收到中行文件一般都是早上9點05分……
對系統來說，每天都要處理大量並發的對賬數據，如果在交易高峰時段進行，會引起客戶交互的延遲和交易的失敗，這是萬萬行不得的
所以通常支付公司不會用那么傻的方式處理數據，而是在一個會計日結束后，通常也是臨晨時段，將前一日交易增量備份到專用對賬服務器中，在物理隔絕環境下進行統一的對賬行為，杜絕硬件資源的搶占。
以上是銀行資金渠道入款的對賬，出款基本原理一致，不過出款渠道在實際業務過程中還有一些特別之處，由於大家不是要建設系統，我就不贅述了。
談完了資金渠道的對賬，我們再來看看對客戶帳。
前面提到了，由於資金落在銀行，所以對支付公司來說，對銀行帳非常重要。那么同理，由於資金落在支付公司，所以對商戶來說，對支付公司賬也一樣重要。能否提供高品質甚至定制化的服務，是目前支付公司走差異化路線的一個主要競爭點。
-------------------------------
一、對支付系統而言，最基本的對賬功能是供商戶在其后台查詢下載某一時間段內的支付數據文件，以供商戶自己進行對賬。
這個功能應該是個支付公司就有，如果沒有就別混了。
二、對大多數支付系統而言，目前已經可以做到對賬文件的主動投送功能。
這個功能方便了商戶系統和支付系統的對接，商戶的結算人員無須登錄支付平台后台下載文件進行對賬，省去了人工操作的麻煩和風險。
對大型支付系統而言，商戶如果跨時間區域很大，反復查詢該區域內的數據並下載，會對服務器造成比較大的壓力。各位看官別笑，覺得查個數據怎么就有壓力了。實際上為了這個查詢，我最早就職的一家支付公司重新優化了所有SQL語句，並且因為查詢壓力過大服務器癱瘓過好幾次。
現在比較主流的做法是把商戶短期內查詢過、或者經常要查詢的數據做緩存。實在不行就干脆實時備份，兩分鍾同步一次數據到專用數據庫供商戶查詢，以避免硬件資源占用。甚至……大多數支付公司都會對查詢范圍跨度和歷史事件進行限制，比如最多只能查一個月跨度內，不超過24個月前的數據……以避免服務嗝屁。
對賬這塊大致就這樣了，再往細的說就說不完了，大家有什么想問的可以單M我或者回復答案。
稍后給大家講一下風控。1.對賬周期：A公司對玩家開放了包括支付寶、財付通在內的十余種電子支付渠道，大部分都是按月對賬的，即當月1-10號（視渠道有差異）進行對賬，然后11號開始打款/轉賬。部分渠道可能是本月對上上個月的賬，即3月對1月的賬，如短信渠道（還分本地和外地）。還有的可能是周結算，如中騰神州行。
2.各渠道成交額： 快錢、易寶等開通了網關支付+賬戶余額支付的渠道成交量最大，最高的時候可以達到千萬級別，最低也是小百萬的級別，其次是支付寶和財付通等，最小的是中騰神州行等，每周僅有幾千元而已。
3.為何要對賬：由於雙方都有計費系統，誰都不願少收錢/多付錢，所以就需要對賬后完成打款/轉賬等流程。而由於網絡/渠道的差異性等總會存在雙方訂單不一致的現象，2者一致的很少很少。不一致的情況有這幾種可能：支付渠道扣款成功了但商戶這顯示訂單未完成（玩家會隨時反饋給A公司，然后A公司及時的核對該筆訂單並給玩家補償對應金額的游戲貨幣），支付渠道未扣款成功但商戶顯示支付成功了，在我經歷3個月對賬工作中，主要還是前者居多。 不一致的訂單總金額如果占當月的交易額度在一定范圍內，基本雙方都懶得查了（數萬甚至數十萬筆訂單查起來很惱火），然后就是走財務流程打轉/轉賬了。
4.怎么來對賬：支付寶、財付通、易寶和快錢等支付渠道給接入商戶開放了對賬后台的權限，商戶可以隨時查看月流水，而系統會在月初生成上個月的所有訂單列表，這個訂單列表可能有成千上萬行（支付渠道訂單號、商戶訂單號、訂單金額、下單時間、完成時間等），而A公司本身的充值系統也可以導出訂單列表，好了，根據訂單號來匹配，篩選出不一致的訂單，然后逐個的去查吧。
5.對賬要多久： 對賬這個事情真的好惱火啊，2個Excel表格一共成千上萬的訂單，開始是通過Excel透視表/篩選等各種方式弄，后來找程序員同事寫個了工具，但比對完了還是有數十甚至上百個不一致的訂單，然后這些只能從2個后台挨個逐筆的對，一共10多個渠道啊，現在想起來都覺得不堪回首。不過也有例外，A公司通過程序實現了QQ幣每日對賬，如果前一天雙方訂單不一致，系統則會將不一致的訂單號郵件發給相關人員，然后針對這幾筆訂單操作即可。一致的話就不會發，總得算來，QQ幣每月不一致的維持在30筆以內。
6.誰來對賬：支付寶、財付通等支付渠道跟商戶聯系的人分3類：銷售、技術和商務（姑且這么叫吧）。一般銷售會負責前期支付渠道的談判和接入，技術則負責具體的接口調試和實施以及日常運維，商務則負責商戶的日常維護和渠道的監控以及對賬事宜，如支付渠道需要維護或調整，商務會提前知會給各大商戶，然后商戶這邊出公告、臨時關閉該渠道入口。部分公司銷售和商務的職能分的不是太細，都是1個人完成的。如果商戶的月成交額達到千萬級別以上，支付渠道這邊就會對你格外的重視，貌似我了解的幾個支付渠道是銷售人員在直接跟商戶打交道，然后商戶該月的流水決定了銷售人員的獎金和提成。
7.爭議比例范圍： 相對於一個支付渠道每月幾百萬的流水，幾百甚至上千元的爭議訂單就顯得微不足道了（我接觸的那段時間，基本最多的也就在千元左右），商戶需要及時的從支付渠道那兒收回資金以支付廣告費和公司的運作，不可能也沒必要為了幾百甚至上千的金額拖幾天，先把無爭議雙方認可的金額走完流程再說，剩下的部分慢慢再對賬。 再者支付渠道方面1個人可能負責數十家商戶，天天被這些訂單惡心着。麥當勞肯德基還有0.1%的損耗，工廠還有次品率呢，更無須說商戶和支付渠道的這些爭議訂單了。
8.商戶如何風控：支付渠道上線前肯定是需要在各個瀏覽器、操作系統下進行調試的，調試無誤后才會上線。而網銀類一般都有支付上限，各個商戶也在充值頁面限定了單筆支付的上限，而對於數據負載這塊，商戶這邊單個渠道每天的訂單筆數能有5000筆就不錯了，差不多也就每分鍾4筆的請求量，這個相對於游戲開服時登陸/加載的數據量來說不算大吧。而客服人員也會24小時關注玩家反饋的充值問題，有了問題商戶能解決的就商戶搞定了，搞不定的也會臨時關閉渠道入口並通知支付渠道來一起搞定吧，所以更大的風險應該是來自於支付渠道本身吧。