中国联通电子商务平台支付系统技术规范书24页文档资料Word格式文档下载.docx

1、“伯安入小学，颖悟非凡貌，属句有夙性，说字惊老师。”于是看，宋元时期小学教师被称为“老师”有案可稽。清代称主考官也为“老师”，而一般学堂里的先生则称为“教师”或“教习”。可见，“教师”一说是比较晚的事了。如今体会，“教师”的含义比之“老师”一说，具有资历和学识程度上较低一些的差别。辛亥革命后，教师与其他官员一样依法令任命，故又称“教师”为“教员”。 2019年12月1. 概述1.1 本文件是中国联合通信有限公司（项目业主，以下简称甲方）电子商务平台支付系统技术规范书，供系统集成商（投标人，以下简称乙方）编写技术应答书。1.2 乙方应在应答书中对本文件内容按顺序逐条应答。对解释性或说明性条款按“

2、理解”或“不理解”应答；对非解释性或说明性条款按“满足”或“条件满足”或“不满足”应答，然后给出详细的功能实现说明。1.3 乙方必须是从事计算机软件开发的企业，并具有良好的企业信誉，足够的经济实力，较长的生命力和延续性，充足的技术队伍，稳定的组织机构。乙方需向甲方出示有效企业资质证明。1.4 乙方应根据本文件中的相关说明和要求，提出总的技术建议和解决方案，并对所提供软件的特色部分给出附加说明。乙方若对本文件中的部分要求不能满足或者有不同于本文件相关要求的其它建议，也应在应答书中详细说明。1.5 若乙方建议的技术方案及软件系统配置符合有关国际或行业标准，则应在应答书中具体说明，并附上相应的详细技

3、术资料。若乙方的软件系统包含自己专用标准，也应在应答书中具体说明，并附上相应的详细技术资料。若乙方在建议的方案中用到第三方的软件产品，要求提供相应软件产品的详细技术资料。1.6 乙方应按照要求提供六份中文技术建议书、应答书和软件系统配置清单，并提供上述文件的电子版，电子版要求为MS Office格式。 1.7 甲方保留对本文件的解释权和修改权。2. 项目概况2.1 概述随着相关技术的发展和消费者消费习惯的改变，电子商务已经由前几年的商业炒作转变为实际的应用，世界范围内以及国内的电子商务业务量都在快速增长，而移动电子商务（手机、PDA等）所占的市场份额也越来越大。中国联通作为国内业务种类最为齐全

4、的电信运营商，有着完善的基础网络设施，包括覆盖全国的传输网和基于传输平台的ATM数据网以及165网，联通总部和各省的165网站，同时还拥有大量的移动用户，并且正在进行移动数据网的建设，所有这些都为电子商务的开展提供了有利的条件。为更好的开展电子商务业务，中国联通决定建设电子商务平台，通过平台的建设可以为联通公司以及社会上其它开展电子商务业务的单位提供安全、支付、站点等支撑功能，减少电子商务业务开发所需要的工作量。从项目建设的角度讲，本工程包括CA认证系统、支付网关、电子商务站点、电子商务应用系统等具体的项目，其中认证、支付和站点属于电子商务平台建设范围，应用系统属于电子商务业务系统，与平台无关

5、，但是考虑到业务开展的需要，在本期工程中建设部分易于开展的应用系统。考虑到电子商务是一个比较新的业务，中国联通将在电子商务业务开展比较好的几个省进行试点工作，本期工程试点省包括北京、上海、山东和广东。中国联通电子商务平台支付系统是为了满足电子商务用户的各种支付要求和电子商务站点对支付功能的要求，在电子商务平台中建设独立的支付系统，为用户和电子商务站点提供统一的支付接口，并实现和各银行支付系统的连接。2.2 中国联通电子商务系统总体结构为方便系统建设，中国联通电子商务系统从功能上划分为两层：业务系统和电子商务平台，业务系统负责具体的业务实现，如业务流程、用户界面、与相关后台业务系统的连接等；电子

