CN106228353A - 一种支付信息处理方法、装置和系统 - Google Patents

Abstract

本发明实施例提供了一种支付信息处理方法、装置和系统，涉及网络技术领域。所述方法包括：根据接收到的订单触发操作，确定进入第一支付模式；获取订单数据和支付界面数据；基于所述订单数据和支付界面数据渲染订单展示页；在接收到支付触发操作后，以第一支付模式对所述订单数据进行支付。本发明实施例降低了支付的步骤，使支付流程缩短，从而可以提高用户体验，避免支付流程过长对支付转化率的影响。

Description

一种支付信息处理方法、装置和系统

技术领域

本发明涉及网络技术领域，特别是涉及一种支付信息处理方法、装置和系统。

背景技术

随着互联网技术的发展，出现了越来越多的与电子商务相关的网站，用户可以在各种电子商务网站中购买各种各样的商品数据。比如在美食网站上购买餐饮店的团购券、购买美食外卖等等。而用户在网站上购买商品数据时，可能需要预先进行支付。

现有技术中，用户在网站的浏览购买页面后，点击购买，则会跳转至订单确认页面。当用户点击确认订单后，则会调起支付页面，而因为支付页面与订单页面是相互独立的，则会跳转至支付页面，然后用户在支付页面中进行支付操作。

但是，上述支付过程中，用户在订单页面点击确认订单想快速支付时，还需要调整到支付页面进行数据加载，数据加载完成后显示支付相关的数据，比如支付的订单信息，支付方式等。因此，上述过程中从确认订单页面进行支付时，需要再次跳转到一个新的页面进行支付方式选择，支付步骤繁琐，并且由于整个支付流程相对较长，影响订单的支付转化率。

发明内容

鉴于上述问题，提出了本发明以便提供一种克服上述问题或者至少部分地解决上述问题的支付信息处理方法、装置和系统。

依据本发明的一个方面，提供了一种支付信息处理方法，包括：

根据接收到的订单触发操作，确定进入第一支付模式；

获取订单数据和支付界面数据；

基于所述订单数据和支付界面数据渲染订单展示页；

在接收到支付触发操作后，以第一支付模式对所述订单数据进行支付。

根据本发明的另一方面，提供了一种支付信息处理方法，包括：

在接收到订单触发操作后，发送订单页展示请求至第一服务器；

接收所述第一服务器根据所述订单页展示请求中的用户信息确定进入第一支付模式的反馈；

向第二服务器发送支付界面展示请求；

接收到第一服务器针对订单页展示请求返回的订单数据和第二服务器针对支付界面展示请求返回的支付界面数据后，基于所述订单数据和支付界面数据渲染订单展示页；

在接收到支付触发操作后，通知第二服务器以第一支付模式对所述订单数据进行支付。

根据本发明的另一方面，提供了一种支付信息处理方法，包括：

在接收到订单触发操作后，发送订单页展示请求至第一服务器，并发送支付界面展示请求至第二服务器；

接收所述第二服务器根据所述支付界面展示请求的用户信息确定进入第一支付模式的反馈；

接收到第一服务器针对订单页展示请求返回的订单数据和第二服务器针对支付界面展示请求返回的支付界面数据后，基于所述订单数据和支付界面数据渲染订单展示页；

在接收到支付触发操作后，通知第二服务器以第一支付模式对所述订单数据进行支付。

根据本发明的另一方面，提供了一种支付信息处理方法，包括：

获取订单数据，并基于所述订单数据渲染订单展示页；

在接收到支付触发操作后，确定进入第一支付模式；

在订单展示页之上生成的一个悬浮框，并将推荐的支付渠道的相关信息在所述悬浮框中展示；

利用所述推荐的支付渠道对所述订单数据进行支付。

根据本发明的另一方面，提供了一种支付信息处理方法，包括：

发送订单页展示请求至第一服务器；

接收第一服务器返回的订单数据，并在订单展示页展示所述订单数据；

在接收到支付触发操作后，向第二服务器发起支付请求；

接收所述第二服务器根据所述支付请求中的用户信息确定进入第一支付模式的反馈，所述反馈包括利用推荐的支付渠道对所述订单数据进行支付时的支付渠道相关信息；

在订单展示页之上生成的一个悬浮框，并将推荐的支付渠道的相关信息在所述悬浮框中展示。

根据本发明的另一方面，提供了一种支付信息处理装置，包括：

支付模式选择模块，用于根据接收到的订单触发操作，确定进入第一支付模式；

数据获取模块，用于获取订单数据和支付界面数据；

同步展示模块，用于基于所述订单数据和支付界面数据渲染订单展示页；

支付模块，用于在接收到支付触发操作后，以第一支付模式对所述订单数据进行支付。

根据本发明的另一方面，提供了一种支付信息处理装置，包括：

订单页展示模块，用于获取订单数据，并基于所述订单数据渲染订单展示页；

支付模式选择模块，用于在接收到支付触发操作后，确定进入第一支付模式；

支付信息展示模块，用于在订单展示页之上生成的一个悬浮框，并将推荐的支付渠道的相关信息在所述悬浮框中展示；

快捷支付模块，用于利用推荐的支付渠道对所述订单数据进行支付。

本发明实施例具备如下优点：

本发明实施例可在用户在购买页面中点击触发进入展示订单展示页的过程后，分别获取业务系统提供的订单数据和支付系统提供的支付界面数据，然后在当前屏幕中可以同时展示所述订单数据和支付界面数据，如此，由于支付界面数据已经展示，用户可以直接利用该支付界面数据进行支付，页面也不会再次跳转，降低了支付的步骤，使支付流程缩短，从而可以提高用户体验，避免支付流程过长对支付转化率的影响。

上述说明仅是本发明技术方案的概述，为了能够更清楚了解本发明的技术手段，而可依照说明书的内容予以实施，并且为了让本发明的上述和其它目的、特征和优点能够更明显易懂，以下特举本发明的具体实施方式。

附图说明

通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本发明的限制。而且在整个附图中，用相同的参考符号表示相同的部件。在附图中：

图1示出了根据本发明一个实施例的一种支付信息处理方法的流程框图；

图1A示出了将订单数据和支付界面数据展示在订单展示页的示例；

图1B示出了将订单数据展示在订单展示页的同时，将支付界面数据展示在悬浮窗的示例；

图2示出了根据本发明一个实施例的另一种支付信息处理方法的流程框图；

图2A为图2实施例的一种支付信息处理方法的交互过程图；

图3示出了根据本发明一个实施例的另一种支付信息处理方法的流程框图；

图3A为图3实施例的一种支付信息处理方法的交互过程图；

图4示出了根据本发明一个实施例的另一种支付信息处理方法的流程框图；

图5示出了根据本发明一个实施例的另一种支付信息处理方法的流程框图；

图5A为图5实施例的一种支付信息处理方法的交互过程图；

图6示出了根据本发明一个实施例的一种支付信息处理装置的结构框图；

图7示出了根据本发明一个实施例的一种支付信息处理系统的结构框图；

图8示出了根据本发明一个实施例的另一种支付信息处理系统的结构框图；

图9示出了根据本发明一个实施例的另一种支付信息处理装置的结构框图；

图10示出了根据本发明一个实施例的另一种支付信息处理系统的结构框图。

具体实施方式

下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例，然而应当理解，可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本公开，并且能够将本公开的范围完整的传达给本领域的技术人员。

实施例一

参照图1，示出了根据本发明一个实施例的一种支付信息处理方法实施例的步骤流程图，具体可以包括如下步骤：

步骤110，根据接收到的订单触发操作，确定进入第一支付模式；

本发明实施例可以应用于各种移动终端的APP(application，应用)中，当然也可以应用于其他类似的终端设备中，本发明实施例不对其加以限制。

在本发明实施例中，用户可以在电子商务网站的商品页面中浏览商品数据，然后点击页面中的购买按钮，该点击页面中的购买按钮则可以理解为上述订单触发操作，从而触发展示订单展示页，此时APP开始进入订单展示页的展示过程，但是还未展示订单展示页。

在本发明实施例中，可以预先设置第一支付模式，该第一支付模式为本发明实施例特设的支付模式，其被触发后，可以不用订单展示页跳转，即可对支付界面数据进行展示。该支付界面数据可以包括支付渠道相关信息，该支付渠道比如各种银行的支付渠道。那么，用户可以预先输入其用户信息，比如用户名和密码等，以登录电子商务网站，然后点击页面中的购买按钮后，则直接进入订单展示页的展示过程。当然如果用户未预先登录，则在用户点击页面中的购买按钮后，可以弹出登录框，然后在用户输入用户名和密码等用户信息后，点击登录，则进入订单展示页的展示过程，此时可以根据接收到的上述订单触发操作，确定进入第一支付模式。

当然，在实际应用中，在本发明实施例中，也可以预先设置多种支付模式，包括第一支付模式，当然还包括普通支付模式。那么，用户可以预先输入其用户信息，比如用户名和密码等，以登录电子商务网站，然后点击页面中的购买按钮后，则直接进入订单展示页的展示过程。当然如果用户未预先登录，则在用户点击页面中的购买按钮后，可以弹出登录框，然后在用户输入用户名和密码等用户信息后，点击登录，则进入订单展示页的展示过程，此时触发判断是否进入第一支付模式。

该普通支付模式为用户在订单展示页中触发展示订单展示页的订单触发操作，按照传统的支付流程，订单展示页跳转至支付页面，然后用户在支付页面中进行支付操作的过程。

从而，本发明实施例可以在订单展示页还未展示时，可以先判断是否进入预设的第一支付模式，还是普通支付模式。

优选的，步骤110包括子步骤A11-A13：

子步骤A11，判断执行所述订单触发操作的用户的用户信息所对应的支付配置信息是否符合预设条件；如果所述用户信息所对应的支付配置信息符合预设条件，则进入子步骤A12。

子步骤A12，需要进入第一支付模式；

其中，如果所述用户信息所对应的支付配置信息不符合预设条件，则需要进入普通支付模式。当然，本发明实施例中，还可以为所述用户信息所对应的支付配置信息不符合预设条件的情况，预先对应其他预设的支付模式，本发明实施例不对其加以限制。

