CN116384991A - 转移支付方法、装置、设备、介质和产品 - Google Patents

Abstract

本公开提供了一种转移支付方法，可以应用于物联网技术领域和金融科技领域。该转移支付方法包括：根据接收的第一设备端的转移支付请求，查询预存储的转移支付协议；解析所述转移支付协议生成确认支付请求；以及根据所述确认支付请求和所述转移支付协议生成支付执行任务，并通过第二设备端执行所述支付执行任务以完成所述转移支付。本公开还提供了一种转移支付装置、设备、存储介质和程序产品。

Description

转移支付方法、装置、设备、介质和产品

技术领域

本公开涉及物联网技术领域，更具体地涉及一种转移支付方法、装置、设备、介质和产品。

背景技术

移动端支付为我国用户的主流支付方式，移动端支付主要有两点优势：一是便捷，支持支付密码、生物识别等多种支付方式；二是安全，具有移动支付APP安全控制和支付验签风控双重保障。

除了移动支付，目前生产上还存在传统的PC端支付和新兴的智能新终端支付等。相比于移动支付，传统的PC端支付和智能新终端支付均存在支付便捷和安全不可兼得的问题。传统的PC端支付无法支持生物识别验签，为确保交易安全，通常需要长流程的信息输入、确认以及介质验签来完成支付，这就牺牲了用户支付的便捷性。智能新终端需要配套搭建支付交互屏幕，支持用户完成支付，同样存在传统PC端支付验证的问题，如果为了便捷支持生物识别技术，一是成本高，二是缺少移动支付APP安全控制和支付验签风控的加持，安全性较弱。

发明内容

鉴于上述问题至少之一，本公开提供了可兼顾支付便捷性和安全性的一种转移支付方法、装置、设备、介质和程序产品。

本公开的一个方面提供了一种转移支付方法，其中，包括：根据接收的第一设备端的转移支付请求，查询预存储的转移支付协议；解析所述转移支付协议生成确认支付请求；以及根据所述确认支付请求和所述转移支付协议生成支付执行任务，并通过第二设备端执行所述支付执行任务以完成所述转移支付。

根据本公开的实施例，在所述根据接收的第一设备端的转移支付请求，查询预存储的转移支付协议之前，还包括：根据接收的业务绑定请求，上传终端设备信息；根据所述终端设备信息和用户身份信息生成所述转移支付协议。

根据本公开的实施例，在所述根据所述终端设备信息和用户身份信息生成所述转移支付协议中，包括：加密所述终端设备信息和用户身份信息生成支付协议信息；存储所述支付协议信息生成所述转移支付协议。

根据本公开的实施例，在所述根据接收的第一设备端的转移支付请求，查询预存储的转移支付协议中，包括：根据所述转移支付请求获取用户登陆信息；根据所述用户登陆信息查询所述转移支付协议。

根据本公开的实施例，在所述根据所述用户登陆信息查询所述转移支付协议中，包括：根据用户登录信息获取协议查询结果；根据所述协议查询结果确定所述转移支付协议。

根据本公开的实施例，在所述解析所述转移支付协议生成确认支付请求中，包括：解密所述转移支付协议生成第一协议状态；根据所述第一协议状态生成所述确认支付请求。

根据本公开的实施例，在所述根据所述第一协议状态生成所述确认支付请求中，包括：根据所述第一协议状态识别所述转移支付请求中关于所述第一设备端的设备使用信息；基于所述设备使用信息生成所述确认支付请求。

根据本公开的实施例，在所述基于所述设备使用信息生成所述确认支付请求中，还包括：根据所述设备使用信息更新所述转移支付协议。

根据本公开的实施例，在所述解析所述转移支付协议生成确认支付请求中，还包括：解析所述转移支付协议生成转移支付消息；根据接收的第二设备端响应于所述转移支付消息发送的确认支付消息生成所述确认支付请求。

根据本公开的实施例，在所述根据所述确认支付请求和所述转移支付协议生成支付执行任务中，包括：根据所述确认支付请求解密所述转移支付协议，生成第二协议状态；根据所述第二协议状态生成支付执行任务；发送所述支付执行任务至所述第二设备端。

根据本公开的实施例，所述的转移支付方法还包括：接收所述第二设备端执行所述支付执行任务生成的支付完成消息；根据所述支付完成消息生成支付结果通知以发送至所述第一设备端和第二设备端。

本公开的另一个方面提供了一种转移支付装置，其中，包括协议查询模块、解析生成模块和支付执行模块。协议查询模块用于根据接收的第一设备端的转移支付请求，查询预存储的转移支付协议；解析生成模块用于解析所述转移支付协议生成确认支付请求；以及支付执行模块用于根据所述确认支付请求和所述转移支付协议生成支付执行任务，并通过第二设备端执行所述支付执行任务以完成所述转移支付。

本公开的第三方面提供了一种电子设备，包括：一个或多个处理器；存储器，用于存储一个或多个程序，其中，当所述一个或多个程序被所述一个或多个处理器执行时，使得一个或多个处理器执行上述转移支付方法。

本公开的第四方面还提供了一种计算机可读存储介质，其上存储有可执行指令，该指令被处理器执行时使处理器执行上述转移支付方法。

本公开的第五方面还提供了一种计算机程序产品，包括计算机程序，该计算机程序被处理器执行时实现上述转移支付方法。

附图说明

通过以下参照附图对本公开实施例的描述，本公开的上述内容以及其他目的、特征和优点将更为清楚，在附图中：

图1示意性示出了根据本公开实施例的转移支付方法、装置、设备、介质和程序产品的应用场景图；

图2示意性示出了根据本公开实施例的转移支付方法的流程图；

图3A示意性示出了根据本公开实施例的服务端的组成图；

图3B示意性示出了根据本公开实施例的生成转移支付协议的场景图；

图3C示意性示出了根据本公开实施例的执行设备认证的场景图；

图4示意性示出了根据本公开一实施例的转移支付方法的场景流程图；

图5示意性示出了根据本公开另一实施例的转移支付方法的场景流程图；

图6示意性示出了根据本公开实施例的转移支付装置的结构框图；以及

图7示意性示出了根据本公开实施例的适于实现转移支付方法的电子设备的方框图。

具体实施方式

以下，将参照附图来描述本公开的实施例。但是应该理解，这些描述只是示例性的，而并非要限制本公开的范围。在下面的详细描述中，为便于解释，阐述了许多具体的细节以提供对本公开实施例的全面理解。然而，明显地，一个或多个实施例在没有这些具体细节的情况下也可以被实施。此外，在以下说明中，省略了对公知结构和技术的描述，以避免不必要地混淆本公开的概念。

