成都网站建设公司:第三方支付平台规划

1平台业务规划

1.1构建“平台—数据—金融”互联网金融战略

打造支付平台，积累商户和个人消费者用户信息、线上线下交易行为、信用等数据，成都网站建设公司基于大数据分析挖掘，更好地利用互联网为个人用户和企业用户提供金融服务，构建自身和的“平台——数据——金融”互联网金融战略。

1.2支付平台的机会和优势

1、互联网经济高速发展，支付行业整体发展迅速；

2、技术环境推动，政府政策支持；

3、用户需求广泛，市场空间巨大；

4、国内支付下一片蓝海——二三线及农村市场正是自身的优势市场，支付平台在这一块市场拥有很多机会；

5、第三方支付处于从支付到金融的商业模式转型，自身的金融属性，符合转型的趋相比于其它的第三方支付平台，支付平台具备先天的金融资源优势。

6、可以在资金、客户资源、政府支持等方面，在小微金融、社区金融等领域，给以支付平台大量的资源支持。

1.3支付平台业务规划方向

1.3.1 业务规划整体目标

支付平台的业务规划整体目标是：

1、整合多方资源，提供全面的支付解决方案，打造自身业内专于支付的领先品牌。

2、依托自身优势，以服务中小微企业为战略重点，紧密结合小微金融、社区金融，构建以支付为基础，集金融服务、企业财务管控、营销服务、自身卡积分商城等于一体的互联网金融综合服务平台。

1.3.2 提供全面的支付解决方案

1.3.2.1 支持购物支付、便民支付等多种业务场景

支持购物支付（包括线上、线下，以线上线下融合的O2O模式）、转账付款、缴费充值等业务场景。

1.3.2.2 覆盖多个支付细分市场，支持多种支付业务类型

一、支付平台，未来应该覆盖多个支付细分市场：自身卡收单市场、互联网支付市场、移动支付市场、预付卡支付市场、数字电视支付市场等。

1、线下自身卡收单市场，作为份额占比最大的支付细分市场，市场整体稳定增长，第三方支付与银联商务占据了收单市场主体地位，也是支付平台最具备优势的市场，拥有的大量商户资源可以提供给支付平台。对于这个市场，支付平台要大力开拓。一方面要整合的资源，另一方面要寻求与银联的合作，实现双赢。

2、互联网支付市场逐步走向成熟，传统市场空间见顶，线上线下融合趋势明显，企业纷纷采取差异化的市场拓展战略。发力市场主要有线下市场、跨境支付以及传统金融产品销售领域，而业务形式更多的采取整合平台优势资源为客户提供行业综合解决方案。对于这个市场，支付要很重视。在这个市场，支付平台应该结合自身的资源优势，着力在线下市场、跨境支付以及传统金融产品销售领域进行业务拓展，整合平台优势资源为客户提供行业综合解决方案。

3、移动支付市场在2012年迎来突破性发展，产业链各方积极布局，抢占市场先机。远程支付正进入高速成长期；近端支付前景可观但大规模商用尚需时日。对于这个市场，支付平台要特别重视，紧密跟踪移动支付的技术和业务模式发展方向，与电信运营商等合作,为客户提供移动支付解决方案。

4、预付卡支付市场，随着预付卡行业监管体系不断完善，市场进入良性发展阶段，整体市场将迎来一个高速增长期。随着获牌企业的扩张，抢占地方资源以及二三线城市将成为预付卡企业未来市场争夺的主要方向。对于这个市场，支付平台要努力争取。在这个市场，支付平台应该积极与预付卡公司开展合作，提供面向预付卡客户的预付卡线上线下支付服务。

5、数字电视支付市场，相关支付应用目前尚处于积极开发、试点阶段。对于这块市场，支付平台要持续关注，跟踪数字电视支付的技术和业务模式发展方向，积极准备应对方案。

二、未来，支付平台将为用户提供多种支付业务类型：

1、线下收单： 支持自身卡（储蓄卡、信用卡）、自身卡积分、预付卡的POS收单等线下收单方式。

2、互联网支付：支持自身卡支付（网银支付、快捷支付）、预付卡支付、虚拟账户支付、自身卡积分支付、信用支付等方式。

3、移动支付：支持自身卡支付（网银支付、快捷支付）、预付卡支付、虚拟账户支付、自身卡积分支付等方式。

4、O2O模式支付：整合二维码等技术，为用户提供O2O模式支付方案。

1.3.2.3 提供行业支付综合解决方案

基于产业链的支付和融资需求，提供行业支付综合解决方案，比如：线下POS收单业务解决方案、第三方支付平台电子支付解决方案、互联网电商电子支付解决方案、产业链与实物贸易电子支付解决方案、航空电子支付解决方案、旅游行业电子支付解决方案、酒店行业电子支付解决方案、租车行业电子支付解决方案等。

1.3.2.4 开展跨境支付业务，开拓国际市场

在网络经济高速增长的刺激下，全球网上购物市场的迅猛发展，消费者跨境网购需求日益强烈；且相较于境内支付业务，跨境支付利润更高。因此，支付平台要抓住中国进出口贸易程度加深的契机，抓住上海自由贸易区的机遇，拓展全球市场。

1.3.2.5 大力开拓国内支付下一片蓝海——二三线及农村市场

目前国内一线城市的支付市场竞争几近饱和，过度营销可能造成资源浪费并带来经营风险。在这种情况下，支付有必要根据我国经济发展方向、经济结构特点和金融市场需求，结合在二三线中小型城市，以及县域农村地区的业务优势，大力发展数量众多、具有一定潜力的二三线中小型城市，以及县域农村地区的支付结算业务，实现客户群体从高端向中低端的逐步覆盖。

