支付系統設計包含：帳戶，對帳，風控...！史上最全的！--轉

原文地址：http://mt.sohu.com/business/d20161222/122312609_481676.shtml

　　

　　帳戶體系是支付系統的基礎，它的設計直接影響整個系統的特性。這裏探討如何針對電子商務系統的支付帳戶體系設計。咱們從一些基本概念開始入手，瞭解怎麼建模。

　　

　　支付帳戶和登陸帳號

　　帳戶體系設計首先要區分兩個概念，支付帳戶和登陸帳號。這是兩個不一樣業務領域的概念：支付帳戶指用戶在支付系統中用於交易的資金全部者權益的憑證；登陸帳號 指用戶在系統中的登陸的憑證和我的信息。 一個用戶能夠有多個登陸帳戶，一個登陸帳戶能夠有多個支付帳戶，好比零錢帳戶，儲值卡帳戶等。通常來講，支付帳戶不會在多個登陸帳戶之間共用。若是沒有特殊說明，下文中的帳戶，都默認指支付帳戶。

　　帳戶的設計需求

　　在支付系統中，帳戶的設置，主要是從以下幾個方面來考慮：

　　交易的需求，好比檢查帳戶是否被鎖定、餘額是否足夠、是否有效等。

　　記帳的需求，按照公司會計需求記錄帳戶上的全部行爲，包括支出、充值、轉帳等。

　　對帳的需求，包括和支付渠道、商戶、我的的對帳需求，覈對交易和帳戶餘額是否正確。

　　風控的需求，如反洗錢、反欺詐等，都須要依賴於帳戶體系來提供核心數據。本文暫不分析這個內容，將在《支付風控》、《支付反洗錢》這兩篇文章中詳細分析

　　信用的需求，對用戶、資產、商戶等主體進行信用評估時，也須要依賴帳戶體系來提供的核心數據。本文也暫不分析這內容，將在《信用與支付》一文中分析。

　　這五個需求，按照其設計的優先級，也是從支付、記帳、對帳、風控來進行。支付系統根據其發展所處的階段，逐步將新增需求歸入設計中。

　　交易與帳戶

　　帳戶設置，通常是從交易開始的。交易的實現必須有帳戶的支持，帳戶是交易的基本構成元素。 從支付系統的角度，交易中涉及到的資金流是資金從一個帳戶流向另外一個帳戶。 發起交易的一方，被稱之爲交易主體，他能夠是我的，也能夠是一個機構。

　　資金從該主體所擁有的帳戶中流出。而接收交易的一方，被稱爲交易對手，他也能夠是我的，或者機構。 和第三方支付或者金融機構的交易不一樣，電商系統中，交易還會涉及到渠道。

　　因爲電商系統自己並沒有清結算的資質，全部資金從交易主體到交易對手的帳戶的流動，在大部分狀況下，並無通過電商系統，而是由電商系統調用支付渠道提供的接口，由它來完成真正的支付過程。固然，渠道也不是活雷鋒，在這過程當中，渠道要收取費用。

　　因此，在電商系統中，一次交易會涉及到三個帳戶：交易主體帳戶、交易對手帳戶以及支付渠道帳戶。 如何在這三個帳戶中完成一次交易，咱們將在後續的《交易和記帳》一文中詳細分析。

　　記帳與帳戶

　　公司的會計須要對每一筆交易都要作詳細的記錄，即記帳。公司天天都產生大量的交易行爲，爲了便於管理和統計，一個簡單的方法是對交易進行分類，好比食品、帶寬、辦公用品等等。 這個分類，按照公司的規模和業務複雜度，能夠有一級，二級，三級或者更多級的結構，這被稱之爲會計科目。記帳時，除了交易明細，還須要在每一個級別上對交易額進行彙總。

　　通常來講，一級科目上彙總稱爲總賬科目，而詳細記錄稱爲明細科目。在電商系統中，因爲涉及到的參與方較多，記帳也相對複雜，但基本方法也是相似的。 電商的參與者能夠分爲商戶、買家和渠道，對這三類參與者，都須要分別創建總賬帳戶和明細帳戶。

　　內部帳戶和外部帳戶

　　當用戶使用銀行卡來支付時，電商支付系統須要和銀行對接，從用戶銀行卡所表明的帳戶上扣除資金。對接了銀行，第三方支付等機構的電商支付系統，它須要鏈接到用戶在這些機構的帳戶來執行扣款或者充值操做，這些帳戶或稱爲外部帳戶。對外部帳戶，支付系統只能記錄帳戶在本系統的明細以及累計消費額，沒法得知帳戶真正餘額。很多電商在玩零錢的概念，也就是讓用戶充值到零錢，使用的時候就直接從零錢中扣除。這就須要零錢帳號。這是電商系統中本身設立的帳號，因此也叫內部帳號，能夠知道帳號的所有消費明細和餘額。固然，除了零錢帳號，也能夠有儲值卡帳號，信用帳號等。

　　那問題來了，何時須要創建帳戶，好比優惠券，須要帳戶嗎？一次消費的儲值卡和能夠充值的儲值卡，須要創建帳戶嗎？這裏先埋個雷，後續介紹支付和記帳時，給出答案。

　　收款帳戶和收單帳戶

　　當電商要對接銀行時，每每都會被要求開設一個收款帳戶。用戶經過這個銀行來支付時，錢就被轉到這個帳戶上。對第三方支付也是同樣。收款帳戶是開設在銀行或者第三方支付這邊的， 即渠道側。 通常來講，渠道天天均可以提供這個帳戶的交易流水供電商對帳用。 這樣在電商這邊，渠道就成爲一個收單機構。因此在電商這邊，創建這個收款帳戶對應的對帳用的收單帳號，用來記錄經過這個渠道進行的各項交易流水。

　　帳戶建模

　　說了這麼多，目的是爲了對帳戶建模。帳戶模型是和公司業務密切相關的，公司不一樣規模，發展的不一樣階段須要不一樣的模型。 帳戶建模自己包括三大核心模型：實體模型、帳戶模型和交易模型。 從交易模型中能夠衍生出針對各個角色的帳戶流水，即明細模型，用於支持對帳。

　　實體模型

　　實體模型和用戶、商戶模型有重疊的地方，這裏專門針對支付而設置的各個實體屬性。通常來講，支付相關的實體模型須要包括以下的屬性：

