CN115018486B - 一种统一支付系统 - Google Patents

Abstract

本申请提供的一种统一支付系统，该系统可以包括聚合支付平台，当用户在商户平台发起下单请求后，商户平台可以将该下单请求发送至聚合支付平台，此时，聚合支付平台可以向商户平台发送其支付地址，当商户平台收到该支付地址后，可以打开对应的聚合支付平台的支付页面，用户可以在该支付页面选择任一第三方支付平台，这样聚合支付平台便能够向清算平台发送由第三方支付平台支付本次订单的支付请求，当聚合支付平台收到清算平台下发的支付凭证后，便可以根据该支付凭证来拉起第三方支付平台供用户向商户平台进行支付，极大地降低了商户的接入门槛及投入成本。

Description

一种统一支付系统

技术领域

本申请涉及移动支付技术领域，尤其涉及一种统一支付系统。

背景技术

目前，用户在日常消费过程中，经常使用支付宝、微信支付、京东支付、QQ钱包等第三方支付平台进行支付。商户为了满足用户使用各种不同类型的第三方支付平台进行支付的多样化支付需求，需要在商户平台搭建多种支付渠道来供用户进行选择。

例如，由于业务场景的多样化，用户不仅对现有的微信小程序&公众号支付、支付宝扫码支付存在需求，而且还希望使用微信、支付宝APP等的支付功能，当商户自身通过交互流程调整来实现上述需求时，不仅需要自研小程序、公众号，还需要在微信及支付宝上进行报备审批，整个流程较为繁琐、实现难度较大，投入成本较高。

发明内容

本申请的目的旨在至少能解决上述的技术缺陷之一，特别是现有技术中商户自身通过交互流程调整来实现用户需求时，整个流程较为繁琐、实现难度较大，投入成本较高的技术缺陷。

本申请提供了一种统一支付系统，所述系统包括：聚合支付平台；

所述聚合支付平台用于接收商户平台发送的下单请求，并根据所述下单请求向所述商户平台发送所述聚合支付平台的支付地址，以供所述商户平台访问所述聚合支付平台的支付地址对应的支付页面；

所述聚合支付平台还用于接收用户在所述支付页面选择的任一第三方支付平台，并向清算平台发送由所述第三方支付平台支付本次订单的支付请求，当所述清算平台返回与所述支付请求对应的支付凭证后，根据所述支付凭证拉起所述第三方支付平台供用户向所述商户平台进行支付。

可选地，所述聚合支付平台还用于：

接收所述第三方支付平台返回的支付结果，并将所述支付结果返回至所述商户平台。

可选地，所述聚合支付平台还用于：

接收所述清算平台发送的支付结果，并向所述商户平台异步通知所述支付结果。

可选地，所述聚合支付平台包括聚合支付收单应用；

所述聚合支付收单应用用于将所述清算平台下发的支付结果转发至所述商户平台。

可选地，所述聚合支付平台包括聚合支付收银台，及运行在第三方支付平台中的聚合支付程序；

所述聚合支付收银台用于根据所述下单请求向所述商户平台发送运行在用户所选择的第三方支付平台中的聚合支付程序的程序地址；

所述聚合支付程序用于通过所述聚合支付收银台向所述清算平台发送由运行所述聚合支付程序的第三方支付平台支付本次订单的支付请求。

可选地，所述聚合支付程序还用于：

接收所述清算平台返回的与所述支付请求对应的支付凭证，并根据所述支付凭证拉起所述第三方支付平台供用户向所述商户平台进行支付。

可选地，所述商户平台中集成有openSDK；

所述openSDK用于根据所述程序地址将所述商户平台的当前页面跳转至所述聚合支付程序的支付页面。

可选地，所述下单请求中包含用户所选择的第三方支付平台；

所述聚合支付收银台从运行所述聚合支付程序的第三方支付平台中获取所述聚合支付程序对应的URL scheme，并将所述URL scheme发送至所述商户平台，以使所述商户平台根据所述URL scheme将当前页面跳转至所述聚合支付程序的支付页面。

可选地，所述程序地址包括程序URL；

所述程序URL用于供所述商户平台转换为对应的二维码后进行显示。

可选地，所述系统还包括用户终端；

