业务处理方法及装置与流程

本申请属于网络技术领域，具体地说，涉及一种业务处理方法及装置。

背景技术：

银企直联是指企业端通过企业财务系统直接与银行端的银行系统联接的一种方式，企业端通过企业财务系统可以直接向银行系统发起交易请求，实现对企业银行账户中资金的管理和调动，完成查询、转账等业务处理操作。通过银企直联虽然可以方便企业完成与银行有关的交易，但是面临的最大的问题即是安全性问题，企业身份如果被盗用，就会导致安全隐患，影响业务处理的安全性。

为了提高业务处理的安全性，现有技术中，通常是在企业财务系统中部署前置机，通过硬证书方式对企业身份进行安全认证。企业财务系统向银行系统发起的业务请求报文，先由前置机利用硬证书进行数字签名之后，再提交至银行系统。

但是，由于硬证书经常会出现过热等问题，需要手工插拔、重启等运维操作，操作很不便利，且随着越来越多的小微企业参与银企直联，小微企业的企业财务系统通常不是企业自创的，而是租用的诸如saas(software-as-a-service，软件即服务)型的软件系统，如果采用现有技术的这种硬证书的方式，硬证书则需设置在租用的服务器上，而租用的服务器通常部署在距离企业较远的专有机房上，一旦硬证书出现问题，那么运维操作就会更加不便利，增加了安全认证的复杂性。

技术实现要素：

有鉴于此，本申请所要解决的技术问题是提供了一种业务处理方法及装 置，在保证业务处理安全性的前提下，提高了安全认证的便利性。

为了解决上述技术问题，本申请公开了一种业务处理方法，包括：

客户端将用户提交的口令请求报文，利用第一软证书进行签名之后发送至服务端；由所述服务端将所述口令请求报文提交至银行系统，使所述银行系统对所述口令请求报文进行签名验证，并在签名验证通过之后，向所述用户提供口令信息；

将所述用户提交的携带所述口令信息的业务请求报文，利用所述第一软证书进行签名之后发送至所述服务端，由所述服务端将所述业务请求报文提交至所述银行系统，使得所述银行系统对所述业务请求报文进行签名验证以及对所述口令信息进行口令校验，并在签名验证和口令校验均通过之后，根据所述业务请求报文进行业务处理。

优选地，所述客户端将用户提交的口令请求报文，利用第一软证书进行签名后发送至服务端，由所述服务端将所述口令请求报文提交至银行系统，使所述银行系统对所述口令请求报文进行签名验证，并在签名验证通过之后，向所述用户提供口令信息包括：

所述客户端将用户提交的口令请求报文，利用第一软证书进行签名后发送至服务端，由所述服务端将所述口令请求报文利用第二软证书进行签名后提交至银行系统，使所述银行系统对所述口令请求报文进行签名验证，并在签名验证通过之后，向所述用户提供口令信息；

所述将用户提交的携带所述口令信息的业务请求报文，利用所述第一软证书进行签名后发送至所述服务端，由所述服务端将所述业务请求报文提交至所述银行系统，使得所述银行系统对所述业务请求报文进行签名验证以及对所述口令信息进行口令校验，并在签名验证和口令校验均通过之后，根据所述业务请求报文进行业务处理包括：

所述将用户提交的携带所述口令信息的业务请求报文，利用所述第一软证书进行签名后发送至所述服务端，由所述服务端将所述业务请求报文利用所述第二软证书进行签名后提交至所述银行系统，使得所述银行系统对所述业务请求报文进行签名验证以及对所述口令信息进行口令校验，并在签名验 证和口令校验均通过之后，根据所述业务请求报文进行业务处理。

一种业务处理方法，包括：

服务端接收用户通过客户端提交的口令请求报文，其中，所述口令请求报文为所述客户端使用第一软证书进行签名的报文；

将所述口令请求报文提交至银行系统，使所述银行系统对所述口令请求报文进行签名验证，并在签名验证通过之后，向所述用户提供口令信息；

接收所述客户端发送的业务请求报文，其中，所述业务请求报文为所述客户端使用所述第一软证书进行签名后的报文，所述业务请求报文中携带所述口令信息；