　　用戶ID，通常直接映射到登陸帳戶的ID；

　　是否容許執行支付；

　　支付密碼；

　　用於設置或者重置支付密碼的手機號；

　　用戶設置或者重置支付密碼的郵箱；

　　用戶的安全等級，根據業務須要來設置。

　　帳戶模型

　　根據業務須要，能夠設置多種帳戶，如支付帳戶、預付卡帳戶、代扣帳戶、零錢帳戶、結算帳戶等。從類別上來講，這裏的帳戶，通常指總帳帳戶。通常來講電商系統中涉及的帳戶類型有：

　　虛擬幣帳號：用戶和使用奇點奇豆的商戶都須要創建虛擬幣帳戶。

　　代扣帳號：用來支持訂閱類型的按期代扣；

　　零錢帳號：即電商的內部帳號，用戶、商戶、清算單位須要創建零錢帳戶

　　第三方支付帳號：用戶在第三方支付機構創建的帳戶。

　　銀行卡帳號：用戶的銀行卡信息，每一個卡對應一個帳戶。

　　結算帳號：用來支持和第三方支付公司、銀行進行結算用。第三方支付須要爲每一個商戶號創建結算帳號；銀行須要爲借記卡、貸記卡分別創建結算帳號（有必要嗎？銀行卡直連時使用）。

　　代扣代繳帳戶：用來支持代扣稅款業務。

　　對這些帳戶，須要設置以下屬性：基本屬性，包括：

　　帳戶號，或稱爲帳戶ID，通常是系統自動生成。特別注意的是，要事先約定好帳戶ID的規則。好比頭三位用來表示帳戶類型，後幾位用來表示帳戶編號等。務必保證根據帳號號可以快速肯定帳戶類型，而且保證帳戶號是不重複的。

　　帳戶名稱，通常是由用戶本身設置的，顯示用。

　　帳戶使用的貨幣類型，注意雖然一張銀行卡能夠支持多個幣種，實際在內部，仍是針對每一個幣種創建獨立的子帳戶。涉及到多幣種的帳戶，也能夠採用相似的建模方案。

　　會計科目代碼，通常是一級會計科目的代碼。

　　帳戶控制相關：

　　是否容許充值；

　　是否容許提現；

　　是否容許透支；

　　是否容許支付；

　　是否容許轉帳進入；

　　是否容許轉帳轉出；

　　是否有安全保障；

　　是否激活；

　　是否凍結。

　　資金相關：

　　當前帳戶餘額：等於可用餘額+凍結餘額；

　　當前帳戶可用餘額；

　　當前帳戶凍結的餘額。凍結餘額指在帳戶上暫不能使用的額度。在支付的時候，每每是先凍結，商品出庫後，再實際執行扣款。

　　銀行卡、第三方支付信息：

　　第三方實體的ID；

　　第三方帳號，如銀行卡號或者在第三方支付的open_id等；

　　第三方的app_id；

　　帳號的失效日期，該帳號何時失效。

　　注意，有些第三方信息是不能保存的，如用戶的帳號密碼、信用卡的CV號等。 爲了不帳戶信息被爬庫或者數據庫信息意外泄露，通常還須要對敏感字段，如密碼等，進行加密保存，甚至保存到另外的表中。更進一步，爲了不帳戶信息被意外修改，還能夠增長一個校驗字段，在寫入數據時設置該字段，在讀取數據時作校驗，一旦發現數據有問題，則關閉該帳號。

　　交易模型

　　交易記錄，交易流水，帳戶流水，交易臺帳，這三個容易混淆的概念，從數據上來講，卻並不複雜，它們的核心是交易流水，帳戶流水是從帳戶視角的交易流水。那對一筆交易，涉及到的方方面面內容不少，有哪些須要記錄的呢？考慮到交易記錄將被用於風控和信用分析，能收集到的信息是越全面越好。

　　流水號：每一筆交易的流水號都不同。須要根據業務狀況詳細設計流水號。這個號每每也是對交易表作分表分庫的依據。

　　交易記錄建立時間；

　　交易記錄最後修改時間；

　　會計科目代碼

　　關聯的訂單號，由商戶提供；

　　訂單名稱、描述、關聯的地址等信息；

　　費用信息，包括：結算貨幣類型、原始費用、實際費用等；

　　交易主體信息，記錄主體ID、類型、名字、帳號、帳號類型、使用的IP地址、手機號、平臺、通知郵箱、當前位置等。這些信息雖然能夠從主體表中獲取，但考慮主體表信息隨時會被修改，因此這裏須要記錄詳細的各原始信息。

　　交易對手信息，記錄對手主體的ID，類型，名字，帳號，帳號類型，手機號，平臺，通知郵箱等。

　　交易渠道信息，記錄所使用的交易渠道的實體id，渠道帳戶，渠道執行支付的時間、渠道側返回的訂單號等。若是有錯誤發生，還須要記錄從渠道接收到的錯誤信息和錯誤碼。

　　能夠說，對帳是支付系統最頭疼的事情。每一筆交易，都要作到各參與者的記錄可以吻合，沒有誤差。對帳系統的工做，是發現有差別的記錄，即軋賬；而後經過人工或者自動的方式，解決這些差別，即平賬。

　　

　　對電商系統來講，每一筆交易，在全部相關主體側都要能對得上：

　　交易主體，若是發起人是我的，必須可以從我的交易歷史記錄中找到這筆交易。但大部分人不會保留電子記錄，因此通常是提供能夠下載的帳單或交易記錄，讓用戶本身對去。

　　交易對手，通常是商戶。商戶側對帳處理同用戶側，也僅僅提供對帳單。

　　交易渠道側，這是對帳的重點，一是覈實交易流水，二是覈實交易佣金，畢竟是租用人家通道作結算的。

　　那有哪些記錄須要對帳？目前主要是兩個：一個是交易記錄；一個是退款記錄。

　　對帳處理流程

　　通常來講，對帳流程涉及到以下步驟：渠道對帳單下載、本地交易記錄準備、軋帳、平帳。

　　渠道對帳單下載

　　銀行，第三方支付，銀聯等，基本都會提供對帳單下載的功能。不過也有少數工做作不到位或者太到位的銀行，只提供帳單查詢後臺，不提供對帳單下載功能。

　　對開發人員來講，這裏有幾個坑：

　　對帳單格式不一。文本，XML，csv的都有。爲了後續可以統一處理，在帳單下載完成後，須要進行標準化處理。

