CN115271694A - 订单支付方法及系统 - Google Patents

Abstract

本公开实施例公开了一种订单支付方法及系统，包括当向第三方系统提交票据订单支付请求后，监测是否接收到第三方系统的回调结果；如果未接收到回调结果，向第三方系统发送主动查询消息，以查询支付是否成功，其中，对于未支付成功的票据订单回滚至待支付票据订单的状态；对于待支付票据订单存在支付超时、且提交了支付请求但未确定支付结果的票据，基于预设的定时任务向第三方系统发送查询请求；基于查询请求的结果，对票据订单进行不同的处理。通过在第三方系统回调基础上，增加两种补偿机制全面保证支付的安全，消除订单重复支付和重复扣款以及第三方系统与平台订单交易状态不一致的问题，极大提升了票据平台的容错性能。

Description

订单支付方法及系统

技术领域

本公开涉及数据处理技术领域，具体涉及到一种订单支付方法及系统。

背景技术

订单支付是目前所有的电商行业交易必不可少的一个环节，是实现商品和资金流转的关键一环。同城汇票交易订单支付，是实现资金从资金方流向持票方的重要入口，因此，订单支付安全和健全完备可容错的支付体系建设尤为重要。

订单支付是通过调用第三方系统接口(第三方系统可以是银行)，实现资金和票据流转，根据第三方接口返回结果，判断该环节是否成功，由于第三方系统的接口往往是异步形式，即一次请求成功后，第三方系统的具体支付结果并不会实时返回。因此在订单请求银行第三方系统支付接口成功后，订单有一个短暂的中间状态，即介于待打款到待背书之间，在该状态下如果银行一直未有回调结果，订单将一直处于该状态，业务无法推进造成业务处理效率低。

发明内容

本公开的主要目的在于提供一种订单支付方法及系统。

为了实现上述目的，根据本公开的第一方面，提供了一种订单支付方法，包括：当向第三方系统提交票据订单支付请求后，监测是否接收到第三方系统的回调结果；如果未接收到回调结果，向第三方系统发送主动查询消息，以查询支付是否成功，其中，对于未支付成功的票据订单回滚至待支付票据订单的状态；对于待支付票据订单存在支付超时、且提交了支付请求但未确定支付结果的票据，基于预设的定时任务向第三方系统发送查询请求；基于查询请求的结果，对票据订单进行不同的处理。

可选地，向第三方系统发送主动查询消息，以查询支付是否成功包括：对于支付成功的票据订单，将该票据订单的状态从待支付状态流转至待背书状态。

可选地，当票据订单回滚至待支付票据订单的状态后，如果在预设时间内再次接收到该票据订单的支付请求，优先向第三方系统发送主动查询消息；基于查询的结果，对票据订单的下一次支付请求进行预设限制，以限制再次对票据订单进行请求。

可选地，如果待支付的票据订单支付超时，且不存在未确定支付结果，则对该未支付的订单进行取消操作。

可选地，基于查询请求的结果，对票据订单进行不同的处理包括：如果支付成功，则票据订单从待支付状态流转至待背书状态；如果支付失败，则票据订单回滚至待支付状态；如果支付正在被处理，则不对票据订单进行处理。

可选地，针对所取消的票据订单，对未支付该票据订单的用户的信息进行记录。

可选地，当向第三方系统提交票据订单支付请求后，确定支付请求指示的不同支付业务对应的结算逻辑；基于所述结算逻辑，就算预设支付金额。

根据本公开的第二方面，提供了一种订单支付系统，包括：第一单元，被配置成当向第三方系统提交票据订单支付请求后，监测是否接收到第三方系统的回调结果；第二单元，被配置成如果未接收到回调结果，向第三方系统发送主动查询消息，以查询支付是否成功，其中，对于未支付成功的票据订单回滚至待支付票据订单的状态；第三单元，被配置成对于待支付票据订单存在支付超时、且提交了支付请求但未确定支付结果的票据，基于预设的定时任务向第三方系统发送查询请求；第四单元，被配置成基于查询请求的结果，对票据订单进行不同的处理。

根据本公开的第三方面，提供了一种计算机可读存储介质，存储有计算机指令，所述计算机指令用于使所述计算机执行第一方面任意一项实现方式所述的订单支付方法。