6、商务平台负责提供通用的支撑功能，包括认证、支付和电子商务业务开发平台。联通电子商务系统的总体架构如下图所示。图1 联通电子商务系统总体架构2.3 支付业务介绍2.3.1 业务开展模式根据联通公司在电子商务业务中的定位，支付系统的业务开展模式如下：1 向商家收取手续费，商家使用支付系统的支付服务，支付系统根据交易数量或支付金额收取一定比例的手续费；2 向用户收取手续费，由于通过电子商务平台向用户提供服务可以为用户带来一定程度的便利性，降低用户交易成本，因此可以向用户收取一定费用。2.3.2 支付方式传统的电子商务支付以网上支付为主，考虑到联通开展电子商务业务的特殊性，需要充分利用联通公司的移动客

7、户资源，本系统应支持各种基于移动终端（短信、WAP等）的支付；另外目前电子商务业务中存在着大量的小额支付业务，如购买彩票、书籍等低价商品，网站收费等，上述支付如果通过银行账号支付对于用户操作比较繁琐，如果计入用户话费将可以大大方便用户使用。根据上述要求，本系统支持的支付方式如下：基于计算机终端和银行账号的支付，即网上现有的各种电子商务业务中的支付方式；基于计算机终端和联通业务资源的支付，用户通过计算机终端和浏览器使用联通话费等业务资源进行网上支付；基于移动终端和联通业务资源的小额支付，用户通过联通手机以WAP、短信等方式使用联通业务资源进行支付，主要用于小额商品的支付；基于移动终端和银行账号的

8、支付，用户通过联通手机以WAP、短信等方式使用银行账号进行支付。乙方在方案建议书中应对支付方式提出自己的建议。2.3.3 支付系统功能根据支付系统的业务需求，支付系统应具有以下功能：用户接入，支付系统应提供灵活的接入方式，允许用户（包括个人用户和电子商务商家等）接入支付平台，目前提供的接入方式包括计算机终端的浏览器方式、用户电子钱包、短信、WAP等方式；支付功能，支付请求的处理、转帐、对账等各种有关支付的操作，支付系统应根据B2C业务和B2B业务的不同要求分别提供不同的支付处理方式，包括用户接口和后台业务流程；计费结算，根据支付系统的业务开展模式，支付系统需要提供计费结算功能，对每一笔交易记录

9、进行统计，提供计费详单和结算单，计费详单和结算单一方面用于和商家对账，另一方面用户提交给联通营业账务系统向用户收费；系统管理，由于支付系统需要不断接入新的商家，因此需要提供用户和商家管理，在支付平台中注册和管理不同类型的用户和商家资料，如简单的用户属性信息或复杂的账户信息等，用户和商家可以在支付平台查询自己的历史交易记录；统计分析，对支付系统的业务记录进行汇总和分析，提供各种统计分析报表。2.4 体系结构中国联通电子商务平台支付系统最终包括两级：全国中心，负责全国性的支付业务和跨省支付业务，省中心，负责省内支付业务，地市不再建设支付平台。全国中心负责与全国性商家、全国性的银行支付接口、综合结算

10、系统全国中心等连接，对于提供全国统一接口的银行，由全国中心负责接受各省发送的支付请求并转发到银行支付网关；对于提供分散接口的银行和基于联通话费的手机小额支付，全国中心仅负责将跨省的异地支付请求转发到用户归属地的省内支付平台；全国中心同时负责支付系统的省际结算，将结算结果发送到联通综合结算系统全国中心以及各省支付平台。省中心负责与本省内商家、银行系统省内支付网关、联通省内电信业务支撑系统（计费、营帐、结算等）互联，所有省内支付（用户所属银行的支付网关在省内，或本省用户使用话费在省内支付）由省内支付平台处理，跨省的异地支付由省内支付平台转发到全国中心处理；省内支付平台同时从全国中心获取结算结果并和

