CN107403312B - 快捷支付方法和装置 - Google Patents

快捷支付方法和装置 Download PDF

Info

Publication number
CN107403312B
CN107403312B CN201610332851.5A CN201610332851A CN107403312B CN 107403312 B CN107403312 B CN 107403312B CN 201610332851 A CN201610332851 A CN 201610332851A CN 107403312 B CN107403312 B CN 107403312B
Authority
CN
China
Prior art keywords
payment
application
payment application
information
user
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN201610332851.5A
Other languages
English (en)
Other versions
CN107403312A (zh
Inventor
翟永恒
徐超劲
刘向华
张兰兰
何辉
蒋慧明
姚雪松
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Samsung Electronics Co Ltd
Original Assignee
Samsung Electronics Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Samsung Electronics Co Ltd filed Critical Samsung Electronics Co Ltd
Priority to CN201610332851.5A priority Critical patent/CN107403312B/zh
Publication of CN107403312A publication Critical patent/CN107403312A/zh
Application granted granted Critical
Publication of CN107403312B publication Critical patent/CN107403312B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/322—Aspects of commerce using mobile devices [M-devices]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/445—Program loading or initiating
    • G06F9/44505—Configuring for program initiating, e.g. using registry, configuration files
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/327—Short range or proximity payments by means of M-devices
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/327—Short range or proximity payments by means of M-devices
    • G06Q20/3272—Short range or proximity payments by means of M-devices using an audio code
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/351—Virtual cards
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/356—Aspects of software for card payments

Abstract

本发明提供了一种快捷支付方法和装置，其中，快捷支付方法，包括：检测快捷支付触发条件；调用终端支持的第一支付应用执行支付处理，完成快速支付或消费。相比现有需要用户首先在终端已安装的多个支付应用中执行切换操作来选择其所需的支付应用，再启动该支付应用进行相应的支付处理，本发明中在检测到快捷支付触发条件后即可快速直接地调用第一支付用于执行支付处理，简化了用户在支付过程中的操作步骤，提高了支付效率和用户体验。

Description

快捷支付方法和装置
技术领域
本发明涉及移动支付技术领域，具体而言，本发明涉及一种快捷支付方法和装置。
背景技术
随着计算机网络、移动通信技术和金融数字化等技术的完美结合，利用手机、PDA((Personal Digital Assistant，掌上电脑)等终端设备进行的B2B(Business-to-Business，企业对企业)、B2C(Business-to-Customer，商对客)、C2C(Customer-to-Customer，个人对个人)或O2O(Online To Offline，线上对线下)等模式的移动电子商务应运而生。
实际应用中，移动电子商务提供的移动支付服务允许用户使用其终端设备在任何时间，任何地点对所消费的商品或服务进行账务支付，带给用户极大的方便，从而得到了广泛的应用。目前，终端设备可以通过支持的支付应用来完成支付业务。例如，可以通过预先安装在终端上的支付应用(也可以称为支付客户端)及其对应的支付服务器完成支付业务。
本发明的发明人发现，现有的支付方法中，在终端设备中支持多个支付应用的情况下，若终端设备当前启动的支付应用不符合用户需求，则需要用户手动切换支付应用，若支付应用中提供多种支付功能，那么还需要用户手动选择相应的支付功能，用户操作非常繁琐，体验不佳。
发明内容
针对上述现有技术存在的缺陷，本发明提供了一种快捷支付方法和装置，用于实现快捷支付，简化用户操作，提高用户体验。
本发明提供了一种快捷支付方法，包括：
检测快捷支付触发条件；
调用终端支持的第一支付应用执行支付处理。
优选地，检测快捷支付触发条件，包括：
启动第二支付应用，第二支付应用绑定有第一支付应用的预设支付功能；
检测用户在第二支付应用中针对预设支付功能的触发操作；
调用终端支持的第一支付应用执行支付处理，包括：
调用第一支付应用的预设支付功能执行支付处理。
优选地，预设支付功能对应预先设置的支付信息；
调用第一支付应用的预设支付功能执行支付处理，包括：
调用第一支付应用，根据预设支付功能对应的支付信息，执行相应的支付处理。
其中，支付信息包含下述至少一项：
支付方式、支付方账户、支付对象、支付金额、支付时间。
优选地，支付方式包括在线支付方式和/或离线支付方式；
其中，离线支付方式包括银行卡支付方式和/或信息码支付方式。
优选地，支付方式包括信息码支付方式；
调用第一支付应用，根据预设支付功能对应的支付信息，执行相应的支付处理，包括：
请求第一支付应用的应用客户端生成信息码支付凭证；
在第二支付应用的应用界面显示信息码支付凭证。
可选地，第一支付应用的预设支付功能，以虚拟支付卡的形式绑定到第二支付应用。
优选地，检测快捷支付触发条件，包括：
启动第二支付应用，第二支付应用绑定有第一支付应用；
检测用户在第二支付应用中针对第一支付应用的触发操作；
调用终端支持的第一支付应用执行支付处理，包括：
启动第一支付应用执行支付处理。
其中，第一支付应用为无卡支付应用；第二支付应用为有卡支付应用。
优选地，将第一支付应用中绑定的支付信息同步绑定到第二支付应用；和/或将第二支付应用中绑定的支付信息同步绑定到第一支付应用。
优选地，检测快捷支付触发条件，包括：
检测用户输入的认证信息；
调用终端支持的第一支付应用执行支付处理，包括：
确定出与用户输入的认证信息对应的第一支付应用的预设支付功能；
调用确定出的第一支付应用的预设支付功能执行支付处理。
基于上述快捷支付方法，本发明还提供了一种快捷支付装置，包括：
触发条件检测模块，用于检测快捷支付触发条件；
第一支付模块，用于调用终端支持的第一支付应用执行支付处理。
本发明又提供了一种快捷支付方法，包括：
启动支付应用；
检测针对支付应用的预设支付功能的触发操作，其中，预设支付功能对应用户预先设置的支付信息；
根据预设支付功能对应的支付信息，执行相应的支付处理。
优选地，支付信息包含下述至少一项：
支付方式、支付方账户、支付对象、支付金额、支付时间。
基于上述快捷支付方法，本发明又提供了一种快捷支付装置，包括：
启动模块，用于启动支付应用；
触发操作检测模块，用于检测针对支付应用的预设支付功能的触发操作，其中，预设支付功能对应用户预先设置的支付信息；
第二支付模块，用于根据预设支付功能对应的支付信息，执行相应的支付处理。
本发明的技术方案中，在检测到快捷支付触发条件时，调用终端支持的第一支付应用执行支付处理，完成快速支付或消费。相比现有需要用户首先在终端已安装的多个支付应用中执行切换操作来选择其所需的支付应用，再启动该支付应用进行相应的支付处理，本发明提供的上述方案，在检测到快捷支付触发条件后即可快速直接地调用第一支付应用执行支付处理，简化了用户在支付过程中的操作步骤，提高了支付效率和用户体验。
本发明的技术方案中，用户可预先对支付信息进行设置，在检测到针对支付应用的预设支付功能的触发操作时，根据预设支付功能对应的用户预先设置的支付信息，直接执行相应的支付处理，完成快速支付；由于支付信息为用户预先设置，可满足用户个性化的快捷支付需求；同时，由于支付信息预先设置，无需用户在支付过程中执行任何信息输入的操作，从而提高了支付效率并提升了用户支付体验。
本发明附加的方面和优点将在下面的描述中部分给出，这些将从下面的描述中变得明显，或通过本发明的实践了解到。
附图说明
图1为本发明实施例一中快捷支付方法的流程示意图；
图2为本发明实施例二中第二支付应用向第一支付应用请求用户授权的流程示意图；
图3为本发明实施例三中用户授权过程阶段和支付使用阶段涉及的设备示意图；
图4为本发明实施例三中用户授权过程阶段的流程示意图；
图5为本发明实施例三中己方支付服务器生成的公钥配送示意图；
图6为本发明实施例三中己方支付模块向己方支付服务器申请授权示意图；
图7为本发明实施例三中己方支付服务器向己方支付客户端下发内容示意图；
图8为本发明实施例三中己方支付客户端向第三方支付服务器发送内容示意图；
图9为本发明实施例三中验证签名并返回认证码至己方支付客户端示意图；
图10为本发明实施例三中认证码换取令牌示意图；
图11为本发明实施例三中己方支付客户端获取用户账户信息示意图；
图12为本发明实施例三中用户授权过程阶段示意图；
图13为本发明实施例三中支付使用阶段的流程示意图；
图14为本发明实施例三中请求第三方支付客户端生成会话密钥示意图；
图15为本发明实施例三中安全模块解密得到会话密钥示意图；
图16为本发明实施例三中己方支付客户端得到支付凭证示意图；
图17为本发明实施例三中支付使用阶段示意图；
图18为本发明实施例三中安全模块的实际运用示意图；
图19为本发明实施例三中可信执行环境典型的终端架构示意图；
图20、21均为本发明实施例四中第三方支付应用虚拟卡绑定示意图；
图22、23均为本发明实施例四中支付虚拟卡绑定示意图；
图24为本发明实施例四中支付虚拟卡使用示意图；
图25、26均为本发明实施例四中转账虚拟卡绑定示意图；
图27为本发明实施例四中转账虚拟卡使用示意图；
图28、29均为本发明实施例四中充值虚拟卡绑定示意图；
图30为本发明实施例四中充值虚拟卡使用示意图；
图31、32为本发明实施例四中缴费虚拟卡绑定示意图；
图33为本发明实施例四中缴费虚拟卡使用示意图；
图34为本发明实施例四中己方支付应用通过第三方支付应用绑定支付卡示意图；
图35为本发明实施例四中第三方支付应用通过己方支付应用绑定支付卡示意图；
图36为本发明实施例五中快捷支付装置的结构示意图；
图37为本发明实施例六中快捷支付方法的流程示意图；
图38为本发明实施例七中快捷支付装置的结构示意图。
具体实施方式
以下将结合附图对本发明的技术方案进行清楚、完整的描述，显然，所描述的实施例仅仅是本发明的一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动的前提下所得到的所有其它实施例，都属于本发明所保护的范围。
本申请使用的“模块”、“装置”等术语旨在包括与计算机相关的实体，例如但不限于硬件、固件、软硬件组合、软件或者执行中的软件。例如，模块可以是，但并不仅限于：处理器上运行的进程、处理器、对象、可执行程序、执行的线程、程序和/或计算机。举例来说，计算设备上运行的应用程序和此计算设备都可以是模块。一个或多个模块可以位于执行中的一个进程和/或线程内，一个模块也可以位于一台计算机上和/或分布于两台或更多台计算机之间。
本申请的说明书和权利要求书中的术语“第一”、“第二”和“第三”等是用于区别不同对象，而非用于描述特定顺序。此外，术语“包括”以及它们任何变形，意图在于覆盖不排他的包含。例如包含了一系列步骤或单元的过程、方法、系统、产品或设备没有限定于已列出的步骤或单元，而是可选地还包括没有列出的步骤或单元，或可选地还包括对于这些过程、方法、产品或设备固有的其它步骤或单元。
本发明中所述的服务器，是指提供计算服务的设备，也称为伺服器，该服务器包括但不限于具备支付计算服务能力的服务器、不具备支付计算服务能力的服务器等。
本发明中所述的客户端，是指与服务器相对应，为客户提供本地服务的程序，也称为用户端，包括但不限于移动设备中运行的应用(应用)，计算机、电视、机顶盒等非移动设备中运行的程序等。
本发明的发明人发现，如果终端设备支持多种支付应用，虽然，用户可以选择多种支付应用进行支付，但也面临着用户需要在多种支付应用的客户端间进行切换的问题，操作非常繁琐，不能实现快捷支付，以及对支付应用的统一管理。
即使终端只支持一种支付应用，但考虑到在一个支付应用的客户端中也可能存在多种支付方式，例如，二维码支付、声波支付等。因此，在实际支付时，用户将面临在不同的支付方式之间进行选择或切换的问题，操作也比较繁琐。
进一步地，本发明的发明人还发现，即使用户经常使用某种支付方式，或经常针对某个对象支付固定金额，用户在每次支付时可能仍然需要选择支付功能、支付金额以及支付对象，操作繁琐，效率较低。
因此，本发明的发明人考虑，可以预先在终端中设定用于完成多种支付功能的快捷支付触发条件，这样，在检测到快捷支付触发条件时，可以调用终端支持的第一支付应用执行支付处理，完成快速支付或消费。相比现有需要用户首先在终端已安装的多个支付应用中执行切换操作来选择其所需的支付应用，在启动该支付应用进行相应的支付处理，本发明提供的上述方案，在检测到快捷支付触发条件后即可快速直接地调用第一支付用于执行支付处理，简化了用户在支付过程中的操作步骤，提高了支付效率和用户体验。
下面结合附图和实施例来详细说明本发明的技术方案。
实施例一
如图1所示，本发明实施例一提供了一种快捷支付方法，具体包括：步骤S101：检测快捷支付触发条件；步骤S102：调用终端支持的第一支付应用执行支付处理。
其中，终端中支持的第一支付应用可以为一个或多个，第一支付应用主要是指终端支持的能够提供交易支付的支付应用。终端通过支付宝、微信、翼支付等支付应用，与支付应用中对应的支付服务器共同完成支付业务。其中，终端中支持的第一支付应用可以为一个或多个，第一支付应用主要是指终端支持的能够提供交易支付的支付应用。终端通过支付应用完成支付业务，或通过支付应用与支付应用对应的支付服务器共同完成支付业务。
在本发明的实施例中，在步骤S101中检测快捷支付触发条件的方式，包括：
1)启动第二支付应用，第二支付应用绑定有第一支付应用的预设支付功能；检测用户在第二支付应用中针对预设支付功能的触发操作；
2)启动第二支付应用，第二支付应用绑定有第一支付应用；检测用户在第二支付应用中针对第一支付应用的触发操作；
3)检测用户输入的认证信息。
当在第二支付应用绑定有第一支付应用的预设支付功能的情况下，步骤S101采用上述方式1)执行，相应的，在步骤S102中，调用第一支付应用的预设支付功能执行支付处理。
实际应用中，预设支付功能对应预先设置的支付信息；支付信息包含但不限于：支付方式、支付方账户、支付对象、支付金额、支付时间。其中，支付方账户可以为银行卡账户或支付应用的支付账户。
上述预设支付功能对应的支付信息可以为系统预先设置，也可以为用户预先设置。
其中，支付方式包括信息码支付，如二维码支付、条形码支付，声波支付以及通过生物识别技术识别用户的生物特征的支付，如指纹支付、声纹支付、虹膜支付等。
具体地，调用第一支付应用，根据预设支付功能对应的支付信息，执行相应的支付处理。
其中，支付方式包括在线支付方式和/或离线支付方式；在线支付方式包括转账等需要与支付服务器端进行实时交互的支付方式；离线支付方式包括银行卡支付方式和/或信息码支付方式等。
优选地，支付方式包括信息码支付方式时；更具体地，请求第一支付应用的应用客户端生成信息码支付凭证；在第二支付应用的应用界面显示所述信息码支付凭证；根据显示的信息码支付凭证执行支付处理。其中，信息码支付凭证中包含第一支付应用的应用客户端实时生成的信息码。
例如，请求第一支付应用的应用客户端生成二维码信息，第一支付应用的应用客户端将实时生成的二维码信息发送至第二支付应用，并在第二支付应用的应用界面显示该成二维码信息，随后根据显示的二维码信息通过扫码的方式执行支付处理。
在此，第一支付应用的应用客户端生成信息码，显示在第二支付应用的应用界面中时，可能会存在信息码在应用界面中的显示区域过小的情况，此时可以通过预定的操作对显示在第二支付应用的应用界面中信息码进行显示大小的调整，如当用户在第二支付应用的应用界面中点击信息码时，信息码可放大显示。
优选地，第一支付应用的预设支付功能，可以以虚拟支付卡的形式绑定到第二支付应用。
在本发明的实施例中，当第二支付应用加载第一支付应用的预设支付功能时，若第一支付应用的预设支付功能是以虚拟支付卡的形式绑定到第二支付应用，则可对虚拟支付卡中的信息做信息保护，如将支付方账户、支付对象、支付金额、支付时间中的部分信息进行屏蔽保护。
当在第二支付应用绑定有第一支付应用的情况下，步骤S101采用上述方式2)执行，相应的，在步骤S102中，启动第一支付应用执行支付处理。
优选地，第一支付应用为无卡支付应用；第二支付应用为有卡支付应用。具体地，无卡支付应用为无银行卡的支付应用，有卡支付应用为有银行卡的支付应用，无卡支付应用可以无需绑定银行卡即可实现快捷支付，有卡支付应用可以通过NFC(Near FieldCommunication，近场通信)、MST(Magnetic Secure Transmission，磁信号安全传输)等技术实现银行卡的快捷支付。
优选地，第一支付应用和第二支付应用之间还可以实现信息的互通，可以将第一支付应用中绑定的支付信息同步绑定到第二支付应用；和/或将第二支付应用中绑定的支付信息同步绑定到第一支付应用。其中，支付信息可以为支付方账户(如银行卡)等。
在本发明的实施例中，启动第二支付应用时，第二支付应用绑定有第一支付应用的预设支付功能或第二支付应用绑定有第一支付应用，但检测到终端设备并未安装第一支付应用，则可以生成应用安装提示信息，以用于提示用户安装相应的第一支付应用。
在本发明的实施例中，第一支付应用和第二支付应用之间可传输支付相关信息，该支付相关信息通过第一支付应用的应用客户端生成的会话秘钥加密后传输，第一支付应用的应用客户端将生成的会话秘钥加密后传输给第二支付应用的应用客户端，第二支付应用的应用客户端获取到加密后的会话秘钥，将加密后的会话秘钥传输至终端设备的安全模块进行解密，第二支付应用的应用客户端通过终端设备中的安全模块获得解密后的会话秘钥。本发明实施例中，通过终端设备的安全模块对会话秘钥进行解密，保证了两个应用客户端之间传输信息的安全性，从而提高了支付安全性。
当步骤S101采用上述方式3)执行，即检测快捷支付触发条件包括检测用户输入的认证信息，相应的，在步骤S102中，确定出与用户输入的认证信息对应的第一支付应用的预设支付功能；调用确定出的第一支付应用的预设支付功能执行支付处理。
本发明实施例提出，用户可以预先设置每个认证信息对应的支付功能，例如，当认证信息为指纹信息时，用户可以预先针对不同手指的指纹分别设置不同的支付功能，后续在支付时，用户可以根据想要触发的支付功能，选择输入相应的指纹信息，终端设备根据用户输入的指纹信息，触发相应的支付功能执行支付处理，从而实现了快捷支付。
本发明实施例一中，快捷支付触发条件可以与终端中支持的第一支付应用存在对应关系，以便后期基于快捷支付触发条件的检测，快速启动与快捷支付触发条件对应的第一支付应用，而无需从终端支持的多个第一支付应用中进行选择切换，简化用户操作，实现快捷支付。进一步地，本实施例的快捷支付方法后续可以虚拟卡片的形式展现给用户的，卡片本身承载了一些信息，在支付的时候只要简单操作卡片就可以了，而无需在第一支付应用中执行切换、填充信息等操作，同时用户不主动删除卡片，卡片生成后可以一直存在，供用户重复、多次操作。
本申请中，终端支持的第一支付应用，可以称为第三方支付应用；第一支付应用中的支付客户端可以称为第三方支付客户端；第一支付应用中与第一支付应用对应的支付服务器可以称为第三方支付服务器。
本发明实施例一中，可以在终端预先启动快捷支付设定程序；快捷支付设定程序检测终端中支持的支付应用并生成列表；之后，用户选择其中一个支付应用，并由用户选择支付应用中的预设支付功能。
相比现有需要切换进入选择的支付应用的支付应用之后，再查找并操作相应功能服务，本发明实施例一提供的上述方案，在检测到预先设置的快捷支付触发条件后，可快速触发启动第一支付应用，调用第一支付应用执行支付处理，简化了操作步骤，提高了支付效率和用户体验。
实施例二
本发明实施例二将详细说明通过第二支付应用的启动来实现快捷支付的方案。
本发明实施例二中，检测到快捷支付触发条件(如终端中的第二支付应用的启动，且用户在第二支付应用中针对第一支付应用的预设支付功能执行了触发操作)后，第二支付应用可以向第一支付应用发送支付处理的请求信息，由第一支付应用根据请求信息执行支付处理。
或者，第二支付应用在向第一支付应用发送支付处理的请求信息之前，可以先请求获得第一支付应用的用户授权。获得用户授权后，第二支付应用向第一支付应用发送支付处理的请求信息，由第一支付应用根据请求信息执行支付处理。
或者，第二支付应用绑定有第一支付应用或第一支付应用的预设支付功能，即集成有第一支付应用的第二支付应用向第一支付应用对应的支付服务器发送支付处理的请求信息后，根据支付服务器的反馈，利用集成的第一支付应用执行预设的支付处理。
其中，第二支付应用通过第一支付应用的用户授权后集成第一支付应用，实际应用中，第二支付应用中可以集成第一支付应用的SDK(Software Development Kit，软件开发工具包)。这样，第二支付应用通过第一支付应用的用户授权后，可以通过集成的第一支付应用的SDK，将请求信息发送给第一支付应用的应用客户端或上传至第一支付应用对应的支付服务器；由第一支付应用的应用客户端或第一支付应用对应的支付服务器对第二支付应用的请求信息进行验证；将验证结果作为反馈返回给第二支付应用。验证通过后，第二支付应用可利用集成的第一支付应用完成预设的支付处理功能服务的执行，无需在切换进入第一支付应用后通过第一支付应用访问对应的支付服务器，缩短了访问过程，提高支付安全。
关于第二支付应用向第一支付应用请求用户授权的方法，如图2所示，其具体流程可以包括如下步骤：
S201：第二支付应用生成数字签名，将生成的数字签名发送给第一支付应用，请求第一支付应用授权。
实际应用中，第二支付应用可以预先生成一个密钥对，包括：第一公钥、第一私钥。其中，第一私钥保存在第二支付应用当中，而与第一私钥对应的第一公钥预先传给第一支付应用，由第一支付应用进行存储。
本发明中所述密钥对，可以为对称密钥，或者非对称密钥，或者对称密钥与非对称密钥的相结合的混合密钥等。本发明中所述加密，包括但不限于对称加密、非对称加密、混合加密系统加密等。
其中，第一支付应用可以通过如下至少一种方式获取第一公钥：
预先共享；证书授权中心颁发的数字证书认证。
例如，第一支付应用通过事先共享密钥的方式获取第二支付应用生成的第一公钥。如物理存储卡传递给对方或者是网络上传给第三方对应的服务器。或者，第一支付应用也可以通过证书授权中心(个人或者机构)颁发的数字证书认证的方式获取第二支付应用生成的第一公钥。
这样，第二支付应用可以根据预先生成的第一私钥生成数字签名，将生成的数字签名发送给第一支付应用，请求第一支付应用授权。
S202：第一支付应用验证数字签名，并返回用户授权结果。
具体地，第一支付应用可以利用预先配送保存的第一公钥对数字签名进行解密，验证该数字签名是否合法，即为数字签名的验证过程。如果验证签名失败，则拒绝该请求；如果数字签名通过第一支付应用的验证，则可以确定第二支付应用通过第一支付应用的用户授权。
更优地，数字签名通过第一支付应用的验证之后，第一支付应用可以返回一个用于再次校验的认证码给第二支付应用。
这样，第二支付应用接收第一支付应用返回的认证码；并将接收的认证码发送给第一支付应用，若发送的认证码通过第一支付应用的验证，则可以确定第二支付应用通过第一支付应用的用户授权。
第一支付应用接收到第二支付应用发送的认证码后，可以对认证码进行验证。如果第一支付应用验证认证码有误，则拒绝该请求；如果第二支付应用发送的认证码通过第一支付应用的验证，即验证无误，则第一支付应用可以将授权令牌作为用户授权结果，返回给第二支付应用。相应地，第二支付应用接收第一支付应用返回的授权令牌。返回授权令牌时，可以进行不加密传输，也可以进行加密传输。
其中，返回的授权令牌包括：用于获取用户账号信息的访问令牌。访问令牌具有预设的第一生命周期。
进一步地，授权令牌还可以包括：用于延长第一生命周期的刷新令牌。
其中，刷新令牌具有预设的第二生命周期。
实际应用中，为了加强第一支付应用与第二支付应用之间的安全通信，终端中还可以增设一个安全模块。终端中的安全模块可以预先生成一个密钥对，包括：第二私钥、第二公钥。其中，第二私钥保存在终端中的安全模块当中，而第二公钥存储于第二支付应用中。
这样，第二支付应用在接收第一支付应用返回的认证码后，可以将接收的认证码和终端预先生成的第二公钥发送给第一支付应用。
在第二支付应用发送的认证码通过第一支付应用的验证之后，第一支付应用可以对终端中安全模块预先生成的第二公钥进行保存。
本发明实施例二中，在调用终端支持的第一支付应用执行支付处理的过程中，获得用户授权后，第二支付应用可以向第一支付应用发送支付处理的请求信息，由第一支付应用根据请求信息执行支付处理。
本发明实施例二中，第二支付应用通过第一支付应用的用户授权后，可以集成第一支付应用，集成第一支付应用的SDK。这样，集成有第一支付应用的第二支付应用向第一支付应用对应的应用客户端或支付服务器发送支付处理的请求信息后，可以根据应用客户端或支付服务器的反馈，利用集成的第一支付应用执行支付处理。
实际应用中，为了用户财产安全，加强第二支付应用与第一支付应用之间的安全通信，第二支付应用可以先利用第一支付应用生成的会话密钥加密支付处理的请求信息之后，向第一支付应用发送加密后的请求信息。
其中，第一支付应用返回的会话密钥是经过终端中的安全模块预先生成的第二公钥加密的；第二公钥对应的第二私钥存储于终端中的安全模块。
本发明实施例二中，第二支付应用可以通过如下方式获取第一支付应用生成的会话密钥：第二支付应用生成数字签名，请求第一支付应用生成会话密钥；数字签名通过第一支付应用的验证后，接收第一支付应用返回的会话密钥。
或者，第二支付应用也可以通过如下方式获取第一支付应用生成的会话密钥：第二支付应用生成数字签名，请求第一支付应用生成会话密钥；数字签名和第二支付应用通过第一支付应用的验证后，接收第一支付应用返回的会话密钥。其中，第一支付应用通过如下至少一项确定第二支付应用是否通过验证：第二支付应用的安装文件；第二支付应用的散列值。
具体地，第一支付应用将接收的数字签名进行解密，以此验证数字签名。实际应用中，第一支付应用将接收的数字签名上传给对应的支付服务器(或称为，第三方支付服务器)，由第三方支付服务器进行解密验证。
进一步地，第一支付应用还验证第二支付应用是否为合法客户端。例如，验证第二支付应用对应安装包的签名是否合法；或者根据第二支付应用通过单向散列函数(常见算法有：Message Digest Algorithm 5，MD5；Secure Hash Algorithm，SHA等)生成第二支付应用对应的原始散列值A。第二支付应用预先将该原始散列值A传给第一支付应用。在实际请求过程中，第二支付应用向第一支付应用发出请求的时候，第一支付应用获取第二支付应用的散列值B，将存储的原始散列值A与获取的散列值B进行对比校验，从而判断请求是否合法。
通过上述双重验证，来保证会话密钥的请求是否来自合法用户。如果验证有误，则拒绝该请求，如果验证无误，第一支付应用可以生成一个会话密钥，并且将此会话密钥用第二公钥进行加密处理，将加密之后的密文回传给第二支付应用。
这样，第二支付应用可以通过终端中存储的第二私钥，解密出第一支付应用生成的会话密钥，之后，利用第一支付应用生成的会话密钥加密支付处理的请求信息。
第一支付应用利用会话密钥解密出请求信息之后，可以根据接收的请求信息，执行相应的支付处理。
实际应用中，当第一支付应用根据请求信息执行相应的支付处理之后，第一支付应用此次生成的会话密钥过期失效。也就是说，下一次调用第一支付应用执行支付处理时需重新生成一个会话密钥。
实施例三
本发明实施例三详细说明本发明的快捷支付方案。
实际应用中，将涉及到两个阶段：用户授权过程阶段；支付使用阶段，即支付服务执行阶段。
本发明实施例三中，如图3所示，用户授权过程阶段中涉及的部件可以包括：终端设备中的安全模块、己方支付客户端、第三方支付客户端，以及己方支付服务器、第三方支付服务器。
其中，安全模块用于生成一个密钥对，包括：第二私钥、第二公钥。其中，第二私钥保存在安全模块当中，而第二公钥传给己方支付客户端。己方支付客户端中包括：己方支付模块、集成的第三方支付SDK。
其中，安装己方支付客户端的终端设备和安装第三方支付客户端的终端设备可以为同一设备，也可以为不同设备。终端之间的连接、服务器之间的连接、终端和服务器之间的连接可以是物理连接，也可以是通过以下至少一种网络的无线连接：蓝牙、超宽带、ZigBee、Wi-Fi(wireless fidelity，无线保真)、宏网络等。例如，用户授权过程阶段需要联网才能进行授权；而第二阶段是用户支付使用阶段，即支付阶段，用户支付使用阶段中涉及的设备与用户授权过程阶段相同，设备连接方式可以是一致的，也可以是终端设备与第三方服务器之间没有连接，例如，用户支付使用阶段可以不联网进行支付，即进行离线支付。
在本发明的实施例中，由于第一支付应用支持离线支付，则绑定了第一支付应用或绑定了第一支付应用的预设支付功能的第二支付应用也相应的支持离线支付。
其中，己方支付应用实际上可以作为上述实施例一、实施例二中的第二支付应用；而第三方支付应用可以作为上述实施例一、实施例二中的第一支付应用。第二支付应用的应用客户端可以称为己方支付客户端，第一支付应用的应用客户端可以称为第三方支付客户端。
实际应用中，支付客户端是指安装在终端设备上的客户端，该客户端包括但不限于具有独立支付功能的客户端、不具有独立支付功能但具有部分支付模块的客户端、不具有独立支付功能也不具有部分支付模块的客户端等。支付模块是指集成在上述支付客户端中的模块，该模块包括但不限于具有支付功能的模块、不具有支付功能的模块等。
本发明实施例三中，用户授权过程阶段需要联网才能进行授权。因此，上述部件之间在用户授权过程阶段需要连接起来，连接可以是物理连接，也可以是通过以下至少一种网络的无线连接：蓝牙、超宽带、ZigBee、Wi-Fi、宏网络等。
而第二阶段是支付使用阶段，即支付服务执行阶段，如图3所示，本阶段中涉及的部件与第一阶段相同，终端设备与第三方服务器之间可以连接或者也可以没有连接。也就是说，本阶段可以不联网进行支付，即进行离线支付。
下面详细介绍第一阶段。
用户授权过程阶段具体包括下述三个步骤：步骤1、己方支付服务器生成数字签名，请求第三方支付客户端授权；步骤2、第三方支付服务器验证数字签名，并返回令牌；步骤3、第三方支付客户端保存相关信息。
具体地，如图4所示，用户请求授权(S401)，己方支付服务器生成数字签名，请求第三方支付客户端授权(S402)，如果第三方支付服务器验证数字签名成功(S403)，则返回令牌至己方支付服务器(S404)，否则拒绝该请求(S406)，最后第三方支付客户端保存相关信息(S405)。
其中，用户请求授权，可以通过触发快捷支付触发条件来实现。
本发明实施例三中，步骤1、己方支付服务器生成数字签名，请求第三方支付客户端授权，具体可以包括如下4个子步骤：
1、己方支付服务器预先生成一个密钥对，包括：第一私钥、第一公钥。其中，第一私钥保存在己方支付服务器当中，而第一公钥预先通过某种方式，传给第三方支付服务器保存，如图5所示。其中，所述某种方式可以是通过事先共享密钥的方式，如物理存储卡传递给对方或者是网络上传给第三方对应的服务器；也可以通过证书授权中心(个人或者机构)颁发的数字证书认证的方式。
2、用户请求授权，例如用户申请将第三方支付的虚拟支付卡绑定在己方支付客户端中，此时己方支付客户端中的己方支付模块向己方支付服务器发出申请，如图6所示。
3、己方支付服务器将相关信息用预先生成的密钥对的第一私钥进行加密，己方支付服务器将加密之后的密文(数字签名)连同各种参数，一起下发至己方支付客户端，如图7所示。
4、己方支付客户端调用第三方支付SDK，将前面己方支付服务器下发给己方支付客户端的信息一并传给第三方支付客户端，请求第三方支付客户端进行用户授权认证，如图8所示。例如，若第三方支付客户端处于为登录状态，则显示登录界面，让用户输入账户信息；若第三方支付客户端有密码保护(如字符密码，PIN码，图案加密等)，则显示密码保护界面，让用户进行解密。第三方支付客户端将己方支付客户端传过来的相关信息包含密文(数字签名)上传给第三方支付服务器。
本发明实施例三中，步骤2、第三方支付服务器验证数字签名，并返回令牌，具体可以包括如下3个子步骤：
1、第三方支付服务器用预先配送保存的第一公钥对密文(数字签名)进行解密，验证该密文是否合法，即为数字签名的验证过程，如果验证签名失败，则拒绝该请求；如果验证签名成功，则由第三方支付服务器返回一个认证码(code)给第三方支付客户端，进而第三方支付客户端将此认证码再回传给己方支付客户端，如图9所示。
2、安全模块生成一个密钥对，其中第二私钥保存在安全模块当中，而第二公钥传给己方支付客户端，如图10所示。己方支付客户端将认证码和第二公钥发送给己方支付服务器，而己方支付服务器将认证码和第二公钥发送给第三方支付服务器，如果第三方支付服务器验证认证码有误，则拒绝该请求，如果验证无误，则返回授权令牌给己方支付服务器，返回的授权令牌包括但不限于下述至少一项：访问令牌、刷新令牌。同时，也将第二公钥下发给第三方支付客户端，第三方支付客户端将第二公钥进行保存。
3、访问令牌和刷新令牌可以不加密传输，也可以加密传输。访问令牌是己方支付服务器从第三方支付服务器上获取相应用户账号信息(账户ID包括但不限于登录ID和用户ID等、账户ID即表示己方支付方的ID、账户头像等)的凭证，如图11所示。为了保证安全性，访问令牌和刷新令牌是有一个生命周期的，即在一个有限的时间段内有效，而刷新令牌是可以延长访问令牌的生命周期的，而当刷新令牌过期之后，则需要重新获取访问令牌和刷新令牌。己方支付服务器将获取的用户账号信息，传给己方支付客户端，己方支付客户端将用户账户信息进行显示。
本发明中所述密钥对，可以为对称密钥，或者非对称密钥，或者对称密钥与非对称密钥的相结合的混合密钥等。本发明中所述加密，包括但不限于对称加密、非对称加密、混合加密系统加密等。
本发明实施例三中，步骤3、第三方支付客户端保存相关信息，如上述步骤2中第2点所述，第三方支付客户端保存由己方支付服务器生成的第二公钥。
根据上述提及的用户授权过程阶段中的各步骤的实现，图12提供了用户授权过程阶段示意图。
①用户请求授权
②己方支付服务器预先生成一个密钥对A，其中私钥A保存在己方支付服务器当中，而公钥A预先通过某种方式，传给第三方支付服务器保存。己方支付服务器将相关信息用预先生成的密钥对A的私钥A进行加密，己方支付服务器将加密之后的密文(数字签名)连同各种参数，一起下发至己方支付客户端
③己方支付客户端调用第三方支付，将前面己方支付服务器下发给己方支付客户端的信息一并传给第三方支付客户端，请求第三方支付客户端进行用户授权认证
④第三方支付客户端将己方支付客户端传过来的相关信息包含密文(数字签名)上传给第三方支付服务器。第三方支付服务器用预先配送保存的公钥A对密文(数字签名)进行解密，验证该密文是否合法，即为数字签名的验证过程，如果验证签名失败，则拒绝该请求；如果验证签名成功，则由第三方支付服务器返回一个认证码给第三方支付客户端。
⑤第三方支付客户端将④中认证码回传给己方支付客户端。
⑥安全模块生成一个密钥对B，其中私钥B保存在安全模块当中，而公钥B传给己方支付客户端。
⑦己方支付客户端将认证码和公钥B发送给己方支付服务器。
⑧己方支付服务器将认证码和公钥B发送给第三方支付服务器。
⑨第三方支付服务器返回令牌给己方支付服务器，返回的令牌包括但不限于下述至少一项：访问令牌、刷新令牌。
⑩己方支付服务器使用⑨中的令牌从第三方支付服务器获取用户账号信息，传给己方支付客户端，己方支付客户端将用户账户信息进行显示。
第三方支付SDK通知第三方支付客户端从第三方服务器上获取公钥B。
第三方支付客户端从第三方服务器上获取公钥B。
第三方支付客户端保存公钥B。
下面详细介绍第二阶段，即支付使用阶段。
本发明中，解决密钥配送问题包括但不限于：可以通过事先共享密钥的方式，如物理存储卡传递给对方或者是网络上传给第三方对应的服务器；也可以通过密钥分配中心的方式；也可以通过Diffie-Hellman密钥交换的方式；也可以通过非对称密钥加解密的方式；也可以通过将公钥拆成若干部分，每个部分分别用上述密钥配送方式的组合方式进行配送的方式等。
下面实施例所述的会话密钥的配送方式，即为通过非对称密钥加解密的方式。
以离线支付为例，支付使用阶段具体包括下述五个步骤：
步骤1、己方支付客户端请求第三方支付客户端生成会话密钥；步骤2、第三方支付客户端返回会话密钥；步骤3、己方支付客户端将请求信息用会话密钥加密，发给第三方支付客户端；步骤4、第三方支付客户端用会话密钥解密出请求信息，生成支付凭证并将此凭证返回给己方支付客户端；步骤5、己方支付客户端将返回的支付凭证展示给商户，进而完成支付操作。
具体地，如图13所示，用户请求支付(S1301)，向第三方支付客户端请求会话密钥(S1302)，如果第三方支付方验证请求合法(S1303)，则返回会话密钥至己方支付方(S1304)，否则拒绝该请求(S1308)，然后己方支付方请求支付凭证(S1305)，进一步地，第三方支付方返回支付凭证(S1306)，最后，商户使用支付凭证收款(S1307)。
本发明实施例三中，步骤1、己方支付客户端请求第三方支付客户端生成会话密钥，具体可以通过如下方式实现：
用户请求使用第三方支付方式进行支付，己方支付客户端将相关信息用密钥加密之后的密文(数字签名)传给第三方支付客户端，并向第三方支付客户端请求会话密钥。
其中，用密钥加密相关信息可以在己方支付服务器进行。也可以在己方支付服务器进行，此时，己方支付服务器生成数字签名，请求第三方支付客户端生成会话密钥，如图14所示，
本发明实施例三中，步骤2、第三方支付服务器验证数字签名，并返回会话密钥，具体可以包括如下2个子步骤：
1、第三方支付客户端将接收到的密文进行解密验证(验证签名)，另外第三方支付客户端还验证己方支付客户端是否为合法客户端，例如，己方支付客户端为Android应用，则验证对应Android安装包的签名是否合法；或者根据己方支付客户端通过单向散列函数(常见算法有：Message Digest Algorithm 5，MD5；Secure Hash Algorithm，SHA等)生成己方支付客户端对应的散列值A，己方支付方预先将该散列值A传给第三方支付客户端，在实际己方支付客户端向第三方支付发出请求的时候生成一个己方支付客户端的散列值B，将A、B两个散列值进行对比校验，从而判断请求是否合法。通过上述双重验证，以保证会话密钥的申请来自合法用户，如果验证有误，则拒绝该请求，如果验证无误，第三方支付客户端生成一个会话密钥，并且将此会话密钥用上述第一阶段(用户授权过程阶段)步骤3中的第二公钥进行加密处理，将加密之后的密文回传给己方支付客户端。
此外，第三方支付客户端还可以将接收到的密文发给第三方支付服务器进行解密验证(验证签名)。
2、己方支付客户端将此密文传至安全模块，用上述第一阶段(用户授权过程阶段)步骤2中第二私钥解密，安全模块将解密之后的明文传回给己方支付客户端，从而得到了会话密钥，如图15所示。
本发明实施例三中，步骤3、己方支付客户端将请求信息用会话密钥加密，发给第三方支付客户端，具体可以通过如下方式实现：
己方支付客户端，将用户ID、请求时间、随机数等信息用会话密钥进行加密，并且将加密之后的信息传给第三方支付客户端用于请求支付凭证，例如支付二维码等。
本发明实施例三中，步骤4、第三方支付客户端用会话密钥解密出请求信息，生成支付凭证并将此凭证返回给己方支付客户端，具体可以通过如下方式实现：
第三方支付客户端验证己方支付客户端传过来的加密信息，并且用会话密钥进行解密，如果验证有误，则拒绝该请求，如果验证无误，则生成一个支付凭证，并且用会话密钥进行加密之后传给己方支付客户端，如图16所示。
同时，该会话密钥过期失效，即用户每请求一次第三方支付则重新生成一个会话密钥。终端设备在合适的时候将账户ID、渠道ID、己方支付客户端请求时间、随机数、终端设备ID等信息同步至第三方支付服务器，其中，在合适的时候同步指的是一旦终端设备连接上网络的时候，将处于网络断开期间的所述信息实时同步至第三方支付服务器、或者是终端设备预设每隔一段时间，将此时间段内的所述信息同步至第三方支付服务器，若已到同步时间点，但是此时无网络，那么当终端设备一旦连上网络，则立即执行同步操作。
本发明实施例三中，步骤5、己方支付客户端将返回的支付凭证展示给商户，进而完成支付操作，具体可以通过如下方式实现：
己方支付客户端用会话密钥解密得到这个支付凭证，并将支付凭证展示出来，商户与第三方支付服务器进行数据交互即可通过该支付凭证完成支付，例如支付凭证包含二维码，则商户只需要扫描该二维码即可完成支付。
根据上述提及的支付使用阶段中的各步骤的实现，图17提供了用户支付使用阶段示意图。
①用户请求使用第三方支付方式进行支付，己方支付客户端将相关信息用密钥A加密之后的密文(数字签名)传给第三方支付客户端，并向第三方支付客户端请求会话密钥。
②第三方支付客户端将接收到的密文进行解密验证(验证签名)，另外第三方支付客户端还验证己方支付客户端是否为合法客户端，第三方支付客户端生成一个会话密钥，并且将此会话密钥用上述公钥B进行加密处理，将加密之后的密文回传给己方支付客户端。
③己方支付客户端将此密文传至安全模块，用上述第一阶段(用户授权过程阶段)步骤二中的第2点所述私钥解密，安全模块将解密之后的明文传回给己方支付客户端。
④己方支付客户端，将用户ID、请求时间、随机数等信息用会话密钥进行加密，并且将加密之后的信息传给第三方支付客户端用于请求支付凭证，例如支付二维码等。
⑤第三方支付客户端验证己方支付客户端传过来的加密信息，并且用会话密钥进行解密，如果验证有误，则拒绝该请求，如果验证无误，则生成一个支付凭证。
⑥终端设备在合适的时候将账户ID、渠道ID、己方支付客户端请求时间、随机数、终端设备ID等信息同步至第三方支付服务器。
⑦将上述⑤中的支付凭证用会话密钥进行加密之后传给己方支付客户端，同时，该会话密钥过期失效，即用户每请求一次第三方支付则重新生成一个会话密钥。
⑧己方支付客户端用会话密钥解密得到这个支付凭证。
⑨己方支付客户端将支付凭证展示出来。
⑩商户与第三方支付服务器进行数据交互即可通过该支付凭证完成支付。
需要注意的是，本发明实施例三中，在用户授权过程阶段和支付使用阶段，共涉及到了三对密钥对，第一密钥对，第二密钥对，第三密钥对即会话密钥；其中，第一密钥对包括：第一公钥、第一私钥；第二密钥对包括：第二公钥、第二私钥。下面表3详细介绍这三对密钥对。
表3三对密钥对的介绍
/>
/>
上述整个流程当中，涉及到两个重要部件：安全模块、第三方支付客户端，下面详细介绍这两个重要部件。
安全模块：
本发明中所述安全模块，可分为硬件部分和软件部分；其中，硬件部分为物理装置，为软件部分运行的物质基础。安全模块的硬件部分可以为终端设备中内置硬件设备；也可以是终端设备的外置硬件设备。若为外置硬件设备，则安全模块和终端设备之间的连接可以是物理连接，也可以是通过以下至少一种网络的无线连接：蓝牙、超宽带、ZigBee、Wi-Fi(wireless fidelity，无线保真)、宏网络等。其中，软件部分为程序、规程、规则，以及可能有的文件、文档及数据等，软件部分是运行、存储在硬件部分之上的。本发明中所述安全模块，具体实施方案包括但不限于下述至少一项：安全元素(Secure Element，SE，通常是智能卡)、可信执行环境(Trusted Execution Environment，TEE)、终端设备上的操作系统的本身的安全系统运行环境或者独立出的运行环境等。
具体地，本发明中安全模块可以是，使用安全系统运行环境和TEE组合的方案，如图18所示。安全系统运行环境为应用程序的运行提供了一个安全的运行环境；而TEE则进行，可信计算、数据加密、系统保护、安全输入、安全显示、安全存储。TEE内部API主要包含了密钥管理，密码算法，安全存储，安全时钟资源和服务，还有扩展的可信UI等API。图19给出的了可信执行环境典型的终端架构示意图。
如果在本发明的流程中没有加入第三方支付客户端这一关键环节，则己方支付客户端可以不通过第三支付客户端而直接与第三方支付服务器进行交互，而加入第三方支付客户端这一关键环节，有如下优势：
本发明的方案中，对己方支付客户端而言：
1)从安全性角度来说，己方支付客户端可直接与第三方支付客户端进行数据交互，将第三方支付客户端和第三方支付服务器视为一个整体，提升安全性。2)容易形成统一标准，便于将本发明所述的方案，直接用于集成其他第三方支付。3)实现离线支付，提升用户体验。
对第三方支付客户端而言：
1)从安全性角度来说，第三方支付服务器的接口不对其他方公开，只供第三方支付客户端使用，提升安全性。2)容易形成统一标准，便于将本发明所述的方案，直接用于其他己方支付客户端，即按照本发明所述的方案将第三方支付客户端集成到终端中的其他应用。3)提升第三支付客户端在终端设备上的安装量。4)实现离线支付，提升用户体验。
本发明实施例三中，第一阶段即用户授权过程阶段是可选的。也就是活，可以跳过第一阶段，直接进行第二阶段即支付使用阶段。
具体地，终端设备检测第三方支付客户端在终端设备上的运行环境是否安全，在用户需要支付的时候，终端设备通知第三方支付客户端显示相应功能的界面，完成快速支付或消费。相比传统的进入第三方应用，查找并操作相应功能，简化了操作步骤。其中，所述用户需要支付的时候，可以是终端设备在任意界面，即终端设备在任意界面的时候，用户可以快速启动显示第三方支付客户端的相应功能的界面，从而完成快捷支付或消费。
本发明提出，在第二支付应用中安全集成第一支付应用的方法，第二支付应用的应用客户端通过第一支付应用SDK与第一支付应用的应用客户端进行交互，第二支付应用的应用客户端与第二支付服务器进行交互，第一支付应用的应用客户端与第一支付服务器进行交互，第一支付服务器与第二支付服务器进行交互。在上述交互的过程中，利用多种密码技术，包括：对称加密、非对称加密以及二者的混合加密系统、单向散列函数、消息认证码、数字签名、伪随机数生成器等，针对本流程中的安全威胁的机密性、完整性、认证、不可否认性，即防窃听、防篡改、防伪装、防否认，进行了有效安全的处理，最大限度地完成了第一支付应用的应用客户端/服务器与第二支付应用的应用客户端/服务器可信、安全的数据通信和数据交互，从而实现了将第一支付应用安全集成在第二支付应用之中。另外，将多个第一支付应用安全集成在第一支付应用中，也就是说，第二支付应用的应用客户端包含多个第一支付应用的统一中心/入口，便于用户在实际支付操作中的管理和选择，从而较大幅度地提升了用户使用体验。
实施例四
第一支付应用的预设支付功能，可以以虚拟支付卡的形式绑定到第二支付应用。
本发明实施例四，将具体说明调用第一支付应用，根据预设支付功能对应的支付信息，执行相应的支付处理。其中，支付信息包含但不限于：支付方式、支付方账户、支付对象、支付金额、支付时间。
实际应用中，可以将预先设置了支付方式、支付方账户、支付对象、支付金额、支付时间等支付信息的快捷支付功能作为虚拟支付卡绑定到终端中的第二支付应用，即己方支付应用(即第二支付应用)。而卡片绑定实质上是用户授权己方的过程。
本发明实施例四中，提供第三方支付应用(即第一支付应用)虚拟支付卡(以下简称虚拟卡)、多功能虚拟卡的绑定和使用方案。虚拟卡片生成后需存储到己方客户端数据库中，己方客户端数据库用于存储虚拟卡的支付信息。己方客户端数据库设计如表4所示。
表4己方客户端数据库
下面详细介绍第三方支付应用虚拟卡的绑定和使用方案
可以通过本发明的快捷支付方案来快速启动支付应用，相当于通过绑定的第一支付应用虚拟卡，快速启动进入第一支付应用，即将第一支付应用虚拟卡作为第一支付应用的快捷入口。
这样，当用户触发快捷支付触发条件之后，用户通过此卡片可以快速启动第三方支付应用，而无需退出当前应用再选择进入第三方支付应用，简化了用户操作。
本发明实施例四中，第三方支付应用虚拟卡的绑定方案，如图20所示，可以包括如下步骤：S2001：用户选择添加第三方支付应用卡片；S2002：己方支付客户端负责检测终端设备中预装安装的第三方支付应用；S2003：生成第三方支付应用列表；S2004：用户选择一个第三方支付应用；S2005：启动用户授权界面；S2006：用户确认用户名和密码。
考虑到此时针对用户名有三种情况：
1)如果第三方支付应用还未有用户登录，则用户授权界面需要用户手动输入用户名并输入该用户名对应的密码，或者通过其他方式进行登录，如指纹登录等。
2)如果第三方支付应用已有登录用户，则用户授权界面默认用户为第三方支付应用此时的登录用户，用户只需输入当前用户名对应的密码即可。
3)如果第三方支付应用已有登录用户，则用户授权界面默认用户为第三方支付应用此时的登录用户，用户可以根据需要修改默认用户名选择其它账号进行授权并输入该用户名对应的密码。
因此，本发明实施例四，用户名和密码确认后，执行步骤S2007：判断授权是否通过。授权的流程和实施例三中用户授权阶段的流程一样。如果授权通过则生成支付应用的虚拟卡，否则，生成失败流程结束。
本发明实施例四中，图21提供了第三方支付应用虚拟卡绑定示意图。
如图21所示，终端提供第三方支付应用卡片和多功能卡片的绑定添加链接；在用户点击第三方支付应用卡片的链接之后，可以选择第三方支付应用。终端中支持的第三方支付应用可以包括：第三方支付应用1、第三方支付应用2、第三方支付应用3等等；用户选择第三方支付应用之后，启动选择的第三方支付应用的用户授权界面；第三方支付应用授权时，用户确定用户名、密码等信息之后，生成卡片并添加到终端支持的功能服务的卡片列表中。
其中，步骤S2004～步骤S2006为可选步骤，如果只能添加一个默认的第三方支付应用，则用户无需选择第三方支付应用，如果终端设备当前已登录第三方支付应用，则可以无需用户确认用户名密码，也可以无需启动用户授权界面。
下面详细介绍多功能虚拟卡的绑定和使用方案
用户可以预先设置支付功能对应的支付信息，例如，设置某个支付功能的支付方式、支付方账户、支付对象、支付金额、支付时间等支付信息中的至少一项，从而得到了预设了支付信息后的快捷支付功能，该快捷支付功能可以但不限于以虚拟支付卡片的形式或虚拟控件的形式在支付应用中呈现，用户在支付时，可以触发该快捷支付功能，终端设备即可根据用户预先设置的支付信息进行快捷支付处理，如果还需要用户提供其他信息，则可以提示用户输入或选择。
用户可以针对某种支付方式进行设置，生成对应某种支付方式的虚拟卡(例如，信息码支付卡)，或用户针对支付对象、支付方式和支付金额进行设置，生成快捷支付或消费的虚拟卡，例如，定向转账卡、手机话费充值卡、燃气充值卡等。己方支付客户端可以管理多个第三方支付应用下的功能虚拟卡，避免了多个支付应用间切换，并且卡片被保存到己方的数据库中，可以重复使用，避免了在多个支付应用的频繁操作。
根据第三方支付应用所提供的服务，多功能虚拟卡可以分为如下几种类型，不限于以下类型：
1)支付类型卡片：基于第三方支付应用所提供的支付方式等支付信息，可通过用户选择生成相应的虚拟支付卡片；己方支付客户端也可根据用户支付行为(可通过第三方支付应用的支付记录获取)，推荐用户以前最常使用的支付信息方式生成此类卡片。用户可以选择基于哪个支付应用生成此类卡片。
2)转账类型卡片：基于第三方支付应用所提供的转账服务，生成具有明确支付信息(如转账对象和转账金额)的卡片，卡片生成后保存到己方数据库，可以重复使用。用户可以选择基于哪个支付应用生成此类卡片。
3)充值类型卡片：此卡片为预付费类型卡片，基于第三方支付应用所提供的充值服务，生成具有明确支付信息(如充值对象和充值金额)的卡片，用户可以选择基于哪个支付应用生成充值卡片；己方支付客户端也可通过比价及优惠政策查询的方式推荐用户选用最优的支付应用生成充值卡片。例如手机充值卡，当用户选择充值100元时，己方支付客户端可以比较100元充值卡在各个支付应用上的实际售价，从而推荐用户选用最优的支付应用来生成此充值卡。卡片生成后保存到己方数据库，可以重复使用。
4)缴费类型卡片：基于第三方支付应用所提供的缴费服务，生成具有明确支付信息(如缴费对象和缴费金额)的卡片，用户可以选择基于哪个支付应用生成缴费卡片。己方支付客户端也可通过查找优惠的方式推荐用户选用最优的支付应用生成缴费卡片。例如生成违章缴费时，某个支付应用有优惠活动，优先推荐此第三方支付应用生成缴费卡片。用户可以选择基于哪个支付应用生成此类卡片。
为保证多功能虚拟卡片使用的安全性，用户选择使用虚拟卡片的时候，可以加入一些生物识别技术，例如指纹，虹膜，耳孔等，防止非用户本人操作虚拟卡片。
下面将分别介绍支付卡、转账卡、充值卡、缴费卡的绑定和使用。
1.支付虚拟卡绑定和使用
本发明实施例四中，支付虚拟卡的绑定方案，如图22所示，可以包括如下步骤：S2201：用户选择添加多功能卡片；S2202：己方支付客户端显示多功能卡片类型列表供用户选择；S2203：用户选择支付类型卡片。
其中，多功能卡片类型列表是己方支付客户端根据目前第三方支付应用所提供的服务而生成的，不限于以下几种：支付类型卡片，转账类型卡片，充值类型卡片，缴费类型卡片。
用户选择支付类型卡片之后，执行步骤S2204：己方支付客户端把提供支付服务的支付应用列表展示给用户，用户选择支付应用；S2205：启动用户授权界面；S2206：用户确认用户名和密码。
本发明实施例四，用户名和密码确认后，执行步骤S2207：判断授权是否通过。授权的流程可参考实施例三中用户授权阶段的流程。如果授权通过则执行步骤S2208：显示该支付应用下的支付信息；S2209：用户选择支付信息。其中，用户可以自己手动选择支付信息，己方支付客户端也可以通过该第三方支付应用获取用户常用的支付信息推荐用户使用。最后，执行步骤S2210：基于用户选择的支付信息，生成虚拟卡。
本发明实施例四中，图23提供了支付虚拟卡绑定示意图。
如图23所示，终端提供第三方支付应用卡片和多功能卡片的绑定添加链接；在用户点击多功能卡片的链接之后，可以选择多功能卡片类型。终端中支持添加的卡片类型可以包括：支付卡片、转账卡片、充值卡片、缴费卡片等等；用户选择第三方支付应用之后，启动选择的第三方支付应用的用户授权界面；第三方支付应用授权时，用户确定用户名、密码等信息之后，选择第三方支付应用支付信息。第三方支付应用支付信息中的支付方式可以包括：二维码支付、条形码支付、声波支付以及通过生物识别技术识别用户的生物特征的支付；其中，通过生物识别技术识别用户的生物特征的支付包括但不限于指纹支付、声纹支付、虹膜支付等。用户选择支付信息后，生成卡片并添加到终端支持的功能服务的卡片列表中。
图23只是本发明所述情况中的一种，凡是和图23所述类似，例如，更改步骤的顺序，增加或者减少其中步骤，均属于本发明所保护的范围。具体的，添加卡片②、选择第三方支付应用③、第三方支付应用授权④，选择第三方支付应用支付方式⑤，上述四种步骤，任意更改顺序进行组合，均属于本发明的保护范围。
本发明实施例四中，图24提供了支付虚拟卡使用示意图。如图24所示，用户从卡片列表中选择二维码卡来支付，己方支付客户端可以从第三方支付应用获取二维码并展示给用户；商家扫码后，第三方支付系统完成支付。其中，支付流程可参考前面实施例三中支付使用阶段。
2.转账虚拟卡绑定和使用
本发明实施例四中，转账虚拟卡的绑定方案，如图25所示，可以包括如下步骤：S2501：用户选择添加多功能卡片；S2502：己方支付客户端显示多功能卡片类型列表供用户选择。S2503：用户选择转账类型卡片。
用户选择转账类型卡片之后，执行步骤S2504：己方支付客户端把提供转账服务的支付应用列表展示给用户，用户选择支付应用；S2505：启动用户授权界面；S2506：用户确认用户名和密码。
本发明实施例四，用户名和密码确认后，执行步骤S2507：判断授权是否通过。授权的流程可参考实施例三中用户授权阶段的流程。如果授权通过则执行步骤S2508：填写转账信息。转账信息包括：转账对象，转账金额和付款方式。
其中，转账对象：可以是银行账号或该支付应用下的其他账号。转账金额：用户根据实际情况填写。付款方式：默认使用第三方支付应用的默认付款方式，如果用户选择其他，以用户的修改为准。
信息填写完毕后，执行步骤S2509：生成相应转账虚拟卡。
本发明实施例四中，图26提供了转账虚拟卡绑定示意图。
如图26所示，终端提供第三方支付应用卡片和多功能卡片的绑定添加链接；在用户点击多功能卡片的链接之后，可以选择多功能卡片类型。终端中支持添加的卡片类型可以包括：支付卡片、转账卡片、充值卡片、缴费卡片等等。用户选择转账卡片之后，选择第三方支付应用，并启动选择的第三方支付应用的用户授权界面；第三方支付应用授权时，用户确定用户名、密码等信息之后，填写转账信息，包括：转账对象、金额、付款方式等。基于转账信息，生成转账卡片并添加到终端支持的功能服务的卡片列表中。
图26只是本发明所述情况中的一种，凡是和图26所述类似，例如，更改步骤的顺序，增加或者减少其中步骤，均属于本发明所保护的范围。具体的，添加卡片②、选择第三方支付应用③、第三方支付应用授权④，上述三种步骤，任意更改顺序进行组合，均属于本发明的保护范围。
本发明实施例四中，图27提供了转账虚拟卡使用示意图。如图27所示，用户从卡片列表中选择转账类型卡片，用户确定转账后，后台己方支付系统和第三方支付系统交互完成转账业务其中，支付流程可参考前面实施例三中支付使用阶段。进一步地，还可以将转账结果展示给用户，用户可继续选择卡片操作。
3.充值虚拟卡绑定和使用
本发明实施例四中，充值虚拟卡的绑定方案，如图28所示，可以包括如下步骤：
S2801：用户选择添加多功能卡片；S2802：己方支付客户端显示多功能卡片类型列表供用户选择。S2803：用户选择充值类型卡片。
其中，多功能卡片类型列表是己方支付客户端根据目前第三方支付应用所提供的服务而生成的，不限于以下几种：支付类型卡片，转账类型卡片，充值类型卡片，缴费类型卡片。
用户选择充值类型卡片之后，执行步骤S2804：己方支付客户端把提供充值服务的支付应用列表展示给用户，用户选择支付应用；S2805：启动用户授权界面；S2806：用户确认用户名和密码。
本发明实施例四，用户名和密码确认后，执行步骤S2507：判断授权是否通过。授权的流程可参考实施例三中用户授权阶段的流程。
如果授权通过则执行步骤S2808：己方支付客户端查询第三方支付支持的充值类型即预付费服务类型(例如手机话费充值，加油卡充值，燃气卡充值等等)，并把充值类型列表展示给用户，用户选择充值类型。S2909：针对充值类型生成卡片编辑界面，用户填写充值信息，包括充值对象、充值金额及付款方式。
其中，充值对象：依赖于充值类型，充值类型决定了充值对象的属性。充值金额：用户根据实际需求填写。付款方式：默认使用第三方支付应用的默认付款方式，如果用户选择其他，以用户的修改为准。
充值信息填写完毕后，执行步骤S2810：己方支付客户端根据用户的充值类型和充值金额对各个第三方支付应用进行比价及优惠政策查询，例如优惠券，折扣等等；S2811：推荐用户最优第三方支付应用。
如果系统查询到的最优第三方支付应用和当前用户选择的第三方支付应用不一样，执行步骤S2812：询问用户是否切换第三方支付应用；S2814：如果用户同意切换，则启用新第三方支付应用的授权界面；S2815：用户确认此第三方支付应用下的用户名和密码；S2816：判断授权是否通过；S2817：授权通过后让用户确认充值信息。S2813：如果用户不修改相应的信息，则生成相应充值虚拟卡。如果用户修改充值金额则执行步骤S2810：重新进行第三方支付应用间的比价及优惠政策查询。
本发明实施例四中，图29提供了充值虚拟卡绑定示意图。
如图29所示，终端提供第三方支付应用卡片和多功能卡片的绑定添加链接；在用户点击多功能卡片的链接之后，可以选择多功能卡片类型。终端中支持添加的卡片类型可以包括：支付卡片、转账卡片、充值卡片、缴费卡片等等。用户选择充值卡片之后，选择第三方支付应用，并启动选择的第三方支付应用的用户授权界面；第三方支付应用授权时，用户确定用户名、密码等信息之后，选择充值类型，比如话费充值、流量充值、加油卡充值。选择充值类型之后，编辑卡片中的信息，比如，充值金额、充值卡号、支付方式等；基于卡片中的信息，生成充值卡片并添加到终端支持的功能服务的卡片列表中。
本发明实施例四中，图30提供了充值虚拟卡使用示意图。如图30所示，用户从卡片列表中选择手机话费充值卡，用户确定充值后，后台己方支付系统和第三方支付系统交互完成转账业务，其中，支付流程可参考前面实施例三中支付使用阶段。进一步地，还可以将充值结果展示给用户，用户可继续选择卡片操作。
4.缴费虚拟卡绑定和使用
本发明实施例四中，缴费虚拟卡的绑定方案，如图31所示，可以包括如下步骤：
S3101：用户选择添加多功能卡片；S3102：己方支付客户端显示多功能卡片类型列表供用户选。S3103：用户选择缴费类型卡片。
其中，多功能卡片类型列表是己方支付客户端根据目前第三方支付应用所提供的服务而生成的，不限于以下几种：支付类型卡片，转账类型卡片，充值类型卡片，缴费类型卡片。
用户选择缴费类型卡片之后，执行步骤S3104：己方支付客户端把提供缴费服务的支付应用列表展示给用户，用户选择支付应用；S3105：启动用户授权界面；S3106：用户确认用户名和密码。
本发明实施例四，用户名和密码确认后，执行步骤S3107：判断授权是否通过。授权的流程可参考实施例三中用户授权阶段的流程。
如果授权通过则执行步骤S3108：己方支付客户端查询第三方支付支持的缴费类型(例如水费，电费，燃气卡，有线电视，交通违章罚款等等)，并把缴费类型列表展示给用户，用户选择缴费类型。
S3109：针对缴费类型生成卡片编辑界面，用户填写缴费信息，包括缴费对象、缴费金额及付款方式。
其中，缴费信息同样可以通过客户端分析用户信息、邮件、及时消息等或由其他定制服务推送自动获得。缴费对象：缴费是后付费类型，用户需要填写一个账单号，系统根据账单号后台查询详细的缴费或用户手动填写。付款方式：默认使用第三方支付应用的默认付款方式，如果用户选择其他，以用户的修改为准。
S3110：己方支付客户端根据用户的缴费类型和缴费金额对各个第三方支付应用进行比价及优惠政策查询，例如优惠券，折扣等等。
S3111：推荐用户最优第三方支付应用。
S3112：如果系统查询到的最优第三方支付应用和当前用户选择的第三方支付应用不一样，询问用户是否切换第三方支付应用。
S3114：如果用户同意切换，则启用新第三方支付应用的授权界面.
S3115：用户确认此第三方支付应用下的用户名和密码；S3116：判断授权是否通过。
S3117：授权通过后让用户确认缴费信息。S3113：如果用户不修改相应的信息，则生成相应缴费虚拟卡。如果用户修改缴费金额则执行步骤S3110：重新进行第三方支付应用间的比价及优惠政策查询。
本发明实施例四中，图32提供了缴费虚拟卡绑定示意图。
如图32所示，终端提供第三方支付应用卡片和多功能卡片的绑定添加链接；在用户点击多功能卡片的链接之后，可以选择多功能卡片类型。终端中支持添加的卡片类型可以包括：支付卡片、转账卡片、充值卡片、缴费卡片等等。用户选择缴费卡片之后，选择第三方支付应用，并启动选择的第三方支付应用的用户授权界面；第三方支付应用授权时，用户确定用户名、密码等信息之后，选择缴费类型，比如缴水费、缴电费、缴交通违章罚款等。选择缴费类型之后，编辑卡片中的信息，比如，缴费金额、水表号、支付方式等；基于卡片中的信息，生成缴费卡片并添加到终端支持的功能服务的卡片列表中。
本发明实施例四中，图33提供了缴费虚拟卡使用示意图。如图30所示，用户从卡片列表中选择自来水缴费卡，用户确定缴费后，后台己方支付系统和第三方支付系统交互完成转账业务其中，支付流程可参考前面实施例三中支付使用阶段。进一步地，还可以将缴费结果展示给用户，用户可继续选择卡片操作。
本发明实施例四中，绑定的虚拟卡片是可编辑的，包括：删除和修改。
删除操作：对已经生成的卡片用户选择删除操作，己方支付客户端需根据卡片ID删除该卡片对应的数据库信息即可。
修改操作：对已经生成的卡片，只允许用户修改卡片内容，卡片内容包括缴费对象、缴费金额和付款方式，特别的对于由特定账单生成的缴费类型的卡片缴费对象和缴费金额是不可修改。
支付应用，账号信息因为已经通过用户授权是不能更改的。卡片类型是生成时确定的，因此也不能修改。修改后的数据写入己方数据库。
本发明实施例四中，还可以将第一支付应用中绑定的支付信息同步绑定到第二支付应用；和/或将第二支付应用中绑定的支付信息同步绑定到第一支付应用。
例如，己方支付应用可以通过第三方支付应用绑定支付卡。具体地，如图34所示，可以通过如下步骤实现：
1.用户请求同步第三方支付应用的支付卡(如银行卡信息)到己方支付应用。
2.己方支付客户端向第三方支付客户端请求卡信息和安全会话用的密钥(提供签名和包名)。
3.第三方支付客户端验证请求有效性后，如果用户授权，则把会话密钥用第二公钥加密后发送给己方支付客户端。
4.己方支付客户端向第三方支付客户端请求卡信息。
5.第三方支付客户端向第三方支付服务器请求卡信息。
6.第三方支付服务器返回卡信息(如果多张卡返回卡列表)。
7.第三方支付客户端将信息通过安全密钥加密后发送给己方支付客户端。
8.己方支付客户端根据获取的卡信息向己方支付服务器发送请求获取银行信息。
9.己方支付服务器向银银行卡服务器(如银联服务器)请求银行信息。
10.银联服务器返回银行在银联的索引和卡种类。
11.己方支付服务器将银行索引,卡种类返给己方支付客户端。
12.己方支付客户端询问用户许可(TC)。
13.己方支付客户端将用户许可和加密后的银行卡信息发送给己方支付服务器。
14.己方支付服务器向银联服务器申请卡注册。
15.银联服务器向发卡方申请卡注册。
16.发卡方返回一个虚拟卡号(为安全本地不存储原卡号)。
17.银联服务器返回卡信息。
18.己方支付服务器返回卡信息，之后己方支付客户端发起卡绑定操作，完成第三方卡卡的信息同步和绑定。如果用户多张卡，则按照前述步骤7开始逐卡绑定。
在己方支付应用和第三方支付应用之间的卡信息的同步方案中，第三方支付也可以通过己方支付绑定支付卡。如图35所示，具体可以通过如下步骤实现：
1.用户请求同步己方支付应用的支付卡到第三方支付应用。
2.第三方支付客户端向己方支付客户端申请同步卡(提供第三方支付应用签名和包名)。
3.己方支付验证第三方支付应用签名后，由用户选择同步的卡片。己方支付客户端上传用户选择的卡到己方支付服务器，同时向服务器请求签名A(己方支付服务器生成)。
4.己方支付服务器记录用户选择的卡(虚拟卡号)和对应流水号，并返回此流水号和签名A。
5.己方支付客户端把流水号和签名A发送给第三方支付客户端。
6.第三方支付客户端通过流水号和签名A请求卡信息。
7.第三方支付服务器通过流水号和签名B(第三方支付服务器生成)向己方支付服务器请求卡信息。
8.己方支付服务器验证签名B和请求，返回虚拟卡号等卡信息。(多张卡会返回卡列表)。
9.第三方支付服务器向银行卡服务器(如银联服务器)通过虚拟卡号请求卡ID(实体卡号相关，后续用于获取实体卡号)。
10.银联服务器返回卡号ID。
11.第三方支付服务器向发卡方通过银行卡ID请求银行卡号。
12.发卡方返回银行实体卡号等信息.。后续，第三方支付客户端按照自有流程绑定银行卡。如果是多张，由前述流程8逐卡绑定。
本发明实施例还提出，也可以不需要在第二支付应用中绑定第一支付应用，终端可以直接根据用户输入的认证信息调用对应的第一支付应用的预设支付功能执行支付处理，或者由终端设备中的己方支付客户端负责检测用户输入的认证信息是否与第三方支付应用的预设支付功能对应，通知第三方支付应用执行支付处理完成快速支付或消费，简化了支付处理的操作步骤。
此方案包含如下流程：
1、快捷支付启动设置
可以通过一些识别技术，例如指纹识别，虹膜识别等快速的把支付应用调用起来，完成支付或消费。
具体的，终端设备启动快捷支付设定程序，其中，用户可以在任意界面启动快捷支付设定程序，用户也可以在己方支付客户端的应用界面启动快捷支付设定程序。
快捷支付设定程序检测终端中存在的支付应用并生成列表，用户选择其中一个支付应用，用户选择支付应用中的支付功能，其中，用户可以选择默认支付信息的支付功能，此外，用户也可以预先设置支付功能的支付信息。启动此快捷支付方式所对应的识别技术，识别用户输入的认证信息(指纹，虹膜等)，并检测用户输入的认证信息是否与其他支付功能对应的支付信息重复，若重复，则提示用户重新输入，终端设备保存用户输入的认证信息与支付功能之间的对应关系，后面用于调用支付功能进行快速支付。
例如，用户可以设定不同的手指用于启动不同的支付功能。
举例如下：
手指编号 支付应用 支付功能
1 支付应用1 二维码支付
2 支付应用2 声波支付
5 支付应用1 手机话费充值服务
6 支付应用3 转账服务
8 支付应用2 缴费服务
或虹膜设置
虹膜 支付应用 支付功能
左眼 支付应用1 二维码支付
右眼 支付应用2 手机话费充值服务
2、启动快捷支付
终端在正常工作的状态(包括锁屏或解锁后)下，一旦检测到用户输入的认证信息满足某一支付应用的预设支付功能，则调用该支付应用的预设支付功能执行支付处理。
或者，己方支付应用启动，己方支付客户端检测到用户输入的认证信息满足某一第三方支付应用的预设支付功能，则调用该第三方支付应用的预设支付功能执行支付处理。
具体的，用户输入认证信息(指纹或虹膜或其他生物特征)，终端设备检测该认证信息是否有预先设定的支付功能，如果没有，则不能启用快捷支付；如果存在，则通知相应的支付应用启动该支付功能进行支付处理。
实施例五
基于实施例一提供的快捷支付方法，本发明实施例五提供了一种快捷支付装置，如图36所示，包括：触发条件检测模块3601和第一支付模块3602。
其中，触发条件检测模块3601用于检测快捷支付触发条件；
第一支付模块3602用于调用终端支持的第一支付应用执行支付处理。
本发明实施例五中，快捷支付装置中的触发条件检测模块3601和第一支付模块3602的具体功能实现，可参考实施例一的快捷支付方法中各步骤的具体实现，在此不再赘述。
本发明的技术方案中，在检测到快捷支付触发条件时，调用终端支持的第一支付应用执行支付处理，完成快速支付或消费。相比现有需要用户首先在终端已安装的多个支付应用中执行切换操作来选择其所需的支付应用，在启动该支付应用进行相应的支付处理，本发明提供的上述方案，在检测到快捷支付触发条件后即可快速直接地调用第一支付用于执行支付处理，简化了用户在支付过程中的操作步骤，提高了支付效率和用户体验。
实施例六
本发明实施例六提供了一种快捷支付方法，如图37所示，包括：步骤S3701：启动支付应用；步骤S3702：检测针对支付应用的预设支付功能的触发操作，其中，预设支付功能对应用户预先设置的支付信息；步骤S3703：根据预设支付功能对应的支付信息，执行相应的支付处理。
其中，支付信息包含下述至少一项：
支付方式、支付方账户、支付对象、支付金额、支付时间。
本发明实施例五中，用户可以预先设置支付功能对应的支付信息，例如，设置某个支付功能的支付方式、支付方账户、支付对象、支付金额、支付时间等支付信息中的至少一项，从而得到了预设了支付信息后的快捷支付功能，该快捷支付功能可以但不限于以虚拟支付卡片的形式或虚拟控件的形式在支付应用中呈现，用户在支付时，可以触发该快捷支付功能，终端设备即可根据用户预先设置的支付信息进行快捷支付处理，如果还需要用户提供其他信息，则可以提示用户输入或选择。
其中，终端设备在执行支付处理之前，可以对用户进行身份认证，即用户鉴权。
本发明的技术方案中，用户可预先对支付信息进行设置，在检测到针对支付应用的预设支付功能的触发操作时，根据预设支付功能对应的用户预先设置的支付信息，直接执行相应的支付处理，完成快速支付；由于支付信息为用户预先设置，可满足用户个性化的快捷支付需求；同时，由于支付信息预先设置，无需用户在支付过程中执行任何信息输入的操作，从而提高了支付效率并提升了用户支付体验。
实施例七
基于实施例六提供的快捷支付方法，本发明实施例七提供了一种快捷支付装置，如图38所示，包括：启动模块3801、触发操作检测模块3802和第二支付模块3803。
启动模块3801启动支付应用；触发操作检测模块3802检测针对支付应用的预设支付功能的触发操作，其中，预设支付功能对应用户预先设置的支付信息；第二支付模块3803根据预设支付功能对应的支付信息，执行相应的支付处理。
本发明实施例七中，快捷支付装置中的启动模块3801、触发操作检测模块3802和第二支付模块3803的具体功能实现，可参考实施例六的快捷支付方法中各步骤的具体实现，在此不再赘述。
本技术领域技术人员可以理解，本发明包括涉及用于执行本申请中所述操作中的一项或多项的设备。这些设备可以为所需的目的而专门设计和制造，或者也可以包括通用计算机中的已知设备。这些设备具有存储在其内的计算机程序，这些计算机程序选择性地激活或重构。这样的计算机程序可以被存储在设备(例如，计算机)可读介质中或者存储在适于存储电子指令并分别耦联到总线的任何类型的介质中，所述计算机可读介质包括但不限于任何类型的盘(包括软盘、硬盘、光盘、CD-ROM、和磁光盘)、ROM(Read-Only Memory，只读存储器)、RAM(Random Access Memory，随即存储器)、EPROM(Erasable ProgrammableRead-Only Memory，可擦写可编程只读存储器)、EEPROM(Electrically ErasableProgrammable Read-Only Memory，电可擦可编程只读存储器)、闪存、磁性卡片或光线卡片。也就是，可读介质包括由设备(例如，计算机)以能够读的形式存储或传输信息的任何介质。
本技术领域技术人员可以理解，可以用计算机程序指令来实现这些结构图和/或框图和/或流图中的每个框以及这些结构图和/或框图和/或流图中的框的组合。本技术领域技术人员可以理解，可以将这些计算机程序指令提供给通用计算机、专业计算机或其他可编程数据处理方法的处理器来实现，从而通过计算机或其他可编程数据处理方法的处理器来执行本发明公开的结构图和/或框图和/或流图的框或多个框中指定的方案。
本技术领域技术人员可以理解，本发明中已经讨论过的各种操作、方法、流程中的步骤、措施、方案可以被交替、更改、组合或删除。进一步地，具有本发明中已经讨论过的各种操作、方法、流程中的其他步骤、措施、方案也可以被交替、更改、重排、分解、组合或删除。进一步地，现有技术中的具有与本发明中公开的各种操作、方法、流程中的步骤、措施、方案也可以被交替、更改、重排、分解、组合或删除。
以上所述仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以作出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。

