CN112200551A - 一种电商平台的多渠道及多币种支付网关***及实现方法 - Google Patents

Abstract

一种电商平台的多渠道及多币种支付网关***，其特征在于，包括：产品层，用于与用户进行交互；核心层，为所述产品层的实现提供业务逻辑；支撑层，为所述产品层和所述核心层提供支撑。所述产品层包括：收银台模块，用于向用户展示订单金额以及为用户提供支付方式选择；管理后台模块，为所述收银台模块提供参数配置；支付产品模块，用于为用户提供便捷支付方式，用户依据自身情况选择对应支付方式。本发明解决商户线上做生意、线上收款需求，增强商户与用户之间的粘性。本发明满足本澳居民/访澳旅客可以使用人民币种作为支付币种，实现随时随地多币种消费无障碍。

Description

一种电商平台的多渠道及多币种支付网关***及实现方法

技术领域

本发明涉及金融支付技术领域，具体涉及一种电商平台的多渠道及多币种支付网关***。

背景技术

目前澳门市场消费需求日趋增多，本地澳门居民和访澳旅客的消费支付场景众多，既要满足本地居民网上购物下单支付，又要满足访澳旅客的移动支付的诉求。而现在澳门市面上主要以线下纸币消费，线上平台支付也只仅支持单币种(澳门元)形式支付，且只有少数支付渠道具备线上支付能力，不能满足日益增长的用户消费需求；而且访澳旅客不能使用人民币进行线上支付更加极度不便利。整体而言提供给用户的支付服务和体验效果较差，并且支付成本较高，支付效率低。

不难看出，现有技术中还存在诸多问题。

发明内容

为此，为了解决现有技术中的上述问题，本发明提出一种电商平台的多渠道及多币种支付网关***及实现方法。

本发明通过以下技术手段解决上述问题：

一种电商平台的多渠道及多币种支付网关***，其特征在于，包括：

产品层，用于与用户进行交互；

核心层，为所述产品层的实现提供业务逻辑；

支撑层，为所述产品层和所述核心层的实现提供所需的软件。

进一步的，所述产品层包括：

收银台模块，用于向用户展示订单金额以及为用户提供支付方式选择；

管理后台模块，为所述收银台模块提供参数配置；

支付产品模块，用于为用户提供便捷支付方式，用户依据自身情况选择对应支付方式，实现支付行为。

进一步的，所述核心层包括：

基础订单模块，用于依据用户的选择生成对应的订单；

支付路由模块，用于依据用户所选择的不同支付方式配置不同的收款账号；

支付通道模块，用于为用户提供不同的第三方支付通道。

进一步的，所述支撑层包括：

监控报警模块，用于监控整个***的风险与故障，并为用户提供预警；

日志管理模块，用于记录整个***的所有运行轨迹；

加签验签模块，用于为所述核心层内的支付行为提供安全验证。

进一步的，所述用户包括：***管理人员、商户和用户。

进一步的，所述收银台模块包括线上收银台子模块和线下收银台子模块。

进一步的，所述基础订单模块内包括：创建订单子模块、关单子模块、支付子模块、退款子模块和回调通知子模块。

进一步的，所述支撑层提供的软件包括redis组件、es、mysql和oracle。

一种电商平台的多渠道及多币种支付网关***的实现方法，包括：

S1、配置业务线的支付参数；

S2、用户依据自身选择生成对应的订单；

S3、判断支付环境的安全性，以及检查订单状态是否异常；

S4、当支付环境安全，订单状态正常时，依据用户选择的支付渠道，匹配所述S1中对应的支付参数；

S5、S4完成后，跳转至第三方支付通道完成支付行为；

S6、第三方支付完成后，返回支付结果至对应用户，对应用户依据支付结果进行对应的后续业务处理。

本发明通过研究并建立多渠道及多币种(人民币及澳门元)支付网关***和统一方法，降低支付成本，提高支付效率，为用户创造更便捷的生活方式。本发明的支付通道丰富、满足消费者多元化支付的需求，多币种兑换没有货币转换费，既方便又省钱。本发明解决商户线上做生意、线上收款需求，增强商户与用户之间的粘性。本发明满足本澳居民/访澳旅客可以使用人民币种作为支付币种，实现随时随地多币种消费无障碍。

附图说明

