本发明专注于移动支付领域，特别是一种新型的移动支付系统和方法，该系统和方法不仅能够兼容基于se技术的手机支付，还包括基于白盒的hce支付方式，并且支持扫码支付功能。

背景技术：

现阶段移动支付业务在国内快速发展，主要有以下几种类型：

基于SE技术的各类手机支付服务，例如华为Pay、小米Pay等。

（2）基于白盒的hce支付；

（3）扫码支付。

在上述各种支付情境中，无论是境内还是境外，均未存在一种移动支付系统，该系统能够实现发卡银行直接接入并同步进行各类业务操作。

在现有技术条件下，若发卡机构欲同时提供这三种移动支付方式，必须独立构建三套系统，分别用于支撑SE、HCE以及二维码支付模式。

为了使更多持卡用户能够体验到移动支付带来的便捷，同时降低发卡方在接入改造方面的投入，有必要研发一套既能兼容上述三种移动支付方式，又能有效减少改造工作的移动支付系统及相应的方法。

公开在本发明背景部分所提供的信息，其目的仅在于加深对发明整体背景的认识，此信息不应被视为对现有技术的认可，亦不应以任何方式表明这些信息已为该领域内的普通技术人员所普遍知晓。

技术实现要素：

考虑到这一情况，本发明提出了一套移动支付系统及相应的方法，该系统具备同时支持hce、se以及二维码支付功能的能力。

本发明的移动支付方法，其特征在于，包括：

绑定流程由移动支付平台负责构建，该流程会为用户与其真实银行卡之间的绑定创建相应的标识，且针对不同的交易类型，会生成一致的绑定标识。

在进行交易操作时，需遵循由绑定步骤所生成的交易流程，并且针对不同的交易类型，将采用相同的交易计数器进行区分。

优选地，进一步包括：

生命周期管理流程涉及移动支付平台，该平台根据用户需求或发卡行的要求，负责执行相应的管理任务。

在交易流程中，特别地，se模式和hce模式下的交易次数统计及验证工作，以及二维码模式下的交易次数统计及验证工作，均由移动支付平台内的不同模块分别负责执行。

在交易流程中，特别地，对于se模式和hce模式下的交易，其计数与验证任务由移动支付平台的申请模块负责处理；而在二维码模式下的交易，则由交易处理模块来完成计数与验证工作。

本发明的移动支付平台，其特征在于，具备：

申请模块旨在创建与用户实际银行卡关联的绑定，并且针对各种交易类型，能够生成统一的绑定信息。

交易处理模块，用于执行交易处理，

在se模式及hce模式下所进行的交易次数统计和交易真实性验证，以及二维码模式下的交易次数统计和交易真实性验证，均由移动支付平台中的不同功能模块分别负责执行。

优选情况下，该申请模块主要负责在se模式和hce模式下进行交易次数的统计以及交易真伪的验证；而交易处理模块则负责在二维码模式下进行交易次数的统计和交易真伪的验证。

优选地，进一步具备：

生命周期管理模块，该模块的实施依据用户的需求或发卡行的指令，对生命周期进行相应的管理。

本款创新的移动支付系统，其显著特点包括：使用移动终端、搭建移动支付平台以及设立发卡机构。

其中，所述移动终端用于发起移动支付请求，

该支付平台所具备的功能包括：一个申请模块，该模块负责创建与用户实际银行卡绑定的账户，且针对不同的交易类型，会生成相同的账户；此外，还有一个交易处理模块，专门负责执行交易处理任务。特别地，在SE模式和HCE模式下进行的交易，其计数和验证工作由移动支付平台的一个特定模块负责；而在二维码模式下进行的交易，其计数和验证工作则由另一个不同的模块来完成。

所述发卡行用于校验用户信息并处理移动支付请求。

本项发明的计算机可读介质内含有计算机程序，当该程序由处理器执行后，能够实现所述的移动支付功能。

本款计算机设备含有内存、运算单元，以及存放在内存中并可由运算单元执行的软件程序，其显著特点为，当运算单元运行该软件程序时，能够实现所述的移动支付操作。

借助本文所附插图及其所展示的与发明原理相关的具体实施细节，本发明的方法与装置的其他特性与优势将更加直观地显现出来，或得到详细阐释。

附图说明

图1是表示本发明的移动支付方法的流程图。

图2是本发明的绑定步骤s100的具体流程图。

图3是本发明的一种方式的生命周期管理步骤的具体流程图。

图4是本发明的另一种方式的生命周期管理步骤的具体流程图。

图5是本发明的交易步骤s200的具体流程图。

图6是表示本发明的移动支付平台的构造示意图。

具体实施方式

此处所展示的是本发明若干实施实例的概览，目的在于对发明的核心概念进行初步阐释。此非旨在确立发明的核心组成部分或界定其保护边界。

在阐述本发明技术细节之前，我们首先对本申请中涉及的一些专业术语进行简要介绍。

