CN112785380B - 交易处理方法及装置 - Google Patents

Abstract

本申请提供了一种交易处理方法及装置，可用于金融领域或其他领域，该交易处理方法包括：接收多个电子商务网站各自对应的订单支付信息并存储；若接收到财务登录请求，则根据该财务登录请求对应的第一采购码，输出该财务登录请求对应的订单支付信息，作为待处理订单支付信息；若接收到所述待处理订单支付信息对应的签名支付请求，则执行该签名支付请求对应的交易处理。本申请能够实现对多个电子商务网站的订单信息统一处理，提高交易处理的效率和准确性，进而能够有效提高交易处理的安全性。

Description

交易处理方法及装置

技术领域

本申请涉及数据处理技术领域，尤其涉及一种交易处理方法及装置。

背景技术

随着互联网技术的高速发展，许多企业在线上电子商务网站寻找合适的原材料进行采购，一般的电子商务网站会要求在采购下单后，一定时间限制内完成订单支付，但是采购人员却没有银行操作的相关权限，现有技术中，为了实现采购财务角色分离，部分电子商务网站会给财务人员也分配用户，让财务人员可以对采购人员的下单完成支付，但是采购人员往往会在多个电子商务网站下单，且非所有的电子商务网站都能够支持采购与财务角色分离，即便能够支持创建不同角色的用户，财务人员需要管理多个电子商务网站用户，无形增加财务人员负担，无法真正实现采购与财务角色分离。

随着企业业务高速发展和内控管理规范，线上企业电子商务交易越来越普及，实现采购与财务角色分离愈发必要。

发明内容

针对现有技术中的问题，本申请提出了一种交易处理方法及装置，能够实现对多个电子商务网站的订单信息统一处理，提高交易处理的效率和准确性，进而能够有效提高交易的安全性。

为了解决上述技术问题，本申请提供以下技术方案：

第一方面，本申请提供一种交易处理方法，包括：

接收多个电子商务网站各自对应的订单支付信息并存储；

若接收到财务登录请求，则根据该财务登录请求对应的第一采购码，输出该财务登录请求对应的订单支付信息，作为待处理订单支付信息；

若接收到所述待处理订单支付信息对应的签名支付请求，则执行该签名支付请求对应的交易处理。

进一步地，所述接收多个电子商务网站各自对应的订单支付信息并存储，包括：

接收多个电子商务网站各自对应的订单支付信息，该订单支付信息包括：第二采购码、订单金额、第一采购人员信息和订单生成时间；

根据所述第二采购码得到其对应的采购码信息，该采购码信息包括：第二采购人员信息、采购码有效期、采购码单笔限额、采购码日累计限额、采购码月累计限额、已使用次数、支持使用次数、日累计订单金额和月累计订单金额；

若存在所述第一采购人员信息与第二采购人员信息相同，所述订单生成时间在所述采购码有效期内，所述已使用次数加1不大于所述支持使用次数，所述订单金额不大于采购码单笔限额，所述订单金额和日累计订单金额之和不大于所述采购码日累计限额，以及所述订单金额和月累计订单金额之和不大于所述采购码月累计限额的订单支付信息，则存储该订单支付信息。

进一步地，所述若接收到所述待处理订单支付信息对应的签名支付请求，则执行该签名支付请求对应的交易处理，包括：

若接收到所述待处理订单支付信息对应的签名支付请求，则获取该签名支付请求对应的可直接支付限额；

若所述签名支付请求对应的可直接支付限额大于所述待处理订单支付信息中的订单金额，则执行该待处理订单支付信息对应的交易处理。

进一步地，在所述获取该签名支付请求对应的可直接支付限额之后，还包括：

若所述可直接支付限额不大于所述待处理订单支付信息中的订单金额，则根据所述待处理订单支付信息确定其对应的多级可授权限额；

若各级可授权限额均大于所述订单金额，则依次执行所述签名支付请求的批复操作和交易处理。

进一步地，在所述接收多个电子商务网站各自对应的订单支付信息并存储之前，还包括：

生成多个不同的第二采购码并设置各个第二采购码各自对应的采购码信息；

将各个第二采购码发送至各自对应的采购人员的终端设备。

第二方面，本申请提供一种交易处理装置，包括：

接收模块，用于接收多个电子商务网站各自对应的订单支付信息并存储；

