本文轉載自：https://xueqiu.com/1694220181/87140351
賬戶體系是支付系統的基礎，它的設計直接影響整個系統的特性。這裏探討如何針對電子商務系統的支付賬戶體系設計。我們從一些基本概念開始入手，瞭解怎麼建模。
支付賬戶和登錄賬號
賬戶體系設計首先要區分兩個概念，支付賬戶和登錄賬號。這是兩個不同業務領域的概念：支付賬戶指用戶在支付系統中用於交易的資金所有者權益的憑證；登錄賬號 指用戶在系統中的登錄的憑證和個人信息。一個用戶可以有多個登錄賬戶，一個登錄賬戶可以有多個支付賬戶，比如零錢賬戶，儲值卡賬戶等。一般來說，支付賬戶不會在多個登錄賬戶之間共用。如果沒有特殊說明，下文中的賬戶，都默認指支付賬戶。
賬戶的設計需求
在支付系統中，賬戶的設置，主要是從如下幾個方面來考慮：
交易的需求，比如檢查賬戶是否被鎖定、餘額是否足夠、是否有效等。
記賬的需求，按照公司會計需求記錄賬戶上的所有行爲，包括支出、充值、轉賬等。
對賬的需求，包括和支付渠道、商戶、個人的對賬需求，覈對交易和賬戶餘額是否正確。
風控的需求，如反洗錢、反欺詐等，都需要依賴於賬戶體系來提供核心數據。本文暫不分析這個內容，將在《支付風控》、《支付反洗錢》這兩篇文章中詳細分析
信用的需求，對用戶、資產、商戶等主體進行信用評估時，也需要依賴賬戶體系來提供的核心數據。本文也暫不分析這內容，將在《信用與支付》一文中分析。
這五個需求，按照其設計的優先級，也是從支付、記賬、對賬、風控來進行。支付系統根據其發展所處的階段，逐步將新增需求納入設計中。
交易與賬戶
賬戶設置，一般是從交易開始的。交易的實現必須有賬戶的支持，賬戶是交易的基本構成元素。從支付系統的角度，交易中涉及到的資金流是資金從一個賬戶流向另一個賬戶。發起交易的一方，被稱之爲交易主體，他可以是個人，也可以是一個機構。
資金從該主體所擁有的賬戶中流出。而接收交易的一方，被稱爲交易對手，他也可以是個人，或者機構。和第三方支付或者金融機構的交易不同，電商系統中，交易還會涉及到渠道。
由於電商系統本身並無清結算的資質，所有資金從交易主體到交易對手的賬戶的流動，在大部分情況下，並沒有經過電商系統，而是由電商系統調用支付渠道提供的接口，由它來完成真正的支付過程。當然，渠道也不是活雷鋒，在這過程中，渠道要收取費用。
所以，在電商系統中，一次交易會涉及到三個賬戶： 交易主體賬戶、交易對手賬戶以及支付渠道賬戶。如何在這三個賬戶中完成一次交易，我們將在後續的《交易和記賬》一文中詳細分析。
記賬與賬戶
公司的會計需要對每一筆交易都要做詳細的記錄，即記賬。公司每天都產生大量的交易行爲，爲了便於管理和統計，一個簡單的方法是對交易進行分類，比如食品、帶寬、辦公用品等等。這個分類，按照公司的規模和業務複雜度，可以有一級，二級，三級或者更多級的結構，這被稱之爲會計科目。記賬時，除了交易明細，還需要在每個級別上對交易額進行彙總。
一般來說，一級科目上彙總稱爲總帳科目，而詳細記錄稱爲明細科目。在電商系統中，由於涉及到的參與方較多，記賬也相對複雜，但基本方法也是類似的。電商的參與者可以分爲商戶、買家和渠道，對這三類參與者，都需要分別建立總帳賬戶和明細賬戶。
內部賬戶和外部賬戶
當用戶使用銀行卡來支付時，電商支付系統需要和銀行對接，從用戶銀行卡所代表的賬戶上扣除資金。對接了銀行，第三方支付等機構的電商支付系統，它需要連接到用戶在這些機構的賬戶來執行扣款或者充值操作，這些賬戶或稱爲外部賬戶。對外部賬戶，支付系統只能記錄賬戶在本系統的明細以及累計消費額，無法得知賬戶真正餘額。不少電商在玩零錢的概念，也就是讓用戶充值到零錢，使用的時候就直接從零錢中扣除。這就需要零錢賬號。這是電商系統中自己設立的賬號，所以也叫內部賬號，可以知道賬號的全部消費明細和餘額。當然，除了零錢賬號，也可以有儲值卡賬號，信用賬號等。
那問題來了，什麼時候需要建立賬戶，比如優惠券，需要賬戶嗎？ 一次消費的儲值卡和可以充值的儲值卡，需要建立賬戶嗎？這裏先埋個雷，後續介紹支付和記賬時，給出答案。
收款賬戶和收單賬戶
當電商要對接銀行時，往往都會被要求開設一個收款賬戶。用戶通過這個銀行來支付時，錢就被轉到這個賬戶上。對第三方支付也是一樣。收款賬戶是開設在銀行或者第三方支付這邊的，即渠道側。一般來說，渠道每天都可以提供這個賬戶的交易流水供電商對賬用。這樣在電商這邊，渠道就成爲一個收單機構。所以在電商這邊，建立這個收款賬戶對應的對賬用的收單賬號，用來記錄通過這個渠道進行的各項交易流水。
賬戶建模
說了這麼多，目的是爲了對賬戶建模。賬戶模型是和公司業務密切相關的，公司不同規模，發展的不同階段需要不同的模型。賬戶建模本身包括三大核心模型：實體模型、賬戶模型和交易模型。從交易模型中可以衍生出針對各個角色的賬戶流水，即明細模型，用於支持對賬。
實體模型
實體模型和用戶、商戶模型有重疊的地方，這裏專門針對支付而設置的各個實體屬性。一般來說，支付相關的實體模型需要包括如下的屬性：
用戶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，即信用卡支付；和借記卡支付。按照支付形態，又分爲認證支付、網銀支付、快捷支付幾種形態。銀行卡網銀支付要求銀行卡必須開通在線支付功能，而快捷支付並不需要開通在線支付功能。主要利用支付驗證要素（卡號、密碼、手機號、CVN2、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 Store Review 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 be rejected.
在 App 內使用非 IAP 的系統來購買內容、功能或服務將被拒絕。
11.3 Apps using IAP to purchase physical goods or goods and services used outside of the App will be rejected.
IAP 購買實物或者應用外的商品或服務將會被拒絕；
11.4 Apps that use IAP to purchase credits or other currencies must 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 Subscription又是一個大坑。官方的文檔在這裏。內容不多，沒有說明的東西卻很多。
續費週期的計算
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經驗，期待。
作者介紹：鳳凰牌老熊，程序員 & 架構師，來自中科大的本科，研究生在軟件所學習。先後在中科輔龍、三星（中國）研究院和國內一些大型的互聯網公司呆過。在中科輔龍公司負責電子政務內容管理系統建設，負責研發龍馭系列產品的研發，這款產品最終實施到2000多個電子政務網站上，期間也參與了一些支付反洗錢以及支付系統的建設。之後在三星中國研究院，負責自然語言處理（NLP）以及智能家居相關項目。智能家居項目在2014CES消費電子展上作爲三星重點項目推介。2014年開始加入愛奇藝公司，負責數據倉庫和支付系統的建設
作者：支付圈
鏈接：https://xueqiu.com/1694220181/87140351
來源：雪球
著作權歸作者所有。商業轉載請聯繫作者獲得授權，非商業轉載請註明出處。