在本发明的一些实施例中，基于前述方案，判断是否存在与所述用户信息对应的客户端，包括：根据所述用户信息判断所述用户是否已经注册过所述客户端；若所述用户未注册过所述客户端，则判断不存在与所述用户信息对应的客户端；若所述用户已注册过所述客户端，则判断存在与所述用户信息对应的客户端。

在本发明的一些实施例中，基于前述方案，还包括：检测是否收到推送失败的提示消息；当收到推送失败的提示消息时，向第一终端发送消息提示用户手动打开客户端，并在客户端启动后再次向客户端推送待支付订单。

在本发明的一些实施例中，基于上述方案，还包括：检测是否收到推送失败的提示消息；当收到推送失败的提示消息时，根据待支付订单中包含的联系方式向用户发送支付信息，以使用户根据支付信息对待支付订单进行支付。

在本发明的一些实施例中，基于前述方案，所述支付信息包括：所述客户端的支付链接和/或下载链接；其中，所述支付链接用于链接第三方支付平台进行支付；所述客户端的下载链接用于下载所述客户端进行支付。

在本发明的一些实施例中，基于上述方案，还包括：接收客户端针对所述待支付订单返回的支付结果；将所述支付结果推送至所述第一终端显示。

在本发明的一些实施例中，基于前述方案，还包括：与所述第一终端保持长连接；在接收到所述客户端返回的支付结果后，通过与所述第一终端的长连接，将所述支付结果推送至所述第一终端。

根据本发明实施例的第二方面，提供了一种支付装置，包括：获取单元，用于获取第一终端发送的待支付订单，并获取与所述待支付订单关联的用户信息；推送单元，用于根据所述用户信息将所述待支付订单推送至与所述用户信息对应的第二终端上的客户端，以使用户能够基于所述第二终端上的客户端对所述待支付订单进行支付。

根据本发明实施例的第三方面，提供了一种计算机可读介质，其上存储有计算机程序，其中，当该程序被处理器执行时，实现上述第一方面所述的支付方法。

根据本发明实施例的第四方面，提供了一种电子设备，包括：一个或多个处理器；存储设备，用于存储一个或多个程序，其中，当所述一个或多个程序被所述一个或多个处理器执行时，所述一个或多个处理器实现上述第一方面所述的支付方法。

本发明实施例提供的技术方案，通过获取第一终端发送的待支付订单，并获取与该待支付订单关联的用户信息，从而根据该用户信息将该待支付订单推送至与该用户信息对应的第二终端上的客户端，使得用户在使用第二终端支付第一终端上提交的订单时，无需进行额外的繁琐操作，只需打开第二终端上的客户端即可完成支付，从而有效提高了支付速度，有利于提升用户体验。

应当理解，前述一般描述和以下详细描述仅是示例性和解释性的，并且不限制本发明。

附图简要说明

此处的附图被纳入说明书并构成说明书的一部分，示出了与本发明相一致的实施例，并与说明书一起用于解释本发明的原理。显然，下面所描述的附图只是本发明的一些实施例，对于本领域的普通技术人员来说，无需付出创造性劳动，就可以基于这些附图获得其他的附图。在附图中：

图1示意性示出了根据本发明第一实施例的支付方法的流程图；

图2示意性示出了根据本发明第二实施例的支付方法的流程图；

图3为本发明实施例中PC网页上呈现的产品信息示意图；

图4示出了根据本发明的实施例的在手机应用程序上显示的待支付订单的示意图；

图5示意性地示出了根据本发明的实施例的支付装置的框图；

图6示意性示出了适合实施本发明实施例的电子设备的计算机系统的结构示意图。

详细描述

现在将参考附图更全面地描述示例实施例。然而，示例实施例可以以多种形式实施，不应被解释为限于本文所述的示例；相反，提供这些实施例是为了使本发明更加全面和完整，并向本领域技术人员充分传达示例实施例的概念。

此外，所描述的特征、结构或特性可以以任何合适的方式组合在一个或多个实施例中。在以下描述中，提供了很多具体细节，以便全面理解本发明的实施例。然而，本领域技术人员将理解，本发明的技术方案可以在没有这些具体细节的情况下实施，或者可以采用其他方法、部件、装置、步骤等。在其他情况下，未详细示出或描述已知的方法、装置、实现或操作，以避免模糊本发明的各个方面。

附图中所示的框图仅仅是功能实体，并不一定对应于物理上独立的实体。也就是说，这些功能实体可以以软件形式实现，也可以在一个或多个硬件模块或集成电路中实现，也可以在不同的网络和/或处理器设备和/或微控制器设备中实现。

附图中所示的流程图仅为示例，并不一定包含所有内容和操作/步骤，也不一定必须按照所述顺序执行。例如，某些操作/步骤可以分解，某些操作/步骤可以组合或部分组合，因此实际执行顺序可能会根据实际情况而改变。