在本发明实施例中，用户在电子商务网站中购买商品时，可以为其用户信息设置支付配置信息，该支付配置信息可以理解为用户给电子商务网站的支付系统的授权信息。

其中，该支付配置信息包括：与所述用户信息所对应的银行卡配置信息。

比如用户M有工商银行的银行卡A，农业银行的银行卡B，招商银行的银行卡C，其可以在电子商务网站的账户系统中授权电子商务网站将M与其银行卡A、银行卡B、银行卡C绑定。当然，还可以为该银行卡A、银行卡B授权开启免密码进行小额支付的权限，比如低于300元，则不用输入密码，直接进行支付。那么用户M的银行卡配置信息包括：(绑定银行卡A，开启免密码许小额支付)、(绑定银行卡B、开启免密码许小额支付)、(绑定银行卡C、未开启免密码许小额支付)。

那么，本发明实施例可以设置判断是否进入第一支付模式的预设条件，比如用户的银行卡配置信息包括绑定至少一张银行卡，以及绑定的银行卡中至少存在一张已开启免密码进行小额支付的权限。

那么对于上述用户M，本发明实施例读取支付配置信息为(绑定银行卡A，开启免密码许小额支付)、(绑定银行卡B、开启免密码许小额支付)、(绑定银行卡C、未开启免密码许小额支付)，其满足上述预设条件，则需要进入第一支付模式。

如果不满足上述预设条件，则进入上述普通支付模式。比如判断当前订单的总额是否超过小额支付，如果超过则可以不进入第一支付模式。当然，也可以只判断用户是否绑定了至少一张银行卡，从而在支付界面中可以直接显示绑定的银行卡，不用跳转至银行卡绑定页面，在支付时可以直接弹出密码输入框进行输入。

需要说明的是在接收到用户触发展示订单展示页的订单触发操作后，确定是否需要进入第一支付模式；如果需要进入第一支付模式，则进入步骤120。

需要说明的是，对于是否进入第一支付模式可以由第一服务器进行判断。其中一种情况是，由客户端在接收到用户触发展示订单展示页的订单触发操作后，发送订单页展示请求至第一服务器。所述第一服务器根据所述订单页展示请求中的用户信息判断是否需要进入第一支付模式，如果需要进入第一支付模式，则返回需要进入第一支付模式的判断结果。然后客户端接收第一服务器返回的判断结果。

客户端在接收到用户触发展示订单展示页的订单触发操作后，发送订单页展示请求至第一服务器。第一服务器收到该订单页展示请求后，首先从订单页展示请求中提取用户信息，比如前述用户M，然后根据该用户信息判断是否需要进入第一支付模式，将是或者否的判断结果返回给客户端。那么该客户端则接收第一服务器返回的判断结果，从而根据该判断结果确定是否进需要进入第一支付模式。如果是，则进入步骤120。如果否，则进入普通支付模式，客户端仅获取订单数据，以该订单数据渲染订单展示页。

当然，实际应用中，由于第一服务器没有用户的支付配置信息，第一服务器可以再向第二服务器发送判断请求，由第二服务器对其进行上述判断，然后返回判断结果给第一服务器，第一服务器再将判断结果返回给客户端。

其中，该客户端可以理解为上述APP。

需要说明的是，在另一种情况中，客户端在接收到用户触发展示订单展示页的订单触发操作后，发送订单页展示请求至第一服务器，并发送支付界面展示请求至第二服务器；所述第二服务器根据所述支付界面展示请求的用户信息判断是否需要进入第一支付模式，如果需要进入第一支付模式，则返回包括支付界面数据的判断结果；客户端接收第二服务器返回的判断结果。

可以理解，在本发明实施例中，对于是否进入第一支付模式可以由第二服务器进行判断。那么对于客户端来说，其在接收到用户触发展示订单展示页的订单触发操作后，发送订单页展示请求至第一服务器，同时需要发送支付界面展示请求至第二服务器。第一服务器收到该订单页展示请求后，返回订单数据给客户端。第二服务器接收到该支付界面展示请求，首先从支付界面展示请求中提取用户信息，比如前述用户M，然后根据该用户信息判断是否需要进入第一支付模式，将是或者否的判断结果返回给客户端。那么该客户端则接收第二服务器返回的判断结果，从而根据该判断结果确定是否进需要进入第一支付模式。如果是，则进入步骤120。如果否，则进入普通支付模式，客户端仅根据该订单数据，以该订单数据渲染订单展示页。

步骤120，获取订单数据和支付界面数据；

在本发明实施例中，在确认进入第一支付模式之后，则可以分别获取订单数据和支付界面数据。

其中，订单数据比如用户购买的商品的商品名称、总价格等信息，当然还可以包括邮寄地址等信息。

支付界面数据可以包括支付控件数据，以及在支付控件中展示的支付渠道等信息。

在实际应用中，可以异步获取订单数据和支付界面数据。

优选的，步骤120包括：

子步骤A41，从第一服务器获取订单数据；

子步骤A42，从第二服务器获取支付界面数据。

在本发明实施例中，订单数据和支付界面数据分属不同的系统负责，比如业务系统的第一服务器提供商品的购买页面、订单展示页面等，支付系统的第二服务器提供支付界面数据。

那么本申请可以分别从第一服务器获取订单数据，从第二服务器获取支付界面数据。当然，上述两个服务器获取数据时，可以采用异步请求获取。

优选的，子步骤A42包括：

子步骤A421，针对预置的支付界面地址生成网页请求并发送至第二服务器；所述第二服务器返回针对所述网页请求的支付界面数据。

本发明实施例能够支持以URL方式调用第二服务器的支付控件，该URL方式基于非入侵式可定制的传送门机制来实现。其具体的过程即针对支付界面地址生成网页请求，然后发送至第二服务器，客户端即可收到第二服务器返回的支付界面数据进行渲染。该支付界面地址由第二服务器维护，其提供支付界面数据。

优选的，子步骤A421包括：

子步骤A4212，启动原生页面框架，由所述原生页面框架针对预置的支付界面地址生成网页请求并发送至第二服务器。

在本发明实施例中，客户端可以为安卓系统的APP，而对于安卓系统，其可以通过native(原生)页面通过URL(Uniform Resoure Locato，统一资源定位符)的方式调用支付控件，如此，业务系统的订单页面可以不依赖支付控件的具体类的声明及实现，耦合低。

具体的，在本发明实施例中，在判断需要进入第一支付模式后，客户端启动native页面，然后由该native页面针对以支付界面数据所对应的URL生成URL请求，然后该URL请求则被发送至第二服务器。那么native页面则可以直接获取到第二服务器返回的支付界面数据。

当然，在实际应用中，本发明实施例可以预先设置支付控件SDK(SoftwareDevelopment Kit,软件开发工具包)，在该支付控件SDK中可以封装支付相关的各种接口，上述URL的调用接口也封装在该SDK中，那么native页面则可以通过调用该SDK的URL请求生成接口，向第二服务器请求支付界面数据。

当然，本发明实施例中，native页面可以先加载订单展示页的框架页面，然后在框架页面中针对预置的支付界面地址生成网页请求并发送至第二服务器，从而获得支付界面数据。其中该框架页面可以有HTML 5(HyperText Markup Language 5，超文本标记语言第5版)

优选的，在本发明实施例中，所述支付界面数据包括根据所述用户对应的支付渠道使用历史记录所推荐的支付渠道。

在本发明实施例中，一个用户在网络中进行购物时，可能会使用各种支付渠道，那么本发明实施例则可以记录该用户使用的支付渠道进行记录。

从而，本发明实施例可以根据该用户对应的支付渠道使用历史记录推荐为其支付渠道，然后在返回支付界面数据时，一并返回该推荐的支付渠道相关信息。

在本发明实施例中，可以根据用户使用支付渠道的使用频率为其推荐支付渠道。比如用户M对各银行卡的使用记录进行统计，其银行卡A的使用了50次，银行卡B使用了30次，银行卡C使用了10次。那么本发明可以以该使用频率为优先级，为用户推荐支付渠道。如在返回支付界面数据时，将银行卡A的相关支付渠道数据返回给客户端。客户端则在支付界面数据对应的支付界面上展示银行卡A的相关信息，该相关信息比如卡号、绑定权限等。

当然，本发明实施例中，还可以采用其他方式为用户推荐支付渠道。

步骤130，基于所述订单数据和支付界面数据渲染订单展示页；

在本发明实施例中，由于可以采用异步的方式分别从第一服务器获取订单数据，从第二服务器获取支付界面数据，那么为了使订单数据的显示和支付界面数据的显示同步，本发明实施例则监控两个数据的同步。在两个数据同步之后，则可以基于所述订单数据和支付界面数据渲染订单展示页，比如在当前显示屏中同时渲染订单数据和支付界面数据。

优选的，步骤130包括：

子步骤A51，在所述订单展示页中展示订单数据和支付界面数据。

如图1A，其为在所述订单展示页中展示订单数据和支付界面数据的一种示例。本发明实施例可以在订单展示页中，以订单数据和支付界面数据为页面元素，将其渲染在订单展示页中进行展示。图1A中S11表示整个页面，整个页面的上半部分S12可以作为支付界面数据的展示部分，下半部分S13可以作为订单数据的展示部分。

当然，本发明实施例中，可以预先规定好订单数据和支付界面数据的展示位置。

优选的，步骤130包括：

子步骤A61，在所述订单展示页中展示订单数据；

子步骤A62，在订单展示页之上生成一个悬浮框，并在所述悬浮框中展示支付界面数据。

在本发明实施例中，可以同步渲染订单展示页和生成悬浮框，从而订单展示页中的订单数据和悬浮框中的支付界面数据可以同步显示。如图1B，其中S21表示整个订单展示页，其中可以展示订单数据，S22为悬浮窗，其中展示支付界面数据。

可以理解，可以预先规定悬浮窗在订单展示页的空白位置显示。

当然，本发明实施例中，该悬浮窗可以拖动，用户可以根据需要拖动悬浮框的位置，方便用户观看被悬浮窗遮挡部分的内容。

