呼叫中心电子支付系统研究与设计
开篇：润墨网以专业的文秘视角，为您筛选了一篇呼叫中心电子支付系统研究与设计范文，如需获取更多写作素材，在线客服老师一对一协助。欢迎您的阅读与分享！
摘要：以航空公司呼叫中心电子支付系统的开发为背景，根据呼叫中心电子支付的实际业务需求，基于J2EE框架结构完成了整个呼叫中心电子支付系统的设计与实现，着重对电子支付系统的接口设计、交易异常的处理、安全性设计进行了分析。航空公司呼叫中心电子支付系统的实际应用表明，该系统达到了设计目标，并成功的实施与运行，对航空公司呼叫中心电子支付业务开展起到了积极的推动作用，对企业开发类似信息系统具有一定的借鉴意义。
关键词：航空公司；呼叫中心；电子支付；电话支付；手机支付
中图分类号：TP393 文献标识码：A 文章编号：1009-3044（2013）13-3040-03
现代企业都注重电子商务和直销渠道的拓展，而网站和呼叫中心正是电子商务的两条重要渠道。现在的许多呼叫中心早已不是以前的单纯以服务为主要业务的成本中心，而是转型为以销售为主的利润中心。随着移动电话的普及，通过手机、电话等进行营销，依然有着沟通交流方便快捷的优势，许多公司都通过呼叫中心销售其生产的产品或服务。因此，完善呼叫中心的电子支付系统，对支撑呼叫中心销售业务的开展具有重要的意义。对比网站的在线支付，呼叫中心的电子支付具有更悠久的历史和成熟的经营模式，而且具备独特的安全性。通过对这一领域系统的开发和不断完善，可以大力推动呼叫中心发挥其在电子商务中的重要作用。
1 呼叫中心电子支付业务需求分析
1.1 业务概述
呼叫中心电子支付主要包括三种支付方式：无卡POS支付、电话支付、手机支付。
无卡POS支付是通过在POS机上手工输入卡片信息进行支付的方式，支付过程中，不需要实体卡片的出现，因此称为无卡POS。这种方式由于需要手工输入，并通过POS机和银行进行通信交易，耗时长，支付效率低，且需要安装POS机，成本高。因此只在早期的时候有使用，现在主要是作为特殊情况下的备份支付方式。
电话支付是通过和银行支付网关或第三方支付平台直接连接，将支付卡片信息传递到银行进行支付的方式，只针对信用卡，而且也是无卡支付，只需要收集卡片信息，不需要出示卡片。具有快速、便捷的特点，是目前主流的支付方式。
手机支付，是专门针对借记卡的支付方式，采用非实时、异步支付方式。呼叫中心收集卡片信息和支付手机号，然后将支付请求提交给银行，银行外呼持卡人手机，并通过自助语音服务，由持卡人输入密码完成支付，银行再将支付结果反馈给呼叫中心。该方式主要用于覆盖没有信用卡，但持有借记卡的用户，且安全性高，主要缺点是非实时、异步方式，且需要持卡人参与，导致支付耗时长，容易产生支付失败。
另外，在呼叫中心开展电子支付业务需要具备以下条件：
呼叫中心的运营不仅仅以服务为目的，需要具备销售职能，销售才能产生电子支付需求。
单笔支付额和整体交易量都需达到一定规模。过小的支付额和交易量，会使客户、商家、银行都失去使用电子支付的意愿。以开展这项业务的航空业为例，单张机票金额在成百上千元人民币，每日有大量的机票销量，产生大量的交易金额。
呼叫中心销售的产品、服务必须具备实名制和可追朔性。出于电子支付安全性的考虑，实名制和可追朔性的产品将有力的规避电子支付的风险和欺诈行为。如机票，不仅在购买时是实名制，在办理值机手续、安检等环节都有严格的身份验证，有效避免冒用，并可追朔。
因此，开展这些业务的往往是航空业和保险业。其它行业如果具备以上条件，也可考虑开展电子支付。
2.2 系统接口设计
电子支付系统最核心的部分，就是与银行、第三方支付平台等支付网关之间的接口。保证双方交易事务的准确性、一致性，是整个系统的关键。因此，交易接口的逻辑规则和对异常情况的处理是非常重要的，需要双方进行明确的约定，以下是对接口设计的探讨。
2.2.1 交易接口的逻辑规则
以电子支付系统最常见的三种交易接口的逻辑规则进行介绍。
支付接口：1）支付准备：支付系统首先生成双方唯一的“请求序列号”，并记录在数据库中；2）支付请求：支付系统将订单号、卡号、有效期、校验码、金额等数据和请求序列号一并发送给银行支付网关；3）银行支付网关收到请求后，记录在数据库中，然后进行卡片信息、余额等验证，并进行扣款等业务处理，支付成功后，支付网关将“支付成功”的结果，以及“交易流水号”、“请求序列号”一并反馈给支付系统，如果校验不通过，未进行扣款，则支付失败，支付网关将“支付失败”的结果，以及失败原因、“请求序列号”一并反馈给支付系统；4）支付系统收到结果后，核对“请求序列号”，并将“支付成功”或“支付失败”的结果记录入库。
查证接口：当交易出现异常时，需向银行支付网关查证交易结果。1）支付系统将之前记录在数据库中的“请求序列号”，发送给银行支付网关；2）银行支付网关查询该笔请求的交易结果，并将结果返回；3）支付系统根据返回的结果记录入库。如果查证不成功，可多次反复发起查证，查证接口可支持支付、退款、当日撤销等多种交易接口的查证。
退款接口：1）退款准备：支付系统首先生成双方唯一的“请求序列号”，并记录在数据库中；2）退款请求：支付系统将之前支付成功的“交易流水号”、退款金额等数据和请求序列号一并发送给银行支付网关；3）银行支付网关收到请求后，记录在数据库中，然后进行交易信息、退款金额等验证，并进行退款等业务处理，退款成功后，支付网关将“退款成功”的结果，以及“交易流水号”、“请求序列号”一并反馈给支付系统，如果校验不通过，未进行退款，则退款失败，支付网关将“退款失败”的结果，以及失败原因、“请求序列号”一并反馈给支付系统；4）支付系统收到结果后，核对“请求序列号”，并将“退款成功”或“退款失败”的结果记录入库。
2.2.2 交易异常的处理
在电子支付系统中，由于交易的准确性和资金的安全性至关重要，因此对接口的各种异常情况需要进行充分的考虑。在交易过程中，虽然产生交易异常的原因多种多样，但按照异常发生的环节归纳起来大致可分为三类：一是交易传输过程中的异常，例如请求超时，网络中断、报文格式有误等。二是银行支付网关内部程序抛出异常，主动返回“交易异常”， 要求支付系统后续进行查证。三是支付系统自身程序抛出异常，例如数据库记录错误、日志记录错误、IO异常等，需要后续进行查证。
对异常的处理，在许多电子支付系统中都是非常复杂的。大量设计、开发人员的主要精力都不是在接口的业务逻辑实现上，而是在对各种异常情况的处理上。因此，有的系统只提示异常，不对异常进行处理，交给业务人员人工干预，甚至有的系统还需要业务人员自己每天在大量交易数据中进行筛选、比对，查找出异常的数据。这样的方式远远不能满足一个有着大量支付交易的系统日常运转，不仅需要业务人力的投入，而且遇到异常就需要人工干预，线下查账核对，影响业务开展。本系统经过多年实践、改进，总结出无论是系统主动抛出的可捕获的异常，还是遭遇最极端的程序出现灾难性故障，无法捕获异常，导致交易不完整的情况，其实都可以通过加强系统、程序的健壮性，加强对异常的逻辑处理规则由系统自动进行处理，基本不需要人工干预。前提是要遵循以下几条原则：
1） 支付系统和银行支付网关双方要对交易接口的逻辑规则进行严格、清晰的定义。
2） 支付系统和银行支付网关双方要保证自身在对交易请求的处理上，内部事务处理结果要和反馈回的结果始终保持一致，即符合原子性、一致性、独立性、持久性。
3） 支付系统和银行支付网关双方要对“支付成功”、“支付失败”、“支付异常”的含义进行明确约定。
4） 支付系统自身要对各种能捕获的异常进行定义，并明确后续处理流程。
5） 支付系统自身通过对业务逻辑、数据完整性检验，即时遭遇最极端的程序出现灾难性故障，无法捕获异常，也能根据不完整的交易记录，对异常进行处理。
2.3 安全性
电子支付系统包含了大量的账户信息、客户信息、交易信息等敏感数据，保障安全性是非常必要的。建立完善的安全体系要综合考虑各方面因素，如管理方面包括符合国家法律法规，规范业务流程、实施软件全生命周期安全、健全运维体系等，系统方面包括体系架构、物理环境、网络安全、应用安全、数据安全、交易安全等。而且各方面是相互配合、逐步改进、不断提升的安全体系。
本系统在应用级安全机制主要包括：用户角色控制、功能权限控制、日志记录，数据传输和存储加密。
接口用户认证：使用SSL、电子证书身份认证、防止抵赖和信息完整性。
加锁机制：在业务操作层面采用悲观锁的方式、在数据库层面采用乐观锁的方式，既能有效避免业务并发引起的事务竞争风险，又可防止在数据库层面采用过严的锁导致死锁问题或引发性能问题。
3 结束语
该系统经过在航空公司呼叫中心多年的开发、不断改进完善，已经成为航空公司呼叫中心开展电子支付不可或缺的关键系统。每年为支撑呼叫中心的各项销售任务，完成销售指标，提供的有力的系统支撑。同时，也为航空公司拓展直销渠道，提升销售业务发挥了重要作用。
参考文献：
[1] 帅青红.电子支付与结算[M].大连：东北财经大学出版社有限责任公司，2011.
[2] 曹红辉.中国电子支付发展研究[M].2版. 北京经济管理出版社，2012.
[3] 徐天宇.电子商务系统规划与设计[M].2版.北京：清华大学出版社，2010.
[4] 宫小全.电子商务系统分析与设计[M].北京：北京交通大学出版社，2010.
[5] 帅青红.电子支付与安全[M].成都：西南财经大学出版社，2009.
[6] 张新谊.电子支付与信息安全实践教程[M].北京：清华大学出版社，2012.
[7] 吴镝.J2EE应用开发实例精解：WAS+RAD[M].北京：清华大学出版社，2011.
[8] 陈松.J2EE电子商务系统开发从入门到精通[M].北京：清华大学出版社，2007.