1 业务背景

客户需要通过星瀚出纳付款处理单发起付款，但不通过星瀚银企互联付款，而是将付款信息发送给已有的第三方系统发起付款，发起后由星瀚系统定时请求查询付款状态并反写付款处理单及其上游，且过程中要确保不发生重复支付、超额支付事故。

2 现有解决方案

• 标准产品生成付款处理单已有支付防重配置做拦截校验，若现场业务对标准产品下推流程有做修改，需评估预置的支付防重配置是否满足新的业务场景。

  支付防重整体介绍：《听产品经理说》第180期·资金云特性：资金支付安全系列之支付防重

  详细配置教程请参考： 支付准入简介 与 支付防重配置指引

  若修改了标准产品的botp转换规则，可能遇到的问题： 出现“支付防重规则与BOTP维护的关联实体下推方式不一致，请重新设置支付防重规则”怎么办？

• 付款处理单的定制化开发方案可以详细学习苍穹定制化开发工具->10.4敏感业务方案文档案例库->KD_DEV_金蝶云·苍穹二开敏感支付安全视频和《定制化开发支付类事故案例及解决方案_v6.0》，视频已详细给出风险点和解决方案。

• 开发过程中需严格遵守金蝶云·苍穹定制化开发规范 与 金蝶云·星瀚定制化开发规范

3 补充建议（持续更新中）

• 星瀚与第三方系统的交互单独保存在一个日志表中，包括发送付款请求和查询付款状态。

  付款单每次发起付款请求前先查询当前付款单id在日志是否有发起过付款；有发起过付款的”付款流水号“（详见《定制化开发支付类事故案例及解决方案_v6.0》）是否同步回了付款失败的状态；若没有发起过付款或已付款失败的付款单才能再次发起付款，以防止付款单的付款状态被篡改导致重复支付。

  
  

• 对于上下游单据存在金额、状态反写的场景，不能仅仅依赖反写规则，需要增加业务校验。

  反写规则存在认为修改的可能，仅依赖单据转换反写规则不可靠。

  
  

• 对于异构系统集成到星瀚的数据，尽可能将异构系统传的唯一流水号作为数据库唯一索引。

  标品的表中有些字段已经设置为唯一索引，二开赋值时可以将异构系统的唯一流水号赋值到对应字段上，例如银企互联-交易明细的银行主键字段。