合同对接使用技巧

电子签章之----------------上上签技术分享

1.什么是电子签章—一句话概括，就是利用互联网手段实现合同签署

电子合同是《中华人民共和国合同法》规定的书面合同形式的一种，指双方或多方当事人之间通过电子信息网络以电子的形式达成的设立、变更、终止财产性民事权利义务关系的协议。传统的合同签订需要双方同时到场，确认合同内容后进行签字加盖指模（公章），才具有法律承认的有效性，能对合同签约方形成制约。这种签约方式自然不适应互联网化产品，随着互联网技术进步，相关法律也顺应时代发展，规定了符合要求的电子合同一样具有法律承认的有效性，可以受到法律保护。电子合同的推出极大促进了依赖双方契约订立的互联网产品飞速发展。

简单来说就是，电子签章是电子签名的一种表现形式，利用图像处理技术将电子签名操作转化为与纸质文件盖章操作相同的可视效果，同时利用电子签名技术保障电子信息的真实性和完整性以及签名人的不可否认性。 电子签章，在一定程度上是企业数字化的一种标志，实现了电子签章就能更好的实现企业的数字化需求，在当今社会，数字化是考验一个企业是否具有顽强生命力的一种标志。

2.为什么需要电子合同

当然是降本增效，为企业节约成本，在供应链金融中，可以提高企业与企业之间的信任度，防止各种赖账的行为发生的同时有效的提高企业与企业之间的合作效率，更好的将整个供应链系统中的信息流整合在一起。有效的提高了企业的运营效率。给融资企业带来了更多的生存机会，将整个供应链生态的资金流给盘活，不会让融资企业因为长期的应收账款导致入不敷出，或不能及时的盘活资金上的流转。

3.什么样的电子合同才是真实有效的：

1. 能够确保合同的发送方是其本人，而不是伪造的----------真实身份

对签约方真实身份的确定，是通过各种实名认证方式来进行保证，所以实名认证是电子合同产品设计中必不可少的一环。实名认证功能可以由电子合同服务提供商提供，也可以由其他第三方符合要求的服务商提供。在上上签对接中，我们所使用的就是上上签原有的实名认证系统，

2. 能够确保合同是签署人真正愿意签署的,而不是不确定的--------真实意愿

意愿认证是指在每一次签署前对用户的身份进行确认，保证是用户本人操作的认证方式。我们常见的用户密码登录其实就是一种意愿认证，但由于目前登录密码丢失、被盗取、被破解的风险很高，所以对于涉及金额较大和较重要的电子合同，产品设计中要考虑加入其他意愿认证方式进行可靠性强化。

常见的意愿认证方式有：指纹登入、短信验证码登入、语音验证码登入、人脸识别登入、UKEY登入等。各种意愿认证方式同样可靠性和用户体验各有不同，根据不同产品要求可以进行选用。

3.能够确保合同原文，合同签名未被中间人修改的--------- 签名未改及原文未改

签名未改及原文未改是通过数字签名技术+时间戳+CA机构颁发的数字证书一起保证和实现的，数字签名技术是其中的核心部分，时间戳和数字证书的实现方式都使用到数字签名。

数字签名是非对称算法和哈希算法的联合运用，在此简单讲解如下：

**非对称算法：**非对称算法是一个神奇的加密算法，它可以生成一对密钥，这对密钥一个称为公钥，一个称为私钥。

• 公钥是公开的，互联网中任何人都可以取得所有他人的公钥；
• 私钥是私密的，只有持有人自己才能使用。

非对称算法可以实现防抵赖的目的。原理是A使用自己的私钥加密文件；B收到文件后，使用A的公钥解密；如果能够解密的，证明文件一定来源于A。

**哈希算法：**任何不同的数据经过哈希算法后得到的哈希值都是不同的，而任何相同的数据经过哈希算法后得到的哈希值都是相同的。因此，哈希值又称为数据的数字指纹。

假设一个用户A执行了电子合同签约，则服务端先对电子合同原文进行哈希算法，得到电子合同原文的哈希值。然后使用用户A的私钥对哈希值进行加密，把加密得到的数字签名连同电子合同一起发送出去。