为了更清楚地说明本发明实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本发明提供的一种电商平台的多渠道及多币种支付网关***的结构图；

图2是本发明提供的一种电商平台的多渠道及多币种支付网关***的实现方法流程图。

具体实施方式

为使本发明的上述目的、特征和优点能够更加明显易懂，下面将结合附图和具体的实施例对本发明的技术方案进行详细说明。需要指出的是，所描述的实施例子仅仅是本发明一部分实施例，而不是全部的实施例，基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

实施例

如图1所示，一种电商平台的多渠道及多币种支付网关***，包括：

产品层，用于与用户进行交互；组合核心层提供的支付能力，对终端用户提供收银台、对运营财务人员提供运营财务***。作为优选，所述产品层包括：

收银台模块，用于向用户展示订单金额以及为用户提供支付方式选择；作为优选，所述收银台模块包括线上收银台子模块和线下收银台子模块。管理后台模块，为所述收银台模块提供参数配置；支付产品模块，用于为用户提供便捷支付方式，用户依据自身情况选择对应支付方式。

收银台模块是整个***发生支付行为时面向用户的唯一入口，即为用户提供一个收银台，用户体验及安全性至关重要。为同时支持业务个性化和用户的一致性体验，收银台主要是通过定制化和配置化的方式实现。对业务线人员来讲接入收银台模块也非常简单，仅需通过订单号跳转至收银台页面，后续流程均由本***完成。

用户下单后到达收银台页面，收银台模块通过订单所属业务线、支付金额、是否合单等信息，展示可用的支付通道。同时风控***(即下文所述的监控预警模块)会从商品、订单、用户行为等维度进行监控，屏蔽高风险的支付渠道。支付渠道出现故障时可在收银台暂停展示。

(1)定制化

为支持统一收银台下各业务线不同模式、不同展示的特性，使用工厂类继承的模式实现各业务数据及展示样式。

收银台主要属性分为展示模块和通道路由，其中重复及默认功能的模块由抽象类用模板的方式实现，子类使用默认方法或者重写父类方法即可达到自定义的实现。

收银台展示实现类已经实现了一套默认的收银台，其中包含大多数必须的组件(如倒计时，头部定制，订单详情等)。

一般情况下，各个业务线仅需简单添加特定的实现类，即可生成一个清晰又丰富的页面。

通过管理后台对收银台各个支付渠道的参数配置(名称、支付费率、排序等)，实现各个对接的支付渠道定制化需求。

(2)配置化

收银台的配置化主要根据各业务的属性(业务类型、品类等)对后续操作做一定的流程处理配置化，比如：

基于后端路由对收银台展示层做不同的处理，用户看到的可支持的通道列表(微信、支付宝等)，以及排序置顶打标记等。

满足不同场景、不同业务在同一种支付方式下收款到不同的收款账号。

根据场景不同，走不同的结算方式，以及结算渠道等。

通过管理后台对不同的支付商户进行相应的参数维护，完成支付渠道的开通，相应结算费率、结算账户维护等配置化操作。

核心层，为所述产品层的实现提供业务逻辑；作为优选，所述核心层包括：

基础订单模块，用于依据用户的选择生成对应的订单；所述基础订单模块是实现业务和支付结算解耦的桥梁。作为优选，所述基础订单模块内包括：创建订单子模块、关单子模块、支付子模块、退款子模块和回调通知子模块。

支付路由模块，用于依据用户所选择的不同支付方式配置不同的收款账号；需要说明的是，所述支付路由模块主要包含两方面，一个是业务侧需要控制支付通道，一个是支付侧需要选择支付账户。

(1)支付账户管理

支付创建订单和处理回调等流程中，需要根据业务类型、支付方式和支付通道确定支付账号，早期版本这个对应关系是通过配置文件维护的。一个业务类型对应多个配置项，每新增一个业务需要增加多个配置，而且随着更多支付通道的接入，新增业务需要配置的信息也越来越多，不易维护。

经过优化，把现有的配置对应关系放到数据库中，数据表由业务类型、支付方式、支付通道唯一确定一个收款账号，支付账号的具体参数信息还是放在文件配置中。创建订单时根据业务类型、支付方式、支付通道查询收款账号，把账号信息记录到支付订单数据表，回调时直接从订单表查询支付账号。

