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

上传人:平*** 文档编号:18082851 上传时间:2017-11-13 格式:DOC 页数:4 大小:35.50KB
返回 下载 相关 举报
盛辉--基于WAP的手机支付中间平台设计研究_第1页
第1页 / 共4页
盛辉--基于WAP的手机支付中间平台设计研究_第2页
第2页 / 共4页
盛辉--基于WAP的手机支付中间平台设计研究_第3页
第3页 / 共4页
盛辉--基于WAP的手机支付中间平台设计研究_第4页
第4页 / 共4页
亲,该文档总共4页,全部预览完了,如果喜欢就下载吧!
资源描述

《盛辉--基于WAP的手机支付中间平台设计研究》由会员分享,可在线阅读,更多相关《盛辉--基于WAP的手机支付中间平台设计研究(4页珍藏版)》请在金锄头文库上搜索。

1、基于的手机支付中间平台设计研究盛 辉摘 要:移动终端的不断发展,使得利用移动终端进行商务活动成为了可能,提出了一种基于 WAP 并利用手机预存话费进行小额支付的中间平台的设计理念,从可扩展性、性能优化及安全性三方面给出了中间平台的构建策略。并对平台支付协议进行了设计,为移动商务的发展提出了一个较好的解决方案。 关键词:预存话费支付 小额支付 手机支付中间平台 一、 模块结构及支付流程手机支付通常有两种形式:银行卡支付和预存话费支付,银行卡支付是将手机号码与银行卡绑定,客户通过手机号实现银行账户的查询、账单支付、商品购买等功能,预存话费支付是客户直接利用现有的预存话费账户,通过话费代收的方式实现

2、账单支付、商品购买等功能,本文主要讨论基于预存话费方式的手机支付中间平台的实现。 该手机支付中间平台包括三大功能模块。WAP 前台界面是直接面向用户的操作界面,主要包括手机支付登录、手机支付注册、用户信息维护及跳转到不同的商户 SP(服务提供商)进行相应业务的缴费操作等功能。WEB 后台管理系统是面向管理员和各个商户 SP 的操作界面,主要包括信息发布,订单查询、用户管理和其它等功能。其中,信息发布是指管理员发布 WAP 前台页面所要展示的动态信息,支付中间平台会为每个商户的每个缴费请求记录相应的订单信息,商户 SP 可以登录 WEB 后台管理系统进行查询及统计操作,用户管理主要是指管理员对商

3、户 SP 基本信息的管理以及商户 SP 对自己相关信息的管理。接口模块是平台的核心部分,主要是实现商户 SP 与支付中间平台、支付中间平台与移动 BOSS 之间的底层通信,横向上可以分为支付中间平台与商户 SP 的接口和与移动 BOSS 的接口。 整个支付流程用户必须先在 WAP 前台界面进行注册,注册成功后便可进行相应的支付活动,无需登录,登录操作仅提供一些基本信息查询与修改功能,如:查询余额、查询历史交易记录、充值卡充值、支付密码修改等,注册成功后,首先用户需要登录到 WAP 前台页面,选择预购买商品或缴费项目超链接,并进入相应的商户 SP 系统,商户 SF 系统调用支付中间平台接口,发送

4、查询余额请求,支付中间平台收到请求后调用移动 BOSS 接口。查询该用户的可划转话费余额,并将查询结果返回给支付平台,支付中间平台以应答方式发送给商户 SP。如果余额充足,用户确认购买,商户 SP 系统将发送缴费信息给支付中间平台,支付中间平台得到请求后将缴费信息发送给移动 BOSS 接口进行缴费,缴费完成后,移动 BOSS 将会把成功信息发送给支付中间平台,支付中间平台再将该信息传递给商户 SP 系统,商户 SP 系统提示用户缴费成功,如用户不确认购买,则返回 WAP 前台页面继续其它操作,如果余额不足,商户 SP 系统将会提示用户充值,用户确认充值后,商户 SP 系统将发送充值请求给支付中

