CN117132281A - 支付增强验证的方法、装置、服务器、系统及介质 - Google Patents

支付增强验证的方法、装置、服务器、系统及介质 Download PDF

Info

Publication number
CN117132281A
CN117132281A CN202310898033.1A CN202310898033A CN117132281A CN 117132281 A CN117132281 A CN 117132281A CN 202310898033 A CN202310898033 A CN 202310898033A CN 117132281 A CN117132281 A CN 117132281A
Authority
CN
China
Prior art keywords
payment
verification
platform
decision
request
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.)
Pending
Application number
CN202310898033.1A
Other languages
English (en)
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.)
China Unionpay Co Ltd
Original Assignee
China Unionpay 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 China Unionpay Co Ltd filed Critical China Unionpay Co Ltd
Priority to CN202310898033.1A priority Critical patent/CN117132281A/zh
Publication of CN117132281A publication Critical patent/CN117132281A/zh
Pending legal-status Critical Current

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/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • G06Q20/4014—Identity check for transactions
    • 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/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G06Q20/367—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes
    • 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/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3829—Payment protocols; Details thereof insuring higher security of transaction involving key management

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Engineering & Computer Science (AREA)
  • Finance (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

本申请公开了一种支付增强验证的方法、装置、服务器、系统及介质，涉及电子支付领域。该方法包括：在发起支付的情况下，接收电子钱包平台基于嵌入电子钱包的支付应用程序的条码支付功能发送的验证决策请求，电子钱包平台包括终端设备自带的电子钱包的后台服务器；根据验证决策请求，生成决策申请请求，并向验证决策平台发送；接收验证决策平台响应于决策申请请求反馈的增强验证方式；向电子钱包平台发送增强验证方式，以使电子钱包平台按照增强验证方式进行增强验证，得到验证结果；在验证结果表征增强验证通过的情况下，与资源管理服务器交互，完成支付。根据本申请实施例能够加强对增强验证的风险的管控，提高支付的安全性。

Description

支付增强验证的方法、装置、服务器、系统及介质
技术领域
本申请属于电子支付领域，尤其涉及一种支付增强验证的方法、装置、服务器、系统及介质。
背景技术
随着电子信息的不断发展，电子支付业务成为了支付技术的一大主流方向。由于终端设备的移动性、快捷性、安全性等优势，使得电子支付业务从计算机处理转移到了终端设备处理。终端设备的操作系统会自带电子钱包，可供用户在电子钱包内绑定银行卡进行支付。此外，由于条码支付的便捷性，用户也可通过在终端设备中安装支付应用程序，利用支付应用程序进行扫码支付。为了拓展终端设备自带的电子钱包的使用范围，可将支付应用程序的条码支付能力整合进电子钱包，使得用户可通过电子钱包使用支付应用程序的条码支付能力。
在通过电子钱包进行条码支付的过程中，需要对支付进行用户的增强验证，以对支付的安全性进行管控。增强验证的决策需要条码支付的主体来进行，进行条码支付的主体是电子钱包，电子钱包的所属方为终端设备的设备厂商，但设备厂商侧的安全系数较低，使得增强验证的风险增大，降低了支付的安全性。
发明内容
本申请实施例提供一种支付增强验证的方法、装置、服务器、系统及介质，能够加强对增强验证的风险的管控，提高支付的安全性。
第一方面，本申请实施例提供一种支付增强验证的方法，应用于支付转接平台，该方法包括：在发起支付的情况下，接收电子钱包平台基于嵌入电子钱包的支付应用程序的条码支付功能发送的验证决策请求，电子钱包平台包括终端设备自带的电子钱包的后台服务器；根据验证决策请求，生成决策申请请求，并向验证决策平台发送；接收验证决策平台响应于决策申请请求反馈的增强验证方式；向电子钱包平台发送增强验证方式，以使电子钱包平台按照增强验证方式进行增强验证，得到验证结果；在验证结果表征增强验证通过的情况下，与资源管理服务器交互，完成支付。
第二方面，本申请实施例提供一种支付增强验证的方法，应用于电子钱包平台，电子钱包平台包括终端设备自带的电子钱包的后台服务器，该方法包括：在发起支付的情况下，基于嵌入电子钱包的支付应用程序的条码支付功能，向支付转接平台发送验证决策请求，以使支付转接平台根据验证决策请求，生成决策申请请求向验证决策平台发送；接收支付转接平台发送的增强验证方式，增强验证方式由验证决策平台根据决策申请请求确定；与终端设备交互，按照增强验证方式进行增强验证，得到验证结果；向支付转接平台反馈验证结果，以使支付转接平台在验证结果表征增强验证通过的情况下与资源管理服务器交互，完成支付。
第三方面，本申请实施例提供一种支付增强验证的装置，应用于支付转接平台，该装置包括：接收模块，用于在发起支付的情况下，接收电子钱包平台基于嵌入电子钱包的支付应用程序的条码支付功能发送的验证决策请求，电子钱包平台包括终端设备自带的电子钱包的后台服务器；请求生成模块，用于根据验证决策请求，生成决策申请请求；发送模块，用于向验证决策平台发送决策申请请求；接收模块还用于接收验证决策平台响应于决策申请请求反馈的增强验证方式；发送模块还用于向电子钱包平台发送增强验证方式，以使电子钱包平台按照增强验证方式进行增强验证，得到验证结果；发送模块还用于在验证结果表征增强验证通过的情况下，与资源管理服务器交互，完成支付。
第四方面，本申请实施例提供一种支付增强验证的装置，应用于电子钱包平台，电子钱包平台包括终端设备自带的电子钱包的后台服务器，该装置包括：发送模块，用于在发起支付的情况下，基于嵌入电子钱包的支付应用程序的条码支付功能，向支付转接平台发送验证决策请求，以使支付转接平台根据验证决策请求，生成决策申请请求向验证决策平台发送；接收模块，用于接收支付转接平台发送的增强验证方式，增强验证方式由验证决策平台根据决策申请请求确定；验证模块，用于与终端设备交互，按照增强验证方式进行增强验证，得到验证结果；发送模块还用于向支付转接平台反馈验证结果，以使支付转接平台在验证结果表征增强验证通过的情况下与资源管理服务器交互，完成支付。
第五方面，本申请实施例提供一种服务器，应用于支付转接平台，该服务器包括：处理器以及存储有计算机程序指令的存储器；处理器执行计算机程序指令时实现第一方面的支付增强验证的方法。
第六方面，本申请实施例提供一种服务器，应用于电子钱包平台，该服务器包括：处理器以及存储有计算机程序指令的存储器；处理器执行计算机程序指令时实现第二方面的支付增强验证的方法。
第七方面，本申请实施例提供一种支付增强验证的系统，包括：支付转接平台，用于执行第一方面的支付增强验证的方法；电子钱包平台，用于执行第二方面的支付增强验证的方法。
第八方面，本申请实施例提供一种计算机可读存储介质，计算机可读存储介质上存储有计算机程序指令，计算机程序指令被处理器执行时实现第一方面的支付增强验证的方法或第二方面的支付增强验证的方法。
本申请实施例提供一种支付增强验证的方法、装置、服务器、系统及介质，在发起支付的情况下，支付转接方的支付转接平台可接收电子钱包平台基于嵌入电子钱包的支付应用程序的条码支付功能发送的验证决策请求，并根据该验证决策请求生成决策申请请求，向验证决策平台发送该决策申请请求，以使验证决策平台根据决策申请请求，为本次支付分配适配的增强验证方式。支付转接平台可将验证决策平台反馈的增强验证方式转发给电子钱包平台，以使电子钱包平台按照该增强验证方式进行增强验证，验证支付的用户的身份的真实性，在增强验证通过的情况下，继续支付流程，以完成支付。在该过程中，增强验证的实施由终端设备厂商方的电子钱包平台进行，但增强验证方式的决策交由支付转接方的支付转接平台和验证决策平台来进行，支付转接方本身负责支付的转接，安全系数更高，对风险的管控更强，可使得决策得到的增强验证方式所对应的增强验证安全性更高，从而提高支付的安全性。
附图说明
为了更清楚地说明本申请实施例的技术方案，下面将对本申请实施例中所需要使用的附图作简单的介绍，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
图1为本申请实施例提供的支付增强验证的方法的场景架构的一示例的示意图；
图2为本申请实施例提供的电子钱包的显示界面的一示例的示意图；
图3为本申请实施例提供的支付增强验证的方法的场景架构的另一示例的示意图；
图4为本申请第一方面一实施例提供的支付增强验证的方法的流程图；
图5为本申请第二方面一实施例提供的支付增强验证的方法的流程图；
图6为本申请实施例提供的支付流程的一示例的流程图；
图7为本申请实施例提供的被扫支付流程的一示例的流程图；
图8为本申请实施例提供的主扫支付流程的一示例的流程图；
图9为本申请第三方面一实施例提供的支付增强验证的装置的结构示意图
图10为本申请第四方面一实施例提供的支付增强验证的装置的结构示意图；
图11为本申请第五方面一实施例提供的服务器的结构示意图。
具体实施方式
下面将详细描述本申请的各个方面的特征和示例性实施例，为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及具体实施例，对本申请进行进一步详细描述。应理解，此处所描述的具体实施例仅意在解释本申请，而不是限定本申请。对于本领域技术人员来说，本申请可以在不需要这些具体细节中的一些细节的情况下实施。下面对实施例的描述仅仅是为了通过示出本申请的示例来提供对本申请更好的理解。需要说明的是，本申请实施例中对信息、数据的获取、存储、使用、处理等均得到用户或相关机构的授权，符合国家法律法规的相关规定。
随着电子信息的不断发展，电子支付业务成为了支付技术的一大主流方向。由于终端设备的移动性、快捷性、安全性等优势，使得电子支付业务从计算机处理转移到了终端设备处理。终端设备的操作系统会自带电子钱包，可供用户在电子钱包内绑定银行卡进行支付。此外，由于条码支付的便捷性，用户也可通过在终端设备中安装支付应用程序，利用支付应用程序进行扫码支付。为了拓展终端设备自带的电子钱包的使用范围，可将支付应用程序的条码支付能力整合进电子钱包，使得用户可通过电子钱包使用支付应用程序的条码支付能力。在通过电子钱包进行条码支付的过程中，需要对支付进行用户的增强验证，以对支付的安全性进行管控。增强验证的决策需要条码支付的主体来进行，进行条码支付的主体是电子钱包，电子钱包的所属方为终端设备的设备厂商，但设备厂商侧的安全系数较低，使得增强验证的风险增大，降低了支付的安全性。
本申请提供一种支付增强验证的方法、装置、服务器、系统及介质，应用于终端设备中电子钱包利用嵌入的支付应用程序的条码支付功能进行支付的场景，能够通过属于支付转接方的支付转接方服务器和属于终端设备厂商的电子钱包平台之间的交互，将支付中的增强验证的决策转交由支付转接平台通过验证决策平台来进行。支付转接平台和验证决策平台均属于支付转接方，支付转接方本身负责支付的转接，由支付转接方决策增强验证方式，安全系数更高，增强验证的风险更小，从而提高支付的安全性。
为了便于理解，这里先对本申请涉及的场景架构进行说明。图1为本申请实施例提供的支付增强验证的方法的场景架构的一示例的示意图，如图1所示，本申请实施例提供的支付增强验证的方法可涉及终端设备厂商方11和支付转接方12，终端设备厂商方11具有电子钱包平台111和终端设备112，支付转接方12具有支付转接平台121和验证决策平台122。
终端设备厂商方11出产的终端设备112中自带电子钱包，电子钱包平台111包括终端设备112自带的电子钱包的后台服务器，属于终端设备厂商方。终端设备112自带的电子钱包可通过用户的操作与用户的银行卡绑定，以利用银行卡完成电子钱包的支付。终端设备112可与电子钱包平台111交互，以实现终端设备112中自带的电子钱包的功能。终端设备112中还可安装有具有条码支付功能的支付应用程序。在本申请实施例中，终端设备112自带的电子钱包可嵌入支付应用程序的条码支付功能。需要说明的是，支付应用程序的条码支付功能嵌入电子钱包，是指电子钱包可展示支付应用程序的付款码，以及电子钱包可扫描支付应用程序所对应的收款码，并不是指从电子钱包跳转到支付应用程序再使用支付应用程序的条码支付功能。例如，图2为本申请实施例提供的电子钱包的显示界面的一示例的示意图，如图2所示，电子钱包的显示界面可显示支付应用程序的付款码21，也可显示扫描支付应用程序的收款码的扫描功能图标22，还可显示绑定的银行卡的支付图标23，电子钱包具有银行卡支付功能以及支付应用程序的条码支付功能。支付应用程序的条码支付功能在电子钱包的嵌入可通过电子钱包平台111与支付转接平台121的交互实现。在一些示例中，支付转接平台121可用于下发付款码或收款码，可通过电子钱包平台111与支付转接平台121的交互，实现支付应用程序的条码支付功能在电子钱包的嵌入。在另一些示例中，支付转接平台121可与下发付款码或收款码的平台、设备等交互，通过支付转接平台121可与下发付款码或收款码的平台、设备等的交互，以及电子钱包平台111与支付转接平台121的交互，共同实现支付应用程序的条码支付功能在电子钱包的嵌入。电子钱包平台111可包括一台服务器或两台以上的服务器，也可包括其他类型的设备，在此并不限定。终端设备112可包括手机、平板电脑、智能手表、智能手环等设备，在此并不限定。
支付转接方12负责进行支付转接，各类电子支付均需通过支付转接方12进行支付转接，由支付转接方12与资源管理方进行交互，以使资源管理方的相关设备，如资源管理服务器实现交易资源的扣除和转入，完成支付。支付转接平台121可用于与电子钱包平台111及验证决策平台122交互，以将增强验证方式的决策权转交给验证决策平台122。本申请实施例中的支付转接平台121可复用支付转接方12实现其他类电子支付的转接的服务器，也可为支付转接方12新建立的专用于实现本申请实施例中支付增强验证的方法的服务器，在此并不限定。支付转接平台121可包括一台服务器或两台以上的服务器，也可包括其他类型的设备，在此并不限定。
验证决策平台122可用于为电子钱包嵌入的支付应用程序的条码支付功能而发起的支付确定适配的增强验证方式，以使电子钱包以及电子钱包平台111按照该适配的增强验证方式进行增强验证，在保证支付安全的情况下完成支付。验证决策平台122可包括一台服务器或两台以上的服务器，也可包括其他类型的设备，在此并不限定。
支付转接平台121和验证决策平台122均属于支付转接方12，支付转接方12的安全系数高于终端设备厂商方11，对应地，支付转接方11的支付转接平台111和验证决策平台122的安全系数也高于终端设备厂商方11的电子钱包平台111的安全系数，将增强验证方式的决策转交给支付转接方处理，能够降低支付风险，提高支付的安全性。
在一些示例中，本申请实施例提供的支付增强验证的方法还可涉及资源管理方，如银行等。图3为本申请实施例提供的支付增强验证的方法的场景架构的另一示例的示意图，图3与图1的不同之处在于，图3中支付增强验证的方法还涉及资源管理方13，资源管理方13可具有资源管理服务器131，资源管理服务器131用于实现支付中用户的资金的扣款和转入。资源管理服务器131可包括一台服务器或两台以上的服务器，也可包括其他类型的设备，在此并不限定。
下面对本申请提供的支付增强验证的方法、装置、服务器、系统及介质分别进行说明。
本申请第一方面提供一种支付增强验证的方法，可应用于支付转接平台，即，该支付增强验证的方法可由支付转接平台执行。图4为本申请第一方面一实施例提供的支付增强验证的方法的流程图，如图4所示，该支付增强验证的方法可包括步骤S301至步骤S305。
在步骤S301中，在发起支付的情况下，接收电子钱包平台基于嵌入电子钱包的支付应用程序的条码支付功能发送的验证决策请求。
发起的与电子钱包相关的支付可包括基于嵌入电子钱包中的支付应用程序的条码支付功能和电子钱包自身原有的银行卡支付功能。在支付为基于嵌入电子钱包中的支付应用程序的条码支付功能发起的支付的情况下，可执行步骤S301。电子钱包平台向支付转接平台发送验证决策请求，验证决策请求用于请求支付转接方决策并提供增强验证方式。
在一些示例中，验证决策请求可包括终端用户关联信息。终端用户关联信息包括终端设备与用户相关的特征信息，可由终端设备及电子钱包平台采集得到。终端设备可将采集到的终端用户关联信息发送给电子钱包平台，电子钱包平台将自身采集到的终端用户关联信息和终端设备采集到的终端用户关联信息整合，通过验证决策请求向支付转接方即支付转接机构发送。
具体地，终端用户关联信息可包括但不限于以下一项或两项以上：终端设备信息、终端网络环境信息、账户信息、终端用户使用习惯信息。终端设备信息可包括与终端设备相关的信息，例如，终端设备信息可包括终端设备标识、终端设备类型、终端设备型号、终端设备位置等信息中的一者或两者以上。终端设备位置可表征终端设备的地理位置，可根据终端设备中的定位装置得到，如终端设备位置可为终端设备的全球定位系统(GlobalPositioning System，GPS)位置。终端网络环境信息可包括与终端设备相关的网络类信息和运行环境等信息，例如，终端网络环境信息可包括终端设备的网络协议(InternetProtocol，IP)地址、电子钱包版本信息、终端设备的操作系统信息等信息中的一者或两者以上。账户信息可包括用户在终端设备的电子钱包中的账户的相关信息，例如，账户信息可包括账户注册日期、注册账户的用户标识、账户的支付密码更新时间戳等信息中的一者或两者以上。终端用户使用习惯信息包括用户使用终端设备的习惯信息，例如，终端用户使用习惯信息可包括用户使用终端设备支付的惯用时间、用户使用终端设备支付的频率、用户使用终端设备支付的惯用金额范围等信息中的一者或两者以上。
在步骤S302中，根据验证决策请求，生成决策申请请求，并向验证决策平台发送。
决策申请请求用于向验证决策平台请求与基于电子钱包嵌入的支付应用程序的条码支付功能发起的支付适配的增强验证方式。支付转接平台可根据验证决策请求中的信息与自身采集的信息，生成决策申请请求，并向验证决策平台发送。
在一些示例中，支付转接平台可获取终端用户关联信息指示的用户在支付转接平台中对应的用户交易关联信息，根据验证决策请求和用户交易关联信息，生成决策申请请求。
生成的决策申请请求可包括终端用户关联信息和用户交易关联信息。终端用户关联信息可参见上文中的相关说明，在此不再赘述。用户交易关联信息包括支付转接方具有的用户与交易相关的特征信息。具体地，用户交易关联信息包括以下一项或两项以上：交易用户信息、用户风险等级信息、支付信息。交易用户信息包括与支付的用户相关的信息，例如，交易用户信息可包括用户证件号、用户属性、用户注册来源等信息中的一者或两者以上。用户风险等级信息可表征用户的风险等级，用户的风险等级越高，本次支付的风险越高；用户的风险等级越低，本次支付的风险越低。支付信息包括与支付相关的信息，例如，支付信息可包括用户绑卡来源、支付卡号、支付卡类型、收款商户编号、支付方式、支付金额等信息中的一者或两者以上。
在步骤S303中，接收验证决策平台响应于决策申请请求反馈的增强验证方式。
验证决策平台接收决策申请请求后，可根据决策申请请求中携带的信息，为本次支付分配对应的增强验证方式，并将分配的增强验证方式向支付转接平台反馈。在一些示例中，验证决策平台可基于决策申请请求和预设的决策规则确定增强验证方式，即，增强验证方式由验证决策平台基于决策申请请求和预设的决策规则确定。决策规则可体现决策申请请求支持携带的信息、支付风险和增强验证方式的对应关系。验证决策平台可根据决策申请请求中携带的信息所满足的决策规则，确定对应的增强验证方式。在一些示例中，决策规则可从预先建立的知识库中获取，知识库可存储在验证决策平台，也可存储在其他支付转接方建立的服务器中，在此并不限定。
决策申请请求携带的信息对应的支付风险越高，对应的增强验证方式对安全性的要求就越高。在一些示例中，增强验证方式包括无验证直接通过、无验证直接终止或有验证。无验证直接通过指不需进行具体的增强验证，可直接确定验证通过，无验证直接通过是极低的支付风险对应的增强验证方式。无验证直接终止指不需进行具体的增强验证，可直接确定验证未通过，无验证直接终止是极高的支付风险对应的增强验证方式。有验证指进行具体的增强验证，有验证对应的支付风险高于无验证直接通过对应的支付风险且低于无验证直接终止对应的支付风险。有验证可包括但不限于以下一项或两项以上：支付密码验证、验证码验证、生物特征验证。支付密码验证可指需要用户提供支付密码的身份验证。验证码验证可指需要用户提供验证码的身份验证，验证码可包括短信验证码或其他类型的验证码，在此并不限定。生物特征验证可指需要用户提供生物特征的身份验证，生物特征可包括人脸图像、指纹、声纹、掌纹、虹膜等中的一者或两者以上，在此并不限定。有验证中不同种类的验证可单独使用，也可叠加使用，在此并不限定。
在步骤S304中，向电子钱包平台发送增强验证方式，以使电子钱包平台按照增强验证方式进行增强验证，得到验证结果。
支付转接平台向电子钱包平台发送增强验证方式，以使终端设备厂商方确定增强验证的方式，从而使电子钱包平台与终端设备交互，实现增强验证，得到验证结果。增强验证用于对支付的用户的身份的真实性进行确认，验证结果可表征增强验证通过或增强验证未通过，通过增验证结果可确定支付的用户的身份是否真实。增强验证通过表示支付的用户的身份真实，增强验证未通过表示支付的用户的身份不真实。
在一些示例中，电子钱包平台接收该增强验证方式，根据该增强验证方式向终端设备发送验证指令，以使终端设备中的电子钱包响应于该验证指令，展示验证界面，采集用户输入的验证信息；终端设备将采集到的验证信息反馈给电子钱包平台；电子钱包平台接收该验证信息，匹配该验证信息与验证标准信息，得到验证结果。验证标准信息为支付的用户的真实身份信息。若验证信息与验证标准信息匹配成功，则验证结果表征增强验证通过，支付的用户的身份真实，支付具有安全性；若验证信息与验证标准信息匹配失败，则验证结果表征增强验证未通过，支付的用户的身份不真实，支付不具有安全性。需要说明的是，若验证信息与验证标准信息的匹配超时，验证结果表征增强验证未通过。
例如，若验证决策平台给出的增强验证方式包括无验证直接通过，表示支付转接方确定本次支付安全性较高，电子钱包平台可不进行具体的增强验证，直接默认验证通过，可通过验证指令通知终端设备不需验证，继续支付的后续流程，以完成支付。若验证决策平台给出的增强验证方式包括无验证直接终止，表示支付转接方确定本次支付非常可疑，风险极大，电子钱包平台可不进行具体的增强验证，直接默认验证不通过，可通过验证指令通知终端设备不需验证，终止本次支付。若验证决策平台给出的增强验证方式包括有验证中的支付密码验证，则电子钱包平台通过验证指令通知终端设备进行支付密码验证，终端设备显示支付密码验证页面，提示用户输入支付密码，并将用户输入的支付密码向电子钱包平台发送，电子钱包平台匹配用户输入的支付密码和预先存储的该用户设定的支付密码，得到验证结果。若验证决策平台给出的增强验证方式包括有验证中的验证码验证，则电子钱包平台通过验证指令通知终端设备进行验证码验证，终端设备可显示验证码验证页面，提示用户输入短信验证码，并将用户输入的短信验证码向电子钱包平台发送，电子钱包平台匹配用户输入的短信验证码和从验证码生成方获取到的短信验证码，得到验证结果。若验证决策平台给出的增强验证方式包括有验证中的生物特征验证，且生物特征验证为人脸验证，则电子钱包平台通过验证指令通知终端设备进行人脸验证，终端设备可调起人脸信息采集页面，采集用户的人脸信息，并将采集的人脸信息向电子钱包平台发送，电子钱包平台匹配采集的人脸信息和获取到的该用户的注册人脸信息，得到验证结果。若验证决策平台给出的增强验证方式包括有验证中的生物特征验证，且生物特征验证为指纹验证，则电子钱包平台通过验证指令通知终端设备进行指纹验证，终端设备可调起指纹信息采集页面，采集用户的指纹信息，并将采集的指纹信息向电子钱包平台发送，电子钱包平台匹配采集的指纹信息和获取到的该用户的注册指纹信息，得到验证结果。
在步骤S305中，在验证结果表征增强验证通过的情况下，与资源管理服务器交互，完成支付。
支付转接平台可接收电子钱包平台发送的验证结果，在验证结果表征增强验证通过的情况下，表示本次支付安全，可继续支付流程。支付转接平台可与资源管理服务器交互，由资源管理服务器完成支付资源在支付账户中的扣除以及支付资源在收款账户的转入等。
在本申请实施例中，在发起支付的情况下，支付转接方的支付转接平台可接收电子钱包平台基于嵌入电子钱包的支付应用程序的条码支付功能发送的验证决策请求，并根据该验证决策请求生成决策申请请求，向验证决策平台发送该决策申请请求，以使验证决策平台根据决策申请请求，为本次支付分配适配的增强验证方式。支付转接平台可将验证决策平台反馈的增强验证方式转发给电子钱包平台，以使电子钱包平台按照该增强验证方式进行增强验证，验证支付的用户的身份的真实性，在增强验证通过的情况下，继续支付流程，以完成支付。在该过程中，增强验证的实施由终端设备厂商方的电子钱包平台进行，但增强验证方式的决策交由支付转接方的支付转接平台和验证决策平台来进行，支付转接方本身负责支付的转接，安全系数更高，对风险的管控更强，可使得决策得到的增强验证方式所对应的增强验证安全性更高，从而提高支付的安全性。
在一些实施例中，在上述步骤S301中支付转接平台接收验证决策请求之前，支付转接平台还可接收交易请求，交易请求包括支付标识和电子钱包标识。交易请求用于发起支付。电子钱包标识用于标识电子钱包，不同终端设备厂商方的电子钱包不同，即，不同终端设备厂商方对应的电子钱包标识不同，也可认为电子钱包标识用于标识终端设备厂商方。支付标识可用于确定支付方式，支付标识可包括支付卡标识或支付应用程序标识。若支付标识包括支付卡标识如银行卡的支付Token，则表示支付方式为利用电子钱包绑定的支付卡进行支付。若支付标识包括支付应用程序标识，则表示支付方式为利用嵌入电子钱包的支付应用程序的条码支付功能进行支付。对应地，上述步骤S301中支付转接平台接收电子钱包平台基于嵌入电子钱包的支付应用程序的条码支付功能发送的验证决策请求可具体细化为：在交易请求中支付标识包括支付应用程序标识的情况下，接收电子钱包平台发送的验证决策请求，支付应用程序标识指示支付应用程序。在交易请求中的支付标识包括支付应用程序标识的情况下，交易请求还包括用户标识，用户标识用于标识用户，以在后续支付过程中确定支付的用户，例如，用户标识可包括用户手机号或其他能够指示用户的标识。在本申请实施例中，通过交易请求中的支付标识可区分电子钱包自身的支付卡支付和电子钱包所嵌入的支付应用程序的条码支付。只有在支付为电子钱包所嵌入的支付应用程序的条码支付的情况下，才将增强验证方式的决策交由支付转接平台和验证决策平台，由支付转接方进行决策。在交易请求中支付标识包括支付卡标识的情况下，电子钱包平台可进行电子钱包的普通支付流程，不需将增强验证方式的决策交由支付转接平台和验证决策平台。
在一些示例中，在支付转接平台接收交易请求后，支付转接平台还可向电子钱包平台反馈交易信息，交易信息可包括本次支付的订单信息。若支付为利用电子钱包绑定的支付卡进行支付，支付转接平台向电子钱包平台反馈的是针对支付卡的订单信息。若支付为利用嵌入电子钱包的支付应用程序的条码支付功能进行支付，支付转接平台向电子钱包平台反馈的是针对支付应用程序的订单信息，订单信息可包括付款码、订单号、商户名称、订单类型等信息等，如，在被扫支付中，订单信息可包括付款码等；在主扫支付中，订单信息可包括订单号、商户名称等。
上述实施例中嵌入电子钱包的支付应用程序的条码支付功能可包括被扫支付功能和主扫支付功能。在被扫支付功能的作用下，终端设备的电子钱包可显示付款码，由收款方利用商户设备扫描付款码以发起支付即被扫支付。在主扫支付功能的作用下，终端设备可扫描收款方出示的收款码以发起支付即主扫支付。
在被扫支付场景中，在支付转接平台接收交易请求之前，电子钱包平台可向支付转接平台发送付款码请求，以请求付款码。支付转接平台接收电子钱包平台发送的付款码请求，响应于该付款码请求，向电子钱包平台发送付款码，以使电子钱包平台将付款码提供给终端设备中的电子钱包，使电子钱包可展示付款码。付款码可由支付转接平台生成，也可由支付转接平台从用于生成支付码的服务器获取，在此并不限定。交易请求由商户设备扫描终端设备中电子钱包展示的付款码触发，通过收单服务器向支付转接平台发送。即，商户设备扫描终端设备中电子钱包展示的付款码，商户设备与收单服务器交互，可使收单服务器将付款码触发的支付的交易请求发送给支付转接平台。
在主扫支付场景中，交易请求由终端设备中电子钱包扫描收款码触发，通过电子钱包平台向支付转接平台发送。即，终端设备扫描收款方的收款码，触发交易请求，终端设备向电子钱包平台发送交易请求，电子钱包平台向支付转接平台发送交易请求，以使支付转接平台接收交易请求。收款方的收款码可预先向支付转接平台请求得到，或，预先向用于生成支付码的服务器请求得到，在此并不限定。
本申请第二方面提供一种支付增强验证的方法，可应用于电子钱包平台，即，该支付增强验证的方法可由电子钱包平台执行。图5为本申请第二方面一实施例提供的支付增强验证的方法的流程图，如图5所示，该支付增强验证的方法可包括步骤S401至步骤S404。
在步骤S401中，在发起支付的情况下，基于嵌入电子钱包的支付应用程序的条码支付功能，向支付转接平台发送验证决策请求，以使支付转接平台根据验证决策请求，生成决策申请请求向验证决策平台发送。
在一些示例中，验证决策请求包括终端用户关联信息。决策申请请求包括终端用户关联信息和用户交易关联信息。用户交易关联信息在支付转接平台中与终端用户关联信息指示的用户对应。
终端用户关联信息可包括但不限于以下一项或两项以上：终端设备信息、终端网络环境信息、账户信息、终端用户使用习惯信息，具体内容可参见上述实施例中的相关说明，在此不再赘述。
用户交易关联信息可包括但不限于以下一项或两项以上：交易用户信息、用户风险等级信息、支付信息，具体内容可参见上述实施例中的相关说明，在此不再赘述。
在步骤S402中，接收支付转接平台发送的增强验证方式。
增强验证方式由验证决策平台根据决策申请请求确定。具体地，增强验证方式由验证决策平台基于决策申请请求和预设的决策规则确定，具体内容可参见上述实施例中的相关说明，在此不再赘述。
在一些示例中，增强验证方式包括无验证直接通过、无验证直接终止或有验证。有验证包括但不限于以下一项或两项以上：支付密码验证、验证码验证、生物特征验证。
在步骤S403中，与终端设备交互，按照增强验证方式进行增强验证，得到验证结果。
在步骤S404中，向支付转接平台反馈验证结果，以使支付转接平台在验证结果表征增强验证通过的情况下与资源管理服务器交互，完成支付。
上述步骤S401至步骤S404的具体内容可参见上述实施例中的相关说明，在此不再赘述。
在本申请实施例中，在发起支付的情况下，电子钱包平台基于嵌入电子钱包的支付应用程序的条码支付功能向支付转接平台发送验证决策请求，以使支付转接平台根据该验证决策请求生成决策申请请求，向验证决策平台发送该决策申请请求，由验证决策平台根据决策申请请求，为本次支付分配适配的增强验证方式。电子钱包平台可接收支付转接平台转发的增强验证方式，并按照该增强验证方式进行增强验证，验证支付的用户的身份的真实性，在增强验证通过的情况下，继续支付流程，以完成支付。在该过程中，增强验证的实施由终端设备厂商方的电子钱包平台进行，但增强验证方式的决策交由支付转接方的支付转接平台和验证决策平台来进行，支付转接方本身负责支付的转接，安全系数更高，对风险的管控更强，可使得决策得到的增强验证方式所对应的增强验证安全性更高，从而提高支付的安全性。
在一些实施例中，在步骤S401之前，电子钱包平台还可向支付转接平台发送交易请求，交易请求包括支付标识和电子钱包标识。对应地，上述步骤S401中基于嵌入电子钱包的支付应用程序的条码支付功能，向支付转接平台发送验证决策请求可具体细化为：在交易请求中支付标识包括支付应用程序标识的情况下，向支付转接平台发送验证决策请求。在交易请求中支付标识包括支付应用程序标识的情况下，交易请求还包括用户标识。这部分的具体内容可参见上述实施例中的相关说明，在此不再赘述。
在一些实施例中，上述步骤S403可具体细化为：根据增强验证方式向终端设备发送验证指令；接收终端设备响应于验证指令采集的验证信息；匹配验证信息与验证标准信息，得到验证结果。这部分的具体内容可参见上述实施例中的相关说明，在此不再赘述。
上述实施例中基于嵌入电子钱包的支付应用程序的条码支付功能发起的支付可包括被扫支付和主扫支付。
在被扫支付的场景中，在电子钱包平台向支付转接平台发送验证决策请求之前，电子钱包平台还可向支付转接平台发送付款码请求；接收支付转接平台响应于付款码请求提供的付款码；向终端设备发送付款码，以使终端设备中的电子钱包展示付款码。这部分的具体内容可参见上述实施例中的相关说明，在此不再赘述。
在主扫支付的场景中，在电子钱包平台向支付转接平台发送交易请求之前，电子钱包平台还可接收终端设备发送的交易发起请求，交易发起请求由终端设备中的电子钱包扫描收款码触发。对应地，电子钱包平台向支付转接平台发送交易请求可具体细化为：响应于交易发起请求，向支付转接平台发送交易请求。这部分的具体内容可参见上述实施例中的相关说明，在此不再赘述。
为了便于理解，下面以一具体示例来说明电子钱包平台、支付转接平台和验证决策平台之间采用本申请实施例中支付增强验证的方法的支付流程。图6为本申请实施例提供的支付流程的一示例的流程图，如图6所示，该支付流程可包括步骤a1至步骤a10。
在步骤a1中，电子钱包平台向支付转接平台发起交易请求。
在步骤a2中，支付转接平台向电子钱包平台反馈交易信息，交易信息可包括订单信息。
在步骤a3中，支付转接平台向电子钱包平台发送增强验证请求。
在步骤a4中，电子钱包平台向支付转接平台发送验证决策请求。
在步骤a5中，支付转接平台向验证决策平台发送决策申请请求，请求验证决策平台进行增强验证方式的决策。
在步骤a6中，验证决策平台向支付转接平台发送增强验证方式。
在步骤a7中，支付转接平台向电子钱包平台发送增强验证方式。
在步骤a8中，电子钱包平台按照增强验证方式对支付的用户进行增强验证，得到验证结果。
在步骤a9中，电子钱包平台向支付转接平台发送验证结果。
在步骤a10中，支付转接平台根据验证结果，确定是否继续支付。
若验证结果表征增强验证通过，继续支付；若验证结果表征增强验证未通过，停止支付。
支付转接平台可与资源管理服务器交互，以使资源管理服务器完成支付的扣款。
上述步骤a1至步骤a10的具体内容可参见上述实施例中的相关说明，在此不再赘述。
本申请实施例中的支付增强验证主要用于电子钱包中支付应用程序的条码支付功能的条码支付场景中，条码支付可包括被扫支付和主扫支付。被扫支付常用于对支付时间要求严格且商户资质良好的场景，如大型商超、连锁店等。主扫支付常用于小微商户消费、线上支付等场景。下面以两个具体示例来说明电子钱包平台、支付转接平台和验证决策平台之间采用本申请实施例中支付增强验证的方法的被扫支付流程和主扫支付流程。
图7为本申请实施例提供的被扫支付流程的一示例的流程图，如图7所示，该支付流程可包括步骤b1至步骤b13。
在步骤b1中，电子钱包平台向支付转接平台发送付款码请求，请求付款码。
在步骤b2中，支付转接平台向电子钱包平台反馈付款码，以使电子钱包平台将付款码提供给终端设备。
在步骤b3中，商户设备扫描付款码，向支付转接平台发起交易请求。
商户设备可直接向支付转接平台发起交易请求，也可通过收单服务器向支付转接平台发起交易请求。
在步骤b4中，支付转接平台向电子钱包平台发送增强验证请求。
在步骤b5中，电子钱包平台向支付转接平台发送验证决策请求。
在步骤b6中，支付转接平台向验证决策平台发送决策申请请求。
在步骤b7中，验证决策平台向支付转接平台发送增强验证方式。
在步骤b8中，支付转接平台向电子钱包平台发送增强验证方式。
在步骤b9中，电子钱包平台按照增强验证方式对支付的用户进行增强验证，得到验证结果。
在步骤b10中，电子钱包平台向支付转接平台发送验证结果。
在步骤b11中，若验证结果表征增强验证通过，支付转接平台可完成支付的扣款。
支付转接平台可与资源管理服务器交互，以使资源管理服务器完成支付的扣款。
在步骤b12中，支付转接平台向电子钱包平台反馈支付结果，支付结果表征支付是否成功。
在步骤b13中，支付转接平台向商户设备反馈支付结果。
上述步骤b1至步骤b13的具体内容可参见上述实施例中的相关说明，在此不再赘述。
图8为本申请实施例提供的主扫支付流程的一示例的流程图，如图8所示，该支付流程可包括步骤c1至步骤c11。
在步骤c1中，终端设备扫描收款方提供的收款码，通过电子钱包平台向支付转接平台发起交易请求。
在步骤c2中，支付转接平台向电子钱包平台反馈交易信息，交易信息可包括订单信息。
在步骤c3中，电子钱包平台向支付转接平台发送验证决策请求。
在步骤c4中，支付转接平台向验证决策平台发送决策申请请求。
在步骤c5中，验证决策平台向支付转接平台发送增强验证方式。
在步骤c6中，支付转接平台向电子钱包平台发送增强验证方式。
在步骤c7中，电子钱包平台按照增强验证方式对支付的用户进行增强验证，得到验证结果。
在步骤c8中，电子钱包平台向支付转接平台发送验证结果。
在步骤c9中，若验证结果表征增强验证通过，终端设备接收用户的输入操作，确定付款，通过电子钱包平台向支付转接平台发送付款请求。
在步骤c10中，支付转接平台完成支付。
具体地，支付转接平台可与资源管理服务器交互，以使资源管理服务器完成支付的扣款。
在步骤c11中，支付转接平台向电子钱包平台反馈支付结果，支付结果表征支付是否成功。
上述步骤c1至步骤c11的具体内容可参见上述实施例中的相关说明，在此不再赘述。
本申请第三方面提供一种支付增强验证的装置，应用于支付转接平台。图9为本申请第三方面一实施例提供的支付增强验证的装置的结构示意图，如图9所示，支付增强验证的装置500可包括接收模块501、请求生成模块502和发送模块503。
接收模块501可用于在发起支付的情况下，接收电子钱包平台基于嵌入电子钱包的支付应用程序的条码支付功能发送的验证决策请求，电子钱包平台包括终端设备自带的电子钱包的后台服务器。
请求生成模块502可用于根据验证决策请求，生成决策申请请求。
发送模块503可用于向验证决策平台发送决策申请请求。
接收模块501还可用于接收验证决策平台响应于决策申请请求反馈的增强验证方式。
在一些示例中，增强验证方式包括无验证直接通过、无验证直接终止或有验证。有验证包括以下一项或两项以上：支付密码验证、验证码验证、生物特征验证。
发送模块503还可用于向电子钱包平台发送增强验证方式，以使电子钱包平台按照增强验证方式进行增强验证，得到验证结果。
发送模块503还可用于在验证结果表征增强验证通过的情况下，与资源管理服务器交互，完成支付。
在本申请实施例中，在发起支付的情况下，支付转接方的支付转接平台可接收电子钱包平台基于嵌入电子钱包的支付应用程序的条码支付功能发送的验证决策请求，并根据该验证决策请求生成决策申请请求，向验证决策平台发送该决策申请请求，以使验证决策平台根据决策申请请求，为本次支付分配适配的增强验证方式。支付转接平台可将验证决策平台反馈的增强验证方式转发给电子钱包平台，以使电子钱包平台按照该增强验证方式进行增强验证，验证支付的用户的身份的真实性，在增强验证通过的情况下，继续支付流程，以完成支付。在该过程中，增强验证的实施由终端设备厂商方的电子钱包平台进行，但增强验证方式的决策交由支付转接方的支付转接平台和验证决策平台来进行，支付转接方本身负责支付的转接，安全系数更高，对风险的管控更强，可使得决策得到的增强验证方式所对应的增强验证安全性更高，从而提高支付的安全性。
在一些实施例中，接收模块501还可用于：接收交易请求，交易请求包括支付标识和电子钱包标识。
接收模块501可用于：在交易请求中支付标识包括支付应用程序标识的情况下，接收电子钱包平台发送的验证决策请求。支付应用程序标识指示支付应用程序。交易请求还包括用户标识。
在一些实施例中，验证决策请求包括终端用户关联信息。请求生成模块502可用于：获取终端用户关联信息指示的用户在支付转接平台中对应的用户交易关联信息；根据验证决策请求和用户交易关联信息，生成决策申请请求，决策申请请求包括终端用户关联信息和用户交易关联信息。
在一些示例中，终端用户关联信息包括以下一项或两项以上：终端设备信息、终端网络环境信息、账户信息、终端用户使用习惯信息。
在一些示例中，用户交易关联信息包括以下一项或两项以上：交易用户信息、用户风险等级信息、支付信息。
在一些实施例中，交易请求由商户设备扫描终端设备中电子钱包展示的付款码触发，通过收单服务器向支付转接平台发送。
接收模块501还可用于：接收电子钱包平台发送的付款码请求。
发送模块503还可用于：响应于付款码请求，向电子钱包平台发送付款码，以使电子钱包平台将付款码提供给终端设备中的电子钱包。
在一些实施例中，交易请求由终端设备中电子钱包扫描收款码触发，通过电子钱包平台向支付转接平台发送。
本申请第四方面提供一种支付增强验证的装置，应用于电子钱包平台，电子钱包平台包括终端设备自带的电子钱包的后台服务器。图10为本申请第四方面一实施例提供的支付增强验证的装置的结构示意图，如图10所示，支付增强验证的装置600可包括发送模块601、接收模块602和验证模块603。
发送模块601可用于在发起支付的情况下，基于嵌入电子钱包的支付应用程序的条码支付功能，向支付转接平台发送验证决策请求，以使支付转接平台根据验证决策请求，生成决策申请请求向验证决策平台发送。
在一些示例中，验证决策请求包括终端用户关联信息。决策申请请求包括终端用户关联信息和用户交易关联信息，用户交易关联信息在支付转接平台中与终端用户关联信息指示的用户对应。
在一些示例中，终端用户关联信息包括以下一项或两项以上：终端设备信息、终端网络环境信息、账户信息、终端用户使用习惯信息。用户交易关联信息包括以下一项或两项以上：交易用户信息、用户风险等级信息、支付信息。
接收模块602可用于接收支付转接平台发送的增强验证方式。增强验证方式由验证决策平台根据决策申请请求确定。
在一些示例中，其特征在于，增强验证方式包括无验证直接通过、无验证直接终止或有验证。有验证包括以下一项或两项以上：支付密码验证、验证码验证、生物特征验证。
验证模块603可用于与终端设备交互，按照增强验证方式进行增强验证，得到验证结果。
发送模块601还可用于向支付转接平台反馈验证结果，以使支付转接平台在验证结果表征增强验证通过的情况下与资源管理服务器交互，完成支付。
在本申请实施例中，在发起支付的情况下，电子钱包平台基于嵌入电子钱包的支付应用程序的条码支付功能向支付转接平台发送验证决策请求，以使支付转接平台根据该验证决策请求生成决策申请请求，向验证决策平台发送该决策申请请求，由验证决策平台根据决策申请请求，为本次支付分配适配的增强验证方式。电子钱包平台可接收支付转接平台转发的增强验证方式，并按照该增强验证方式进行增强验证，验证支付的用户的身份的真实性，在增强验证通过的情况下，继续支付流程，以完成支付。在该过程中，增强验证的实施由终端设备厂商方的电子钱包平台进行，但增强验证方式的决策交由支付转接方的支付转接平台和验证决策平台来进行，支付转接方本身负责支付的转接，安全系数更高，对风险的管控更强，可使得决策得到的增强验证方式所对应的增强验证安全性更高，从而提高支付的安全性。
在一些实施例中，发送模块601还可用于：向支付转接平台发送交易请求，交易请求包括支付标识和电子钱包标识。
发送模块601可具体用于：在交易请求中支付标识包括支付应用程序标识的情况下，向支付转接平台发送验证决策请求，交易请求还包括用户标识。
在一些实施例中，验证模块603可具体用于根据增强验证方式向终端设备发送验证指令。
接收模块602可具体可用于接收终端设备响应于验证指令采集的验证信息。
验证模块603可具体用于匹配验证信息与验证标准信息，得到验证结果。
在一些实施例中，发送模块601还用于向支付转接平台发送付款码请求。
接收模块602还可用于接收支付转接平台响应于付款码请求提供的付款码。
发送模块601还可用于向终端设备发送付款码，以使终端设备中的电子钱包展示付款码。
在一些实施例中，接收模块602还可用于接收终端设备发送的交易发起请求。交易发起请求由终端设备中的电子钱包扫描收款码触发。
发送模块601可具体用于响应于交易发起请求，向支付转接平台发送交易请求。
本申请第五方面提供一种服务器，应用于支付转接平台。图11为本申请第五方面一实施例提供的服务器的结构示意图。如图11所示，服务器700包括存储器701、处理器702及存储在存储器701上并可在处理器702上运行的计算机程序。
在一些示例中，上述处理器702可以包括中央处理器(CPU)，或者特定集成电路(Application Specific Integrated Circuit，ASIC)，或者可以被配置成实施本申请实施例的一个或多个集成电路。
存储器701可包括只读存储器(Read-Only Memory，ROM)，随机存取存储器(RandomAccess Memory，RAM)，磁盘存储介质设备，光存储介质设备，闪存设备，电气、光学或其他物理/有形的存储器存储设备。因此，通常，存储器包括一个或多个编码有包括计算机可执行指令的软件的有形(非暂态)计算机可读存储介质(例如，存储器设备)，并且当该软件被执行(例如，由一个或多个处理器)时，其可操作来执行参考根据本申请第一方面实施例中支付增强验证的方法所描述的操作。
处理器702通过读取存储器701中存储的可执行程序代码来运行与可执行程序代码对应的计算机程序，以用于实现上述第一方面实施例中的支付增强验证的方法。
在一些示例中，服务器700还可包括通信接口703和总线704。其中，如图11所示，存储器701、处理器702、通信接口703通过总线704连接并完成相互间的通信。
通信接口703，主要用于实现本申请实施例中各模块、装置、单元和/或设备之间的通信。也可通过通信接口703接入输入设备和/或输出设备。
总线704包括硬件、软件或两者，将服务器700的部件彼此耦接在一起。举例来说而非限制，总线704可包括加速图形端口(Accelerated Graphics Port，AGP)或其他图形总线、增强工业标准架构(Enhanced Industry Standard Architecture，EISA)总线、前端总线(Front Side Bus，FSB)、超传输(Hyper Transport，HT)互连、工业标准架构(IndustryStandard Architecture，ISA)总线、无限带宽互连、低引脚数(Low pin count，LPC)总线、存储器总线、微信道架构(Micro Channel Architecture，MCA)总线、外围组件互连(Peripheral Component Interconnect，PCI)总线、PCI-Express(PCI-E)总线、串行高级技术附件(Serial Advanced Technology Attachment，SATA)总线、视频电子标准协会局部(Video Electronics Standards Association Local Bus，VLB)总线或其他合适的总线或者两个或更多个以上这些的组合。在合适的情况下，总线704可包括一个或多个总线。尽管本申请实施例描述和示出了特定的总线，但本申请考虑任何合适的总线或互连。
本申请第六方面提供一种服务器，应用于电子钱包平台。服务器包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序。
存储器包括一个或多个编码有包括计算机可执行指令的软件的有形(非暂态)计算机可读存储介质(例如，存储器设备)，并且当该软件被执行(例如，由一个或多个处理器)时，其可操作来执行参考根据本申请第二方面实施例中支付增强验证的方法所描述的操作。
处理器通过读取存储器中存储的可执行程序代码来运行与可执行程序代码对应的计算机程序，以用于实现上述第二方面实施例中的支付增强验证的方法。
在一些示例中，服务器还可包括通信接口和总线。存储器、处理器、通信接口通过总线连接并完成相互间的通信。
应用于电子钱包平台的服务器中存储器、处理器、通信接口、总线之间的连接及其他内容可参考图11所示的服务器以及相关说明，在此不再赘述。
本申请第七方面还提供一种支付增强验证的系统，该支付增强验证的系统可包括上述实施例中的支付转接平台和电子钱包平台。支付转接平台可执行上述第一方面实施例中的支付增强验证的方法。电子钱包平台可执行上述第二方面实施例中的支付增强验证的方法。具体内容可参见上述实施例中的相关说明，且能达到相同的技术效果，为避免重复，这里不再赘述。
在一些实施例中，该支付增强验证的系统还可包括验证决策平台。验证决策平台可用于响应于支付转接平台发送的决策申请请求，向支付转接平台反馈与决策申请请求匹配的增强验证方式。具体内容可参见上述实施例中的相关说明，且能达到相同的技术效果，为避免重复，这里不再赘述。
本申请第八方面还提供一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序指令，该计算机程序指令被处理器执行时可实现上述第一方面实施例中的支付增强验证的方法或上述第二方面实施例中的支付增强验证的方法，且能达到相同的技术效果，为避免重复，这里不再赘述。其中，上述计算机可读存储介质可包括非暂态计算机可读存储介质，如只读存储器(Read-Only Memory，简称ROM)、随机存取存储器(RandomAccess Memory，简称RAM)、磁碟或者光盘等，在此并不限定。
本申请实施例还可提供一种计算机程序产品，该计算机程序产品中的指令由电子设备的处理器执行时，使得电子设备可执行上述第一方面实施例中的支付增强验证的方法或上述第二方面实施例中的支付增强验证的方法，且能达到相同的技术效果，为避免重复，这里不再赘述。
需要明确的是，本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同或相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。对于装置实施例、服务器实施例、系统实施例、计算机可读存储介质实施例、计算机程序产品实施例而言，相关之处可以参见方法实施例的说明部分。本申请并不局限于上文所描述并在图中示出的特定步骤和结构。本领域的技术人员可以在领会本申请的精神之后，作出各种改变、修改和添加，或者改变步骤之间的顺序。并且，为了简明起见，这里省略对已知方法技术的详细描述。
上面参考根据本申请的实施例的方法、装置(系统)和计算机程序产品的流程图和/或框图描述了本申请的各方面。应当理解，流程图和/或框图中的每个方框以及流程图和/或框图中各方框的组合可以由计算机程序指令实现。这些计算机程序指令可被提供给通用计算机、专用计算机、或其它可编程数据处理装置的处理器，以产生一种机器，使得经由计算机或其它可编程数据处理装置的处理器执行的这些指令使能对流程图和/或框图的一个或多个方框中指定的功能/动作的实现。这种处理器可以是但不限于是通用处理器、专用处理器、特殊应用处理器或者现场可编程逻辑电路。还可理解，框图和/或流程图中的每个方框以及框图和/或流程图中的方框的组合，也可以由执行指定的功能或动作的专用硬件来实现，或可由专用硬件和计算机指令的组合来实现。
本领域技术人员应能理解，上述实施例均是示例性而非限制性的。在不同实施例中出现的不同技术特征可以进行组合，以取得有益效果。本领域技术人员在研究附图、说明书及权利要求书的基础上，应能理解并实现所揭示的实施例的其他变化的实施例。在权利要求书中，术语“包括”并不排除其他装置或步骤；数量词“一个”不排除多个；术语“第一”、“第二”用于标示名称而非用于表示任何特定的顺序。权利要求中的任何附图标记均不应被理解为对保护范围的限制。权利要求中出现的多个部分的功能可以由一个单独的硬件或软件模块来实现。某些技术特征出现在不同的从属权利要求中并不意味着不能将这些技术特征进行组合以取得有益效果。

Claims (22)

1.一种支付增强验证的方法，其特征在于，应用于支付转接平台，所述方法包括：
在发起支付的情况下，接收电子钱包平台基于嵌入电子钱包的支付应用程序的条码支付功能发送的验证决策请求，所述电子钱包平台包括终端设备自带的所述电子钱包的后台服务器；
根据所述验证决策请求，生成决策申请请求，并向验证决策平台发送；
接收所述验证决策平台响应于所述决策申请请求反馈的增强验证方式；
向所述电子钱包平台发送所述增强验证方式，以使所述电子钱包平台按照所述增强验证方式进行增强验证，得到验证结果；
在所述验证结果表征增强验证通过的情况下，与资源管理服务器交互，完成支付。
2.根据权利要求1所述的方法，其特征在于，在所述接收电子钱包平台基于嵌入电子钱包的支付应用程序的条码支付功能发送的验证决策请求之前，还包括：
接收交易请求，所述交易请求包括支付标识和电子钱包标识；
所述接收电子钱包平台基于嵌入电子钱包的支付应用程序的条码支付功能发送的验证决策请求，包括：
在所述交易请求中所述支付标识包括支付应用程序标识的情况下，接收所述电子钱包平台发送的所述验证决策请求，所述支付应用程序标识指示所述支付应用程序，所述交易请求还包括用户标识。
3.根据权利要求1所述的方法，其特征在于，所述验证决策请求包括终端用户关联信息，
所述根据所述验证决策请求，生成决策申请请求，包括：
获取所述终端用户关联信息指示的用户在所述支付转接平台中对应的用户交易关联信息；
根据所述验证决策请求和所述用户交易关联信息，生成所述决策申请请求，所述决策申请请求包括所述终端用户关联信息和所述用户交易关联信息。
4.根据权利要求3所述的方法，其特征在于，
所述终端用户关联信息包括以下一项或两项以上：
终端设备信息、终端网络环境信息、账户信息、终端用户使用习惯信息；
所述用户交易关联信息包括以下一项或两项以上：
交易用户信息、用户风险等级信息、支付信息。
5.根据权利要求2所述的方法，其特征在于，所述交易请求由商户设备扫描所述终端设备中所述电子钱包展示的付款码触发，通过收单服务器向所述支付转接平台发送，
在所述接收交易请求之前，还包括：
接收所述电子钱包平台发送的付款码请求；
响应于所述付款码请求，向所述电子钱包平台发送付款码，以使所述电子钱包平台将付款码提供给所述终端设备中的所述电子钱包。
6.根据权利要求2所述的方法，其特征在于，所述交易请求由所述终端设备中所述电子钱包扫描收款码触发，通过所述电子钱包平台向所述支付转接平台发送。
7.根据权利要求1至6中任意一项所述的方法，其特征在于，所述增强验证方式包括无验证直接通过、无验证直接终止或有验证，
所述有验证包括以下一项或两项以上：
支付密码验证、验证码验证、生物特征验证。
8.一种支付增强验证的方法，其特征在于，应用于电子钱包平台，所述电子钱包平台包括终端设备自带的电子钱包的后台服务器，所述方法包括：
在发起支付的情况下，基于嵌入所述电子钱包的支付应用程序的条码支付功能，向支付转接平台发送验证决策请求，以使所述支付转接平台根据所述验证决策请求，生成决策申请请求向验证决策平台发送；
接收所述支付转接平台发送的增强验证方式，所述增强验证方式由所述验证决策平台根据所述决策申请请求确定；
与所述终端设备交互，按照所述增强验证方式进行增强验证，得到验证结果；
向所述支付转接平台反馈所述验证结果，以使所述支付转接平台在验证结果表征增强验证通过的情况下与资源管理服务器交互，完成支付。
9.根据权利要求8所述的方法，其特征在于，在所述基于嵌入所述电子钱包的支付应用程序的条码支付功能，向支付转接平台发送验证决策请求之前，还包括：
向所述支付转接平台发送交易请求，所述交易请求包括支付标识和电子钱包标识；
所述基于嵌入所述电子钱包的支付应用程序的条码支付功能，向支付转接平台发送验证决策请求，包括：
在所述交易请求中所述支付标识包括支付应用程序标识的情况下，向所述支付转接平台发送验证决策请求，所述交易请求还包括用户标识。
10.根据权利要求8所述的方法，其特征在于，
所述验证决策请求包括终端用户关联信息，所述决策申请请求包括所述终端用户关联信息和用户交易关联信息，所述用户交易关联信息在所述支付转接平台中与所述终端用户关联信息指示的用户对应。
11.根据权利要求10所述的方法，其特征在于，
所述终端用户关联信息包括以下一项或两项以上：
终端设备信息、终端网络环境信息、账户信息、终端用户使用习惯信息；
所述用户交易关联信息包括以下一项或两项以上：
交易用户信息、用户风险等级信息、支付信息。
12.根据权利要求8所述的方法，其特征在于，所述与所述终端设备交互，按照所述增强验证方式进行增强验证，得到验证结果，包括：
根据所述增强验证方式向所述终端设备发送验证指令；
接收所述终端设备响应于所述验证指令采集的验证信息；
匹配所述验证信息与验证标准信息，得到所述验证结果。
13.根据权利要求8所述的方法，其特征在于，在所述向支付转接平台发送验证决策请求之前，还包括：
向所述支付转接平台发送付款码请求；
接收所述支付转接平台响应于所述付款码请求提供的付款码；
向所述终端设备发送所述付款码，以使所述终端设备中的所述电子钱包展示所述付款码。
14.根据权利要求9所述的方法，其特征在于，在所述向所述支付转接平台发送交易请求之前，还包括：
接收所述终端设备发送的交易发起请求，所述交易发起请求由所述终端设备中的所述电子钱包扫描收款码触发；
所述向所述支付转接平台发送交易请求，包括：
响应于所述交易发起请求，向所述支付转接平台发送所述交易请求。
15.根据权利要求8至14中任意一项所述的方法，其特征在于，所述增强验证方式包括无验证直接通过、无验证直接终止或有验证，
所述有验证包括以下一项或两项以上：
支付密码验证、验证码验证、生物特征验证。
16.一种支付增强验证的装置，其特征在于，应用于支付转接平台，所述装置包括：
接收模块，用于在发起支付的情况下，接收电子钱包平台基于嵌入电子钱包的支付应用程序的条码支付功能发送的验证决策请求，所述电子钱包平台包括终端设备自带的所述电子钱包的后台服务器；
请求生成模块，用于根据所述验证决策请求，生成决策申请请求；
发送模块，用于向验证决策平台发送所述决策申请请求；
所述接收模块还用于接收所述验证决策平台响应于所述决策申请请求反馈的增强验证方式；
所述发送模块还用于向所述电子钱包平台发送所述增强验证方式，以使所述电子钱包平台按照所述增强验证方式进行增强验证，得到验证结果；
所述发送模块还用于在所述验证结果表征增强验证通过的情况下，与资源管理服务器交互，完成支付。
17.一种支付增强验证的装置，其特征在于，应用于电子钱包平台，所述电子钱包平台包括终端设备自带的电子钱包的后台服务器，所述装置包括：
发送模块，用于在发起支付的情况下，基于嵌入所述电子钱包的支付应用程序的条码支付功能，向支付转接平台发送验证决策请求，以使所述支付转接平台根据所述验证决策请求，生成决策申请请求向验证决策平台发送；
接收模块，用于接收所述支付转接平台发送的增强验证方式，所述增强验证方式由所述验证决策平台根据所述决策申请请求确定；
验证模块，用于与所述终端设备交互，按照所述增强验证方式进行增强验证，得到验证结果；
所述发送模块还用于向所述支付转接平台反馈所述验证结果，以使所述支付转接平台在验证结果表征增强验证通过的情况下与资源管理服务器交互，完成支付。
18.一种服务器，其特征在于，应用于支付转接平台，所述服务器包括：处理器以及存储有计算机程序指令的存储器；
所述处理器执行所述计算机程序指令时实现如权利要求1至7中任意一项所述的支付增强验证的方法。
19.一种服务器，其特征在于，应用于电子钱包平台，所述服务器包括：处理器以及存储有计算机程序指令的存储器；
所述处理器执行所述计算机程序指令时实现如权利要求8至15中任意一项所述的支付增强验证的方法。
20.一种支付增强验证的系统，其特征在于，包括：
支付转接平台，用于执行如权利要求1至7中任意一项所述的支付增强验证的方法；
电子钱包平台，用于执行如权利要求8至15中任意一项所述的支付增强验证的方法。
21.根据权利要求20所述的系统，其特征在于，还包括：
验证决策平台，用于响应于支付转接平台发送的所述决策申请请求，向所述支付转接平台反馈与所述决策申请请求匹配的增强验证方式。
22.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有计算机程序指令，所述计算机程序指令被处理器执行时实现如权利要求1至15中任意一项所述的支付增强验证的方法。
CN202310898033.1A 2023-07-20 2023-07-20 支付增强验证的方法、装置、服务器、系统及介质 Pending CN117132281A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202310898033.1A CN117132281A (zh) 2023-07-20 2023-07-20 支付增强验证的方法、装置、服务器、系统及介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202310898033.1A CN117132281A (zh) 2023-07-20 2023-07-20 支付增强验证的方法、装置、服务器、系统及介质

Publications (1)

Publication Number Publication Date
CN117132281A true CN117132281A (zh) 2023-11-28

Family

ID=88853530

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202310898033.1A Pending CN117132281A (zh) 2023-07-20 2023-07-20 支付增强验证的方法、装置、服务器、系统及介质

Country Status (1)

Country Link
CN (1) CN117132281A (zh)

Similar Documents

Publication Publication Date Title
CN105608621A (zh) 远程开户的方法、服务器及系统
CN106897874B (zh) 移动支付方法、装置及系统
CN108717652B (zh) 订单处理系统及方法、订单服务端、第二客户端
CN109544335B (zh) 基于区块链的交易数据处理方法、装置、设备及存储介质
US11636488B2 (en) System for managing personal identifiers and financial instrument use
CN110084586B (zh) 一种移动终端安全支付系统和方法
CN111861457B (zh) 支付令牌申请方法、设备、系统和服务器
CN111861431A (zh) 数字货币的支付方法及系统
CN112085531B (zh) 资源处理方法、服务器、终端、设备、系统及存储介质
TWI839875B (zh) 支付方法、使用者終端、裝置、設備、系統及介質
CN111243145B (zh) 一种处理访客信息的方法、装置、介质及电子设备
CN113065622A (zh) 一种业务办理方法、终端及服务器
CN115564430A (zh) 交易授权
KR20170052126A (ko) 금융정보 생성을 위한 비대면 다중 인증 방법
CN110766388B (zh) 虚拟卡生成方法及系统、电子设备
CN113259873B (zh) 基于5g消息的预约换卡方法、系统及银行端
EP3552133B1 (en) System and method for online digital univocal identification
CN112330323A (zh) 生成令牌种子和二维码的方法、支付方法和装置
CN110766415A (zh) 基于付款码的交易处理方法以及付款码的处理方法
RU137815U1 (ru) Система проверки подлинности держателя платежной карты
CN117132281A (zh) 支付增强验证的方法、装置、服务器、系统及介质
CN115829556A (zh) 支付方法、设备、装置、介质及产品
CN113706137B (zh) 一种应用于缴费信息的数据处理方法及系统
CN111681009B (zh) 多平台集中认证授权系统及方法、认证授权及服务装置
CN111937021B (zh) 电子交易系统

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
REG Reference to a national code

Ref country code: HK

Ref legal event code: DE

Ref document number: 40102040

Country of ref document: HK