支付系统做到最后，绕不开风控。之前几篇把支付核心链路、对账、退款都跑通了，但没有风控的支付系统等于在裸奔。这篇聊聊我在支付系统中搭建的基础风控模块——从交易风控的定位到规则引擎的设计思路。
风控在支付链路中的位置
风控不是一个独立系统，它嵌在支付的各个环节里。按介入时机可以分三类：
交易前风控（Pre-transaction）：在用户发起支付之前就进行校验。比如登录设备异常检测、账户状态校验、收款方黑名单过滤。这一步成本最低，拦截效果最好。
交易中风控（In-transaction）：支付请求提交后、真正扣款前的那个窗口期。这是风控的核心战场——规则引擎在这里跑。需要在毫秒级完成判断，不能拖慢支付体验。
交易后风控（Post-transaction）：交易已完成，但还可以做事后分析。比如 T+1 的批量规则扫描、异常交易汇总、可疑账户标记。这一步主要是为了发现规则引擎漏掉的case。
我的实现里，交易中风控是重点。在支付服务调用渠道下单之前，插入一个风控决策节点：
用户下单 → 创建支付单 → 【风控决策】→ 调用渠道 → 回调处理
↓
通过 / 拒绝 / 人工审核
风控决策的输入是一个"风控上下文"，包含用户信息、交易信息、设备信息、历史行为等。输出是一个决策结果：PASS（通过）、REJECT（拒绝）、REVIEW（转人工审核）。
规则引擎设计
风控的核心是规则引擎。简单说就是把一系列规则跑一遍，每条规则给出一个风险分数，最后汇总做决策。
规则分类
我按风险维度把规则分成了几组：
1. 黑名单规则
最简单也最有效。维护几张黑名单表：
- 用户黑名单：被标记过的欺诈用户
- 设备黑名单：关联过欺诈行为的设备ID
- IP黑名单：已知的代理/机房IP段
- 收款方黑名单：高风险商户
命中黑名单直接返回REJECT，不走后续规则。
2. 频率规则
统计时间窗口内的交易行为：
- 同一用户 1 小时内支付次数 > 10 次
- 同一设备 24 小时内关联用户数 > 3
- 同一银行卡 1 小时内支付次数 > 5
频率规则需要一个高性能的计数器，我用Redis的滑动窗口来实现。用 sorted set 存时间戳，ZRANGEBYSCORE 做窗口统计。
3. 金额规则
针对交易金额的异常检测：
- 单笔金额超过用户历史最高金额的 N 倍
- 日累计金额超过阈值
- 首次交易金额异常偏高
- 交易金额命中特定模式（比如反复试探 999.99 这种刚好在限额以下的金额）
4. 设备指纹规则
设备指纹是比较有效的反欺诈手段。采集的信息包括：
- 设备型号、操作系统版本
- 屏幕分辨率、时区
- 是否root/越狱
- 是否使用模拟器
- 网络环境（WiFi/蜂窝/代理）
综合这些信息生成一个设备ID，再看这个设备ID的历史行为。设备指纹的采集我放在客户端SDK里，每次支付请求带上来。
风险评分模型
每条规则被触发后会产生一个风险分数。分数的设计：
| 规则类型 | 触发分数 |
|---|---|
| 黑名单命中 | 100（直接拒绝） |
| 高频交易 | 30-50 |
| 金额异常 | 20-40 |
| 设备异常 | 20-60 |
| 新设备+大额 | 40 |
最终把所有触发规则的分数累加，根据总分做决策：
- 总分 < 30：PASS
- 30 ≤ 总分 < 70：REVIEW（进入人工审核队列）
- 总分 ≥ 70：REJECT
阈值是可以动态调整的，放在配置中心里。业务上线初期可以把REVIEW的范围放宽一些，观察一段时间再收紧。
决策结果处理
三种决策结果的处理逻辑不同：
PASS：正常走支付流程，无感知。
REJECT：返回给用户一个模糊的错误（"支付异常，请稍后重试"），不要告诉用户被风控拦截了。记录拒绝原因到风控日志，供后续分析。
REVIEW：支付先挂起（状态设为 RISK_REVIEWING），推到审核队列。运营在风控后台看到这笔交易的详情和触发规则，手动决定放行还是拒绝。要注意设置审核超时——比如 30 分钟没处理就自动拒绝。
常见欺诈场景
做风控之前，先了解对手在干什么：
盗卡交易：用偷来或买来的银行卡信息发起支付。特点是新设备 + 新用户 + 大额 + 收货地址与持卡人不符。
薅羊毛：批量注册小号，利用新用户优惠。特点是同一设备/IP关联大量账号，交易模式高度相似。
洗钱：通过大量小额交易将非法资金合法化。特点是高频、固定金额、快进快出。
退款欺诈：正常支付后发起恶意退款（声称未收到货等）。需要结合物流信息和历史退款率来判断。
试探攻击：用小额交易测试卡号是否有效，验证通过后再大额盗刷。特点是短时间内连续小额交易。
针对每种场景，规则引擎里都有对应的规则组合来应对。
架构层面的考虑
风控系统对性能要求很高——交易中风控的决策延迟要控制在 50ms 以内。几个关键设计：
- 黑名单用 Redis + 本地缓存双层，热数据放内存
- 频率统计全部走 Redis，不查数据库
- 规则引擎用责任链模式，命中黑名单可以提前终止
- 风控日志异步写入，不阻塞主流程
- 规则配置通过配置中心下发，支持热更新
小结
这篇只是风控的基础部分。实际生产环境中，基于规则的风控只是起步——后面还有基于机器学习的实时风控模型、关联图谱分析、用户行为序列建模等等。但对于一个中小规模的支付系统来说，把规则引擎做好，已经能覆盖绝大部分风险场景了。
支付系统这个系列到这里告一段落。从支付核心流程、渠道对接、对账、退款到风控，基本把一个支付系统该有的模块都过了一遍。后面如果有新的实践再继续补充。
