CN115730938A - 基于订单状态幂等控制的防重复支付方法及装置 - Google Patents

Abstract

本发明涉及数据处理技术领域，公开了一种基于订单状态幂等控制的防重复支付方法及装置，包括：接收订单的订单状态；在订单状态符合预设订单状态时，接收订单的支付请求；修改订单状态，并根据支付请求支付订单；在订单支付失败时，对订单的变更操作进行回滚还原，再次发起所述支付请求。在金融科技的电子交易场景中，本申请能够在同一笔订单支付失败之后重新发起支付请求，避免了用户对相同消费重复下单的问题，避免后台出现过多的冗余数据问题；再此前提之下，严格控制了重复支付场景，避免出现资金损耗问题；这种交易订单与支付订单一对多的设计方式，满足了用户支付失败后重新支付的需求，满足了多次支付之间的数据隔离，使之相互之间无影响。

Description

基于订单状态幂等控制的防重复支付方法及装置

技术领域

本发明涉及数据处理技术领域，尤其涉及一种基于订单状态幂等控制的防重复支付方法及装置。

背景技术

随着电子交易(electronic transaction)的普及和经济的发展，越来越多的用户通过移动终端进行线上购物，线上购物已经成为一种重要的购物形式。

金融科技场景中的线上消费，一般流程可以包含下单和支付，在下单和支付的过程中常常由于各种原因出现交易失败的问题。在现有技术中，在本次交易失败时，一般会将本次交易操作作废处理，即：将下单与支付生成的相关数据全部以失败和作废处理，这种处理方式导致了用户只能重新下单进行支付的问题。

发明内容

本发明提供一种基于订单状态幂等控制的防重复支付方法及装置，以解决现有技术中，在本次交易失败时，将本次交易操作作废处理，用户重新下单进行支付的技术问题。

第一方面，提供了一种基于订单状态幂等控制的防重复支付方法，包括以下步骤：

接收订单的订单状态；

在所述订单状态符合预设订单状态时，接收所述订单的支付请求；

修改所述订单状态，并根据所述支付请求支付所述订单；

在所述订单支付失败时，对所述订单的变更操作进行回滚还原，并再次发起所述支付请求。

第二方面，提供了一种基于订单状态幂等控制的防重复支付装置，包括：

订单状态接收模块，用于接收订单的订单状态；

支付请求接收模块，用于在所述订单状态符合预设订单状态时，接收所述订单的支付请求；

支付模块，用于修改所述订单状态，并根据所述支付请求支付所述订单；

再次支付模块，用于在所述订单支付失败时，对所述订单的变更操作进行回滚还原，并再次发起所述支付请求。

第三方面，提供了一种计算机设备，包括存储器、处理器以及存储在存储器中并可在处理器上运行的计算机程序，处理器执行计算机程序时实现上述基于订单状态幂等控制的防重复支付方法的步骤。

第四方面，提供了一种计算机可读存储介质，计算机可读存储介质存储有计算机程序，计算机程序被处理器执行时实现上述基于订单状态幂等控制的防重复支付方法的步骤。

上述基于订单状态幂等控制的防重复支付方法、装置、计算机设备及存储介质所实现的方案中，首先接收订单的订单状态，然后在所述订单状态符合预设订单状态时，接收所述订单的支付请求，其次修改所述订单状态，并根据所述支付请求支付所述订单，最后在所述订单支付失败时，对所述订单的变更操作进行回滚还原，并再次发起所述支付请求。在本发明中，针对现有技术中在本次交易失败时，将本次交易操作作废处理，需要用户重新下单进行支付的技术问题。先接收符合预设订单状态的订单的支付请求，再修改订单状态，从而能够在根据支付请求支付订单失败时，对订单的变更操作进行回滚还原，并再次发起支付请求。能够在同一笔订单支付失败之后重新发起支付请求，避免了用户对相同消费重复下单的问题，避免后台出现过多的冗余数据问题；再此前提之下，严格控制了重复支付场景，避免出现资金损耗问题；这种交易订单与支付订单一对多的设计方式，不仅满足了用户支付失败后重新支付的需求，又满足了多次支付之间的数据隔离，使之相互之间无影响。

