基于C++的网络第三方支付系统.docx

基于C++的网络第三方支付系统.docx

《基于C++的网络第三方支付系统.docx》由会员分享，可在线阅读，更多相关《基于C++的网络第三方支付系统.docx（52页珍藏版）》请在冰豆网上搜索。

基于C++的网络第三方支付系统

摘要

进入21世纪，中国互联网产业发展势不可挡，电子商务己经成为商品交易的最新模式。

作为资金流关键环节的支付，成为制约电子商务发展的主要瓶颈。

而第三方支付模式为电子商务中的信任难题找到了初步解决方案，将电子商务推向一个新高潮。

第三方支付指由具备一定实力和信誉保障的非银行独立机构，集成银行支付结算系统接口或基于其他服务通道，为交易各方提供货币支付、资金清算、交易监管等交易支持服务而形成的支付模式。

目前，我国第三方支付模式可以分为两类:

一类是独立的第三方网关模式，一类是具备担保功能的非独立第三方支付模式。

在电子商务交易时，在网络这个特定的虚拟环境中，由于信息的不对称，双方会产生道德风险，从而阻碍网上交易的发展。

本文通过完全信息静态博弈，参与人不固定的重复博弈等模型，从理论上分析了网上交易所面临的困境，并通过建立改进的动态博弈模型，说明第三方支付是如何解决网上交易的信任问题的，从而指出了第三方支付的巨大优势。

关键字:

电子商务；第三方支付

Abstract

Enteringthe21stcentury,China'sInternetindustrydevelopmentunstoppable,e-commercehavealreadybecomecommoditiestrading,thelatestmodel.Ascashflowkeylinkspayment,restrictedthedevelopmentofecbottleneck.Butthethirdpartypaymentmodelsfore-commercetrustinthepreliminaryconundrumtofindsolutions,wille-commercetoanewhigh.

Thethird-partyreferstothestrengthandcredibilitybyhavecertainnon-bankindependentinstitutions,ensurepaymentsandsettlementsysteminterfaceintegratedbankbasedonotherservicechannel,orfortradingallpartiestoprovidemoneytopay,fundsettlement,tradesupervisiontradesupportservices,intheformofpaymentmode.Atpresent,ourcountrythird-partypaymentmodecanbedividedintotwokinds:

onekindisanindependentthirdpartygatewaymode,onekindistheguaranteefunctionwithindependentthird-partypaymentmode.

Intheelectronicbusinesstransactions,innetworkthisparticularvirtualenvironment,becauseoftheasymmetryofinformation,bothsideswillproducemoralhazardandhinderthedevelopmentofonlinetransactions.Thisarticlethroughthecompleteinformationstaticgame,participantsdon'tfixedrepeatedgamemodel,suchasonlineexchangeareanalyzedtheoretically,andthedifficultiesfacedbyestablishingthedynamicgamemodel,improvementsthatthethird-partyishowtosolvetheproblemoftrustofonlinetransactions,andpointedoutthegreatadvantageofthird-partypayment.

Keyword:

electroniccommerce;Third-partypayment

目录

摘要1

Abstract2

引言3

1、第三方支付平台系统4

1.1支付平台的介绍4

1.1.1虚拟账户和电子钱包4

1.1.2第三方支付平台的基本服务模式6

1.1.3虚拟账户的资金沉淀7

1.2平台结构分析7

1.2.1总体结构7

1.2.2功能模块8

1.3与商户网站的连接11

1.3.1支付平台接入设计12

1.3.2支付接口开发13

2、第三方支付的应用现状20

2.1第三方支付在BZB中的应用20

2.2第三方支付在BZC中的应用21

2.3第三方支付在CZC中的应用22

3、安全电子支付系统的设计22

3.1系统开发背景22

3.2系统原理图和交易流程23

3.3系统应满足的安全要求24

3.4系统软件的设计25

3.5系统软件的工作流程26

3.6系统安全性分析38

3.7系统的优点40

4、加强第三方支付发展的对策建议41

4.1深化行业细分41

4.2提供增值服务42

4.3加强与银行的合作43

4.4提高网上支付的安全性44

4.5提供多元化的支付方式45

结论46

参考文献47

致谢47

引言

随着电子商务近几年来的迅猛发展，电子支付已越来越成为人们普遍接受的生活方式，而银行卡网上支付由于其实时性、便捷性成为网上B2C业务的一种主要支付手段。

