局域網(wǎng)ip分配規(guī)則_局域網(wǎng)ip分類

早茶

快訊

精選

智庫

專欄

鳳凰牌老熊（ID：shamphone）

　　賬戶體系是支付系統(tǒng)局域網(wǎng)ip分配規(guī)則的基礎局域網(wǎng)ip分配規(guī)則，它的設計直接影響整個系統(tǒng)的特性。這里探討如何針對電子商務系統(tǒng)的支付賬戶體系設計。我們從一些基本概念開始入手，局域網(wǎng)ip分配規(guī)則了解怎么建模。

　　支付賬戶和登錄賬號

　　賬戶體系設計首先要區(qū)分兩個概念，支付賬戶和登錄賬號。 這是兩個不同業(yè)務領域的概念：支付賬戶指用戶在支付系統(tǒng)中用于交易的資金所有者權益的憑證局域網(wǎng)ip分配規(guī)則；登錄賬號指用戶在系統(tǒng)中的登錄的憑證和個人信息。 一個用戶可以有多個登錄賬戶，一個登錄賬戶可以有多個支付賬戶，比如零錢賬戶，儲值卡賬戶等。 一般來說，支付賬戶不會在多個登錄賬戶之間共用。如果沒有特殊說明，下文中的賬戶，都默認指支付賬戶。

　　賬戶的設計需求

　　在支付系統(tǒng)中，賬戶的設置，主要是從如下幾個方面來考慮：

交易的需求，比如檢查賬戶是否被鎖定、余額是否足夠、是否有效等。

記賬的需求，按照公司會計需求記錄賬戶上的所有行為，包括支出、充值、轉賬等。

對賬的需求，包括和支付渠道、商戶、個人的對賬需求，核對交易和賬戶余額是否正確。

風控的需求，如反洗錢、反欺詐等，都需要依賴于賬戶體系來提供核心數(shù)據(jù)。本文暫不分析這個內(nèi)容，將在《支付風控》、《支付反洗錢》這兩篇文章中詳細分析

信用的需求，對用戶、資產(chǎn)、商戶等主體進行信用評估時，也需要依賴賬戶體系來提供的核心數(shù)據(jù)。本文也暫不分析這內(nèi)容，將在《信用與支付》一文中分析。

　　這五個需求，按照其設計的優(yōu)先級，也是從支付、記賬、對賬、風控來進行。 支付系統(tǒng)根據(jù)其發(fā)展所處的階段，逐步將新增需求納入設計中。

　　交易與賬戶

　　賬戶設置，一般是從交易開始的。 交易的實現(xiàn)必須有賬戶的支持，賬戶是交易的基本構成元素。 從支付系統(tǒng)的角度，交易中涉及到的資金流是資金從一個賬戶流向另一個賬戶。 發(fā)起交易的一方，被稱之為交易主體，他可以是個人，也可以是一個機構。

　　資金從該主體所擁有的賬戶中流出。 而接收交易的一方，被稱為交易對手，他也可以是個人，或者機構。 和第三方支付或者金融機構的交易不同，電商系統(tǒng)中，交易還會涉及到渠道。

　　由于電商系統(tǒng)本身并無清結算的資質(zhì)，所有資金從交易主體到交易對手的賬戶的流動，在大部分情況下，并沒有經(jīng)過電商系統(tǒng)，而是由電商系統(tǒng)調(diào)用支付渠道提供的接口，由它來完成真正的支付過程。 當然，渠道也不是活雷鋒，在這過程中，渠道要收取費用。

　　所以，在電商系統(tǒng)中，一次交易會涉及到三個賬戶： 交易主體賬戶、交易對手賬戶以及支付渠道賬戶。 如何在這三個賬戶中完成一次交易，我們將在后續(xù)的《交易和記賬》一文中詳細分析。

　　記賬與賬戶

　　公司的會計需要對每一筆交易都要做詳細的記錄，即記賬。 公司每天都產(chǎn)生大量的交易行為，為了便于管理和統(tǒng)計，一個簡單的方法是對交易進行分類，比如食品、帶寬、辦公用品等等。 這個分類，按照公司的規(guī)模和業(yè)務復雜度，可以有一級，二級，三級或者更多級的結構，這被稱之為會計科目。 記賬時，除了交易明細，還需要在每個級別上對交易額進行匯總。

　　一般來說，一級科目上匯總稱為總帳科目，而詳細記錄稱為明細科目。 在電商系統(tǒng)中，由于涉及到的參與方較多，記賬也相對復雜，但基本方法也是類似的。 電商的參與者可以分為商戶、買家和渠道，對這三類參與者，都需要分別建立總帳賬戶和明細賬戶。

　　內(nèi)部賬戶和外部賬戶

　　當用戶使用銀行卡來支付時，電商支付系統(tǒng)需要和銀行對接，從用戶銀行卡所代表的賬戶上扣除資金。對接了銀行，第三方支付等機構的電商支付系統(tǒng)，它需要連接到用戶在這些機構的賬戶來執(zhí)行扣款或者充值操作，這些賬戶或稱為外部賬戶。對外部賬戶，支付系統(tǒng)只能記錄賬戶在本系統(tǒng)的明細以及累計消費額，無法得知賬戶真正余額。 不少電商在玩零錢的概念，也就是讓用戶充值到零錢，使用的時候就直接從零錢中扣除。這就需要零錢賬號。這是電商系統(tǒng)中自己設立的賬號，所以也叫內(nèi)部賬號，可以知道賬號的全部消費明細和余額。 當然，除了零錢賬號，也可以有儲值卡賬號，信用賬號等。

　　那問題來了，什么時候需要建立賬戶，比如優(yōu)惠券，需要賬戶嗎？ 一次消費的儲值卡和可以充值的儲值卡，需要建立賬戶嗎？這里先埋個雷，后續(xù)介紹支付和記賬時，給出答案。

　　收款賬戶和收單賬戶

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

　　賬戶建模