支付通道模块，用于为用户提供不同的第三方支付通道。需要实名的是，本发明对接的第三方通道包括但不限于：支付宝、支付宝(澳门地区)、微信、云闪付、Mpay、applepay等第三方通道，每一个第三方通道下有多个支付产品。第三方通道的接口形式差异很大，但是都提供下单、退款、查询、支付通知、账单下载等标准功能。本***对这些第三方通道做了一次封装，用一个抽象类作为基类，使用模版方法设计模式，在基类中定义了一个标准流程，具体的实现在通道各自的实现类中。客户类只需要关心基类的公共方法，和具体通道无关。

支撑层，为所述产品层和所述核心层的实现提供所需的软件。支撑层主要包含支撑各***所需的各软件及基础服务等信息，包括但不限于：缓存用的 redis组件，搜索用的es，数据存储用到的数据库mysql和oracle。

作为优选，所述支撑层包括：

监控报警模块，用于监控整个***的风险与故障，并为用户提供预警；

日志管理模块，用于记录整个***的所有运行轨迹；

加签验签模块，用于为所述核心层内的支付行为提供安全验证。

需要说明的是，所述支撑层包含监控报警、日志管理、加签验签等模块。其中日志管理模块使用ELK进行收集管理；作为优选，本发明还提供有配置管理模块和消息总线模块，配置管理模块采用分布式配置中心进行管理，消息总线模块使用二次封装的RabbitMQ进行消息分发及消费。

由于支付***对可用性有极高要求以及支付数据的敏感性，本***独立实现了监控报警功能，下面将详细描述该监控报警模块的功能及设计思路。

监控***

为保证监控的实时性及有效性，监控依赖的资源如数据库必须和业务库要进行隔离(避免鸡蛋放在同一个篮子里)。支付监控***涵盖了API监控、服务性能监控、数据库监控等，能够提供统一的报警、分析和故障排除能力。从异常数据采集到故障问题主动发现及稳定性趋势分析，为支付体系优化提供数据支撑。

(1)监控后台

监控后台主要包含监控用户管理以及监控项创建管理，用户可以根据需求对应的监控项目，可配置的参数涵盖API请求地址、请求方式、可用性、正确性、响应时间等性能数据以及报警方式和策略。接口监控可以针对固定host IP 绑定以及设置超时时间，监控请求支持GET、POST两种方式，POST方式可以设置固定请求参数辅助，监控频率支持分钟、秒两种级别配置；响应数据模块可以校验HTTP code是否异常，配置响应数据类型，比较检测返回key值，针对DB监控还可以设置DB查询超时时间；报警模块目前支持短信和邮件两种方式，可以设置最小、最大报警阈值，超过最大阈值每隔最大报警数会触发一次报警，规避了故障期间短信轰炸问题。

(2)监控核心

为了实现最快监控频率10秒，同时可以支持成千上万的监控项并行运行，支付监控采用了多进程管理的方式。父进程创建指定数量的子进程，每个子进程完成固定数量的监控任务退出任务，此时父进程实时监控子进程状态并创建新的子进程执行任务；父进程还可以接受外部信号完成服务重启以及停止。

(3)监控报警

执行监控项会根据监控配置进行接口请求以及返回数据分析处理，然后通过Redis计数方式按报警策略进行报警通知。

作为优选，所述用户包括：***管理人员、商户和用户。

如图2所示，一种电商平台的多渠道及多币种支付网关***的实现方法，包括：

S1、配置业务线的支付参数；

S2、用户依据自身选择生成对应的订单；

S3、判断支付环境的安全性，以及检查订单状态是否异常；

S4、当支付环境安全，订单状态正常时，依据用户选择的支付渠道，匹配所述S1中对应的支付参数；

S5、S4完成后，跳转至第三方支付通道完成支付行为；

S6、第三方支付完成后，返回支付结果至对应用户，对应用户依据支付结果进行对应的后续业务处理。

即***首先配置业务线的支付参数，比如支持什么支付渠道，支持哪些客户端、费率等信息。

