支付寶等大型支付系統後臺系統是如何對賬和風控的
阿新 • • 發佈：2018-11-01
作者：天順
連結：http://www.zhihu.com/question/20091391/answer/15591658
來源：知乎
著作權歸作者所有，轉載請聯絡作者獲得授權。
先扯淡一下對賬，這坑有點大，容我慢慢填。剛剛打了半小時的草稿由於沒儲存，宕機後被系統吃掉了……知乎貌似原來有自動儲存功能的……去哪裡了……
業務上，為何對賬，對賬的操作步驟等@詹世波已經說得很多了，我談談一些沒涉及的。
關於對賬更深層次的理解，請各位關注我的專欄，我會不定時在專欄裡分享我關於支付業務的理解。
為了可以更好地解釋支付結算系統對賬過程，我們先把業務從頭到尾串起來描述一下場景，幫助大家理解：
一個可能得不能再可能的場景，請大家深刻理解裡面每個角色做了什麼，獲取了哪些資訊：
某日陽光燦爛，支付寶使用者小明在淘寶上看中了暖腳器一隻，價格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分……
對系統來說，每天都要處理大量併發的對賬資料，如果在交易高峰時段進行，會引起客戶互動的延遲和交易的失敗，這是萬萬行不得的
所以通常支付公司不會用那麼傻的方式處理資料，而是在一個會計日結束後，通常也是臨晨時段，將前一日交易增量備份到專用對賬伺服器中，在物理隔絕環境下進行統一的對賬行為，杜絕硬體資源的搶佔。
以上是銀行資金渠道入款的對賬，出款基本原理一致，不過出款渠道在實際業務過程中還有一些特別之處，由於大家不是要建設系統，我就不贅述了。
談完了資金渠道的對賬，我們再來看看對客戶帳。
前面提到了，由於資金落在銀行，所以對支付公司來說，對銀行帳非常重要。那麼同理，由於資金落在支付公司，所以對商戶來說，對支付公司賬也一樣重要。能否提供高品質甚至定製化的服務，是目前支付公司走差異化路線的一個主要競爭點。
就流程而言@詹世波已經說的差不多了，我就不贅述了……
----------------------------------------------------------沒經過排版的小知識點---------------------------------------------------
之前說過，銀行與支付公司之間的通訊都是可以作為糾紛憑證的。原理是對支付報文的關鍵資訊進行金鑰加簽+md5處理，以確保往來報文“不可篡改，不可抵賴”。
同理，支付公司和商戶之間也會有類似機制保證報文的可追溯性，由此我們可以知道，一旦我方支付系統通知商戶支付結果，那麼我們就要為此承擔責任。由此我們再推斷一個結論：
即便某支付訂單銀行方面出錯導致資金未能到賬，一旦我們支付系統通知商戶該筆交易成功，那麼根據協議該結算的資金還是要結算給這個商戶。自然，我們回去追究銀行的問題，把賬款追回。
----------------------------------------------------------沒經過排版的小知識點---------------------------------------------------
一、對支付系統而言，最基本的對賬功能是供商戶在其後臺查詢下載某一時間段內的支付資料檔案，以供商戶自己進行對賬。
這個功能應該是個支付公司就有，如果沒有就別混了。
二、對大多數支付系統而言，目前已經可以做到對賬檔案的主動投送功能。
這個功能方便了商戶系統和支付系統的對接，商戶的結算人員無須登入支付平臺後臺下載檔案進行對賬，省去了人工操作的麻煩和風險。
對大型支付系統而言，商戶如果跨時間區域很大，反覆查詢該區域內的資料並下載，會對伺服器造成比較大的壓力。各位看官別笑，覺得查個數據怎麼就有壓力了。實際上為了這個查詢，我最早就職的一家支付公司重新優化了所有SQL語句，並且因為查詢壓力過大伺服器癱瘓過好幾次。
現在比較主流的做法是把商戶短期內查詢過、或者經常要查詢的資料做快取。實在不行就乾脆實時備份，兩分鐘同步一次資料到專用資料庫供商戶查詢，以避免硬體資源佔用。甚至……大多數支付公司都會對查詢範圍跨度和歷史事件進行限制，比如最多隻能查一個月跨度內，不超過24個月前的資料……以避免服務嗝屁。
對賬這塊大致就這樣了，再往細的說就說不完了，大家有什麼想問的可以單M我或者回復答案。
稍後給大家講一下風控。
-----------------------------------------------風控的分割線-------------------------------------------
風險控制，在各行各業都尤其重要。
金融即風險，控制好風險，才有利潤。
雖然第三方支付嚴格意義上說並非屬於金融行業，但由於涉及資金的清分和結算，業務主體又是資金的收付，所以風險控制一樣非常重要。
對支付公司來說，風控主要分為合規政策風控以及交易風控兩種。
前者主要針對特定業務開展，特定產品形態進行法規層面的風險規避，通常由公司法務和風控部門一起合作進行。例如，一家公司要開展第三方支付業務，現在要獲得由人民銀行頒發的“支付業務許可證”。遵守中國對於金融管制的所有條規，幫助人行監控洗錢行為……這些法規合規風險，雖然條條框框，甚至顯得文縐縐，但如果沒人解讀沒人公關，業務都會無法開展。
當然，這塊也不是本題所關注的重點，提問者關注的，應當是業務進行過程中的交易風控環節。
現在隨著各支付公司風險控制意識的加強，風控系統漸漸被重視起來。除了上述提到的合規風控相關功能，風控系統最講技術含量，最講業務水平，最考究資料分析的業務就是交易風控環節。
對一筆支付交易而言，在它發生之前、發生過程中及發生過程後，都會被風控系統嚴密監控，以確保支付及客戶資產安全。而所有的所有祕密，都歸結到一個詞頭上：規則。風控系統是一系列規則的集合，任何再智慧的風控方案，都繞不開規則二字。
我們先看看，哪些情況是交易風控需要監控處理的：
1.釣魚網站
什麼是釣魚呢？
用我的說法，就是利用技術手段矇蔽消費者，當消費者想付款給A的時候，替換掉A的支付頁面，將錢付給B，以達成非法佔用資金的目的。
還有更低階的，直接就是發小廣告，裡面帶一個類似http://tiaobao.com的網址，開啟後和淘寶頁面一摸一樣，上當客戶直接付款給假冒網站主。
第一種情況風控系統是可以通過規則進行簡單判定的，雖然有誤殺，但不會多。
通常使用的規則是判斷提交訂單的IP地址和銀行實際支付完成的IP地址是否一致，如果不一致，則判斷為釣魚網站風險交易，進入待確認訂單。
但第二種情況，親爹親孃了，支付公司真的沒辦法。當然遇到客戶投訴後可能會事後補救，但交易是無法阻止了。
2.盜卡組織利用盜卡進行交易
大家都知道，信用卡資訊是不能隨便公佈給別人的，國內大多信用卡雖然都設定了密碼，但銀行仍然會開放無磁無密支付介面給到商戶進行快速支付之用。
所謂無磁無密，就是不需要磁軌資訊，不需要密碼就可以進行支付的通道。只需要獲取到客戶的CVV，有效期，卡號三個核心資訊，而這三個資訊是在卡上直接有的，所以大家不要隨便把卡交給別人哦~
碰到類似的這種交易，風控系統就不會像釣魚網站這樣簡單判斷了。
過去我們所有的歷史交易，都會存庫，不僅會存支付相關資訊，更會利用網頁上的控制元件（對，噁心的activex或者目前用的比較多的flash控制元件）抓取支付者的硬體資訊，儲存在資料庫中。
當一筆交易資訊帶著能夠蒐集到的硬體資訊一同提交給風控系統時，風控系統會進行多種規則判定。
例如：當天該卡是否交易超過3次
當天該IP是否交易超過3次
該主機CPU的序列號是否在黑名單之列
等等等等，一批規則跑完後，風控系統會給該交易進行加權評分，標示其風險係數，然後根據評分給出處理結果。
通過硬體資訊採集以及歷史交易記錄回溯，我們可以建立很多交易風控規則來進行監控。所以規則樣式的好壞，規則係數的調整，就是非常重要的用以區別風控系統檔次高低的標準。
例如，我聽說著名的風控廠商RED，有一個“神經網路”機制，灰常牛逼。
其中有一個規則我到現在還記憶猶新：
某人早上八點在加利福尼亞進行了信用卡支付，到了下午一點，他在東亞某小國家發起了信用卡支付申請。系統判斷兩者距離過長，不是短短5小時內能夠到達的，故判定交易無效，支付請求拒絕。
規則非常重要，當然，資料也一樣重要。我們不僅需要從自己的歷史記錄中整合資料，同時還要聯合卡組織、銀行、風控機構，購買他們的資料和風控服務用來增加自己的風控實力。
SO，風控是一個不斷積累資料、分析資料、運營資料、積累資料的迴圈過程。
好的風控規則和引數，需要經過無數次的規則修改和調整，是一個漫長的過程。
不知道大家做網際網路，有沒有利用GA做過AB測試，同樣的，風控系統也需要反覆地做類似AB測試的實驗，以保證理論和實際的匹配。
最後給大家說一個小小的概念：
所謂風控，是指風險控制，不是風險杜絕。
風控的目標一定不是把所有風險全部杜絕。
合理的風控，目標一定是：利潤最大化，而不是風險最小化
過於嚴格的風控規則，反而會傷害公司利益（看看銷售和風控經常打架就知道了）
不光是交易的風控，我們日常制定規則，法規，公司流程，也一定要秉著這個出發點進行規劃。
連結：http://www.zhihu.com/question/20091391/answer/15591658
來源：知乎
著作權歸作者所有，轉載請聯絡作者獲得授權。
先扯淡一下對賬，這坑有點大，容我慢慢填。剛剛打了半小時的草稿由於沒儲存，宕機後被系統吃掉了……知乎貌似原來有自動儲存功能的……去哪裡了……
業務上，為何對賬，對賬的操作步驟等@詹世波已經說得很多了，我談談一些沒涉及的。
關於對賬更深層次的理解，請各位關注我的專欄，我會不定時在專欄裡分享我關於支付業務的理解。
為了可以更好地解釋支付結算系統對賬過程，我們先把業務從頭到尾串起來描述一下場景，幫助大家理解：
一個可能得不能再可能的場景，請大家深刻理解裡面每個角色做了什麼，獲取了哪些資訊：
某日陽光燦爛，支付寶使用者小明在淘寶上看中了暖腳器一隻，價格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分……
對系統來說，每天都要處理大量併發的對賬資料，如果在交易高峰時段進行，會引起客戶互動的延遲和交易的失敗，這是萬萬行不得的
所以通常支付公司不會用那麼傻的方式處理資料，而是在一個會計日結束後，通常也是臨晨時段，將前一日交易增量備份到專用對賬伺服器中，在物理隔絕環境下進行統一的對賬行為，杜絕硬體資源的搶佔。
以上是銀行資金渠道入款的對賬，出款基本原理一致，不過出款渠道在實際業務過程中還有一些特別之處，由於大家不是要建設系統，我就不贅述了。
談完了資金渠道的對賬，我們再來看看對客戶帳。
前面提到了，由於資金落在銀行，所以對支付公司來說，對銀行帳非常重要。那麼同理，由於資金落在支付公司，所以對商戶來說，對支付公司賬也一樣重要。能否提供高品質甚至定製化的服務，是目前支付公司走差異化路線的一個主要競爭點。
就流程而言@詹世波已經說的差不多了，我就不贅述了……
----------------------------------------------------------沒經過排版的小知識點---------------------------------------------------
之前說過，銀行與支付公司之間的通訊都是可以作為糾紛憑證的。原理是對支付報文的關鍵資訊進行金鑰加簽+md5處理，以確保往來報文“不可篡改，不可抵賴”。
同理，支付公司和商戶之間也會有類似機制保證報文的可追溯性，由此我們可以知道，一旦我方支付系統通知商戶支付結果，那麼我們就要為此承擔責任。由此我們再推斷一個結論：
即便某支付訂單銀行方面出錯導致資金未能到賬，一旦我們支付系統通知商戶該筆交易成功，那麼根據協議該結算的資金還是要結算給這個商戶。自然，我們回去追究銀行的問題，把賬款追回。
----------------------------------------------------------沒經過排版的小知識點---------------------------------------------------
一、對支付系統而言，最基本的對賬功能是供商戶在其後臺查詢下載某一時間段內的支付資料檔案，以供商戶自己進行對賬。
這個功能應該是個支付公司就有，如果沒有就別混了。
二、對大多數支付系統而言，目前已經可以做到對賬檔案的主動投送功能。
這個功能方便了商戶系統和支付系統的對接，商戶的結算人員無須登入支付平臺後臺下載檔案進行對賬，省去了人工操作的麻煩和風險。
對大型支付系統而言，商戶如果跨時間區域很大，反覆查詢該區域內的資料並下載，會對伺服器造成比較大的壓力。各位看官別笑，覺得查個數據怎麼就有壓力了。實際上為了這個查詢，我最早就職的一家支付公司重新優化了所有SQL語句，並且因為查詢壓力過大伺服器癱瘓過好幾次。
現在比較主流的做法是把商戶短期內查詢過、或者經常要查詢的資料做快取。實在不行就乾脆實時備份，兩分鐘同步一次資料到專用資料庫供商戶查詢，以避免硬體資源佔用。甚至……大多數支付公司都會對查詢範圍跨度和歷史事件進行限制，比如最多隻能查一個月跨度內，不超過24個月前的資料……以避免服務嗝屁。
對賬這塊大致就這樣了，再往細的說就說不完了，大家有什麼想問的可以單M我或者回復答案。
稍後給大家講一下風控。
-----------------------------------------------風控的分割線-------------------------------------------
風險控制，在各行各業都尤其重要。
金融即風險，控制好風險，才有利潤。
雖然第三方支付嚴格意義上說並非屬於金融行業，但由於涉及資金的清分和結算，業務主體又是資金的收付，所以風險控制一樣非常重要。
對支付公司來說，風控主要分為合規政策風控以及交易風控兩種。
前者主要針對特定業務開展，特定產品形態進行法規層面的風險規避，通常由公司法務和風控部門一起合作進行。例如，一家公司要開展第三方支付業務，現在要獲得由人民銀行頒發的“支付業務許可證”。遵守中國對於金融管制的所有條規，幫助人行監控洗錢行為……這些法規合規風險，雖然條條框框，甚至顯得文縐縐，但如果沒人解讀沒人公關，業務都會無法開展。
當然，這塊也不是本題所關注的重點，提問者關注的，應當是業務進行過程中的交易風控環節。
現在隨著各支付公司風險控制意識的加強，風控系統漸漸被重視起來。除了上述提到的合規風控相關功能，風控系統最講技術含量，最講業務水平，最考究資料分析的業務就是交易風控環節。
對一筆支付交易而言，在它發生之前、發生過程中及發生過程後，都會被風控系統嚴密監控，以確保支付及客戶資產安全。而所有的所有祕密，都歸結到一個詞頭上：規則。風控系統是一系列規則的集合，任何再智慧的風控方案，都繞不開規則二字。
我們先看看，哪些情況是交易風控需要監控處理的：
1.釣魚網站
什麼是釣魚呢？
用我的說法，就是利用技術手段矇蔽消費者，當消費者想付款給A的時候，替換掉A的支付頁面，將錢付給B，以達成非法佔用資金的目的。
還有更低階的，直接就是發小廣告，裡面帶一個類似http://tiaobao.com的網址，開啟後和淘寶頁面一摸一樣，上當客戶直接付款給假冒網站主。
第一種情況風控系統是可以通過規則進行簡單判定的，雖然有誤殺，但不會多。
通常使用的規則是判斷提交訂單的IP地址和銀行實際支付完成的IP地址是否一致，如果不一致，則判斷為釣魚網站風險交易，進入待確認訂單。
但第二種情況，親爹親孃了，支付公司真的沒辦法。當然遇到客戶投訴後可能會事後補救，但交易是無法阻止了。
2.盜卡組織利用盜卡進行交易
大家都知道，信用卡資訊是不能隨便公佈給別人的，國內大多信用卡雖然都設定了密碼，但銀行仍然會開放無磁無密支付介面給到商戶進行快速支付之用。
所謂無磁無密，就是不需要磁軌資訊，不需要密碼就可以進行支付的通道。只需要獲取到客戶的CVV，有效期，卡號三個核心資訊，而這三個資訊是在卡上直接有的，所以大家不要隨便把卡交給別人哦~
碰到類似的這種交易，風控系統就不會像釣魚網站這樣簡單判斷了。
過去我們所有的歷史交易，都會存庫，不僅會存支付相關資訊，更會利用網頁上的控制元件（對，噁心的activex或者目前用的比較多的flash控制元件）抓取支付者的硬體資訊，儲存在資料庫中。
當一筆交易資訊帶著能夠蒐集到的硬體資訊一同提交給風控系統時，風控系統會進行多種規則判定。
例如：當天該卡是否交易超過3次
當天該IP是否交易超過3次
該主機CPU的序列號是否在黑名單之列
等等等等，一批規則跑完後，風控系統會給該交易進行加權評分，標示其風險係數，然後根據評分給出處理結果。
通過硬體資訊採集以及歷史交易記錄回溯，我們可以建立很多交易風控規則來進行監控。所以規則樣式的好壞，規則係數的調整，就是非常重要的用以區別風控系統檔次高低的標準。
例如，我聽說著名的風控廠商RED，有一個“神經網路”機制，灰常牛逼。
其中有一個規則我到現在還記憶猶新：
某人早上八點在加利福尼亞進行了信用卡支付，到了下午一點，他在東亞某小國家發起了信用卡支付申請。系統判斷兩者距離過長，不是短短5小時內能夠到達的，故判定交易無效，支付請求拒絕。
規則非常重要，當然，資料也一樣重要。我們不僅需要從自己的歷史記錄中整合資料，同時還要聯合卡組織、銀行、風控機構，購買他們的資料和風控服務用來增加自己的風控實力。
SO，風控是一個不斷積累資料、分析資料、運營資料、積累資料的迴圈過程。
好的風控規則和引數，需要經過無數次的規則修改和調整，是一個漫長的過程。
不知道大家做網際網路，有沒有利用GA做過AB測試，同樣的，風控系統也需要反覆地做類似AB測試的實驗，以保證理論和實際的匹配。
最後給大家說一個小小的概念：
所謂風控，是指風險控制，不是風險杜絕。
風控的目標一定不是把所有風險全部杜絕。
合理的風控，目標一定是：利潤最大化，而不是風險最小化
過於嚴格的風控規則，反而會傷害公司利益（看看銷售和風控經常打架就知道了）
不光是交易的風控，我們日常制定規則，法規，公司流程，也一定要秉著這個出發點進行規劃。