　　下載方式不一，HTTP，HTTPS，FTP的，都有。下載程序須要按照渠道的協議來處理。

　　下載時間不一，通常是凌晨1點後，到中午12才能用的也有。若是在預約的時間取不到數據，須要注意重試讀取。

　　穩定性差。FTP服務器出問題那是常有的事。渠道側解決方案每每就是重啓。因此重試機制是必要的。

　　看一下第三方支付的對帳單狀況：

　　

　　銀行直連的對帳狀況：

　　

　　技術選型上，HTTP(S)用apache httpclient便可實現連接池和斷點續傳， FTP也可使用Apache Commons Net API。 但無論是哪個，都須要設置重試次數和連接超時間。重試次數和間隔的設置須要當心，重試太頻繁，容易把服務器打死.；時間間隔太大，又會阻塞後續處理步驟。5～10分鐘是一個合適的重試間隔區間。

　　連接超時指在服務器出現問題時，鏈接在指定時間內獲取不到數據即自動斷開。這個很容易被忽略。咱們有一次系統出問題，是渠道側的FTP假死後重啓，致使咱們的客戶端掛住，一直在等待從新連接。

　　渠道對帳單標準化

　　找個例子你們看看，好比微信的對帳單，他是csv格式的，包括以下信息：

　　交易時間：這是在微信側的支付完成的時間。這個時間會成爲一個陷阱。

　　公衆帳號ID，商戶號,子商戶號,設備號：這些信息須要作驗證，確保是本身的單子，不要讓微信把老王家的單子也給發過來了；

　　微信訂單號,商戶訂單號： 這兩個是對單的核心。前者是微信側產生的訂單號，在微信支付接口返回值中有。可是萬一收不到這個返回值，那在本地記錄中可能就空了。後者是咱們發送給微信的訂單號，通常用這個來作對單依據。兩邊的數據中都會有這個值。

　　用戶標識,交易類型,交易狀態,付款銀行,貨幣種類,總金額,企業紅包金額：這幾個就是對單的核心字段，必須確保雙方是一致的。

　　商品名稱,商戶數據包,手續費,費率：這些是可選驗證。

　　

　　而某寶的對帳單，是文本格式的，用空格隔開。他們家的就簡單不少，只有商戶訂單號，交易流水號，交易時間，支付時間，付款方，交易金額，交易類型，交易狀態這些字段。

　　

　　因爲每一個渠道的帳單格式都不盡相同，在獲得帳單後，下一步是對帳單作標準化處理，這樣軋賬以及後續工做就能夠統一處理了。 標準化後的帳單數據能夠放在文件系統或者數據庫中。這取決於交易數據量。天天百萬以上的量，仍是使用文件系統，比較合適。數據庫操做相對比較慢，也浪費資源。

　　基於文件系統的標準化涉及以下內容：

　　文件格式標準化：統一使用csv或者json或者xml格式。若是是使用hadoop或者spark來對帳，使用csv是個不錯的選擇。

　　文件存儲統一化：文件目錄，文件名都須要遵循統一命名規範。

　　爲了加快處理速度，咱們使用hdfs做爲文件系統，有利於後續的對帳的處理。

　　本地交易記錄準備

　　本地交易記錄的準備，總的來講有以下方法: – 啥都不作，直接用原始數據。鑑於大部分系統使用的是mysql，這也意味着在MySQL上作對帳。對帳時須要大量的數據查找工做，必然會影響線上業務。在數據規模較大，好比超過100萬時，就不太合適了。

　　固然，還有一個選擇是使用備庫來執行對帳，這樣既簡單，也不影響線上業務。這是典型的空間換時間的作法。

　　若是業務大到須要分表分庫才能處理，那對帳數據準備也不同。使用分庫也不現實，由於分庫通常是按照主體id，而不是渠道id，來分庫，這樣對帳就須要在多個庫上進行，效率反而下降了。而對分表分庫創建從庫也很是耗費資源。這種狀況下，須要同步一份數據到(hdfs)文件系統中，或者NOSQL數據庫上。

　　因爲交易記錄是支付系統核心數據，有大量的應用，如信用、風控等，都須要交易記錄數據。這些應用對交易記錄的需求還不徹底一致，爲了提高性能，交易記錄會使用異步的方式來將數據投遞給使用方。 交易記錄在入庫時，投遞消息到消息系統中。使用方監聽這個消息，一旦收到新消息，則從交易記錄庫中查詢數據，獲取數據並更新到庫中。關於此類數據同步的文章很多，這裏就不詳細介紹。

　　軋賬

　　軋賬是按照客戶訂單號來比較本地交易記錄和渠道交易記錄是否一致。從算法角度，是計算兩個數組的差別。在單機運行時，能夠採用的算法很多，這裏不詳細介紹。咱們推薦採用mapreduce來軋賬，這有個優點，能夠按照訂單號將渠道提供的記錄和本地記錄shuffle到同一個reduce處理上，這樣就能夠很容易進行數據比對。 軋賬中最大的坑，莫過於切分點的問題。

　　好比以整0點爲切分點，那存在一個問題，本地23:59發起的交易，到了渠道側，可能會在00:01處理，這一筆交易變成次日的賬了。實際處理中，一筆交易在渠道側處理，花上幾分鐘都有可能。 對於切分點附近沒法確認的賬，作一個時間窗，在時間窗內的數據，留待次日對帳時繼續處理。

　　平賬

　　發現兩邊不一致的數據，那應該如何處理？數據量不大時，記錄起來，人工甄別就行。但若是數據量很大，天天上千條，人工處理就成本過高了。這個沒有統一的處理方法，須要根據有問題的數據，作個分析，而後作自動處理。針對交易記錄的對帳的處理，主要有以下狀況：

　　本地未支付，支付渠道已支付。這主要是本地未正確接收到渠道下發的異步通知致使。通常處理是將本地狀態修改成已支付，並作響應的後續處理，好比通知業務方等。

　　本地已支付，支付渠道已支付，可是金額不一樣，這個須要人工覈查。

　　本地已支付，可是支付渠道中無記錄；或者本地無記錄，支付渠道有記錄。在排除跨日因素外，這種狀況很是少見，須要瞭解具體緣由後作處理。

　　針對退款的對帳處理，主要有以下狀況：