在此使用的术语仅仅是为了描述具体实施例，而并非意在限制本公开。在此使用的术语“包括”、“包含”等表明了所述特征、步骤、操作和/或部件的存在，但是并不排除存在或添加一个或多个其他特征、步骤、操作或部件。

在此使用的所有术语(包括技术和科学术语)具有本领域技术人员通常所理解的含义，除非另外定义。应注意，这里使用的术语应解释为具有与本说明书的上下文相一致的含义，而不应以理想化或过于刻板的方式来解释。

在使用类似于“A、B和C等中至少一个”这样的表述的情况下，一般来说应该按照本领域技术人员通常理解该表述的含义来予以解释(例如，“具有A、B和C中至少一个的系统”应包括但不限于单独具有A、单独具有B、单独具有C、具有A和B、具有A和C、具有B和C、和/或具有A、B、C的系统等)。

近年来，随着互联网和移动网络的快速发展，在线支付和移动支付逐渐成为电子商务的主要支付方式。作为新兴的电子支付方式，移动支付拥有随时随地、方便、快捷等诸多特点。随着信息技术的快速发展，手机之类的手持无线终端正逐渐地发展成为能够支持各种信息服务和各种环境的低功耗、超轻量的智能终端，这为移动支付的发展提供了很好的硬件环境，移动支付已日益成为我们生活中不可或缺的一部分。

其中，现有应用已存在一次申请即可介入多种支付方式的方案，从而能够在需要接入三方支付，仅通过一个移动终端实现，而无需重新注册多个应用，具体地现有的这种移动支付方法具体可以包括以下步骤1-步骤11，具体如下：

步骤1，移动设备终端与服务端进行HTTP通信，采集所述移动设备终端的设备信息，生成用户唯一标识，将该用户唯一标识与设备信息绑定。

步骤2，所述移动设备终端通过向所述服务端发送加密的支付请求报文，该支付请求包括支付模式及其对应的第三方支付接口、支付金额、支付商户名称及支付时间。

步骤3，加密的支付请求报文执行传输。

步骤4，接收加密的支付请求报文，并对支付请求报文进行解密，从解密后的支付请求中提取支付请求并发送。

步骤5，接收解密后的支付请求，并根据支付请求中的支付模式及对应的第三方支付接口，请求不同的三方支付服务器，将支付请求报文发送给对应的第三方支付平台。

步骤6，第三方支付服务器接收支付请求报文，生成支付订单信息，并发送支付订单信息进行加密处理。

步骤7，将加密的支付订单信息发送进行解密。

步骤8，将解密后的支付订单信息发送给所述移动设备终端。

步骤9，所述移动设备终端在接收到的支付页面填写支付验证信息，包括银行卡号、支付密码或快捷支付信息或指纹支付信息，所述移动设备终端将支付验证信息加密后发送进行解密。

步骤10，将支付验证信息解密后发送给，所述支付处理模块递给所述三方支付服务器。

步骤11，支付验证信息验证成功后，所述三方支付服务器返回处理结果，接收所述三方支付服务器回传的支付通知，并将支付成功的信息传递给所述移动设备终端和第三方支付平台。

可见，上述移动支付的方式虽然可以聚合了多种支付，建立了从服务端到用户端的聚合支付方案，接入方仅需要一次申请，即可接入多种支付方式，简化了移动用户终端的操作和相应的开发工作，但是仍然无法很好地兼容支付便捷性和安全性。

鉴于现有技术存在的上述问题至少之一，本公开提供了可兼顾支付便捷性和安全性的转移支付方法、装置、设备、介质和程序产品。

需要说明的是，本公开实施例的转移支付方法和装置可以应用于物联网技术领域、信息安全技术领域以及金融科技领域，也可以应用于除物联网技术领域、信息安全技术领域和金融科技领域之外的任意领域，如金融服务领域等，本公开实施例的转移支付方法和装置的应用领域不作具体限定。

此外，在本公开的技术方案中，所涉及的用户个人信息的收集、存储、使用、加工、传输、提供、公开和应用等处理，均符合相关法律法规的规定，采取了必要保密措施，且不违背公序良俗。在本公开的技术方案中，在获取或采集用户个人信息之前，均获取了用户的授权或同意。

鉴于上述问题至少之一，本公开提供了可兼顾支付便捷性和安全性的一种转移支付方法、装置、设备、介质和程序产品。

本公开的实施例提供了一种转移支付方法，包括：根据接收的第一设备端的转移支付请求，查询预存储的转移支付协议；解析所述转移支付协议生成确认支付请求；以及根据所述确认支付请求和所述转移支付协议生成支付执行任务，并通过第二设备端执行所述支付执行任务以完成所述转移支付。

图1示意性示出了根据本公开实施例的转移支付方法、装置、设备、介质和程序产品的应用场景图。

如图1所示，根据该实施例的应用场景100可以包括终端设备101、102、103、网络104和服务器105。网络104用以在终端设备101、102、103和服务器105之间提供通信链路的介质。网络104可以包括各种连接类型，例如有线、无线通信链路或者光纤电缆等等。

用户可以使用终端设备101、102、103通过网络104与服务器105交互，以接收或发送消息等。终端设备101、102、103上可以安装有各种通讯用户端应用，例如购物类应用、网页浏览器应用、搜索类应用、即时通信工具、邮箱用户端、社交平台软件等(仅为示例)。

终端设备101、102、103可以是具有显示屏并且支持网页浏览的各种电子设备，包括但不限于智能手机、平板电脑、膝上型便携计算机和台式计算机等等。

服务器105可以是提供各种服务的服务器，例如对用户利用终端设备101、102、103所浏览的网站提供支持的后台管理服务器(仅为示例)。后台管理服务器可以对接收到的用户请求等数据进行分析等处理，并将处理结果(例如根据用户请求获取或生成的网页、信息、或数据等)反馈给终端设备。

需要说明的是，本公开实施例所提供的转移支付方法一般可以由服务器105执行。相应地，本公开实施例所提供的转移支付装置一般可以设置于服务器105中。本公开实施例所提供的转移支付方法也可以由不同于服务器105且能够与终端设备101、102、103和/或服务器105通信的服务器或服务器集群执行。相应地，本公开实施例所提供的转移支付装置也可以设置于不同于服务器105且能够与终端设备101、102、103和/或服务器105通信的服务器或服务器集群中。