1.3.3 依托自身金融优势，构建互联网金融综合服务平台

1.3.3.1 为个人消费者提供投资理财、融资贷款等金融增值服务

结合社区金融，为个人消费者提供：投资理财（基金、理财、保险）、融资贷款（消费信贷、汽车信贷、住房按揭）、P2P贷款等金融服务。

1.3.3.2 为商户提供资金理财、融资贷款等金融增值服务

结合小微金融，为商户提供：资金理财、供应链融资、小额贷款、P2P贷款等金融服务。

1.3.4 为商户提供财务管理增值服务

在进行支付的基础上，逐步实现现金业务的电子化，未来将为商户提供资金清算、资金归集、自动分账、资金账户管理、集中授权等增值服务，实现支付、资金归集、财务管理和订单的四位一体，将有效提升中小微企业的资金流转效率和财务管理水平。

为企业客户提供ERP接口，帮助企业客户实现支企直联。

1.3.5 为商户提供营销增值服务

在中小微企业广泛关注的营销服务方面，注重附着在支付业务基础上的营销功能，依托积累的大数据，未来可以打通与各类社会化网络营销平台的接口，让每一笔交易的结束转化为更多商机的开始。

1.3.6 构建自身卡积分商城

构建基于社区的特色积分商城，为社区居民提供商城购物服务、特色团购服务、本地生活便利服务，可以使用的自身卡积分进行支付。

将所有的业务所消费的积分,统一到支付下面,回馈客户，针对积分会员，以积分为核心，涵盖特惠折扣、其他增值服务等内容的客户长期回馈计划，具体服务包括积分的积累、查询、兑换、其他基本服务及增值服务。

1、通用积分——在支付积分商户消费，均可累积支付积分。

2、特惠商户——除通用积分之外，用户可以享受支付餐饮、旅游、休闲等各行业特惠商户的优惠折扣。

3、精彩奖品——源源不断的积分累积可以兑换奖品或参加抽奖

2平台总体设计

2.1平台总体架构

2.1.1 整体架构视图

2.1.2 整体架构概述

支付平台分为基础业务平台、公共服务、产品、渠道四个层面。

1、基础业务平台层：作为支付平台的架构基础及核心，支撑各种业务应用服务。分为核心系统和支撑系统两大部分。核心系统包括：资金处理系统、客户信息系统、核心管控系统。支撑系统包括：报表系统、数据分析&挖掘系统、信用系统、风控系统、后台管理系统等

2、公共服务层：为用户提供各种业务应用服务。包括：登录与身份验证系统、交易系统、收费系统、支付服务系统、金融服务系统、第三方支付ATM充值取现系统、企业财务管控系统、自身卡积分商城、营销服务系统等。公共服务可以根据用户需求，基于iTP2P（Third-party Payment Platform）基础业务平台进行扩展。

3、产品层：分为行业应用平台、商户业务平台、个人业务平台。行业应用平台是为了满足行业支付综合解决方案；商户业务平台是为了满足商户用户的业务需求；个人业务平台是为了满足个人用户的业务需求。

4、渠道层：适用于PC、PAD、手机、ATM、VTM、数字电视、固定电话等多种业务终端，满足各种业务应用场景。

2.1.3 系统功能介绍

2.1.3.1 支付服务系统主要功能

1、支持多种支付主体，包括：储蓄卡、信用卡、预付卡、虚拟账户、自身积分。

2、提供购物支付、转账付款、信用卡还款、缴费充值等支付功能。

3、支持多种支付方式：

 线下收单： 支持自身卡（储蓄卡、信用卡）、自身卡积分、预付卡的POS收单等线下收单方式。

 互联网支付：支持自身卡支付（网银支付、快捷支付）、预付卡支付、虚拟账户支付、自身卡积分支付、信用支付等方式。

 移动支付：支持自身卡支付（网银支付、快捷支付）、预付卡支付、虚拟账户支付、自身卡积分支付等方式。

 O2O模式支付：整合二维码等技术，为用户提供O2O模式支付方案。

4、面向客户的线上支付

成员行的客户，可在第三方支付(支付宝、财付通)平台上，直接使用其自身自身卡，进行网关支付和快捷支付。

5、面向预付卡客户的线上线下支付

持有预付卡的客户可在商户POS上直接刷自身卡消费其绑定的预付卡内金额。同时，也可在支付平台上直接使用预付卡进行线上支付或使用上银快付功能。

6、提供虚拟账户的非担保型支付模式和担保型支付模式

“虚拟账户”是指交易双方在支付平台中所设立的账号，这种账号与传统的自身账户具有类似功能，可以在两个虚拟账户之间转账，也可以在虚拟账户与实际自身账户之间转账。分为两种模式：非担保型（直付模式）和担保型（间付模式）。

（1）非担保型的支付流程与传统转账或汇款流程类似，支付平台在交易中屏蔽了自身账户，交易双方以虚拟账户为付款和收款接口进行交易。该模式以一种非常经济的方式实现网上双向支付，而且流程简单，使用方便。这是网银支付、网关支付难以做到的。

非担保型支付模式以一种非常经济的方式实现了网上双向支付，而且流程简单，使用方便，交易支付流程如下：

（一）客户和商家都在支付平台上注册姓名、自身账户等资料信息，并开设账户。

（二）客户在商家处进行购物，提交订单后，商家将客户在支付平台的账号和支付信息传送给支付平台请求支付。

（三）支付平台向客户发出支付请求。

（四）客户通过支付平台连接到开户自身进行支付。

