NFC支付方法及终端与流程

本申请涉及终端技术领域，尤其涉及一种NFC支付方法及终端。

背景技术：

随着互联网金融的发展，用户通过终端上安装的应用程序(application，APP)进行支付已广泛应用。

常见的APP包括微信支付、支付宝等第三方支付应用。利用第三方支付应用支付时，一种实现方案为：付款方终端扫描收款方提供的二维码或者收款方终端扫描付款方提供的二维码，然后扫描二维码的终端将二维码中携带的内容发送至服务器由服务器进行验证，在验证成功后进行支付。

参考图1，以用户使用手机通过支付宝进行支付为例，用户需要在手机主页界面101打开支付宝应用。用户接着在支付宝应用的显示界面102选择“付款”这一功能，进而支付宝应用加载显示有二维码的界面103。商户的销售点(Point of Sale，POS)终端可扫描该二维码进行收款(图1中以过程104示出)。可见，在扫描二维码支付过程中，用户通常需要操作终端打开第三方支付应用并选择付款功能后调出二维码，用户操作较多。此外，如果终端已锁屏，用户在打开支付宝应用前还需要增加解锁终端的操作。综上所述，现有技术中，在使用第三方支付应用支付时，操作繁琐。

技术实现要素：

本申请实施例提供一种NFC支付方法及终端，用以解决现有技术中使用第三方支付应用支付时操作繁琐的问题。

为达到上述目的，本申请的实施例采用如下技术方案：

第一方面，提供一种NFC支付方法，该方法包括：第一终端根据预设触发条件，显示至少一个第三方支付应用。第一终端将所述至少一个第三方支付应用中的其中一个确定为目标第三方支付应用并通过该目标第三方支付应用与第二终端交互以完成NFC支付。

本申请实施例提供的上述NFC支付方法，第一终端和第二终端之间能够利用第三方支付应用进行NFC支付。与现有技术中通过扫描二维码才能使用第三方支付应用支付相比，本申请实施例提供的上述NFC支付方法能够使得用户碰一下便能利用第三方支付应用进行支付，能够减少用户操作且提升利用第三方支付应用进行支付的速度。

在一种可能的设计中，第一终端根据预设触发条件，显示至少一个第三方支付应用，包括：当第一终端检测到第二终端的射频(Radio Frequency，RF)场时，第一终端显示所述至少一个第三方支付应用。

在一种可能的设计中，第一终端根据预设触发条件，显示至少一个第三方支付应用，包括：第一终端接收用户的快捷操作，并根据所述快捷操作，显示至少一个第三方支付应用。

其中，该快捷操作包括按压预设物理按键、输入预设指纹信息、输入特定语音指令或输入预设手势。

在一种可能的设计中，第一终端确定目标第三方支付应用，包括：第一终端接收用户在所述至少一个第三方支付应用中选择第三方支付应用的选择操作并将用户选择的所述第三方支付应用确定为所述目标第三方支付应用。

在一种可能的设计中，所述第一终端通过所述第一终端和第二终端建立的NFC连接接收第二终端发送的携带有目标第三方支付应用的应用标识(application identification，AID)的应用选择指令。第一终端根据该应用选择指令，显示所述目标第三方支付应用。

在一种可能的设计中，第一终端显示至少一个第三方支付应用的同时，第一终端显示支持NFC支付的卡应用。

在一种可能的设计中，在第一终端通过目标第三方支付应用与第二终端交互以完成NFC支付之前，第一终端确定用户身份验证成功。

在一种可能的设计中，在第一终端通过目标第三方支付应用与第二终端交互以完成NFC支付之后，第一终端提示用户已完成NFC支付。

在一种可能的设计中，第一终端通过目标第三方支付应用与第二终端交互以完成NFC支付，包括：第一终端通过第一终端和第二终端建立的NFC连接接收第二终端发送的用于获取目标第三方支付应用的支付信息的请求消息。第一终端根据该请求消息，通过所述NFC连接向第二终端发送预设格式的响应消息，该预设格式的响应消息中携带目标第三方支付应用的支付信息。

在一种可能的设计中，在第一终端通过第一终端和第二终端建立的NFC连接接收第二终端发送的请求消息之前，第一终端通过已建立的所述NFC连接接收第二终端发送的应用选择指令，该应用选择指令中携带目标第三方支付应用的AID。进而，第一终端根据目标第三方支付应用的AID，确定第一服务，该第一服务为与所述目标第三方支付应用对应的服务。相应的，所述第一终端根据所述请求消息，通过所述NFC连接向第二终端发送预设格式的响应消息，包括：第一终端基于所述第一服务解析所述请求消息，并将目标第三方支付应用的支付信息封装为预设格式的响应消息。第一终端通过已建立的所述NFC连接向第二终端发送所述预设格式的响应消息。

在一种可能的设计中，第一终端存储有目标第三方支付应用的AID和服务类型的对应关系。相应的，第一终端根据目标第三方支付应用的AID，确定第一服务包括：第一终端根据所述对应关系，确定第一服务。

其中，所述第一服务为特定类型的主机卡模拟(Host-based Card Emulation，HCE)服务。

在一种可能的设计中，第一终端存储有所述目标第三方支付应用的注册信息。该注册信息包括目标第三方支付应用的AID和服务类型的表示信息，该注册信息用于确定目标第三方支付应用的AID和服务类型的对应关系。

在一种可能的设计中，第一终端通过所述第一终端和所述第二终端建立的NFC连接接收第二终端发送的请求消息，包括：第一终端通过所述NFC连接接收第二终端发送的读取NFC标签的请求消息。相应的，第一终端根据所述请求消息，通过所述NFC连接向所述第二终端发送预设格式的响应消息，包括：第一终端获取预先生成的NFC标签中存储的所述预设格式的响应消息并通过所述NFC连接向第二终端发送所述预设格式的响应消息。

在一种可能的设计中，在第一终端确定目标第三方支付应用之后，所述方法还包括：第一终端将目标第三方支付应用的支付信息生成预设格式的响应消息，并将该预设格式的响应消息封装为NFC标签。

第二方面，提供一种NFC支付方法，该方法应用于第二终端，该方法包括：第二终端通过第二终端和第一终端建立的NFC连接向第一终端发送用于获取所述第一终端中目标第三方支付应用的支付信息的请求消息。第二终端通过所述NFC连接接收第一终端发送的预设格式的响应消息，该预设格式的响应消息中携带所述目标第三方支付应用的支付信息。第二终端根据所述预设格式的响应消息与目标第三方支付应用的服务器交互以完成NFC支付。

在一种可能的设计中，在第二终端通过第二终端和第一终端建立的NFC连接向第一终端发送请求消息之前，所述方法还包括：第二终端通过第二终端和第一终端建立的NFC连接向第一终端发送应用选择指令，该应用选择指令包含所述目标第三方支付应用的应用标识。第二终端接收第一终端根据应用选择指令发送的应答消息。相应的，第二终端通过第二终端和第一终端建立的NFC连接向所述第一终端发送请求消息，包括：第二终端根据所述应答消息，通过所述第二终端和第一终端建立的NFC连接向第一终端发送所述请求消息。

在一种可能的设计中，第二终端通过第二终端和第一终端建立的NFC连接向第一终端发送请求消息，包括：第二终端通过已建立的所述NFC连接向第一终端发送用于读取NFC标签的所述请求消息。

在一种可能的设计中，所述预设格式的响应消息中还携带功能类型，该功能类型用于表示所述第一终端要执行第一目标功能。相应的，第二终端根据所述预设格式的响应消息与所述目标第三方支付应用的服务器交互以完成NFC支付，包括：第二终端根据所述功能类型确定与所述第一目标功能对应的第二目标功能，并根据所述第二目标功能向所述目标第三方支付应用的服务器发送所述支付信息。

其中，所述功能类型是所述目标第三方支付应用在安装到所述第二终端时向系统注册的，用于表示所述目标第三方支付应用的所述第二目标功能能够处理携带有所述功能类型的消息。可选的，所述功能类型包括付款类型和收款类型。

在一种可能的设计中，实际应用中，可能存在的场景是第二终端既能够与银行卡等卡应用对应的服务器通信，也能够与微信支付等第三方支付应用的服务器进行通信。考虑到此次NFC支付既可能为通过银行卡等卡应用进行的NFC支付，也可能为通过微信支付等第三方支付应用进行的NFC支付。因此，第二终端需要根据此次NFC支付所使用的应用选取相应的服务器以与该服务器建立连接和交互数据。具体的，当用户在第二终端上选择的用于完成此次NFC支付的应用为目标第三方支付应用时或者第二终端与第一终端协商确定此次进行NFC支付的应用为目标第三方支付应用时，或者所述第二终端读取到的第一终端封装生成的NFC标签中携带有应用标识，且该应用标识为目标第三方支付应用的应用标识时，所述第二终端确定要与所述目标第三方支付应用的服务器进行通信，从而建立与所述目标第三方支付应用的服务器建立连接并通信。其中，上述的第二终端与第一终端协商确定，具体是所述第二终端确定通过应用选择指令选择的支付应用是所述第一终端上的所述目标第三方支付应用还是银行卡应用等非第三方支付应用。若是前者，则确定要与所述目标第三方支付应用的服务器进行通信，否则，确定要与银行卡对应的服务器进行通信。

在一种可能的设计中，所述第二终端根据预设格式的响应消息与目标第三方支付应用的服务器交互以完成NFC支付，包括：所述第二终端根据支付风险验证信息进行支付风险判断。在确定无支付风险后，第二终端向目标第三方支付应用的服务器发送目标第三方支付应用的支付信息以请求目标第三方支付应用的服务器完成NFC支付。

其中，该支付风险验证信息由所述预设格式的响应消息携带或由所述第二终端从所述目标第三方支付应用的服务器获取得到。

在一种可能的设计中，所述支付风险验证信息包括所述第一终端的位置信息。则相应的，第二终端根据支付风险验证信息进行支付风险判断，包括：第二终端确定所述第二终端的位置信息。当所述第二终端的位置信息和所述第一终端的位置信息匹配时，所述第二终端确定无支付风险。

在一种可能的设计中，所述第二终端根据所述预设格式的响应消息与所述目标第三方支付应用的服务器交互以完成NFC支付，包括：第二终端向所述目标第三方支付应用的服务器发送目标第三方支付应用的支付信息，以便于目标第三方支付应用的服务器根据该支付信息进行支付验证以及根据支付风险验证信息进行支付风险判断，并在支付验证成功和确定无支付风险时完成NFC支付。

其中，所述支付风险验证信息从所述第二终端获取得到或由所述目标第三方支付应用的服务器本地生成。

在一种可能的设计中，所述第二终端根据所述预设格式的响应消息与所述目标第三方支付应用的服务器交互以完成NFC支付，包括：第二终端向目标第三方支付应用的服务器发送所述目标第三方支付应用的支付信息。第二终端接收所述目标第三方支付应用的服务器发送的身份验证请求。第二终端根据支付风险验证信息进行支付风险判断，在确定无支付风险后，向所述目标第三方支付应用的服务器发送身份验证结果以便于所述目标第三方支付应用的服务器根据所述身份验证结果以及所述支付信息完成NFC支付。

其中，所述支付风险验证信息由所述预设格式的响应消息携带或由所述第二终端从所述目标第三方支付应用的服务器获取得到。

第三方面，提供一种NFC支付方法，包括：第一终端显示第一界面，所述第一界面显示有至少一个第三方支付应用的图标。第一终端接收用户在所述第一界面中选择目标第三方支付应用的图标的选择操作。响应于所述选择操作，第一终端和第二终端通过所述目标第三方支付应用交互以完成NFC支付。

