安全不是一句承诺，是一组可以逐条核对的机制
下面每一条都对应平台里真实运行的规则。我们刻意不用"100% 安全"这类说法，只讲机制是什么、为什么这样设计。
先冻结、后出款、不确定不动钱
下单即冻结
事务保证代付提交时立刻冻结对应资金，成功后实扣，失败经确认后退回。冻结与实扣在数据库同一事务内完成。
结果未知不自动处理
防重复付款上游超时或查不到结果时，平台不判失败、不自动退回、不自动重发，订单进入人工裁决队列。
没有"一键重新下单"
产品设计失败订单不会被自动重新提交。这是刻意的产品决策，不是功能缺失。
幂等下单
唯一约束同一商户订单号只会创建一笔订单；重复提交返回同一结果，不会重复出款。
余额由流水推导，差异只登记不调账
复式流水
每一笔资金变动记两条分录，余额是流水的推导结果。后台没有任何功能可以直接改写余额字段。
不变量校验
系统每日重算"余额 == 全部流水之和"，不一致即告警。
每日自动对账
内部账本对账与上游订单对账每日自动执行，运营也可随时手动触发。
差异不自动调账
对账发现的差异只记录、不自动修改任何余额。任何调整都必须走明确的业务单据与审批。
关键操作两个人、两道验证
| 操作 | 控制 |
|---|---|
| 充值入账确认 | 审核人 ≠ 建单人；实时验证码 |
| 入账冲正 | 审批人 ≠ 发起人；实时验证码 |
| 提现放款 | 放款人 ≠ 复核人 |
| 结算单确认 | 确认人 ≠ 提交人 |
| 失败订单资金裁决 | 实时验证码；先核实上游结果 |
| 上游备付金入池 | 审批人 ≠ 录入人；实时验证码 |
| 管理员账号变更 | 实时验证码 |
职责分离由后端强制校验，不是可关闭的开关。二次验证只接受认证器实时码，恢复码不能用于操作确认；连续输错会中止操作，避免账号被锁。
私钥在商户手里，服务器 IP 必须在白名单里
RSA 请求签名
每个 API 请求用商户私钥签名，平台用公钥验签。签名覆盖方法、路径、时间戳与请求体。
私钥只展示一次
密钥对在商户浏览器本地生成，平台只保存公钥。私钥在注册成功时展示一次，平台不保存、无法找回。
IP 白名单强制
注册应用必须填写 1 到 10 条服务器 IP；白名单为空的应用会被直接拒绝调用。
真实来源 IP
平台在边界层获取客户端真实 IP，不信任请求头中可伪造的转发字段。
两步验证与登录保护
- 三个后台均支持基于认证器的两步验证（TOTP），可按角色强制启用
- 绑定时提供一次性恢复码，用于认证器丢失时登录；重新生成会作废旧码
- 连续输错密码触发锁定，锁定时间逐轮翻倍
- 会话令牌轮换采用原子条件更新，被劫持的旧令牌无法续期
规则可配置，命中有留痕
- 收款账号黑名单：全局或按商户
- 单笔限额、日累计限额、时间窗内的下单频次上限
- 每次拦截都记录命中日志，运营可按商户与规则类型查询
- 被拦截的订单不会产生资金变动（事务已回滚）
边界、存储、日志、供应链
边界防护与源站锁定
所有入口经边界防护层接入，源站只接受来自边界层的流量，公网无法直连。
多可用区与静态加密
生产服务跨多个可用区部署；数据库与凭证存储静态加密，密钥独立于开发环境。
审计日志与脱敏
涉及资金与权限的操作记入审计日志；日志写入侧对证件号、卡号等敏感字段脱敏。
依赖漏洞门禁
每次提交自动审计生产依赖，高危漏洞阻断合并；镜像推送即扫描。
第三方渗透测试
定期进行第三方渗透测试与独立代码审查，发现项按严重度限期修复并留档。
变更有测试证据
每项功能变更附带测试证据报告，记录测试覆盖了什么、没覆盖什么。
边界说清楚，才谈得上信任
- 不做代收：平台只提供出款服务，不代商户收款
- 不托管商户私钥：平台只保存公钥
- 不向第三方共享交易数据：数据仅用于履行代付服务与法定合规义务
- 不承诺具体到账时长：以查单终态为准，不用"秒到"之类的说法