上述基于订单状态幂等控制的防重复支付方法、装置、计算机设备及存储介质所实现的方案中，首先接收订单的订单状态，然后在所述订单状态符合预设订单状态时，接收所述订单的支付请求；在对所述订单的支付请求进行校验之后，将所述订单状态修改为支付进行中，若所述订单状态修改失败，则对所述支付请求进行拦截，终止支付所述订单，若所述订单状态修改成功，则根据所述支付请求支付所述订单；最后在所述订单支付失败时，对所述订单的变更操作进行回滚还原，并再次发起所述支付请求。本申请在订单状态符合预设订单状态的订单的支付请求校验通过之后，将订单状态修改为支付进行中，从而在订单状态修改失败时，对所述支付请求进行；本申请将幂等控制节点放在了数据校验之后，在支付流程中的节点靠前，能够更早的对多余的支付请求进行拦截，避免了系统后续的不必要消耗，提高了数据的完整性和安全性。

附图说明

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

图1是本发明一实施例基于订单状态幂等控制的防重复支付方法的一应用环境示意图；

图2是本发明一实施例中基于订单状态幂等控制的防重复支付方法的一流程示意图；

图3是本发明一实施例中基于订单状态幂等控制的防重复支付方法的总体流程示意图；

图4是本发明一实施例中基于订单状态幂等控制的防重复支付装置的一结构示意图；

图5是本发明一实施例中计算机设备的一结构示意图；

图6是本发明一实施例中计算机设备的另一结构示意图。

具体实施方式

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

本发明实施例提供的基于订单状态幂等控制的防重复支付方法，可应用在如图1的应用环境中，其中，客户端通过网络与服务端进行通信。服务端可以通过客户端接收订单的订单状态，并在所述订单状态符合预设订单状态时，接收所述订单的支付请求，修改所述订单状态根据所述支付请求支付所述订单，最后在所述订单支付失败时，对所述订单的变更操作进行回滚还原，通过客户端再次发起所述支付请求。在本发明中，针对现有技术中在本次交易失败时，将本次交易操作作废处理，需要用户重新下单进行支付的技术问题。先接收符合预设订单状态的订单的支付请求，再修改订单状态，从而能够在根据支付请求支付订单失败时，对订单的变更操作进行回滚还原，并再次发起支付请求。能够在同一笔订单支付失败之后重新发起支付请求，避免了用户对相同消费重复下单的问题，避免后台出现过多的冗余数据问题；再此前提之下，严格控制了重复支付场景，避免出现资金损耗问题；这种交易订单与支付订单一对多的设计方式，不仅满足了用户支付失败后重新支付的需求，又满足了多次支付之间的数据隔离，使之相互之间无影响。

更具体地，服务端通过客户端接收订单的订单状态，然后在所述订单状态符合预设订单状态时，接收所述订单的支付请求；在对所述订单的支付请求进行校验之后，将所述订单状态修改为支付进行中，若所述订单状态修改失败，则对所述支付请求进行拦截，终止支付所述订单，若所述订单状态修改成功，则根据所述支付请求支付所述订单；最后在所述订单支付失败时，对所述订单的变更操作进行回滚还原，通过客户端再次发起所述支付请求。本申请在订单状态符合预设订单状态的订单的支付请求校验通过之后，将订单状态修改为支付进行中，从而在订单状态修改失败时，对所述支付请求进行；本申请将幂等控制节点放在了数据校验之后，在支付流程中的节点靠前，能够更早的对多余的支付请求进行拦截，避免了系统后续的不必要消耗，提高了数据的完整性和安全性。

其中，客户端可以但不限于各种个人计算机、笔记本电脑、智能手机、平板电脑和便携式可穿戴设备。服务端可以用独立的服务器或者是多个服务器组成的服务器集群来实现。下面通过具体的实施例对本发明进行详细的描述。

请参阅图2和图3所示，图2和图3为本发明实施例提供的基于订单状态幂等控制的防重复支付方法的流程示意图，包括如下步骤：

本申请实施例适用于金融科技的电子交易场景中各个业务领域的支付过程。

在本申请实施例中，同一笔订单允许发起多次支付请求，即在一次支付失败后，用户可再次对该笔订单发起支付请求进行支付，以解决订单支付失败时的重复下单操作，提升用户操作体验。

