一种生成支付页面的方法、系统及车载终端与流程

本申请涉及移动支付领域，具体涉及一种生成支付页面的方法、系统及车载终端。

背景技术：

随着智能移动终端的广泛应用，移动支付已是如今最受欢迎的支付方式之一。当前，用户在车载终端应用进行消费购物或购买汽车服务时，车载终端应用将支付链接转化为支付二维码，之后，用户需要打开移动终端，扫描对应的支付二维码，在移动终端显示支付页面后，用户通过支付页面完成付款。在上述付款过程中，用户需要操作移动终端，通过扫描二维码来获取支付页面，操作流程不够简化，使用不够便捷。

技术实现要素：

本申请的目的在于，提供一种生成支付页面的方法、系统及车载终端，其可以解决上述技术问题，可以通过移动终端直接生成车载终端的订单的支付页面，省去扫描二维码的步骤，简化用户的操作流程。

为解决上述技术问题，本申请涉及一种生成支付页面的方法，包括：

车载终端根据待支付订单向服务器发送用于获取支付链接的第一请求；

所述服务器根据所述第一请求将所述待支付订单的支付链接发送给所述车载终端，以使得所述车载终端将所述支付链接发送给移动终端；

所述移动终端根据所述支付链接生成支付页面。

其中，车载终端根据待支付订单向服务器发送用于获取支付链接的第一请求的步骤，包括：

所述车载终端获取所述待支付订单的订单信息；

根据所述订单信息生成用于获取所述支付链接的第一请求；

将所述第一请求发送至所述服务器。

其中，服务器根据所述第一请求将所述待支付订单的支付链接发送给所述车载终端的步骤，包括：

所述服务器根据所述第一请求包含的待支付订单的订单信息，向第三方支付平台发送用于获取支付链接的第二请求；

所述第三方支付平台根据所述第二请求创建支付链接，并将所述支付链接发送给所述服务器，以使得所述服务器将所述支付链接发送给所述车载终端。

其中，服务器根据所述第一请求包含的待支付订单的订单信息，向第三方支付平台发送用于获取支付链接的第二请求的步骤，包括：

所述服务器从所述第一请求中获取所述待支付订单的订单信息；

根据所述订单信息创建支付请求参数；

根据所述支付请求参数，向对应的第三方支付平台发送用于获取支付链接的第二请求。

其中，移动终端根据所述支付链接生成支付页面的步骤，包括：

所述移动终端接收所述车载终端的支付请求，所述支付请求包含所述支付链接；

基于所述支付链接对应的支付应用创建所述支付链接对应的支付信息；

基于所述支付应用显示所述支付信息对应的支付页面。

本申请还提供一种生成支付页面的系统，包括：车载终端、服务器和移动终端；

所述车载终端，用于根据待支付订单向所述服务器发送用于获取支付链接的第一请求；

所述服务器，用于根据所述第一请求将所述待支付订单的支付链接发送给所述车载终端，以使得所述车载终端将所述支付链接发送给所述移动终端；

所述移动终端，用于根据所述支付链接生成支付页面。

本申请还提供第二种生成支付页面的方法，应用于车载终端，其特征在于，包括：

根据待支付订单向服务器发送用于获取支付链接的第三请求；

接收所述服务器根据所述第三请求发送的所述待支付订单的支付链接，并将所述支付链接发送给移动终端，以使得所述移动终端根据所述支付链接生成支付页面。

在第二种生成支付页面的方法中，根据待支付订单向服务器发送用于获取支付链接的第三请求的步骤，包括：

获取所述待支付订单的订单信息；

根据所述订单信息生成用于获取支付链接的第三请求并发送至服务器。

其中，服务器发送的所述支付链接为第三方支付平台创建的支付链接，所述支付链接与所述移动终端上安装的支付应用对应。

本申请还提供了一种车载终端，其特征在于，包括：存储器和处理器；

所述存储器存储有至少一条程序指令；

所述处理器通过加载并执行所述至少一条程序指令以实现如上所述的应用于车载终端的生成支付页面的方法。