但不可否认支付安全始终是电子商务发展的瓶颈,也是影响在线购物者购买意愿程度的重要因素。

最新的互联网调查报告的数据（CNNIC）数据表明，随着电子商务的不断推进，人们对网上购物的关注点主要集中在从事电子商务交易时所持有的一个心理障碍――对交易信用的担心。

国外的网上支付，最早使用的是SET协议和SSL协议。

但是完全依赖SSL协议本身，并不能准确完成对用户的身份验证，它主要解决的是点对点之间的信道加密，不能保证信息的不可抵赖性。

而以信用卡和数字证书为基础的SET（SecureElectronicTransaction）安全电子交易协议由于它要求持卡人在客户端安装电子钱包，交易流程较为复杂，客户普遍不愿意接受这种网上支付方式。

2001年，Visa推出了自己的银行卡网上支付标准3-Dsecure标准（名称为VerifiedbyVisa）即VBV模式成了国外银行卡网上支付的典型安全模式。

Visa作为除发卡行、商户和持卡人以外的第三方单位，它提供的历史记录，也为抵赖交易的时候提供了一定的不可否认的证据：

每一次交易，在发卡行向持卡人发送带有发卡行数字签名的验证响应信息的同时，发卡行都向验证历史服务器传输包含上述带发卡行签名的响应信息的一份拷贝，同时附上商户和持卡人的相关信息及有关本次交易的订单序列号、持卡人主账号等相关交易信息。

这是可信第三方的重要作用，为交易双方提供一个可信任的交易平台。

1、第三方支付平台系统

近年来，各商业银行纷纷推出开放的网上支付平台接口，与银行连接己经比较简单。

网关型第三方支付机构的进入门槛也就随之大大降低，这就造成了众多网关型第三方支付机构依靠拼价格来争夺市场的竞争状况。

虽然这类网关型第三方支付机构在国内己经非常成熟，但这种模式的价值却越来越小，因为它本身只掌握了支付的渠道，还没有掌握支付所需的资源，只能起到通道的作用。

随着市场的发展和竞争的需要，网关型第三方支付机构都已经开始提供虚拟账户的服务，系统增加了平台支付的功能，通过买卖双方在平台内部开立的虚拟账户，使部分交易的资金只在支付平台内循环。

原来单一的支付网关也演变成了虚拟账户和支付网关相结合的支付平台。

1.1支付平台的介绍

1.1.1虚拟账户和电子钱包

虚拟账户是第三方支付平台为用户在平台内部开设的专用账户，用户注册后将在平台上拥有个人专属的支付和交易管理账户。

账户内的资金是预先通过其他方式充值的金额及前次购物后所剩余额的总和。

用户开设的虚拟账户与自己的某一银行账户相联，以便于日后充值或提现之用。

开设虚拟账户后，如果需要支付的金额大于虚拟账户内的金额，用户可以选择直接用绑定的银行账户中资金完成支付，也可以先把银行卡中的部分资金充值到自己的虚拟账户里，再选用虚拟账户支付方式付款。

若虚拟账户内的钱足够支付时，用户可以直接使用虚拟账户中的资金完成支付。

总之，用户使用虚拟账户付款，可以有效避免用户的银行卡号和密码频繁暴露于电脑和网上，提高网上支付的安全性，同时也简化了整个支付的操作。

电子钱包实质上也是一种虚拟账户，可以看成是虚拟账户的另一种称谓。

用户需要先通过其他方式（例如:

现金支付、银行卡支付、邮局汇款或银行电汇多等）对这个电子钱包进行充值，充值完成后，消费者就可以进行支付、转账等操作。

虚拟账户一般有两个密码，一个是登录密码，用于登录账户，查看账目等一般性操作；另一个是支付密码，凡是牵涉到资金流转的过程，都需要使用支付密码。

缺少任何一个密码，都不能使资金发生流转。

虚拟账户的支付密码与所绑定的银行账户的支付密码是两个密码。

用户登录虚拟账户后进行的各种操作，就只涉及虚拟账户的支付密码，因为第三方支付平台是不会知道用户的银行账户的各种密码的，而用户点击充值或者付款时，登录到银行页面上时，需要输入银行账户的支付密码。

通过使用某个指定的网上银行账户，向虚拟账户充值。

