第三方支付平台系统_概要设计

系统概要设计说明书
XXX信息技术有限公司
2013年9月
文档控制页版本记录
目录
第一章引言 (3)
1.1 目的 (3)
1.2 背景 (3)
1.3 术语定义 (4)
1.4 参考资料 (4)
第二章系统环境 (5)
1.5 运行环境 (5)
1.1.1 系统支撑环境 (5)
1.1.2 部署图 (5)
1.1.3 系统接口...................................................................................... 错误!未定义书签。

1.1.4 系统安全控制.............................................................................. 错误!未定义书签。

1.6 运行模块组合.................................................................................. 错误!未定义书签。

1.7 运行环境的配置.............................................................................. 错误!未定义书签。

1.8 条件与限制...................................................................................... 错误!未定义书签。

第三章系统总体结构设计. (7)
1.9 系统结构设计描述 (7)
1.10 总体结构图 (8)
1.11 功能需求与程序的关系 (9)
1.12 子系统清单 (26)
第四章模块功能分配 (12)
1.13 系统划分及功能描述 (14)
1.14 专用模块功能概述.......................................................................... 错误!未定义书签。

1.15 公用模块功能概述.......................................................................... 错误!未定义书签。

1.1.5 版本控制管理.............................................................................. 错误!未定义书签。

1.1.6 帮助模块...................................................................................... 错误!未定义书签。

第五章数据库设计.. (42)
1.16 逻辑视图.......................................................................................... 错误!未定义书签。

1.17 数据库表关系图 (42)
1.18 数据表清单 (48)
1.19 主要算法设计 (50)
1.20 其它数据结构设计 (50)
第六章接口设计 (51)
1.21 用户接口 (51)
1.22 内部接口 (53)
1.23 外部系统接口 (53)
第七章安全保密设计.................................................................................. 错误!未定义书签。

1.24 用户管理和权限控制...................................................................... 错误!未定义书签。

第八章维护及出错处理设计. (54)
1.25 系统维护设计 (54)
1.26 出错信息 (54)
1.27 出错处理.......................................................................................... 错误!未定义书签。

1.28 系统故障预防与恢复...................................................................... 错误!未定义书签。

1.29 数据备份与恢复 (56)
第九章设计约束.......................................................................................... 错误!未定义书签。

1.30 字节集编码约束.............................................................................. 错误!未定义书签。

1.31 操作系统约束.................................................................................. 错误!未定义书签。

1.32 其他约束.......................................................................................... 错误!未定义书签。

第十章附件.. (58)
评审意见.......................................................................................................... 错误!未定义书签。

第一章引言
1.1目的
《XX第三方支付平台系统—概要设计》依照《XX第三方支付平台系统—需求规格说明书》中对系统功能的需求描述，细化需求规格说明书中所涉及的功能需求，将需求描述分割成具体的实现模块，为后续的详细设计提供明确的功能、流程概述和设计依据，为编码人员了解当前编写的功能模块在整个系统中所处的位置提供详尽的文档说明。

预期读者：开发人员。

1.2背景
第三方支付具有显著的特点：
第一第三方支付平台提供一系列的应用接口程序，将多种银行卡支付方式整合到一个界面上，负责交易结算中与银行的对接，使网上购物更加快捷、便利。

消费者和商家不需要在不同的银行开设不同的账户，可以帮助消费者降低网上购物的成本，帮助商家降低运营成本；同时，还可以帮助银行节省网关开发费用，并为银行带来一定的潜在利润。

第二较之SSL、SET等支付协议，利用第三方支付平台进行支付操作更加简单而易于接受。

SSL是应用比较广泛的安全协议，在SSL中只需要验证商家的身份。

SET协议是发展的基于信用卡支付系统的比较成熟的技术。

但在SET中，各方的身份都需要通过CA进行认证，程序复杂，手续繁多，速度慢且实现成本高。

有了第三方支付平台，商家和客户之间的交涉由第三方来完成，使网上交易变得更加简单。