本申请的生成支付页面的方法、系统及车载终端，该生成支付页面的方法包括：车载终端根据待支付订单向服务器发送用于获取支付链接的第一请求；服务器根据第一请求将待支付订单的支付链接发送给车载终端，以使得车载终端将支付链接发送给移动终端；移动终端根据支付链接生成支付页面。通过这样的方式，本申请可以通过移动终端直接生成车载终端的订单的支付页面，省去扫描二维码的步骤，简化了用户的操作流程，使用便捷。

上述说明仅是本申请技术方案的概述，为了能够更清楚了解本申请的技术手段，而可依照说明书的内容予以实施，并且为了让本申请的上述和其他目的、特征和优点能够更明显易懂，以下特举较佳实施例，并配合附图，详细说明如下。

附图说明

图1是根据第一实施例示出的一种生成支付页面的方法的流程示意图；

图2是根据第一实施例示出的一种生成支付页面的方法在一实际应用的原理示意图；

图3是根据第二实施例示出的一种生成支付页面的系统的结构示意图；

图4是根据第三实施例示出的一种生成支付页面的方法的流程示意图；

图5是根据第四实施例示出的一种一种车载终端的结构示意图。

具体实施方式

以下由特定的具体实施例说明本申请的实施方式，熟悉此技术的人士可由本说明书所揭露的内容轻易地了解本申请的其他优点及功效。

在下述描述中，参考附图，附图描述了本申请的若干实施例。应当理解，还可使用其他实施例，并且可以在不背离本申请的精神和范围的情况下进行机械组成、结构、电气以及操作上的改变。下面的详细描述不应该被认为是限制性的，这里使用的术语仅是为了描述特定实施例，而并非旨在限制本申请。

第一实施例

图1是根据第一实施例示出的一种生成支付页面的方法的流程示意图。请参考图1，本实施例的生成支付页面的方法，包括以下步骤：

步骤110，车载终端根据待支付订单向服务器发送用于获取支付链接的第一请求。

其中，车载终端支持tbox，可以接入网络。在车载终端与服务器通信基于http协议，通过三次握手建立车载终端与服务器连接后，车载终端根据支付订单向服务器发送http请求报文，即用于获取支付链接的第一请求。

在一实施方式中，步骤110中，服务器根据第一请求将待支付订单的支付链接发送给车载终端的步骤，具体包括：

车载终端获取待支付订单的订单信息；

根据订单信息生成用于获取支付链接的第一请求；

将第一请求发送至服务器。

在一应用场景中，在车载终端与服务器建立连接后，用户通过车载终端进行消费购物。在用户完成购买并在车载终端提交订单后，车载终端将获取到对应的待支付订单信息，其中，待支付订单信息包括订单的编号、名称、金额等信息。之后，车载终端根据待支付订单的订单信息生成http请求报文，并将请求报文发送至服务器。

实际实现时，用户在车载终端上提交订单时，可以选择用于支付此次订单的支付方式，例如：支付宝、微信、银联等。

步骤120，服务器根据第一请求将待支付订单的支付链接发送给车载终端，以使得车载终端将支付链接发送给移动终端。

其中，服务器集成了第三方支付平台的java服务端sdk能力。服务器根据第一请求，通过调用第三方支付平台sdk能力，获取到待支付订单的支付链接，接着，将包含支付链接的http请求报文作为应答报文传递给车载终端。

在一实施方式中，服务器根据第一请求将待支付订单的支付链接发送给车载终端的步骤，具体包括：

服务器根据第一请求包含的待支付订单的订单信息，向第三方支付平台发送用于获取支付链接的第二请求；

第三方支付平台根据第二请求创建支付链接，并将支付链接发送给服务器，以使得服务器将支付链接发送给车载终端。

其中，服务器从第一请求中获取待支付订单的订单信息，其中，订单信息包括订单的编号、名称、金额等信息，此外还可以包括已确定用于支付待支付订单的支付方式，例如：支付宝、微信、银联等。

