CN111027952A - 一种支持智慧能源服务的统一支付系统及方法 - Google Patents

Abstract

本发明所要解决的技术问题在于提供一种支持智慧能源服务的多渠道统一支付系统。包括用于保存支付数据的数据库，其特征在于包括业务系统、支付接口、以及支付核心，与所述业务系统交互业务状态数据，计算支付数据，并与支付接口进行支付数据的交互，所述核心支付处理模块，用于调取所述数据库中的支付相关数据进行计算；所述外部通道接收到所述支付数据或支付指令，判断出应支付渠道，所述渠道管理模块接收到所述支付数据，通过所述支付渠道进行支付，或者返回支付结果。本发明可以实现多渠道统一支付以及收付渠道聚合管理。

Description

一种支持智慧能源服务的统一支付系统及方法

技术领域

本发明涉及一种统一支付系统，尤其涉及一种支持智慧能源服务的多渠道统一支付系统及方法，属于智慧能源服务技术领域。

背景技术

智慧能源服务系统为开展有序充电、绿色能源交易等业务应用，亟待构建健全的多元主体多方的敏捷的清分结算及分润分成的清分结算体系。然而，传统行业的一级清分、多方分成的模式已经不适用生态化的智慧能源服务系统建设。开放式、生态化的智慧能源服务系统涉及多元主体(生产者、消费者、第三方等)在业务开展的多级清分结算以及多方分润分成。

目前，电动汽车充电普遍采用按桩、用户组合打折，出行实现优惠券折扣的营销方式，存在营销活动不统一，无法跨业务开展营销运营的缺陷。目前所有开展业务均为背靠背自营业务，资金管理符合央行规定；所有业务用户注册、登录已统一，网上国网与国网统一用户平台统一对接；所有业务均具有开户、充值、支付、清分、结算需求；目前存在账户不统一问题，出行有独立账户，其他业务账户统一；e卡仅支持充电、商城购物，其他业务尚不支持；与运营商/省公司清分需人工参与，资金结算采用财务转账或线下转账模式，无法做到实时结算。

因此，为了满足智慧能源服务系统的发展需要，有必要开发一种支持智慧能源服务的多渠道统一支付系统。

发明内容

本发明所要解决的技术问题在于提供一种支持智慧能源服务的多渠道统一支付系统。

为了实现上述目的，本发明采用下述的技术方案：

一种支持智慧能源服务的统一支付系统，包括用于保存支付数据

的数据库，其特征在于包括：

业务系统，用于具体业务的处理；

支付接口，用于与多种外部支付接口对接，实现支付数据交互

支付核心，与所述业务系统交互业务状态数据，计算支付数据，并与支付接口进行支付数据的交互，所述支付核心包括核心支付处理模块、外部通道模块、渠道管理模块，

所述核心支付处理模块，用于调取所述数据库中的支付相关数据进行计算，得到支付数据或者支付指令传给所述外部通道模块；

所述外部通道接收到所述支付数据或支付指令，判断出应支付渠道，发送给所述渠道管理模块，

所述渠道管理模块接收到所述支付数据，通过所述支付渠道进行支付，或者返回支付结果。

优选地，还包括与所述核心支付处理模块进行数据交互的安全中心模块，

所述安全中心模块包括用于进行接口访问权限控制以及安全鉴权。

优选地，所述支付核心调取所述数据库的信息，将来自各个所述支付接口的单个客户的多个订单进行合并计算和记录。

优选地，所述支付核心基于交易合并值，再查找对应的清分规则，并基于所述清分规则计算分润比例进行分润。

一种支持智慧能源服务的统一支付方法，其特征在于：

支付接口从各个应用获得商品订单

支付接口模块接收到来自支付接口的所述商品订单，并上传给支付核心模块；

所述支付核心模块，调取数据库中的信息，根据订单的特定字段来查找清分规则，所述清分规则是事先与利润分配各方协商确定的分润比例；

所述支付核心模块根据所述清分规则生成清分数据，向各个分润方进行资金划拨，

其中，所述支付核心在调取所述数据库中的信息时，将来自所述各个支付接口的单个客户的多个订单进行合并计算和记录。

