本文檔適用人員：交易領域的產品研發人員
銀聯
現如今手機 App 接入支付寶和微信支付即可，早年間 PC 端還得通過與銀聯商務對接，接入銀聯在線支付。但這是什麼東西？unionpay，chinapay，銀聯在線支付，銀聯在線，這又是什麼鬼？
據說銀聯自己人都不一定能搞清楚這些東西的歷史淵源。
首先，這是中國銀聯，現在是銀聯總公司辦公室打理。它是這麼介紹自己的：
中國銀聯是中國銀行卡聯合組織，通過銀聯跨行交易清算系統，實現商業銀行系統間的互聯互通和資源共享，保證銀行卡跨行、跨地區和跨境的使用。中國銀聯大力推進各類基於銀行卡的綜合支付服務。
我們應該拿銀聯與 Visa、Mastercard 這樣的卡組織相提並論。
其次，銀聯在線支付其實是個支付網關（注：由於支付寶和微信支付的大行其道，支付網關這個詞已經慢慢地難以理解了）。這是銀聯在線支付的網站：，現在的域名統一到 了，變成了銀聯持卡人服務網站。
銀聯在線支付網站也是一波三折，最開始是銀聯的互聯網部搞的，只有在線支付的介紹內容，比較簡潔。後來因爲銀聯主站的調整，加上老的持卡人服務網站 的調整，整個網站雜亂了起來。再後來互聯網部解散了，移交給產品部，之後又移交給其他事業部。
最後，銀聯在線的網站是，銀聯的子公司 ChinaPay 搞的。ChinaPay 歷史悠久，開始算是一家搞電子商務的創業公司，後來因經營不善被銀聯收購，用以發展電子商務及在線支付服務。這個網站原來是 ChinaPay 和銀聯的互聯網部一起搞的，後來銀聯的人覺得這麼做不行，還是要單獨做，於是就做出來 online.unionpay.com 那套東西了。
長江後浪推前浪，前浪死在沙灘上，現在在銀聯裏大家談支付網關都是說銀聯在線支付。
銀聯，是2002年國內80多家金融機構共同出資組建的股份制金融機構，其本身定位是銀行卡組織。
他對國內商業銀行的銀行卡制定了統一的標準，凡是商業銀行按照銀聯標準髮卡，這些卡就能夠進入銀聯的清分網絡。
原本兩家銀行數據假使是互相獨立的，銀聯制定規範前，工行的 ATM 機沒法受理華夏銀行卡的提現。在銀聯介入後，由於卡信息規範得到了統一，工行 ATM 機能夠讀懂華夏銀行卡內的磁條信息。更重要的是，工行可以通過銀聯的網絡查詢到華夏借記卡中的餘額，並受理用戶的提現需求。用戶在提現後，根據銀聯的清分數據，華夏銀行會在規定賬期內將資金結算給工行。
銀聯在這個過程中，不參與交易和收單，不負責出款，僅僅負責信息傳遞併產生清分數據，賺的是“信息費”。這和其他著名卡組織的功能基本相同，制定標準、打通髮卡行、負責清分信息。
中國銀聯控股銀聯商務。
因爲銀聯是後臺部門，當然這幾年也開始面向前端了，但總體來說，主要精力放在後臺建設上，因此很多業務落地是要委託銀聯商務來做的，特別是省級銀聯分公司更是要依託於當地的銀聯商務來完成其業務指標，所以說關係是很近的。
同時也是上下級的關係，銀聯商務 POS 直連業務必須要接入當地銀聯（總部也有，但是佔比很小，而且總部也基本上不承接實際業務，都是要落地到各地分子公司），於是銀聯對銀商上報的商戶就有審覈義務，還有一些指標要求或者規範化要求等。
一句話總結：支付寶的快捷支付，通過機制設計代替了銀聯跨行結算的作用，繞過了銀聯通道。
支付寶直接對接銀行，所以不涉及跨行，既然不跨行，那跟銀聯就沒有關係。
快捷支付或第三方支付的流程是這樣：
張三買了一包100元的茶葉，用他的工行卡綁定快捷支付，付款100元至支付寶的工行對公賬戶；
支付寶從支付寶的建行對公賬戶中轉給茶葉商的建行賬戶中100元；
爲了完成上述的過程，第三方支付公司需要在各家商業銀行開立對公結算賬戶，並打通各行銀行卡快捷支付的接口。用戶通過網絡完成快捷支付的綁定後，即可完成個人銀行卡向第三方支付對應本行對公結算賬戶的付款。交易發生時，第三方支付公司再從商戶賬戶所在銀行對應的對公結算賬戶把對應資金劃給商戶即可。
直接通過卡號或賬戶來區分對公、對私，沒什麼好辦法。
銀行卡有銀聯標準規範，但對公賬戶每家銀行規則都不同。由於對公賬戶也可以辦理銀行卡（不能在 ATM 上提現），因此單純依靠 卡bin 無法區分出銀行卡對應的銀行賬戶是對公賬戶還是對私賬戶。
一般採用如下一些方法：
- 對公、對私業務入口不同，分流到不同接口，
- 讓用戶在業務處理過程中提供銀行賬戶對應的屬性信息（例如代收付批量文件中），
- 維護各家銀行的對公賬戶規則。這個比較費勁，關鍵是維護成本較高，
- 一般對公賬戶的賬戶名稱至少在6位以上，對私賬戶的名稱一般最多3、4位，因此可以先根據賬戶名稱長度做一下判斷，再查找是否包含股份公司、有限公司、協會之類的關鍵詞。（注：僅靠長度判斷的話遇上維吾爾族人賬戶名稱也是醉了）
快捷支付
順着上面的話題，我們說說快捷支付吧。
快捷支付本質是代扣服務（對私）的產品包裝。
什麼是代扣？
代扣一般指用戶通過線上或線下櫃檯方式簽署“用戶-商戶-銀行”的三方協議，授權商戶可以從其銀行賬戶中扣錢。典型應用場景是電視費、保險費定期的扣除。
傳統的代扣服務的授權過程較爲麻煩，而且行業應用場景限制較多（例如只對實名行業開放）。快捷支付針對小額支付的需求場景，簡化了授權過程（例如只需要完成持卡人銀行卡、身份證、手機號的實名認證即可），同時通過下行短信驗證碼的形式來完成消費確認，很好平衡了安全性、便捷性。
首先，我們要知道，一個網上支付的過程，對第三方支付機構（如支付寶）和銀行後臺系統整個交互流程來說，可分爲主動扣款和被動付款兩種調用模式。兩種模式有什麼分別呢？
上圖是快捷支付的簡化版流程。順序來看，小明買了9.9元包郵的鼠標墊之後，第一步跳轉到支付寶頁面上選擇了快捷支付，支付寶將小明綁定的銀行卡、姓名、金額通過調用主動扣款指令傳給銀行（注意，沒有密碼），銀行覈對卡號姓名、指令來源、餘額等信息無誤之後，把扣款成功的信息發給支付寶，支付寶再把扣款成功的信息告訴小明，小明可以等待賣家發貨了。這個流程裏，支付寶是主動的一方，是支付寶主動扣了小明的款項。
上圖是通過銀行網銀支付的簡化版流程。在快捷支付推出之前，這個是支付寶唯一的在線支付方式。順序來看，小明通過支付寶頁面選擇了網銀支付，支付寶通過頁面跳轉，調用訂單支付指定傳 給銀行（注意，此時沒有個人客戶的任何信息，只有一個支付訂單號），小明需要事先插好U盾，此時再通過展現的網銀頁面來進行支付。銀行將扣款成功指令傳給小明和支付寶，支付寶再把付款成功信息告訴小明。這個流程裏，支付寶是被動的一方，是小明主動支付給了支付寶。注意到上面兩個流程的諸多不同了吧？正是這種種不同促使支付寶異常堅定地推行快捷支付，也正是這種種不同促使銀行對支付寶又愛又恨，時遠時近。一，快捷支付有助於大幅度提高用戶支付的成功率越高的成功率，就意味着支付寶越多的資金沉澱，在早期，這個資金沉澱就是支付寶和銀行合作的基礎所在。在通過銀行網銀支付流程中，影響支付成功率有三個主要因素：
一是有個致命的前提，客戶需要先去銀行開通網銀。有銀行卡的用戶（可開通快捷支付）和開通網銀的用戶，這絕對是幾個數量級之間的用戶數差別。支付寶無法忍受用戶羣體被這個限定死。
二是需要用戶來主動保證網銀支付環境的正常。而各位一定對我國各大銀行各式各樣的網銀問題抓過狂發過浪，而且這種種問題是支付寶完全乾涉不了也幫助不了。在早期，支付寶恨不得能人工指導每一個用戶怎麼使用各大銀行的網銀。
三是網銀支付的流程過長。有過開發經驗的前輩們一定有體會，越長的流程意味着各種可能的異常處理情形越複雜，出錯的概率也越高。這也是在早期爲什麼支付寶出現許多支付結果不確定的情況，這其實對支付寶和銀行兩方都非常頭疼。因爲雙方能夠定位問題的就是一個訂單號。二，快捷支付有助於更好的構築阿里渴望的大數據。我們有沒有發現在兩個流程中，支付寶和銀行交互的數據是有巨大差別的？在快捷支付的過程中，支付寶掌握了用戶的所有信息，包括身份、賬號、驗證方式、手機號，如果是信用卡，還有到期日、CVV碼等，用時髦的話來說，這就天然的和用戶購物流程形成了完整的閉環。這些信息都可以用於構建用戶信用基礎信息。而在網銀支付的流程中，支付寶只掌握了一個訂單號，只知道這個用戶下了一個訂單，然後訂單就被付款成功了。至於誰付的？賬號多少？姓甚名誰？手機驗證是否準確？等等一系列，都是黑盒子。如果換做是你，你會希望用戶用那種方式呢？
（出處5）
POS
你可能天天刷，但下面的這些知識你未必都知道。
POS簽單上有很多序列號，都是什麼意思呢？如果收單後處理投訴時讓你提供流水號，那指的是哪一個字段呢？
批次號(Batch NO.)：POS從簽到起至結算、簽退爲止的交易爲一批次，交易批次號標識一批交易。POS中心爲每個POS的每個批次分配一個批次號，在簽到響應報文中下傳給POS終端。
對應銀聯ISO8583報文的報文頭域7： 批次號(Batch Number)
序號(Refer NO.)：或稱參考號。POS中心爲交易分配的流水號，在響應報文中下傳給POS終端作爲對賬參考號，並用於事後查證。
對應銀聯ISO8583報文的域37：檢索參考號（Retrieval Reference Number）
授權號(Auth Code)：授權標識應答碼，簡稱“授權碼”。是髮卡行返回或銀聯CUPS代授權時返回的授權序號。
對應銀聯ISO8583報文的域38：授權標識應答碼 Authorization Identification Response
查詢號(Trace NO.)：或稱流水號。POS機爲每一筆交易產生的順序編號。POS每上送一次交易此號碼增加1。 POS流水號爲6位數字，值從1至999999循環使用。在自動衝正時，POS中心依據POS流水號作爲確定被衝正交易的要素之一。
交易發起方賦予交易的一組數字，與域7（交易傳輸時間 Transmission Date/Time）、域32（受理機構標識碼 Acquiring Institution Identification Code）和域33（發送機構標識碼 Forwarding Institution Identification Code）的組合值唯一標識一筆交易的編號。
憑證號(Voucher NO.)：查詢號（Trace NO. 也叫POS流水號）也作爲交易憑證號（在籤購單上打印爲Voucher NO.），在進行撤銷等交易時，輸入原交易憑證號作爲確定原交易的要素之一，並且必須上送原交易的憑證號。
- 對髮卡行來說——卡號+參考號+授權號，就能夠確定一筆交易；
- 對於收單方來說——憑證號+域7（對應籤購單上的日期/時間）+域32（對應籤購單上的收單機構）+33域（對應籤購單上的髮卡機構）能夠唯一確定一筆交易。
因此如果是向髮卡行投訴，則需要提供卡號、參考號、授權號，
如果是向收單方投訴，則需要提供憑證號、交易日期時間、收單機構、髮卡機構。
（出處6）
對於銀聯的直聯商戶，流程如下：
- 刷卡信息（包括磁道和密碼）由 POS 機具受理後通過收單機構送往銀聯的收單系統。
- 銀聯收單系統將報文通過銀聯核心交換平臺送到信用卡的髮卡銀行，根據交易指令，在髮卡銀行的對應的卡片賬戶進行扣款。
- 銀聯核心交換系統收到扣款成功的返回後，將交易結果原路返回到 POS 終端上。
- 當天晚上11點，清算信息開始批量處理。
- T+1日，各行在人行的頭寸賬戶根據銀聯的清算文件（指令）將資金進行劃撥，即交易資金從信用卡的髮卡銀行轉移到商戶的收單銀行。
- 收單銀行將資金轉入商戶的具體清算賬戶（也可以由銀聯直接轉入）。
就扮演的角色而言，有持卡人、商戶、收單機構（爲商戶提供服務的銀行或機構）、轉接清算機構（銀聯、VISA等卡組織）、髮卡機構（信用卡銀行）。
上一節提到了清算，看圖理解這個概念吧：
第三方支付公司
支付寶，財付通，這些都屬於第三方支付公司。
一，爲什麼第三方支付公司的資金需要有備付金管理辦法
最初，支付公司的資金是不受監管的。
比如小明在網上看中了一款產品，使用了支付寶進行付款，在使用支付寶付款的時候，選擇的是小明的招商銀行卡，付款成功後，小明的招行賬戶會扣除資金，同時支付寶會將支付成功的信息告訴賣家，賣家發貨。
在第二天，招商銀行會將小明被扣除的資金結算給支付寶，這個時候這筆錢是由銀行結算給支付寶在招商銀行開設的對公賬戶。
而小明由於還沒有確認收貨，或者可能一週之後纔會確認收貨，那麼在這段時間，這筆錢會一直停留在支付寶的對公賬戶中。
這筆錢，沒有任何人會去監管，而且因爲存在着時間差，所以支付寶可能會將這筆錢挪去他用。
也有可能存在着一些小的支付公司，甚至之前資金鍊斷裂，卷錢走人。
所以，政府認爲，這個錢我是肯定要去監管起來的。
於是在2013年6月7日，中國人民銀行公告〔2013〕第6號公佈《支付機構客戶備付金存管辦法》，核心就是要監管起支付公司裏面那些實際上是用戶的錢。這部分錢被稱爲客戶備付金，需要嚴格和支付公司自己的錢區分開來。
二，備付金管理辦法的核心是什麼
核心就是三種賬戶，分別爲存管賬戶、收付賬戶、匯繳賬戶。
存管賬戶就是大老婆，每家支付公司只能在一家銀行開立存管賬戶。你選擇了工商銀行，就不能選擇華夏銀行。存管賬戶裏的錢可以跨行劃款、同行劃款、用起來和普通的對公賬戶完全一模一樣，不受限制。但一般存管賬戶只能開一個，也有的支付公司，會選擇在同一個銀行不同地區的分行之間開賬戶。
收付賬戶就是姨太太，每家支付公司可以在每一家銀行都開立一個收付賬戶，但收付賬戶不能跨行劃款，除非收款賬戶是存管賬戶。收付賬戶只能同行劃款，A支付公司可以在工行開一個收付賬戶、在農行也開一個收付賬戶，但一旦在農行上海分行開一個賬戶，就不能在農行深圳分行再開收付賬戶了。
匯繳賬戶就是情人，隨便在哪家銀行隨便開幾個，但是這個賬戶日終清零，只能把這個賬戶裏的錢每天歸集到本行收付賬戶或是跨行歸集到存管賬戶，好可憐。
有的人問，那匯繳賬戶有啥用？比如某個支付公司和某家分行合作了一個網上收單業務，那麼這個匯繳賬戶就是這家銀行每天把收單的錢結給這個支付公司的賬戶。
三，備付金賬戶之間頭寸是如何調撥的
存管賬戶、收付賬戶、匯繳賬戶之間的錢是如何調撥的？
首先明確的一點，這個錢不會走銀聯的系統，這件事情和銀聯沒有一毛錢關係。
那麼匯繳賬戶到收付賬戶，就是通過每家銀行的行內轉賬進行調撥。
匯繳賬戶、收付賬戶到存管賬戶，就是通過人行的大小額系統、跨行清算系統（俗稱超級網銀）或是同城系統進行調撥。
當然我們說的系統，都是背後的系統，實際上前端的產品就是各家銀行的企業網銀、銀企直聯，甚至極端點，你去櫃檯把這個錢完成調撥都沒問題。
每家銀行現在陸續的都上了備付金管理系統，這個系統對接了每家支付公司，讓銀行能夠掌握支付公司在自己銀行開設的所有備付金賬戶的每日餘額和資金調撥明細，並且做到匯繳賬戶能每日清零，控制收付賬戶、匯繳賬戶的跨行轉賬權限，並且每日能生成報表報送給人行。
這些措施都上了的話，基本可以杜絕支付公司捲款跑人的問題了。
（出處7）
跟 B2B 技術團隊交流時，他們老說銀企直連，那這又是什麼呢？
直聯網關是相對間聯網關而言的，這倆貨都是第三方支付裏的概念。
間聯網關是第三方支付公司提供網銀支付網關的最標準模式。
消費者需要支付時，商家向第三方支付公司的網關接口提交標準報文請求將消費者引導到“收銀臺”，沒錯，就是支付寶那個熟悉的選擇支付銀行的頁面。用戶在收銀臺選擇銀行後，支付寶再將用戶引導到網銀界面……後面的流程大家都懂的。
直聯網關是在標準網關基礎上進行的衍生網關服務。
做過電商的同學都知道，消費者完成消費行爲前的任一步驟都可能產生用戶跳出，爲了儘可能減少用戶跳出，縮短支付流程就成爲很重要的優化點。基於此需求，第三方支付公司提供了直聯網關接口，消費者在需要支付時，電商網站直接告訴第三方支付公司消費者需要使用哪家銀行進行付款，支付公司受理信息後迅速引導消費者到網銀支付頁面，這個過程中支付公司界面就不再出現，用戶體驗會好一些。這類產品幾乎所有支付公司都有。
真正意義上的銀行接口，最常見的是信用卡無磁無密支付接口。這類接口的特點是用戶只需輸入信用卡面上卡號、有效期、CVV2，便能完成支付。不少支付公司會將這類接口直接提供給商戶使用，由商戶代爲收集用戶上述信息並提交到支付公司完成支付。由於此類支付接口風險性很大，故銀行要求只能在實名制行業使用。
此外比較常見的有銀企直連接口。銀企直連不是一個簡單交易接口，不少銀行包裝銀企直連是一堆業務接口的集合。
銀企直連通常用在即時出款到銀行賬戶（提現、代發代付業務）業務上比較多。支付公司也會提供這類出款接口給商戶，幫助其完成系統對接的付款需求。
分爲支付寶與銀行對賬，商戶與支付寶對賬。
爲了可以更好地解釋支付結算系統對賬過程，我們先把業務從頭到尾串起來描述一下場景，幫助大家理解：一個可能得不能再可能的場景，請大家深刻理解裏面每個角色做了什麼，獲取了哪些信息：某日陽光燦爛，支付寶用戶小明在淘寶上看中了暖腳器一隻，價格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分……對系統來說，每天都要處理大量併發的對賬數據，如果在交易高峯時段進行，會引起客戶交互的延遲和交易的失敗，這是萬萬行不得的。所以通常支付公司不會用那麼傻的方式處理數據，而是在一個會計日結束後，通常也是凌晨時段，將前一日交易增量備份到專用對賬服務器中，在物理隔絕環境下進行統一的對賬行爲，杜絕硬件資源的搶佔。以上是銀行資金渠道入款的對賬，出款基本原理一致，不過出款渠道在實際業務過程中還有一些特別之處，由於又不是讓大家親自要建設系統，就不再贅述了。談完了資金渠道的對賬，我們再來看看對客戶帳。前面提到了，由於資金落在銀行，所以對支付公司來說，對銀行帳非常重要。那麼同理，由於資金落在支付公司，所以對商戶來說，對支付公司賬也一樣重要。能否提供高品質甚至定製化的服務，是目前支付公司走差異化路線的一個主要競爭點。
Tips：之前說過，銀行與支付公司之間的通訊都是可以作爲糾紛憑證的。原理是對支付報文的關鍵信息進行密鑰加簽+ md5 處理，以確保往來報文“不可篡改，不可抵賴”。同理，支付公司和商戶之間也會有類似機制保證報文的可追溯性，由此我們可以知道，一旦我方支付系統通知商戶支付結果，那麼我們就要爲此承擔責任。由此我們再推斷一個結論：即便某支付訂單銀行方面出錯導致資金未能到賬，一旦我們支付系統通知商戶該筆交易成功，那麼根據協議該結算的資金還是要結算給這個商戶。自然，我們會去追究銀行的問題，把賬款追回。
1）對支付系統而言，最基本的對賬功能是供商戶在其後臺查詢下載某一時間段內的支付數據文件，以供商戶自己進行對賬。這個功能應該是個支付公司就有，如果沒有就別混了。
2）對大多數支付系統而言，目前已經可以做到對賬文件的主動投送功能。這個功能方便了商戶系統和支付系統的對接，商戶的結算人員無須登錄支付平臺後臺下載文件進行對賬，省去了人工操作的麻煩和風險。對大型支付系統而言，商戶如果跨時間區域很大，反覆查詢該區域內的數據並下載，會對服務器造成比較大的壓力。各位看官別笑，覺得查個數據怎麼就有壓力了。現在比較主流的做法是把商戶短期內查詢過、或者經常要查詢的數據做緩存，實在不行就乾脆實時備份，兩分鐘同步一次數據到專用數據庫供商戶查詢，以避免硬件資源佔用。甚至……大多數支付公司都會對查詢範圍跨度和歷史事件進行限制，比如最多隻能查一個月跨度內，不超過24個月前的數據……以避免服務掛掉。（出處10）
我們自家新開發一個 App 如何接入支付解決方案呢？
此問題涉及如下幾方面：
1 移動支付廠商的選型
1.1 支付渠道由於是 App，採用的支付方式主要大致有如下幾種方式：a App SDK支持銀行卡支付（借記卡、信用卡）、賬戶支付、快捷支付等。支付寶、微信支付、銀聯在線等主流的第三方支付都提供了對應的解決方案。b WAP/HTML5與 App SDK 類似，但微信支付目前不開放給第三方的手機網頁版。像信用卡無磁無密支付（ePOS/MOTOPay）、代扣等由於只對實名行業開放，且商家需要資質較好，一般行業應該不適用。
1.2 增值服務的考察對普通商戶而言，在選擇第三方支付廠商時候，除了考慮支付渠道、交易手續費外，還需要重點考慮第三方支付提供的其他服務，主要包括如下一些方面：a 結算週期、結算手續費，b 提現/退款接口，c 分賬/代付（委託結算）等結算服務：或者叫分潤。例如對代理商按照自定義規則對交易進行分賬並批量代付到指定的銀行賬號（對公、對私）。一般而言，支付寶、財付通（微信支付）、銀聯在線支付對分賬/代付支持較弱，而像快錢/匯付/易寶之類獨立第三方支付，在結算服務商策略相對靈活、產品解決方案也相對完善。綜上所述，建議結合自己業務模式，從支付渠道+增值服務兩方面對主流第三方支付廠商進行對比，選擇最適合自身的廠商。
2 與第三方支付平臺對接問題此問題主要涉及如下兩方面：
2.1 平臺虛擬賬戶資金流轉問題簡單說來，你自己平臺有一套虛擬賬戶體系，第三方平臺也有一套虛擬賬戶體系，實際資金存放在銀行的賬戶體系中（第三方支付在銀行設立的備付金賬戶中）。你自己平臺的賬戶體系和第三方支付的賬戶體系、第三方支付虛擬賬戶體系與銀行賬戶體系間都只涉及信息流轉（電子貨幣），實際的資金流轉只發生在銀行的賬戶體系內。你作爲商戶接入第三方支付時候，第三方支付會在其平臺爲你方設立單獨的商戶虛擬賬戶（會有多個賬戶，包括結算賬戶、現金賬戶、信用賬戶等賬戶類型），你方平臺的收單備付金（待結算資金）存放在結算賬戶中。商戶自身也可以通過在線支付等方式對現金賬戶進行充值，充值金額存放在現金賬戶中，這樣可以解決你所提到的提現資金預存問題。當然如果你方交易量大（每日待結算資金量大），也可以和第三方支付探討通過軋差方式。
2.2 提現對第三方支付而言，影響提現服務因素包括時效性、費率等。在時效性上一般分爲實時、準實時、T+n。大部分情況下，除支付寶、財付通基於提升自己用戶體驗的考慮支持實時、準實時提現外，一般第三方支付對接入商戶及接入商戶用戶的提現請求都採用 T+1 到賬方式：在 T+1 與商戶完成結算後，通過批量代付功能完成對應商家用戶的提現請求。
第三方支付牌照包括：網絡支付、預付卡的發行與受理、銀行卡收單，其中網絡支付又分爲：貨幣匯兌、互聯網支付、移動電話支付、固定電話支付、數字電視支付幾種。預付費卡的發行和受理是分開的，原則上不允許支付機構同時擁有預付費卡發行+銀行卡收單牌照，但可以爲預付費卡受理+銀行卡收單。支付機構發行預付卡的，應當提供預付卡的受理服務。具體請參看：非金融機構支付服務管理辦法（人民銀行令〔2010〕第2號）央行公佈非金融機構支付服務管理辦法實施細則
比如衆美聯的 B2B 雲採購就屬於大宗交易電商網站。
一般第三方支付提供的支付方式大致有幾種：
1）賬戶支付賬戶支付有幾種形態：a）電商網站自己的賬戶體系，用戶通過第三方支付對網站自有賬戶充值後再進行支付。b）直接使用第三方支付的賬戶體系（與電商賬戶不綁定），用戶充值是充值到第三方支付賬戶中並支付（注意與快捷支付的區別）。c）與第三方支付的賬戶體系同步，此種情況較少採用，除非合作關係較爲緊密。像 C2C、B2B 平臺常用的擔保支付之類也可以歸爲賬戶支付範疇。一般應用在適合比較重視賬戶體系建設的網站，支付金額沒有限制（取決於充值的金額）。
2）快捷支付用戶在第三方支付賬戶體系中：第一步認證授權：經過實名認證後，綁定銀行卡第二步消費：在第三方支付收銀臺以第三方支付賬戶登錄，下行短信後，輸入驗證碼及交易密碼，完成支付。也有在商戶側綁定授權及完成支付的（例如銀聯的綁定支付/快捷支付，但只針對有信用的品牌大商戶）。一般應用在電商網站及移動端，且需要第三方支付的賬戶體系認同度高，用戶願意綁定。支付金額有限制。
3）網關支付就是典型的在線支付。一般的在線支付對額度會有限制，但基本上能夠滿足大部分場景的需要。普通在線支付 B2C、B2B 網關是有交易限額限制。對需要大額支付的商家，大部分的第三方支付網關支付還提供 B2B 大額支付的接口，配合企業網銀/個人網銀，基本上能夠做到無限額支付。一般 B2B 大額支付只提供了 PC 端功能（主要受限於企業網銀）。
4）代收、代付與商戶簽署代收、代付協議後，直接從用戶銀行卡扣錢。一般支付額度較大，應用在信任關係比較緊密的上下游商家間。5）信用支付在 B2B 經常會針對信用好的商戶進行授信，根據其信用度授予一定額度，因此會有所謂的信用支付概念。針對以上幾種支付形態，還會有一些組合，例如賬戶餘額+網關支付，信用支付+賬戶餘額，一般叫組合支付。具體使用一種或多種支付方式，需要根據公司業務形態來確定。另外如果公司交易量大的話，從降低成本等角度考慮，一般會在交易平臺前端自建一個類支付的平臺，主要用於接入多家支付公司，各家支付公司支付通道路由、統一對賬等，另外還會適度接入一些直連銀行（注：通過銀企直連接口）。
轉載自《做在線交易你必須知道的關於支付的知識》