早茶

快訊

精選

智庫(kù)

專欄

鳳凰牌老熊（ID：shamphone）

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

　　支付賬戶和登錄賬號(hào)

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

　　賬戶的設(shè)計(jì)需求

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

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

記賬的需求，按照公司會(huì)計(jì)需求記錄賬戶上的所有行為，包括支出、充值、轉(zhuǎn)賬等。

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

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

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

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

　　交易與賬戶

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

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

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

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

　　記賬與賬戶

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

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

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

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

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

　　收款賬戶和收單賬戶

　　當(dāng)電商要對(duì)接銀行時(shí)，往往都會(huì)被要求開(kāi)設(shè)一個(gè)收款賬戶。用戶通過(guò)這個(gè)銀行來(lái)支付時(shí)，錢就被轉(zhuǎn)到這個(gè)賬戶上。 對(duì)第三方支付也是一樣。收款賬戶是開(kāi)設(shè)在銀行或者第三方支付這邊的， 即渠道側(cè)。 一般來(lái)說(shuō)，渠道每天都可以提供這個(gè)賬戶的交易流水供電商對(duì)賬用。 這樣在電商這邊，渠道就成為一個(gè)收單機(jī)構(gòu)。 所以在電商這邊，建立這個(gè)收款賬戶對(duì)應(yīng)的對(duì)賬用的收單賬號(hào)，用來(lái)記錄通過(guò)這個(gè)渠道進(jìn)行的各項(xiàng)交易流水。

　　賬戶建模

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

　　實(shí)體模型

　　實(shí)體模型和用戶、商戶模型有重疊的地方，這里專門針對(duì)支付而設(shè)置的各個(gè)實(shí)體屬性。 一般來(lái)說(shuō)，支付相關(guān)的實(shí)體模型需要包括如下的屬性：

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

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

支付密碼；

用于設(shè)置或者重置支付密碼的手機(jī)號(hào)；

用戶設(shè)置或者重置支付密碼的郵箱；

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

賬戶模型

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

虛擬幣賬號(hào)：用戶和使用奇點(diǎn)奇豆的商戶都需要建立虛擬幣賬戶。

代扣賬號(hào)： 用來(lái)支持訂閱類型的定期代扣；

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

第三方支付賬號(hào)：用戶在第三方支付機(jī)構(gòu)建立的賬戶。

銀行卡賬號(hào)：用戶的銀行卡信息，每個(gè)卡對(duì)應(yīng)一個(gè)賬戶。

結(jié)算賬號(hào)：用來(lái)支持和第三方支付公司、銀行進(jìn)行結(jié)算用。 第三方支付需要為每個(gè)商戶號(hào)建立結(jié)算賬號(hào)；銀行需要為借記卡、貸記卡分別建立結(jié)算賬號(hào)（有必要嗎？銀行卡直連時(shí)使用）。

代扣代繳賬戶：用來(lái)支持代扣稅款業(yè)務(wù)。

　　對(duì)這些賬戶，需要設(shè)置如下屬性： 基本屬性，包括：

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

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

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

會(huì)計(jì)科目代碼，一般是一級(jí)會(huì)計(jì)科目的代碼。

　　賬戶控制相關(guān)：

是否允許充值；

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

是否允許透支；

是否允許支付；

是否允許轉(zhuǎn)賬進(jìn)入；

是否允許轉(zhuǎn)賬轉(zhuǎn)出；

是否有安全保障；

是否激活；

是否凍結(jié)。

　　資金相關(guān)：

當(dāng)前賬戶余額：等于可用余額+凍結(jié)余額；

當(dāng)前賬戶可用余額；

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

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

第三方實(shí)體的ID；

第三方賬號(hào)，如銀行卡號(hào)或者在第三方支付的open_id等；

第三方的app_id；

賬號(hào)的失效日期，該賬號(hào)什么時(shí)候失效。

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

　　交易模型

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

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

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

交易記錄最后修改時(shí)間；

會(huì)計(jì)科目代碼

關(guān)聯(lián)的訂單號(hào)，由商戶提供；

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

費(fèi)用信息，包括： 結(jié)算貨幣類型、原始費(fèi)用、實(shí)際費(fèi)用等；

交易主體信息，記錄主體ID、類型、名字、賬號(hào)、賬號(hào)類型、使用的IP地址、手機(jī)號(hào)、平臺(tái)、通知郵箱、當(dāng)前位置等。 這些信息雖然可以從主體表中獲取，但考慮主體表信息隨時(shí)會(huì)被修改，所以這里需要記錄詳細(xì)的各原始信息。

交易對(duì)手信息，記錄對(duì)手主體的ID，類型，名字，賬號(hào)，賬號(hào)類型，手機(jī)號(hào)，平臺(tái)，通知郵箱等。

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

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

（稀缺廣告位預(yù)定進(jìn)行中，詢 suipay）

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