　　本地未退款，支付渠道已退款，則以支付渠道爲準，修改本地爲已退款狀態，並出發後續處理。

　　本地已退款、支付渠道已退款，可是金額不一樣，須要人工覈查；

　　本地已退款，可是支付渠道無記錄；或者支付渠道有記錄，可是本地沒有。在排除跨日因素外， 這種狀況很是少見，須要瞭解具體緣由後作處理。

　　總之，對帳工做，即複雜也不復雜。須要細心，對業務要有深刻的瞭解，並選擇合適的架構。

　　這一期，回到支付系統的核心業務，即支付。每一個電商公司的支付系統都已經或多或少的實現了交易核心功能，可也都是一直在改進，老是不斷的有新的需求冒出來。因此這一期開始，咱們梳理一下：到底有哪些支付方式？每種支付方式都是怎麼運做的？

　　

　　支付和交易

　　說到支付就不得不提交易。這兩個概念在不一樣公司中是不同的。咱們的定義是，交易是生成訂單；支付是對訂單進行付款。訂單生成過程咱們之後另開話題來講。這一次重點介紹支付。而就支付行爲來講，咱們碰到的大部分都是單次支付，其次還有轉帳和退款。在蘋果推出訂閱支付後，國內支付寶等也在陸續跟進。單次支付是咱們用的最多的支付方式了，即一次結清全部款項。把單次支付走通了，其餘支付方式也容易處理。 本期重點介紹單次支付。

　　銀行卡支付

　　先說你們比較熟悉的銀行卡支付，它分爲線上支付和線下支付兩種形式。線下支付就是一般說的POS收單，這裏不介紹這個內容。對線上支付，按照卡的類別，分爲貸記卡支付，也叫motopay、ePOS，即信用卡支付；和借記卡支付。按照支付形態，又分爲認證支付、網銀支付、快捷支付幾種形態。銀行卡網銀支付要求銀行卡必須開通在線支付功能，而快捷支付並不須要開通在線支付功能。主要利用支付驗證要素（卡號、密碼、手機號、CVN二、CVV2等），結合安全認證（例如短信驗證碼），讓持卡人完成互聯網支付。

　　認證支付

　　指用戶在綁卡時，將卡信息提供給電商。這樣在支付時，用戶無需再輸入這些信息，由電商在服務器側保留用戶的帳戶信息，好比身份證號，卡號，手機號。在用戶支付時，無需再輸入這些內容，最多就提供個密碼或者校驗碼，就能夠完成支付。這基本不會打斷用戶的使用體驗，因此也是電商喜歡的支付方式。但認證支付最讓人詬病的就是安全性。一方面須要向電商暴露我的信息，一旦被竊取，資金就容易被盜走。還有在手機上執行支付，一旦手機丟失，竊取者就能夠垂手可得的使用或者轉移資金。

　　快捷支付

　　快捷支付和認證支付相似，不一樣點在於綁卡以後，有些銀行接口會返回token，後續使用token來做爲支付憑證，無需提供卡號信息，這樣電商也不須要本地保留卡號了。目前主要是銀聯有提供token接口。

　　網銀支付

　　相對來講，網銀支付要安全不少。網銀支付是由銀聯或者銀行提供支付界面，用戶必須在頁面上輸入卡號，密碼等驗證信息才能夠執行支付。大部分銀行還要求用戶使用U盾或者其它安全硬件。但安全和易用永遠是個矛盾。網銀使用會打斷用戶體驗，增長用戶使用難度。對使用硬件加密的支付，不可能每天帶着U盤跑。另外網銀主要用在web端，在手機端，嵌入網銀頁面，仍是比較難看的

　　支付流程

　　走一個具體的例子看看吧。好比用戶在電商系統中買了200塊錢的東西，而後經過浦發銀行卡作結算，用的是快捷支付。這個過程是：

　　用戶在交易界面上，提交訂單到交易系統中；交易系統確認訂單無誤後，請求支付系統進行結算。這是在交易系統作的，後面工做就進入支付系統。

　　用戶被引導到收銀臺頁面，讓用戶確認交易金額，選擇支付方式，調用支付系統接口。

　　支付系統接收到支付請求，驗證請求的各個字段是否有問題，確認無誤後，調用支付網關執行支付。

　　支付網關請求浦發銀行的快捷支付接口執行支付。

　　支付網關接收到支付結果報文後，對結果報文作解析，獲取結果，並將結果告知交易系統。這能夠經過URL或者RPC調用來實現。

　　商城系統收到支付結果後，開始執行後續操做。若是是支付成功，則開始準備出庫。這一步在交易系統中處理，這裏不作介紹。

　　網銀支付，和快捷相比，就在第4步，插入一個步驟，將用戶導航到網銀頁面輸入支付信息，後續步驟是同樣的。在資金流上也是相同的。 而在第五步獲取返回結果上，通常銀行就直接同步返回，銀聯是分爲同步和異步返回。同步告知操做成功或者失敗，異步告知扣款成功或者失敗。同步操做和異步操做都須要調用方提供一個回調的URL地址，銀聯會將參數附加在這個地址上。經過解析這些參數能夠獲得執行結果。異步操做通常有2-3秒的延遲，取決於網絡，以及該交易處理的複雜度。

　　資金流

　　上一節說的是支付的信息流，那資金流應該是怎麼走的？在第三步，會觸發資金流。資金從用戶我的帳戶上轉移到電商公司的帳戶。固然，銀行也不是活雷鋒，這一筆交易是要收手續費的。資金是實時到帳的，手續費通常是按月結算。有按交易筆數計費的，但大部分仍是按照交易金額來收費。

　　同行快捷支付是比較簡單的場景，讓咱們來逐步增長難度。若是支付系統沒有對接浦發銀行，那對浦發卡，就得走其它支付方式：銀聯或者第三方支付。

　　先說銀聯快捷。銀聯提供的多種接入方式，常說的快捷支付，在銀聯文檔中叫商戶側開通token接口。經過這個接口，能夠實現同行和跨行資金結算。無論收款行是浦發仍是其它行，均可以完成結算。對本地和用戶來講，體驗是同樣的。而在銀聯側，後臺資金流處理卻不同。瞭解這個資金流，有助於在異常狀況下，瞭解資金到底跑到哪裏了。

　　若是收款行也是浦發銀行，銀聯發報文給浦發，浦發使用內部系統完成兩個帳戶間的轉賬，即時完成。

