支付方法、终端设备、服务器、系统及介质与流程

1.本技术属于数据处理领域，尤其涉及一种支付方法、终端设备、服务器、系统及介质。


背景技术：

2.随着支付技术的发展，电子支付的应用越来越广泛。用户可通过终端设备实现支付。终端设备中安装有应用程序和软件开发工具包(software development kit，sdk)，sdk可集成在应用程序中，共同实现支付。
3.支付过程在终端设备中涉及应用程序和sdk两个主体，支付过程涉及的主体增多，支付存在的安全风险也随之增大。因此，亟需一种能够提高安全性的支付方法。


技术实现要素：

4.本技术实施例提供一种支付方法、终端设备、服务器、系统及介质，能够提高支付的安全性。
5.第一方面，本技术实施例提供一种支付方法，应用于软件开发工具包sdk服务器，方法包括：响应于接收的支付请求消息，向安全控制系统发送安全验证请求消息，安全验证请求消息包括安全验证信息，用于指示安全控制系统根据安全验证信息对支付请求消息对应的支付进行安全验证；接收安全控制系统发送的安全验证结果信息；在安全验证结果信息表征安全验证通过的情况下，向终端设备中的sdk发送第一通知消息，终端设备具有sdk和宿主程序，第一通知消息用于指示sdk通知宿主程序展示用户验证页面，以提示用户输入第一用户验证输入信息，第一用户验证输入信息用于宿主程序服务器进行用户验证以得到用户验证结果信息；在用户验证结果信息表征用户验证通过的情况下，发起付款请求，以完成支付。
6.第二方面，本技术实施例提供一种支付方法，应用于终端设备，终端设备具有软件开发工具包sdk和宿主程序，方法包括：通过sdk获取sdk服务器发送的第一通知消息，第一通知消息是sdk服务器基于表征安全验证通过的安全验证结果信息发送的，安全验证结果信息是安全控制系统基于安全验证请求消息中的安全验证信息对支付请求消息对应的支付进行安全验证得到的，安全验证请求消息由sdk服务器响应于接收的支付请求消息发送；响应于第一通知消息，通过sdk通知宿主程序展示用户验证页面，以提示用户输入第一用户验证输入信息；通过宿主程序向宿主程序服务器反馈第一用户验证输入信息，第一用户验证输入信息用于宿主程序服务器进行用户验证以得到用户验证结果信息；通过sdk向sdk服务器发送通过宿主程序从宿主程序服务器获取的用户验证结果信息，使sdk服务器在用户验证结果信息表征用户验证通过的情况下，发起付款请求，以完成支付。
7.第三方面，本技术实施例提供一种支付方法，应用于宿主程序服务器，方法包括：接收终端设备通过宿主程序反馈的第一用户验证输入信息，终端设备具有软件开发工具包sdk和宿主程序，第一用户验证输入信息在sdk响应于第一通知消息通知宿主程序展示用户
验证页面后得到，第一通知消息是sdk服务器基于表征安全验证通过的安全验证结果信息发送的，安全验证结果信息是安全控制系统基于安全验证请求消息中的安全验证信息对支付请求消息对应支付进行安全验证得到的，安全验证请求消息由sdk服务器响应于接收的支付请求消息发送；根据第一用户验证输入信息进行用户验证，得到用户验证结果信息；向终端设备中的宿主程序发送用户验证结果信息，通过宿主程序将用户验证结果信息传输给sdk，以使sdk向sdk服务器发送用户验证结果信息，在用户验证结果信息表征用户验证通过的情况下，使sdk服务器发起付款请求，以完成支付。
8.第四方面，本技术实施例提供一种sdk服务器，包括：发送模块，用于响应于接收的支付请求消息，向安全控制系统发送安全验证请求消息，安全验证请求消息包括安全验证信息，用于指示安全控制系统根据安全验证信息对支付请求消息对应的支付进行安全验证；接收模块，用于接收安全控制系统发送的安全验证结果信息；发送模块还用于在安全验证结果信息表征安全验证通过的情况下，向终端设备中的sdk发送第一通知消息，终端设备具有sdk和宿主程序，第一通知消息用于指示sdk通知宿主程序展示用户验证页面，以提示用户输入第一用户验证输入信息，第一用户验证输入信息用于宿主程序服务器进行用户验证以得到用户验证结果信息；发送模块还用于在用户验证结果信息表征用户验证通过的情况下，发起付款请求，以完成支付。
9.第五方面，本技术实施例提供一种终端设备，终端设备具有软件开发工具包sdk和宿主程序，终端设备包括：接收模块，用于通过sdk获取sdk服务器发送的第一通知消息，第一通知消息是sdk服务器基于表征安全验证通过的安全验证结果信息发送的，安全验证结果信息是安全控制系统基于安全验证请求消息中的安全验证信息对支付请求消息对应的支付进行安全验证得到的，安全验证请求消息由sdk服务器响应于接收的支付请求消息发送；显示模块，用于响应于第一通知消息，通过sdk通知宿主程序展示用户验证页面，以提示用户输入第一用户验证输入信息；发送模块，用于通过宿主程序向宿主程序服务器反馈第一用户验证输入信息，第一用户验证输入信息用于宿主程序服务器进行用户验证以得到用户验证结果信息；发送模块还用于通过sdk向sdk服务器发送通过宿主程序从宿主程序服务器获取的用户验证结果信息，使sdk服务器在用户验证结果信息表征用户验证通过的情况下，发起付款请求，以完成支付。
10.第六方面，本技术实施例提供一种宿主程序服务器，包括：接收模块，用于接收终端设备通过宿主程序反馈的第一用户验证输入信息，终端设备具有软件开发工具包sdk和宿主程序，第一用户验证输入信息在sdk响应于第一通知消息通知宿主程序展示用户验证页面后得到，第一通知消息是sdk服务器基于表征安全验证通过的安全验证结果信息发送的，安全验证结果信息是安全控制系统基于安全验证请求消息中的安全验证信息对支付请求消息对应支付进行安全验证得到的，安全验证请求消息由sdk服务器响应于接收的支付请求消息发送；验证模块，用于根据第一用户验证输入信息进行用户验证，得到用户验证结果信息；发送模块，用于向终端设备中的宿主程序发送用户验证结果信息，通过宿主程序将用户验证结果信息传输给sdk，以使sdk向sdk服务器发送用户验证结果信息，在用户验证结果信息表征用户验证通过的情况下，使sdk服务器发起付款请求，以完成支付。
11.第七方面，本技术实施例提供一种sdk服务器，包括：处理器以及存储有计算机程序指令的存储器；处理器执行计算机程序指令时实现第一方面的支付方法。
12.第八方面，本技术实施例提供一种终端设备，包括：处理器以及存储有计算机程序指令的存储器；处理器执行计算机程序指令时实现第二方面的支付方法。
13.第九方面，本技术实施例提供一种宿主程序服务器，包括：处理器以及存储有计算机程序指令的存储器；处理器执行计算机程序指令时实现第一方面的支付方法。
14.第十方面，本技术实施例提供一种支付系统，包括第七方面的sdk服务器、第八方面的终端设备和第九方面的宿主程序服务器。
15.第十一方面，本技术实施例提供一种计算机可读存储介质，计算机可读存储介质上存储有计算机程序指令，计算机程序指令被处理器执行时实现第一方面的支付方法、第二方面的支付方法、第三方面的支付方法。
16.申请实施例提供一种支付方法、终端设备、服务器、系统及介质，sdk服务器响应于支付请求消息，向安全控制系统发送安全验证请求消息，以请求安全控制系统对本次支付进行安全验证，以完成sdk所属方所需的安全性方面的验证。在安全验证通过的情况下，sdk服务器向终端设备的sdk发送用于指示sdk通知宿主程序展示用户验证页面的消息，以使sdk能够触发宿主程序主动发起用户验证，以完成宿主程序所属方所需的用户身份安全性方面的验证。在支付过程中实现了sdk所属方和宿主程序所属方两个主体的双向验证，提高了支付的安全性。
附图说明
17.为了更清楚地说明本技术实施例的技术方案，下面将对本技术实施例中所需要使用的附图作简单的介绍，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
18.图1为本技术实施例提供的支付方法的应用场景的一示例的示意图；
19.图2为本技术第一方面提供的支付方法的一实施例的流程图；
20.图3为本技术第一方面提供的支付方法的另一实施例的流程图；
21.图4为本技术第一方面提供的支付方法的又一实施例的流程图；
22.图5为本技术第一方面提供的支付方法的又另一实施例的流程图；
23.图6为本技术第一方面提供的支付方法的再一实施例的流程图；
24.图7为本技术第二方面提供的支付方法的一实施例的流程图；
25.图8为本技术第二方面提供的支付方法的另一实施例的流程图；
26.图9为本技术第二方面提供的支付方法的又一实施例的流程图；
27.图10为本技术第二方面提供的支付方法的又另一实施例的流程图；
28.图11为本技术第二方面提供的支付方法的再一实施例的流程图；
29.图12为本技术第三方面提供的支付方法的一实施例的流程图；
30.图13为本技术第三方面提供的支付方法的另一实施例的流程图；
31.图14为本技术实施例提供的支付流程的一示例的流程图；
32.图15为本技术实施例提供的支付流程的另一示例的流程图；
33.图16为本技术实施例提供的支付流程的又一示例的流程图；
34.图17为本技术第四方面提供的sdk服务器的一实施例的结构示意图；
35.图18为第五方面提供的终端设备的一实施例的结构示意图；
36.图19为第六方面提供的宿主程序服务器的一实施例的结构示意图；
37.图20为本技术第七方面提供的sdk服务器的一实施例的结构示意图。
具体实施方式
38.下面将详细描述本技术的各个方面的特征和示例性实施例，为了使本技术的目的、技术方案及优点更加清楚明白，以下结合附图及具体实施例，对本技术进行进一步详细描述。应理解，此处所描述的具体实施例仅意在解释本技术，而不是限定本技术。对于本领域技术人员来说，本技术可以在不需要这些具体细节中的一些细节的情况下实施。下面对实施例的描述仅仅是为了通过示出本技术的示例来提供对本技术更好的理解。
39.随着支付技术的发展，电子支付的应用越来越广泛。用户可通过终端设备实现支付。终端设备中安装有用于支付的应用程序，但应用程序的功能有限，为了使得支付功能更加完善，终端设备中还可设置sdk，sdk可集成在应用程序中，和应用程序共同实现支付。在这种情况下，支付过程在终端设备中会涉及应用程序和sdk两个主体，支付过程涉及的主体增多，支付存在的安全风险也随之增大。因此，亟需一种能够提高安全性的支付方法。
40.本技术实施例提供一种支付方法、终端设备、服务器、系统及介质，能够分别以sdk和宿主程序为主体，进行双重验证，在sdk为主体的验证和宿主程序为主体的验证均通过的情况下，完成支付。通过sdk和宿主程序两方面的验证来保证sdk相关交互和宿主程序相关交互的安全性，从而提高整个支付过程的安全性。
41.本技术提供的支付方法应用于支付场景中，主要可涉及终端设备、sdk后台系统、宿主程序后台系统和安全控制系统。图1为本技术实施例提供的支付方法的应用场景的一示例的示意图。如图1所示，终端设备11可分别与sdk后台系统12、宿主程序后台系统13进行通信交互，sdk后台系统12还可分别与宿主程序后台系统13、安全控制系统14进行通信交互。
42.终端设备11具有宿主程序和sdk。终端设备11的支付功能需要宿主程序调用sdk共同实现。终端设备11中的sdk与宿主程序之间可交互。终端设备11中的sdk可与sdk后台系统12通信交互，终端设备11中的宿主程序可与宿主程序后台系统13通信交互。终端设备11为用户用于进行支付的设备，具体可包括手机、平板电脑、电子计算机、只能穿戴设备等，在此并不限定。
43.sdk后台系统12为sdk的后台系统，可包括一台以上的sdk服务器，在此并不限定sdk后台系统12中sdk服务器的种类和数量。终端设备11在支付过程中，会通过sdk将支付相关的信息发送给sdk后台系统。sdk后台系统也可预先存储支付的用户的账户信息及个人信息等。
44.在一些实施例中，sdk后台系统12可包括sdk后台子系统和支付码子系统，sdk后台子系统与支付码子系统之间可通信交互，sdk后台子系统还可与终端设备11中的sdk通信交互，支付码子系统可与宿主程序后台系统通信交互。支付码子系统存储有支付码的相关信息，可对支付码进行管理和验证。支付码可包括收款码、付款码等，支付码具体可为二维码或其他形式的图形码，在此并不限定。
45.宿主程序后台系统13为宿主程序的后台系统，可包括一台以上的宿主程序服务器，在此并不限定宿主程序后台系统13中宿主程序服务器的种类和数量。终端设备11在支
付过程中，会通过宿主程序与宿主程序后台系统13交互。宿主程序后台系统13还可与sdk后台系统12通信交互。
46.安全控制系统14可用于对支付进行安全验证，可包括一台以上的电子设备，在此并不限定安全控制系统14中电子设备的种类和数量。安全控制系统14可与sdk后台系统12通信交互。在sdk后台系统12包括sdk后台子系统和支付码子系统的情况下，安全控制系统14可与其中的sdk后台子系统通信交互。
47.在一些实施例中，终端设备11中sdk和宿主程序之间的信息传输为加密传输，即终端设备11中sdk和宿主程序之间交互的信息为加密信息。sdk和宿主程序中各自存储有加、解密所需的加、解密算法，sdk和宿主程序中的加、解密算法可根据应用环境、需求等设定，例如，sdk和宿主程序中的加、解密算法可包括sm2算法、sm4算法、数据加密标准(data encryption standard，des)、rsa算法等，在此并不限定。sdk中加、解密算法所需的密钥可由sdk后台系统12存储和管理，即sdk中加、解密的密钥可存储于sdk后台系统12中的sdk服务器，sdk可通过与sdk后台系统12进行交互以实现加、解密。宿主程序中加、解密算法所需的密钥可由宿主程序后台系统13存储和管理，即宿主程序中加、解密的密钥存储于宿主程序后台系统13中的宿主程序服务器，宿主程序可通过与宿主程序后台系统13进行交互以实现加、解密。通过sdk与宿主程序之间的密文传输，sdk与宿主程序之间传输的信息不容易被窃取，可保证sdk与宿主程序之间的通信安全。
48.在一些实施例中，终端设备11中sdk可具有安全域，sdk中的信息可存储于安全域。安全域可为加密的数据存储空间，具体可通过硬件和/或软件实现，如通过安全元件(secure element，se)和/或可信执行环境(trusted execution environment，tee)等实现。sdk可对安全域的权限进行管理，如划分不可开放读取的数据和仅有宿主程序有权限读取的数据等。
49.下面对本技术中的支付方法、终端设备、服务器、系统及介质依次进行说明。
50.本技术第一方面提供一种支付方法，该支付方法应用于sdk服务器，即该支付方法可由sdk服务器执行。图2为本技术第一方面提供的支付方法的一实施例的流程图。如图2所示，该支付方法可包括步骤s201至步骤s204。
51.在步骤s201中，响应于接收的支付请求消息，向安全控制系统发送安全验证请求消息。
52.支付请求消息用于发起支付。支付请求消息可由终端设备中的sdk向sdk服务器发送，或者，支付请求消息可由支付受理设备向sdk服务器发送。在sdk后台系统包括sdk后台子系统和支付码子系统的情况下，可由支付受理设备向支付码子系统中的sdk服务器发起支付，支付码子系统中的sdk服务器再向sdk后台子系统中的sdk服务器发送支付请求消息。支付请求消息可包括订单信息、终端设备信息、支付信息等。订单信息可包括订单标识、订单发起方、订单明细、订单金额、订单时间等与订单关联的信息，在此并不限定。终端设备信息可包括对进行本次支付的终端设备的地理位置、设备标识等与终端设备关联的信息，在此并不限定。支付信息可包括支付付款方信息、支付收款方信息、支付金额、支付时间等与支付相关的信息，在此并不限定。支付收款方信息可包括商户名称、商户账户等信息，支付付款方信息可包括支付方账户、支付方支付卡信息、支付方标识等信息，在此并不限定。
53.安全验证请求消息包括安全验证信息。安全验证请求消息用于指示安全控制系统
根据安全验证信息对支付请求消息对应的支付进行安全验证。安全验证信息可包括终端设备中sdk向sdk服务器发送的至少部分信息，安全验证信息还可包括sdk服务器中预存的与支付请求消息指示的支付付款方信息等，在此并不限定。例如，安全验证信息可包括支付卡卡号、支付方登录账号、支付方登录账号关联的手机号、支付卡关联的手机号、终端设备标识、终端设备的地理位置、支付金额、支付时间、支付卡的历史支付信息等信息中的一项或两项以上，安全验证信息还可包括其他能够进行安全性方面验证的信息，在此并不限定。
54.在一些示例中，在安全验证请求消息包括支付卡卡号的情况下，该支付卡卡号可以为终端设备中sdk提供的默认支付卡卡号，若用户在终端设备切换默认支付卡即默认支付卡卡号发生变化的情况下，sdk会向sdk服务器发送包括新的默认支付卡卡号的消息，sdk服务器会被触发向安全控制系统再次发送包括新的默认支付卡卡号的安全验证请求消息。也就是说，若用户在终端设备显示的付款详情页切换默认支付卡，对应地，sdk服务器会重新向安全控制系统发送包括切换后的默认支付卡卡号的安全验证请求消息。
55.安全控制系统接收到安全验证请求消息，根据安全验证请求消息中的安全验证信息进行安全验证。安全验证可对支付的合法性以及支付的终端设备的登录状态的安全性进行验证，具体可通过安全验证信息是否满足预定的安全判定条件，来确定安全验证是否通过。安全判定条件可根据具体场景、需求等设定，在此并不限定。例如，安全验证信息包括本次支付的终端设备标识和支付卡的历史支付信息，支付卡的历史支付信息包括支付卡的历史支付中的终端设备标识，若本次支付的终端设备标识和支付卡的历史支付中的终端设备标识一致，则安全验证通过；反之，安全验证未通过。又例如，安全验证信息包括本次支付的终端设备的地理位置、支付时间和支付卡的历史支付信息，支付卡的历史支付信息包括支付卡最近一次支付的终端设备的地理位置和支付时间，若支付卡最近一吃支付的支付时间与本次支付的支付时间之间的时长小于预设时长，且支付卡最近一次支付的终端设备的地理位置与本次支付的终端设备的地理位置之间的距离大于预设距离，则安全验证未通过；反之，安全验证通过。还例如，安全验证信息包括支付方登录账号关联的手机号和支付卡关联的手机号，若支付方登录账号关联的手机号与支付卡关联的手机号一致，则安全验证通过；反之，则安全验证未通过。
56.在一些示例中，在安全风险度非常高的情况下，如账户余额不足、支付为非法支付等情况，才判定安全验证未通过。在安全风险度中、低，能够通过后续的用户验证来判断支付的安全的情况下，可判定安全验证通过。例如，安全验证信息包括本次支付的终端设备标识和支付卡的历史支付信息，支付卡的历史支付信息包括支付卡的历史支付中的终端设备标识，由于用户存在更换终端设备的可能性，若本次支付的终端设备标识和支付卡的历史支付中的终端设备标识不一致，也可视为安全验证通过，在后续过程中可通过用户验证判断是否为用户本人使用更换的终端设备进行支付。又例如，安全验证信息包括本次支付的支付金额和支付方账户余额，若本次支付的支付金额小于等于支付方账户余额，则安全验证通过；反之，安全验证未通过。
57.在一些示例中，sdk在接收到支付请求消息的情况下，若检测到当前登录的用户账号并未关联支付卡，可发出绑卡提示信息，以提示用户进入绑卡流程以绑定支付卡。在绑定支付卡后，sdk再向安全控制系统发送安全验证请求消息。
58.在步骤s202中，接收安全控制系统发送的安全验证结果信息。
59.安全控制系统根据安全验证信息进行安全验证，可得到对于本次支付即支付请求消息指示的支付的安全验证结果信息。安全验证结果信息用于表征安全验证是否通过。若安全验证结果信息表征安全验证未通过，sdk服务器可向终端设备中的sdk发送指示消息，以使sdk发出中止支付的弹窗信息。
60.在一些示例中，在sdk服务器接收到表征安全验证通过的安全验证结果信息后，终端设备中的sdk可调用预设的查询接口，将本次支付的如付款方信息等支付信息、订单号等订单信息等传输至sdk服务器，sdk服务器可进一步补充本次支付的如商户号等其他订单信息以及与付款相关的其他支付信息等，将支付信息、订单信息同步至宿主程序服务器，以实现sdk服务器与宿主程序服务器关于本次支付的信息的同步。
61.在一些示例中，在sdk后台系统包括sdk后台子系统和支付码子系统的情况下，在sdk后台子系统中的sdk服务器接收到表征安全验证通过的安全验证结果信息后，sdk后台子系统中的sdk服务器可可调用预设的查询接口，将本次支付的如付款方信息等支付信息、订单号等订单信息等传输至支付码子系统的sdk服务器，支付码子系统的sdk服务器可进一步补充本次支付的如商户号等其他订单信息以及与付款相关的其他支付信息等，将支付信息、订单信息同步至宿主程序服务器，以实现sdk后台系统中的sdk服务器与宿主程序服务器关于本次支付的信息的同步。
62.在步骤s203中，在安全验证结果信息表征安全验证通过的情况下，向终端设备中的sdk发送第一通知消息。
63.安全验证结果信息表征安全验证通过，则可再进行宿主程序的所属方的用户验证流程。第一通知消息用于指示sdk通知宿主程序展示用户验证页面，以提示用户输入第一用户验证输入信息。第一用户验证输入信息用于宿主程序服务器进行用户验证以得到用户验证结果信息。
64.终端设备中的sdk响应于第一通知消息，可向宿主程序发送用于指示宿主程序展示用户验证页面的消息。宿主程序响应于该消息，宿主程序使终端设备显示用户验证页面。用户验证页面可包括密码填写区、验证码填写区、生物特征采集区等，在此并不限定用户验证的方式。用户向用户验证页面输入的信息即为第一用户验证输入信息。宿主程序可向宿主程序服务器发送第一用户验证输入信息。宿主程序服务器可根据接收到的第一用户验证输入信息进行用户验证，并得到用户验证结果信息。用户验证用于验证用户的身份。用户验证通过表示进行支付操作的用户是合法的用户本人。例如，第一用户验证输入信息为密码，宿主程序服务器验证第一用户验证输入信息与宿主程序服务器中用户注册的密码是否一致，若一致，则用户验证通过；反之，则用户验证未通过。又例如，第一用户验证输入信息为人脸图像，宿主程序服务器验证第一用户验证输入信息与宿主程序服务器中用户预留的人脸图像是否属于同一用户，若属于同一用户，则用户验证通过；反之，则用户验证未通过。
65.用户验证结果信息用于表征用户验证是否通过。宿主程序服务器可将用户验证结果信息分别向宿主程序和sdk服务器反馈，宿主程序还会将用户验证结果传输给sdk，以使sdk的所属方和宿主程序的所属方均可得知用户验证是否通过。
66.在一些示例中，在宿主程序展示用户验证页面时，sdk可添加与展示用户验证页面这一动作关联的埋点信息，以便后续对宿主程序展示用户验证页面这一过程的执行情况的分析和排查。
67.在步骤s204中，在用户验证结果信息表征用户验证通过的情况下，发起付款请求，以完成支付。
68.用户验证结果信息表征用户验证通过，表示用户身份安全性较高，可向支付方账户管理系统发起付款请求，正常进行支付。用户验证结果信息表征用户验证未通过，可中止该支付。
69.在一些实施例中，由于用户验证结果信息在传输过程中可能被窃取或篡改，为了进一步保证支付安全，可通过一致性验证条件来对用户验证结果信息在传输过程中的安全性进行验证。在用户验证结果信息满足一致性验证条件的情况下，发起所述付款请求。一致性验证条件用于判断用户验证结果信息在传输过程中是否安全、有效。用户验证结果信息满足一致性验证条件，表示用户验证结果信息在传输过程中是安全、有效的，可向支付方账户管理系统发起付款请求，正常进行支付，或者，由sdk服务器通过宿主程序服务器向支付方账户管理系统发起付款请求，正常进行支付；用户验证结果信息不满足一致性验证条件，表示用户验证结果信息在传输过程中并不安全、有效，可中止该支付。
70.在一些示例中，一致性验证条件可包括第一用户验证结果信息和第二用户验证结果信息一致。其中，第一用户验证结果信息为由宿主程序服务器通过宿主程序传输给sdk的用户验证结果信息。第二用户验证结果信息为从宿主程序服务器获取的用户验证结果信息。第一用户验证结果信息和第二用户验证结果信息一致，表示用户验证结果信息在传输过程中是安全、有效的；第一用户验证结果信息和第二用户验证结果信息不一致，表示用户验证结果信息在传输过程中并不安全、有效。
71.支付成功后，sdk服务器可获取付款结果信息，付款结果信息表征付款是否成功。sdk服务器可将付款结果信息传输给sdk、商户系统等，以将付款是否成功的结果展示给用户、商户等。
72.在上述支付过程中，用户验证通过后，由于用户验证结果信息的传输、付款、以及付款结果信息的传输都需要一定时间，终端设备不会立即显示支付完成页面，在这种情况下，sdk可控制终端设备显示付款中标识，如包含“loading”字样的图像，在终端设备显示支付完成页面时，停止显示付款中标识。
73.在本技术实施例中，sdk服务器响应于支付请求消息，向安全控制系统发送安全验证请求消息，以请求安全控制系统对本次支付进行安全验证，以完成sdk所属方所需的安全性方面的验证。在安全验证通过的情况下，sdk服务器向终端设备的sdk发送用于指示sdk通知宿主程序展示用户验证页面的消息，以使sdk能够触发宿主程序主动发起用户验证，以完成宿主程序所属方所需的用户身份安全性方面的验证。在支付过程中实现了sdk所属方和宿主程序所属方两个主体的双向验证，提高了支付的安全性，也满足了sdk所属方和宿主程序所属方两个主体对安全性管控的需求。
74.在一些示例中，在sdk服务器通过宿主程序服务器向支付方账户管理系统发起付款请求的情况下，sdk服务器可提供sdk所属方的第一支付策略信息，第一支付策略信息可包括sdk所属方的优惠信息、支付活动信息等，可用于参与支付请求消息指示的支付的金额计算。宿主程序服务器可提供宿主程序所属方的第二支付策略信息，第二支付策略信息可包括宿主程序所属方的优惠信息、支付活动信息等，可用于参与支付请求消息指示的支付的金额计算。
75.在一些实施例中，sdk服务器也可在接收支付请求消息后，直接向宿主程序服务器或通过支付策略系统向宿主程序服务器查询优惠信息、支付活动信息等支付策略信息。
76.在上述实施例中，sdk与宿主程序之间交互的信息为加密信息，sdk需要对信息进行加、解密。对应地，sdk服务器存储有用于对sdk与宿主程序之间交互的信息进行加、解密的密钥。
77.在一些实施例中，sdk服务器可向宿主程序服务器请求用户验证方式，并将宿主程序服务器的反馈传输给sdk，以使sdk做出对应的操作。图3为本技术第一方面提供的支付方法的另一实施例的流程图。图3与图2的不同之处在于，图3所示的支付方法还可包括步骤s205至步骤s208，图2中的步骤s203可具体细化为图3中的步骤s2031。
78.在步骤s205中，在安全验证结果信息表征安全验证通过的情况下，向宿主程序服务器发送用户验证方式请求消息。
79.用户验证方式请求消息用于向宿主程序服务器请求用户验证方式，可包括支付请求消息指示的支付对应的订单信息、终端设备信息、支付信息中的一项或两项以上。订单信息、终端设备信息和支付信息的具体内容可参见上述实施中的相关说明，在此不再赘述。
80.宿主程序服务器可根据用户验证方式请求消息中的信息，确定验证操作信息，验证操作信息用于指示是否进行用户验证以及用户验证的方式。宿主程序服务器可存储有用于确定是否进行用户验证以及用户验证的方式的判断条件，可通过用户验证方式请求消息中的信息是否满足参考条件来判断是否进行用户验证以及用户验证的方式。判断条件可根据支付场景、需求等设置，在此并不限定。例如，用户验证方式请求消息可包括支付信息，支付信息包括支付金额，判断条件可包括支付金额范围与是否进行用户验证以及用户验证的方式的对应关系，如判断条件包括：支付金额小于100元，不需进行用户验证；支付金额在100元至500元的范围内，需进行用户验证，且用户验证的方式为密码验证；支付金额在500元至1000元的范围内，需进行用户验证，且用户验证的方式为验证码验证；支付金额大于1000元，需进行用户验证，且用户验证的方式为生物特征验证。又例如，用户验证方式请求消息可包括订单信息和支付信息，订单信息包括订单标识和下订单用户账号，支付信息包括付款方登录账号，判断条件可包括：下订单用户账号与付款方登录账号不一致，需进行用户验证，且用户验证方式为生物特征验证；下订单用户账号与付款方登录账号一致，需进行用户验证，且用户验证方式为密码验证。
81.宿主程序服务器确定验证操作信息后，可向sdk服务器发送用户验证方式反馈消息。用户验证方式反馈消息包括验证操作信息。
82.在步骤s206中，接收宿主程序服务器发送的用户验证方式反馈消息。
83.在步骤s207中，在验证操作信息包括拒绝支付标识的情况下，向sdk发送第二通知消息。
84.拒绝支付标识表示不需进行用户验证且停止支付。响应于用户验证方式反馈信息，sdk服务器向终端设备中sdk发送第二通知信息。第二通知消息用于指示sdk发出拒绝支付提示信息。sdk响应于第二通知消息，可发出提示信息，以提示用户存在支付风险。例如，提示信息使终端设备显示“宿主程序风险受限”等文字。在一些示例中，用户验证方式反馈消息还可包括拒绝支付原因，对应地，第二通知信息也可包括该拒绝支付原因，sdk响应于第二通知信息发出的提示信息可包括该拒绝支付原因，终端设备可显示该决绝支付原因，
以告知用户。拒绝支付原因可包括sdk异常、宿主程序服务器异常等导致用户验证方式标识失败的原因。
85.在步骤s208中，在验证操作信息包括免密支付标识的情况下，向sdk发送第三通知消息。
86.免密支付标识表示不需进行用户验证且可继续支付流程。响应于用户验证方式反馈信息，sdk服务器向终端设备中sdk发送第三通知信息。第三通知消息用于指示sdk发出免密支付提示信息。免密支付提示信息可提示用户该支付为免密方式的支付。
87.在步骤s2031中，在验证操作信息包括用户验证方式标识且安全验证结果信息表征安全验证通过的情况下，向sdk发送第一通知消息。
88.第一通知消息包括用户验证方式标识。用户验证方式标识用于指示用户验证的方式。第一通知消息用于指示sdk通知宿主程序展示与用户验证方式标识匹配的用户验证页面，以提示用户输入与用户验证方式标识匹配的第一用户验证输入信息。即sdk响应于第一通知消息，可向宿主程序发送包括用户验证方式标识的指示消息，宿主程序根据用户验证方式标识，展现与用户验证方式标识指示的用户验证的方式对应的用户验证页面，对应地，用户输入的第一用户验证输入信息也与用户验证方式标识指示的用户验证的方式对应。
89.例如，用户验证方式标识为01，用户验证的方式为密码验证，宿主程序展示的用户验证页面为密码验证页面，用户需输入的第一用户验证输入信息为密码；用户验证方式标识为10，用户验证的方式为验证码验证，宿主程序展示的用户验证页面为验证码验证页面，用户需输入的第一用户验证输入信息为验证码；用户验证方式标识为11，用户验证的方式为生物特征验证，宿主程序展示的用户验证页面为生物特征验证页面，用户需输入的第一用户验证输入信息为生物特征。
90.在一些实施例中，支付请求消息、安全验证请求消息和安全验证结果信息可包括目标宿主程序标识。目标宿主程序标识包括支付请求消息对应的支付的宿主程序标识，即目标宿主程序标识可表征支付请求消息对应的支付关联的宿主程序。
91.sdk服务器预设有第一对应关系。第一对应关系包括宿主程序标识与用户验证调起方的关系。宿主程序标识用于标识宿主程序。用户验证调起方用于指示展示用户验证页面的主体，用户验证调起方包括终端设备中的sdk或宿主程序。在接收安全验证结果信息后，sdk服务器可根据目标宿主程序标识和第一对应关系，确定与目标宿主程序标识对应的目标用户验证调起方。目标用户验证调起方为在第一对应关系中与目标宿主程序标识对应的用户验证调起方。
92.在目标用户验证调起方为宿主程序的情况下，sdk服务器向sdk发送第一通知消息。在目标用户验证调起方为sdk的情况下，sdk服务器向sdk发送第四通知消息。第四通知消息用于指示sdk展示用户验证页面，以提示用户输入第二用户验证输入信息。第二用户验证输入信息用于sdk服务器进行用户验证以得到用户验证结果信息。终端设备中的sdk响应于第四通知消息，可由sdk直接展示用户验证页面，对应地，用户验证由sdk服务器执行。终端设备中的sdk可向sdk服务器发送第二用户验证输入信息。sdk服务器根据第二用户验证输入信息进行用户验证，得到用户验证结果信息，用户验证的具体内容可参见上述实施例中宿主程序服务器进行的用户验证的相关说明，在此不再赘述。
93.通过第一对应关系的设置，可使终端设备中用户验证的主体设置更加灵活，具有
更多选择性。
94.在一些实施例中，支付由商户系统或通过终端设备中安装的商户程序发起，在sdk服务器接收到支付请求消息前，商户系统与sdk之间、sdk与sdk服务器之间还需就订单的相关信息进行交互。图4为本技术第一方面提供的支付方法的又一实施例的流程图。图4与图2的不同之处在于，图4所示的支付方法还可包括步骤s209至步骤s211。
95.在步骤s209中，响应于商户系统发送的订单请求消息，生成订单标识。
96.在用户下单生成订单后，商户系统可向sdk服务器发送订单请求消息，以向sdk服务器请求能够标识该笔订单的标识即订单标识。sdk服务器生成的订单标识具体可为订单流水号。
97.在步骤s210中，向商户系统发送订单反馈消息，以使商户系统向sdk发送sdk调用请求消息。
98.sdk服务器可生成订单反馈消息，订单反馈消息包括订单标识。sdk服务器向商户系统发送该订单反馈消息，订单反馈消息包括订单标识。商户系统接收到订单反馈消息后，可向终端设备的sdk发送sdk调用请求消息，sdk调用请求包括订单标识。sdk调用请求消息用于请求调用终端设备中的sdk。终端设备中的sdk在初始化的过程中，可采集终端设备的地理位置、终端设备标识等信息。
99.在步骤s211中，响应于sdk发送的第一订单查询消息，向sdk发送第一查询反馈消息。
100.sdk可向sdk服务器发送第一订单查询消息，以在sdk服务器通过订单标识查询订单标识对应的订单信息。第一订单查询消息包括订单标识。sdk服务器查找到与订单标识对应的订单消息后，通过第一查询反馈消息将与订单标识对应的订单消息反馈给sdk。第一查询反馈消息包括与订单标识对应的订单信息。sdk接收到第一查询反馈消息后，可向sdk服务器发送支付请求消息。
101.在一些实施例中，商户可指定特定的付款方付款，订单请求消息包括指定付款方身份信息，即通过订单请求消息制定特定的付款方。sdk向sdk服务器发送的支付请求消息包括如用户登录账号等支付的付款方身份信息，sdk服务器可在指定付款方身份信息与支付请求消息指示的支付的付款方身份信息不一致的情况下，向sdk发送支付中止通知消息，以使sdk发出支付提示信息。支付提示信息可提示用户切换用户登录账号重新支付，支付提示信息也可提示用户支付中止的原因，如支付提示信息为终端设备显示的“登录账号信息与商户指定信息不符，暂无法支付”等字样。
102.在一些实施例中，支付可为用户利用终端设备扫描他人的收款码发起的支付。在sdk服务器接收到支付请求消息前，sdk与sdk服务器之间还需就订单的相关信息进行交互。图5为本技术第一方面提供的支付方法的又另一实施例的流程图。图5与图2的不同之处在于，图5所示的支付方法还可包括步骤s212和步骤s213。
103.在步骤s212中，接收终端设备的sdk发送的第二订单查询消息。
104.终端设备扫描收款码，可得到第一码信息。第一码信息为从收款码中读取得到的码信息。终端设备的sdk可向sdk服务器发送第二订单查询消息。第二订单查询消息用于向sdk服务器请求查询与第一码信息对应的订单消息。第二订单查询消息包括终端设备扫描收款码得到的第一码信息。
105.在步骤s213中，向sdk发送第二查询反馈消息。
106.sdk服务器根据第一码信息，查找与第一码信息对应的订单信息。在查找到与第一码信息对应的订单信息后，sdk服务器可生产第二查询反馈消息，并向sdk发送第二查询反馈消息。第二查询反馈消息包括与第一码信息对应的订单信息。
107.sdk接收到第二查询反馈消息后，可根据用户的输入确定支付金额，生成支付请求消息，向sdk服务器发送支付请求消息。sdk服务器在接收到支付请求消息后，可判断支付请求消息指示的支付的付款卡是否可用，在付款卡可用的情况下，向安全控制系统发送安全验证请求消息。
108.在一些实施例中，支付可为用户利用终端设备显示付款码，由他人利用支付受理终端扫描付款码发起的支付。在sdk服务器接收到支付请求消息前，sdk可向sdk服务器申请付款码。图6为本技术第一方面提供的支付方法的再一实施例的流程图。图6与图2的不同之处在于，图6所示的支付方法还可包括步骤s214。
109.在步骤s214中，响应于接收的付款码申请消息，向sdk发送付款码反馈消息。
110.付款码申请消息由sdk发送。即终端设备中的sdk可向sdk服务器发送付款码申请消息，付款码申请消息用于向sdk服务器申请付款码。sdk服务器为付款码申请消息分配付款码，并通过付款码反馈消息将付款码反馈给sdk。付款码反馈消息包括付款码。
111.在一些示例中，sdk后台系统包括sdk后台子系统和支付码子系统。sdk可向sdk后台子系统中的sdk服务器发送付款码申请消息，sdk后台子系统中的sdk服务器向支付码子系统中的sdk服务器转发付款码申请消息，支付码子系统中的sdk服务器为付款码申请消息分配付款码，并向sdk后台子系统中的sdk服务器发送付款码反馈消息，sdk后台子系统中的sdk服务器向sdk转发付款码反馈消息。
112.支付请求消息由支付受理设备基于扫描的付款码生成。sdk收到付款码反馈消息后，可在支付时显示付款码。支付受理设备扫描付款码，得到第二码信息，第二码信息为从付款码中读取得到的码信息。支付受理设备可基于第二码信息生成支付请求消息，并向sdk服务器发送支付请求消息。
113.本技术第二方面提供一种支付方法，该支付方法应用于终端设备，即该支付方法可由终端设备执行。终端设备具有sdk和宿主程序。图7为本技术第二方面提供的支付方法的一实施例的流程图。如图7所示，该支付方法可包括步骤s301至步骤s304。
114.在步骤s301中，通过sdk获取sdk服务器发送的第一通知消息。
115.第一通知消息是sdk服务器基于表征安全验证通过的安全验证结果信息发送的。安全验证结果信息是安全控制系统基于安全验证请求消息中的安全验证信息对支付请求消息对应的支付进行安全验证得到的。安全验证请求消息由sdk服务器响应于接收的支付请求消息发送。
116.在步骤s302中，响应于第一通知消息，通过sdk通知宿主程序展示用户验证页面，以提示用户输入第一用户验证输入信息。
117.在步骤s303中，通过宿主程序向宿主程序服务器反馈第一用户验证输入信息。
118.第一用户验证输入信息用于宿主程序服务器进行用户验证以得到用户验证结果信息。
119.在步骤s304中，通过sdk向sdk服务器发送通过宿主程序从宿主程序服务器获取的
用户验证结果信息，使sdk服务器在用户验证结果信息表征用户验证通过的情况下，发起付款请求，以完成支付。
120.在一些实施例中，用户验证结果信息还用于使sdk服务器在用户验证结果信息满足一致性验证条件的情况下，发起付款请求。
121.在一些示例中，一致性验证条件包括：第一用户验证结果信息和第二用户验证结果信息一致，第一用户验证结果信息为由宿主程序服务器通过宿主程序传输给sdk的用户验证结果信息，第二用户验证结果信息为从宿主程序服务器获取的用户验证结果信息。
122.上述步骤s301至步骤s304的具体内容可参见上述实施例中的相关说明，在此不再赘述。
123.在本技术实施例中，sdk服务器响应于支付请求消息，向安全控制系统发送安全验证请求消息，以请求安全控制系统对本次支付进行安全验证，以完成sdk所属方所需的安全性方面的验证。在安全验证通过的情况下，终端设备中的sdk接收到sdk服务器发送的用于指示sdk通知宿主程序展示用户验证页面的消息，sdk响应于该消息，触发宿主程序主动发起用户验证，以完成宿主程序所属方所需的用户身份安全性方面的验证。在支付过程中实现了sdk所属方和宿主程序所属方两个主体的双向验证，提高了支付的安全性，也满足了sdk所属方和宿主程序所属方两个主体对安全性管控的需求。
124.在一些实施例中，sdk服务器可向宿主程序服务器请求用户验证方式，sdk可通过sdk服务器获取宿主程序服务器的反馈，并做出对应的操作。图8为本技术第二方面提供的支付方法的另一实施例的流程图。图8与图7的不同之处在于，图8所示的支付方法还可包括步骤s305和步骤s306。
125.在步骤s305中，响应于sdk接收的第二通知消息，通过sdk发出拒绝提示信息。
126.第二通知消息由sdk服务器在验证操作信息包括拒绝支付标识的情况下发送。
127.在步骤s306中，响应于sdk接收的第三通知消息，通过sdk发出免密支付提示信息。
128.第三通知消息由sdk服务器在验证操作信息包括免密支付标识的情况下发送。
129.用户验证方式反馈消息包括验证操作信息。用户验证方式反馈消息由宿主服务器响应于用户验证方式请求消息发送。用户验证方式请求消息由sdk服务器在安全验证结果信息表征安全验证通过的情况下向宿主程序服务器发送。用户验证方式请求消息包括支付请求消息指示的支付对应的订单信息、终端设备信息、支付信息中的一项或两项以上。
130.在一些实施例中，第一通知消息由sdk服务器在验证操作信息包括用户验证方式标识的情况下发送。第一通知消息包括用户验证方式标识，用于指示sdk通知宿主程序展示与用户验证方式标识匹配的用户验证页面，以提示用户输入与用户验证方式标识匹配的第一用户验证输入信息。
131.上述步骤s305和步骤s306的具体内容可参见上述实施例中的相关说明，在此不再赘述。
132.在一些实施例中，安全验证结果信息包括目标宿主程序标识。目标宿主程序标识包括支付请求消息对应的支付的宿主程序标识。第一通知消息由sdk服务器在目标用户验证调起方为宿主程序的情况下发送。目标用户验证调起方为第一对应关系中与目标宿主程序标识匹配的用户验证调起方，目标宿主程序标识包括支付请求消息对应的支付的宿主程序标识。第一对应关系包括宿主程序标识与用户验证调起方的关系。
133.在一些实施例中，在目标用户验证调起方为sdk的情况下，终端设备通过sdk获取sdk服务器发送的第四通知消息。第四通知消息由sdk服务器在目标用户验证调起方为sdk的情况下发送。终端设备响应于第四通知消息，调用sdk展示用户验证页面，以提示用户输入第二用户验证输入信息。终端设备通过sdk向sdk服务器反馈第二用户验证输入信息。第二用户验证输入信息用于sdk服务器进行用户验证以得到用户验证结果信息。
134.在一些实施例中，支付由商户系统或通过终端设备中安装的商户程序发起，在sdk服务器接收到支付请求消息前，商户系统与sdk之间、sdk与sdk服务器之间还需就订单的相关信息进行交互。图9为本技术第二方面提供的支付方法的又一实施例的流程图。图9与图7的不同之处在于，图9所示的支付方法还可包括步骤s307至步骤s309。
135.在步骤s307中，通过sdk接收sdk调用请求消息，sdk调用请求消息由商户系统响应于订单反馈消息生成。
136.订单反馈消息和sdk调用请求消息包括订单标识。订单标识由sdk服务器响应于商户系统发送的订单请求消息生成。
137.在步骤s308中，响应于sdk调用请求消息，通过sdk向sdk服务器发送第一订单查询消息。
138.在步骤s309中，通过sdk接收sdk服务器响应于第一订单查询消息发送的第一查询反馈消息。
139.第一查询反馈消息包括与订单标识对应的订单信息。
140.在一些实施例中，订单请求消息包括指定付款方身份信息。响应于通过sdk接收的支付中止通知消息，终端设备可通过sdk发出支付提示信息。支付中止通知消息由sdk服务器在指定付款方身份信息与支付请求消息指示的支付的付款方身份信息不一致的情况下发送。
141.上述步骤s307至步骤s309的具体内容可参见上述实施例中的相关说明，在此不再赘述。
142.在一些实施例中，支付可为用户利用终端设备扫描他人的收款码发起的支付。在sdk服务器接收到支付请求消息前，sdk与sdk服务器之间还需就订单的相关信息进行交互。图10为本技术第二方面提供的支付方法的又另一实施例的流程图。图10与图7的不同之处在于，图10所示的支付方法还可包括步骤s310至步骤s312。
143.在步骤310中，扫描付款码，得到第一码信息。
144.在步骤311中，通过sdk向sdk服务器发送第二订单查询消息。
145.第二订单查询消息包括第一码信息。
146.在步骤312中，通过sdk接收sdk服务器发送的第二查询反馈消息。
147.第二查询反馈消息包括与第一码信息对应的订单信息。
148.上述步骤s310至步骤s312的具体内容可参见上述实施例中的相关说明，在此不再赘述。
149.在一些实施例中，支付可为用户利用终端设备显示付款码，由他人利用支付受理终端扫描付款码发起的支付。在sdk服务器接收到支付请求消息前，sdk可向sdk服务器申请付款码。图11为本技术第二方面提供的支付方法的再一实施例的流程图。图11与图7的不同之处在于，图11所示的支付方法还可包括步骤s313至步骤s315。
150.在步骤s313中，通过sdk向sdk服务器发送付款码申请消息。
151.在步骤s314中，通过sdk接收sdk服务器发送的付款码反馈消息。
152.付款码反馈消息包括付款码。
153.在步骤s315中，显示付款码。
154.付款码用于被支付受理设备扫描以生成支付请求消息。
155.上述步骤s313至步骤s315的具体内容可参见上述实施例中的相关说明，在此不再赘述。
156.本技术第三方面提供一种支付方法，应用于宿主程序服务器，即该支付方法可由宿主程序服务器执行。图12为本技术第三方面提供的支付方法的一实施例的流程图。如图12所示，该支付方法可包括步骤s401至步骤s403。
157.在步骤s401中，接收终端设备通过宿主程序反馈的第一用户验证输入信息。
158.第一用户验证输入信息在sdk响应于第一通知消息通知宿主程序展示用户验证页面后得到。第一通知消息是sdk服务器基于表征安全验证通过的安全验证结果信息发送的。安全验证结果信息是安全控制系统基于安全验证请求消息中的安全验证信息对支付请求消息对应支付进行安全验证得到的。安全验证请求消息由sdk服务器响应于接收的支付请求消息发送。
159.在步骤s402中，根据第一用户验证输入信息进行用户验证，得到用户验证结果信息。
160.在步骤s403中，向终端设备中的宿主程序发送用户验证结果信息，通过宿主程序将用户验证结果信息传输给sdk，以使sdk向sdk服务器发送用户验证结果信息，在用户验证结果信息表征用户验证通过的情况下，使sdk服务器发起付款请求，以完成支付。
161.在一些实施例中，在执行步骤s403之后，宿主程序服务器还可向sdk服务器发送用户验证结果信息，以使sdk服务器在用户验证结果信息表征用户验证通过且用户验证结果信息满足一致性验证条件的情况下，发起付款请求，以完成支付。
162.在一些示例中，一致性验证条件包括第一用户验证结果信息和第二用户验证结果信息一致。第一用户验证结果信息为由宿主程序服务器通过宿主程序传输给sdk的用户验证结果信息，第二用户验证结果信息为从宿主程序服务器获取的用户验证结果信息。
163.上述步骤s401至步骤s403的具体内容可参见上述实施例中的相关说明，在此不再赘述。
164.在本技术实施例中，sdk服务器响应于支付请求消息，向安全控制系统发送安全验证请求消息，以请求安全控制系统对本次支付进行安全验证，以完成sdk所属方所需的安全性方面的验证。在安全验证通过的情况下，sdk服务器向终端设备的sdk发送用于指示sdk通知宿主程序展示用户验证页面的消息，以使sdk能够触发宿主程序主动发起用户验证。终端设备可接收用户输入的第一用户验证输入信息，并将第一用户验证输入信息向宿主程序服务器发送，宿主程序服务器可完成宿主程序所属方所需的用户身份安全性方面的验证。在支付过程中实现了sdk所属方和宿主程序所属方两个主体的双向验证，提高了支付的安全性，也满足了sdk所属方和宿主程序所属方两个主体对安全性管控的需求。
165.在上述实施例中，宿主程序服务器存储有用于对宿主程序与sdk之间交互的信息进行加、解密的密钥，具体内容可参见上述实施例中的现关说明，在此不再赘述。
166.在一些实施例中，宿主程序服务器可接受sdk服务器的请求，向sdk服务器提供用户验证方式，sdk可通过sdk服务器获取宿主程序服务器的反馈，并做出对应的操作。图13为本技术第三方面提供的支付方法的另一实施例的流程图。图13与图12的不同之处在于，图13所示的支付方法还可包括步骤s404和步骤s405。
167.在步骤s404中，接收sdk服务器在安全验证结果信息表征安全验证通过的情况下发送的用户验证方式请求消息。
168.用户验证方式请求消息包括支付请求消息指示的支付对应的订单信息、终端设备信息、支付信息中的一项或两项以上。
169.在步骤s405中，根据用户验证方式请求消息，向sdk服务器发送用户验证方式反馈消息。
170.用户验证方式反馈消息包括验证操作信息。
171.在验证操作信息包括拒绝支付标识的情况下，sdk服务器向sdk发送第二通知消息，第二通知消息用于指示sdk发出拒绝支付提示信息。在验证操作信息包括免密支付标识的情况下，sdk服务器向sdk发送第三通知消息，第三通知消息用于指示sdk发出免密支付提示信息。
172.在一些实施例中，第一通知消息由sdk服务器在验证操作信息包括用户验证方式标识的情况下发送。第一通知消息包括用户验证方式标识，用于指示sdk通知宿主程序展示与用户验证方式标识匹配的用户验证页面，以提示用户输入与用户验证方式标识匹配的第一用户验证输入信息。
173.上述步骤s404和步骤s405的具体内容可参见上述实施例中的相关说明，在此不再赘述。
174.在一些示例中，安全验证结果信息包括目标宿主程序标识。目标宿主程序标识包括支付请求消息对应的支付的宿主程序标识。第一通知消息由sdk服务器在目标用户验证调起方为宿主程序的情况下发送。目标用户验证调起方为第一对应关系中与目标宿主程序标识匹配的用户验证调起方。目标宿主程序标识包括支付请求消息对应的支付的宿主程序标识。第一对应关系包括宿主程序标识与用户验证调起方的关系。
175.为了便于说明，下面分别以支付由商户系统或通过终端设备中安装的商户程序发起、支付由终端设备扫描他人的收款码发起、支付由支付受理终端扫描付款码发起三种场景为例，对终端设备、系统、服务器之间的支付流程的交互进行说明。
176.在该示例中，支付由商户系统或通过终端设备中安装的商户程序发起。图14为本技术实施例提供的支付流程的一示例的流程图。终端设备包括sdk和宿主程序。如图14所示，该支付流程包括步骤s501至步骤s522。
177.在步骤s501中，用户下单后，商户系统向sdk服务器发送订单请求消息。
178.在步骤s502中，sdk服务器响应于订单请求消息，向商户系统发送订单反馈消息。订单反馈消息可包括sdk服务器生成的订单标识。
179.在步骤s503中，商户系统向终端设备中sdk发送sdk调用请求消息。
180.在步骤s504中，sdk采集终端设备信息。
181.在步骤s505中，sdk向sdk服务器发送第一订单查询消息。
182.在步骤s506中，sdk服务器向sdk反馈第一查询反馈消息。
183.在步骤s507中，sdk向sdk服务器发送支付请求消息。
184.在步骤s508中，sdk服务器向安全控制系统发送安全验证请求消息。
185.在步骤s509中，安全控制系统对支付请求消息指示的支付进行安全验证。
186.在步骤s510中，安全控制系统向sdk服务器反馈安全验证结果信息。
187.在步骤s511中，在安全验证结果信息表征安全验证通过的情况下，sdk服务器向宿主程序服务器发送用户验证方式请求消息。
188.在步骤s512中，宿主程序服务器响应于用户验证方式请求消息，向sdk服务器发送用户验证方式反馈消息。用户验证方式反馈消息包括用户验证方式标识。
189.在步骤s513中，sdk服务器向sdk发送第一通知消息。第一通知消息包括用户验证方式标识。
190.在步骤s514中，sdk向宿主程序传输用户验证方式标识。
191.在步骤s515中，宿主程序被触发，展示与用户验证方式标识匹配的用户验证页面。
192.在步骤s516中，宿主程序接收用户输入的第一用户验证输入信息，向宿主程序服务器发送第一用户验证输入信息。
193.在步骤s517中，宿主程序服务器根据第一用户验证输入信息进行用户验证，得到用户验证结果信息。
194.在步骤s518中，sdk服务器从宿主程序服务器获取用户验证结果信息。为了便于说明，将sdk服务器直接从宿主服务器获取到的用户验证结果信息称为第二用户验证结果信息。
195.在步骤s519中，宿主程序服务器向宿主程序发送用户验证结果信息。
196.在步骤s520中，宿主程序将用户验证结果信息反馈给sdk。
197.在步骤s521中，sdk将用户验证结果信息反馈给sdk服务器。为了便于说明，将sdk服务器从sdk获取到的用户验证结果信息称为第一用户验证结果信息。
198.在步骤s522中，在第一用户验证结果信息和第二用户验证结果信息一致的情况下，sdk服务器发起付款请求，以完成支付。
199.上述步骤s501至步骤s522的具体内容可参见上述实施例中的相关说明，在此不再赘述。
200.在该示例中，支付由终端设备扫描他人的收款码发起。图15为本技术实施例提供的支付流程的另一示例的流程图。终端设备包括sdk和宿主程序。如图15所示，该支付流程可包括步骤s601至步骤s621。
201.在步骤s601中，终端设备扫描收款码，得到第一码信息，sdk向sdk服务器发送第二订单查询消息。第二订单查询消息包括第一码信息。
202.在步骤s602中，sdk服务器向sdk发送第二查询反馈消息。
203.在步骤s603中，sdk接收用户输入，确定支付金额。
204.在步骤s604中，sdk向sdk服务器发送支付请求消息。
205.在步骤s605中，sdk服务器判断是否有可用的付款卡。
206.在步骤s606中，在存在可用的付款卡的情况下，sdk服务器向安全控制系统发送安全验证请求消息。
207.在步骤s607中，安全控制系统对支付请求消息指示的支付进行安全验证。
208.在步骤s608中，安全控制系统向sdk服务器反馈安全验证结果信息。
209.在步骤s609中，在安全验证结果信息表征安全验证通过的情况下，sdk服务器向宿主程序服务器发送用户验证方式请求消息。
210.在步骤s610中，宿主程序服务器响应于用户验证方式请求消息，向sdk服务器发送用户验证方式反馈消息。用户验证方式反馈消息包括用户验证方式标识。
211.在步骤s611中，sdk服务器向sdk发送第一通知消息。第一通知消息包括用户验证方式标识。
212.在步骤s612中，sdk向宿主程序传输用户验证方式标识。
213.在步骤s613中，宿主程序被触发，展示与用户验证方式标识匹配的用户验证页面。
214.在步骤s614中，宿主程序接收用户输入的第一用户验证输入信息，向宿主程序服务器发送第一用户验证输入信息。
215.在步骤s615中，宿主程序服务器根据第一用户验证输入信息进行用户验证，得到用户验证结果信息。
216.在步骤s616中，sdk服务器从宿主程序服务器获取用户验证结果信息。为了便于说明，将sdk服务器直接从宿主服务器获取到的用户验证结果信息称为第二用户验证结果信息。
217.在步骤s617中，宿主程序服务器向宿主程序发送用户验证结果信息。
218.在步骤s618中，宿主程序将用户验证结果信息反馈给sdk。
219.在步骤s619中，sdk将用户验证结果信息反馈给sdk服务器。为了便于说明，将sdk服务器从sdk获取到的用户验证结果信息称为第一用户验证结果信息。
220.在步骤s620中，在第一用户验证结果信息和第二用户验证结果信息一致的情况下，sdk服务器向宿主程序服务器发起付款请求。
221.在步骤s621中，宿主程序服务器向付款方账户管理系统发起付款请求，以完成支付。
222.上述步骤s601至步骤s621的具体内容可参见上述实施例中的相关说明，在此不再赘述。
223.在该示例中，支付由支付受理终端扫描终端设备显示的付款码发起。终端设备包括sdk和宿主程序。这里以sdk后台系统包括sdk后台子系统和支付码子系统为例进行说明，为了便于说明，将sdk后台子系统中的sdk服务器称为第一sdk服务器，将支付码子系统中的sdk服务器称为第二sdk服务器。图16为本技术实施例提供的支付流程的又一示例的流程图。如图16所示，该支付流程可包括步骤s701至步骤s723。
224.在步骤s701中，终端设备中sdk通过第一sdk服务器向第二sdk服务器发送付款码申请消息。
225.在步骤s702中，第二sdk服务器分配付款码，并通过第一sdk服务器向sdk发送付款码反馈消息。付款码反馈消息包括付款码。
226.在步骤s703中，支付受理终端扫描终端设备显示的付款码，得到第二码信息，向第二sdk服务器发送支付请求消息。
227.在步骤s704中，第二sdk服务器可通过支付策略系统向宿主程序服务器发送支付策略查询消息。
228.在步骤s705中，宿主程序服务器通过支付策略系统向第二sdk服务器反馈支付策略信息。
229.在步骤s706中，第二sdk服务器向第一sdk服务器发送附加处理请求消息。附加处理请求消息包括支付策略信息。
230.在步骤s707中，第一sdk服务器向安全控制系统发送安全验证请求消息。
231.在步骤s708中，安全控制系统对支付请求消息指示的支付进行安全验证。
232.在步骤s709中，安全控制系统向第一sdk服务器反馈安全验证结果信息。
233.在步骤s710中，第一sdk服务器通过第二sdk服务器将支付信息、订单信息等信息同步至宿主程序服务器。
234.在步骤s711中，第一sdk服务器通过第二sdk服务器向宿主程序服务器发送用户验证方式请求消息。
235.在步骤s712中，宿主程序服务器通过第二sdk服务器向第一sdk服务器发送用户验证方式反馈消息。用户验证方式反馈消息包括用户验证方式标识。
236.在步骤s713中，第一sdk服务器向sdk发送第一通知消息。第一通知消息包括用户验证方式标识。
237.在步骤s714中，sdk向宿主程序传输用户验证方式标识。
238.在步骤s715中，宿主程序被触发，展示与用户验证方式标识匹配的用户验证页面。
239.在步骤s716中，宿主程序接收用户输入的第一用户验证输入信息，向宿主程序服务器发送第一用户验证输入信息。
240.在步骤s717中，宿主程序服务器根据第一用户验证输入信息进行用户验证，得到用户验证结果信息。
241.在步骤s718中，第一sdk服务器通过第二sdk服务器从宿主程序服务器获取用户验证结果信息。为了便于说明，将sdk服务器通过第二sdk服务器从宿主服务器获取到的用户验证结果信息称为第二用户验证结果信息。
242.在步骤s719中，宿主程序服务器向宿主程序发送用户验证结果信息。
243.在步骤s720中，宿主程序将用户验证结果信息反馈给sdk。
244.在步骤s721中，sdk将用户验证结果反馈给第一sdk服务器。为了便于说明，将第一sdk服务器从sdk获取到的用户验证结果信息称为第一用户验证结果信息。若宿主程序的所属方与付款卡所属方相同，跳转步骤s724；若宿主程序的所属方与付款卡所属方不同，跳转步骤s725
245.在步骤s722中，在第一用户验证结果信息和第二用户验证结果信息一致的情况下，第一sdk服务器通过第二sdk服务器和宿主程序服务器向付款方账户管理系统发起付款请求，以完成支付。
246.在步骤s723中，在第一用户验证结果信息和第二用户验证结果信息一致的情况下，第一sdk服务器通过第二sdk服务器向付款方账户管理系统发起付款请求，以完成支付。
247.在上述步骤s722和步骤s723之前，若支付使用了支付策略信息，第二sdk服务器还可与支付策略系统交互以承兑支付策略信息。
248.上述步骤s701至步骤s723的具体内容可参见上述实施例中的相关说明，在此不再赘述。
249.本技术第四方面提供一种sdk服务器。图17为本技术第四方面提供的sdk服务器的一实施例的结构示意图。如图17所示，该sdk服务器800可包括发送模块801和接收模块802。
250.发送模块801可用于响应于接收的支付请求消息，向安全控制系统发送安全验证请求消息。
251.安全验证请求消息包括安全验证信息，用于指示安全控制系统根据安全验证信息对支付请求消息对应的支付进行安全验证。
252.接收模块802可用于接收安全控制系统发送的安全验证结果信息。
253.发送模块801还可用于在安全验证结果信息表征安全验证通过的情况下，向终端设备中的sdk发送第一通知消息。
254.终端设备具有sdk和宿主程序。第一通知消息用于指示sdk通知宿主程序展示用户验证页面，以提示用户输入第一用户验证输入信息。第一用户验证输入信息用于宿主程序服务器进行用户验证以得到用户验证结果信息。
255.发送模块801还可用于在用户验证结果信息表征用户验证通过的情况下，发起付款请求，以完成支付。
256.在一些实施例中，发送模块801可用于在用户验证结果信息满足一致性验证条件的情况下，发起所述付款请求。
257.在一些示例中，一致性验证条件包括：第一用户验证结果信息和第二用户验证结果信息一致。
258.第一用户验证结果信息为由宿主程序服务器通过宿主程序传输给sdk的用户验证结果信息。第二用户验证结果信息为从宿主程序服务器获取的用户验证结果信息。
259.在本技术实施例中，sdk服务器响应于支付请求消息，向安全控制系统发送安全验证请求消息，以请求安全控制系统对本次支付进行安全验证，以完成sdk所属方所需的安全性方面的验证。在安全验证通过的情况下，sdk服务器向终端设备的sdk发送用于指示sdk通知宿主程序展示用户验证页面的消息，以使sdk能够触发宿主程序主动发起用户验证，以完成宿主程序所属方所需的用户身份安全性方面的验证。在支付过程中实现了sdk所属方和宿主程序所属方两个主体的双向验证，提高了支付的安全性，也满足了sdk所属方和宿主程序所属方两个主体对安全性管控的需求。
260.在一些示例中，sdk服务器存储有用于对sdk与宿主程序之间交互的信息进行加、解密的密钥。
261.在一些实施例中，发送模块801还可用于在安全验证结果信息表征安全验证通过的情况下，向宿主程序服务器发送用户验证方式请求消息。
262.用户验证方式请求消息包括支付请求消息指示的支付对应的订单信息、终端设备信息、支付信息中的一项或两项以上。
263.接收模块802还可用于接收宿主程序服务器发送的用户验证方式反馈消息。
264.用户验证方式反馈消息包括验证操作信息。
265.发送模块801还可用于在验证操作信息包括拒绝支付标识的情况下，向sdk发送第二通知消息。
266.第二通知消息用于指示sdk发出拒绝支付提示信息。
267.接收模块802还可用于在验证操作信息包括免密支付标识的情况下，向sdk发送第
三通知消息。
268.第三通知消息用于指示sdk发出免密支付提示信息。
269.在一些实施例中，发送模块801可用于：在验证操作信息包括用户验证方式标识的情况下，向sdk发送第一通知消息。
270.第一通知消息包括用户验证方式标识，用于指示sdk通知宿主程序展示与用户验证方式标识匹配的用户验证页面，以提示用户输入与用户验证方式标识匹配的第一用户验证输入信息。
271.在一些实施例中，sdk服务器还可包括查询模块。
272.查询模块可用于根据目标宿主程序标识和预设的第一对应关系，确定与目标宿主程序标识对应的目标用户验证调起方。
273.第一对应关系包括宿主程序标识与用户验证调起方的关系。
274.发送模块801可用于在目标用户验证调起方为宿主程序的情况下，向sdk发送第一通知消息。
275.在一些实施例中，发送模块801还可用于在目标用户验证调起方为sdk的情况下，向sdk发送第四通知消息。
276.第四通知消息用于指示sdk展示用户验证页面，以提示用户输入第二用户验证输入信息。第二用户验证输入信息用于sdk服务器进行用户验证以得到用户验证结果信息。
277.在一些实施例中，sdk服务器800还可包括订单标识生成模块。
278.订单标识生成模块可用于响应于商户系统发送的订单请求消息，生成订单标识。
279.发送模块801还可用于向商户系统发送订单反馈消息，以使商户系统向sdk发送sdk调用请求消息。
280.订单反馈消息和sdk调用请求消息包括订单标识。
281.发送模块801还可用于响应于sdk发送的第一订单查询消息，向sdk发送第一查询反馈消息。
282.第一查询反馈消息包括与订单标识对应的订单信息。
283.在一些实施例中，订单请求消息包括指定付款方身份信息。
284.发送模块801还可用于在指定付款方身份信息与支付请求消息指示的支付的付款方身份信息不一致的情况下，向sdk发送支付中止通知消息，以使sdk发出支付提示信息。
285.在一些实施例中，接收模块802还可用于接收终端设备的sdk发送的第二订单查询消息。
286.第二订单查询消息包括终端设备扫描收款码得到的第一码信息。
287.发送模块801还可用于向sdk发送第二查询反馈消息。
288.第二查询反馈消息包括与第一码信息对应的订单信息。
289.在一些实施例中，发送模块801还可用于响应于接收的付款码申请消息，向sdk发送付款码反馈消息。
290.付款码申请消息由sdk发送。付款码反馈消息包括付款码。对应地，支付请求消息由支付受理设备基于扫描的付款码生成。
291.本技术第五方面提供一种终端设备。终端设备具有sdk和宿主程序。图18为第五方面提供的终端设备的一实施例的结构示意图。如图18所示，该终端设备900可包括接收模块
901、显示模块902和发送模块903。
292.接收模块901可用于通过sdk获取sdk服务器发送的第一通知消息。
293.第一通知消息是sdk服务器基于表征安全验证通过的安全验证结果信息发送的。安全验证结果信息是安全控制系统基于安全验证请求消息中的安全验证信息对支付请求消息对应的支付进行安全验证得到的。安全验证请求消息由sdk服务器响应于接收的支付请求消息发送。
294.显示模块902可用于响应于第一通知消息，通过sdk通知宿主程序展示用户验证页面，以提示用户输入第一用户验证输入信息。
295.发送模块903可用于通过宿主程序向宿主程序服务器反馈第一用户验证输入信息。
296.第一用户验证输入信息用于宿主程序服务器进行用户验证以得到用户验证结果信息。
297.发送模块903还可用于通过sdk向sdk服务器发送通过宿主程序从宿主程序服务器获取的用户验证结果信息，使sdk服务器在用户验证结果信息表征用户验证通过的情况下，发起付款请求，以完成支付。
298.在一些实施例中，所述用户验证结果信息还用于使所述sdk服务器在所述用户验证结果信息满足一致性验证条件的情况下，发起所述付款请求。
299.在一些示例中，一致性验证条件包括：第一用户验证结果信息和第二用户验证结果信息一致。第一用户验证结果信息为由宿主程序服务器通过宿主程序传输给sdk的用户验证结果信息，第二用户验证结果信息为从宿主程序服务器获取的用户验证结果信息。
300.在本技术实施例中，sdk服务器响应于支付请求消息，向安全控制系统发送安全验证请求消息，以请求安全控制系统对本次支付进行安全验证，以完成sdk所属方所需的安全性方面的验证。在安全验证通过的情况下，终端设备中的sdk接收到sdk服务器发送的用于指示sdk通知宿主程序展示用户验证页面的消息，sdk响应于该消息，触发宿主程序主动发起用户验证，以完成宿主程序所属方所需的用户身份安全性方面的验证。在支付过程中实现了sdk所属方和宿主程序所属方两个主体的双向验证，提高了支付的安全性，也满足了sdk所属方和宿主程序所属方两个主体对安全性管控的需求。
301.在一些示例中，sdk具有安全域，sdk中的信息存储于安全域。
302.sdk与宿主程序之间交互的信息为加密信息。sdk中加、解密的密钥存储于sdk服务器。宿主程序中加、解密的密钥存储于宿主程序服务器。
303.在一些实施例中，显示模块902还可用于响应于sdk接收的第二通知消息，通过sdk发出拒绝提示信息。
304.第二通知消息由sdk服务器在验证操作信息包括拒绝支付标识的情况下发送。
305.显示模块902还可用于响应于sdk接收的第三通知消息，通过sdk发出免密支付提示信息。
306.第三通知消息由sdk服务器在验证操作信息包括免密支付标识的情况下发送。
307.其中，用户验证方式反馈消息包括验证操作信息。用户验证方式反馈消息由宿主服务器响应于用户验证方式请求消息发送。用户验证方式请求消息由sdk服务器在安全验证结果信息表征安全验证通过的情况下向宿主程序服务器发送。用户验证方式请求消息包
括支付请求消息指示的支付对应的订单信息、终端设备信息、支付信息中的一项或两项以上。
308.在一些实施例中，第一通知消息由sdk服务器在验证操作信息包括用户验证方式标识的情况下发送。第一通知消息包括用户验证方式标识，用于指示sdk通知宿主程序展示与用户验证方式标识匹配的用户验证页面，以提示用户输入与用户验证方式标识匹配的第一用户验证输入信息。
309.在一些实施例中，安全验证结果信息包括目标宿主程序标识。目标宿主程序标识包括支付请求消息对应的支付的宿主程序标识。第一通知消息由sdk服务器在目标用户验证调起方为宿主程序的情况下发送，目标用户验证调起方为第一对应关系中与目标宿主程序标识匹配的用户验证调起方，目标宿主程序标识包括支付请求消息对应的支付的宿主程序标识，第一对应关系包括宿主程序标识与用户验证调起方的关系。
310.在一些实施例中，接收模块901还可用于通过sdk获取sdk服务器发送的第四通知消息。第四通知消息由sdk服务器在目标用户验证调起方为sdk的情况下发送。
311.显示模块902还可用于响应于第四通知消息，调用sdk展示用户验证页面，以提示用户输入第二用户验证输入信息。
312.发送模块903还可用于通过sdk向sdk服务器反馈第二用户验证输入信息。
313.第二用户验证输入信息用于sdk服务器进行用户验证以得到用户验证结果信息。
314.在一些实施例中，接收模块901还可用于通过sdk接收sdk调用请求消息。
315.sdk调用请求消息由商户系统响应于订单反馈消息生成。订单反馈消息和sdk调用请求消息包括订单标识。订单标识由sdk服务器响应于商户系统发送的订单请求消息生成。
316.发送模块903还可用于响应于sdk调用请求消息，通过sdk向sdk服务器发送第一订单查询消息。
317.接收模块901还可用于通过sdk接收sdk服务器响应于第一订单查询消息发送的第一查询反馈消息。
318.第一查询反馈消息包括与订单标识对应的订单信息。
319.在一些实施例中，订单请求消息包括指定付款方身份信息。
320.显示模块902还可用于响应于通过sdk接收的支付中止通知消息，通过sdk发出支付提示信息。
321.支付中止通知消息由sdk服务器在指定付款方身份信息与支付请求消息指示的支付的付款方身份信息不一致的情况下发送。
322.在一些实施例中，终端设备900还可包括扫描模块。
323.扫描模块可用于扫描付款码，得到第一码信息；
324.发送模块903还可用于通过sdk向sdk服务器发送第二订单查询消息。
325.第二订单查询消息包括第一码信息。
326.接收模块901还可用于通过sdk接收sdk服务器发送的第二查询反馈消息。
327.第二查询反馈消息包括与第一码信息对应的订单信息。
328.在一些实施例中，发送模块903还可用于通过sdk向sdk服务器发送付款码申请消息。
329.接收模块901还可用于通过sdk接收sdk服务器发送的付款码反馈消息，付款码反
馈消息包括付款码。
330.显示模块902还可用于显示付款码。
331.付款码用于被支付受理设备扫描以生成支付请求消息。
332.本技术第六方面提供一种宿主程序服务器。图19为第六方面提供的宿主程序服务器的一实施例的结构示意图。如图19所示，宿主程序服务器1000可包括接收模块1001、验证模块1002和发送模块1003。
333.接收模块1001可用于接收终端设备通过宿主程序反馈的第一用户验证输入信息。
334.终端设备具有软件开发工具包sdk和宿主程序。第一用户验证输入信息在sdk响应于第一通知消息通知宿主程序展示用户验证页面后得到。第一通知消息是sdk服务器基于表征安全验证通过的安全验证结果信息发送的。安全验证结果信息是安全控制系统基于安全验证请求消息中的安全验证信息对支付请求消息对应支付进行安全验证得到的。安全验证请求消息由sdk服务器响应于接收的支付请求消息发送。
335.验证模块1002可用于根据第一用户验证输入信息进行用户验证，得到用户验证结果信息。
336.发送模块1003可用于向终端设备中的宿主程序发送用户验证结果信息，通过宿主程序将用户验证结果信息传输给sdk，以使sdk向sdk服务器发送用户验证结果信息，在用户验证结果信息表征用户验证通过的情况下，使sdk服务器发起付款请求，以完成支付。
337.在一些实施例中，发送模块1003还可用于向sdk服务器发送用户验证结果信息，以使sdk服务器在用户验证结果信息表征用户验证通过且用户验证结果信息满足一致性验证条件的情况下，发起付款请求，以完成支付。
338.在一些示例中，一致性验证条件包括第一用户验证结果信息和第二用户验证结果信息一致。
339.第一用户验证结果信息为由宿主程序服务器通过宿主程序传输给sdk的用户验证结果信息。第二用户验证结果信息为从宿主程序服务器获取的用户验证结果信息。
340.在本技术实施例中，sdk服务器响应于支付请求消息，向安全控制系统发送安全验证请求消息，以请求安全控制系统对本次支付进行安全验证，以完成sdk所属方所需的安全性方面的验证。在安全验证通过的情况下，sdk服务器向终端设备的sdk发送用于指示sdk通知宿主程序展示用户验证页面的消息，以使sdk能够触发宿主程序主动发起用户验证。终端设备可接收用户输入的第一用户验证输入信息，并将第一用户验证输入信息向宿主程序服务器发送，宿主程序服务器可完成宿主程序所属方所需的用户身份安全性方面的验证。在支付过程中实现了sdk所属方和宿主程序所属方两个主体的双向验证，提高了支付的安全性，也满足了sdk所属方和宿主程序所属方两个主体对安全性管控的需求。
341.在一些示例中，宿主程序服务器存储有用于对宿主程序与sdk之间交互的信息进行加、解密的密钥。
342.在一些实施例中，接收模块1001还可用于接收sdk服务器在安全验证结果信息表征安全验证通过的情况下发送的用户验证方式请求消息。
343.用户验证方式请求消息包括支付请求消息指示的支付对应的订单信息、终端设备信息、支付信息中的一项或两项以上。
344.发送模块1003还可用于根据用户验证方式请求消息，向sdk服务器发送用户验证
方式反馈消息。
345.用户验证方式反馈消息包括验证操作信息。
346.其中，在验证操作信息包括拒绝支付标识的情况下，sdk服务器向sdk发送第二通知消息，第二通知消息用于指示sdk发出拒绝支付提示信息。在验证操作信息包括免密支付标识的情况下，sdk服务器向sdk发送第三通知消息，第三通知消息用于指示sdk发出免密支付提示信息。
347.在一些实施例中，第一通知消息由sdk服务器在验证操作信息包括用户验证方式标识的情况下发送。第一通知消息包括用户验证方式标识，用于指示sdk通知宿主程序展示与用户验证方式标识匹配的用户验证页面，以提示用户输入与用户验证方式标识匹配的第一用户验证输入信息。
348.在一些实施例中，安全验证结果信息包括目标宿主程序标识。目标宿主程序标识包括支付请求消息对应的支付的宿主程序标识。
349.第一通知消息由sdk服务器在目标用户验证调起方为宿主程序的情况下发送。目标用户验证调起方为第一对应关系中与目标宿主程序标识匹配的用户验证调起方。目标宿主程序标识包括支付请求消息对应的支付的宿主程序标识。第一对应关系包括宿主程序标识与用户验证调起方的关系。
350.本技术第七方面提供了一种sdk服务器。图20为本技术第七方面提供的sdk服务器的一实施例的结构示意图。如图20所示，sdk服务器1100包括存储器1101、处理器1102及存储在存储器1101上并可在处理器1102上运行的计算机程序。
351.在一个示例中，上述处理器1102可以包括中央处理器(cpu)，或者特定集成电路(application specific integrated circuit，asic)，或者可以被配置成实施本技术实施例的一个或多个集成电路。
352.存储器1101可包括只读存储器(read-only memory，rom)，随机存取存储器(random access memory，ram)，磁盘存储介质设备，光存储介质设备，闪存设备，电气、光学或其他物理/有形的存储器存储设备。因此，通常，存储器包括一个或多个编码有包括计算机可执行指令的软件的有形(非暂态)计算机可读存储介质(例如，存储器设备)，并且当该软件被执行(例如，由一个或多个处理器)时，其可操作来执行参考根据本技术第一方面实施例中的支付方法所描述的操作。
353.处理器1102通过读取存储器1101中存储的可执行程序代码来运行与可执行程序代码对应的计算机程序，以用于实现上述第一方面的实施例中的支付方法。
354.在一些示例中，sdk服务器1100还可包括通信接口1103和总线1104。其中，如图20所示，存储器1101、处理器1102、通信接口1103通过总线1104连接并完成相互间的通信。
355.通信接口1103，主要用于实现本技术实施例中各模块、装置、单元和/或设备之间的通信。也可通过通信接口1103接入输入设备和/或输出设备。
356.总线1104包括硬件、软件或两者，将sdk服务器1100的部件彼此耦接在一起。举例来说而非限制，总线1104可包括加速图形端口(accelerated graphics port，agp)或其他图形总线、增强工业标准架构(enhanced industry standard architecture，eisa)总线、前端总线(front side bus，fsb)、超传输(hypertransport，ht)互连、工业标准架构(industry standard architecture，isa)总线、无限带宽互连、低引脚数(low pin count，
lpc)总线、存储器总线、微信道架构(microchannel architecture，mca)总线、外围组件互连(peripheral component interconnect，pci)总线、pci-express(pci-e)总线、串行高级技术附件(serial advanced technology attachment，sata)总线、视频电子标准协会局部(video electronics standards association local bus，vlb)总线或其他合适的总线或者两个或更多个以上这些的组合。在合适的情况下，总线1104可包括一个或多个总线。尽管本技术实施例描述和示出了特定的总线，但本技术考虑任何合适的总线或互连。
357.本技术第八方面提供了一种终端设备，终端设备可包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序。存储器和处理器的种类及关系可参见上述sdk服务器中存储器和处理器的相关说明。与上述sdk服务器的不同之处包括，当存储器中的软件被执行时，其可操作来执行参考根据本技术第二方面实施例中的支付方法所描述的操作；以及，处理器通过读取存储器中存储的可执行程序代码来运行与可执行程序代码对应的计算机程序，以用于实现上述第二方面的实施例中的支付方法。在一些示例中，终端设备还可包括通信接口和总线。存储器、处理器、通信接口可通过总线连接并完成相互间的通信，存储器、处理器、通信接口和总线之间的通信连接可参见图20所示的sdk服务器中的存储器、处理器、通信接口和总线之间的通信连接，在此不再赘述。
358.本技术第九方面提供了一种宿主程序服务器，宿主程序服务器可包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序。存储器和处理器的种类及关系可参见上述sdk服务器中存储器和处理器的相关说明。与上述sdk服务器的不同之处包括，当存储器中的软件被执行时，其可操作来执行参考根据本技术第三方面实施例中的支付方法所描述的操作；以及，处理器通过读取存储器中存储的可执行程序代码来运行与可执行程序代码对应的计算机程序，以用于实现上述第三方面的实施例中的支付方法。在一些示例中，宿主程序服务器还可包括通信接口和总线。存储器、处理器、通信接口可通过总线连接并完成相互间的通信，存储器、处理器、通信接口和总线之间的通信连接可参见图20所示的sdk服务器中的存储器、处理器、通信接口和总线之间的通信连接，在此不再赘述。
359.本技术第十方面提供一种支付系统，该支付系统可包括上述实施例中的sdk服务器、终端设备和宿主程序服务器，sdk服务器、终端设备和宿主程序服务器的具体内容可参见上述实施例中的相关说明，在此不再赘述。
360.本技术第十一方面还提供一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序指令，该计算机程序指令被处理器执行时可实现上述实施例中第一方面的支付方法、第二方面的支付方法和/或第三方面的支付方法，且能达到相同的技术效果，为避免重复，这里不再赘述。其中，上述计算机可读存储介质可包括非暂态计算机可读存储介质，如只读存储器(read-only memory，简称rom)、随机存取存储器(random access memory，简称ram)、磁碟或者光盘等，在此并不限定。
361.本技术实施例还可提供一种计算机程序产品，该计算机程序产品中的指令可由sdk服务器、终端设备、宿主程序服务器的处理器执行时，使得sdk服务器、终端设备、宿主程序服务器执行上述第一方面的实施例中的支付方法、第二方面的实施例中的支付方法、第三方面的实施例中的支付方法。
362.需要明确的是，本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同或相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之
处。对于sdk服务器实施例、终端设备实施例、宿主程序服务器实施例、系统实施例、计算机可读存储介质实施例和计算机程序产品实施例而言，相关之处可以参见方法实施例的说明部分。本技术并不局限于上文所描述并在图中示出的特定步骤和结构。本领域的技术人员可以在领会本技术的精神之后，作出各种改变、修改和添加，或者改变步骤之间的顺序。并且，为了简明起见，这里省略对已知方法技术的详细描述。
363.上面参考根据本技术的实施例的方法、装置(系统)和计算机程序产品的流程图和/或框图描述了本技术的各方面。应当理解，流程图和/或框图中的每个方框以及流程图和/或框图中各方框的组合可以由计算机程序指令实现。这些计算机程序指令可被提供给通用计算机、专用计算机、或其它可编程数据处理装置的处理器，以产生一种机器，使得经由计算机或其它可编程数据处理装置的处理器执行的这些指令使能对流程图和/或框图的一个或多个方框中指定的功能/动作的实现。这种处理器可以是但不限于是通用处理器、专用处理器、特殊应用处理器或者现场可编程逻辑电路。还可理解，框图和/或流程图中的每个方框以及框图和/或流程图中的方框的组合，也可以由执行指定的功能或动作的专用硬件来实现，或可由专用硬件和计算机指令的组合来实现。
364.本领域技术人员应能理解，上述实施例均是示例性而非限制性的。在不同实施例中出现的不同技术特征可以进行组合，以取得有益效果。本领域技术人员在研究附图、说明书及权利要求书的基础上，应能理解并实现所揭示的实施例的其他变化的实施例。在权利要求书中，术语“包括”并不排除其他装置或步骤；数量词“一个”不排除多个；术语“第一”、“第二”用于标示名称而非用于表示任何特定的顺序。权利要求中的任何附图标记均不应被理解为对保护范围的限制。权利要求中出现的多个部分的功能可以由一个单独的硬件或软件模块来实现。某些技术特征出现在不同的从属权利要求中并不意味着不能将这些技术特征进行组合以取得有益效果。