将所述业务请求报文提交至所述银行系统，使所述银行系统对所述业务请求报文进行签名验证以及对所述口令信息进行口令校验，并在签名验证和口令校验均通过之后，根据所述业务请求报文进行业务处理。

优选地，所述将所述口令请求报文提交至银行系统包括：

将所述口令请求报文利用第二软证书进行签名后提交至所述银行系统；

所述将所述业务请求报文提交至所述银行系统包括：

将所述业务请求报文使用所述第二软证书进行签名后提交至所述银行系统。

一种业务处理方法，包括：

银行系统接收服务端提交的口令请求报文；其中，所述口令请求报文为客户端将用户提交的口令请求报文利用第一软证书进行签名后发送至所述服务端的；

对所述口令请求报文进行签名验证，并在签名验证通过之后，向所述用户提供口令信息；

接收所述服务端提交的业务请求报文；其中，所述业务请求报文为所述客户端将用户提交的携带所述口令信息的业务请求报文利用所述第一软证书进行签名后发送至所述服务端；

对所述业务请求报文进行签名验证以及对所述口令信息进行口令校验， 并在签名验证和口令校验均通过之后，根据所述业务请求报文进行业务处理。

优选地，所述银行系统接收服务端提交的口令请求报文包括：

所述银行系统接收服务端提交的利用第二软证书进行签名后的口令请求报文；

所述接收所述服务端提交的业务请求报文包括：

接收所述服务端提交的利用所述第二软证书进行签名后的业务请求报文。

一种业务处理装置，包括：

第一签名模块，用于将用户提交的口令请求报文，利用第一软证书进行签名之后发送至服务端；由所述服务端将所述口令请求报文提交至银行系统，使所述银行系统对所述口令请求报文进行签名验证，并在签名验证通过之后，向所述用户提供口令信息；

第二签名模块，用于将所述用户提交的携带所述口令信息的业务请求报文，利用所述第一软证书进行签名之后发送至所述服务端，由所述服务端将所述业务请求报文提交至所述银行系统，使得所述银行系统对所述业务请求报文进行签名验证以及对所述口令信息进行口令校验，并在签名验证和口令校验均通过之后，根据所述业务请求报文进行业务处理。

优选地，所述口令请求报文具体由所述服务端将利用第二软证书进行签名后提交至银行系统，使所述银行系统对所述口令请求报文进行签名验证，并在签名验证通过之后，向所述用户提供口令信息；

所述业务请求报文具体由所述服务端利用所述第二软证书进行签名后提交至所述银行系统，使得所述银行系统对所述业务请求报文进行签名验证以及对所述口令信息进行口令校验，并在签名验证和口令校验均通过之后，根据所述业务请求报文进行业务处理。

一种业务处理装置，包括：

第一接收模块，用于接收用户通过客户端提交的口令请求报文，其中，所述口令请求报文为所述客户端使用第一软证书进行签名的报文；

第一发送模块，用于将所述口令请求报文提交至银行系统，使所述银行系统对所述口令请求报文进行签名验证，并在签名验证通过之后，向所述用户提供口令信息；

第二接收模块，用于接收所述客户端发送的业务请求报文，其中，所述业务请求报文为所述客户端使用所述第一软证书进行签名后的报文，所述业务请求报文中携带所述口令信息；

第二发送模块，用于将所述业务请求报文提交至所述银行系统，使所述银行系统对所述业务请求报文进行签名验证以及对所述口令信息进行口令校验，并在签名验证和口令校验均通过之后，根据所述业务请求报文进行业务处理。

优选地，所述第一发送模块具体用于将所述口令请求报文利用第二软证书进行签名后提交至所述银行系统；

所述第二发送模块具体用于将所述业务请求报文使用所述第二软证书进行签名后提交至所述银行系统。

一种业务处理装置，包括：

第三接收模块，用于接收服务端提交的口令请求报文；其中，所述口令请求报文为客户端将用户提交的口令请求报文利用第一软证书进行签名后发送至所述服务端的；

第一验证模块，用于对所述口令请求报文进行签名验证，并在签名验证通过之后，向所述用户提供口令信息；

