基于WAP的手机支付中间平台设计研究

　　模块结构及支付流程　　 

　　手机支付通常有两种形式：银行卡支付和预存话费支付，银行卡支付是将手机号码与银行卡绑定，客户通过手机号实现银行账户的查询、账单支付、商品购买等功能，预存话费支付是客户直接利用现有的预存话费账户，通过话费代收的方式实现账单支付、商品购买等功能，本文主要讨论基于预存话费方式的手机支付中间平台的实现。 

　　该手机支付中间平台包括三大功能模块。WAP前台界面是直接面向用户的操作界面，主要包括手机支付登录、手机支付注册、用户信息维护及跳转到不同的商户SP(服务提供商)进行相应业务的缴费操作等功能。WEB后台管理系统是面向管理员和各个商户SP的操作界面，主要包括信息发布，订单查询、用户管理和其它等功能。其中，信息发布是指管理员发布WAP前台页面所要展示的动态信息，支付中间平台会为每个商户的每个缴费请求记录相应的订单信息，商户SP可以登录WEB后台管理系统进行查询及统计操作，用户管理主要是指管理员对商户SP基本信息的管理以及商户SP对自己相关信息的管理。接口模块是平台的核心部分，主要是实现商户SP与支付中间平台、支付中间平台与移动BOSS之间的底层通信，横向上可以分为支付中间平台与商户SP的接口和与移动BOSS的接口。 

　　整个支付流程用户必须先在WAP前台界面进行注册，注册成功后便可进行相应的支付活动，无需登录，登录操作仅提供一些基本信息查询与修改功能，如：查询余额、查询历史交易记录、充值卡充值、支付密码修改等，注册成功后，首先用户需要登录到WAP前台页面，选择遇购买商品或缴费项目超链接，并进入相应的商户SP系统，商户SF系统调用支付中间平台接口，发送余额查询请求，支付中间平台收到请求后调用移动BOSS接口。查询该用户的可划转话费余额，并将查询结果返回给支付平台，支付中间平台以应答方式发送给商户SP。如果余额充足，用户确认购买，商户SP系统将发送缴费信息给支付中间平台，支付中间平台得到请求后将缴费信息发送给移动BOSS接口进行缴费，缴费完成后，移动BOSS将会把成功信息发送给支付中间平台，支付中间平台再将该信息传递给商户SP系统，商户SP系统提示用户缴费成功，如用户不确认购买，则返回WAP前台页面继续其它操作，如果余额不足，商户SP系统将会提示用户充值，用户确认充值后，商户SP系统将发送充值请求给支付中间平台，支付中间平台将调用移动BOSS充值卡充值接口，进行充值，完成后即可进行支付。如放弃充值，则返回WAP前台页面继续其它操作。　　 

　　平台构建策略　　 

　　2.1可扩展性策略 

　　以往，用户需要记住商户SP的平台地址，登录后进行相应的缴费操作，商户SP接收到缴费请求后会直接调用移动BOSS接口来实现相应的缴费等操作，现在，支付中间平台会统一管理商户SP的基本信息，用户只需记住支付中间平台的地址，就可以很轻松的访问到其它商户SP的支付系统，商户SP在设计自己的支付系统时，只需将原有直接调用移动BOSS接口的部分改为调用支付中间平台接口，其它部分不需要做任何的改动，支付中间平台的设计思想不但解决了每个商户SP各自为政，自己独立开发支付系统，需要让用户分别记住每个服务提供商的平台地址并进行相应的支付操作的问题，同时还使得每个新商户SP的接人变得非常的简单，增强了支付中间平台对商户SP支付系统的可扩展性。每个新接人的商户SP只要按照相关的协议规定，调用支付中间平台的公共接口，并把基本信息告诉支付中间平台，就可以实现接人。 

　　2.2性能优化策略 

　　为了提高支付中间平台的性能，采用异步长连接的方式来实现与商户SP及移动BOSS之间的连接，如图3。所谓异步长连接就是客户端与服务端建立连接后，保持连接状态，请求方在没有收到响应的情况下，可以发起多个请求，处理方可以并行处理，按任意顺序返回给请求方处理结果。同时，为了提高支付中间平台在接人商户SP时的可扩展性，采用分层收发请求策略。这样可以为每一个首次建立连接的商户SP建立一个属于商户SP自己专有的发送队列及接收队列，所有的发送请求首先要加入发送队列，这是第一层。第二层是一个所有商户SP公共的发送及接收队列，来存放接收自不同商户发送队列的信息，并统一将请求发送给移动BOSS。当移动BOSS处理完请求并返回结果时，返回的信息将首先存放到第二层公共的接收队列里，接收队列收到信息会根据一定的标识策略分发给所属商户SP的接收队列，然后商户SP接收队列再将信息发送给相应的商户SP。为了进一步实现并发控制，并提高支付中间平台与移动BOSS之间的系统资源利用率，更进一步的提升系统性能，支付中间平台在与移动BOSS建立连接时会同时创建多个异步长连接实例，这样一来，不管是在时间、空间，还是在系统资源利用率方面都可以做到最大程度的利用，大大提高系统自身及系统之间的性能，优化整套系统的体系结构。 