一旦用户启动了将资金从银行账户转账至虚拟账户的过程，用户将无法取消充值的转账。

转账完成后，充值的金额会加入用户虚拟账户的余额中，而实际上用户的资金已经转到了第三方支付机构的银行账户，而以后消费者的付款行为就成了第三方支付平台向卖方支付货款的行为。

如果卖方也使用第三方支付平台提供的虚拟账户收款，那么这种支付行为的结果就是第三方支付平台的本身数据库中的几个操作，在买方虚拟账户中减去支付货款的金额，同时将这个金额加到卖方虚拟账户的余额中。

从整个过程来看，支付行为没有涉及到资金的转移，而只是支付平台内部的一些操作，这种只涉及到买卖双方和支付平台三方的网上支付，实现了资金流转和支付过程的分离。

类比银行提供的电子支付系统，如果买卖双方使用同一家银行的账户，那么整个支付过程也就成了银行内部的几个操作，也就不需要第三方支付机构的参与了。

通过提供虚拟账户服务，单纯的网关型第三方支付系统演变成具有结算功能的支付平台，同时将消费者的付款行为和商户的收款行为都变成平台内部的操作，让资金和支付过程相分离，从而减少了在账户资源和资金流转渠道上对银行的依赖。

1.1.2第三方支付平台的基本服务模式

单纯的网关型第三方支付系统只为用户提供了银行账户到银行账户的收付款，而提供虚拟账户或电子钱包服务的支付平台使用户有了更多的选择。

如果买卖双方的其中一方没有虚拟账户，基于虚拟账户的电子邮件收付款也能让用户在线发送付款请求和接受付款。

拥有虚拟账户的用户可以利用电子邮件付款模式向没有虚拟账户的人付款。

用户向没有虚拟账户的人付款时，收款人会收到付款人的电子邮件通知。

收款人点击电子邮件中的链接后，可以注册一个新账户，而该款项会立即出现在账户余额中。

同样如果付款人没有虚拟账户，收款方只需提供付款方的E-MAIL地址即可。

在收款方完成收款操作后，支付平台会自动发送E-MAIL通知付款方。

付款方查看催款通知后，按照邮件里的提示完成虚拟账户的注册并充值，即可完成对付款方虚拟账户的付款。

理论上拥有虚拟账户的用户就可以付款给任何人，也可以接受任何人付款。

而且这种收付款的行为与实际发生的交易实现了分离，即便收款人和付款人之间没有产生任何买卖关系，这种收付款的操作仍然可以完成，这相当于一种汇款的行为。

图1.1支付平台资金流动示意图

在买家、卖家、支付平台三者之间，支付平台行使银行的职能（如图3.1），完成支付结算的功能；在卖家、支付平台，银行之间，支付平台代理买家角色，完成买家的支付请求及资金清算功能；在买家、支付平台，银行之间，支付平台代理卖家角色，完成商家的交易信息的生成及商户的收款和结算功能。

1.1.3虚拟账户的资金沉淀

用户对虚拟账户充值操作，相当于是一种预支付的行为，这种预支付必然会使用户的一部分资金在第三方支付平台那里沉积下来，也就是存放在第三方支付机构在各家银行开设的银行账户中。

这些资金没有随着支付行为的发生而离开第三方支付的银行账户，因为收款方不是每笔交易后都立刻与支付平台进行结算，而是定期进行结算，然后将虚拟账户中的资金再转入自己的银行账户，这就使得沉淀的资金不仅来源于消费者预支付的那部分资金，也包括那些直接从消费者的银行账户“支付”到收款方的虚拟账户，但暂时停留在支付平台的银行账户那里，还没有转到收款方银行账户的资金。

虽然大部分虚拟账户中闲置资金都很少，大部分网上支付的交易金额也相对较小，但是随着交易量的不断增大，以及虚拟账户的数量的增加，资金的沉淀还是会逐渐增加。

只要有新的虚拟账户参与近来，就会带来新的资金。

只要买卖双方不把资金转到其他银行账户或兑换成现金，这些资金就会一直在第三方支付平台那里，而且会越来越多。

1.2平台结构分析

1.2.1总体结构

第三方支付平台系统（如图1.2，1.3）从宏观上可以分为两个子系统，即“充值提现子系统”和“平台支付子系统”，“充值提现子系统”主要用于从银行账户向虚拟账户充值，和将虚拟账户中的资金转入银行账户。