银行卡，系由商业银行及其他金融机构面向公众发行的，具备消费信贷、资金转移、现金存取等全部或部分功能的信用支付手段。

hce（主机端）功能允许，无需借助安全媒介，nfc控制器能够将智能卡指令的相关数据传递给应用处理器，同时操作系统也会将这些信息传达至指定的手机应用程序。

安全单元（se），这一模块主要服务于支付应用的数据安全存储与运算，确保支付流程在芯片层面获得稳固的安全防护。其存在形式多样，包括智能SD卡、智能SIM卡，亦或是移动终端内部嵌入的独立安全模块。

（令牌）系一种虚拟卡号，旨在用于向卡组织进行申请，并支持移动支付交易。

二维码是一种在平面上按照特定规则排列，由黑白相间的图形符号组成的记录数据信息的方式，它能够被图像输入设备或光电扫描设备自动识别，进而实现信息的自动化处理。

图1是表示本发明的移动支付方法的流程图。

如图1所示，本发明的移动支付方法包括：

步骤s100中，移动支付平台负责创建与用户实际银行卡的绑定关系，并且针对各种交易类型，生成统一的绑定标识。

交易步骤s200涉及通过绑定步骤所生成的交易执行，具体来说，针对不同的交易模式，需分别采用同一的交易计数器进行操作。

具体而言，在交易流程的s200环节，移动支付平台中的不同模块分别负责执行在se模式和hce模式下进行的交易次数统计以及交易验证工作，而在二维码模式下进行的交易计数和验证任务则由另一组模块独立完成。在SE模式以及HCE模式下所进行的交易次数统计与验证工作，均由移动支付平台的申请模块负责处理；而在二维码交易模式下，此类工作则由移动支付平台的交易处理模块负责执行。

作为优选方案，它还具备以下特点：具体包括生命周期管理流程，该流程由移动支付平台根据用户需求或发卡机构的申请来执行。

首先，对于绑定步骤s100进行具体说明。

图2展示了本发明中绑定步骤s100的详细流程图。在该流程图中，移动该应用或网关的动作等同于移动终端的操作，比如说是用于发起移动支付功能的手机。图2展示了用户可借助不同方式向移动支付平台提出申请，涵盖多种类型。这些申请的处理流程均在移动支付平台端进行。无论用户申请哪一种类型，发卡行的处理手段均保持一致。同时，发卡行关注的焦点在于确保真实卡片能够支持相应的移动支付交易。

如图2所示绑定步骤s100包括以下具体子步骤：

步骤1：用户登录移动应用，进行移动支付卡申请操作；

用户需按照提示输入必要的个人信息，随后移动应用会对这些信息进行初步的合法性审核，涉及的内容包括用户的身份资料以及与其绑定的银联卡的相关数据。

在步骤3中，移动应用会将用户的相关资料传递至移动支付系统，同时，在申请移动支付卡片的过程中，还需将设备数据一并提交给移动支付平台。

步骤4：移动支付平台将用户信息发送给发卡行进行用户校验；

步骤5：发卡行进行用户校验；

步骤6：发卡行返回用户校验结果，移动支付平台存储申请信息；

步骤7：移动支付平台生成用户使用协议及条款并通知用户；

用户须接受相关条款与协议，随后由移动应用程序将其信息传递至移动支付系统。

步骤9：移动支付平台生成移动支付卡信息（即，标记）；

步骤10：移动支付平台将（标记）转送给发卡行；

步骤11：移动支付平台向用户展示支付卡申请已成功完成的信息，同时告知用户需要申请一个激活码。

接着，对于生命周期管理步骤进行具体说明。

发卡行与移动支付平台共享一套统一的接口，负责对生命周期进行管理。该接口能够应对hce、se模式和二维码支付等三种支付场景。此外，生命周期管理既可由移动终端（即移动应用或app网关）借助移动支付平台启动，亦可通过发卡行通过移动支付平台启动。以下将分别对这两种情况予以阐述。

图3展示了本发明所采用的一种生命周期管理的详细步骤流程图。其中，该生命周期管理是由移动终端，也就是移动应用或网关，借助移动支付平台来启动的。

如图3所示，本发明的生命周期管理步骤具体包括下述内容：

步骤1：持卡人从移动应用/app网关发起生命周期管理请求；

步骤2：移动支付平台处理持卡人请求；

步骤3：移动支付平台通知处理结果到发卡行；

步骤4：发卡行接收到请求后返回应答到移动支付平台；

步骤5：移动支付平台将处理结果反馈到移动应用/app网关；

步骤6：移动应用/app网关处理通知结果。

图4展示了本发明所采用的另一种生命周期管理流程的详细步骤图。该流程图中描绘了生命周期管理是由发卡行借助移动支付平台启动的，而发卡行有权自主向移动支付平台提出生命周期管理的申请。

如图4所示，本发明的生命周期管理涉及以下具体步骤：，