基于这种处理机制，单笔订单在支付过程中可能会存在两次或多次支付请求的同时发起，或者一次支付请求还未处理完成又接收到相同支付请求的情况，造成重复支付的问题。本申请实施例能够对同一笔订单的重复支付请求进行拦截处理，并通过对订单的不同阶段设置不同的状态码值，允许每一阶段的状态码值只能做指定的变更操作(状态修改幂等控制)，从而实现一笔订单只能进行一次成功支付的设计初衷。

S100，接收订单的订单状态。

在本申请实施例中，用户可以通过移动终端的购物软件向服务器发送下单请求，服务器在接受到用户的下单请求之后，生成本次交易支付的订单，并设置本次订单的订单状态。移动终端可以为手机、平板、电脑等。

值得注意的是，这里的订单状态可以是指成功提交的订单的支付状态，一般可分为三种，一种是订单未支付的状态，所述订单状态为交易进行中，另一种是订单支付中的状态，所述订单状态为支付进行中，还有一种是订单支付完成的状态，所述订单状态为支付成功。在本申请实施例中，可以通过对所述订单设置状态码值的方式，来表示所述订单的订单状态，比如，设置所述订单的状态码值为00，表示所述订单的订单状态为交易进行中，设置所述订单的状态码值为03，表示所述订单的订单状态为支付进行中，设置所述订单的状态码值为33，表示所述订单的订单状态为支付成功。

一般情况下，可以将订单初始的订单状态设置为交易进行中。

在本申请实施例中，用户可以通过移动终端发起订单的支付请求。比如，在实际应用中，用户可以根据在购物软件上显示的订单，点击“支付”按钮，即可向第三方支付渠道商发起所述订单的支付请求；所述第三方支付渠道商可以为各个银行以及金融机构。

此外，商家也可以发起所述订单的支付请求。

S200,在所述订单状态符合预设订单状态时，接收所述订单的支付请求。

在S200中，也即在所述订单状态符合预设订单状态时，接收所述订单的支付请求，包括：

在所述订单状态符合交易进行中时，接收所述订单的支付请求；将所述交易进行中作为所述预设订单状态。即为移动终端只有在订单的订单状态为交易进行中时，才能进行订单的支付，第三方支付渠道商才会接收所述订单的支付请求；对应的，在订单的订单状态非交易进行中时，移动终端无法进行订单的支付，第三方支付渠道商也无需接收所述订单的支付请求。

可以理解为，只有在订单状态为初始的订单状态时，第三方支付渠道商才会接收所述订单的支付请求。

在本申请实施例中，在所述接收所述订单的支付请求之后，包括：

对所述订单的支付请求进行校验。

在本申请实施例中，通过第三方支付渠道商服务器对订单的支付请求进行校验，就是通过一般接口设计的相同逻辑，对支付请求中的必须字段是否完整和字段规则是否正确等进行的校验，用于确定支付请求是否存在异常，属于前置校验。

值得注意的是，这里的支付请求中包含有订单交易支付的相关必要信息，所述相关必要信息可以为用户、商家、交易订单号、交易支付方式和交易支付金额等，所述交易订单号属于订单的标识信息，所述交易支付方式可以为微信、支付宝或银行卡等。

S300,所述支付请求校验通过之后，可以修改所述订单状态，并根据所述支付请求支付所述订单。

在S300中，也即所述修改所述订单状态，并根据所述支付请求支付所述订单，包括：

将所述订单状态修改为支付进行中。

若所述订单状态修改失败，则对所述支付请求进行拦截，终止支付所述订单。

在本申请实施例中，存在两种情况会导致订单状态修改失败：

1)在订单状态为支付进行中时，表示在本次支付之前已经存在一次支付请求将所述订单状态修改为支付进行中，本次订单状态无法修改为支付进行中，本次订单支付终止。此时，为防止重复支付，需将本次的支付请求拦截，并以失败处理所述支付请求。此时，用户可返回至上次支付请求所产生的页面对所述订单进行支付，从而实现一笔订单只能存在一次支付成功的设计初衷。

2)在订单支付过程中存在网络问题或系统异常等，则会导致所述订单状态无法修改为支付进行中，订单支付终止。