5、间平台,支付中间平台将调用移动 BOSS 充值卡充值接口,进行充值,完成后即可进行支付。如放弃充值,则返回 WAP 前台页面继续其它操作。 二、 平台构建策略 (一)可扩展性策略 以往,用户需要记住商户 SP 的平台地址,登录后进行相应的缴费操作,商户 SP 接收到缴费请求后会直接调用移动 BOSS 接口来实现相应的缴费等操作,现在,支付中间平台会统一管理商户 SP 的基本信息,用户只需记住支付中间平台的地址,就可以很轻松的访问到其它商户 SP 的支付系统,商户 SP 在设计自己的支付系统时,只需将原有直接调用移动BOSS 接口的部分改为调用支付中间平台接口,其它部分不需要做任何的改动,支付中

6、间平台的设计思想不但解决了每个商户 SP 各自为政,自己独立开发支付系统,需要让用户分别记住每个服务提供商的平台地址并进行相应的支付操作的问题,同时还使得每个新商户 SP的接人变得非常的简单,增强了支付中间平台对商户 SP 支付系统的可扩展性。每个新接人的商户 SP 只要按照相关的协议规定,调用支付中间平台的公共接口,并把基本信息告诉支付中间平台,就可以实现接人。 (二)性能优化策略 为了提高支付中间平台的性能,采用异步长连接的方式来实现与商户 SP 及移动 BOSS之间的连接。所谓异步长连接就是客户端与服务端建立连接后,保持连接状态,请求方在没有收到响应的情况下,可以发起多个请求,处理方可以

7、并行处理,按任意顺序返回给请求方处理结果。同时,为了提高支付中间平台在接人商户 SP 时的可扩展性,采用分层收发请求策略。这样可以为每一个首次建立连接的商户 SP 建立一个属于商户 SP 自己专有的发送队列及接收队列,所有的发送请求首先要加入发送队列,这是第一层。第二层是一个所有商户 SP 公共的发送及接收队列,来存放接收自不同商户发送队列的信息,并统一将请求发送给移动 BOSS。当移动 BOSS 处理完请求并返回结果时,返回的信息将首先存放到第二层公共的接收队列里,接收队列收到信息会根据一定的标识策略分发给所属商户 SP 的接收队列,然后商户 SP 接收队列再将信息发送给相应的商户 SP。为

8、了进一步实现并发控制,并提高支付中间平台与移动 BOSS 之间的系统资源利用率,更进一步的提升系统性能,支付中间平台在与移动 BOSS 建立连接时会同时创建多个异步长连接实例,这样一来,不管是在时间、空间,还是在系统资源利用率方面都可以做到最大程度的利用,大大提高系统自身及系统之间的性能,优化整套系统的体系结构。 (三)安全性策略 为了确保数据传递的安全性,对整个支付流程采用如下安全策略:第一、支付中间平台在数据传输方式上选择基于CP/IP 的 Socket 进行系统及平台之间的互联互通,在一定程度上可提高系统自身数据传输的安全性,而且平台会对不同的 IP 地址请求做出相应的安全策略,增加部分

9、鉴权机制,最大程度地降低支付中间平台所存在的安全隐患。第二、商户 SP 与支付中间平台之间通过公网进行数据传输。这样可增加支付中间平台的可扩展性,商户的接人将不受空间和时间的限制。但这样做存在着许多安全隐患,为了确保数据传输的正确性,在传输前对某些协议规定的信息进行 MD5 或 RSA 加密,另外,引入超时处理机制,以确保数据传输过程中的实时性,避免在整个传输过程中因某些不可预测因素而造成的数据包丢失。数据包在传递过程中如果发生超时,将根据协议规定的超时策略进行处理,第三、支付中间平台与移动 BOSS 之间通过专线进行数据传输,以避免数据传输过程中遇到的许多安全隐患,如数据被恶意截获、篡改等,