图1示意性示出了本发明第一实施例的支付方法的流程图；图2示意性示出了本发明第二实施例的支付方法的流程图。图1和图2所示的支付方法的执行主体可以是服务器或者其他具有通讯功能的设备。为了便于说明，以图1和图2所示的支付方法的执行主体为例。

参见图1，本发明第一实施例提供的一种支付方法，包括：

步骤s102，获取第一终端发送的待支付订单，并获取与该待支付订单关联的用户信息。

在本发明的一个实施例中，与待支付订单关联的用户信息可以是提交该待支付订单的用户的信息。需要说明的是，第一终端发送的待支付订单可以是既包含产品信息又包含对应的支付信息的订单，也可以是包含支付信息但不包含产品信息的订单。

其中，服务器端获取上述用户信息的过程可以是，一方面，获取第一终端向服务器端发送的用户信息。例如，用户在第一终端登录并下单后，第一终端将登录用户的信息发送给服务器端；另一方面，也可以是服务器端接收到第一终端发送的待支付订单后，根据待支付订单所包含的信息获取关联的用户信息。例如，若用户未在第一终端登录并下单，则服务器端在获取待支付订单后，根据待支付订单所包含的信息自动创建用户账户，并将其作为与待支付订单关联的用户信息；另一方面，服务器端还可以接收第一终端发送的与待支付订单关联的用户标识，然后根据用户标识与用户信息的对应关系获取相应的用户信息。例如，用户通过第三方账号（如微博、微信等）登录并下单后，服务端根据第三方账号的信息映射获取用户信息。

步骤s104，根据用户信息，将待支付订单推送至与该用户信息对应的第二终端上的客户端，以使用户基于第二终端上的客户端对待支付订单进行支付。

根据本发明的一个示例性实施例，步骤s104可以具体包括：检测与客户端建立的长连接的状态；若与客户端建立的长连接处于维持状态，则通过与客户端的长连接向客户端推送待支付订单；若与客户端建立的长连接处于断开状态，则通过第二终端的操作系统对应的推送通道向客户端推送待支付订单。

需要说明的是，当客户端启动时，客户端会与服务器建立长连接，以便服务器向客户端推送信息，当然第一终端也可以与服务器建立长连接，以便向服务器发送相关信息。

本发明实施例中，若客户端或第一终端与服务器建立长连接，则可以通过心跳包的方式与服务器维持长连接，如心跳包发送周期为120~300秒，除心跳包外所有需要响应的协议包若在6~15秒内没有响应则需要重新发送，周期为1~3次。当服务器在5分钟内没有收到客户端或第一终端上传的数据包时，视为与客户端或第一终端的长连接断开。还需注意的是，在发送任何需要响应的协议包时，发送包和响应包的协议号必须一致，每个协议包包含固定的包头和包尾，协议中具体描述内容的前两个字节记录描述内容的长度，以保证协议包中数据的完整性。

图1所示实施例的支付方法，使得用户无需进行额外繁琐的操作，即可使用第二终端对第一终端上提交的订单进行支付，只需要在第二终端上打开客户端即可完成支付，有效提高了支付速度，有利于提升用户体验。

第一终端可以为PC（个人计算机，又称电脑），第二终端可以为移动终端，例如手机、平板电脑、智能穿戴设备等。基于图1所示的支付方式，用户在PC上提交的订单可以基于移动终端进行快速支付，有利于提高用户体验。

基于图1所示的支付方法，如图2所示，本发明实施例二提供的支付方法，在图1所示的步骤s104之前还包括：

步骤s103，判断是否存在与该用户信息对应的客户端，当判断存在与该用户信息对应的客户端时，执行步骤s104，即根据该用户信息向该客户端推送待支付订单。

在本发明的一个实施例中，基于前述方案，还包括：当判断不存在与该用户信息对应的客户端时，执行步骤s105，即根据该待支付订单包含的联系方式向该用户发送支付信息，以使用户根据该支付信息对该待支付订单进行支付。

根据本发明的一个示例性实施例，所述联系方式包括：手机号码、邮箱账号、即时通讯软件账号。所述支付信息包括：所述客户端的支付链接和/或下载链接；其中，所述支付链接用于链接第三方支付平台进行支付；所述客户端的下载链接用于下载所述客户端进行支付。

在本发明的一个实施例中，步骤s103具体包括：根据用户信息判断用户是否注册过该客户端；若用户未注册过该客户端，则判断不存在与该用户信息对应的客户端；若用户已注册过该客户端，则判断存在与该用户信息对应的客户端。

需要说明的是，当用户注册客户端后，服务器会保存该用户的信息，因此，当服务器接收到第一终端发送的待支付订单并获取与该待支付订单关联的用户信息时，可以根据该用户信息将该待支付订单推送至对应的客户端。