输出模块，用于若接收到财务登录请求，则根据该财务登录请求对应的第一采购码，输出该财务登录请求对应的订单支付信息，作为待处理订单支付信息；

交易处理模块，用于若接收到所述待处理订单支付信息对应的签名支付请求，则执行该签名支付请求对应的交易处理。

进一步地，所述接收模块包括：

接收单元，用于接收多个电子商务网站各自对应的订单支付信息，该订单支付信息包括：第二采购码、订单金额、第一采购人员信息和订单生成时间；

判断单元，用于根据所述第二采购码得到其对应的采购码信息，该采购码信息包括：第二采购人员信息、采购码有效期、采购码单笔限额、采购码日累计限额、采购码月累计限额、已使用次数、支持使用次数、日累计订单金额和月累计订单金额；

存储单元，用于若存在所述第一采购人员信息与第二采购人员信息相同，所述订单生成时间在所述采购码有效期内，所述已使用次数加1不大于所述支持使用次数，所述订单金额不大于采购码单笔限额，所述订单金额和日累计订单金额之和不大于所述采购码日累计限额，以及所述订单金额和月累计订单金额之和不大于所述采购码月累计限额的订单支付信息，则存储该订单支付信息。

进一步地，所述交易处理模块，包括：

获取单元，用于若接收到所述待处理订单支付信息对应的签名支付请求，则获取该签名支付请求对应的可直接支付限额；

处理单元，用于若所述签名支付请求对应的可直接支付限额大于所述待处理订单支付信息中的订单金额，则执行该待处理订单支付信息对应的交易处理。

第三方面，本申请提供一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现所述的交易处理方法。

第四方面，本申请提供一种计算机可读存储介质，其上存储有计算机指令，所述指令被执行时实现所述的交易处理方法。

由上述技术方案可知，本申请提供一种交易处理方法及装置。其中，该方法包括：接收多个电子商务网站各自对应的订单支付信息并存储；若接收到财务登录请求，则根据该财务登录请求对应的第一采购码，输出该财务登录请求对应的订单支付信息，作为待处理订单支付信息；若接收到所述待处理订单支付信息对应的签名支付请求，则执行该签名支付请求对应的交易处理；能够实现对多个电子商务网站交易的统一处理，提高交易处理的效率和准确性，进而能够有效提高交易的安全性；具体地，能够实现采购人员能够通过采购码完成订单支付，适应当前和未来业务的快速发展，主要有以下优点：(一)采购财务人员只需管理各自的***软件用户，避免了交叉，彻底实现采购财务角色分离。(二)通过预先设置采购码的额度、有效期、使用次数以及持有人，能否根据不同的采购场景签发相应的采购码，灵活配置能否快速支持各类业务发展。(三)按照订单金额的各层级审批控制，能够让采购码订单经过合理的审批人批复，有效控制资金风险。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本申请实施例中交易处理方法的流程示意图；

图2是本申请实施例中交易处理方法步骤111至步骤113的流程示意图；

图3是本申请应用实例中采购码发放过程的流程示意图；

图4是本申请应用实例中企业电子商务网站下单过程的流程示意图；

图5是本申请应用实例中交易处理过程的流程示意图；

图6是本申请实施例中交易处理装置的结构示意图；

图7是本申请应用实例中交易处理装置的结构示意图；

图8为本申请实施例的电子设备9600的***构成示意框图。

具体实施方式

为了使本技术领域的人员更好地理解本说明书中的技术方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

为了实现对多个电子商务网站的订单信息统一处理，提高交易处理的效率和准确性，进而有效提高交易的安全性，本申请实施例提供一种交易处理装置，该装置可以是一服务器或客户端设备，所述客户端设备可以包括智能手机、平板电子设备、网络机顶盒、便携式计算机、台式电脑、个人数字助理(PDA)、车载设备和智能穿戴设备等。其中，所述智能穿戴设备可以包括智能眼镜、智能手表和智能手环等。

在实际应用中，进行交易处理的部分可以在如上述内容所述的服务器侧执行，也可以所有的操作都在所述客户端设备中完成。具体可以根据所述客户端设备的处理能力，以及用户使用场景的限制等进行选择。本申请对此不作限定。若所有的操作都在所述客户端设备中完成，所述客户端设备还可以包括处理器。

