CN113393233A - 一种数据处理方法、装置、设备与存储介质 - Google Patents

Abstract

本申请实施例公开了一种数据处理方法、装置、设备与存储介质，属于数据处理技术领域。该方法包括：接收终端发送的产品订单的支付请求，所述支付请求中包含第二支付平台的标识；确定所述产品订单与第一支付流水数据相关联，所述第一支付流水数据中包含第一支付平台的标识；根据所述第一支付流水数据确定所述产品订单的支付状态为未成功，则向所述第一支付平台发送支付关闭请求，并接收所述第一支付平台反馈的支付已关闭响应；获取所述第二支付平台的支付地址，并向所述终端发送所述第二支付平台的支付地址。本申请实施例解决了重复支付的问题。

Description

一种数据处理方法、装置、设备与存储介质

技术领域

本申请实施例涉及数据处理技术领域，特别涉及一种数据处理方法、装置、设备与存储介质。

背景技术

随着互联网的飞速发展，网上商城因其便利、实惠等诸多优势，越来越受商家和买家的钟爱。为了满足用户的需求，方便用户支付，网上商城都会接入多种支付方式，每一种支付方式都需要对接一个独立的支付平台。

利用第三方支付平台进行产品支付过程中，若存在多种支付方式，每种支付方式对应一个支付平台，当用户从商城客户端利用第三方支付平台进行支付时，只能通过回调或主动查询第三方支付平台才能知道该订单的状态。当出现网络不稳定，系统故障等情况时，容易回调延迟或失败，从而导致商城平台的订单支付状态与第三方支付平台对应的支付状态不一致，进而导致用户进行重复支付。

发明内容

为了解决重复支付的问题，本申请实施例提供了一种数据处理方法、装置、设备与存储介质。

一方面，本申请实施例提供了一种数据处理方法，该方法包括：

接收终端发送的产品订单的支付请求，所述支付请求中包含第二支付平台的标识；

确定所述产品订单与第一支付流水数据相关联，所述第一支付流水数据中包含第一支付平台的标识；

根据所述第一支付流水数据确定所述产品订单的支付状态为未成功，则向所述第一支付平台发送支付关闭请求，并接收所述第一支付平台反馈的支付已关闭响应；

获取所述第二支付平台的支付地址，并向所述终端发送所述第二支付平台的支付地址。

另一方面，本申请实施例提供了一种数据处理装置，该装置包括：

收发单元，用于接收终端发送的产品订单的支付请求，所述支付请求中包含第二支付平台的标识；

确定单元，用于确定所述产品订单与第一支付流水数据相关联，所述第一支付流水数据中包含第一支付平台的标识；

所述确定单元，还用于根据所述第一支付流水数据确定所述产品订单的支付状态为未成功；

所述收发单元，还用于向所述第一支付平台发送支付关闭请求，并接收所述第一支付平台反馈的支付已关闭响应；

处理单元，用于获取所述第二支付平台的支付地址；

所述收发单元，还用于向所述终端发送所述第二支付平台的支付地址。

可选的，所述确定单元，还用于：

确定所述产品订单的支付状态为成功支付时，向所述终端发送订单已支付响应。

可选的，所述产品订单不存在相关联的支付流水数据时，所述处理单元，用于生成所述产品订单的第二支付流水数据并与所述产品订单相关联，所述第二支付流水数据中包括所述第二支付平台的标识；

所述收发单元，还用于向所述第二支付平台发送所述产品订单的支付请求；接收所述第二支付平台发送的支付响应，所述支付响应中包含所述第二支付平台的支付地址。

可选的，所述确定单元，还用于确定所述产品订单与已关闭的第二支付流水数据相关联，所述第二支付流水数据中包含所述第二支付平台的标识；

所述收发单元，还用于向所述第二支付平台发送流水激活请求，所述流水激活请求中包含所述第二支付流水数据。

可选的，所述收发单元，还用于接收所述终端发送的产品下单请求；

所述处理单元，还用于生成并存储所述产品订单。

可选的，所述收发单元，还用于：

根据所述第一支付流水数据向所述第一支付平台发送所述产品订单的支付查询请求；

接收所述第一支付平台发送的支付查询响应，所述支付查询响应中包含所述产品订单的支付状态。

可选的，所述第二支付平台的支付地址为所述第二支付平台的支付URL；

所述收发单元，还用于：

接收所述第二支付平台发送的所述产品订单的支付结果；所述支付结果为所述终端利用所述第二支付平台的支付URL进行支付的结果。

另一方面，本申请实施例提供了一种计算设备，包括至少一个处理器、以及至少一个存储器，其中，所述存储器存储有计算机程序，当所述程序被所述处理器执行时，使得所述处理器执行本申请实施例提供的数据处理方法的步骤。

另一方面，本申请实施例提供了一种存储介质，所述存储介质存储有计算机指令，当所述计算机指令在计算机上运行时，使得计算机执行本申请实施例提供的数据处理方法的步骤。

本申请实施例中的商城服务器与支付平台相连接，利用支付平台进行产品订单的支付，支付平台包括第一支付平台和第二支付平台。用户在对产品订单进行支付时，首先选择第一支付平台，则产品订单与第一支付流水数据相关联，第一支付流水数据中包含第一支付平台的标识。在利用第一支付平台进行支付的过程中，若未支付成功，用户也可以选择第二支付平台进行支付。

用户通过终端向商城服务器发送产品订单的支付请求，该支付请求中包含第二支付平台的标识。商城服务器确定产品订单与第一支付流水数据相关联，并根据第一支付流水数据确定产品订单的支付状态为未成功，则向第一支付平台发送支付关闭请求。第一支付平台根据支付关闭请求关闭第一支付流水，并向商城服务器反馈支付已关闭响应。商城服务器获取并向终端发送第二支付平台的支付地址，使得终端可以根据第二支付平台的支付地址向第二支付平台发送该产品订单的支付请求，从而第二支付平台对该产品订单进行支付处理。