（五）支付确认返回给支付平台。

（六）支付平台将客户已经付款的信息通知商家。

（七）商家向客户发货。

（八）客户接受商品并验证后通知支付平台。

（九）支付平台将货款转入卖家账户。

非担保型支付模式交易流程

（2）担保型支付模式中，支付平台不仅充当资金支付和接收的接口，更承担起买卖双方的担保人角色。这种支付模式在保持虚拟账户支付快捷、灵活等优点的同时，引入了相对受信任的第三方作为担保。但第三方担保模式的交易过程要比直付模式复杂得多。支付平台要额外承担资金管理、担保、通知、验证等一系列服务，意味着交易复杂度、交易成本的大大增加。

担保型支付模式中支付平台的工作流程主要分三步：一是将买方货款转拨到第三方平台所在账户。二是当转账成功后通知卖方发货。三是接受买方确认货物信息后，货款转拨到卖方账户。一次成功的第三方支付过程包括9个环节：

（一）买方进入买方市场，浏览自己所需商品信息。

（二）买方如果觉得某件商品合适，就和卖方达成交易协议。卖方发送信息通知买方到支付平台进行支付。

（三）买方进入支付平台，提交其账户密码以及所付款额等信息给支付平台。

（四）支付平台接收到买方提供的自身账户信息后，进入买方账户所在自身，对其提供的账户信息进行验证。

（五）验证成功后，支付平台将买方所应支付的款额转拨到支付平台所在账户，对其进行临时保管。

（六）通知卖家，买方应付货款已到，准备发货。

（七）卖家配送商品到买方手中。

（八）买方收到商品后进行验证，如果满意就发送信息给支付平台，确认商品已验收，同意付款。

（九）支付平台收到用户确认信息后，将其临时保存的货款转拨给卖方，完成一次完整的支付过程。

担保型支付模式交易流程

2.1.3.2 金融服务系统主要功能

1、面向个人消费者的金融服务功能：

提供投资理财（基金、理财、保险）、融资贷款（消费信贷、汽车信贷、住房按揭）、P2P贷款等功能。

 为消费者提供“现金宝”功能。“现金宝”是创新现金管理账户，既能持续获得超越活期利息的收益，随用随取，还能直接跨基金公司实时转换近千只热门基金，当天完成交易，费率低至4折，操作简单快捷。

  基金实时转换——支持实时任意转换天天盈支持的近千只基金产品，当天完成交易，变现灵活

  定期定额理财——专为都市”月光族”量身定制的”定期定额”自动理财功能。一次签约，自动投资理财，省时省力、稳收益

 为消费者提供“基金快车道”功能，“基金快车道”是一站式快捷发起各基金公司的交易模式，从此摆脱繁冗的账户确认过程，为广大投资者管理基金账户带来无限便利。

  一站式交易——相比一家家地去开基金公司的账户，在支付开通一家基金公司，在开通其他基金公司的账户时，系统会自动将投资者的个人资料调出，不需要一一填写，买基金就像日常网购一样方便。

  过程简洁——当进行申购、赎回等操作时，基金快车道简化为只需输入金额、选择支付渠道、验证密码三步，相比传统方式需要登录基金公司网站、找到购买基金的页面、选择基金、下单、选择支付渠道、确认等繁琐步骤，效率更高。

 消费者可以在线购买会员的理财产品。

 消费者可以在线申请消费信贷、汽车信贷、住房按揭，由成员提供贷款。

 消费者可以在线进行P2P投资

2、面向个人消费者的金融服务功能：

提供资金理财、供应链融资、小额贷款、P2P贷款等功能。

 面向商户端的理财服务：支付将与使用其线下支付的商户合作，将商户的交易流水存在支付，由支付提供利息或者基金等理财服务。基金、支付、企业客户三方基于平等的前提下，合理分配收益。

 面向垂直行业的供应链融资，向产业链条上有资金需求的中小企业提供贷款。主要集中在包括航空、保险、旅游、游戏等行业客户，业务贯穿整个产业链，对整个行业各个链条的交易信息非常清楚，对链条上的企业信誉情况可以快速评定。

 面向电商平台的订单融资，依据电商平台上的订单及商户信用，向电商平台上有资金需求的中小企业提供贷款。

 商户可以在线申请小额贷款，由成员提供贷款。

 商户可以在线进行P2P融资

2.1.3.3 企业财务管理主要功能

1、提供资金清算、资金归集、自动分账、资金账户管理、集中授权等功能。

2、为企业客户提供ERP接口，帮助企业客户实现支企直联。

2.1.3.4 营销服务系统主要功能

与国内新浪微博、QQ、豆瓣等各大社区合作，通过优惠券系统和社区分享工具的产品组合，帮助企业整合社区资源以及自身、品牌商的推广资源，辅助针对现有用户的激励机制，引导真实的用户将口碑分享到各大社区，实现企业产品和品牌曝光以及与用户的深度沟通。

同时，后台的数据统计和分析工具，帮助商户得到一手的、有效的、可监测的传播数据，解决了商户营销资金缺乏、营销工具单一、营销数据不可查的营销困境。

2.1.3.5 自身卡积分商城主要功能

提供城积分的积累、消费、兑换、查询、其他基本服务及增值服务。

 赚积分——在支付积分商户消费，均可累积支付积分。

 特惠商户——除赚取积分之外，用户可以享受支付餐饮、旅游、休闲等各行业特惠商户的优惠折扣。

 花积分：积分换礼、积分券充值、积分抽奖、积分充话费、积分充油卡等

 积分互通：可以与合作商户进行积分互换

 精彩奖品——源源不断的积分累积可以兑换奖品或参加抽奖