第四接收模块，用于接收所述服务端提交的业务请求报文；其中，所述业务请求报文为所述客户端将用户提交的携带所述口令信息的业务请求报文利用所述第一软证书进行签名后发送至所述服务端；

第二验证模块，用于对所述业务请求报文进行签名验证以及对所述口令信息进行口令校验，并在签名验证和口令校验均通过之后，根据所述业务请求报文进行业务处理。

优选地，所述第三接收模块具体用于接收接收服务端提交的利用第二软证书进行签名后的口令请求报文；

所述第四接收模块，具体用于接收所述服务端提交的利用所述第二软证书进行签名后的业务请求报文。

与现有技术相比，本申请可以获得包括以下技术效果：

本申请实施例中，用户通过客户端首先向服务端提交口令请求报文，并由客户端利用软证书对口令请求报文进行签名，从而银行系统接收到服务端提交的口令请求报文，对口令请求报文进行签名验证，确认用户身份，并在验证通过之后，向用户提供口令信息；从而用户通过客户端向服务端提交携带口令信息的业务请求报文，并由客户端利用软证书对业务请求报文进行签名，银行系统接收到业务请求报文之后，不仅进行签名验证还需要进行口令验证，在签名验证以及口令验证均通过之后，再根据业务请求报文进行业务处理，通过软证书和口令信息，对用户进行了双重认证，保证了业务处理安全性，且采用软证书同时提高了安全认证的便利性。

当然，实施本申请的任一产品必不一定需要同时达到以上所述的所有技术效果。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1是本申请实施例的一种业务处理方法一个实施例的流程图；

图2是本申请实施例的一种业务处理方法又一个实施例的信令流程图；

图3是本申请实施例的一种业务处理装置一个实施例的结构示意图；

图4是本申请实施例的一种业务处理装置又一个实施例的结构示意图；

图5是本申请实施例的一种业务处理装置又一个实施例的结构示意图；

图6是本申请实施例的一种业务处理系统一个实施例的结构示意图。

具体实施方式

以下将配合附图及实施例来详细说明本申请的实施方式，藉此对本申请如何应用技术手段来解决技术问题并达成技术功效的实现过程能充分理解并据以实施。

本申请的技术方案主要适用于银企直联的应用场景中。在银企直连中，由于业务处理需要跨域银行端以及企业端，现有技术通常采用部署前置机，以硬证书进行安全认证的方式来业务处理的安全性，但是硬证书操作并不便利，容易增加安全认证的复杂性。特别是随着越来越多的小微企业参与银企直联，小微企业的企业财务系统通常不是企业自创的，而是租用的诸如saas(software-as-a-service，软件即服务)型的软件系统，如果采用硬证书的方式，硬证书则需设置在租用的服务器上，而租用的服务器通常部署在距离企业较远的专有机房上，一旦硬证书出现问题，那么运维操作就会更加不便利，使得安全认证更加复杂性。

为了在保证业务处理安全性的同时，提高安全认证的便利性，发明人经过一系列研究，提出本申请的技术方案，在本申请实施例中，由用户通过客户端向服务端提交口令请求报文；其中，口令请求报文利用软证书进行签名，银行系统接收到服务端提交的口令请求报文，对口令请求报文先进行签名验证，验证通过之后，向用户提供口令信息；从而发起业务请求时，需要通过客户端向服务端提交携带口令信息的业务请求报文，业务请求报文同样利用软证书进行签名，银行系统接收到业务请求报文之后，不仅进行签名验证还需要进行口令验证，在签名验证以及口令验证均通过之后，再根据业务请求报文进行业务处理，通过软证书和口令信息，对用户进行了双重认证，保证了业务处理安全性，且同时提高了安全认证的便利性。

下面将结合附图对本申请技术方案进行详细描述。

图1为本申请实施例提供的一种业务处理方法一个实施例的流程图，该方法可以包括以下几个步骤：

101：客户端将用户提交的口令请求报文，利用第一软证书进行签名之后发送至服务端。

