WO2024016634A1

WO2024016634A1 - 基于智能路由的远程支付方法、终端、装置、系统及介质

Info

Publication number: WO2024016634A1
Application number: PCT/CN2023/074832
Authority: WO
Inventors: 王钰; 周继恩; 陈卓; 黄河; 沈玺; 徐鑫源; 谢治民; 武晓龙; 胡晔州; 程晨; 黄永生
Original assignee: 中国银联股份有限公司
Priority date: 2022-07-19
Filing date: 2023-02-07
Publication date: 2024-01-25
Also published as: CN115293753A; TW202405715A

Abstract

本申请公开了一种基于智能路由的远程支付方法、终端、装置、系统及介质，属于数据处理领域。该方法包括：在电子商务应用程序触发多方支付入口的情况下，调用第一SDK向远程支付平台发送列表请求消息；调用第一SDK从远程支付平台获取第一支付应用列表，第一支付应用列表表征远程支付平台支持的多个优先级由高至低排列的支付应用程序；调用第一SDK获取第二支付应用列表，第二支付应用列表表征用户终端具有的支付应用程序；由第一SDK调起第一支付应用列表与第二支付应用列表的交集中优先级最高的支付应用程序；通过该支付应用程序调用第二SDK与远程支付平台交互，完成支付。

Description

基于智能路由的远程支付方法、终端、装置、系统及介质

相关申请的交叉引用

本申请要求享有于2022年07月19日提交的名称为“基于智能路由的远程支付方法、终端、装置、系统及介质”的中国专利申请202210846578.3的优先权，该申请的全部内容通过引用并入本文中。

技术领域

本申请属于数据处理领域，尤其涉及一种基于智能路由的远程支付方法、终端、装置、系统及介质。

背景技术

随着支付技术的发展，用户对支付的需求也越来越多。为了满足用户购物或其他事项的需求，越来越多的商户开发电子商务应用程序并向用户提供电子商务应用程序。商户可通过电子商务应用程序与用户进行交互，用户可对安装在用户终端的电子商务应用程序进行操作实现购物等事宜，通过远程支付技术付款。

在支付过程中，用户需要在电子商务应用程序的支付界面手动选取支付应用程序，跳转到该支付应用程序进行支付操作，支付效率较低。

发明内容

本申请实施例提供一种基于智能路由的远程支付方法、终端、装置、系统及介质，能够提高支付效率。

第一方面，本申请实施例提供一种基于智能路由的远程支付方法，应用于用户终端，用户终端具有电子商务应用程序、集成在电子商务应用程序的第一软件开发工具包SDK、支付应用程序以及与集成在支付应用程序的第二SDK，电子商务应用程序属于第一主体，支付应用程序属于第二主体，第一SDK和第二SDK属于第三主体，该方法包括：在电子商务应用程序触发多方支付入口的情况下，调用第一SDK向远程支付平台发送列表请求消息，列表请求消息包括列表要求信息，列表要求信息包括电子商务应用标识和用户标识；调用第一SDK从远程支付平台获取第一支付应用列表，第一支付应用列表表征远程支付平台支持的多个优先级由高至低排列的支付应用程序，优先级由远程支付平台基于列表要求信息对应的关联数据得到；调用第一SDK获取第二支付应用列表，第二支付应用列表表征用户终端具有的支付应用程序；由第一SDK调起第一目标支付应用程序，第一目标支付应用程序为第一支付应用列表与第二支付应用列表的交集中优先级最高的支付应用程序；通过第一目标支付应用程序调用第二SDK与远程支付平台交互，完成支付。

第二方面，本申请实施例提供一种基于智能路由的远程支付方法，应用于远程支付平台，该方法包括：在用户终端的电子商务应用程序触发多方支付入口的情况下，接收用户终端调用第一软件开发工具包SDK发送的列表请求消息，列表请求消息包括列表要求信息，列表要求信息包括电子商务应用标识和用户标识，用户终端具有电子商务应用程序、集成在电子商务应用程序的第一SDK、支付应用程序以及与集成在支付应用程序的第二SDK，电子商务应用程序属于第一主体，支付应用程序属于第二主体，第一SDK和第二SDK属于第三主体；根据列表请求消息，获取列表要求信息对应的关联数据，并基于关联数据，得到远程支付平台支持的支付应用程序的优先级；根据远程支付平台支持的支付应用程序的优先级，生成第一支付应用列表，并向用户终端发送，第一支付应用列表表征远程支付平台支持的多个优先级由高至低排列的支付应用程序；与用户终端的第一目标支付应用程序的第二SDK交互，完成支付，第一目标支付应用程序为第一支付应用列表与第二支付应用列表的交集中优先级最高的支付应用程序，第二支付应用列表表征用户终端具有的支付应用程序。

第三方面，本申请实施例提供一种用户终端，其特征在于，用户终端具有电子商务应用程序、集成在电子商务应用程序的第一软件开发工具包SDK、支付应用程序以及与集成在支付应用程序的第二SDK，电子商务应用程序属于第一主体，支付应用程序属于第二主体，第一SDK和第二SDK属于第三主体，用户终端包括：通信模块，用于在电子商务应用程序触发多方支付入口的情况下，被第一SDK调用向远程支付平台发送列表请求消息，列表请求消息包括列表要求信息，列表要求信息包括电子商务应用标识和用户标识；以及，用于被第一SDK调用从远程支付平台获取第一支付应用列表，第一支付应用列表表征远程支付平台支持的多个优先级由高至低排列的支付应用程序，优先级由远程支付平台基于列表要求信息对应的关联数据得到；处理模块，用于被第一SDK调用获取第二支付应用列表，第二支付应用列表表征用户终端具有的支付应用程序；以及，用于调用第一SDK调起第一目标支付应用程序，第一目标支付应用程序为第一支付应用列表与第二支付应用列表的交集中优先级最高的支付应用程序；通信模块还用于被第一目标支付应用程序的第二SDK调用与远程支付平台交互，完成支付。

第四方面，本申请实施例提供一种基于智能路由的远程支付装置，其特征在于，应用于远程支付平台，基于智能路由的远程支付装置包括：通信模块，用于在用户终端的电子商务应用程序触发多方支付入口的情况下，接收用户终端调用第一软件开发工具包SDK发送的列表请求消息，列表请求消息包括列表要求信息，列表要求信息包括电子商务应用标识和用户标识，用户终端具有电子商务应用程序、集成在电子商务应用程序的第一SDK、支付应用程序以及与集成在支付应用程序的第二SDK，电子商务应用程序属于第一主体，支付应用程序属于第二主体，第一SDK和第二SDK属于第三主体；处理模块，用于根据列表请求消息，获取列表要求信息对应的关联数据，并基于关联数据，得到远程支付平台支持的支付应用程序的优先级；以及，用于根据远程支付平台支持的支付应用程序的优先级，生成第一支付应用列表，第一支付应用列表表征远程支付平台支持的多个优先级由高至低排列的支付应用程序；通信模块还用于向用户终端发送第一支付应用列表，以及，用于与用户终端的第一目标支付应用程序的第二SDK交互，完成支付，第一目标支付应用程序为第一支付应用列表与第二支付应用列表的交集中优先级最高的支付应用程序，第二支付应用列表表征用户终端具有的支付应用程序。

第五方面，本申请实施例提供一种用户终端，包括：处理器以及存储有计算机程序指令的存储器；处理器执行计算机程序指令时实现第一方面的基于智能路由的远程支付方法。

第六方面，本申请实施例提供一种电子设备，应用于远程支付平台，电子设备包括：处理器以及存储有计算机程序指令的存储器；处理器执行计算机程序指令时实现第二方面的基于智能路由的远程支付方法。

第七方面，本申请实施例提供一种远程支付系统，包括：用户终端，用户终端具有电子商务应用程序、集成在电子商务应用程序的第一软件开发工具包SDK、支付应用程序以及与集成在支付应用程序的第二SDK，电子商务应用程序属于第一主体，支付应用程序属于第二主体，第一SDK和第二SDK属于第三主体，用户终端用于执行第一方面的基于智能路由的远程支付方法；远程支付平台，用于执行第二方面的基于智能路由的远程支付方法。

第八方面，本申请实施例提供一种计算机可读存储介质，计算机可读存储介质上存储有计算机程序指令，计算机程序指令被处理器执行时实现第一方面的基于智能路由的远程支付方法或第二方面的基于智能路由的远程支付方法。

本申请实施例提供一种基于智能路由的远程支付方法、终端、装置、系统及介质，用户终端在电子商务应用程序触发多方支付入口的情况下，利用集成在电子商务应用程序的第一SDK与远程支付平台交互，向远程支付平台提供列表要求信息，以使远程支付平台根据列表要求信息，提供与列表要求信息对应的表征优先级由高至低排列的远程支付平台支持的多个支付应用程序的列表。第一SDK通过用户终端本地具有的支付应用程序和远程支付平台提供的表征优先级由高至低排列的远程支付平台支持的多个支付应用程序，确定本地具有的优先级最高的支付应用程序并自动调起，不需用户手动选择支付应用程序，自动调起的本地具有的优先级最高的支付应用程序即第一目标支付应用程序可调用第二SDK与远程支付平台交互，以完成支付。在该远程支付过程中，不需用户手动选取支付应用程序，能够自动调起与电子商务应用程序和用户适配的支付应用程序进行支付，提高了支付效率。

附图说明

为了更清楚地说明本申请实施例的技术方案，下面将对本申请实施例中所需要使用的附图作简单的介绍，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本申请实施例提供的基于智能路由的远程支付方法的一示例的应用场景架构图；

图2为本申请第一方面一实施例提供的基于智能路由的远程支付方法的流程图；

图3为本申请第一方面另一实施例提供的基于智能路由的远程支付方法的流程图；

图4为本申请第一方面又一实施例提供的基于智能路由的远程支付方法的流程图；

图5为本申请第一方面再一实施例提供的基于智能路由的远程支付方法的流程图；

图6为本申请第二方面一实施例提供的基于智能路由的远程支付方法的流程图；

图7为本申请第二方面另一实施例提供的基于智能路由的远程支付方法的流程图；

图8为本申请第二方面又一实施例提供的基于智能路由的远程支付方法的流程图；

图9为本申请第二方面再一实施例提供的基于智能路由的远程支付方法的流程图；

图10为本申请实施例提供的基于智能路由的远程支付流程的一示例的流程图；

图11为本申请实施例提供的基于智能路由的远程支付流程的另一示例的流程图；

图12为本申请第三方面一实施例提供的用户终端的结构示意图；