在本发明实施例中，订单展示页面中还可以展示可供用户输入或者选择的选项，比如对邮寄地址的输入或者选择。

优选的，还包括：在所述支付界面数据对应的支付界面中，接收用户对支付渠道的选择操作。

在本发明实施例中，在支付界面数据被展示后，其为一个支付界面。如前所述，支付界面数据被渲染后可以得到订单展示页面中的支付界面，或者得到悬浮框中的支付界面。本发明实施例还可以在支付界面中为用户提供支付渠道选择组件，其中可以为用户提供多种支付渠道，同时可以默认一个支付渠道。然后可以接收用户选择的支付渠道。

可以理解，在本发明另一种实施例中，本发明第二服务器返回的支付界面数据可以包括多种支付渠道数据，还可以包括对一个支付渠道的选择数据。从而在对支付界面渲染时，即可将多种支付渠道数据提供给客户端的用户选择。

步骤130，基于所述订单数据和支付界面数据渲染订单展示页；

步骤140，在接收到支付触发操作后，以第一支付模式对所述订单数据进行支付。

在本发明实施例中，用户在点击如图1A中的确认订单的按钮提交订单后，则客户端判断为接收到用户触发进行支付的支付触发操作。此时则以第一支付模式进行支付，在第一支付模式中订单展示页不跳转，直接以支付界面中被确定为进行支付的支付渠道为该订单数据进行支付。其中被确定为进行支付的支付渠道比如推荐的支付渠道，或者用户选择的支付渠道。

特别是，当所述支付渠道为第二服务器为用户推荐的支付渠道，该用户可以只点击一次确认，即可完成支付过程，不用用户选择支付渠道，切换支付方式，使用户支付的操作更简便，操作成本进一步降低。

优选的，在为用户推荐了支付渠道的情况下，步骤140包括：

子步骤141，在第一支付模式中，利用所述推荐的支付渠道对所述订单数据进行支付时，如果支付失败，则根据用户的支付渠道历史记录推荐下一个支付渠道对所述订单数据进行支付，直至支付成功或者直至支付失败且触发停止条件。

在本发明实施例中，在初始情况下，第二服务器为客户端推荐了一个支付渠道，如果用户点击确认订单按钮，则本发明实施例则会直接以该支付渠道进行支付。

但是，在实际应用中可能存在某种情况导致支付失败的，则本发明实施例可以自动为推荐下一个支付渠道进行支付，无需用户手动切换。在实际应用中，可以按照使用频率的优先级推荐下一个支付渠道进行支付。

当然，可以理解，在本发明实施例中，可以从绑定的银行卡并开启免密码进行小额支付的权限的银行卡中进行推荐，因为在订单数据的总额小于该小额支付的上限时，均可以自动完成支付，无需用户选择。比如前述用户M，推荐支付渠道时，会从银行卡A、银行卡B中进行推荐，银行卡C由于没有开启免密码小额支付的权限，该银行卡不能进行无需用户操作进行支付的流程，所以可以不推荐银行卡C。

可以理解在实际应用中，可能存在上述用户M的银行卡A、银行卡B都支付失败的情况，则没有新的银行卡支持自动支付的流程，则触发停止条件。那么在直至支付失败且触发停止条件的情况下，此时可以提示用户自动支付失败，然后为用户提供普通支付流程的切换接口，比如在支付界面中生成普通支付流程切换接口，当用户点击该普通支付流程切换接口，则针对该订单数据进入普通支付流程，如跳转至传统的支付页面，用户在该支付页面中执行支付操作。

优选的，在步骤140之后，还包括：

步骤150，在利用下一个支付渠道对所述订单数据进行支付时，将所述支付渠道相关信息更新在所述支付界面数据所在的支付界面中。

比如对于上述用户M的订单，初始的推荐渠道为银行卡A，那么支付界面中展示的支付渠道相关信息为银行卡A、支付总额、购买商品名称、价格、数量等等。如果采用银行卡A支付失败，下一个推荐的为银行卡B，那么此时，可以将银行卡B的相关信息更新到支付界面中。比如更新到上述悬浮框中。更新时，比如将银行卡A替换为银行卡B，其他前后一致的信息可以保持不变。

综上，本发明实施例可以具备如下优点其中一个或者多个：

首先，可在用户在购买页面中点击触发进入展示订单展示页的过程后，分别获取业务系统提供的订单数据和支付系统提供的支付界面数据，然后在当前屏幕中可以同时展示所述订单数据和支付界面数据，如此，由于支付界面数据已经展示，用户可以直接利用该支付界面数据进行支付，页面也不会再次跳转，降低了支付的步骤，使支付流程缩短，从而可以提高用户体验，避免支付流程过长对支付转化率的影响。

其次，本发明实施例可以同步展示订单数据和支付界面数据，可以保证两者的渲染一致性，使用户感觉两者是一致展示的。

再次，本发明实施例可以自动为用户推荐支付渠道进行支付，并且在某个支付渠道支付失败时自动为用户推荐下一个支付渠道进行支付，从而可以实现用户点击一个按键进行支付的过程，不用用户选择支付渠道，减少用户的操作成本；

最后，采用悬浮窗与订单展示页分别展示支付数据和订单数据的方式，可以在避免订单页跳转的情况下，不改变业务系统和支付系统原有的对接方式，逻辑耦合低。

实施例二

参照图2，示出了根据本发明一个实施例的一种支付信息处理方法实施例的步骤流程图，具体可以包括如下步骤：

步骤201，客户端在接收到订单触发操作后，发送订单页展示请求至第一服务器；

在本发明实施例中，结合图2A对本发明实施例进行描述。

在本发明实施例中，用户可以在客户端的购物页面点击购买按钮，然后客户端则向第一服务器发出订单页展示请求。如图2A中的M11，客户端将订单页展示请求发给第一服务器。

该订单页展示请求可以包括用户信息，商品信息等信息。该用户信息比如用户账户，该商品信息比如商品名称、编号、购买数量等。

步骤202，接收所述第一服务器根据所述订单页展示请求中的用户信息确定进入第一支付模式的反馈；

可以理解，所述第一服务器根据所述订单页展示请求中的用户信息确定进入第一支付模式的反馈。

在实际应用中，所述第一服务器根据所述订单页展示请求中的用户信息判断是否需要进入第一支付模式，如果需要进入第一支付模式，则返回需要进入第一支付模式的判断结果；

第一服务器接收到订单页展示请求后，可以先从该订单页展示请求提取用户信息，然后判断是否需要进入第一支付模式。当然实际应用中，第一服务器由于是业务系统的服务器，其中不存在用户的支付账户信息，可以调用第二服务器的接口进行判断。

在实际应用中，第一服务器根据所述订单页展示请求中的用户信息，判断所述用户信息对应的支付配置信息是否符合预设条件，如果所述用户信息对应的支付配置信息符合预设条件，则返回需要进入第一支付模式的判断结果，如果所述用户信息对应的支付配置信息不符合预设条件，则返回需要进入普通支付模式的判断结果。

该支付配置信息包括：与所述用户信息所对应的银行卡配置信息；上述预设条件包括：所述银行卡配置信息包括绑定至少一张银行卡，以及绑定的银行卡中至少存在一张已开启免密码进行小额支付的权限。

如图2A中的M12，其通过上述步骤判断是否需要进入第一支付模式。

当第一服务器确定需要进入第一支付模式后，如有图2A的M13反馈需要进入第一支付模式，同时还可以返回订单数据。

当然，如果第一服务器确定需要进入普通支付模式，则返回需要进入普通支付模式的判断结果，以及订单数据。

当然订单数据和上述判断结果可以不同时返回，本发明实施例不对其加以限制。

那么，客户端接收第一服务器返回的判断结果；如果所述判断结果为需要进入第一支付模式，则进入步骤203。

步骤203，客户端向第二服务器发送支付界面展示请求。

客户端接收到第一服务器返回的判断结果后，对其进行解析，如果所述判断结果是需要进入第一支付模式，则可以如图2A的M14，向第二服务器发送支付界面展示请求。该支付界面展示请求可以包括用户信息、订单信息等数据。

当然，如果所述判断结果是需要进入普通支付模式，则可以直接渲染订单数据，则订单展示页按照传统页面结构进行展示。

在本发明实施例中，客户端收到需要进入第一支付模式的判断结果后，可以调用本地预置的支付模式SDK，向第二服务器发送支付界面展示请求。

其中，客户端在向第二服务器发送支付界面展示请求时，可以针对预置的支付界面地址生成网页请求并发送至第二服务器。该网页请求包括用户信息和订单信息。具体的，在安卓系统中，可以启动原生页面框架，由所述原生页面框架针对预置的支付界面地址生成网页请求并发送至第二服务器。

所述第二服务器针对所述支付界面展示请求返回支付界面数据。如图2A的M15,第二服务器返回支付界面数据给客户端。该支付界面数据可以包括支付控件数据。当然还可以包括推荐的支付渠道。其中该推荐的支付渠道可以由第二服务器从支付界面展示请求中提取用户信息后，根据用户的支付渠道使用历史记录进行推荐。

步骤204，客户端接收到第一服务器针对订单页展示请求返回的订单数据和第二服务器针对支付界面展示请求返回的支付界面数据后，基于所述订单数据和支付界面数据渲染订单展示页；

客户端则根据第二服务器的反馈进入第一支付模式，那么对于从第一服务器获取的订单数据，和对于从第二服务器获取的支付界面数据，在两者都接收到后，可以对两者同步进行渲染。

在实际应用中，在本发明实施例中，客户端是异步请求订单数据和支付界面数据，那么为了同步渲染订单数据和支付界面数据，本发明实施例则监控两个请求对应的数据是否全部接收到，如果接收到，则如图2A中的M16，同步渲染订单数据和支付界面数据。

优选的，在本发明一种实施例中，上述基于所述订单数据和支付界面数据渲染订单展示页的步骤，包括：

接收到第一服务器针对订单页展示请求返回的订单数据和第二服务器针对支付界面展示请求返回的支付界面数据后，在订单展示页中展示订单数据和支付界面数据。