以支付方式为支付宝为例，服务器根据获取到的待支付订单的订单信息生成alipaytradeapppayrequest，即创建支付宝订单请求参数，服务器根据请求参数通过调用支付宝sdk中alipayclient.sdkexecute(request)来生成支付宝待支付的http请求报文，即用于获取支付链接的第二请求。服务器将用于获取支付链接的第二请求发送至支付宝平台之后，支付宝平台根据第二请求创建支付链接，通过服务器将包含支付链接的http请求报文作为应答报文传递给车载终端。

同样地，若订单信息中，已确定用于支付待支付订单的支付方式为微信或银联，服务器将向对应微信或银联的支付平台发送用于获取支付链接的第二请求；对应支付方式的支付平台根据第二请求创建支付链接，并将支付链接发送给服务器，以使得服务器将支付链接发送给车载终端。实际实现时，如用户没有选择支付方式，则服务器可以使用默认的支付方式创建支付请求参数，进而向对应的第三方支付平台请求支付链接。

步骤130，移动终端根据支付链接生成支付页面。

其中，移动终端和车载终端建立tcp/ip协议的socket通道，手机连接车载终端应用集成支付宝应用端sdk能力。车载终端应用通过tcp/ip协议与移动终端应用通过三次握手建立连接，之后，移动终端在接收到包含支付链接的支付请求后，移动终端基于支付链接对应的支付应用创建支付链接对应的支付信息，例如，对应的支付应用为支付宝，那么，移动终端将通过支付宝的sdk能力，将支付请求生成prepayinfo对象，接着，通过调用paytask.pay方法拉起支付宝支付页面。之后，用户通过支付页面，完成待支付订单的支付。

同样地，若支付链接对应的支付应用为微信或银联等，移动终端将通过对应的微信或银联的sdk能力，来拉起对应支付应用的支付页面。

图2是根据第一实施例示出的一种生成支付页面的方法在一实际应用的原理示意图，其中，本实施例以支付方式为支付宝为例，移动终端以手机端为例，对本申请的生成支付页面的方法的原理进行说明。

如图2所示，车机云端即服务器，集成了支付宝java服务端sdk能力，也即集成支付宝云端的sdk能力，车机端即车载终端，车机端支持tbox可以接入网络，手机端和车机端建立tcp/ip协议的socket通道，手机端和车机端集成支付宝应用端的sdk能力。

在车机端与车机云端通信基于http协议，通过三次握手建立车机端与服务器连接后，车机端将订单信息生成http请求报文，之后，向车机云端发起http请求，即发送用于获取支付链接的第一请求。车机云端在接受到车机端应用请求后，从待支付订单的订单信息中获取到订单的编号、名称、金额等，根据获取到的订单信息生成alipaytradeapppayrequest，即创建支付宝订单请求参数，接着，调用支付宝sdk中alipayclient.sdkexecute(request)，向支付宝云端发起http请求，即用于获取支付链接的第二请求。然后，支付宝云端根据第二请求生成支付宝待支付订单的支付链接。接着，返回支付链接至车机云端，由车机云端返回支付链接至车机端。通过这样的方式，将包含支付链接的http请求报文作为应答报文通过车机云端传递给车机端，之后，车机端将支付链接发送至手机端，其中，车载终端应用通过tcp/ip协议与手机端应用通过三次握手已建立连接。手机端应用接到支付宝待支付的http请求报文,通过支付宝sdk能力将支付宝待支付的http请求生成prepayinfo对象，创建支付请求，通过调用paytask.pay方法拉起支付宝支付页面，从而，显示支付页面。

通过本实施例的方式，商家不需要接入服务器的支付系统，通过车载终端将现有主流的支付方式的支付链接发送给移动终端，以使得移动终端根据支付链接生成支付页面。通过这样的方式，可以不需要开发新的支付能力或因为开发新的支付能力而需要申请支付牌照，节约了时间和开发成本。同时，不同于现有的通过扫描二维码来获取支付页面的方法，通过本申请的方式，用户不需要扫描二维码，就可以接收到支付页面，进而，完成支付动作，简化了用户操作，提高了便捷性。