在一种可能设计中，第一终端显示第一界面，包括：在第一终端处于锁屏状态时，第一终端接收用户输入的快捷操作，响应于所述快捷操作，第一终端显示第一界面。

其中，所述快捷操作包括按压预设物理按键、输入预设指纹信息、输入特定语音指令或输入预设手势；

在一种可能设计中，所述第一终端显示第一界面，包括：当第一终端触碰所述第二终端时，第一终端显示第一界面。

在一种可能设计中，在第一终端和第二终端交互以完成NFC支付之前，响应于所述选择操作，第一终端显示第二界面，该第二界面显示有第一提示信息，该第一提示信息用于提示用户进行身份验证。相应的，响应于用户身份验证成功的操作，所述第一终端和第二终端交互以完成NFC支付。

在一种可能的设计中，在第一终端和第二终端交互以完成NFC支付之后，第一终端显示第二提示信息，所述第二提示信息用于提示用户已完成NFC支付。

第四方面，提供一种终端，所述终端作为第一终端包括一个或多个处理器、显示器以及存储器；其中，所述存储器中存储一个或多个程序，所述一个或多个程序包括指令，当所述指令被所述第一终端执行时，使得所述第一终端执行以下步骤：根据预设触发条件，所述显示器显示至少一个第三方支付应用；所述处理器在所述显示器显示的所述至少一个第三方支付应用中确定目标第三方支付应用并通过所述目标第三方支付应用与第二终端交互以完成NFC支付。

在一种可能的设计中，所述显示器，还用于当所述处理器检测到所述第二终端的射频场时，显示所述至少一个第三方支付应用。

在一种可能的设计中，所述第一终端还包括：输入设备。所述输入设备，用于接收用户的快捷操作，所述快捷操作包括按压预设物理按键、输入预设指纹信息、输入特定语音指令或输入预设手势。所述显示器，还用于根据所述输入设备接收的所述快捷操作，显示至少一个第三方支付应用。

在一种可能的设计中，所述输入设备，还用于接收用户在所述至少一个第三方支付应用中选择第三方支付应用的选择操作。所述处理器，还用于将用户选择的所述第三方支付应用确定为所述目标第三方支付应用。

在一种可能的设计中，所述显示器，还用于在显示至少一个第三方支付应用的同时，显示支持NFC支付的卡应用。

在一种可能的设计中，所述处理器，还用于确定用户身份验证成功。

在一种可能的设计中，所述显示器，还用于显示提示用户已完成NFC支付的提示信息。

在一种可能的设计中，所述终端作为第一终端还包括接收器和发送器。其中，所述接收器，用于通过所述第一终端和所述第二终端建立的NFC连接接收所述第二终端发送的请求消息，所述请求消息用于获取所述目标第三方支付应用的支付信息。所述发送器，用于通过所述NFC连接向所述第二终端发送预设格式的响应消息，所述预设格式的响应消息中携带所述目标第三方支付应用的支付信息。

在一种可能的设计中，所述接收器，还用于通过所述第一终端和所述第二终端建立的NFC连接接收所述第二终端发送的应用选择指令，所述应用选择指令中携带所述目标第三方支付应用的AID。所述处理器，还用于根据所述目标第三方支付应用的AID，确定第一服务，所述第一服务为与所述目标第三方支付应用对应的服务。所述处理器，还用于基于所述第一服务解析所述请求消息，并将所述目标第三方支付应用的支付信息封装为预设格式的响应消息。所述发送器，还用于通过所述NFC连接向所述第二终端发送所述预设格式的响应消息。

在一种可能的设计中，所述存储器中存储有所述目标第三方支付应用的AID和服务类型的对应关系。所述处理器，还用于根据所述对应关系，确定所述第一服务。

在一种可能的设计中，所述存储器中存储有所述目标第三方支付应用的注册信息，所述注册信息包括所述目标第三方支付应用的AID和服务类型的表示信息；所述注册信息用于确定所述目标第三方支付应用的AID和服务类型的对应关系。

在一种可能的设计中，所述接收器，还用于通过所述第一终端和所述第二终端建立的NFC连接接收所述第二终端发送的读取NFC标签的请求消息。所述处理器，还用于获取预先生成的NFC标签中存储的所述预设格式的响应消息。所述发送器，还用于通过所述NFC连接向所述第二终端发送所述预设格式的响应消息。

在一种可能的设计中，所述处理器，还用于将所述目标第三方支付应用的支付信息生成预设格式的响应消息，并将所述预设格式的响应消息封装为NFC标签。

第五方面，提供一种终端，所述终端作为第二终端包括：一个或多个处理器、发送器、接收器和存储器；其中，所述存储器中存储一个或多个程序，所述一个或多个程序包括指令，当所述指令被所述第二终端执行时，使得所述第二终端执行以下步骤：所述发送器通过所述第二终端和第一终端建立的NFC连接向所述第一终端发送请求消息，所述请求消息用于获取所述第一终端中目标第三方支付应用的支付信息。所述接收器通过所述NFC连接接收所述第一终端发送的预设格式的响应消息，所述预设格式的响应消息中携带所述目标第三方支付应用的支付信息。所述处理器根据所述预设格式的响应消息与所述目标第三方支付应用的服务器交互以完成NFC支付。

在一种可能的设计中，所述发送器，还用于通过所述第二终端和第一终端建立的NFC连接向所述第一终端发送应用选择指令，所述应用选择指令包含所述目标第三方支付应用的应用标识。所述接收器，还用于接收所述第一终端根据所述应用选择指令发送的应答消息。所述第二终端发送器，还用于根据所述应答消息，通过所述第二终端和第一终端建立的NFC连接向所述第一终端发送所述请求消息。

在一种可能的设计中，所述发送器，还用于通过所述第二终端和第一终端建立的NFC连接向所述第一终端发送用于读取NFC标签的所述请求消息。

在一种可能的设计中，所述预设格式的响应消息中还携带功能类型；所述功能类型用于表示所述第一终端要执行第一目标功能。则所述处理器，还用于根据所述功能类型确定与所述第一目标功能对应的第二目标功能。所述发送器，还用于根据所述第二目标功能向所述目标第三方支付应用的服务器发送所述支付信息。

其中，所述功能类型是所述目标第三方支付应用在安装到所述第二终端时向系统注册的，用于表示所述目标第三方支付应用的所述目标功能能够处理包括所述功能类型的消息。可选的，所述功能类型包括付款和收款。

在一种可能的设计中，所述处理器，还用于根据支付风险验证信息进行支付风险判断。所述发送器，还用于在确定无支付风险后，向所述目标第三方支付应用的服务器发送所述目标第三方支付应用的支付信息以请求所述目标第三方支付应用的服务器完成NFC支付。

其中，所述支付风险验证信息由所述预设格式的响应消息携带或由所述第二终端从所述目标第三方支付应用的服务器获取得到。

在一种可能的设计中，所述支付风险验证信息包括所述第一终端的位置信息。所述处理器，还用于确定所述第二终端的位置信息。当所述第二终端的位置信息和所述第一终端的位置信息匹配时，所述第二终端确定无支付风险。

在一种可能的设计中，所述发送器，还用于向所述目标第三方支付应用的服务器发送所述目标第三方支付应用的支付信息，以便于所述目标第三方支付应用的服务器根据所述支付信息进行支付验证以及根据支付风险验证信息进行支付风险判断，并在支付验证成功和确定无支付风险时完成NFC支付。

其中，所述支付风险验证信息从所述第二终端获取得到或由所述目标第三方支付应用的服务器本地生成。

在一种可能的设计中，所述发送器，还用于向所述目标第三方支付应用的服务器发送所述目标第三方支付应用的支付信息。所述接收器，还用于接收所述目标第三方支付应用的服务器发送的身份验证请求。所述处理器，还用于根据支付风险验证信息进行支付风险判断，所述支付风险验证信息由所述预设格式的响应消息携带或由所述第二终端从所述目标第三方支付应用的服务器获取得到。所述发送器，还用于在确定无支付风险后，向所述目标第三方支付应用的服务器发送身份验证结果以便于所述目标第三方支付应用的服务器根据所述身份验证结果以及所述支付信息完成NFC支付。

第六方面，提供一种终端，所述终端作为第一终端包括一个或多个处理器、显示器、输入设备以及存储器；其中，所述存储器中存储一个或多个程序，所述一个或多个程序包括指令，当所述指令被所述第一终端执行时，使得所述第一终端执行以下步骤：所述显示器显示第一界面，所述第一界面显示有至少一个第三方支付应用。所述输入设备接收用户在所述第一界面中选择目标第三方支付应用的选择操作。所述处理器，响应于所述选择操作和第二终端通过所述目标第三方支付应用交互以完成NFC支付。

在一种可能的设计中，所述输入设备，还用于在所述第一终端处于锁屏状态时，接收用户输入的快捷操作。所述显示器还用于响应于所述快捷操作，显示第一界面。

其中，所述快捷操作包括按压预设物理按键、输入预设指纹信息、输入特定语音指令或输入预设手势。

在一种可能的设计中，所述显示器，还用于当所述第一终端触碰所述第二终端时，显示第一界面。

在一种可能的设计中，所述显示器，还用于响应于所述选择操作，显示第二界面，所述第二界面显示有第一提示信息，所述第一提示信息用于提示用户进行身份验证。所述处理器，还用于响应于用户身份验证成功的操作，和第二终端交互以完成NFC支付。

在一种可能的设计中，所述显示器，还用于显示第二提示信息，所述第二提示信息用于提示用户已完成NFC支付。

第七方面，提供一种计算机可读存储介质，所述计算机可读存储介质中存储有指令，其特征在于，当所述指令在终端上运行时，使得所述终端执行第一方面所述的NFC支付方法。

第八方面，提供一种包含指令的计算机程序产品，其特征在于，当所述计算机程序产品在终端上运行时，使得所述终端执行第一方面所述的NFC支付方法。

第九方面，提供一种计算机可读存储介质，所述计算机可读存储介质中存储有指令，其特征在于，当所述指令在终端上运行时，使得所述终端执行第二方面所述的NFC支付方法。

第十方面，提供一种包含指令的计算机程序产品，当所述计算机程序产品在终端上运行时，使得所述终端执行第二方面所述的NFC支付方法。

附图说明

图1为现有技术中第三方支付应用通过二维码进行支付的过程示意图；

图2a为本申请实施例提供的NFC支付方法的一种应用场景示意图；

图2b为本申请实施例提供的NFC支付方法的另一种应用场景示意图；

图3为本申请实施例提供的手机的结构示意图；

图4为本申请实施例提供的一种NFC支付方法的流程示意图；

图5为手机中NFC功能的设置界面示意图；

图5a为本申请实施例提供的一种NFC支付方法的过程示意图；

图5b为本申请实施例提供的又一种NFC支付方法的过程示意图；

图6、图7、图8为本申请实施例提供的再一种NFC支付方法的过程示意图；

图9a、图9b为本申请实施例提供的第三方支付应用注册HCE服务的实现过程示意图；

图10a、图10b、图10c、图11a、图11b以及图11c为本申请实施例提供的NFC支付方法的流程示意图；

图12a、图12b、图12c以及图12d为本申请实施例提供的第一终端的结构示意图；

图13a、图13b以及图13c为本申请实施例提供的第二终端的结构示意图。

具体实施方式

近场通信(Near Field Communication，NFC)是一种基于射频识别(Radio Frequency Identification，RFID)技术的短距离无线连接技术。NFC技术利用射频场感应实现NFC终端的近距离通信，两个NFC终端通过触碰或者靠近，即可实现快速、安全和非接触式的交换信息、内容和交易。

