CN108052398A - 一种订单处理状态的反馈方法及聚合支付平台 - Google Patents

Abstract

本发明公开了一种订单处理状态的反馈方法和聚合支付平台。该方法应用于聚合支付平台，包括：接收第三方支付服务器返回的订单处理状态，订单处理状态为成功、失败或处理中；在确定订单处理状态为处理中时，经过预设的延迟时间再向第三方支付服务器发送查询消息，查询消息用于查询当前的订单处理状态。本发明实施例可以通过聚合支付平台代替商户向第三方支付平台发送查询当前订单处理状态的请求，直到订单处理完成后，将第三方支付平台返回的查询结果发送给商户，从而避免了商户因不停地发送查询请求而造成的服务器资源浪费。

Description

一种订单处理状态的反馈方法及聚合支付平台

技术领域

本发明涉及互联网支付技术领域，具体涉及一种订单处理状态的反馈方法及聚合支付平台。

背景技术

随着互联网技术的发展，第三方支付已经成为目前的主流支付模式。在这种支付模式下，第三方支付平台处理订单后，会返回订单处理状态，用于通知商户订单的处理状态，该订单处理状态包括成功、失败和处理中，其中处理中代表处理未完成。对于这种处理中的订单，有些第三方支付平台在处理完成后，不会发送处理状态通知，需要商户主动发送查询请求。商户不停地发送查询请求，则造成服务器资源的浪费。

因此，如何在不浪费商户服务器资源的情况下通知商户订单的处理状态，成为亟待解决的问题。

发明内容

本发明的实施例提供一种订单处理状态的反馈方法及聚合支付平台，从而避免了商户因不停地发送查询请求而造成的服务器资源浪费。

本发明的一个方面提供了一种订单处理状态的反馈方法，应用于聚合支付平台，包括：接收第三方支付服务器返回的订单处理状态，该订单处理状态为成功、失败或处理中；在确定订单处理状态为处理中时，经过预设的延迟时间再向第三方支付服务器发送查询消息，该查询消息用于查询当前的订单处理状态。

在本发明的一个实施例中，上述方法还包括：后端服务器接收第一商户服务器发送的订单；后端服务器向第三方支付服务器发送订单；其中，接收第三方支付服务器返回的订单处理状态，包括：后端服务器接收第三方支付服务器返回的订单处理状态。

在本发明的一个实施例中，在确定订单处理状态为处理中时，经过预设的延迟时间再向第三方支付服务器发送查询消息，包括：后端服务器在确定订单处理状态为处理中时，向队列服务器发送订单处理状态；队列服务器将订单处理状态放在延迟队列中；队列服务器在预设的延迟时间之后将订单处理状态从延迟队列移到正常队列中；消费队列服务器从正常队列中获取订单处理状态；消费队列服务器根据订单处理状态向后端服务器发送查询请求消息；后端服务器根据查询请求消息向第三方支付服务器发送查询消息。

在本发明的一个实施例中，在后端服务器根据查询请求消息向第三方支付服务器发送查询消息之后，上述方法还包括：后端服务器接收第三方支付服务器返回的查询的订单处理状态；后端服务器向消费队列服务器发送查询的订单处理状态；消费队列服务器在确定查询的订单处理状态为处理中时，向队列服务器发送查询的订单处理状态；队列服务器将查询的订单处理状态放在延迟队列中。

在本发明的一个实施例中，上述方法还包括：消费队列服务器在确定查询的订单处理状态为成功或失败时，向第二商户服务器发送通知，该通知用于指示订单处理状态为成功或失败。

在本发明的一个实施例中，在后端服务器根据查询请求消息向第三方支付服务器发送查询消息之后，上述方法还包括：后端服务器接收第三方支付服务器返回的查询的订单处理状态；后端服务器在确定查询的订单处理状态为处理中时，向队列服务器发送查询的订单处理状态；队列服务器将查询的订单处理状态放在延迟队列。

在本发明的一个实施例中，上述方法还包括：后端服务器在确定查询的订单处理状态为成功或失败时，向队列服务器发送查询的订单处理状态；队列服务器将查询的订单处理状态放在正常队列。

本发明的另一个方面提供了一种聚合支付平台，该聚合支付平台接收第三方支付服务器返回的订单处理状态，其中该订单处理状态为成功、失败或处理中，并且在确定订单处理状态为处理中时，经过预设的延迟时间再向第三方支付服务器发送查询消息，该查询消息用于查询当前的订单处理状态。