所述用户终端用于对所述商户平台中显示的二维码进行扫描，并展示扫描后得到的所述聚合支付程序的支付页面供用户使用。

从以上技术方案可以看出，本申请实施例具有以下优点：

本申请提供的一种统一支付系统，该系统可以包括聚合支付平台，当用户在商户平台发起下单请求后，商户平台可以将该下单请求发送至聚合支付平台，此时，聚合支付平台可以向商户平台发送其支付地址，当商户平台收到该支付地址后，可以打开对应的聚合支付平台的支付页面，用户可以在该支付页面中选择任一第三方支付平台，这样聚合支付平台便能够向清算平台发送由第三方支付平台支付本次订单的支付请求，当聚合支付平台收到清算平台下发的支付凭证后，便可以根据该支付凭证来拉起第三方支付平台供用户向商户平台进行支付，该过程中，用户可以选择任意第三方支付平台进行支付，而商户平台也无需搭建多种支付渠道，即可通过简便的支付流程进行商品交易，极大地降低了商户的接入门槛及投入成本，使得商户可以投入更多的资源、精力在主营业务上。

附图说明

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

图1为本申请实施例提供的统一支付系统中多方平台之间数据交互流程图；

图2为本申请实施例提供的统一支付系统中又一多方平台之间数据交互流程图；

图3为本申请实施例提供的聚合支付平台与其他平台之间的数据交互流程图；

图4为本申请实施例提供的使用openSDK访问聚合支付程序的流程图；

图5为本申请实施例提供的URL scheme跳转至聚合支付程序的流程图；

图6为本申请实施例提供的使用程序URL访问聚合支付程序的流程图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

目前，由于业务场景的多样化，用户不仅对现有的微信小程序&公众号支付、支付宝扫码支付存在需求，而且还希望使用微信、支付宝APP等的支付功能，当商户自身通过交互流程调整来实现上述需求时，不仅需要自研小程序、公众号，还需要在微信及支付宝上进行报备审批，整个流程较为繁琐、实现难度较大，投入成本较高。

基于此，本申请提出了如下技术方案，具体参见下文：

在一个实施例中，如图1所示，图1为本申请实施例提供的统一支付系统中多方平台之间数据交互流程图；本申请提供了一种统一支付系统，所述系统包括：聚合支付平台。

所述聚合支付平台用于接收商户平台发送的下单请求，并根据所述下单请求向所述商户平台发送所述聚合支付平台的支付地址，以供所述商户平台访问所述聚合支付平台的支付地址对应的支付页面；

所述聚合支付平台还用于接收用户在所述支付页面选择的任一第三方支付平台，并向清算平台发送由所述第三方支付平台支付本次订单的支付请求，当所述清算平台返回与所述支付请求对应的支付凭证后，根据所述支付凭证拉起所述第三方支付平台供用户向所述商户平台进行支付。

本实施例中，统一支付系统可以包括聚合支付平台，聚合支付平台分别与商户平台、清算平台以及第三方支付平台之间进行数据交互，以实现商户平台与用户之间的支付操作，减少商户平台对支付功能的研发投入，并降低支付流程的管理难度。

其中，商户平台指的是与用户进行商品、服务交易的平台，包括但不限于餐饮类平台、休闲娱乐类平台、知识科普类平台、购物类平台、直播类平台等，在此不做限制。

如图1所示，商户平台可以接收用户发起的下单请求，并将该下单请求发送至聚合支付平台。例如，当用户在某一商户平台中进行商品交易，如下单购买饮料后，该商户平台可以将用户发起的下单请求发送至聚合支付平台，由聚合支付平台来对接第三方支付平台，用户可以通过所选择的第三方支付平台向商户平台进行付款，这样便可以极大程度上减少商户平台自行研发与用户需求对应的多种不同类型的第三方支付渠道的研发投入。

进一步地，聚合支付平台在对接第三方支付平台的过程中，可以根据商户平台发送的下单请求生成聚合支付平台的支付地址，并将该支付地址发送给商户平台，以供商户平台访问该支付地址对应的支付页面。可以理解的是，该支付页面指的是聚合支付平台的支付页面，该支付页面中包含相应的支付金额等，因此，聚合支付平台可以接收用户在该支付页面中进行的相关操作，如选择任一第三方支付平台等，当聚合支付平台接收到用户确认的支付金额以及选择的任一第三方支付平台后，便可以向清算平台发送由第三方支付平台支付本次订单的支付请求。