具体来说，NFC终端的工作模式可分为三种：一、点对点模式(Peer-to-Peer，P2P)，该模式具体应用于名片分享、网页分享等场景。二、卡模拟模式(Card Emulation，CE)，该模式具体用于如银行卡、交通卡、会员卡、优惠券、身份证等移动支付或身份验证场景。三、读写器模式(Reader/Writer，R/W)，该模式具体用于银行卡销售点终端(Point of Sale，POS)机、公交卡POS机等移动支付或身份验证场景，以及标签读/写场景。

以所述NFC终端为手机为例，目前，当手机上安装有由银行等金融机构提供的卡应用时，手机可工作在卡模拟的工作模式下完成支付。也即通过在手机上下载与安装卡应用，将卡应用于物理卡绑定实现手机的卡模拟，可代替传统的物理集成电路(IC，Integrated Circuit)卡，直接使用手机完成支付。

但是，当用户更换手机时，需要重新执行上述下载、安装卡应用以及将卡应用与物理卡绑定的绑卡过程。因此，该实现方式在用户更换手机的场景下对用户而言使用较为不便。

与卡应用相比，微信、支付宝等第三方支付应用为与用户的账号密码相对应的，其不受用户是否更换手机的影响。也即用户只要在任意手机上登录已注册的账号密码等账户信息便可使用第三方支付应用进行支付。因此，从该维度讲，第三方支付应用更为便利。然而，第三方支付应用在支付时通常是通过扫描二维码的方式实现支付，从该维度讲，其存在操作繁琐、支付速度慢的缺点。此外，还可能存在用户的资金损失等安全风险，如商户二维码被恶意替换导致的交易资金无法被支付到商户账户，或者，消费者手机生成的二维码被恶意第三方截获后用在其他地方进行付款导致的消费者资金被盗刷等。

为了解决现有技术中第三方支付应用通过扫描二维码实现支付存在的操作繁琐、支付速度慢以及可能存在的安全风险等问题，同时为了避免现有的手机卡模拟方法存在的更换手机就需要下载与绑定卡应用的问题，本申请实施例将现有的第三方支付应用与NFC技术结合起来提供一种使用第三方支付应用进行NFC支付的方法。

本申请实施例提供的所述NFC支付方法应用在两个支持NFC功能的不同终端之间进行支付的场景。为便于描述，本申请实施例将所述两个支持NFC功能的不同终端称为第一终端和第二终端。其中，第一终端可以为手机、平板电脑、笔记本电脑、超级移动个人计算机、上网本、个人数字助理、可穿戴设备等。第二终端也可以为手机、平板电脑、笔记本电脑、可穿戴设备、POS机等设备。

示例性的，如图2a所示，本申请实施例所指的第一终端可以为手机100，第二终端可以为POS终端200。

示例性的，如图2b所示，本申请实施例所指的第一终端和第二终端均可以为手机100。

本申请实施例所指的第一终端和第二终端均支持NFC功能。且第一终端和第二终端中安装能够支持第三方支付的应用，也即第三方支付应用。

其中，本申请实施例所指的第三方支付应用主要是指支付服务提供机构提供的、具有线上绑卡功能的应用(可理解的是，第三方支付应用的账户与其线上绑定的卡片的关联记录在服务器端进行保存即可，不需要在终端本地下载卡应用及其个人化数据来模拟卡片)。也就是说，本申请实施例所说的第三方支付应用包括但不限于仅提供线上绑卡与线上支付功能的应用，或者，至少提供线上绑卡与线上支付功能的应用。例如：所述第三方支付应用包括微信、支付宝等。

需要说明的是，本申请实施例所述的第三方支付应用，通常不包括具有线下NFC支付功能的支付应用，例如：为了实现卡模拟功能，需要在终端本地下载卡应用与个人化数据的支付应用，如各种银行卡应用等。

以所述第一终端和第二终端均为手机为例，如图3所示，手机300包括：

射频(radio frequency，RF)电路310、存储器320、输入单元330、NFC芯片340、处理器350、电源360、显示单元370、重力传感器380、音频电路390等部件。本领域技术人员可以理解，图3中示出的手机结构并不构成对手机的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。

下面分别对手机300的各功能组件进行介绍：

其中，RF电路310可用于收发信息或通话过程中，信号的接收和发送，特别地，将基站的下行信息接收后，给处理器350处理；另外，将上行的数据发送给基站。通常，RF电路包括但不限于天线、至少一个放大器、收发信机、耦合器、低噪声放大器(low noise amplifier，LNA)、双工器等。此外，RF电路310还可以通过无线通信与网络和其他设备通信。所述无线通信可以使用任一通信标准或协议，包括但不限于全球移动通讯系统(global system of mobile communication，GSM)、通用分组无线服务(general packet radio service，GPRS)、码分多址(code division multiple access，CDMA)、宽带码分多址(wideband code division multiple access,WCDMA)、长期演进(long term evolution,LTE)、电子邮件、短消息服务(short messaging service，SMS)等。

存储器320可用于存储软件程序以及模块，该处理器350通过运行存储在存储器320的软件程序以及模块，从而执行手机300的各种功能应用以及数据处理。存储器320可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序(Application，APP)等，比如声音播放功能、图像播放功能等；存储数据区可存储根据手机300的使用所创建的数据(比如音频数据、图像数据、电话本等)等。此外，存储器320可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。

输入单元330可用于接收输入的数字或字符信息，以及产生与手机300的用户设置以及功能控制有关的键信号输入。具体地，输入单元330可包括触摸屏331以及其他输入设备332。触摸屏331，也称为触控面板，可收集用户在其上或附近的触摸操作(比如用户使用手指、触笔等任何适合的物体或附件在触摸屏331上或在触摸屏331附近的操作)，并根据预先设定的程式驱动相应的连接装置。可选的，触摸屏331可包括触摸检测装置和触摸控制器两个部分。其中，触摸检测装置检测用户的触摸方位，并检测触摸操作带来的信号，将信号传送给触摸控制器；触摸控制器从触摸检测装置上接收触摸信息，并将它转换成触点坐标，再送给处理器350，并能接收处理器350发来的命令并加以执行。此外，可以采用电阻式、电容式、红外线以及表面声波等多种类型实现触摸屏331。除了触摸屏331，输入单元330还可以包括其他输入设备332。具体地，其他输入设备332可以包括但不限于物理键盘、功能键(比如音量控制按键、电源开关按键等)、轨迹球、鼠标、操作杆等中的一种或多种。

NFC芯片340包括NFC控制器(Near Field Communication Cntroller，NFCC)341，其功能包括射频信号的调制解调以及NFC协议处理。NFCC341连接射频天线(即NFC天线)实现NFC信号的发送与接收。

可选的，为了实现NFC支付，手机中还可能包括安全模块(security element，SE)。SE用于对敏感信息的安全存储和对交易事务提供安全的执行环境，可以集成在处理器350中，或者位于手机的客户识别模块(Subscriber Identification Module，SIM)卡，或者位于手机的安全数字存储卡(Secure Digital Memory Card，SD)中，也可以为独立的芯片。NFCC可以和SE互相连接。

显示单元370可用于显示由用户输入的信息或提供给用户的信息以及手机300的各种菜单。显示单元370可包括显示面板371，可选的，可以采用液晶显示器(Liquid Crystal Display，LCD)、有机发光二极管(Organic Light-Emitting Diode,OLED)等形式来配置显示面板371。进一步的，触摸屏331可覆盖显示面板371，当触摸屏331检测到在其上或附近的触摸操作后，传送给处理器350以确定触摸事件的类型，随后处理器350根据触摸事件的类型在显示面板371上提供相应的视觉输出。虽然在图3中，触摸屏331与显示面板371是作为两个独立的部件来实现手机300的输入和输入功能，但是在某些实施例中，可以将触摸屏331与显示面板371集成而实现手机300的输入和输出功能。

重力传感器(gravity sensor)380，可以检测手机在各个方向上(一般为三轴)加速度的大小，静止时可检测出重力的大小及方向，可用于识别手机姿态的应用(比如横竖屏切换、相关游戏、磁力计姿态校准)、振动识别相关功能(比如计步器、敲击)等。

手机300还可以包括其它传感器，比如光传感器。具体地，光传感器可包括环境光传感器及接近光传感器。其中，环境光传感器可根据环境光线的明暗来调节显示面板331的亮度；接近光传感器可以检测是否有物体靠近或接触手机，可在手机300移动到耳边时，关闭显示面板331和/或背光。手机300还可配置的陀螺仪、气压计、湿度计、温度计、红外线传感器等其他传感器，在此不再赘述。

音频电路390、扬声器391、麦克风392可提供用户与手机300之间的音频接口。音频电路390可将接收到的音频数据转换后的电信号，传输到扬声器391，由扬声器391转换为声音信号输出；另一方面，麦克风392将收集的声音信号转换为电信号，由音频电路390接收后转换为音频数据，再将音频数据输出至RF电路310以发送给比如另一手机，或者将音频数据输出至存储器320以便进一步处理。

处理器350是手机300的控制中心，利用各种接口和线路连接整个手机的各个部分，通过运行或执行存储在存储器320内的软件程序和/或模块，以及调用存储在存储器320内的数据，执行手机300的各种功能和处理数据，从而对手机进行整体监控。可选的，处理器350可包括一个或多个处理单元；可选的，处理器350可集成应用处理器和调制解调处理器，其中，应用处理器主要处理操作系统、用户界面和应用程序等，调制解调处理器主要处理无线通信。可以理解的是，上述调制解调处理器也可以不集成到处理器350中。

手机300还包括给各个部件供电的电源360(比如电池)，可选的，电源可以通过电源管理系统与处理器350逻辑相连，从而通过电源管理系统实现管理充电、放电、以及功耗管理等功能。

尽管未示出，手机300还可以包括天线、无线保真(Wireless-Fidelity，WiFi)模块、近距离无线通信(Near Field Communication,NFC)模块、蓝牙模块、扬声器、加速计、陀螺仪等。

本申请实施例提供一种NFC支付方法，可应用于图2a或图2b所示的场景。如图4所示，该方法包括以下步骤：

401、第一终端根据预设触发条件，显示至少一个第三方支付应用。

402、所述第一终端确定目标第三方支付应用。

其中，所述目标第三方支付应用为所述至少一个第三方支付应用中的一个

403、第一终端通过所述目标第三方支付应用与第二终端交互以完成NFC支付。

可选的，在一种实现方式中，从用户可见的角度而言，该预设触发条件包括所述第一终端触碰第二终端。具体的，所述第一终端触碰第二终端是指第一终端和第二终端的距离在NFC协议规定的通信距离内，第一终端和第二终端能够进行NFC通信。

尽管对用户而言，第一终端触碰第二终端，仅为“碰一下”这样一个简单的动作且持续时间很短，但第一终端和第二终端之间实际上经过了第一终端和第二终端建立NFC连接、射频(Radio Fre)发现、第一终端接收到第二终端发送的应用选择指令(select AID)、第一终端根据该应用选择指令进行响应等NFC交互过程。

第二终端工作在读写模式或点对点模式时，第二终端可向外发射NFC信号以提供射频场。因此，可选的，在一种实现方式中，“所述第一终端触碰第二终端”具体为第一终端检测到第二终端的射频场。在该触发条件下，第一终端显示支持NFC支付的应用列表。该应用列表中显示有包括所述目标第三方支付应用在内的至少一个第三方支付应用。

具体实现中，该应用列表中所显示的应用可以为第一终端默认设置的用于进行NFC支付的应用，也可以为用户在第一终端的设置界面设置的用于进行NFC支付的应用。其中，应用列表中，应用的排序可能是终端默认设置的，如给出的选择列表的顺序就是默认顺序，也可能是用户设置的。