优选的，在本发明一种实施例中，上述基于所述订单数据和支付界面数据渲染订单展示页的步骤，包括：

接收到第一服务器针对订单页展示请求返回的订单数据和第二服务器针对支付界面展示请求返回的支付界面数据后，在订单展示页中展示所述订单数据，并在所述订单展示页的指定位置上生成悬浮框以展示所述支付界面数据。

当然，在本发明实施例则，在支付界面数据渲染完毕后，其在相应的支付界面中展示。

优选的，还包括：接收用户在支付界面中对支付渠道的选择操作。那么可以根据用户的选择确定支付渠道。

步骤205，客户端在接收到支付触发操作后，通知第二服务器以第一支付模式对所述订单数据进行支付。

在本发明实施例中，如图2A的M17，用户可以在客户端的订单展示页中点击确认订单的操作，那么客户端则接收到用户触发进行支付的支付触发操作后，如M18，向第二服务器发送支付请求。

当然，本发明实施例向第二服务器发送支付请求，也可以由客户端调用预置的支付SDK中的接口实现。

第二服务器接收到支付请求后，则可以如M19以第一支付模式的支付流程进行支付。

优选的，当第二服务器在返回支付界面数据时，为其推荐了支付渠道的情况下，所述第二服务器在第一支付模式中，在利用上述推荐的支付渠道对所述订单数据进行支付后，如果支付失败，则根据用户的支付渠道历史记录推荐下一个支付渠道对所述订单数据进行支付，直至支付成功或者直至支付失败且触发停止条件。

进一步的，在客户端中：接收由第二服务器在利用下一个推荐的支付渠道对所述订单数据进行支付时，返回的所述支付渠道相关信息，并更新在所述支付界面数据所在的支付界面中

综上，本发明实施例可以具备如下优点其中一个或者多个：

首先，可在用户在购买页面中点击触发进入展示订单展示页的过程后，分别获取业务系统提供的订单数据和支付系统提供的支付界面数据，然后在当前屏幕中可以同时展示所述订单数据和支付界面数据，如此，由于支付界面数据已经展示，用户可以直接利用该支付界面数据进行支付，页面也不会再次跳转，降低了支付的步骤，使支付流程缩短，从而可以提高用户体验，避免支付流程过长对支付转化率的影响。

其次，本发明实施例可以同步展示订单数据和支付界面数据，可以保证两者的渲染一致性，使用户感觉两者是一致展示的。

再次，本发明实施例可以自动为用户推荐支付渠道进行支付，并且在某个支付渠道支付失败时自动为用户推荐下一个支付渠道进行支付，从而可以实现用户点击一个按键进行支付的过程，不用用户选择支付渠道，减少用户的操作成本；

最后，采用悬浮窗与订单展示页分别展示支付数据和订单数据的方式，可以在避免订单页跳转的情况下，不改变业务系统和支付系统原有的对接方式，逻辑耦合低。

实施例三

参照图3，示出了根据本发明一个实施例的一种支付信息处理方法实施例的步骤流程图，具体可以包括如下步骤：

步骤301，客户端在接收到订单触发操作后，发送订单页展示请求至第一服务器，并发送支付界面展示请求至第二服务器；

在本发明实施例中，结合图3A进行描述。

在本发明实施例中，用户可以在客户端的购物页面点击购买按钮，然后客户端则向第一服务器发出订单页展示请求，同时客户端会向第二服务器发送支付界面展示请求。如图3A中的M21和M22。

可以理解，该支付界面展示请求包括用户信息、订单信息等信息。

在本发明实施例中，客户端可以调用本地预置的支付模式SDK，向第二服务器发送支付界面展示请求。

可以理解，客户端在向第二服务器发送支付界面展示请求时，可以针对预置的支付界面地址生成网页请求并发送至第二服务器。具体的，在安卓系统中，可以启动原生页面框架，由所述原生页面框架针对预置的支付界面地址生成网页请求并发送至第二服务器。

步骤302，接收所述第二服务器根据所述支付界面展示请求的用户信息确定进入第一支付模式的反馈；

可以理解，所述第一服务器根据所述订单页展示请求中的用户信息确定进入第一支付模式的反馈。

在实际应用中，所述所述第二服务器根据所述支付界面展示请求的用户信息判断是否需要进入第一支付模式，如果需要进入第一支付模式，则返回包括支付界面数据的判断结果；

第一服务器接收到订单页展示请求后，如图3A的M23，返回订单数据。

第二服务器接收到支付界面展示请求后，可以先从该支付界面展示请求提取用户信息，然后判断是否需要进入第一支付模式。

在实际应用中，第二服务器根据所述支付界面展示请求中的用户信息，判断所述用户信息对应的支付配置信息是否符合预设条件，如果所述用户信息对应的支付配置信息符合预设条件，则返回需要进入第一支付模式的判断结果，如果所述用户信息对应的支付配置信息不符合预设条件，则返回需要进入普通支付模式的判断结果。

该支付配置信息包括：与所述用户信息所对应的银行卡配置信息；上述预设条件包括：所述银行卡配置信息包括绑定至少一张银行卡，以及绑定的银行卡中至少存在一张已开启免密码进行小额支付的权限。

如图3A中的M24，其通过上述步骤判断是否需要进入第一支付模式。

当第二服务器确定需要进入第一支付模式后，如有图3A的M25反馈需要进入第一支付模式，同时还可以返回支付界面数据。该支付界面数据可以包括支付控件数据。当然还可以包括推荐的支付渠道。其中该推荐的支付渠道可以由第二服务器从支付界面展示请求中提取用户信息后，根据用户的支付渠道使用历史记录进行推荐。

当然，如果第二服务器确定需要进入普通支付模式，则返回需要进入普通支付模式的判断结果，不返回支付界面数据。那么客户端直接渲染订单数据。

当然支付界面数据和上述判断结果可以不同时返回，本发明实施例不对其加以限制。

客户端接收第二服务器返回的判断结果；如果所述判断结果为需要进入第一支付模式，则进入步骤303。

步骤303，客户端接收到第一服务器针对订单页展示请求返回的订单数据和第二服务器针对支付界面展示请求返回的支付界面数据后，基于所述订单数据和支付界面数据渲染订单展示页；

客户端则根据第二服务器的反馈进入第一支付模式，那么对于从第一服务器获取的订单数据，和对于从第二服务器获取的支付界面数据，在两者都接收到后，可以对两者同步进行渲染。

在实际应用中，客户端接收到第二服务器返回的上述判断结果后，对其进行解析，如果所述判断结果是需要进入第一支付模式，则可以如图3A的M26，直接渲染订单数据和支付界面数据。

当然，如果所述判断结果是需要进入普通支付模式，则可以直接渲染订单数据，则订单展示页按照传统页面结构进行展示。

优选的，还包括：接收用户在支付界面中对支付渠道的选择操作。那么可以根据用户的选择确定支付渠道。

步骤304，客户端在接收到支付触发操作后，通知第二服务器以第一支付模式对所述订单数据进行支付。

在本发明实施例中，如图3A的M27，用户可以在订单展示页中点击确认订单的操作，那么客户端则接收到用户触发进行支付的支付触发操作后，如M28，向第二服务器发送支付请求。

当然，本发明实施例向第二服务器发送支付请求，也可以由客户端调用预置的支付SDK中的接口实现。

第二服务器接收到支付请求后，则可以如M29以第一支付模式的支付流程进行支付。

优选的，当第二服务器在返回支付界面数据时，为其推荐了支付渠道的情况下，在所述第二服务器在第一支付模式中，利用上述推荐的支付渠道对所述订单数据进行支付后，如果支付失败，则根据用户的支付渠道历史记录推荐下一个支付渠道对所述订单数据进行支付，直至支付成功或者直至支付失败且触发停止条件。

进一步的，在客户端中：接收由第二服务器在利用下一个推荐的支付渠道对所述订单数据进行支付时，返回的所述支付渠道相关信息，并更新在所述支付界面数据所在的支付界面中

综上，本发明实施例可以具备如下优点其中一个或者多个：

首先，可在用户在购买页面中点击触发进入展示订单展示页的过程后，分别获取业务系统提供的订单数据和支付系统提供的支付界面数据，然后在当前屏幕中可以同时展示所述订单数据和支付界面数据，如此，由于支付界面数据已经展示，用户可以直接利用该支付界面数据进行支付，页面也不会再次跳转，降低了支付的步骤，使支付流程缩短，从而可以提高用户体验，避免支付流程过长对支付转化率的影响。

其次，本发明实施例可以同步展示订单数据和支付界面数据，可以保证两者的渲染一致性，使用户感觉两者是一致展示的。

再次，本发明实施例可以自动为用户推荐支付渠道进行支付，并且在某个支付渠道支付失败时自动为用户推荐下一个支付渠道进行支付，从而可以实现用户点击一个按键进行支付的过程，不用用户选择支付渠道，减少用户的操作成本；

最后，采用悬浮窗与订单展示页分别展示支付数据和订单数据的方式，可以在避免订单页跳转的情况下，不改变业务系统和支付系统原有的对接方式，逻辑耦合低。

实施例四

参照图4，示出了根据本发明一个实施例的一种支付信息处理方法实施例的步骤流程图，具体可以包括如下步骤：

步骤410，获取订单数据，并基于所述订单数据渲染订单展示页；

在本发明实施例中，用户可以在购买页面中点击购买，然后客户端即可向第一服务器发送订单页展示请求，从而客户端可以获取订单数据，然后基于该订单数据渲染订单展示页。

步骤420，在接收到支付触发操作后，确定进入第一支付模式；

在本发实施例中，用户可以在订单展示页中点击确认订单按钮，该点击确认订单按钮的操作则可以理解为触发确认订单的支付触发操作，那么此时可以根据该支付触发操作，确定进入第一支付模式。

当然，也可以通过其他方式触发支付触发操作。比如支付界面中点击确认支付按钮，本发明实施例不对其加以限制。

在本发明实施例中，可以直接根据该支付触发操作，进入第一支付模式。