步骤1：发卡行发起生命周期管理请求；

步骤2：移动支付平台处理请求；

步骤3：移动支付平台通知处理结果到发卡行；

步骤4：移动支付平台将处理结果反馈待移动应用/app网关。

最后，对于交易步骤s200进行具体说明。

本发明中，移动支付平台实现了对同一ATC的独立处理，确保了同一卡在不同支付场景下的使用。具体来说，在SE模式和HCE模式下，平台能够同时支持二维码支付。对于提交的交易，平台在确认无误后，会将交易请求还原为真实卡号，并转发至发卡机构。

具体而言，se模式和hce模式的交易验证流程是在申请模块中进行的；这是因为，校验arqc所需密钥的分散工作也是在申请模块中完成的。同时，atc的校验和记录工作同样是在处理模块中完成的。至于二维码支付的交易，它们是在交易处理模块中完成的，而二维码类型交易的atc校验同样是在交易处理模块中完成的。

通过将空中交通管制（ATC）和交易验证功能分别设置于不同的处理单元，用户得以使用同一平台完成多样化的交易操作。

图5展示了本发明交易步骤s200的详细流程图。其中，“收单”环节涉及诸如收单机构等机构，“转接系统”则被部署在收单机构与移动支付平台之间。

如图5所示，本发明的交易步骤s200具体包括下述子步骤：

用户在终端处实施刷卡操作，或者二维码被扫描识别，从而向收款方发起一笔交易申请。

步骤2：收单机构获取交易后向转接系统发送交易申请；

步骤3：转接系统向移动支付平台发送支付处理请求；

步骤4：平台将执行移动支付验证操作，并完成去标记化处理（此过程将转换成与之关联的实际银行卡的卡号）。

步骤5：转接系统向发卡发送交易请求；

步骤6：发卡行将交易应答并发送到转接系统；

步骤7：转接系统收到发卡应答后通知到收单。

正如前文所述，移动支付平台依据系统内部的细致分类，对发卡行不进行分类处理，同时提供了包括json接入、xml接入在内的三种接入途径供发卡行挑选，从而有效降低了发卡行接入移动支付平台的复杂程度。在处理移动支付交易时，移动支付平台将二维码支付以及hce、se支付场景中的atc和交易验证分别置于不同的处理模块，从而实现了用户能够享受到覆盖多种应用场景的功能。

接着，对于本发明的移动支付平台进行说明。

图6是表示本发明的移动支付平台的构造示意图。

如图6所示，本发明的移动支付平台100具备：

申请模块101，其功能是生成与用户实际银行卡绑定信息，且针对不同交易类型，能够生成一致的绑定数据。

交易处理模块102，用于执行交易处理；以及

生命周期管理模块编号为103，该模块执行的管理活动是依据用户的需求或是发卡行的指令来进行的。

在SE模式和HCE模式下进行的交易统计与验证，以及二维码模式下的交易统计与验证，分别由移动支付平台中的不同模块负责执行。具体来说，申请模块101负责处理SE模式和HCE模式下的交易统计与验证，而交易处理模块102则负责二维码模式下的交易统计与验证。

进一步，本发明还提供一种移动支付系统。该移动支付系统整合了移动终端、支付平台和发卡行等功能。移动终端负责发起支付请求，支付平台则包括申请模块和交易处理模块。申请模块负责创建与用户实际卡片绑定的虚拟卡，并为不同交易模式生成统一的卡片。交易处理模块负责执行交易操作，而在se模式和hce模式下的交易计数与验证，以及二维码模式下的交易计数与验证，分别由支付平台的不同模块负责处理。发卡行则负责核实用户信息，并处理支付请求。

此外，本发明还涉及一种计算机可读的存储介质，该介质中存有特定的计算机软件，当该软件由处理器运行时，能够执行前述的移动支付流程。

此外，本创新技术还涉及一种电脑设备，该设备包含内存、运算单元，以及存储于内存中、可在运算单元上运行的软件程序。该软件程序在运算单元上运行时，能够实现先前提到的移动支付操作方式。

发卡行与移动支付平台共享一个统一的接口，该接口负责处理各类申请及生命周期管理，从而大幅降低了发卡行在接入过程中所需进行的改造工作。

本发明的移动支付方式及其系统，具备兼容hce、se和二维码支付的功能，从而显著提升了用户支付操作的便利性。此外，通过构建一个统一的发卡行接入平台，发卡行仅需进行一次调整，便能够支持上述三种支付场景，此举有效降低了接入改造的工作量。

本例主要阐述了本项发明的移动支付技术和支付系统。即便只是对某些实施细节进行了具体说明，但本行业的一般技术人员应知晓，本发明仍可在不违背其核心精神和适用范围的前提下，以多种方式得以实现。因此，所提供的实例及其应用方法仅作为参考，并非具有约束力，只要不违背附图中权利要求所界定的本发明的基本理念与界限，本发明便可以包括各式各样的改动和替代方案。