在本发明的一个实施例中，上述聚合支付平台包括：后端服务器，用于接收第一商户服务器发送的订单，向第三方支付服务器发送订单，并接收第三方支付服务器返回的订单处理状态。

在本发明的一个实施例中，上述聚合支付平台还包括：队列服务器和消费队列服务器；后端服务器还在确定订单处理状态为处理中时，向队列服务器发送订单处理状态；队列服务器用于将订单处理状态放在延迟队列中，在预设的延迟时间之后将订单处理状态从延迟队列移到正常队列中；消费队列服务器用于从正常队列中获取订单处理状态，并根据订单处理状态向后端服务器发送查询请求消息，后端服务器根据查询请求消息向第三方支付服务器发送查询消息。

在本发明的一个实施例中，在后端服务器根据查询请求消息向第三方支付服务器发送查询消息之后，后端服务器还接收第三方支付服务器返回的查询的订单处理状态，并向消费队列服务器发送查询的订单处理状态；消费队列服务器还在确定查询的订单处理状态为处理中时，向队列服务器发送订单处理状态；队列服务器还将订单处理状态放在延迟队列中。

在本发明的一个实施例中，消费队列服务器还在确定查询的订单处理状态为成功或失败时，向第二商户服务器发送通知，该通知用于指示订单处理状态为成功或失败。

在本发明的一个实施例中，在后端服务器根据查询请求消息向第三方支付服务器发送查询消息之后，后端服务器还接收第三方支付服务器返回的查询的订单处理状态，在确定查询的订单处理状态为处理中时，向队列服务器发送查询的订单处理状态；队列服务器还将查询的订单处理状态放在延迟队列。

在本发明的一个实施例中，后端服务器还在确定查询的订单处理状态为成功或失败时，向队列服务器发送查询的订单处理状态；队列服务器还将查询的订单处理状态放在正常队列。

本发明实施例可以通过聚合支付平台代替商户向第三方支付平台发送查询当前订单处理状态的请求，直到订单处理完成后，将第三方支付平台返回的查询结果发送给商户，从而避免了商户因不停地发送查询请求而造成的服务器资源浪费。

附图说明

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

图1A是根据本发明一个实施例的支付系统的示意性框架图。

图1B是根据本发明一个实施例的聚合支付平台的示意性结构图。

图1C是根据本发明一个实施例的商户系统的示意性结构图。

图2是根据本发明一个实施例的订单处理状态的反馈方法的示意性流程图。

图3是根据本发明另一实施例的订单处理状态的反馈方法的过程的示意性流程图。

具体实施方式

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

图1A是根据本发明一个实施例的支付系统100的示意性框架图。

支付系统100可以包括第三方支付服务器110、聚合支付平台120和商户系统130。

在支付系统100中，第三方支付服务器110可以通过与银行支付结算系统接口对接，完成交易双方之间的网络支付结算，第三方支付平台可以为银联、支付宝或微信等；聚合支付平台120则是一个将多种互联网支付方式整合起来的支付接口，商户系统130可以通过聚合支付SDK(Software Development Kit，软件开发工具包)与聚合支付平台120连接；商户系统130可以负责向聚合支付平台120发送交易订单，并且处理聚合支付平台120发送的订单处理状态通知。聚合支付平台120与商户系统130和第三方支付服务器110之间可以通过有线或无线网络进行通信。

图2是根据本发明一个实施例的订单处理状态的反馈方法的示意性流程图，该反馈方法可以应用在图1A中聚合支付平台120上，可以由聚合支付平台120执行。

210，接收第三方支付服务器返回的订单处理状态。

在接收第三方支付服务器返回的订单处理状态之前，图2方法还可以包括接收商户系统发送的订单，并且向第三方支付服务器发送订单。

例如，商户系统向聚合支付平台发送的订单，可以是用户通过网络页面或者应用程序的用户界面向商户系统发送的订单，也可以是商户系统发起的订单。这些订单相对于聚合支付平台来说，可以是收款订单、打款订单或者退款订单。

另外，聚合支付平台向第三方支付服务器发送上述订单之前，可以先检查订单的合法性，若合法，则将该订单发送给第三方支付服务器，若不合法，则向商户系统返回参数错误信息。聚合支付平台在接收商户系统发送上述订单时，可以将订单信息存入聚合支付平台订单数据库，该聚合支付平台订单数据库可以包含订单处理状态字段，对于新存入的订单，它的订单处理状态字段可以为空。