在该实现方式中，由于显示的应用列表中包括多个应用，因此，在第一终端通过目标第三方支付应用与第二终端交互以完成NFC支付之前，第一终端接收用户在显示的所述至少一个第三方支付应用中选择第三方支付应用的操作，并将用户选择的第三方支付应用作为目标第三方支付应用，进而第一终端激活目标第三方支付应用并通过该目标第三方支付应用与第二终端交互以完成NFC支付。其中，在激活目标第三方支付应用后，该目标第三方支付应用或其相关信息能够被第二终端发现或选中。其中，若目标第三方支付应用作为一种卡模拟应用被第二终端发现，则激活该目标第三方支付应用意味着将与卡模拟相关的RF技术或RF协议参数配置给NFC芯片，该过程具体可参考NFC协议标准。若目标第三方支付应用提供NFC标签(Tag)给第二终端，则激活该目标第三方支付应用意味着将NFC标签相关的RF技术或RF协议参数配置给NFC芯片，该过程具体可参考NFC协议标准。

可选的，在另一种实现方式中，“所述第一终端触碰第二终端”具体为在第一终端和第二终端建立NFC连接后，第一终端接收到第二终端发送的应用选择指令。由于该应用选择指令中携带用于进行此次NFC支付的应用的AID(本申请实施例应用在第三方支付应用作为进行NFC支付的场景，因此，该应用选择指令中携带目标第三方支付应用的AID)。因此，第一终端显示的应用列表中可能仅包括该目标第三方支付应用。可选的，当第一终端的界面仅显示目标第三方支付应用时，用户可再次进行确认操作以激活该目标第三方支付应用。

当然，在该实现方式中，为了支持用户选择其他应用重新开始本次交易，则在显示所述目标第三方支付应用的同时还可显示其他应用。

可选的，该预设触发条件还包括用户按压预设物理按键、输入预设指纹信息、输入特定语音指令、输入预设手势、在指纹传感器上的特定按压力度或特定手势、人脸识别、扫描特定图标以及检测到第一终端处于特定位置(如银行、商场等)等快捷触发方式。当所述第一终端检测到上述任意一种快捷触发方式时，显示所述包含至少一个第三方支付应用的应用列表。

可选的，在利用目标第三方支付应用进行NFC支付之前，第一终端提示用户进行身份验证，在身份验证成功后利用该目标第三方支付应用完成此次NFC支付。提示用户进行身份验证的方式包括：显示指纹识别区提示信息以提示用户在所述指纹识别区进行指纹识别，指纹识别成功后，利用目标第三方支付应用进行NFC支付。还包括：提示输入密码、提示用户输入特定手势、提示用户输入语音信息等。

可选的，第一终端是否对用户进行身份验证由第一终端根据本次交易金额决定，当交易金额较大，超过一定额度时，提示用户验证身份。当交易金额较小，小于一定额度时，则无需提示用户进行身份验证。当然，还可能根据本次交易的时间、位置等信息来决定是否要求用户进行身份验证，如预先采用大数据分析等方法统计出用户通常交易的时间范围或者位置范围，将该时间范围设定为安全时间范围，将该位置范围设定为安全位置范围。则如果当前交易时间与安全时间范围相匹配；或者，当前位置与安全位置范围相匹配时，无需要求用户进行身份验证。否则，提示用户验证身份。

可选的，在第一终端通过所述目标第三方支付应用与第二终端交互并完成NFC支付后，第一终端提示用户已完成NFC支付。该提示方式可以为在第一终端上显示提示信息以及支付金额等信息，可以以短信方式提示，也可以以语音、震动等其他方式提示，本申请实施例不限定提示方式。

需要说明的是，在以下情况时，第一终端无需显示支付应用列表。这些情况至少包括：用户仅设置某个特定第三方支付应用为默认支付应用时，则第一终端在检测到预设触发条件后可直接确定其为目标第三方支付应用，并不显示上述应用列表。或者，在第一终端在检测到预设触发条件后直接将优先级最高的或用户使用最频繁的支付应用确定为目标第三方支付应用。

本申请实施例提供的上述NFC支付方法，第一终端和第二终端之间能够利用第三方支付应用进行NFC支付。与现有技术中通过扫描二维码才能使用第三方支付应用支付相比，本申请实施例提供的上述NFC支付方法能够使得用户碰一下便能利用第三方支付应用进行支付，能够减少用户操作且提升利用第三方支付应用进行支付的速度。

为了更清楚的说明本申请实施例提供的上述方法，结合图2a所示的应用场景对本申请实施例提供的方法进行具体阐述。

示例性的，参考图5，用户在手机100的设置界面500进行设置，将“微信支付”、“支付宝”和“PAY”这些应用设定为第一终端默认进行NFC支付的应用。

其中，“微信支付”和“支付宝”为本申请实施例所指的第三方支付应用。“PAY”为第一终端预先安装的应用，可能为手机制造商预置的应用或者称之为系统自带应用，能够承载银行卡、公交卡等支持NFC支付的卡模拟应用，如HCE应用。在其他实现方式中，HCE应用也可能并未承载在手机系统自带的特定应用中，为用户直接在手机上安装。HCE应用在进行NFC支付时的具体实现可参考现有技术，此处不再赘述。

参考图5a，当手机100靠近POS终端200时(图5a中以过程501示出)，手机100显示界面502a，该界面502a显示手机100上可用于进行NFC支付的应用列表，该应用列表中分别显示有“微信支付”、“支付宝”这两个第三方支付应用以及“PAY”中安装的“中国银行”、“招商银行”、“市政交通一卡通”等支持NFC支付的卡应用。手机接收用户在界面502a显示的应用列表中选择“微信支付”的选择操作后，显示界面503。该界面503中显示指纹验证信息提示用户进行指纹验证，在指纹验证成功后，手机100将微信支付确定为目标第三方支付应用。手机100和POS终端200利用微信支付完成此次NFC支付，并在微信支付结束后显示界面504，该界面504中显示提示用户已完成微信支付的提示信息并显示支付金额等相关信息。当然，也可以跳过界面502a，当用户通过界面503验证身份后，即认为用户一并完成了选择的操作，在该界面503中，用户也可以通过如单击其他应用图标来切换应用。

可选的，“微信支付”也可以作为“PAY”中增加的支付应用，可理解为在“PAY”中绑定微信支付这些第三方支付应用，这样，可将已绑定的这些第三方支付应用看做是一种特殊的卡应用，与“PAY”中已绑定的其他银行卡应用类似。在这种情况下，作为界面502a的一种替换形式，参考图5b，当手机100触碰POS终端200时，手机100显示界面502b，该界面502b中显示“PAY”中所显示的所有应用，包括“中国银行”、“招商银行”、“市政交通一卡通”以及“微信支付”、“支付宝支付”。

示例性的，参考图6，手机100在触碰POS终端200时(如图6中过程601所示)，手机100显示界面602，该界面602显示的应用列表中仅包括微信支付。一种可能的原因是在手机100触碰POS终端200时，POS终端200向手机100发送selecet AID指令，且该select AID指令中携带了微信支付的AID。再一种可能的原因是手机100上只设置了微信支付为默认应用，或者，手机100自动根据应用的优先级或使用频率等条件筛选出微信支付。手机100接收用户在界面602的确认操作后，手机显示界面603提示用户进行指纹验证。指纹验证成功后，手机100和POS终端200利用微信支付完成此次NFC支付，并在微信支付结束后显示界面604，该界面604中显示提示用户已完成微信支付的提示信息并显示支付金额。

需要说明的是，上述图5a、图5b和图6中验证指纹的操作，可以在手机靠近POS终端的过程中进行。也可以是在手机离开POS终端后进行，这种情况下，当用户完成指纹验证后，需要再次靠近POS终端即可接着进行NFC支付。为了保证通过这种“手机两次靠近POS终端”的方式进行NFC支付时，NFC支付的过程不会中断，一种可能的实现方式是在手机第一次靠近POS终端过程中或离开POS终端之后，手机记录用户选择微信支付作为目标第三方支付应用的操作，则当手机再次靠近POS终端时，相当于手机已经激活了微信支付可继续完成后续过程。其中，如果在选择微信支付后还进行了身份验证操作，则在身份验证成功后，手机将该验证成功的有效性保持一定时间。因此，只要在一定时间内手机再次靠近POS终端，就可以直接使用目标第三方支付应用完成此次NFC支付，能够免去再次验证身份的过程。

参考图7，在其他实现方式中，当交易金额较小(如小于预设额度)时，手机100触碰POS终端200时(该过程以图7中的过程701示出)，无需要求用户验证身份，而是手机100和POS终端200直接利用微信支付完成NFC支付，并在完成NFC支付后显示提示界面702，用于提示用户已完成微信支付并显示支付金额等信息。

参考图8，在其他实现方式中，用户在手机100的锁屏界面输入预设手势(图8中以过程801示出)后，手机100显示界面802。该界面802中显示手机100中能够进行NFC支付的应用列表，该应用列表中分别显示有“微信支付”、“支付宝支付”等第三方支付应用和“PAY”中安装的“中国银行”、“招商银行”、“市政交通一卡通”等支持NFC支付的卡应用。手机100接收用户在界面802中选择“微信支付”的选择操作后，显示界面803。该界面803中显示指纹验证信息提示用户进行指纹验证。在指纹验证成功后，手机显示界面804，该界面804显示有提示用户身份验证成功的提示信息。当手机100触碰POS终端200(该过程以过程805示出)后，手机100和POS终端200利用微信支付完成此次NFC支付，并在微信支付结束后显示界面806。该界面806中显示提示用户已完成微信支付的提示信息并显示支付金额。

上述图4、图5a、图6、图7、图8所示的方法，可以应用在第一终端处于已解锁场景，也可以应用在第一终端处于未解锁的状态，如第一终端锁屏或息屏的场景。当应用在锁屏或息屏场景下时，本申请实施例还能够省去用户解锁第一终端的步骤，进一步减少用户操作，并实现快速支付。

为了实现图4、图5a、图6、图7、图8所示的过程，在一种实现方式中，目标第三方支付应用向第一终端注册特定类型的HCE服务，然后第一终端基于该特定类型的HCE服务与第二终端交互以利用目标第三方支付应用完成NFC支付。

其中，本申请实施例所指的特定类型的HCE服务用于与现有技术中的银行卡等HCE应用注册的HCE服务进行区分。当第一终端中既包括第三方支付应用，又包括招商银行、中国银行等银行卡的HCE应用时，银行卡类应用注册至现有技术中定义的HCE服务，第三方支付应用在安装时注册至该特定类型的HCE服务，进而第三方支付应用可看作一种特殊类型的HCE应用。

此外，本申请实施例中该特定类型的HCE服务用于在应用选择指令(如ISO/IEC 7816-4定义的SELECT命令)中携带的AID为目标第三方支付应用的AID时，解析该应用选择指令并进行应答，以及采用预设协议进行后续的NFC支付的交互过程，例如：第一终端向第二终端发送目标第三方支付应用的支付信息的过程。这里所说的预设协议可以为第一终端的系统开发者定义的，则该特定类型的HCE服务相当于系统开发者专门提供给各个第三方支付应用的接口。当然，该预设协议也可以为通过其他方式定义的，如某个或某些第三方支付应用与系统开发者合作定义。

对于上述特定类型的HCE服务，在一种实现方式中，它可以是第一终端系统专门为第三方支付应用提供的独立服务，即第三方支付应用可单独调用该服务对应的接口来实现NFC支付。

