论文网
关于电子商务方面论文例文,与呼叫中心电子支付系统与设计相关论文摘要
本论文是一篇关于电子商务方面论文摘要,关于呼叫中心电子支付系统与设计相关学年毕业论文范文。免费优秀的关于电子商务及数据库及电子商务系统方面论文范文资料,适合电子商务论文写作的大学硕士及本科毕业论文开题报告范文和学术职称论文参考文献下载。
摘 要：以航空公司呼叫中心电子支付系统的开发为背景,根据呼叫中心电子支付的实际业务需求,基于J2EE框架结构完成了整个呼叫中心电子支付系统的设计与实现,着重对电子支付系统的接口设计、交易异常的处理、安全性设计进行了分析.航空公司呼叫中心电子支付系统的实际应用表明,该系统达到了设计目标,并成功的实施与运行,对航空公司呼叫中心电子支付业务开展起到了积极的推动作用,对企业开发类似信息系统具有一定的借鉴意义.
关 键 词：航空公司；呼叫中心；电子支付；支付；手机支付
中图分类号：TP393文献标识码：A文章编号：1009-3044（2013）13-3040-03
现代企业都注重电子商务和直销渠道的拓展,而网站和呼叫中心正是电子商务的两条重要渠道.现在的许多呼叫中心早已不是以前的单纯以服务为主要业务的成本中心,而是转型为以销售为主的利润中心.随着移动的普及,通过手机、等进行营销,依然有着沟通交流方便快捷的优势,许多公司都通过呼叫中心销售其生产的产品或服务.因此,完善呼叫中心的电子支付系统,对支撑呼叫中心销售业务的开展具有重要的意义.对比网站的在线支付,呼叫中心的电子支付具有更悠久的历史和成熟的经营模式,而且具备独特的安全性.通过对这一领域系统的开发和不断完善,可以大力推动呼叫中心发挥其在电子商务中的重要作用.
1呼叫中心电子支付业务需求分析
1.1业务概述
呼叫中心电子支付主要包括三种支付方式：无卡POS支付、支付、手机支付.
无卡POS支付是通过在POS机上手工输入卡片信息进行支付的方式,支付过程中,不需要实体卡片的出现,因此称为无卡POS.这种方式由于需要手工输入,并通过POS机和银行进行通信交易,耗时长,支付效率低,且需要安装POS机,成本高.因此只在早期的时候有使用,现在主要是作为特殊情况下的备份支付方式.
支付是通过和银行支付网关或第三方支付平台直接连接,将支付卡片信息传递到银行进行支付的方式,只针对信用卡,而且也是无卡支付,只需要收集卡片信息,不需要出示卡片.具有快速、便捷的特点,是目前主流的支付方式.
手机支付,是专门针对借记卡的支付方式,采用非实时、异步支付方式.呼叫中心收集卡片信息和支付手机号,然后将支付请求提交给银行,银行外呼持卡人手机,并通过自助语音服务,由持卡人输入密码完成支付,银行再将支付结果反馈给呼叫中心.该方式主要用于覆盖没有信用卡,但持有借记卡的用户,且安全性高,主要缺点是非实时、异步方式,且需要持卡人参与,导致支付耗时长,容易产生支付失败.
另外,在呼叫中心开展电子支付业务需要具备以下条件：
呼叫中心的运营不仅仅以服务为目的,需要具备销售职能,销售才能产生电子支付需求.
单笔支付额和整体交易量都需达到一定规模.过小的支付额和交易量,会使客户、商家、银行都失去使用电子支付的意愿.以开展这项业务的航空业为例,单张机票
关于电子商务方面论文例文
本文出处 http://www.sxsky.net/benkelunwen/06085302.html
呼叫中心销售的产品、服务必须具备实名制和可追朔性.出于电子支付安全性的考虑,实名制和可追朔性的产品将有力的规避电子支付的风险和欺诈行为.如机票,不仅在购买时是实名制,在办理值机手续、安检等环节都有严格的身份验证,有效避免冒用,并可追朔.
因此,开展这些业务的往往是航空业和保险业.其它行业如果具备以上条件,也可考虑开展电子支付.
2.2系统接口设计
电子支付系统最核心的部分,就是与银行、第三方支付平台等支付网关之间的接口.保证双方交易事务的准确性、一致性,是整个系统的关键.因此,交易接口的逻辑规则和对异常情况的处理是非常重要的,需要双方进行明确的约定,以下是对接口设计的探讨.
2.2.1交易接口的逻辑规则
以电子支付系统最常见的三种交易接口的逻辑规则进行介绍.
支付接口：1）支付准备：支付系统首先生成双方唯一的“请求序列号”,并记录在数据库中；2）支付请求：支付系统将订单号、卡号、有效期、校验码、金额等数据和请求序列号一并发送给银行支付网关；3）银行支付网关收到请求后,记录在数据库中,然后进行卡片信息、余额等验证,并进行扣款等业务处理,支付成功后,支付网关将“支付成功”的结果,以及“交易流水号”、“请求序列号”一并反馈给支付系统,如果校验不通过,未进行扣款,则支付失败,支付网关将“支付失败”的结果,以及失败原因、“请求序列号”一并反馈给支付系统；4）支付系统收到结果后,核对“请求序列号”,并将“支付成功”或“支付失败”的结果记录入库.
查证接口：当交易出现异常时,需向银行支付网关查证交易结果.1）支付系统将之前记录在数据库中的“请求序列号”,发送给银行支付网关；2）银行支付网关查询该笔请求的交易结果,并将结果返回；3）支付系统根据返回的结果记录入库.如果查证不成功,可多次反复发起查证,查证接口可支持支付、退款、当日撤销等多种交易接口的查证.
退款接口：1）退款准备：支付系统首先生成双方唯一的“请求序列号”,并记录在数据库中；2）退款请求：支付系统将之前支付成功的“交易流水号”、退款金额等数据和请求序列号一并发送给银行支付网关；3）银行支付网关收到请求后,记录在数据库中,然后进行交易信息、退款金额等验证,并进行退款等业务处理,退款成功后,支付网关将“退款成功”的结果,以及“交易流水号”、“请求序列号”一并反馈给支付系统,如果校验不通过,未进行退款,则退款失败,支付网关将“退款失败”的结果,以及失败原因、“请求序列号”一并反馈给支付系统；4）支付系统收到结果后,核对“请求序列号”,并将“退款成功”或“退款失败”的结果记录入库.
2.2.2交易异常的处理在电子支付系统中,由于交易的准确性和资金的安全性至关重要,因此对接口的各种异常情况需要进行充分的考虑.在交易过程中,虽然产生交易异常的原因多种多样,但按照异常发生的环节归纳起来大致可分为三类：一是交易传输过程中的异常,例如请求超时,网络中断、报文格式有误等.二是银行支付网关内部程序抛出异常,主动返回“交易异常”,要求支付系统后续进行查证.三是支付系统自身程序抛出异常,例如数据库记录错误、日志记录错误、IO异常等,需要后续进行查证.
对异常的处理,在许多电子支付系统中都是非常复杂的.大量设计、开发人员的主要精力都不是在接口的业务逻辑实现上,而是在对各种异常情况的处理上.因此,有的系统只提示异常,不对异常进行处理,交给业务人员人工干预,甚至有的系统还需要业务人员自己每天在大量交易数据中进行筛选、比对,查找出异常的数据.这样的方式远远不能满足一个有着大量支付交易的系统日常运转,不仅需要业务人力的投入,而且遇到异常就需要人工干预,线下查账核对,影响业务开展.本系统经过多年实践、改进,总结出无论是系统主动抛出的可捕获的异常,还是遭遇最极端的程序出现灾难性故障,无法捕获异常,导致交易不完整的情况,其实都可以通过加强系统、程序的健壮性,加强对异常的逻辑处理规则由系统自动进行处理,基本不需要人工干预.前提是要遵循以下几条原则：
1）支付系统和银行支付网关双方要对交易接口的逻辑规则进行严格、清晰的定义.
2）支付系统和银行支付网关双方要保证
关于电子商务方面论文例文,与呼叫中心电子支付系统与设计相关论文摘要参考文献资料：