第三第三方支付平台本身依附于大型的门户网站，且以与其合作的银行的信用作为信用依托，因此第三方支付平台能够较好地突破网上交易中的信用问题，有利于推动电子商务的快速发展。

任务提出者：XXXX信息技术有限公司
开发者：XXXX信息技术有限公司项目组
用户：XX签约商户、持卡人、业务运营人员
1.3术语定义
1.4参考资料
第二章系统环境
2.1运行环境
2.2部署图
结合总体结构图，不同类型的的服务对部署提出了不同的需求，比如交互服务要求公网可访问、可以快速变化；核心的业务功能服务则要求稳定、具有海量吞吐能力；
外部合作服务可能要求特殊的网络访问方式。

由于不同的服务有不同的部署要求，采用分布式部署，通过分布式服务间的协作实现业务流程。

为了支撑可用的服务协作网络，平台采用以服务为单元的部署架构。

每一个服务是一个独立的或多台物理机器组成的集群；服务与服务之间是松耦的，它们具有不同的服务功能、发布策略、管理策略与软硬件基础。

第三章系统总体设计
3.1系统结构设计描述
支付平台作为第三方支付企业的核心服务包括三方面：
1、对客户提供电子货币支付、结算服务；
2、与银行一起完成电子货币与真实货币的转换/清算；
3、协助银行完成客户的的真实货币结算；
为了满足互联网金融服务系统的快速变化与高度稳定的要求，同时也借鉴了支付宝的经验，将系统设计为面向服务的架构，系统引入了阿里巴巴开源服务框架Dubbo。

Dubbo是一个分布式服务框架，致力于提供高性能和透明化的RPC远程服务调用方案，以及SOA服务治理方案。

其核心部分包含:
远程通讯: 提供对多种基于长连接的NIO框架抽象封装，包括多种线程模型，序列化，以及“请求-响应”模式的信息交换方式。

集群容错: 提供基于接口方法的透明远程过程调用，包括多协议支持，以及软负载均衡，失败容错，地址路由，动态配置等集群支持。

自动发现: 基于注册中心目录服务，使服务消费方能动态的查找服务提供方，使地址透明，使服务提供方可以平滑增加或减少机器。

Dubbo能做什么？
透明化的远程方法调用，就像调用本地方法一样调用远程方法，只需简单配置，没有任何API侵入。

软负载均衡及容错机制，可在内网替代F5等硬件负载均衡器，降低成本，减少单点。

服务自动注册与发现，不再需要写死服务提供方地址，注册中心基于接口名查询服务提供者的IP地址，并且能够平滑添加或删除服务提供者。

3.2总体结构图
3.3功能需求与程序的关系
3.4实体模型描述
3.4.1会员
3.4.1.1会员实体
记录会员基本信息，身份证，登录名，姓名等。

3.4.1.2会员账户
会员的在支付平台系统的账户信息，包含账户余额，账户类型等信息。

3.4.1.3会员提现记
记录会员的每次提现的金额等信息。

3.4.1.4会员充值
记录会员账户的每次充值数据。

3.4.1.5会员交易记录
记录会员的交易历史，包括收款和付款。

3.4.2运营
3.4.2.1权限
操作员实体：记录可以登录运营后台的所有人员
角色实体：按照功能分组，每个角色包含多个权限，如果把这个操作员分配给某个操
作员那么这个操作员就具有这个角色所具有的所有权限。

权限实体：表示一个操作员被允许的操作。

3.4.2.2结算
账户实体：保存用户金额，分为会员账户和银行账户，其中银行账户是银行在支付平台系统的一个映射账户。

结算周期定义实体：商户的结算周期，结算最定金额，上次结算日期。

结算记录：商户每次结算时计算笔数，金额的统计。

账务历史：商户结算根据未结算的账户历史统计得出。

划款记录：计算出结算金额后，生成一笔打款记录把钱结算到商户的银行账号中。

3.4.3商户
3.4.3.1商户实体及商户扩展资料实体
保存商户的基本信息和数据，包括商户签约名称，商户的签约网站，商户的合约时间等。

商户的基本资料在商户和支付平台签约的时候指定，为了安全性，商户不可自行更改自己的基础信息。

