早茶
快訊
精選
智庫(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)。
評(píng)論列表
還沒(méi)有評(píng)論,快來(lái)說(shuō)點(diǎn)什么吧~