　　說了這么多，目的是為了對賬戶建模。 賬戶模型是和公司業(yè)務密切相關的，公司不同規(guī)模，發(fā)展的不同階段需要不同的模型。 賬戶建模本身包括三大核心模型：實體模型、賬戶模型和交易模型。 從交易模型中可以衍生出針對各個角色的賬戶流水，即明細模型，用于支持對賬。

　　實體模型

　　實體模型和用戶、商戶模型有重疊的地方，這里專門針對支付而設置的各個實體屬性。 一般來說，支付相關的實體模型需要包括如下的屬性：

用戶ID，一般直接映射到登錄賬戶的ID；

是否允許執(zhí)行支付；

支付密碼；

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

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

用戶的安全等級，根據(jù)業(yè)務需要來設置。

賬戶模型

　　根據(jù)業(yè)務需要，可以設置多種賬戶，如支付賬戶、預付卡賬戶、代扣賬戶、零錢賬戶、結算賬戶等。 從類別上來說，這里的賬戶，一般指總賬賬戶。一般來說電商系統(tǒng)中涉及的賬戶類型有：

虛擬幣賬號：用戶和使用奇點奇豆的商戶都需要建立虛擬幣賬戶。

代扣賬號： 用來支持訂閱類型的定期代扣；

零錢賬號：即電商的內(nèi)部賬號，用戶、商戶、清算單位需要建立零錢賬戶

第三方支付賬號：用戶在第三方支付機構建立的賬戶。

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

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

代扣代繳賬戶：用來支持代扣稅款業(yè)務。

　　對這些賬戶，需要設置如下屬性： 基本屬性，包括：

賬戶號，或稱為賬戶ID，一般是系統(tǒng)自動生成。特別注意的是，要事先約定好賬戶ID的規(guī)則。比如頭三位用來表示賬戶類型，后幾位用來表示賬戶編號等。務必保證根據(jù)賬號號能夠快速確定賬戶類型，并且保證賬戶號是不重復的。

賬戶名稱，一般是由用戶自己設置的，顯示用。

賬戶使用的貨幣類型，注意雖然一張銀行卡可以支持多個幣種，實際在內(nèi)部，還是針對每個幣種建立獨立的子賬戶。 涉及到多幣種的賬戶，也可以采用類似的建模方案。

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

　　賬戶控制相關：

是否允許充值；

是否允許提現(xiàn)；

是否允許透支；

是否允許支付；

是否允許轉賬進入；

是否允許轉賬轉出；

是否有安全保障；

是否激活；

是否凍結。

　　資金相關：

當前賬戶余額：等于可用余額+凍結余額；

當前賬戶可用余額；

當前賬戶凍結的余額。凍結余額指在賬戶上暫不能使用的額度。在支付的時候，往往是先凍結，商品出庫后， 再實際執(zhí)行扣款。

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

第三方實體的ID；

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

第三方的app_id；

賬號的失效日期，該賬號什么時候失效。

　　注意，有些第三方信息是不能保存的，如用戶的賬號密碼、信用卡的CV號等。 為了避免賬戶信息被爬庫或者數(shù)據(jù)庫信息意外泄露，一般還需要對敏感字段，如密碼等，進行加密保存，甚至保存到另外的表中。 更進一步，為了避免賬戶信息被意外修改，還可以增加一個校驗字段，在寫入數(shù)據(jù)時設置該字段，在讀取數(shù)據(jù)時做校驗，一旦發(fā)現(xiàn)數(shù)據(jù)有問題，則關閉該賬號。

　　交易模型

　　交易記錄，交易流水，賬戶流水，交易臺賬，這三個容易混淆的概念，從數(shù)據(jù)上來說，卻并不復雜，它們的核心是交易流水，賬戶流水是從賬戶視角的交易流水。那對一筆交易，涉及到的方方面面內(nèi)容很多，有哪些需要記錄的呢？考慮到交易記錄將被用于風控和信用分析，能收集到的信息是越全面越好。

流水號：每一筆交易的流水號都不一樣。需要根據(jù)業(yè)務情況詳細設計流水號。這個號往往也是對交易表做分表分庫的依據(jù)。

交易記錄創(chuàng)建時間；

交易記錄最后修改時間；

會計科目代碼

關聯(lián)的訂單號，由商戶提供；

訂單名稱、描述、關聯(lián)的地址等信息；

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

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

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

交易渠道信息，記錄所使用的交易渠道的實體id，渠道賬戶，渠道執(zhí)行支付的時間、渠道側返回的訂單號等。如果有錯誤發(fā)生，還需要記錄從渠道接收到的錯誤信息和錯誤碼。

- - - - 廣 告 主 推 薦 - - - -

（稀缺廣告位預定進行中，詢 suipay）

　　可以說，對賬是支付系統(tǒng)最頭疼的事情。每一筆交易，都要做到各參與者的記錄能夠吻合，沒有偏差。對賬系統(tǒng)的工作，是發(fā)現(xiàn)有差異的記錄，即軋帳；然后通過人工或者自動的方式，解決這些差異，即平帳。

　　對電商系統(tǒng)來說，每一筆交易，在所有相關主體側都要能對得上：

交易主體，如果發(fā)起人是個人，必須能夠從個人交易歷史記錄中找到這筆交易。但大部分人不會保留電子記錄，所以一般是提供可以下載的賬單或交易記錄，讓用戶自己對去。

交易對手，一般是商戶。商戶側對賬處理同用戶側，也僅僅提供對賬單。

交易渠道側，這是對賬的重點，一是核實交易流水，二是核實交易傭金，畢竟是租用人家通道做結算的。

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

　　對賬處理流程

　　一般來說，對賬流程涉及到如下步驟： 渠道對賬單下載、本地交易記錄準備、軋賬、平賬。

　　渠道對賬單下載

　　銀行，第三方支付，銀聯(lián)等，基本都會提供對賬單下載的功能。不過也有少數(shù)工作做不到位或者太到位的銀行，只提供賬單查詢后臺，不提供對賬單下載功能。