根据本公开的第四方面，提供了一种电子设备，包括：至少一个处理器；以及与所述至少一个处理器通信连接的存储器；其中，所述存储器存储有可被所述至少一个处理器执行的计算机程序，所述计算机程序被所述至少一个处理器执行，以使所述至少一个处理器执行第一方面任意一项实现方式所述的订单支付方法。

在本公开实施例订单支付方法及系统中，包括当向第三方系统提交票据订单支付请求后，监测是否接收到第三方系统的回调结果；如果未接收到回调结果，向第三方系统发送主动查询消息，以查询支付是否成功，其中，对于未支付成功的票据订单回滚至待支付票据订单的状态；对于待支付票据订单存在支付超时、且提交了支付请求但未确定支付结果的票据，基于预设的定时任务向第三方系统发送查询请求；基于查询请求的结果，对票据订单进行不同的处理。通过在第三方系统回调基础上，增加两种补偿机制全面保证支付的安全，消除订单重复支付和重复扣款以及第三方系统与平台订单交易状态不一致的问题，极大提升了票据平台的容错性能，克服了相关技术中票据订单支付无法实时得到支付结果导致票据业务无法被及时处理的问题。

附图说明

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

图1是根据本公开实施例的订单支付方法流程图；

图2是根据本公开实施例的订单支付方法的一个应用示意图；

图3是根据本公开实施例的订单支付方法的另一个应用示意图；

图4是根据本公开实施例的电子设备的示意图。

具体实施方式

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

需要说明的是，本公开的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本公开的实施例。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

需要说明的是，在不冲突的情况下，本公开中的实施例及实施例中的特征可以相互组合。下面将参考附图并结合实施例来详细说明本公开。

根据本公开实施例，提供了一种订单支付方法，如图1所示，该方法包括如下的步骤101至步骤104：

步骤101：当向第三方系统提交票据订单支付请求后，监测是否接收到第三方系统的回调结果。

在本实施例中，由于第三方系统的接口往往是异步形式，即一次请求成功后，第三方系统的具体支付结果并无法实时回调通知票据交易平台。在本实施例中可以在支付请求递交后，监测是否接收到回调结果。

作为本实施例一种可选的实现方式，当向第三方系统提交票据订单支付请求后，确定支付请求指示的不同支付业务对应的结算逻辑；基于所述结算逻辑，就算预设支付金额。

在本可选的实现方式中，票据订单支付作为汇票交易的重要步骤，也是订单流转过程的重要组成单元。本实施例在实现时，可以针对所有交易环节，设定一套成熟的模板模式，交易环节通过传入特定的场景类型枚举，选择对应的逻辑处理器单元进行业务校验与处理，具体的流程如图2。

方案执行步骤：①自定义整套成熟的策略模式，不同环节对应不同的操作枚举，根据请求枚举获取相应的逻辑处理单元②通过主键对订单加锁，并根据主键获取订单信息③针对订单的不同环节，进行订单预置状态校验④执行各环节特定业务的额外校验⑤事务中订单信息处理和特定业务操作⑥释放锁⑦各环节额外操作⑧订单状态变更异步通知。从图中我们可以发现，这一方案具有一般普适性，对于任意一个交易环节，只需要定义和编写不同的业务实现单元，均能实现特定业务功能。

上图1中，支付请求到达后，进入订单流控制中心，会根据入参中的枚举值选择支付的业务处理单元，通过主键tickedId对该订单尝试加锁，如果之前已经有了对该订单的操作(已加锁还未释放)，本次加锁失败，则支付失败。若加锁成功，会查询库中订单信息并进行预置状态校验，不同环节预置的订单状态均不相同。例如支付时，订单的状态须是审核通过的已确认待打款状态。预置状态校验不通过，则支付失败。预置状态校验成功，会进行支付环节特定的业务校验，例如资金方用户信息、持票方用户信息、支付验证码、支付渠道的可用性等。业务校验成功，会继续执行订单信息更新和订单支付操作。第三方系统放款接口调用失败，事务回滚，订单信息更新失败，否则本次支付成功，释放对象锁，其他请求对该订单的操作可继续执行。