应该理解，图1中的终端设备、网络和服务器的数目仅仅是示意性的。根据实现需要，可以具有任意数目的终端设备、网络和服务器。

以下将基于图1描述的场景，通过图2～图5对本公开实施例的转移支付方法进行详细描述。

图2示意性示出了根据本公开实施例的转移支付方法的流程图。

如图2所示，该实施例的转移支付方法包括操作S210～操作S230。

在操作S201中，根据接收的第一设备端的转移支付请求，查询预存储的转移支付协议；

在操作S202中，解析所述转移支付协议生成确认支付请求；

在操作S203中，根据所述确认支付请求和所述转移支付协议生成支付执行任务，并通过第二设备端执行所述支付执行任务以完成所述转移支付。

服务端为可以实现上述转移支付方法的设备端，如金融企业(如银行)的大规模数据中心的至少一服务器，以具体实现上述转移支付方法的具体流程。其中，服务端可以同时分别作为第一设备端和第二设备端实现各自支付功能的支持服务器。换言之，基于第一设备端与服务端之间的交互可以利用第一设备端实现独立支付功能，也可以基于第二设备端与服务端的交互利用第二设备端实现独立支付功能。其中，对应不同的金融企业可以具有不同服务端，如银行甲的服务端和银行乙的服务端可以是两个不同的服务端。

第一设备端可以是非便携可移动支付的设备端，如电脑网页登录的PC端、位置固定的支付柜台和支付设备端。其中，第一设备端的支付过程一般需要依赖支付介质(如支付U盾)等进行支付验签来保障支付安全性。其中，第二设备端则可以是便携可以移动支付的设备端，如智能手机的移动端或者具有移动可支付功能的应用程序的IPAD的移动端等。其中，第二设备端的支付过程一般无需支付介质的支付验签实现，而是仅通过用户的简单验证操作实现直接高效的便捷支付。

转移支付请求可以为实现转移支付功能的请求指令(如具体的请求代码)或者具有相应请求信息的请求文件(如可读文档或者文件等)。其中，转移支付可以理解为将第一设备端的支付请求转移至其他非第一设备端的设备端继续执行支付并完成支付的功能。其中，转移支付请求一般可以通过第一设备端生成并发送至服务端，并由服务端实现接收和进一步的转移支付处理。

转移支付协议可以为确保转移支付功能安全、稳定且高效实现而建立在第一设备端、服务端和第二设备端三者之间的共同遵循的约定规则，基于该转移支付协议，才能够借助服务端作为中间设备端实现将第一设备端的支付过程转移至第二设备端，并最终通过第二设备端实现最终支付。

转移支付协议一般可以同时兼具第一设备端、服务端和第二设备端的设备端信息以及用户个人信息内容，从而能够确保整个支付的过程是针对同一用户的个人支付过程，保证整个支付过程的安全性和便携性的兼顾效果。为此，可以对转移支付协议进行诸如加解密处理，从而能够在将用户个人信息作为中间信息实现对三者之间的信息绑定，保证转移支付协议在执行过程中的准确性。

通过对转移支付协议进行解析(如解密处理)，可以对转移支付协议中所具有的设备端信息和用户个人信息以及对应的转移支付请求进行解析，并据此可以生成针对第二设备端的确认支付请求。确认支付请求可以是为通过第二设备端实现最终支付的请求指令(如具体的请求代码)或者具有相应请求信息的请求文件(如可读文档或者文件等)，主要用于判断第二设备端是否可以继续执行转移支付。

基于上述确认支付请求和转移支付协议所具有的相关信息，可以生成用于通过第二设备端执行支付的支付执行任务，该支付执行任务可以是第二设备端可执行处理的一个或多个指令序列，能够在被操作执行时使得第二设备端可以便捷、高效的实现安全支付。

其中，在本公开的实施例中，在获取用户的信息之前，可以获得用户的同意或授权。例如，在操作S201之前，可以向用户发出获取用户信息的请求。在用户同意或授权可以获取用户信息的情况下，生成绑定用户个人信息的转移支付协议。

本公开实施例的上述转移支付方法提供了一种任意终端支付交易可直接转移至移动端执行支付的方案，且该方案也可以支持双端并行支付。具体地，可以将PC端和智能新终端等第一设备端的支付交易转移至用户可信的移动支付设备(即第二设备端)进行支付，且在此过程中还可以通过支付消息提示用户通过作为移动端的该第二设备端完成支付，从而能够兼顾用户支付的便捷性和安全性，显著提高了PC端支付的效率，同时也极大地改善了用户支付体验。

以下将基于图2描述的流程，通过图3A～图5的具体实施案例对上述转移支付方法进行详细描述。

图3A示意性示出了根据本公开实施例的服务端的组成图；图3B示意性示出了根据本公开实施例的生成转移支付协议的场景图；图3C示意性示出了根据本公开实施例的执行设备认证的场景图；图4示意性示出了根据本公开一实施例的转移支付方法的场景流程图；以及图5示意性示出了根据本公开另一实施例的转移支付方法的场景流程图。

如图3B-图5所示，可以作为第一设备端的PC端可以提供基于服务端的支付端，以提供商业支付界面使得用户与服务端实现支付交互。用户PC端登录网页或应用程序进行支付选择时，可以支持用户录入支付信息，进行支付验签完成支付，展示支付结果；

如图3B-图5所示，可以作为第二设备端的移动端可以提供商业银行的应用软件或者应用程序，移动端可以支持各类金融服务，包括获取移动端的设备产品序列号(如IMEI序列号)，提供基于服务端的完整移动支付服务，支持推送转移支付消息，以及在完成支付后的支付结果展示。

如图3B-图5所示，服务端可以为接收并处理用户支付请求的金融企业后台服务器，如图3A所示，服务端300可以包括五个模块：PC端支付处理模块310、加解密模块320、协议管理模块330、移动端支付处理模块340、消息通知模块350。

其中，PC端支付处理模块310主要是接收并处理用户在PC端发起的支付请求，查询用户是否签订转移支付协议，调用加解密模块320解密协议管理模块330的协议信息，查询用户转移支付协议，处理支付请求，调用移动端支付处理模块340转移支付请求，展示并同步支付处理结果。

加解密模块320主要对转移支付协议进行SM4加解密处理。

协议管理模块330主要存储并管理用户签订的转移支付协议。