用户B收到带数字签名的电子合同后，先对原文用哈希算法得到哈希值，然后使用用户A的公钥对数字签名进行解密（对于用户A的公钥可信度是由CA机构的数字证书来保证，只要是国家认证的CA机构颁发的数字证书都认为是可信的，在此不展开讲解），解密得到的哈希值与原文用哈希算法得到哈希值进行比对，如果哈希值一致，则证明电子合同确实是A所签署的，并且没有被纂改过，也就达到验证“签名未改、原文未改”的目的。

**时间戳：**签订时间同样是电子签名成立和有效性关键环节，电子签名一般使用时间戳技术来对电子合同的签订时间进行有效确认。原理是对电子合同进行一次哈希运算，将哈希值发送给时间戳签发中心，时间戳签发中心使用数字签名技术对哈希值和当前时间进行一次数字签名。

由于对于电子合同哈希值具有唯一性，所以时间戳的数字签名可以确认电子合同签约的时间点，这样就保证了“签名未改”的实现。

4.第三方接口常用对接技巧

1.根据三方企业所提供的api对接文档，对api的公共请求部分提取出来，在供应链金融2.0中，我们所使用的是将各种api请求的公用参数保存进数据库，并对其进行加密处理，在api公共部分对其进行查询与获取。这样可以有效的防止第三方的服务发生改变所带来的的代码修改，能在不重启应用的情况下，及时将老的参数替换新的参数，有效的提高了运营效率。增强了整个系统的灵活性。

2.接口对接方面，一般三方服务商会让我们对请求信息进行签名处理，在涉及到财务方面的接口，通常还会加上时间戳和异步回调，所以在处理api对接的时候我们就需要，对这些公用的功能进行抽取，提炼，将相同功能写在一起，避免重复代码重复出现，提高代码的可读性，降低代码的耦合度

3.对接三方api接口最重要的一环就是业务需求了解，我们需要与第三方服务商共同探讨出来一个行之有效的解决方案，避免因为各种不确定性，延长工作时间，减低工作效率。这是最重要的一点，也是最需要我们做到的一点，这点做不好，其实其他都是白搭。

5.上上签的业务流程

以融资端进行讲解：

融资商在融资端进行注册操作，在注册完成后，（同时进行账号绑定，及客户id与上上签系统进行绑定，用于标识融资商）我们会要求其进行实名认证(现在我们是利用上上签的认证系统)，融资端在进行完实名认证之后才能进入融资企业端。在融资端进入系统，可以选择相应的融资产品，融资产品绑定了相关的合同模板，在发送合同的时候（如果账号还没有绑定则需要再次进行绑定）。在所有的合同操作中，都需要确保客户id与上上签系统已经进行了绑定。发送合同，及将模板的动态字段进行填充，即将模板的字段进行赋值，在发送完合同后（异步通知—在系统中记录相应合同），平台端可以对合同进行审批，审批完成后就可以让资金方进行签署或者撤销（异步通知动态改变合同状态).

6.上上签对接中使用的技巧

1.在第三方api管理模块中配置上上签公用参数，利用公共函数计算出上上签请求需要的请求头部信息，后续就可以直接调用

2.利用上上签的异步通知进行数据更新，（发送、撤销、签署合同、创建模板、修改模板都会产生相应的异步通知）

3.首先将请求实现，模糊化参数。利用一个String参数代表整个参数类型，在具体实现业务需求的时候在对其进行扩充处理。

7.核心逻辑代码抽取讲解:

/**
 * 获取上上签公共部分
 *
 * @return
 */
@Cacheable
@Override
public BestSignConfig getBestSignCommon() {
   
   /**
   *查询三方系统中与上上签有关参数
   */
   OthersApi otherApi = iOthersApiService.lambdaQuery().eq(OthersApi::getApiNo, OtherApiType.BEST_SIGN.getCode()).eq(OthersApi::getStatus, EnableOrDisableEnum.DISABLE.getCode