3.4.3.2商户操作员实体
商户审批后，系统自动为商户创建一个默认操作员，此操作员拥有商户的最高权限，不可删除，不可修改用户名，可修改登陆密码。

商户可建立子操作员，子操作员由默认操作员创建，分配权限，可删除，可修改。

操作员可根据自己的被赋予的权限，在商户后台拥有权限相应的功能操作。

3.4.3.3角色
商户操作员可建立角色，一个操作员可以拥有多个角色，一个角色对应多个操作员。

3.4.3.4功能权限
功能权限由操作员自行管理，一个功能权限对应多个资源，操作员与功能权限为多对多的关系。

3.4.3.5账户实体
每个商户在我们平台拥有一个账户实体，用户支付成功的时候增加实体的余额，退款则相应减少退款余额。

每次账户余额的变更，对应生成一条账户历史。

3.4.3.6结算信息
商户的结算信息，主要包括商户的结算方式，自动结算、手动结算。

结算周期，日结、月结等信息。

3.4.4核心交易
3.4.4.1订单实体
记录核心的订单数据，包含每次请求的商户订单号，系统生成的流水号，商户交易的金额，手续费，商户的账户信息等和商户支付相关的核心记录。

状态变化情况为：下单时创建，状态未付，当用户在银行付完款后，更改状态为已付。

3.4.4.2支付记录实体
下单后，付款人选择支付方式时产生，初始状态为未付，付款人每次更换不同的支付方式重复发起支付时产生新的支付记录，状态都为未付，其中一笔支付记录付款成功后，系统自动把其他未付的支付记录撤销；订单被撤销时，关联的所有支付记录也都被撤销；如果某一笔支付记录已被撤销，然后才收到银行系统的支付成功通知，系统则发起自动退款。

3.4.4.3退款记录实体
退款记录创建时需要传入退款订单号，且对于同一商户的退款订单号不允许重复，如果没有传退款订单号，则系统自动生成一个。

3.4.4.4账户实体
每个商户在我们平台拥有一个账户实体，用户支付成功的时候增加实体的余额，退款则相应减少退款余额。

每次账户余额的变更，对应生成一条账户历史。

第四章模块功能分配4.1系统划分及功能描述
4.1.1运营门户
4.1.1.1需求规定1．功能需求
2．运营角色划分
客户服务人员
会员信息管理人员
商户信息管理人员
销售人员
会计
银行接口管理员
超级管理员
结算审核员网络管理员
1． 会员管理用例
会员信息管理员
会员信息查询
会员资料审核
会员状态变更
会员黑名单管理
2． 商户管理用例
商户信息管理员商户信息查询
商户基本信息维护
商户信息审核
商户费率设置商户结算设置商户账户状态变更
提交状态变更请求
状态变更审核
修改商户信息
添加商户信息
3．运营用户管理用例
运营人员
运营人员登录
运营人员注销
运营用户维护
运营角色维护
添加运营人员删除运营人员
运营人员角色设置
添加角色
删除角色
查询角色查询运营人员
4．客户服务管理用例
客户服务人员
查询会员信息
查询商户信息
查询会员交易记录
查询商户交易记录
投诉处理
常见问题维护
添加常见问题
常见问题查询
常见问题修改
投诉查询
投诉处理
5． 银行接口管理用例
银行接口管理人员
银行编码维护
银行分流设置
银行接口状态变更
银行接口费率设置
银行接口维护
添加银行接口
银行接口查询
6． 会计管理用例
会计人员
财务对账
财务调账
账务减免
呆坏账处理
挂账处理
会计报表
审计核算
4.1.1.2 包设计结构
4.1.1.3 基本设计概念和处理流程
1． 权限流程
基本设计概念：
1）管理员登录运营管理系统。

2）运营管理系统接收到管理员的登录请求后，验证管理员的账号和密码的有效性，验证失败后告知登录人登录失败，成功则展现管理界面给管理员。

3）管理员选择需要维护的数据，发起维护请求。

4）验证管理员是否有本次数据维护的权限。

