技术规范标准_某公司电子金融管理平台技术规范书

中国电信云南公司2017年电子金融管理平台技术规范书 创新业务部二一七年六月我们总羡慕别人的幸福，却常常忽略自己生活中的美好。其实，幸福很平凡也很简单，它就藏在看似琐碎的生活中。幸福的人，并非拿到了世界上最好的东西，而是珍惜了生命中的点点滴滴，用感恩的心态看待生活，用乐观的态度闯过磨难。目 录1前言11.1项目背景11.2工程目标32需求分析62.1商户信息管理模块62.1.1业务场景支撑和规则说明62.1.2商户信息同步流程72.1.3商户信息综管台管理72.2营销活动管理模块82.2.1业务场景支撑和规则说明92.2.2基础返利102.2.3营销规则配置122.2.4营销成本管理132.2.5营销活动监控132.2.6清结算报表132.2.7营销数据来源管理142.2.8批充后返功能管理142.2.9关联套餐返利162.2.10关联用户组返利162.2.11 代金券应用172.2.12 微信公众号营销202.2.13 结算对账272.2.14 营销结果查询与统计272.2.15其他接口272.3数据分析管理模块272.3.1业务场景支撑和规则说明282.3.2用户数据集团同步接口282.3.3个人账户纬度的交易数据集团同步接口292.3.4商户纬度的交易数据集团同步接口292.3.5统计查询报表292.4运营风险管理模块302.4.1业务场景支撑和规则说明302.4.2实现省内交易状态监控312.4.3实现省内活动成本监控312.4.4实现省内对账结果监控312.4.5实现省内接口能力自监控312.4.6具备差错处理能力322.5 数据处理中心322.5.1用户数据采集322.5.2商户数据采集332.5.3交易数据采集333系统设计343.1系统特性343.2系统技术架构353.3安全体系363.3.1目标与方法373.3.2数据交换安全383.3.3数据库安全393.4系统管理403.4.1日志管理403.4.2操作员日志413.4.3配置管理413.4.4参数配置423.4.5用户和权限管理423.5系统备份443.5.1数据库系统数据的备份443.5.2日志文件等的备份453.5.3核心系统联机热备份454系统部署方案464.1系统组网结构464.2网络及系统资源测算484.3存储空间计算484.4网络带宽计算504.5硬件设备清单及预算524.6软件运行环境524.7 维护支撑内容535软件功能列表及预算536备注571 前言1.1 项目背景本方案为中国电信云南公司电子金融管理平台项目技术建议书。中国电信云南公司为了配合中国电信天翼电子商务有限公司全国个人（C类）账户平台的建设内容，基于具体实现适当优化、业务系统交互安全、业务数据一致的原则下，实现统一管理、省市自主运营的目标，在云南省内建立了以翼支付账户为基础的省级翼支付管理平台（现统称云南省电子金融管理平台）。为提升省内翼支付平台功能，加快本地需求响应速度，加强对云南省内消费情况的监控能力，省内自主营销，因此，为了支付翼支付业务健康地发展，提出建设中国电信云南公司电子金融平台，重点在营销活动支撑、数据分析及应用、商户管理等方面加强翼支付平台功能。存在问题在实际拓展业务时发现主要发现存在以下问题：（1） 省内自有翼支付商户管理功能欠缺。目前云南省翼支付商户统一在集团平台注册、审核、管理，省内核查或获取商户信息需要登到集团平台进行操作，无法将商户在本省内进行针对性的营销和有效管理。而商户亦无法自助管理自身的交易数据、不能自主发起自身的营销活动，需要经电信审批或二次包装后方可开展推送活动。（2） 省内个性化营销管理功能欠缺。营销活动主要是为了提高翼支付用户使用基于翼支付账户的翼支付业务的交易频度与交易金额，以及吸引非翼支付用户转化为翼支付用户、提高翼支付品牌知名度与扩大翼支付业务使用范围，从而不定期推出的各种优惠促销活动，并可增加线下商户及用户的拓展。然而云南省翼支付平台并没有自身的营销管理功能，仅可以参加集团统一管理固定配置的简单优惠活动。远远无法满足省内个性化营销业务需求，如无法针对某些商户、某些用户的返利、赠送代金券等叠加营销。在集团侧难以支撑各省本地个性化业务的开展的前提下，省内就无法及时推广营销活动，不能让用翼支付用户充分体验各种营销活动带来的价值。（3） 省内数据管理功能欠缺。全国所有的核心账户数据均在集团平台，大量的用户数据、交易数据、活动数据、商户数据、对账数据、结算数据汇集在集团，导致省内每次需要核查或导出数据时，集团报表平台响应能力不足，亦无法针对省内需求制定出满足要求的报表。并且消费数据不在本地平台，无法及时监控云南的消费情况，存在安全隐患。（4） 省内运营风险监控管理功能欠缺。目前云南省翼支付平台与集团支付中心核心账户信息交互，基本使用人工编辑、界面导入的方式，难以管控操作过程中的差错和不规范。针对数据对账、成本监控、用户交易异常、商户套利套现、系统运营异常等核心问题亦没有做到实时监控，尚处在手工核对阶段，需要花费大量人力、物力，实际效果还得取决于集团的支撑力度。总体而言，云南省翼支付平台的建设严重落后于全国翼支付建设的水平，仅有建设了翼支付平台的基础功能。在支付公司全国范围内大力发展翼支付、以营销方式推广品牌的背景下，云南省内翼支付平台功能和支撑能力均与日益增加的翼支付用户量不符、与日益增长的交易量不符、与日益膨胀的省内个性化营销活动需求严重不符，已不能满足业务拓展的需要。为了确保翼支付在云南的稳定、可持续的发展，对翼支付平台的提升改造迫在眉睫。中国电信云南公司需要在目前的情况下直接跟进最新、最主流的平台建设思路，大跨步拓展相关业务，循序渐进加强平台建设以适应业务发展的需要，提升企业在移动支付业务上的竞争力。1.2 工程目标云南省电子金融管理平台项目的建设将主要达到以下几个目标（根据云南实际情况分布实施）： 商户信息管理：通过接口或文件方式，获取省支付平台与集团平台商户相关数据，便于营销活动关联商户、数据经营分析以及有效进行商家信息管理； 营销管理模块：实现省内配置营销活动、管控营销规则权限，通过返利、赠送代金券、批充等方式对pos交易、扫码数据、微信公众号等进行自主营销，并完善相关结算流程；平台间通过接口进行营销策略交互。 数据分析管理模块：基于多渠道汇总的用户、商户和交易数据，实现省内自主管理用户数据、交易数据、活动数据、商户数据、对账数据、结算数据等数据，实现基础数据的查询并具备统计分析报表功能，是开展营销活动、数据分析等工作的重要基础。通过有效整合集团和省的交易数据，以多维数据及可视化图表展现出来，提供相应的数据分析模型进行用户特征分析、营销活动效益分析，为运营策略提供有价值依据。 运营风险监控管理模块：对用户交易异常、商户套利套现、系统运营异常等制定监控规则和机制，实现风险自动化监控告警功能。 数据处理中心模块：基于多渠道汇总的用户、商户和交易数据，在电子金融管理平台实现基础数据的查询、是开展营销活动、数据分析等工作的重要基础。系统总体架构与周边系统的关系 电子金融管理平台与集团支付平台接口 现金充值等接口 代金券业务接口 网关支付接口 集团支付平台与ODS数据接口 用户数据同步 商户数据同步 交易（扫码、网关等）数据同步 电子金融管理平台与CRM接口 用户套餐信息同步接口 用户通讯状态查询接口 电子金融管理平台与ODS数据接口 用户数据同步 商户数据同步 交易（扫码、网关等）数据同步 2 需求分析2.1 商户信息管理模块为实现省内自主管理商户信息，获取外部平台全部商户数据，便于营销支撑平台活动开展及商家信息管理。2.1.1业务场景支撑和规则说明云南省的商户信息分置集团多个平台（扫码/商超/油站/线上/网关），而省内获取到的仅有间连pos商户的部分信息，无法做到有效管理。省内商户管理模块作为基础管理，主要能支撑的业务场景有：1、 通过省支付平台与集团支付平台等渠道获取商户数据，获取的商户数据包含：POS直连、间连、扫码、网关等所有类型的商户信息。2、 通过商户类型、归属地等字段（地市、区县、电信支局），分权分域有效统一管理所有的商户信息。3、 拒绝商户孤岛，结合省内自主营销，形成有效统一的商圈组，进行定向的营销活动。4、 提供商户查询功能，支持按POS商户、收款码商户、付款码、网关等进行分类管理及查询。5、 系统提供商户信息的编辑（增删改查）功能，商户管理包含“商户编码、商户名称、商户类型、行业类型、商户状态、商户地址、营业执照、组织机构代码、法人代表、财务联系人等信息”等主要字段。2.1.2商户信息同步流程商户信息管理业务流程如下：流程说明：（1） 如集团商户信息有有新增或更新，则通过接口同步通知省内ODS更新，再同步至省内平台。（2） 商户信息需要完善字段，如商户名称，地市码等。2.1.3商户信息综管台管理综管台实现省内商户信息维护管理。例如下图2.2 营销活动管理模块新版营销模块，建议所有营销规则、营销活动均在省内管控，集团只是作为核心账户管理的提供者，仅仅作为营销结果的实施。营销活动主要是为了提高翼支付用户使用基于翼支付账户的翼支付业务的交易频度与交易金额，以及吸引非翼支付用户转化为翼支付用户、提高翼支付品牌知名度与扩大翼支付业务使用范围，从而不定期推出的各种优惠促销活动。目前营销方式主要包括如下几种类型： 返利充值 返代金券、红包等抵用券所有的营销活动方式均以原价执行，返现充值到翼支付账户或者提供中奖商品予以优惠，先到先得，过期失效，额满为止。目的在于一方面简化系统的复杂性，另一方面扩大翼支付账户的使用程度。营销时间以翼支付平台的时间为基准（需要时钟同步，确保时钟准确）。 实时返利翼支付用户在使用符合实时返利营销活动规则的翼支付业务时，翼支付平台则根据实时返利要求立刻自动以现金充值形式返现到其翼支付账户。鉴于实时返利活动对于翼支付平台的复杂性与营销活动的风控规则要求，一般建议在交易1分钟（可以设置到秒级）后由系统自动提取符合实时返利要求的交易信息及其翼支付用户并对其翼支付账户进行返现充值。返现充值不可用于提现。2.2.1业务场景支撑和规则说明由于云南省内没有营销支撑系统，省内的营销活动需要统一提交集团，按T+7处理，处理时间长，不能按区域、不能个性化的营销活动配置。而省内pos自带的营销模块，只能简单支持间连商户pos，对于渐成主流的扫码营销或其他数据来源（如民生）的翼支付交易均无法支撑。营销活动模块主要具备的能业务能力：1、实现省内具备自主营销能力，随时配置营销活动，快速开展活动。2、省内可灵活配置多种活动规则，开展差异化、个性化的活动、满足各类场景。3、省内充分获取交易数据、用户数据，有利于掌握业务发展动态、并有效评估活动效益，为日常运营提供决策依据 4、提供扫码营销活动配置。本期营销活动支撑的几类典型业务场景如下：1、 典型交易类 具体规则：营销支撑模块获取到典型的翼支付交易数据（如扫码、posp、充值、民生缴费、线上交易等），通过匹配已配置的返利规则,进行翼支付返利或代金券发放的营销活动。其中、成本结算由特定的成本商户号负责。2、 批充直送类 具体规则：根据营销要求提取特征用户（如为了维系存量中的高值用户），将用户数据批量导入营销支撑平台，再通过相关审核流程后，直接对用户进行翼支付返利或代金券发放的营销活动。其中、成本结算由特定的成本商户号负责。3、 对外提供营销服务类 具体规则：营销支撑模块提供统一的外部数据源接口（如提供给企信）。企信侧准实时提供大网受理业务交易（办理高值套餐、购机等） 通过对外营销服务接口推送到营销支撑模块，通过匹配已配置的返利规则，进行翼支付返利或代金券发放的营销活动。其中、成本结算由特定的成本商户号负责。2.2.2基础返利 系统提供省内翼支付交易基础返利活动配置，包含返利基本规则设置、活动用户限制、黑名单配置、活动商户配置等，用户在使用符合活动规则的业务时，系统以翼支付金形式给返还到用户翼支付账户。注：集团收款码、付款码交易由于数据来源非实时（需要等待集团回传前一日的交易数据），目前仅能实现隔日返利。交易返利活动配置需要提供如下配置规则：序号活动规则描述1活动时间活动时间设置，用户仅在该时间段内的消费才给予返利2交易来源包含间连POS交易，集团直连POS交易，客户端扫码交易，活动配置时可选定活动的消费交易渠道3百分比返利带封顶按消费的金额比例进行返利，同时进行返利金额的封顶限制4固定金额返利无论消费金额大小都按返利活动配置的固定金额进行返利充值5返利金额封顶返利活动中所返利金额总数具有封顶设置，限制返利总额。即当返利金额累计达到/超过返利总额时，则不再进行返利6返利月限额系统进行返利时，发现用户返利的金额超过活动返利月限额限制，1）如果用户当月返利的金额已等于返利限额，则不进行返利。2）如果用户当月返利的金额小于月返利限额且增加本次返利金额后大于月返利限额，则以月返利限额减去已返利金额进行返利。7返利名额限制当该活动的返利名额达到活动的返利名额限制，则该活动不继续进行返利。实现返利名额限制功能。8返利活动单人返利次数限制可以对单人返利次数进行限制，用户返利的次数达到单人返利次数限制，则不继续进行返利。建议用户返利力度较大的活动。配合返利名额限制，可达到前几百名用户返利的功能。9单笔金额下限返利活动对消费金额的下限进行限制，只有达到单笔消费金额下限的消费记录，才认为是符合返利的消费记录。否则不进行返利。10返利优先级配置管理当用户满足两个或多个活动时，用户只能享受优先级最高的活动的返利，其他活动不返利。使用场景如下：A返利活动是12月份整个月都有，B返利活动是12月里的星期1,3,5，并且B的优先级高于A，遇到B，则A就不返利。11离散时间设置可以在活动时间内进一步指定具体时间消费满才给予返利。例如：每周五六七，加油消费单笔满300元的，给予返利15%。12异网用户限制返利活动可以配置是否对异网号码消费进行返利。13指定活动商户设置返利活动商户，可以配置一个或多个商户14外省用户限制为了将营销成本投入到本省用户上，在营销返利时，需判断号码是否为外省号码，如果是外省号码则不进行返利2.2.3营销规则配置营销规则主要包括多个维度，不同的营销方式由不同纬度组合构成： 商户 渠道类型 业务种类 时间范围 黑名单 单用户累计交易次数下限 单用户单笔交易金额下限 单用户累计交易金额下限 单用户成功参与次数上限 单用户成功营销金额上限 本次营销活动的营销金额上限 本次营销活动的交易次数上限 优惠方式 中奖商品 优惠金额 优惠比例 异网用户限制(设置异网用户是否参与活动设置) 外省用户限制其中黑名单是不能参与营销活动的翼支付用户列表，存放手机号码或翼支付卡号信息，属于黑名单的翼支付用户不能参与营销活动。2.2.4营销成本管理每次营销活动成本可以设置是天翼支付、省电信或活动商户单独承担或共同承担，通过参数进行灵活设置，相应的营销成本通过报表体现。规则要素描述备注营销活动编号天翼支付承担比例按笔分摊三者之和等于100%，具体金额则为优惠金额的相应百分比省电信承担比例按笔分摊商户承担比例按笔分摊天翼支付承担金额按笔分摊三者之和等于营销规则中的优惠金额（一般固定）省电信承担金额按笔分摊商户承担金额按笔分摊2.2.5营销活动监控翼支付平台需要持续监控营销活动的优惠执行情况，以及交易笔数与金额的波动情况，避免翼支付平台受到非正常攻击时大量额外优惠所产生的成本支出。可以通过查询、报表以及系统报警（短信）手段及时反馈营销活动执行效果。2.2.6清结算报表翼支付平台需要定时出具如下类别的报表： 返利活动优惠金额报表 可疑交易报表 返利营销活动执行效果比较报表（执行前、执行后） 营销成本报表 营销退货报表 批充结算报表 代金券发放报表 代金券使用情况报表2.2.7营销数据来源管理系统通过CRM、ODS、支付公司等外部系统获取用户相关数据，主要有：用户基础数据、用户套餐数据、用户交易数据等，平台对其进行入库管理，并将其应用于营销活动中。要求针对不用渠道数据源均可进行营销活动、针对扫码交易数据，可以进行立减、立返、代金券返利的营销活动配置. 翼支付平台营销需要如下数据来源的营销类别： Pos类交易数据，可实现预存款充值返利/代金券模式返利 扫码类交易数据，可实现对扫码交易进行预存款充值返利/代金券模式返利 省内系统CRM、ODS、支付公司等外部系统用户数据2.2.8批充后返功能管理 提供批充功能，应用于各类返利活动中需要用户集中返利的场景，批量为用户充值翼支付金、代金券。即平台支持批量导入需要充值的翼支付号码与金额，并选择充值商户、充值类型，完成翼支付金充值，并提供审核功能，只有通过审批后才执行批充。1）提供批充业务审核功能，批充活动执行需经过活动配置和审核两个环节，活动配置由申请人填写，活动审核由高级权限管理员审核。2）批充类型可配置为翼支付金或翼支付代金券3）批充活动申请：填写申请人、活动说明、批充类型、营销成本方（充值商户），并按批充模板填写或上传待批充的用户数据4）提供批充查询功能：包含批充活动查询、批充号码明细查询等5）提供批充统计功能：可根据不同活动主题统计展示批充申请总额、批充成功总额、批充申请总数、批充成功总数等。具体包含： 批充任务查询：地市及省团队翼支付业务管理员可查询所有批充任务。查询条件包含：批次号、地区、时间范围（以申请时间为准，细到月）、状态。查询结果字段：批次号、批充原因、成本方（商户名）、批充类型、总金额、申请人、申请时间、审批人、审批时间、状态、失败金额、失败明细（点击后可查号码、金额、失败原因）。批充号码查询：输入任一号码，可查其批充历史记录。查询结果字段：批次号、号码、充值金额、批充类型、批充原因、批充结果。预存款充值返利：2.2.9关联套餐返利平台提供返利活动管理用户套餐，以防范低值用户进行套利行为。平台通过与IT系统对接，获取用户套餐信息，实现根据用户套餐档次进行返利或不返利的功能。套餐返利功能具体如下：1）要求平台定期从ODS系统获取套餐配置信息（套餐ID，套餐名称，套餐值），存放到平台数据库中。实现在进行返利活动配置时候，让配置人员进行配置可以返利的套餐档次（对应一段套餐值范围），不同套餐档次对应不同的返利规则或返利月封顶金额，一个活动可以配置多个套餐档次。2）在给用户返利时候，平台调用ODS系统的数据库接口，查询用户所属的套餐信息（套餐ID、套餐名称），然后判断套餐是否在返利活动关联的套餐范围内。如果是，才进行返利。与ODS系统接口：1）获取套餐配置信息接口：套餐ID，套餐名称2）获取用户套餐信息接口：条件：用户手机号码；结果：用户手机号码、套餐ID、套餐名称）。2.2.10关联用户组返利将用户组和返利活动关联。关联后只有在用户组中的用户，才会获得返利。系统支持对用户组信息管理。包含可以新增用户组信息、用户组名单等管理；支持系统管理员通过后台批量导入用户组成员清单及用户所属的用户组。1) 用户组管理要求平台提供新增返利用户组配置管理功能，可以添加、修改、删除用户组信息。2) 用户组成员管理要求平台提供新增用户组成员配置管理功能，可以添加、修改用户组的成员。3) 返利活动关联用户组要求平台支持将用户组和返利活动关联。关联后只有在用户组中的用户，才会获得返利2.2.11 代金券应用云南省内缺失省内代金券管理模块，导致不能实时下发代金券，影响用户体验。云南的代金券下发只能线下统一提交集团，按T+7处理，处理时间长，不能结合营销活动实时进行。省电子金融平台与集团代金券平台对接，实现本地发放代金券的能力。在营销活动开展过程中，集团平台负责代金券制作管理。集团平台开放代金券下发接口给省平台，省平台上实现代金券下发的管理工作。要求支持如下场景及功能：1) 应用于消费返券：单笔交易即时返券，返还规则为单笔交易满XX元返X元代金券X张。消费返代金券活动要求提供如下配置规则，序号活动配置描述1代金券配置指定代金券编号及金额，用于活动中选择返还哪种代金券2个人单笔交易金额下限设置单笔最低交易金额、只有达到消费金额下限才给予返券3活动返券总次数设置本次活动返券的总次数4个人返券总次数限制单个用户在活动期内最多返券次数 5活动时间活动时间设置，用户仅在该时间段内的消费才给予返券6离散时间设置在活动时间范围内进一步设置具体时间。例如：每周五六七 7黑名单配置支持添加黑名单用户，即在黑名单中的用户不给予返券8异网用户限制设置异网用户是否参与活动设置9指定活动商户设置返券活动商户，可以配置一个或多个商户2) 结合商户发行联名代金券3) 应用于手动发券：平台提供手动发券功能，管理员可以使用“批充管理”功能批量导入用户号码及代金券编号等信息动对目标用户发放代金券；可用于对用户进行补返利场景。4) 发券结果查询：提供发券结果记录查询，不予返券原因查询功能。5) 对账功能：要求提供集团代金券与省平台对账、报表等功能。目前代金券申请下发流程如下：代金券应用主要涉及代金券申请、管理及使用，相关业务流程如下：1) 省公司人员向集团平台申请代金券活动，包括活动编号、代金券金额、代金券成本商户；2) 省公司人员将代金券活动信息录入省平台；3) 省公司人员录入代金券成本商户的活动审核机制，可根据活动成本额度分级审核4) 配置代金券营销活动；管理员审核通过后，活动开始处理，为满足条件的用户发放代金券。代金券返利：2.2.12 微信公众号营销一、背景为充分利用微信入口进行翼支付宣传，开展代金券派送、抢红包、强互动性活动，大力吸粉，发展新用户，提高用户黏性。在多省成功应用的前提下，需要建设微信号红包、代金券等应用功能。此外，可结合营销平台，开展线上线下联动营销，有力辅助翼支付发展。二、项目需求1、微信公众号建设 （1）业务查询翼支付绑定支持翼支付用户通过输入翼支付账户+短信验证码，在微信公众号进行账号绑定，从而使用翼支付的相关服务。余额查询要求系统支持用户完成账号绑定后，即可查询翼支付账户余额交易查询要求提供用户查询近三个月的翼支付交易明细。（2）红包活动管理实现红包活动的快速配置，具有红包活动创建、红包总金额、单个红包金额、红包数量、中奖概率等规则配置功能；通过与翼支付充值接口对接，实现用户可将抢得的红包充值到翼支付账号；红包活动发布后，用户可通过微信公众号进入活动页面参与抢红包，抢到的红包可自主进行翼支付金充值。具体功能如下：红包的制作本地红包由电信管理员在管理门户上进行制作，本地红包包含面值、开始时间、结束时间、标题、内容、图标、创建时间、创建者、状态信息。红包的获取本地红包的获取方式有两种1）主动发放：由管理平台通过导入用户清单的方式主动向用户派发红包，并群发短信告知用户，红包发放后，清单用户无需在活动页面参与抢红包，该红包自动进入用户的红包栏目内。2）接口发放：用户通过参加营销活动获取红包。红包的查看用户可以通过展示门户中“我的”栏目查看已经获取的红包，先看到红包的数量，如果有新的红包，在红包右上方进行红点提示。用户点击红包可以查看具体内容。红包的使用用户在有效期内打开红包，并点击使用，可以将本地红包按红包面值给翼支付账户充值，该操作为不可提现充值。用户通过短信验证码进行红包充值。红包的结算每天统计前一天红包的使用情况，并生成报表。然后由省公司根据报表中的金额与集团结算。红包规则补充说明1) 指定红包的总额和总个数，单个红包可设置金额区间2) 可设置红包活动时间3）单个手机号只能抢到1个红包，抢到后不能再抢了（3）代金券活动管理代金券的制作提供代金券发放活动管理功能，具备活动创建、代金券活动ID、发放总数量、面值设置等功能。代金券的领取系统提供两种发放领取方式，一种是由管理员导入用户清单发放，活动用户进入代金券领取活动页面，即可领取。一种是新用户首次关注微信号，即可自动获赠代金券代金券查询提供运营管理人员查所有代金券获取记录、使用状态查询等（4）公众号管理功能消息自定义回复可自定义消息自动回复的内容，包含：用户首次关注微信号自动回复的消息、消息自动回复、关键字自动回复（用户在微信对话窗根据提示输入关键字即可显示定义好的内容）消息查询针对用户在微信回复的消息，提供关键字检索功能，支持将查询结果导出到本地消息群发支持针对指定用户、用户群或用户组进行消息群发，消息群发可以在后台配置，实现模版化。功能主要包含：l 支持文字消息与图文消息l 支持针对性的活动消息推送l 支持不同用户、用户组不同推送l 支持后台配置群发类型粉丝查询记录关注用户的基本信息，包括用户OPENID，用户昵称，用户性别，归属地，关注时间、关注状态、用户头像等信息。l 粉丝信息记录l 粉丝openID获取并记录l 粉丝信息分类l 粉丝信息后台查询消息提醒平台可根据模板给指定的关注用户或所有用户，设置自动消息提醒功能，例如用户参与抽奖活动中奖后，系统可以自动给该用户推送一条系统设置好的中奖消息自定义菜单公众号的自动定义菜单管理，支持菜单的创建、修改和删除，展现成树状结构：l 部署公众号自定义菜单能力l 部署公众号自定义菜单关键字与规则l 修改公众号自定义菜单能力l 删除自定义菜单能力l 菜单支持关键字与链接等多样化配置二、接口建设本期主要与集团翼支付、CRM、流量系统、定位系统等周边接口。为了保证接口设计的规范性和开放性，系统的接口设计将遵循如下原则：l 安全可靠性原则：系统应提供良好的安全性和可靠性策略，支持多种安全而可靠的技术手段，制定严格的安全可靠的管理措施；l 开放性原则：提供开放式标准接口，提供与其它系统的互联互通；l 灵活性原则：支持接口服务的重组与更新的灵活性，便于业务处理流程的修改；l 可扩展性原则：支持新业务的扩展以及代理接口容量与接口性能的提高；l 可管理性原则：提供良好的管理机制，保证在运行过程中提供给管理员方便的管理方式以处理各种情况；l 统一性原则：应当保证系统接口的方式、接口形式、使用的协议等标准、统一。（1）微信公众号平台接口微信公众号平台是本系统的核心业务交互平台，微信公众号的所有交互都要经过微信平台，是本业务的关键周边系统。微信公众号平台主要要实习以下几种接口：l 消息收发接口l 自定义菜单接口l 素材接口l 粉丝用户接口l 数据分析接口2.2.13 结算对账返利活动结算流程：根据返利配置的成本商户账户，由集团自动从该商户账户中扣除营销费用。需预先将营销成本充值进入预存款账户，翼支付金的结算根据返利金额结算，翼代金券的结算待活动结束后以代金券使用量进行结算。2.2.14 营销结果查询与统计 系统提供各类营销活动的营销结果查询，要求根据日常业务需要提供账户返利查询、返利规则查询、返利交易查询、不满足返利及原因查询、代金券返利结果查询、不满足返代金券查询、返利商户配置历史查询等多种维度查询功能。系统提供各类营销活动的营销结果数据统计，包含返利结算报表、返利结算明细报表等统计。2.2.15其他接口 根据营销活动需要，与CRM系统、ODS、计费、支付等省内其他对接，获取用户通讯状态、套餐等营销活动开展需要的基础数据信息。2.3 数据分析管理模块建设省内数据平台，实现省内自主管理用户数据、交易数据、活动数据、商户数据、对账数据、结算数据等。用户数据、交易数据、商户数据需要从集团开放的数据接口或下载页面获取，并同步回省内入库。营销活动均在省内实施与监控，无论是策划营销规则、营销活动的配置数据、还是提供给集团实施的营销结果数据、提供给商户结算分担的成本数据，均已在省内系统中。省内平台针对以上数据源，可以根据业务管理要求，进行定制化开发，实现数据管理、进行数据分析、执行数据统计，生成各类业务报表和丰富化展示视图。2.3.1业务场景支撑和规则说明集团数据主要分步在集团平台，而集团平台主要是支撑全国，无法有效定制提供云南省所需的各类个性化数据报表，无法进行云南省的数据分析以及营销分析，甚至由于全国数据量太大，导致省内数据的导出都比较困难。 建设省内数据平台模块的目的是：1、管理个人账户与商户信息，有效支撑各区域对商户、个人账户活跃等指标的数据报表2、进行用户价值、营销效益等数据分析，开展精准营销3、获取集团、省内各渠道的用户、商户、交易等数据，有助于开展各种场景的营销活动。2.3.2用户数据集团同步接口（1） 集团每日定期将T-1日有新增或更新的用户信息文件推送省内更新。（2） 省内可自行查询用户数据。2.3.3个人账户纬度的交易数据集团同步接口（1） 集团每日定期将T-1日的交易信息文件推送省内更新。（2） 省内可自行查询个人账户交易数据。2.3.4商户纬度的交易数据集团同步接口（1） 集团每日定期将T-1日的交易信息文件推送省内更新。（2） 省内可自行查询商户交易数据。2.3.5统计查询报表1、根据日常经营及数据分析需要，提供查询功能；提供报表配置能力，对用户数、交易金额、分区域、营销成本、交易频次、商户统计等数据提供后台配置功能，并可在前台展示或导出方式功能。2、用户价值分析整合集团支付平台、省支付平台、省IT系统相关的用户数据、交易数据、进行用户的行为特征分析，包含静态数据与动态数据分析。具体如下：1) 静态数据分析（1） 按用户数、交易笔数、交易金额统计用户性别占比情况（2） 按用户数、交易笔数、交易金额统计用户年龄段分布情况（3） 按用户数、交易笔数、交易金额统计天翼网龄、翼支付网龄分布情况（4） 按用户数、交易笔数、交易金额统计用户归属地分布情况（5） 按用户数、交易笔数、交易金额统计消费地分布情况2) 动态数据分析（1） 按交易笔数、交易金额、时间统计用户消费频次分布情况（2） 按交易笔数、交易金额、时间统计用户消费额度分布情况（3） 按行业统计用户消费偏好分布情况3、营销效益分析在综合分析的基础上结合营销活动维度进行活动效益分析，按时间、区域统计比对各个活动的交易金额、交易笔数、活动用户、新用户情况统计分析。2.4 运营风险管理模块增加省内平台运营监控管理功能，为实现重点问题监控、交易对账、差错处理等运营功能。支付系统对信息安全和资金安全性有着很高的要求，并且随着营销活动的开展，套现、套利等问题经常发生，人工检查非常困难而且成本很高，容易造成营销成本的浪费和资金损失。因此系统需对交易行为进行多方位监控，防止用户、商户套现套利事件的发展，减少营销成本的资金损失，并不断总结经验教训，优化完善营销活动配置，最大化营销成本的投入效果。2.4.1业务场景支撑和规则说明互联网金融的独特性决定了风控的独特性，配套风控依赖于深度的数据汇聚和行为挖掘。建设运营管理模块的业务场景主要注重以下几点：1、 通过交易行为监控，多方位防止套现、套利事件发生；2、 随时关注营销活动成本，减少营销成本的资金损失；3、 重点问题监控、数据对账、数据通报等提供运营关键点的支撑； 2.4.2实现省内交易状态监控1、根据集团同步的交易数据，汇总个人账户的交易数据源，关注在同一商户多次交易的用户交易和返利数据，对用户返利情况进行统计，并设计告警规则进行监控告警。2、根据集团同步的交易数据，汇总商户的交易数据，统计分析商户的异常交易情况，并以图表数据的形式展示在综管台。支持对指定商户交易额进行监控，当指定商户单笔/日/月消费累计总额达到X元时，以图表展示告警的形式通知监控人员。3、增加省内平台运营监控管理功能，实现对系统交易异常、对账异常等业务进行监控的功能。2.4.3实现省内活动成本监控2.4.4实现省内对账结果监控2.4.5实现省内接口能力自监控2.4.6具备差错处理能力差错处理、审核平账等功能 2.5 数据处理中心为有效管理全省翼支付业务相关数据，开展各类营销活动、整合查询、数据分析工作，集中汇总集团各渠道的用户、商户和交易数据，数据处理中心需要从外部系统同步的数据源包括以下几类：2.5.1用户数据采集1) 采集方式数据流向过程为：支付公司集团汇聚平台集团ODS各省企信部2) 采集内容要求获取的用户基本信息包含：用户的手机号码、手机号码归属地市、手机号码归属区县、翼支付状态、翼支付开通时间、翼支付注销时间等。3) 采集流程2.5.2商户数据采集1) 采集方式数据流向过程为：支付公司集团汇聚平台集团ODS各省企信部2) 采集内容商户管理包含“商户编码、商户名称、商户类型、行业类型、商户状态、商户地址、营业执照、组织机构代码、法人代表、财务联系人等信息”等主要字段。3) 采集流程2.5.3交易数据采集1) 采集方式数据流向过程为：支付公司集团汇聚平台集团ODS各省企信部2) 采集内容交易数据包括POS交易（间连、直连）、扫码交易和网关交易。需要包括交易时间、手机号码、交易金额、交易金额、交易标识、交易渠道、交易结果、商户号、终端号、商户全称等主要数据字段。3) 采集流程 集团支付平台各渠道的交易数据采集流程同商户数据采集流程。3 系统设计3.1 系统特性安全性：系统对于安全性要求较高的模块使用CA数字证书认证方式，从而多层次多角度的提高系统的安全性。可移植性：系统采用跨平台的技术方案，可以方便的在多种主机、网络、操作系统环境下工作。易维护性：系统对大部分的模块使用配置化的实现，可通过较为简单的配置来实现原本较为复杂的业务要求。这样大大提高了系统的灵活性，并便于后期维护。同时系统的技术方案和配置化的实现也决定了系统的部署是极为便捷的。开放性：系统支持主流的业务接口（如8583报文）。同时系统由于是可配置化的，所以对一些较为特殊的业务接口也得以很好的支持。这样大大提高了与外部机构互联互通的效率。友好性：系统在设计和实现过程中，着重考虑到人机交互，最大程度上提高界面的友好度。为服务不同类型的用户实现多语言多呈现方式的界面交互。高效性：系统在实现过程中同时考虑到系统的效率问题，不存在内存泄露，资源死锁问题。对于Web互联网应用进行界面优化等措施，从而提高系统的效率。最终实现用户同时在线数大于100个，系统查询、支付等操作的响应速度小于3秒。3.2 系统技术架构翼支付平台使用J2EE的B/S技术架构，J2EE技术架构具有标准化、跨平台的优势。架构采用SpringMvc+SpringIbatis的组合架构。如下图所示：OS FrameWorkdatabaseSPRINGMVC表示层业务层ORMSPRING事务处理IBATISWEBSERVICE 服务组件*.JSP,Application.xmlIBATIS session管理其他服务类管理Spring是为J2EE 应用程序开发提供集成的一种开源框架，时下业界流行将其作为业务层配置来使用。Ibatis 是开发源码的数据库操作架构。Ibatis着力点于POJO 与 SQL之间的映射关系。也就是说，Ibatis并不会为程序员在运行期自动生成 SQL 执行。具体的 SQL 需要程序员编写，然后通过映射配置文件，将SQL所需的参数，以及返回的结果字段映射到指定 POJO。3.3 安全体系由于系统安全体系的具体实施方案涉及到个人或企业对于安全等级的要求，以及协作机构之间的安全性约定等诸多方面的内容，涉及到很多尚未确定的细节性因素，所以在这里我们只在总体上说明系统安全体系的建设原则、方法和建议。系统安全是整个系统可靠运行和进行安全防范的基石，在统一设计原则下，在不同的安全层次，在预防、检测和恢复等各个阶段确保系统的持续稳定运行防止信息的损坏、泄露或被非法修改并保证系统平台的安全。一个完整的安全解决方案应涵盖系统中所有的用户、网络、主机、应用服务器以及应用程序，并建立高效、可靠的安全管理策略。因此我们从业务应用系统的整个体系架构考虑，设计一个坚实、可靠的安全体系方案。整个方案从物理安全、数据库安全、应用安全、运行安全等方面来构架整个体系。3.3.1目标与方法系统安全体系的构建不仅要在技术层面上在网络层次、系统层次和应用层次等各层次上实现高可靠性、高可扩展性，而且要结合信息安全具有层次性，动态性、过程性与生命周期性的特点实现高可管理性。具体目标为：1. 文件和交易敏感信息（如客户密码、各类密钥、操作员口令等）的私有性，即确保交易敏感信息在网络传输、信息处理和数据存储过程中不出现明文；2. 文件和交易数据的完整性和来源的确认性；3. 文件和交易的不可否认性；4. 密钥的集中存储与管理；5. 用户信息的集中管理与用户身份的统一认证；6. 基于安全策略的统一访问控制机制；7. 网络非法侵入和恶意攻击的自动检测；8. 网络和系统的漏洞扫描；9. 完整的安全审计日志和方法；10. 完善的安全管理规范和运行规范。11. 管理平台增加账户短信验证，加强账户使用人的操作安全。具体实现的方法：自顶向下的制定安全方案。首先是制定安全策略，我们的策略是从不同层次、不同范围制定相应的安全策略，再统一进行管理控制，具体来说制定了系统与网络安全策略、应用安全策略、访问安全策略、密钥管理安全策略。依照相关的国际标准和业界标准，并根据策略中明确指出的方向自上而下逐一进行设计。体系中的安全流程和架构是总体技术设计；安全步骤和产品则具体实现安全策略和流程。3.3.2数据交换安全交易安全主要解决交易处理中的数据安全性问题，也就是数据的安全传输、完整性检测、安全认证等内容。在翼支付平台系统中和数据交换安全相关的主要包括网站系统和交易网关、渠道系统和交易网关、交易网关和支付网关、商户与核心系统之间的数据交换，其中数据交换主要包括敏感数据的加密和数据的签名处理。敏感数据主要包括账户ID和账户密码（或者卡号和密码），加密的方式主要采用3DES的方式，通过与加密机交互产生加密结果。签名数据主要是为了确保传输过程中的数据不被篡改，签名数据可以根据不同的使用场景采用不同的签名算法，实现时可以采用RSA加密的方式获得签名结果，也可以通过盐值加密摘要运算的方式获得签名数据。3.3.3数据库安全数据库的安全方案包括数据库的备份和恢复、数据库用户角色管理。这里主要描述数据库用户角色管理方案。数据库系统在利用角色管理数据库安全性方面采取的基本措施有： 通过验证用户名和口令，防止非法用户注册到数据库，对数据库进行非法存取操作。 授予用户一定的权限，限制用户操作数据库的权力。 授予用户对数据库实体的存取执行权限，阻止用户访问非授权数据。 提供数据库实体存取审计机制，使数据库管理员可以监视数据库中数据的存取情况和系统资源的使用情况。 采用视图机制，限制存取基表的行和列集合。 角色管理的基本策略是： 对所有客户端按工作性质分类，分别授予不同的用户角色。 对不同的用户角色，根据其使用的数据源，分别授予不同的数据库对象存取权限。在数据库日常管理中，将采取如下技术手段： 数据库数据采用本地备份数据库在线备份及磁带库离线备份，这样部署既能恢复历史数据，又能快速恢复最近有效的在线备份数据库。 数据库自身在运行时将开启安全审计功能，确保关键的系统更改操作能记录到审计日志中。数据库访问严格定义角色、用户等要素，交易账户专门用于应用程序内嵌式使用，管理账户按管理人员、网点等角色定义访问权限，最大程度上限制共享账户的使用，确保账户的密码只有相关责任人知晓。同时对关键表的更改、删除等操作将记录在安全审计表中。3.4系统管理3.4.1日志管理平台将具有完善的日志管理，将各种日志进行分类，日志管理必须包括以下能力:具有对重要数据操作的日志记录、用户登录和退出的日志、异常的日志记录、日志查询和打印、日志统计和分析、日志数据至少保存某个固定时间（如在线可查询的日志保持3个月）。日志管理提供系统日志、接口日志、错误日志、操作日志、数据库服务器运行及出错日志等功能。日志支持文本或数据库的方式进行存储，可以灵活定义其日志级别，同时也可结合统计分析工具对这些日志进行查询、分析、统计