消息通知模块350主要是支持定制转移支付消息通知，通过移动端设备提示用户可通过移动端进行支付；

移动端支付处理模块340主要是接收PC端支付处理模块310转移来的支付请求，调用消息通知模块350提示用户可在移动端支付，调用加解密模块320解密查询用户转移支付协议并判断、处理用户在移动端的支付请求，展示并同步支付处理结果。

如图3B-图5所示，在本公开实施例中，具体以将基于某商业银行服务端的PC端的支付交易转移至移动端，并支持双端并行支付为例作更为详尽的说明如下。其中，商业银行服务端可拓展至任意支付机构的服务端，PC端支付可拓展至任意非便携移动支付终端。

在本公开实施例中涉及转移支付场景主要包括签订协议场景(如图3B所示)、补充协议场景(如图3C所示)以及两种具体支付场景，该两种具体支付场景可以包括如图4所示第一支付场景和如图5所示第二支付场景。

其中，第一支付场景为用户签订转移支付协议，在PC端选择商业银行服务端支付，选择通过PC端完成支付并获取支付结果，移动端同步也会收到支付消息和支付结果通知；第二支付场景则为用户签订转移支付协议，在PC端选择商业银行服务端支付，选择通过移动端完成支付，PC端同步会收到并展示支付结果。

如图3B所示，根据本公开的实施例，在操作S201所述根据接收的第一设备端的转移支付请求，查询预存储的转移支付协议之前，还包括：

根据接收的业务绑定请求，上传终端设备信息；

根据所述终端设备信息和用户身份信息生成所述转移支付协议。

如图3B所示，通过签订转移支付协议场景实现对转移支付协议的生成，实现通过服务端将用户个人信息和第二设备端、第一设备端的信息绑定的过程，具体包括操作S31-S34。

在操作S31中，通过PC端和移动端所具有的服务端的应用程序或应用界面提供专用于转移支付的用户交互界面，使得用户能够借助于PC端或移动端的交互界面向服务端发送业务绑定请求。其中，该业务绑定请求为能够调用转移支付协议签订功能的请求指令，使得服务端可以借助于PC端或移动端向用户推送协议签订页面，使得用户可以在移动端或PC端的支付过程中实现签订转移支付协议。

在操作S32中，在转移支付协议过程中，用户还可以通过PC端或移动端的应用程序或应用界面直接上传用户身份信息和第二设备端的终端设备信息，其中用户身份信息为用户的个人信息，包括用户的姓名、身份证号码(客户三要素)、手机号以及其他与用户个人身份相关的信息，终端设备信息可以包括第一设备端和/或第二设备端的设备身份信息，如可信设备序列号IMEI或者设备MAC地址信息等。

其中，上述的用户个人信息可以包括手机号，手机号可以作为识别用户身份的主要工具。为避免输错手机号对其他用户造成打扰，同时兼顾减少用户在PC端的操作，在PC端上首次使用转移支付功能，需要验证移动端短信验证码，用户同意将PC设备加入常用设备后，系统将PC端设备的MAC地址信息补充进转移支付协议，后续识别身份时仅需输入手机号。也可以拓展为首次转移支付过程需要二次验证，非首次转移支付则只需要输入基本信息。

其中，在本公开的实施例的上述操作S31和操作S32中，在获取用户的信息之前，可以获得用户的同意或授权。例如，在操作S32之前，可以向用户发出获取用户信息的请求。在用户同意或授权可以获取用户信息的情况下，执行所述操作S32。

如图3B所示，根据本公开的实施例，在所述根据所述终端设备信息和用户身份信息生成所述转移支付协议中，包括；

加密所述终端设备信息和用户身份信息生成支付协议信息；

存储所述支付协议信息生成所述转移支付协议。

如图3B所示，在操作S33中，可以通过加解密模块对上传的包括终端设备信息和用户身份信息的协议信息进行sm4加密处理，生成协议加密文件。

在操作S34中，进一步可以通过协议管理模块存储上述加密后的协议信息的加密文件，生成转移支付协议。可见，转移支付协议可以为经加密之后至少具有终端设备信息和用户身份信息的存储数据文件。

其中，在本公开的实施例中，在获取用户的信息之前，可以获得用户的同意或授权。具体，可以向用户发出获取用户信息的请求。在用户同意或授权可以获取用户信息的情况下，执行相应的后续操作。

如图4和图5所示，根据本公开的实施例，在操作S201所述根据接收的第一设备端的转移支付请求，查询预存储的转移支付协议中，包括：

根据所述转移支付请求获取用户登陆信息；

根据所述用户登陆信息查询所述转移支付协议。

在操作S401和操作S501中，用户在PC端消费，选择商业银行的服务端进行支付，此时可以生成自PC端向服务端发送的转移支付请求；

在操作S402和操作S502中，基于该转移支付请求，服务端向PC端发送通知，使得用户可以通过PC端的支付界面引导用户输入手机号进行服务端的账户登陆，从而获取用户对服务端的账户登录内容，如账户名、账户号、姓名、身份证号码、手机号等作为用户登陆信息。

在操作S403和操作S503中，商业银行服务端的PC端支付处理模块获取用户登陆信息的手机号(MOB)，并调用协议管理模块查询服务端数据库是否存在该用户登录信息相匹配的转移支付协议，即确定用户是否签订转移支付协议(AGR)。

在本公开的实施例中，在获取用户的信息之前，可以获得用户的同意或授权。例如，在操作操作S402和操作S502之前，可以向用户发出获取用户信息的请求。在用户同意或授权可以获取用户信息的情况下，执行所述操作操作S402和操作S502。

如图4和图5所示，根据本公开的实施例，在所述根据所述用户登陆信息查询所述转移支付协议中，包括：

根据用户登录信息获取协议查询结果；

根据所述协议查询结果确定所述转移支付协议。

在操作S404和操作S504中，服务端的协议管理模块可以基于用户登录信息的手机号(MOB)查询服务端数据库中所存储的转移支付协议，并反馈查询结果作为协议查询结果。其中，该协议查询结果可以是转移支付协议本身(即确认已签订协议，否则确认未签订协议)，也可以直接是“已有协议”或“尚无协议”的反馈指令结果，例如在确认用户已经签订转移支付协议(AGR)并向PC端支付处理模块返回结果AGR＝1(若签订则AGR＝1，如未签订则AGR＝0)。

如此，便可以实现对转移支付协议直接确认，若该转移支付协议在该服务端的数据库中存在，可以直接实现对转移支付协议的调取处理，便捷高效。