具体的，参考图9a，在一种实现方式中，第一终端扩展HCE服务类型，例如新增一种服务类型：HostApduSpecificService。这样，银行卡等HCE应用的注册信息中携带的用于表示HCE服务类型的表示信息为HostApduService，第三方支付应用的注册信息中携带的用于表示HCE服务类型的表示信息为HostApduSpecificService。在另一种实现方式中，将目前的HCE服务类型HostApduService修改为HostApduCommonService，表示目前的银行卡等HCE应用对应的HCE服务类型。将本申请实施例所指的特定类型的HCE服务表示为HostApduSpecificService，表示特定特定HCE服务类型。这样，银行卡等HCE应用的注册信息中携带的用于表示HCE服务类型的表示信息为HostApduCommonService，第三方支付应用中携带的用于表示HCE服务类型的表示信息为HostApduSpecificService。第一终端保存每个应用的AID和HCE服务类型表示信息的对应关系。

在上述实现方式中，第一终端保存每个应用的AID和HCE服务类型的对应关系。进而在获取了应用的AID后，根据存储的该AID对应的HCE服务类型确定其对应的HCE服务类型。

在上述实现方式中，相当于第一终端的系统给上层应用提供了特定类型的HCE服务和普通类型的HCE服务两个服务接口。其中，上述特定类型的HCE服务适用于微信支付等第三支付服务提供商提供的应用，即注册该特定类型的HCE服务的应用是微信支付等第三方支付应用。而现有HCE服务或者修改后的普通HCE服务适用于银行等机构发行的卡应用，即注册该普通HCE服务的应用是目前常见的银行卡、会员卡等卡应用。

对于上述特定类型的HCE服务，在另一种实现方式中，上述特定类型的HCE服务也可以是在现有HCE服务中扩展的服务，即第三方支付应用调用现有HCE服务对应的接口，该HCE服务根据第二终端发送的应用选择指令中携带的应用标识或应用类型等方式确定此次NFC支付要调用的对象是否为第三方支付应用，并在要调用的对象为第三方支付应用时使用HCE服务中新扩展的功能进行处理。

具体的，对现有HCE服务进行修改与增强，如在现有HCE服务中新增识别应用类型的能力。此时，第三方支付应用可在向第一终端注册的配置文件中新增应用类型参数(App Type Param)这一参数，该应用类型参数用于标识HCE服务类型。具体的，当该参数的值为第一取值时，表示注册该HCE服务的应用是目前常见的银行卡、会员卡等卡应用。当该参数的值为第二取值时，表示注册该HCE服务的应用是微信支付等第三方支付应用。第一终端存储应用的AID和应用类型参数的对应关系。参考图9b，第三方支付应用1的AID为AID1，其对应的AppType的取值为B，第三方支付应用2的AID为AID2，其对应的AppType的取值也为B，表示该第三方支付应用1和第三方支付应用2对应的HCE服务类型为同一种HCE服务类型，该HCE服务类型具体为本申请实施例所指的特定HCE服务类型。银行卡1的AID为AID3，其对应的AppType的取值为A，公交卡应用2的AID为AID4，其对应的AppType的取值为A，表示该银行卡1和公交卡应用2对应的HCE服务类型为同一种HCE服务类型，该HCE服务类型具体为目前所指的HCE服务类型。

在该实现方式中，第一终端存储应用AID和AppType的对应关系，进而在获取了应用的AID后，根据存储的该AID对应的AppType的取值确定其对应的HCE服务类型。

在图9b的实现方式中，相当于第一终端的系统给上层应用提供了HCE服务这一个接口，但是该HCE服务有两个处理分支。其中，对于应用类型参数为第三方支付应用的情况，HCE服务的处理逻辑是本申请实施例所描述的步骤901至步骤909的处理逻辑。对于应用类型为目前的银行卡等IC卡的情况，HCE服务的处理逻辑是现有的卡技术流程(如PBOC或EMVCo定义的流程)，此处不再赘述。

综上所述，以上所有可能的实现方式中，第三方支付应用注册的HCE服务，不论是如图9a中新增的独立服务，还是如图9b中通过对现有HCE服务进行修改与增强后扩展的服务，都可以统一叫做特定类型的HCE服务。

这样，当第一终端接收到第二终端发送的携带有目标第三方支付应用的AID的应用选择指令时，第一终端能够根据该应用选择指令中携带的AID确定此次进行NFC支付的应用为目标第三方支付应用。则第一终端确定由目标第三方支付应用对应的该特定类型的HCE服务解析该应用选择指令并向第二终端发送响应消息。具体的，如图10a所示，该过程包括以下步骤：

901、第一终端和第二终端建立NFC连接以及第一终端与第二终端执行射频发现的过程。

该步骤的具体实现可参考现有技术，此处不再赘述。

902、第一终端接收第二终端发送的应用选择指令。

其中，所述应用选择指令中携带所述目标第三方支付应用的AID。

需要说明的是，该目标第三方支付应用的AID是该目标第三方支付应用在安装到第一终端上时向系统注册的，可能需要该应用的开发者事先向特定机构申请，以专门标识该类应用。

903、所述第一终端根据所述目标第三方支付应用的AID，确定所述目标第三方支付应用对应的HCE服务。

可选的，在一种实现方式中，第一终端存储有所述目标第三方支付应用的AID和服务类型的对应关系，则第一终端根据预存的所述对应关系，确定所述目标第三方支付应用的AID对应的HCE服务。

其中，所述第一终端存储有所述目标第三方支付应用的注册信息，该注册信息包括所述目标第三方支付应用的AID和服务类型的表示信息，该注册信息用于确定所述目标第三方支付应用的AID和服务类型的对应关系。

具体的，如图9a或图9b所示，目标第三方支付应用在安装到第一终端上时需要向系统注册特定类型的HCE服务。在注册该特定类型的HCE服务时，目标第三方支付应用需要向第一终端的系统声明一些注册信息(如：安卓系统中，通过manifest配置文件声明与注册)。其中，这些注册信息可以包括所述目标第三方支付应用的AID和HCE服务类型表示信息。第一终端可根据该HCE服务类型表示信息确定目标第三方支付应用的HCE服务类型，进而确定并存储目标第三方支付应用的AID和HCE服务类型的对应关系。这里所述的HCE服务类型表示信息为专门标识HCE服务类型的信息。参考前述图9a，该专门标识HCE服务类型的信息为新增的针对第三方支付应用的HCE服务，如HostApduSpecificService。或者，所述专门标识HCE服务类型的信息为专门标识支付应用类型的信息。参考前述图9b，所述专门标识HCE服务类型的信息为App Type Param。

可选的，在一种实现方式中，第一终端根据应用注册的AID来区分其注册的HCE服务。例如，第三方支付应用申请注册的AID的编号为预设段内的编号，则当AID为预设段内的编号时，第一终端将该应用注册的HCE服务确定为特定类型的HCE服务；当AID为其他编号时，第一终端将该应用注册的HCE服务确定为普通类型的HCE服务。

可选的，在其他实现方式中，第一终端在接收到应用选择指令后，向目标第三方支付应用的服务器发送该应用选择指令。目标第三方支付应用的服务器根据该应用选择指令携带的AID确定该目标第三方支付应用对应的HCE服务类型，并通知第一终端用于解析该应用选择指令的HCE服务类型，进而第一终端根据该HCE服务类型确定HCE服务。

904、第一终端基于步骤903确定的所述HCE服务向所述第二终端回复响应消息。

其中，所述响应消息包括所述第一终端生成的应用选择响应，如ISO/IEC 7816协议定义的SELECT响应，用于通知第一终端应用选择成功。

在该步骤中，所述第一终端基于已确定的HCE服务解析所述应用选择指令并向第二终端发送响应消息。

在第一终端向第二终端回复应用选择响应后，第二终端向第一终端发送请求消息以获取第一终端的支付信息。

905、第一终端基于步骤903确定的所述HCE服务接收第二终端发送的第一请求消息。

其中，该第一请求消息用于获取所述目标第三方支付应用的支付信息，该支付信息具体为第一终端用于付款的付款信息。该第一请求消息为预设协议规定的预设格式的消息。该预设协议可以为专门针对传输第三方支付应用的支付信息制定的，也可以为NFC标准组织定义的协议，如NFC数据交换格式(NFC Data Exchange Format，NDEF)协议。

本申请实施例所述的特定类型的HCE服务能够接收与处理所述预设协议规定的预设格式的消息。因此，本步骤中，第一终端基于所述特定类型的HCE服务接收所述第一请求消息。

906、第一终端基于步骤903确定的所述HCE服务解析所述第一请求消息并生成预设格式的响应消息。

在本步骤的具体实现中，第一终端基于步骤903确定的HCE服务解析所述第一请求消息后将目标第三方支付应用生成的支付信息封装为预设格式的响应消息。

其中，目标第三方支付应用生成的支付信息可以为第一终端离线生成的一次性支付信息，具体地，可以是目标第三方支付应用根据自己的账号以及可能的本次交易金额、时间、预先下载的密钥种子等其他信息，以特定算法在本地生成的一次性支付信息。该支付信息还可以为所述目标第三方支付应用的服务器在线生成的一次性支付信息并由所述服务器发送给所述第一终端。每次在利用该目标第三方支付应用进行NFC支付时，生成的一次性支付信息根据每次支付时的交易金额、位置或时间不同而不同。此外，该支付信息还可以为目标第三方支付应用根据自己的账号生成的固定支付信息，也即在每次利用该目标第三方支付应用支付时目标第三方支付应用的支付信息均为该固定支付信息。

可选的，步骤906生成的所述预设格式的响应消息还包括支付风险验证信息，该支付风险验证信息为用于进行支付风险判断的信息。例如：该支付风险验证信息可以为第一终端的位置信息。

907、第一终端基于步骤903确定的所述HCE服务向第二终端发送所述预设格式的响应消息。

可选的，第一终端在发送所述预设格式的响应消息前，对携带在所述预设格式的响应消息中的支付信息、支付风险验证信息等信息进行安全处理。也可以仅对其中的部分信息，如所述支付风险验证信息进行安全处理。示例性的，本申请实施例提供以下两种安全处理方式：

方式1、第一终端对携带在所述预设格式中的响应信息中的信息计算摘要(如计算哈希值)，然后使用所述目标第三方支付应用的私钥对计算的摘要进行加密，即得到签名。再把上述信息及其签名封装到该预设格式的响应消息中。也可能把目标第三方支付应用的公钥证书一起封装到该预设格式的响应消息。当然，也可以使用第二终端的公钥或双方终端协商的对称密钥等对上述信息及其签名进行加密后再封装到响应消息中发送给第二终端。

方式2、使用服务器的公钥或与服务器协商的对称密钥对上述信息加密，再把加密后的信息封装到该预设格式的响应消息中即可。上述加密的具体实现过程可参考现有技术，此处不再赘述。当然，也可以在该加密操作之前对该响应消息中的信息做签名处理，如用第一终端对应的私钥对该信息的哈希值做加密，以将该签名及该信息一起做加密后再封装与发送。

可选的，有些条件下，例如当此次交易金额较大(如大于预设阈值)时，第二终端执行以下步骤908a以进行支付风险判断。或者第二终端在收到第一终端发送的所述预设格式的响应消息后默认执行下述步骤908a以进行支付风险判断。

908a、第二终端根据支付风险验证信息对此次支付进行风险判断。

可选的，所述支付风险验证信息由步骤907所述的预设格式的响应消息中携带。或者，第二终端向所述目标第三方支付应用的服务器请求支付风险验证信息以从所述服务器获取得到该支付风险验证信息。其中，所述目标第三方支付应用的服务器在生成所述第一终端的支付信息时生成并保存该支付风险验证信息。

