2. 电商支付基础
做支付反欺诈，第一步不是急着上规则引擎或机器学习模型，而是把“钱是怎么走的”彻底搞清楚。欺诈分子攻击的从来不是抽象的风控系统，而是支付流程中的具体环节：下单、支付请求、渠道扣款、回调通知、清算、结算、退款。只有知道每个环节的正常形态、数据字段和时序约束，才能识别出异常。本章围绕支付流程、支付方式、清结算机制、常见支付渠道四条主线，说明它们与反欺诈的直接关系。
一、核心原理：一笔支付到底经历了什么
电商支付可以抽象为“交易—支付—清算—结算”四层。交易层负责订单与金额确认；支付层负责向渠道发起扣款并接收结果；清算层负责渠道与平台之间核对交易明细、计算应收应付；结算层负责把资金实际划转到商户账户。反欺诈的介入点贯穿四层，但重点在支付层和清算层。
以一次典型的银行卡支付为例，其核心时序如下：
1. 用户下单 → 订单系统生成 order_id、amount、merchant_id
2. 收银台选择支付方式 → 生成 payment_id，调用渠道下单接口
3. 渠道返回支付凭证（如二维码、跳转链接、）
4. 用户完成验证（密码/短信/3DS）→ 渠道异步扣款
5. 渠道回调 notify_url → 平台验签、更新支付状态
6. 平台主动查询渠道订单 → 对账兜底
7. 日终清算 → 生成清算文件，核对交易与资金
8. 结算 → 按周期打款至商户银行账户这里有两个反欺诈必须抓住的关键点：异步性和状态机。回调可能延迟、重复甚至伪造，因此平台不能仅凭一次回调就认定支付成功，必须验签、幂等处理，并以主动查询和对账作为最终依据。欺诈者常利用“回调伪造”或“支付状态与订单状态不一致”来薅取商品或优惠。
二、方法流程：支付方式与清结算机制
不同支付方式的风险特征差异极大。银行卡涉及拒付（chargeback），风险高但可追索；第三方钱包到账快、拒付难，风险集中在盗号与套现；货到付款（COD）则把风险转移到物流与签收环节。理解这些差异，才能为每种方式配置不同的风控策略。
| 支付方式 | 资金到账速度 | 典型欺诈手法 | 风控重点 |
|---|---|---|---|
| 银行卡 | T+1 至 T+3 | 盗卡、拒付、测卡 | CVV/3DS 校验、BIN 黑名单、拒付率监控 |
| 第三方钱包 | 实时 | 盗号、套现、洗钱 | 账户行为、设备指纹、收款方聚集度 |
| 货到付款 | 签收后结算 | 虚假下单、拒收 | 收货地址、历史拒收率、下单频次 |
| 余额/礼品卡 | 实时 | 盗刷余额、卡密倒卖 | 兑换频率、IP 与设备关联 |
清结算机制是反欺诈的“照妖镜”。清算关注交易明细是否与渠道一致，结算关注资金是否真实到账。常见差异包括：渠道成功但平台未收到回调、平台成功但渠道失败、金额不一致、重复清算。这些差异往往对应欺诈或系统漏洞。例如，攻击者可能利用回调重放，让平台重复发货；也可能利用退款与清算时间差进行套利。
三、案例/场景：渠道差异如何影响风控决策
假设某平台同时接入银行卡、某第三方钱包和货到付款。某日风控发现一批订单集中在凌晨 2 点到 4 点，使用同一钱包渠道，收货地址分散但手机号段集中，且全部选择加急发货。若只看单笔订单，金额不大、行为正常；但结合渠道特征——钱包到账实时、拒付困难——这批订单一旦发货，资金几乎无法追回。
进一步排查清算数据发现，这些订单的渠道清算状态为“成功”，但收款方账户在短时间内多次变更绑定银行卡。这正是典型的“盗号+套现”组合。若平台只依赖支付成功回调就发货，损失将直接产生。正确的做法是：对高风险渠道组合启用延迟发货、二次验证，并在清算层监控收款方聚集度。
四、常见支付渠道与反欺诈的关系
渠道是反欺诈的数据来源和对抗前线。每个渠道提供的字段不同：银行卡渠道通常返回 BIN、卡类型、3DS 结果；钱包渠道返回账户 ID、实名状态；跨境渠道还会返回 IP 国家、AVS 结果。风控系统应尽量采集这些字段，并建立渠道维度的基线。
- 渠道成功率基线：某渠道成功率突然从 95% 降到 80%，可能是渠道故障，也可能是攻击者在批量测卡。
- 渠道拒付率：银行卡渠道拒付率超过阈值，需立即收紧该渠道的放行策略。
- 渠道回调延迟：延迟异常升高时，应暂停自动发货，改为主动查询确认。
- 渠道限额与风控规则：了解渠道自身的风控规则，避免平台策略与渠道策略冲突导致误杀。
下面是一段简化的支付回调验签与幂等处理示例，反欺诈系统通常在此处插入风险校验：
def handle_payment_notify(payload, signature):
if not verify_signature(payload, signature):
return {"code": "FAIL", "msg": "invalid signature"}
payment_id = payload["payment_id"]
if redis.get(f"notify:{payment_id}"):
return {"code": "SUCCESS", "msg": "duplicate"}
order = order_service.get_by_payment(payment_id)
risk_result = risk_engine.check(order, payload)
if risk_result.level == "HIGH":
order_service.hold(order.id, reason="risk_hold")
return {"code": "SUCCESS", "msg": "held"}
order_service.mark_paid(order.id)
redis.setex(f"notify:{payment_id}", 3600, "1")
return {"code": "SUCCESS"}需要强调的是，渠道不是孤立的。反欺诈系统应把渠道数据与用户、设备、订单、清算数据打通，形成统一的风险视图。例如，同一设备在多个渠道频繁尝试不同卡号，即使每个渠道单独看都正常，联合起来就是明显的测卡行为。