Summary

  • Stripe Radar 的频次属性排除正在评估的付款。authorized_charges_per_email_hourly 在某邮箱过去一小时内的第一笔尝试上显示 0；首笔成功获得发卡行授权后，第二笔看到 1。
  • 若前两笔都在该小时内成功获授权，条件 > 1 到第三笔才首次匹配；写成 >= 1 则第二笔就可能匹配。实际处理结果还受其他规则和发卡行决定影响。

闸机后面的数字

同一邮箱连续付款，商户首先想到的是限速。Radar 允许符合套餐条件的商户编写自定义规则，频次属性看起来像现成的旋钮。但旋钮标的不是“当前第几笔”，而是结账前已经留下多少符合条件的记录。Stripe 的官方规则指南写得很清楚：当前付款不计入频次。

拿 authorized_charges_per_email_hourly 来算。某邮箱在此前一小时没有成功授权，第一笔面对的数值就是 0。第一笔获授权，第二笔面对 1；第二笔也获授权，第三笔面对 2。因此 > 1 的第一次可能匹配是第三笔，>= 1 才把第一次可能匹配移到第二笔。这是一小时滚动窗口，旧授权离开窗口后，数值会回落。一个符号改变拦截位置，不能靠“超过一次”这种口头描述替代。

还要看“数的是什么”。Stripe 把成功授权、所有扣款尝试、发卡行拒绝、Radar 机器学习模型阻断列为不同计数。发卡行连续拒绝不会把成功授权计数抬高。自定义阻断也不能直接当成机器学习阻断来读。商户若用授权计数追踪刷卡测试，再拿实际尝试量解释这条计数，容易把密集失败误认成安静。

Stripe 当前文档说，默认 Radar 规则会检查每笔交易；自定义规则取决于所购套餐。规则指南还给出允许、阻断、人工复核等规则的执行次序，允许规则可能优先于后续阻断。单个频次属性为 0，并不许诺付款会通过。要判断一笔交易，必须连同其他命中规则和发卡行结果一起看。

这个设定直接影响商户愿意承担的损失。共享 IP 可能把多个正常顾客装进同一计数；不断换邮箱的人则可能把足迹拆散。公开资料没有某家商户的实际规则和误伤率。能改变个案判断的，是那条生效中的完整表达式、逐笔计数值与最终决定。

Sources