当判断结果为此次支付无风险时，第二终端执行下述步骤909a。当判断结果为此次支付存在风险时，第二终端则结束此次NFC支付或向第一终端发送询问信息，该询问信息用于提示第一终端此次支付存在风险。第一终端收到该询问信息后提示用户此次NFC支付存在风险并询问用户是否继续此次NFC支付，第一终端根据用户的选择向第二终端发送响应消息以结束此次NFC支付或继续此次NFC支付。当然，若第二终端的用户为付款方时，也可以或直接向第二终端的用户进行风险提示，征得该用户的同意后再继续执行后面的过程。

示例性的，所述支付风险验证信息为第一终端的位置信息，则第二终端根据该位置信息对此次支付进行风险判断的过程具体为：第二终端判断第一终端位置与第二终端其本身当前所在的位置之间的距离是否小于阈值，如果小于阈值，则认为第一终端“靠近”第二终端，此次支付无风险；否则第二终端认为此次支付存在风险。

可选的，当所述预设格式的响应消息中携带的信息为安全处理后的信息时，所述第二终端对该安全处理后的信息进行验证，在验证成功后执行该步骤908a。例如，针对上述安全处理方式1，第二终端使用自己的私钥对响应消息中的签名进行验证。若响应消息中的信息是使用第二终端的公钥或双方终端协商的对称密钥经过加密后的，则第二终端需要先使用自己的私钥或者双方终端协商的对称密钥对响应消息中的信息进行解密。

909a、第二终端收到所述预设格式的响应消息后确定用于处理该预设格式的响应消息的通道为所述目标第三方支付应用的通道。

在本步骤的具体实现中，当所述预设格式的响应消息中包括所述目标第三方支付应用的AID时，第二终端根据该AID确定用于处理该预设格式的响应消息的通道为所述目标第三方支付应用的通道，即第二终端与所述目标第三方支付应用的服务器建立连接。当所述预设格式的响应消息中不包括所述目标第三方支付应用的AID时，第二终端根据前述步骤902至步骤904的select命令的发送和应答过程中所选择的目标第三方支付应用确定用于处理该预设格式的响应消息的通道为所述目标第三方支付应用的通道。

需要说明的是，目前，POS机等终端仅支持银行卡应用等非第三方支付应用。而本申请实施例中，第二终端既可以为仅支持第三方支付应用的POS机。也可以为同时支持目前的银行卡应用等非第三方支付应用和微信支付等第三方支付应用的POS机，此时，第二终端根据所接收支付信息对应的支付应用是第三方支付应用还是非第三方支付应用，决定选择第三方支付应用对应的服务器还是非第三方支付应用对应的服务器(如银联的结算服务器或某银行的服务器、Visa的结算服务器等)进行支付结算。

还需要说明的是，上述步骤909a还可以在步骤908a之前执行也即在确定处理预设格式的响应消息的通道为目标第三方支付应用的通道后，第二终端进行支付风险判断，在确定无支付风险时，执行下述步骤910a，当确定存在支付风险时，自动结束此次NFC支付或根据用户的操作结束此次NFC支付或继续此次NFC支付。此外，由于本实施例中可以在步骤步骤902-904的应用选择过程中确定所选择的支付应用是不是第三方支付应用，因此，步骤909a表示可以在步骤904之后执行。

910a、第二终端向所述目标第三方支付应用的服务器发送第二请求消息。

其中，所述第二请求消息中携带所述第一终端发送的支付信息。所述第二请求消息用于请求所述目标第三方支付应用的服务器对本次交易进行授权，即请求服务器对所述支付信息进行验证，若该服务器对该支付信息验证成功，则可授权本次交易，即直接从相应的付款方账户中扣除本次交易金额，并向收款方账户中增加本次交易金额，或者，请求第三方支付应用绑定的银行卡所述银行等金融机构进行资金的转移。

可选的，当第一终端向第二终端回复的所述响应消息中还携带支付风险验证信息时，该第二请求消息中还可携带所述支付风险验证信息或根据该支付风险验证信息判断的结果。

此外，所述目标第三方支付应用的服务器根据所述支付信息确定付款方账户信息。为了便于服务器确定收款方账户信息，第二终端在发送所述第二请求消息的同时，所述第二终端还可能向所述目标第三方支付应用的服务器发送收款账户信息或者第二终端的标识等便于该服务器查找到收款账户的其他信息。

911a、所述目标第三方支付应用的服务器根据支付信息进行支付验证，验证成功后，进行资金转移。

所述目标第三方支付应用的服务器收到第二请求消息后，由于第二请求消息中携带有第一终端的支付信息，服务器根据该支付信息进行验证。

参考步骤906，所述第一终端的支付信息可能为第一终端本地生成的一次性支付信息，也可能为服务器生成的一次性支付信息，还可能为第一终端用户通过目标第三方支付应用注册的账户等固定的支付信息。

其中，对于第一终端本地生成的支付信息，一种方式是服务器可采用同样的预设算法生成一个支付信息并与第二终端发送的该支付信息进行比对以判断该支付信息是否合法。对于服务器生成的支付信息，一种方式是服务器可根据第一终端的目标第三方支付应用的账户或账户标识或第一终端的标识等获取之前预存的支付信息，并直接将获取到的该本地预存的支付信息与所述第二请求消息中携带的支付信息进行比较以判断该支付信息是否合法。

此外，这里所述的资金转移可以是从付款方的所述目标第三方支付应用账户中进行资金转移。例如：从付款方的微信支付的零钱、支付宝的余额等第三方支付服务商单独提供与运营的账户中进行资金转移。或者，从付款方的所述目标第三方支付应用绑定的银行卡向收款方的所述目标第三支付应用账户或所述第三方支付应用绑定的银行卡中转移资金。

可选的，当支付金额较大时，所述目标第三方支付应用的服务器向所述第一终端发送身份验证通知消息，如下发验证码、要求输入支付密码或指纹等，在身份验证成功后，所述目标第三方支付应用的服务器进行资金转移。

可选的，作为上述步骤908a至步骤911a的替代方案，本申请实施例还提供了一种进行支付风险判断的方法，如图10b所示，该方法包括以下步骤：

908b、第二终端收到所述预设格式的响应消息后确定用于处理该预设格式的响应消息的通道为所述目标第三方支付应用的通道。

本步骤与上述908a类似，这里不再赘述。

909b、第二终端向所述目标第三方支付应用的服务器发送第二请求消息。

该步骤具体可参考步骤910a，此处不再赘述。其中，与步骤910a不同的地方在于，由于在图10a所示的实现方式中，由第二终端进行支付风险判断，因此步骤910a所述的第二请求消息中可能包含支付风险验证结果。而由于在该实现过程中，第二终端无需进行支付风险判断，由目标第三方支付应用的服务器进行支付风险判断。因此，该步骤909b所述的第二请求消息中可能包括支付风险验证信息而不包含支付风险判断结果。一种可能的原因是，上述步骤907中的所述响应消息携带的支付风险验证信息可能是经过上述方式2的安全处理方式处理后的信息，因此，只有该目标第三方支付应用的服务器可以经过去安全处理(如解密处理)得到该支付风险验证信息。

910b、所述目标第三方支付应用的服务器根据所述支付信息进行支付验证。

本步骤中，服务器对支付信息的验证与上述步骤911a类似，这里不再赘述。

911b、所述目标第三方支付应用的服务器根据支付风险验证信息进行支付风险判断。

需要说明的是，本步骤所述的支付风险验证信息，可以为所述第二请求消息中携带的。或者，所述支付风险验证信息为所述目标第三方支付应用的服务器收到上述第二请求消息后根据其中的支付信息确定的。具体的，根据所述支付信息确定目标第三方支付应用账户，进而确定该账户所属用户在注册该账户时设置的支付风险验证信息，如安全位置范围或者安全时间范围。或者，所述支付风险验证信息也可以是所述目标第三方支付应用的服务器收到上述第二请求消息后根据其中的支付信息确定该服务器为第一终端的目标第三方支付应用生成该支付信息时对应的支付风险验证信息。

所述目标第三方支付应用的服务器利用上述支付风险验证信息进行支付风险判断的过程具体包括：例如：服务器将第一终端的位置与第二终端的位置进行比较，若两者距离小于阈值，则认为本次交易无支付风险，否则认为有支付风险。其中，该第二终端的位置可以为第二终端提交上述第二请求消息时一并携带的。又如：服务器将第一终端的位置与第一终端用户所设置的安全交易位置范围进行比较，若该位置在该安全交易位置范围内，则认为本次交易无支付风险，否则认为有支付风险。

可选的，当所述第二请求消息中携带的所述用于支付风险判断的消息为加密后的消息时，所述第二终端进行解密，解密成功后，执行该步骤910b。

912b、当对所述支付信息进行支付验证通过后以及确定无支付风险后，所述目标第三方支付应用的服务器进行资金转移。

本步骤中的资金转移，与上述步骤911a类似，这里不再赘述。

可选的，作为上述步骤908a至步骤911a的替代方案，本申请实施例还提供了一种进行支付风险判断的方法，如图10c所示，该方法包括以下步骤：

908c、第二终端收到预设格式的响应消息后确定用于处理该响应消息的通道为目标第三方支付应用的通道。

该步骤具体可参考步骤908b，此处不再赘述。

909c、所述第二终端向所述目标第三方支付应用的服务器发送第二请求消息。

其中，所述第二请求消息中携带所述第一终端发送的支付信息。所述第二请求消息用于请求所述目标第三方支付应用的服务器对本次交易进行授权，即请求服务器对所述支付信息进行验证。

910c、所述目标第三方支付应用的服务器根据所述支付信息进行支付验证。

支付验证通过后执行下述步骤911c。

911c、所述目标第三方支付应用的服务器向所述第二终端发送响应消息，该响应消息用于提示第二终端进行身份验证。

第二终端收到所述目标第三方支付应用的服务器发送的所述响应消息后，执行下述步骤912c以进行支付风险判断，并在支付风险判断通过后进行身份验证。

912c、所述第二终端根据支付风险判断信息进行支付风险判断。

当第二终端判断此次支付存在风险时，结束此次流程。当第二终端判断此次支付不存在风险时，执行下述步骤913。

913、所述第二终端对用户进行身份验证。

其中，该身份验证的方式包括指纹验证、输入特定密码、输入特定验证码等。第一终端对用户进行身份验证后，执行下述步骤914以将身份验证结果发送至目标第三方支付应用的服务器。

914、所述第二终端向所述目标第三方支付应用的服务器发送身份验证结果。

915、所述目标第三方支付应用的服务器根据身份验证结果，在身份验证通过后，进行资金转移。

本步骤中的资金转移，与上述步骤911a类似，这里不再赘述。

可选的，作为步骤914和步骤915的一种替代方案，第二终端获取用户的身份验证信息并向目标第三方支付应用的服务器发送用户输入的指纹、密码等身份验证信息以便于该目标第三方支付应用的服务器根据该身份验证信息进行身份验证。

在目标第三方支付应用的服务器进行身份验证成功或收到第二终端发送的身份验证成功的身份验证结果后，执行步骤915。

为了支持图4、图5a、图6、图7、图8的实现过程，本申请实施例还提供了一种NFC支付方法，在该方法中，第一终端将其自身的支付信息保存在NFC标签中，第二终端能够读取该NFC标签以获取第一终端的支付信息。该方法可应用在第一终端为收款方，第二终端为付款方的场景下。在该场景下，第一终端作为收款方终端将其自身的支付信息(即收款信息)保存在NFC标签中，第二终端作为付款方终端能够读取该NFC标签以获取第一终端的收款信息。或者，该方法可应用在在第一终端为付款方，第二终端为收款方的场景下。在该场景下，第一终端作为付款方终端将其自身的支付信息(即付款信息)保存在NFC标签中，第二终端作为收款方终端能够读取该NFC标签以获取第一终端的付款信息。