图13为本申请第四方面一实施例提供的基于智能路由的远程支付装置的结构示意图；

图14为本申请第五方面一实施例提供的用户终端的结构示意图。

具体实施方式

下面将详细描述本申请的各个方面的特征和示例性实施例，为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及具体实施例，对本申请进行进一步详细描述。应理解，此处所描述的具体实施例仅意在解释本申请，而不是限定本申请。对于本领域技术人员来说，本申请可以在不需要这些具体细节中的一些细节的情况下实施。下面对实施例的描述仅仅是为了通过示出本申请的示例来提供对本申请更好的理解。

随着支付技术的发展，用户对支付的需求也越来越多。为了满足用户购物或其他事项的需求，越来越多的商户开发电子商务应用程序并向用户提供电子商务应用程序。商户可通过电子商务应用程序与用户进行交互，用户可对安装在用户终端的电子商务应用程序进行操作实现购物等事宜，通过远程支付技术付款。在支付过程中，用户需要在电子商务应用程序的支付界面手动选取支付应用程序，跳转到该支付应用程序进行支付操作，支付效率较低。

本申请提供一种基于智能路由的远程支付方法、终端、装置、系统及介质，能够通过用户终端与远程支付平台的交互，在电子商务应用程序触发多方支付入口的情况下，利用集成在电子商务应用程序的软件开发工具包(Software Development Kit，SDK)与远程支付平台交互，自动确定并拉起支付应用程序，不需用户手动选择支付应用程序，即可进行支付。

本申请实施例中的基于智能路由的远程支付方法可涉及用户、商户、远程支付管理方和发卡行等主体。商户可为用户提供电子商务应用程序，发卡行等机构可为用户提供支付应用程序。远程支付管理方可提供集成在电子商务应用程序中的SDK和集成在支付应用程序中的SDK。用户可利用具有电子商务应用程序、集成在电子商务应用程序中的SDK、支付应用程序和集成在支付应用程序中的SDK的用户终端与远程支付管理方的平台进行交互，以使远程支付管理方的平台与资源管理系统进行交互，由资源管理系统完成用户的资源卡中资源的转入和转出，实现支付。

例如，图1为本申请实施例提供的基于智能路由的远程支付方法的一示例的应用场景架构图。如图1所示，远程支付系统可包括用户终端11、远程支付平台12和资源管理系统13。

用户终端11具有电子商务应用程序111和支付应用程序112，电子商务应用程序111集成有第一SDK 113，支付应用程序112集成有第二SDK114。电子商务应用程序属于第一主体，支付应用程序属于第二主体，第一SDK和第二SDK属于第三主体。第一主体可为商户等，第二主体可为发卡行、支付服务提供方等，第三主体可为卡组织、收单机构等远程支付管理方，在此并不限定。在一些示例中，第二主体和第三主体可为同一主体，例如，在第三主体也可开发并向用户提供支付应用程序的情况下，用户终端11可利用第三主体的支付应用程序进行支付，第二主体与第三主体可为同一主体。第一SDK可提供订单处理功能和调起支付应用程序的功能。第二SDK可提供支付控件、主动扫码、被动扫码等支付功能。用户终端11可包括手机、平板电脑、可穿戴设备等可进行支付的终端设备，在此并不限定用户终端11的类型。用户终端11可通过第一SDK 113和第二SDK 114与远程支付平台12通信交互。

远程支付平台12为远程支付管理方的服务平台，可管理第一SDK113和第二SDK 114，与第一SDK 113和第二SDK 114通信交互，也可进行用户的支付应用程序的多方支付功能的授权开通以及资源卡绑定处理，还可进行支付的处理和统计。多方支付功能指支付应用程序通过集成的第二SDK接入远程支付平台进行支付的功能。开通多方支付功能的支付应用程序的支付可通过远程支付平台12进行。用户可通过前往发卡行或通过支付应用程序开通终端设备中支付应用程序的多方支付功能。远程支付平台12可包括多台如服务器等的电子设备，在此并不限定远程支付平台12中电子设备的类型和数量。远程支付平台12可与资源管理系统13通信交互，资源管理系统13可完成用户用于支付的资源卡中资源的转入和转出。

下面对本申请提供的基于智能路由的远程支付方法、用户终端、装置、设备、系统及介质依次进行介绍。

本申请第一方面提供一种基于智能路由的远程支付方法，可应用于用户终端，即该基于智能路由的远程支付方法可由用户终端执行。用户终端具有电子商务应用程序、集成在电子商务应用程序的第一SDK、支付应用程序以及与集成在支付应用程序的第二SDK，电子商务应用程序、第一SDK、支付应用程序、第二SDK的具体内容可参见上述实施例中的相关说明，在此不再赘述。图2为本申请第一方面一实施例提供的基于智能路由的远程支付方法的流程图。如图2所示，该基于智能路由的远程支付方法可包括步骤S201至步骤S205。

在步骤S201中，在电子商务应用程序触发多方支付入口的情况下，调用第一SDK向远程支付平台发送列表请求消息。

多方支付入口为电子商户应用程序中多方支付功能的入口。多方支付入口被触发，则利用多方支付功能进行支付。例如，用户对订单界面的多方支付入口进行输入，触发多方支付入口，多方支付入口可实现为多方支付功能的触发控件，在此并不限定。在多方支付入口被触发的情况下，用户终端可调用电子商务应用程序中集成的第一SDK向远程支付平台发送列表请求消息。

列表请求消息用于向远程支付平台请求支付应用程序的列表。列表请求消息可包括列表要求信息。列表要求信息表征对请求的支付应用程序的列表中表征的支付应用程序的要求。列表要求信息不同，请求得到的支付应用程序的列表中的信息也可能不同。列表要求信息可包括电子商务应用标识和用户标识。电子商务应用标识用于标识电子商务应用程序，可包括电子商务应用程序的编号、名称等能够在远程支付平台唯一标识电子商务应用程序的信息，在此并不限定。用户标识用于标识用户，可包括用户的账号名称、脱敏后的用户个人信息等能够在远程支付平台唯一标识用户的信息，在此并不限定。

在一些示例中，列表要求信息还可包括以下一项或多项：用户终端操作系统版本、第一SDK的版本、第二SDK的版本。用户终端操作系统版本表征用户终端的操作系统的版本。不同的用户终端操作系统版本、第一SDK的版本、第二SDK的版本，能够支持的支付应用程序可能不同，对应地，请求得到的支付应用程序的列表中的信息可能不同。

在一些示例中，列表请求消息还可包括订单信息，以使远程支付平台可根据订单信息进行订单处理。或者，在用户终端调用第一SDK向远程支付平台发送列表请求消息之前、之后或同时，也可调用第一SDK向远程支付平台发送订单信息，以使远程支付平台可根据订单信息进行订单处理。

在步骤S202中，调用第一SDK从远程支付平台获取第一支付应用列表。

第一支付应用列表表征远程支付平台支持的多个优先级由高至低排列的支付应用程序。具体地，第一支付应用列表可包括远程支付平台支持的多个优先级由高至低排列的支付应用程序的标识，每个标识可表征一个支付应用程序。优先级为支付应用程序被调用的优先级，可由远程支付平台基于列表要求信息对应的关联数据得到。

远程支付平台接收到列表请求消息，可根据列表请求消息中的列表要求信息，获取与列表要求信息对应的关联数据；根据关联数据，得到远程支付平台支持的支付应用程序的优先级；根据优先级，生成第一支付应用列表，并向用户终端的第一SDK提供第一支付应用列表。远程支付平台支持的支付应用程序包括开通多方支付功能的第二主体的支付应用程序。需要说明的是，第二主体的支付应用程序开通多方支付功能，表示第二主体授权支付应用程序具有可开通多方支付功能的权限，用户终端中的支付应用程序仍需要用户开通多方支付功能后，才具有多方支付功能。

关联数据包括与列表要求信息关联的历史支付数据和/或自定义数据。不同的列表要求信息对应的关联数据可能不同，不同的关联数据对应的第一支付应用列表也可能不同，即不同的列表要求信息对应的第一支付应用列表可能不同。

例如，列表要求信息包括电子商务应用标识和用户标识，在用户标识相同、电子商务应用标识不同的情况下，同一用户使用不同电子商务应用程序关联的历史支付数据和/或自定义数据可能不同，获取的第一支付应用列表也可能不同；在用户标识不同、电子商务应用标识相同不同的情况下，不同用户使用相同的电子商务应用程序关联的历史支付数据和/或自定义数据可能不同，获取的第一支付应用列表也可能不同；在用户标识不同、电子商务应用标识不同的情况下，不同用户使用不同的电子商务应用程序关联的历史支付数据和/或自定义数据可能不同，获取的第一支付应用列表也可能不同。

又例如，列表要求信息还包括用户终端操作系统版本，不同用户终端操作系统版本所支持的支付应用程序也可能不同，获取的第一支付应用列表也可能不同；列表要求信息还包括第一SDK的版本，不同第一SDK的版本所支持的支付应用程序也可能不同，获取的第一支付应用列表也可能不同；列表要求信息还包括第二SDK的版本，不同第二SDK的版本所对应的支付应用程序也可能不同，获取的第一支付应用列表也可能不同。

关联数据的种类在此并不限定，根据关联数据确定支付应用程序的优先级的优先级确定策略可根据关联数据的种类、具体场景、需求等设定，在此并不限定。在关联数据包括多项的情况下，可为每项关联数据设置权重，根据权重，利用权重算法，确定支付应用程序的优先级。在一些示例中，关联数据包括以下一项或多项：支付应用程序支付频率、支付应用程序支付成功率、支付应用程序支付资源量、支付应用程序支付时间、用户在支付应用程序的支付信用度、第一主体指定的支付应用程序的调起顺序、第三主体指定的支付应用程序的调起顺序。

支付应用程序支付频率为支付应用程序被使用支付的频率，在一些示例中，支付应用程序支付频率越高，支付应用程序的优先级越高。支付应用程序支付成功率为支付应用程序被使用支付的成功率，在一些示例中，支付应用程序支付成功率越高，支付应用程序的优先级越高。支付应用程序支付资源量为支付应用程序被使用支付的资源量，资源量可包括总资源量、平均资源量、最近一次支付的资源量等中的一项或多项，在此并不限定，在一些示例中，支付应用程序支付资源量越高，支付应用程序的优先级越高。支付应用程序支付时间可包括支付应用程序被使用支付的时间戳，可根据支付应用程序支付时间确定各个支付应用程序在一个时间段内被使用的先后顺序，在一些示例中，支付应用程序支付时间距离当前时间越近，支付应用程序的优先级越高。用户在支付应用程序的支付信用度为用户使用该支付应用程序进行支付的信用度，在一些示例中，用户在支付应用程序的支付信用度越高，支付应用程序的优先级越高。第一主体指定的支付应用程序的调起顺序包括第一主体预先设定的支付应用程序被第一SDK调起的顺序，在一些示例中，第一主体指定的支付应用程序的调起顺序中位于前位的支付应用程序的优先级相对于位于后位的支付应用程序的优先级更高。第三主体指定的支付应用程序的调起顺序包括第三主体预先设定的支付应用程序被第一SDK调起的顺序，在一些示例中，第三主体指定的支付应用程序的调起顺序中位于前位的支付应用程序的优先级相对于位于后位的支付应用程序的优先级更高。

