支付方法、装置、设备及存储介质与流程

1.本技术属于支付技术领域，尤其涉及一种支付方法、装置、设备及存储介质。


背景技术：

2.随着科技技术的发展，支付行业加速互联网化，用户进行账单支付的方式也越来越多，例如，用户可以通过具有支付功能的应用程序进行移动支付。
3.在相关技术中，为了给用户提供更为便捷的服务，这些具有支付功能的应用程序中往往会嵌入一些商户小程序，用户可以在这些商户小程序中下单，并在该商户小程序中请求支付订单，然而，用户仅可以通过该应用程序所属方提供的支付控件支付商户小程序中的订单，无法通过其他方式支付，如此，使得支付方式较为单一，影响支付效率。


技术实现要素：

4.本技术实施例提供一种支付方法、装置、设备及存储介质，能够解决相关技术中支付方式单一、且支付效率低的问题。
5.第一方面，本技术实施例提供一种支付方法，应用于主体应用程序服务端，该方法可以包括：
6.接收主体应用程序中商户小程序的支付订单；
7.根据支付订单，向与支付小程序对应的资源支付服务端发送查询请求，其中，查询请求用于请求资源支付服务端确定主体应用程序的应用账户与支付小程序的支付账户是否建立授权关系，支付小程序为嵌入主体应用程序中的具有支付功能的应用程序；
8.接收资源支付服务端发送的查询反馈结果；
9.在查询反馈结果表征应用账户和支付账户已建立授权关系的情况下，向资源支付服务端发送第一支付指令，第一支付指令用于指示支付小程序对支付订单进行处理。
10.第二方面，本技术实施例提供一种支付方法，应用于资源支付服务端，该方法可以包括：
11.接收主体应用程序服务端发送的查询请求；
12.根据查询请求，确定应用账户与支付账户是否建立授权关系的查询反馈结果，应用账户为与主体应用程序服务端对应的主体应用程序的账户，支付账户为资源支付服务端对应的支付小程序的账户，支付小程序为嵌入主体应用程序中的具有支付功能的应用程序；
13.向主体应用程序服务端发送查询反馈结果；
14.在接收到主体应用程序发送的第一支付指令的情况下，通过支付小程序的支付账户对支付订单进行处理。
15.第三方面，本技术实施例提供一种支付方法，应用于电子设备，该支付方法还可以包括：
16.显示主体应用程序中商户小程序的第一界面；
17.在接收到对第一界面的第一输入的情况下，从第一界面切换显示为第二界面，其中，第一输入为确认在商户小程序中提交支付订单的输入，第二界面为支付小程序对支付订单进行处理的界面，支付小程序为嵌入主体应用程序中的具有支付功能的应用程序；
18.在确定主体应用程序的应用账户与支付小程序的支付账户已建立授权关系的情况下，显示支付小程序对支付订单处理后的支付结果。
19.第四方面，本技术实施例提供一种支付方法，应用于电子设备，该支付方法还可以包括：
20.显示主体应用程序的第三界面，第三界面包括n个支付方，n为大于1的整数；
21.在接收到用户对n个支付方中目标支付方的第三输入的情况下，从第三界面切换显示为第四界面，第四界面为目标支付方对应的支付小程序的支付界面，支付小程序为嵌入主体应用程序中的具有支付功能的应用程序，支付界面包括支付小程序提供的付款码；
22.在确定主体应用程序的应用账户与支付小程序的支付账户已建立授权关系的情况下，显示第五界面，第五界面包括支付小程序对支付订单处理后的支付结果；支付小程序的所属方与主体应用程序的所属方不同。
23.第五方面，本技术实施例提供一种支付装置，应用于主体应用程序服务端，该装置可以包括：
24.接收模块，用于接收主体应用程序中商户小程序的支付订单；
25.发送模块，用于根据支付订单，向与支付小程序对应的资源支付服务端发送查询请求，其中，查询请求用于请求资源支付服务端确定主体应用程序的应用账户与支付小程序的支付账户是否建立授权关系，支付小程序为嵌入主体应用程序中的具有支付功能的应用程序；
26.接收模块还用于，接收资源支付服务端发送的查询反馈结果；
27.发送模块还用于，在查询反馈结果表征应用账户和支付账户已建立授权关系的情况下，向资源支付服务端发送第一支付指令，第一支付指令用于指示支付小程序对支付订单进行处理。
28.第六方面，本技术实施例提供一种支付装置，应用于资源支付服务端，该装置可以包括：
29.接收模块，用于接收主体应用程序服务端发送的查询请求；
30.确定模块，用于根据查询请求，确定应用账户与支付账户是否建立授权关系的查询反馈结果，应用账户为与主体应用程序服务端对应的主体应用程序的账户，支付账户为资源支付服务端对应的支付小程序的账户，支付小程序为嵌入主体应用程序中的具有支付功能的应用程序；
31.发送模块，用于向主体应用程序服务端发送查询反馈结果；
32.处理模块，用于在接收到主体应用程序发送的第一支付指令的情况下，通过支付小程序的支付账户对支付订单进行处理。
33.第七方面，本技术实施例提供了一种支付装置，应用于电子设备，该装置可以包括：
34.显示模块，用于显示主体应用程序中商户小程序的第一界面，第一显示模块，用于显示主体应用程序中商户小程序的第一界面；
35.显示模块还用于，在接收到对第一界面的第一输入的情况下，从第一界面切换显示为第二界面，其中，第一输入为确认在商户小程序中提交支付订单的输入，第二界面为支付小程序对支付订单进行处理的界面，支付小程序为嵌入主体应用程序中的具有支付功能的应用程序；
36.显示模块还用于，在确定主体应用程序的应用账户与支付小程序的支付账户已建立授权关系的情况下，显示支付小程序对支付订单处理后的支付结果。
37.第八方面，本技术实施例提供了一种支付装置，应用于电子设备，该装置可以包括：
38.显示模块，用于显示主体应用程序的第三界面，第三界面包括n个支付方，n为大于1的整数；
39.显示模块还用于，在接收到用户对n个支付方中目标支付方的第三输入的情况下，从第三界面切换显示为第四界面，第四界面为目标支付方对应的支付小程序的支付界面，支付小程序为嵌入主体应用程序中的具有支付功能的应用程序，支付界面包括支付小程序提供的付款码；
40.显示模块还用于，在确定主体应用程序的应用账户与支付小程序的支付账户已建立授权关系的情况下，显示第五界面，第五界面包括支付小程序对支付订单处理后的支付结果；支付小程序的所属方与主体应用程序的所属方不同。
41.第九方面，本技术实施例提供了一种计算设备，该计算设备包括：处理器以及存储有计算机程序指令的存储器；
42.处理器执行计算机程序指令时实现如第一方面所示的支付方法、如第二方面所示的支付方法、如第三方面所示的支付方法、或者如第四方面所示的支付方法。
43.第十方面，本技术实施例提供了一种计算机存储介质，计算机存储介质上存储有计算机程序指令，计算机程序指令被处理器执行时实现如第一方面所示的支付方法、如第二方面所示的支付方法、如第三方面所示的支付方法、或者如第四方面所示的支付方法。
44.第十一方面，本技术实施例提供了一种芯片，芯片包括处理器和通信接口，通信接口和处理器耦合，处理器用于运行程序或指令，实现如第一方面所示的支付方法、如第二方面所示的支付方法、如第三方面所示的支付方法、或者如第四方面所示的支付方法。
45.第十二方面，本技术实施例提供一种计算机程序产品，该程序产品被存储在存储介质中，该程序产品被至少一个处理器执行以实现如第一方面所示的支付方法、如第二方面所示的支付方法、如第三方面所示的支付方法、或者如第四方面所示的支付方法。
46.本技术实施例的支付方法、装置、设备及存储介质，主体应用程序服务端可以根据主体应用程序中商户小程序的支付订单，向与支付小程序对应的资源支付服务端发送查询请求，查询请求用于请求资源支付服务端确定主体应用程序的应用账户与支付小程序的支付账户是否建立授权关系，支付小程序为嵌入主体应用程序中的具有支付功能的应用程序；接着，在接收到资源支付服务端发送的表征应用账户和支付账户已建立授权关系的查询反馈结果时，可以向资源支付服务端发送第一支付指令，第一支付指令用于指示支付小程序对支付订单进行处理，由此，该支付方式可以通过除主体应用程序所属方提供的支付控件之外的支付方式，支付商户小程序中的订单，增加付款途径，提高支付效率，并且，在主体应用程序中的支付小程序支付商户小程序的订单，无需跳转到主体应用程序外的页面如
html5页面，也无需跳转到第三方支付应用以完成支付，减少了用户触发启动第三方应用程序以及返回主体应用程序的操作，提高了用户支付的便捷性。
附图说明
47.为了更清楚地说明本技术实施例的技术方案，下面将对本技术实施例中所需要使用的附图作简单的介绍，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
48.图1是根据本技术提供的支付方法的一个实施例的支付架构示意图；
49.图2为本技术实施例提供的一种支付方法的流程交互图之一；
50.图3为本技术实施例提供的一种支付方法的流程交互图之二；
51.图4为本技术实施例提供的一种基于主体应用程序服务端的支付方法的流程图；
52.图5为本技术实施例提供的一种基于资源支付服务端的支付方法的流程图；
53.图6为本技术实施例提供的一种支付方法的交互流程示意图之一；
54.图7为本技术实施例提供的一种支付方法的交互流程示意图之二；
55.图8为本技术实施例提供的一种基于电子设备的支付方法的流程图；
56.图9为本技术实施例提供的一种基于电子设备的支付方法的界面图之一；
57.图10为本技术实施例提供的一种基于电子设备的支付方法的流程图；
58.图11为本技术实施例提供的一种基于电子设备的支付方法的界面图之二；
59.图12是本技术一个实施例提供的支付装置的结构示意图；
60.图13是本技术一个实施例提供的支付装置的结构示意图；
61.图14是本技术一个实施例提供的支付装置的结构示意图；
62.图15是本技术一个实施例提供的支付装置的结构示意图；
63.图16是本技术一个实施例提供的计算机设备的结构示意图。
具体实施方式
64.下面将详细描述本技术的各个方面的特征和示例性实施例，为了使本技术的目的、技术方案及优点更加清楚明白，以下结合附图及具体实施例，对本技术进行进一步详细描述。应理解，此处所描述的具体实施例仅意在解释本技术，而不是限定本技术。对于本领域技术人员来说，本技术可以在不需要这些具体细节中的一些细节的情况下实施。下面对实施例的描述仅仅是为了通过示出本技术的示例来提供对本技术更好的理解。
65.需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括
……”
限定的要素，并不排除在包括要素的过程、方法、物品或者设备中还存在另外的相同要素。
66.在相关技术中，为了给用户提供更为便捷的服务，一些应用程序提供了支付功能，使得用户可以通过这些具有支付功能的应用程序进行移动支付。这些具有支付功能的应用
程序有时还会嵌入一些商户小程序，用户可以在这些商户小程序中挑选所需服务或商品进行下单，并在该商户小程序中确认支付订单，此时，可以通过这些应用程序所属方提供的支付控件支付商户小程序中的支付订单。
67.然而，这种支付方式具有局限性，即用户仅可以通过该应用程序所属方提供的支付控件进行支付，无法通过其他方式支付，如此，使得支付方式较为单一，影响支付效率。另外，虽然可以跳转到第三方应用程序支付，但是，该过程会增加用户操作，增加支付过程的复杂性。
68.基于此，为了解决上述出现的问题，本技术实施例提供了一种基于支付小程序的支付方法，主体应用程序服务端可以根据主体应用程序中商户小程序的支付订单，向与支付小程序对应的资源支付服务端发送查询请求，查询请求用于请求资源支付服务端确定主体应用程序的应用账户与支付小程序的支付账户是否建立授权关系，支付小程序为嵌入主体应用程序中的具有支付功能的应用程序；接着，在接收到资源支付服务端发送的表征应用账户和支付账户已建立授权关系的查询反馈结果时，可以向资源支付服务端发送第一支付指令，第一支付指令用于指示支付小程序对支付订单进行处理，由此，该支付方式可以通过除主体应用程序所属方提供的支付控件之外的支付方式，支付商户小程序中的订单，增加付款途径，提高支付效率，并且，在主体应用程序中的支付小程序支付商户小程序的订单，无需跳转到主体应用程序外的页面如html5页面，也无需跳转到第三方支付应用以完成支付，减少了用户触发启动第三方应用程序以及返回主体应用程序的操作，提高了用户支付的便捷性。
69.基于此，本技术实施例提供了一种支付方法、装置、设备及存储介质。下面将结合附图1至图11，详细描述本技术实施例的支付方法、装置、服务器及存储介质，应注意，这些实施例并不是用来限制本技术公开的范围。
70.首先，对本技术实施例提供的支付方法的支付架构进行说明。
71.如图1所示，该支付架构10可以包括电子设备101、主体应用程序服务端102、资源支付服务端103和资源管理服务端104。
72.下面对其上述支付架构10进行详细说明。
73.电子设备101，在一个示例中，电子设备101可以用于与用户进行人机交互，例如，接收并响应用户对电子设备101输入等。在另一个示例中，电子设备101安装有主体应用程序，电子设备101用于与主体应用程序对应的主体应用程序服务端102进行数据交互，以响应用户的输入。
74.主体应用程序服务端102，在一个示例中，可以与主体应用程序所在的电子设备101进行数据交互，例如，更新电子设备101中安装的主体应用程序的版本，以及，为主体应用程序提供数据支持。在另一个示例中，主体应用程序服务端102，可以与资源支付服务端102进行数据交互，其中，与资源支付服务端102对应的支付程序可以嵌入主体应用程序，作为主体应用程序中的支付小程序，以实现支付功能，例如，主体应用程序服务端102具体可以用于向与支付小程序对应的资源支付服务端102发送查询请求，以请求资源支付服务端确定主体应用程序服务端的应用账户与支付小程序的支付账户是否建立授权关系；以及，接收资源支付服务端102发送的查询反馈结果。在又一个示例中，主体应用程序服务端102可以为电子设备101中的主体应用程序提供支付控件，并与资源管理服务端104进行数据交
互，其中，主体应用程序服务端102可以向资源管理服务端104发送资源转移请求，该资源转移请求携带支付订单相关的信息，以使资源管理服务端104根据支付订单执行相应资源转移的方法，如根据支付订单，对与主体应用程序的应用账户绑定的资源卡中的资源进行转移；以及，主体应用程序服务端102还可以接收资源管理服务端104发送的与资源转移请求对应的资源转移结果。
75.资源支付服务端103，在一种示例中，资源支付服务端103可以与主体应用程序服务端102进行数据交互，其中，资源支付服务端103用于为嵌入到主体应用程序服务中的支付小程序提供数据支持，基于此，通过与主体应用程序服务端102进行交互，提示主体应用程序服务端102通过支付小程序向用户进行相应提示，如提示用户输入用户身份凭证、用户通信设备信号；以及，资源支付服务端103接收主体应用程序服务端103发送的查询请求，并根据查询请求，确定主体应用程序服务的应用账户与资源支付服务端对应的支付小程序的支付账户是否建立授权关系的查询反馈结果；以及，资源支付服务端103向主体应用程序服务端发送查询反馈结果。在另一种示例中，资源支付服务端103还可以与资源管理服务端104进行数据交互，其中，资源支付服务端103向资源管理服务端104发送绑卡请求，绑卡请求用于请求资源管理服务端根据授权码、授权接口凭证、用户身份标识和用户授权信息，对支付小程序的支付账户进行绑定第一资源卡处理；以及，资源支付服务端103用于接收资源管理服务端104反馈的与支付账户绑定的第一资源卡的资源卡信息；以及，资源支付服务端103用于向资源管理服务端104发送资源转移请求，该资源转移请求携带支付订单相关的信息，以使资源管理服务端104根据支付订单执行相应资源转移的方法，如根据支付订单，对与支付小程序的支付账户绑定的资源卡中的资源进行转移；以及，主体应用程序服务端102还可以接收资源管理服务端104发送的与资源转移请求对应的资源转移结果。
76.资源管理服务端104，可以与主体应用程序服务端102资源支付服务端103进行数据交互。其中，资源管理服务端104可以用于根据授权码、授权接口凭证、用户身份标识和用户授权信息，对支付小程序的支付账户进行绑定第一资源卡处理。资源管理服务端104还可以用于基于主体应用程序服务端102和资源支付服务端103发送的资源转移请求，对支付订单执行相应资源转移的方法，如根据支付订单，对与支付小程序的支付账户绑定的资源卡中的资源进行转移。
77.基于上述如图1所示的支付架构，结合图2，对本技术实施例提供的支付方法进行详细说明。
78.如图2所示，本技术实施例中的支付方法可以包括s201至s222，具体步骤如下所示。
79.s201，电子设备101接收用户对电子设备101中主体应用程序的至少一个商户小程序的第四输入；
80.s202，电子设备101响应于第四输入，显示与第四输入对应的商户小程序的第一界面；
81.s203，电子设备101在接收到用户对第一界面的第一输入的情况下，从第一界面切换显示为第二界面，其中，第一输入为确认在商户小程序中提交支付订单的输入，第二界面为支付小程序对支付订单进行处理的界面，支付小程序为嵌入主体应用程序中的具有支付功能的应用程序；
82.s204，电子设备101可以通过主体应用程序，向主体应用程序服务端102发送商户小程序的支付订单；
83.需要注意的是，在接收到第一输入的情况下，电子设备101也可以先执行s204，再执行从第一界面切换显示为第二界面；当然，电子设备101也可以先执行从第一界面切换显示为第二界面，再执行s204；同理，电子设备101还可以在执行从第一界面切换显示为第二界面的同时，执行s204；
84.s205，主体应用程序服务端102根据支付订单，向与支付小程序对应的资源支付服务端103发送查询请求；
85.s206，资源支付服务端103接收查询请求，并根据查询请求，确定主体应用程序的应用账户与支付小程序的支付账户是否建立授权关系的查询反馈结果；
86.s207，资源支付服务端103向主体应用程序服务端102发送查询反馈结果；
87.s208，主体应用程序服务端102接收查询反馈结果，并在查询反馈结果表征应用账户和支付账户已建立授权关系的情况下，向资源支付服务端103发送第一支付指令，第一支付指令用于指示支付小程序对支付订单进行处理；
88.s209，资源支付服务端103接收第一支付指令，并根据第一支付指令向资源管理服务端104发送第一资源转移请求，第一资源转移请求包括支付订单，支付订单可以包括支付小程序的支付账户绑定的第三资源卡、支付订单的资源转移量、收款方账户的信息(如与商户小程序对应的商户方的账户信息)；
89.s210，资源管理服务端104根据第一资源转移请求，从支付账户绑定的第三资源卡中转出资源转移量的资源，并将资源转移量的资源转入收款方账户；
90.s211，资源管理服务端104向资源支付服务端103发送第一结果，第一结果用于表征已完成对支付订单的资源转移处理；
91.s212，资源支付服务端103在接收到第一结果的情况下，通过主体应用程序服务端102向电子设备101发送第一结果；
92.s213，电子设备101根据第一结果，显示第三界面，第三界面包括支付小程序对支付订单处理后的支付结果。
93.另外，在一种可能的实施例中，查询反馈结果还可以表征应用账户和支付账户未建立授权关系，即若查询反馈结果携带第一信息获取请求，则查询反馈结果用于表征应用账户和支付账户未建立授权关系，第一信息获取请求用于请求与应用账户绑定的第一通信设备号，基于此，在s207之后，如图3所示，该支付方法还可以包括：
94.s214，主体应用程序服务端102根据第一信息，向资源支付服务端103发送第一实名匹配请求；其中，第一实名匹配请求包括与应用账户绑定的第一通信设备号，第一实名匹配请求用于请求确定第一通信设备号是否与支付账户关联；
95.s215，资源支付服务端103接收主体应用程序服务端102发送的第一实名匹配请求，并获取与支付账户绑定的第二通信设备号；
96.s216，资源支付服务端103在获取到与支付账户绑定的第二通信设备号的情况下，根据第一实名匹配请求，确定第一通信设备号和第二通信设备号是否匹配；
97.s217，资源支付服务端103在确定第一通信设备号和第二通信设备号匹配的情况下，向主体应用程序服务端102发送第二实名匹配请求；
98.s218，主体应用程序服务端102接收资源支付服务端103发送的第二实名匹配请求，第二实名匹配请求包括第一匹配结果和与支付账户绑定的第一用户身份凭证，第一匹配结果用于表示第一通信设备号和支付账户绑定的第二通信设备号匹配；以及，获取与应用账户绑定的第二用户身份凭证；s219，主体应用程序服务端102在获取到与应用账户绑定的第二用户身份凭证的情况下，确定第一用户身份凭证和第二用户身份凭证是否匹配；
99.s220，主体应用程序服务端102在第一用户身份凭证和第二用户身份凭证匹配的情况下，向资源支付服务端发送建立通知，建立通知用于通知资源支付服务端建立应用账户和支付账户的授权关系。然后，可以执行s208。
100.由此，主体应用程序服务端可以根据主体应用程序中商户小程序的支付订单，向与支付小程序对应的资源支付服务端发送查询请求，查询请求用于请求资源支付服务端确定主体应用程序的应用账户与支付小程序的支付账户是否建立授权关系，支付小程序为嵌入主体应用程序中的具有支付功能的应用程序；接着，在接收到资源支付服务端发送的表征应用账户和支付账户已建立授权关系的查询反馈结果时，可以向资源支付服务端发送第一支付指令，第一支付指令用于指示支付小程序对支付订单进行处理，由此，该支付方式可以通过除主体应用程序所属方提供的支付控件之外的支付方式，支付商户小程序中的订单，增加付款途径，提高支付效率，并且，在主体应用程序中的支付小程序支付商户小程序的订单，无需跳转到主体应用程序外的页面如html5页面，也无需跳转到第三方支付应用以完成支付，减少了用户触发启动第三方应用程序以及返回主体应用程序的操作，提高了用户支付的便捷性。
101.基于此，为了更好的说明上述内容，下面结合图4至图9对本技术实施例提供的支付方法进行说明。
102.首先，下面结合图4对本技术实施例提供的基于主体应用程序服务端的支付方法进行详细说明。
103.图4为本技术实施例提供的一种基于主体应用程序服务端的支付方法的流程图。
104.如图4所示，该支付方法可以应用于如图1所示的支付架构中的主体应用程序服务端，该支付方法具体可以包括如下步骤：
105.步骤410，接收主体应用程序中商户小程序的支付订单；步骤420，根据支付订单，向与支付小程序对应的资源支付服务端发送查询请求，其中，查询请求用于请求资源支付服务端确定主体应用程序的应用账户与支付小程序的支付账户是否建立授权关系，支付小程序为嵌入主体应用程序中的具有支付功能的应用程序；步骤430，接收资源支付服务端发送的查询反馈结果；步骤440，在查询反馈结果表征应用账户和支付账户已建立授权关系的情况下，向资源支付服务端发送第一支付指令，第一支付指令用于指示支付小程序对支付订单进行处理。
106.由此，该支付方式可以通过除主体应用程序所属方提供的支付控件之外的支付方式，支付商户小程序中的订单，增加付款途径，提高支付效率，并且，在主体应用程序中的支付小程序支付商户小程序的订单，无需跳转到主体应用程序外的页面如html5页面，也无需跳转到第三方支付应用以完成支付，减少了用户触发启动第三方应用程序以及返回主体应用程序的操作，提高了用户支付的便捷性。
107.下面对上述步骤进行详细说明，具体如下所示：
108.首先，涉及步骤430，在一种或多种可能的实施例中，若查询反馈结果携带第一信息获取请求，则查询反馈结果用于表征应用账户和支付账户未建立授权关系，第一信息获取请求用于请求与应用账户绑定的第一通信设备号。
109.基于此，在步骤430之后，可以判断与应用账户绑定的第一通信设备号和与支付账户绑定的第二通信设备号是否匹配，若匹配，则进一步验证与支付账户绑定的第一用户身份凭证和与应用账户绑定的第二用户身份凭证是否匹配，若匹配，则建立应用账户和支付账户的授权关系，基于此，该支付方法还可以包括：
110.步骤4401，根据第一信息获取请求，向资源支付服务端发送第一实名匹配请求；其中，第一实名匹配请求包括与应用账户绑定的第一通信设备号，第一实名匹配请求用于请求确定第一通信设备号是否与支付账户关联；
111.步骤4402，接收资源支付服务端发送的第二实名匹配请求，第二实名匹配请求包括第一匹配结果和与支付账户绑定的第一用户身份凭证，第一匹配结果用于表示第一通信设备号和支付账户绑定的第二通信设备号匹配；
112.步骤4403，在获取到与应用账户绑定的第二用户身份凭证的情况下，确定第一用户身份凭证和第二用户身份凭证是否匹配；
113.步骤4404，在第一用户身份凭证和第二用户身份凭证匹配的情况下，向资源支付服务端发送建立通知，建立通知用于通知资源支付服务端建立应用账户和支付账户的授权关系。
114.其中，第一用户身份凭证可以为表征用户身份的信息，如授权标识auth id或身份证号码，这里，主体应用程序服务端可以而接收资源支付服务端发送的auth id，auth id能够在资源支付服务端标识唯一用户，且不为支付小程序的账户用户id。如此，可以根据第一用户身份凭证。
115.在一个实施例中，若第一通信设备号和第二通信设备号不匹配，则需要提示用户输入用户身份凭证，接着，将用户输入的用户身份凭证与第二用户身份凭证进行匹配，若匹配，则进入用户的生物特征如人脸、虹膜等认证，若认证通过后，则可以建立应用账户和支付账户的授权关系，基于此，在上述步骤4401之后，该支付方法还可以包括：
116.步骤4405，接收资源支付服务端发送的第一指令；
117.步骤4406，根据第一指令，通过支付小程序，提示用户输入用户身份凭证；
118.步骤4407，在接收到用户输入的目标用户身份凭证的情况下，将目标用户身份凭证与应用账户绑定的第二用户身份凭证进行匹配；
119.步骤4408，在目标用户身份凭证和第二用户身份凭证匹配的情况下，通过支付小程序，提示用户进行生物特征提取；
120.步骤4409，在获取到用户的目标生物特征信息、且目标生物特征信息与预设生物特征匹配的情况下，向资源支付服务端发送建立通知。
121.在另一个实施例中，若第一通信设备号和第二通信设备号匹配、支付小程序已实名且与主体应用程序一致，即第一用户身份凭证和第二用户身份凭证匹配，则为了保证验证的准确性，可以实时采集用户的生物特征，以进一步验证用户身份，基于此，上述涉及的步骤4404具体可以包括：
122.步骤44041，在第一用户身份凭证和第二用户身份凭证匹配的情况下，通过支付小
程序，提示用户进行生物特征提取；
123.步骤44042，在获取到用户的目标生物特征信息、且目标生物特征信息与预设生物特征匹配的情况下，向资源支付服务端发送建立通知。
124.在又一个实施例中，若第一通信设备号和第二通信设备号匹配、支付小程序已实名，但是，第一用户身份凭证和第二用户身份凭证不匹配，则可以提示用户实时输入目标用户身份凭证，接着，将用户输入的用户身份凭证与第二用户身份凭证进行匹配，若匹配，则进入用户的生物特征如人脸、虹膜等认证，若认证通过后，则可以建立应用账户和支付账户的授权关系，基于此，在上述涉及的步骤4403之后，该支付方法还可以包括：
125.步骤4501，在第一用户身份凭证和第二用户身份凭证不匹配的情况下，通过支付小程序，提示用户输入用户身份凭证；
126.步骤4502，在接收到用户输入的目标用户身份凭证的情况下，将目标用户身份凭证与应用账户绑定的第二用户身份凭证进行匹配；
127.步骤4503，在目标用户身份凭证和第二用户身份凭证匹配的情况下，通过支付小程序，提示用户进行生物特征提取；
128.步骤4504，在获取到用户的目标生物特征信息、且目标生物特征信息与预设生物特征匹配的情况下，向资源支付服务端发送建立通知。
129.在再一个实施例中，若第一通信设备号和第二通信设备号匹配，但支付小程序未经过实名认证，则在上述步骤4401之后，该支付方法还可以包括：
130.步骤4601，接收资源支付服务端发送的第二指令；
131.步骤4602，根据第二指令，通过支付小程序，提示用户输入用户身份凭证；
132.步骤4603，在接收到用户输入的目标用户身份凭证的情况下，将目标用户身份凭证与应用账户绑定的第二用户身份凭证进行匹配；
133.步骤4604，在目标用户身份凭证和第二用户身份凭证匹配的情况下，通过支付小程序，提示用户进行生物特征提取；
134.步骤4605，在获取到用户的目标生物特征信息、且目标生物特征信息与预设生物特征匹配的情况下，向资源支付服务端发送建立通知。
135.在再一个实施例中，若支付小程序未绑定用户通信设备号，则在上述步骤4402之前，该支付方法还可以包括：
136.步骤4701，接收资源支付服务端发送的第三指令；
137.步骤4702，根据第三指令，通过支付小程序，提示用户输入用户通信设备号；
138.步骤4703，在接收到用户输入的目标用户通信设备号的情况下，向资源支付服务端发送用户通信设备通知，用户通信设备通知包括目标用户通信设备号，用户通信设备通知用于通知资源支付服务端将目标用户通信设备号确定为与支付账户绑定的第二通信设备号。
139.在另一种或多种可能的实施例中，在一些场景中，若用户身份凭证关联多个用户通信设备号，则与用户通信设备号对应的支付小程序的支付账户可以为m个支付账户，为了保证确定建立授权关系的准确性，m为大于1的整数；在步骤430之前，该支付方法还可以包括：
140.步骤4801，接收资源支付服务端发送的第五指令；
141.步骤4802，根据第五指令，通过所示支付小程序，提示用户从m个支付账户中确定目标支付账户，目标支付账户为确定查询与应用账户建立授权关系的支付账户；
142.步骤4803，向资源支付服务端发送用户确定的目标支付账户，以便资源支付服务端反馈主体应用程序的应用账户与目标支付账户是否建立授权关系的查询反馈结果。
143.然后，在步骤440之后，若支付小程序的支付账户未绑定资源卡，则在一种或多种可能的实施例中，该支付方法还可以包括：
144.步骤4901，接收资源支付服务端发送的第四指令；
145.步骤4902，根据第四指令，通过支付小程序，提示用户为支付账户绑定资源卡；
146.步骤4903，在接收到用户输入为支付账户绑定的第一资源卡的情况下，向资源支付服务端发送第一资源卡的信息。在另一种或多种可能的实施例中，若资源卡处于被冻结、或被封号的状态，则在步骤440之后，该支付方法还可以包括：
147.接收资源支付服务端发送的异常指令，异常指令用于表示支付账户的账户状态和/或与支付账户绑定的资源卡的状态为预设异常状态；
148.根据异常指令，向资源管理服务端发送第二资源转移请求，第二资源转移请求包括支付订单，支付订单包括应用账户绑定的第二资源卡、支付订单的资源转移量、收款方账户的信息，第二资源转移请求用于请求资源管理服务端根据第二资源卡对支付订单进行处理。
149.需要说明的是，在一些实施例中，支付小程序的所属方与主体应用程序的所属方不同。如此，该支付方式可以通过除主体应用程序所属方提供的支付控件之外的支付方式，支付商户小程序中的订单，增加付款途径，提高支付效率。
150.下面结合图5对本技术实施例提供的基于资源支付服务端的支付方法进行详细说明。
151.图5为本技术实施例提供的一种基于资源支付服务端的支付方法的流程图。
152.如图5所示，该支付方法可以应用于如图1所示的支付架构中的资源支付服务端，该支付方法具体可以包括如下步骤：
153.步骤510，接收主体应用程序服务端发送的查询请求；步骤520，根据查询请求，确定应用账户与支付账户是否建立授权关系的查询反馈结果，应用账户为与主体应用程序服务端对应的主体应用程序的账户，支付账户为资源支付服务端对应的支付小程序的账户，支付小程序为嵌入主体应用程序中的具有支付功能的应用程序；步骤530，向主体应用程序服务端发送查询反馈结果；步骤540，在接收到主体应用程序发送的第一支付指令的情况下，通过支付小程序的支付账户对支付订单进行处理。
154.下面对上述步骤进行详细说明，具体如下所示：
155.首先，涉及步骤510，在一种或多种可能的实施例中，支付小程序的支付账户为m个支付账户，m为大于1的整数，基于此，在步骤510之后，该支付方法还可以包括：
156.向主体应用程序服务端发送第五指令，第五指令用于指示主体应用程序服务端通过所示支付小程序，提示用户从m个支付账户中确定目标支付账户；
157.在接收到主体应用程序服务端发送的用户确定的目标支付账户的情况下，确定应用账户与目标支付账户是否建立授权关系的查询反馈结果。
158.其次，涉及步骤530，在一种或多种可能的实施例中，查询反馈结果携带第一信息
获取请求，查询反馈结果用于表征应用账户和支付账户未建立授权关系，第一信息获取请求用于请求与应用账户绑定的第一通信设备号，基于此，在步骤530之后，该支付方法还可以包括：
159.步骤5501，接收主体应用程序服务端发送的第一实名匹配请求，第一实名匹配请求包括与应用账户绑定的第一通信设备号；
160.步骤5502，在获取到与支付账户绑定的第二通信设备号的情况下，根据第一实名匹配请求，确定第一通信设备号和第二通信设备号是否匹配；
161.步骤5503，在确定第一通信设备号和第二通信设备号匹配的情况下，向主体应用程序服务端发送第二实名匹配请求，第二实名匹配请求包括第一匹配结果和与支付账户绑定的第一用户身份凭证，第一匹配结果用于表示第一通信设备号和支付账户绑定的第二通信设备号匹配，第二实名匹配请求用于请求主体应用程序服务端确定第一用户身份凭证是否与应用账户关联。
162.在一种实施例中，在步骤5503之后，该支付方法还可以包括：
163.接收主体应用程序服务端发送的建立通知；
164.根据建立通知，建立应用账户和支付账户的授权关系。
165.在另一个实施例中，在步骤5502之后，该支付方法还可以包括：
166.在确定第一通信设备号和第二通信设备号不匹配的情况下，向主体应用程序服务端发送第一指令，第一指令用于指示主体应用程序通过支付小程序提示用户输入用户身份凭证。
167.在又一个实施例中，在步骤5503之前，该支付方法还可以包括：
168.确定支付账户是否实名认证；
169.在确定支付账户已实名认证的情况下，将与支付账户已实名认证的用户身份凭证确定为第一用户身份凭证。
170.反之，在确定支付账户未实名认证的情况下，向主体应用程序服务端发送第二指令，第二指令用于指示主体应用程序通过支付小程序提示用户输入用户身份凭证，并根据用户输入的目标用户身份凭证确定是否建立应用账户和支付账户的授权关系。
171.在再一个实施例中，在步骤5501之后，该支付方法还可以包括：
172.在获取到与支付账户未绑定的第二通信设备号的情况下，向主体应用程序服务端发送第三指令，第三指令用于指示主体应用程序通过支付小程序提示用户输入用户通信设备号；
173.接收主体应用程序服务端发送的用户通信设备通知，用户通信设备通知包括用户输入的目标用户通信设备号；
174.将目标用户通信设备号确定为第二通信设备号。
175.基于此，本技术实施例可以通过如下例子，对上述图4和图5中的内容进行进一步地说明。
176.首先，调用主体应用程序中支付小程序，判断支付小程序的支付账户是否与主体应用程序的应用账户建立授权关系。
177.若支付账户与应用账户建立授权，则通过支付小程序进行支付。
178.若支付账户与应用账户未建立授权，则可以执行如下步骤。
179.若应用账户绑定的第一通信设备号已关联支付账户，即第一通信设备号与支付账户绑定的第二通信设备号匹配，则进一步判断支付账户是否已实名：
180.(1)支付账户已实名
181.若支付账户绑定的第一用户身份凭证与应用账户绑定的第二用户身份凭证一致，则可以触发电子设备显示关联身份信息页面，然后，触发人脸核验页面，进行人脸核验，核验通过后建立支付账户与应用账户的绑定关系。
182.若支付账户绑定的第一用户身份凭证与应用账户绑定的第二用户身份凭证不一致，则可以触发电子设备身份证输入页面，用户输入用户身份凭证，输入的目标用户身份凭证与第二用户身份凭证一致后进行人脸核验。
183.这里，核验通过后，如果关联支付账号数量为0个，则创建用户名形式的支付账号并关联身份信息，建立应用账户与支付账号的绑定关系，如果关联支付账号数量多于1个，则用户选择其中一个支付账户，并建立选择的支付账户与应用账户的绑定关系。
184.(2)支付账户未实名
185.可以触发电子设备显示身份证输入页面，用户输入目标用户身份凭证，在输入的目标用户身份凭证与第二用户身份凭证一致后进行人脸核验，核验通过后，如果关联支付账号数量为0个，则创建用户名形式的支付账号并关联身份信息，建立应用账户与支付账号的绑定关系，如果关联支付账号数量多于1个，则用户选择其中一个支付账户，并建立选择的支付账户与应用账户的绑定关系。
186.若应用账户绑定的第一通信设备号未关联支付账户，即第一通信设备号与支付账户绑定的第二通信设备号不匹配，则触发身份证号输入页面，用户输入目标用户身份凭证，在输入的目标用户身份凭证与第二用户身份凭证一致后进行人脸核验，核验通过后，如果关联支付账号数量为0个，则创建用户名形式的支付账号并关联身份信息，建立应用账户与支付账号的绑定关系，如果关联支付账号数量多于1个，则用户选择其中一个支付账户，并建立选择的支付账户与应用账户的绑定关系。
187.需要说明的是，在一个示例中，若第一通信设备号与第二通信设备号匹配，在支付账户绑定的用户身份凭证和应用账户绑定的用户身份凭证并不一致，但用户输入的目标用户身份凭证与应用账户绑定的用户身份凭证一致，但在支付小程序无记录的情形，资源支付服务端可以为该用户创建支付账户的账户名，例如，创建用户名的规则为第一通信设备号+随机字符串，基于此，该方法还可以包括：接收主体应用程序服务端发送的身份凭证匹配通知；根据身份凭证匹配通知和第一通信设备号，生成支付账户的账户信息，账户信息包括支付账户的账户名称。
188.在另一个示例中，用户在账号选择页面，选择账号并点击确定后，关联关系即建立成功，并跳转至后续页面。
189.在又一个示例中，对于第一通信设备号，在支付小程序对应的实名信息证件类型为非身份证时，先与主体应用程序进行实名信息校验，如果校验信息一致，通过主体应用程序向用户报错不支持的证件类型；如果校验信息不一致，继续原用户关联流程，进入用户手输姓名身份证号页面。
190.在再一个示例中，对于实名信息比对接口，同一个openid限制每秒最多只能请求1次，超过该频率时，提示用户“操作过于频繁，请稍等几秒再试”。
191.在再一个示例中，若仅关联到1个支付账号且该支付账号冻结，则可以通过第一预设显示方式展示，如置灰且不可勾选，根据冻结类型展示不同的提示文案；若关联到多个支付账号且多个支付账号全部冻结，则可以通过第二预设显示方式展示，如置灰且不可勾选，根据冻结类型展示不同的提示文案；若关联到多个支付账号，且多个支付账号中的部分支付账号冻结，部分支付账号正常，则可以通过第三预设显示方式展示，如展示分两部分，正常的可以勾选，冻结的置灰且不可勾选，根据冻结类型展示不同的提示文案。进一步地，不同异常状态对应的提示文案如下：后台冻结-不可解冻：“支付账号状态异常”；后台冻结-允许解冻：“支付账号被冻结”；支付小程序自助冻结：“支付账号被冻结，解冻请使用与支付小程序对应的支付应用程序”。其中，不同的冻结类型可以根据统一用户中的冻结类型字段(freezetp)来进行区分，具体取值如下：支付小程序冻结；后台冻结；(对应上述中的资源支付服务端冻结-允许解冻)；违规冻结(不可解冻)；(对应上述中的资源支付服务端冻结-不可解冻)。关联逻辑中，若用户在资源支付服务端需新创建支付账号，不涉及异常状态；若用户在后台仅能查询到1条满足关联的记录，在关联前，判断该支付账号状态是否正常，若正常则关联成功，若异常，则需展示账号关联页面，并通过账号关联页面显示异常原因；若用户在后台查询到多条满足关联的记录，则展示账号关联页面，并按照账号状态是否正常分别进行展示。
192.然后，涉及步骤540，在一种或多种可能的实施例中，该步骤具体可以包括：
193.在接收到主体应用程序发送的第一支付指令的情况下，向资源管理服务端发送第一资源转移请求，第一资源转移请求包括支付订单，支付订单包括支付账户绑定的第一资源卡、支付订单的资源转移量和收款方账户的信息，第一资源转移请求用于请求资源管理服务端根据第一资源卡对支付订单进行处理。在另一种或多种可能的实施例中，涉及步骤540之后，该支付方法还可以包括：
194.步骤5601，在确定支付小程序的支付账户未绑定资源卡的情况下，向主体应用程序服务端发送第四指令，第四指令用于指示主体应用程序服务端通过支付小程序，提示用户为支付账户绑定资源卡；
195.步骤5602，在接收到主体应用程序服务端发送的第一资源卡的信息的情况下，向资源管理服务端发送绑卡请求，绑卡请求包括第一资源卡的信息、授权码、授权接口凭证、用户身份标识(如openid)和用户授权信息，绑卡请求用于请求资源管理服务端根据授权码、授权接口凭证、用户身份标识和用户授权信息，将支付账户和第一资源卡进行绑定；
196.步骤5603，在接收到资源管理服务端发送的完成绑定结果的情况下，向资源管理服务端发送第三资源转移请求，第三资源转移请求包括支付订单，支付订单包括第一资源卡、支付订单的资源转移量、收款方账户的信息，第三资源转移请求用于请求资源管理服务端根据第一资源卡对支付订单进行处理。
197.示例性地，如图6所示，绑定资源卡的过程可以基于资源支付服务端和资源管理服务端，基于此，具体如下所示：
198.s601，若支付账户没有绑定资源卡或要绑定资源卡，则电子设备接收用户对“添加资源卡”进入添卡页面的输入，以及在资源卡列表中选择资源管理服务端的输入，根据上述两种输入，通过授权支付小程序发送用户信息至该资源管理服务端，其中，用户信息包括用户身份凭证、通信设备号等。
199.s602，资源支付服务端根据生成授权码code，向资源管理服务端发送授权码code。
200.s603，资源管理服务端向资源支付服务端反馈code；
201.s604，资源支付服务端向资源管理服务端发送绑卡请求，该绑卡请求包括授权接口凭证(access token)和用户标识(open id)；
202.s605，资源管理服务端在接收到绑卡请求的情况下，向资源支付服务端发送第二信息获取请求，第二信息获取请求用于获取用户信息；
203.s606，资源支付服务端根据第二信息获取请求，向资源管理服务端发送用户授权后的用户信息；
204.s607，资源管理服务端根据用户信息，在资源管理服务端h5页面中展示资源支付服务端的用户关联的资源卡列表中，确定用户绑定的资源卡。
205.s608，资源管理服务端通过绑卡接口向资源支付服务端发送用户绑定的资源卡信息；
206.s609，资源支付服务端向资源管理服务端发送sn号，sn号用于前台跳转到资源支付服务端的传入参数。
207.s610，资源管理服务端根据sn号，访问资源支付服务端在线支付开通页面；
208.s611，资源支付服务端通过支付小程序跳转至在线支付开通页面，以便用户完成在线支付开通验证和短信验证后系统同步完成绑卡过程，然后，直接触发后续的支付或设置支付密码流程,。
209.需要说明的是，用户设置支付密码的过程会出现如下情况，下面分别进行说明。若用户完成绑定资源卡，且未设置支付密码，则资源支付服务端可通过支付小程序提示用户输入支付密码。输入支付密码的过程，会出现如下可能：若新支付密码与原有密码一致，提示用户重新设置付密码；若新支付密码不是重复、连续的数字，提示用户重新设置付密码；若新支付密码至少包括目标数字，提示用户重新设置付密码，其中，目标数字包括下述中的至少一种：用户的通信设备号中至少部分连续的数字、身份证号码中至少部分连续的数字。
210.以及，进一步地，如图7所示，资源支付服务端具体可以包括全渠道系统和资源支付管理系统，基于资源支付服务端具体的系统，可以执行如下绑定资源卡的过程。
211.如图7所示，在一种或多种可能的实施例中，在上述s601之后，资源支付服务端具体可以执行如下步骤：
212.s701，全渠道系统向资源支付管理系统发送请求，请求支持的资源卡列表中每个资源卡所属方的资源管理服务端的api接口；
213.s702，资源支付管理系统向全渠道系统返回支持绑定资源卡的资源管理服务端的信息，如资源管理服务名称、资源管理服务机构号、资源卡类别；
214.s703，全渠道系统向资源支付管理系统发送用户信息，其中，该用户信息可以包括用户身份凭证、通信设备号等。
215.s704，资源支付管理系统向全渠道系统发送sn号，sn号用于前台跳转银联页面的传入参数，一次有效，有效期为5分钟。
216.另外，资源支付管理系统还可以向全渠道系统发送用户身份标识、与支付小程序关联的支付账户等本技术实施例中用于建立应用账户和支付账户之间授权关系的信息。
217.由此，用户可以通过图6和图7所示的内容提示用户每次绑定一张资源卡，这样，用
户可以登录支付小程序，选择一键绑卡功能，然后，选择支持绑定资源卡所属方的资源管理服务端，并对其进行授权，即通过支付小程序向资源支付服务端后台发送用户信息如用户姓名、身份证件号码、证件类型等，以便完成资源卡的绑定，以及完成在线支付的开通。另外，还可以通过上述方式提示用户每次绑定多个资源卡，可以参照上述方式完成资源卡的绑定，以及完成在线支付的开通，在此不再赘述。
218.下面结合图8对本技术实施例提供的基于电子设备的支付方法进行详细说明。
219.图8为本技术实施例提供的一种基于电子设备的支付方法的流程图。
220.如图8所示，该支付方法可以应用于如图1所示的支付架构中的电子设备，该支付方法具体可以包括如下步骤：
221.步骤810，显示主体应用程序中商户小程序的第一界面；
222.步骤820，在接收到对第一界面的第一输入的情况下，从第一界面切换显示为第二界面，其中，第一输入为确认在商户小程序中提交支付订单的输入，第二界面为支付小程序对支付订单进行处理的界面，支付小程序为嵌入主体应用程序中的具有支付功能的应用程序；
223.步骤830，在确定主体应用程序的应用账户与支付小程序的支付账户已建立授权关系的情况下，显示支付小程序对支付订单处理后的支付结果。
224.由此，如图9所示，显示主体应用程序中商户小程序的第一界面90，在接收到对第一界面的第一输入如用户点击“立即购买”的情况下，从第一界面切换显示为第二界面91，以便让用户核实支付内容，然后，在用户点击“确认付款”、且支付账户与应用账户已建立授权关系的情况下，显示支付小程序对支付订单处理后的支付结果。
225.如此，可以在主体应用程序中，将资源支付服务端提供的支付功能以小程序的形式接入主体应用程序，从而无需跳转到其他第三方应用程序，直接在主体应用内即可实现快速支付服务。
226.另外，应用场景还可以用于线下扫码支付的场景，基于此，下面结合图10对本技术实施例提供的基于电子设备的支付方法进行详细说明。
227.图10为本技术实施例提供的一种基于电子设备的支付方法的流程图。
228.如图10所示，该支付方法可以应用于如图1所示的支付架构中的电子设备，该支付方法具体可以包括如下步骤：
229.步骤1010，显示主体应用程序的第三界面，第三界面包括n个支付方，n为大于1的整数；
230.步骤1020，在接收到用户对n个支付方中目标支付方的第三输入的情况下，从第三界面切换显示为第四界面，第四界面为目标支付方对应的支付小程序的支付界面，支付小程序为嵌入主体应用程序中的具有支付功能的应用程序，支付界面包括支付小程序提供的付款码；
231.步骤1030，在确定主体应用程序的应用账户与支付小程序的支付账户已建立授权关系的情况下，显示第五界面，第五界面包括支付小程序对支付订单处理后的支付结果；支付小程序的所属方与主体应用程序的所属方不同。
232.如图11所示，显示主体应用程序的第三界面110，第三界面110包括3个支付方，如支付方1、支付方2和支付方3。在接收到用户对支付方3的第三输入的情况下，从第三界面
110切换显示为第四界面111，这里，第四界面111为支付方3对应的支付小程序的支付界面，支付界面可以包括支付小程序提供的付款码，以便交由收款设备扫描，在确定主体应用程序的应用账户与支付小程序的支付账户已建立授权关系的情况下显示第五界面112。
233.如此，本技术实施例提供的支付方法除了可以应用于远程的移动支付的场景之外，还可以应用于近场的移动支付，即向收款设备显示付款码，也可以实现在主体应用程序中，将与支付方对应的资源支付服务端提供的支付功能以小程序的形式接入主体应用程序，从而无需跳转到其他第三方应用程序，直接在主体应用内即可实现快速支付服务。
234.基于相同的发明构思，本技术还提供了一种支付装置。具体结合图12进行详细说明。
235.图12是本技术一个实施例提供的支付装置的结构示意图。
236.在本技术一些实施例中，图12所示支付装置可以设置于如图1所示的主体应用程序服务端中。
237.如图12所示，该支付装置120具体可以包括：
238.接收模块1201，用于接收主体应用程序中商户小程序的支付订单；
239.发送模块1202，用于根据支付订单，向与支付小程序对应的资源支付服务端发送查询请求，其中，查询请求用于请求资源支付服务端确定主体应用程序的应用账户与支付小程序的支付账户是否建立授权关系，支付小程序为嵌入主体应用程序中的具有支付功能的应用程序；
240.接收模块1201还用于，接收资源支付服务端发送的查询反馈结果；
241.发送模块1202还用于，在查询反馈结果表征应用账户和支付账户已建立授权关系的情况下，向资源支付服务端发送第一支付指令，第一支付指令用于指示支付小程序对支付订单进行处理。
242.下面分别对本技术实施例中支付装置120进行详细说明。
243.在一种或者多种可选的实施例中，本技术实施例中的支付装置120还可以包括第一确定模块；其中，
244.发送模块1202还用于，在查询反馈结果携带第一信息获取请求，查询反馈结果用于表征应用账户和支付账户未建立授权关系，第一信息获取请求用于请求与应用账户绑定的第一通信设备号的情况下，根据第一信息获取请求，向资源支付服务端发送第一实名匹配请求；其中，第一实名匹配请求包括与应用账户绑定的第一通信设备号，第一实名匹配请求用于请求确定第一通信设备号是否与支付账户关联；
245.接收模块1201还可以用于，接收资源支付服务端发送的第二实名匹配请求，第二实名匹配请求包括第一匹配结果和与支付账户绑定的第一用户身份凭证，第一匹配结果用于表示第一通信设备号和支付账户绑定的第二通信设备号匹配；
246.第一确定模块，用于在获取到与应用账户绑定的第二用户身份凭证的情况下，确定第一用户身份凭证和第二用户身份凭证是否匹配；
247.发送模块1202还用于，在第一用户身份凭证和第二用户身份凭证匹配的情况下，向资源支付服务端发送建立通知，建立通知用于通知资源支付服务端建立应用账户和支付账户的授权关系。
248.在另一种或者多种可选的实施例中，本技术实施例中的支付装置120还可以包括
第一提示模块和第一匹配模块；其中，
249.接收模块1201还用于，接收资源支付服务端发送的第一指令；
250.第一提示模块，用于根据第一指令，通过支付小程序，提示用户输入用户身份凭证；
251.第一匹配模块，用于在接收到用户输入的目标用户身份凭证的情况下，将目标用户身份凭证与应用账户绑定的第二用户身份凭证进行匹配；
252.第一提示模块还可以用于，在目标用户身份凭证和第二用户身份凭证匹配的情况下，通过支付小程序，提示用户进行生物特征提取；
253.发送模块1202还用于，在获取到用户的目标生物特征信息、且目标生物特征信息与预设生物特征匹配的情况下，向资源支付服务端发送建立通知。
254.在又一种或者多种可选的实施例中，本技术实施例中的支付装置120还可以包括第二提示模块；其中，
255.第二提示模块，用于在第一用户身份凭证和第二用户身份凭证匹配的情况下，通过支付小程序，提示用户进行生物特征提取；
256.发送模块1202还用于，在获取到用户的目标生物特征信息、且目标生物特征信息与预设生物特征匹配的情况下，向资源支付服务端发送建立通知。
257.在再一种或者多种可选的实施例中，本技术实施例中的支付装置120还可以包括第三提示模块、第二匹配模块；其中，
258.第三提示模块，用于在第一用户身份凭证和第二用户身份凭证不匹配的情况下，通过支付小程序，提示用户输入用户身份凭证；
259.第二匹配模块，用于在接收到用户输入的目标用户身份凭证的情况下，将目标用户身份凭证与应用账户绑定的第二用户身份凭证进行匹配；
260.第三提示模块还用于，在目标用户身份凭证和第二用户身份凭证匹配的情况下，通过支付小程序，提示用户进行生物特征提取；
261.发送模块1202还用于，在获取到用户的目标生物特征信息、且目标生物特征信息与预设生物特征匹配的情况下，向资源支付服务端发送建立通知。
262.在再一种或者多种可选的实施例中，本技术实施例中的支付装置120还可以包括第四提示模块、第三匹配模块；其中，
263.接收模块1201还用于，接收资源支付服务端发送的第二指令；
264.第四提示模块，用于根据第二指令，通过支付小程序，提示用户输入用户身份凭证；
265.第三匹配模块，用于在接收到用户输入的目标用户身份凭证的情况下，将目标用户身份凭证与应用账户绑定的第二用户身份凭证进行匹配；
266.第四提示模块还用于，在目标用户身份凭证和第二用户身份凭证匹配的情况下，通过支付小程序，提示用户进行生物特征提取；
267.发送模块1202还用于，在获取到用户的目标生物特征信息、且目标生物特征信息与预设生物特征匹配的情况下，向资源支付服务端发送建立通知。
268.在再一种或者多种可选的实施例中，本技术实施例中的支付装置120还可以包括第五提示模块；其中，
269.接收模块1201还用于，接收资源支付服务端发送的第三指令；
270.根据第三指令，通过支付小程序，提示用户输入用户通信设备号；
271.发送模块1202还用于，在接收到用户输入的目标用户通信设备号的情况下，向资源支付服务端发送用户通信设备通知，用户通信设备通知包括目标用户通信设备号，用户通信设备通知用于通知资源支付服务端将目标用户通信设备号确定为与支付账户绑定的第二通信设备号。
272.在再一种或者多种可选的实施例中，本技术实施例中的支付装置120还可以包括第六提示模块；其中，
273.接收模块1201还用于，接收资源支付服务端发送的第四指令；
274.第六提示模块，用于根据第四指令，通过支付小程序，提示用户为支付账户绑定资源卡；
275.发送模块1202还用于，在接收到用户输入为支付账户绑定的第一资源卡的情况下，向资源支付服务端发送第一资源卡的信息。
276.在再一种或者多种可选的实施例中，本技术实施例中的支付装置120还可以包括第七提示模块；其中，
277.接收模块1201还用于，在支付小程序的支付账户为m个支付账户，m为大于1的整数的情况下，接收资源支付服务端发送的第五指令；
278.第七提示模块，用于根据第五指令，通过所示支付小程序，提示用户从m个支付账户中确定目标支付账户，目标支付账户为确定查询与应用账户建立授权关系的支付账户；
279.发送模块1202还用于，向资源支付服务端发送用户确定的目标支付账户，以便资源支付服务端反馈主体应用程序的应用账户与目标支付账户是否建立授权关系的查询反馈结果。
280.在再一种或者多种可选的实施例中，接收模块1201还用于，接收资源支付服务端发送的异常指令，异常指令用于表示支付账户的账户状态和/或与支付账户绑定的资源卡的状态为预设异常状态；
281.发送模块1202还用于，根据异常指令，向资源管理服务端发送第二资源转移请求，第二资源转移请求包括支付订单，支付订单包括应用账户绑定的第二资源卡、支付订单的资源转移量、收款方账户的信息，第二资源转移请求用于请求资源管理服务端根据第二资源卡对支付订单进行处理。
282.在再一种或者多种可选的实施例中，支付小程序的所属方与主体应用程序的所属方不同。
283.基于相同的发明构思，本技术还提供了一种支付装置。具体结合图13进行详细说明。
284.图13是本技术一个实施例提供的支付装置的结构示意图。
285.在本技术一些实施例中，图13所示支付装置可以设置于如图1所示的资源支付服务端中。
286.如图13所示，该支付装置130具体可以包括：
287.接收模块1301，用于接收主体应用程序服务端发送的查询请求；
288.确定模块1302，用于根据查询请求，确定应用账户与支付账户是否建立授权关系
的查询反馈结果，应用账户为与主体应用程序服务端对应的主体应用程序的账户，支付账户为资源支付服务端对应的支付小程序的账户，支付小程序为嵌入主体应用程序中的具有支付功能的应用程序；
289.发送模块1303，用于向主体应用程序服务端发送查询反馈结果；
290.处理模块1304，用于在接收到主体应用程序发送的第一支付指令的情况下，通过支付小程序的支付账户对支付订单进行处理。
291.下面分别对本技术实施例中支付装置130进行详细说明。
292.在一种或者多种可选的实施例中，接收模块1301还可以用于，在查询反馈结果携带第一信息获取请求，查询反馈结果用于表征应用账户和支付账户未建立授权关系，第一信息获取请求用于请求与应用账户绑定的第一通信设备号的情况下，接收主体应用程序服务端发送的第一实名匹配请求，第一实名匹配请求包括与应用账户绑定的第一通信设备号；
293.确定模块1302还可以用于，在获取到与支付账户绑定的第二通信设备号的情况下，根据第一实名匹配请求，确定第一通信设备号和第二通信设备号是否匹配；
294.发送模块1303还可以用于，在确定第一通信设备号和第二通信设备号匹配的情况下，向主体应用程序服务端发送第二实名匹配请求，第二实名匹配请求包括第一匹配结果和与支付账户绑定的第一用户身份凭证，第一匹配结果用于表示第一通信设备号和支付账户绑定的第二通信设备号匹配，第二实名匹配请求用于请求主体应用程序服务端确定第一用户身份凭证是否与应用账户关联。
295.在另一种或者多种可选的实施例中，本技术实施例中的支付装置130还可以包括第一建立模块；其中，
296.接收模块1301还可以用于，接收主体应用程序服务端发送的建立通知；
297.第一建立模块，用于根据建立通知，建立应用账户和支付账户的授权关系。
298.在又一种或者多种可选的实施例中，发送模块1303还可以用于，在确定第一通信设备号和第二通信设备号不匹配的情况下，向主体应用程序服务端发送第一指令，第一指令用于指示主体应用程序通过支付小程序提示用户输入用户身份凭证。
299.在再一种或者多种可选的实施例中，确定模块1302还可以用于，确定支付账户是否实名认证；
300.确定模块1302还可以用于，在确定支付账户已实名认证的情况下，将与支付账户已实名认证的用户身份凭证确定为第一用户身份凭证。
301.在再一种或者多种可选的实施例中，发送模块1303还可以用于，在确定支付账户未实名认证的情况下，向主体应用程序服务端发送第二指令，第二指令用于指示主体应用程序通过支付小程序提示用户输入用户身份凭证，并根据用户输入的目标用户身份凭证确定是否建立应用账户和支付账户的授权关系。
302.在再一种或者多种可选的实施例中，发送模块1303还可以用于，在获取到与支付账户未绑定的第二通信设备号的情况下，向主体应用程序服务端发送第三指令，第三指令用于指示主体应用程序通过支付小程序提示用户输入用户通信设备号；
303.接收模块1301还可以用于，接收主体应用程序服务端发送的用户通信设备通知，用户通信设备通知包括用户输入的目标用户通信设备号；
304.确定模块1302还可以用于，将目标用户通信设备号确定为第二通信设备号。
305.在再一种或者多种可选的实施例中，发送模块1303还可以用于，在确定支付小程序的支付账户未绑定资源卡的情况下，向主体应用程序服务端发送第四指令，第四指令用于指示主体应用程序服务端通过支付小程序，提示用户为支付账户绑定资源卡；
306.发送模块1303还可以用于，在接收到主体应用程序服务端发送的第一资源卡的信息的情况下，向资源管理服务端发送绑卡请求，绑卡请求包括第一资源卡的信息、授权码、授权接口凭证、用户身份标识和用户授权信息，绑卡请求用于请求资源管理服务端根据授权码、授权接口凭证、用户身份标识和用户授权信息，将支付账户和第一资源卡进行绑定；
307.发送模块1303还可以用于，在接收到资源管理服务端发送的完成绑定结果的情况下，向资源管理服务端发送第三资源转移请求，第三资源转移请求包括支付订单，支付订单包括第一资源卡、支付订单的资源转移量、收款方账户的信息，第三资源转移请求用于请求资源管理服务端根据第一资源卡对支付订单进行处理。
308.在再一种或者多种可选的实施例中，发送模块1303还用于，在支付小程序的支付账户为m个支付账户，m为大于1的整数的情况下，向主体应用程序服务端发送第五指令，第五指令用于指示主体应用程序服务端通过所示支付小程序，提示用户从m个支付账户中确定目标支付账户；
309.确定模块1302还可以用于，在接收到主体应用程序服务端发送的用户确定的目标支付账户的情况下，确定应用账户与目标支付账户是否建立授权关系的查询反馈结果。
310.在再一种或者多种可选的实施例中，发送模块1303具体可以用于，在接收到主体应用程序发送的第一支付指令的情况下，向资源管理服务端发送第一资源转移请求，第一资源转移请求包括支付订单，支付订单包括支付账户绑定的第一资源卡、支付订单的资源转移量和收款方账户的信息，第一资源转移请求用于请求资源管理服务端根据第一资源卡对支付订单进行处理。
311.基于相同的发明构思，本技术还提供了一种支付装置。具体结合图14进行详细说明。
312.图14是本技术一个实施例提供的支付装置的结构示意图。
313.在本技术一些实施例中，图14所示支付装置可以设置于如图1所示的电子设备中。
314.如图14所示，该支付装置140具体可以包括：
315.显示模块1401，用于显示主体应用程序中商户小程序的第一界面；
316.显示模块1401还用于，在接收到对第一界面的第一输入的情况下，从第一界面切换显示为第二界面，其中，第一输入为确认在商户小程序中提交支付订单的输入，第二界面为支付小程序对支付订单进行处理的界面，支付小程序为嵌入主体应用程序中的具有支付功能的应用程序；
317.显示模块1401还用于，在确定主体应用程序的应用账户与支付小程序的支付账户已建立授权关系的情况下，显示支付小程序对支付订单处理后的支付结果。
318.基于相同的发明构思，本技术还提供了一种支付装置。具体结合图15进行详细说明。
319.图15是本技术一个实施例提供的支付装置的结构示意图。
320.在本技术一些实施例中，图15所示支付装置可以设置于如图1所示的电子设备中。
321.如图15所示，该支付装置150具体可以包括：
322.显示模块1501，用于显示主体应用程序的第三界面，第三界面包括n个支付方，n为大于1的整数；
323.显示模块1501还用于，在接收到用户对n个支付方中目标支付方的第三输入的情况下，从第三界面切换显示为第四界面，第四界面为目标支付方对应的支付小程序的支付界面，支付小程序为嵌入主体应用程序中的具有支付功能的应用程序，支付界面包括支付小程序提供的付款码；
324.显示模块1501还用于，在确定主体应用程序的应用账户与支付小程序的支付账户已建立授权关系的情况下，显示第五界面，第五界面包括支付小程序对支付订单处理后的支付结果；支付小程序的所属方与主体应用程序的所属方不同。
325.由此，主体应用程序服务端可以根据主体应用程序中商户小程序的支付订单，向与支付小程序对应的资源支付服务端发送查询请求，查询请求用于请求资源支付服务端确定主体应用程序的应用账户与支付小程序的支付账户是否建立授权关系，支付小程序为嵌入主体应用程序中的具有支付功能的应用程序；接着，在接收到资源支付服务端发送的表征应用账户和支付账户已建立授权关系的查询反馈结果时，可以向资源支付服务端发送第一支付指令，第一支付指令用于指示支付小程序对支付订单进行处理，由此，该支付方式可以通过除主体应用程序所属方提供的支付控件之外的支付方式，支付商户小程序中的订单，增加付款途径，提高支付效率，并且，在主体应用程序中的支付小程序支付商户小程序的订单，无需跳转到主体应用程序外的页面如html5页面，也无需跳转到第三方支付应用以完成支付，减少了用户触发启动第三方应用程序以及返回主体应用程序的操作，提高了用户支付的便捷性。
326.基于相同的发明构思，本技术还提供了一种支付设备。具体结合图16进行详细说明。
327.图16是本技术一个实施例提供的支付设备的结构示意图。
328.如图16所示，该支付设备可以包括本技术实施例中涉及的下述中的至少一种：电子设备、服务器。其中，该支付设备可以包括处理器1601以及存储有计算机程序指令的存储器1602。
329.具体地，上述处理器1601可以包括中央处理器(cpu)，或者特定集成电路(application specific integrated circuit，asic)，或者可以被配置成实施本技术实施例的一个或多个集成电路。
330.存储器1602可以包括用于数据或指令的大容量存储器。举例来说而非限制，存储器1602可包括硬盘驱动器(hard disk drive，hdd)、软盘驱动器、闪存、光盘、磁光盘、磁带或通用串行总线(universal serial bus，usb)驱动器或者两个或更多个以上这些的组合。在合适的情况下，存储器1602可包括可移除或不可移除(或固定)的介质。在合适的情况下，存储器1602可在综合网关容灾设备的内部或外部。在特定实施例中，存储器1602是非易失性固态存储器。在特定实施例中，存储器1602包括固态存储(rom)。在合适的情况下，该rom可以是掩模编程的rom、可编程rom(prom)、可擦除prom(eprom)、电可擦除prom(eeprom)、电可改写rom(earom)或闪存或者两个或更多个以上这些的组合。
331.处理器1601通过读取并执行存储器1602中存储的计算机程序指令，以实现上述实
施例中的任意一种支付方法。
332.在一个示例中，支付设备还可包括通信接口1603和总线1610。其中，如图16所示，处理器1601、存储器1602、通信接口1603通过总线1610连接并完成相互间的通信。
333.通信接口1603，主要用于实现本技术实施例中各模块、装置、单元和/或设备之间的通信。
334.总线1610包括硬件、软件或两者，将流量控制设备的部件彼此耦接在一起。举例来说而非限制，总线可包括加速图形端口(agp)或其他图形总线、增强工业标准架构(eisa)总线、前端总线(fsb)、超传输(ht)互连、工业标准架构(isa)总线、无限带宽互连、低引脚数(lpc)总线、存储器总线、微信道架构(mca)总线、外围组件互连(pci)总线、pci-express(pci-x)总线、串行高级技术附件(sata)总线、视频电子标准协会局部(vlb)总线或其他合适的总线或者两个或更多个以上这些的组合。在合适的情况下，总线1610可包括一个或多个总线。尽管本技术实施例描述和示出了特定的总线，但本技术考虑任何合适的总线或互连。
335.该数据处理设备可以执行本技术实施例中的支付方法，从而实现结合图1至图11描述的支付方法和装置。
336.另外，结合上述实施例中的支付方法，本技术实施例可提供一种计算机可读存储介质来实现。该计算机可读存储介质上存储有计算机程序指令；该计算机程序指令被处理器执行时实现上述实施例中的任意一种支付方法。
337.需要明确的是，本技术并不局限于上文所描述并在图中示出的特定配置和处理。为了简明起见，这里省略了对已知方法的详细描述。在上述实施例中，描述和示出了若干具体的步骤作为示例。但是，本技术的方法过程并不限于所描述和示出的具体步骤，本领域的技术人员可以在领会本技术的精神后，作出各种改变、修改和添加，或者改变步骤之间的顺序。
338.以上的结构框图中所示的功能块可以实现为硬件、软件、固件或者它们的组合。当以硬件方式实现时，其可以例如是电子电路、专用集成电路(asic)、适当的固件、插件、功能卡等等。当以软件方式实现时，本技术的元素是被用于执行所需任务的程序或者代码段。程序或者代码段可以存储在机器可读介质中，或者通过载波中携带的数据信号在传输介质或者通信链路上传送。“机器可读介质”可以包括能够存储或传输信息的任何介质。机器可读介质的例子包括电子电路、半导体存储器设备、rom、闪存、可擦除rom(erom)、软盘、cd-rom、光盘、硬盘、光纤介质、射频(rf)链路，等等。代码段可以经由诸如因特网、内联网等的计算机网络被下载。
339.还需要说明的是，本技术中提及的示例性实施例，基于一系列的步骤或者装置描述一些方法或系统。但是，本技术不局限于上述步骤的顺序，也就是说，可以按照实施例中提及的顺序执行步骤，也可以不同于实施例中的顺序，或者若干步骤同时执行。
340.以上，仅为本技术的具体实施方式，所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，上述描述的系统、模块和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。应理解，本技术的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本技术揭露的技术范围内，可轻易想到各种等效的修改或替换，这些修改或替换都应涵盖在本技术的保护范围之内。