5）验证请求数据是否有效，进行数据处理。

6）告知操作员处理结果。

处理流程：
2．商户业务开通流程
基本设计概念：
商户业务开通包括商户合同确认、商户资质审核、结算设置、费率设置、银行分流设置、支付渠道设计等一系列操作。

3．银行接口维护
基本设计概念：
和银行签订协议完成后首先做技术接口对接联调，完后需要在运营后台完成银行协议维护、银行渠道维护、支付渠道维护、银行费率设置等操作。

银行渠道和支付渠道区分：支付平台和工商银行深圳分行合作在线业务，按定义规则
定义银行渠道编号ICBC_B2C_SZ，和工商银行北京总行合作在线业务，定义银行渠道编号ICBC_B2C_BJ，不同的合作银行，不同的支行，不同的业务定义一个银行渠道编号。

支付渠道编号则是针对商户和付款方定义的一种支付方式，如前面定义的两个银行渠道编号，对应的支付渠道编号是ICBC_B2C。

系统会根据银行分流设置，引到不同的银行通道。

4．销售模块
基本设计概念：
销售模块是针对支付平台内部销售人员，提供根据不同商户和交易日期，交易额、收入的一个统计报表功能。

5．会计管理
基本设计概念：
会计系统中“综合业务工作平台”作为运营门户的一个分支，主要功能有财务调整、报表下载。

4.1.2商户门户
4.1.2.1需求规定
4.1.2.2包设计结构
4.1.3会员门户
4.1.3.1需求规定
4.1.3.2包设计结构
4.1.4支付网关
4.1.4.1包设计结构
4.1.4.2基本设计概念和处理流程
基本设计概念：
支付网关在线支付是网上交易的重要环节之一，支付网关后台通过多点连接各家商业
银行，一点连接商户的方式，简化了商户的在线收款方案。

支付网关就相当于商场收银台，无论客户使用哪家银行的账户在线支付，支付网关都可以代为收款并记录交易明细。

支付网关只适用于实现商户收款。

支付处理流程：
4.1.5商户接口
请参考《XX支付平台商家接入文档》。

4.1.6核心业务流程
4.1.6.1商户接入
1．基本设计概念
商户自行完成注册：
商户注册的用户名只能是邮箱地址。

商户所需的审批材料尽可能以电子档的方式，连同注册时一起提交。

商户审批流程：
审核内容包括身证证、营业执照、ICP备案等。

资料审核完成后，进行下一步业务设置、结算设置、结算及结算规则设置、银行分流设置。

商户接入：
业务开通后，商户登录商户后台，下载商户接口文档，开始技术接入。

2．处理流程
4.1.6.2支付网关处理
1．基本设计概念
支付网关主要负责商户提交的报文解析/验证，并检查商户合法性。

在商户接入流程中对商户做的交易限额、业务限制在此一一检查。

最后展示出过滤后的可用支付银行列表，供用户选择。

2．处理流程
4.1.6.3支付去银行流程
1．基本设计概念
银行分流：
支付公司一般会和同一家银行不同的分行合作，如工商银行，支付公司分别接入北京分行和深圳分行。

一是当其中一个分行发生特别情况时，有一备份银行，不至于中断用户使用工行支付的通道。

二是两个不同的分行，交易额度、业务范围、成本都会有差异，设置银行分流可以根据商户业务需要灵活配置。

阶梯费率：
阶梯费率与固定费率不同，可以设置当商户交易额在一个时间段达到一定的交易量时，费率在固定费率基础上下调。

本系统支持为不同商户，不同业务类型，设置阶梯范围。

在此过程中创建商户订单记录，创建支付记录，创建银行订单记录，并计算出商户手续费、银行成本。

2．处理流程
4.1.6.4费率流程
1．基本设计概念：
商户费率：商户接入支付平台，按每笔交易的金额收取手续费率。

银行费率：支付平台接入银行，需要付给银行的手续费率。

银行也有包年的费率。

付款方：一般指的银行卡持卡人，或平台会员用户。

收款方：一般指的是商户。