上述的客户端设备可以具有通信模块(即通信单元)，可以与远程的服务器进行通信连接，实现与所述服务器的数据传输。所述服务器可以包括任务调度中心一侧的服务器，其他的实施场景中也可以包括中间平台的服务器，例如与任务调度中心服务器有通信链接的第三方服务器平台的服务器。所述的服务器可以包括单台计算机设备，也可以包括多个服务器组成的服务器集群，或者分布式装置的服务器结构。

所述服务器与所述客户端设备之间可以使用任何合适的网络协议进行通信，包括在本申请提交日尚未开发出的网络协议。所述网络协议例如可以包括TCP/IP协议、UDP/IP协议、HTTP协议、HTTPS协议等。当然，所述网络协议例如还可以包括在上述协议之上使用的RPC协议(Remote Procedure Call Protocol，远程过程调用协议)、REST协议(Representational State Transfer，表述性状态转移协议)等。

需要说明的是，本申请公开的交易处理方法及装置可用于金融技术领域，也可用于除金融技术领域之外的任意领域，本申请公开的交易处理方法及装置的应用领域不做限定。

具体通过下述各个实施例进行说明。

为了实现对多个电子商务网站的订单信息统一处理，提高交易处理的效率和准确性，进而有效提高交易的安全性，本实施例提供一种执行主体是交易处理装置的交易处理方法，该交易处理装置包括但不限于服务器，如图1所示，该方法具体包含有如下内容：

步骤100：接收多个电子商务网站各自对应的订单支付信息并存储。

具体地，所述电子商务网站可以是B2B网站，即提供企业对企业间电子商务活动平台的网站。所述订单支付信息可以包含有：订单信息和第二采购码；订单信息可以包含有：采购人员信息、订单金额和订单日期等；第二采购码可以是采购人员输入电子商务网站的采购码，用于获取对应的采购码信息，可以是字符串等。各电子商务网站发送的订单支付信息中的第二采购码可以不同。

进一步地，在步骤100之前，可以具体包含有如下步骤：

电子商务网站接收采购人员的终端设备发送的商品采购下单请求，根据该商品采购下单请求生成B2B订单信息，并向支付机构发起订单支付请求；支付机构接收到电子商务网站提交的订单支付请求，若验证该订单支付请求合法性通过，则向采购人员的终端设备提供付款台页面，若支付机构接收到付款台页面网上支付银行选定信息，向其对应的银行***发送支付请求，所述交易处理装置可以是银行***。

步骤200：若接收到财务登录请求，则根据该财务登录请求对应的第一采购码，输出该财务登录请求对应的订单支付信息，作为待处理订单支付信息。

具体地，可以接收财务人员从前端发送的财务登录请求，该财务登录请求可以包含有：财务人员身份信息，如账号和姓名等；可以从交易处理装置本地得到该财务登录请求对应的财务人员下发的采购码，即上述第一采购码；从各订单支付信息中提取第二采购码与第一采购码相同的订单支付信息，并输出至前端，以供财务人员接下来在前端选择并支付。

步骤300：若接收到所述待处理订单支付信息对应的签名支付请求，则执行该签名支付请求对应的交易处理。

具体地，若存在多条待处理订单支付信息，签名支付请求可以对应一条或多条待处理订单支付信息；所述签名支付请求可以包含有U盾***信息和待处理订单支付信息的选中信息，用于确定执行交易处理的待处理订单支付信息等；执行所述待处理订单支付信息对应的交易处理可以是完成待处理订单支付信息的订单支付。

由上述描述可知，本实施例提供的交易处理方法，通过接收多个电子商务网站各自对应的订单支付信息并存储；若接收到财务登录请求，则根据该财务登录请求对应的第一采购码，输出该财务登录请求对应的订单支付信息，作为待处理订单支付信息；若接收到所述待处理订单支付信息对应的签名支付请求，则执行该签名支付请求对应的交易处理，能够应用采购码提高对多个电子商务网站的订单信息统一处理的效率和准确性，进而有效提高交易的安全性。

为了进一步提高获取订单支付信息的可靠性，参见图2，在本申请一个实施例中，步骤100包括：

步骤111：接收多个电子商务网站各自对应的订单支付信息，该订单支付信息包括：第二采购码、订单金额、第一采购人员信息和订单生成时间。

步骤112：根据所述第二采购码得到其对应的采购码信息，该采购码信息包括：第二采购人员信息、采购码有效期、采购码单笔限额、采购码日累计限额、采购码月累计限额、已使用次数、支持使用次数、日累计订单金额和月累计订单金额。