进一步地，订单支付环节，作为订单流的一个组成部分，通过集成该流程的优势，也扩展了新增交易渠道的可能性，在本可选的实现方式中通过设定订单流的框架，完成不同业务渠道的订单结算逻辑，支付体系过程如图3。当票据订单提交支付请求后，支付中心控制器确定具体的结算逻辑，以进入对应的渠道计算逻辑，最终计算得到服务费和成交金额。计算完成后可以与第三方系统进行交互发送支付请求。而后可以按照如下的步骤实现订单的支付。

步骤102：如果未接收到回调结果，向第三方系统发送主动查询消息，以查询支付是否成功，其中，对于未支付成功的票据订单回滚至待支付票据订单的状态。

在本实施例中，在事务中请求银行支付，如果遇到网络波动或银行服务宕机，导致接口超时事务回滚，订单状态此时又会回到最初待打款状态，但实际可能这次请求经过网络延迟到达第三方系统，请求是成功的，第三方系统处理成功，此时便会造成两遍订单信息不一致。

在银行回调的基础上，增加了主动查询这种补偿机制，可以通过延时mq消息，在第三方系统未回调时，主动查询订单支付结果，如果查到支付成功，系统自动流转订单到下一状态。

如果支付未成功，则可能是第三方系统的支付接口请求失败，失败的原因可以是网络原因导致接口超时、服务不可用等，而后可以回滚至待支付状态。

作为本实施例一种可选的实现方式，当票据订单回滚至待支付票据订单的状态后，如果在预设时间内再次接收到该票据订单的支付请求，优先向第三方系统发送主动查询消息；基于查询的结果，对票据订单的下一次支付请求进行预设限制，以限制再次对票据订单进行请求。

在本可选的实现方式中，由于不论支付成功或者失败，均可记录一次支付操作流水记录，当用户在支付有效期内再次对支付失败的订单发起支付请求，会优先根据支付流水记录号再次主动查询银行的支付结果。

进一步地，如果查询的结果为处理成功或处理中，则无法对该订单继续发起支付请求直到第三方系统有结果；如果查询结果是第三方系统出现异常，用户无法发起支付请求，直到第三方系统的查询结果为订单支付失败，才可以再次支付。该方式能够极大程度避免用户同意订单重复扣款重复支付问题。

作为本实施例一种可选的实现方式，向第三方系统发送主动查询消息，以查询支付是否成功包括：对于支付成功的票据订单，将该票据订单的状态从待支付状态流转至待背书状态。

在本可选的实现方式中，对于支付成功的票据订单，在更改完订单的状态后，还可以继续接收第三方系统的回调结果，如果接收到了回调结果，不对回调结果处理。

步骤103：对于待支付票据订单存在支付超时、且提交了支付请求但未确定支付结果的票据，基于预设的定时任务向第三方系统发送查询请求。

在本可选的实现方式中，对于未支付成功的票据订单，可以将超过预设时长的票据订单取消。而对于提交了支付请求，但仍未确定第三方系统的支付结果时，不做取消处理，票据订单继续保持待打款状态。

进一步地，如果第三方系统没有支付回调接口，那么支付的结果如果完全依赖主动查询，而如果第三方系统一直在处理中，多次查询依然无果，后续的业务无法推进。基于该问题，本实施例通过定时任务每N分钟扫描一次超时未打款的订单，在得到对应的支付流水记录号后，查询第三方系统的支付结果。

步骤104：基于查询请求的结果，对票据订单进行不同的处理。

在本实施例中，针对步骤103的不同的支付结果，对于支付成功的结果，订单自动进入下一状态。如果支付失败则取消票据订单；如果是支付处理中，此次任务暂不处等下一次任务再执行。

作为本实施例一种可选的实现方式，针对所取消的票据订单，对未支付该票据订单的用户的信息进行记录。

进一步地，对于取消的订单，可以对买方违约进行记录生成判罚结果。克服了相关技术中存在的，如果实际支付却因无支付结果导致订单取消，从而生成误判结果导致纠纷的问题。