无论是“充值”，还是“提现”，都是一种基于网上银行的付款操作。

这与支付网关的“付款部分”所起的作用是一致的，因此这部分的系统结构也就没有实质性的变化。

对于“平台支付子系统”，由于是虚拟账户到虚拟账户到的支付，整个支付的过程变成平台内部数据库中两条记录的UPDATE操作，而这中间最关键的就是将支付的信息传递给“平台支付子系统”，也就是“商户接口”部分。

图1.2第三方支付平台系统总体结构图

图1.3支付序列图

1.2.2功能模块

以下是“充值取现子系统”，“平台支付子系统”的序列图，用来说明两个子系统的功能。

对于用户的充值，提现操作，都涉及用户，第三方支付平台，银行三个对象，这里的用户不区分是付款人，还是收款人，尤其对于提现操作，付款人和收款人都会存在这样的行为；而真正的平台支付过程则只涉及付款人，收款人和第三方支付平台三个对象。

充值取现子系统:

图1.4充值序列图

图1.5提现序列图

平台支付子系统:

图1.6平台支付子系统序列图

1.3与商户网站的连接

第三方支付平台与商户网站的连接主要通过第三方支付机构提供的是一个统一的CGI接口程序来实现。

一般来说，用户可以使用包含aspp，phP，jsP在内的多种技术来接入支付平台，接入的实现与商家使用的动态页面技术无关。

前期开发中，商户网站应具有基本的订单数据库支持，支付接口可以预留。

第三方支付平台的接入工作，主要完成两个动作:

一个是商家将订单相关数据进行定义和构成，准备提交到第三方支付平台，一般定义一个Send页面来完成；另一个是付款方在第三方支付平台完成支付过程后，第三方支付平台会将支付结果数据通知商家，商家可以通过程序自动接收这些支付结果数据，一般定义一个receive页面来完成。

在Send页面中，对支付的相关数据采用了form方式提交。

只要采用了与第三方支付平台一致的数据处理规则，也可以采用其他方式进行提交。

在receive页面中，主要是对从支付平台接收过来的数据进行处理。

比如说，判断数据是否被伪造，判断支付是否成功，支付成功或失败分别进行什么样的处理。

商家可以结合自己网站的处理逻辑来完成。

1.3.1支付平台接入设计

在支付平台接入程序方面，主要表现为商家网站将支付数据提交到支付平台，等待支付平台处理完毕之后，再从支付平台接收支付结果数据。

现在对这两个步骤分述如下:

1商家提交支付数据到第三方支付平台（需要提交的数据如下）

·商户编号（merehant_id）

商家在支付平台的唯一身份编号。

通过支付平台支付的钱，将被转到该商户编号所对应的虚拟账户上。

·订单编号（orderid）

由商家网站生成的、可在商家网站唯一确定某笔订单的编号。

通过此订单编号，用户可以在商家网站查找该笔定单的详细信息，商家同时也可以在支付平台的系统中查询该笔订单的支付状况。

订单编号是商家网站一记录与支付平台系统一记录的关联点。

·订单金额（amount）

订单应付金额。

支付平台根据此参数扣取用户所需要支付的金额，转到商家的虚拟账户上。

·订货人姓名（pname）

用于在支付平台页面提示用户订单中产品或服务的购买者。

·支付结果返回地址（merchant-ur1）

用于在支付完成之后，支付平台将支付结果返回到指定的页面，以进行进一步处理。

一般是商家网站上的支付结果接收页面的绝对地址。

·商品描述（eommdity_info）

用于在支付平台页面提示用户订单中产品或服务的简单描述。

·商家附加信息（merehant-param）

商户如果有数据必须要传递到支付接收页面时，可通过此参数来进行传递。

另外，此参数将被作为商户私有参数记录到商家在支付平台的交易记录中。

用户可以在网关交易的详细记录中看到该数据。

·检验选择（issupportdes）

商家用来选择是否对订单签名进行安全性校验。

该参数可以有两个选项:

l为不校验；2为校验。

·订单校验加密串（mac）

2商家从支付平台接收的支付结果数据（应与订单提交前的对应数据相匹配）

·商户编号（merehant_id）

·订单编号（orderid）

·订单金额（amount）

·交易日期（date）