具体地，可以根据从预先存储在交易处理装置本地的各采购码信息中，得到所述第二采购码对应的采购码信息。

步骤113：若存在所述第一采购人员信息与第二采购人员信息相同，所述订单生成时间在所述采购码有效期内，所述已使用次数加1不大于所述支持使用次数，所述订单金额不大于采购码单笔限额，所述订单金额和日累计订单金额之和不大于所述采购码日累计限额，以及所述订单金额和月累计订单金额之和不大于所述采购码月累计限额的订单支付信息，则存储该订单支付信息。

具体地，所述第一采购人员信息可以为订单支付信息中的采购人员信息，第二采购人员信息可以为根据第二采购码从本地得到的采购码信息中的采购人员信息；在执行成功交易处理之后，可以应用该交易对应的订单支付信息更新采购码信息中的已使用次数、日累计订单金额和月累计订单金额。根据第二采购码和订单支付信息，可以实现订单支付信息筛选，存储有效订单支付信息。

为了进一步提高交易处理的可靠性，在本申请一个实施例中，步骤300包含有：

步骤311：若接收到所述待处理订单支付信息对应的签名支付请求，则获取该签名支付请求对应的可直接支付限额。

具体地，可以根据签名支付请求中的U盾***信息得到可直接支付限额，可以理解的是，各财务人员的U盾对应有各自的可直接支付限额。

步骤312：若所述签名支付请求对应的可直接支付限额大于所述待处理订单支付信息中的订单金额，则执行该待处理订单支付信息对应的交易处理。

为了进一步提高交易处理的可靠性，在本申请一个实施例中，在步骤311之后，还包含有：

步骤321：若所述可直接支付限额不大于所述待处理订单支付信息中的订单金额，则根据所述待处理订单支付信息确定其对应的多级可授权限额。

步骤322：若各级可授权限额均大于所述订单金额，则依次执行所述签名支付请求的批复操作和交易处理。

为了在提高交易处理的效率和准确性的基础上，实现采购码的灵活配置，快速支持各类业务发展，在本申请一个实施例中，在步骤100之前，还包含有：

步骤001：生成第二采购码并设置第二采购码对应的采购码信息。

具体地，可以将第二采购码、采购码信息及两者的对应关系存储在交易处理装置中。

步骤002：将第二采购码发送至对应的采购人员的终端设备。

所述终端设备可以包括：平板电脑、笔记本和手机等。可以生成多个不同的第二采购码并设置各个第二采购码各自对应的采购码信息；将各个第二采购码发送至各自对应的采购人员的终端设备。

为了进一步说明本方案，本申请提供一种交易处理方法的应用实例，具体包含有如下内容：

1)采购码发放，如图3所示，该采购码发放过程包含有：

步骤S001：进入采购码管理菜单；即财务人员登陆银行***，进入采购码管理栏目，栏目首页顶部为查询区，支持发放日期、采购人员、有效期条件组合查询；中部为操作区，操作按钮包括新增、修改、作废、发放操作；下部为采购码记录展示区，支持勾选记录，进行修改、作废、发放操作。

步骤S002：新增采购码；即新增操作，新增页面要求输入采购码的额度、有效期、支持使用次数等信息。额度支付设置单笔支付额度、日累计支付额度、月累计支付额度；有效期默认为30天，最大支持有效期为30天；支持使用次数最少为1次，最多使用次数为5次；保存按钮操作完成采购码新增，取消按钮操作作废本次录入。

步骤S003：勾选采购码；即支持勾选多条采购码记录进行发放、作废操作；修改操作仅支持勾选1条采购码记录。

步骤S004：进行发放|修改|作废操作；即勾选需发放的采购码记录，则进行发放；勾选需修改采购码记录则进行修改操作；勾选需作废采购码记录则进行作废操作。

步骤S005：生成短信发送的指令。

步骤S006：输入采购人员信息；即发放页面要求输入采购人员姓名、性别、证件类型、证件号码和手机号码等信息。

步骤S007：完成采购码发放；即生成待审批发送指令，进入S204步骤，由审核人员对发放的采购信息进行审核并发送。

2)企业电子商务网站下单；如图4所示，企业电子商务网站下单过程包含有：

步骤S101：企业电子商务交易***向支付机构发起订单支付请求；即采购人员在B2B网站进行商品采购下单，企业电子商务交易***生成B2B订单信息，并向支付机构发起订单支付请求。