在实际应用中，也可以在接收到用户触发确认订单的支付触发操作后，判断是否需要进入第一支付模式；如果需要进入第一支付模式，则进入步骤430。

在本发实施例中，用户可以在订单展示页中点击确认订单按钮，该点击确认订单按钮的操作则可以理解为触发确认订单的支付触发操作，那么此时可以判断是否需要进入第一支付模式。

优选的，步骤420包括：

子步骤B11，判断执行所述订单触发操作的用户的用户信息所对应的支付配置信息是否符合预设条件；如果所述用户信息所对应的支付配置信息符合预设条件，则进入子步骤B12。

子步骤B12，需要进入第一支付模式；

其中，如果所述用户信息所对应的支付配置信息不符合预设条件，则进入需要进入普通支付模式。

其中，所述支付配置信息可以包括：与所述用户信息所对应的银行卡配置信息；所述预设条件可以包括：所述银行卡配置信息包括绑定至少一张银行卡，以及绑定的银行卡中至少存在一张已开启免密码进行小额支付的权限。

子步骤B11-B13与前述实施例的子步骤A11-A13的原理类似，在此不再赘叙。

在实际应用中，对于是否需要进入第一支付模式的判断过程可以在第二服务器中执行。那么客户端在接收到用户触发确认订单的支付触发操作后，向第二服务器发送支付请求；所述第二服务器根据所述支付请求中的用户信息判断是否需要进入第一支付模式，如果需要进入第一支付模式，则返回包括支付渠道相关信息的判断结果；客户端接收第二服务器返回的判断结果。

可以理解，对于客户端来说，其在接收到支付触发操作后，可以发送支付请求至第二服务器。

第二服务器接收到该支付请求，首先从支付请求中提取用户信息，然后根据该用户信息判断是否需要进入第一支付模式，将是或者否的判断结果返回给客户端。那么该客户端则接收第二服务器返回的判断结果，从而根据该判断结果确定是否进需要进入第一支付模式。如果是，则进入步骤430。如果否，则进入普通支付模式，客户端仅根据该订单数据，以该订单数据渲染订单展示页。当然第二服务器也可以返回支付界面数据或者空值，如果客户端接收到支付界面数据，则确认进入第一支付模式，如果客户端接收到空值，则确认进入普通支付模式。

其中，客户端在向第二服务器发送支付请求时，可以针对预置的支付界面地址生成网页请求并发送至第二服务器。该网页请求包括用户信息和订单信息。具体的，在安卓系统中，可以启动原生页面框架，由所述原生页面框架针对预置的支付界面地址生成网页请求并发送至第二服务器。

步骤430，在订单展示页之上生成的一个悬浮框，并将推荐的支付渠道的相关信息在所述悬浮框中展示。

在本发明实施例中，第二服务器可以为客户端推荐支付渠道，其将该支付渠道返回该客户端，而第二服务器则会在第一支付模式中，以该推荐的支付渠道进行支付。

可以理解，本发明实施例对于利用支付渠道进行支付的相关信息，可以在订单展示页之上生成的一个悬浮框，并将推荐的支付渠道的相关信息在所述悬浮框中展示。此时，订单展示页不用跳转，用户也可以从悬浮窗中看到支付相关信息。当然，该支付渠道相关信息还可以包括支付流程的流转过程信息。

步骤440，利用推荐的支付渠道对所述订单数据进行支付；

在本发明实施例中，如果需要使用第一支付模式，则可以为用户推荐支付渠道以进行支付。

在本发明实施例中，在第一支付模式进入支付过程后，则禁止用户对订单页面的操作，使该支付过程不被用户的操作打断，直到客户端收到第二服务器返回的支付失败结果或者支付成功结果，允许客户端的用户操作页面。

优选的，步骤430包括：

子步骤B31，根据所述用户信息对应的支付渠道使用历史记录推荐支付渠道。

在本发明实施例中，可以根据用户使用支付渠道的使用频率为其推荐支付渠道。比如用户M对各银行卡的使用记录进行统计，其银行卡A的使用了50次，银行卡B使用了30次，银行卡C使用了10次。那么本发明可以以该使用频率为优先级，为用户推荐支付渠道，然后直接以该支付渠道进行支付。

优选的，步骤430包括：

子步骤B32，当利用推荐的支付渠道对所述订单数据进行支付时，如果支付失败，则据用户的支付渠道历史记录推荐下一个支付渠道对所述订单数据进行支付，直至支付成功或者直至支付失败且触发停止条件。

在本发明实施例中，在第一支付模式进入支付过程后，在支付成功或者直至支付失败且触发停止条件之前，可以禁止用户对订单页面的操作，使该支付过程不被用户的操作打断，直到客户端收到第二服务器在支付成功后返回的结果，或者直至支付失败且触发停止条件后返回的结果，允许客户端的用户操作页面。

优选的，步骤440之后，还包括：

步骤441，在利用下一个支付渠道对所述订单数据进行支付时，将所述支付渠道相关信息更新在所述悬浮框中。

此步骤441与前述实施例步骤150原理类似，在此不再赘叙。

综上，本发明实施例可以具备如下优点其中一个或者多个：

首先，可在用户在购买页面中点击触发进入展示订单展示页的过程后，获取业务系统提供的订单数据进行展示，然后在用户触发订单确认按钮后，直接进行支付过程，而支付过程的支付相关信息则直接在客户端的订单展示页之上的悬浮框中，本发明实施例的订单展示页也不会再次跳转，用户可以点击一个按键进行支付，降低了支付的步骤，使支付流程缩短，从而可以提高用户体验，避免支付流程过长对支付转化率的影响。

其次，本发明实施例可以自动为用户推荐支付渠道进行支付，并且在某个支付渠道支付失败时自动为用户推荐下一个支付渠道进行支付，从而可以实现用户点击一个按键进行支付的过程，不用用户选择支付渠道，减少用户的操作成本。

实施例五

参照图5，示出了根据本发明一个实施例的一种支付信息处理方法实施例的步骤流程图，具体可以包括如下步骤：

步骤501，客户端发送订单页展示请求至第一服务器；

在本发明实施例中，结合图5A进行描述。

如图5A的M31，用户在购物页面中点击购买后，客户端可以向第一服务器发送订单页展示请求。

步骤502，客户端接收第一服务器返回的订单数据，并在订单展示页展示所述订单数据；

如图5A的M32，第一服务器接收到订单页展示请求后，则向客户端返回订单数据。客户端则渲染该订单数据，得到订单展示页面。

步骤503，客户端在接收到支付触发操作后，向第二服务器发起支付请求；

在用户在订单展示页面中点击确认提交按钮后，则客户端接收到支付触发操作，如图5A的M35，则客户端向第二服务器发送支付请求。

步骤504，在接收所述第二服务器根据所述支付请求中的用户信息确定进入第一支付模式的反馈，所述反馈包括第二服务器利用推荐的支付渠道对所述订单数据进行支付时，返回的支付渠道相关信息；

可以理解，所述第二服务器根据所述支付请求中的用户信息判断是否需要进入第一支付模式，如果需要进入第一支付模式，则第二服务器以第一支付模式，利用推荐的支付渠道对所述订单数据进行支付，并反馈给客户端需要进入第一支付模式。在实际应用中该反馈可以返回包括支付渠道相关信息的判断结果。

如图5A的M36，第二服务器则根据该支付请求判断是否进入第一支付模式。如果需要进入第一支付模式，则如M37，返回包括支付界面数据的判断结果。如果需要进入普通支付模式，则返回支付页面，客户端则将订单展示页面跳转至该支付页面。

步骤505，客户端在订单展示页之上生成的一个悬浮框，并将推荐的支付渠道的相关信息在所述悬浮框中展示。

当客户端收到支付渠道相关信息时，则在订单展示页之上生成的一个悬浮框，并将推荐的支付渠道的相关信息在所述悬浮框中展示。如图5A的M39，在订单展示页之上生成的一个悬浮框，并将推荐的支付渠道的相关信息在所述悬浮框中展示。

综上，本发明实施例可以具备如下优点其中一个或者多个：

首先，可在用户在购买页面中点击触发进入展示订单展示页的过程后，获取业务系统提供的订单数据进行展示，然后在用户触发订单确认按钮后，直接进行支付过程，而支付过程的支付相关信息则直接在客户端的订单展示页之上的悬浮框中，本发明实施例的订单展示页也不会再次跳转，用户可以点击一个按键进行支付，降低了支付的步骤，使支付流程缩短，从而可以提高用户体验，避免支付流程过长对支付转化率的影响。

其次，本发明实施例可以自动为用户推荐支付渠道进行支付，并且在某个支付渠道支付失败时自动为用户推荐下一个支付渠道进行支付，从而可以实现用户点击一个按键进行支付的过程，不用用户选择支付渠道，减少用户的操作成本。

对于方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本发明实施例并不受所描述的动作顺序的限制，因为依据本发明实施例，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作并不一定是本发明实施例所必须的。

实施例六

参照图6，示出了根据本发明一个实施例的一种支付信息处理装置实施例的结构框图，具体可以包括如下模块：

支付模式选择模块610，用于根据接收到的订单触发操作，确定进入第一支付模式；

数据获取模块620，用于获取订单数据和支付界面数据；

同步展示模块630，用于基于所述订单数据和支付界面数据渲染订单展示页；

支付模块640，用于在接收到支付触发操作后，以第一支付模式对所述订单数据进行支付。

优选的，所述同步展示模块，包括：

综合展示模块，用于在所述订单展示页中展示订单数据和支付界面数据。

优选的，所述同步展示模块，包括：

订单展示子模块，用于在所述订单展示页中展示订单数据；

悬浮窗渲染子模块，用于在订单展示页之上生成一个悬浮框，并在所述悬浮框中展示支付界面数据。

优选的，所述数据获取模块包括：

订单数据获取子模块，用于从第一服务器获取订单数据；

支付界面数据获取子模块，用于从第二服务器获取支付界面数据。

优选的，所述支付界面数据获取子模块包括：

网页请求发送子模块，用于针对预置的支付界面地址生成网页请求并发送至第二服务器；所述第二服务器返回针对所述网页请求的支付界面数据。