优选地，所述支付核心与业务系统交互业务状态数据，计算支付数据，并与所述支付接口进行支付数据的交互，

所述支付核心通过核心支付处理模块，调取所述数据库中的支付相关数据进行计算，得到支付数据或者支付指令传给所述外部通道模块；

所述支付核心通过外部通道接收到所述支付数据或支付指令，判断出应支付渠道，发送给所述渠道管理模块，

所述支付核心通过渠道管理模块接收到所述支付数据，通过所述支付渠道进行支付，或者返回支付结果。

优选地，所述支付核心基于交易合并值，再查找对应的清分规则，并基于所述清分规则计算分润比例进行分润及资金划拨。

优选地，所述核心支付进行数据交互时通过安全中心模块进行接口访问权限控制以及安全鉴权。

与现有技术相比较，本发明采用主流的B/S架构、组件设计模式，基于J2EE技术构建了多渠道统一支付系统，完成多渠道统一支付核心模型的设计，以及支付流程和查询与退款流程的设计，最终实现收付渠道聚合管理。

附图说明

图1为预付费支付的流程图；

图2为后付费支付的流程图；

图3为本发明所提供的多渠道统一支付系统的结构图；

图4为本发明所提供的多渠道统一支付系统的实施过程示意图；

图5为本发明所提供的多渠道统一支付系统中，风险控制管理的架构图；

图6为本发明所提供的多渠道统一支付系统中，多方分润的流程图。

具体实施方式

下面结合附图和具体实施例对本发明的技术内容做进一步的详细说明。

目前，智慧能源服务运营的业务主要包括电动汽车、分布式储能、分布式光伏、V2G、光储充、智慧家居等客户侧能源服务。智慧能源服务系统是智慧能源服务业务的运营管理平台。

随着客户侧电动汽车、储能、分布式电源的快速发展，能源生产消费呈现出点多面广的特征，客户侧能源服务参与主体多元化、能源服务商品化形态愈发凸显，智慧能源服务运营模式逐步向电商运营模式靠拢。按照接入智慧能源服务系统的运营主体不同，可以分为公司运营业务、社会机构运营业务、个人运营业务三类，下边以电动汽车充电业务为例，分别阐述智慧能源服务的各种业务运营模式。

(1)平台运营商统一运营，采用背靠背自营交易业务模式

面向电动汽车用户在国网公共桩进行充电业务场景。为方便用户开具发票，业务运营模式设计为背靠背自营业务模式，平台运营商统一进行运营管理。该场景下，电动汽车用户在不同运营商(省公司)充电设施上进行充电，由平台运营商统一出具票据。设计为背靠背自营交易业务模式，省公司、合资公司均为平台运营商下游供应商，平台运营商向下游供应商采购服务/产品，由平台运营商统一进行运营管理，向电动汽车用户提供服务/产品。

(2)合资公司运营，采用撮合类交易业务模式

面向电动汽车用户在国网专用充电站进行充电业务场景。为给客户提供便捷的交费、充电、票据服务，将该场景业务运营模式设计为撮合类交易业务模式，由商户(合资公司)进行业务运营，通过平台直接为电动汽车用户提供服务。

该场景下，电动汽车用户在专用充电站充电设施上进行充电，费用通过平台交存到商户(合资公司)账户，由商户(合资公司)直接为用户出具票据。设计为撮合类交易业务模式，运营商(省公司)为商户(合资公司)下游供应商，商户(合资公司)向下游供应商采购服务/产品，由商户(合资公司)进行运营管理，向电动汽车用户提供服务/产品。平台运营商为交易双方提供平台服务，向商户(合资公司)收取信息服务费(佣金)。

(3)合资公司自建桩，采用撮合类交易业务模式

面向电动汽车用户在商户(合资公司)自建专用充电站进行充电业务场景。为给客户提供便捷的交费、充电、票据服务，将该场景业务运营模式设计为撮合类交易业务模式，由商户(合资公司)进行业务运营，通过平台直接为电动汽车用户提供服务。