步骤S102：支付机构向对应银行发起支付请求；即支付机构接收到商务交易***提交的支付请求，验证请求的合法性，并向采购人员展示付款台页面，采购人员核对页面上的订单信息，并选择网上支付银行，支付机构通过人行通道(银联或网联机构)向对应银行发起支付请求。

步骤S103：录入信息；即银行***接收到支付请求后，核对通道合法性，登记订单相关信息，并提供U盾支付及采购码支付选择，采购人员选择采购码支付，并将采购码、手机号码、以及接收的短信验证码录入信息，银行***进入交易处理过程。

3)交易处理，如图5所示，交易处理过程包含有：

步骤S201：校验订单信息；即银行***校验报文的合法性，登记订单相关信息。

步骤S202：校验采购码信息；即调用采购码验证模块进行采购码信息核对，核对信息包括采购码合法性、采购人员信息、采购码是否在有效期内、使用次数是否未达上限，验证采购码单笔限额、日累计限额、月累计限额，判断逻辑如下：

条件1：订单金额<单笔限额；

条件2：订单金额+日累计订单金额<日累计限额；

条件3：订单金额+月累计订单金额<月累计限额；

满足上述3个条件，则生成待提交指令。

步骤S203：生成待提交指令信息；即财务人员登陆银行***，进入指令查询栏目，对采购码订单信息核对，信息核对无误后，***U盾进行签名支付，***判断持盾人可直接支付限额是否大于支付订单金额，满足则进行入账处理步骤S206，否则进入步骤S204处理。

步骤S204：生成一笔待审批的指令；即判断集团的授权模式，授权模块包括二级授权和多级授权，二级授权模式下，满足支付金额<授权人可授权限额条件的一级授权人和二级授权人进行指令批复操作步骤S205，均批准则进入步骤S206。多级授权模块下，满足预先设置的授权路径上的授权人进行指令批复操作步骤S205，均批准则进入步骤S206。

步骤S205：支付指令审批授权；即授权人登陆银行***指令批复菜单，查看可批复指令，进行批准、拒绝操作。

步骤S206：完成入账；即可以进行借贷方账务处理。

从软件层面来说，为了实现对多个电子商务网站的订单信息统一处理，提高交易处理的效率和准确性，进而能够有效提高交易的安全性，本申请提供一种用于实现所述交易处理方法中全部或部分内容的交易处理装置的实施例，参见图6，所述交易处理装置具体包含有如下内容：

接收模块10，用于接收多个电子商务网站各自对应的订单支付信息并存储。

输出模块20，用于若接收到财务登录请求，则根据该财务登录请求对应的第一采购码，输出该财务登录请求对应的订单支付信息，作为待处理订单支付信息。

交易处理模块30，用于若接收到所述待处理订单支付信息对应的签名支付请求，则执行该签名支付请求对应的交易处理。

在本申请一个实施例中，所述接收模块包括：

接收单元，用于接收多个电子商务网站各自对应的订单支付信息，该订单支付信息包括：第二采购码、订单金额、第一采购人员信息和订单生成时间。

判断单元，用于根据所述第二采购码得到其对应的采购码信息，该采购码信息包括：第二采购人员信息、采购码有效期、采购码单笔限额、采购码日累计限额、采购码月累计限额、已使用次数、支持使用次数、日累计订单金额和月累计订单金额。

存储单元，用于若存在所述第一采购人员信息与第二采购人员信息相同，所述订单生成时间在所述采购码有效期内，所述已使用次数加1不大于所述支持使用次数，所述订单金额不大于采购码单笔限额，所述订单金额和日累计订单金额之和不大于所述采购码日累计限额，以及所述订单金额和月累计订单金额之和不大于所述采购码月累计限额的订单支付信息，则存储该订单支付信息。

在本申请一个实施例中，所述交易处理模块，包括：

获取单元，用于若接收到所述待处理订单支付信息对应的签名支付请求，则获取该签名支付请求对应的可直接支付限额。

处理单元，用于若所述签名支付请求对应的可直接支付限额大于所述待处理订单支付信息中的订单金额，则执行该待处理订单支付信息对应的交易处理。

本说明书提供的交易处理装置的实施例具体可以用于执行上述交易处理方法的实施例的处理流程，其功能在此不再赘述，可以参照上述交易处理方法实施例的详细描述。