第二实施例

图3是根据第二实施例示出的一种生成支付页面的系统的结构示意图。请参考图3，本实施例的生成支付页面的系统，包括：车载终端220、服务器230和移动终端210。

车载终端220，用于根据待支付订单向服务器230发送用于获取支付链接的第一请求；

服务器230，用于根据第一请求将待支付订单的支付链接发送给车载终端220，以使得车载终端220将支付链接发送给移动终端210；

移动终端210，用于根据支付链接生成支付页面。

在一实施方式中，车载终端220用于根据待支付订单向服务器230发送用于获取支付链接的第一请求的步骤，包括：

车载终端220获取待支付订单的订单信息；

根据订单信息生成用于获取支付链接的第一请求；

将第一请求发送至服务器230。

在一实施方式中，服务器230用于根据第一请求将待支付订单的支付链接发送给车载终端220的步骤，包括：

服务器230根据第一请求包含的待支付订单的订单信息，向第三方支付平台发送用于获取支付链接的第二请求；

第三方支付平台根据第二请求创建支付链接，并将支付链接发送给服务器230，以使得服务器230将支付链接发送给车载终端220。

其中，服务器230根据第一请求包含的待支付订单的订单信息，向第三方支付平台发送用于获取支付链接的第二请求的步骤，包括：

服务器230从第一请求中获取待支付订单的订单信息；

根据订单信息创建支付请求参数；

根据支付请求参数，向对应的第三方支付平台发送用于获取支付链接的第二请求。

在一实施方式中，移动终端230用于根据支付链接生成支付页面的步骤，包括：

移动终端230接收车载终端220的支付请求，支付请求包含支付链接；

基于支付链接对应的支付应用创建支付链接对应的支付信息；

基于支付应用显示支付信息对应的支付页面。

本实施例中的移动终端210、车载终端220和服务器230的具体工作流程详见第一个实施例的描述，在此不再赘述。

第三实施例

图4是根据第三实施例示出的一种生成支付页面的方法的流程示意图。请参考图4，本实施例的生成支付页面的方法，应用于车载终端，包括以下步骤：

步骤310，根据待支付订单向服务器发送用于获取支付链接的第三请求。

其中，车载终端支持tbox，可以接入网络。在车载终端与服务器通信基于http协议，通过三次握手建立车载终端与服务器连接后，车载终端根据支付订单向服务器发送http请求报文，即用于获取支付链接的第三请求。

在一实施方式中，步骤310，根据待支付订单向服务器发送用于获取支付链接的第三请求的步骤，具体包括：

获取待支付订单的订单信息；

根据订单信息生成用于获取支付链接的第三请求并发送至服务器。

在一应用场景中，在车载终端与服务器建立连接后，用户通过车载终端进行购物消费。在用户完成购物并在车载终端提交订单后，车载终端将获取到对应的待支付订单信息，其中，待支付订单信息包括订单的编号、名称、金额等信息。之后，车载终端根据待支付订单的订单信息生成http请求报文，并将http请求报文发送至服务器。

实际实现时，用户在车载终端上提交订单时，可以选择用于支付此次订单的支付方式，例如：支付宝、微信、银联等。

步骤320，接收服务器根据第三请求发送的待支付订单的支付链接，并将支付链接发送给移动终端，以使得移动终端根据支付链接生成支付页面。

其中，服务器发送的支付链接为第三方支付平台创建的支付链接，支付链接与移动终端上安装的支付应用对应，且服务器集成了第三方支付平台的java服务端sdk能力。

在一应用场景中，服务器从第三请求中获取待支付订单的订单信息，其中，订单信息包括订单的编号、名称、金额等信息，此外还可以包括已确定用于支付待支付订单的支付方式，例如：支付宝、微信、银联等。