在一种可能的实施方式中，在订单支付过程中存在网络问题或系统异常等导致所述订单状态修改失败，造成订单支付终止时，用户可以通过移动终端再次向所述第三方支付渠道商发送支付请求，从而由第三方支付渠道商在确定出所述订单状态符合预设订单状态时，接收所述订单的支付请求；修改订单状态，并根据所述支付请求支付所述订单；在所述订单支付失败时，对订单的变更操作进行回滚还原，并再次通过移动终端发起所述支付请求。

若所述订单状态修改成功，则根据所述支付请求支付所述订单。

在本申请实施例中，只有在订单状态为交易进行中时，所述订单状态才能修改成功。举例说明，当状态码值00表示所述订单的订单状态为交易进行中，状态码值03表示所述订单的订单状态为支付进行中时，数据库中的状态码值必须是00，才能将所述状态码值修改为目标码值03，此为幂等控制的核心。

在本申请实施例中，幂等控制即为幂等性控制。关于幂等性的解释，可以抄用一段数学上的定义f(f(x))＝f(x)表示，意为x被函数f作用一次和作用无限次的结果是一样的，将幂等性应用在软件系统中，可简单定义为：某个函数或者某个接口使用相同参数调用一次或者无限次，其造成的后果是一样的。将幂等控制应用于本申请，能够使得本申请实施例的系统在接收支付请求时，即使是相同的请求参数，无论调用方发起多少次重复的支付请求，最终也只有一次支付请求产生作用，且能够对于重复的支付请求不作处理或作为异常处理。

在现有技术中，多数系统的幂等控制会做在本数据库层，在修改数据库数据时对状态码值进行校验，略显滞后。由上述内容可知，本申请实施例将幂等控制节点放在了数据校验之后，在订单支付流程中的节点靠前，能够更早的对多余的支付请求进行拦截，避免了系统后续的不必要消耗，提高了数据的完整性和安全性。

在S300中，所述根据所述支付请求支付所述订单，包括：

根据支付单和支付明细支付所述订单；所述支付请求包含有所述支付单和所述支付明细。

在本申请实施例中，在订单状态修改为支付进行中后，可通过移动终端显示支付请求包含的支付单和支付明细，所述支付单中表明有交易订单号，所述支付明细中记录有用户、商家、交易支付方式和交易支付金额。用户可以选择交易支付方式提交订单，订单提交成功之后，所述移动终端显示支付页面，用户即可通过所述支付页面向第三方支付渠道商支付所述交易支付金额，从而可以通过第三方支付渠道商将所述交易支付金额支付给商家。

S400,在所述订单支付失败时，对所述订单的变更操作进行回滚还原，并再次发起所述支付请求。

在本申请实施例中，在支付所述订单的交易支付金额时，若存在网络问题、系统异常或支付工具异常等，则会导致第三方支付渠道商扣款失败，所述订单支付失败。

需要说明的是，对所述订单的变更操作进行回滚还原可以为将订单的订单状态修改为本次支付请求之前初始的订单状态。举例说明，在订单支付失败时，所述订单状态仍为支付进行中，此时，需将订单状态修改为交易进行中，即将状态码值03更改为初始状态码值00。

具体地说，在订单支付失败时，所述订单的订单状态仍为支付进行中，此时，若根据再次发起的支付请求支付所述订单，则会导致订单的订单状态修改失败，再次发起的支付请求会被拦截，从而无法通过再次发起的支付请求对订单进行支付。所以，需要将本次支付失败订单的订单状态修改至本次支付之前的初始的订单状态，这样才能够便于根据再次发起的支付请求对初始的订单状态进行修改，从而能够根据再次发起的支付请求对所述订单进行支付。

在本申请实施例中，同一笔订单在支付失败之后允许重新发起支付请求，不仅可以避免用户对相同消费重复下单，而且能够避免后台出现过多的冗余数据。在此前提之下，又严格控制了重复支付场景，避免出现资金损耗和其它问题。

在S400中，也即在所述对所述订单的变更操作进行回滚还原之前，包括：

对所述支付请求进行失败处理，将所述支付请求中的支付单和支付明细均标记为失败。

从上述方案可以看出，本申请实施例在同一笔订单支付失败之后，能够将所述支付请求进行失败处理，并对所述订单的变更操作进行回滚还原，重新发起所述支付请求对所述订单进行支付，这样交易订单和支付订单一对多的设计方式，使得本申请实施例不仅能够满足用户对所述订单支付失败之后重新支付的需求，又满足了多次支付之间的数据隔离，使之相互之间无影响。

