Summary

  • Stripe Radarの頻度属性には、評価中の決済が入らない。同じメールアドレスについて authorized_charges_per_email_hourly は、直近一時間の最初の試行で0。最初が承認されれば、次の試行では1になる。
  • 先の二件がともにその一時間内に承認された場合、> 1 が初めて一致しうるのは三件目。>= 1 なら二件目だ。決済の最終結果は別のルールやカード発行会社の判断にも左右される。

「二件目」のつもりが「三件目」

不正なカード試行を抑えたい店にとって、頻度制限は分かりやすい道具に見える。同じメールから短時間に何件も来たら止める。ただ、設定画面の数字は入口を通る人数をリアルタイムで足したものではない。Stripeのガイドは、処理中の支払いを頻度の計算から外すと明記している。

例として示された authorized_charges_per_email_hourly は、直近一時間にそのメールから成功した承認の履歴を見る。最初の試行は0を見て、承認されれば次の試行が1を見る。二件目も承認されて初めて三件目が2を見る。> 1 はその三件目で初めて条件を満たし、>= 1 は二件目から満たす。一時間は過去にさかのぼる移動窓なので、古い承認が窓の外へ出れば数も減る。

さらに、何を積み上げるかで意味が変わる。Stripeは承認成功、課金の試行、発行会社による拒否、Radarの機械学習モデルによるブロックを別の属性として扱う。発行会社に拒まれた試行が増えても、承認成功のカウンターは増えない。独自のブロックルールによる停止を、機械学習によるブロック件数として数えるのも別物を混ぜる行為だ。

Stripeの現行文書では、標準ルールが全取引を審査し、独自ルールの作成は対応するRadarプランの機能とされる。ガイドには許可、拒否、レビューの優先関係も記載されている。頻度だけで決済の行き先は決まらない。ゼロが見えた一件も、他の審査や発行会社の判断を受ける。

商売上の賭けは、誰を同じ箱に入れるかだ。共有IPには無関係の正当な客が集まりうる。メールを次々変える相手は、一つのメールの履歴を薄くできる。公開資料は個別の店がどのルールを使い、何件の売上を失ったかを示さない。そこを判断するには有効な条件式と各決済のカウンター値、最終判断の記録が要る。

Sources