　　若是收款行是他行，好比工行。銀聯發指令給浦發和工行，分別完成各自帳戶上資金餘額的增減，對我的和電商來講，這筆資金算是落地了。但實際資金流並非當即發生。銀聯會在半夜作清結算後處理這筆資金。這個過程就是金融機構之間的清結算了，通常不須要關注。

　　若是使用的是第三方支付，對用戶來講，處理的流程和銀聯同樣。但資金流會不同。第三方支付在浦發和工行通常都會有落地的託管資金。 發生交易後，通常來講不會產生跨行資金流動。用戶在浦發行的錢會被結算到第三方支付在浦發行的託管帳戶，而在工行的錢，會由第三方支付在工行的帳戶打到客戶帳戶上。這就下降了跨行資金流動成本。

　　目前國內主要銀行都提供快捷和直聯的接口。對電商來講，要對接哪些銀行是個須要考慮的問題。怎麼對接銀行，渠道和第三方支付。

　　銀聯Token支付

　　通常來講，大部分銀行都提供直聯和網銀接口，但不須要直接對接全部銀行。銀聯和第三方支付也提供直聯接口，能夠直接對接國內主要銀行。也不是全部銀行都被銀聯支持，這和銀聯簽約的接口有關，須要在對接時諮詢銀聯。從咱們使用狀況看，浦發借記卡、郵儲銀行卡是不支持的。 另外 交行、平安（含原深發）、上海銀行、浦發、北京銀行，上述銀行卡需經過 這個地址 開通銀聯在線支付業務。

　　對接銀行

　　大部分銀行提供的銀行卡支付接口，借記卡支付和貸記卡支付是不同的。但也有幾個好心的銀行，能夠用一套接口同時開通借記卡和貸記卡。點名贊一下這些銀行：宇宙第一大行工商銀行和建設銀行。其餘同窗對接中若是也發現借記卡和貸記卡用一個接口的，也請及時告知。 做爲國內最保守的軟件團隊，和銀行對接時務必作好足夠的準備。在商務談判完成、拿到銀行的接口文檔後，須要考慮兩個問題：專線問題、加密問題。

　　專線問題

　　首先是專線問題。大部分銀行對接是須要專線的。 與銀行溝通的時候，注意收集以下信息：

　　專線類型： MSTP類型或者SDH類型。

　　專線接入點：目前國內主要是聯通、電信。

　　封裝類型： HDLC或者PPP

　　專線代寬：默認是2M

　　前置機IP，這個須要在銀行側和電商側進行配置。 專線實際上是在銀行和電商之間創建一個局域網，須要雙方分配通信IP。 其實這兩組IP都是NAT後的IP，銀行分配給咱們的是電商真實的前置機IP通過最外端的網絡防火牆轉換後的IP段，後者也是對方的真實前置機IP通過轉換後的IP段。 出於安全考慮，雙方都不會將真實IP暴露出去，因此要NAT。

　　接入地址：即電商這邊機房的地址。

　　這些專業名詞，能夠本身檢索，太專業了，其實我也不懂。從可靠性角度考慮，通常建議從聯通、電信各拉一條線路出來。一旦有一個線路出問題了，也不會致使全部交易被終止了。不須要專線的銀行接口有：浦發、工行、交行信用卡等。須要專線的有中行、農行、建行等。通常專線須要1個月左右的時間，包括銀行側的申請、施工時間。

　　加密問題

　　其次是加密問題。部分銀行，如中行，前置要求使用加密機。此處加密機的經常使用功能有三方面：

　　MAC加密（完整性）；

　　支付會話密碼加密（安全性）；

　　密鑰交換加密（防截取）。

　　對開發來講，加密機的主要做用，是讓黑客都沒法從內存中看到密碼。不是作廣告，國內對接銀行通常就用江南天安的加密機了

　　對接銀聯

　　對接銀聯比對接銀行簡單，不須要專線，不須要加密機。 不過須要獲取ADSS認證。 銀聯最近在推Token接口，有兩套接口，一套是銀聯側開通，一套是商戶側開通。前者相似網銀支付，後者相似快捷支付。務必要求接入後者接口啊。基本上讀完接口文檔就知道怎麼寫代碼了。

　　在上一篇支付系統之銀行卡支付中，挖了個坑，就是關於綁卡的坑。 在用戶使用銀行卡作支付以前，首先須要完成綁卡的操做。怎麼實現綁卡，怎麼驗證用戶綁的是本身的而不是隔壁老王的卡，這就是本期的重點。

　　

　　爲何要求用戶綁卡？這和快捷支付有關。參見上一篇文章的分析，綁卡是將用戶卡信息提供給電商，之後電商就用這個信息去銀行完成支付。綁卡其實是一個受權，讓用戶容許商家自動從他的帳戶上扣除資金。因此綁卡也叫簽約，用戶和銀行，商家的三方簽定的支付合約。但咱們知道，綁卡對用戶和商戶來講都存在巨大風險。

　　若是說用戶綁卡是圖省事，那商戶爲何要作這個事？首先固然是提高用戶體驗了，讓用戶花錢更容易。其次，提高支付成功率。使用網銀支付成功率在20%左右，銀聯直聯成功率通常在50%左右，銀行卡直聯能夠提高到70%左右。這是至關可觀的數據。因此，當你看到綁卡送洗衣粉之類作法時，不須要擔憂商家會不會賠本。

　　怎麼綁卡？咱們知道對接銀行有兩種途徑，直接對接銀行接口和經過銀聯來間接對接。這兩種狀況下綁卡處理也不一樣。

　　綁卡場景

　　直觀的，電商網站會在用戶後臺提供一個綁卡的入口，讓用戶直接綁卡。以支付寶綁卡流程爲例，咱們能夠體驗下：

　　

　　這裏有以下要點：

　　只能綁本身的卡，這主要從安全角度考慮。

　　須要用戶在銀行側預留的手機號進行短信驗證。但不是全部銀行都須要。這個時候，爲了統一處理，能夠考慮本身發驗證短信。

　　對這個入口不要期望太多，更多的用戶是在支付中綁卡。也就是提交訂單後，發現沒有銀行卡了，就開始綁卡。和純綁卡流程不一樣的是，最後一步，綁卡成功後，通常都同時完成支付。有些渠道會提供綁卡並支付的接口，減小交互次數。

　　綁卡流程