本申请实施例在利用第二支付平台对产品订单进行支付时，在确定该订单已存在未支付成功的第一支付流水(与第一支付平台相对应)时，需将第一支付平台的第一支付流水关闭后，才可以利用第二支付平台进行支付，从而避免了第一支付平台和第二支付平台对同一产品订单的重复支付。

附图说明

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

图1示出了现有技术中支付方法的流程图；

图2示出了本申请实施例提供的一种数据处理系统的系统架构图；

图3示出了本申请实施例中一种终端设备的界面示意图；

图4示出了本申请实施例提供的一种数据处理方法的流程图；

图5示出了本申请一个具体实施例提供的数据处理方法的流程图；

图6示出了本申请另一个具体实施例提供的分布式系统应用于区块链系统的结构示意图；

图7示出了本申请实施例提供的一种区块结构的示意图；

图8示出了本申请一个实施例提供的数据处理装置的结构方框图；

图9示出了本申请一个实施例提供的服务器的结构方框图。

具体实施方式

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

本发明的说明书和权利要求书及上述附图中的术语“第一”和“第二”是用于区别不同对象，而非用于描述特定顺序。此外，术语“包括”以及它们任何变形，意图在于覆盖不排他的保护。例如包含了一系列步骤或单元的过程、方法、系统、产品或设备没有限定于已列出的步骤或单元，而是可选地还包括没有列出的步骤或单元，或可选地还包括对于这些过程、方法、产品或设备固有的其它步骤或单元。

为了方便理解，下面对本申请实施例中涉及的名词进行解释：

支付平台：也叫第三方电子支付平台，属于第三方的服务中介机构，是完成第三方担保支付的功能。它主要是面向开展电子商务业务的企业提供电子商务基础支撑与应用支撑服务，不直接从事具体的电子商务活动。第三方支付平台独立于银行、网站以及商家来进行职能清晰的支付。

商城服务器：电子商城的系统服务器，电子商城也可称为网上商城，类似于现实世界当中的商店，是利用电子商务的各种手段，达成从买到卖的过程的虚拟商店，从而减少中间环节，消除运输成本和代理中间的差价，造就对普通消费和加大市场流通带来巨大的发展空间。电子商城就是以电子商务软件来构建的大型商品电子交易平台，其主要作用是通过电子商城交易平台向客户准确、快捷的销售产品。

支付流水：类似于银行流水，是指支付账户的交易记录。支付流水是证明个人或公司对产品支付情况的一种证明材料。

URL(Uniform Resource Locator，统一资源定位符)：在互联网上，每一信息资源都有统一的且在网上唯一的地址，该地址就叫URL，它是互联网上的统一资源定位标志，即网络地址。

Deeplink：移动端深度链接(mobile deep linking、deeplink)，使用URI链接到一个特定的位置，在一个APP(Application，移动应用程序)中特定的位置，而不是简单地启动APP首页。如果没有Deeplink，每个APP都是独立的。内容和服务之间的链接消失了，应用搜索是断裂的。从一定程度上说，每个APP都建立起自己的孤岛，链接和数据不能在App之间交换，Deeplink让APP开发者能够链接到应用内特定的页面。举个例子用户A在APP1上向用户B发送某个商品在APP2上的介绍链接，假如该APP1使用了Deeplink技术，如果用户B同样安装了这个APP2，那用户B就可以点击链接，跳转APP2中该商品页面。可以直接在这个页面购买该商品，不是跳转到首页再去搜索并寻找。

具体实践过程中，目前的支付方案，无法完全避免重复支付，一般做法是商城服务器通过定时脚本请求支付平台的查询接口，进行商城服务器与支付平台的对账操作，检测交易流水。当定时脚本发现有产品订单被重复支付时，发出告警提示。

当用户在电子商城中选中某个产品后，通过电子商城的客户端购买该产品，并选择第一支付平台进行支付。具体的支付流程如图1所示，包括如下步骤：

步骤101：终端通过商城客户端向商城服务器发送产品的下单请求。

步骤102：商城服务器根据用户选择的产品生成产品订单，并存储产品订单。

步骤103：商城服务器向第一支付平台服务器发送支付请求。

步骤104：第一支付平台服务器向商城服务器发送第一支付平台的支付URL。

步骤105：商城服务器将第一支付平台的支付URL向商城客户端发送。

步骤106：商城客户端根据接收到的支付URL，向第一支付平台服务器发送权限和安全性校验请求。

步骤107：第一支付平台服务器进行权限和安全性校验。

步骤108：第一支付平台服务器向商城客户端发送校验结果。

步骤109：商城客户端通过Deeplink技术，跳转至同一终端上安装的第一支付平台对应的客户端。

步骤110：第一支付平台客户端向第一支付平台服务器发送该产品订单的支付请求。

步骤111：第一支付平台服务器处理该支付请求。

步骤112：第一支付平台服务器向第一支付平台客户端和商城服务器反馈支付结果。

步骤113：第一支付平台客户端跳回至商城客户端。

在上述支付过程中，商城服务器根据步骤112，第一支付平台服务器的反馈结果来确定是否完成支付。可能会出现因为网络不稳定、系统故障等原因导致支付平台反馈延迟或失败，从而导致商城服务器中的订单状态与第一支付平台对应支付流水的状态不一致，进而导致用户进行重复支付的问题。另一种可能的具体交易过程中，在步骤109，商城客户端跳转了第一支付平台客户端但未支付时，若用户利用另一个终端设备，对同一个产品订单选择第二支付平台进行支付，由于该产品订单尚未支付，因此用户可以切换支付方式，则在另一个终端设备上，商城客户端跳转至第二支付平台客户端。此时，第一支付平台客户端的支付页面和第二支付平台客户端的支付页面都是有效的，用户可以利用两个终端都进行支付，从而会出现一个产品订单支付了不止一次，产品订单被重复支付的问题。