在本申请实施例中，所述的基于订单状态幂等控制的防重复支付方法还包括：

所述订单支付成功，本次交易完成。在本申请实施例中，订单支付成功，则表示第三方支付渠道商扣款成功，可通过第三方支付渠道商将所述交易支付金额支付给商家。此时，所述订单的订单状态为交易成功。

在本申请实施例中，所述基于订单状态幂等控制的防重复支付方法，首先接收订单的订单状态，然后在所述订单状态符合预设订单状态时，接收所述订单的支付请求，其次修改所述订单状态，并根据所述支付请求支付所述订单，最后在所述订单支付失败时，对所述订单的变更操作进行回滚还原，并再次发起所述支付请求。在本发明中，针对现有技术中在本次交易失败时，将本次交易操作作废处理，需要用户重新下单进行支付的技术问题。先接收符合预设订单状态的订单的支付请求，再修改订单状态，从而能够在根据支付请求支付订单失败时，对订单的变更操作进行回滚还原，并再次发起支付请求。能够在同一笔订单支付失败之后重新发起支付请求，避免了用户对相同消费重复下单的问题，避免后台出现过多的冗余数据问题；再此前提之下，严格控制了重复支付场景，避免出现资金损耗问题；这种交易订单与支付订单一对多的设计方式，不仅满足了用户支付失败后重新支付的需求，又满足了多次支付之间的数据隔离，使之相互之间无影响。

应理解，上述实施例中各步骤的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本发明实施例的实施过程构成任何限定。

在一实施例中，提供一种基于订单状态幂等控制的防重复支付装置，该装置与上述实施例中基于订单状态幂等控制的防重复支付方法一一对应。如图4所示，该防重复支付装置包括订单状态接收模块10、支付请求接收模块20、支付模块30和再次支付模块40。各功能模块详细说明如下：

订单状态接收模块10，用于接收订单的订单状态；

支付请求接收模块20，用于在所述订单状态符合预设订单状态时，接收所述订单的支付请求；

支付模块30，用于修改所述订单状态，并根据所述支付请求支付所述订单；

再次支付模块40，用于在所述订单支付失败时，对所述订单的变更操作进行回滚还原，并再次发起所述支付请求。

在一实施例中，支付请求接收模块20，具体用于：

在所述订单状态符合交易进行中时，接收所述订单的支付请求；

将所述交易进行中作为所述预设订单状态。

在一实施例中，在支付请求接收模块20之后，具体用于：

对所述订单的支付请求进行校验。

在一实施例中，支付模块30，具体用于：

将所述订单状态修改为支付进行中；

若所述订单状态修改失败，则对所述支付请求进行拦截，终止支付所述订单；

若所述订单状态修改成功，则根据所述支付请求支付所述订单。

在一实施例中，支付模块30，具体用于：

根据支付单和支付明细支付所述订单；

所述支付请求包含有所述支付单和所述支付明细。

在一实施例中，再次支付模块40，在所述对所述订单的变更操作进行回滚还原之前，具体用于：

对所述支付请求进行失败处理。

在一实施例中，再次支付模块40，具体用于：

所述订单支付成功，本次交易完成。

在本申请实施例中，首先接收订单的订单状态，然后在所述订单状态符合预设订单状态时，接收所述订单的支付请求；在对所述订单的支付请求进行校验之后，将所述订单状态修改为支付进行中，若所述订单状态修改失败，则对所述支付请求进行拦截，终止支付所述订单，若所述订单状态修改成功，则根据所述支付请求支付所述订单；最后在所述订单支付失败时，对所述订单的变更操作进行回滚还原，并再次发起所述支付请求。本申请在订单状态符合预设订单状态的订单的支付请求校验通过之后，将订单状态修改为支付进行中，从而在订单状态修改失败时，对所述支付请求进行；本申请将幂等控制节点放在了数据校验之后，在支付流程中的节点靠前，能够更早的对多余的支付请求进行拦截，避免了系统后续的不必要消耗，提高了数据的完整性和安全性。