本申请实施例中，企业财务系统采用客户端+服务端的方式进行部署，用户可以通过客户端向服务端发起请求，通过服务端可以与银行系统进行联接通信。

企业财务系统可以是b/s(browser/server，浏览器/服务器)架构或者c/s(client/server，客户机/服务器)架构。

因此，客户端可以为客户机或浏览器。

本申请实施例中，采用软证书对报文进行签名。在客户端为浏览器时，具体可以是通过调用设置于浏览器中的签名控件，利用软证书对报文进行签名。

软证书是一种数字证书，是一种权威性的电子文档,由权威公正的第三方机构颁发，用以证明自己的身份和识别对方的身份。软证书以文件作为存储介质，以电子文件形式存放的。软证书无需进行复杂的运维操作，使得安全认证更加便利。

为了方便描述区分，客户端进行签名使用的软证书，描述为第一软证书。

在银企直联场景中，所述用户也即企业用户，客户端设置在企业端，位于企业内网，第一软证书用于验证用户身份，也即用于验证企业身份。

口令请求报文用于请求口令信息。用户通过客户端请求进行业务处理时，首先向银行系统提交口令请求报文。

102：服务端将所述口令请求报文提交至银行系统。

客户端将进行签名的口令请求报文提交至服务端，服务端即可以将口令请求报文提交至银行系统。

其中，服务端可以设置在企业端，为企业服务器。

当然，在企业采用saas型软件系统时，服务端可以是指saas服务器。

103：银行系统对所述口令请求报文进行签名验证，并在签名验证通过之后，向所述用户提供口令信息。

银行系统对口令请求报文进行签名验证。银行系统利用第一软证书的公钥对口令请求报文进行签名验证，以确认用户身份。

如果签名验证通过，即可以向用户提供口令信息。

其中，所述口令信息可以是指一次性口令，是指只能使用一次的密码，为每间隔预设时间，生成的一个不可预测的随机数字组合。

其中，银行系统向用户提供口令信息，可以是通过通信信息的形式发送，比如短消息或者来电通话等，银行系统可以利用所述用户的用户终端标识，与所述用户终端建立通信连接；基于所述通信连接，向所述用户终端传输携带所述口令信息的通信信息。用户终端例如可以是指手机等便携式设备，用户终端标识可以是指手机号码等通讯号码。

104：客户端将用户提交的携带所述口令信息的业务请求报文，利用所述第一软证书进行签名之后发送至所述服务端。

用户获得口令信息之后，即可以向客户端提交携带所述口令信息的业务请求报文，例如用户可以在客户端通过输入口令信息，触发业务请求报文。

105：服务端将所述业务请求报文提交至所述银行系统。

客户端首先利用所述第一软证书进行签名之后，再发送至服务端，即由服务端提交至银行系统。

106：银行系统对所述对所述业务请求报文进行签名验证以及对所述口令信息进行口令校验，并在签名验证和口令校验均通过之后，根据所述业务请求报文进行业务处理。

银行系统不仅对业务请求报文进行签名验证，还需要对口令信息进行校验。

银行系统可以利用第一软证书的公钥，验证业务请求报文的签名；可以利用保存的向用户发送的口令信息，对业务请求报文携带的口令信息进行口令校验。仅在签名验证和口令校验均通过之后，根据所述业务请求报文进行业务处理。

在本实施例中，由用户通过客户端向服务端提交口令请求报文；口令请求报文首先由客户端利用第一软证书进行签名，银行系统接收到服务端提交的口令请求报文，对口令请求报文先进行签名验证，验证通过之后，向用户提供口令信息；用户通过客户端向服务端提交业务请求报文，同时携带该口 令信息；携带口令信息的业务请求报文由客户端利用第一软证书进行签名；银行系统接收到业务请求报文之后，不仅进行签名验证还需要进行口令验证，在签名验证以及口令验证均通过之后，再根据业务请求报文进行业务处理，通过软证书和口令信息，对用户进行了双重认证，保证了业务处理安全性，且采用软证书方式，同时提高了安全认证的便利性。

作为又一个实施例，为了进一步提高业务处理的安全性，服务端也需要进行安全认证，服务端同样可以采样软证书方式进行身份认证。