在图2所示的支付方式中，当服务器获取第一终端发送的待支付订单，并获取与该待支付订单关联的用户信息时，判断是否存在与该用户信息对应的客户端，以便根据判断结果选择合适的支付方式。具体地，当存在与该用户信息对应的客户端时，直接将待支付订单推送至与该用户信息对应的客户端，以便用户直接通过该客户端进行支付，方便快捷。当不存在与该用户信息对应的客户端时，可根据待支付订单中包含的联系方式向用户发送支付信息，协助用户进行支付。

在本发明的一个具体实施例中，第一终端可以为PC端，第二终端可以为移动终端。若用户已经在移动终端上注册了客户端，则服务器端在获取待支付订单和用户信息时，会直接将待支付订单推送到移动终端上的客户端，以便用户通过客户端进行快捷支付。若用户尚未在移动终端上注册客户端，则服务器端在获取待支付订单和用户信息时，可以根据待支付订单中包含的手机号（当然也可以是邮箱账号、即时通讯账号等其他联系方式）向用户发送支付信息，以便用户也可以在移动终端上进行支付。例如，可以向用户发送短信，短信中包含上述客户端的下载地址，以便用户根据下载地址下载客户端，然后进行注册支付；或者短信中还可以包含第三方支付平台（如微信支付平台、支付宝平台、话费支付平台等）的链接地址，以便用户点击该链接地址即可跳转到第三方支付平台进行支付。可见，图2所示实施例的技术方案可以通过不同的方式实现移动支付，有利于提高用户体验。

此外，在本发明的一些实施例中，在图1和图2所示的步骤s104之后，还可以检测是否收到推送失败的提示消息。若收到推送失败的提示消息，则本发明提出如下解决方案：

解决方案 1：

当收到推送失败的提示信息时，向第一终端发送提示用户手动打开客户端的消息，待客户端启动后再次向客户端推送待支付的订单。

需要说明的是，在第二终端上将待支付订单推送到客户端时，可能由于第二终端的操作系统或其他原因，无法将待支付订单推送到客户端，因此，服务器可以向第一终端发送提示消息，让用户手动打开客户端，客户端启动后会与服务器建立连接（最好是长连接），服务器再将待支付订单推送到客户端，这样，用户手动打开客户端后，客户端即可显示待支付订单，然后用户直接在客户端上支付即可，方便快捷。

解决方案 2：

当收到推送失败的提示消息时，根据待支付订单中包含的联系方式，向用户发送支付信息，以便用户根据支付信息对待支付订单进行支付。

需要说明的是，在向客户端推送待支付订单时，可能由于与客户端通讯失败或者第二终端安装的客户端已被卸载等原因，导致待支付订单无法推送至客户端，因此可以根据待支付订单中包含的联系方式，向用户发送支付信息，协助用户进行支付。

在本发明的一个实施例中，这里的支付信息可以包括：支付链接和/或客户端的下载链接；其中，支付链接用于链接到第三方支付平台进行支付；客户端的下载链接用于下载支付客户端。

此外，在本发明的一些实施例中，基于前述方案，还包括：接收客户端针对待支付的订单返回的支付结果；将支付结果推送至第一终端进行显示，以便用户获知支付是否成功。

进一步地，服务器端可以与第一终端保持长连接，当服务器端接收到上述客户端返回的支付结果时，通过服务器端与第一终端之间的长连接将支付结果推送给第一终端，以便第一终端及时向用户提示支付结果，例如，第一终端可以同步跳转至支付成功页面提示用户。

下面以第一终端为PC网页端，第二终端为手机端为例，详细说明本发明的具体实施例。需要说明的是，手机端上安装有相应的app(应用)客户端。具体流程如下：

用户在PC网页上选定合适的商品后，按照页面提示选择手机快捷支付选项，进入待支付订单的PC网页界面。

当PC网页进入支付界面时，当前界面会通过弹窗告知用户本次支付流程已经转至手机APP客户端（此处仅为举例，不作具体限定），用户可以选择继续通过APP客户端完成后续支付操作。当然，用户也可以选择继续在PC网页上完成支付。

当用户选择移动终端快捷支付选项时，PC网页会将当前用户的用户信息、待支付的产品信息、支付信息传输给服务器，并启动与服务器的长连接和保持长连接，以便随时监控服务器的返回信息。需要说明的是，PC网页在将当前用户的用户信息、待支付的产品信息、支付信息传输给服务器之前，也可以先与服务器建立长连接。

在本发明的一个实施例中，上述服务器可以基于 (一种Java开源框架) 构建，PC上的浏览器可以利用 (一种快速简洁的框架) 与服务器实现HTTP长连接，或者通过调用数据通讯相关的 (API即应用程序编程接口) 向服务器发送信息。