阶梯费率：一个时间段内，根据商户的交易量，设置一个交易量阶梯范围，不同的阶梯范围商户费率也不同。

2．处理流程：
4.1.6.5支付完成后流程
1．基本设计概念
当用户在银行页面输入卡号，密码完成付款后，银行发送报文通知支付平台。

支付平台更新订单状态，更新账务余额，创建账务历史，交易成功。

交易成功后，异步消息通知会计系统做会计分录，通知风控系统保存交易数据做事后分析，通知商户通知系统通知商户。

2．处理流程
支付成功后处理流程
支付失败后处理流程
4.1.6.6充值流程
1．基本设计概念
充值业务，需要关闭所有信用卡支付通道，防不法分子套现。

充值业务支付流程，参考支付网关处理，支付去银行流程，支付成功后流程。

2．处理流程
4.1.6.7账户间转账流程
1．基本设计概念
账户间转账：是指注册为支付平台会员、商户、代理商之间发生的转账过程。

转账需要注意，要防止不法分子通过转账来套现洗钱。

2．处理流程
4.1.6.8结算流程
1．基本设计概念
结算：将一个时间段发生的交易汇总，打入商户银行卡的过程。

结算周期：日周月，或自定义时间。

风险预存期：如T+1，即当天的交易第二天零点后结算。

结算方式：自助结算即由商户后台手动发起结算，自动结算即由系统每日零点后的一个时间启动定时任务发起结算。

结算模块只负责统计商户结算数据，生成结算记录，更新账务并生成打款记录。

实际的打款流程由会计系统完成。

2．处理流程
4.1.6.9退款流程
1．基本设计计概念
退款：交易交易发生的钱退回给付款用户。

部分退款：即一笔订单可以分多次部分退款，前提是银行一定要支持部分退款功能。

退款原路返回：如用户用尾号0002的招行信用卡付款，退款成功退回到用户尾号0002的招行信用卡上。

如果是用会员余额支付，退款原路退回到会员会员账户中。

退款时平台收取的支付手续费退吗？
系统设计为所有交易发生的退款，支付手续费均退回。

退款时银行收取的支付手续费（即成本）退吗？
取决于和银行。

不管银行退不退支付手续费，平台均退回支付手续费，银行退回部分由支付平台承担。

是否支持退回买家账户？
只有使用会员余额支付的才可退回买家账户。

2．处理流程
4.1.6.10商户通知流程
1．基本设计概念
商户通知：交易处理完成后，支付系统和商户系统通讯的过程。

商户补单：由于网络等其它原因，导致交易结果不能成功送达商户系统，这时候需要补单处理。

通知机制：通知动作由人工发起或交易成功驱动，如果第1次通知商户失败，通知系
统间隔2、4、8、16分钟尝试4次来通知商户。

2．处理流程
异步消息,请求通知服务
4.1.6.11会计处理
1．基本设计
一笔来自业务系统的请求在账务系统中至少一条账务流水明细记录，同时会计系统中根据业务的需要产生一套或者多套会计分录流水，账户余额与会计余额相对应。

账务系统提供对客户的账务支持，客户查询的账户余额、账务明细都来自于账务系统。

会计系统则是为了支付平台内部核算管理需要而设计，所有的银行资金清算与结转都需要会计系统的支撑，内部账户和外部客户的资金核算管理也需要会计系统，两个系统相互依赖，账务系统是会计系统的前置。

2．处理流程
4.1.6.12对账流程
1．基本设计概念
对账：将银行交易数据和平台数据一一对比，找出异常数据。

2．处理流程
5.4.1风控处理
7．基本设计概念
从交易流程和交易数据入手进行风险检测和处理，最大限度地规避交易风险。

事中监控：能在交易进行过程中监测和控制有风险的交易。

事后分析：能根据交易的历史数据进行统计和分析并作出预警。

8．处理流程
第五章数据库设计详细请参考《XX第三方支付平台系统-数据库设计》。

5.1数据库表关系图
商户会员账户关系图：
账户表相关关系图：
商户表关系图：
支付表关系图：
商户通知表关系图：
权限表关系图：
5.2数据表清单。