特别是在服务端为租用的诸如saas服务器时，也即企业财务系统并非企业自创的时，由于租用的服务器部署在专有机房，企业通过租用的方式使用，此时的服务端并非位于企业内网，用户通过客户端提交的口令请求报文或者业务请求报文，需要发送至位于企业外网的服务端，因此也有必要对服务端进行安全认证，以保证软件身份也为银行系统授权的，以进一步保证业务处理的安全性。

具体的，可以是服务端接收到客户端提交的口令请求报文时，可以利用第二软证书进行签名之后再提交至银行系统。同样业务请求报文也由服务端利用第二软证书进行签名之后提交银行系统。

从而银行系统对口令情况报文以及业务请求报文的进行签名验证可以包括利用第一软证书的公钥对使用第一软证书进行的签名进行验证，以确认企业身份；利用第二软证书的公钥对使用第二软证书的签名进行验证，以确认软件身份。

下面结合一个实际应用，以服务端为saas服务器为例，对本申请技术方案进行详细描述，如图2所示，为本申请实施例提供的一种业务处理方法又一个实施例的信令流程图，该方法可以包括以下几个步骤：

201：客户端接收用户提交的口令请求报文。

用户可以在客户端录入业务交易，并请求获取口令信息，发起口令请求报文。

202：客户端利用第一软证书将所述口令请求报文进行签名后发送至 saas服务器。

此外，作为又一个实施例，在该实际应用中，客户端也可以采用硬证书对口令请求报文签名。

203：saas服务器利用第二软证书将所述口令请求报文进行签名后提交至银行系统。

204：银行系统对所述口令请求报文进行签名验证，并在签名验证通过之后，向所述用户提供口令信息。

银行系统对口令请求报文的签名验证包括对客户端以及saas服务器分别进行的签名进行的验证，以确认企业身份以及软件身份，使得只有被授权的企业和软件能够实现业务处理。

205：客户端接收用户提交的携带所述口令信息的业务处理报文。

206：客户端利用第一软证书将所述业务请求报文进行签名后发送至saas服务器。

207：saas服务器利用第二软证书将所述口令请求报文进行签名后提交至银行系统。

208：：银行系统对所述对所述业务请求报文进行签名验证以及对所述口令信息进行口令校验，并在签名验证和口令校验均通过之后，根据所述业务请求报文进行业务处理。

银行系统对业务请求报文的签名验证包括对客户端以及saas服务器分别进行的签名进行的验证。

在本实施例中，通过软证书和口令信息，对用户进行了双重认证，能够有效避免因软证书可能被复制冒用带来的安全性问题。保证了业务处理安全性，且分别在客户端以及服务端对口令请求报文以及业务请求报文进行签名，进一步保证了业务处理的安全性。且采用软证书方式，同时提高了安全认证的便利性。

此外，作为又一个实施例，在服务端位于企业内网，为企业服务器时，对口令请求报文以及业务请求报文利用第一软证书进行的签名，也可以是在 服务端执行的，由于服务端位于企业内网，因此可以利用企业申请的第一软证书进行签名，也可以实现对企业身份的认证，并不局限于在客户端利用第一软证书对口令请求报文以及业务请求报文进行签名的方式。

图3为本申请实施例提供的一种业务处理装置一个实施例的结构示意图，该装置在实际应用中可以配置为客户端，该装置可以包括：

第一签名模块301，用于将用户提交的口令请求报文，利用第一软证书进行签名之后发送至服务端；由所述服务端将所述口令请求报文提交至银行系统，使所述银行系统对所述口令请求报文进行签名验证，并在签名验证通过之后，向所述用户提供口令信息；

第二签名模块302，用于将所述用户提交的携带所述口令信息的业务请求报文，利用所述第一软证书进行签名之后发送至所述服务端，由所述服务端将所述业务请求报文提交至所述银行系统，使得所述银行系统对所述业务请求报文进行签名验证以及对所述口令信息进行口令校验，并在签名验证和口令校验均通过之后，根据所述业务请求报文进行业务处理。