如图11a所示，该方法包括以下步骤：

1001、第一终端根据所述目标第三方支付应用的支付信息生成预设格式的响应消息，并将所述预设格式的响应消息封装为NFC标签。

其中，所述支付信息的具体生成可参考前述步骤906，此处不再赘述。

当所述第一终端为付款方终端，所述第二终端为收款方终端时，所述目标第三方支付应用的支付信息为所述目标第三方支付应用的付款信息。当所述第一终端为收款方终端，所述第二终端为付款方终端时，所述目标第三方支付应用的支付信息为所述目标第三方支付应用的收款信息。

可选的，所述预设格式的响应消息可以为NDEF消息。

可选的，第一终端可以在确定并激活目标第三方支付应用作为此次NFC支付的应用后，将所述预设格式的响应消息封装为NFC标签。具体的，触发第一终端生成NFC标签的触发条件包括：第一终端检测到用户的快捷操作，该快捷操作包括用户按压预设物理按键、输入预设指纹信息、输入特定语音指令、输入预设手势等。还包括：第一终端检测到第二终端的射频场。

可选的，在其他实现方式中，第一终端在未与第二终端建立NFC连接以进行NFC支付之前，第一终端可在本地将目标第三方支付应用的支付信息封装为NDEF消息并保存到NFC标签。

可选的，所述预设格式的响应消息中还可能携带支付风险验证信息、响应消息的功能类型以及目标第三方支付应用的标识等其他信息。

其中，所述支付风险验证信息可以为位置信息。所述功能类型是所述目标第三方支付应用在安装到所述第二终端时向系统注册的，用于表示所述目标第三方支付应用的某个目标功能能够处理携带有所述功能类型的消息。功能类型包括收款类似、付款类型等。其中，目标第三方支付应用向系统注册所述功能类型的具体方式可以是，目标第三方支付应用分别针对其收款功能和付款功能向系统注册相应的功能类型，如，以安卓系统为例，在其manifest配置文件中，在对应收款功能的活动(activity)下注册支持的功能类型为收款类型，在对应付款功能的活动(activity)下注册支持的功能类型为付款类型。在本申请实施例中，当第一终端为付款方终端，所述第二终端为收款终端时，所述功能类型为付款类型。当所述第一终端为收款方终端，所述第二终端为付款方终端时，所述功能类型为收款类型。

在其他实现方式中，所述功能类型用于指示第二终端执行所述功能类型表示的目标功能。例如：第一终端发送的响应消息中携带的功能类型为“收款”，则第二终端收到该响应消息后，执行收款功能。同理，第一终端发送的响应消息中携带的功能类型为“付款”，则第二终端收到该响应消息后，执行付款功能。

所述目标第三方支付应用的标识可以是其应用包名等，可通过现有安卓定义的标签分发(Tag Dispatch)机制中使用的应用记录(Android Application Record，AAR)这样一个单独的记录来传输该标识，当然，也可以采用其他方式进行传输，如在上述响应消息中将其与其他信息一起放入一个AAR的承载(payload)中。

1002、第一终端和第二终端建立NFC连接以及执行射频发现过程。

在本步骤的射频发现过程中，第二终端可以检测出第一终端是否支持NFC标签协议，也即第二终端可以检测出第一终端是否有NFC标签。一旦检测出NFC标签，则按照下面的步骤1003继续处理。

1003、第一终端接收第二终端发送的用于读取所述NFC标签的请求消息。

其中，该步骤可以执行在步骤1001之前且步骤1002之后，也可以执行在步骤1001和步骤1002之后。

由于第一终端将其自身的付款信息以及其他可能的信息封装到NFC标签中，所以第二终端向第一终端发送请求消息，该请求消息用于读取所述第一终端生成的NFC标签。这里所说的请求消息，可以是NFC标签协议中定义的读命令，这里不再赘述。

1004、第一终端向第二终端发送响应消息，所述响应消息中携带所述NFC标签中封装的内容。

这里所说的响应消息，可以是上述NFC标签协议中定义的读命令对应的读响应，这里不再赘述。

1005、第二终端打开所述目标第三方支付应用。

具体的，当所述NFC标签中携带的信息包括所述目标第三方支付应用的标识时，所述第二终端根据该标识直接确定要将这些信息转发给该标识对应的目标第三方支付应用进行处理，进而可打开所述目标第三方支付应用。当所述NFC标签中携带的信息不包括所述目标第三方支付应用的标识时，所述第二终端根据用户的操作打开所述目标第三方支付应用，如用户在第一、第二终端触碰之前已在第二终端上选择目标第三方支付应用。或者，多个应用在安装到第二终端上时向系统注册了处理NFC标签的能力，则第二终端的系统读取该NFC标签后将本地所有已安装的能够处理NFC标签的应用筛选出来供用户选择。

可选的，在打开所述目标第三方支付应用后，当所述NFC标签中携带的信息还包括所述响应消息的功能类型时，如该功能类型为“付款”，则所述第二终端确定所述第一终端要进行的动作为“付款”。相应的，所述第二终端要进行的动作即为“收款”，则第二终端直接打开所述目标第三支付应用的收款界面，可理解为直接将该NFC标签中的信息转发给该目标第三方支付应用的相应功能进行处理。或者，当该功能类型为“收款”时，所述第二终端确定所述第一终端要进行的动作为“收款”。相应的，所述第二终端要进行的动作即为“付款”，则第二终端直接打开所述目标第三支付应用的付款界面。

可选的，当所述NFC标签中还携带用于支付风险判断的支付风险验证信息时，第二终端执行下述步骤1006a以进行支付风险判断。

1006a、所述第二终端根据支付风险验证信息进行支付风险判断。

当支付风险判断的结果为支付无风险时，执行下述步骤1007a。当支付风险判断的结果为支付存在风险时，第二终端则结束此次NFC支付或向第一终端发送询问信息，该询问信息用于提示第一终端此次支付存在风险。第一终端收到该询问信息后提示用户此次NFC支付存在风险并询问用户是否继续此次NFC支付，第一终端根据用户的选择向第二终端发送响应消息以结束此次NFC支付或继续此次NFC支付。该步骤的具体实现可参考步骤908a，此处不再赘述。

需要说明的是，当所述NFC标签中不包含支付风险验证信息时，第二终端则不执行该步骤1006a，可直接执行下述步骤1007a。或者，第二终端向所述目标第三方支付应用的服务器请求所述第一终端的支付风险验证信息，并根据从所述服务器获取的位置信息执行该步骤1006a以对此次支付进行风险判断。

1007a、第二终端确定用于进行NFC支付的通道为所述目标第三方支付应用的通道。

需要说明的是，上述步骤1007a可以在步骤1006a之前执行也可以在步骤1006a之后执行，本申请实施例不限定步骤1006a和步骤1007a的执行顺序。当第二终端先执行上述步骤1007a再执行步骤1006a以进行支付风险判断时，则当判断无支付风险时才执行下述步骤1008a。此外，本步骤1007a也可以在步骤1005之后默认执行，也即在确定通过目标第三方支付应用完成此次NFC支付时，第二终端可确定本次交易要使用的通道为该目标第三方支付应用的通道，也就是第二终端要与该目标第三方支付应用的服务器建立通信连接。

本步骤的具体实现可参考前述步骤909a，此处不再赘述。

1008a、第二终端向所述目标第三方支付应用的服务器发送第二请求消息。

本步骤的具体实现可参考前述步骤910a，此处不再赘述。

1009a、目标第三方支付应用的服务器根据支付信息进行验证，验证成功后，进行资金转移。

可选的，当支付金额较大时，所述目标第三方支付应用的服务器向所述第一终端发送身份验证信息，如下发验证码、输入支付密码或指纹等，在身份验证成功后，所述目标第三方支付应用的服务器进行资金转移。

本步骤的具体实现可参考前述步骤911a，此处不再赘述。

可选的，作为上述步骤1006a至步骤1009a的替代方案，本申请实施例还提供了一种进行支付风险判断的方法，如图11b所示，该方法包括以下步骤：

1006b、第二终端确定用于处理NFC标签中信息的通道为所述目标第三方支付应用的通道。

本步骤的具体实现可参考前述步骤909a，此处不再赘述。

1007b、第二终端向所述目标第三方支付应用的服务器发送第二请求消息。

本步骤的具体实现可参考前述步骤909b类似，此处不再赘述。

1008b、目标第三方支付应用的服务器对所述支付信息进行验证。

本步骤可参考前述步骤911a，此处不再赘述。

1009b、目标第三方支付应用的服务器根据支付风险验证信息进行支付风险判断。

可选的，所述第二请求消息中携带支付风险验证信息。则在本步骤的具体实现中，目标第三方支付应用的服务器根据第二请求消息中携带的该支付风险验证信息进行支付风险判断。

可选的，所述目标第三方支付应用的服务器在生成所述目标第三方支付应用的付款信息时保存支付风险验证信息。则在本步骤的具体实现中，目标第三方支付应用的服务器根据预先保存的支付风险验证信息进行支付风险判断。

本步骤可参考步骤911b，此处不再赘述。

1010b、当对支付信息验证成功且确定无支付风险后，进行资金转移。

可选的，当支付金额较大时，所述目标第三方支付应用的服务器向所述第一终端发送身份验证信息，如输入验证码、输入指纹等，在身份验证成功后，所述目标第三方支付应用的服务器进行资金转移。

本步骤可参考步骤912b，这里不再赘述。

可选的，作为上述步骤1006a至步骤1009a的替代方案，本申请实施例还提供了一种进行支付风险判断的方法，该方法主要应用在第一终端为收款方终端，第二终端为付款方终端的场景下。

如图11c所示，该方法包括以下步骤：

1006c、第二终端确定用于处理NFC标签中的信息的通道为目标第三方支付应用的通道。

1007c、第二终端向目标第三方支付应用的服务器发送第二请求消息。

其中，所述第二请求消息中携带所述第一终端发送的支付信息，如第一终端的收款信息。该第二请求消息用于请求所述目标第三方支付应用的服务器对本次交易进行授权。所述目标第三方支付应用的服务器还可根据第一终端发送的支付信息确定收款方账户。

此外，为了便于所述目标第三方支付应用的服务器确定收款方账户，第二终端可能还向该服务器发送第二终端用户的相关信息，如第二终端用户在目标第三方支付应用上注册的账户或其他能关联到其账户的信息，以便于服务器确定本次交易中用于付款的账户。

可选的，目标第三方支付应用的服务器收到第二终端发送的所述第二请求消息后，执行下述步骤1008c以要求用户进行身份验证。

1008c、目标第三方支付应用的服务器向第二终端发送身份验证请求。

其中，该服务器可在收到上述第二请求消息后直接确定需要第二终端的用户进行身份验证，或者，根据具体情况(如本次交易金额超过阈值等)确定需要第二终端的用户进行身份验证，那么，该服务器可向第二终端发送身份验证请求，以通知第二终端的用户进行身份验证。

1009c、第二终端根据支付风险验证信息进行支付风险判断。

其中，第二终端在接收该服务器发送的上述身份验证请求后，可根据支付风险验证信息进行判断，以决定是否提示用户进行身份验证。若第二终端认为无支付风险，则执行如下步骤1010c，要求用户进行身份验证。

其中，所述支付风险验证信息由步骤1004发送的所述响应消息携带，或者该支付风险验证信息由第二终端从目标第三方支付应用的服务器获取得到。