优选的，所述网页请求发送子模块包括：

原生页面调用子模块，用于启动原生页面框架，由所述原生页面框架针对预置的支付界面地址生成网页请求并发送至第二服务器。

优选的，支付模式选择模块包括：

支付配置信息判断子模块，用于判断执行所述订单触发操作的用户的用户信息所对应的支付配置信息是否符合预设条件；如果所述用户信息所对应的支付配置信息符合预设条件，则需要进入第一支付模式。

其中，如果所述用户信息所对应的支付配置信息不符合预设条件，则需要进入普通支付模式。

优选的，所述支付配置信息包括：与所述用户信息所对应的银行卡配置信息；所述预设条件包括：所述银行卡配置信息包括绑定至少一张银行卡，以及绑定的银行卡中至少存在一张已开启免密码进行小额支付的权限。

优选的，所述支付界面数据包括根据所述用户对应的支付渠道使用历史记录所推荐的支付渠道。

优选的，所述支付模块包括：

第一支付子模块，用于在第一支付模式中，利用所述推荐的支付渠道对所述订单数据进行支付时，如果支付失败，则根据用户的支付渠道历史记录推荐下一个支付渠道对所述订单数据进行支付，直至支付成功或者直至支付失败且触发停止条件。

优选的，还包括：

支付数据更新模块，用于在利用下一个支付渠道对所述订单数据进行支付时，将所述支付渠道相关信息更新在所述支付界面数据所在的支付界面中。

首先，可在用户在购买页面中点击触发进入展示订单展示页的过程后，分别获取业务系统提供的订单数据和支付系统提供的支付界面数据，然后在当前屏幕中可以同时展示所述订单数据和支付界面数据，如此，由于支付界面数据已经展示，用户可以直接利用该支付界面数据进行支付，页面也不会再次跳转，降低了支付的步骤，使支付流程缩短，从而可以提高用户体验，避免支付流程过长对支付转化率的影响。

其次，本发明实施例可以同步展示订单数据和支付界面数据，可以保证两者的渲染一致性，使用户感觉两者是一致展示的。

再次，本发明实施例可以自动为用户推荐支付渠道进行支付，并且在某个支付渠道支付失败时自动为用户推荐下一个支付渠道进行支付，从而可以实现用户点击一个按键进行支付的过程，不用用户选择支付渠道，减少用户的操作成本；

最后，采用悬浮窗与订单展示页分别展示支付数据和订单数据的方式，可以在避免订单页跳转的情况下，不改变业务系统和支付系统原有的对接方式，逻辑耦合低。

综上，本发明实施例可以具备如下优点其中一个或者多个：

首先，可在用户在购买页面中点击触发进入展示订单展示页的过程后，分别获取业务系统提供的订单数据和支付系统提供的支付界面数据，然后在当前屏幕中可以同时展示所述订单数据和支付界面数据，如此，由于支付界面数据已经展示，用户可以直接利用该支付界面数据进行支付，页面也不会再次跳转，降低了支付的步骤，使支付流程缩短，从而可以提高用户体验，避免支付流程过长对支付转化率的影响。

其次，本发明实施例可以同步展示订单数据和支付界面数据，可以保证两者的渲染一致性，使用户感觉两者是一致展示的。

再次，本发明实施例可以自动为用户推荐支付渠道进行支付，并且在某个支付渠道支付失败时自动为用户推荐下一个支付渠道进行支付，从而可以实现用户点击一个按键进行支付的过程，不用用户选择支付渠道，减少用户的操作成本；

最后，采用悬浮窗与订单展示页分别展示支付数据和订单数据的方式，可以在避免订单页跳转的情况下，不改变业务系统和支付系统原有的对接方式，逻辑耦合低。

实施例七

参照图7，示出了根据本发明一个实施例的一种支付信息处理系统实施例的结构框图，具体可以包括如下模块：

客户端710、第一服务器720、第二服务器730；

所述客户端710包括：

第一发送模块711，用于在接收到订单触发操作后，发送订单页展示请求至第一服务器720；

第一接收模块712，用于接收所述第一服务器720根据所述订单页展示请求中的用户信息确定进入第一支付模式的反馈；

第二发送模块713，用于向第二服务器730发送支付界面展示请求；

第一同步模块714，用于接收到第一服务器720针对订单页展示请求返回的订单数据和第二服务器730针对支付界面展示请求返回的支付界面数据后，基于所述订单数据和支付界面数据渲染订单展示页；

支付模块715，用于在接收到支付触发操作后，通知第二服务器以第一支付模式对所述订单数据进行支付；

所述第一服务器720用于向客户端返回根据所述订单页展示请求中的用户信息确定进入第一支付模式的反馈。

其中，第一服务器还用于针对订单页面请求返回的订单数据。

优选的，所述第一同步模块包括：

第一页面同步子模块，用于接收到第一服务器针对订单页面请求返回的订单数据和第二服务器针对支付界面展示请求返回的支付界面数据后，在订单展示页中展示所述订单数据和支付界面数据。

优选的，所述第一同步模块包括：

第一悬浮窗同步子模块，用于接收到第一服务器针对订单页面请求返回的订单数据和第二服务器针对支付界面展示请求返回的支付界面数据后，在订单展示页中展示所述订单数据，并在所述订单展示页的指定位置上生成悬浮框以展示所述支付界面数据。

优选的，在客户端中还包括：

选择模块，用于在所述支付界面数据对应的支付界面中，接收用户对支付渠道的选择操作。

优选的，所述第二发送模块包括：

第二发送子模块，用于针对预置的支付界面地址生成网页请求并发送至第二服务器；

进一步的所述第二服务器还用于针对所述网页请求返回支付界面数据。

优选的，第二发送子模块包括：

网页请求调用子模块，用于启动原生页面框架，由所述原生页面框架针对预置的支付界面地址生成网页请求并发送至第二服务器。

所述第一服务器还用于根据所述订单页展示请求中的用户信息，判断所述用户信息对应的支付配置信息是否符合预设条件，如果所述用户信息对应的支付配置信息符合预设条件，则返回需要进入第一支付模式的判断结果。

其中，如果所述用户信息对应的支付配置信息不符合预设条件，则返回需要进入普通支付模式的判断结果至客户端。

优选的，所述支付配置信息包括：与所述用户信息所对应的银行卡配置信息；上述预设条件包括：所述银行卡配置信息包括绑定至少一张银行卡，以及绑定的银行卡中至少存在一张已开启免密码进行小额支付的权限。

优选的，所述支付界面数据包括根据所述用户对应的支付渠道使用历史记录所推荐的支付渠道。

优选的，第二服务器还用于在第一支付模式中，利用所述推荐的支付渠道对所述订单数据进行支付时，如果支付失败，则根据用户的支付渠道历史记录推荐下一个支付渠道对所述订单数据进行支付，直至支付成功或者直至支付失败且触发停止条件。

优选的，在所述客户端中还包括：

更新展示模块，用于接收由第二服务器在利用下一个推荐的支付渠道对所述订单数据进行支付时，返回的所述支付渠道相关信息，并更新在所述支付界面数据所在的支付界面中。

综上，本发明实施例可以具备如下优点其中一个或者多个：

首先，可在用户在购买页面中点击触发进入展示订单展示页的过程后，分别获取业务系统提供的订单数据和支付系统提供的支付界面数据，然后在当前屏幕中可以同时展示所述订单数据和支付界面数据，如此，由于支付界面数据已经展示，用户可以直接利用该支付界面数据进行支付，页面也不会再次跳转，降低了支付的步骤，使支付流程缩短，从而可以提高用户体验，避免支付流程过长对支付转化率的影响。

其次，本发明实施例可以同步展示订单数据和支付界面数据，可以保证两者的渲染一致性，使用户感觉两者是一致展示的。

再次，本发明实施例可以自动为用户推荐支付渠道进行支付，并且在某个支付渠道支付失败时自动为用户推荐下一个支付渠道进行支付，从而可以实现用户点击一个按键进行支付的过程，不用用户选择支付渠道，减少用户的操作成本；

最后，采用悬浮窗与订单展示页分别展示支付数据和订单数据的方式，可以在避免订单页跳转的情况下，不改变业务系统和支付系统原有的对接方式，逻辑耦合低。

实施例八

参照图8，示出了根据本发明一个实施例的一种支付信息处理系统实施例的结构框图，具体可以包括如下模块：

客户端810、第一服务器820、第二服务器830；

所述客户端810包括：

第三发送模块811，用于在接收到订单触发操作后，发送订单页展示请求至第一服务器820，并发送支付界面展示请求至第二服务器830；

第二接收模块812，用于接收所述第二服务器830根据所述支付界面展示请求的用户信息确定进入第一支付模式的反馈；

第二同步模块813，用于接收到第一服务器820针对订单页展示请求返回的订单数据和第二服务器830针对支付界面展示请求返回的支付界面数据后，基于所述订单数据和支付界面数据渲染订单展示页；

支付模块814，用于在接收到支付触发操作后，通知第二服务器830以第一支付模式对所述订单数据进行支付；

所述第二服务器830用于向客户端返回根据所述订单页展示请求中的用户信息确定进入第一支付模式的反馈。

其中，第一服务器还用于针对订单页面请求返回的订单数据。

优选的，所述第二同步模块包括：

第二页面同步子模块，用于接收到第一服务器针对订单页面请求返回的订单数据和第二服务器针对支付界面展示请求返回的支付界面数据后，在订单展示页中展示所述订单数据和支付界面数据。

优选的，所述第二同步模块包括：

第二悬浮窗同步子模块，用于接收到第一服务器针对订单页面请求返回的订单数据和第二服务器针对支付界面展示请求返回的支付界面数据后，在订单展示页中展示所述订单数据，并在所述订单展示页的指定位置上生成悬浮框以展示所述支付界面数据。

优选的，在客户端中还包括：

选择模块，用于在所述支付界面数据对应的支付界面中，接收用户对支付渠道的选择操作。

优选的，所述第三发送模块包括：

第三发送子模块，用于针对预置的支付界面地址生成网页请求并发送至第二服务器；