当清算平台接收到该支付请求后，便可以根据该支付请求下发对应的支付凭证至聚合支付平台，聚合支付平台可以根据该支付凭证来拉起对应的第三方支付平台供用户向商户平台进行支付，从而完成相应的支付操作。

可以理解的是，本申请中的清算平台指的是银联/网联渠道等具有清算、结算功能的平台，其业务主要涉及在各个金融机构之间调拨资金、划拨支付的结算款项，以及偿还由这些行为引起的资金欠款。当本申请中用户通过第三方支付平台向商户平台进行付款时，必须先通过银联/网联渠道进行对接，即交易先经过银联/网联渠道，当收到支付凭证后，聚合支付平台才能拉起相应的第三方支付平台进行付款操作。

更进一步地，本申请中用户在选择第三方支付平台时，可以是在商户平台发起下单请求的同时进行选择，也可以在聚合支付平台的支付页面中进行选择，当用户在商户平台中设置默认支付方式时，商户平台在发送下单请求至聚合支付平台时可以直接将该默认支付方式一并发出。另外，商户平台在聚合支付平台中开通产品时，也可以根据自身需求选择一个或多个不同类型的支付方式，当商户平台只选择了其中一种类型的支付方式时，聚合支付平台会根据商户平台已开通的产品调用对应的支付地址，而非调用用户所选择的与商户平台已开通的产品不符的支付地址。

上述实施例中，当用户在商户平台发起下单请求后，商户平台可以将该下单请求发送至聚合支付平台，此时，聚合支付平台可以向商户平台发送其支付地址，当商户平台收到该支付地址后，可以打开对应的聚合支付平台的支付页面，用户可以在该支付页面中选择任一第三方支付平台，这样聚合支付平台便能够向清算平台发送由第三方支付平台支付本次订单的支付请求，当聚合支付平台收到清算平台下发的支付凭证后，便可以根据该支付凭证来拉起第三方支付平台供用户向商户平台进行支付，该过程中，用户可以选择任意第三方支付平台进行支付，而商户平台也无需搭建多种支付渠道，即可通过简便的支付流程进行商品交易，极大地降低了商户的接入门槛及投入成本，使得商户可以投入更多的资源、精力在主营业务上。

在一个实施例中，如图2所示，图2为本申请实施例提供的统一支付系统中又一多方平台之间数据交互流程图；所述聚合支付平台还可以用于：接收所述第三方支付平台返回的支付结果，并将所述支付结果返回至所述商户平台。

本实施例中，第三方支付平台不仅可以供用户向商户平台进行付款，还可以向聚合支付平台返回支付结果，并由聚合支付平台将该支付结果返回至商户平台，这样商户平台便可以及时知晓本次支付操作的具体支付金额，以便后续进行查账核对。

在一个实施例中，如图2所示，所述聚合支付平台还可以用于：接收所述清算平台发送的支付结果，并向所述商户平台异步通知所述支付结果。

本实施例中，清算平台不仅可以根据聚合支付平台发送的支付请求来生成相应的支付凭证，还可以在第三方支付平台支付完成后，通过聚合支付平台异步通知商户平台本次支付操作的支付结果，以便商户平台根据该支付结果来进行核对。

进一步地，商户平台可以将清算平台发送的支付结果与第三方支付平台发送的支付结果进行比对，查看是否出错，以进一步提高交易准确度。

可以理解的是，“对账”系商户将自有平台存储的数据与上游渠道(本处即指聚合支付平台)提供的对账单数据进行比对的过程。但商户自有平台存储的数据是基于上游渠道通过接口提供数据。故，此“对账”操作的意义更多是作为商户修正平台异常数据(包括技术、人为方面导致)的方向标。

在一个实施例中，如图3所示，图3为本申请实施例提供的聚合支付平台与其他平台之间的数据交互流程图；所述聚合支付平台可以包括聚合支付收单应用；所述聚合支付收单应用用于将所述清算平台下发的支付结果转发至所述商户平台。

本实施例中，如图3所示，聚合支付平台可以利用聚合支付收单应用来与清算平台进行对接，具体对接事宜可以包括将清算平台下发的支付结果转发至商户平台，以便商户平台对该支付结果进行确认，查看用户是否已付款成功，付款成功后即可安排发货/服务等后续事宜。