进一步地，第三方支付服务器接收聚合支付平台发送上述订单后，会向聚合支付平台返回订单处理状态，该订单处理状态为成功、失败或处理中。其中，处理中这种订单处理状态，作为一种中间态，代表订单未处理完成，第三方支付平台需要花费时间进一步处理，待处理完成后，订单处理状态变更为成功或失败。例如，对于订单处理状态为处理中的订单，当第三方支付服务器收到查询该订单的处理状态的请求时，若该订单在查询的时刻订单处理状态仍为处理中，第三方支付服务器将返回处理中的订单处理状态；若该订单在查询的时刻订单处理状态已变更为成功或失败，第三方支付服务器将返回成功或失败的订单处理状态。

具体地，在210中，该订单处理状态可以为聚合支付平台向第三方支付服务器发送订单后，第三方支付服务器返回的订单处理状态；也可以是聚合支付平台向第三方支付服务器发送订单状态查询请求后，第三方支付服务器返回的订单处理状态。

220，在确定订单处理状态为处理中时，经过预设的延迟时间再向第三方支付服务器发送查询消息。

例如，聚合支付平台在向第三方支付服务器发送查询消息之前，会根据该订单处理状态进行获取查询消息处理。此处，该查询消息作为标识信息，可以包含订单号参数，用作第三方支付服务器查询的标识，用于查询当前的订单处理状态。当前的订单处理状态，指的是查询时刻的订单处理状态。当聚合支付平台确定查询的订单处理状态为成功或失败时，向商户系统发送通知，该通知用于指示订单处理状态为成功或失败。同时可以更新聚合支付平台订单数据库中的订单处理状态字段；当确定查询的订单处理状态仍为处理中时，则继续执行220。

相对于220中确定订单处理状态为处理中时的情况，图2方法还包括在确定订单处理状态为成功或失败时，向商户系统发送通知，该通知用于指示订单处理状态为成功或失败，这里的订单处理状态可以为聚合支付平台向第三方支付服务器发送订单后，第三方支付服务器返回的订单处理状态；也可以是聚合支付平台向第三方支付服务器发送订单状态查询请求后，第三方支付服务器返回的订单处理状态。同时可以更新聚合支付平台订单数据库中的订单处理状态字段。聚合支付平台向商户系统发送的通知，可以为异步通知。

本发明实施例可以通过聚合支付平台代替商户向第三方支付平台发送查询当前订单处理状态的请求，直到订单处理完成后，将第三方支付平台返回的查询结果发送给商户，从而避免了商户因不停地发送查询请求而造成的服务器资源浪费。

图1B是根据本发明一个实施例的聚合支付平台的示意性结构图。图1C是根据本发明一个实施例的商户系统的示意性结构图。

聚合支付平台120可以包括后端服务器121、队列服务器122和消费队列服务器123，商户系统130可以包括第一商户服务器131和第二商户服务器132，结合图1B及图1C，由聚合支付平台120的后端服务器121、队列服务器122和消费队列服务器123执行，对图2方法作进一步描述。

根据本发明的实施例，210具体包括：后端服务器接收第一商户服务器发送的订单；后端服务器向第三方支付服务器发送订单；其中，接收第三方支付服务器返回的订单处理状态，包括：后端服务器接收第三方支付服务器发送的订单处理状态。

例如，后端服务器向第三方支付服务器发送上述订单之前，可以先检查该订单的合法性，若合法，则将订单发送给第三方支付服务器，若不合法，则向第一商户服务器返回参数错误信息。后端服务器在接收第一商户服务器发送上述订单时，可以将订单存入聚合支付平台订单数据库。第三方支付服务器接收后端服务器发送上述订单后，会向后端服务器返回订单处理状态，该订单处理状态为成功、失败或处理中。

相对于220中在确定订单处理状态为处理中时的情况，在确定订单处理状态为成功或失败时，图2方法可以具体包括：后端服务器在确定订单处理状态为成功或失败时，向队列服务器发送该订单处理状态；队列服务器将该订单处理状态放在正常队列中；消费队列服务器从正常队列中获取该订单处理状态；消费队列服务器在确定该订单处理状态为成功或失败时，向第二商户服务器发送通知，该通知用于指示该订单处理状态为成功或失败。与此同时，聚合支付平台也可以更新订单数据库中的订单处理状态字段。