　　對開發(fā)人員來說，這里有幾個坑：

對賬單格式不一。文本，XML，csv的都有。為了后續(xù)能夠統(tǒng)一處理，在賬單下載完成后，需要進行標準化處理。

下載方式不一，HTTP，HTTPS，F(xiàn)TP的，都有。下載程序需要按照渠道的協(xié)議來處理。

下載時間不一，一般是凌晨1點后，到中午12才能用的也有。如果在預定的時間取不到數(shù)據(jù)，需要注意重試讀取。

穩(wěn)定性差。FTP服務器出問題那是常有的事。渠道側解決方案往往就是重啟。所以重試機制是必要的。

　　看一下第三方支付的對賬單情況：

　　銀行直連的對賬情況：

　　技術選型上，HTTP(S)用apache httpclient即可實現(xiàn)鏈接池和斷點續(xù)傳， FTP也可以使用Apache Commons Net API。 但不管是哪一個，都需要設置重試次數(shù)和鏈接超時間。重試次數(shù)和間隔的設置需要小心，重試太頻繁，容易把服務器打死.；時間間隔太大，又會阻塞后續(xù)處理步驟。5～10分鐘是一個合適的重試間隔區(qū)間。

　　鏈接超時指在服務器出現(xiàn)問題時，連接在指定時間內(nèi)獲取不到數(shù)據(jù)即自動斷開。這個很容易被忽略。我們有一次系統(tǒng)出問題，是渠道側的FTP假死后重啟，導致我們的客戶端掛住，一直在等待重新鏈接。

　　渠道對賬單標準化

　　找個例子大家看看， 比如微信的對賬單，他是csv格式的，包括如下信息：

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

公眾賬號ID，商戶號,子商戶號,設備號： 這些信息需要做驗證，確保是自己的單子，不要讓微信把老王家的單子也給發(fā)過來了；

微信訂單號,商戶訂單號： 這兩個是對單的核心。前者是微信側產(chǎn)生的訂單號，在微信支付接口返回值中有。但是萬一收不到這個返回值，那在本地記錄中可能就空了。 后者是我們發(fā)送給微信的訂單號，一般用這個來做對單依據(jù)。兩邊的數(shù)據(jù)中都會有這個值。

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

商品名稱,商戶數(shù)據(jù)包,手續(xù)費,費率：這些是可選驗證。

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

　　由于每個渠道的賬單格式都不盡相同， 在得到賬單后，下一步是對賬單做標準化處理，這樣軋帳以及后續(xù)工作就可以統(tǒng)一處理了。 標準化后的賬單數(shù)據(jù)可以放在文件系統(tǒng)或者數(shù)據(jù)庫中。這取決于交易數(shù)據(jù)量。每天百萬以上的量，還是使用文件系統(tǒng)，比較合適。數(shù)據(jù)庫操作相對比較慢，也浪費資源。

　　基于文件系統(tǒng)的標準化涉及如下內(nèi)容：

文件格式標準化：統(tǒng)一使用csv或者json或者xml格式。如果是使用hadoop或者spark來對賬，使用csv是個不錯的選擇。

文件存儲統(tǒng)一化：文件目錄，文件名都需要遵循統(tǒng)一命名規(guī)范。

　　為了加快處理速度，我們使用hdfs作為文件系統(tǒng)，有利于后續(xù)的對賬的處理。

　　本地交易記錄準備

　　本地交易記錄的準備，總的來說有如下方法: – 啥都不做，直接用原始數(shù)據(jù)。鑒于大部分系統(tǒng)使用的是mysql，這也意味著在MySQL上做對賬。對賬時需要大量的數(shù)據(jù)查找工作，必然會影響線上業(yè)務。在數(shù)據(jù)規(guī)模較大，比如超過100萬時，就不太合適了。

當然，還有一個選擇是使用備庫來執(zhí)行對賬，這樣既簡單，也不影響線上業(yè)務。這是典型的空間換時間的做法。

如果業(yè)務大到需要分表分庫才能處理，那對賬數(shù)據(jù)準備也不一樣。使用分庫也不現(xiàn)實，因為分庫一般是按照主體id，而不是渠道id，來分庫，這樣對賬就需要在多個庫上進行，效率反而降低了。而對分表分庫建立從庫也非常耗費資源。這種情況下，需要同步一份數(shù)據(jù)到(hdfs)文件系統(tǒng)中，或者NOSQL數(shù)據(jù)庫上。

　　由于交易記錄是支付系統(tǒng)核心數(shù)據(jù)，有大量的應用，如信用、風控等，都需要交易記錄數(shù)據(jù)。這些應用對交易記錄的需求還不完全一致，為了提升性能， 交易記錄會使用異步的方式來將數(shù)據(jù)投遞給使用方。 交易記錄在入庫時，投遞消息到消息系統(tǒng)中。使用方監(jiān)聽這個消息，一旦收到新消息，則從交易記錄庫中查詢數(shù)據(jù)，獲取數(shù)據(jù)并更新到庫中。關于此類數(shù)據(jù)同步的文章不少，這里就不詳細介紹。

　　軋帳

　　軋帳是按照客戶訂單號來比較本地交易記錄和渠道交易記錄是否一致。從算法角度，是計算兩個數(shù)組的差異。在單機運行時，可以采用的算法不少，這里不詳細介紹。 我們推薦采用mapreduce來軋帳，這有個優(yōu)勢，可以按照訂單號將渠道提供的記錄和本地記錄shuffle到同一個reduce處理上，這樣就可以很容易進行數(shù)據(jù)比對。 軋帳中最大的坑，莫過于切分點的問題。

　　比如以整0點為切分點，那存在一個問題，本地23:59發(fā)起的交易，到了渠道側，可能會在00:01處理，這一筆交易變成第二天的帳了。實際處理中，一筆交易在渠道側處理，花上幾分鐘都有可能。 對于切分點附近無法確認的帳，做一個時間窗，在時間窗內(nèi)的數(shù)據(jù)，留待第二天對賬時繼續(xù)處理。