在支付过程中，***首先调用风控中心(即上文所述监控预警模块)判断用户当前支付环境的安全性是否满足，如校验通过，继续检查该订单的状态是否有异常，比如已关单或者已经支付过，将抛出对应的异常信息。所有的检查通过后，根据用户选择的支付渠道以及业务侧上送的商户信息，找出对应的支付渠道参数，比如商户号，支付秘钥、渠道下单的url等信息，去第三方下单，然后将第三方返回的支付参数转回给业务线、客户端跳转至第三方sdk，由用户完成支付行为。在用户支付的过程中，支付中心定时器每5秒去第三方轮询支付结果直至查询到支付结果或者收到第三方的支付回调，更新支付状态并通知给业务线，进行后续的业务处理，比如发货等。

本发明通过研究并建立多渠道及多币种(人民币及澳门元)支付网关***和统一方法，降低支付成本，提高支付效率，为用户创造更便捷的生活方式。本发明的支付通道丰富、满足消费者多元化支付的需求，多币种兑换没有货币转换费，既方便又省钱。本发明解决商户线上做生意、线上收款需求，增强商户与用户之间的粘性。本发明满足本澳居民/访澳旅客可以使用人民币种作为支付币种，实现随时随地多币种消费无障碍。

在本说明书中所谈到的“一个实施例”、“另一个实施例”、“实施例”、“优选实施例”等，指的是结合该实例描述的具体特征、结构或者特点包含在本申请概括描述的至少一个实施例中。在说明书中多个地方出现同种表述不是一定指的是同一个实施例。进一步来说，结合任一实施例描述一个具体特征、结构或者特点时，所要主张的是结合其他实施例来实现这种特征、结构或者特点也落在本发明内。尽管这里参照本发明的多个解释性实例对本发明进行了描述，但是，应该理解，本领域技术人员可以设计出很多其他的修改和实施方式，这些修改和实施方式降落在本申请公开的原则范围和精神之内。更具体地说，在本申请公开、附图和权利要求的范围内，可以对主题结合布局的组成部件和/或布局进行的变形和改进外，对于本领域技术人员来说，其他的用途也将是明显的。

Claims (9)

1.一种电商平台的多渠道及多币种支付网关***，其特征在于，包括：

产品层，用于与用户进行交互；

核心层，为所述产品层的实现提供业务逻辑；

支撑层，为所述产品层和所述核心层的实现提供所需的软件。

2.根据权利要求1所述的电商平台的多渠道及多币种支付网关***，其特征在于，所述产品层包括：

收银台模块，用于向用户展示订单金额以及为用户提供支付方式选择；

管理后台模块，为所述收银台模块提供参数配置；

支付产品模块，用于为用户提供便捷支付方式，用户依据自身情况选择对应支付方式。

3.根据权利要求2所述的电商平台的多渠道及多币种支付网关***，其特征在于，所述核心层包括：

基础订单模块，用于依据用户的选择生成对应的订单；

支付路由模块，用于依据用户所选择的不同支付方式配置不同的收款账号；

支付通道模块，用于为用户提供不同的第三方支付通道。

4.根据权利要求3所述的电商平台的多渠道及多币种支付网关***，其特征在于，所述支撑层包括：

监控报警模块，用于监控整个***的风险与故障，并为用户提供预警；

日志管理模块，用于记录整个***的所有运行轨迹；

加签验签模块，用于为所述核心层内的支付行为提供安全验证。

5.根据权利要求1所述的电商平台的多渠道及多币种支付网关***，其特征在于，所述用户包括：***管理人员、商户和用户。

6.根据权利要求2所述的电商平台的多渠道及多币种支付网关***，其特征在于，所述收银台模块包括线上收银台子模块和线下收银台子模块。

7.根据权利要求3所述的电商平台的多渠道及多币种支付网关***，其特征在于，所述基础订单模块内包括：创建订单子模块、关单子模块、支付子模块、退款子模块和回调通知子模块。

8.根据权利要求1所述的电商平台的多渠道及多币种支付网关***，其特征在于，所述支撑层提供所需的软件包括redis组件、es、mysql和oracle。

9.一种电商平台的多渠道及多币种支付网关***的实现方法，其特征在于，包括：

S1、配置业务线的支付参数；

S2、用户依据自身选择生成对应的订单；

S3、判断支付环境的安全性，以及检查订单状态是否异常；

S4、当支付环境安全，订单状态正常时，依据用户选择的支付渠道，匹配所述S1中对应的支付参数；

S5、S4完成后，跳转至第三方支付通道完成支付行为；

S6、第三方支付完成后，返回支付结果至对应用户，对应用户依据支付结果进行对应的后续业务处理。

Images