【正文】 ldate+ amp。事實上， BZB 與 BZC、 CZC 這兩個支付領域的相似度并不是很高， BZC、 CZC 一直都是以小額分散的支付為主， BZB 領域的支付金額數(shù)量一般都上萬，如今大部分 BZB交易，特別是金額巨大的交易，在支付環(huán)節(jié)還是采用線下支付，也就是傳統(tǒng)的銀行付款方式。這些商品對購買者視、聽、觸、嗅等感覺體驗要求較低，在 BZC領域付款方式以貨到付款與網上支付相結合。此外 BZC 支付涉及到很多大的商家，而這些商家在很大程度上又是各大銀行的客戶，銀行和第三方支付平臺都在努力成為這些大商戶的支付選擇，未來各大銀行與第三方支付平臺在 BZC 支付領域的競爭將日趨激烈。第三方支付的一站式接入服務使銀行與商家雙方都避免了一對一接入的高昂成本，同時也為賣家和買家提供了一個信用擔保機構，在相當長的時期內都有存在的必要性與必然性。 系統(tǒng)原理圖和交易流程 該系統(tǒng)包括 5 個實體 :生產商、購買商、商業(yè)銀行、認證中心 CFCA(China Finance Certificate Authority)和交易中心 (即第三方信任實體，簡稱 TTP)。但驗證簽名和數(shù)據加 密都要消耗系統(tǒng)資源，為了改善系統(tǒng)效率，有的信息可進其中轉帳金額為商業(yè)機密。 (2)PSS:該軟件構成了買方交易平臺 .它首先提供產品訂購過程中所需的安全功能 :與生產商之間的雙向身份認證，產生購買商對定單的數(shù)字簽名，驗證生產商對帳單和承諾的數(shù)字簽名，加解密與生產商之間傳遞的信息 .其次提供支付過程 所需的安全功能 :與交易中心之間的雙向身份認證，采用銀行的公鑰加密提交的轉帳信息，生成交易中心需保存的交易證據，產生對交易證據的數(shù)字簽名。 該模塊應提供 :身份認證、數(shù)字簽名、與交易中心業(yè)務系統(tǒng)聯(lián)系的公 共接口、支付歷史數(shù)據存儲管理、密鑰與證書管理等服務。 BSS:配置商業(yè)銀行的服務器證書，用于與 TSS 之間的身份識別、消息加密和生成數(shù)字簽名。為 PSS 用生產商簽名公鑰驗證其簽名 ) step3:從 RespMsg 中獲得交易標識 RandomT，并根據頁面上訂購的產品，生成 OI(訂貨指令 OrderInstruction), OI 的數(shù)據結構見表 33。 表 36PurchaseResp 的數(shù)據結構 數(shù)據單元 描述 Purchase=Res (Cert,enINVOICE,INVOICEenvelop,SIGN 一 SK (H(INVOICE))} Cert 生產商的數(shù)字證書 EnINVOICE {EN一 K(INVOICE)} (MSS 軟件隨機生成對稱密鑰 K加密 INVOICE) INVOICEenvelop {EN一 PK(K)} (MSS 軟件用購買商公開密鑰加密 K形成數(shù)字信封 ) H(INVOICE) 用 hash 函數(shù)對 INVOICE 求摘要 SIGNSK() 生產商用簽名私鑰 SK對摘要簽名 ② PSS 收到 MSS 購買回答 (PurHaseResp)后，做以下幾步 : stepl:verify(Cert)，若核實 ，則往下 進行， 否則終止 ， StepZ:由DESK.(INVOICEenveloP)得到 K，從 DEK。 表 39 lnitPTResp 的數(shù)據結構 數(shù)據單元 描述 InitPTResp {,SIGNSK(H (RespMsg))} CertTTP 交易中心的數(shù)字證書 RespMsg {RandomT， message， ID} RandomT 從 InitPTRequ 得到 message 說明已收到初始請求 ID TTP 產生的本地 ID H(RespMsg) 用 hash 函數(shù)對 RespMsg 求摘要 SIGNSK() 交易中心用簽名私鑰 SK 對摘要簽名 描述 {Cert. RespMsg, SIGNSKTTP (H (RespMsg))} 交易中心的數(shù)字證書 {RandomT， message， IDTTP} 從 InitPTRequ 得到 說明已收到初始請求 TTP 產生的本地 ID 用 hash 函數(shù)對 RespMsg 求摘要 表 314TransTBRequ 的數(shù)據結構 數(shù)據單元 描述 TransTBRequ {Cert, Cert, PM, SIGNSK (H(PM))} Cert 交易中心的數(shù)字證書 Cert 購買商的數(shù)字證書 PM 從 TransPTRequ 得到 SIGNSK (H(PM)) 從 TransPTRequ 得到 (5)商業(yè)銀行處理轉帳通知 商業(yè)銀 行處理轉帳通知步驟如圖 36 圖 3一 6商業(yè)銀行處理轉帳通知步驟 ① BSS 收到轉帳請求 TranoTBRequ 后，做以下幾步 : stepl:verify(cert)， Verify(Cert)，若核實，則往下進行，否則終止， Step2:驗證購買商的數(shù)字簽名， DEPK， (SIGNSK(H(PM))是否等于 H(PM)，若相等，則往下進行，否則終止， step3:給 TSS 發(fā)送轉帳受理通知 Notes， Notes 的數(shù)據結構見表 315。 ③ BSS 從 PM中用自己的私鑰取出轉帳支付指令 PI，并將 PI送到銀行后臺系統(tǒng)進行處理。 表 311TransPTRequ 的數(shù)據結構 數(shù)據單元 描述 TransPTRequ {Cert,enPM, PMenvelop,SIGNSK(H(PM))} Cert 購買商的數(shù)字證書 EnPM {ENKP(PM)} (PSS 軟件隨機生成對稱密鑰 K，加密 PM) PMenvelop {ENPK (K)} (PSS 軟件用交易中心公開密鑰加密 KP 形成數(shù)字信封 ) H(PM) 用 hash 函數(shù)對 PM求摘要 SIGNSK() 購買商對 PM數(shù)字簽名 (4)交易中心轉發(fā)轉帳通知 交易中心轉發(fā)轉帳通知步驟如圖 3一 5: 圖 3一 5交易中心轉發(fā)轉帳通知步驟 ① TSS 收到 PSS 的轉帳請求 TransPTRequ 后，做以下幾步 : stepl:verify(cert， )，若核實，則往下進行，否則終止， Step2:由口 ESK::， (PMenvel。 (SIGNSK。 表 34 PurchaseRequ 的數(shù)據結構 數(shù)據單元 描述 PurchaseRequ {Cert,en0I,OIEnvelop,SIGNSK(H (0I))} Cert 購買商的數(shù)字證書 EnOI {ENKP(OI)) (PSS 軟 件隨機生成對稱密鑰 K，加密 OI) OIEnvelop {ENPK (K)} (PSS 軟件用生產商公開密鑰加密 KP 形成數(shù)字信封 ) OI 訂貨指令 H(OI) 用 hash 函數(shù)對 OI 求摘要 SIGN 一 SK() 購買商用簽名私鑰 SK 對摘要簽名 (2)生產商形成帳單 生產商形成帳單交易步驟如圖 33: ① MSS 收到 PSS 的購買請求 (PurehaseRequ)后，做以下幾步 : stepl:Verify(Cert)，若核實，則往下進行，否則終止， stepZ:由 DESK，(01envel。 (l)購買商提交訂單 購買商提交訂單交易步驟如圖 32: 圖 32購買商提交訂單交易步驟 ①購買商在生產商的 WEB 服務器上選擇好要訂購的產品，并填寫完其它必要信息 (如送貨時間、地點等 )后，點擊頁面上的提交接扭，此時激活 PSS 軟件。具體配置情況如下 : (3)TSS:該軟件構成了安全交易平臺。 (5)生產商、購買商都能驗證銀行的數(shù)字簽名。下面詳細分析該系統(tǒng)所需的安全需求。該系統(tǒng)原理圖見圖 31。傳統(tǒng)上，企業(yè)之間的業(yè)務往來是通過傳真、電話和設在各地的辦事處完成，但這 種模式效率低、成本高。第三方支付平臺的出現(xiàn)，很好地解決了 CZC 交易中的很多不確定因素，平臺的接入很好地解決了買家與賣家之間的信用問題，也提供了更為安全的支付技術。主要可以分為以下兩類 : 一類是，一些規(guī)模較大的網上商城例如 :卓越網、當當網以及一些直銷企業(yè)網站等等，他們在所采用的第三方支付平臺，往往都是從自己的電子商務網站建立起來的支 付網關，因而這類支付平臺只針對該企業(yè)的產品，支付網站最初也是為了滿足自身配送商品和實時支付而研發(fā)搭建的，逐步擴展到提供專業(yè)化的支付產品服務。即使有第三方支付平臺能夠暫時保管資金，但是用戶雙方都要經受將近一周或者更長時間 的巨額資金無法到帳的風險。merchantkey=+ Merchantkey: MD5md5=newMD5()； Stringmylnac=(SertStr): //進行 md5加密，程序未列出 Stringvresult=失敗 : if((mac)){ if(succeed=Y){//支付成功 Vresult=成功 : //商戶網站邏輯處理 }else{ //支付失敗 } }else{ //簽名錯誤 } % !doctypehtlmPublie//w3c// html head title支付平臺 /title metaequiv=contenttypecontent=text/html: charset==gb2312” / /head body divalign=eenter tablewidth=259bordf0cellPadding=lcellsPaeing=1 Bgcolor=CCCCCC trbgcolor=FFFFFF tdwidth=68訂單編號 :/td tdwidth=182%=orderid%/td /tr trbgeolo 作” FFFFFF” td訂單金額 :/td td%=amount%/td /tr trbgcolor=FFFFFF td支付結果 :/td td%=vresult%/td /tr /table /div body /html 第三方支付的應用現(xiàn)狀 第三方支付在 BZB 中的應用 目前， BZB 的交易額占到了整個中國電子商務市場的 98%，是電子商務的絕對主流。amount=+arnount+amp。否則，可能會導致驗證簽名不通過，支付失敗。每個商戶編號是唯一對應一個虛擬賬戶的。amount=amount 值 amp。 該參數(shù)可以有兩個選項 :l為不校驗； 2 為校驗。 在支付平臺 接入程序方面，主要表現(xiàn)為商家網站將支付數(shù)據提交到支付平臺，等待支付平臺處理完畢之后，再從支付平臺接收支付結果數(shù)據。一般來說，用戶可以使用包含 aspp， phP， jsP 在內的多種技術來接入支付平臺，接入的實現(xiàn)與商家使用的動態(tài)頁面技術無關。只要買賣雙方不把資金轉到其他銀行賬戶或兌換成現(xiàn)金，這些資金就會一直在第三方支付平臺那里，而且會越來越多。付款方查看催款通知后，按照郵件里的提示完成虛擬賬戶的注冊并充值，即可完成對付款方虛擬賬戶的付款。 通過提供虛擬賬戶服務，單純的網關型第三方支付系統(tǒng)演變成具有結算功能的支付平臺，同時將消費者的付款行為和商戶的收款行為都變成平臺內部的操作，讓資金和支付過程相分離，從而減少了在賬戶資源和資金流轉渠道上對銀行的依賴。虛擬賬戶的支付密碼與所綁定的銀行賬戶的支付密碼是兩個密碼。用戶開設的虛擬賬戶與自己的某一銀行賬戶相聯(lián)，以便于日后充值或提現(xiàn)之用。這是可信第三方的重要作用，為交易雙方提供一個可信任的交易平臺。 Thirdparty payment 目錄 摘要 ................................................................................................................................. 1 Abstract ............................................................................................................................ 2 引言 ................................................................................................................................. 4 第三方支付平臺系統(tǒng) ................................................................................................... 4 .........................................................................................