11、全国中心对账。最终的支付系统体系结构如下所示。图1 支付系统体系结构考虑到系统建设初期业务量不会很大，没有必要在各省建设支付系统，因此本期工程只建设支付系统全国中心，由全国中心完成全国范围内支付业务的处理，与四个试点省业务支撑系统的连接也全部由全国中心负责。本期虽然不进行各省支付平台的建设，但是整个支付系统的结构应按照最终的体系结构设计，本期全国中心的功能应包括全国中心及省中心功能，全国中心可以作为虚拟的省中心使用，以后在需要的时候可以随时将省中心分离到省内。2.5 支付流程针对不同的支付方式和不同的支付系统组网方式，存在不同的支付流程，下面以短信方式、基于联通话费的跨省支付为例介绍支付流程的

12、设计。图1 异地支付流程示意图图中各支付步骤含义如下：（1） 手机用户发送短信到电子商务平台要求支付；（2） 短信网关将短信转发到电子商务平台；（3） 电子商务平台判断该用户非本省用户，将支付请求转发到全国中心；（4） 全国中心将支付请求转发到用户归属地；（5） 归属地电子商务平台将扣费请求发送到业务支撑系统；（6） 业务支撑系统将扣费结果返回到电子商务平台；（7） 电子商务平台将支付结果返回到全国中心；（8） 全国中心将支付结果返回到商家所在省中心；（9） 省中心将用户支付信息发送到相应的商家；（10） 省中心将支付确认信息发送到短信网关；（11） 短信网关将支付确认信息发送给用户。上述流程

13、仅供乙方参考，并非最终确定的流程，乙方应根据自己的经验，参考联通支付系统业务需求书，在建议书中和需求分析中详细描述各种支付方式的流程。2.6 支付系统结构为便于系统扩展以及适应今后的业务发展，支付系统内部应根据功能划分清晰的层次，各层实现本层的功能，层与层之间采用支付系统内部定义的标准接口，某一层内部功能或结构发生变化时不影响其它层。根据支付系统功能划分，可以将所需功能划分为用户接入、业务处理、后台业务系统连接三部分，相应的内部模块和层次划分如下图所示。图3 支付系统层次划分上图中支付系统划分为三层：表示层、业务逻辑层和数据层，分别对应于用户接入、业务处理和后台业务系统连接。表示层是本系统的接

14、入层，所有用户和电子商务参与单位通过该层接入支付系统，表示层对外提供标准的支付接口，支付接口针对不同的支付方式、不同的支付终端类型提供不同的接口，并将用户的支付请求转换为标准的支付请求发送到业务逻辑层，通过表示层可以对业务逻辑层屏蔽用户接入方式的差别。业务逻辑层用于具体的支付请求处理和相关的各种管理操作、后台账务处理等，包括具体的支付流程处理，根据不同的支付方式完成各种支付请求；计费结算，通过对支付记录的处理完成计费处理，生成向用户收费的详单、账单和与商家、银行之间的结算单，另外还要完成与各省分公司及各部门之间的结算；账务处理完成与各交易合作方之间的对账等功能；系统管理完成商家、用户等的管理，

15、可以设置商家及用户属性，允许商家和用户查询交易情况等；接口模块用于对不同的支付方式转换为不同3. 功能需求3.1 支付支付是本系统的核心功能，为了完成具体的支付处理，系统需要以下功能：用户支付请求受理，能够通过各种方式受理用户的支付请求，包括基于INTERNET和短信等方式；支付请求的分析处理，对用户的支付请求进行分析，确定支付类型，根据支付类型转不同的业务流程进行处理；账务处理，包括计费、对账、转帐、结算、手工调整等功能，完成与用户、商家、银行等与支付相关的各种账务流程的处理。3.2 管理支付系统应具有比较强的管理功能，可以随时完成对商家、用户、业务等的管理。商家管理用于对商家的增、删、查、