可选地，作为上述在确定订单处理状态为成功或失败时的替代实施方式，图2方法可选地具体包括：后端服务器在确定订单处理状态为成功或失败时，向第二商户服务器发送通知，该通知用于指示该订单处理状态为成功或失败。与此同时，聚合支付平台也可以更新订单数据库中的订单处理状态字段。

根据本发明的实施例，220具体包括：后端服务器在确定订单处理状态为处理中时，向队列服务器发送该订单处理状态；队列服务器将该订单处理状态放在延迟队列中；队列服务器在上述预设的延迟时间之后将该订单处理状态从延迟队列移到正常队列中；消费队列服务器从正常队列中获取该订单处理状态；消费队列服务器根据该订单处理状态向后端服务器发送查询请求消息；后端服务器根据该查询请求消息向第三方支付服务器发送查询消息。

具体地，后端服务器接收消费队列服务器发送查询请求消息后，根据该查询请求消息，进行获取查询消息处理。如上所述，该查询消息作为订单的识别信息，可以包括订单号参数，第三方支付服务器根据该查询消息可以确定所要查询的订单。队列服务器可以包括延迟队列和正常队列，延迟队列只放处理中的订单处理状态，正常队列可以放成功、失败、处理中这三种处理状态中的任意一种订单处理状态。

可选地，作为另一实施例，后端服务器根据上述查询请求消息向第三方支付服务器发送上述查询消息之后，220具体还包括：后端服务器接收第三方支付服务器返回的查询的订单处理状态；后端服务器向消费队列服务器发送该查询的订单处理状态；消费队列服务器在确定该查询的订单处理状态为处理中时，向队列服务器发送该查询的订单处理状态；队列服务器将该查询的订单处理状态放在延迟队列中。

可选地，作为另一实施例，220具体还包括：消费队列服务器在确定上述查询的订单处理状态为成功或失败时，向第二商户服务器发送通知，该通知用于指示该订单处理状态为成功或失败。与此同时，聚合支付平台也可以更新订单数据库中的订单处理状态字段。

本发明实施例可以通过聚合支付平台包括的后端服务器、队列服务器和消费队列服务器，代替商户向第三方支付平台发送查询当前订单处理状态的请求，直到订单处理完成后，这时查询的订单处理状态为成功或失败，将第三方支付平台返回的查询结果发送给商户，从而避免了商户因不停地发送查询请求而造成的服务器资源浪费。

可选地，作为另一实施例，在后端服务器根据上述查询请求消息向第三方支付服务器发送上述查询消息之后，220可选地，可以包括：后端服务器接收第三方支付服务器返回的查询的订单处理状态；后端服务器在确定该查询的订单处理状态为处理中时，向队列服务器发送该查询的订单处理状态；队列服务器将该查询的订单处理状态放在延迟队列。

可选地，作为另一实施例，220可选地，还可以包括：后端服务器在确定上述查询的订单处理状态为成功或失败时，向队列服务器发送该查询的订单处理状态；队列服务器将该查询的订单处理状态放在正常队列。消费队列服务器从队列服务器正常队列中获取该订单处理状态，并向第二商户服务器发送通知，该通知用于指示该订单处理状态为成功或失败。与此同时，聚合支付平台也可以更新订单数据库中的订单处理状态字段，将处理中更新为成功或失败。

进一步地，在上述本发明实施例中，队列服务器负责在预设的延迟时间之后，将延迟队列中的订单处理状态移至正常队列中；消费队列服务器不断地从队列服务器正常队列中获取订单处理状态，当获取的订单处理状态为成功或失败时，则向第二商户服务器发送通知，当获取的订单处理状态为处理中时，则向后端服务器发送查询请求消息，后端服务器根据该查询请求消息进行查询消息处理，并将查询消息发送给第三方支付服务器，第三方支付服务器根据查询消息获取要查询订单的订单处理状态，并将查询结果返回后端服务器；第一商户服务器可以为商户网站服务器，可以用于接收用户通过网络页面或者应用程序的用户界面提交的订单；第二商户服务器可以为商户处理异步通知服务器，可以用于接收聚合支付平台发送的异步通知，该异步通知用于指示订单处理状态为成功或失败；上述预设的延迟时间可以为1分钟，上述队列服务器可以为RabbitMQ(Rabbit Message Queue)服务器，聚合支付平台可以在设置RabbitMQ参数时将延迟时间设置为1分钟。

