支付领域 - 资损问题

一、资损是什么在支付领域资损是一个核心风控术语特指“资金的非预期损失”。1. 什么是非预期这笔损失不在正常的业务计划或预算之内。例如计划内的为了拉新预算100万作为用户红包。这是营销成本不是资损。非预期的由于红包规则有漏洞被黑产批量套走100万。这100万就是资损。2. 什么是资金损失指的是公司资产负债表上现金或现金等价物的真实减少。不是数据丢失、不是体验下降而是“钱少了”。3. 关键特征是什么因为系统、规则或流程中存在可被利用的缺陷从而被触发造成的损失。二、为什么要防止资损不做会直接死。法律强制央行、网联、支付监管资金不安全 罚款、吊销牌照、直接关停平台会直接倒闭一次资损几十万、几百万小支付公司直接破产商户彻底不信任你商户的钱被盗、被错扣、提现失败永远不用你的收款码账永远对不平资金流水、余额、清算、结算对不上就是定时炸弹纠纷 赔偿商户投诉、监管核查、用户索赔全部是平台买单三、产生资损的场景有哪些分别如何预防场景 1撞库盗号 → 恶意提现对应登录、余额、提现系统商户登录只需要「账号 密码」无验证码、无登录失败锁定、无异地提醒黑客行为用工具「撞库」批量试账号密码碰巧破解了一个商户账号操作流程黑客登录商户后台查看可用余额86,000 元绑定自己的银行卡发起全额提现平台接口没做任何校验直接打款成功资损结果商户找平台索赔平台实打实亏 86000 元资损根源登录无安全防护、提现无二次验证、无收款账户白名单如何预防登录加图形验证码 / 短信验证码密码错误 5 次锁定账号提现必须短信 / 邮箱二次确认提现账户绑定白名单非白名单不能提核心技术方案强化身份验证 风险拦截二次验证场景 2重复点击提现 → 重复打款对应提现、余额系统提现接口没做「幂等性」同一个请求允许多次执行商户操作点提现按钮时网络卡了商户连续点了 5 次系统行为接口收到 5 次请求执行 5 次提现每次都扣余额、打款商户余额1000 元提现金额 1000 元资损结果商户只应该收到 1000结果收到 5000平台亏 4000 元资损根源无幂等、无余额兜底校验如何预防提现加唯一订单号同一订单只执行一次提现前强校验可用余额 提现金额同一商户 1 分钟内只能发起 1 笔提现核心技术方案幂等性设计 余额强校验场景 3抓包篡改提现金额 → 多提钱对应提现、余额系统提现接口没做参数签名金额可直接改黑客操作在商户后台发起提现提现金额 100 元用抓包工具Fiddler修改请求参数amount100→ 改成amount50000发送请求系统行为没验签、没校验金额合法性直接执行提现 50000资损结果平台亏 49900 元资损根源参数明文、无签名、无防篡改如何预防所有资金接口必须SHA256/SHA512 加签验签金额篡改 → 验签失败 → 直接拒绝大额提现如 5000需人工复核核心技术方案参数加签 验签SHA512对应你之前的需求场景 4越权漏洞 → A 商户提 B 商户的钱对应余额、明细、提现你的系统没做商户身份校验漏洞原理接口请求只传merchantId1001前端传什么后端就认什么黑客操作登录自己的商户 AID1001把请求里的merchantId1002商户 B直接查看商户 B 的余额、交易明细甚至发起提现资损结果商户 B 的钱被陌生人提走平台全额赔偿资损根源越权、未校验「当前登录商户 操作商户」如何预防所有资金接口登录商户 ID 操作商户 ID才能执行商户 ID 从 Token 里取不许前端传参核心技术方案基于 Token 的身份校验 参数白名单场景 5支付回调重复 → 商户余额重复增加对应今日收款、余额、入账场景用户扫码付款成功微信 / 支付宝重复推送 3 次回调你的系统没做回调幂等每回调一次就给商户加一次余额结果实际收款 1000 元商户余额加了 3000 元资损结果平台多给商户 2000商户提现后平台亏 2000如何预防按「交易订单号」去重同一订单只入账一次入账前必须查订单状态已入账则拒绝核心技术方案回调订单状态校验 主动补单场景 6清算轧差计算错误 → 多结算给商户对应清算、入账、余额你的系统每日清算轧差公式写错。正确结算金额 总收款 - 手续费错误结算金额 总收款 手续费一天商户总收款100 万手续费 1 万正确结算99 万系统结算101 万资损结果一天平台亏 2 万长期就是天文数字如何预防清算公式双人校验日终自动对账不平立即报警清算结果人工复核后再执行核心技术方案公式校验 自动对账 人工复核场景 7内部员工无权限 → 手动篡改商户余额对应后台资金管理后台系统运营 / 客服员工权限过大可直接修改商户可用余额员工行为私下给熟人商户加余额 5 万元商户提现资损结果平台亏 5 万还涉及内部舞弊如何预防最小权限原则员工不能直接改金额改余额必须走流程申请→复核→审批→留痕所有资金操作全记录日志不可删除场景 7内部员工无权限 → 手动篡改商户余额权限 审计场景 8用户付款成功 → 商户未入账掉单对应收款、入账、明细用户扫码付款 2000 元银行 / 通道扣款成功你的系统网络波动没收到回调没给商户入账结果用户付了钱商户没收到投诉到监管处理结果平台必须先垫付 2000 给商户再自己找银行追责资损结果平台垫付资金占压成本 纠纷成本如何预防定时主动查询订单状态补单机制异常订单自动监控、人工介入核心技术方案异常监控 自动补单 告警四、事前、事中、事后事前验明正身也就是确认操作用户合法。事中参数防篡改防止重复提交、重复扣款要有余额校验。事后监控对账及时发现资损然后复盘。其中事前、事中在前面的场景分析中都已经存在了。五、如何监控对账及时发现资损对账 两边账对一对看钱平不平平台自己的账我们系统里的交易、收款、余额第三方的账微信 / 支付宝 / 银行 / 通道给我们的流水两边金额必须完全一样不一样 有资损风险用第三方流水 与 我方流水 按订单号一一匹配核对订单号、金额、状态确保每一笔钱都真实、正确、不丢、不错、不多。5.1 对账到底在 “对” 什么核心原理对账原理有 4 步1. 拉取把第三方流水拉过来微信对账文件、支付宝对账文件、银行对账文件把我方平台流水查出来我们系统里的交易记录2. 匹配按订单号out_trade_no一笔一笔配对3. 核对每一笔都要核对 3 个东西订单号一致金额一致状态一致成功 / 失败4. 结果判断完全一致 → 对账成功平账我方有对方没有 → 长款可能多给商户入账了对方有我方没有 → 短款 / 掉单用户付了钱我们没入账金额不一致 → 金额错误资损5.2 对账举例用户扫码支付 100 元用户付款成功 → 银行 / 微信 / 支付宝 记录订单 A 100 元 成功我们系统也记录订单 A 100 元 成功晚上对账第三方订单 A 100我们订单 A 100→平账 ✅异常场景 1掉单最常见银行订单 A 100 元 成功用户真扣钱了我们订单 A 未支付系统漏了→对账不平 ❌ → 自动补单 → 给商户入账异常场景 2金额错了银行订单 A 100 元我们订单 A 101 元→对账不平 ❌ → 资损风险 → 报警异常场景 3重复入账银行订单 A 100 元只付 1 次我们订单 A 入账 2 次 → 200 元→对账不平 ❌ → 多给商户钱 资损