作为又一个实施例，为了进一步提高业务处理的安全性，服务端也需要进行安全认证，服务端同样可以采样软证书方式进行身份认证。因此，所述口令请求报文可以具体由所述服务端将利用第二软证书进行签名后提交至银行系统，使所述银行系统对所述口令请求报文进行签名验证，并在签名验证通过之后，向所述用户提供口令信息；

所述业务请求报文可以具体由所述服务端利用所述第二软证书进行签名后提交至所述银行系统，使得所述银行系统对所述业务请求报文进行签名验证以及对所述口令信息进行口令校验，并在签名验证和口令校验均通过之后，根据所述业务请求报文进行业务处理。

图4为本申请实施例提供的一种业务处理装置又一个实施例的结构示意图，该装置在实际应用中可以配置在服务端，所述服务端可以为设置企业内网中的企业服务器，或者设置在企业外网的租用服务器，该装置可以包括：

第一接收模块401，用于接收用户通过客户端提交的口令请求报文，其中，所述口令请求报文为所述客户端使用第一软证书进行签名的报文；

第一发送模块402，用于将所述口令请求报文提交至银行系统，使所述银行系统对所述口令请求报文进行签名验证，并在签名验证通过之后，向所述用户提供口令信息；

第二接收模块403，用于接收所述客户端发送的业务请求报文，其中，所述业务请求报文为所述客户端使用所述第一软证书进行签名后的报文，所述业务请求报文中携带所述口令信息；

第二发送模块404，用于将所述业务请求报文提交至所述银行系统，使所述银行系统对所述业务请求报文进行签名验证以及对所述口令信息进行口令校验，并在签名验证和口令校验均通过之后，根据所述业务请求报文进行业务处理。

作为又一个实施例，为了进一步提高业务处理的安全性，服务端也需要进行安全认证，服务端同样可以采样软证书方式进行身份认证。因此，所述第一发送模块可以具体用于将所述口令请求报文利用第二软证书进行签名后提交至所述银行系统。

所述第二发送模块可以具体用于将所述业务请求报文使用所述第二软证书进行签名后提交至所述银行系统。

图5为本申请实施例提供的一种业务处理装置又一个实施例的结构示意图，该装置在实际应用中可以配置在银行系统中，该装置可以包括：

第三接收模块501，用于接收服务端提交的口令请求报文；其中，所述口令请求报文为客户端将用户提交的口令请求报文利用第一软证书进行签名后发送至所述服务端的；

第一验证模块502，用于对所述口令请求报文进行签名验证，并在签名验证通过之后，向所述用户提供口令信息；

第四接收模块503，用于接收所述服务端提交的业务请求报文；其中，所述业务请求报文为所述客户端将用户提交的携带所述口令信息的业务请 求报文利用所述第一软证书进行签名后发送至所述服务端；

第二验证模块504，用于对所述业务请求报文进行签名验证以及对所述口令信息进行口令校验，并在签名验证和口令校验均通过之后，根据所述业务请求报文进行业务处理。

其中，在所述口令请求报文是具体由所述服务端将利用第二软证书进行签名后提交至银行系统时，所述第三接收模块也即具体用于接收接收服务端提交的利用第二软证书进行签名后的口令请求报文；

第一验证模块对口令请求报文的签名验证包括对客户端以及saas服务器分别进行的签名进行的验证，以确认企业身份以及软件身份，使得只有被授权的企业和软件能够实现业务处理。

具体的可以是利用第一软证书的公钥对使用第一软证书进行的签名进行验证，以确认企业身份；利用第二软证书的公钥对使用第二软证书的签名进行验证，以确认软件身份。

所述业务请求报文可以具体由所述服务端利用所述第二软证书进行签名后提交至所述银行系统时，所述第四接收模块，也即具体用于接收所述服务端提交的利用所述第二软证书进行签名后的业务请求报文。

第二验证模块对业务请求报文的签名验证包括对客户端以及saas服务器分别进行的签名进行的验证。

具体的可以是利用第一软证书的公钥对使用第一软证书进行的签名进行验证，以确认企业身份；利用第二软证书的公钥对使用第二软证书的签名进行验证，以确认软件身份。