例如，关联数据包括支付应用程序支付成功率，优先级确定策略为支付应用程序支付成功率越高，优先级越高；设用户A1在电子商务应用程序B1中利用支付应用程序C1的支付应用程序支付成功率为99.3％，用户A1在电子商务应用程序B1中利用支付应用程序C2的支付应用程序支付成功率为99.5％，用户A1在电子商务应用程序B1中利用支付应用程序C3的支付应用程序支付成功率为99％，则包括用户A1的标识和电子商务应用程序B1的标识的列表请求消息所对应的第一支付应用列表中支付应用程序按照优先级由高至低排列依次为支付应用程序C2、支付应用程序C1、支付应用程序C3；设用户A1在电子商务应用程序B2中利用支付应用程序C2的支付应用程序支付成功率为99.6％，用户A1在电子商务应用程序B2中利用支付应用程序C3的支付应用程序支付成功率为99.1％，用户A1在电子商务应用程序B2中利用支付应用程序C4的支付应用程序支付成功率为99.3％，优先级确定策略为支付成功率越高，优先级越高，则包括用户A1的标识和电子商务应用程序B2的标识的列表请求消息所对应的第一支付应用列表中支付应用程序按照优先级由高至低排列依次为支付应用程序C2、支付应用程序C4、支付应用程序C3，根据不同列表要求信息获取的第一支付应用列表不同。

又例如，关联数据包括支付应用程序支付时间，优先级确定策略为支付应用程序支付时间距离当前时间越近，优先级越高；设当前时间为2022年6月27日18:00，用户A1在电子商务应用程序B1中利用支付应用程序C1的支付应用程序支付时间为2022年1月15日9:05，用户A1在电子商务应用程序B1中利用支付应用程序C2的支付应用程序支付时间为2022年5月26日15:32，用户A1在电子商务应用程序B1中利用支付应用程序C3的支付应用程序支付时间为2022年6月23日21:16，则包括用户A1的标识和电子商务应用程序B1的标识的列表请求消息所对应的第一支付应用列表中支付应用程序按照优先级由高至低排列依次为支付应用程序C3、支付应用程序C2、支付应用程序C1。

在步骤S203中，调用第一SDK获取第二支付应用列表。

第二支付应用列表表征用户终端具有的支付应用程序。用户终端具有的支付应用程序即为用户终端安装有的支付应用程序。第一SDK可对用户终端本地的支付应用程序的scheme等进行标识检查，确定用户终端安装的支付应用程序。具体地，第二支付应用列表可包括用户终端具有的支付应用程序的标识。

在步骤S204中，由第一SDK调起第一目标支付应用程序。

第一目标支付应用程序为第一支付应用列表与第二支付应用列表的交集中优先级最高的支付应用程序。第一SDK可选取第一支付应用列表表征的支付应用程序与第二支付应用列表保证的支付应用程序的交集，并将该交集中的优先级最高的支付应用程序确定为第一目标支付应用程序并调起。第一目标支付应用程序被调起可自动启动，即用户终端自动跳转至第一目标支付应用程序。

例如，第一支付应用列表中按照优先级由高至低的顺序排列的支付应用程序分别为支付应用程序C3、支付应用程序C1、支付应用程序C4、支付应用程序C2和支付应用程序C5，第二支付应用列表中的支付应用程序分别为支付应用程序C1、支付应用程序C2和支付应用程序C4，则第一目标支付应用程序为支付应用程序C1，第一SDK调起第一目标支付应用程序，使第一目标支付应用程序参与支付流程。

用户终端不同的操作系统，可采用不同的方式调起第一目标支付应用程序。例如，在某些操作系统中可通过scheme的方式调起第一目标支付应用程序，在另一些操作系统中可通过intent的方式调起第一目标支付应用程序。

在一些示例中，可由第一SDK向第一目标支付应用程序发起调起信息，调起信息可包括第一信息和第二信息，第一信息可用于指示第一目标支付应用程序自动启动，第二信息可用于指示调起第一目标支付应用程序所显示的页面。第一目标支付应用程序响应于该调起信息自动启动，直接跳转至调起信息指示的页面。调起信息指示的页面可为支付页面或其他页面，在此并不限定。在一些示例中，scheme中可存储有可信支付应用程序名单，可信支付应用程序名单中记录的支付应用程序为第一SDK能够调起的支付应用程序，即第一SDK具有发送调起信息权限的支付应用程序。

在本示例中，在用户触发多方支付入口后，不需用户进行确认操作，也不需要用户在列表中进行选择操作来选择使用的支付应用程序，可直接调起用户终端中优先级最高的支付应用程序，缩短了远程控件支付流程的链路，减少了用户繁琐的操作路径，提升了用户体验。

在步骤S205中，通过第一目标支付应用程序调用第二SDK与远程支付平台交互，完成支付。

第一目标支付应用程序被调起，第一目标支付应用程序会调用自身集成的第二SDK与远程支付平台交互，以使远程支付平台与资源管理系统交互，完成支付的资源的转入、转出，完成支付。

第一目标支付应用程序的第二SDK可向远程支付平台发送支付请求消息。支付请求消息可包括用户标识。远程支付平台响应于支付请求消息，向第二SDK反馈资源卡列表，资源卡列表表征与用户标识对应的资源卡。在一些示例中，在第一目标支付应用程序开通多方支付功能的情况下，资源卡列表可表征该用户标识在远程支付平台对应的所有资源卡，并不只是第一目标支付应用程序绑定的资源卡，即资源卡列表可表征授权开通多方支付功能的各支付应用程序中用户标识对应的用户绑定的资源卡。在一些示例中，资源卡列表可表征该用户标识对应的用户在第一目标支付应用程序绑定的资源卡。用户终端可向用户展示资源卡列表，第二SDK响应于用户对资源卡列表的输入，确定用户选择的目标资源卡，向远程支付平台发送支付消息。支付消息可包括目标资源卡的标识和支付资源量。远程支付平台响应于支付消息，向资源管理系统发送支付消息，资源管理系统将支付资源量的资源从目标资源卡中转出，完成支付。

资源卡列表中资源卡的排列顺序可根据卡排列因素信息得到。卡排列因素信息可根据场景、需求等设定，在此并不限定。在一些示例中，卡排列因素信息可包括资源卡绑定顺序、资源卡使用时间、资源卡所属支付应用程序、资源卡属性、资源卡中资源量、资源卡状态等中的一项或多项。例如，资源卡列表中资源卡可按资源卡绑定顺序由早至晚排列，或者，资源卡列表中资源卡可按资源卡使用时间距离当前时间由近至远排列，或者，资源卡列表中资源卡可优先排列所属被调起的支付应用程序的资源卡等。在一些示例中，卡排列因素除了可确定资源卡列表中资源卡的排列顺序，还可对资源卡列表中可使用的资源卡进行标记或对资源卡列表中不可使用的资源卡进行标记，标记方法在此并不限定，可采用字体、颜色、加粗、下划线等方式进行标记。例如，资源卡属性为信用卡、资源卡中资源量不足以支付或资源卡状态为不可支付状态等情况下，可将该资源卡的标识置为灰色，并排列在资源卡列表的末尾；不可支付状态可包括销卡状态、挂失状态、止付状态、限制状态、未签约状态、未开通状态等，在此并不限定。

在一些示例中，不管支付是否成功，远程支付平台可向第一目标支付应用程序的第二SDK发送支付结果信息，第二SDK可将该支付结果信息向电子商务应用程序中的第一SDK传输，第一SDK再将该支付结果信息向电子商务应用程序传输，以使电子商务应用程序向用户展示支付结果信息。支付结果信息用于表征支付成功或支付失败。在支付成功的情况下，第二SDK可调起电子商务应用程序，使电子商务应用程序提示用户支付成功。

在本申请实施例中，用户终端在电子商务应用程序触发多方支付入口的情况下，利用集成在电子商务应用程序的第一SDK与远程支付平台交互，向远程支付平台提供列表要求信息，以使远程支付平台根据列表要求信息，提供与列表要求信息对应的表征优先级由高至低排列的远程支付平台支持的多个支付应用程序的列表。第一SDK通过用户终端本地具有的支付应用程序和远程支付平台提供的表征优先级由高至低排列的远程支付平台支持的多个支付应用程序，确定本地具有的优先级最高的支付应用程序并自动调起，不需用户手动选择支付应用程序，自动调起的本地具有的优先级最高的支付应用程序即第一目标支付应用程序可调用第二SDK与远程支付平台交互，以完成支付。在该远程支付过程中，不需用户手动选取支付应用程序，能够自动调起与电子商务应用程序和用户适配的支付应用程序进行支付，提高了支付效率。

此外，远程支付平台提供表征优先级由高至低排列的支付应用程序的第一支付应用列表，使得用户终端中第一SDK能够自动调起本地具有的优先级最高的支付应用程序进行支付，在无需用户进行支付应用程序选择操作的情况下，为用户主动调起优先级最高的支付应用程序，支付应用程序推荐过程是智能化的路由过程，实现了支付应用程序精准、合理的推荐，即实现了支付方式精准、合理的自动选择。

而且，在属于第一主体的电子商务应用程序中集成属于第三主体的第一SDK，在属于第二主体的支付应用程序中集成属于第三主体的第二SDK，使得电子商务应用程序和多个支付应用程序能够接入属于第三主体的远程支付平台，实现了多方支付功能。由此可得，多方支付功能使得多个支付应用程序接入同一远程支付平台，实现了多支付应用程序支付的线上平台共享，对远程控件支付流程进行了优化，缩短了用户支付的操作路径，提高了用户体验。

在一些实施例中，上述第一目标支付应用程序所属的第二主体授权第一目标支付应用程序具有可开通多方支付功能的权限，但用户终端中第一目标支付应用程序有可能未开通多方支付功能，因此在支付过程中，需对用户终端中第一目标支付应用程序是否开通多方支付功能进行检查。图3 为本申请第一方面另一实施例提供的基于智能路由的远程支付方法的流程图。图3与图2的不同之处在于，图3中的步骤S205可具体细化为图3中的步骤S2051至步骤S2053。