当支付风险判断的结果为支付存在风险时，第二终端则结束此次NFC支付或显示提示信息，该提示信息用于提示用户此次支付存在风险并询问用户是否继续此次NFC支付，第二终端根据用户结束此次NFC支付或继续此次NFC支付。

1010c、第二终端在确定无支付风险时对用户进行身份验证。

其中，该身份验证的方式包括指纹验证、输入特定密码、输入特定验证码等。第一终端对用户进行身份验证后，执行下述步骤1011c以将身份验证结果发送至目标第三方支付应用的服务器。

1011c、第二终端向目标第三方支付应用的服务器发送身份验证结果。

其中，在身份验证成功时，第二终端可以将该成功的结果发送给该目标第三方支付应用的服务器。在身份验证失败时，第二终端可以将该失败的结果发送给该服务器，或者，也可以直接结束流程而不将该结果发送给该服务器。

1012c、目标第三方支付应用的服务器在对用户进行身份验证成功后，进行资金转移。

该步骤所述的资金转移的具体实现可参考上述步骤911a，此处不再赘述。

可选的，作为步骤1010c和步骤1011c的一种替代方案，第二终端获取用户的身份验证信息并向目标第三方支付应用的服务器发送用户输入的指纹、密码等身份验证信息以便于该目标第三方支付应用的服务器根据该身份验证信息进行身份验证。

在目标第三方支付应用的服务器进行身份验证成功或收到第二终端发送的身份验证成功的身份验证结果后，执行步骤1012c。

上述主要从各个网元之间交互的角度对本申请实施例提供的方案进行了介绍。可以理解的是，各个网元，例如第一终端、第二终端以及目标第三方支付应用的服务器等为了实现上述功能，其包含了执行各个功能相应的硬件结构和/或软件模块。本领域技术人员应该很容易意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，本申请能够以硬件或硬件和计算机软件的结合形式来实现。某个功能究竟以硬件还是计算机软件驱动硬件的方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

本申请实施例可以根据上述方法示例对第一终端、第二终端等进行功能模块的划分，例如，可以对应各个功能划分各个功能模块，也可以将两个或两个以上的功能集成在一个处理模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。需要说明的是，本申请实施例中对模块的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。

在采用对应各个功能划分各个功能模块的情况下，图12a示出了上述实施例中所涉及的第一终端的一种可能的结构示意图，第一终端1100包括：显示模块1101、确定模块1102以NFC支付模块1103。显示模块1101用于支持第一终端1100执行图4中的过程401。确定模块1102用于支持第一终端1100执行图4中的过程402。NFC支付模块1103用于支持第一终端1100执行图4中的过程403，图10a、图10b以及图10c中的过程901、902、903、904、905、906及907；还用于支持第一终端1100执行图11a、图11b以及图11c中的过程1001、1002、1003以及1004。

其中，上述方法实施例涉及的各步骤的所有相关内容均可以援引到对应功能模块的功能描述，在此不再赘述。

在采用集成的单元的情况下，图12b示出了上述实施例中所涉及的第一终端的一种可能的结构示意图。第一终端1200包括：处理模块1202、通信模块1203和显示模块1204。显示模块1204用于支持第一终端1200显示特定信息，例如，显示模块1203用于支持第一终端1200执行执行图4中的过程401。处理模块1202用于对第一终端1200的动作进行控制管理，例如，处理模块1202用于支持第一终端1200执行图4中的过程402、403，图10a、图10b以及图10c中的过程901、902、903、904、905、906及907；图11a、图11b以及图11c中的过程1001、1002、1003以及1004，和/或用于本文所描述的技术的其它过程。通信模块1203用于支持第一终端1200与其他网络实体的通信，例如与第二终端或目标第三方支付应用的服务器之间的通信。第一终端1200还可以包括存储模块1201，用于存储第一终端的程序代码和数据。

其中，处理模块1202可以是处理器或控制器，例如可以是中央处理器(Central Processing Unit，CPU)，通用处理器，数字信号处理器(Digital Signal Processor，DSP)，专用集成电路(Application-Specific Integrated Circuit，ASIC)，现场可编程门阵列(Field Programmable Gate Array，FPGA)或者其他可编程逻辑器件、晶体管逻辑器件、硬件部件或者其任意组合。其可以实现或执行结合本申请公开内容所描述的各种示例性的逻辑方框，模块和电路。所述处理器也可以是实现计算功能的组合，例如包含一个或多个微处理器组合，DSP和微处理器的组合等等。通信模块1203可以是收发器、收发电路或通信接口等。显示模块1204可以是各种类型的显示器等，存储模块1201可以是存储器。

当处理模块1202为处理器，通信模块1203为收发器，显示模块1204为显示器，存储模块1201为存储器时，本申请实施例所涉及的第一终端可以为图12c所示的第一终端。

参阅图12c所示，该第一终端1300包括：显示器1301、一个或多个处理器1302、收发器1303、存储器1304以及总线1305。其中，收发器1303、处理器1302以及存储器1304通过总线1305相互连接。总线1305可以是外设部件互连标准(Peripheral Component Interconnect，PCI)总线或扩展工业标准结构(Extended Industry Standard Architecture，EISA)总线等。所述总线可以分为地址总线、数据总线、控制总线等。为便于表示，图12c中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。

具体的，参考图12d，第一终端1400包括通过总线1405互相连接的一个或多个处理器1401、显示器1402、输入设备1403以及存储器1404。其中，所述存储器1404中存储一个或多个程序，所述一个或多个程序包括指令，当所述指令被所述第一终端执行时，使得所述第一终端执行以下步骤：所述显示器1402显示第一界面，所述第一界面显示有至少一个第三方支付应用。所述输入设备1403接收用户在所述第一界面中选择目标第三方支付应用的选择操作。所述处理器1401，响应于所述选择操作和第二终端通过所述目标第三方支付应用交互以完成NFC支付。

可选的，所述输入设备1403，还用于在所述第一终端处于锁屏状态时，接收用户输入的快捷操作，所述快捷操作包括按压预设物理按键、输入预设指纹信息、输入特定语音指令或输入预设手势。所述显示器1402，还用于响应于所述快捷操作，显示第一界面。

可选的，所述显示器1402，还用于当所述第一终端触碰所述第二终端时，显示第一界面。

可选的，所述显示器1402，还用于响应于所述选择操作，显示第二界面，所述第二界面显示有第一提示信息，所述第一提示信息用于提示用户进行身份验证。所述处理器1401，还用于响应于用户身份验证成功的操作，和第二终端交互以完成NFC支付。

可选的，所述显示器1402，还用于显示第二提示信息，所述第二提示信息用于提示用户已完成NFC支付。

在采用对应各个功能划分各个功能模块的情况下，图13a示出了上述实施例中所涉及的第二终端的一种可能的结构示意图，第二终端1500包括：发送模块1501、接收模块1502以及NFC支付模块1503。发送模块1501用于支持第二终端1500执行图10a、图10b及图10c中的过程902、905以及910a，还用于支持第二终端1500执行图10b中的过程909b，还用于支持第二终端1500执行图10c中的过程909c、914，还用于支持第二终端1500执行图11a中的过程1003、过程1008a，图11b中的过程1007b，图11c中的过程1007c、过程1011c。接收模块1502用于支持第二终端1500执行图10a中的过程904以及过程907，还用于支持第二终端1500执行图10c中的过程911c，还用于支持第二终端1500执行图11a中的过程1004、图11c中的过程1008c。NFC支付模块1503用于支持第二终端1500执行图10a中的过程908a以及909a；还用于支持第二终端1500执行图10b中的过程908b、图10c中的过程908c、912c以及过程913。还用于支持第二终端1500执行图11a中的过程1005、1006a以及过程1007a。还用于支持第二终端1500执行图11b中的过程1006b、图11c中的过程1006c、1009c以及1010c。

其中，上述方法实施例涉及的各步骤的所有相关内容均可以援引到对应功能模块的功能描述，在此不再赘述。

在采用集成的单元的情况下，图13b示出了上述实施例中所涉及的第二终端的一种可能的结构示意图。第二终端1600包括：处理模块1602和通信模块1603。处理模块1602用于对第二终端1600的动作进行控制管理，例如，处理模块1602用于支持第二终端1600执行图10a中的过程908a以及909a；图10b中的过程908b、图10c中的过程908c、912c以及过程913；图11a中的过程1005、1006a以及过程1007a；图11b中的过程1006b、图11c中的过程1006c、1009c以及1010c，和/或用于本文所描述的技术的其它过程。通信模块1603用于支持第二终端1600与其他网络实体的通信，例如与第一终端或目标第三方支付应用的服务器之间的通信。第二终端1600还可以包括存储模块1601，用于存储第二终端的程序代码和数据。

其中，处理模块1602可以是处理器或控制器，例如可以是中央处理器(Central Processing Unit，CPU)，通用处理器，数字信号处理器(Digital Signal Processor，DSP)，专用集成电路(Application-Specific Integrated Circuit，ASIC)，现场可编程门阵列(Field Programmable Gate Array，FPGA)或者其他可编程逻辑器件、晶体管逻辑器件、硬件部件或者其任意组合。其可以实现或执行结合本申请公开内容所描述的各种示例性的逻辑方框，模块和电路。所述处理器也可以是实现计算功能的组合，例如包含一个或多个微处理器组合，DSP和微处理器的组合等等。通信模块1603可以是收发器、收发电路或通信接口等。存储模块1601可以是存储器。

当处理模块1602为处理器，通信模块1603为收发器，存储模块1601为存储器时，本申请实施例所涉及的第二终端可以为图13c所示的第二终端。

参阅图13c所示，该第二终端1700包括：处理器1701、收发器1702、存储器1703以及总线1704。其中，收发器1702、处理器1701以及存储器1703通过总线1704相互连接。总线1704可以是外设部件互连标准(Peripheral Component Interconnect，PCI)总线或扩展工业标准结构(Extended Industry Standard Architecture，EISA)总线等。所述总线可以分为地址总线、数据总线、控制总线等。为便于表示，图13c中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。

结合本申请公开内容所描述的方法或者算法的步骤可以硬件的方式来实现，也可以是由处理器执行软件指令的方式来实现。软件指令可以由相应的软件模块组成，软件模块可以被存放于随机存取存储器(Random Access Memory，RAM)、闪存、只读存储器(Read Only Memory，ROM)、可擦除可编程只读存储器(Erasable Programmable ROM，EPROM)、电可擦可编程只读存储器(Electrically EPROM，EEPROM)、寄存器、硬盘、移动硬盘、只读光盘(CD-ROM)或者本领域熟知的任何其它形式的存储介质中。一种示例性的存储介质耦合至处理器，从而使处理器能够从该存储介质读取信息，且可向该存储介质写入信息。当然，存储介质也可以是处理器的组成部分。处理器和存储介质可以位于ASIC中。

本领域技术人员应该可以意识到，在上述一个或多个示例中，本申请所描述的功能可以用硬件、软件、固件或它们的任意组合来实现。当使用软件实现时，可以将这些功能存储在计算机可读介质中或者作为计算机可读介质上的一个或多个指令或代码进行传输。计算机可读介质包括计算机存储介质和通信介质，其中通信介质包括便于从一个地方向另一个地方传送计算机程序的任何介质。存储介质可以是通用或专用计算机能够存取的任何可用介质。

以上所述的具体实施方式，对本申请的目的、技术方案和有益效果进行了进一步详细说明，所应理解的是，以上所述仅为本申请的具体实施方式而已，并不用于限定本申请的保护范围，凡在本申请的技术方案的基础之上，所做的任何修改、等同替换、改进等，均应包括在本申请的保护范围之内。