为了进一步说明本方案，本申请提供一种交易处理装置的应用实例，参见图7，在本应用实例中，该交易处理装置包含有：采购码管理模块1、采购码验证模块2、指令提交模块3和指令授权审批模块4；其中，指令提交模块3和指令授权审批模块4结合实现的功能可以包含有上述接收模块、输出模块和交易处理模块结合实现的功能，具体描述如下：

采购码管理模块1，用于管理人员新增、修改、作废、发放采购码，新增操作会要求输入采购码相关信息，所述的相关信息包括采购码的额度、有效期、支持使用次数等信息；修改操作能够对采购码的额度、有效期、支持使用次数等信息进行修改；删除操作能够对已创建的采购码进行作废；发放操作会要求输入采购人员的身份信息、接收手机号，所述的身份信息包括姓名、性别、证件类型、证件号码等身份信息。

采购码验证模块2，用于采购人员在电子商务网站上使用采购码下单后，银行***接收到采购码订单支付指令后，调用采购码验证模块进行采购码的合法信息校验，所述的校验步骤包括：采购码是否真实有效、采购码持有人身份信息一致、采购码的额度是否充足、采购码的未达使用次数上限等校验。

指令提交模块3，用于银行***接收支付机构通过人行支付通道发送支付请求，提供采购码下单页面，生成采购码订单支付指令，财务人员登陆银行***指令提交栏目查看订单记录，核对相关订单信息，使用U盾介质签名完成采购码订单提交。

指令授权审批模块4，用于设置不同级别财务管理人员可审批的支付额度范围。审批人接收采购码管理模块1提交的发送指令，对采购码的相关信息进行审核，审核通过，采购人可以接收到采购码信息，及使用采购码进行下单；接收到指令提交模块3提交的支付指令，对支付金额和支付的订单信息进行审核，审核通过，完成订单支付。

由上述描述可知，本申请提供的交易处理方法及装置，能够实现对多个电子商务网站交易的统一处理，提高交易处理的效率和准确性，进而能够有效提高交易的安全性；具体地，能够实现采购人员能够通过采购码完成订单支付，适应当前和未来业务的快速发展，主要有以下优点：(一)采购财务人员只需管理各自的***软件用户，避免了交叉，彻底实现采购财务角色分离。(二)通过预先设置采购码的额度、有效期、使用次数以及持有人，能否根据不同的采购场景签发相应的采购码，灵活配置能否快速支持各类业务发展。(三)按照订单金额的各层级审批控制，能够让采购码订单经过合理的审批人批复，有效控制资金风险。

从硬件层面来说，为了实现对多个电子商务网站的订单信息统一处理，提高交易处理的效率和准确性，进而有效提高交易的安全性，本申请提供一种用于实现所述交易处理方法中的全部或部分内容的电子设备的实施例所述电子设备具体包含有如下内容：

处理器(processor)、存储器(memory)、通信接口(Communications Interface)和总线；其中，所述处理器、存储器、通信接口通过所述总线完成相互间的通信；所述通信接口用于实现所述交易处理装置以及用户终端等相关设备之间的信息传输；该电子设备可以是台式计算机、平板电脑及移动终端等，本实施例不限于此。在本实施例中，该电子设备可以参照实施例用于实现所述交易处理方法的实施例及用于实现所述交易处理装置的实施例进行实施，其内容被合并于此，重复之处不再赘述。

图8为本申请实施例的电子设备9600的***构成的示意框图。如图8所示，该电子设备9600可以包括中央处理器9100和存储器9140；存储器9140耦合到中央处理器9100。值得注意的是，该图8是示例性的；还可以使用其他类型的结构，来补充或代替该结构，以实现电信功能或其他功能。

在本申请一个或多个实施例中，交易处理功能可以被集成到中央处理器9100中。其中，中央处理器9100可以被配置为进行如下控制：

步骤100：接收多个电子商务网站各自对应的订单支付信息并存储。

步骤200：若接收到财务登录请求，则根据该财务登录请求对应的第一采购码，输出该财务登录请求对应的订单支付信息，作为待处理订单支付信息。

步骤300：若接收到所述待处理订单支付信息对应的签名支付请求，则执行该签名支付请求对应的交易处理。

从上述描述可知，本申请的实施例提供的电子设备，能够实现对多个电子商务网站的订单信息统一处理，提高交易处理的效率和准确性，进而有效提高交易的安全性。

在另一个实施方式中，交易处理装置可以与中央处理器9100分开配置，例如可以将交易处理装置配置为与中央处理器9100连接的芯片，通过中央处理器的控制来实现交易处理功能。