基于上述处理流程出现的问题，本申请的发明人构思了一种数据处理方法以解决订单重复支付的问题。具体的，在本申请实施例中，用户首先选择第一支付平台进行支付，商城服务器中将产品订单与第一支付流水数据相关联。若用户又选择了第二支付平台进行支付，则商城服务器会根据第一支付流水数据确定产品订单的支付状态是否为成功，当产品订单未支付成功时，向第一支付平台发送支付关闭请求，以使第一支付平台关闭产品订单的支付流水。这样，用户在利用第二支付平台进行支付时，第一支付平台的支付流水已关闭，则不会出现第一支付平台和第二支付平台重复支付的问题。

下面对本申请实施例的技术方案的架构做一些简单介绍，需要说明的是，以下介绍的架构仅用于说明本申请实施例而非限定。在具体实施时，可以根据实际需要灵活地应用本申请实施例提供的技术方案。

为进一步说明本申请实施例提供的技术方案，下面结合附图以及具体实施方式对此进行详细的说明。虽然本申请实施例提供了如下述实施例或附图所示的方法操作步骤，但基于常规或者无需创造性的劳动在所述方法中可以包括更多或者更少的操作步骤。在逻辑上不存在必要因果关系的步骤中，这些步骤的执行顺序不限于本申请实施例提供的执行顺序。

参考图2，其为本申请实施例提供的数据处理方法的系统架构图。该架构至少包括终端设备201、商城服务器202、第一支付平台服务器203和第二支付平台服务器204。终端设备201中安装有商城客户端、第一支付平台客户端、第二支付平台客户端。商城服务器202为商城客户端对应的服务器，第一支付平台服务器203为第一支付平台客户端对应的服务器，第二支付平台服务器204为第二支付平台客户端对应的服务器。

终端设备201可以是手机、个人电脑(personal computer，PC)、平板电脑(PAD)、掌上电脑(Personal Digital Assistant，PDA)、笔记本电脑或者智能穿戴式设备(例如智能手表和智能手环)等终端设备。终端设备201中可以安装购物软件和支付软件，例如该购物软件可以是商城平台应用，商城平台应用可以包括Deeplink功能，支付软件可以是支付平台应用，支付平台应用可以包括支付功能。

用户在商城客户端中浏览并选中产品，商城客户端向用户显示多个支付方式用户可以从多个支付方式中选择一个进行支付，每一种支付方式对应一个支付软件。商城客户端向商城服务器发送支付请求，商城平台根据产品对应的产品订单判断产品订单的支付状态，在确定该产品订单未支付成功时，商城客户端可以根据用户选择的支付方式调用支付软件，终端设备201显示支付软件的支付页面。或者，购物软件还可以为浏览器应用，在浏览器中，同样可以包括Deeplink功能，用户可以在浏览器应用调用跳转的支付页面中进行支付；或者购物软件还可以为小程序应用，在小程序应用中包括Deeplink功能，用户可以在小程序应用调用跳转的支付页面中进行支付。

商城服务器202可以为包括具有产品展示功能以及应用内调用其他应用功能的应用程序或者应用程序对应网站的后台服务器。第一支付平台服务器203和第二支付平台服务器204可以为包括具有支付功能的应用程序的后台服务器。

商城服务器202和/或第一支付平台服务器203和/或第二支付平台服务器204可以是一个独立的设备，也可以是多个服务器所形成的服务器集群。优选地，商城服务器202和/或第一支付平台服务器203和/或第二支付平台服务器204可以采用云计算技术进行信息处理。

终端设备201、商城服务器202、第一支付平台服务器203和第二支付平台服务器204之间可以通过一个或者多个网络进行通信连接。该网络可以是有线网络，也可以是无线网络，例如无线网络可以是移动蜂窝网络，或者可以是无线保真(WIreless-Fidelity，WIFI)网络，当然还可以是其他可能的网络，本发明实施例对此不做限制。

本申请实施例提供一种优选的实施方式，以终端设备为手机为例进行介绍。图3示例性示出了终端设备的一种可能的界面示意图，如图3所示，终端设备中可安装多个APP，比如视频、时钟、通话记录、信息、安全邮箱、手机、S备忘录、设置等。本发明实施例中可预先在第一终端中安装商城客户端和支付平台客户端，比如商城APP301、第一支付APP302、第二支付APP303。

示例性的，用户可以在商城APP301中选购产品，当用户确定购买的产品后，通过商城APP301下单。商城服务器根据用户选择的产品，生成产品订单，商城APP301向用户展示支付选项，支付选项中包括第一支付方式和第二支付方式。用户选择第一支付方式，则由商城APP301的产品显示页面转为第一支付APP302的支付页面。若用户此时不想利用第一支付方式进行支付了，又选择第二支付方式进行支付，则商城服务器根据接收到的支付请求，确定产品订单与第一支付平台的第一支付流水数据相关联，且产品订单的支付状态为未成功，则向第一支付平台服务器发送支付关闭请求。在第一支付平台服务器关闭产品订单的第一支付流水后，商城服务器向商城APP301发送第二支付平台的支付地址。商城APP301根据第二支付平台的支付地址，跳转到第二支付APP303的支付页面。从而，由于第一支付已关闭，则产品订单不会出现重复支付的问题。

当然，本申请实施例提供的架构并不限用于图2所示的结构，本申请实施例并不进行限制。为进一步说明本申请实施例提供的技术方案，下面结合附图以及具体实施方式对此进行详细的说明。虽然本申请实施例提供了如下述实施例或附图所示的方法操作步骤，但基于常规或者无需创造性的劳动在所述方法中可以包括更多或者更少的操作步骤。在逻辑上不存在必要因果关系的步骤中，这些步骤的执行顺序不限于本申请实施例提供的执行顺序。