该场景下，电动汽车用户在商户(合资公司)自建专用充电站充电设施上进行充电，费用通过平台交存到商户(合资公司)账户，由商户(合资公司)直接为用户出具票据。设计为撮合类交易业务模式，由商户(合资公司)进行运营管理，向电动汽车用户提供服务/产品。平台运营商为交易双方提供平台服务，向商户(合资公司)收取信息服务费(佣金)。

(4)平台运营商统一运营，采用背靠背自营交易业务模式

面向电动汽车用户在社会公共桩进行充电业务场景。为方便用户开具发票，业务运营模式设计为背靠背自营业务模式，平台运营商统一进行运营管理。

该场景下，电动汽车用户在不同社会运营商充电设施上进行充电，由平台运营商统一出具票据。设计为背靠背自营交易业务模式，社会运营商为平台运营商下游供应商，平台运营商向下游供应商采购服务/产品，由平台运营商统一进行运营管理，向电动汽车用户提供服务/产品。

(5)合资公司运营，采用撮合类交易业务模式

面向电动汽车用户在社会专用充电站进行充电业务场景。为给客户提供便捷的交费、充电、票据服务，将该场景业务运营模式设计为撮合类交易业务模式，由商户(合资公司)进行业务运营，通过平台直接为电动汽车用户提供服务。

该场景下，电动汽车用户在社会运营商专用充电站充电设施上进行充电，费用通过平台交存到商户(合资公司)账户，由商户(合资公司)直接为用户出具票据。设计为撮合类交易业务模式，社会运营商为商户(合资公司)下游供应商，商户(合资公司)向下游供应商采购服务/产品，由商户(合资公司)进行运营管理，向电动汽车用户提供服务/产品。平台运营商为交易双方提供平台服务，向商户(合资公司)收取信息服务费(佣金)。

(6)个人桩主运营，采用撮合类交易业务模式

面向电动汽车用户在个人共享充电桩上进行充电业务场景。由于个人桩主一般无法提供发票服务，将该场景业务运营模式设计为撮合类交易业务模式，由个人桩主进行业务运营，通过平台为电动汽车用户提供服务。

该场景下，电动汽车用户在个人共享充电桩上进行充电，费用通过平台交存到商户(个人桩主)账户，由商户(个人桩主)和用户线下协商解决消费票据事宜。设计为撮合类交易业务模式，由商户(个人桩主)进行运营管理，向电动汽车用户提供服务/产品。平台运营商为交易双方提供平台服务，向商户(个人桩主)收取信息服务费(佣金)。

按照用户在使用业务时支付的先后顺序，智慧能源服务支付模式分为预付费、后付费两种模式。下面分别展开详细具体的说明。

预付费：用户在使用业务之前必须预先支付费用，这个费用在用户成功使用业务之后再给予实际的扣除。

如图1所示，以充电业务为例，预付费支付流程如下：

用户在使用业务之前冻结用户账户金额；

用户使用业务(用户消费)之后，进行实际金额扣除，并解除账户冻结；

商户账户收取业务款项。

预付费支付方式一般包括：

(1)虚拟账户预充值、支付

该支付模式适用于背靠背自营交易业务支付。

(2)支付账户预授权、支付

该支付方式适用于背靠背自营交易、撮合类交易业务支付。

后付费：将个人信息在平台运营商处登记后，先消费，消费后实时或定期根据消费情况统一支付结算，多消费多付费，少消费少付费。具体支付流程如图2所示。

为降低后付费支付模式在业务资金回收方面存在的风险，本发明中可以采用保证金、平台授信、第三方信用等方式降低或避免资金回收风险。

保证金模式：用户在使用业务(消费)前，向平台运营方交存一定额度保证金，用户逾期未完成欠费订单支付，平台运营商可扣除保证金抵扣用户欠费款项。

平台授信模式：平台运营商对用户进行综合授信评估，授予用户一定授信额度，该额度内用户可先消费后付款，用户逾期未完成欠费订单支付，平台运营商可通过收取滞纳金、降低授信额度、取消授信等措施进行惩罚。

第三方信用模式：引入第三方信用机构，在使用业务前对用户进行第三方信用分评估，满足条件后可先消费后付款，由第三方信用机构承担业务资金垫付。用户逾期未还款，由第三方信用机构通过收取用户滞纳金、联合惩戒、减低信用分等措施进行惩罚。