　　平帳

　　發(fā)現(xiàn)兩邊不一致的數(shù)據(jù)，那應該如何處理？數(shù)據(jù)量不大時，記錄起來，人工甄別就行。但如果數(shù)據(jù)量很大，每天上千條，人工處理就成本太高了。這個沒有統(tǒng)一的處理方法，需要根據(jù)有問題的數(shù)據(jù)，做個分析，然后做自動處理。 針對交易記錄的對賬的處理，主要有如下情況：

本地未支付，支付渠道已支付。這主要是本地未正確接收到渠道下發(fā)的異步通知導致。 一般處理是將本地狀態(tài)修改為已支付，并做響應的后續(xù)處理，比如通知業(yè)務方等。

本地已支付，支付渠道已支付，但是金額不同，這個需要人工核查。

本地已支付，但是支付渠道中無記錄；或者本地無記錄，支付渠道有記錄。在排除跨日因素外，這種情況非常少見，需要了解具體原因后做處理。

　　針對退款的對賬處理，主要有如下情況：

本地未退款，支付渠道已退款，則以支付渠道為準，修改本地為已退款狀態(tài)，并出發(fā)后續(xù)處理。

本地已退款、支付渠道已退款，但是金額不同，需要人工核查；

本地已退款，但是支付渠道無記錄；或者支付渠道有記錄，但是本地沒有。 在排除跨日因素外， 這種情況非常少見，需要了解具體原因后做處理。

　　總之，對賬工作，即復雜也不復雜。需要細心，對業(yè)務要有深入的了解，并選擇合適的架構。

　　這一期，回到支付系統(tǒng)的核心業(yè)務，即支付。每個電商公司的支付系統(tǒng)都已經(jīng)或多或少的實現(xiàn)了交易核心功能，可也都是一直在改進，總是不斷的有新的需求冒出來。所以這一期開始，我們梳理一下：到底有哪些支付方式？每種支付方式都是怎么運作的？

　　支付和交易

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

　　銀行卡支付

　　先說大家比較熟悉的銀行卡支付，它分為線上支付和線下支付兩種形式。線下支付就是通常說的POS收單，這里不介紹這個內(nèi)容。對線上支付，按照卡的類別，分為貸記卡支付，也叫motopay、ePOS，即信用卡支付；和借記卡支付。按照支付形態(tài)，又分為認證支付、網(wǎng)銀支付、快捷支付幾種形態(tài)。銀行卡網(wǎng)銀支付要求銀行卡必須開通在線支付功能，而快捷支付并不需要開通在線支付功能。主要利用支付驗證要素（卡號、密碼、手機號、CVN2、CVV2等），結合安全認證（例如短信驗證碼），讓持卡人完成互聯(lián)網(wǎng)支付。

　　認證支付

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

　　快捷支付

　　快捷支付和認證支付類似，不同點在于綁卡之后，有些銀行接口會返回token，后續(xù)使用token來作為支付憑證，無需提供卡號信息，這樣電商也不需要本地保留卡號了。目前主要是銀聯(lián)有提供token接口。

　　網(wǎng)銀支付

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

　　支付流程

　　走一個具體的例子看看吧。比如用戶在電商系統(tǒng)中買了200塊錢的東西，然后通過浦發(fā)銀行卡做結算，用的是快捷支付。這個過程是：

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

　　用戶被引導到收銀臺頁面， 讓用戶確認交易金額，選擇支付方式，調(diào)用支付系統(tǒng)接口。

　　支付系統(tǒng)接收到支付請求，驗證請求的各個字段是否有問題，確認無誤后，調(diào)用支付網(wǎng)關執(zhí)行支付。

　　支付網(wǎng)關請求浦發(fā)銀行的快捷支付接口執(zhí)行支付。

　　支付網(wǎng)關接收到支付結果報文后，對結果報文做解析，獲取結果，并將結果告知交易系統(tǒng)。這可以通過URL或者RPC調(diào)用來實現(xiàn)。

　　商城系統(tǒng)收到支付結果后，開始執(zhí)行后續(xù)操作。如果是支付成功，則開始準備出庫。這一步在交易系統(tǒng)中處理，這里不做介紹。

　　網(wǎng)銀支付，和快捷相比，就在第4步，插入一個步驟，將用戶導航到網(wǎng)銀頁面輸入支付信息，后續(xù)步驟是一樣的。在資金流上也是相同的。 而在第五步獲取返回結果上，一般銀行就直接同步返回，銀聯(lián)是分為同步和異步返回。同步告知操作成功或者失敗，異步告知扣款成功或者失敗。同步操作和異步操作都需要調(diào)用方提供一個回調(diào)的URL地址，銀聯(lián)會將參數(shù)附加在這個地址上。通過解析這些參數(shù)可以得到執(zhí)行結果。異步操作一般有2-3秒的延遲，取決于網(wǎng)絡，以及該交易處理的復雜度。

　　資金流

　　上一節(jié)說的是支付的信息流，那資金流應該是怎么走的？ 在第三步，會觸發(fā)資金流。資金從用戶個人賬戶上轉移到電商公司的賬戶。當然，銀行也不是活雷鋒，這一筆交易是要收手續(xù)費的。資金是實時到賬的，手續(xù)費一般是按月結算。有按交易筆數(shù)計費的，但大部分還是按照交易金額來收費。

　　同行快捷支付是比較簡單的場景，讓我們來逐步增加難度。如果支付系統(tǒng)沒有對接浦發(fā)銀行，那對浦發(fā)卡，就得走其它支付方式：銀聯(lián)或者第三方支付。