在一个实施例中，如图3所示，所述聚合支付平台可以包括聚合支付收银台，及运行在第三方支付平台中的聚合支付程序。

所述聚合支付收银台用于根据所述下单请求向所述商户平台发送运行在用户所选择的第三方支付平台中的聚合支付程序的程序地址。

所述聚合支付程序用于通过所述聚合支付收银台向所述清算平台发送由运行所述聚合支付程序的第三方支付平台支付本次订单的支付请求。

本实施例中，如图3所示，聚合支付平台不但可以包括聚合支付收银台，还可以包括聚合支付程序以及聚合支付收单应用。其中，聚合支付程序运行在第三方支付平台中，如小程序、公众号等。

聚合支付收银台主要负责根据商户平台发送的下单请求向商户平台发送运行在用户所选择的第三方支付平台中的聚合支付程序的程序地址，以便商户平台根据该程序地址来访问运行第三方支付平台中的聚合支付程序，并使用户通过该聚合支付程序来进行支付操作；当商户平台访问聚合支付程序的支付页面后，可以向用户展示该支付页面，用户可以在展示的支付页面中确认支付金额，当聚合支付程序接收到用户确认的支付金额后，便可以通过聚合支付收银台向清算平台发送由第三方支付平台支付该支付金额的支付请求，以便清算平台能够返回支付凭证后供第三方支付平台向商户平台进行支付操作。

可以理解的是，本申请中的聚合支付程序可以运行在任意第三方支付平台中，当商户平台在聚合支付平台中开通相应的产品，如通过某一具体的第三方支付平台进行支付的产品，聚合支付平台即可为该商户平台发送运行在该第三方支付平台中的聚合支付程序的程序地址，这样商户平台便可以访问该聚合支付程序，并通过该聚合支付程序来完成支付操作，该过程无需商户平台分别对接不同类型的第三方支付平台的平台接口，而是通过自有的APP/H5来对接聚合支付程序的程序地址接口，便可以满足用户使用不同类型的第三方支付平台进行支付的需求，同时也免去对接不同类型的第三方支付平台的操作流程。

在一个实施例中，如图3所示，所述聚合支付程序还可以用于：接收所述清算平台返回的与所述支付请求对应的支付凭证，并根据所述支付凭证拉起所述第三方支付平台供用户向所述商户平台进行支付。

本实施例中，当清算平台返回支付凭证后，聚合支付程序可以根据返回的支付凭证来拉起对应的第三方支付平台供用户向商户平台进行支付操作。

例如，当聚合支付程序接收到第三方支付平台的支付凭证后，可以拉起第三方支付平台中用于支付的支付工具，如操作键盘、人脸识别、指纹识别等，以便用户通过该支付工具进行支付操作。

在一个实施例中，如图4所示，图4为本申请实施例提供的使用openSDK访问聚合支付程序的流程图；所述商户平台中集成有openSDK。

所述openSDK用于根据所述程序地址将所述商户平台的当前页面跳转至所述聚合支付程序的支付页面。

本实施例中，如图4所示，商户平台可以包括商户APP和商户后台应用，其中，商户APP中集成有openSDK，该openSDK的英文全称为Open Software Development Kit，中文译文为开放软件开发工具包，商户APP可以使用该openSDK拉起对应的聚合支付程序，从而将商户APP的当前页面跳转至聚合支付程序的支付页面。

具体地，商户平台可以利用代码编写一个小工具，引入各第三方支付平台对应的openSDK，接着编写代码来读取配置文件的信息，按照第三方支付平台的接口标准组装好参数，作为将要调用的接口的请求报文，然后利用openSDK调用第三方支付平台接口，并访问运行在第三方支付平台上的聚合支付程序，以此来进行支付操作。

在一个实施例中，如图5所示，图5为本申请实施例提供的URL scheme跳转至聚合支付程序的流程图；通过所述下单请求中包含用户所选择的第三方支付平台。

所述聚合支付收银台从运行所述聚合支付程序的第三方支付平台中获取所述聚合支付程序对应的URL scheme，并将所述URL scheme发送至所述商户平台。

所述商户平台根据所述URL scheme将当前页面跳转至所述聚合支付程序的支付页面。