2.2平台技术架构

支付平台是基于iTP2P（Third-party Payment Platform）技术平台架构的第三方支付应用系统，多年以来的成功案例和技术经验积累保证了iTP2P（Third-party Payment Platform）技术平台的高稳定性、高容量和高性能。

iTP2P（Third-party Payment Platform）技术平台是基于J2EE架构体系的面向（移动）互联网的金融业务应用平台。作为支付的基础技术平台，它为系统提供了基础的技术组件和运行时环境。整个技术平台基于分层、组件模块化的设计思想，使得平台具有良好的稳定性和可扩展性。

iTP2P（Third-party Payment Platform）技术平台遵循J2EE架构体系，采用分层提供服务支持的设计思想，将系统划分EIS层（应用集成层、数据持久层）、业务逻辑层、业务表现层和客户表现层。系统对每一层定义明确的功能接口，同时在层次内实现组件化的接口实现，层次间的松耦合和组件模块的独立变化保证了系统的稳定性。此外，层次化、组件模块化的架构体系，能对业务需求的变化做出快速的反应，使系统具备了最大程度的扩展性。

iTP2P（Third-party Payment Platform）分层架构图

上图可以清晰的了解到整个系统的层次划分，系统从最底部的EIS层（图中为数据库、分布式缓存系统、其他与支付平台交互的系统）开始，经由业务逻辑层（iTP2P（Third-party Payment Platform）基础组件、iPay产品组件、客户化组件）一层一层的向上提供接口服务，最终实现按业务要求的操作界面和其他系统接口。各层次专注于自身功能的接口实现，整个层次保持相对的稳定。系统各组件之间保持接口稳定性，可在各个层次、各个组件内部进行优化的策略，在不影响整个业务的前提下，不断的完善和改进。

2.3基础业务平台

2.3.1 资金处理系统

2.3.1.1 资金处理业务模式

2.3.1.2 财务会计业务模式

2.3.1.3 支付清算业务模式

2.3.1.4 核算中心业务模式

2.3.2 交易系统

2.3.3 规则引擎组件

在第三方支付平台的设计实现上需要设计应用很多规则。这些规则在整个运营过程中需要进行动态的调整、设置。

在iPay产品中，以上这些规则的定义和执行都通过规则引擎来执行，规则引擎包含了规则的定义和规则的计算执行两部分内容：

在iPay产品中的规则引擎有以下特点：

规则参数可配置

支持预定义的规则模板

支持基于脚本语言定义的规则定义（可支持二次开发）

第三方支付平台运营管理人员可以通过运营中心提供的配置界面，进行规则的可视化配置。下图是规则引擎的结构示意：

2.3.4 调度引擎组件

调度引擎主要实现定时任务的自动调度，在第三方支付平台中主要完成批处理任务、定时任务的调度执行如：生成清算报表、日终对账等任务。下图是调度引擎组件的示意图：

任务调度引擎将任务的定义与任务的调度相分离。调度引擎支持独立的应用部署，可以支持大任务量并发处理。任务的定义支持配置文件方式和数据库方式存储。

iPay产品的调度服务引擎的结构设计图如下所示：

由上图可看到，计划任务模块由Schedule Manager统一对任务进行调度，而任务大致分为简单周期（simple）任务和复杂周期（cron）任务。其中复杂周期任务又可能需要辅助有工作日定义。

定时服务组件主要有以下4个模块组成：

  Schedule Manager：是整个计划任务的管理员角色，以服务(Service)形式根据外部XML配置对一系列任务进行安排和调度。实质上是一个接口，在其之上采用JDK Timer、commonj、Quartz等具体方式进行实现。

  简单周期任务（simple）：按照一定周期反复执行任务，可设定周期、延时、重复次数等。

  复杂周期任务（cron）：在每月、每周或每天的某个时刻执行任务，可设定条件、工作日等。并可根据工作日服务过滤或增加工作日管理。

  常用任务实现：执行一个类或一个ActionProcess等iPay产品常用任务的实现；执行一个类是指可调用任意一个java类中的方法来完成一个任务；执行一个ActionProcess是调用一个iPay产品中的业务逻辑处理对象。

2.3.5 数据集成/交互/报文处理引擎组件

在第三方支付平台设计实现上，可能需要对多个外围系统（支付网关、短信平台等）系统进行数据通讯和交易的请求处理，iPay产品基于iTP2P（Third-party Payment Platform）平台提供的多种外围系统的交易适配器，根据不同的交易请求，在交易引擎中定制业务逻辑应该访问的一组后台交易适配器，完成一次系统间的请求交互。

后台交易适配器包含两部分：交易报文格式化/解析和通讯协议适配器，在产品包中提供了支持多种常用通讯协议的通讯协议适配器。对于交易报文的格式化/解析组件，在产品包中包含了多种标准报文协议的支持，如：定长，XML,JSON,ISO8583报文等。交易适配器封装了对外围系统交易的请求处理。

2.3.6 异常处理组件

iTP2P（Third-party Payment Platform）技术平台提供了统一的异常处理组件，该模块以面向切面（AOP）的方式植入至系统的应用处理的各个环节，实现了异常处理与业务处理的分离。通过统一的异常处理机制，确保了系统中所有的异常信息均能够被捕获，并根据业务以及审计的需要进行相应的记录和处理。

异常处理模块对于捕获的异常，通常采用信息记录的方式记录至相应的存储结构中（比如日志文件、数据库表等），平台提供了灵活的异常处理配置，可以在运行时调整异常处理的策略，比如异常信息记录的级别，异常处理的方式等。