以支付方式为支付宝为例，服务器根据获取到的待支付订单的订单信息生成alipaytradeapppayrequest，即创建支付宝订单请求参数，服务器根据请求参数通过调用支付宝sdk中alipayclient.sdkexecute(request)来生成支付宝待支付的http请求报文。服务器将http请求报文发送至支付宝平台之后，支付宝平台根据http请求报文创建支付链接，通过服务器将包含支付链接的http请求报文作为应答报文传递给车载终端。

同样地，若订单信息中，已确定用于支付待支付订单的支付方式为微信或银联，服务器将向对应微信或银联的支付平台发送创建支付链接的请求，并将支付链接发送给服务器，以使得服务器将支付链接发送给车载终端。实际实现时，如用户没有选择支付方式，则服务器可以使用默认的支付方式创建支付请求参数，以向对应的第三方支付平台请求支付链接。

在一实施方式中，移动终端和车载终端建立tcp/ip协议的socket通道，车载终端连接车载终端应用集成支付宝应用端sdk能力。车载终端应用通过tcp/ip协议与移动终端应用通过三次握手建立连接，之后，移动终端在接收到包含支付链接的支付请求后，移动终端基于支付链接对应的支付应用创建支付链接对应的支付信息，例如，对应的支付应用为支付宝，那么，移动终端将通过支付宝的sdk能力，将支付请求生成prepayinfo对象，接着，通过调用paytask.pay方法拉起支付宝支付页面。之后，用户通过支付页面，完成待支付订单的支付。实际实现时，在生成支付页面的过程中，车载终端的屏幕也会提示待支付订单的支付状态，其中，支付状态可以包括待支付、取消支付等确认界面，在用户完成支付后，车载终端的屏幕还可以提示已完成支付的确认界面。

同样地，若支付链接对应的支付应用为微信或银联等，移动终端将通过对应的微信或银联的sdk能力，来拉起对应支付应用的支付页面。

通过上述方式，移动终端直接生成车载终端的订单的支付页面，省去扫描二维码的步骤，简化了用户的操作流程，使用便捷。

第四实施例

图5是根据第四实施例示出的一种车载终端的结构示意图。请参考图5，本实施例车载终端，包括：存储器410和处理器420，存储器410存储有至少一条程序指令，处理器420通过加载并执行至少一条程序指令以实现如下方法：

根据待支付订单向服务器发送用于获取支付链接的第三请求；

接收服务器根据第三请求发送的待支付订单的支付链接，并将支付链接发送给移动终端，以使得移动终端根据支付链接生成支付页面。

在一实施方式中，处理器420根据待支付订单向服务器发送用于获取支付链接的第三请求的步骤，包括：

获取待支付订单的订单信息；

根据订单信息生成用于获取支付链接的第三请求并发送至服务器。

在一实施方式中，处理器420发送的支付链接为第三方支付平台创建的支付链接，支付链接与移动终端上安装的支付应用对应。

本实施例的服务器的具体工作流程详见第一实施例、第三实施例的描述，在此不再赘述。

通过上述移动终端直接生成车载终端的订单的支付页面的方式，省去扫描二维码的步骤，简化了用户的操作流程，使用便捷。

本申请的生成支付页面的方法、系统及车载终端，该生成支付页面的方法包括：车载终端根据待支付订单向服务器发送用于获取支付链接的第一请求；服务器根据第一请求将待支付订单的支付链接发送给车载终端，以使得车载终端将支付链接发送给移动终端；移动终端根据支付链接生成支付页面。通过这样的方式，本申请可以通过移动终端直接生成车载终端的订单的支付页面，省去扫描二维码的步骤，简化了用户的操作流程，使用便捷。

以上所述，仅是本申请的较佳实施例而已，并非对本申请作任何形式上的限制，虽然本申请已以较佳实施例揭露如上，然而并非用以限定本申请，任何熟悉本专业的技术人员，在不脱离本申请技术方案范围内，当可利用上述揭示的技术内容作出些许更动或修饰为等同变化的等效实施例，但凡是未脱离本申请技术方案内容，依据本申请的技术实质对以上实施例所作的任何简单修改、等同变化与修饰，均仍属于本申请技术方案的范围内。