　　先說銀聯(lián)快捷。銀聯(lián)提供的多種接入方式，常說的快捷支付，在銀聯(lián)文檔中叫商戶側開通token接口。通過這個接口，可以實現(xiàn)同行和跨行資金結算。不管收款行是浦發(fā)還是其它行，都可以完成結算。對本地和用戶來說，體驗是一樣的。而在銀聯(lián)側，后臺資金流處理卻不一樣。了解這個資金流，有助于在異常情況下，了解資金到底跑到哪里了。

　　如果收款行也是浦發(fā)銀行，銀聯(lián)發(fā)報文給浦發(fā)，浦發(fā)使用內(nèi)部系統(tǒng)完成兩個賬戶間的轉帳，即時完成。

　　如果收款行是他行，比如工行。銀聯(lián)發(fā)指令給浦發(fā)和工行，分別完成各自賬戶上資金余額的增減，對個人和電商來說，這筆資金算是落地了。但實際資金流并不是立即發(fā)生。銀聯(lián)會在半夜做清結算后處理這筆資金。這個過程就是金融機構之間的清結算了，一般不需要關注。

　　如果使用的是第三方支付，對用戶來說，處理的流程和銀聯(lián)一樣。但資金流會不一樣。 第三方支付在浦發(fā)和工行一般都會有落地的托管資金。 發(fā)生交易后，一般來說不會產(chǎn)生跨行資金流動。用戶在浦發(fā)行的錢會被結算到第三方支付在浦發(fā)行的托管賬戶，而在工行的錢，會由第三方支付在工行的賬戶打到客戶賬戶上。 這就降低了跨行資金流動成本。

　　目前國內(nèi)主要銀行都提供快捷和直聯(lián)的接口。對電商來說，要對接哪些銀行是個需要考慮的問題。怎么對接銀行，渠道和第三方支付。

銀聯(lián)Token支付

　　一般來說，大部分銀行都提供直聯(lián)和網(wǎng)銀接口，但不需要直接對接所有銀行。銀聯(lián)和第三方支付也提供直聯(lián)接口，可以直接對接國內(nèi)主要銀行。也不是所有銀行都被銀聯(lián)支持，這和銀聯(lián)簽約的接口有關，需要在對接時咨詢銀聯(lián)。從我們使用情況看， 浦發(fā)借記卡、郵儲銀行卡是不支持的。 另外 交行、平安（含原深發(fā)）、上海銀行、浦發(fā)、北京銀行，上述銀行卡需通過 這個地址 開通銀聯(lián)在線支付業(yè)務。

　　對接銀行

　　大部分銀行提供的銀行卡支付接口，借記卡支付和貸記卡支付是不一樣的。但也有幾個好心的銀行，可以用一套接口同時開通借記卡和貸記卡。點名贊一下這些銀行： 宇宙第一大行工商銀行和建設銀行。其他同學對接中如果也發(fā)現(xiàn)借記卡和貸記卡用一個接口的，也請及時告知。 作為國內(nèi)最保守的軟件團隊，和銀行對接時務必做好足夠的準備。在商務談判完成、拿到銀行的接口文檔后，需要考慮兩個問題：專線問題、加密問題。

　　專線問題

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

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

專線接入點：目前國內(nèi)主要是聯(lián)通、電信。

封裝類型： HDLC或者PPP

專線代寬：默認是2M

　　前置機IP，這個需要在銀行側和電商側進行配置。 專線其實是在銀行和電商之間建立一個局域網(wǎng)，需要雙方分配通訊IP。 其實這兩組IP都是NAT后的IP，銀行分配給我們的是電商真實的前置機IP經(jīng)過最外端的網(wǎng)絡防火墻轉換后的IP段，后者也是對方的真實前置機IP經(jīng)過轉換后的IP段。 出于安全考慮，雙方都不會將真實IP暴露出去，所以要NAT。

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

　　這些專業(yè)名詞，可以自己檢索，太專業(yè)了，其實我也不懂。從可靠性角度考慮，一般建議從聯(lián)通、電信各拉一條線路出來。一旦有一個線路出問題了，也不會導致所有交易被終止了。不需要專線的銀行接口有：浦發(fā)、工行、交行信用卡等。 需要專線的有中行、農(nóng)行、建行等。一般專線需要1個月左右的時間，包括銀行側的申請、施工時間。

　　加密問題

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

MAC加密（完整性）；

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

密鑰交換加密（防截?。?。

　　對開發(fā)來說，加密機的主要作用，是讓黑客都無法從內(nèi)存中看到密碼。 不是做廣告，國內(nèi)對接銀行一般就用江南天安的加密機了

　　對接銀聯(lián)

　　對接銀聯(lián)比對接銀行簡單， 不需要專線，不需要加密機。 不過需要獲取ADSS認證。 銀聯(lián)最近在推Token接口，有兩套接口，一套是銀聯(lián)側開通，一套是商戶側開通。前者類似網(wǎng)銀支付，后者類似快捷支付。 務必要求接入后者接口啊?；旧献x完接口文檔就知道怎么寫代碼了。

　　在上一篇 支付系統(tǒng)之銀行卡支付中，挖了個坑，就是關于綁卡的坑。 在用戶使用銀行卡做支付之前，首先需要完成綁卡的操作。怎么實現(xiàn)綁卡，怎么驗證用戶綁的是自己的而不是隔壁老王的卡，這就是本期的重點。

　　為什么要求用戶綁卡？這和快捷支付有關。參見上一篇文章的分析，綁卡是將用戶卡信息提供給電商，以后電商就用這個信息去銀行完成支付。綁卡實際上是一個授權，讓用戶允許商家自動從他的賬戶上扣除資金。所以綁卡也叫簽約，用戶和銀行，商家的三方簽訂的支付合約。 但我們知道，綁卡對用戶和商戶來說都存在巨大風險。

　　如果說用戶綁卡是圖省事，那商戶為什么要做這個事？首先當然是提升用戶體驗了，讓用戶花錢更容易。其次，提升支付成功率。使用網(wǎng)銀支付成功率在20%左右，銀聯(lián)直聯(lián)成功率一般在50%左右，銀行卡直聯(lián)可以提升到70%左右。這是相當可觀的數(shù)據(jù)。所以，當你看到綁卡送洗衣粉之類做法時，不需要擔心商家會不會賠本。