如图8所示，该电子设备9600还可以包括：通信模块9110、输入单元9120、音频处理器9130、显示器9160、电源9170。值得注意的是，电子设备9600也并不是必须要包括图8中所示的所有部件；此外，电子设备9600还可以包括图8中没有示出的部件，可以参考现有技术。

如图8所示，中央处理器9100有时也称为控制器或操作控件，可以包括微处理器或其他处理器装置和/或逻辑装置，该中央处理器9100接收输入并控制电子设备9600的各个部件的操作。

其中，存储器9140，例如可以是缓存器、闪存、硬驱、可移动介质、易失性存储器、非易失性存储器或其它合适装置中的一种或更多种。可储存上述与失败有关的信息，此外还可存储执行有关信息的程序。并且中央处理器9100可执行该存储器9140存储的该程序，以实现信息存储或处理等。

输入单元9120向中央处理器9100提供输入。该输入单元9120例如为按键或触摸输入装置。电源9170用于向电子设备9600提供电力。显示器9160用于进行图像和文字等显示对象的显示。该显示器例如可为LCD显示器，但并不限于此。

该存储器9140可以是固态存储器，例如，只读存储器(ROM)、随机存取存储器(RAM)、SIM卡等。还可以是这样的存储器，其即使在断电时也保存信息，可被选择性地擦除且设有更多数据，该存储器的示例有时被称为EPROM等。存储器9140还可以是某种其它类型的装置。存储器9140包括缓冲存储器9141(有时被称为缓冲器)。存储器9140可以包括应用/功能存储部9142，该应用/功能存储部9142用于存储应用程序和功能程序或用于通过中央处理器9100执行电子设备9600的操作的流程。

存储器9140还可以包括数据存储部9143，该数据存储部9143用于存储数据，例如联系人、数字数据、图片、声音和/或任何其他由电子设备使用的数据。存储器9140的驱动程序存储部9144可以包括电子设备的用于通信功能和/或用于执行电子设备的其他功能(如消息传送应用、通讯录应用等)的各种驱动程序。

通信模块9110即为经由天线9111发送和接收信号的发送机/接收机9110。通信模块(发送机/接收机)9110耦合到中央处理器9100，以提供输入信号和接收输出信号，这可以和常规移动通信终端的情况相同。

基于不同的通信技术，在同一电子设备中，可以设置有多个通信模块9110，如蜂窝网络模块、蓝牙模块和/或无线局域网模块等。通信模块(发送机/接收机)9110还经由音频处理器9130耦合到扬声器9131和麦克风9132，以经由扬声器9131提供音频输出，并接收来自麦克风9132的音频输入，从而实现通常的电信功能。音频处理器9130可以包括任何合适的缓冲器、解码器、放大器等。另外，音频处理器9130还耦合到中央处理器9100，从而使得可以通过麦克风9132能够在本机上录音，且使得可以通过扬声器9131来播放本机上存储的声音。

上述描述可知，本申请的实施例提供的电子设备，能够实现对多个电子商务网站的订单信息统一处理，提高交易处理的效率和准确性，进而有效提高交易的安全性。

本申请的实施例还提供能够实现上述实施例中的交易处理方法中全部步骤的一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，该计算机程序被处理器执行时实现上述实施例中的交易处理方法的全部步骤，例如，所述处理器执行所述计算机程序时实现下述步骤：

步骤100：接收多个电子商务网站各自对应的订单支付信息并存储。

步骤200：若接收到财务登录请求，则根据该财务登录请求对应的第一采购码，输出该财务登录请求对应的订单支付信息，作为待处理订单支付信息。

步骤300：若接收到所述待处理订单支付信息对应的签名支付请求，则执行该签名支付请求对应的交易处理。

从上述描述可知，本申请实施例提供的计算机可读存储介质，能够实现对多个电子商务网站的订单信息统一处理，提高交易处理的效率和准确性，进而有效提高交易的安全性。

本申请中上述方法的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。相关之处参见方法实施例的部分说明即可。

本领域内的技术人员应明白，本申请的实施例可提供为方法、***、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本申请是参照根据本申请实施例的方法、设备(***)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

本申请中应用了具体实施例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本申请的限制。

Claims (8)

1.一种交易处理方法，其特征在于，包括：

接收多个电子商务网站各自对应的订单支付信息并存储；

