Stripe Radar のテスト

以下の情報を使用して、不正防止戦略をテストします。

以下のテストクレジットカード番号を使用して、テスト環境で特定のリスクレベルの支払いを作成します。テスト支払いを作成するには、Stripe ダッシュボード (テスト環境) を使用するか、テスト API キーを使用して Create a Charge (支払いの作成) を呼び出します。

番号	説明
	`highest` のリスクレベルの支払いが発生しますが、設定されているルールによってはブロックされる可能性があります (たとえば、`Block if :risk_level: = 'highest'` ルールが無効になっている場合、このカードでの支払いはブロックされません)。
	`highest` のリスクレベルの支払いが生成され、ルールに関係なく常にブロックされます。
	`elevated` のリスクレベルの支払いが生成されます。

ルール

ルールを追加または更新する前に、ルールの基準に一致する過去の本番環境での支払いが検索されます。その支払いのリストを参照し、判定基準の対象となる行動を確認することができます。また、お客様が今後の影響を推測できるように、検索結果のサマリーが示されます。

テストするルールごとに、サマリーには、以下のカテゴリーに該当する支払いの金額と回数が記載されます。

不審請求の申請と不正使用の早期警告: 不審請求の申請または不正使用の早期警告 (EFW) を受け取った決済です。
返金された決済: 返金された決済です。
ブロックされた決済と失敗した決済: Radar によってブロックされた決済、Stripe によってブロックされた決済、またはカード発行会社によって拒否された決済です。
成功した決済: 正常に処理され、まだ不正使用として特定されておらず、返金もされていない決済です。

さらに、許可ルールをテストする際、上書きも表示されます。これは、不正利用のリスクが高いことやカスタムのブロックルールを根拠として Radar がブロックする支払いを指しますが、今後は提案したルールによって許可されます。ダッシュボードで、これらのサマリーのメトリックの内訳を確認できます。たとえば、不正利用として分類された返金を確認できます。

次の表のサンプルの質問を確認して、ルールを実装できるかどうかを判断します。

注意

不正使用による支払いのみをブロックして正当な支払いを許可する完璧なルールを作成できることはまれであるため、ルールを実装するかどうかは通常トレードオフに基づいて決定します。そのルールが誤検出する有効な支払いと、ブロックする必要のある不正使用による支払いを比較検討してください。各社に適したトレードオフはビジネスに固有の状況によって異なります。詳細については、Stripe の不正検出入門をご覧ください。

ルールのタイプ	このルールを実装する状況
ブロック	不審請求が申請されたか、EFW を受たか、ビジネスの正当な支払いで許容される金額を擬製にして不正利用として返金された支払いと一致します。返金と一致し、業務負担を減らして、返金の悪用を防止します。カード発行会社が支払いを拒否したために失敗した支払いと一致します。送信する取引で失敗した取引数が多い場合、カード発行会社はオーソリ率を下げることがあります (たとえば、ビジネスで大量のカードテスティングが行われた場合など)。
確認	不審請求が申請されたか、EFW を受けたか、不正利用として返金された支払いと一致します。チームは、潜在的な不正取引やその他の疑わしい支払いアクティビティーを厳密に評価するように求められます。
3DS のリクエスト	不審請求が申請されたか、EFW を受信したか、ビジネスの正当な支払いで許容される金額を犠牲にして不正利用として返金された支払いと一致します。注意: 3DS は、ユーザーがチャレンジを受けることを常に保証するとは限りません。このため、不正行為者がフリクションレス 3DS に合格して不正行為を行った場合にライアビリティシフトを受けますが、EFW を受ける可能性があります (最終的に VFMP の対象としての指定を受ける場合があります)。
許可	以前にブロックされた支払いのうち、ビジネスにとって安全であるという確信度が高い、許容可能金額と一致します。許可ルールの場合は評価が多少難しくなります。以前ブロックされた支払いが許可された場合に、そのうちどの支払いが不正利用になるのかを認識する手段がないためです。したがって、このルールでは、一致する過去の支払いのリストを見直して、それらの支払いが、許可対象にしたい支払いであることを確認することが非常に重要です。多くの上書きと一致しません。これは、リスクの高い支払いを許可していることを示します。