银行POS收单系统联机系统的设计与实现
第 1 章 绪论
本章的主要内容包括项目的来源、项目开发的目的和意义、国内外相关领域现状分析以及本项目的主要工作内容四部分。
1.1项目开发目的和意义
银行原始的收单系统支持方式单一，不能给商户带来便利。本次 POS 收单系统主要针对信用卡，是为了实现银行业务的支持方式的多样性的其中一个环节，鉴于信用卡的优点，使银行的商户可以选择各种适宜自己的支付方式，同时，开发新的独立的信用卡支付系统也便于银行自身统计每种支付方式在商户应用中的频率，对银行自身更便利的服务商户提供数据基础。提升银行的交易效率，提高用户的用户体验。
1.2 本文主要工作内容
本项目的主要任务是完成银行POS收单系统中联机系统的开发部分。
银行信用卡POS收单系统对本银行信用卡的间连POS收单需要实现的功能包括：
(1)对本行信用卡的交易受理；
(2)对本行信用卡交易的日终对账及差错处理；
(3)对本行信用卡交易的资金清分清算；
(4)对本行信用卡交易的业务管理功能。
根据需要实现功能的不同，将本系统分为3个子系统：
(1)联机系统，完成本行信用卡对支持的交易的受理；
(2)日终系统，完成本行信用卡产生的交易的日终对账、清分清算操作；
(3)控制台系统，完成本行信用卡交易的业务管理。
由参考文献以银联支付系统的总体逻辑架构，一个基本的银联支付系统的逻辑架构图如图1-1所示。
根据这个逻辑架构图，银行信用卡 POS 收单系统由三部分组成：联机系统、日终系统、控制台系统。联机系统部分主要负责的是本银行或者其他银行信用卡在本行 POS机上产生的各种交易进行功能的实现。同时，对产生的各类交易进行日志流水记录，生成流水文件供日终系统对当日或当月等一段时间内的交易流水进行日终统计、清分清算或批量处理等处理。
第 2 章 需求分析与系统总体设计
本章主要论述银行 POS 收单系统联机系统的需求分析和总体设计方面的内容，其中需求分析分为业务需求和功能需求；总体设计方案将给出系统整体上的模块设计方案。
2.1 系统需求
本系统的系统需求将分为两个，业务需求和功能需求，由参考文献得到下面介绍的两种需求的具体内容。
2.1.1 系统业务需求
POS 收单系统联机部分将信用卡交易上送总行贷记卡的前置系统，并转接到信用卡系统进行处理。交易处理流程分为以下四部分：
(1) POS 业务系统接收 POS 终端发送的交易请求；
(2) 通过交易检查后，根据转接规则将交易转发给相关系统；
(3) 接收相关系统返回的交易应答；
(4) 将交易应答转发给 POS 终端。
各系统间交易转接示意图2-1所示。
信用卡POS收单系统中联机系统所支持的交易如表2-1 所示。
2.2 总体设计方案
总体设计方案中分别介绍联机系统的整体设计方案以及每个模块中各个子模块的整体设计方案。
2.2.1 联机系统整体方案
POS 终端上传标准 8583 报文之后，根据对 8583 报文处理的需要将联机系统划分为两个子模块GPOSP和GFRONT，其中GPOSP模块负责对上传的报文进行8583规范转换，GFRONT 模块则对规范处理后的报文进行内部核心结构的转换、发送路径选择以及通信。
GPOSP 模块的各个子模块系统结构图如图 2-2 所示。
图中POS终端即为需要上传报文的POS机，COMMNAC模块和COMMGold模块是通信模块，分别与 POS 机和 GFRONT 通信，Switch 模块是对刚上送的报文进行转换，这部分的转换只是对报文进行一些必要的处理，添加该报文在 GFRONT 模块内部传送必要的报文头等信息，ToCtl 模块是对报文转换模块Switch的超时控制，其中，当报文从POS终端上送时进行的是超时等级操作，当报文从GFRONT模块返回时进行的是解超时操作。
GFRONT 模块的各个子模块系统结构图如图 2-3 所示。
GFRONT 模块对报文的处理主要进过 Bridge 路由桥接模块，Switch 转换模块，PacSend 包发送模块以及 Comm 通信模块。CommP 是与 GPOSP 进行通信的模块，接收过来的报文首先经过路由桥接模块 Bridge，查找该条交易在系统内部传送的模块路径，Swt 模块根据不同交易分为 SwtDBT、SwtNEW、SwtEMU 等不同处理模块，模块内部选择通过路由桥接模块进行处理，分别对应每种交易的转换规则对 8583、xml 或者自定义报文进行解析。报文经过内部转换、处理、提取之后，通过 PacSend 模块发往通信模块Comm，此通信模块也有几部分构成如CommCUP、CommB、CommH等与不同前置通信的模块，根据交易类型报文发往前置的不同系统。另外，GFRONT 模块在含有超时控制模块的同时也含有HSM验证模块，主要在Swt过程中进行MAC校验、支持判断、磁密信息校验、卡现实检查、限额检查和客户化检查等。
第 3 章 系统详细设计与实现 ........................... 17
3.1 GPOSP 和 GFRONT 模块中数据库的设计与实现 ...................... 18
3.1.1 ISO8583转换规则数据库设计与实现 ......... 18
3.1.2 BufChg报文转换数据库设计与实现 ................... 20
第 4 章 系统测试与性能分析 ................... 45
4.1 测试环境 ....................... 45
4.2 功能性测试 ................. 45
4.2.1 POS查询 ....................... 45
第 5 章 结 论 .................52
第 4 章 系统测试与性能分析
本系统的业务逻辑和流程都比较简易，主要是一些功能性的东西，实现起来技术难度较高，比较复杂，但是测试和使用起来都比较简易。这里简易介绍一下本系统的测试过程。系统采用黑盒测试，因为系统在开发过程中已经对各个模块分别进行了测试，所以这里只对系统的主要功能进行集成测试。
4.1 测试环境
软件环境：操作系统AIX，版本5.3 ；数据库DB2，版本9.1； 硬件环境：新国都、新大陆POS 机各一台，远程连接电脑一台。
第 5 章 结 论
本系统通过在 Linux 操作系统下使用 C 语言和 DB2 数据库经过半年完成。系统的主要成果是实现了银联标准和银行指定的银行IC卡、信用卡等磁条卡在POS机上的相应消费查询等常用 POS 功能，且与 POS 收单系统的其他子系统形成接口，为清算、差错平台等的数据提供有力支持。
整个系统在设计过程中主要有三个优点
(1)银联和银行报文区分处理，系统在处理银联标准报文时将银联标准上送报文和系统自身处理报文这两个过程分别独立，通过接口连接，很明确的区分了银联和行内的处理方式；
(2)报文在某一模块内独立处理，分别在不同的模块中的报文在该模块中流转的过程中，对报文的每一步处理都是独立的，这种创新，使得在系统在出错时，在调试过程中能够以最短的时间找到问题根源，并且根据报文内容分析出错误的原因；
(3)系统报文流转采用日志记录，报文的每一步变更流转采用日志记录，同样系统在DEBUG 阶段根据每一步变更流转的报文可以很容易分析出报文在运行时是否正确以及出错如何排查；
但是这几个创新性也同样有几个缺点，但是在平衡系统运行稳定性方面，还是利大于弊的，其中最大的缺点是对系统开发人员在银联标准等业务方面的水平要求较高，不仅考虑专业知识同时也要对银联的知识十分了解。
论文中的系统由于时间的限制在今后的应用实践中还需要更多的改进，尽量在保持优点的同时改进仍然存在的弊端。另外，在 POS 收单类系统中本论文中涉及到的设计方案在该类系统中还需要很长时间的适应性，并且不断学习别的系统在该类系统设计中的优秀的设计方案，集众方案的优点并不断改进才能使 POS 收单类系统不断完善，实现功能更全面，安全性更高的优秀系统。
参考文献（略）