请参见图4，为本发明实施例提供的图片处理方法的流程示意图，该方法例如可以应用于如图2所示的场景中，该方法的流程描述如下。

步骤401、商城服务器接收终端发送的产品订单的支付请求，支付请求中包含第二支付平台的标识。

可选的，这里的产品可以为现实中存在的真实物品，例如衣服、电器、玩具等，或者产品也可以为虚拟商品，例如基金产品等金融投资类的产品、预定时间段内的会员资格、游戏道具等。

产品订单为商城服务器根据用户选择的产品生成的订货凭据。用户需对选定的产品下单，即用户浏览商城网站挑选商品并提交订单。商城服务器提供在一定的时间范围内，即在用户将订单提交至商城服务器而管理员还未对订单进行确认操作这段时间内，允许会员自行修改、取消自己的订单等订单管理相关操作。

商城客户端根据用户绑定的多个支付方式，向用户显示多个支付方式的选项供用户选择。一种可选的实施例中，用户对产品订单进行支付时，用户针对产品订单选择了第二支付方式，则终端向商城服务器发送支付请求，该支付请求中包含第二支付平台的标识。

步骤402、商城服务器确定产品订单与第一支付流水数据相关联，第一支付流水数据中包含第一支付平台的标识。

这里，第一支付流水数据与第一支付平台相对应，商城服务器中存储有产品订单与支付流水数据的关联关系，产品订单与第一支付流水数据相关联则表明用户选择过第一支付平台对该产品订单进行支付。

需要说明的是，第一支付平台和第二支付平台均为用户绑定的多个支付平台中的任意支付平台，用户可以利用第一支付平台进行支付，也可以利用第二支付平台进行支付。第一支付平台与第二支付平台可以为两个不同的支付平台，第一支付平台与第二支付平台也可以为同一个支付平台。

步骤403、商城服务器根据第一支付流水数据确定产品订单的支付状态为未成功，则向第一支付平台发送支付关闭请求。

产品订单的支付状态包括未支付、支付成功和支付失败，其中，未支付和支付失败均表示产品订单未支付成功，即支付状态为未成功。

一种可选的实施例中，商城服务器从第一支付平台处确定产品订单的支付状态。具体的，商城服务器根据第一支付流水数据向第一支付平台发送产品订单的支付查询请求；

商城服务器接收第一支付平台发送的支付查询响应，支付查询响应中包含产品订单的支付状态。

具体实施过程中，商城服务器可以通过调用支付平台的查询接口，确定产品订单对应的支付状态。当第一支付平台中产品订单未支付成功时，用户还可以利用第二支付平台进行支付，为了避免重复支付，商城服务器向第一支付平台发送支付关闭请求。

一种较佳的实施例中，第一支付平台与第二支付平台为两个不同的支付平台。针对该产品订单，用户首先选择了第一支付平台进行支付，因此，商城服务器中存储有产品订单与第一支付流水数据，且两者相关联。商城服务器根据用户选择第一支付平台进行支付，将产品订单与第一支付流水数据相关联，此时第一支付流水数据的状态为未支付。当商城服务器接收到第一支付平台发送的支付结果后，可以根据支付结果将第一支付流水数据对应的支付状态改为支付成功或支付失败。用户选择第一支付平台之后，也可以选择第二支付平台对同一个产品订单进行支付。则此时，商城服务器在确定产品订单已与第一支付流水数据相关联后，需要确定产品订单的支付状态为未成功，并向第一支付平台发送支付关闭请求，以避免第一支付平台与第二支付平台重复支付。

另一种可能的实施例中，第一支付平台与第二支付平台也可以为相同的支付平台。这种情况下，用户选择第二支付平台即为用户选择同一支付平台两次，即第二支付平台也为第一支付平台。当用户第二次选择第一支付平台时，需保证第一支付平台第一次支付未成功，商城服务器通过调用第一支付平台的查询接口，确定产品订单的支付状态为未成功，则商城服务器向第一支付平台发送支付关闭请求，以使第一支付平台将第一支付流水关闭。

步骤404、商城服务器接收第一支付平台反馈的支付已关闭响应。

步骤405、商城服务器获取第二支付平台的支付地址。

这里，商城服务器中可以存储有第二支付平台的支付地址，则商城服务器直接从数据库中获取第二支付平台的支付地址。若商城服务器中未存储第二支付平台的支付地址，商城服务器也可以向第二支付平台发送请求以获取第二支付平台的支付地址，并将第二支付平台的支付地址存入商城服务器的数据库中。

步骤406、商城服务器向终端发送第二支付平台的支付地址。

本申请实施例中的商城服务器与支付平台相连接，利用支付平台进行产品订单的支付，支付平台包括第一支付平台和第二支付平台。用户在对产品订单进行支付时，首先选择第一支付平台，则产品订单与第一支付流水数据相关联，第一支付流水数据中包含第一支付平台的标识。在利用第一支付平台进行支付的过程中，若未支付成功，用户也可以选择第二支付平台进行支付。

用户通过终端向商城服务器发送产品订单的支付请求，该支付请求中包含第二支付平台的标识。商城服务器确定产品订单与第一支付流水数据相关联，并根据第一支付流水数据确定产品订单的支付状态为未成功，则向第一支付平台发送支付关闭请求。第一支付平台根据支付关闭请求关闭第一支付流水，并向商城服务器反馈支付已关闭响应。商城服务器获取并向终端发送第二支付平台的支付地址，使得终端可以根据第二支付平台的支付地址向第二支付平台发送该产品订单的支付请求，从而第二支付平台对该产品订单进行支付处理。

本申请实施例在利用第二支付平台对产品订单进行支付时，在确定该订单已存在未支付成功的第一支付流水(与第一支付平台相对应)时，需将第一支付平台的第一支付流水关闭后，才可以利用第二支付平台进行支付，从而避免了第一支付平台和第二支付平台对同一产品订单的重复支付。

