韋國(guó)志

（中國(guó)移動(dòng)通信集團(tuán)浙江有限公司杭州分公司 浙江 310016）

0 引言

電信運(yùn)營(yíng)商支付是用戶通過(guò)各種接入渠道、借助電信支付平臺(tái)為電信業(yè)務(wù)付費(fèi)或者在聯(lián)盟商戶進(jìn)行消費(fèi)的能力。

1 電信運(yùn)營(yíng)商支付中存在的問(wèn)題

1.1 支付能力問(wèn)題

（1）隨著互聯(lián)網(wǎng)支付的快速發(fā)展，電信運(yùn)營(yíng)商支撐系統(tǒng)對(duì)簽約支付、快捷支付及網(wǎng)銀支付等各類支付方式的拓展及支持力度不足；

（2）目前簽約關(guān)系管理分散建設(shè)，未納入電信運(yùn)營(yíng)商支撐域統(tǒng)一管理；在客戶投訴或故障時(shí)，無(wú)法快速定位問(wèn)題原因，客戶感知差；

（3）各支付業(yè)務(wù)與金融機(jī)構(gòu)的支付接口比較分散，對(duì)外業(yè)務(wù)口徑不統(tǒng)一，重復(fù)建設(shè)、資源利用效率低下。

1.2 渠道賬戶問(wèn)題

社會(huì)渠道資金的管理模式陳舊，線下流程過(guò)長(zhǎng)，導(dǎo)致渠道資金周轉(zhuǎn)效率低，成為渠道、電信運(yùn)營(yíng)商合作水平提升的阻礙。

2 如何提升電信運(yùn)營(yíng)商支付能力

2.1 建設(shè)統(tǒng)一支付網(wǎng)關(guān)

（1）統(tǒng)一支付網(wǎng)關(guān)制定支付規(guī)范，并與各業(yè)務(wù)平臺(tái)及金融機(jī)構(gòu)對(duì)接，各業(yè)務(wù)平臺(tái)不再直連金融機(jī)構(gòu)，從而統(tǒng)一各類支付業(yè)務(wù)的對(duì)外口徑及規(guī)則；

（2）拓展或新增快捷支付、簽約支付及網(wǎng)銀支付等新型支付方式，有效提升支撐系統(tǒng)的支付能力；

（3）集中管理簽約支付關(guān)系，實(shí)現(xiàn)簽約、支付記錄的集中化管理；

（4）通過(guò)快捷支付、網(wǎng)銀支付等方式實(shí)現(xiàn)手機(jī)閱讀、彩鈴、SP及增值等業(yè)務(wù)的一次性支付要求，包括非電信運(yùn)營(yíng)商客戶的支付需求。

2.2 加強(qiáng)渠道資金管理

（1）建設(shè)渠道賬戶，實(shí)現(xiàn)對(duì)合作伙伴的預(yù)存資金額度的實(shí)時(shí)控制和管理功能；

（2）加強(qiáng)終端管理平臺(tái)終端款的在線支付能力，實(shí)現(xiàn)B2B、B2C的支付功能。

2.3 構(gòu)建統(tǒng)一支付接口

（1）實(shí)現(xiàn)省公司與銀行（與電信運(yùn)營(yíng)商建立簽約關(guān)系的協(xié)議銀行）的集中一點(diǎn)接入，包括簽約支付、網(wǎng)銀支付、快捷支付接口，實(shí)現(xiàn)兩者間的流程、業(yè)務(wù)規(guī)則、接口的標(biāo)準(zhǔn)化；

（2）為業(yè)務(wù)平臺(tái)提供統(tǒng)一的電子支付接口，集中實(shí)現(xiàn)在線支付服務(wù)。

2.4 建設(shè)統(tǒng)一支付中心

（1）建立統(tǒng)一的簽約模型，支持目前工行簽約、短信易充值簽約、總對(duì)總簽約、終端簽約、回繳款簽約等簽約關(guān)系，實(shí)現(xiàn)簽約管理的集中化；

（2）實(shí)現(xiàn)簽約用戶銀行卡支付的集中管理，并提供完整的交易信息查詢能力

3 統(tǒng)一支付網(wǎng)關(guān)建設(shè)的技術(shù)分析

圖1 統(tǒng)一支付網(wǎng)關(guān)建設(shè)的技術(shù)分析

統(tǒng)一支付網(wǎng)關(guān)劃分為統(tǒng)一支付接口、統(tǒng)一支付中心兩部分。

銀行支付接口：主要負(fù)責(zé)與簽約銀行進(jìn)行簽約、支付、對(duì)賬、查詢等業(yè)務(wù)的交互。

電子支付接口：主要負(fù)責(zé)與外圍業(yè)務(wù)平臺(tái)進(jìn)行簽約、支付、對(duì)賬、查詢等交互，并且統(tǒng)一提供簽約頁(yè)面、支付頁(yè)面，方便業(yè)務(wù)平臺(tái)快速接入。

統(tǒng)一支付中心：

（1）簽約關(guān)系管理：統(tǒng)一管理簽約關(guān)系，并且支持簽約信息的變更、查詢和取消。

（2）簽約支付管理：實(shí)現(xiàn)業(yè)務(wù)平臺(tái)發(fā)起的訂單支付，并提供查詢功能。

（3）安全認(rèn)證：提供簽約、支付業(yè)務(wù)操作時(shí)驗(yàn)證碼生成、下發(fā)及有效期管理，以及與銀行所需的安全證書管理。

（4）接口管理：管理對(duì)支付機(jī)構(gòu)、業(yè)務(wù)平臺(tái)接口的接入權(quán)限、業(yè)務(wù)范圍。

（5）對(duì)賬管理：提供對(duì)支付機(jī)構(gòu)、統(tǒng)一支付網(wǎng)關(guān)、業(yè)務(wù)平臺(tái)的三方對(duì)賬功能，并支持對(duì)賬結(jié)果查詢、本地調(diào)賬處理功能。

（6）支付：為客戶提供基礎(chǔ)的快捷支付、網(wǎng)銀支付能力。

（7）客戶管理：提供對(duì)客戶資料的管理能力。

（8）充值管理：提供對(duì)BOSS充值接口的管理能力。

（9）運(yùn)維管理：提供系統(tǒng)參數(shù)、業(yè)務(wù)參數(shù)的統(tǒng)一配置，系統(tǒng)、業(yè)務(wù)的監(jiān)控告警，日志管理等基礎(chǔ)運(yùn)維功能。

統(tǒng)一支付網(wǎng)關(guān)采用三層架構(gòu)，分別為接入層、業(yè)務(wù)層、數(shù)據(jù)層。

（1）接入層：分別為電子支付接口、銀行支付接口、WEB服務(wù)和銀行前置機(jī)，采用的開(kāi)發(fā)框架為AppFrame 5.5。

（2）業(yè)務(wù)層：分別實(shí)現(xiàn)業(yè)務(wù)處理子系統(tǒng)、運(yùn)維管理子系統(tǒng)，采用的開(kāi)發(fā)框架為AppFrame5.5，中間件平臺(tái)為：WebLogic，F(xiàn)TP服務(wù)為對(duì)賬文件提供服務(wù)。

（3）數(shù)據(jù)存儲(chǔ)層：DB采用ORACLE。

（4）鑒于目前ESB項(xiàng)目的建設(shè)進(jìn)度，本項(xiàng)目不建議接ESB。

（5）業(yè)務(wù)平臺(tái)需要提供HTTP接口供支付網(wǎng)關(guān)調(diào)用。

統(tǒng)一支付網(wǎng)關(guān)為各業(yè)務(wù)平臺(tái)提供統(tǒng)一的支付頁(yè)面，提供網(wǎng)銀支付功能（用戶需通過(guò)自己所擁有的借記卡、信用卡在銀行側(cè)申請(qǐng)開(kāi)通網(wǎng)上銀行），支持電信運(yùn)營(yíng)商客戶、非電信運(yùn)營(yíng)商客戶進(jìn)行網(wǎng)銀支付，支持網(wǎng)廳、掌廳等渠道。

（1）銀行根據(jù)統(tǒng)一支付網(wǎng)關(guān)的請(qǐng)求，提供安全證書以及支付頁(yè)面。

（2）請(qǐng)求報(bào)文中需要填寫返回 URL，支付結(jié)果銀行以POST方式通知網(wǎng)關(guān)。

（3）銀行、統(tǒng)一支付網(wǎng)關(guān)提供頁(yè)面跳轉(zhuǎn)和服務(wù)器異步通知兩種方式通知給網(wǎng)關(guān)及業(yè)務(wù)平臺(tái)，以保證交易的完整性