　　怎么綁卡？我們知道對接銀行有兩種途徑，直接對接銀行接口和通過銀聯(lián)來間接對接。這兩種情況下綁卡處理也不同。

　　綁卡場景

　　直觀的，電商網(wǎng)站會在用戶后臺提供一個綁卡的入口，讓用戶直接綁卡。以支付寶綁卡流程為例，我們可以體驗下：

　　這里有如下要點：

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

需要用戶在銀行側預留的手機號進行短信驗證。但不是所有銀行都需要。這個時候，為了統(tǒng)一處理，可以考慮自己發(fā)驗證短信。

　　對這個入口不要指望太多，更多的用戶是在支付中綁卡。也就是提交訂單后，發(fā)現(xiàn)沒有銀行卡了，就開始綁卡。 和純綁卡流程不同的是，最后一步，綁卡成功后，一般都同時完成支付。有些渠道會提供綁卡并支付的接口，減少交互次數(shù)。

　　綁卡流程

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

用戶必須已經(jīng)綁定了手機號。該手機號用于修改支付密碼；

用戶需設置了支付密碼。支付密碼不同于登錄密碼。

　　針對用戶不同狀態(tài)，綁卡流程上有區(qū)別。當然，綁卡是安全操作，要求用戶必須登錄到系統(tǒng)中。為了避免和服務器端的交互被劫持，所有操作必須在安全鏈接中進行，即使用https。當用戶開始綁卡時，執(zhí)行如下流程：

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

檢查用戶是否設置支付密碼。如果已經(jīng)設置，則需要用戶輸入密碼。確認后開始綁卡。否則，也是先進去綁卡后設置密碼。

用戶輸入卡號，系統(tǒng)根據(jù)卡號判斷卡的發(fā)卡行，并顯示給用戶。有些實現(xiàn)，如微信支付，會提供掃卡識碼功能。

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

調(diào)用銀行綁卡驗證接口進行綁卡。這里有一個四要素驗證的概念。由于國內(nèi)要求實名制，所有銀行卡都是實名辦理的，所以銀行可以驗證姓名，身份證號，銀行卡號和手機號是不是一致的，如果沒問題，則會發(fā)短信到手機上。

用戶輸入短信驗證碼并確認綁卡，服務器端將用戶實名信息以及短信驗證碼組合形成報文，發(fā)送給銀行，執(zhí)行簽約操作。銀行側簽約成功后，返回簽約號給商戶。

卡bin

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

　　目前，國內(nèi)的 銀行卡 按照數(shù)字打頭的不同分別歸屬于不同的銀行卡組織，其中以BIN號“4”字打頭的銀行卡屬于VISA卡組織，以“5”字打頭的屬于MASTERCARD卡組織，以“9”字和“62”、“60”打頭的屬于中國銀聯(lián)，而“62”、“60”打頭的銀聯(lián)卡是符合國際標準的銀聯(lián) 標準卡 ，可以在國外使用，這也是中國銀聯(lián)近幾年來主要發(fā)行的銀行卡片。 大部分銀行卡號前6位即可確定發(fā)卡行和卡類型，但也有非標卡需要6-10位才可以判斷出來。需要維護一個卡bin庫。附件是一個比較完整的卡bin庫， csv格式的。

　　短信和身份驗證

　　一般綁卡操作第五步需要銀行下發(fā)短信驗證碼。 短信驗證的接口，不同銀行還不一樣。有些銀行是短信和身份驗證一起做了；有些銀行是可以配置身份驗證是否同時發(fā)短信。還有些比較奇葩的機構，比如某聯(lián)，接口中讓你傳身份信息，但實際上沒傳也是可以的，也不驗證身份信息到底對不對。這在對接渠道時需要特別注意。

　　此類接口一般包含如下內(nèi)容：

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

編碼方式： 默認都是UTF-8，指傳輸?shù)膬?nèi)容的編碼方式；

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

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

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

商戶訂單號：即發(fā)送給渠道的訂單號；

發(fā)送時間：該請求送出的時間。

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

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

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

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

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

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

　　系統(tǒng)會返回上述數(shù)據(jù)的驗證結果。如果驗證通過，則會發(fā)短信。但這不是所有的渠道都是這樣。哪些字段會參與驗證、需不需要發(fā)短信，需要注意看接口文檔。

　　綁卡接口

　　綁卡接口和發(fā)短信接口類似，還需要將用戶的卡號，身份證等信息傳遞過去。在綁卡成功后，會返回一個簽約號。這個簽約號是后續(xù)調(diào)用支付，解約等接口所必須的。 這里有個問題，已經(jīng)綁卡的用戶，調(diào)用綁卡簽約接口再綁一次，會出現(xiàn)什么情況？這個和銀行實現(xiàn)有關。 大部分銀行，如農(nóng)業(yè)、浦發(fā)、建行等，對綁卡簽約接口調(diào)用，會首先驗證身份信息，如果驗證不通過，則不執(zhí)行后續(xù)操作。驗證通過后，再檢查這個卡在該商戶下是否已經(jīng)綁過了， 如果沒有綁過，則執(zhí)行綁卡，否則會提示卡已經(jīng)綁定過了，不能重復簽約。 但工行的實現(xiàn)不一樣，他是首先驗證這個卡是不是已經(jīng)綁過了，如果已經(jīng)綁卡，則不繼續(xù)驗證身份信息。 總之，銀行都不支持重復綁卡。

　　銀聯(lián)綁卡