在步骤S2051中，通过第一目标支付应用程序调用第二SDK与远程支付平台交互，完成第二SDK的初始化。

第二SDK集成在支付应用程序中，在支付应用程序被调起需要使用该支付应用程序的第二SDK的情况下，需要对第二SDK进行初始化。第二SDK可调用init接口(即初始化接口)进行初始化。初始化可包括对环境的初始化，第二SDK可将获取的环境参数以及初始化需要的其他参数向远程支付平台发送，由远程支付平台判断第二SDK是否能够进行初始化，并向第二SDK反馈。第二SDK可根据远程支付平台的判断结果，确实是否继续执行初始化。

在一些示例中，若第一目标支付应用程序在用户终端第一次被使用，第一目标支付应用还可展示隐私信息授权页面，提示用户对第一目标支付应用程序对用户信息的使用进行授权。隐私信息授权页面可包括隐私信息授权说明、同意授权选项和拒绝授权选项。在用户同意授权第一目标支付应用程序使用用户信息的情况下，可进行第一目标支付应用程序的第二SDK的初始化。若第一目标支付应用程序在之前已经过用户对第一目标支付应用程序使用用户信息的授权，则不需再次展示隐私信息授权页面，可直接进行第一目标支付应用程序的第二SDK的初始化。

在步骤S2052中，由第二SDK查询本地存储的多方支付功能开通标识位，确定用户终端中的第一目标支付应用程序是否开通多方支付功能。

第二SDK初始化成功后，第二SDK还需要确定用户终端中的第一目标支付应用程序是否开通了多方支付功能。若用户终端中的第一目标支付应用程序未开通多方支付功能，第二SDK无法与远程支付平台交互完成后续的支付过程。

多方支付功能开通标识位可表征用户终端中的第一目标支付应用程序是否开通多方支付功能。多方支付功能开通标识位可用数字、字母或其他字符表示，在此并不限定。例如，多方支付功能开通标识位为1，表示用户终端中的第一目标支付应用程序已开通多方支付功能；多方支付功能开通标识位为0，表示用户终端中的第一目标支付应用程序未开通多方支付功能。

在步骤S2053中，在用户终端中的第一目标支付应用程序开通多方支付功能的情况下，由第二SDK与远程支付平台交互，完成支付。

用户终端中的第一目标支付应用程序开通多方支付功能，表示用户终端中的第一目标支付应用程序具有与远程支付平台交互完成支付的权限，第二SDK可与远程支付平台交互。

在一些示例中，步骤S2053还可进一步细化为：在用户终端中的第一目标支付应用程序开通多方支付功能的情况下，由第二SDK确定用户是否在第一目标支付应用程序登录；在用户在第一目标支付应用程序已登录的情况下，由第二SDK与远程支付平台交互，完成支付。由于若用户未在第一目标支付应用程序登录，第一目标支付应用程序相当于没有得到用户的使用授权，即使第一SDK调起第一目标支付应用程序，第一目标支付应用程序也不能正常进行支付。在用户终端中的第一目标支付应用程序开通多方支付功能，且用户在第一目标支付应用程序登录的情况下，第一目标支付应用程序才能够正常使用多方支付功能进行支付。

在一些实施例中，在第一目标支付应用程序未开通多方支付功能，或，用户在第一目标支付应用程序未登录的情况下，可采取其他措施辅助用户进行支付，以提高支付成功率。图4为本申请第一方面又一实施例提供的基于智能路由的远程支付方法的流程图。图4与图2的不同之处在于，图4所示的基于智能路由的远程支付方法还可包括步骤S206，或，包括步骤S207至步骤S209，或，包括步骤210和步骤S211。

在步骤S206中，在用户终端中的第一目标支付应用程序未开通多方支付功能，或，用户在第一目标支付应用程序未登录的情况下，通过第一目标支付应用程序的第二SDK调起第二目标支付应用程序，由第二目标支付应用程序的第二SDK与远程支付平台交互，完成支付。

在用户终端中的第一目标支付应用程序未开通多方支付功能，或，用户在第一目标支付应用程序未登录的情况下，第一目标支付应用程序不能正常使用多方支付功能进行支付。为了提高支付成功率，第一目标支付应用程序的第二SDK可调起第二支付应用程序继续支付流程。第二目标支付应用程序为指定的支付应用程序或第一支付应用列表与第二支付应用列表的交集中优先级次高的支付应用程序。指定的支付应用程序可以为一个，也可以为多个。在指定的支付应用程序为多个的情况下，第二目标支付应用程序为指定的支付应用程序中的任意一个，或其中优先级最高的一个，在此并不限定。在一些示例中，第二目标支付应用程序可包括由第一主体或第三主体指定的支付应用程序。第一支付应用列表与第二支付应用列表的交集中优先级次高的支付应用程序，即为第一支付应用列表与第二支付应用列表的交集中优先级仅次于第一目标支付应用程序的支付应用程序。例如，第一支付应用列表与第二支付应用列表的交集中，支付应用程序按照优先级由高至低的顺序排列依次为支付应用程序C2、支付应用程序C1、支付应用程序C4和支付应用程序C3，则第一目标支付应用程序为支付应用程序C2，第二目标支付应用程序为支付应用程序C1。

在第二目标支付应用程序被调起的情况下，由第二目标支付应用程序的第二SDK与远程支付平台交互，完成支付。第二目标支付应用程序的第二SDK与远程支付平台交互完成支付的具体内容和第一目标支付应用程序的第二SDK与远程支付平台交互完成支付的具体内容基本一致，在此不再赘述。

在第一目标支付应用程序不能正常使用多方支付功能进行支付的情况下，用户终端可自动调起用户终端中的其他支付应用程序，通过其他支付应用程序的第二SDK与远程平台交互以完成支付，避免支付失败，提高了支付成功率，且该过程不需用户手动操作，也提高了用户的支付体验。

在步骤S207中，在用户终端中的第一目标支付应用程序未开通多方支付功能，或，用户在第一目标支付应用程序未登录的情况下，通过第一目标支付应用程序的第二SDK与远程支付平台交互，以展示支付选择页面。

在用户终端中的第一目标支付应用程序未开通多方支付功能，或，用户在第一目标支付应用程序未登录的情况下，第一目标支付应用程序不能正常使用多方支付功能进行支付。为了提高支付成功率，远程支付平台可向第一目标支付应用程序的第二SDK提供支付选择页面，支付选择页面包括开通多方支付功能的支付应用程序的标识，以供用户进行选择。

在步骤S208中，响应于用户的第一选择输入，在支付选择页面中确定第三目标支付应用程序。

第一选择输入为用户对支付选择页面的选择输入，第一选择输入可指示支付选择页面中的一个支付应用程序的标识，第三目标支付应用程序即为第一选择输入在支付选择页面中指示的支付应用程序。

在步骤S209中，通过第一目标支付应用程序的第二SDK调起第三目标支付应用程序，由第三目标支付应用程序的第二SDK与远程支付平台交互，完成支付。

在第三目标支付应用程序被调起的情况下，由第三目标支付应用程序的第二SDK与远程支付平台交互，完成支付。第三目标支付应用程序的第二SDK与远程支付平台交互完成支付的具体内容和第一目标支付应用程序的第二SDK与远程支付平台交互完成支付的具体内容基本一致，在此不再赘述。

在第一目标支付应用程序不能正常使用多方支付功能进行支付的情况下，远程支付平台可向用户终端中第一目标支付应用程序的第二SDK提供支付选择页面，以供用户选择调起的支付应用程序，用户选择调起的支付应用程序即第三目标支付应用程序进行的支付被取消的可能性较小，可进一步提高支付的成功率。

在步骤S210中，在第一目标支付应用程序未开通多方支付功能，或，用户在第一目标支付应用程序未登录的情况下，展示第一引导信息和/或第二引导信息。

第一引导信息用于引导用户为第一目标支付应用程序开通多方支付功能。用户终端响应于用户对第一引导信息的操作输入，通过第一目标支付应用程序的第二SDK与远程支付平台交互，以开通用户终端中第一目标支付应用程序的多方支付功能。

第二引导信息用于引导用户登录第一目标支付应用程序。用户终端可响应于用户对第二引导信息的操作输入，通过第一目标支付应用程序与第一目标支付应用程序的后台系统交互，以实现用户在第一目标支付应用程序的登录。

在步骤S211中，在第一目标支付应用程序开通多方支付功能且用户在第一目标支付应用程序已登录的情况下，由第一目标支付应用程序的第二SDK与远程支付平台交互，完成支付。

在第一目标支付应用程序开通多方支付功能且用户在第一目标支付应用程序已登录的情况下，第一目标支付应用程序可正常使用多方支付功能进行支付，则可调用第一目标支付应用程序的第二SDK与远程支付平台交互完成支付。

通过引导用户开通用户终端中第一目标支付应用程序的多方支付功能，以及，引导用户在第一目标支付应用程序登录，可继续通过第一目标支付应用程序的第二SDK完成支付，避免支付失败，提高支付的成功率。

在一些实施例中，在支付过程中可能会出现支付取消的情况，支付取消可能由多种原因引起，可通过提供支付选择页面，向用户再次确定是否取消本次支付，避免误操作或程序错误导致的支付失败。图5为本申请第一方面再一实施例提供的基于智能路由的远程支付方法的流程图。图5与图2的不同之处在于，图5所示的基于智能路由的远程支付方法还可包括步骤S212至步骤S215。

在步骤S212中，调用第二SDK通过支付前置协议接口或监听接口监听是否出现支付取消动作。

用户输入导致的取消支付或程序错误导致的取消支付均会产生支付取消动作。第二SDK可通过支付前置协议接口或监听接口监听支付取消动作。在支付取消动作出现的情况下，支付前置协议接口或监听接口能够接收到触发指令，通过触发指令可调起第一目标支付应用程序的第二SDK执行步骤S213。

在步骤S213中，在出现支付取消动作的情况下，调用第二SDK与远程支付平台交互，以展示支付选择页面。

第一目标支付应用程序的第二SDK与远程支付平台交互，从远程支付平台获取并展示支付选择页面。支付选择页面包括开通多方支付功能的支付应用程序的标识，支付选择页面的具体内容可参见上述实施例中的相关说明，在此不再赘述。

在步骤S214中，响应于用户的第二选择输入，在支付选择页面中确定第四目标支付应用程序。