Claims (29)

1.一种由电子设备执行的方法，其特征在于，包括：
检测快捷支付触发条件；
从终端支持的至少一个第一支付应用中，调用与所述触发条件对应的第一支付应用执行支付处理；
其中，所述检测快捷支付触发条件，包括：
启动第二支付应用，所述第二支付应用绑定有第一支付应用的支付功能；
检测用户在第二支付应用中针对所述支付功能的触发操作；其中，所述支付功能对应支付信息，所述支付信息中至少包含支付方式；
当所述支付方式包括信息码支付方式时，调用与所述触发条件对应的第一支付应用执行支付处理，包括：
在所述第二支付应用的应用界面显示所述信息码支付凭证；
根据显示的信息码支付凭证执行支付处理，所述信息码支付凭证中包含第一支付应用的应用客户端实时生成的信息码。
2.根据权利要求1所述的方法，其特征在于，所述检测快捷支付触发条件，包括：
启动第二支付应用，所述第二支付应用绑定有第一支付应用的预设支付功能；
检测用户在第二支付应用中针对所述预设支付功能的触发操作；
调用与所述触发条件对应的第一支付应用执行支付处理，包括：
调用与所述触发条件对应的第一支付应用的所述预设支付功能执行支付处理。
3.根据权利要求2所述的方法，其特征在于，所述预设支付功能对应预先设置的支付信息；
调用与所述触发条件对应的第一支付应用执行支付处理，包括：
调用与所述触发条件对应的第一支付应用，根据预设支付功能对应的支付信息，执行相应的支付处理。
4.根据权利要求3所述的方法，其特征在于，所述预先设置的支付信息包含下述至少一项：
支付方式、支付方账户、支付对象、支付金额、支付时间。
5.根据权利要求4所述的方法，其特征在于，支付方式包括在线支付方式和/或离线支付方式；
其中，离线支付方式包括银行卡支付方式和/或信息码支付方式。
6.根据权利要求4或5所述的方法，其特征在于，所述支付方式包括信息码支付方式；
调用与所述触发条件对应的第一支付应用，根据预设支付功能对应的支付信息，执行相应的支付处理，包括：
请求与所述触发条件对应的第一支付应用的应用客户端生成信息码支付凭证；
在第二支付应用的应用界面显示所述信息码支付凭证。
7.根据权利要求1-6任一所述的方法，其特征在于，所述第一支付应用的预设支付功能，以虚拟支付卡的形式绑定到所述第二支付应用。
8.根据权利要求1所述的方法，其特征在于，检测快捷支付触发条件，包括：
启动第二支付应用，所述第二支付应用绑定有第一支付应用；
检测用户在第二支付应用中针对第一支付应用的触发操作；
调用与所述触发条件对应的第一支付应用，包括：
启动与所述触发操作对应的第一支付应用执行支付处理。
9.根据权利要求1-8任一所述的方法，其特征在于，所述第一支付应用为无卡支付应用；所述第二支付应用为有卡支付应用。
10.根据权利要求1-9任一所述的方法，其特征在于，还包括：
将第一支付应用中绑定的支付信息同步绑定到第二支付应用；和/或
将第二支付应用中绑定的支付信息同步绑定到第一支付应用。
11.根据权利要求1所述的方法，其特征在于，检测快捷支付触发条件，包括：
检测用户输入的认证信息；
调用与所述触发条件对应的第一支付应用执行支付处理，包括：
确定出与用户输入的认证信息对应的第一支付应用的预设支付功能；
调用确定出的第一支付应用的预设支付功能执行支付处理。
12.根据权利要求1所述的方法，其特征在于，所述支付信息还包含下述至少一项：
支付方账户、支付对象、支付金额、支付时间。
13.一种由电子设备执行的装置，其特征在于，包括：
触发条件检测模块，用于检测快捷支付触发条件；
第一支付模块，用于从终端支持的至少一个第一支付应用中，调用与所述触发条件对应的第一支付应用执行支付处理；
所述触发条件检测模块，包括：第一启动子模块以及第一触发操作检测子模块；其中，
所述第一启动子模块，用于启动第二支付应用，所述第二支付应用绑定有第一支付应用的支付功能；
所述第一触发操作检测子模块，用于检测用户在第二支付应用中针对所述支付功能的触发操作；其中，所述支付功能对应支付信息，所述支付信息中至少包含支付方式；
当所述支付方式包括信息码支付方式时，所述第一支付模块在调用与所述触发条件对应的第一支付应用执行支付处理时，具体用于：
在所述第二支付应用的应用界面显示所述信息码支付凭证；
根据显示的信息码支付凭证执行支付处理，所述信息码支付凭证中包含第一支付应用的应用客户端实时生成的信息码。
14.根据权利要求13所述的装置，其特征在于，
第一启动子模块，还用于启动第二支付应用，所述第二支付应用绑定有第一支付应用的预设支付功能；
第一触发操作检测子模块，还用于检测用户在第二支付应用中针对所述预设支付功能的触发操作；
所述第一支付模块包括：
支付功能调用子模块，用于调用与所述触发条件对应的第一支付应用的所述预设支付功能执行支付处理。
15.根据权利要求14所述的装置，其特征在于，所述预设支付功能对应预先设置的支付信息；
支付功能调用子模块包括：
支付处理执行单元，用于调用与所述触发条件对应的第一支付应用，根据预设支付功能对应的支付信息，执行相应的支付处理。
16.根据权利要求15所述的装置，其特征在于，所述支付信息包含下述至少一项：
支付方式、支付方账户、支付对象、支付金额、支付时间。
17.根据权利要求16所述的装置，其特征在于，支付方式包括在线支付方式和/或离线支付方式；
其中，离线支付方式包括银行卡支付方式和/或信息码支付方式。
18.根据权利要求16或17所述的装置，其特征在于，所述支付方式包括信息码支付方式；
支付处理执行单元包括：
信息码支付凭证生成子单元，请求与所述触发条件对应的第一支付应用的应用客户端生成信息码支付凭证；
显示子单元，用于在第二支付应用的应用界面显示所述信息码支付凭证。
19.根据权利要求14-18任一所述的装置，其特征在于，所述第一支付应用的预设支付功能，以虚拟支付卡的形式绑定到所述第二支付应用。
20.根据权利要求13所述的装置，其特征在于，触发条件检测模块包括：
第二启动子模块，用于启动第二支付应用，所述第二支付应用绑定有第一支付应用；
第二触发操作检测子模块，用于检测用户在第二支付应用中针对第一支付应用的触发操作；
第一支付模块包括：
启动子模块，用于启动与所述触发操作对应的第一支付应用执行支付处理。
21.根据权利要求14-20任一所述的装置，其特征在于，所述第一支付应用为无卡支付应用；所述第二支付应用为有卡支付应用。
22.根据权利要求14-21任一所述的装置，其特征在于，还包括：
绑定模块，用于将第一支付应用中绑定的支付信息同步绑定到第二支付应用；和/或将第二支付应用中绑定的支付信息同步绑定到第一支付应用。
23.根据权利要求13所述的装置，其特征在于，触发条件检测模块包括：
认证信息检测子模块，用于检测用户输入的认证信息；
第一支付模块包括：
支付功能确定子模块，用于确定出与用户输入的认证信息对应的第一支付应用的预设支付功能；
支付功能调用子模块，还用于调用确定出的第一支付应用的预设支付功能执行支付处理。
24.一种由电子设备执行的方法，其特征在于，包括：
启动第二支付应用，所述第二支付应用绑定有第一支付应用的支付功能；
检测针对所述第二支付应用的支付功能的触发操作；
根据所述支付功能对应的支付信息，执行相应的支付处理；
其中，所述支付信息至少包含支付方式，当所述支付方式为信息码支付方式时，所述根据所述支付功能对应的支付信息，执行相应的支付处理，包括：
在所述第二支付应用的应用界面显示所述信息码支付凭证；
根据显示的信息码支付凭证执行支付处理，所述信息码支付凭证中包含第一支付应用的应用客户端实时生成的信息码。
25.根据权利要求24所述的方法，其特征在于，所述支付信息还包含下述至少一项：
支付方账户、支付对象、支付金额、支付时间。
26.一种由电子设备执行的装置，其特征在于，包括：
启动模块，用于启动第二支付应用，所述第二支付应用绑定有第一支付应用的支付功能；
触发操作检测模块，用于检测针对所述支付应用的支付功能的触发操作；
第二支付模块，用于根据所述支付功能对应的支付信息，执行相应的支付处理；
其中，所述支付信息至少包含支付方式，当所述支付方式为信息码支付方式时，所述第二支付模块在根据所述支付功能对应的支付信息，执行相应的支付处理时，具体用于：
在所述第二支付应用的应用界面显示所述信息码支付凭证；
根据显示的信息码支付凭证执行支付处理，所述信息码支付凭证中包含第一支付应用的应用客户端实时生成的信息码。
27.根据权利要求26所述的装置，其特征在于，所述支付信息包含下述至少一项：
支付方账户、支付对象、支付金额、支付时间。
28.一种电子设备，其特征在于，包括：
处理器、存储器和总线；
所述总线，用于连接所述处理器和所述存储器；
所述存储器，用于存储操作指令；
所述处理器，用于通过调用所述操作指令，执行上述权利要求1-12中任一项所述的方法。
29.一种电子设备，其特征在于，包括：
处理器、存储器和总线；
所述总线，用于连接所述处理器和所述存储器；
所述存储器，用于存储操作指令；
所述处理器，用于通过调用所述操作指令，执行上述权利要求24-25中任一项所述的方法。
CN201610332851.5A 2016-05-18 2016-05-18 快捷支付方法和装置 Active CN107403312B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201610332851.5A CN107403312B (zh) 2016-05-18 2016-05-18 快捷支付方法和装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201610332851.5A CN107403312B (zh) 2016-05-18 2016-05-18 快捷支付方法和装置