后付费支付方式一般包括：

(1)快捷支付：使用微信、支付宝、京东金融、网银等方式进行欠费订单支付；

(2)免密支付：用户签约开通免密支付后，产生欠费订单后使用微信、支付宝、京东金融等支付方式自动进行账户扣款，完成欠费订单支付。

(3)信用代扣：用户签约开通第三方信用机构信用代扣业务，使用业务后自动从用户账户扣除本次费用，扣款成功可奖励信用分，扣款失败将进行提醒和惩戒。

随着支付业务的快速发展，多渠道统一支付的账户系统能够在一定程度上对支付业务的拓展起到帮助，现阶段多渠道统一支付更多的是具备稳定、多样的支付能力，但是从个性化营销的角度来看，还存在很大的发展空间，如配合商户进行支付返现、赠送红包、赠送优惠券、评论打赏等营销活动，如果有了合理的统一账户，这一系列的问题都会迎刃而解；根据合法资金清分的迫切需求，为避免非法二清，也需建立统一的账户体系，“二清”是相对“一清”而言。“一清”一般指资金直接通过银行或者获得支付牌照的第三方支付公司进行清算，交易结算款直接划转给商户。而“二清”是资金需要进行两次清算，即结算资金由银行或者第三方支付机构先转至“二清”公司自己开设的账户，经由该公司处理后，再结算给商户。

收付渠道聚合管理即把多家第三方支付提供的支付接口聚合到一个平台上面，来给商家或者个人来提供支付服务。聚合收付渠道，为用户提供支付便捷性，为商户降低接入成本，也为平台提供更多的合作空间，接入目前市场上所有主流的银行及第三方支付机构通道，支持新的支付方式的快速接入；对接支付宝、微信、京东金融、招行一网通等通道，融入业务平台，满足支付、充值、提现、退款等场景；通过统一的收银台，归集对接的支付通道，满足前端用户的各种支付需求；不仅支持C端用户的移动支付，也可以支持B端用户的PC端收银台支付。

为了满足上述需求，本发明提供了一种支持智慧能源服务的多渠道统一支付系统。如图3所示，该系统采用主流的B/S架构、组件设计模式，基于J2EE技术进行构建，分为数据持久层、业务逻辑层、WEB展现层等。支付平台主要由支付接口、支付核心和业务系统组成。支付接口提供各种现行的支付产品接入方式，包括API、WEB、WAP/H5和SDK；支付核心主要处理支付环节的业务，包括支付单处理、订单关联、用户及商户的管理；外部通道主要实现支付核心调用各外部支付通道完成支付指令的传输和支付结果的返回处理；渠道管理完成外部渠道的对接，外部渠道包括各银行、微信、支付宝及其他第三方支付渠道。业务系统负责全部具体业务的处理，例如电力充电等。

如图4所示，该多渠道统一支付系统主要完成支付、查询、退款三个基本功能，此三个功能属于实时调用，需要立即返回结果。每次调用传递的信息包含一个订单。在具体实施过程中，该多渠道统一支付系统包括如下功能模块：

交易前置模块：负责实现支付核心业务处理，比如记录商户交易流水、对接各个支撑服务；

风控模块：交易单日/单笔限额，商户黑名单、欺诈行为识别等风险因素控制；

路由模块：通过设定的优先级、限额等路由规则，选择合适的渠道，保证成功率，降低成本；

交易网关模块：负责所有支付渠道的报文包装、数据加密、协议转换、签名验证、状态映射。

该多渠道统一支付系统采用如下的聚合管理接入方式：

1、统一的接口管理，主要管理业务系统、支付渠道等交互接口；

2、多渠道统一支付的接口能力由统一接口接入层开放给外部系统，支持一次开发多处使用，增加接口复用性；

3、实现能力管控、安全控制、策略控制等功能；

4、支持高并发接口访问的流量控制等功能；

5、支持接口访问控制权限、介入认证等常见的安全鉴权功能。

6、支付网关提供基础的扣费、冲正、查询，支付账户的充值、提现、转账及余额查询等服务，并为为B2B提供记账功能。

