"友好欺诈"缺口：为什么支付处理器难以保护小微商家

对于任何在线商家而言，拒付（chargeback）都是一个众所周知的噩梦。你发货了产品，提供了送达证明，并遵循了每一项协议，结果客户却声称他们从未收到过商品。在行业内，这通常被称为“友好欺诈”（friendly fraud）——这是对那些滥用争议流程以同时获取产品和退款的客户的一种委婉说法。

最近，雪茄爱好者利基产品 Ciglue 的创作者分享了一个案例，凸显了支付处理器在处理此类行为时的系统性失效。在一名客户成功对已送达的订单提出争议，并随即立即下达第二个订单以重复该骗局后，商家向 Stripe 提供了明确的证据——包括客户在邮件中炫耀该计划的内容。尽管如此，商家发现了一个令人沮丧的现实：一个商家提供的欺诈证据并不能转化为对其他商家的保护信号。

欺诈检测中的信号缺口

Stripe 将其 "Radar" 工具作为一种先进的、由机器学习驱动的欺诈预防系统进行推广。其价值主张基于网络效应：因为 Stripe 处理海量的交易量，因此它可以识别出单个商家无法发现的模式。

然而，Ciglue 的案例揭示了一个关键的盲点。据报道，当商家提供确凿的证据证明客户正在滥用拒付系统时，Stripe 并不会利用这些信息来创建跨商家的欺诈信号。这意味着坏人可以从一个 Stripe 商家转移到另一个商家，每次都像是一张白纸一样重新开始。

正如一位观察者所指出的，当前的系统创造了一个失衡的环境：

"对我而言，关键的教训是 Stripe 承认他们不会使用争议后的友好欺诈证据来构建 Radar 中的跨商家信号……这表明了系统对独立卖家而言是多么失衡。"

商家的困境：防御 vs. 摩擦

由于支付处理器在争议过程中通常保持中立或不表态，商家被迫实施自己的防御措施。围绕这一问题的社区讨论提出了几种策略，尽管每种策略都有其自身的权衡：

1. 激进的内部黑名单机制

许多 SaaS 创始人与电商卖家主张“零容忍”政策。这包括不仅禁止使用该卡，还要禁止任何提出争议的客户的电子邮件地址和设备指纹。虽然这对于单个店铺而言是有效的，但它无法阻止客户攻击其他商家。

2. 区域屏蔽

一些人建议完全禁止高风险地区或国家。虽然这可以大幅降低欺诈率，但它也会限制市场覆盖范围，并可能疏远那些地区的合法客户。

3. 技术加固

高级用户建议跳出仪表板进行观察。这包括分析访问日志以寻找结账提交中的模式——例如 IP 范围、缺乏 JavaScript 执行或直接 API 调用——以便在自动化卡片测试攻击发生之前将其拦截。

4. 通过 3DS 实现责任转移

像 EMV 3DS 2.x 身份验证这样的技术解决方案可以提供“责任转移”保护，将某些欺诈类型的风险从商家转移到发卡行。然而，这会增加结账流程中的摩擦，从而可能降低转化率。

银行卡生态系统的结构性问题

这是 Stripe 特有的失败，还是全球支付生态系统的特征？有人认为，整个信用卡系统都是为了向消费者倾斜而设计的。银行通常站在持卡人一边，而支付处理器充作为中间人，促进交易，但对争议的结果几乎不承担责任。

这创造了一种“友好欺诈”实际上受到激励的局面。客户知道银行很可能会站在他们那边，而且商家知道，即使有送达证明，他们也可能仍然会失去资金、产品以及争议处理费。

结论

对于小微商家而言，对抗友好欺诈是一场艰苦的战斗。当那些被宣传为营销为“基于网络的保护”的工具无法在网络内共享关键的欺诈信号时，防御的重担完全落在了个体卖家身上。除非支付处理器从被动反应的姿态转向主动的、跨商家的信号系统，否则友好欺诈中的“友好”一词将继续只让骗子获益。