本发明提供了一种基于订单状态幂等控制的防重复支付装置，首先接收订单的订单状态，然后在所述订单状态符合预设订单状态时，接收所述订单的支付请求，其次修改所述订单状态，并根据所述支付请求支付所述订单，最后在所述订单支付失败时，对所述订单的变更操作进行回滚还原，并再次发起所述支付请求。在本发明中，针对现有技术中在本次交易失败时，将本次交易操作作废处理，需要用户重新下单进行支付的技术问题。先接收符合预设订单状态的订单的支付请求，再修改订单状态，从而能够在根据支付请求支付订单失败时，对订单的变更操作进行回滚还原，并再次发起支付请求。能够在同一笔订单支付失败之后重新发起支付请求，避免了用户对相同消费重复下单的问题，避免后台出现过多的冗余数据问题；再此前提之下，严格控制了重复支付场景，避免出现资金损耗问题；这种交易订单与支付订单一对多的设计方式，不仅满足了用户支付失败后重新支付的需求，又满足了多次支付之间的数据隔离，使之相互之间无影响。

关于基于订单状态幂等控制的防重复支付装置的具体限定可以参见上文中对于基于订单状态幂等控制的防重复支付方法的限定，在此不再赘述。上述基于订单状态幂等控制的防重复支付装置中的各个模块可全部或部分通过软件、硬件及其组合来实现。上述各模块可以硬件形式内嵌于或独立于计算机设备中的处理器中，也可以以软件形式存储于计算机设备中的存储器中，以便于处理器调用执行以上各个模块对应的操作。

在一个实施例中，提供了一种计算机设备，该计算机设备可以是服务端，其内部结构图可以如图5所示。该计算机设备包括通过系统总线连接的处理器、存储器、网络接口和数据库。其中，该计算机设备的处理器用于提供计算和控制能力。该计算机设备的存储器包括非易失性和/或易失性存储介质、内存储器。该非易失性存储介质存储有操作系统、计算机程序和数据库。该内存储器为非易失性存储介质中的操作系统和计算机程序的运行提供环境。该计算机设备的网络接口用于与外部的客户端通过网络连接通信。该计算机程序被处理器执行时以实现基于订单状态幂等控制的防重复支付方法服务端侧的功能或步骤。

在一个实施例中，提供了一种计算机设备，该计算机设备可以是客户端，其内部结构图可以如图6所示。该计算机设备包括通过系统总线连接的处理器、存储器、网络接口、显示屏和输入装置。其中，该计算机设备的处理器用于提供计算和控制能力。该计算机设备的存储器包括非易失性存储介质、内存储器。该非易失性存储介质存储有操作系统和计算机程序。该内存储器为非易失性存储介质中的操作系统和计算机程序的运行提供环境。该计算机设备的网络接口用于与外部服务器通过网络连接通信。该计算机程序被处理器执行时以实现一种基于订单状态幂等控制的防重复支付方法客户端侧的功能或步骤

在一个实施例中，提供了一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，处理器执行计算机程序时实现以下步骤：

接收订单的订单状态；

在所述订单状态符合预设订单状态时，接收所述订单的支付请求；

修改所述订单状态，并根据所述支付请求支付所述订单；

在所述订单支付失败时，对所述订单的变更操作进行回滚还原，并再次发起所述支付请求。

在一个实施例中，提供了一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器执行时实现以下步骤：

接收订单的订单状态；

在所述订单状态符合预设订单状态时，接收所述订单的支付请求；

修改所述订单状态，并根据所述支付请求支付所述订单；

在所述订单支付失败时，对所述订单的变更操作进行回滚还原，并再次发起所述支付请求。

需要说明的是，上述关于计算机可读存储介质或计算机设备所能实现的功能或步骤，可对应参阅前述方法实施例中，服务端侧以及客户端侧的相关描述，为避免重复，这里不再一一描述。