这种多渠道统一支付方式仍然存在诸多风险，例如资金风险、信息安全风险、违规操作风险等，因此需要针对多渠道统一支付存在的问题，加强监管，让多渠道统一支付得到进一步的发展。

如图5所示，该多渠道统一支付系统采用如下的风险控制管理架构，针对风险支付交易事前、事中、事后的有效控制手段。通过人工介入多级审核制度，提高平台的管控力；支持央行新规的13张备付金报表、电信反欺诈、会员黑名单、风险共享平台接入；针对用户提供账户及账户资金的冻结和解冻功能。

上述多渠道统一支付系统在实际运行过程中，通过如下技术措施实现风险管控。

1、系统监控

·CPU负载

·内存使用率

·磁盘使用率

·网络带宽占用

2、JVM监控

JMX提供了关于JVM的大部分核心信息，启动时设置参数，支持远程访问JMX，之后即可通过接入JMX来实时读取JVM的CPU、内存等信息。Zabbix也支持通过JMX来获取信息。

3、服务监控

服务监控主要是对接口的状态监控。服务监控关注如下指标：

·QPS：每秒请求数对于使用容器的系统，包括Apache Tomcat,Resin,JBoss等，可以从Access

·Log中采集到每个接口的QPS。没输出Access

·Log的系统，考虑通过Annotation来规范输出访问计数。当然，这个指标还可以细分为每秒成功请求数、失败请求数、总请求数等。

·请求响应时间：在服务器端监控每个接口的响应时间。简单做法是在方法执行前后打时间戳计算，对于HTTP请求，也可以从access

·log中获取接口执行时间。当然也可以用annotation来实现统一的执行时间监控。

·执行异常数：指程序运行过程中发生的未捕获处理的异常，一般是对场景考虑不周导致的异常发生，比如空指针、错误参数、数据访问等的异常。这些异常一旦发现，需要修复代码逻辑。异常在应用日志中一般都会把错误堆栈打印出来。

4、数据库监控

监控在应用侧执行，通过应用代码中打印日志来实现，数据库监控重点关注如下指标：

·每秒请求数

·慢查询处理数

·SQL语句执行时间

5、业务监控

业务监控的实现方式如下：

(1)每个支付通道监控包括如下内容：

·支付通道接口请求数：如果一段时间内接口请求环比大幅度下降，可能是该接口出现问题了。

·支付通道接口请求失败数，即调用接口失败的数量。

·支付通道接口请求延迟。

·支付通道支付失败率。每个通道支付有一定的失败率，如果给定时间内突然有超过这个失败率的情况出现，则可能是通道出现问题了。

·支付通道同步、异步调用次数。

(2)支付接口，如支付、提现、退款、签约、订阅等，监控如下内容：

·总金额，如果总金额有大的波动，则有洗钱的可能

·每笔平均金额

·支付成功率

实际上对一个业务来说，大部分系统监控的指标是类似的，而按照这种方式，每个指标在各个被监控系统中还需要单独写脚本实现，工作量大。针对这种情况，可以采用日志集中监控的方式来处理。考虑到日志最终都需要归并到一个日志仓库中，这个仓库可以有很多用途，特别是日常维护中的日志查询工作。多数指标可以在日志上完成计算的。借助这个系统，也可以完成监控：zabbix监控。

如图6所示，支付接口模块接收到来自支付接口的各个应用APP的商品订单，上传给支付核心模块。支付核心模块，调取数据库信息，根据订单的特定字段(事先预设)来查找清分规则。清分规则是事先与利润分配各方协商确定的分润比例。支付核心模块根据清分规则生成清分数据，向各个分润方进行资金划拨。

在订单处理过程中，支付核心调取数据库的信息，将来自各个支付接口的单个客户的多个订单进行合并计算和记录。在此单个客户可以是多人共用客户(具有一个客户代码)，也可以是单人客户。通过合并计算和记录，单个客户在不同支付接口(不同应用APP)上交易的数据就可以整合到一起，从而产生交易合并值。