本实施例中，如图5所示，聚合支付平台可以利用聚合支付收银台来从第三方支付平台中获取聚合支付程序对应的URL scheme，URL scheme指的是用于打开聚合支付程序的超链接类型之一，商户平台可在其APP/H5商城中访问该URL scheme以拉起聚合支付程序，供用户使用对应的第三方支付平台进行付款。

在一个实施例中，如图6所示，图6为本申请实施例提供的使用程序URL访问聚合支付程序的流程图；所述程序地址可以包括程序URL；所述程序URL用于供所述商户平台转换为对应的二维码后进行显示。

本实施例中，如图6所示，聚合支付平台向商户平台下发的聚合支付程序的程序地址可以为程序URL，商户平台可以将该程序URL转换为对应的二维码后向用户进行展示，以便用户扫描该二维码。

在一个实施例中，所述系统还可以包括用户终端。

所述用户终端用于对所述商户平台中显示的二维码进行扫描，并展示扫描后得到的所述聚合支付程序的支付页面供用户使用。

本实施例中，如图6所示，当商户平台将该程序URL转换为对应的二维码后向用户进行展示后，用户可以使用自身的用户终端来扫描该二维码，以跳转至对应的聚合支付程序的支付页面进行付款操作，方便使用不同类型的第三方支付平台进行支付的用户的支付需求。

最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间可以根据需要进行组合，且相同相似部分互相参见即可。

对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本申请。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本申请的精神或范围的情况下，在其它实施例中实现。因此，本申请将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。

Claims (7)

1.一种统一支付系统，其特征在于，所述系统包括：聚合支付平台；

所述聚合支付平台用于接收商户平台发送的下单请求，并根据所述下单请求向所述商户平台发送所述聚合支付平台的支付地址，以供所述商户平台访问所述聚合支付平台的支付地址对应的支付页面；

所述聚合支付平台还用于接收用户在所述支付页面选择的任一第三方支付平台，并向清算平台发送由所述第三方支付平台支付本次订单的支付请求，当所述清算平台返回与所述支付请求对应的支付凭证后，根据所述支付凭证拉起所述第三方支付平台供用户向所述商户平台进行支付；

所述聚合支付平台包括聚合支付收银台，及运行在第三方支付平台中的聚合支付程序；

所述聚合支付收银台用于根据所述下单请求向所述商户平台发送运行在用户所选择的第三方支付平台中的聚合支付程序的程序地址；

所述聚合支付程序用于通过所述聚合支付收银台向所述清算平台发送由运行所述聚合支付程序的第三方支付平台支付本次订单的支付请求；

所述商户平台中集成有openSDK；所述openSDK用于根据所述程序地址将所述商户平台的当前页面跳转至所述聚合支付程序的支付页面；

或者，所述聚合支付收银台从运行所述聚合支付程序的第三方支付平台中获取所述聚合支付程序对应的URLscheme，并将所述URLscheme发送至所述商户平台，以使所述商户平台根据所述URLscheme将当前页面跳转至所述聚合支付程序的支付页面。

2.根据权利要求1所述的系统，其特征在于，所述聚合支付平台还用于：

接收所述第三方支付平台返回的支付结果，并将所述支付结果返回至所述商户平台。

3.根据权利要求1所述的系统，其特征在于，所述聚合支付平台还用于：

接收所述清算平台发送的支付结果，并向所述商户平台异步通知所述支付结果。

4.根据权利要求3所述的系统，其特征在于，所述聚合支付平台包括聚合支付收单应用；

所述聚合支付收单应用用于将所述清算平台下发的支付结果转发至所述商户平台。

5.根据权利要求1所述的系统，其特征在于，所述聚合支付程序还用于：

接收所述清算平台返回的与所述支付请求对应的支付凭证，并根据所述支付凭证拉起所述第三方支付平台供用户向所述商户平台进行支付。

6.根据权利要求1所述的系统，其特征在于，所述程序地址包括程序URL；

所述程序URL用于供所述商户平台转换为对应的二维码后进行显示。

7.根据权利要求6所述的系统，其特征在于，所述系统还包括用户终端；

所述用户终端用于对所述商户平台中显示的二维码进行扫描，并展示扫描后得到的所述聚合支付程序的支付页面供用户使用。