如图4和图5所示，根据本公开的实施例，在所述操作S202解析所述转移支付协议生成确认支付请求中，包括：

解密所述转移支付协议生成第一协议状态；

根据所述第一协议状态生成所述确认支付请求。

在操作S405和操作S505中，商业银行服务端PC端支付处理模块收到已签订转移支付协议的结果，一方面可以通知前端继续支持用户通过PC端进行支付，如操作S406-S408，同时另一方面还可以支持走移动端的支付转移处理流程，如操作S451-在操作S457；

在操作S451中，，商业银行服务端的PC端支付处理模块可以调取所获取的转移支付协议，并调用加解密模块解密转移支付协议(亦可以参照图5所示操作S506)，确认协议信息内容；，得到转移支付协议的第一协议状态。其中，该第一协议状态为该转移支付协议的当前阶段下的可用或不可用状态的信息内容，如转移支付功能冻结的特殊情况下，默认该转移支付协议的状态为不可用状态，此时后续转移支付功能的流程将无法进行。

如图4和图5所示，根据本公开的实施例，在所述根据所述第一协议状态生成所述确认支付请求中，包括：

根据所述第一协议状态识别所述转移支付请求中关于所述第一设备端的设备使用信息；

基于所述设备使用信息生成所述确认支付请求。

为了防止用户在他人移动设备上登陆过商业银行移动用户端，而将转移支付消息发到他人移动设备，造成消息打扰，或者避免可信设备不一致，在PC端发起支付请求时和转移移动端发起支付请求时解密转移支付协议，并根据转移支付协议判断用户可信设备的设备使用信息，如第一设备端的IMEI信息。

具体地，如图4所示，在操作S452和操作S507中，服务端的协议管理模块返回协议状态以及可信设备IMEI等信息。在确认转移支付协议的第一协议状态时，可以进一步基于第一协议状态来判断该转移支付协议的有效性，如第一协议状态为可用状态，则进一步识别该转移支付请求中的PC端的设备信息，如设备型号、设备MAC地址信息等，也即获取第一设备端的设备使用信息。

在操作S453和操作S508中，服务端的PC端支付处理模块判断协议有效。若上述第一协议状态的状态处于可用状态，同时其所获取的设备使用信息能够和转移支付协议中绑定的设备信息能够相匹配，则可以判断该协议有效，否则无效。

在操作S454中，在上述转移支付协议有效的情况下，服务端的PC端支付处理模块可以调用移动端支付处理模块生成确认支付请求，以进一步实现后续的转移支付进程。其中，该确认支付请求为上述转移支付协议有效的情况下生成的用于请求继续执行转移支付进程的请求指令，如为具体的指令代码，在被调用时可以进一步实现对转移支付进程的后续执行。

在操作S455中，服务端的移动端支付处理模块可以接收该确认支付请求；

在操作S456和操作S509中，根据该确认支付请求的执行，可以进一步调用消息通知模块向用户移动端生成并发送可移动支付的消息提示。

在操作S457和操作S510中，根据服务端的消息通知模块所发送的提示消息内容，作为第二设备端的用户移动端可以直接并调用前端向用户提示支付信息或者支付界面。

进一步地，如图5所示，在操作S581中，确认上述转移支付协议有效的情况下，服务端的PC端支付处理模块可以将确认支付请求发送至移动端支付处理模块，启动移动端转移支付的支付进程。

另一方面，在操作S406和操作S582中，无论上述转移支付协议是否有效，均可以在转移支付实施之前，通过PC端支付处理模块通知PC端引导用户支付或者在协议无效的情况下直接反馈至PC端并基于PC端完成支付，实现基于PC端的支付过程，也即放弃转移支付的进程。换言之，本公开实施例的转移支付方法可以有效地保证用户对PC端支付和转移至移动端支付的双端支付的选择权，从而极大改善用户体验。

如图3C、图4和图5所示，根据本公开的实施例，在所述基于所述设备使用信息生成所述确认支付请求中，还包括：

根据所述设备使用信息更新所述转移支付协议。

在本公开实施例中，若解密转移支付协议所获取的设备使用信息存在问题，例如设备地址信息(MAC地址信息)不匹配甚至设备型号不匹配等，则说明当前用户所登录使用并发送转移支付请求的第二设备端并非转移支付协议中所绑定的设备，存在设备安全性问题。为确保后续支付进程的安全性，需要对转移支付协议中涉及的设备使用信息根据当前使用PC端设备作进一步的更新。

具体地，如图3C所示，在操作S301中，用户通过PC端选择商业银行服务端进行支付。

在操作S302中，PC端相互用户提供支付界面引导用户输入手机号登陆。

在操作S303中，服务端的PC端支付处理模块可以获取用户登陆信息手机号(MOB)，并调用协议管理模块查询用户是否签订转移支付协议(AGR)；

在操作S304中，商业银行服务端的协议管理模块基于用户手机号(MOB)确认用户已签订转移支付协议(AGR)并向PC端支付处理模块返回结果AGR＝1(如签订则AGR＝1，如未签订则AGR＝0)，同时可以确认该转移支付协议的第一协议状态为可用状态。

在操作S305中，服务端的PC端支付处理模块可以确认用户已签订转移支付协议。

在操作S306中，服务端的加解密模块可以解密转移支付协议，确认转移支付协议中绑定的设备使用信息，可以确定用户已绑定的PC端设备、移动端设备，其中默认该PC端设备可以为常用设备，并确认该PC端设备的具体信息，如设备名称、设备型号、设备地址信息等。

在操作S307中，服务端的协议管理模块可以进一步根据上述转移支付协议所获取的设备使用信息，查询与用户当前使用PC端信息是否匹配，若返回PC端设备信息与协议中的设备使用信息不匹配，则该当前使用PC端为不非常用设备，其安全性待验证。

在操作S308中，服务端的PC端支付处理模块可以通知当前PC端通过前端引导用户使用移动端的验证短信验证码执行对当前PC端的二次认证。

在操作S309中，PC端通过向用户提供支付界面来引导用户输入短信验证码以同意授权PC端为常用设备。

在操作S310，服务端的PC端支付处理模块可以直接获取并上送该当前PC端的设备信息(如MAC信息)；

在操作S311中，服务端的加解密模块可以对上述上传的设备信息进行加密生成新的加密协议文件；