基于交易合并值，再查找对应的清分规则、优惠规则、或者其他营销活动规则。这样，单个客户的在不同应用中进行的不同交易，可以整合在一起，享受更多优惠，或者有资格参与更多营销活动。对于分润方，也可以基于该单个客户在不同APP的数据而全面掌握该客户的消费习惯和消费水平等信息，从而推出更多具有针对性的活动。

本发明的支持智慧能源服务的统一支付系统，包括用于保存支付数据的数据库，其特征在于包括：

业务系统，用于具体业务的处理；

支付接口，用于与多种外部支付接口对接，实现支付数据交互

支付核心，与所述业务系统交互业务状态数据，计算支付数据，并与支付接口进行支付数据的交互，所述支付核心包括核心支付处理模块、外部通道模块、渠道管理模块，

所述核心支付处理模块，用于调取所述数据库中的支付相关数据进行计算，得到支付数据或者支付指令传给所述外部通道模块；

所述外部通道接收到所述支付数据或支付指令，判断出应支付渠道，发送给所述渠道管理模块，

所述渠道管理模块接收到所述支付数据，通过所述支付渠道进行支付，或者返回支付结果。

还包括与所述核心支付处理模块进行数据交互的安全中心模块，

所述安全中心模块包括用于进行接口访问权限控制以及安全鉴权。

所述支付核心调取所述数据库的信息，将来自各个所述支付接口的单个客户的多个订单进行合并计算和记录。

所述支付核心基于交易合并值，再查找对应的清分规则，并基于所述清分规则计算分润比例进行分润。

支付接口从各个应用获得商品订单

支付接口模块接收到来自支付接口的所述商品订单，并上传给支付核心模块；

所述支付核心模块，调取数据库中的信息，根据订单的特定字段来查找清分规则，所述清分规则是事先与利润分配各方协商确定的分润比例；

所述支付核心模块根据所述清分规则生成清分数据，向各个分润方进行资金划拨，

其中，所述支付核心在调取所述数据库中的信息时，将来自所述各个支付接口的单个客户的多个订单进行合并计算和记录。

所述支付核心与业务系统交互业务状态数据，计算支付数据，并与所述支付接口进行支付数据的交互，

所述支付核心通过核心支付处理模块，调取所述数据库中的支付相关数据进行计算，得到支付数据或者支付指令传给所述外部通道模块；

所述支付核心通过外部通道接收到所述支付数据或支付指令，判断出应支付渠道，发送给所述渠道管理模块，

所述支付核心通过渠道管理模块接收到所述支付数据，通过所述支付渠道进行支付，或者返回支付结果。

所述支付核心基于交易合并值，再查找对应的清分规则，并基于所述清分规则计算分润比例进行分润及资金划拨。

所述核心支付进行数据交互时通过安全中心模块进行接口访问权限控制以及安全鉴权。

日志通过Apache Flume来收集，通过Apache Kafka来汇总，一般最后日志都归档到Elastic中。使用Apache Spark的Streaming组件来接入Apache Kafka完成监控指标的提取和计算，将结果推送到Zabbix服务器上，实现可扩展的监控。

这个业务监控方式的优势在于：

(1)监控脚本的跨系统使用。指定日志规范后，只要按照这个规范编制的日志，都可以纳入监控，无需额外配置。

(2)服务重新部署时无须考虑监控脚本的部署，所有监控直接生效。

但是，这种业务监控方式的难点在于如何提炼一套通用的日志规范。在本发明的实施例中，通过Spark来分析日志。具体说明如下：

1、日志收集

Flume和logstash都可以用于日志收集，从实际使用来看，两者在性能上并无太大差异。flume是java系统，logstash是ruby系统。使用中都会涉及到对系统的扩展，这就看那个语言你能hold住了。

2、日志数据流

Flume和Logstash都支持日志直接入库，即写入HDFS，Elastic等，有必要中间加一层Kafka吗？太有必要了，日志直接入库，以后分析就限制于这个库里面了。接入Kafka后，对于需要日志数据的应用，可以在kafka上做准实时数据流分析，并将结果保存到需要的数据库中。

3、日志分析

Streaming分析，可以走Spark，也可以用Storm，甚至直接接入kafka做单机处理。这取决于日志数据规模了。Spark streaming是推荐的，社区活跃度高，又集成了多种算法。