Publications (2)

Publication Number Publication Date
CN107403312A CN107403312A (zh) 2017-11-28
CN107403312B true CN107403312B (zh) 2024-03-26

Family

ID=60394609

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201610332851.5A Active CN107403312B (zh) 2016-05-18 2016-05-18 快捷支付方法和装置

Country Status (1)

Country Link
CN (1) CN107403312B (zh)

Families Citing this family (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108197930B (zh) * 2017-12-13 2023-10-20 创新先进技术有限公司 一种doi展示和交易信息校验方法、装置及设备
CN112232801B (zh) * 2018-01-05 2021-08-20 华为终端有限公司 一种电子交易的方法及终端
CN108764895A (zh) * 2018-03-14 2018-11-06 顾馨媛 一种移动支付的增强方法
CN108960818A (zh) * 2018-05-04 2018-12-07 中国银联股份有限公司 一种虚拟卡生成方法、用户终端以及令牌服务器
CN108900490B (zh) * 2018-06-21 2021-04-20 咪付（广西）网络技术有限公司 一种基于蓝牙和声波的安全认证方法
CN108762854A (zh) * 2018-08-17 2018-11-06 深圳市万通顺达科技股份有限公司 基于操作系统的呼出二维码的方法及其系统、存储介质
CN109325744B (zh) * 2018-10-23 2022-05-27 北京三快在线科技有限公司 支付处理方法、装置、介质及电子设备
CN109801053B (zh) * 2018-12-28 2023-05-19 易票联支付有限公司 一种统一绑定银行卡的系统及方法
CN110138795B (zh) * 2019-05-23 2021-11-19 南威软件股份有限公司 一种通信过程中的多步混合加解密方法
CN110264184B (zh) * 2019-06-28 2021-07-23 Oppo（重庆）智能科技有限公司 支付控制方法及相关产品
CN110889694B (zh) * 2019-10-15 2024-04-02 武汉城市一卡通有限公司 实现一个支付证书支持nfc和二维码两种支付方式的方法
JP2021128703A (ja) * 2020-02-17 2021-09-02 東芝テック株式会社 決済端末およびプログラム
CN111861457B (zh) * 2020-06-28 2023-02-21 中国银联股份有限公司 支付令牌申请方法、设备、系统和服务器
CN112131590A (zh) * 2020-09-28 2020-12-25 平安国际智慧城市科技股份有限公司 数据库连接建立方法、装置、计算机设备及存储介质
CN112581123B (zh) * 2020-12-08 2024-02-23 中国银联股份有限公司 卡管理方法、用户终端、服务器、系统及存储介质
CN112819469B (zh) * 2021-03-15 2024-04-02 中国工商银行股份有限公司 支付方法及系统、终端、服务器、计算机系统和介质
CN114626860B (zh) * 2022-05-12 2022-08-05 武汉和悦数字科技有限公司 用于线上商品支付的身份动态识别方法及装置
CN116679861A (zh) * 2022-11-30 2023-09-01 荣耀终端有限公司 一种内容显示方法及其电子设备

Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2005013163A2 (fr) * 2003-07-30 2005-02-10 Jan-Georges Zizka Systeme et procede de paiement electronique
CN103064515A (zh) * 2012-12-18 2013-04-24 广东欧珀移动通信有限公司 一种基于指纹识别快速进入功能的方法和装置
CN103366269A (zh) * 2013-07-05 2013-10-23 李卓桓 一种用于快捷支付的方法、设备及系统
WO2014092286A1 (ko) * 2012-12-13 2014-06-19 에스케이플래닛 주식회사 오프라인 상거래를 위한 결제 지원 방법, 이를 위한 시스템 및 장치
CN104361699A (zh) * 2014-11-15 2015-02-18 安徽省新方尊铸造科技有限公司 一种基于签名识别技术的超市快捷支付系统
CN104574082A (zh) * 2013-10-29 2015-04-29 江苏华御信息技术有限公司 一种基于指纹验证的安全快捷支付的方法
CN104778579A (zh) * 2015-04-30 2015-07-15 北京奇虎科技有限公司 基于电子身份识别载体的感应支付方法及相应装置
CN104902071A (zh) * 2015-04-13 2015-09-09 广东欧珀移动通信有限公司 一种保护手机支付安全的方法及装置
CN105187872A (zh) * 2015-07-28 2015-12-23 成都亿邻通科技有限公司 一种数字电视收视费快捷支付的方法

Patent Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2005013163A2 (fr) * 2003-07-30 2005-02-10 Jan-Georges Zizka Systeme et procede de paiement electronique
WO2014092286A1 (ko) * 2012-12-13 2014-06-19 에스케이플래닛 주식회사 오프라인 상거래를 위한 결제 지원 방법, 이를 위한 시스템 및 장치
CN103064515A (zh) * 2012-12-18 2013-04-24 广东欧珀移动通信有限公司 一种基于指纹识别快速进入功能的方法和装置
CN103366269A (zh) * 2013-07-05 2013-10-23 李卓桓 一种用于快捷支付的方法、设备及系统
CN104574082A (zh) * 2013-10-29 2015-04-29 江苏华御信息技术有限公司 一种基于指纹验证的安全快捷支付的方法
CN104361699A (zh) * 2014-11-15 2015-02-18 安徽省新方尊铸造科技有限公司 一种基于签名识别技术的超市快捷支付系统
CN104902071A (zh) * 2015-04-13 2015-09-09 广东欧珀移动通信有限公司 一种保护手机支付安全的方法及装置
CN104778579A (zh) * 2015-04-30 2015-07-15 北京奇虎科技有限公司 基于电子身份识别载体的感应支付方法及相应装置
CN105187872A (zh) * 2015-07-28 2015-12-23 成都亿邻通科技有限公司 一种数字电视收视费快捷支付的方法

Also Published As

Publication number Publication date
CN107403312A (zh) 2017-11-28

Similar Documents

Publication Publication Date Title
CN107403312B (zh) 快捷支付方法和装置
KR102044751B1 (ko) 블록체인 기반 사용자 인증에 따른 보상을 제공하는 방법
TWI667585B (zh) 一種基於生物特徵的安全認證方法及裝置
CN108604345B (zh) 一种添加银行卡的方法及装置
RU2649786C2 (ru) Мобильное платежное устройство на базе технологии биораспознавания, способ и устройство
JP6586446B2 (ja) 通信端末および関連システムのユーザーの識別情報を確認するための方法
US8843415B2 (en) Secure software service systems and methods
CN106878245B (zh) 图形码信息提供、获取方法、装置及终端
CN111899026A (zh) 一种支付方法和装置
CN111431719A (zh) 一种移动终端密码保护模块、移动终端及密码保护方法
JP2015537399A (ja) モバイル決済のためのアプリケーションシステム及びモバイル決済手段を提供する及び用いるための方法
CN111914293A (zh) 一种数据访问权限验证方法、装置、计算机设备及存储介质
CN107609878B (zh) 一种共享汽车的安全认证方法及系统
GB2607701A (en) Multi-node authentication method and apparatus based on block chain
KR101659847B1 (ko) 모바일 단말을 이용한 2채널 사용자 인증 방법
CN112861102A (zh) 基于区块链对电子文件的处理方法和系统
KR101318154B1 (ko) 이미지 기반의 공유문서 사용자 인증 방법 및 이를 위한 컴퓨터로 판독가능한 기록매체
WO2022042745A1 (zh) 一种密钥管理方法及装置
CN110034933A (zh) 跨系统用户互信认证方法及跨系统用户互信认证系统
JP2016012902A (ja) 電子データ利用システム、携帯端末装置、及び電子データ利用システムにおける方法
CN102264069B (zh) 基于通用引导架构的认证控制方法、装置及系统
US11301847B1 (en) Systems and methods for an authorized identification system
CN107808284B (zh) 一种基于pos机系统的支付方法
JP6515080B2 (ja) 情報処理システム、情報処理方法、及びプログラム
Khu-Smith et al. Enhancing e-commerce security using GSM authentication

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant