摘要：中國現(xiàn)代化支付系統(tǒng)CNAPS（簡稱支付系統(tǒng)）是中國支付清算體系的中樞，主要包括大額支付系統(tǒng)和小額支付系統(tǒng)。它將商業(yè)銀行為客戶提供的金融服務(wù)系統(tǒng)和中央銀行為商業(yè)銀行提供的支付資金清算服務(wù)系統(tǒng)，通過中國國家金融網(wǎng)絡(luò)結(jié)合在一起。本文探討在銀聯(lián)已有架構(gòu)的基礎(chǔ)上構(gòu)建銀聯(lián)結(jié)算系統(tǒng)與現(xiàn)代化支付系統(tǒng)的接口框架，實現(xiàn)支付結(jié)算系統(tǒng)需要提供給客戶的結(jié)算功能。對銀聯(lián)接入現(xiàn)代化支付系統(tǒng)的開發(fā)設(shè)計有實際指導(dǎo)意義。

關(guān)鍵詞：大額支付系統(tǒng)；小額支付系統(tǒng)；接口服務(wù)器；銀聯(lián)行內(nèi)系統(tǒng)

中圖分類號：TP311.52 文獻(xiàn)標(biāo)識碼：A 文章編號：1007-9599 （2012） 17-0000-02

中國銀聯(lián)為國內(nèi)唯一的銀行卡聯(lián)合組織，向各成員機構(gòu)提供轉(zhuǎn)接清算服務(wù)。銀聯(lián)結(jié)算業(yè)務(wù)是通過現(xiàn)代化支付系統(tǒng)完成發(fā)卡機構(gòu)、收單機構(gòu)及委托代理清算商戶之間的資金轉(zhuǎn)移。本文擬對銀聯(lián)行內(nèi)業(yè)務(wù)系統(tǒng)與現(xiàn)代化支付系統(tǒng)之間接口進(jìn)行分析，提出建立松耦合、模塊化以及參數(shù)驅(qū)動的接口系統(tǒng)框架結(jié)構(gòu)。

1 接口服務(wù)器的分析與設(shè)計

1.1 系統(tǒng)拓?fù)浣Y(jié)構(gòu)

接口服務(wù)器是介于支付系統(tǒng)前置機（簡稱MBFE）和銀聯(lián)行內(nèi)業(yè)務(wù)系統(tǒng)之間的業(yè)務(wù)轉(zhuǎn)換系統(tǒng)，它將實現(xiàn)銀聯(lián)行內(nèi)系統(tǒng)到中國現(xiàn)代化支付系統(tǒng)（CNAPS）之間的數(shù)據(jù)管理和交互功能，從而實現(xiàn)銀聯(lián)業(yè)務(wù)系統(tǒng)與現(xiàn)代化支付系統(tǒng)的直接對接。

如圖1，接口系統(tǒng)主要功能包括對MBFE的接口、對行內(nèi)業(yè)務(wù)系統(tǒng)的接口、往來賬報文的業(yè)務(wù)轉(zhuǎn)換池功能和參數(shù)驅(qū)動的管理控制模塊。

接口系統(tǒng)支持多個接口服務(wù)器的負(fù)載均衡功能，滿足大業(yè)務(wù)量情況下高可用性和高擴(kuò)展性，物理設(shè)備必須能夠承受銀聯(lián)大小額業(yè)務(wù)帶來的壓力以及網(wǎng)絡(luò)和具體物理設(shè)備都需采用雙活方式以保證系統(tǒng)的可靠性。

接口系統(tǒng)的松耦合、模塊化以及參數(shù)驅(qū)動的系統(tǒng)框架結(jié)構(gòu)決定了系統(tǒng)能夠方便的支持功能升級，考慮到支付系統(tǒng)本身的特點、未來的業(yè)務(wù)擴(kuò)展需求及降低銀聯(lián)運營成本的需要，接口系統(tǒng)小額業(yè)務(wù)處理模塊支持“定時、達(dá)量、手工觸發(fā)”三種模式打包發(fā)送業(yè)務(wù)；接口系統(tǒng)還可以進(jìn)行模塊化升級，可以通過配置的方式方便迅捷的實現(xiàn)和其他行內(nèi)業(yè)務(wù)系統(tǒng)（如銀聯(lián)網(wǎng)銀等渠道）對接，同時接口服務(wù)器嵌入了業(yè)務(wù)轉(zhuǎn)換池和路由功能，業(yè)務(wù)路由器可以動態(tài)調(diào)整分配來自各系統(tǒng)（如大額支付系統(tǒng)、小額支付系統(tǒng)等）的業(yè)務(wù)請求。

1.2 典型業(yè)務(wù)流程分析

業(yè)務(wù)處理分為往賬業(yè)務(wù)、來賬業(yè)務(wù)和信息類業(yè)務(wù)。以往賬業(yè)務(wù)為例：（1）行內(nèi)系統(tǒng)經(jīng)辦、復(fù)核、授權(quán)發(fā)起業(yè)務(wù)。（2）接口服務(wù)器經(jīng)往賬處理模塊進(jìn)行業(yè)務(wù)轉(zhuǎn)換（如一代支付報文tag與二代支付報文xml轉(zhuǎn)換或銀行卡交換報文ISO8583與二代支付報文xml轉(zhuǎn)換）。（3）轉(zhuǎn)換后的報文發(fā)往支付系統(tǒng)MBFE。（4）支付系統(tǒng)將清算結(jié)果通過MBFE發(fā)回接口服務(wù)器。（5）接口服務(wù)將業(yè)務(wù)清算結(jié)果進(jìn)行轉(zhuǎn)換。（6）行內(nèi)系統(tǒng)接收清算結(jié)果，并進(jìn)行記賬處理。

1.3 業(yè)務(wù)層報文處理設(shè)計

銀聯(lián)行內(nèi)系統(tǒng)與支付系統(tǒng)間有三種業(yè)務(wù)級報文交換模式：

模式一、接口服務(wù)器發(fā)送報文給支付系統(tǒng)MBFE，支付系統(tǒng)受理該報文，根據(jù)業(yè)務(wù)流程的不同，對于需回復(fù)應(yīng)答報文的則支付系統(tǒng)回應(yīng)相應(yīng)的報文給接口服務(wù)器；對于無需回復(fù)應(yīng)答報文的則支付系統(tǒng)不回應(yīng)相應(yīng)的報文給參與者。

模式二、支付系統(tǒng)發(fā)送報文給接口服務(wù)器，接口系統(tǒng)受理該報文，無須返回業(yè)務(wù)應(yīng)答報文給支付系統(tǒng)；對這類報文，銀聯(lián)行內(nèi)系統(tǒng)業(yè)務(wù)檢查失敗、核簽失敗的，則直接丟棄該報文；

模式三、支付系統(tǒng)發(fā)送報文給接口服務(wù)器，接口系統(tǒng)受理該報文，返回業(yè)務(wù)回應(yīng)報文給支付系統(tǒng)；對這類報文，銀聯(lián)行內(nèi)系統(tǒng)業(yè)務(wù)檢查失敗、核簽失敗的，則組織“已拒絕”的回應(yīng)報文發(fā)送給支付系統(tǒng)。

1.4 應(yīng)用結(jié)構(gòu)設(shè)計

支付系統(tǒng)MBFE和銀聯(lián)行內(nèi)業(yè)務(wù)系統(tǒng)之間的接口服務(wù)器，通訊協(xié)議采用TCP/IP，信息交換方式可采用APPC方式。在MBFE端的服務(wù)器上提供一組API，供接口程序調(diào)用，從而實現(xiàn)銀聯(lián)業(yè)務(wù)系統(tǒng)與支付系統(tǒng)的對接。如圖2。

接口系統(tǒng)與行內(nèi)系統(tǒng)采用單筆定長方式進(jìn)行業(yè)務(wù)交互，系統(tǒng)采用松耦合、層次化模式設(shè)計，由主控調(diào)用各類動態(tài)庫組件完成業(yè)務(wù)功能，動態(tài)庫可動態(tài)增加或減少，可在無需修改主控程序的情況下進(jìn)行靈活調(diào)用。

1.5 數(shù)據(jù)存儲設(shè)計

（1）支付報文存儲結(jié)構(gòu)。大額支付業(yè)務(wù)報文的數(shù)據(jù)存儲結(jié)構(gòu)見下圖：

該類型用于：1）包括一般大額支付業(yè)務(wù)、即時轉(zhuǎn)賬、即時轉(zhuǎn)賬借貸通知等支付報文。2）包括自由格式報文、查詢、查復(fù)等信息類業(yè)務(wù)。

（2）批量業(yè)務(wù)包存儲結(jié)構(gòu)。批量包支付業(yè)務(wù)報文的數(shù)據(jù)存儲結(jié)構(gòu)見下圖：

該類型用于：1）小額批量支付業(yè)務(wù)包。2）大額明細(xì)下載報文。大額明細(xì)業(yè)務(wù)數(shù)據(jù)的排列順序須與批量包支付業(yè)務(wù)頭塊的排列要求一致；批量支付業(yè)務(wù)頭塊用于標(biāo)識支付業(yè)務(wù)的匯總信息。

（3）文件類報文存儲結(jié)構(gòu)

該類型僅用于業(yè)務(wù)系統(tǒng)接收文件形式報文時使用，正文塊的內(nèi)容為文件名，正文的實際內(nèi)容在文件中。這類報文主要有下載明細(xì)和公共數(shù)據(jù)更新。

1.6 交易流程的設(shè)計

（1）發(fā)送交易控制流程

1）銀聯(lián)行內(nèi)系統(tǒng)導(dǎo)入一筆業(yè)務(wù)信息，為該業(yè)務(wù)信息產(chǎn)生一個報文標(biāo)識號；如果是有異步回執(zhí)的SAPS信息或管理信息，為該業(yè)務(wù)信息產(chǎn)生一個報文參考號。將該筆業(yè)務(wù)按規(guī)定的格式打包，通知接口程序向前置機發(fā)送業(yè)務(wù)信息，同時，MBFE端接口程序調(diào)用連接API，建立與支付系統(tǒng)前置機的連接。2）銀聯(lián)行內(nèi)系統(tǒng)端接口程序在接收到行內(nèi)系統(tǒng)的請求后，向前置機系統(tǒng)的接口程序發(fā)送業(yè)務(wù)信息。3）MBFE端接口程序接收銀聯(lián)行內(nèi)行內(nèi)系統(tǒng)發(fā)來的業(yè)務(wù)信息。4）MBFE端接口程序按照所規(guī)定的接口API格式，調(diào)用發(fā)送信息API。5）MBFE端接口程序向行內(nèi)系統(tǒng)接口程序同步返回確認(rèn)信息。6）銀聯(lián)行內(nèi)系統(tǒng)接口程序接收MBFE返回的確認(rèn)信息，并發(fā)送給行內(nèi)系統(tǒng)。7）行內(nèi)系統(tǒng)接收到MBFE的確認(rèn)信息，解包后，作相應(yīng)處理。再調(diào)用斷開連接API，結(jié)束與支付系統(tǒng)前置機的連接。

（2）接收交易控制流程

1）接收程序首先調(diào)用連接API，建立與支付系統(tǒng)前置機的連接，接著按照所規(guī)定的接口API格式，循環(huán)調(diào)用接收信息API，從前置機上獲取待接收報文。2）MBFE端接口程序?qū)那爸脵C取得的信息發(fā)送給銀聯(lián)行內(nèi)行內(nèi)系統(tǒng)接口程序。3）銀聯(lián)行內(nèi)行內(nèi)系統(tǒng)接口程序接收到MBFE系統(tǒng)發(fā)來的的報文后，解包后轉(zhuǎn)發(fā)銀聯(lián)行內(nèi)系統(tǒng)。4）行內(nèi)系統(tǒng)接收到轉(zhuǎn)發(fā)來的信息后，根據(jù)業(yè)務(wù)種類的不同進(jìn)行相應(yīng)的處理。5）待銀聯(lián)行內(nèi)行內(nèi)系統(tǒng)處理完后，產(chǎn)生對所接收信息的確認(rèn)回應(yīng)信息。6）銀聯(lián)行內(nèi)行內(nèi)系統(tǒng)接口程序?qū)⒔邮盏降男袃?nèi)系統(tǒng)發(fā)來的回應(yīng)信息轉(zhuǎn)發(fā)給MBFE系統(tǒng)。7）MBFE系統(tǒng)根據(jù)所收到的回應(yīng)信息進(jìn)行相應(yīng)的處理。再調(diào)用斷開連接API，結(jié)束與支付系統(tǒng)前置機的連接。

1.7 接口安全管理

為保障銀聯(lián)業(yè)務(wù)系統(tǒng)與支付系統(tǒng)之間支付業(yè)務(wù)的處理和支付信息傳遞的安全、準(zhǔn)確和及時，銀聯(lián)接口服務(wù)器系統(tǒng)從用戶管理、審計追蹤、網(wǎng)絡(luò)安全，密押及加密管理、業(yè)務(wù)權(quán)限控制等多方面保障結(jié)算接口的安全管理。

密押管理策略：為實現(xiàn)銀聯(lián)系統(tǒng)與支付系統(tǒng)之間報文傳輸?shù)耐暾院筒豢纱鄹男裕涌谙到y(tǒng)對發(fā)往支付系統(tǒng)的所有支付信息需經(jīng)支付密押設(shè)備加編全國押，對從支付系統(tǒng)接收的所有支付信息進(jìn)行核全國押處理，并對核押不符的支付業(yè)務(wù)經(jīng)查詢查復(fù)后進(jìn)行手工核押。

2 結(jié)論

2010年4月銀聯(lián)小額支付業(yè)務(wù)上線，通過實例證明接口框架：支持AIX操作系統(tǒng)平臺及多種數(shù)據(jù)庫如SYBASE和DB2等，支持SOCKET或MQ通信方式，支持銀聯(lián)行內(nèi)系統(tǒng)（如賬務(wù)核算系統(tǒng)、資金管理系統(tǒng)等）接入，負(fù)責(zé)支付類業(yè)務(wù)邏輯處理與報文之間轉(zhuǎn)換，簡化行內(nèi)系統(tǒng)的應(yīng)用邏輯，對接入現(xiàn)代化支付系統(tǒng)的設(shè)計開發(fā)有實際指導(dǎo)意義。

參考文獻(xiàn)：

[1]中國人民銀行支付結(jié)算司.第二代支付系統(tǒng)業(yè)務(wù)需求-清算賬戶管理系統(tǒng)[M].北京：[出版者不詳]，2010，9

[2]張清明.小額批量支付系統(tǒng)設(shè)計問題研究[J].電子科技大學(xué)學(xué)報，2005

[作者簡介]金清，工程師/大學(xué)本科，主研領(lǐng)域：支付清算，系統(tǒng)分析。