統(tǒng)一支付網(wǎng)關(guān)給業(yè)務(wù)平臺(tái)提供快捷支付功能，支持電信運(yùn)營(yíng)商用戶和非電信運(yùn)營(yíng)商用戶，支持網(wǎng)廳、營(yíng)業(yè)廳、IVR等渠道，提供頁(yè)面和接口兩種方式。

（1）銀行授權(quán)統(tǒng)一支付網(wǎng)關(guān)進(jìn)行快捷支付的簽約；使用快捷支付前，用戶需要同意相關(guān)條款、協(xié)議，進(jìn)行快捷支付的簽約。

（2）業(yè)務(wù)平臺(tái)支付時(shí)，發(fā)送業(yè)務(wù)平臺(tái)編碼+唯一標(biāo)識(shí)符（可為手機(jī)號(hào)、個(gè)人賬號(hào)等）到統(tǒng)一支付網(wǎng)關(guān)，統(tǒng)一支付網(wǎng)關(guān)根據(jù)此信息查詢是否存在綁定的快捷支付銀行卡信息；若不存在需傳入卡面信息，包括客戶名稱、證件號(hào)碼、證件類型、銀行預(yù)留手機(jī)號(hào)、銀行卡號(hào)（信用卡還需有效期、CVV2碼）。

4 幾種安全技術(shù)分析

4.1 數(shù)字簽名

數(shù)字簽名是非對(duì)稱密鑰加密技術(shù)與數(shù)字摘要技術(shù)的應(yīng)用，可以保證交易數(shù)據(jù)的完整性、不可抵賴性。具體流程如下（以業(yè)務(wù)平臺(tái)和支付網(wǎng)關(guān)交易為例）：

（1）業(yè)務(wù)平臺(tái)使用哈希函數(shù)（MD5）對(duì)原始數(shù)據(jù)生成摘要；

（2）然后用業(yè)務(wù)平臺(tái)的私鑰對(duì)摘要進(jìn)行數(shù)字簽名操作（RSA算法）；

（3）業(yè)務(wù)平臺(tái)將經(jīng)過(guò)BASE64編碼的原始數(shù)據(jù)和數(shù)字簽名一起發(fā)給支付網(wǎng)關(guān)；

（4）支付網(wǎng)關(guān)對(duì)原始數(shù)據(jù)經(jīng)過(guò)BASE64解碼，并使用與業(yè)務(wù)平臺(tái)同樣的哈希函數(shù)（MD5）生成摘要；

（5）支付網(wǎng)關(guān)使用業(yè)務(wù)平臺(tái)的公鑰對(duì)數(shù)字簽名進(jìn)行解密得到業(yè)務(wù)平臺(tái)的摘要；

（6）對(duì)比這兩份摘要，如果一致則認(rèn)為交易數(shù)據(jù)時(shí)完整的，同時(shí)為業(yè)務(wù)平臺(tái)發(fā)送的，否則不通過(guò)交易。

4.2 異常數(shù)據(jù)稽核處理

（1）電信運(yùn)營(yíng)商側(cè)存在簽約關(guān)系，銀行側(cè)不存在，導(dǎo)致送銀行無(wú)法扣費(fèi)。

解決方案：電信運(yùn)營(yíng)商側(cè)作廢簽約關(guān)系，告知用戶重新簽約。

（2）銀行側(cè)簽約信息和電信運(yùn)營(yíng)商側(cè)簽約信息數(shù)據(jù)有差異（證件信息、預(yù)留手機(jī)號(hào)碼）。

解決方案：電信運(yùn)營(yíng)商側(cè)作廢簽約關(guān)系，告知用戶重新簽約。

（3）渠道賬戶資金數(shù)據(jù)稽核不平。

解決方案：批量不平帳則需要檢查程序邏輯。個(gè)別案例分析相關(guān)數(shù)據(jù)，進(jìn)行調(diào)賬處理，調(diào)整規(guī)則為“賬本金額=賬本封存金額＋賬戶來(lái)源金額－賬戶支出金額”。

4.3 敏感數(shù)據(jù)存儲(chǔ)

（1）為報(bào)障數(shù)據(jù)安全，數(shù)據(jù)庫(kù)存儲(chǔ)數(shù)據(jù)時(shí)需要對(duì)用戶關(guān)鍵數(shù)據(jù)進(jìn)行加密存儲(chǔ)。

（2）目前需要加密存儲(chǔ)的只有快捷支付的支付密碼。

（3）支付密碼用sha進(jìn)行不可逆加密。