第二选择输入为用户对支付选择页面的选择输入，第二选择输入可指示支付选择页面中的一个支付应用程序的标识，第四目标支付应用程序即为第二选择输入在支付选择页面中指示的支付应用程序。

在步骤S215中，通过第一目标支付应用程序的第二SDK调起第四目标支付应用程序，并由第四目标支付应用程序的第二SDK与远程支付平台交互，完成支付。

在第四目标支付应用程序被调起的情况下，由第四目标支付应用程序的第二SDK与远程支付平台交互，完成支付。第四目标支付应用程序的第二SDK与远程支付平台交互完成支付的具体内容和第一目标支付应用程序的第二SDK与远程支付平台交互完成支付的具体内容基本一致，在此不再赘述。

在支付过程中可能会出现支付取消的情况下，通过提供支付选择页面，向用户再次确定是否取消本次支付，并提供其他支付应用程序的选择，能够避免误操作或程序错误导致的支付失败，提高支付的成功率。

在一些示例中，上述实施例中用户终端中第一目标支付应用程序未开通多方支付功能、用户在第一目标支付应用程序未登录等情况也可回调支付前置协议接口或监听接口，通知第一目标支付应用程序，以使第一目标支付应用程序跳转至对应的开通多方支付功能流程、登录流程等。若开通多方支付功能流程中成功开通多方支付功能和/或在登录流程中成功登录，第一目标支付应用程序会回调第二SDK，第二SDK继续远程支付流程。若开通多方支付功能流程中开通多方支付功能失败和/或在登录流程中登录失败，也可回调第二SDK，第二SDK与远程支付平台交互，以展示支付选择页面。

本申请第二方面提供一种基于智能路由的远程支付方法，可应用于远程支付平台，即该基于智能路由的远程支付方法可由远程支付平台执行。图6为本申请第二方面一实施例提供的基于智能路由的远程支付方法的流程图。如图6所示，该基于智能路由的远程支付方法可包括步骤S301至步骤S304。

在步骤S301中，在用户终端的电子商务应用程序触发多方支付入口的情况下，接收用户终端调用第一SDK发送的列表请求消息。

列表请求消息包括列表要求信息。列表要求信息包括电子商务应用标识和用户标识。

在一些示例中，列表要求信息还可包括以下一项或多项：用户终端操作系统版本、第一SDK的版本、第二SDK的版本。

用户终端具有电子商务应用程序、集成在电子商务应用程序的第一SDK、支付应用程序以及与集成在支付应用程序的第二SDK。其中，电子商务应用程序属于第一主体，支付应用程序属于第二主体，第一SDK和第二SDK属于第三主体。

在步骤S302中，根据列表请求消息，获取列表要求信息对应的关联数据，并基于关联数据，得到远程支付平台支持的支付应用程序的优先级。

不同的列表要求信息对应的关联数据可能不同，不同的关联数据对应能够得到的远程支付平台支持的支付应用程序的优先级也可能不同，具体内容可参见上述实施例中的说明，在此不再赘述。

在一些示例中，关联数据包括以下一项或多项：支付应用程序支付频率、支付应用程序支付成功率、支付应用程序支付资源量、支付应用程序支付时间、用户在支付应用程序的支付信用度、第一主体指定的支付应用程序的调起顺序、第三主体指定的支付应用程序的调起顺序。

在步骤S303中，根据远程支付平台支持的支付应用程序的优先级，生成第一支付应用列表，并向用户终端发送。

第一支付应用列表表征远程支付平台支持的多个优先级由高至低排列的支付应用程序。

在步骤S304中，与用户终端的第一目标支付应用程序的第二SDK交互，完成支付。

第一目标支付应用程序为第一支付应用列表与第二支付应用列表的交集中优先级最高的支付应用程序。第二支付应用列表表征用户终端具有的支付应用程序。

步骤S301至步骤S304的具体内容可参见上述实施例中的相关说明，在此不再赘述。

在本申请实施例中，在用户终端的电子商务应用程序触发多方支付入口的情况下，远程支付平台与集成在电子商务应用程序的第一SDK交互，从第一SDK获取列表要求信息，根据列表要求信息，向第一SDK提供与列表要求信息对应的表征优先级由高至低排列的远程支付平台支持的多个支付应用程序的列表。第一SDK通过用户终端本地具有的支付应用程序和远程支付平台提供的表征远程支付平台支持的优先级由高至低排列的多个支付应用程序，确定本地具有的优先级最高的支付应用程序并自动调起，不需用户手动选择支付应用程序。远程支付平台与用户终端自动调起的本地具有的优先级最高的支付应用程序即第一目标支付应用程序的第二SDK交互，以完成支付。在该远程支付过程中，不需用户手动选取支付应用程序，用户终端能够自动调起与电子商务应用程序和用户适配的支付应用程序进行支付，提高了支付效率。

在一些实施例中，上述第一目标支付应用程序所属的第二主体授权第一目标支付应用程序具有可开通多方支付功能的权限，但用户终端中第一目标支付应用程序有可能未开通多方支付功能，因此在支付过程中，需对用户终端中第一目标支付应用程序是否开通多方支付功能进行检查。图7为本申请第二方面另一实施例提供的基于智能路由的远程支付方法的流程图。图7与图6的不同之处在于，图6中的步骤S304可具体细化为图7中的步骤S3041和步骤S3042。

在步骤S3041中，与第一目标支付应用程序的第二SDK交互，完成第二SDK的初始化。

在步骤S3042中，在第二SDK确定用户终端中的第一目标支付应用程序开通多方支付功能的情况下，与第一目标支付应用程序的第二SDK交互，完成支付。

在一些示例中，还可在用户在第一目标支付应用程序已登录的情况下，与第一目标支付应用程序的第二SDK交互，完成支付。即，在第二SDK确定用户终端中的第一目标支付应用程序开通多方支付功能，且用户在第一目标支付应用程序已登录的情况下，与第一目标支付应用程序的第二SDK交互，完成支付。

上述步骤S3041和步骤S3042的具体内容可参见上述实施例中的相关说明，在此不再赘述。

在一些实施例中，在第一目标支付应用程序未开通多方支付功能，或，用户在第一目标支付应用程序未登录的情况下，可采取其他措施辅助用户进行支付，以提高支付成功率。图8为本申请第二方面又一实施例提供的基于智能路由的远程支付方法的流程图。图8与图6的不同之处在于，图8所示的基于智能路由的远程支付方法还可包括步骤S305，或者，包括步骤S306和步骤S307，或者，包括步骤S308和步骤S309。

在步骤S305中，在用户终端中的第一目标支付应用程序未开通多方支付功能，或，用户在第一目标支付应用程序未登录的情况下，与用户终端中第二目标支付应用程序的第二SDK交互，完成支付。

第二目标支付应用程序为指定的支付应用程序或第一支付应用列表与第二支付应用列表的交集中优先级次高的支付应用程序。

在步骤S306中，在用户终端中的第一目标支付应用程序未开通多方支付功能，或，用户在第一目标支付应用程序未登录的情况下，与用户终端中第一目标支付应用程序的第二SDK交互，提供支付选择页面。

支付选择页面包括开通多方支付功能的支付应用程序的标识。

在步骤S307中，与用户终端中第三目标支付应用程序的第二SDK交互，完成支付。

第三目标支付应用程序包括用户终端响应于用户的第一选择输入，在支付选择页面中确定的支付应用程序

在步骤S308中，在第一目标支付应用程序未开通多方支付功能，或，用户在第一目标支付应用程序未登录的情况下，与用户终端中第一目标支付应用程序的第二SDK交互，为用户终端中第一目标支付应用程序开通多方支付功能。

在步骤S309中，在第一目标支付应用程序开通多方支付功能且用户在第一目标支付应用程序已登录的情况下，与用户终端中第一目标支付应用程序的第二SDK交互，完成支付。

上述步骤S305至步骤S309的具体内容可参见上述实施例中的相关说明，在此不再赘述。

在一些实施例中，在支付过程中可能会出现支付取消的情况，支付取消可能由多种原因引起，可通过提供支付选择页面，向用户再次确定是否取消本次支付，避免误操作或程序错误导致的支付失败。图9为本申请第二方面再一实施例提供的基于智能路由的远程支付方法的流程图。图9与图6的不同之处在于，图9所示的基于智能路由的远程支付方法还可包括步骤S310和步骤S311。

在步骤S310中，在用户终端监听到支付取消动作的情况下，与用户终端中第一目标支付应用程序的第二SDK交互，提供支付选择页面。

在步骤S311中，与用户终端中第四目标支付应用程序的第二SDK交互，完成支付。

第四目标支付应用程序包括用户终端响应于用户的第二选择输入在支付选择页面中确定的支付应用程序。

上述步骤S310和步骤S311的具体内容可参见上述实施例中的相关说明，在此不再赘述。

为了便于理解，下面从电子商务应用程序、第一SDK、支付应用程序、第二SDK以及远程支付平台之间的交互来对上述实施例中第一目标支付应用程序被调起以及进行支付的流程进行说明。图10为本申请实施例提供的远程支付流程的一示例的流程图。如图10所示，该远程支付流程可包括步骤S401至步骤S413。

在步骤S401中，用户终端中的电子商务应用程序接收用户对多方支付入口的触发输入。

在步骤S402中，响应于触发输入，电子商务应用程序向第一SDK发送订单信息和电子商务应用标识。

在步骤S403中，第一SDK向远程支付平台发送列表请求消息。列表请求消息可包括列表要求信息和订单信息。

在步骤S404中，远程支付平台根据列表请求消息，生成订单。

在步骤S405中，远程支付平台根据列表要求信息，获取与列表要求信息对应的关联数据，基于关联数据，得到远程支付平台支持的支付应用程序的优先级，生成第一支付应用列表。

在步骤S406中，远程支付平台向第一SDK发送第一支付应用列表。

在步骤S407中，第一SDK从用户终端获取第二支付应用列表，根据第一支付应用列表和第二支付应用列表，调起第一目标支付应用程序。

在步骤S408中，第一目标支付应用程序调用第一目标支付应用程序的第二SDK。

在步骤S409中，第二SDK向用户请求进行支付验证。

在步骤S410中，在支付验证通过的情况下，第二SDK与远程支付平台交互，进行支付。

在步骤S411中，远程支付平台得到支付结果信息，向第二SDK发送支付结果信息。

在步骤S412中，第二SDK向第一SDK发送支付结果信息。

在步骤S413中，第一SDK向电子商务应用程序发送支付结果信息。

上述步骤S401至步骤S413的具体内容可参见上述实施例中的相关说明，在此不再赘述。