应理解，上述延迟时间仅仅是示例，上述延迟时间可以根据实际需要预先设定，例如，可以设置为10分钟或60分钟，甚至更多。当然，该延迟时间也可以设置为小于1分钟。

下面结合具体例子，更加详细地描述本发明的实施例。

图3是根据本发明另一实施例的订单处理状态的反馈方法的过程的示意性流程图，是图2实施例的例子。

305，发送订单。

后端服务器接收商户网站服务器发送的订单，将订单信息添加到聚合支付平台订单数据库中，该订单可以为收款订单、打款订单或退款订单。

310，发送订单。

后端服务器向第三方支付服务器发送该订单，在此之前，会先检测订单的合法性，若合法，则将该订单发送给第三方支付服务器，若不合法，则向商户网站服务器返回参数错误信息。

315，返回订单处理状态。

后端服务器接收第三方支付服务器同步返回的订单处理状态。

320，发送订单处理状态。

后端服务器检测该订单处理状态，并向RabbitMQ服务器发送该订单处理状态。对于处理中的订单处理状态，RabbitMQ服务器将该订单处理状态放在延迟队列中，延迟1分钟后，再将该订单处理状态从该延迟队列移到正常队列中；对于成功或者失败的订单处理状态，RabbitMQ服务器将该订单处理状态放在正常队列中。

330，发送订单处理状态。

消费队列服务器从RabbitMQ服务器正常队列中获取订单处理状态，消费队列服务器检测该订单处理状态，在确定订单处理状态为成功或者失败时，执行333；在确定订单处理状态为处理中时，执行337。

333，发送异步通知。

消费队列服务器向商户处理异步通知服务器发送异步通知，该异步通知用于指示订单处理状态为成功或失败。与此同时，聚合支付平台更新订单数据库中的订单处理状态字段。

337，发送查询请求消息。

消费队列服务器向后端服务器发送查询请求消息。

340，发送查询消息。

后端服务器处理消费队列服务器发送的查询请求消息，获取查询消息后，向第三方支付服务器发送该查询消息。

345，返回查询的订单处理状态。

第三方支付服务器接收上述查询消息后，会根据该查询消息查询相应订单的订单处理状态，并将查询的订单处理状态同步返回给后端服务器，后端服务器接收第三方支付服务器同步返回的查询的订单处理状态。

350，返回查询的订单处理状态。

后端服务器向消费队列服务器返回查询的订单处理状态。消费队列服务器检测该查询的订单处理状态，在确定该查询的订单处理状态为成功或失败时，执行333；在确定查询的订单处理状态为处理中时，执行355。

355，发送查询的订单处理状态。

消费队列服务器向RabbitMQ服务器发送该查询的订单处理状态，该查询的订单处理状态为处理中，RabbitMQ服务器将该查询的订单处理状态放在延迟队列中，延迟1分钟后，再将该订单处理状态从延迟队列移到正常队列中，之后执行330。

可选地，作为图3的实施例的替代实施例，在步骤320中，对于后端服务器检测订单处理状态为成功或失败的情况，后端服务器可以向商户处理异步通知服务器发送异步通知，该异步通知用于指示订单处理状态为成功或失败，与此同时，聚合支付平台更新订单数据库中的订单处理状态字段；对于后端服务器检测订单处理状态为处理中的情况，可以与图3步骤320中的执行方式相同。

可选地，作为图3的实施例的替代实施例，在步骤350中，后端服务器接收第三方支付服务器同步返回的查询的订单处理状态后，可以执行320。

可选地，作为图3的实施例的替代实施例，在步骤350中，对于后端服务器检测查询的订单处理状态为处理中的情况，可以与图3步骤320中的执行方式相同；对于后端服务器检测查询的订单处理状态为成功或失败的情况，后端服务器可以向消费队列服务器发送该查询的订单处理状态，消费队列服务器将向商户处理异步通知服务器发送异步通知，该异步通知用于指示订单处理状态为成功或失败，与此同时，聚合支付平台更新订单数据库中的订单处理状态字段。

上面描述了根据本发明实施例的订单处理状态的反馈方法，下面结合图1A描述应用该反馈方法的聚合支付平台。