订单支付成功后，应对特定的业务场景，例如：其他业务部门需要统计某用户某天或者某一时间段支付订单数量来计算会员信用分、打款率，需要将订单信息进行异步mq推送，买方在打款过程中存在违约或者交易超时导致订单取消，会生成判罚记录等，这一系列操作都会在额外操作中异步进行。之所以这些业务不放在上一步签收中一并进行，主要出于两个方面的考虑：(1)订单状态维护和第三方机构签收放款接口调用，在事务中进行，由于事务设置了超时时间，过多冗余业务处理可能造成事务超时导致失败回滚(2)主干订单流程已完成，而上述业务场景，对于整体订单流程无实质性的影响，不影响买卖双方的交易目的，后续额外补偿操作大可不必占用用户的时间、系统的资源，无需同步执行。

本实施例基于第三方系统回调基础上，增加两种补偿机制：限频次的主动查询、定时任务，从而全面保证支付的安全，消除订单重复支付和重复扣款以及银行与平台订单交易状态不一致的问题，在用户无感知的情况下，完成一系列的补偿操作，极大提升平台的容错性能，弥补由于第三方系统系统原因、网络抖动异常等外在因素导致交易的不可用。

需要说明的是，在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行，并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

根据本公开实施例，还提供了一种订单支付系统，包括：第一单元，被配置成当向第三方系统提交票据订单支付请求后，监测是否接收到第三方系统的回调结果；第二单元，被配置成如果未接收到回调结果，向第三方系统发送主动查询消息，以查询支付是否成功，其中，对于未支付成功的票据订单回滚至待支付票据订单的状态；第三单元，被配置成对于待支付票据订单存在支付超时、且提交了支付请求但未确定支付结果的票据，基于预设的定时任务向第三方系统发送查询请求；第四单元，被配置成基于查询请求的结果，对票据订单进行不同的处理。

作为本实施例一种可选的实现方式，向第三方系统发送主动查询消息，以查询支付是否成功包括：对于支付成功的票据订单，将该票据订单的状态从待支付状态流转至待背书状态。

作为本实施例一种可选的实现方式，当票据订单回滚至待支付票据订单的状态后，如果在预设时间内再次接收到该票据订单的支付请求，优先向第三方系统发送主动查询消息；基于查询的结果，对票据订单的下一次支付请求进行预设限制，以限制再次对票据订单进行请求。

作为本实施例一种可选的实现方式，如果待支付的票据订单支付超时，且不存在未确定支付结果，则对该未支付的订单进行取消操作。

作为本实施例一种可选的实现方式，基于查询请求的结果，对票据订单进行不同的处理包括：如果支付成功，则票据订单从待支付状态流转至待背书状态；如果支付失败，则票据订单回滚至待支付状态；如果支付正在被处理，则不对票据订单进行处理。

作为本实施例一种可选的实现方式，针对所取消的票据订单，对未支付该票据订单的用户的信息进行记录。

作为本实施例一种可选的实现方式，当向第三方系统提交票据订单支付请求后，确定支付请求指示的不同支付业务对应的结算逻辑；基于所述结算逻辑，就算预设支付金额。

本公开实施例提供了一种电子设备，如图4所示，该电子设备包括一个或多个处理器41以及存储器42，图4中以一个处理器41为例。

该控制器还可以包括：输入装置43和输出装置44。

处理器41、存储器42、输入装置43和输出装置44可以通过总线或者其他方式连接，图4中以通过总线连接为例。