在上述远程支付过程中，还需对第二SDK进行初始化、检测用户终端中第一目标支付应用程序是否开通多方支付功能以及用户是否登录等动作。下面从电子商务应用程序、第一SDK、支付应用程序、第二SDK以及远程支付平台之间的交互来对上述远程支付流程进行说明，该示例中省去了上述示例中的第一目标支付应用程序具体如何被调起的内容。图11为本申请实施例提供的远程支付流程的另一示例的流程图。如图11所示，该远程支付流程可包括步骤S501至步骤S517。

在步骤S501中，用户终端响应于用户对电子商务应用程序的多方支付入口的触发输入，利用第一SDK调起第一目标支付应用程序。

在步骤S502中，第一目标支付应用程序调用第一目标支付应用程序的第二SDK。

在步骤S503中，第二SDK与远程支付平台交互，完成第二SDK的初始化。

在步骤S504中，第一目标支付应用程序实现支付前置协议及监听。

在步骤S505中，第二SDK进行订单处理。

在步骤S506中，第二SDK判断用户是否在第一目标支付应用程序开通多方支付功能，若还未开通多方支付功能，跳转至步骤S507；若已开通多方支付功能，跳转至步骤S508。

在步骤S507中，第二SDK调起用户终端中开通多方支付功能的另一支付应用程序，以利用另一支付应用程序进行支付。

在步骤S508中，第二SDK判断用户是否登录第一目标支付应用程序，若用户未登录，跳转至步骤S509；若用户已登录，跳转至步骤 S511。

在步骤S509中，第二SDK回调至支付前置协议及监听，通知第一目标支付应用程序。

在步骤S510中，第一目标支付应用程序跳转至登录流程，若登录流程中登录成功，跳转至步骤S511；若登录流程中登录失败，跳转至步骤S515。

在步骤S511中，第二SDK进行支付验证。

在步骤S512中，第二SDK检测是否出现支付取消动作，若出现支付取消动作，跳转至步骤S513；若未出现支付取消动作，跳转至步骤S515。

在步骤S513中，第二SDK与远程支付平台交互，以获取并展示支付选择页面。

在步骤S514中，响应于用户的选择输入，第二SDK调起用户终端中另一支付应用程序，以利用另一支付应用程序进行支付。

在步骤S515中，第二SDK与远程支付平台交互以进行支付。

在步骤S516中，远程支付平台向第二SDK发送支付结果信息。

在步骤S517中，第二SDK通过第一SDK向电子商务应用程序发送支付结果信息。

上述步骤S501至步骤S517的具体内容可参见上述实施例中的相关说明，在此不再赘述。

本申请第三方面提供一种用户终端，该用户终端具体可为上述实施例中的用户终端。用户终端具有电子商务应用程序、集成在电子商务应用程序的第一SDK、支付应用程序以及与集成在支付应用程序的第二SDK。电子商务应用程序属于第一主体，支付应用程序属于第二主体，第一SDK和第二SDK属于第三主体。图12为本申请第三方面一实施例提供的用户终端的结构示意图。如图12所示，该用户终端600可包括通信模块601和处理模块602。

通信模块601可用于用于在电子商务应用程序触发多方支付入口的情况下，被第一SDK调用向远程支付平台发送列表请求消息，列表请求消息包括列表要求信息，列表要求信息包括电子商务应用标识和用户标识；以及，用于被第一SDK调用从远程支付平台获取第一支付应用列表，第一支付应用列表表征远程支付平台支持的多个优先级由高至低排列的支付应用程序，优先级由远程支付平台基于列表要求信息对应的关联数据得到。

在一些示例中，列表要求信息还包括以下一项或多项：用户终端操作系统版本、第一SDK的版本、第二SDK的版本。

处理模块602可用于被第一SDK调用获取第二支付应用列表，第二支付应用列表表征用户终端具有的支付应用程序；以及，用于调用第一SDK调起第一目标支付应用程序，第一目标支付应用程序为第一支付应用列表与第二支付应用列表的交集中优先级最高的支付应用程序。

通信模块601还可用于被第一目标支付应用程序的第二SDK调用与远程支付平台交互，完成支付。

而且，多方支付功能使得多个支付应用程序接入同一远程支付平台，实现了多支付应用程序支付的线上平台共享，对远程控件支付流程进行了优化，缩短了用户支付的操作路径，提高了用户体验。

在一些实施例中，上述处理模块602可用于被第二SDK调用查询本地存储的多方支付功能开通标识位，确定用户终端中的第一目标支付应用程序是否开通多方支付功能。

通信模块601可用于在用户终端中的第一目标支付应用程序开通多方支付功能的情况下，被第二SDK调用与远程支付平台交互，完成支付。

在一些实施例中，处理模块602可用于在用户终端中的第一目标支付应用程序开通多方支付功能的情况下，被第二SDK调用确定用户是否在第一目标支付应用程序登录。

通信模块601可用于在用户在第一目标支付应用程序已登录的情况下，被第二SDK调用与远程支付平台交互，完成支付。

在一些实施例中，通信模块601还可用于被第一目标支付应用程序的第二SDK调用与远程支付平台交互，完成第二SDK的初始化。

在一些实施例中，通信模块601还可用于在用户终端中的第一目标支付应用程序未开通多方支付功能，或，用户在第一目标支付应用程序未登录的情况下，第一目标支付应用程序的第二SDK调起第二目标支付应用程序，被第二目标支付应用程序的第二SDK调用与远程支付平台交互，完成支付。

在一些实施例中，用户终端还可包括显示模块。

通信模块601还可用于在用户终端中的第一目标支付应用程序未开通多方支付功能，或，用户在第一目标支付应用程序未登录的情况下，被第一目标支付应用程序的第二SDK调用与远程支付平台交互，获取支付选择页面。

显示模块可用于展示支付选择页面。

处理模块602还可用于响应于用户的第一选择输入，在支付选择页面中确定第三目标支付应用程序。

通信模块601还可用于在通过第一目标支付应用程序的第二SDK调起第三目标支付应用程序的情况下，被第三目标支付应用程序的第二SDK调用与远程支付平台交互，完成支付；

在一些实施例中，用户终端还可包括显示模块。

显示模块用于在第一目标支付应用程序未开通多方支付功能，或，用户在第一目标支付应用程序未登录的情况下，展示第一引导信息和/或第二引导信息。

第一引导信息用于引导用户为第一目标支付应用程序开通多方支付功能。第二引导信息用于引导用户登录第一目标支付应用程序。

通信模块601还可用于在第一目标支付应用程序开通多方支付功能且用户在第一目标支付应用程序已登录的情况下，被第一目标支付应用程序的第二SDK调用与远程支付平台交互，完成支付。

在一些实施例中，用户终端还可包括显示模块。

处理模块602还可用于调用第二SDK通过支付前置协议接口或监听接口监听是否出现支付取消动作。

通信模块601还可用于在出现支付取消动作的情况下，被第二SDK调用与远程支付平台交互，获取支付选择页面。

显示模块可用于展示支付选择页面。

处理模块602还可用于响应于用户的第二选择输入，在支付选择页面中确定第四目标支付应用程序。

通信模块601还可用于在通过第一目标支付应用程序的第二SDK调起第四目标支付应用程序的情况下，被第四目标支付应用程序的第二SDK调用与远程支付平台交互，完成支付。

在一些实施例中，处理模块602可用于被第一SDK调用向第一目标支付应用程序发送调起信息；控制第一目标支付应用程序响应于调起信息启动，并直接跳转至调起信息指示的页面。

本申请第四方面提供一种基于智能路由的远程支付装置，可应用于远程支付平台，远程支付平台的具体内容可参见上述实施例中的相关说明，在此不再赘述。图13为本申请第四方面一实施例提供的基于智能路由的远程支付装置的结构示意图。如图13所示，基于智能路由的远程支付装置700可包括通信模块701和处理模块702。

通信模块701可用于在用户终端的电子商务应用程序触发多方支付入口的情况下，接收用户终端调用第一SDK发送的列表请求消息。

列表请求消息包括列表要求信息，列表要求信息包括电子商务应用标识和用户标识。

用户终端具有电子商务应用程序、集成在电子商务应用程序的第一SDK、支付应用程序以及与集成在支付应用程序的第二SDK。电子商务应用程序属于第一主体，支付应用程序属于第二主体，第一SDK和第二SDK属于第三主体。

处理模块702可用于根据列表请求消息，获取列表要求信息对应的关联数据，并基于关联数据，得到远程支付平台支持的支付应用程序的优先级；以及，用于根据远程支付平台支持的支付应用程序的优先级，生成第一支付应用列表。

通信模块701还可用于向用户终端发送第一支付应用列表，以及，用于与用户终端的第一目标支付应用程序的第二SDK交互，完成支付。

在一些实施例中，通信模块701可用于在第二SDK确定用户终端中的第一目标支付应用程序开通多方支付功能的情况下，与第一目标支付应用程序的第二SDK交互，完成支付。

在一些实施例中，在用户在第一目标支付应用程序已登录的情况下，与第一目标支付应用程序的第二SDK交互，完成支付。

在一些实施例中，通信模块701还可用于与第一目标支付应用程序的第二SDK交互，完成第二SDK的初始化。

在一些实施例中，通信模块701还可用于在用户终端中的第一目标支付应用程序未开通多方支付功能，或，用户在第一目标支付应用程序未登录的情况下，与用户终端中第二目标支付应用程序的第二SDK交互，完成支付。

在一些实施例中，通信模块701还可用于在用户终端中的第一目标支付应用程序未开通多方支付功能，或，用户在第一目标支付应用程序未登录的情况下，与用户终端中第一目标支付应用程序的第二SDK交互，提供支付选择页面；以及，用于与用户终端中第三目标支付应用程序的第二SDK交互，完成支付。

支付选择页面包括开通多方支付功能的支付应用程序的标识。第三目标支付应用程序包括用户终端响应于用户的第一选择输入，在支付选择页面中确定的支付应用程序。

在一些实施例中，通信模块701还可用于在第一目标支付应用程序未开通多方支付功能，或，用户在第一目标支付应用程序未登录的情况下，与用户终端中第一目标支付应用程序的第二SDK交互，为用户终端中第一目标支付应用程序开通多方支付功能；以及，用于在第一目标支付应用程序开通多方支付功能且用户在第一目标支付应用程序已登录的情况下，与用户终端中第一目标支付应用程序的第二SDK交互，完成支付。

在一些实施例中，通信模块701还可用于在用户终端监听到支付取消动作的情况下，与用户终端中第一目标支付应用程序的第二SDK交互，提供支付选择页面；以及，用于与用户终端中第四目标支付应用程序的第二SDK交互，完成支付。