在支付系统100中，聚合支付平台120接收第三方支付服务器返回的订单处理状态，其中该订单处理状态为成功、失败或处理中，并且在确定该订单处理状态为处理中时，经过预设的延迟时间再向第三方支付服务器发送查询消息，该查询消息用于查询当前的订单处理状态。

本发明实施例可以通过聚合支付平台代替商户向第三方支付平台发送查询当前订单处理状态的请求，直到订单处理完成后，将第三方支付平台返回的查询结果发送给商户，从而避免了商户因不停地发送查询请求而造成的服务器资源浪费。

聚合支付平台的操作和功能，可以参考图2的210和220的方法，为了避免重复，在此不再赘述。

本发明实施例中，结合图1A、图1B和图1C，对聚合支付平台作具体描述。聚合支付平台120可以包括后端服务器121、队列服务器122和消费队列服务器123，可以实现图2中的方法。

后端服务器接收第一商户服务器发送的订单，向第三方支付服务器发送该订单，并接收第三方支付服务器返回的订单处理状态。

可选地，作为本发明另一实施例，后端服务器还在确定订单处理状态为处理中时，向队列服务器发送该订单处理状态；队列服务器将订单处理状态放在延迟队列中，在预设的延迟时间之后将该订单处理状态从延迟队列移到正常队列中；消费队列服务器从正常队列中获取订单处理状态，并根据该订单处理状态向后端服务器发送查询请求消息，后端服务器根据该查询请求消息向第三方支付服务器发送查询消息。

可选地，作为本发明另一实施例，在后端服务器根据查询请求消息向第三方支付服务器发送查询消息之后，后端服务器还接收第三方支付服务器返回的查询的订单处理状态，并向消费队列服务器发送查询的订单处理状态；消费队列服务器还在确定查询的订单处理状态为处理中时，向队列服务器发送该订单处理状态；队列服务器还将该订单处理状态放在延迟队列中。

可选地，作为本发明另一实施例，消费队列服务器还在确定查询的订单处理状态为成功或失败时，向第二商户服务器发送通知，该通知用于指示订单处理状态为成功或失败。

可选地，作为本发明另一实施例，在后端服务器根据查询请求消息向第三方支付服务器发送查询消息之后，后端服务器还接收第三方支付服务器返回的查询的订单处理状态，在确定查询的订单处理状态为处理中时，向队列服务器发送查询的订单处理状态；队列服务器还将查询的订单处理状态放在延迟队列。

可选地，作为本发明另一实施例，后端服务器还在确定查询的订单处理状态为成功或失败时，向队列服务器发送查询的订单处理状态；队列服务器还将查询的订单处理状态放在正常队列。

聚合支付平台120中后端服务器121、队列服务器122和消费队列服务器123的操作和功能，可以参考图2实施例的210和220中具体包括的内容，为了避免重复，在此不再赘述。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统、装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

在本申请所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。

所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序校验码的介质。

以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应以所述权利要求的保护范围为准。

Claims (14)

1.一种订单处理状态的反馈方法，其特征在于，应用于聚合支付平台，包括：

接收第三方支付服务器返回的订单处理状态，所述订单处理状态为成功、失败或处理中；

在确定所述订单处理状态为处理中时，经过预设的延迟时间再向所述第三方支付服务器发送查询消息，所述查询消息用于查询当前的订单处理状态。

2.根据权利要求1所述的反馈方法，其特征在于，还包括：

后端服务器接收第一商户服务器发送的订单；

所述后端服务器向所述第三方支付服务器发送所述订单；

其中，所述接收第三方支付服务器返回的订单处理状态，包括：

所述后端服务器接收所述第三方支付服务器返回的订单处理状态。

3.根据权利要求2所述的反馈方法，其特征在于，所述在确定所述订单处理状态为处理中时，经过预设的延迟时间再向所述第三方支付服务器发送查询消息，包括：

所述后端服务器在确定所述订单处理状态为处理中时，向队列服务器发送所述订单处理状态；

所述队列服务器将所述订单处理状态放在延迟队列中；

所述队列服务器在所述预设的延迟时间之后将所述订单处理状态从所述延迟队列移到正常队列中；

消费队列服务器从所述正常队列中获取所述订单处理状态；

所述消费队列服务器根据所述订单处理状态向所述后端服务器发送查询请求消息；