16、改，可以修改商家的各种支付参数，包括结算周期、对账方式、费率等信息，同时允许商家查询与自己相关的详细支付情况；用户管理实现对支付用户的管理，包括用户资料修改、交易情况查询等，并允许用户查询自己的交易记录；业务管理用于针对不同的业务类型维护该业务的各种业务参数；系统管理，用于对支付系统进行各种管理，包括系统参数配置、操作员管理、权限管理、数据备份恢复等；整个电子商务平台将设置统一的网管平台，对认证、支付、站点等统一进行管理，乙方不需要考虑网管平台的建设。3.3 与其它系统接口由于支付系统涉及到用户、商家、银行、联通业务支撑系统等多个系统，与其它系统的接口比较复杂，因此乙方应对接口部分作为重要的功

17、能进行详细的设计和描述。与用户和商家的接口属于本系统提供给其它系统的接口，可以由本系统提出接口标准，并对外提供接口协议或接口模块供其它系统使用；与银行和联通业务支撑系统的接口需要遵循银行和联通业务支撑系统现有的接口标准。3.4 代收费系统由于联通拥有遍布全国的营业系统和完善的计费帐务系统，因此可以为其它单位提供代收费服务，尤其是目前很多收费网站向用户收取一定的费用以提供各种信息服务，由于金额较小，用户缴费不太方便，联通公司可以替上述网站收费并从中收取一定的手续费，也可以为社会上其它行业和单位代收小额费用。用户可以通过短信、WAP等方式向代收费系统发送收费请求，由代收费系统完成扣费后将扣费结果同

18、时反馈给用户和收费单位。代收费系统属于应用系统，但是考虑到与支付系统关系比较密切，因此由乙方与支付系统一起开发。3.5 详细的功能需求参见中国联通电子商务平台支付系统业务需求。4. 总体要求4.1 乙方应在对中国联通电子商务平台深刻理解的基础上，结合联通公司业务特点，对联通支付系统的建设提出建议的系统方案。4.2 乙方应对支付系统进行周密的论证，对所建议的方案在安全性、可靠性、可行性和可扩展性方面采用的方案作出详细的描述。4.3 乙方应针对本项目成立专门的项目组，项目组成员必须稳定，在项目终验前不得退出或更换，若因特殊原因需调整，需经甲方同意。4.4 乙方应向甲方提供完整的支付系统软件,应负责

19、完成整个软件系统和硬件设备的互连互通，保证整个支付系统的正确运行。若因乙方失误，造成系统运行错误或硬件、软件短缺导致系统达不到原定性能指标，乙方应免费进行补充，直至满足要求。4.5 乙方应对系统所需要的软件和硬件设备的配置、数量提出明确要求，提供应用软件在不同配置下的系统处理能力等性能指标。4.6 乙方应承诺其应用软件满足平滑移植，即应用软件与硬件平台相对分离，应用软件可以自由运行在主流操作系统的主流硬件平台上。乙方应明确给出选用的应用软件平台的具体特性和使用限制。4.7 乙方应保证不同时期提供的同类软件兼容。5. 技术要求5.1 处理能力乙方应对所提供系统的处理能力进行详细说明。5.2 安全

20、可靠性联通支付系统应该提供724小时的不间断服务，当线路和设备局部故障和异常情况发生时，系统应具有检错、纠错功能；系统能够提供数据备份与数据恢复功能，确保数据正确、完整；能够抵抗来自系统外部和内部的攻击，保证系统安全、可靠地运行。5.3 开放性支付系统必须具有充分的开放性，提供标准接口用于商家和用户的接入，在运行过程中可以随时接入新的商家、提供新的用户接入方式、开展新的业务类型。支付系统应能适应用户各种客户端的要求，如电子钱包方式、浏览器方式、移动终端方式等，并支持各种主流的操作系统和浏览器。5.4 可扩展性5.4.1 体系结构的扩充联通支付系统体系结构具有可扩展性，可以随时在规模、节点设置等