异常处理处理组件如下图所示：

2.3.7 缓存组件

对于对于数据密集型的电子商务类应用，缓存组件可以极大提高系统的吞吐量并减少请求响应时间。iTP2P（Third-party Payment Platform）技术平台的缓存组件由是本地的Java的分布式缓存和远地的Memecached集中式缓存结合而成。对于只读类型的数据，例如系统中的类似省份城市的相对稳定的数据，产品采用基于Java的本地缓存，具有快速、简单、多种缓存策略（FIFO、LRU、LFU）的特性，通过配置的方式针对接口的方法调用实现内存、硬盘的二级缓存机制，无需考虑担心内存不足导致缓存失效的问题，此外缓存数据还可以在JVM虚拟机重启的过程中持久化到硬盘中以防止缓存数据的意外丢失；对于读写型数据，例如系统中类似于商品描述、商品价格等频繁变动的数据，产品采用基于Memcached的远地集中式缓存，Memecached使用内存管理数据，通过缓存数据库查询或者与其他系统交互返回的结果，减少与数据库或者其他系统交互的次数，减少响应时间，此外Memecached使用客户端实现负载均衡，可支持缓存服务器水平和垂直扩展。iTP2P（Third-party Payment Platform）技术平台的缓存框架基于AOP实现了对两种缓存的封装，对于业务逻辑实现者可以透明的使用方法调用返回的数据，而无需关心数据本身是否来自缓存。下图为缓存框架的示意图：

2.3.8 通用会话组件

HTTP协议是无状态的，但通过Session机制，就能把无状态的变成有状态的。Session的功能就是保存HTTP请求之间的状态数据；有了session的支持，就很容易实现诸如用户登录、购物车等网站功能。

会话保持可以由客户端和服务器端来分别实现，客户端使用Cookie保存会话数据，服务器端使用Session保持会话数据。但使用服务器端保持会话会有诸多限制：如容量限制、会话复制的限制等等。为了确保第三方支付平台良好的伸缩行和可扩展性，iPay提供了同时支持Cookie和Session的会话组件。

通过精心设计，会话组件良好的伸缩性和可扩展性表现在以下几个方面：

  使用标准的HttpSession接口，而不是增加新的API。这样任何WEB应用，都可以轻易在两种不同的session机制之间切换。

  应用程序不需要知道session中的对象是被保存到了cookie中还是别的什么地方。

  Session框架可以把同一个Session中的不同的对象分别保存到不同的地方去，应用程序同样不需要关心这些。例如，把一般信息放到cookie中，关键信息放到DB中。甚至同是cookie，也有持久和临时之分，有生命期长短之分。

通用会话组件的示意图如下所示：

2.3.9 安全组件

安全组件面向Web应用安全中常见的脚本注入（Injection）、跨站脚本攻击（XSS）、跨站请求伪造（CSRF）、不安全的直接对象引用等，构建了一道可定制化、可监控的安全防线。目前保护Web应用安全的两种方式有两种方式：黑名单机制（阻止含有非法内容的请求）和白名单机制（允许含有安全内容的请求）。iTP2P（Third-party Payment Platform） Web应用安全有两部分组成：iTP2P（Third-party Payment Platform） Web应用安全检测插件（可插入、易扩展）和iTP2P（Third-party Payment Platform） Web应用安全威胁处理插件（可追溯、实时性）。

iTP2P（Third-party Payment Platform） Web应用安全有两部分组成

2.4系统安全性

2.4.1客户端安全

2.4.1.1 验证码

通过系统生成4至6位随机字符（可定制）或者生成简单的问答，在用户登录时，需要用户手动输入，这样即防止了网络爬虫或者机器人的攻击，又缓冲了对服务器的瞬时高并发请求。

2.4.1.2 动态密码

通过系统生成随机的密码序列，校验用户输入的、对应于密码串的序列字符来判断用户的合法性，从而提高系统的安全性。这种方式既替代了大部分证书方式的安全性，同时降低了总体安全成本，而且符合用户习惯，方便使用。在用户的登录页面上，生成用户此次登录需要输入的密码串序列，用户根据此序列输入开户时所发密码卡中的密码串对应字符，形成有效的密码。

2.4.1.3 手机随机码

使用这种安全方式的用户，可以在登录或支付时在其预先登记的手机上收到支付平台以短信方式发出的一次性随机码，将该随机码输入系统，才可完成登录或支付。

2.4.2 应用层安全

应用层安全包括数据的不可否认性和保密性，以及对用户的认证、支付平台的安全，首先要为服务器申请第三方认证权威颁发的服务器证书，防止假网站，确保个人用户和商家访问的是真正的会员中心服务器。本方案中采用SSL技术来解决数据加解密问题，使用安全控件、动态密码、手机随机码解决身份认证问题。

2.4.2.1 SSL网关

SSL网关被放在停火区内，为Web服务器提供安全的SSL数据通道。

用户办理个人信息相关的操作，例如登录等，都是通过SSL网关进入到支付平台应用系统环境来的。

2.4.2.2 应用服务器安全

通常采用的应用服务中间件具有适应性强的安全架构。安全管理员无须应用编码，就能设计和实施实时、现实的运行时安全策略。

  安全服务：应用服务中间件向所有的应用和组件，提供功能齐全的安全服务--先进的认证、授权、审核和加密功能。

  应用服务中间件 安全框架：应用服务中间件从业务逻辑中去除了安全代码，让容器去保证应用的安全，从而解决了保证应用安全方面的难题。

  安全策略：通过其动态脚色映射和利用授权策略引擎，应用服务中间件 允许根据实际情况实时创建和处理安全策略与角色，因此，创建的安全策略强大而灵活。

  与第三方安全解决方案间的互操作性：应用服务中间件 安全框架支持即插即用，因此，允许外来安全解决方案管理应用服务中间件资源。