4、日志高能预警

根据我们的测试，在高并发系统中，关于日志，有如下结论：

(1)Log4j与logback在高并发下性能上并无太多差异，不用太纠结使用哪个API，影响性能的是日志内容的写法和数据量。

(2)输出类名和行号会严重影响性能，这需要使用到性能不佳的反射机制。执行频率高，性能要求高的代码，禁用反射，禁用new操作。

(3)线程时输出日志，写锁是影响性能的关键因素。缓解写锁的措施，首选加大日志写入缓冲区，其次是异步打印。

与现有技术相比较，本发明采用主流的B/S架构、组件设计模式，基于J2EE技术构建了多渠道统一支付系统，完成多渠道统一支付核心模型的设计，以及支付流程和查询与退款流程的设计，最终实现收付渠道聚合管理。

上面对本发明所提供的支持智慧能源服务的统一支付系统进行了详细的说明。对本领域的一般技术人员而言，在不背离本发明实质内容的前提下对它所做的任何显而易见的改动，都将构成对本发明专利权的侵犯，将承担相应的法律责任。

Claims (8)

1.一种支持智慧能源服务的统一支付系统，包括用于保存支付数据的数据库，其特征在于包括：

业务系统，用于具体业务的处理；

支付接口，用于与多种外部支付接口对接，实现支付数据交互

支付核心，与所述业务系统交互业务状态数据，计算支付数据，并与支付接口进行支付数据的交互，所述支付核心包括核心支付处理模块、外部通道模块、渠道管理模块，

所述核心支付处理模块，用于调取所述数据库中的支付相关数据进行计算，得到支付数据或者支付指令传给所述外部通道模块；

所述外部通道接收到所述支付数据或支付指令，判断出应支付渠道，发送给所述渠道管理模块，

所述渠道管理模块接收到所述支付数据，通过所述支付渠道进行支付，或者返回支付结果。

2.如权利要求1所述的支持智慧能源服务的统一支付系统，其特征在于：

还包括与所述核心支付处理模块进行数据交互的安全中心模块，

所述安全中心模块包括用于进行接口访问权限控制以及安全鉴权。

3.如权利要求2所述的支持智慧能源服务的统一支付系统，其特征在于：

所述支付核心调取所述数据库的信息，将来自各个所述支付接口的单个客户的多个订单进行合并计算和记录。

4.如权利要求3所述的支持智慧能源服务的统一支付系统，其特征在于：

所述支付核心基于交易合并值，再查找对应的清分规则，并基于所述清分规则计算分润比例进行分润。

5.一种支持智慧能源服务的统一支付方法，其特征在于：

支付接口从各个应用获得商品订单

支付接口模块接收到来自支付接口的所述商品订单，并上传给支付核心模块；

所述支付核心模块，调取数据库中的信息，根据订单的特定字段来查找清分规则，所述清分规则是事先与利润分配各方协商确定的分润比例；

所述支付核心模块根据所述清分规则生成清分数据，向各个分润方进行资金划拨，

其中，所述支付核心在调取所述数据库中的信息时，将来自所述各个支付接口的单个客户的多个订单进行合并计算和记录。

6.如权利要求5所述的支持智慧能源服务的统一支付方法，其特征在于：

所述支付核心与业务系统交互业务状态数据，计算支付数据，并与所述支付接口进行支付数据的交互，

所述支付核心通过核心支付处理模块，调取所述数据库中的支付相关数据进行计算，得到支付数据或者支付指令传给所述外部通道模块；

所述支付核心通过外部通道接收到所述支付数据或支付指令，判断出应支付渠道，发送给所述渠道管理模块，

所述支付核心通过渠道管理模块接收到所述支付数据，通过所述支付渠道进行支付，或者返回支付结果。

7.如权利要求6所述的支持智慧能源服务的统一支付方法，其特征在于：

所述支付核心基于交易合并值，再查找对应的清分规则，并基于所述清分规则计算分润比例进行分润及资金划拨。

8.如权利要求7所述的支持智慧能源服务的统一支付方法，其特征在于：

所述核心支付进行数据交互时通过安全中心模块进行接口访问权限控制以及安全鉴权。

Images