可选的，本申请实施例中用户针对同一产品订单发起的两次支付，可以在同一终端设备上发起，也可以在两个不同的终端设备上发起。对于在同一终端设备上发起两次支付，该终端设备上需同时安装有第一支付平台客户端和第二支付平台客户端。若在两个不同的终端设备上分别发起，则其中一个终端设备上至少需要安装有第一支付平台客户端，另一个终端设备上至少需要安装有第二支付平台客户端。

具体实施过程中，在用户选择支付方式之前，商城服务器需要生成产品订单。则商城服务器接收终端发送的产品订单的支付请求之前，包括：

商城服务器接收终端发送的产品下单请求；

商城服务器生成并存储产品订单。

具体来说，一种可选的实施例中，用户可以在同一终端上发起两次支付请求。首先终端通过商城客户端向用户显示电子商城中的各个产品，用户从中选出需要购买的产品，执行下单操作。商城客户端基于用户选择的产品，向商城服务器发送产品下单请求。商城服务器根据产品下单请求中包含的产品标识，生成产品订单并存储在商城服务器的数据库中。

之后，商城客户端向用户显示终端支持的所有支付方式，包括对应于第一支付平台的第一支付方式和对应于第二支付平台的第二支付方式。用户选择第一支付方式，则商城服务器将产品订单与第一支付流水数据相关联，此时产品订单的支付状态为未成功。商城服务器将第一支付平台的支付地址发送至商城客户端。商城客户端可以跳转至第一支付平台客户端的支付页面，等待用户的支付操作。

若此时用户不想用第一支付平台支付，想选择第二支付平台支付，则用户无需关闭第一支付平台的第一支付流水，可以重新回到商城客户端，在该产品订单的支付方式中选择第二支付方式，商城客户端则向商城服务器发送同一产品订单的支付请求，这次支付请求中包含第二支付平台的标识。商城服务器中的产品订单已与第一支付流水数据相关联，因此商城服务器需确保该产品订单未被第一支付平台执行支付操作。则商城服务器在产品订单的支付状态为未成功时，向第一支付平台发送支付关闭请求，以避免重复支付。

另一中可选的实施例中，用户可以在不同终端上发起两次支付请求，为了便于描述，将发出第一次支付请求的终端作为第一终端，将发出第二次支付请求的终端作为第二终端，其中第一终端中至少安装有第一支付平台客户端，第二终端中至少安装有二支付平台客户端，两个终端中均安装有商城客户端。

首先第一终端通过商城客户端向用户显示电子商城中的各个产品，用户从中选出需要购买的产品，执行下单操作。在商城服务器生成产品订单后，第一终端向用户显示第一终端支持的所有支付方式，包括第一支付方式。用户选择第一支付方式，则商城服务器将产品订单与第一支付流水数据相关联，此时产品订单的支付状态为未成功。商城服务器将第一支付平台的支付地址发送至第一终端。第一终端显示第一支付平台客户端的支付页面，等待用户的支付操作。

若此时用户不在第一终端上完成支付操作，而是选择第二支付平台支付，则用户打开第二终端上的商城客户端，在该产品订单的支付方式中选择第二支付方式，第二终端则向商城服务器发送同一产品订单的支付请求，这次支付请求中包含第二支付平台的标识。商城服务器中的产品订单已与第一支付流水数据相关联，因此商城服务器需确保该产品订单未被第一支付平台执行支付操作。则商城服务器在产品订单的支付状态为未成功时，向第一支付平台发送支付关闭请求，以避免重复支付。

第一支付流水关闭后，商城服务器获取第二支付平台的支付地址。可选地，第二支付平台的支付地址为所述第二支付平台的支付URL。

若用户曾经利用过第二支付平台的支付URL对电子商城中的产品进行支付，则商城服务器的数据库中存有第二支付平台的支付URL，商城服务器可以直接从数据库中获取。若用户未曾利用第二支付平台的支付URL对电子商城中的产品进行支付，则商城服务器需要向第二支付平台发送请求，以获取第二支付平台的支付URL，商城服务器可以在接收到第二支付平台的响应后，将第二支付平台的支付URL进行存储，并向商城客户端发送。

为了便于用户操作，商城客户端可以具有Deeplink功能，即商城客户端根据支付URL调用第二支付平台客户端，直接显示第二支付平台客户端的支付界面，而无需用户重新打开第二支付平台客户端。

第二支付平台客户端向第二支付平台发送支付请求，并接收第二支付平台反馈的支付结果。同时，为了同步商城服务器中产品订单的状态，第二支付平台也向商城服务器发送该产品订单的支付结果。商城服务器接收第二支付平台发送的产品订单的支付结果，该支付结果为终端利用第二支付平台的支付URL进行支付的结果。

本申请实施例中，商城服务器接收到终端发送的产品订单的支付请求之后，若确定产品订单的支付状态为成功支付，则无需执行后续流程，直接向终端发送订单已支付响应。即由于产品订单已支付，直接拒绝用户的第二次支付请求，避免重复支付。

一种可选的实施例中，商城服务器接收到产品订单的支付请求后，若判断产品订单不存在相关联的支付流水数据，即表明第用户选择的第一次支付方式即与第二支付平台相对应，则商城服务器生成产品订单的第二支付流水数据并与产品订单相关联，第二支付流水数据中包括第二支付平台的标识。

商城服务器向第二支付平台发送产品订单的支付请求；并接收第二支付平台发送的支付响应，支付响应中包含第二支付平台的支付地址。

进一步地，商城服务器中存储有产品订单对应于每一个支付平台的支付流水的状态，并且，针对同一支付平台只存有一个支付流水。同时，一个产品订单在一个支付平台上也仅存有一个支付流水。这样可以简化商城服务器、支付平台与客户端之间的支付对账与排查难度。