21、方面进行扩充。5.4.2 软、硬件系统的扩充支付系统的软、硬件系统应具有模块化结构，能够灵活配置设备，方便地进行在线扩容和升级，同时应用软件也应具有模块化扩展能力，以适应扩大业务范围、增加多种应用的需要。5.4.3 容量的扩充系统建设初期，考虑到电子交易量少，系统规模可以较小并集中建设，随着电子商务的发展、交易量的上升，支付系统全国中心的处理能力能够不断地增加，并且可以随之新建省中心，可以很快完成省中心与省内站点和全国中心的互联。5.4.4 适用于多种应用需求支付系统应能够满足联通公司各业务部门开展电子商务的需求，以后其它业务部门提出新的支付方式时可以很快满足需求。5.5 易操作性应提供友好的

22、人机界面，必要的信息输出需要汉化。5.6 易维护性应具有故障诊断和恢复能力，并提供相应的软件测试工具。5.7 高效性支付系统要有较快的响应时间，乙方应对此提出相应的量化指标。5.8 产品要求乙方提供的支付系统应包括整个系统运行所需要的全部组成部分，包括所需要的硬件设备、系统软件、应用软件以及系统开发运行所需要的第三方软件，其中应用软件包括支付系统全国中心软件、省中心软件、支付系统向电子商务站点提供的接口模块，用于其它应用系统调用支付系统功能。5.9 网管接口乙方所提供的软硬件设备应支持SNMP等标准的网管协议，硬件设备和系统软件可以由电子商务平台网管系统直接进行管理，应用软件可以通过网管接口向

23、网管软件提供故障和性能参数，纳入网管系统统一管理。6. 招标范围6.1 招标范围本次工程范围包括：（1） 支付系统全国中心软硬件平台（含省中心软件部分）；（2） 支付系统全国中心与银行支付网关的互联；（3） 支付系统全国中心的省中心模块与四个试点省的业务支撑系统、电子商务站点的互联；（4） 在全国政协建设代收费系统，为各种网站等第三方提供缴费手段。6.2 乙方负责上述工程范围内的硬件设备供货、软件开发、安装、调试、培训和售后服务，并负责配合和电子商务平台其它系统（认证平台、电子商务业务平台、应用系统等）的互连。7. 项目管理7.1 甲乙双方对本项目应用软件进行合作开发，在软件设计、开发、调试和

24、安装等系列过程中均由甲乙方人员共同参与实施，为此项目甲乙双方组建联合开发小组。7.2 乙方提供的产品中，涉及到第三方产品，若出现技术上或法律上的纠纷，应由乙方负全部责任，并确保不影响项目进度。7.3 在项目实施的全过程中，甲方有对项目进度进行监督控制的职责和权利，乙方应全面配合，每两周向甲方提交一份最新进展情况报告。7.4 在项目实施的全过程中，甲方有对软件质量进行监督控制的职责和权利，乙方应全面配合，确保人力、物力的定量投入，并每两周向甲方提交最新文档资料。7.5 乙方对软件的开发应严格按照软件工程理论进行管理，各阶段都应提交相应的设计、开发技术文档，并经甲方认可。8. 知识产权8.1 甲方

25、拥有本项目开发的应用软件（包括源程序和各种文档）的所有权。8.2 乙方将本项目的所有设计文档、源代码和相关资料移交给甲方，并保证文档的一致性和完整性，乙方有责任对第三方保密。8.3 甲方为乙方提供的所有业务技术资料、文档，乙方有责任对第三方保密。8.4 乙方全面承担由乙方产品中涉及到的第三方产品所引起的一切法律责任。9. 技术文档9.1 乙方应提供在对业务功能进行详细分析的基础上，根据技术规范书的要求编写的应用软件需求说明书。9.2 乙方应提供应用软件逻辑设计文档，系统结构设计文档，数据库设计文档，接口需求说明书，接口设计文档，程序详细设计说明书，应用软件模块设计文档，软件故障处理流程文档。9