　　先介紹比較簡單的銀聯直聯綁卡。爲了保證卡的安全，綁卡有這些前置需求：

　　用戶必須已經綁定了手機號。該手機號用於修改支付密碼；

　　用戶需設置了支付密碼。支付密碼不一樣於登陸密碼。

　　針對用戶不一樣狀態，綁卡流程上有區別。固然，綁卡是安全操做，要求用戶必須登陸到系統中。爲了不和服務器端的交互被劫持，全部操做必須在安全連接中進行，即便用https。當用戶開始綁卡時，執行以下流程：

　　檢查用戶是否有手機號。沒有則進入設置手機號流程。

　　檢查用戶是否設置支付密碼。若是已經設置，則須要用戶輸入密碼。確認後開始綁卡。不然，也是先進去綁卡後設置密碼。

　　用戶輸入卡號，系統根據卡號判斷卡的髮卡行，並顯示給用戶。有些實現，如微信支付，會提供掃卡識碼功能。

　　用戶輸入銀行預留手機。對於沒有綁過卡的用戶，須要用戶提供真實姓名和身份證號。對於信用卡，還須要輸入cv碼和有效期。這一步，卡的信息都收集全了。

　　調用銀行綁卡驗證接口進行綁卡。這裏有一個四要素驗證的概念。因爲國內要求實名制，全部銀行卡都是實名辦理的，因此銀行能夠驗證姓名，身份證號，銀行卡號和手機號是否是一致的，若是沒問題，則會發短信到手機上。

　　用戶輸入短信驗證碼並確認綁卡，服務器端將用戶實名信息以及短信驗證碼組合造成報文，發送給銀行，執行簽約操做。銀行側簽約成功後，返回簽約號給商戶。

　　卡bin

　　這裏有個問題，如何根據卡號判斷髮卡行？這就須要卡bin。 BIN號即銀行標識代碼的英文縮寫。BIN由6位數字表示，出如今卡號的前6位，由國際標準化組織（ISO）分配給各從事跨行轉接交換的銀行卡組織。銀行卡的卡號是標識髮卡機構和持卡人信息的號碼，由如下三部分組成：髮卡行標識代碼（BIN號）、髮卡行自定義位、校驗碼。

　　目前，國內的銀行卡 按照數字打頭的不一樣分別歸屬於不一樣的銀行卡組織，其中以BIN號「4」字打頭的銀行卡屬於VISA卡組織，以「5」字打頭的屬於MASTERCARD卡組織，以「9」字和「62」、「60」打頭的屬於中國銀聯，而「62」、「60」打頭的銀聯卡是符合國際標準的銀聯 標準卡 ，能夠在國外使用，這也是中國銀聯近幾年來主要發行的銀行卡片。大部分銀行卡號前6位便可肯定髮卡行和卡類型，但也有非標卡須要6-10位才能夠判斷出來。須要維護一個卡bin庫。附件是一個比較完整的卡bin庫， csv格式的。

　　短信和身份驗證

　　通常綁卡操做第五步須要銀行下發短信驗證碼。短信驗證的接口，不一樣銀行還不同。有些銀行是短信和身份驗證一塊兒作了；有些銀行是能夠配置身份驗證是否同時發短信。還有些比較奇葩的機構，好比某聯，接口中讓你傳身份信息，但實際上沒傳也是能夠的，也不驗證身份信息到底對不對。這在對接渠道時須要特別注意。

　　此類接口通常包含以下內容：

　　版本號：當前接口的版本號；

　　編碼方式：默認都是UTF-8，指傳輸的內容的編碼方式；

　　簽名和簽名方法：生成報文的簽名。 不是全部的字段都須要放到簽名中，文檔中會說明哪些字段須要簽名；

　　簽名算法：生成簽名的算法，RSA, RSA128， MD5等。

　　商戶代碼：在渠道側註冊的商戶號。

　　商戶訂單號：即發送給渠道的訂單號；

　　發送時間：該請求送出的時間。

　　帳號和帳號類型：銀行卡、存摺、IC卡等支持的帳號類型以及對應的帳號；

　　卡的加密信息：如信用卡的CVN2，有效期等。

　　開戶行信息：開戶行所在地以及名稱；大部分是不須要的。

　　身份證件類型和身份證號：能夠用於實名驗證的證件，指 身份證、軍官證、護照、回鄉證、臺胞證、警官證、士兵證等。不一樣銀行能夠支持的證件類型不同，這也不是問題。大部分就是身份證了。

　　姓名：真實姓名，必須和身份證一致；

　　手機號：在所在銀行註冊的手機號。

　　系統會返回上述數據的驗證結果。若是驗證經過，則會發短信。但這不是全部的渠道都是這樣。哪些字段會參與驗證、需不須要發短信，須要注意看接口文檔。

　　綁卡接口

　　綁卡接口和發短信接口相似，還須要將用戶的卡號，身份證等信息傳遞過去。在綁卡成功後，會返回一個簽約號。這個簽約號是後續調用支付，解約等接口所必須的。這裏有個問題，已經綁卡的用戶，調用綁卡簽約接口再綁一次，會出現什麼狀況？這個和銀行實現有關。 大部分銀行，如農業、浦發、建行等，對綁卡簽約接口調用，會首先驗證身份信息，若是驗證不經過，則不執行後續操做。驗證經過後，再檢查這個卡在該商戶下是否已經綁過了，若是沒有綁過，則執行綁卡，不然會提示卡已經綁定過了，不能重複簽約。 但工行的實現不同，他是首先驗證這個卡是否是已經綁過了，若是已經綁卡，則不繼續驗證身份信息。總之，銀行都不支持重複綁卡。

　　銀聯綁卡

　　銀聯直聯綁卡和銀行綁卡相似，可是得注意驗證接口，僅驗證卡號和姓名，不驗證身份證號和手機號。這致使第5步沒法正常進行。銀聯只有到第六步執行綁卡時才作身份驗證。 因此在處理上，還須要作一些調整，來確保和銀行的流程的一致。 一種處理方法是，對銀聯，在第五步就開始調用銀聯接口執行綁卡操做，可是在本地標記爲預綁卡狀態；商戶側發送短信驗證碼，驗證經過後，纔將狀態設置爲綁卡成功。