在这种情况下，为了分辨不同的支付状态或激活状态，商城服务器中的支付流水需要保存有激活状态或支付状态的标识。则商城服务器接收第一支付平台反馈的支付已关闭响应之后，商城服务器获取所述第二支付平台的支付地址之前，还包括：

商城服务器确定产品订单与已关闭的第二支付流水数据相关联，第二支付流水数据中包含第二支付平台的标识；

商城服务器向第二支付平台发送流水激活请求，流水激活请求中包含第二支付流水数据。

具体实施过程中，支付平台对应的支付流水可以通过支付关闭请求进行关闭，则支付平台将支付流水的状态标识设置为已关闭，同时，商城服务器中该支付流水的状态标识也被设置为已关闭。处于已关闭的支付流水不可再继续进行支付，但商城服务器可以向支付平台发送流水激活请求，以激活已关闭的支付流水。支付平台对接收到流水激活请求后，将已关闭的支付流水开启，则由于当前该支付流水还未支付成功，则该支付流水的状态为未支付。同时，商城服务器中该支付水流的状态标识也被更新为未支付。

这样，针对同一个产品订单，商城服务器中对应一个支付平台只有一个支付流水，且同一时间最多只有一个支付平台的支付流水有效；同时，一个产品订单在一个支付平台上也只有一条支付流水，从而有利于商家与用户对账与排查问题。

下面以具体实施例对上述流程进行详细介绍。

实施例一提供了一种具体的实施过程，其系统架构包括商城客户端、商城服务器、第一支付客户端、第二支付客户端、第一支付平台和第二支付平台，实施例一中，商城服务器中已存有用户A的产品订单，且该产品订单已与第一支付流水数据相关联，第一支付流水对应于第一支付平台。该产品订单的下单方式参照图1所示的流程，这里不多赘述。实施例一的方法如图5所示，包括：

步骤501、商城客户端向用户显示多个支付方式，商城客户端基于用户选择的第二支付方式，向商城服务器发送支付接口获取请求，第二支付方式与第二支付平台相对应，支付接口获取请求中包含第二支付平台的标识。

步骤502、商城服务器查询商城数据库，获取产品订单的状态。

步骤503、产品订单是否为已支付状态，若是，执行步骤504；否则执行步骤505。

步骤504、商城服务器向商城客户端发送已支付响应。

步骤505、商城服务器判断该产品订单是否已与上一次支付流水相关联，上一次支付流水对应第一支付平台。若是，执行步骤509，否则执行步骤506。

步骤506、商城服务器生成第二支付流水号，并将第二支付平台、第二支付流水号与产品订单相关联，并添加到商城数据库中。

步骤507、商城服务器向第二支付平台发送支付请求，根据第二支付平台发送的响应确定第二支付平台的支付URL，并将第二支付平台的支付URL保存至商城数据库中。

步骤508、商城服务器向商城客户端发送第二支付平台的支付URL，以使商城客户端根据支付URL跳转到第二支付平台的支付页面。

步骤509、商城服务器根据第一支付流水，调用第一支付平台的查询接口，获取第一支付平台中第一支付流水的支付状态。

步骤510、商城服务器判断第一支付流水的支付状态是否为已支付，若是，则执行步骤511；否则执行步骤512。

步骤511、商城服务器更新商城数据库中第一支付流水的支付状态为已支付，然后执行步骤504。

步骤512、商城服务器判断第一支付平台与第二支付平台是否为同一支付平台，若是，则执行步骤513，否则执行步骤514。

步骤513、商城服务器从商城数据库中获取第一支付平台的支付URL，然后执行步骤508。

步骤514、商城服务器向第一支付平台发送支付关闭请求，若发送失败，则执行步骤515；若执行成功，执行步骤516。

步骤515、商城服务器向商城客户端发送支付关闭失败响应，引导用户用第一支付方式进行支付，或者重新下单。

步骤516、商城服务器查询商城数据库，判断产品订单是否与状态为已关闭的第二支付流水相关联，若是，执行步骤517，否则执行步骤506。

步骤517、商城服务器向第二支付平台发送流水激活请求，以激活第二支付平台中第二支付流水。

步骤518、商城服务器查询商城数据库，获取第二支付平台的支付URL，然后执行步骤508。

需要说明的是，上述实施例一中涉及的订单生成过程、第一支付平台的支付过程和第二支付平台的支付过程等具体后台流程并未详细介绍，本领域技术人员可以清楚地了解本申请实施例中相关的具体支付流程，本申请实施例中不再赘述。此外，本申请实施例中的支付流水数据、支付请求、支付关闭请求、流水激活请求等并不构成对整体支付过程的限定，仅为对产品支付的数据处理过程描述清楚，上述内容的表述也可以用其它名称替代。

实施例二涉及的数据处理系统可以是由客户端、多个节点(接入网络中的任意形式的计算设备，如服务器、用户终端)通过网络通信的形式连接形成的分布式系统。

以分布式系统为区块链系统为例，参见图6，图6是本发明实施例二提供的分布式系统100应用于区块链系统的一个可选的结构示意图，由多个节点(接入网络中的任意形式的计算设备，如服务器、用户终端)和客户端形成，节点之间形成组成的点对点(P2P，PeerTo Peer)网络，P2P协议是一个运行在传输控制协议(TCP，Transmission ControlProtocol)协议之上的应用层协议。在分布式系统中，任何机器如服务器、终端都可以加入而成为节点，节点包括硬件层、中间层、操作系统层和应用层。

参见图6示出的区块链系统中各节点的功能，涉及的功能包括：

1)路由，节点具有的基本功能，用于支持节点之间的通信。

节点除具有路由功能外，还可以具有以下功能：