本申请实施例还提供一种业务处理系统，该业务处理系统可以包括客户端、服务端以及银行系统。

客户端与服务端，在银企直联场景中，即构成企业财务系统、

如图6所示，为本申请实施例提供的业务处理系统一个实施例的结构示意图，该业务处理系统部署在企业内网中，包括客户端601、服务端602以及银行系统603。

客户端601可以配置有如图3所示的业务处理装置，服务端602可以配置有如图4所示的业务处理装置，银行系统可以配置由如图5所示的业务处理装置。

在用户需要进行业务处理时，通过客户端601提交口令请求报文，客户端601对口令请求报文利用第一软证书进行签名后提交至服务端602。服务端602将口令请求报文提交至银行系统603，也可以利用第二软证书进行签名后再提交至银行系统603。银行系统603对口令请求报文进行签名验证，验证通过之后，向用户提交口令信息。

接收到口令信息的用户，可以通过客户端就601提交携带口令信息的业务请求报文，客户端601对业务请求报文利用第一软证书进行签名后提交至服务端602。服务端602将业务请求报文提交至银行系统603，也可以利用第二软证书进行签名后再提交至银行系统603。银行系统603对业务请求报文进行签名验证以及对口令信息进行口令校验，在签名验证以及口令校验均通过之后，即可以根据业务请求报文进行业务处理。

通过本申请实施例的业务处理系统，通过软证书和口令信息，对用户进行了双重身份认证，保证了业务处理安全性，进一步的可以在服务端进行再次签名验证，锦衣保证业务处理的安全性，而采用软证书方式，提高了安全认证的便利性。因此，本申请实施例在保证业务处理安全性的同时，提高安全认证才便利性。

需要说明的是，本申请的技术方案不仅适用于银企直联这种场景中，任何需要跨系统进行业务处理的领域或场景中，均可以采用本申请的技术方案进行安全认证，以保证业务处理的安全性，因此对于采用本申请技术，用于保证任何跨系统进行业务处理的安全性的方式，均应在本申请的保护范围。

在一个典型的配置中，计算设备包括一个或多个处理器(cpu)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(ram)和/或非易失性内存等形式，如只读存储器(rom)或闪存(flashram)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(pram)、静态随机存取存储器(sram)、动态随机存取存储器(dram)、其他类型的随机存取存储器(ram)、只读存储器(rom)、电可擦除可编程只读存储器(eeprom)、快闪记忆体或其他内存技术、只读光盘只读存储器(cd-rom)、数字多功能光盘(dvd)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括非暂存电脑可读媒体(transitorymedia)，如调制的数据信号和载波。

如在说明书及权利要求当中使用了某些词汇来指称特定组件。本领域技术人员应可理解，硬件制造商可能会用不同名词来称呼同一个组件。本说明书及权利要求并不以名称的差异来作为区分组件的方式，而是以组件在功能上的差异来作为区分的准则。如在通篇说明书及权利要求当中所提及的“包含”为一开放式用语，故应解释成“包含但不限定于”。“大致”是指在可接收的误差范围内，本领域技术人员能够在一定误差范围内解决所述技术问题，基本达到所述技术效果。此外，“耦接”一词在此包含任何直接及间接的电性耦接手段。因此，若文中描述一第一装置耦接于一第二装置，则代表所述第一装置可直接电性耦接于所述第二装置，或通过其他装置或耦接手段间接地电性耦接至所述第二装置。说明书后续描述为实施本申请的较佳实施方式，然所述描述乃以说明本申请的一般原则为目的，并非用以限定本申请的范围。本申请的保护范围当视所附权利要求所界定者为准。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的商品或者系统不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种商品或者系统所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的商品或者系统中还存在另外的相同要素。

上述说明示出并描述了本申请的若干优选实施例，但如前所述，应当理解本申请并非局限于本文所披露的形式，不应看作是对其他实施例的排除， 而可用于各种其他组合、修改和环境，并能够在本文所述申请构想范围内，通过上述教导或相关领域的技术或知识进行改动。而本领域人员所进行的改动和变化不脱离本申请的精神和范围，则都应在本申请所附权利要求的保护范围内。