2.4.3 网络层安全

支付平台安全系统中，除了采用安全通信等技术外，网络层的安全技术也十分重要。在本方案中网络层的安全防护主要是通过防火墙，防病毒，入侵检测等安全技术，保障整个支付平台的网络层安全。

网络层安全集成的主要的建设内容，是网络安全基础设施的部署，包括安全区域的合理划分，为实现网络层安全而实施的防火墙、入侵检测、流量检测、完整性保护系统、防病毒网关等安全产品和安全技术。

典型的网络层安全需要考虑如下问题：

  需要建立防火墙用以对网络各区域进行逻辑隔离。

  需要使用VLAN划分不同网段，对关键服务器进行分组安全隔离。

  需要建立入侵检测系统随时监视网络入侵行为，阻断入侵行为并报警。

  需要建立全网防病毒系统，保护重要服务器和工作站不受病毒侵害，构成统一整体，但在病毒的管理方面实行分散管理，需要在Internet出口处建立防病毒网关，防御Internet病毒对会员中心内部的侵害。

  在主干交换机实施流量检测系统，监视主干交换机上的百兆以太模块实时数据流量。

2.4.4 系统层安全

系统层安全是针对运行支付平台运行的操作系统、中间件和数据库等软件平台进行安全防护，其主要采用的措施如下：

系统的安全补丁（Patch）

关闭不需要的进程服务和端口

使用漏洞扫描产品，定期进行安全扫描，及时发现问题并采取补救措施。

2.4.5业务安全控制

支付平台通过服务器证书、防火墙等系统来保证系统的安全性，以及通过负载均衡来保证系统的高可用性，这只是从系统和结构的角度保证系统的安全，还必须从业务的角度来保证业务的安全。主要从几个方面来保证：

2.4.5.1 用户权限设置

遵循最小用户权限原则对用户分配权限，并可以根据需要变更用户权限。

2.4.5.2 登录控制

登录日志中记录客户访问系统的远程IP地址、时间、会话ID等详细信息，可以统计客户访问系统的次数。

登录页面随机产生的附加码，登录需要输入此附加码，防止用程序恶意破解密码。

如果客户密码输入次数累计达到一定的值（具体值由系统管理员设置），系统会将此客户冻结，防止恶意攻击。

2.4.5.3 可疑日志查询

系统管理员可以登录支付平台管理系统，查询可疑的日志，可疑日志的记录类型包括密码连续输入错误导致用户被冻结等。自身可以通过客户服务系统或统一消息发送平台等渠道通知用户。

2.4.5.4 关键信息加密存储

系统对所有关键信息（如密码），都以密文进行存储，防止内部人员读取关键信息明文。

2.4.5.5 应用访问控制

系统只开放提供给用户访问的接口，而且通过接口只能完成系统提供的功能，有效防范黑客请求。

2.4.5.6 会话管理

与应用服务器的会话管理结合，实现多种会话的建立和管理，让不同的会话采用统一的管理机制，以及动态负载均衡状态下的会话数据同步。同时实现会话的超时管理，有效防范、避免黑客使用已经失效的会话攻击系统，同时防止垃圾会话数据占用内存，影响系统性能甚至使系统无法工作。

2.4.5.7 多渠道确认机制

通过系统提供的多渠道通知确认机制，使得某些安全敏感操作，可以通过手机确认等多种方式，进一步提高安全级别。

2.4.6 备份与灾难恢复

支付平台作为重要的外网网站系统，建议采用应用级的灾备方案，搭建异地灾备中心，实现业务的高可靠性运转。基本备份策略如下：

1.系统每日业务终了，进行全部数据备份，并做异地保存，全部数据备份采用磁带介质。

2.每月月终备份永久保存。

3.系统升级前的程序和数据永久保存。

4.数据库服务器均双机热备。

灾备系统的搭建采用和生产系统一致的设备及软件选型，数量为生产系统的一半。

2.5稳定性、高容量、高性能方案

2.5.1 高稳定性、高容量、高性能方案

高稳定性、高容量、高性能主要表现在系统的可靠性、吞吐性能、可扩展性、负载均衡能力和系统伸缩能力等方面。本方案进行过全面、大量、严格的性能测试，应用系统的各项性能指标表现优异。

2.5.1.1 高稳定性

支付平台的高稳定性，能保证网络系统中各主机24小时正常运行，并保证系统在访问高峰期能做到正常工作且快速响应。系统提供数据、进程的备份和恢复机制，防止各种可能的问题而造成损失。

本方案建议使用标准的J2EE应用服务器以及成熟的iPay 产品，以下几个方面确保了平台系统的高稳定性：

  系统采用成熟的iPay平台，最大程度上保证了系统的稳定性。

  基于iPay的开发流程是成熟稳定的：基于iPay的系统的开发，采用参数化定制的方式，辅以集成开发工具IDE。因此基于iPay的系统的开发是一个规范的开发过程。

  iPay平台自身的会话重建技术，保证了客户信息的不可丢失性，从数据层面保障了系统的稳定性。

  支持集群部署，既能充分保证支付平台具有强劲的处理能力，又能在系统关键处理环节上避免单点故障。

  支持7天×24小时不间断平稳运行，系统可用性达到99.999%，生产运行和维护互不影响。

  iPay平台支持横向扩展（增加服务器数量）和纵向扩展（增加单台服务器的硬件配置），并支持联机扩展。

  完善的交易日志处理，保障了交易信息的可恢复性和问题的可定位特性。

  准确的交易定位和监测，通过系统跟踪手段，能够准确、快速的定位和分析问题、解决问题，保证系统的正常运行。

  有效的监控平台，实现对网络节点（设备）和应用系统的实时、全面的监控和预警。

  监控平台实时的在线维护能力，有效促进了对系统问题的处理能力和系统恢复能力。

  严密的安全手段，屏蔽外来干扰。

