涉及用户支付和资金的系统，安全上要特别注意什么？

Question

Accepted Answer

结论：涉及用户支付和资金时，普通业务系统只负责订单、业务账和支付指令编排，实际收款、付款、分账和结算应走银行或依法取得许可的支付机构；不要自建无资质“资金池”。工程上必须做到服务端定价、签名验签、幂等处理、不可静默改写的账务流水、支付渠道—业务账—银行入账三方对账，以及退款和提现的职责分离。

支付成功页面不是到账证据，数据库里一个“余额”字段也不是账务系统。资金系统要区分业务订单、支付机构交易、银行结算、退款、手续费和企业内部账。任何一层失败或延迟都可能造成“用户已扣款但订单未更新”“重复回调记两次收入”或“退款显示成功但渠道仍处理中”。

在落实合规责任、证据与技术控制时，还可以对照软件开发服务可以提供哪些合规支持？；这些内容补充了需要放在同一项决策中考虑的上下文。

三种资金路径的边界对比

路径	适用业务	资金实际由谁处理	主要风险	直接判断
商户直连银行或持牌支付机构	自营商城、预约、门店收款	持牌机构结算到商户账户	多渠道接口和对账工作量	普通自营业务优先
平台型产品的服务商/分账能力	多商户平台、佣金或履约后结算	按持牌产品规则处理	商户进件、分账比例、退款和冻结复杂	必须按平台官方产品设计
自建钱包、归集后人工转给商户	储值、撮合、多方清结算	业务公司实际控制资金	可能构成未经许可的支付或清算，安全责任极高	未经专业合规确认不要做

“聚合一个二维码”也不代表可以改变资金路径。签约主体、特约商户、收款账户、手续费、退款来源和结算周期要逐项核对。中国人民银行发布的《非银行支付机构监督管理条例》明确，设立非银行支付机构需批准，未经批准不得从事或变相从事支付业务；业务系统不能用“技术服务”名称绕过许可边界。

服务端根据商品、合同、优惠和税费重新计算应付金额，不能信任客户端上传的金额。创建全局唯一业务订单号和支付尝试号；同一订单可以有多次支付尝试，但只能有一个符合规则的成功结果。调用支付接口时记录请求、渠道单号、金额、币种和当前状态，不记录银行卡密码等不必要敏感认证数据。

支付机构的异步通知必须验证签名、证书、时间戳和通知标识，并检查商户号、订单号、金额与币种。即使验签通过，也用唯一键和幂等事务保证同一通知重复 100 次仍只入账一次。前端跳转到“成功页”只用于体验，最终订单状态由可信服务端通知或主动查询确认。

退款、撤销、拒付和关单是不同状态。退款申请先校验原交易、可退金额和已退累计值，高金额或异常退款走双人审批；渠道受理不等于已到账，后台持续查询并对账。失败重试必须有上限、退避和人工队列，不能无限重复扣款或退款。

每笔余额变化生成追加式分录，记录账户、方向、金额、币种、业务类型、关联订单、操作者和时间；更正通过反向或调整分录，不能直接覆盖历史值。核心记账事务保证借贷或来源去向平衡，金额使用定点整数最小货币单位或合适的十进制定点类型，避免二进制浮点误差。

每日自动做三方对账：业务订单与内部支付流水、内部流水与支付机构账单、支付机构结算与银行到账。分别列出长款、短款、重复、状态不一致、手续费差异和跨日数据，由负责人处理并保留原因。关键指标是未解释资金差异金额为 0，而不是简单要求三边交易笔数完全相同，因为手续费、退款和结算批次的粒度不同。

支付密钥和证书放在受控密钥系统，区分测试与生产，限制服务身份和出口网络，定期轮换并记录到期。客服能查订单但不能改账；财务发起退款与审批分离；开发人员默认不能读取生产敏感数据或直接执行资金 SQL。管理员启用多因素认证，高风险操作二次确认并记录完整审计链。

上线测试覆盖金额篡改、重复请求、重复回调、回调乱序、签名错误、超时后实际成功、部分退款、退款重试、跨日结算和渠道不可用。验收要求重复入账数为 0、未授权资金操作成功数为 0、每笔渠道交易可追到业务订单和账务分录、对账差异均有责任人与处理状态。渗透测试不能代替账务对账，两者都要做。

滚水科技可以负责订单、账务、支付接口、权限、对账和监控的工程实现，并在合同中明确不代替银行或持牌机构提供支付清算。涉及平台分账、储值、提现、跨境或大额资金时，先由客户、支付机构和专业合规人员确认业务模式，再开发；案例中心只能说明第一方项目经验，不能证明任何金融许可。