　　銀聯(lián)直聯(lián)綁卡和銀行綁卡類似，但是得注意驗證接口，僅驗證卡號和姓名，不驗證身份證號和手機號。這導致第5步無法正常進行。銀聯(lián)只有到第六步執(zhí)行綁卡時才做身份驗證。 所以在處理上，還需要做一些調(diào)整，來確保和銀行的流程的一致。 一種處理方法是，對銀聯(lián)，在第五步就開始調(diào)用銀聯(lián)接口執(zhí)行綁卡操作，但是在本地標記為預綁卡狀態(tài)；商戶側發(fā)送短信驗證碼，驗證通過后，才將狀態(tài)設置為綁卡成功。

　　銀聯(lián)網(wǎng)銀綁卡處理起來比較麻煩。用戶在電商頁面上輸入卡號，然后被導航到銀聯(lián)頁面上去完成綁卡操作，成功后，銀聯(lián)返回一個token作為簽約號，用于支持后續(xù)操作。這問題就來了，用戶可以在銀聯(lián)頁面上綁定一個別人的卡，而電商側是無法知道這個卡的情況的。所以這種方式盡量不要用。

　　實名認證

　　綁卡操作有個不錯的副產(chǎn)品，就是實名認證。常說的二要素，三要素，四要素認證，可以通過這個操作完成。 二要素指姓名和身份證號，三要素加上銀行卡號，四要素則加上手機號?？雌饋恚坪蹉y行都應該支持四要素驗證，但大部分銀行接口僅支持三要素，畢竟手機號還是非常容易變。 當然，實名認證，也就是二要素認證，是應用最多的認證了。國內(nèi)唯一的庫是在公安部這，由NCIIC負責對外提供接口?？梢蕴峁┤缦鹿δ埽?/p>

簡項核查：返回“一致”“不一致”“庫中無此號”

返照核查：返回“一致+網(wǎng)紋照片”“不一致”“庫中無此號”

人像核查：返回“同一人”“不同人”“庫中無此號”

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

　　當然，這里也要注意，涉密人員是沒法查到相關信息的。 性能上， XX通一般在200ms內(nèi)即可返回結果，普通商用應該是沒問題的。 有些公司還會額外提供四要素接口，以XX通為例，它號稱支持大部分銀行卡的四要素認證。但是實現(xiàn)上有點兒懵，居然是實時請求銀行的接口，這就導致接口延遲非常高，1秒以上的占大部分，甚至10秒以上的都不少見，基本無法商用。這種情況下，還不如直接上銀聯(lián)。

　　應用內(nèi)支付指使用手機操作系統(tǒng)自帶的支付功能來支持支付。目前國內(nèi)主要的應用內(nèi)支付有 Google Pay、Apple Pay、小米支付、華為支付等。 其中Apple Pay是典型的一個應用內(nèi)支付，Android平臺的各種支付也一般是沿用Apple Pay的設計。

　　為什么要IAP

　　相對來說，應用內(nèi)支付的用戶體驗，和微信支付、支付寶相比，還是有一定差距的，但是為什么要開發(fā)應用內(nèi)支付呢？ 這個和蘋果的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 內(nèi)使用非 IAP 的系統(tǒng)來購買內(nèi)容、功能或服務將被拒絕。

　　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 內(nèi)使用。

　　這問題就來了，如果要購買的服務，即在IOS內(nèi)使用，也在Android等IOS系統(tǒng)外使用， 那應該是使用規(guī)則11.2或者規(guī)則11.3來執(zhí)行？ 比如說視頻網(wǎng)站，視頻既可以在IOS上看，也可以在Android上看，那是否是需要通過IAP來購買？ 蘋果公司在這一點上采取模糊的策略。 愛奇藝、騰訊視頻，在IOS上購買會員，只能用IAP支付。這就和蘋果公司的審核有關。

　　IAP支付流程

　　一般IAP支付的開發(fā)流程，首先需要一些準備工作，包括：

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

登錄到iTunes Connect，使用App ID創(chuàng)建一個新的應用，在該應用中，創(chuàng)建應用內(nèi)付費項目，設置好價格和Product ID以及購買介紹和截圖。

添加一個用于在sandbox付費的測試用戶，填寫相關的稅務，銀行，聯(lián)系人信息。

　　完成這些準備工作后，既可以進入正式的開發(fā)，開發(fā)代碼我們這里就不說了，流程如下：

用戶選擇要購買的內(nèi)容并點擊購買按鈕；

用戶通過App Store賬戶驗證

蘋果服務器驗證用戶請求

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

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

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

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

　　用戶訪問AppStore時使用的是Apple的賬號，不是應用系統(tǒng)的賬號。 也就是說，我們并不知道到底是誰在購買這個內(nèi)容。 比如在應用中有兩個賬號A和B，用A賬號登錄后，上IAP買了東西，然后用B賬號來登錄，也上IAP買東西， 這兩次購買，用的是同一個Apple賬號。蘋果也不會告訴你，到底是哪個賬號付了錢。 賬號坑在單次購買中還沒什么問題，但碰到訂閱的情況，得好好處理下。在訂閱章節(jié)中會詳細說明。從上述流程可以看出，蘋果服務器都是和客戶端打交道的，這里面似乎沒有應用服務器什么事情。 只有在客戶端接收到蘋果返回信息后，才可以把這個信息轉發(fā)給應用服務器。 如果用戶一直不打開手機上的應用，那應用服務器就一直收不到通知了。 好在后來蘋果提供了一個驗證功能，應用服務器可以把接收到的返回信息（加密后的字符串）發(fā)送給蘋果服務器來驗證和解密。

　　IAP訂閱

　　IAP Subion又是一個大坑。 官方的文檔在這里。內(nèi)容不多，沒有說明的東西卻很多。

　　續(xù)費周期的計算

　　IAP主要提供給周期性訂閱的音樂、電子書等內(nèi)容使用。 一般就按月來計算周期。蘋果是以自然月來算權益周期。比如在1月3號買了權益，到2月3號，這個權益就過期啦，需要在此之前完成續(xù)費。 那問題來了，1月31號買的權益，到幾號過期？以自然月算，這個權益會在3月1日前到期，如果2月份，3月份都續(xù)費了，到4月份，也是享受到4月30日了。