　　對(duì)電商系統(tǒng)來(lái)說(shuō)，每一筆交易，在所有相關(guān)主體側(cè)都要能對(duì)得上：

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

交易對(duì)手，一般是商戶。商戶側(cè)對(duì)賬處理同用戶側(cè)，也僅僅提供對(duì)賬單。

交易渠道側(cè)，這是對(duì)賬的重點(diǎn)，一是核實(shí)交易流水，二是核實(shí)交易傭金，畢竟是租用人家通道做結(jié)算的。

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

　　對(duì)賬處理流程

　　一般來(lái)說(shuō)，對(duì)賬流程涉及到如下步驟： 渠道對(duì)賬單下載、本地交易記錄準(zhǔn)備、軋賬、平賬。

　　渠道對(duì)賬單下載

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

　　對(duì)開(kāi)發(fā)人員來(lái)說(shuō)，這里有幾個(gè)坑：

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

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

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

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

　　看一下第三方支付的對(duì)賬單情況：

　　銀行直連的對(duì)賬情況：

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

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

　　渠道對(duì)賬單標(biāo)準(zhǔn)化

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

交易時(shí)間：這是在微信側(cè)的支付完成的時(shí)間。 這個(gè)時(shí)間會(huì)成為一個(gè)陷阱。

公眾賬號(hào)ID，商戶號(hào),子商戶號(hào),設(shè)備號(hào)： 這些信息需要做驗(yàn)證，確保是自己的單子，不要讓微信把老王家的單子也給發(fā)過(guò)來(lái)了；

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

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

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

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

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

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

文件格式標(biāo)準(zhǔn)化：統(tǒng)一使用csv或者json或者xml格式。如果是使用hadoop或者spark來(lái)對(duì)賬，使用csv是個(gè)不錯(cuò)的選擇。

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

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

　　本地交易記錄準(zhǔn)備

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

當(dāng)然，還有一個(gè)選擇是使用備庫(kù)來(lái)執(zhí)行對(duì)賬，這樣既簡(jiǎn)單，也不影響線上業(yè)務(wù)。這是典型的空間換時(shí)間的做法。

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

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

　　軋帳

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

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

　　平帳

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

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

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

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

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

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

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

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

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

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

　　支付和交易

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

　　銀行卡支付

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

　　認(rèn)證支付

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

　　快捷支付

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

　　網(wǎng)銀支付

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

　　支付流程

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

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

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

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

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

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

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

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

　　資金流

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

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

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

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

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

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

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

銀聯(lián)Token支付

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

　　對(duì)接銀行

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

　　專線問(wèn)題

　　首先是專線問(wèn)題。 大部分銀行對(duì)接是需要專線的。 與銀行溝通的時(shí)候，注意收集如下信息：

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

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

封裝類型： HDLC或者PPP

專線代寬：默認(rèn)是2M

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

　　接入地址：即電商這邊機(jī)房的地址。

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

　　加密問(wèn)題

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

MAC加密（完整性）；

支付會(huì)話密碼加密（安全性）；

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

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

　　對(duì)接銀聯(lián)

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

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

　　為什么要求用戶綁卡？這和快捷支付有關(guān)。參見(jiàn)上一篇文章的分析，綁卡是將用戶卡信息提供給電商，以后電商就用這個(gè)信息去銀行完成支付。綁卡實(shí)際上是一個(gè)授權(quán)，讓用戶允許商家自動(dòng)從他的賬戶上扣除資金。所以綁卡也叫簽約，用戶和銀行，商家的三方簽訂的支付合約。 但我們知道，綁卡對(duì)用戶和商戶來(lái)說(shuō)都存在巨大風(fēng)險(xiǎn)。

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

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

　　綁卡場(chǎng)景

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

　　這里有如下要點(diǎn)：

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

需要用戶在銀行側(cè)預(yù)留的手機(jī)號(hào)進(jìn)行短信驗(yàn)證。但不是所有銀行都需要。這個(gè)時(shí)候，為了統(tǒng)一處理，可以考慮自己發(fā)驗(yàn)證短信。

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

　　綁卡流程

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

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

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

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

檢查用戶是否有手機(jī)號(hào)。沒(méi)有則進(jìn)入設(shè)置手機(jī)號(hào)流程。

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

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

用戶輸入銀行預(yù)留手機(jī)。對(duì)于沒(méi)有綁過(guò)卡的用戶，需要用戶提供真實(shí)姓名和身份證號(hào)。對(duì)于信用卡，還需要輸入cv碼和有效期。這一步，卡的信息都收集全了。

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

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

卡bin

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

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

　　短信和身份驗(yàn)證

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

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

版本號(hào)：當(dāng)前接口的版本號(hào)；

編碼方式： 默認(rèn)都是UTF-8，指?jìng)鬏數(shù)膬?nèi)容的編碼方式；

簽名和簽名方法： 生成報(bào)文的簽名。 不是所有的字段都需要放到簽名中，文檔中會(huì)說(shuō)明哪些字段需要簽名；

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