若接收到财务登录请求，则根据该财务登录请求对应的第一采购码，从各订单支付信息中提取第二采购码与第一采购码相同的订单支付信息，作为待处理订单支付信息；

若接收到所述待处理订单支付信息对应的签名支付请求，则执行该签名支付请求对应的交易处理；

所述接收多个电子商务网站各自对应的订单支付信息并存储，包括：

接收多个电子商务网站各自对应的订单支付信息，该订单支付信息包括：第二采购码、订单金额、第一采购人员信息和订单生成时间；

根据所述第二采购码得到其对应的采购码信息，该采购码信息包括：第二采购人员信息、采购码有效期、采购码单笔限额、采购码日累计限额、采购码月累计限额、已使用次数、支持使用次数、日累计订单金额和月累计订单金额；

若存在所述第一采购人员信息与第二采购人员信息相同，所述订单生成时间在所述采购码有效期内，所述已使用次数加1不大于所述支持使用次数，所述订单金额不大于采购码单笔限额，所述订单金额和日累计订单金额之和不大于所述采购码日累计限额，以及所述订单金额和月累计订单金额之和不大于所述采购码月累计限额的订单支付信息，则存储该订单支付信息。

2.根据权利要求1所述的交易处理方法，其特征在于，所述若接收到所述待处理订单支付信息对应的签名支付请求，则执行该签名支付请求对应的交易处理，包括：

若接收到所述待处理订单支付信息对应的签名支付请求，则获取该签名支付请求对应的可直接支付限额；

若所述签名支付请求对应的可直接支付限额大于所述待处理订单支付信息中的订单金额，则执行该待处理订单支付信息对应的交易处理。

3.根据权利要求2所述的交易处理方法，其特征在于，在所述获取该签名支付请求对应的可直接支付限额之后，还包括：

若所述可直接支付限额不大于所述待处理订单支付信息中的订单金额，则根据所述待处理订单支付信息确定其对应的多级可授权限额；

若各级可授权限额均大于所述订单金额，则依次执行所述签名支付请求的批复操作和交易处理。

4.根据权利要求1所述的交易处理方法，其特征在于，在所述接收多个电子商务网站各自对应的订单支付信息并存储之前，还包括：

生成多个不同的第二采购码并设置各个第二采购码各自对应的采购码信息；

将各个第二采购码发送至各自对应的采购人员的终端设备。

5.一种交易处理装置，其特征在于，包括：

接收模块，用于接收多个电子商务网站各自对应的订单支付信息并存储；

输出模块，用于若接收到财务登录请求，则根据该财务登录请求对应的第一采购码，从各订单支付信息中提取第二采购码与第一采购码相同的订单支付信息，作为待处理订单支付信息；

交易处理模块，用于若接收到所述待处理订单支付信息对应的签名支付请求，则执行该签名支付请求对应的交易处理；

所述接收模块包括：

接收单元，用于接收多个电子商务网站各自对应的订单支付信息，该订单支付信息包括：第二采购码、订单金额、第一采购人员信息和订单生成时间；

判断单元，用于根据所述第二采购码得到其对应的采购码信息，该采购码信息包括：第二采购人员信息、采购码有效期、采购码单笔限额、采购码日累计限额、采购码月累计限额、已使用次数、支持使用次数、日累计订单金额和月累计订单金额；

存储单元，用于若存在所述第一采购人员信息与第二采购人员信息相同，所述订单生成时间在所述采购码有效期内，所述已使用次数加1不大于所述支持使用次数，所述订单金额不大于采购码单笔限额，所述订单金额和日累计订单金额之和不大于所述采购码日累计限额，以及所述订单金额和月累计订单金额之和不大于所述采购码月累计限额的订单支付信息，则存储该订单支付信息。

6.根据权利要求5所述的交易处理装置，其特征在于，所述交易处理模块，包括：

获取单元，用于若接收到所述待处理订单支付信息对应的签名支付请求，则获取该签名支付请求对应的可直接支付限额；

处理单元，用于若所述签名支付请求对应的可直接支付限额大于所述待处理订单支付信息中的订单金额，则执行该待处理订单支付信息对应的交易处理。

7.一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其特征在于，所述处理器执行所述程序时实现权利要求1至4任一项所述的交易处理方法。

8.一种计算机可读存储介质，其上存储有计算机指令，其特征在于，所述指令被处理器执行时实现权利要求1至4任一项所述的交易处理方法。