支付选择页面包括开通多方支付功能的支付应用程序的标识。第四目标支付应用程序包括用户终端响应于用户的第二选择输入在支付选择页面中确定的支付应用程序。

本申请第五方面还提供了一种用户终端。图14为本申请第五方面一实施例提供的用户终端的结构示意图。如图14所示，用户终端800包括存储器801、处理器802及存储在存储器801上并可在处理器802上运行的计算机程序。

在一个示例中，上述处理器802可以包括中央处理器(CPU)，或者特定集成电路(Application Specific Integrated Circuit，ASIC)，或者可以被配置成实施本申请实施例的一个或多个集成电路。

存储器801可包括只读存储器(Read-Only Memory，ROM)，随机存取存储器(Random Access Memory，RAM)，磁盘存储介质设备，光存储介质设备，闪存设备，电气、光学或其他物理/有形的存储器存储设备。因此，通常，存储器包括一个或多个编码有包括计算机可执行指令的软件的有形(非暂态)计算机可读存储介质(例如，存储器设备)，并且当该软件被执行(例如，由一个或多个处理器)时，其可操作来执行参考根据本申请第一方面实施例中基于智能路由的远程支付方法所描述的操作。

处理器802通过读取存储器801中存储的可执行程序代码来运行与可执行程序代码对应的计算机程序，以用于实现上述第一方面实施例中的基于智能路由的远程支付方法。

在一些示例中，用户终端800还可包括通信接口803和总线804。其中，如图14所示，存储器801、处理器802、通信接口803通过总线804连接并完成相互间的通信。

通信接口803，主要用于实现本申请实施例中各模块、装置、单元和/或设备之间的通信。也可通过通信接口803接入输入设备和/或输出设备。

总线804包括硬件、软件或两者，将用户终端800的部件彼此耦接在一起。举例来说而非限制，总线804可包括加速图形端口(Accelerated Graphics Port，AGP)或其他图形总线、增强工业标准架构(Enhanced Industry Standard Architecture，EISA)总线、前端总线(Front Side Bus，FSB)、超传输(Hyper Transport，HT)互连、工业标准架构(Industry Standard Architecture，ISA)总线、无限带宽互连、低引脚数(Low pin count，LPC)总线、存储器总线、微信道架构(Micro Channel Architecture，MCA)总线、外围组件互连(Peripheral Component Interconnect，PCI)总线、PCI-Express(PCI-E)总线、串行高级技术附件(Serial Advanced Technology Attachment，SATA)总线、视频电子标准协会局部(Video Electronics Standards Association Local Bus，VLB)总线或其他合适的总线或者两个或更多个以上这些的组合。在合适的情况下，总线804可包括一个或多个总线。尽管本申请实施例描述和示出了特定的总线，但本申请考虑任何合适的总线或互连。

本申请第六方面还提供了一种电子设备。该电子设备可包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序。

存储器包括一个或多个编码有包括计算机可执行指令的软件的有形(非暂态)计算机可读存储介质(例如，存储器设备)，并且当该软件被执行(例如，由一个或多个处理器)时，其可操作来执行参考根据本申请第二方面实施例中基于智能路由的远程支付方法所描述的操作。

处理器通过读取存储器中存储的可执行程序代码来运行与可执行程序代码对应的计算机程序，以用于实现上述第二方面实施例中的基于智能路由的远程支付方法。

在一些示例中，电子设备还可包括通信接口和总线。存储器、处理器、通信接口可通过总线连接并完成相互间的通信。

存储器、处理器、通信接口和总线的连接关系和具体实现可参见上述实施例中用户终端中存储器801、处理器802、通信接口803和总线804的连接关系和具体实现，在此不再赘述。

本申请第七方面还提供一种远程支付系统。该远程支付系统可包括上述实施例中的用户终端和远程支付平台。

用户终端具有电子商务应用程序、集成在电子商务应用程序的第一SDK、支付应用程序以及与集成在支付应用程序的第二SDK。电子商务应用程序属于第一主体，支付应用程序属于第二主体，第一SDK和第二SDK属于第三主体。用户终端用于执行第一方面实施例中的基于智能路由的远程支付方法。

远程支付平台可用于执行第二方面实施例中的基于智能路由的远程支付方法。

用户终端、远程支付平台、基于智能路由的远程支付方法的具体内容可参见上述实施例中的相关说明，在此不再赘述。

本申请第八方面还提供一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序指令，该计算机程序指令被处理器执行时可实现上述第一方面实施例中的基于智能路由的远程支付方法或第二方面实施例中的基于智能路由的远程支付方法，且能达到相同的技术效果，为避免重复，这里不再赘述。其中，上述计算机可读存储介质可包括非暂态计算机可读存储介质，如只读存储器(Read-Only Memory，简称ROM)、随机存取存储器(Random Access Memory，简称RAM)、磁碟或者光盘等，在此并不限定。

本申请实施例还可提供一种计算机程序产品。该计算机程序产品中的指令由电子设备的处理器执行时，使得所述电子设备执行上述第一方面实施例中的基于智能路由的远程支付方法或第二方面实施例中的基于智能路由的远程支付方法，且能达到相同的技术效果，为避免重复，这里不再赘述。

需要明确的是，本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同或相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。对于用户终端实施例、装置实施例、设备实施例、系统实施例、计算机可读存储介质实施例和计算机程序产品实施例而言，相关之处可以参见方法实施例的说明部分。本申请并不局限于上文所描述并在图中示出的特定步骤和结构。本领域的技术人员可以在领会本申请的精神之后，做出各种改变、修改和添加，或者改变步骤之间的顺序。并且，为了简明起见，这里省略对已知方法技术的详细描述。

上面参考根据本申请的实施例的方法、装置(系统)和计算机程序产品的流程图和/或框图描述了本申请的各方面。应当理解，流程图和/或框图中的每个方框以及流程图和/或框图中各方框的组合可以由计算机程序指令实现。这些计算机程序指令可被提供给通用计算机、专用计算机、或其它可编程数据处理装置的处理器，以产生一种机器，使得经由计算机或其它可编程数据处理装置的处理器执行的这些指令使能对流程图和/或框图的一个或多个方框中指定的功能/动作的实现。这种处理器可以是但不限于是通用处理器、专用处理器、特殊应用处理器或者现场可编程逻辑电路。还可理解，框图和/或流程图中的每个方框以及框图和/或流程图中的方框的组合，也可以由执行指定的功能或动作的专用硬件来实现，或可由专用硬件和计算机指令的组合来实现。

本领域技术人员应能理解，上述实施例均是示例性而非限制性的。在不同实施例中出现的不同技术特征可以进行组合，以取得有益效果。本领域技术人员在研究附图、说明书及权利要求书的基础上，应能理解并实现所揭示的实施例的其他变化的实施例。在权利要求书中，术语“包括”并不排除其他装置或步骤；数量词“一个”不排除多个；术语“第一”、“第二”用于标示名称而非用于表示任何特定的顺序。权利要求中的任何附图标记均不应被理解为对保护范围的限制。权利要求中出现的多个部分的功能可以由一个单独的硬件或软件模块来实现。某些技术特征出现在不同的从属权利要求中并不意味着不能将这些技术特征进行组合以取得有益效果。

Claims

一种基于智能路由的远程支付方法，应用于用户终端，所述用户终端具有电子商务应用程序、集成在所述电子商务应用程序的第一软件开发工具包SDK、支付应用程序以及与集成在支付应用程序的第二SDK，所述电子商务应用程序属于第一主体，所述支付应用程序属于第二主体，所述第一SDK和所述第二SDK属于第三主体，所述方法包括：

在所述电子商务应用程序触发多方支付入口的情况下，调用所述第一SDK向远程支付平台发送列表请求消息，所述列表请求消息包括列表要求信息，所述列表要求信息包括电子商务应用标识和用户标识；

调用所述第一SDK从远程支付平台获取第一支付应用列表，所述第一支付应用列表表征所述远程支付平台支持的多个优先级由高至低排列的支付应用程序，优先级由所述远程支付平台基于所述列表要求信息对应的关联数据得到；

调用所述第一SDK获取第二支付应用列表，所述第二支付应用列表表征所述用户终端具有的支付应用程序；

由所述第一SDK调起第一目标支付应用程序，所述第一目标支付应用程序为所述第一支付应用列表与所述第二支付应用列表的交集中优先级最高的支付应用程序；

通过所述第一目标支付应用程序调用所述第二SDK与所述远程支付平台交互，完成支付。
根据权利要求1所述的方法，其中，所述列表要求信息还包括以下一项或多项：

用户终端操作系统版本、第一SDK的版本、第二SDK的版本。
根据权利要求1所述的方法，其中，所述关联数据包括以下一项或多项：

支付应用程序支付频率、支付应用程序支付成功率、支付应用程序支付资源量、支付应用程序支付时间、用户在支付应用程序的支付信用度、所述第一主体指定的支付应用程序的调起顺序、所述第三主体指定的支付应用程序的调起顺序。
根据权利要求1所述的方法，其中，所述通过所述第一目标支付应用程序调用所述第二SDK与所述远程支付平台交互，完成支付，包括：

由所述第二SDK查询本地存储的多方支付功能开通标识位，确定所述用户终端中的所述第一目标支付应用程序是否开通多方支付功能；

在所述用户终端中的所述第一目标支付应用程序开通多方支付功能的情况下，由所述第二SDK与所述远程支付平台交互，完成支付。
根据权利要求4所述的方法，其中，在所述由所述第二SDK查询本地存储的多方支付功能开通标识位，确定所述第一目标支付应用程序是否开通多方支付功能之前，还包括：

通过所述第一目标支付应用程序调用所述第二SDK与所述远程支付平台交互，完成所述第二SDK的初始化。
根据权利要求4所述的方法，其中，所述在所述第一目标支付应用程序开通多方支付功能的情况下，由所述第二SDK与所述远程支付平台交互，完成支付，包括：

在所述用户终端中的所述第一目标支付应用程序开通多方支付功能的情况下，由所述第二SDK确定用户是否在所述第一目标支付应用程序登录；

在用户在所述第一目标支付应用程序已登录的情况下，由所述第二SDK与所述远程支付平台交互，完成支付。
根据权利要求4或6所述的方法，还包括：

在所述用户终端中的所述第一目标支付应用程序未开通多方支付功能，或，用户在所述第一目标支付应用程序未登录的情况下，通过所述第一目标支付应用程序的所述第二SDK调起第二目标支付应用程序，由所述第二目标支付应用程序的所述第二SDK与所述远程支付平台交互，完成支付，所述第二目标支付应用程序为指定的支付应用程序或所述第一支付应用列表与所述第二支付应用列表的交集中优先级次高的支付应用程序；