　　自動續(xù)費

　　應用開發(fā)應該不需要關心續(xù)費的細節(jié)。蘋果會做自動處理。在權益到期前10天，蘋果檢查用戶賬戶是否可以扣款，商品價格是否有變動。在權益到期前24小時，蘋果開始扣款，如果失敗，會多次重試，直到成功。問題來了，這個重試，會延續(xù)到用戶權益過期后一小段時間，蘋果沒有說這段時間該算是有權益還是沒有，但開發(fā)人員需要注意應該如何處理。

　　免費試用

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

　　Receipt 驗證

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

　　IAP破解和防御

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

　　transactionState 有四個狀態(tài)：

SKPaymentTransactionStatePurchasing

SKPaymentTransactionStatePurchased

SKPaymentTransactionStateFailed

SKPaymentTransactionStateRestored

　　SKPaymentTransactionStatePurchased 表示購買成功了。 只要修改這個變量值，如果客戶端應用直接根據(jù)交易狀態(tài)來處理業(yè)務流程，那就會收到這個假的交易成功信息，接下來用戶就能不花錢得到所買的物品。這個過程，甚至都不需要接入網(wǎng)絡。

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

　　兩套賬戶體系

　　蘋果支付的賬戶體系,當然是以apple id為基礎的，它允許用戶在多臺設備上共用一個賬戶。一臺設備上，一般只有一個激活賬戶。但對應用系統(tǒng)來說，大部分是允許多個賬號登陸的。這對續(xù)費來說就是個大問題。 用戶以賬戶a登錄后，發(fā)起續(xù)費，獲得權益。然后以賬號B登錄了，顯然，A的權益不會衍生給B。過幾天A開始續(xù)費了，續(xù)費之后，切換到B賬號登錄，客戶端在B賬號登錄時得到續(xù)費的收據(jù)并發(fā)送給應用服務器。那這算是誰的續(xù)費請求？當然是A的。在這個apple id發(fā)起的續(xù)費請求，所有的收據(jù)都會有一個相同的原始交易號original transaction Id。在用戶發(fā)起訂閱時，需要記錄這個id和賬號的關系，每次續(xù)費，需要在解析收據(jù)后，根據(jù)原始交易號從這里獲取真正的充值賬戶，不能從客戶端提交的用戶id作為憑據(jù)。

　　還是這個坑，如果在賬戶b登錄后也發(fā)起訂閱請求，會怎么樣？這個調(diào)用將會失敗，所以需要阻止用戶發(fā)起這樣的請求。或者設置多個產(chǎn)品副本來讓用戶購買。

　　分成，定價和國際化

　　在iTunes中的給的產(chǎn)品定價必須是稅前的，蘋果和商家的分成，也是按稅前算。商家給出在一個主要銷售國家和地區(qū)（比如國內(nèi)的基本就是中國了）的價格，即基準價格。在其他地區(qū)的銷售價格，蘋果會自動根據(jù)當前的匯率來換算成當?shù)氐呢泿?。當然，也可以自己修改設定在這些國家或者地區(qū)的當?shù)貎r格。目前是支持到155個國家。還要特別注意版權問題。

　　基準價格調(diào)整，如果是往高了調(diào)整， 則在用戶下一次續(xù)費時，需要用戶確認。如果往低了調(diào)，那就不需要用戶確認，直接扣款了。

　　蘋果對商家的產(chǎn)品價格體系有分組（Group）的概念，同國內(nèi)說的價格體系，比如白金會員、黃金會員、貴賓等，在同一個Group里面，用戶只能選擇一個檔，比如用戶要么是白金要么是黃金會員，不會同時是。

　　在同一個分組中，如果用戶訂閱時間超過一年（365天），則商家可以得到來自這個用戶收益的更多的分成，目前是85%。這個訂閱時間不包括免費試用期。 同時可以有60天的寬限。也就是說，這一年中，如果用戶曾經(jīng)停止續(xù)費，然后又開始繼續(xù)續(xù)費，只要中間不續(xù)費的時間不超過60天就行。

　　更多的坑

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

沙盒環(huán)境，沒法做取消訂閱操作。 只能在線上模擬。 所以產(chǎn)品設計和開發(fā)時，盡量不要依賴取消訂閱操作，也應該不依賴于這個操作。

沙盒環(huán)境下，有些receipt可能會收不到transaction id，線上的暫未發(fā)現(xiàn)這個問題。

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

Android IAP

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

　　- - - - - - - - - -

　　鳳凰牌老熊，程序員 & 架構師，來自中科大的本科，研究生在軟件所學習。先后在中科輔龍、三星（中國）研究院和國內(nèi)一些大型的互聯(lián)網(wǎng)公司呆過。在中科輔龍公司負責電子政務內(nèi)容管理系統(tǒng)建設，負責研發(fā)龍馭系列產(chǎn)品的研發(fā)，這款產(chǎn)品最終實施到2000多個電子政務網(wǎng)站上，期間也參與了一些支付反洗錢以及支付系統(tǒng)的建設。之后在三星中國研究院，負責自然語言處理（NLP）以及智能家居相關項目。智能家居項目在2014CES消費電子展上作為三星重點項目推介。2014年開始加入愛奇藝公司，負責數(shù)據(jù)倉庫和支付系統(tǒng)的建設。

　　責編丨陳晨（微信zfzjcc）

　　鳳凰牌老熊（ID：shamphone）

　　拓展閱讀

　　今起，第三方支付再也無法任性局域網(wǎng)ip分配規(guī)則！

　　銀聯(lián)0.38%費率的真相，你究竟知道多少？

　　你說我涉嫌二清，那我就想辦法搞一張支付牌照好了……

　　版權聲明

　　未經(jīng)許可，禁止轉載、摘編、復制及建立鏡像等任何使用。如需轉載，請通過本號后臺申請并獲得授權，歡迎轉發(fā)朋友圈。（商務合作請加suipay）。