在上述计算机设备及计算机可读存储介质所实现的方案中，首先接收订单的订单状态，然后在所述订单状态符合预设订单状态时，接收所述订单的支付请求，其次修改所述订单状态，并根据所述支付请求支付所述订单，最后在所述订单支付失败时，对所述订单的变更操作进行回滚还原，并再次发起所述支付请求。在本发明中，针对现有技术中在本次交易失败时，将本次交易操作作废处理，需要用户重新下单进行支付的技术问题。先接收符合预设订单状态的订单的支付请求，再修改订单状态，从而能够在根据支付请求支付订单失败时，对订单的变更操作进行回滚还原，并再次发起支付请求。能够在同一笔订单支付失败之后重新发起支付请求，避免了用户对相同消费重复下单的问题，避免后台出现过多的冗余数据问题；再此前提之下，严格控制了重复支付场景，避免出现资金损耗问题；这种交易订单与支付订单一对多的设计方式，不仅满足了用户支付失败后重新支付的需求，又满足了多次支付之间的数据隔离，使之相互之间无影响。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一非易失性计算机可读取存储介质中，该计算机程序在执行时，可包括如上述各方法的实施例的流程。其中，本申请所提供的各实施例中所使用的对存储器、存储、数据库或其它介质的任何引用，均可包括非易失性和/或易失性存储器。非易失性存储器可包括只读存储器(ROM)、可编程ROM(PROM)、电可编程ROM(EPROM)、电可擦除可编程ROM(EEPROM)或闪存。易失性存储器可包括随机存取存储器(RAM)或者外部高速缓冲存储器。作为说明而非局限，RAM以多种形式可得，诸如静态RAM(SRAM)、动态RAM(DRAM)、同步DRAM(SDRAM)、双数据率SDRAM(DDRSDRAM)、增强型SDRAM(ESDRAM)、同步链路(Synchlink)DRAM(SLDRAM)、存储器总线(Rambus)直接RAM(RDRAM)、直接存储器总线动态RAM(DRDRAM)、以及存储器总线动态RAM(RDRAM)等。

所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，仅以上述各功能单元、模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能单元、模块完成，即将所述装置的内部结构划分成不同的功能单元或模块，以完成以上描述的全部或者部分功能。

以上所述实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围，均应包含在本发明的保护范围之内。

Claims (10)

1.一种基于订单状态幂等控制的防重复支付方法，其特征在于，包括以下步骤：

接收订单的订单状态；

在所述订单状态符合预设订单状态时，接收所述订单的支付请求；

修改所述订单状态，并根据所述支付请求支付所述订单；

在所述订单支付失败时，对所述订单的变更操作进行回滚还原，并再次发起所述支付请求。

2.根据权利要求1所述的防重复支付方法，其特征在于，在所述订单状态符合预设订单状态时，接收所述订单的支付请求，包括：

在所述订单状态符合交易进行中时，接收所述订单的支付请求；

将所述交易进行中作为所述预设订单状态。

3.根据权利要求1所述的防重复支付方法，其特征在于，在所述接收所述订单的支付请求之后，包括：

对所述订单的支付请求进行校验。

4.根据权利要求1所述的防重复支付方法，其特征在于，所述修改所述订单状态，并根据所述支付请求支付所述订单，包括：

将所述订单状态修改为支付进行中；

若所述订单状态修改失败，则对所述支付请求进行拦截，终止支付所述订单；

若所述订单状态修改成功，则根据所述支付请求支付所述订单。

5.根据权利要求1所述的防重复支付方法，其特征在于，所述根据所述支付请求支付所述订单，包括：

根据支付单和支付明细支付所述订单；

所述支付请求包含有所述支付单和所述支付明细。

6.根据权利要求1所述的防重复支付方法，其特征在于，在所述对所述订单的变更操作进行回滚还原之前，包括：

对所述支付请求进行失败处理。

7.根据权利要求1所述的防重复支付方法，其特征在于，还包括：

所述订单支付成功，本次交易完成。

8.一种基于订单状态幂等控制的防重复支付装置，其特征在于，包括：

订单状态接收模块，用于接收订单的订单状态；

支付请求接收模块，用于在所述订单状态符合预设订单状态时，接收所述订单的支付请求；

支付模块，用于修改所述订单状态，并根据所述支付请求支付所述订单；

再次支付模块，用于在所述订单支付失败时，对所述订单的变更操作进行回滚还原，并再次发起所述支付请求。

9.一种计算机设备，包括存储器、处理器以及存储在所述存储器中并可在所述处理器上运行的计算机程序，其特征在于，所述处理器执行所述计算机程序时实现如权利要求1至7任一项所述防重复支付方法的步骤。

10.一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现如权利要求1至7任一项所述防重复支付方法的步骤。

Images