在操作S312中，服务端的协议管理模块可以将上述加密协议文件作为已有转移支付协议的补充文件进行存储，从而实现对转移支付协议的更新，将当前PC端的设备信息也通过上述二次认证的方式绑定在转移支付协议中作为常用设备MAC信息。

其中，在本公开的实施例中，在获取用户的信息之前，可以获得用户的同意或授权。例如，在操作S302、303和307之前，可以向用户发出获取用户信息的请求。在用户同意或授权可以获取用户信息的情况下，执行所述操作S302、303和307。

如图4和图5所示，根据本公开的实施例，在所述操作S202解析所述转移支付协议生成确认支付请求中，还包括：

解析所述转移支付协议生成转移支付消息；

根据接收的第二设备端响应于所述转移支付消息发送的确认支付消息生成所述确认支付请求。

在解析转移支付协议之后，可以在确定该转移支付协议的第一协议状态为可用状态，且其设备信息与当前使用PC端设备信息匹配的情况下，确认该转移支付协议有效，此时可以将转移支付请求直接转达至移动端支付处理模块进行处理，并通过消息通知模块响应于该转移支付请求生成向移动端发送的转移支付消息。该转移支付消息为用于向移动端进行发送向用户提示可以继续进行转移支付的信息，具体可以使得移动端在处理该消息之后能够弹出提示框或者提示交互界面等。

如图5所示，在操作S511中，移动端可以响应于转移支付消息通过弹出交互界面或通知消息等提示用户可通过移动端完成支付。

在操作S512，用户通过移动端的交互界面或者通知消息的反馈来选择是否继续进行移动端的转移支付。若用户确认转移支付，则可以通过移动端向服务端发送确认支付请求，该确认支付请求为用于向服务端表明继续执行转移支付的请求指令。

如图4和图5所示，根据本公开的实施例，在所述操作S203根据所述确认支付请求和所述转移支付协议生成支付执行任务中，包括：

根据所述确认支付请求解密所述转移支付协议，生成第二协议状态；

根据所述第二协议状态生成支付执行任务；

发送所述支付执行任务至所述第二设备端。

如图5所示，在操作S513中，在接收到来自移动端的确认支付请求之后，通过服务端的移动端支付处理模块可以再次调用转移支付协议。

进一步地，在操作S514中，服务端的加解密模块再次解密转移支付协议，重新确认协议信息内容；

在操作S515中，服务端的协议管理模块返回协议状态作为第二协议状态，并重新确认该第二协议状态是否为可用状态或非可用状态，同时可以确认该转移支付协议中所绑定的可信设备信息，如PC端和移动端的绑定设备信息。

在操作S516，服务端的移动端支付处理模块可以进一步判断从服务端登录所检测获取的当前使用的移动端设备信息与解密确认的转移支付协议中绑定的可信移动设备信息(如设备序列号IMEI)是否一致。其中，若信息不一致则进一步执行操作S5171，即直接向移动端发送提示，告知用户不支持转移支付，并请用户继续选择PC端支付，若信息一致则进一步执行操作S5172，提示用户支持转移支付，并通过移动端支付引导功能引导用户完成支付过程。

其中，在操作S5172中，可以根据上述第二协议状态的内容生成支付执行任务，该支付执行任务为服务端产生并发送至移动端的可执行任务，在该移动端接收到该支付执行任务时，可以实现后续的支付过程，从而完成整个转移支付的过程。其中，该支付执行任务可以是一具体的处理器可执行指令序列。

如图4和图5所示，根据本公开的实施例，所述的转移支付方法还包括：

接收所述第二设备端执行所述支付执行任务生成的支付完成消息；

根据所述支付完成消息生成支付结果通知以发送至所述第一设备端和第二设备端。

为减少用户操作步骤，同时支持用户不同的支付习惯，若用户已签订转移支付协议且有绑定的可信移动端设备，则可以同时支持用户继续PC端支付或者移动端支付，无论在PC端页面还是移动端页面上用户均无需做选择操作，而通过线程扫描保障两端的支付结果通知互通，且均在响应设备端的前端为用户展示。

其中，消息通知模块可以实现服务端向PC端和移动端的应用软件或应用网页等推送通知的功能，支持按照功能定制通知，比如可仅支持转移支付消息通知，而不允许其他通知。若用户签订转移支付协议则必须同步开通转移支付消息提醒。

具体地，在操作S5171中，移动端接收消息提示用户此次不支持转移支付，则转移支付功能中止，用户仅能继续操作PC端完成支付过程。在操作S5172中，移动端接收消息提示用户此次可以支持转移支付，则移动端可以接收服务端生成的支付执行任务，并基于服务端的支付功能完成该支付执行任务的执行，实现支付，同时生成支付完成消息。其中，支付完成消息为支付执行任务完成执行之后产生的信息，具体可以是“success”或“fail”，也可以是对应“success”或“fail”的具体代码。

通过该支付完成消息可以生成支付结果通知发送至设备端完成整个转移支付过程。其中，该支付结果通知某些情况下可以是上述支付完成消息本身，一般而言支付结果通知是对该支付执行过程过程的反馈信息，其具体可以是对应“success”或“fail”的文字内容或图片信息，如“支付成功”或“支付失败”的文字内容或表情图片等。

具体地，在操作S406中，PC端可以提供支付界面支持用户继续支付验签，完成支付。

在操作S407中，服务端的PC端支付处理模块对PC端的继续支付请求进行处理。具体地，在操作S471中，服务端的移动端支付处理模块可以线程轮询支付结果，并通知移动端的前端展示；在操作S472中，移动端可以提示用户支付结果。

在操作S408中，PC端的支付界面也可以根据服务端发送的支付完成消息展示支付结果。

在本公开的另一实施例中，如图5所示，在操作S5 1 8中，服务端的移动端支付处理模块处理支付请求，并向移动端和PC端支付管理模块通知支付结果；具体地，在操作S5181中，移动端可以接收支付结果通知展示支付结果；在操作S5182中，服务端的PC端支付处理模块可以通过线程轮询支付状态，并通知PC端的前端展示支付结果。在操作S519中，PC端支付界面可以根据支付结果通知展示支付结果。

需要说明的是，本公开实施例中的上述转移支付方法，具体是将基于商业银行服务端的PC端支付交易转移至移动端实现支付，并支持双端并行支付，其中商业银行可拓展至任意支付机构，PC端支付可拓展至任意非移动支付终端。此外，其中，在本公开的实施例中，在获取用户的信息之前，可以获得用户的同意或授权，在用户同意或授权可以获取用户信息的情况下，执行后续的操作内容。