10、同样,为了确保数据传输过程的实时性,避免整个传输过程中因某些不可预测因素造成的数据包丢失,在这里也对数据包请求超时做相应的处理。 三、 平台支付协议设计 (一)平台与移动 BOSS 的支付协议 该部分的支付协议中,设 BOSS 的监听端口为 6666,移动 BOSS 作为 SOCKET 服务端,支付中间平台作为 SOCK-ET 客户端,双方通过握手报文保持连接,握手间隔 1 分钟。数据包采用包头包体的格式。 1包头格式。 包头为定长包头,如占 40 个字节,包含乎台代码、包长、功能码、加密标志、交易时间、业务返回码、序列号和后续包标志等信息。其中,平台代码固定填写“PAY” 。功能码包括注册申

11、请,注销申请、用户鉴权、话费缴费、退货接口、充值卡缴费、话费缴费冲正、可划转余额查询等 8 种,每种功能都有相应的 4 位 ACSII 码值,如话费缴费为 0201。它们的业务超时时间都设定为 30 秒,即支付平台发起请求后超过 30 秒就认为业务失败,加密标志中,0 为不加密,1 为加密。交易过程中,支付平台发送交易请求包时,填写请求时间;BOSS 发送交易应答包时,填写响应时间,业务返回码中,应答报文 100 表示成功,其他失败,请求报文填写 000。序列号是异步连接过程中该条请求信息在整个支付活动中的唯一标识,对于后续包标志,只在交易数据超过 1024 字节时使用,进行分包传输,循环发送

12、与接受,发送方除最后一个包的后续包标志置 0 外,前面所有包的后续包标志置 1;接收方循环接收并发送应答,直至收到的交易包的后续包标志为 0 时为止,循环过程结束,接收方的应答包是仅有包头的空包。2包体格式。 包体为变长包体,在以上 8 种功能中,针对不同的功能请求,其请求包与应答包包体的格式有所不同,其中,除了可划转余额查询功能的应答包包体包含用户可用余额和可划转余额两项内容外,其余功能的应答包包体均为空,另外,可根据应答包包头的“业务返回码”来判定业务是否办理成功,现以话费缴费(0201)为例加以说明:话费缴费功能的请求包包体包括手机号码、划转请求金额、订单编号等信息,订单编号不可重复,其

13、格式为:YYMMDD顺序增长 ID(YYMMDD 和 ID 间补零凑足 12 字节),例如:090106000001。所有涉及到金额的地方全部以分为单位,该功能的应答包中,应答包包头返回码为 100 时,判定业务办理成功;为 999 时,判定业务办理失败,为 404 时,判定业务办理超时。应答包包体为空。 (二)与商户 SP 的支付协议 该部分的支付协议中,设支付平台监听端口为 9999,网络超时时间为 60 秒。支付平台作为服务端,商户系统作为客户端,所有交易都由客户端发起请求,服务端应答。客户端启动后发送登录请求报文,在收到服务端的登录成功应答报文后可以进行话费缴费、冲正、退货等交易,客户

14、端退出前发送注销请求并在接收到服务端应答后退出,其数据包也采用包头包体的格式,其包头与第一部分支付协议中的格式相同。包体格式只是在内容上有所不同。移动终端的不断发展,使得利用移动终端进行商务活动成为了可能,提出了一种基于WAP 并利用手机预存话费进行小额支付的中间平台的设计理念,从可扩展性、性能优化及安全性三方面给出了中间平台的构建策略。并对平台支付协议进行了设计,为移动商务的发展提出了一个较好的解决方案。参考文献:1王影,于凌云:安全电子服务研究.微机发展,2005,10(2)2赵影:基于 WAP 的移动电子商务安全性研究J.内蒙古科技与经济,2005,12(3)3储节旺,郭春侠:移动电子商务研究J.现代情报,2002,3(3)4姜志,聂志锋:移动电子商务及其关键技术J.湖北邮电技术,2002,9(3)

展开阅读全文
相关资源
正为您匹配相似的精品文档
相关搜索

最新文档


当前位置:首页 > 行业资料 > 其它行业文档

电脑版 |金锄头文库版权所有
经营许可证:蜀ICP备13022795号 | 川公网安备 51140202000112号