进一步的所述第二服务器用于针对所述网页请求返回包括支付界面数据的判断结果。

优选的，第三发送子模块包括：

网页请求调用模块，用于启动原生页面框架，由所述原生页面框架针对预置的支付界面地址生成网页请求并发送至第二服务器。

所述第二服务器还用于根据所述订单页展示请求中的用户信息，判断所述用户信息对应的支付配置信息是否符合预设条件，如果所述用户信息对应的支付配置信息符合预设条件，则返回需要进入第一支付模式的判断结果。

其中，如果所述用户信息对应的支付配置信息不符合预设条件，则返回需要进入普通支付模式的判断结果至客户端。

优选的，所述支付配置信息包括：与所述用户信息所对应的银行卡配置信息；上述预设条件包括：所述银行卡配置信息包括绑定至少一张银行卡，以及绑定的银行卡中至少存在一张已开启免密码进行小额支付的权限。

优选的，所述支付界面数据包括根据所述用户对应的支付渠道使用历史记录所推荐的支付渠道。

优选的，第二服务器还用于在第一支付模式中，利用所述推荐的支付渠道对所述订单数据进行支付时，如果支付失败，则根据用户的支付渠道历史记录推荐下一个支付渠道对所述订单数据进行支付，直至支付成功或者直至支付失败且触发停止条件。

优选的，在所述客户端中还包括：

更新展示模块，用于接收由第二服务器在利用下一个推荐的支付渠道对所述订单数据进行支付时，返回的所述支付渠道相关信息，并更新在所述支付界面数据所在的支付界面中。

综上，本发明实施例可以具备如下优点其中一个或者多个：

首先，可在用户在购买页面中点击触发进入展示订单展示页的过程后，分别获取业务系统提供的订单数据和支付系统提供的支付界面数据，然后在当前屏幕中可以同时展示所述订单数据和支付界面数据，如此，由于支付界面数据已经展示，用户可以直接利用该支付界面数据进行支付，页面也不会再次跳转，降低了支付的步骤，使支付流程缩短，从而可以提高用户体验，避免支付流程过长对支付转化率的影响。

其次，本发明实施例可以同步展示订单数据和支付界面数据，可以保证两者的渲染一致性，使用户感觉两者是一致展示的。

再次，本发明实施例可以自动为用户推荐支付渠道进行支付，并且在某个支付渠道支付失败时自动为用户推荐下一个支付渠道进行支付，从而可以实现用户点击一个按键进行支付的过程，不用用户选择支付渠道，减少用户的操作成本；

最后，采用悬浮窗与订单展示页分别展示支付数据和订单数据的方式，可以在避免订单页跳转的情况下，不改变业务系统和支付系统原有的对接方式，逻辑耦合低。

实施例九

参照图9，示出了根据本发明一个实施例的一种支付信息处理装置实施例的结构框图，具体可以包括如下模块：

订单页展示模块910，用于获取订单数据，并基于所述订单数据渲染订单展示页；

支付模式选择模块920，用于在接收到支付触发操作后，确定进入第一支付模式；

支付信息展示模块930，用于在订单展示页之上生成的一个悬浮框，并将推荐的支付渠道的相关信息在所述悬浮框中展示。

快捷支付模块940，用于利用推荐的支付渠道对所述订单数据进行支付；

优选的，所述支付模式选择模块包括：

支付配置信息判断子模块，用于判断执行所述订单触发操作的用户的用户信息所对应的支付配置信息是否符合预设条件；如果所述用户信息所对应的支付配置信息符合预设条件，则需要进入第一支付模式。

其中，如果所述用户信息所对应的支付配置信息不符合预设条件，则需要进入普通支付模式。

优选的，所述支付模式选择模块包括：

支付渠道推荐子模块，用于根据所述用户信息对应的支付渠道使用历史记录推荐支付渠道。

优选的，所述快捷支付模块包括：

第一支付子模块，用于当利用推荐的支付渠道对所述订单数据进行支付时，如果支付失败，则据用户的支付渠道历史记录推荐下一个支付渠道对所述订单数据进行支付，直至支付成功或者直至支付失败且触发停止条件。

优选的，还包括：

支付数据更新模块，用于在利用下一个支付渠道对所述订单数据进行支付时，将所述支付渠道相关信息更新在所述悬浮框中。

优选的，所述支付模式选择模块包括：

第四发送子模块，用于在接收到用户触发确认订单的支付触发操作后，向第二服务器发送支付请求；

第四接收子模块，用于在接收所述第二服务器根据所述支付请求中的用户信息确定进入第一支付模式的反馈。所述反馈包括第二服务器利用推荐的支付渠道对所述订单数据进行支付时，返回的支付渠道相关信息。

优选的，所述第四发送模块包括：

网页请求发送子模块，用于针对预置的支付界面地址生成网页请求并发送至第二服务器；所述第二服务器返回针对所述网页请求的支付界面数据。

优选的，所述网页请求发送子模块包括：

原生页面调用子模块，用于启动原生页面框架，由所述原生页面框架针对预置的支付界面地址生成网页请求并发送至第二服务器。

首先，可在用户在购买页面中点击触发进入展示订单展示页的过程后，获取业务系统提供的订单数据进行展示，然后在用户触发订单确认按钮后，直接进行支付过程，而支付过程的支付相关信息则直接在客户端的订单展示页之上的悬浮框中，本发明实施例的订单展示页也不会再次跳转，用户可以点击一个按键进行支付，降低了支付的步骤，使支付流程缩短，从而可以提高用户体验，避免支付流程过长对支付转化率的影响。

其次，本发明实施例可以自动为用户推荐支付渠道进行支付，并且在某个支付渠道支付失败时自动为用户推荐下一个支付渠道进行支付，从而可以实现用户点击一个按键进行支付的过程，不用用户选择支付渠道，减少用户的操作成本。

实施例十

参照图10，示出了根据本发明一个实施例的一种支付信息处理系统实施例的结构框图，具体可以包括如下模块：

客户端1010、第一服务器1020、第二服务器1030；

所述客户端1010包括：

第五发送模块1011，用于发送订单页展示请求至第一服务器1020；

订单页面展示模块1012，用于接收第一服务器1020返回的订单数据，并在订单展示页展示所述订单数据；

第六发送模块1013，用于在接收到支付触发操作后，向第二服务器1030发起支付请求；

第五接收模块1014，用于在接收所述第二服务器1030根据所述支付请求中的用户信息确定进入第一支付模式的反馈，所述反馈包括第二服务器1030利用推荐的支付渠道对所述订单数据进行支付时，返回的支付渠道相关信息；

展示模块1015，用于在订单展示页之上生成的一个悬浮框，并将推荐的支付渠道的相关信息在所述悬浮框中展示；

所述第二服务器1030用于根据所述支付请求中的用户信息确定进入第一支付模式的反馈，以及利用推荐的支付渠道对所述订单数据进行支付，并返回所述支付渠道的支付渠道相关信息。

其中，第一服务器用于返回订单数据。

优选的，所述第二服务器还用于判断执行所述订单触发操作的用户的用户信息所对应的支付配置信息是否符合预设条件；如果所述用户信息所对应的支付配置信息符合预设条件，则需要进入第一支付模式。

其中，如果所述用户信息所对应的支付配置信息不符合预设条件，则需要进入普通支付模式。

优选的，所述第二服务器还用于根据所述用户信息对应的支付渠道使用历史记录推荐支付渠道。

优选的，所述快捷支付模块包括：

第一支付子模块，用于当利用推荐的支付渠道对所述订单数据进行支付时，如果支付失败，则据用户的支付渠道历史记录推荐下一个支付渠道对所述订单数据进行支付，直至支付成功或者直至支付失败且触发停止条件。

优选的，在客户端中，还包括：

支付数据更新模块，用于接收第二服务器在利用下一个支付渠道对所述订单数据进行支付时，返回的支付渠道相关信息，并将所述支付渠道相关信息更新在所述悬浮框中。

优选的，所述第六发送模块包括：

第六发送子模块，用于在接收到用户触发确认订单的支付触发操作后，向第二服务器发送支付请求；

第六接收子模块，用于接收第二服务器返回的判断结果。

所述第二服务器还用于根据所述支付请求中的用户信息判断是否需要进入第一支付模式，如果需要进入第一支付模式，则返回包括支付渠道相关信息的判断结果。

优选的，所述第六发送子模块包括：

网页请求发送子模块，用于针对预置的支付界面地址生成网页请求并发送至第二服务器；所述第二服务器返回针对所述网页请求的支付界面数据。

优选的，所述网页请求发送子模块包括：

原生页面调用子模块，用于启动原生页面框架，由所述原生页面框架针对预置的支付界面地址生成网页请求并发送至第二服务器。

首先，可在用户在购买页面中点击触发进入展示订单展示页的过程后，获取业务系统提供的订单数据进行展示，然后在用户触发订单确认按钮后，直接进行支付过程，而支付过程的支付相关信息则直接在客户端的订单展示页之上的悬浮框中，本发明实施例的订单展示页也不会再次跳转，用户可以点击一个按键进行支付，降低了支付的步骤，使支付流程缩短，从而可以提高用户体验，避免支付流程过长对支付转化率的影响。

其次，本发明实施例可以自动为用户推荐支付渠道进行支付，并且在某个支付渠道支付失败时自动为用户推荐下一个支付渠道进行支付，从而可以实现用户点击一个按键进行支付的过程，不用用户选择支付渠道，减少用户的操作成本。

对于装置实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

在此提供的算法和显示不与任何特定计算机、虚拟系统或者其它设备固有相关。各种通用系统也可以与基于在此的示教一起使用。根据上面的描述，构造这类系统所要求的结构是显而易见的。此外，本发明也不针对任何特定编程语言。应当明白，可以利用各种编程语言实现在此描述的本发明的内容，并且上面对特定语言所做的描述是为了披露本发明的最佳实施方式。

在此处所提供的说明书中，说明了大量具体细节。然而，能够理解，本发明的实施例可以在没有这些具体细节的情况下实践。在一些实例中，并未详细示出公知的方法、结构和技术，以便不模糊对本说明书的理解。

