双乾支付韩伟：保障支付机构不发生重复出款
2018年8月9日，某微信公众号曝出发生重大支付事件，重复结算金额超3亿。 重复计费是支付公司常犯的错误。 该公司曾于2014年11月4日、2017年1月24日、2018年5月发生双重结算案件，受到银联通报批评。 2014年11月，一家支付公司也遇到重复结算问题。 涉案金额9亿元，重复结算4.5亿元。 截至目前，资金尚未全部收回。 多次结算给支付公司带来巨大损失。 如何避免这个问题呢？ 我们邀请了双干支付技术总监韩伟进行分享。
一、背景介绍
确保客户备付金安全是每个支付公司的首要责任，因此中国人民银行也出台了一系列措施和规定，要求支付公司严格遵守《支付公司客户备付金托管办法》。支付机构”。 支付机构和储备银行需要能够每天检查客户储备交易的详细信息。 支付机构必须具备完善的公司治理规范和风险管理体系以及有效的客户准备金保障措施。
支付机构每月与备付金进行人工核对数据，并每季度在中国人民银行客户备付金信息核验系统中报送以下信息：
支付机构和各储备银行应当核查核实其业务系统记录的活期存取款业务和储备银行账户存取款信息。
支付机构及备付金存管银行法人（或其授权分支机构）应计算并核对支付机构业务系统中客户资金账户的当期金额、期末余额以及各备付金银行的变动及余额存款。
然而，所有支付系统都是由人类开发的，不可避免地会出现错误。 那么如何保证支付机构不重复支付呢？ 我简单讲一下预防和治理方法。
2. 错误场景
常见错误场景：
1、程序逻辑错误
每次取款时，等待银行返回结果，然后将成功的取款结果保存在数据库中。 一旦网络异常或数据库繁忙、无法插入成功状态或其他原因导致存储过程回滚，则最终状态不会更新，因此可以重复撤回。
2.次日场景，或者服务器时差
某笔结算交易恰好跨越两天。 例如，如果23:59提交，银行将在第二天发放款项。 但由于异步通知成功未能正常发生，昨天查询程序检查是否成功，没有结果，导致再次提现。 有时候，由于上游服务器和你的生产服务器有几分钟的时间差，导致查询失败，钱又被提走了。
3. 多个定时任务
通常，计划任务与项目工程文件一起提交，并且可以轻松部署在多个服务器集群中。 当付费作业运行在多台服务器上时，必然会导致重复付费。
4、服务器异常崩溃
服务器异常崩溃、蓝屏等，导致无法完成数据库存储、发送异步通知、甚至内存状态丢失等，都可能导致重复提现。
5. 提交并发
一般财务审核按钮都是并发提交的，或者如果是自动审核的话，提交时会出现并发，会导致重复提现。
作为支付机构，主要需要在以下情况下保证资金安全：
确保结算账户不重复结算（T1、T0、D0）
确保不重复向银行账户或银行卡结算（T1、T0、D0）
确保商户（结算账户）结算资金无重复提取
确保客户（支付账户）不重复提款
确保支付服务不重复
按重要性（从重要到次要）：
支付业务不重复（因为批量业务，一旦批量重复，损失将会巨大）
直接结算到银行账户或卡，无需重复（T1、T0、D0）（因为商户结算资金一般都比较大）
客户提款不重复，商户结算提款不重复（一般为单次提款）
不会出现重复结算到账的情况（如果总对账能查到，可以发起冲销交易，避免损失）
3、解决思路
3.1 分步进行提现和结算
分步提取储备金
A。 生成提款批次
b.审计
C。 提款
将商户结算分解为步骤
A。 生成商户结算表
b.审计
C。 提款
3、分步提取客户现金
A。 生成提款记录
b.审计
C。 提款
3.2 为各步骤添加风险控制机制
1、提款前扣除余额：
生成支付批次时，会先扣除商户余额，然后再处理剩余部分；
产生提现请求时，会先扣除商户余额或账户余额，然后再处理剩余部分。
2、每次付款请求或提现都需要通过财务审核（当两批要求提现金额相同时，财务部门一般都能看到）。 如果是D0，或者系统定时的T0、T1，系统也应该主动去做审核。
3. 代付款时，作业仅处理已批准但未付款的批次。 然而，Job一旦进入，无论后续如何执行，都会被标记为“处理中”。 因此，即使该批次再次进入提现队列，或者存储过程回滚，也不会再次触发重复提现。
4、客户提款批量、按时处理。 通道只有单一接口，也被封装成批量接口。 （批处理还可以减轻压力并减少个别重复的可能性）
5. 生成结算单时，
如果是T1商户，每天只能生成一条结算记录，时间范围为T日。
如果是T0商户，看T0事件的数量。 如果频率为每天一次，则只能生成一条结算记录。
如果T0会话数为2个及以上，则会严格按照交易时间划分多条结算记录，保证每个时间段不能重叠、重复生成记录。
如果是D0商户，生成的每条结算记录都必须与交易记录严格匹配。
6、为了减少误差，系统自动处理的结算严格按照D0、T0、T1的结算时间进行处理，之前的交易将不予结算。 如果商户之前有未结算的资金，必须经过人工审核后才能加入提现队列。
7、财务手册审核完成后，标记为已审核，或者D0进入作业后立即标记为已审核。 审核完成后，将标记为“已批准并撤回处理”，等待付款。 这里可以添加一个风控，可以确定同一天同一商户同一结算金额的多条结算记录不允许通过审核，或者可以抛出结算异常等待财务手册确认。
8、提现只有4种状态：处理中、成功、退回、异常。 处理中、已退回、提现成功的状态不可修改。 对于状态“异常”的，您可以再次手动提款或标记为“已退回”。 除了明确的“成功”标记外，任何其他异常返回码都对应于异常。 这是为了防止上游通道添加返回码而导致重复提现。 所有异常都会被抛出到异常菜单，随后由财务人员处理。
9. 对于异常订单，专门的查询服务器会在1小时内查询，财务人员1小时后才能处理订单（系统人为锁定1小时，主要是防止1小时内通道变更为交易成功） ）。 如果你想优化这个等待时间，建议单独筛选出那些收款人信息不正确的失败，以便进行财务或自动退款。
10、前端和后端均使用验证防止重复提交，防止并发提交的情况发生。 采取的一般措施是：
禁用提交按钮
在数据库中添加约束
锁
令牌在提交的表单中生成并由服务器验证。
您可以参考以下链接：
防止重复提交表单的八种方法
如何解决并发创建2个相同订单的问题
11、取款时，需要接入中国人民银行指定的电信反诈骗前端机，建议接入过滤下的银联黑名单数据库。
3.3 增加系统和财务手工验证步骤
【系统自动+财务人工审核】支付公司需要每天自动验证备付金，这样至少第二天就能检测到系统是否存在异常。 我们花了大约3个月的时间搭建了储量自动验证系统。
【系统自动验证】D0结算到银行卡时，可检测提款记录中是否已存在该订单号；
【系统自动验证】普通商户结算账户余额时，可检测收支记录中是否存在一日内多次相同金额的录入，结算金额是否与前一日交易金额相符， ETC。
【财务人工审核】财务每天至少3次检查各储备银行的提款情况，并与系统提款记录进行比对。
对于异常订单，在财务处理过程中，必须检查对账文件，然后才能进一步提款或退款。 （网上连接一般需要2小时，银联可实时获取，部分银行直连需要次日）。 如果当天无法提供退款对账单据，一般建议客户退款或次日再次付款。
3.4 其他一些规则
规定23:50至0:10之间不能提币，避免支付服务器与上游服务器存在时差，导致无法准确查询获取提币指令。 也避免了一些银行造成次日重复取款的情况。
同一个定时任务只能在一台服务器上执行。 一旦服务器挂掉，就会在另一台服务器上手动启动。 不允许在多个服务器上自动启动计划任务。
定期自动检查已批准但未成功支付的订单。 由于程序异常、蓝屏、数据库停止响应、无提现记录等情况，均会处于“已审核，处理中”状态，不会出现重复提现。 虽然此项检查与重复提款无关，但为了增强客户体验，还是建议这样做。
4. 一般原则
1、控制提款风险的一般原则：
2、先扣款，再生成并处理订单。 宁长付不短付，进则宽，出则严。
3.自动验证商户结算记录和客户付款记录，不允许同一天出现多个相同金额的结算记录。 如果同一客户多次提款相同金额，建议添加例外情况并进行人工审核。
4、只要进入加工流程，先标记“加工中”。 对于“正在处理”的订单，您无法再次自动启动它们。
5. 除成功外，所有其他通知均被归类为异常，需要手动处理。
6、异常交易需要定时器主动查询1小时，然后发布给财务部门重新处理和提现。
7、需要有一个自动备付金核查系统，每天深夜自动与备付金银行核对，次日人工与财务部门确认。
8. 不允许在多个服务器上开启同一个支付定时器。
9、提币跳过23:50-0:10时间段，避免上游服务器与您的服务器时差，导致第二天出现提币。
10.审核提交等，加上前后端反并发处理，防止http。
本文档根据“支付产品架构交流群”的聊天记录整理而成，由志愿者整理并发布到本网站。 如果您想及时收到“支付产品架构交流群”的最新动态，请扫描二维码关注“凤凰牌老熊”微信公众号。