26、.3 乙方应提供软件模块关联图，数据流程图，对模块之间的调用关系和调用接口给出详细说明。9.4 乙方应提供应用软件配置说明书和应用软件使用说明书（包括用户手册、操作手册、维护手册）9.5 乙方应提供完整的、准确的源代码、目标代码，源代码文档中对主要的函数调用要求作出说明和详细注释。9.6 乙方应提供应用软件开发总结文档，对软件开发过程中的主要技术问题给出详细解答。9.7 乙方提供的文档和资料均应以磁介质（或光盘）和纸张为载体，文件格式为Word文档或PDF文档或其他可视化文件。10. 技术服务10.1 若关于支付系统的要求和需求发生非重大变动，在本项目最终验收之前，乙方应免费对系统进行相应的修

27、改，在本工程项目保修期内和保修期后，乙方应以优惠价对系统进行相应的修改。10.2 根据乙方向甲方所提供的应用软件系统以及甲方的需求，乙方应向甲方提供全方位的、有效的、及时的技术支持和服务。10.3 乙方负责所提供的应用软件系统的现场安装、调试和开通，软件系统安装、调试时所需的工具软件、补丁包等均由乙方负责。10.4 系统试运行期六个月（具体期限由双方商定）。在试运行期间，乙方应向甲方提供724小时的响应服务，若乙方所提供的应用软件系统出现问题或故障时，乙方应指定相关的开发技术人员在4小时内赶到现场，免费进行故障处理和软件更新。在试运行期间如出现重大问题（系统瘫痪或故障率大于3%），则试运行期从

28、故障修复之日起重新计算。10.5 乙方应对其提交的软件产品提供不少于3年的免费维护期。在维护期内，乙方应向甲方提供724小时的响应服务，保证在任何时候甲方人员都能及时找到乙方的相关专业技术人员。如甲方认为必要，乙方的技术人员应在24小时内赶到现场予以相应的技术支持。保修期从终验合格证书签署之日起开始计算。乙方应给出保修期结束之后对所提供的软件系统的服务支持方式和费用。10.6 乙方对其提供的软件应提供至少10年的技术支持。10.7 乙方应在技术建议书中详细说明技术支持、服务的范围和程度。10.8 系统开通运行后，乙方要应甲方的要求定期对用户进行免费技术培训（原则上一年内一至两次）。11. 人员

29、培训11.1 乙方应向最终用户提供有关应用软件开发、运行维护等方面的详细培训计划，并提供培训环境，通过培训，使最终用户的技术人员能够达到以下水平：熟练使用应用软件所采用的各种开发工具，具有独立开发能力；掌握应用软件的运行维护方法，能够独立安装和调测应用软件；掌握应用软件中的处理流程、编程方法以及函数调用，能够对应用系统进行配置、剪裁，掌握应用软件的修改和扩充方法，具有独立对应用软件修改和扩充的能力；具有熟练查阅各种技术文件及维护手册的能力。11.2 除了上述培训外，乙方还须在项目实施过程中，对参加开发的最终用户人员进行现场培训，即一边实施开发，一边培训，在实施过程中进行技术转移。11.3 乙方应提供最终用户根据系统事实的具体需求而提出的培训。11.4 乙方承担培训任务的师资应具有三年以上的授课经验，并具有相当的理论水平和实际工作经验。11.5 培训人数CA中心高级培训（总部）4人，RA中心培训15人（总部及四个试点省各3人），培训所需的交通和食宿等费用由乙方负责，培训课程应包括系统管理维护培训和业务系统培训，乙方应在建议书中提出详细的培训课程和时间安排。