所述后端服务器根据所述查询请求消息向所述第三方支付服务器发送所述查询消息。

4.根据权利要求3所述的反馈方法，其特征在于，在所述后端服务器根据所述查询请求消息向所述第三方支付服务器发送所述查询消息之后，还包括：

所述后端服务器接收所述第三方支付服务器返回的查询的订单处理状态；

所述后端服务器向所述消费队列服务器发送所述查询的订单处理状态；

所述消费队列服务器在确定所述查询的订单处理状态为处理中时，向所述队列服务器发送所述查询的订单处理状态；

所述队列服务器将所述查询的订单处理状态放在所述延迟队列中。

5.根据权利要求4所述的反馈方法，其特征在于，还包括：

所述消费队列服务器在确定所述查询的订单处理状态为成功或失败时，向第二商户服务器发送通知，所述通知用于指示所述订单处理状态为成功或失败。

6.根据权利要求3所述的反馈方法，其特征在于，在所述后端服务器根据所述查询请求消息向所述第三方支付服务器发送所述查询消息之后，还包括：

所述后端服务器接收所述第三方支付服务器返回的查询的订单处理状态；

所述后端服务器在确定所述查询的订单处理状态为处理中时，向所述队列服务器发送所述查询的订单处理状态；

所述队列服务器将所述查询的订单处理状态放在所述延迟队列。

7.根据权利要求6所述的反馈方法，其特征在于，还包括：

所述后端服务器在确定所述查询的订单处理状态为成功或失败时，向所述队列服务器发送所述查询的订单处理状态；

所述队列服务器将所述查询的订单处理状态放在所述正常队列。

8.一种聚合支付平台，其特征在于，所述聚合支付平台接收第三方支付服务器返回的订单处理状态，其中所述订单处理状态为成功、失败或处理中，并且在确定所述订单处理状态为处理中时，经过预设的延迟时间再向所述第三方支付服务器发送查询消息，所述查询消息用于查询当前的订单处理状态。

9.根据权利要求8所述的聚合支付平台，其特征在于，所述聚合支付平台包括：后端服务器，用于接收第一商户服务器发送的订单，向所述第三方支付服务器发送所述订单，并接收所述第三方支付服务器返回的订单处理状态。

10.根据权利要求9所述的聚合支付平台，其特征在于，所述聚合支付平台还包括：队列服务器和消费队列服务器；

所述后端服务器还在确定所述订单处理状态为处理中时，向所述队列服务器发送所述订单处理状态；

所述队列服务器用于将所述订单处理状态放在所述延迟队列中，在所述预设的延迟时间之后将所述订单处理状态从所述延迟队列移到正常队列中；

所述消费队列服务器用于从所述正常队列中获取所述订单处理状态，并根据所述订单处理状态向所述后端服务器发送查询请求消息，所述后端服务器根据所述查询请求消息向所述第三方支付服务器发送所述查询消息。

11.根据权利要求10所述的聚合支付平台，其特征在于，在所述后端服务器根据所述查询请求消息向所述第三方支付服务器发送所述查询消息之后，所述后端服务器还接收所述第三方支付服务器返回的查询的订单处理状态，并向所述消费队列服务器发送所述查询的订单处理状态；

所述消费队列服务器还在确定所述查询的订单处理状态为处理中时，向所述队列服务器发送所述查询的订单处理状态；

所述队列服务器还将所述查询的订单处理状态放在所述延迟队列中。

12.根据权利要求11所述的聚合支付平台，其特征在于，所述消费队列服务器还在确定所述查询的订单处理状态为成功或失败时，向第二商户服务器发送通知，所述通知用于指示所述订单处理状态为成功或失败。

13.根据权利要求10所述的聚合支付平台，其特征在于，在所述后端服务器根据所述查询请求消息向所述第三方支付服务器发送所述查询消息之后，所述后端服务器还接收所述第三方支付服务器返回的查询的订单处理状态，在确定所述查询的订单处理状态为处理中时，向所述队列服务器发送所述查询的订单处理状态；

所述队列服务器还将所述查询的订单处理状态放在所述延迟队列。

14.根据权利要求13所述的聚合支付平台，其特征在于，所述后端服务器还在确定所述查询的订单处理状态为成功或失败时，向所述队列服务器发送所述查询的订单处理状态；

所述队列服务器还将所述查询的订单处理状态放在所述正常队列。