2.5.1.2 高容量

系统本身不对注册用户容量进行限制，注册用户容量的增长对应用系统的影响主要集中在当注册用户容量增加后，相关数据表操作的性能降低，因此这种影响的技术解决办法主要集中在数据库处理层面的调整和优化，因此如何保障数据库处理层面的并发读写和可扩展性尤为重要，在多年实施经验中我们积累了对数据库处理层面的调整和优化的最佳实践--数据库切分。

数据库切分的基本思想就要把一个数据库切分成多个部分放到不同的数据库上，从而缓解单一数据库的性能问题。

对于海量数据的数据库，如果是因为表多而数据多，这时候适合使用垂直切分，即把关系紧密（比如同一模块）的表切分出来放在一个数据库实例上（如系统配置参数相关表）。如果表并不多，但每张表（如用户表和订单表）的数据非常多，这时候适合水平切分，即把表的数据按某种规则（比如按ID散列）切分到多个数据库实例上。当然，现实中更多是这两种情况混杂在一起，这时候需要根据实际情况做出选择，也可能会综合使用垂直与水平切分，从而将原有数据库切分成类似矩阵一样可以无限扩充的数据库阵列。

垂直切分的最大特点就是规则简单，实施也更为方便，尤其适合各业务之间的耦合度非

常低，相互影响很小，业务逻辑非常清晰的系统。在这种系统中，可以很容易做到将不同业

务模块所使用的表分拆到不同的数据库中。根据不同的表来进行拆分，对应用程序的影响也

更小，拆分规则也会比较简单清晰。水平切分于垂直切分相比，相对来说稍微复杂一些。因为要将同一个表中的不同数据拆分到不同的数据库中，对于应用程序来说，拆分规则本身就较根据表名来拆分更为复杂，后期的数据维护也会更为复杂一些。

iPay产品对切分后的多个数据库提供了统一的数据访问层（DAL），屏蔽了切分后的数据库访问的复杂性。

2.5.1.3 高性能

系统响应时间是指客户端接发起用户请求到客户端接收到服务器发来的数据所需的时间。响应时间直接影响用户的购物体验，从一定程度上决定了用户对于该网站的认可度。系统采用各种技术：分层缓存、压缩传输，集群等提高性能，并大量采用局部刷新、异步加载等，致力于最大程度提高用户购物体验。

我们从以下两个大的方面降低系统响应时间：

多维度缓存：从商城整体架构上来说，选择合适的缓存策略能带来性能的极大提升，iPay产品提供两个维度的缓存。

缓存的位置：从缓存使用者的角度来定义的，本地缓存是进程内缓存，适合于只读数据，远地缓存是进程外缓存，适合于读写数据。

缓存的内容：从缓存中存放的具体内容来定义的，视图缓存、处理结果缓存、数据缓存分别对应于架构体系的视图层、业务逻辑层和数据访问层。

基于事件驱动的异步处理: 事件驱动模型可以通过并发提高系统的容量和性能。事件驱动有以下三个要素：事件源：产生事件的源体；监听器：能够接收事件源通知的对象；事件处理程序：用于处理事件的对象。iPay产品针对事件驱动模型提供了三种实现：JMS、ActiveDMQ、组件容器事件发布器和监听器，iPay商城的发送邮件、手机短信均采用事件驱动的方式实现。此外iPay产品在对系统资源的使用方面（如端口监听和文件读写）采用了非阻塞API，如日终对账文件的读取使用NIO的Channel和Buffer。

此外，本方案还将采用了以下方式确保系统的高效运行：

  平台化总控改造，规范和简化了交易请求机制，提升了交易的处理能力。

  对现有系统的系统资源的使用进行了调整，规范系统资源的合理调度。

  数据（数据字典和系统参数，以及频繁调度的静态交易数据）高速缓冲技术，有效的减少系统资源的占用，提升系统处理速度。

  系统中交易流程、组件等对象实例的复用，减少了内存的开销和对象创建、销毁的过程，节省了时间，提升了速度。

  系统对有限的系统资源（如数据库资源、通信资源等）采用缓冲池技术管理，保障系统对资源的快速调度。

  多线程处理技术的使用，提升了交易请求的并发度和处理速度。

  系统中，对大部分交易对象和组件实例进行高速缓存处理，大大的减少了在对象创建上浪费的时间和资源。

  配置参数化文件的缓存处理，配置文件仅在系统启动时的访问磁盘，减少系统IO处理，有效的提升了处理速度。

  iPay自有的会话管理，采用可定制管理模式，提升了系统的处理效率。

2.6系统监控

2.6.1 监控系统的设计目标

一个系统的运行环境包括网络、硬件和软件三个部分，要保障系统的正常运行，监控系统必须能够从网络节点（包括网络和设备）和应用这两个层次对系统进行全面监控。

网络节点的监控，是实现对系统运行环境的物理资源的监控，对一个交易系统来说，网络节点的监控，就是实现对交易流程中涉及的各个设备环节的监控，也即交易节点监控。应用监控是对系统运行环境的逻辑资源进行监控。

监控系统要能够确保系统的正常运行，及时的发现问题，并做出响应，监控系统必须满足以下基本要求：