或者，

在所述用户终端中的所述第一目标支付应用程序未开通多方支付功能，或，用户在所述第一目标支付应用程序未登录的情况下，通过所述第一目标支付应用程序的所述第二SDK与所述远程支付平台交互，以展示支付选择页面，所述支付选择页面包括开通多方支付功能的支付应用程序的标识；响应于用户的第一选择输入，在所述支付选择页面中确定第三目标支付应用程序；通过所述第一目标支付应用程序的所述第二SDK调起第三目标支付应用程序，由所述第三目标支付应用程序的所述第二SDK与所述远程支付平台交互，完成支付；

或者，

在所述第一目标支付应用程序未开通多方支付功能，或，用户在所述第一目标支付应用程序未登录的情况下，展示第一引导信息和/或第二引导信息，所述第一引导信息用于引导用户为所述第一目标支付应用程序开通多方支付功能，所述第二引导信息用于引导用户登录所述第一目标支付应用程序；在所述第一目标支付应用程序开通多方支付功能且用户在所述第一目标支付应用程序已登录的情况下，由所述第一目标支付应用程序的所述第二SDK与所述远程支付平台交互，完成支付。
根据权利要求1所述的方法，还包括：

调用所述第二SDK通过支付前置协议接口或监听接口监听是否出现支付取消动作；

在出现支付取消动作的情况下，调用所述第二SDK与所述远程支付平台交互，以展示支付选择页面，所述支付选择页面包括开通多方支付功能的支付应用程序的标识；

响应于用户的第二选择输入，在所述支付选择页面中确定第四目标支付应用程序；

通过所述第一目标支付应用程序的所述第二SDK调起第四目标支付应用程序，并由所述第四目标支付应用程序的所述第二SDK与所述远程支付平台交互，完成支付。
根据权利要求1所述的方法，其中，所述由所述第一SDK调起第一目标支付应用程序，包括：

由第一SDK向所述第一目标支付应用程序发送调起信息；

由所述第一目标支付应用程序响应于调起信息启动，并直接跳转至调起信息指示的页面。
一种基于智能路由的远程支付方法，应用于远程支付平台，所述方法包括：

在用户终端的电子商务应用程序触发多方支付入口的情况下，接收所述用户终端调用第一软件开发工具包SDK发送的列表请求消息，所述列表请求消息包括列表要求信息，所述列表要求信息包括电子商务应用标识和用户标识，所述用户终端具有所述电子商务应用程序、集成在所述电子商务应用程序的所述第一SDK、支付应用程序以及与集成在支付应用程序的第二SDK，所述电子商务应用程序属于第一主体，所述支付应用程序属于第二主体，所述第一SDK和所述第二SDK属于第三主体；

根据所述列表请求消息，获取所述列表要求信息对应的关联数据，并基于所述关联数据，得到所述远程支付平台支持的支付应用程序的优先级；

根据所述远程支付平台支持的支付应用程序的优先级，生成第一支付应用列表，并向所述用户终端发送，所述第一支付应用列表表征所述远程支付平台支持的多个优先级由高至低排列的支付应用程序；

与所述用户终端的第一目标支付应用程序的所述第二SDK交互，完成支付，所述第一目标支付应用程序为所述第一支付应用列表与第二支付应用列表的交集中优先级最高的支付应用程序，所述第二支付应用列表表征所述用户终端具有的支付应用程序。
根据权利要求10所述的方法，其中，所述列表要求信息还包括以下一项或多项：

用户终端操作系统版本、第一SDK的版本、第二SDK的版本。
根据权利要求10所述的方法，其中，所述关联数据包括以下一项或多项：

支付应用程序支付频率、支付应用程序支付成功率、支付应用程序支付资源量、支付应用程序支付时间、用户在支付应用程序的支付信用度、所述第一主体指定的支付应用程序的调起顺序、所述第三主体指定的支付应用程序的调起顺序。
根据权利要求10所述的方法，其中，所述与所述用户终端的第一目标支付应用程序的所述第二SDK交互，完成支付，包括：

在所述第二SDK确定所述用户终端中的所述第一目标支付应用程序开通多方支付功能的情况下，与所述第一目标支付应用程序的所述第二SDK交互，完成支付。
根据权利要求13所述的方法，其中，在所述与所述第一目标支付应用程序的所述第二SDK交互，完成支付之前，还包括：

与所述第一目标支付应用程序的所述第二SDK交互，完成所述第二SDK的初始化。
根据权利要求13所述的方法，其中，所述与所述第一目标支付应用程序的所述第二SDK交互，完成支付，包括：

在用户在所述第一目标支付应用程序已登录的情况下，与所述第一目标支付应用程序的所述第二SDK交互，完成支付。
根据权利要求13或15所述的方法，还包括：

在所述用户终端中的所述第一目标支付应用程序未开通多方支付功能，或，用户在所述第一目标支付应用程序未登录的情况下，与所述用户终端中第二目标支付应用程序的所述第二SDK交互，完成支付，所述第二目标支付应用程序为指定的支付应用程序或所述第一支付应用列表与所述第二支付应用列表的交集中优先级次高的支付应用程序；

或者，

在所述用户终端中的所述第一目标支付应用程序未开通多方支付功能，或，用户在所述第一目标支付应用程序未登录的情况下，与所述用户终端中所述第一目标支付应用程序的所述第二SDK交互，提供支付选择页面，所述支付选择页面包括开通多方支付功能的支付应用程序的标识；与所述用户终端中第三目标支付应用程序的所述第二SDK交互，完成支付，所述第三目标支付应用程序包括所述用户终端响应于用户的第一选择输入，在所述支付选择页面中确定的支付应用程序；

或者，

在所述第一目标支付应用程序未开通多方支付功能，或，用户在所述第一目标支付应用程序未登录的情况下，与所述用户终端中所述第一目标支付应用程序的所述第二SDK交互，为所述用户终端中所述第一目标支付应用程序开通多方支付功能；在所述第一目标支付应用程序开通多方支付功能且用户在所述第一目标支付应用程序已登录的情况下，与所述用户终端中所述第一目标支付应用程序的所述第二SDK交互，完成支付。
根据权利要求13或15所述的方法，还包括：

在所述用户终端监听到支付取消动作的情况下，与所述用户终端中所述第一目标支付应用程序的所述第二SDK交互，提供支付选择页面，所述支付选择页面包括开通多方支付功能的支付应用程序的标识；

与所述用户终端中所述第四目标支付应用程序的所述第二SDK交互，完成支付，所述第四目标支付应用程序包括所述用户终端响应于用户的第二选择输入在所述支付选择页面中确定的支付应用程序。
一种用户终端，所述用户终端具有电子商务应用程序、集成在所述电子商务应用程序的第一软件开发工具包SDK、支付应用程序以及与集成在支付应用程序的第二SDK，所述电子商务应用程序属于第一主体，所述支付应用程序属于第二主体，所述第一SDK和所述第二SDK属于第三主体，所述用户终端包括：

通信模块，用于在所述电子商务应用程序触发多方支付入口的情况下，被所述第一SDK调用向远程支付平台发送列表请求消息，所述列表请求消息包括列表要求信息，所述列表要求信息包括电子商务应用标识和用户标识；以及，用于被所述第一SDK调用从远程支付平台获取第一支付应用列表，所述第一支付应用列表表征所述远程支付平台支持的多个优先级由高至低排列的支付应用程序，优先级由所述远程支付平台基于所述列表要求信息对应的关联数据得到；

处理模块，用于被所述第一SDK调用获取第二支付应用列表，所述第二支付应用列表表征所述用户终端具有的支付应用程序；以及，用于调用所述第一SDK调起第一目标支付应用程序，所述第一目标支付应用程序为所述第一支付应用列表与所述第二支付应用列表的交集中优先级最高的支付应用程序；

所述通信模块还用于被所述第一目标支付应用程序的所述第二SDK调用与所述远程支付平台交互，完成支付。
一种基于智能路由的远程支付装置，应用于远程支付平台，所述基于智能路由的远程支付装置包括：

通信模块，用于在用户终端的电子商务应用程序触发多方支付入口的情况下，接收所述用户终端调用第一软件开发工具包SDK发送的列表请求消息，所述列表请求消息包括列表要求信息，所述列表要求信息包括电子商务应用标识和用户标识，所述用户终端具有所述电子商务应用程序、集成在所述电子商务应用程序的所述第一SDK、支付应用程序以及与集成在支付应用程序的第二SDK，所述电子商务应用程序属于第一主体，所述支付应用程序属于第二主体，所述第一SDK和所述第二SDK属于第三主体；

处理模块，用于根据所述列表请求消息，获取所述列表要求信息对应的关联数据，并基于所述关联数据，得到所述远程支付平台支持的支付应用程序的优先级；以及，用于根据所述远程支付平台支持的支付应用程序的优先级，生成第一支付应用列表，所述第一支付应用列表表征所述远程支付平台支持的多个优先级由高至低排列的支付应用程序；

所述通信模块还用于向所述用户终端发送所述第一支付应用列表，以及，用于与所述用户终端的第一目标支付应用程序的所述第二SDK交互，完成支付，所述第一目标支付应用程序为所述第一支付应用列表与第二支付应用列表的交集中优先级最高的支付应用程序，所述第二支付应用列表表征所述用户终端具有的支付应用程序。
一种用户终端，包括：处理器以及存储有计算机程序指令的存储器；

所述处理器执行所述计算机程序指令时实现如权利要求1至9中任意一项所述的基于智能路由的远程支付方法。
一种电子设备，应用于远程支付平台，所述电子设备包括：处理器以及存储有计算机程序指令的存储器；

所述处理器执行所述计算机程序指令时实现如权利要求10至17中任意一项所述的基于智能路由的远程支付方法。
一种远程支付系统，包括：

用户终端，所述用户终端具有电子商务应用程序、集成在所述电子商务应用程序的第一软件开发工具包SDK、支付应用程序以及与集成在支付应用程序的第二SDK，所述电子商务应用程序属于第一主体，所述支付应用程序属于第二主体，所述第一SDK和所述第二SDK属于第三主体，所述用户终端用于执行如权利要求1至9中任意一项所述的基于智能路由的远程支付方法；

远程支付平台，用于执行如权利要求10至17中任意一项所述的基于智能路由的远程支付方法。
一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序指令，所述计算机程序指令被处理器执行时实现如权利要求1至17中任意一项所述的基于智能路由的远程支付方法。