【正文】 要集中在從事電子商務(wù)交易時(shí)所持有的一個(gè)心理障礙――對(duì)交易信用的擔(dān)心。 2021 年， Visa 推出了自己的銀行卡網(wǎng)上支付標(biāo)準(zhǔn) 3D secure 標(biāo)準(zhǔn) (名稱為 Verified by Visa)即 VBV模式成了國(guó)外銀行卡網(wǎng)上支付的典型安全模式。網(wǎng)關(guān)型第三方支付機(jī)構(gòu)的進(jìn)入門(mén)檻也就隨之大大降低，這就造成了眾多網(wǎng)關(guān)型第三方支付機(jī)構(gòu)依靠拼價(jià)格來(lái)爭(zhēng)奪市場(chǎng)的競(jìng)爭(zhēng)狀況。 支付平臺(tái)的介紹 虛擬賬戶和電子錢(qián)包 虛擬賬戶是第三方支付平臺(tái)為用戶在平臺(tái)內(nèi)部開(kāi)設(shè)的專用賬戶，用戶注冊(cè)后將在平臺(tái)上擁有個(gè)人專屬的支付和交易管理賬戶。若虛擬賬戶內(nèi)的錢(qián)足夠支付時(shí)，用戶可以直接使用虛擬賬戶中的資金完成支付。 虛擬賬戶一般有兩個(gè)密碼，一個(gè)是登錄密碼，用于登錄賬戶，查看賬目等一般性操作；另一個(gè)是支付密碼，凡是牽涉到資金流轉(zhuǎn)的過(guò)程，都需要使用支付密碼。通過(guò)使用某個(gè)指定的網(wǎng)上銀行賬戶，向虛擬賬戶 充值。從整個(gè)過(guò)程來(lái)看，支付行為沒(méi)有涉及到資金的轉(zhuǎn)移，而只是支付平臺(tái)內(nèi)部的一些 操作，這種只涉及到買賣雙方和支付平臺(tái)三方的網(wǎng)上支付，實(shí)現(xiàn)了資金流轉(zhuǎn)和支付過(guò)程的分離。如果買賣雙方的其中一方?jīng)]有虛擬賬戶，基于虛擬賬戶的電子郵件收付款也能讓用戶在線發(fā)送付款請(qǐng)求和接受付款。同樣如果付款人沒(méi)有虛擬賬戶，收款方只需提供付款方的 EMAIL 地址即可。而且這種收付款的行為與實(shí)際發(fā)生的交易實(shí)現(xiàn)了分離，即便收款人和付款人之間沒(méi)有產(chǎn)生任何買賣關(guān)系，這種收付款的操作仍然可以完成，這相當(dāng)于一種匯款的行為。 雖然大部分虛擬賬戶中閑置資金都很少，大部分網(wǎng)上支付的交易金額也相對(duì)較小，但是隨著交易量的不斷增大，以及虛擬賬戶的數(shù)量的增加，資金的沉淀還是會(huì)逐漸增加。無(wú)論是“充值”，還是“提現(xiàn)”，都是一種基于網(wǎng)上銀行的付款操作。對(duì)于用戶的充值，提現(xiàn)操作，都涉及用戶，第三方支付平臺(tái)，銀行三個(gè)對(duì)象，這里的用戶不區(qū)分是付款人，還是收款人，尤其對(duì)于提現(xiàn)操作，付款人和收款人都會(huì)存在這樣的行為；而真正的平臺(tái)支付過(guò)程則只涉及付款人，收款人和第三方支付平臺(tái)三個(gè)對(duì)象。 第三方支付平臺(tái)的接入工作，主要完成兩個(gè)動(dòng)作 :一個(gè)是商家將訂單相關(guān)數(shù)據(jù)進(jìn)行定義和構(gòu)成，準(zhǔn)備提交到第三方支付平臺(tái)，一般定義一個(gè) Send 頁(yè)面來(lái)完成；另一個(gè)是付款 方在第三方支付平臺(tái)完成支付過(guò)程后，第三方支付平臺(tái)會(huì)將支付結(jié)果數(shù)據(jù)通知商家，商家可以通過(guò)程序自動(dòng)接收這些支付結(jié)果數(shù)據(jù)，一般定義一個(gè) receive 頁(yè)面來(lái)完成。比如說(shuō)，判斷數(shù)據(jù)是否被偽造，判斷支付是否成功，支付成功或失敗分別進(jìn)行什么樣的處理。商戶編號(hào) (merehant_id) 商家在支付平臺(tái)的唯一身份編號(hào)。通過(guò)此訂單編號(hào)，用戶可以在商家網(wǎng)站查找該筆定單的詳細(xì)信息，商家同時(shí)也可以在支付平臺(tái)的系統(tǒng)中查詢?cè)摴P 訂單的支付狀況。支付平臺(tái)根據(jù)此參數(shù)扣取用戶所需要支付的金額，轉(zhuǎn)到商家的虛擬賬戶上。支付結(jié)果返回地址 (merchantur1) 用于在支付完成之后，支付平臺(tái)將支付結(jié)果返回到指定的頁(yè)面，以進(jìn)行進(jìn)一步處理。 訂單校驗(yàn)加密串 (mac) 2商家從支付平臺(tái)接收的支付結(jié)果數(shù)據(jù) (應(yīng)與訂單提交前的對(duì)應(yīng)數(shù)據(jù)相匹配 ) 交易日期 (date) .商家附加信息 (merehant 夕 aram) 商家可以根據(jù)這個(gè)值，與按范例中相同規(guī)則生成的的訂單校驗(yàn)加密串對(duì)比，如果不一致，表明數(shù)據(jù)可能被偽造，可以認(rèn)為支付失敗。 Md5 校驗(yàn)串生成方法 : 當(dāng)消費(fèi)者在商戶端生成最終訂單的時(shí)候，將訂單中的 merchantid， orderid，amount， merehanturi， key五個(gè)參數(shù)的 value值根據(jù) :“ merehantid=erehantid值 amp。merchantkey=key 值”的規(guī)則拼成一個(gè)無(wú)間隔的字符串 (char 型，順序不能改變 )。支付平臺(tái)通過(guò)遠(yuǎn)程讀取商戶服務(wù)器上的支付接收頁(yè)面，顯示在用戶的瀏覽器上。商戶密鑰是由用戶自行設(shè)定的一組混合字符串，由數(shù)字或字母或兩者混合組成。從而保證該交易在安 全的環(huán)境中進(jìn)行。orderid=0000001amp。 ； : PublieelassMD5{ PublicStringgetMD5ofstr(Strings)； PublieMDS()； Publiestaticvoidmain(Stringargs[])； } 提交付款訂單接口 以表單的 POST 方式將交易數(shù)據(jù)提交到支付平臺(tái)提供的支付接口，假設(shè)支付接口的 URL 是 : : %PageeontentTyPe=” text/html； charset=gh2312” language=java% %PageimPort=MD5% % stringmerchantesid=000000000000000001； //商戶編號(hào) Stringmerchankey=” TempKeyForTest”； //商戶密鑰 stringorderid=0000001； //訂單編號(hào) stringamount=100， ； //訂單金額 StringissuPportDEs=2//是否安全校驗(yàn)， 2 為必校驗(yàn) Stringmerehantweurl=； //刀支付結(jié)果返回地址 StringPname=://刀支付人姓名 Stringeonunodityinfo=//商品信息 Stringmerchantparam=； //商戶私有參數(shù) Stringp=； //傳遞 emall 到支付平臺(tái)頁(yè)面 Stringpid=； //合作伙伴商戶編號(hào) //生成加密串，注意順序 StringSertstr=merchantid=+merehantid+amp。merehantkey=+merehantkey； MD5mds=newMD5()； Stringmac= 侶 tr(())； //進(jìn)行 md5加密，程序未列出 % !doetyPehtlnlPublie” //W3c// html head title支付平臺(tái) /title metahttPequiv= ” contenttypecontent=text/html ；charset=gh2312 head BODY divalign=center tablewidth=259border0cellPadding=1cellsPaeing=l bgeolor=CCCCCC trbgeolorFFFFFF tdwidth=68訂單編號(hào) :/td tdwidth=182%=orderid%叼 td /tr trbgeolor=FFFFFF td訂單金額 :/td td%=amount%/td /tr trbgcolor=FFFFFF td支付人 :/td td%=Pname%/td /tT trbgcolor=FFFFFF td商品名稱 :/td td%=modityinfo%/td /tr tr td/tdtd/td /tr /table /div divalign=eenterstyle=fontsize=12Px: Fontweight:bold:eolo=ed: formname=frmmethod=Postaetion= inPutname=merchantidtype=hidden value=%=merchantid% inPutname=orderidtype=hiddenvalue=%=orderid% inPutname=amounttype=hiddenvalue=%=amount% inPutname=issuPPortDEStyPe=” hidden value=%=issuPPortDES% inPutname=mactype=hiddenvalue=%=mae% inPutname=merchanturltype=， hidden， value=%=merchanturl% inPutname=Pnametype=hiddenvalue=%pname% inPutname=moditymfo” type=hidden value=%=cotnmodityinfo% inPutname=merehantParamtype=hidden value=%merchantparam% inPutname=Pernailtype=hiddenvalue=%=p% inPutname=PidtyPe=hiddenvalue=%pid% inputname=paybytype=submitvalue=支付平臺(tái) /fonn /div /BODY HTML 支付結(jié)果頁(yè)面返回接口 支付完成以后，支付平臺(tái)將訂單支付結(jié)果數(shù)據(jù)返回到商戶提交表單時(shí)所 設(shè)定的 merchanturl。date=+dealdate+ amp。以阿里巴巴為例，其1300 萬(wàn)中小企業(yè)客戶目前仍只能在網(wǎng)上達(dá)成交易，網(wǎng)下完成交易，這大大降低了雙方交易的效率，從某種意義上說(shuō)還處于電子商務(wù)的初級(jí)階段。事實(shí)上， BZB 與 BZC、 CZC 這兩個(gè)支付領(lǐng)域的相似度并不是很高， BZC、 CZC 一直都是以小額分散的支付為主， BZB 領(lǐng)域的支付金額數(shù)量一般都上萬(wàn)，如今大部分 BZB交易，特別是金額巨大的交易，在支付環(huán)節(jié)還是采用線下支付，也就是傳統(tǒng)的銀行付款方式。 這類行業(yè)第三方支付平臺(tái)，大多為獨(dú)立網(wǎng)關(guān)，基本完全獨(dú)立于電子商務(wù)網(wǎng)站，就是前文提到的第一種類型的“獨(dú)立的第三方網(wǎng)關(guān)模式”。這些商品對(duì)購(gòu)買者視、聽(tīng)、觸、嗅等感覺(jué)體驗(yàn)要求較低，在 BZC領(lǐng)域付款方式以貨到付款與網(wǎng)上支付相結(jié)合。買方選購(gòu)商品后，使用該平臺(tái)提供的賬戶進(jìn)行貨款支付，并由第三方通知賣家貨款到達(dá)、進(jìn)行發(fā)貨。此外 BZC 支付涉及到很多大的商家，而這些商家在很大程度上又是各大銀行的客戶，銀行和第三方支付平臺(tái)都在努力成為這些大商戶的支付選擇，未來(lái)各大銀行與第三方支付平臺(tái)在 BZC 支付領(lǐng)域的競(jìng)爭(zhēng)將日趨激烈。在 CZC的電子商務(wù)平臺(tái)上聚集了大量的個(gè)人買家和賣家，由于網(wǎng)上交易、支付的雙方互不見(jiàn)面，交易的真實(shí)性不容易考察和驗(yàn)證，且 CZC 交易次數(shù)多而交易額較小，各大銀行不愿花太多精力在這種耗費(fèi)大而收入微薄的 業(yè)務(wù)上，這給第三方網(wǎng)上支付提供了很大的發(fā)展空間，使得其成為 CZC 的主要支付方式。第三方支付的一站式接入服務(wù)使銀行與商家雙方都避免了一對(duì)一接入的高昂成本，同時(shí)也為賣家和買家提供了一個(gè)信用擔(dān)保機(jī)構(gòu)，在相當(dāng)長(zhǎng)的時(shí)期內(nèi)都有存在的必要性與必然性。 BZB 是電子商務(wù)中歷史最長(zhǎng)、發(fā)展最完善的商業(yè)模式，交易數(shù)額大、貨物規(guī)范、市場(chǎng)較大，而且 BtoB 的平臺(tái)、賬號(hào)、貨物規(guī)范性等條件比 BtoC好得多，所以 BtoB 模式具有很好的發(fā)展前景。 系統(tǒng)原理圖和交易流程 該系統(tǒng)包括 5 個(gè)實(shí)體 :生產(chǎn)商、購(gòu)買商、商業(yè)銀行、認(rèn)證中心 CFCA(China Finance Certificate Authority)和交易中心 (即第三方信任實(shí)體，簡(jiǎn)稱 TTP)。根據(jù)網(wǎng)上交易過(guò)程的步驟分析，并參考了各種支付協(xié)議的數(shù)據(jù)流程，確定了該系統(tǒng)的信息流、數(shù)據(jù)流、資金流按下列步驟進(jìn)行 : (l)購(gòu)買商向生產(chǎn)商下定單 購(gòu)買商通過(guò)瀏覽器在生產(chǎn)商的 Web 服務(wù)器定購(gòu)商品。但驗(yàn)證簽名和數(shù)據(jù)加 密都要消耗系統(tǒng)資源，為了改善系統(tǒng)效率，有的信息可進(jìn) Statement 作為商業(yè)機(jī)密應(yīng)加密 : (3)Order， Invoiee， Statement 需做數(shù)字簽名，提供防篡改及不 可否認(rèn)保護(hù) 支付過(guò)程的安全要求 支付過(guò)程 中每一步的安全要求如下 : (1)向 TTP 提供解決爭(zhēng)議的證據(jù)，其安全要求包括 : ①購(gòu)買商與 TTP 之間的雙向身份認(rèn)證， ②對(duì) PM進(jìn)行數(shù)字簽名，以防止對(duì) PM 的非授權(quán)修改和購(gòu)買商否認(rèn)發(fā)出 PM； ③ PM 應(yīng)包括解決爭(zhēng)議的足夠信息，包括發(fā)票號(hào) IN，賬單工 NVO 工 CE，支付指令 PI 等。其中轉(zhuǎn)帳金額為商業(yè)機(jī)密。首先應(yīng)提供商品訂購(gòu)過(guò)程中所需的安全功能 :與購(gòu)買商之間的雙向身份認(rèn)證，驗(yàn)證購(gòu)買商對(duì)定單的數(shù)字簽名，生成生產(chǎn)商對(duì)帳單和承諾的數(shù)字簽名，加解密與購(gòu) 買商之間傳遞的信息。 (2)PSS:該軟件構(gòu)成了買方交易平臺(tái) .它首先提供產(chǎn)品訂購(gòu)過(guò)程中所需的安全功能 :與生產(chǎn)商之間的雙向身份認(rèn)證，產(chǎn)生購(gòu)買商對(duì)定單的數(shù)字簽名，驗(yàn)證生產(chǎn)商對(duì)帳單和承諾的數(shù)字簽名，加解密與生產(chǎn)商之間傳遞的信息 .其次提供支付過(guò)程 所需的安全功能 :與交易中心之間的雙向身份認(rèn)證，采用銀行的公鑰加密提交的轉(zhuǎn)帳信息，生成交易中心需保存的交易證據(jù)，產(chǎn)生對(duì)交易證據(jù)的數(shù)字簽名。其安全功能是 :與生產(chǎn)商之間的雙向身份認(rèn)證、與購(gòu)買商之間的雙向身份認(rèn)證、與銀行之間的雙向身份認(rèn)證、驗(yàn)證購(gòu)買商提交的交易證據(jù)的數(shù)字簽名、驗(yàn)證銀行響應(yīng)的支付結(jié)果的數(shù)字簽名，并在出 現(xiàn)爭(zhēng)議時(shí)驗(yàn)證爭(zhēng)議各方提交證據(jù)的真?zhèn)巍? 該模塊應(yīng)提供 :身份認(rèn)證、數(shù)字簽名、與交易中心業(yè)務(wù)系統(tǒng)聯(lián)系的公 共接口、支付歷史數(shù)據(jù)存儲(chǔ)管理、密鑰與證書(shū)管理等服務(wù)。 PSS:配置購(gòu)買商服務(wù)器證書(shū)，用于與 MSS之間的身份識(shí)別、消息加密和生成數(shù)字簽名；用于與 TSS 之間的身份識(shí)別、消息加密和生成數(shù)字簽名。 BSS:配置商業(yè)銀行的服務(wù)器證書(shū)，用于與