综上，如图3C-图5所示，用户在商业银行PC端支付界面输入个人信息(手机号)发起支付请求，服务端的PC端支付处理模块获取用户个人信息(手机号)；然后调用协议管理模块判断用户是否签订转移支付协议，如未签订则走传统PC端支付处理流程，若已签订则调用加解密模块对协议管理模块的转移支付协议进行解密，判断是否需要用户二次验证(该PC终端是常用设备无需二次验证，不是常用设备需要二次验证)；然后查询用户协议信息，包括转移支付协议状态是否正常、是否绑定可信设备IMEI等，若转移支付协议状态不正常或未绑定可信设备IMEI，则引导用户继续通过PC端完成支付交易，若转移支付协议状态正常且已绑定可信设备IMEI，则前端提示可通过可信移动支付设备继续完成支付，同时调用移动端支付处理模块通知支付请求；移动端支付处理模块调用消息通知模块通过移动设备提示用户进行支付，用户若选择通过移动端支付，移动端支付处理模块调用加解密模块对协议管理模块的转移支付协议进行解密，判断从移动设备获取的可信设备IMEI与协议中可信设备IMEI是否一致，若不一致则提示无法通过移动端支付，若一致则处理支付请求，同步通知PC端支付处理模块支付结果，移动端APP和PC端支付界面为用户展示支付结果。

因此，为了解决非移动终端支付安全和便捷性不可兼得的问题，本公开实施例提供了一种任意终端支付交易转移至移动端，并支持双端并行支付的支付方案，使得当用户在非移动终端发起支付交易时，非移动终端获取用户信息，查询用户转移支付协议、可信设备等，转移用户支付请求至移动端，移动支付设备提示用户进行支付，同时支持用户通过PC端或移动端完成支付，两端共享支付结果。因此，能够兼顾用户支付的便捷性和安全性，显著提高了PC端支付的效率，同时也极大地改善了用户支付体验。

基于上述转移支付方法，本公开还提供了一种转移支付装置。以下将结合图6对该装置进行详细描述。

图6示意性示出了根据本公开实施例的转移支付装置600的结构框图。

如图6所示，该实施例的转移支付装置600包括协议查询模块610、解析生成模块620和支付执行模块630。

协议查询模块610用于根据接收的第一设备端的转移支付请求，查询预存储的转移支付协议。在一实施例中，协议查询模块610可以用于执行前文描述的操作S201，在此不再赘述。

解析生成模块620用于解析所述转移支付协议生成确认支付请求。在一实施例中，解析生成模块620可以用于执行前文描述的操作S202，在此不再赘述。

支付执行模块630用于根据所述确认支付请求和所述转移支付协议生成支付执行任务，并通过第二设备端执行所述支付执行任务以完成所述转移支付。在一实施例中，支付执行模块630可以用于执行前文描述的操作S203，在此不再赘述。

根据本公开的实施例，协议查询模块610、解析生成模块620和支付执行模块630中的任意多个模块可以合并在一个模块中实现，或者其中的任意一个模块可以被拆分成多个模块。或者，这些模块中的一个或多个模块的至少部分功能可以与其他模块的至少部分功能相结合，并在一个模块中实现。根据本公开的实施例，协议查询模块610、解析生成模块620和支付执行模块630中的至少一个可以至少被部分地实现为硬件电路，例如现场可编程门阵列(FPGA)、可编程逻辑阵列(PLA)、片上系统、基板上的系统、封装上的系统、专用集成电路(ASIC)，或可以通过对电路进行集成或封装的任何其他的合理方式等硬件或固件来实现，或以软件、硬件以及固件三种实现方式中任意一种或以其中任意几种的适当组合来实现。或者，协议查询模块610、解析生成模块620和支付执行模块630中的至少一个可以至少被部分地实现为计算机程序模块，当该计算机程序模块被运行时，可以执行相应的功能。

图7示意性示出了根据本公开实施例的适于实现转移支付方法的电子设备的方框图。

如图7所示，根据本公开实施例的电子设备700包括处理器701，其可以根据存储在只读存储器(ROM)702中的程序或者从存储部分708加载到随机访问存储器(RAM)703中的程序而执行各种适当的动作和处理。处理器701例如可以包括通用微处理器(例如CPU)、指令集处理器和/或相关芯片组和/或专用微处理器(例如，专用集成电路(ASIC))等等。处理器701还可以包括用于缓存用途的板载存储器。处理器701可以包括用于执行根据本公开实施例的方法流程的不同动作的单一处理单元或者是多个处理单元。

在RAM 703中，存储有电子设备700操作所需的各种程序和数据。处理器701、ROM702以及RAM 703通过总线704彼此相连。处理器701通过执行ROM 702和/或RAM 703中的程序来执行根据本公开实施例的方法流程的各种操作。需要注意，所述程序也可以存储在除ROM 702和RAM 703以外的一个或多个存储器中。处理器701也可以通过执行存储在所述一个或多个存储器中的程序来执行根据本公开实施例的方法流程的各种操作。

根据本公开的实施例，电子设备700还可以包括输入/输出(I/O)接口705，输入/输出(I/O)接口705也连接至总线704。电子设备700还可以包括连接至I/O接口705的以下部件中的一项或多项：包括键盘、鼠标等的输入部分706；包括诸如阴极射线管(CRT)、液晶显示器(LCD)等以及扬声器等的输出部分707；包括硬盘等的存储部分708；以及包括诸如LAN卡、调制解调器等的网络接口卡的通信部分709。通信部分709经由诸如因特网的网络执行通信处理。驱动器710也根据需要连接至I/O接口705。可拆卸介质711，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器710上，以便于从其上读出的计算机程序根据需要被安装入存储部分708。

本公开还提供了一种计算机可读存储介质，该计算机可读存储介质可以是上述实施例中描述的设备/装置/系统中所包含的；也可以是单独存在，而未装配入该设备/装置/系统中。上述计算机可读存储介质承载有一个或者多个程序，当上述一个或者多个程序被执行时，实现根据本公开实施例的方法。

根据本公开的实施例，计算机可读存储介质可以是非易失性的计算机可读存储介质，例如可以包括但不限于：便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本公开中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。例如，根据本公开的实施例，计算机可读存储介质可以包括上文描述的ROM 702和/或RAM 703和/或ROM 702和RAM 703以外的一个或多个存储器。