商戶代碼：在渠道側(cè)注冊(cè)的商戶號(hào)。

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

發(fā)送時(shí)間：該請(qǐng)求送出的時(shí)間。

賬號(hào)和賬號(hào)類型： 銀行卡、存折、IC卡等支持的賬號(hào)類型以及對(duì)應(yīng)的賬號(hào)；

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

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

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

姓名：真實(shí)姓名，必須和身份證一致；

手機(jī)號(hào)：在所在銀行注冊(cè)的手機(jī)號(hào)。

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

　　綁卡接口

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

　　銀聯(lián)綁卡

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

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

　　實(shí)名認(rèn)證

　　綁卡操作有個(gè)不錯(cuò)的副產(chǎn)品，就是實(shí)名認(rèn)證。常說(shuō)的二要素，三要素，四要素認(rèn)證，可以通過(guò)這個(gè)操作完成。 二要素指姓名和身份證號(hào)，三要素加上銀行卡號(hào)，四要素則加上手機(jī)號(hào)?？雌饋?lái)，似乎銀行都應(yīng)該支持四要素驗(yàn)證，但大部分銀行接口僅支持三要素，畢竟手機(jī)號(hào)還是非常容易變。 當(dāng)然，實(shí)名認(rèn)證，也就是二要素認(rèn)證，是應(yīng)用最多的認(rèn)證了。國(guó)內(nèi)唯一的庫(kù)是在公安部這，由NCIIC負(fù)責(zé)對(duì)外提供接口。可以提供如下功能：

簡(jiǎn)項(xiàng)核查：返回“一致”“不一致”“庫(kù)中無(wú)此號(hào)”

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

人像核查：返回“同一人”“不同人”“庫(kù)中無(wú)此號(hào)”

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

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

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

　　為什么要IAP

　　相對(duì)來(lái)說(shuō)，應(yīng)用內(nèi)支付的用戶體驗(yàn)，和微信支付、支付寶相比，還是有一定差距的，但是為什么要開(kāi)發(fā)應(yīng)用內(nèi)支付呢？ 這個(gè)和蘋果的AppStore的審核政策有關(guān)。 在官方的 (App Store Review Guidelines) 中， 有如下幾條意見(jiàn)：

　　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)來(lái)購(gòu)買內(nèi)容、功能或服務(wù)將被拒絕。

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

　　IAP 購(gòu)買實(shí)物或者應(yīng)用外的商品或服務(wù)將會(huì)被拒絕；

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

　　通過(guò) IAP 購(gòu)買的積分或者其他貨幣必須只在 App 內(nèi)使用。

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

　　IAP支付流程

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

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

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

添加一個(gè)用于在sandbox付費(fèi)的測(cè)試用戶，填寫(xiě)相關(guān)的稅務(wù)，銀行，聯(lián)系人信息。

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

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

用戶通過(guò)App Store賬戶驗(yàn)證

蘋果服務(wù)器驗(yàn)證用戶請(qǐng)求

蘋果服務(wù)器從用戶帳號(hào)扣款

蘋果向用戶返回購(gòu)買成功信息

軟件接收并顯示用戶購(gòu)買信息

　　老司機(jī)都能看出來(lái)，這里有好多好多的坑。

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

　　IAP訂閱

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

　　續(xù)費(fèi)周期的計(jì)算

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

　　自動(dòng)續(xù)費(fèi)

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

　　免費(fèi)試用

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

　　Receipt 驗(yàn)證

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

　　IAP破解和防御

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

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

SKPaymentTransactionStatePurchasing

SKPaymentTransactionStatePurchased

SKPaymentTransactionStateFailed

SKPaymentTransactionStateRestored

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

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

　　兩套賬戶體系

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

　　還是這個(gè)坑，如果在賬戶b登錄后也發(fā)起訂閱請(qǐng)求，會(huì)怎么樣？這個(gè)調(diào)用將會(huì)失敗，所以需要阻止用戶發(fā)起這樣的請(qǐng)求?；蛘咴O(shè)置多個(gè)產(chǎn)品副本來(lái)讓用戶購(gòu)買。

　　分成，定價(jià)和國(guó)際化

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

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

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

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

　　更多的坑

　　目前用的是IOS 10.0 版本， 這個(gè)版本和IAP有關(guān)的坑，先記錄下：

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

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

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

Android IAP

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

　　- - - - - - - - - -

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

　　責(zé)編丨陳晨（微信zfzjcc）

　　鳳凰牌老熊（ID：shamphone）

　　拓展閱讀

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

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

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

　　版權(quán)聲明

　　未經(jīng)許可，禁止轉(zhuǎn)載、摘編、復(fù)制及建立鏡像等任何使用。如需轉(zhuǎn)載，請(qǐng)通過(guò)本號(hào)后臺(tái)申請(qǐng)并獲得授權(quán)，歡迎轉(zhuǎn)發(fā)朋友圈。（商務(wù)合作請(qǐng)加suipay）。