中国电信融合支付社区平台总体解决方案初稿.docx
《中国电信融合支付社区平台总体解决方案初稿.docx》由会员分享，可在线阅读，更多相关《中国电信融合支付社区平台总体解决方案初稿.docx（34页珍藏版）》请在冰豆网上搜索。
中国电信融合支付社区平台总体解决方案初稿
中国电信融合支付社区平台总体解决方案
设计编号：
建设单位：
设计单位：
2010年2月
概述
背景
翼支付-行业版、翼支付-公众版、翼支付-电话版为中国电信支付产品具体表现的三种产品形态。
翼支付-行业版应用是中国电信针对行业客户（政府、企业、校园等）提供的融入了综合支付能力的信息化应用综合解决方案。
行业人员通过天翼手机终端既可以使用优质的语音和信息服务，也可以通过直接刷手机实现内部食堂/超市消费、门禁识别和考勤、单位资源管理等后勤服务，还可以在外部电信商家联盟进行消费。
翼支付行业版应用是中国电信在扩大移动用户规模、提高市场份额、增强用户粘性、实现融合差异化发展的有力手段。
翼支付-行业版支持翼支付的所有功能，通过与电信联盟商家的发展结合，可以为行业群体在行业外提供更加丰富、方便、快捷和安全的应用服务，进一步增强移动终端用户粘性，扩大用户规模。
中国电信融合支付平台建设以“统一规划、逻辑一致、物理集约、兼顾现状”为原则，按照全国、省两级能力平台，全国、省、社区三层应用体系构建。
社区平台即为承接翼支付行业版应用业务需求所建设平台，本文档主要针对翼支付行业版应用，对融合支付社区平台建设方案进行研究，为社区平台建设提供总体解决方案。
编制依据
中国电信融合支付平台技术规范——总册V2.0（暂行）；
中国电信融合支付平台技术规范——全国平台功能分册V2.0（暂行）；
中国电信融合支付平台技术规范——省平台功能分册V2.0（暂行）；
中国电信翼支付业务行业版应用技术规范（暂行）；
中国电信支付账户体系设计方案；
相关部门提供的调研资料。
业务需求
业务定义
翼支付行业版产品是中国电信面向各类行业客户提供的融入了移动支付能力的信息化应用综合解决方案。
行业客户通过电信天翼手机既可以使用优质的语音和信息服务，也可以直接刷手机实现内部食堂/超市消费、门禁识别、考勤和资源管理等后勤服务，还可以在外部电信商家联盟进行消费。
通过翼支付行业版产品，可以形成行业客户内部统一管理的信息平台，全面提升行业客户的管理效率和管理水平，并为行业用户提供与工作、生活、学习息息相关的支付功能。
业务需求
翼支付行业版产品集成了四类服务，为行业用户提供一系列整体服务。
1）内部后勤服务
为行业用户提供身份识别类（如门禁、考勤、会议签到、资源管理等）、小额消费类（如内部食堂、超市等）和信息查询类（如教学、工作、生活类信息）的后勤服务，并将其集成在电信天翼手机终端或卡中，行业用户手持电信手机即可享受全方位的后勤服务，无需再携带各种繁琐的卡片。
2）外部商户消费
为行业用户提供电信消费账户，用户为该账户充值后可在外部的联盟商家刷电信手机消费、乘坐公交、使用电子优惠券等服务。
通过此账户可实现对企业员工的福利卡服务。
该账户依托于电信融合支付平台，为行业用户提供开户、充值、消费、挂失、补卡、销户等功能。
3）综合信息化解决方案
针对行业客户的管理和办公需求，提供综合信息化解决方案，如企业总机、移动OA、销售管家等。
一般而言，行业客户对该类服务的需求超过对内部后勤服务的需求，行业客户在实现内部后勤服务后也会考虑引入综合信息化解决方案。
4）通讯服务
为行业用户提供中国电信优质的通信服务，包括语音、短信、手机上网及3G特色应用等。
在融合支付体系中的定位
账户关系
中国电信融合支付产品定位于以消费类账户为主的多账户多媒介（WEB、IVR、SMS、RFID等）多商户的支付应用。
基于电信网络及业务运营现状，中国电信的用户消费类账户与电信通信账户采取分离设置的方式，消费类账户独立于电信通信计费账户体系，是用户进行消费支付的核心账户。
电信用户还可以使用电信积分在合作商户进行消费。
中国电信用户还可以通过其它关联账户（如银行账户、第三方行业账户等）进行各种支付和消费。
这样，用户就可以通过固话、移动和互联网等多种接入手段，保证支付账号及相关联的账户在任意交易场景均可融合使用，方便用户随时随地快捷方便地使用电信支付业务。
按照账户的用途以及是否由电信平台管理的维度来划分，账户体系可分为：
电信消费类账户、电信通信类账户和其他关联类账户，账户和平台的建设可分阶段建设和实施。
（一）电信消费类账户
电信消费类账户是中国电信支付产品使用，存放在电信平台上，由电信管理和运营的支付账户类型，在初期阶段主要包括了支付账户。
（二）电信通信类账户
电信通信类账户是中国电信客户用来支付电信产品使用费用的账户，分为电信通信账户和电信充值付费卡。
电信通信账户包括预付费用户预存账户和后付费出帐账户。
（三）其他关联类账户
其他关联类账户是指由第三方金融机构或行业机构发行和管理，但和中国电信支付产品相关联，可以为电信支付产品使用的账户类型。
包括可以为电信消费类账户充值或为电信支付产品直接用于支付。
目标账户架构图如下：
翼支付-行业版客户账户即为上述账户体系中的第三方行业关联账户，为校企内部用户账户，一般该账户由校院和企业内部自行管理和使用，或电信代为管理。
与支付平台关系
行业用户也是中国电信的用户，社区平台即翼支付行业版平台，也是中国电信支付体系的重要组成部分。
中国电信融合支付平台负责建设和管理电信消费账户，支持所有电信联盟商家的消费。
行业用户开通翼支付行业版应用时，同时开通融合支付平台消费帐户。
对于社区平台来说，融合支付平台中的消费账户是翼支付行业版平台账户充值的重要资金源，同时翼支付行业版账户也可通过接口向电信自有支付账户进行充值。
用户也可以在两个账户间设定绑定关系，实现自动充值功能。
系统总体规划
系统定位
融合支付社区平台即为翼支付-行业版客户提供本单位内部应用的业务平台，各省公司应采用“集中部署，能力复用”的建设模式并在平台建设和系统维护等方面与相关方进行充分合作，降低投资成本。
系统建设原则
（1）统筹兼顾：
以客户需求为出发点，重点采用“集中部署，能力复用”的集约型建设模式，并在平台建设和系统维护等方面与相关方进行充分合作，降低投资成本；适当采用分散模式满足客户个性化需求；
（2）开放性：
系统遵循开放性架构，支持多种接入网络、终端、与支付渠道，为各种业务提供统一的、开放的能力引擎调用；业务维护和发展不依赖于设备厂商，能够保证业务的持续升级和发展；
（3）安全性：
集约型系统应按照电信级的应用进行设计，系统软硬件架构充分考虑整个系统运行的安全策略和机制；针对各类应用的安全需求，采用多种安全技术手段，为用户提供完善的安全技术保障；
（4）成熟性：
采用成熟稳定并具有多样本运营实例的硬件平台和第三方软件；
（5）可扩展性：
平台采用模块化松耦合设计，易于扩展，某一模块的修改，不影响其他系统正常运行；新增功能时对系统修改应尽可能少。
系统架构体系
融合支付平台在服务于电信自有业务对支付功能需求的基础上，扩展服务于电子商务支付、手机移动支付等业务需求，具备多种支付手段和渠道能力。
远程支付能够支持实现互联网（WEB）、WAP、短信、语音支付等应用；现场支付能够实现大额有密联机交易、小额无密脱机交易功能。
中国电信融合支付平台建设以“统一规划、逻辑一致、物理集约、兼顾现状”为原则，按照全国、省两级能力平台，全国、省、社区三层应用体系构建。
全国级平台侧重于银行统一接入、自有支付账户管理、清分清算、集团级自有业务平台接入、商户系统接入和管理，并提供虚拟省平台功能；省平台侧重于本省自有业务平台、IT系统的接入，POS接入和管理，省内支付数据的汇聚和转发；社区平台承载翼支付行业版应用业务，实现在校企封闭环境内的消费类、身份识别、自助服务等功能。
融合支付社区平台的建设模式包括集约模式和分散模式两种，集约模式根据具体情况包括全省集中和区域集中情况。
集约模式和分散模式两种方式在系统的整体结构、运行机制、功能表现均一致，主要区别在于平台的部署方式不同，以及由此带来的系统运维管理的不同。
系统总体架构-集约模式
集约模式是指在省内或区域建一个集中的社区平台，各行业客户将各自已有的应用系统接入社区平台；行业内部的消费POS通过应用系统与社区平台相连；社区平台统一与OTA平台、ISAG平台相连。
翼支付行业版客户账户（校企账户）由社区平台进行集中管理，社区平台支持不同校企间的分权分域管理。
集约模式社区平台由电信公司进行建设，运营由电信公司或第三方负责。
集约模式，可提升投资效益，同时设备放置于电信机房，客户业务由电信公司一定程度上的代为管理维护，增加客户黏性。
在功能上，集约模式适合支撑具有共性业务需求的聚类校企客户，建议对小型企业、规模较小的学校、商务楼宇进行推广。
需要考虑，集约模式在一定程度上增加了维护的工作量，同时社区平台放置于电信侧，电信机房与客户之间的承载网络可靠性尤为重要。
系统总体架构-分散模式
在分散模式中，每个行业客户分别按照该企业需求建设一套社区平台。
社区平台与电信融合支付平台打通接口，电信融合支付平台消费帐户用于单位周边联盟商家的刷卡消费；社区平台分别与OTA平台、ISAG平台打通接口，以利用短信方式支持空中圈存及信息推送服务。
分散模式，各个校企内所建设社区平台管理各自的账户，支持内部的商务消费、门禁考勤、身份识别等应用。
分散模式，设备建议放置于客户机房，可由电信公司或第三方公司代为管理维护，或客户自行维护。
在功能上，分散模式适合支撑具有较多个性业务需求的校企客户，且由独享平台的需求。
建议对大/中型企业、厂区、规模较大的高职学校进行推广。
融合支付社区平台功能架构
从系统总体架构上来看，融合支付社区平台主要包括数据中心、消费类应用子系统、身份识别及综合管理类子系统、自助服务类及查询子系统几部分。
数据中心包括支撑管理、结算、卡务、密钥管理等功能；消费类应用子系统包括充值转帐（圈存）、补助发放、综合商务消费管理、集中式电控管理等；身份识别及综合管理类子系统包括数字迎新管理（校园特有）、翼支付行业版用户注册管理、门禁管理、考勤管理等；自助服务类及查询子系统包括web自助查询、触摸屏自助查询等。
数据中心
数据中心是社区系统的中心平台，它包含对一机通中心主机系统的管理和维护，数据交换、交易及同步，用户及设备的管理、系统参数的设置和环境的设定，系统各模块的工作状态监控和工作模式的设定，密钥管理等功能。
基于社区平台，建立商务管理、银行转账、身份识别管理、翼支付行业版用户指纹注册等各子系统，定义统一的接口标准和接入规范，随行业客户规模的扩大、支付卡功能的增加可随时增加子系统，为行业客户以后的发展提供良好的数据接口，便于以后翼支付行业版的功能扩展。
翼支付行业版用户基本信息资料和电子钱包都作为统一的公用数据在全网上实时共享，经过中央集控中心的统一授权和管理，由数据交换中心、数据共享中心的统一发布，所有数据的变更都做到全网立即生效，做到全单位数据的同步。
数据中心作为翼支付行业版用户身份、消费等信息集中地，汇集了大量的日常行为数据，可以根据这些数据进行多方面的统计，从各个侧面了解整个企业的动态运行情况，因此企业有需要对这些数据进行汇总统计分析，为领导层管理决策提供参考信息。
消费类应用子系统
消费类应用子系统主要借助于翼支付行业版手机内的电子钱包，完成圈存、充值、消费等商务应用。
此类子系统包括但不仅限于，根据实际应用场景进行配置：
Ø充值转帐（圈存）系统
Ø补助发放系统
Ø综合商务消费管理系统
Ø无线班车管理系统
Ø浴室水控系统
Ø集中式电控管理系统
Ø预付费IC卡电表系统
Ø补助管理发放系统
Ø自助卡控复印机
Ø自助洗衣系统
Ø机房管理子系统
Ø智能卡水表系统
身份识别及综合管理类子系统
身份识别及综合管理类子系统主要利用翼支付行业版完成对用户的标识，及相应业务功能。
此类子系统包括但不仅限于，根据实际应用场景进行配置：
Ø数字迎新管理系统（校园特有）
Ø翼支付行业版用户注册管理系统
Ø门禁管理子系统
Ø无障碍通道管理系统
Ø车辆出入控制管理系统
Ø人员出入控制管理系统
Ø指纹识别系统
Ø考勤管理系统
Ø会议签到系统
Ø公寓（宿舍）管理系统
Ø多媒体卡控系统
自助服务类及查询子系统
（1）WEB自助查询
基于WEB的网上自助查询子系统，向翼支付行业版平台用户提供了一种方便、快捷的数据检索手段。
在此WEB网站上可以访问翼支付行业版的相关信息，用户根据设定的登录权限，即可查询需要的信息，用户可以自助挂失，查询本人帐户的状态，个人信息，个人的历史消费记录、存取款记录和补助领取等记录。
（2）触摸屏自助信息查询
全天候24小时为翼支付行业版用户提供信息服务，在此系统上，安装有卡识别器，无支付卡的用户可以查询公共信息和公告，有支付卡的用户利用此系统，还可以自助进行翼支付行业版的信息查询、自助挂失、解挂、查询历史消费记录、存取款记录、补助记录等。
（3）语音查询
通过内外部电话网络可实现卡内余额查询，自主修改密码，卡片挂失，自动委托转帐操作，自动挂失等功能。
（4）手机查询
手机查询除UTK服务和短信服务外，还包括特定开发的软终端和WAP网站。
UTK菜单以模块化组织，方便灵活，可以根据行业客户的具体要求定制，开发出适合本行业的应用菜单。
（5）短信提醒服务
账户重要信息变更提醒，账户资金信息变更提醒，消费重要信息提醒，到帐提醒等。
系统接口
融合支付社区平台对外接口包括与翼支付-行业版客户（校企）内原有系统的接口、与ISAG平台接口、与OTA平台接口等。
系统接口示意如下图所示：
与原有系统接口：
对于校企客户原已有部分系统，如教务系统、图书馆管理系统等，需由社区平台进行接入，实现校企客户业务体系一致。
与ISAG接口：
实现由ISAG平台提供与翼支付-行业版业务应用相关的短信/彩信能力，包括支付结果短信通知、验证码下发，短信提醒服务等功能。
与OTA平台接口：
与OTA平台的对接主要依靠OTA平台，根据不同的用户群提供OTA菜单的定制服务；同时利用OTA技术可以管理UIM卡内文件的功能，来实现空中圈存、账户状态设置等功能。
与融合支付省级平台接口：
利用一机通平台与省级支付平台的接口，实现用户电信在线支付账户与社区平台内部账户的资金划拨。
与POS接口：
处理POS终端的报文组，进行解包，接口适配，实现通讯服务。
网络承载方案
网络承载总体原则
充分考虑省内各类业务的开展和网络部署，社区平台对底层承载网的基本要求包括：
✧业务网络与公众互联网间的互联要进行严格控制，具备防攻击能力；
✧承载网具备冗余保护功能，提升系统的可用性和可靠性；
✧充分考虑关键业务信息流在IP网上传输的QoS保证要求。
网络承载方案
根据业务需求，融合支付社区平台系统对外的接口通路一般需要考虑以下互联需求：
A．社区平台和融合支付省级平台互联
B．社区平台和校企客户已有系统的互联
C．社区平台与ISAG等电信业务系统的互联
D．社区平台接入POS终端
针对上述互联需求，可针对具体情况采用VPN、专线、公网等方式承载。
集约模式平台网络承载方案
初期集约模式下融合支付社区平台一般由电信公司进行投资建设，并负责维护，设备设置在电信核心机房，采用分权分域模式为各翼支付行业版客户提供业务应用。
针对集约型社区平台对外互联需求，主要通路承载方式为：
与融合支付省级平台互联：
CN2网络上已划分单独MPLSVPN承载业务网络（VRF：
PI-1），社区平台和融合支付省级平台互通采用局域网或PI-1VPN进行承载。
与翼支付行业版客户（校企）已有系统互联：
为保证校企客户相关数据信息的安全，建议根据校企客户已有网络情况采用相应的CN2VPN、城域网VPN、专线方式进行承载。
与ISAG等电信业务系统互联：
采用局域网或CN2PI-1VPN进行承载。
与POS终端互联：
POS终端上联方式分为RS232、网控、拨号、局域网、CDMA1X/EVDO等。
分散模式平台网络承载方案
分散模式下融合支付社区平台一般建立在各翼支付行业版客户（校企客户）机房侧，针对社区平台互联需求，主要通路承载方式为：
与融合支付省级平台互联：
根据客户网络资源情况，社区平台和融合支付省级平台互通可采用CN2VPN、城域网VPN、专线方式进行承载。
与翼支付行业版客户（校企）已有系统互联：
社区平台放置在客户侧，与已有系统经校园网/局域网实现互通。
与ISAG等电信业务系统互联：
采用城域网或CN2VPN进行承载，对于非电信建设、运维平台，建议采用城域网进行互联。
与POS终端互联：
POS终端上联方式分为RS232、网控、拨号、局域网、CDMA1X/EVDO等。
平台网络组织方案
对于集约模式的融合支付社区平台，应综合考虑平台运营所需的电信级可靠性、冗余性以及对外网络互联需求，根据实际需求进行相应网络设备、安全设备、服务器设备的选型和配置，系统应具备电信级可靠性、多种冗余、备份和集群处理的机制和功能。
建议对于社区平台与不同平台互通，采用不同的网络进行承载，对关键应用提供QoS保障和安全保证。
针对通用情况，建议系统网络设备配置应包括1对三层组网交换机、1对防火墙、1对专线接入路由器。
两个三层组网交换机之间采用VRRP实现互为备份；两台防火墙可采用Standby-Standby或Active-Standby模式进行保护，配置严格的保护策略，控制平台之间的互通；对于有需专线接入或互通需求平台，可配置一对专线接入路由器。
平台上联接入CN2、城域网等网络应采用冗余链路，避免单链路故障，保证客户应用的持续性、稳定性。
服务器配置方面，对于关键应用如数据库服务器、应用服务器建议配置双机设备，存在内网、外网访问需求的服务器配置双网卡，具有冗余保护机制，保证业务网元的可靠性。
集约模式社区平台系统网络组织图可参考如下：
对于分散模式社区平台，可结合建设、维护单位主体，翼支付行业版客户需求，参照集约模式社区平台进行配置。
系统设计要求
系统指标
针对集约模式融合支付社区平台系统指标如下所示：
序号
指标参数
参数值
一、系统容量（系统扩展支持容量）
1
系统账户容量
＞50万
2
商户账户容量
≥1万
3
子系统接入数量
≥512个
4
流水账保留天数
不限，由用户自行配置
5
黑名单容量
≥10万个
6
部门级数
≥4级
7
持卡人卡片类型
＞10
8
历史数据保存时间
各类人员、机构及重要管理业务数据要求保存期为50年，翼支付行业版金融消费及身份认证记录保存期为7年
9
存储容量
＞2TB
二、系统处理能力
1
系统工作特征
7×24小时实时系统
2
交易处理方式
联机为主，脱机为辅
3
多机并发处理能力
联机≥64台；脱机不限
4
通讯处理能力
≥1000笔/分；平均延时小于3秒，最大延时不超过30秒
6
读写卡时间（网络状况正常）
＜1秒
7
POS机通讯速率
4800/9600/15620/19200/38400/57600/115300bps可调，正常情况下在15620bps以上
8
POS机传输数据出错率，重传率
＜2/10000
系统可靠性
1）应采用成熟的、容错性和易恢复性俱佳的系统；
2）系统必须支持连续7×24小时不间断地工作。
应用软件中的任一构件更新、加载时，在不更新与上下构件的接口的前提下，不影响业务运转和服务；
3）系统平均无故障时间不小于26280小时（3年）；系统平均无故障率不低于99.999%
4）系统应支持负载均衡能力，支持应用部署在多台服务器上，避免应用系统的单点故障。
冗余点在单台设备软硬件故障情况下，要求系统所承载业务仍正常提供且服务质量不劣化；
5）系统应具备静态过负荷控制和动态过负荷控制两种过负荷控制的能力，能根据CPU、内存、处理能力进行过负荷控制；
6）系统应具备自动或手动恢复措施，能够实现快速切换，保证系统连续运行。
在系统使用过程中，由于硬件出现故障或其它原因造成系统暂时性的中断后系统重新启动时，能够保证系统将原有的数据快速恢复。
7）软件故障情况下，系统应具备故障守护恢复机制，即当发生一般性软件障碍时，系统应具有自纠恢复能力，例如：
软件发生障碍时能进行局部再装入等。
当发生全系统中断或电源中断恢复后，系统应能迅速地自动再启动运行；
8）系统能够正确识别外围系统发的错误请求及重复请求，避免出现一些不可预测的结果；
9）系统应有良好的备份和恢复策略，系统数据和业务数据可联机备份、联机恢复，恢复的数据必须保持其完整性和一致性。
系统易用和可维护性
1）系统应易于修改，对某一个子系统的修改，不影响其他子系统的正常运行；
2）系统应易于扩展，新增服务时要求对系统整体做尽可能少的修改；
3）系统应具备自管理和监控功能，能够实时监控各模块的执行；
4）系统应具备在线升级协议及版本的功能，在不中断业务的情况下支持对系统的外部接口协议进行在线升级、对修改后的系统版本进行在线升级；
5）系统新增接入翼支付行业版客户某已有系统时，应不影响系统已提供其他业务的正常使用；
6）集约型平台新增接入翼支付行业版客户时，对已接入的行业版客户业务不应产生影响；
7）系统所具有的应用功能模块可多种方式，灵活组合提供给翼支付行业版客户，满足不同客户对功能的差异化需求，与客户已有应用易于耦合。
系统开放性
1）应用系统应该采用构件化设计思想，系统框架与业务逻辑分离；要求具备开放的体系结构；
2）系统采用开放的接口协议与开发平台；
3）具有丰富的三方系统交互接口，充分支持与翼支付-行业版客户已有系统的互联。
分权分域—集约模式
集约模式下，社区平台应实现对使用集约型平台的翼支付-行业版客户提供分权分域管理功能。
系统分权分域管理要实现各翼支付-行业版客户之间数据信息的独立和隔离，客户对社区平台系统的访问应互不干扰，某客户对社区平台上本单位数据的修改不应影响其他客户的使用。
分域：
从访问和管理对象的层次结构上看，用户操作涉及到不同层次/不同区域（针对社区平台即为不同校企单位），系统应对不同客户能访问和管理的层次进行控制。
分权：
对在层的管理范围内的用户操作，增加权限方面的控制，包括操作级别的控制（如对通常操作项分成增、删、改、查等多个级别），存取操作权限细目（结合操作级别控制，还可对存取相关的特定操作动作进行控制，形成受限的操作动作集）。
容灾备份方案
系统容灾备份方式不同其可靠性也不同，对于业务系统通常将容灾备份方式划分成以下几个等级：
（1）双机热备：
系统主机实现双机热备份；
（2）磁带库备份：
定期磁带备份数据；
（3）数据级备份：
通过高速传输通道和磁盘控制技术将数据传送到远离生产环境的系统中，备份数据与生产系统数据完全一致，更新方式为同步或异步；
（4）应用级容灾：
实现应用系统和生产数据的完成异地备份，异地备份的系统和数据与生产系统和数据完成相同，当生产系统出线故障是，异地容灾系统可以迅速的接管生产任务；
（5）业务、人员、维护容灾：
在应用容灾的基础上实现业务、人员和维护的容灾。
社区平台应在集约模式和分散模式下分别采用相应的容灾等级。
在分散模式下建议以客户需求为主，综合考虑可靠性需求和投资。
在集约模式下，社区平台应至少实现双机热备及磁带库备份，同时考虑到集约模式社区平台的稳定性直接关系到翼支付行业用户在线业务使用感知，建议在省公司可结合本省具体情况（包括资金、管理的校企数量和规模），以双节点为最终目标架构，本期建议暂不考虑UDB异地容灾。
最终目标的双节点
升级会员 