2)应用，用于部署在区块链中，根据实际业务需求而实现特定业务，记录实现功能相关的数据形成记录数据，在记录数据中携带数字签名以表示任务数据的来源，将记录数据发送到区块链系统中的其他节点，供其他节点在验证记录数据来源以及完整性成功时，将记录数据添加到临时区块中。

本发明实施例二中，应用实现的业务包括：

2.1)钱包，用于提供进行电子货币的交易的功能，包括发起支付请求(即，将支付的交易记录发送给区块链系统中的其他节点)，其他节点验证成功后，作为承认交易有效的响应，将交易的记录数据存入区块链的临时区块中；当然，钱包还支持查询电子货币地址中剩余的电子货币；

2.2)共享账本，用于提供账目数据的存储、查询和修改等操作的功能，将对支付流水的操作的记录数据发送到区块链系统中的其他节点，其他节点验证有效后，作为承认对账文件中数据有效的响应，将记录数据存入临时区块中，还可以向发起操作的节点发送确认响应。

2.3)智能合约，计算机化的协议，可以执行某个合约的条款，通过部署在共享账本上的用于在满足一定条件时而执行的代码实现，根据实际的业务需求代码用于完成自动化的交易，例如查询产品订单的支付状态，在第二支付平台确认后将用户的资金转移到第二支付平台的支付地址；当然，智能合约不仅限于执行用于交易的合约，还可以执行对接收的信息进行处理的合约。

3)区块链，包括一系列按照产生的先后时间顺序相互接续的区块(Block)，新区块一旦加入到区块链中就不会再被移除，区块中记录了区块链系统中节点提交的记录数据。

参见图7，图7是本发明实施例提供的区块结构(Block Structure)一个可选的示意图，每个区块中包括本区块存储交易记录的哈希值(本区块的哈希值)、以及前一区块的哈希值，各区块通过哈希值连接形成区块链。另外，区块中还可以包括有区块生成时的时间戳等信息。区块链(Blockchain)，本质上是一个去中心化的数据库，是一串使用密码学方法相关联产生的数据块，每一个数据块中包含了相关的信息，用于验证其信息的有效性(防伪)和生成下一个区块。

下述为本申请装置实施例，对于装置实施例中未详尽描述的细节，可以参考上述一一对应的方法实施例。

请参考图8，其示出了本申请一个实施例提供的数据处理装置的结构方框图。该数据处理装置通过硬件或者软硬件的结合实现成为图2中商城服务器202的全部或者一部分。该装置包括：收发单元801、确定单元802、处理单元803；

收发单元801，用于接收终端发送的产品订单的支付请求，所述支付请求中包含第二支付平台的标识；

确定单元802，用于确定所述产品订单与第一支付流水数据相关联，所述第一支付流水数据中包含第一支付平台的标识；

所述确定单元802，还用于根据所述第一支付流水数据确定所述产品订单的支付状态为未成功；

所述收发单元801，还用于向所述第一支付平台发送支付关闭请求，并接收所述第一支付平台反馈的支付已关闭响应；

处理单元803，用于获取所述第二支付平台的支付地址；

所述收发单元801，还用于向所述终端发送所述第二支付平台的支付地址。

可选的，所述确定单元802，还用于：

确定所述产品订单的支付状态为成功支付时，向所述终端发送订单已支付响应。

可选的，所述产品订单不存在相关联的支付流水数据时，所述处理单元803，用于生成所述产品订单的第二支付流水数据并与所述产品订单相关联，所述第二支付流水数据中包括所述第二支付平台的标识；

所述收发单元801，还用于向所述第二支付平台发送所述产品订单的支付请求；接收所述第二支付平台发送的支付响应，所述支付响应中包含所述第二支付平台的支付地址。

可选的，所述确定单元802，还用于确定所述产品订单与已关闭的第二支付流水数据相关联，所述第二支付流水数据中包含所述第二支付平台的标识；

所述收发单元801，还用于向所述第二支付平台发送流水激活请求，所述流水激活请求中包含所述第二支付流水数据。

可选的，所述收发单元801，还用于接收所述终端发送的产品下单请求；

所述处理单元803，还用于生成并存储所述产品订单。

可选的，所述收发单元801，还用于：

根据所述第一支付流水数据向所述第一支付平台发送所述产品订单的支付查询请求；

接收所述第一支付平台发送的支付查询响应，所述支付查询响应中包含所述产品订单的支付状态。

可选的，所述第二支付平台的支付地址为所述第二支付平台的支付URL；

所述收发单元801，还用于：

接收所述第二支付平台发送的所述产品订单的支付结果；所述支付结果为所述终端利用所述第二支付平台的支付URL进行支付的结果。

请参考图9，其示出了本申请一个实施例提供的服务器的结构方框图。该服务器1000实现为图2中的商城服务器202。具体来讲：

服务器1000包括中央处理单元(CPU)1001、包括随机存取存储器(RAM)1002和只读存储器(ROM)1003的系统存储器1004，以及连接系统存储器1004和中央处理单元1001的系统总线1005。所述服务器1000还包括帮助计算机内的各个器件之间传输信息的基本输入/输出系统(I/O系统)1006，和用于存储操作系统1013、应用程序1014和其他程序模块1015的大容量存储设备1007。

所述基本输入/输出系统1006包括有用于显示信息的显示器1008和用于用户输入信息的诸如鼠标、键盘之类的输入设备1009。其中所述显示器1008和输入设备1009都通过连接到系统总线1005的输入输出控制器1010连接到中央处理单元1001。所述基本输入/输出系统1006还可以包括输入输出控制器1010以用于接收和处理来自键盘、鼠标、或电子触控笔等多个其他设备的输入。类似地，输入输出控制器1010还提供输出到显示屏、打印机或其他类型的输出设备。

所述大容量存储设备1007通过连接到系统总线1005的大容量存储控制器(未示出)连接到中央处理单元1001。所述大容量存储设备1007及其相关联的计算机可读介质为服务器1000提供非易失性存储。也就是说，所述大容量存储设备1007可以包括诸如硬盘或者CD-ROM驱动器之类的计算机可读介质(未示出)。