当服务器接收到PC网页的信息后，会将符合移动支付要求的相关数据推送给手机APP客户端。在推送到APP的过程中，有两种不同的处理方案。一种是当前手机APP客户端与服务器之间的长连接处于保持状态；另一种是当前手机APP客户端与服务器之间的长连接处于断开状态。下面分别对这两种情况进行描述：

手机APP客户端与服务端的长连接维护：

当手机APP客户端与服务端保持长连接时，服务端通过长连接直接推送支付信息，手机APP收到支付信息后会根据当前APP是否处于展现态（展现态即前台运行状态）来决定如何处理该信息。

具体地，若当前APP处于非显示状态（非显示状态即后台运行状态），则该信息会显示在手机通知栏中，用户通过点击通知栏中的信息打开APP，并自动跳转至支付界面；若当前APP处于显示状态，则根据服务器推送的支付信息，向用户呈现相应的支付提示，提示包括但不限于弹窗信息（如在当前APP的显示界面显示弹窗信息）、角标提醒（如在当前APP的显示界面的通知消息图标处进行角标提醒）、页面自动跳转显示等，以便用户根据支付提示进行支付操作。

手机APP客户端与服务端长连接断开：

当手机APP客户端与服务器的长连接断开时，服务器会根据手机类型选择与手机厂商相关的推送通道，比如小米手机、iOS系统的APNS通道，进行推送操作。

若推送成功，支付信息会显示在手机通知栏，用户点击通知栏信息打开APP会自动跳转至支付界面。若服务器收到推送失败的消息，PC网页会收到服务器的推送消息，提醒用户当前支付操作被阻止，需要用户手动点击启动APP才能完成后续支付操作。

在本发明的一个实施例中，用户在手机APP上进行支付操作的过程会通过APP与服务器之间的长连接通道实时传输到服务器，服务器会根据PC网页与服务器之间的长连接通道实时传输到PC网页。当用户在手机APP上完成支付后，PC网页会自动跳转至支付成功界面，给予用户良好的信息反馈。

需要注意的是，为了保证服务器能及时将支付结果传输给PC网页，PC网页需要与服务器保持长连接，也就是说，只要PC网页接口不关闭，PC网页就会与服务器保持长连接。

可以看出，本发明实施例的快捷支付方案不需要用户进行扫描二维码等复杂操作，用户只需要打开手机APP即可进入支付页面进行支付，整体流程更加便捷、人性化，有利于提升用户体验。如图3所示，用户在PC网页上选择好合适的商品后，根据页面上的提示，选择“快捷支付”选项，然后打开手机APP，APP会直接呈现需要支付的订单信息如图4所示，然后用户在手机APP上即可完成支付。

需要说明的是，本发明上述具体实施例适用于用户已注册移动应用程序且该应用程序安装在手机上的应用场景。若用户未注册移动应用程序，则服务器可以根据待支付订单中包含的用户联系方式向用户发送支付信息，使得用户也能够根据支付信息完成移动支付。

例如，服务器根据待支付订单中包含的手机号向用户发送支付短信(当然也可以是其他联系方式如邮箱账号、即时通讯账号等)，短信中包含APP的下载地址，以便用户根据下载地址下载APP然后进行注册支付；或者支付短信中还可以包含第三方支付平台的链接地址(如微信支付平台、支付宝平台、话费支付平台等)，以便用户点击链接地址链接到第三方支付平台进行支付。

图5示意性地示出了根据本发明的实施例的支付装置的框图。

参见图5，本发明实施例提供的一种支付设备500，包括：获取单元502、推送单元504。

具体地，获取单元502用于获取第一终端发送的待支付订单，并获取与该待支付订单关联的用户信息；推送单元504用于根据该用户信息，将该待支付订单推送至与该用户信息对应的第二终端上的客户端，以便用户在第二终端上基于该客户端对该待支付订单进行支付。

在本发明的一些实施例中，基于前述方案，推送单元504被配置为：检测与客户端建立的长连接的状态；若与客户端建立的长连接处于维持状态，则通过与客户端的长连接将待支付订单推送给客户端；若与客户端建立的长连接处于断开状态，则通过与第二终端的操作系统对应的推送通道将待支付订单推送给客户端。

在本发明的一些实施例中，在上述方案的基础上，还包括：判断单元，用于判断是否存在与所述用户信息对应的客户；推送单元504，用于当判断单元确定存在与所述用户信息对应的客户时，向所述客户推送所述待支付订单。

在本发明的一些实施例中，基于前述方案，还包括：第一发送单元，用于当判断单元判断不存在与用户信息对应的客户时，根据待支付订单中包含的联系方式向用户发送支付信息，以便用户根据支付信息对待支付订单进行支付。