本公开的实施例还包括一种计算机程序产品，其包括计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。当计算机程序产品在计算机系统中运行时，该程序代码用于使计算机系统实现本公开实施例所提供的方法。

在该计算机程序被处理器701执行时执行本公开实施例的系统/装置中限定的上述功能。根据本公开的实施例，上文描述的系统、装置、模块、单元等可以通过计算机程序模块来实现。

在一种实施例中，该计算机程序可以依托于光存储器件、磁存储器件等有形存储介质。在另一种实施例中，该计算机程序也可以在网络介质上以信号的形式进行传输、分发，并通过通信部分709被下载和安装，和/或从可拆卸介质711被安装。该计算机程序包含的程序代码可以用任何适当的网络介质传输，包括但不限于：无线、有线等等，或者上述的任意合适的组合。

在这样的实施例中，该计算机程序可以通过通信部分709从网络上被下载和安装，和/或从可拆卸介质711被安装。在该计算机程序被处理器701执行时，执行本公开实施例的系统中限定的上述功能。根据本公开的实施例，上文描述的系统、设备、装置、模块、单元等可以通过计算机程序模块来实现。

根据本公开的实施例，可以以一种或多种程序设计语言的任意组合来编写用于执行本公开实施例提供的计算机程序的程序代码，具体地，可以利用高级过程和/或面向对象的编程语言、和/或汇编/机器语言来实施这些计算程序。程序设计语言包括但不限于诸如Java，C++，python，“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算设备上执行、部分地在用户设备上执行、部分在远程计算设备上执行、或者完全在远程计算设备或服务器上执行。在涉及远程计算设备的情形中，远程计算设备可以通过任意种类的网络，包括局域网(LAN)或广域网(WAN)，连接到用户计算设备，或者，可以连接到外部计算设备(例如利用因特网服务提供商来通过因特网连接)。

附图中的流程图和框图，图示了按照本公开各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图或流程图中的每个方框、以及框图或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

本领域技术人员可以理解，本公开的各个实施例和/或权利要求中记载的特征可以进行多种组合或/或结合，即使这样的组合或结合没有明确记载于本公开中。特别地，在不脱离本公开精神和教导的情况下，本公开的各个实施例和/或权利要求中记载的特征可以进行多种组合和/或结合。所有这些组合和/或结合均落入本公开的范围。

以上对本公开的实施例进行了描述。但是，这些实施例仅仅是为了说明的目的，而并非为了限制本公开的范围。尽管在以上分别描述了各实施例，但是这并不意味着各个实施例中的措施不能有利地结合使用。本公开的范围由所附权利要求及其等同物限定。不脱离本公开的范围，本领域技术人员可以做出多种替代和修改，这些替代和修改都应落在本公开的范围之内。

Claims (15)

1.一种转移支付方法，其中，包括：

根据接收的第一设备端的转移支付请求，查询预存储的转移支付协议；

解析所述转移支付协议生成确认支付请求；以及

根据所述确认支付请求和所述转移支付协议生成支付执行任务，并通过第二设备端执行所述支付执行任务以完成所述转移支付。

2.根据权利要求1所述的方法，其中，在所述根据接收的第一设备端的转移支付请求，查询预存储的转移支付协议之前，还包括：

根据接收的业务绑定请求，上传终端设备信息；

根据所述终端设备信息和用户身份信息生成所述转移支付协议。

3.根据权利要求2所述的方法，其中，在所述根据所述终端设备信息和用户身份信息生成所述转移支付协议中，包括；

加密所述终端设备信息和用户身份信息生成支付协议信息；

存储所述支付协议信息生成所述转移支付协议。

4.根据权利要求1所述的方法，其中，在所述根据接收的第一设备端的转移支付请求，查询预存储的转移支付协议中，包括：

根据所述转移支付请求获取用户登陆信息；

根据所述用户登陆信息查询所述转移支付协议。

5.根据权利要求4所述的方法，其中，在所述根据所述用户登陆信息查询所述转移支付协议中，包括：

根据用户登录信息获取协议查询结果；

根据所述协议查询结果确定所述转移支付协议。

6.根据权利要求1所述的方法，其中，在所述解析所述转移支付协议生成确认支付请求中，包括：

解密所述转移支付协议生成第一协议状态；

根据所述第一协议状态生成所述确认支付请求。

7.根据权利要求6所述的方法，其中，在所述根据所述第一协议状态生成所述确认支付请求中，包括：

根据所述第一协议状态识别所述转移支付请求中关于所述第一设备端的设备使用信息；

基于所述设备使用信息生成所述确认支付请求。

8.根据权利要求7所述的方法，其中，在所述基于所述设备使用信息生成所述确认支付请求中，还包括：

根据所述设备使用信息更新所述转移支付协议。

9.根据权利要求1所述的方法，其中，在所述解析所述转移支付协议生成确认支付请求中，还包括：

解析所述转移支付协议生成转移支付消息；

根据接收的第二设备端响应于所述转移支付消息发送的确认支付消息生成所述确认支付请求。

10.根据权利要求1所述的方法，其中，在所述根据所述确认支付请求和所述转移支付协议生成支付执行任务中，包括：

根据所述确认支付请求解密所述转移支付协议，生成第二协议状态；

根据所述第二协议状态生成支付执行任务；

发送所述支付执行任务至所述第二设备端。

11.根据权利要求1所述的方法，其中，还包括：

接收所述第二设备端执行所述支付执行任务生成的支付完成消息；

根据所述支付完成消息生成支付结果通知以发送至所述第一设备端和第二设备端。

12.一种转移支付装置，其中，包括：

协议查询模块，用于根据接收的第一设备端的转移支付请求，查询预存储的转移支付协议；

解析生成模块，用于解析所述转移支付协议生成确认支付请求；以及

支付执行模块，用于根据所述确认支付请求和所述转移支付协议生成支付执行任务，并通过第二设备端执行所述支付执行任务以完成所述转移支付。

13.一种电子设备，包括：

一个或多个处理器；

存储装置，用于存储一个或多个程序，

其中，当所述一个或多个程序被所述一个或多个处理器执行时，使得所述一个或多个处理器执行根据权利要求1～11中任一项所述的方法。

14.一种计算机可读存储介质，其上存储有可执行指令，该指令被处理器执行时使处理器执行根据权利要求1～11中任一项所述的方法。

15.一种计算机程序产品，包括计算机程序，所述计算机程序被处理器执行时实现根据权利要求1～11中任一项所述的方法。

Images