处理器41可以为中央处理器(CentralProcessingUnit，CPU)。处理器41还可以为其他通用处理器、数字信号处理器(DigitalSignalProcessor，DSP)、专用集成电路(ApplicationSpecificIntegratedCircuit，ASIC)、现场可编程门阵列(Field-ProgrammableGateArray，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等芯片，或者上述各类芯片的组合。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。

存储器42作为一种非暂态计算机可读存储介质，可用于存储非暂态软件程序、非暂态计算机可执行程序以及模块，如本公开实施例中的控制方法对应的程序指令/模块。处理器41通过运行存储在存储器42中的非暂态软件程序、指令以及模块，从而执行服务器的各种功能应用以及数据处理，即实现上述方法实施例的方法。

存储器42可以包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需要的应用程序；存储数据区可存储根据服务器操作的处理装置的使用所创建的数据等。此外，存储器42可以包括高速随机存取存储器，还可以包括非暂态存储器，例如至少一个磁盘存储器件、闪存器件、或其他非暂态固态存储器件。在一些实施例中，存储器42可选包括相对于处理器41远程设置的存储器，这些远程存储器可以通过网络连接至网络连接装置。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

输入装置43可接收输入的数字或字符信息，以及产生与服务器的处理装置的用户设置以及功能控制有关的键信号输入。输出装置44可包括显示屏等显示设备。

一个或者多个模块存储在存储器42中，当被一个或者多个处理器41执行时，执行如图1所示的方法。

本领域技术人员可以理解，实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，程序可存储于一计算机可读取存储介质中，该程序在执行时，可包括如上述各电机控制方法的实施例的流程。其中，存储介质可为磁碟、光盘、只读存储记忆体(Read-OnlyMemory，ROM)、随机存储记忆体(RandomAccessMemory，RAM)、快闪存储器(FlashMemory)、硬盘(HardDiskDrive，缩写：HDD)或固态硬盘(Solid-StateDrive，SSD)等；存储介质还可以包括上述种类的存储器的组合。

虽然结合附图描述了本公开的实施方式，但是本领域技术人员可以在不脱离本公开的精神和范围的情况下作出各种修改和变型，这样的修改和变型均落入由所附权利要求所限定的范围之内。

Claims (10)

1.一种订单支付方法，其特征在于，包括：

当向第三方系统提交票据订单支付请求后，监测是否接收到第三方系统的回调结果；

如果未接收到回调结果，向第三方系统发送主动查询消息，以查询支付是否成功，其中，对于未支付成功的票据订单回滚至待支付票据订单的状态；

对于待支付票据订单存在支付超时、且提交了支付请求但未确定支付结果的票据，基于预设的定时任务向第三方系统发送查询请求；

基于查询请求的结果，对票据订单进行不同的处理。

2.根据权利要求1所述的订单支付方法，其特征在于，向第三方系统发送主动查询消息，以查询支付是否成功包括：

对于支付成功的票据订单，将该票据订单的状态从待支付状态流转至待背书状态。

3.根据权利要求1所述的订单支付方法，其特征在于，当票据订单回滚至待支付票据订单的状态后，如果在预设时间内再次接收到该票据订单的支付请求，优先向第三方系统发送主动查询消息；

基于查询的结果，对票据订单的下一次支付请求进行预设限制，以限制再次对票据订单进行请求。

4.根据权利要求1所述的订单支付方法，其特征在于，如果待支付的票据订单支付超时，且不存在未确定支付结果，则对该未支付的订单进行取消操作。

5.根据权利要求1所述的订单支付方法，其特征在于，基于查询请求的结果，对票据订单进行不同的处理包括：

如果支付成功，则票据订单从待支付状态流转至待背书状态；

如果支付失败，则票据订单回滚至待支付状态；

如果支付正在被处理，则不对票据订单进行处理。

6.根据权利要求1所述的订单支付方法，其特征在于，针对所取消的票据订单，对未支付该票据订单的用户的信息进行记录。

7.根据权利要求1所述的订单支付方法，其特征在于，当向第三方系统提交票据订单支付请求后，确定支付请求指示的不同支付业务对应的结算逻辑；

基于所述结算逻辑，就算预设支付金额。

8.一种订单支付系统，其特征在于，系统包括：

第一单元，被配置成当向第三方系统提交票据订单支付请求后，监测是否接收到第三方系统的回调结果；

第二单元，被配置成如果未接收到回调结果，向第三方系统发送主动查询消息，以查询支付是否成功，其中，对于未支付成功的票据订单回滚至待支付票据订单的状态；

第三单元，被配置成对于待支付票据订单存在支付超时、且提交了支付请求但未确定支付结果的票据，基于预设的定时任务向第三方系统发送查询请求；

第四单元，被配置成基于查询请求的结果，对票据订单进行不同的处理。

9.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有计算机指令，所述计算机指令用于使所述计算机执行权利要求1-7任意一项所述的订单支付方法。

10.一种电子设备，其特征在于，包括：至少一个处理器；以及与所述至少一个处理器通信连接的存储器；其中，所述存储器存储有可被所述至少一个处理器执行的计算机程序，所述计算机程序被所述至少一个处理器执行，以使所述至少一个处理器执行权利要求1-7任意一项所述的订单支付方法。

Images