类似地，应当理解，为了精简本公开并帮助理解各个发明方面中的一个或多个，在上面对本发明的示例性实施例的描述中，本发明的各个特征有时被一起分组到单个实施例、图、或者对其的描述中。然而，并不应将该公开的方法解释成反映如下意图：即所要求保护的本发明要求比在每个权利要求中所明确记载的特征更多的特征。更确切地说，如下面的权利要求书所反映的那样，发明方面在于少于前面公开的单个实施例的所有特征。因此，遵循具体实施方式的权利要求书由此明确地并入该具体实施方式，其中每个权利要求本身都作为本发明的单独实施例。

本领域那些技术人员可以理解，可以对实施例中的设备中的模块进行自适应性地改变并且把它们设置在与该实施例不同的一个或多个设备中。可以把实施例中的模块或单元或组件组合成一个模块或单元或组件，以及此外可以把它们分成多个子模块或子单元或子组件。除了这样的特征和/或过程或者单元中的至少一些是相互排斥之外，可以采用任何组合对本说明书(包括伴随的权利要求、摘要和附图)中公开的所有特征以及如此公开的任何方法或者设备的所有过程或单元进行组合。除非另外明确陈述，本说明书(包括伴随的权利要求、摘要和附图)中公开的每个特征可以由提供相同、等同或相似目的的替代特征来代替。

此外，本领域的技术人员能够理解，尽管在此所述的一些实施例包括其它实施例中所包括的某些特征而不是其它特征，但是不同实施例的特征的组合意味着处于本发明的范围之内并且形成不同的实施例。例如，在下面的权利要求书中，所要求保护的实施例的任意之一都可以以任意的组合方式来使用。

本发明的各个部件实施例可以以硬件实现，或者以在一个或者多个处理器上运行的软件模块实现，或者以它们的组合实现。本领域的技术人员应当理解，可以在实践中使用微处理器或者数字信号处理器(DSP)来实现根据本发明实施例的支付信息处理设备中的一些或者全部部件的一些或者全部功能。本发明还可以实现为用于执行这里所描述的方法的一部分或者全部的设备或者装置程序(例如，计算机程序和计算机程序商品数据)。这样的实现本发明的程序可以存储在计算机可读介质上，或者可以具有一个或者多个信号的形式。这样的信号可以从因特网网站上下载得到，或者在载体信号上提供，或者以任何其他形式提供。

应该注意的是上述实施例对本发明进行说明而不是对本发明进行限制，并且本领域技术人员在不脱离所附权利要求的范围的情况下可设计出替换实施例。在权利要求中，不应将位于括号之间的任何参考符号构造成对权利要求的限制。单词“包含”不排除存在未列在权利要求中的元件或步骤。位于元件之前的单词“一”或“一个”不排除存在多个这样的元件。本发明可以借助于包括有若干不同元件的硬件以及借助于适当编程的计算机来实现。在列举了若干装置的单元权利要求中，这些装置中的若干个可以是通过同一个硬件项来具体体现。单词第一、第二、以及第三等的使用不表示任何顺序。可将这些单词解释为名称。

Claims (21)

1.一种支付信息处理方法，其特征在于，包括：

根据接收到的订单触发操作，确定进入第一支付模式；

获取订单数据和支付界面数据；

基于所述订单数据和支付界面数据渲染订单展示页；

在接收到支付触发操作后，以第一支付模式对所述订单数据进行支付。

2.根据权利要求1所述的方法，其特征在于，所述基于所述订单数据和支付界面数据渲染订单展示页的步骤，包括：

在所述订单展示页中展示订单数据和支付界面数据。

3.根据权利要求1所述的方法，其特征在于，所述基于所述订单数据和支付界面数据渲染订单展示页的步骤，包括：

在所述订单展示页中展示订单数据；

在订单展示页之上生成一个悬浮框，并在所述悬浮框中展示支付界面数据。

4.根据权利要求1所述的方法，其特征在于，所述获取订单数据和支付界面数据的步骤，包括：

从第一服务器获取订单数据；

从第二服务器获取支付界面数据。

5.根据权利要求4所述的方法，其特征在于，所述从第二服务器获取支付界面数据的步骤，包括：

针对预置的支付界面地址生成网页请求并发送至第二服务器；所述第二服务器返回针对所述网页请求的支付界面数据。

6.根据权利要求5所述的方法，其特征在于，所述针对预置的支付界面地址生成网页请求并发送至第二服务器的步骤，包括：

启动原生页面框架，由所述原生页面框架针对预置的支付界面地址生成网页请求并发送至第二服务器。

7.根据权利要求1-6其中之一所述的方法，其特征在于，所述确定进入第一支付模式的步骤，包括：

判断执行所述订单触发操作的用户的用户信息所对应的支付配置信息是否符合预设条件；

如果所述用户信息所对应的支付配置信息符合预设条件，则需要进入第一支付模式。

8.根据权利要求7所述的方法，其特征在于，所述支付配置信息包括：与所述用户信息所对应的银行卡配置信息；所述预设条件包括：所述银行卡配置信息包括绑定至少一张银行卡，以及绑定的银行卡中至少存在一张已开启免密码进行小额支付的权限。

9.根据权利要求1-6其中之一所述的方法，其特征在于，所述支付界面数据包括根据所述用户对应的支付渠道使用历史记录所推荐的支付渠道。

10.根据权利要求9所述的方法，其特征在于，所述在接收到支付触发操作后，以第一支付模式对所述订单数据进行支付的步骤，包括：

在第一支付模式中，利用所述推荐的支付渠道对所述订单数据进行支付时，如果支付失败，则根据用户的支付渠道历史记录推荐下一个支付渠道对所述订单数据进行支付，直至支付成功或者直至支付失败且触发停止条件。

11.根据权利要求10所述的方法，其特征在于，在所述在接收到支付触发操作后，以第一支付模式对所述订单数据进行支付的步骤之后，还包括：

在利用下一个支付渠道对所述订单数据进行支付时，将所述支付渠道相关信息更新在所述支付界面数据所在的支付界面中。

12.一种支付信息处理方法，其特征在于，包括：

在接收到订单触发操作后，发送订单页展示请求至第一服务器；

接收所述第一服务器根据所述订单页展示请求中的用户信息确定进入第一支付模式的反馈；

向第二服务器发送支付界面展示请求；

接收到第一服务器针对订单页展示请求返回的订单数据和第二服务器针对支付界面展示请求返回的支付界面数据后，基于所述订单数据和支付界面数据渲染订单展示页；

在接收到支付触发操作后，通知第二服务器以第一支付模式对所述订单数据进行支付。

13.一种支付信息处理方法，其特征在于，包括：

在接收到订单触发操作后，发送订单页展示请求至第一服务器，并发送支付界面展示请求至第二服务器；

接收所述第二服务器根据所述支付界面展示请求的用户信息确定进入第一支付模式的反馈；

接收到第一服务器针对订单页展示请求返回的订单数据和第二服务器针对支付界面展示请求返回的支付界面数据后，基于所述订单数据和支付界面数据渲染订单展示页；

在接收到支付触发操作后，通知第二服务器以第一支付模式对所述订单数据进行支付。

14.一种支付信息处理方法，其特征在于，包括：

获取订单数据，并基于所述订单数据渲染订单展示页；

在接收到支付触发操作后，确定进入第一支付模式；

在订单展示页之上生成的一个悬浮框，并将推荐的支付渠道的相关信息在所述悬浮框中展示；

利用所述推荐的支付渠道对所述订单数据进行支付。

15.根据权利要求14所述的方法，其特征在于，所述在接收到支付触发操作后，确定进入第一支付模式的步骤，包括：

判断执行所述支付触发操作的用户的用户信息所对应的支付配置信息是否符合预设条件；

如果所述用户信息所对应的支付配置信息符合预设条件，则需要进入第一支付模式。

16.根据权利要求14所述的方法，其特征在于，所述利用所述推荐的支付渠道对所述订单数据进行支付的步骤，包括：

根据所述用户信息对应的支付渠道使用历史记录推荐支付渠道。

17.根据权利要求15所述的方法，其特征在于，所述利用所述推荐的支付渠道对所述订单数据进行支付的步骤，包括：

当利用推荐的支付渠道对所述订单数据进行支付时，如果支付失败，则据用户的支付渠道历史记录推荐下一个支付渠道对所述订单数据进行支付，直至支付成功或者直至支付失败且触发停止条件。

18.根据权利要求17所述的方法，其特征在于，在订单展示页之上生成的一个悬浮框，并将推荐的支付渠道的相关信息在所述悬浮框中展示的步骤之后，还包括：

在利用下一个支付渠道对所述订单数据进行支付时，将所述支付渠道相关信息更新在所述悬浮框中。

19.一种支付信息处理方法，包括：

发送订单页展示请求至第一服务器；

接收第一服务器返回的订单数据，并在订单展示页展示所述订单数据；

在接收到支付触发操作后，向第二服务器发起支付请求；

接收所述第二服务器根据所述支付请求中的用户信息确定进入第一支付模式的反馈，所述反馈包括利用推荐的支付渠道对所述订单数据进行支付时的支付渠道相关信息；

在订单展示页之上生成的一个悬浮框，并将推荐的支付渠道的相关信息在所述悬浮框中展示。

20.一种支付信息处理装置，其特征在于，包括：

支付模式选择模块，用于根据接收到的订单触发操作，确定进入第一支付模式；

数据获取模块，用于获取订单数据和支付界面数据；

同步展示模块，用于基于所述订单数据和支付界面数据渲染订单展示页；

支付模块，用于在接收到支付触发操作后，以第一支付模式对所述订单数据进行支付。

21.一种支付信息处理装置，其特征在于，包括：

订单页展示模块，用于获取订单数据，并基于所述订单数据渲染订单展示页；

支付模式选择模块，用于在接收到支付触发操作后，确定进入第一支付模式；

支付信息展示模块，用于在订单展示页之上生成的一个悬浮框，并将推荐的支付渠道的相关信息在所述悬浮框中展示；

快捷支付模块，用于利用推荐的支付渠道对所述订单数据进行支付。