.商家附加信息（merehant夕aram）

·交易结果（sueeeed）

如果为“Y”表示支付成功；如果为“N”表示支付失败。

·订单校验加密串（mac）

在支付平台服务器端生成的订单校验加密串。

商家可以根据这个值，与按范例中相同规则生成的的订单校验加密串对比，如果不一致，表明数据可能被伪造，可以认为支付失败。

鉴于web技术的多样性，商家可以根据网站的需要采取不同的方式进行数据的提交和接收。

但是不管采用什么办法，以上的参数是必要的。

1.3.2支付接口开发

当消费者完成网上购物过程，形成最终订单且消费者选择使用第三方支付平台进行网上支付时，该接口程序将消费者订单中有关支付的信息提交到支付平台，消费者在完成网上支付后，将通过URL方式将支付结果返回给商户。

Md5校验串生成方法:

当消费者在商户端生成最终订单的时候，将订单中的merchantid，orderid，amount，merehant-uri，key五个参数的value值根据:

“merehant-id=erehant-id值&orderid=oulerid值&amount=amount值&merchant-url=erchant-url值&merchant-key=key值”的规则拼成一个无间隔的字符串（char型，顺序不能改变）。

其中参数key为商户自行在支付平台账户管理里设置的密钥值。

在用户提交到支付平台的数据中，需要设定merehanturl。

这个值就是支付平台传递数据到商户的目的地址。

支付平台通过远程读取商户服务器上的支付接收页面，显示在用户的浏览器上。

假设merchantesurl=httP:

//www.bZc.co而rePlycgi商户编号是第三方支付平台分配给其用户的一组数字字符串，用于标明该用户的身份。

每个商户编号是唯一对应一个虚拟账户的。

在网上交易过程中，如果操作成功，和该商户编号对应的虚拟账户的账户余额就会发生相应的改变。

商户密钥是由用户自行设定的一组混合字符串，由数字或字母或两者混合组成。

它在支付平台中所起的作用就是，保障支付过程的安全进行。

在网上交易的过程中，该字符串与其他数据组成新的字符串，经过加密后在商户网站和支付平台间进行传递。

支付平台从用户注册的数据库中，获取对应的数据，采取相同的规则，对商户网站提交的数据进行对比认证。

从而保证该交易在安全的环境中进行。

商户网站中所提交的商户密钥，必须与其在支付平台中所设定的商户密钥值保持一致。

否则，可能会导致验证签名不通过，支付失败。

例如:

Merehant-id=000000000000000001&orderid=0000001&arnount=100&merchant-

url=httP:

//

使用标准MD5算法对该字符串进行加密，加密结果即为所需的订单MD5校验码，将其写入mac字段。

MDS算法软件接口如下，具体程序见附录。

imPortjava.io.Printstream；

imPortjava.lang.refleet.Array:

PublieelassMD5{

PublicStringgetMD5ofstr（Strings）；

PublieMDS（）；

Publiestaticvoidmain（Stringargs[]）；

}

提交付款订单接口

以表单的POST方式将交易数据提交到支付平台提供的支付接口，假设支付接口的URL是:

httPs:

//

send.jSP:

<%@PageeontentTyPe=”text/html；charset=gh2312”language="java"%>

<%@PageimPort="MD5"%>

<%

stringmerchantesid="000000000000000001"；//商户编号

Stringmerchan-key=”TempKeyForTest”；//商户密钥

stringorderid="0000001"；//订单编号

stringamount="100，，；//订单金额

StringissuPportDEs="2"//是否安全校验，2为必校验

Stringmerehantweurl=""；//刀支付结果返回地址

StringPname="":

//刀支付人姓名

Stringeonunodity-info=""//商品信息

Stringmerchant-param=""；//商户私有参数

Stringpemail=""；//传递emall到支付平台页面

Stringpid=""；//合作伙伴商户编号

//生成加密串，注意顺序

StringSertstr="merchant-id="+merehant-id+"&orderid="+orderid+

"&amount="+arnount+"&merehanturl="+merehanturl+

"&merehant-key="+merehant-key；

MD5mds=newMD5（）；

Stringmac=md5.getMD5o侣tr（Sertstr.tostring（））；

//进行md5加密，程序未列出

%>

doetyPehtlnlPublie”-//W3c//dtdhtml4.0transitional//en">