所述计算机可读介质可以包括计算机存储介质和通信介质。计算机存储介质包括以用于存储诸如计算机可读指令、数据结构、程序模块或其他数据等信息的任何方法或技术实现的易失性和非易失性、可移动和不可移动介质。计算机存储介质包括RAM、ROM、EPROM、EEPROM、闪存或其他固态存储其技术，CD-ROM、DVD或其他光学存储、磁带盒、磁带、磁盘存储或其他磁性存储设备。当然，本领域技术人员可知所述计算机存储介质不局限于上述几种。上述的系统存储器1004和大容量存储设备1007可以统称为存储器。

根据本发明的各种实施例，所述服务器1000还可以通过诸如因特网等网络连接到网络上的远程计算机运行。也即服务器1000可以通过连接在所述系统总线1005上的网络接口单元1011连接到网络1012，或者说，也可以使用网络接口单元1011来连接到其他类型的网络或远程计算机系统(未示出)。

所述存储器还包括一个或者一个以上的程序，所述一个或者一个以上程序存储于存储器中，所述一个或者一个以上程序包含用于进行本发明实施例提供的数据处理方法的指令。

本领域普通技术人员可以理解上述实施例的签到方法中的全部或部分步骤是可以通过程序来指令相关的硬件来完成，该程序可以存储于一计算机可读存储介质中，存储介质可以包括：只读存储器(ROM，Read Only Memory)、随机存取记忆体(RAM，RandomAccess Memory)、磁盘或光盘等。

本领域普通技术人员可以理解上述实施例的签到方法中的全部或部分步骤是可以通过程序来指令相关的硬件来完成，该程序可以存储于计算机可读存储介质中，存储介质可以包括：只读存储器(ROM，Read Only Memory)、随机存取记忆体(RAM，Random AccessMemory)、磁盘或光盘等。

上述本申请实施例序号仅仅为了描述，不代表实施例的优劣。

以上所述仅为本申请的较佳实施例，并不用以限制本申请，凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

Claims (10)

1.一种数据处理方法，其特征在于，所述方法包括：

接收终端发送的产品订单的支付请求，所述支付请求中包含第二支付平台的标识；

确定所述产品订单与第一支付流水数据相关联，所述第一支付流水数据中包含第一支付平台的标识；

根据所述第一支付流水数据确定所述产品订单的支付状态为未成功，则向所述第一支付平台发送支付关闭请求，并接收所述第一支付平台反馈的支付已关闭响应；

获取所述第二支付平台的支付地址，并向所述终端发送所述第二支付平台的支付地址。

2.根据权利要求1所述的方法，其特征在于，所述接收终端发送的产品订单的支付请求之后，还包括：

确定所述产品订单的支付状态为成功支付时，向所述终端发送订单已支付响应。

3.根据权利要求2所述的方法，其特征在于，所述产品订单不存在相关联的支付流水数据时，所述获取所述第二支付平台的支付地址，包括：

生成所述产品订单的第二支付流水数据并与所述产品订单相关联，所述第二支付流水数据中包括所述第二支付平台的标识；

向所述第二支付平台发送所述产品订单的支付请求；

接收所述第二支付平台发送的支付响应，所述支付响应中包含所述第二支付平台的支付地址。

4.根据权利要求3所述的方法，其特征在于，所述接收所述第一支付平台反馈的支付已关闭响应之后，所述获取所述第二支付平台的支付地址之前，还包括：

确定所述产品订单与已关闭的第二支付流水数据相关联，所述第二支付流水数据中包含所述第二支付平台的标识；

向所述第二支付平台发送流水激活请求，所述流水激活请求中包含所述第二支付流水数据。

5.根据权利要求1至4任一项所述的方法，其特征在于，所述接收终端发送的产品订单的支付请求之前，包括：

接收所述终端发送的产品下单请求；

生成并存储所述产品订单。

6.根据权利要求1至4任一项所述的方法，其特征在于，所述根据所述第一支付流水数据确定所述产品订单的支付状态为未成功，包括：

根据所述第一支付流水数据向所述第一支付平台发送所述产品订单的支付查询请求；

接收所述第一支付平台发送的支付查询响应，所述支付查询响应中包含所述产品订单的支付状态。

7.根据权利要求1至4任一项所述的方法，其特征在于，所述第二支付平台的支付地址为所述第二支付平台的支付URL(统一资源定位符)；

所述向所述终端发送所述第二支付平台的支付地址之后，还包括：

接收所述第二支付平台发送的所述产品订单的支付结果；所述支付结果为所述终端利用所述第二支付平台的支付URL进行支付的结果。

8.一种数据处理装置，其特征在于，所述装置包括：

收发单元，用于接收终端发送的产品订单的支付请求，所述支付请求中包含第二支付平台的标识；

确定单元，用于确定所述产品订单与第一支付流水数据相关联，所述第一支付流水数据中包含第一支付平台的标识；

所述确定单元，还用于根据所述第一支付流水数据确定所述产品订单的支付状态为未成功；

所述收发单元，还用于向所述第一支付平台发送支付关闭请求，并接收所述第一支付平台反馈的支付已关闭响应；

处理单元，用于获取所述第二支付平台的支付地址；

所述收发单元，还用于向所述终端发送所述第二支付平台的支付地址。

9.一种计算设备，其特征在于，包括至少一个处理器、以及至少一个存储器，其中，所述存储器存储有计算机程序，当所述程序被所述处理器执行时，使得所述处理器执行权利要求1至7任一项所述的数据处理方法。

10.一种存储介质，所述存储介质存储有计算机指令，其特征在于，当所述计算机指令在计算机上运行时，使得计算机执行权利要求1至7任一项所述的数据处理方法。

Images