結論
Stripe Radar は 決済前のリスク評価とルール実行 のための仕組み、Dispute（チャージバック）は 決済後の争い のためのプロセスです。
混同すると「Radar で止めれば Dispute は起きないはず」という期待が生まれ、運用が破綻しやすいです。
Stripe 公式で押さえるべき事実
- dispute が始まると、Stripe は disputed amount と dispute fee を残高から差し引く
- dispute が open の間は、通常の refund とは別の dispute 対応フローとして扱う
- 反証期限は長くありません
- 3Dセキュアは一部の不正 dispute で liability shift に寄与するが、すべての dispute を防ぐわけではない
このテーマで判断すべき軸
- 許容する偽陽性（止めすぎによる機会損失）と 許容する偽陰性（通しすぎによるチャージバック）のバランス
- 3DS や追加認証 をどの金額・どの国で強制するか
- 証拠のテンプレ（配送証跡、ログ、利用規約同意）を誰が揃えるか
実装の基本フロー
- 決済メタデータに、後から Dispute で説明できる情報（配送先、注文ID、顧客メール等）を載せる習慣をつける
- Radar ルール変更は 変更理由と期待効果 を残し、A/B 的に振る舞いを観測する
- Webhook で Dispute イベントを受け、期限と担当をチケット化する
- CS・物流・開発で 証拠提出のチェックリスト を共通化する
失敗しやすい点
- ルールを厳しくしすぎて正規ユーザーが通らず、サポート負荷だけが増える
- Dispute 通知をメールのみで追い、期限切れ で自動敗訴扱いに近い状態になる
- PaymentIntent と注文の紐づけが弱く、証拠を集めるのに数日かかる
- 3Dセキュアや配送証跡を持っているのに、提出テンプレがなく evidence 化できない
運用で見る指標
- Radar ルール別のブロック率・誤検知っぽい問い合わせ件数
- Dispute 率（カードブランド・国・商品カテゴリ別）
- 証拠提出までのリードタイムと勝率（社内定義）
次に読む記事
用語: Radar、Dispute、Webhook — 用語集一覧 から辿れます。
よくある質問
Radar を有効にすれば安全ですか？
リスクは下がりますが、ビジネス特性に合わないルールは誤検知や売上損失を生みます。計測とチューニングが必要です。
Dispute に負けたらどうなりますか？
Stripe では dispute 発生時点で disputed amount と dispute fee が残高から差し引かれます。勝てば資金は戻りますが、fee の扱いは契約や地域で確認が必要です。