　　銀聯網銀綁卡處理起來比較麻煩。用戶在電商頁面上輸入卡號，而後被導航到銀聯頁面上去完成綁卡操做，成功後，銀聯返回一個token做爲簽約號，用於支持後續操做。這問題就來了，用戶能夠在銀聯頁面上綁定一個別人的卡，而電商側是沒法知道這個卡的狀況的。因此這種方式儘可能不要用。

　　實名認證

　　綁卡操做有個不錯的副產品，就是實名認證。常說的二要素，三要素，四要素認證，能夠經過這個操做完成。二要素指姓名和身份證號，三要素加上銀行卡號，四要素則加上手機號。看起來，彷佛銀行都應該支持四要素驗證，但大部分銀行接口僅支持三要素，畢竟手機號仍是很是容易變。固然，實名認證，也就是二要素認證，是應用最多的認證了。國內惟一的庫是在公安部這，由NCIIC負責對外提供接口。能夠提供以下功能：

　　簡項覈查：返回「一致」「不一致」「庫中無此號」

　　返照覈查：返回「一致+網紋照片」「不一致」「庫中無此號」

　　人像覈查：返回「同一人」「不一樣人」「庫中無此號」

　　官方接口收費是 5元/條。 市面上主要的第三方服務提供商有國政通（簡項、返照）、諾證通（簡項）、IDface（三接口）等，收費簡項覈查：0.5~2.0元、返照覈查爲0.8~2.1元、 人像覈查2.0~8.0元不等。通常都和訪問量有關，量大從優。

　　固然，這裏也要注意，涉密人員是無法查到相關信息的。性能上， XX通通常在200ms內便可返回結果，普通商用應該是沒問題的。有些公司還會額外提供四要素接口，以XX通爲例，它號稱支持大部分銀行卡的四要素認證。可是實現上有點兒懵，竟然是實時請求銀行的接口，這就致使接口延遲很是高，1秒以上的佔大部分，甚至10秒以上的都很多見，基本沒法商用。這種狀況下，還不如直接上銀聯。

　　應用內支付指使用手機操做系統自帶的支付功能來支持支付。目前國內主要的應用內支付有 Google Pay、Apple Pay、小米支付、華爲支付等。 其中Apple Pay是典型的一個應用內支付，Android平臺的各類支付也通常是沿用Apple Pay的設計。

　　

　　爲何要IAP

　　相對來講，應用內支付的用戶體驗，和微信支付、支付寶相比，仍是有必定差距的，可是爲何要開發應用內支付呢？這個和蘋果的AppStore的審覈政策有關。 在官方的 (App StoreReview Guidelines) 中， 有以下幾條意見：

　　1.2 Apps utilizing a system other than the In-App Purchase API(IAP) to purchase content, functionality, or services in an App will berejected.

　　在 App 內使用非 IAP 的系統來購買內容、功能或服務將被拒絕。

　　11.3 Apps using IAP to purchase physical goods or goods andservices used outside of the App will be rejected.

　　IAP 購買實物或者應用外的商品或服務將會被拒絕；

　　11.4 Apps that use IAP to purchase credits or other currenciesmust consume those credits within the App

　　經過 IAP 購買的積分或者其餘貨幣必須只在 App 內使用。

　　這問題就來了，若是要購買的服務，即在IOS內使用，也在Android等IOS系統外使用，那應該是使用規則11.2或者規則11.3來執行？ 好比說視頻網站，視頻既能夠在IOS上看，也能夠在Android上看，那是不是須要經過IAP來購買？ 蘋果公司在這一點上採起模糊的策略。 愛奇藝、騰訊視頻，在IOS上購買會員，只能用IAP支付。這就和蘋果公司的審覈有關。

　　IAP支付流程

　　通常IAP支付的開發流程，首先須要一些準備工做，包括：

　　在developer.apple.com上配置一個App ID，使用該ID生成和安裝相應的Provisioning Profile文件。

　　登陸到iTunes Connect，使用App ID建立一個新的應用，在該應用中，建立應用內付費項目，設置好價格和Product ID以及購買介紹和截圖。

　　添加一個用於在sandbox付費的測試用戶，填寫相關的稅務，銀行，聯繫人信息。

　　完成這些準備工做後，既能夠進入正式的開發，開發代碼咱們這裏就不說了，流程以下：

　　用戶選擇要購買的內容並點擊購買按鈕；

　　用戶經過App Store帳戶驗證

　　蘋果服務器驗證用戶請求

　　蘋果服務器從用戶賬號扣款

　　蘋果向用戶返回購買成功信息

　　軟件接收並顯示用戶購買信息

　　老司機都能看出來，這裏有好多好多的坑。

　　用戶訪問AppStore時使用的是Apple的帳號，不是應用系統的帳號。 也就是說，咱們並不知道究竟是誰在購買這個內容。好比在應用中有兩個帳號A和B，用A帳號登陸後，上IAP買了東西，而後用B帳號來登陸，也上IAP買東西， 這兩次購買，用的是同一個Apple帳號。蘋果也不會告訴你，究竟是哪一個帳號付了錢。帳號坑在單次購買中還沒什麼問題，但碰到訂閱的狀況，得好好處理下。在訂閱章節中會詳細說明。從上述流程能夠看出，蘋果服務器都是和客戶端打交道的，這裏面彷佛沒有應用服務器什麼事情。只有在客戶端接收到蘋果返回信息後，才能夠把這個信息轉發給應用服務器。 若是用戶一直不打開手機上的應用，那應用服務器就一直收不到通知了。 好在後來蘋果提供了一個驗證功能，應用服務器能夠把接收到的返回信息（加密後的字符串）發送給蘋果服務器來驗證和解密。

　　IAP訂閱

　　IAP Subion又是一個大坑。官方的文檔在這裏。內容很少，沒有說明的東西卻不少。

　　續費週期的計算

　　IAP主要提供給週期性訂閱的音樂、電子書等內容使用。通常就按月來計算週期。蘋果是以天然月來算權益週期。好比在1月3號買了權益，到2月3號，這個權益就過時啦，須要在此以前完成續費。 那問題來了，1月31號買的權益，到幾號過時？以天然月算，這個權益會在3月1日前到期，若是2月份，3月份都續費了，到4月份，也是享受到4月30日了。

　　自動續費