2.6.1.1 网络节点监控

网络节点监控，可以迅速判定系统架构中的性能故障，而且不需要在被监控的服务器上安装任何软件，从而将监控带来的性能方面的负面影响降到最小，我们可以称为交易节点监控系统。

2.6.1.1.1硬件级监控

一个运行系统环境，接入了很多的设备，每一个设备（网络节点）都是一个监控点，要实现对系统的网络进行全面监控，必须达到：

网络节点间的网络情况监控：是否畅通，网速大小等

网络节点（设备）与网络节点（设备）之间的畅通性

支持动态网络节点增减

2.6.1.1.2系统级监控

系统级监控就是实现对设备的运行情况监控，如对系统是否在运行，系统内存、CPU、交换区、磁盘空间、系统IO，以及对外服务端口等系统资源情况监控等等。设备监控是从系统级别的监控。

2.6.1.1.3网络级监控

网络级监控具备如下特点：

  快速方便的实施

  方便的安装、使用和配置

  无代理、非嵌入式结构，不需要在被监控服务器上安装软件，从而将对系统的影响降到最低

  对网络资源和系统、如服务器Cluster的运行持续的进行状态轮询

  收集系统部件的详细性能数据，如CPU、虚存、交换区、进程、服务可用性等

  对其他管理工具提供广泛的支持，如为Microsoft、Citrix、BEA、Sun、Oracle、SAP和Siebel提供API

  对业界标准的广泛支持，如SNMP(v1、v2&v3)、Telent、FTP、News、email、DNS、LDAP、Radius以及其他一些服务

  支持从其他来源收集性能数据，如日志、命令行或批处理文件

  支持动态或静态基线的门限值设定

  故障确定后提供多种方式的告警

  支持监控的网络节点动态增减

2.6.1.2 应用监控

应用监控就是监控设备上运行的应用软件的运行状态。对不同的应用软件，监控功能不一样。

对应用的监控，除了实现对应用系统的运行情况进行全面监控外，还要对应用流程实现全流程监控：从应用流程的发起点到应用结束点，涵盖所有的流程环节。

2.6.2 监控系统设计

监控系统的运行要求配置一个监控服务器，实现如下监控模式：

  根据监控系统配置的监控规则（如服务器类型，操作系统类型，采用的协议模式，访问授权信息等），主动获取监控对象的监控数据。

  根据参数配置，启动监控守护线程，被动接收从监控代理发送过来的监控数据信息

  分析监控数据，按照监控规则进行处理，如预警处理，监控信息通知，监控报表生成等

  监控人员通过监控终端，登录监控服务器，查看被监控的系统状态，并对被监控的系统进行实时在线维护。

2.6.2.1 网络节点监控方案设计

网络节点的监控，需要支持动态的网络检点增减，因此对网络节点的监控主要是针对具体的监控设备或网段，采用主动获取的监控方式，监控网络畅通状态和设备状态，获取监控信息。

网络节点的监控对所有的应用系统相同。

2.6.2.2 应用监控方案设计

应用监控主要是实现业务的全流程监控，从业务流程的发起点到业务流程的结束，完成对各个应用环节的监控。

应用监控分主动监控数据获取和被动监控数据获取两种方式，主动获取由监控服务器发起，被动监控数据由部署在各环节上的监控代理获取，然后发送到监控服务器。监控人员通过监控终端登录监控服务器，查看应用状态和业务流程状态，以及各个环节的运行状态，并进行在线实时维护。

对不同的应用，应用监控要求各不一样，需要针对不同的应用软件环境和硬件环境，进行定制。

2.6.3 第三方支付平台系统监控设计

对于第三方支付平台系统来说，最为直接和迫切需要的，就是可实时报警和反馈的监控系统。该系统可以7x24不间断访问测试系统，提供最为实时和直接的警告。使系统管理员及时加以处理，减少反应的时间。

第三方支付平台系统的监控也需要从网络节点（包括网络和设备）和应用这两个层次实现全面监控。

2.6.3.1 网络节点监控

如网络节点监控设计目标所述，网络节点监控包括网络级监控和系统级监控，在第三方支付平台系统会员中心系统中，将根据接入设备和网络部署情况，进行监控策略定制，实现对系统的各个环节进行有效的监控和维护。

系统网络节点的监控实现参见上节的监控系统设计。

2.6.3.2 系统应用监控

第三方支付平台是一个7x24不间断的客户交易系统，通过监控系统进行分析，以确定系统的运行情况和故障环节。就是实现对第三方支付平台的WEB服务器的应用软件、应用服务器的应用软件和数据库服务器的应用软件的运行情况进行监控，尤其是应用服务器的应用软件——第三方支付平台的运行情况进行监控。

监控系统对第三方支付平台的监控，应该包容如下内容：

监控：

系统状态查看

系统资源情况

系统登录用户数、并发用户数监控

系统维护

监控启动停止操作

应用系统启动停止操作

系统资源在线维护

系统内部组件在线实时调整

系统参数在线实时维护

系统耗时对象并发数在线控制

以上只是部分功能列举，监控系统必须具备灵活的扩展性，可根据具体的应用需要，可进行扩展。

第三方支付平台的基础平台iTP2P（Third-party Payment Platform），符合JMX标准，能通过监控平台iTP2P（Third-party Payment Platform） Monitor进行全面的应用监控，如系统运行状况、资源状态、耗时对象等等的监控，并能够针对问题，对生产系统进行实时在线调整维护。

2.6.4 iTP2P监控平台Monitor介绍

2.6.4.1 iTP2P Monitor的逻辑框架