　　 2.3安全性策略 

　　为了确保数据传递的安全性，对整个支付流程采用如下安全策略：第一、支付中间平台在数据传输方式上选择基于TCP/IP的Socket进行系统及平台之间的互联互通，在一定程度上可提高系统自身数据传输的安全性，而且平台会对不同的IP地址请求做出相应的安全策略，增加部分鉴权机制，最大程度地降低支付中间平台所存在的安全隐患。第二、商户SP与支付中间平台之间通过公网进行数据传输。这样可增加支付中间平台的可扩展性，商户的接人将不受空间和时间的限制。但这样做存在着许多安全隐患，为了确保数据传输的正确性，在传输前对某些协议规定的信息进行MD5或RSA加密，另外，引入超时处理机制，以确保数据传输过程中的实时性，避免在整个传输过程中因某些不可预测因素而造成的数据包丢失。数据包在传递过程中如果发生超时，将根据协议规定的超时策略进行处理，第三、支付中间平台与移动BOSS之间通过专线进行数据传输，以避免数据传输过程中遇到的许多安全隐患，如数据被恶意截获、篡改等，同样，为了确保数据传输过程的实时性，避免整个传输过程中因某些不可预测因素造成的数据包丢失，在这里也对数据包请求超时做相应的处理。　　 

　　平台支付协议设计 

　　3.1平台与移动BOSS的支付协议 

　　该部分的支付协议中，设BOSS的监听端口为6666，移动BOSS作为SOCKET服务端，支付中间平台作为SOCK-ET客户端，双方通过握手报文保持连接，握手间隔1分钟。数据包采用包头＋包体的格式。 

　　(1)包头格式。 

　　包头为定长包头，如占40个字节，包含乎台代码、包长、功能码、加密标志、交易时间、业务返回码、序列号和后续包标志等信息。其中，平台代码固定填写“PAY”。功能码包括注册申请，注销申请、用户鉴权、话费缴费、退货接口、充值卡缴费、话费缴费冲正、可划转余额查询等8种，每种功能都有相应的4位ACSII码值，如话费缴费为0201。它们的业务超时时间都设定为30秒，即支付平台发起请求后超过30秒就认为业务失败，加密标志中，0为不加密，1为加密。交易过程中，支付平台发送交易请求包时，填写请求时间；BOSS发送交易应答包时，填写响应时间，业务返回码中，应答报文100表示成功，其他失败，请求报文填写000。序列号是异步连接过程中该条请求信息在整个支付活动中的唯一标识，对于后续包标志，只在交易数据超过1024字节时使用，进行分包传输，循环发送与接受，发送方除最后一个包的后续包标志置0外，前面所有包的后续包标志置1；接收方循环接收并发送应答，直至收到的交易包的后续包标志为0时为止，循环过程结束，接收方的应答包是仅有包头的空包。 

　　(2)包体格式。 

　　包体为变长包体，在以上8种功能中，针对不同的功能请求，其请求包与应答包包体的格式有所不同，其中，除了可划转余额查询功能的应答包包体包含用户可用余额和可划转余额两项内容外，其余功能的应答包包体均为空，另外，可根据应答包包头的“业务返回码”来判定业务是否办理成功，现以话费缴费(0201)为例加以说明：话费缴费功能的请求包包体包括手机号码、划转请求金额、订单编号等信息，订单编号不可重复，其格式为：YYMMDD＋顺序增长ID(YYMMDD和ID间补零凑足12字节)，例如：090106000001。所有涉及到金额的地方全部以分为单位，该功能的应答包中，应答包包头返回码为100时，判定业务办理成功；为999时，判定业务办理失败，为404时，判定业务办理超时。应答包包体为空。　　 

　　3.2与商户SP的支付协议 

　　该部分的支付协议中，设支付平台监听端口为9999，网络超时时间为60秒。支付平台作为服务端，商户系统作为客户端，所有交易都由客户端发起请求，服务端应答。客户端启动后发送登录请求报文，在收到服务端的登录成功应答报文后可以进行话费缴费、冲正、退货等交易，客户端退出前发送注销请求并在接收到服务端应答后退出，其数据包也采用包头＋包体的格式，其包头与第一部分支付协议中的格式相同。包体格式只是在内容上有所不同。