　　應用開發應該不須要關心續費的細節。蘋果會作自動處理。在權益到期前10天，蘋果檢查用戶帳戶是否能夠扣款，商品價格是否有變更。在權益到期前24小時，蘋果開始扣款，若是失敗，會屢次重試，直到成功。問題來了，這個重試，會延續到用戶權益過時後一小段時間，蘋果沒有說這段時間該算是有權益仍是沒有，但開發人員須要注意應該如何處理。

　　免費試用

　　免費試用不是強制需求，但這有利於用戶判斷是否值得購買這個物品。免費試用期是在itunes connect中設置。 當用戶第一次購買這個東西的時候， 客戶端接收到的Receipt中包含免費試用信息。在免費期快到的時候，蘋果發起第一次扣款。整個過程和自動續費相似，惟一區別是第一個月是免費的。

　　Receipt 驗證

　　客戶端接收到 Receipt 以後，須要提交到服務器端進行處理，開通權益。 這就來了個問題：Receipt應該在客戶端仍是服務器端解析？固然須要在服務器端處理，這樣能夠防止越獄後的一些插件，如IAP Cracker、IAP Free等僞造交易憑證，欺騙蘋果服務器，開通權益。此外，還需注意，客戶端和服務器端之間需經過HTTPS以及參數簽名等方式來確保通信安全。 服務器端接收到Receipt以後，首先驗證請求的有效性， 而後將Receipt發送到蘋果服務器上進行驗證和解析。接收到蘋果處理結果後， 將Receipt中的user_id,product_id、purchase_date、transaction_id等作驗證和處理。

　　IAP破解和防護

　　既然Iap的驗證主要是在蘋果服務器端和手機客戶端進行，而且是使用域名。這簡直是爲攻擊打開了一扇大門，而不只僅是漏洞。 早期的IAP內購解鎖工具IAP cracker對IAP的破解比較簡單粗暴。寫過IAP程序的人都知道， 程序中基本都是用transactionState來判斷交易是否成功。

　　transactionState 有四個狀態：

　　SKPaymentTransactionStatePurchasing

　　SKPaymentTransactionStatePurchased

　　SKPaymentTransactionStateFailed

　　SKPaymentTransactionStateRestored

　　SKPaymentTransactionStatePurchased 表示購買成功了。 只要修改這個變量值，若是客戶端應用直接根據交易狀態來處理業務流程，那就會收到這個假的交易成功信息，接下來用戶就能不花錢獲得所買的物品。這個過程，甚至都不須要接入網絡。

　　另外一個工具IAPfree功能更強大，安裝使用也複雜不少。它是經過修改DNS，讓客戶端訪問黑客提供的服務器來取代訪問蘋果服務器，實現所謂的MITM中間人攻擊。當用戶在客戶端觸發購買流程時，會被引導到假裝的蘋果服務器上，不扣款而直接返回扣款成功收據。用戶不須要支付任何資金，客戶端可以拿到完整的收據。若是是在客戶端處理收據驗證也沒有任何問題。爲了不用戶所使用的設備被封，這些軟件甚至能夠提供僞造UDID的功能。 爲此，蘋果特別說明，必定要在服務器端驗證用戶購買信息，驗證內容包括收據簽名，證書，產家信息等，確保收據無誤後，才能授予權益。若是發現有詐，則將用戶拉黑。

　　兩套帳戶體系

　　蘋果支付的帳戶體系,固然是以apple id爲基礎的，它容許用戶在多臺設備上共用一個帳戶。一臺設備上，通常只有一個激活帳戶。但對應用系統來講，大部分是容許多個帳號登錄的。這對續費來講就是個大問題。用戶以帳戶a登陸後，發起續費，得到權益。而後以帳號B登陸了，顯然，A的權益不會衍生給B。過幾天A開始續費了，續費以後，切換到B帳號登陸，客戶端在B帳號登陸時獲得續費的收據併發送給應用服務器。那這算是誰的續費請求？固然是A的。在這個apple id發起的續費請求，全部的收據都會有一個相同的原始交易號original transaction Id。在用戶發起訂閱時，須要記錄這個id和帳號的關係，每次續費，須要在解析收據後，根據原始交易號從這裏獲取真正的充值帳戶，不能從客戶端提交的用戶id做爲憑據。

　　仍是這個坑，若是在帳戶b登陸後也發起訂閱請求，會怎麼樣？這個調用將會失敗，因此須要阻止用戶發起這樣的請求。或者設置多個產品副原本讓用戶購買。

　　分紅，訂價和國際化

　　在iTunes中的給的產品訂價必須是稅前的，蘋果和商家的分紅，也是按稅前算。商家給出在一個主要銷售國家和地區（好比國內的基本就是中國了）的價格，即基準價格。在其餘地區的銷售價格，蘋果會自動根據當前的匯率來換算成當地的貨幣。固然，也能夠本身修改設定在這些國家或者地區的當地價格。目前是支持到155個國家。還要特別注意版權問題。

　　基準價格調整，若是是往高了調整，則在用戶下一次續費時，須要用戶確認。若是往低了調，那就不須要用戶確認，直接扣款了。

　　蘋果對商家的產品價格體系有分組（Group）的概念，同國內說的價格體系，好比白金會員、黃金會員、貴賓等，在同一個Group裏面，用戶只能選擇一個檔，好比用戶要麼是白金要麼是黃金會員，不會同時是。

　　在同一個分組中，若是用戶訂閱時間超過一年（365天），則商家能夠獲得來自這個用戶收益的更多的分紅，目前是85%。這個訂閱時間不包括免費試用期。同時能夠有60天的寬限。也就是說，這一年中，若是用戶曾經中止續費，而後又開始繼續續費，只要中間不續費的時間不超過60天就行。

　　更多的坑

　　目前用的是IOS 10.0 版本， 這個版本和IAP有關的坑，先記錄下：

　　沙盒環境，無法作取消訂閱操做。只能在線上模擬。 因此產品設計和開發時，儘可能不要依賴取消訂閱操做，也應該不依賴於這個操做。

　　沙盒環境下，有些receipt可能會收不到transaction id，線上的暫未發現這個問題。

　　蘋果提供單個收據和列表收據兩種格式。推薦使用列表數據，但問題是，這個列表收據的長度，蘋果也不知道最多會有多少。

　　Android IAP

　　好吧，用這個話題做總結，不是太好。IOS上用蘋果支付是被逼的，android上用IAP是圖什麼？支付寶和微信支付有這麼多用戶基數，接入也很方便，費用比IAP便宜多了。若是你有接入android IAP經驗，期待。