Radar for Teams: ルールの基本

このガイドでは、Radar ルールに関連するさまざまなトピックを扱います。トピックには、使用できる 100 を超える Radar ルール、およびバックテストやルールの記述などに関するベストプラクティスが含まれます。

Radar
Radar

Stripe ネットワークの力で不正利用を防止します。

もっと知る 
  1. はじめに
  2. ルールの順番と階層の重要性
  3. ルール言語の早見表
    1. 自然言語でルールを記述する
  4. 一般的に使用される Radar ルール
    1. カードテスティングまたはカードキャッシングの防止に役立つルール
    2. 既知の高リスクの SKU での不正防止に役立つルール
    3. プリペイドカードのトライアル乱用の防止に役立つルール
  5. 不正利用を分析してルール作成に役立てる
    1. 不正利用の確認
    2. 不正利用の推進要因に関する詳細なインサイトを得る
  6. ルールを作成するための 3 種類の属性
    1. タイプ 1
    2. タイプ 2
    3. 頻度に基づく属性
    4. カードの詳細に基づいた属性
    5. 決済の詳細に基づいた属性
    6. 顧客の詳細に基づいた属性
    7. タイプ 3
  7. ルールで保存されたリストを使用する (許可リストやブロックリストなど)
  8. 複数の条件を組み合わせて複合ルールを記述する
  9. バックテストのルール
    1. ダッシュボードでバックテストを行う
    2. カスタムのバックテストによる分析を実行する
  10. 不正利用の一般的な傾向
    1. テスト
    2. 値の抽出
  11. その他のベストプラクティス
    1. Stripe.js を使用することの重要性
  12. 結論
    1. その他のメモ

Stripe のデフォルトルールは、機械学習を使用し、相当数の不正使用による決済を予測してブロックします。どの決済をレビューするか、許可するか、ブロックするかについてさらに詳細なコントロールを必要とするビジネスにとって、ルールは不正防止をカスタマイズ するための強力なツールとなります。

このガイドでは、Radar ルールに関連するさまざまなトピックを扱います。トピックには、使用できる 100 を超える Radar ルール、およびバックテストやルールの記述などに関するベストプラクティスが含まれます。

それでは始めましょう。

ルールの順番と階層の重要性

Radar ページにリストされているルールの順番は重要です。すべての決済はお客様が作成したルールに対して評価され、以下の順番で実行されます。

  1. 3DS のリクエスト: Payment Intents API または Checkout とともに使用された場合に、3D セキュア認証をリクエストするルール。このルールに一致するかどうかにかかわらず、許可、ブロック、レビュールールがその後に評価されます。
  2. 許可: 決済の処理を許可するルール。許可ルールを実装する際には注意が必要です。このルールは、3DS ルールを除く、すべてのルール (Stripe の機械学習モデルを含む) に優先するため、使用には細心の注意が必要です。$100,000 以上を処理した加盟店のみが許可ルールを記述できます。
  3. ブロック: 決済をブロックして拒否するルール。決済が拒否されると、レビューのルールで再度見直されることはありません。
  4. レビュー: これらの決済は処理され、顧客は支払いを完了しますが、必要に応じて後で見直しできるようにフラグが付けられます。

これを実践するため、例として以下のルールを使用します。$10 未満の決済はすべて処理されます。これは、最初のルールが決済を許可するためです。よって、その後のルールは評価されません。同様に、これらのルールに従い、通常リスクレベルの、アメリカで行われた $1,500 の決済も、$1,000 を超える決済をブロックするルールがあるにもかかわらず、許可されます。これは、リストの 2 番目のルールで、アメリカで行われた通常リスクレベルの決済が許可されているためです。いったん特定のルールがトリガーされると、それ以降のルールは評価されません。

  • $10 未満の決済を許可

  • アメリカ国内の normal のリスクレベルの決済を許可

  • リスクレベルが high の決済をブロック

  • greater than $1,000 の決済をブロック

  • outside the US で発行されたカードの決済を レビュー

ルール言語の早見表

ルールは SQL に類似しており、ルールを作成するために使用するデータタイプに基づき、使用できる演算子が異なります。以下はそれらをまとめた早見表です。

演算子
文字列
メタデータ
数値
説明
=
等しい

:card_country: = 'us'

!=
等しくない

:card_funding: != 'prepaid'

<
より小さい

:amount_in_gbp: < 10.00

>
より大きい

:amount_in_usd: > 500.00

<=
以下

:amount_in_eur:<= 100.00

>=
以上

:amount_in_cad: >= 10.00

IN
グループに含まれる

:card_country: IN ('gb', 'ie')

INCLUDES
文字列を含む

:ip_address: INCLUDES '192.168'

LIKE
指定のパターンと一致する

:email: LIKE 'fraud%@stripe.com'

特定の属性またはメタデータ属性の存在を明示的に確認する場合は、!= 演算子ではなく、is_missing 関数を使用します。この関数に、欠落している可能性がある属性またはメタデータキーを指定します。たとえば、顧客のメールアドレスにアクセスできないすべての支払いに一致するルールを作成できます。

  • Review if is_missing(:email_domain:)

または、顧客のメールアドレスが欠落して「いない」すべての支払いに一致するルールを作成することもできます。

  • Review if !(is_missing(:email_domain:))

自然言語でルールを記述する

もっと簡単にルールを作成したい場合、または特定の不正利用シナリオへの対処に使用する属性がわからない場合は、AI を活用した Radar アシスタントを利用して自然言語のプロンプトを Radar の構文のルールに変換します。また、Radar アシスタントからルールを直接バックテストして、ルールを導入する前に、もっと以前に導入していたらどのようなパフォーマンスであったかを確認することができます。

一般的に使用される Radar ルール

以下は、さまざまな目的に基づいて、一般的に使用される Radar ルールの一部を挙げたものです。

カードテスティングまたはカードキャッシングの防止に役立つルール

Block if :total_charges_per_ip​_address_hourly: > 1

このルールはカードテスティングの防止に役立ちます。お客様のアカウントで 1 つの IP アドレスのオーソリに複数回成功した場合に支払いをブロックします。

Block if :blocked_charges_per_ip​_address_hourly: > 1

さらに積極的にカードテスティングを防止したい場合は、このルールと :total_charges_per_ip_address_hourly: を組み合わせて使用してください。

Block if :total_charges_per​_card_number_hourly: > 1

このルールはクレジットカード現金化の防止に役立ちます。お客様のアカウントで過去 1 時間に 1 つのカード番号のオーソリに複数回成功した場合に支払いをブロックします。

Block if :blocked_charges_per_card​_number_hourly: > 1

さらに積極的にクレジットカード現金化を防止したい場合は、このルールと :total_charges_per_card_number_hourly: を組み合わせて使用してください。

Block if :address_zip_check: != 'pass'

このルールを使用するには、決済フォームで郵便番号を収集していることを確認してください。このルールは、カード発行会社が、提供された郵便番号とカードに登録されている郵便番号を照合して確認できなかった場合に支払いをブロックします。

Block if :cvc_check:: != 'pass'

このルールを使用するには、決済フォームでセキュリティコードを収集するようにしてください。このルールは、提供されたセキュリティコードとカードに登録されているセキュリティコードをカード発行会社が照合できなかった場合に支払いをブロックします。

既知の高リスクの SKU での不正防止に役立つルール

このルールでは、メタデータを使用するか、または支払い説明として SKU 情報を渡す必要があります。これらの決済は処理され、顧客は支払いを完了しますが、もう一度確認できるようにフラグが付けられます。

Review if ::SKU Category:: IN ('baby formula', 'personal hygiene')

食料品店を運営していて、SKU カテゴリーを含むメタデータを Stripe に送信しているとします。「個人向け衛生用品」や「乳児用粉ミルク」という SKU カテゴリーがタグ付けされている商品を含む注文はリスクが高いことに気付きました。このルールでは、Stripe ダッシュボードの手動レビューリストにこれらの商品を含むすべての注文を掲載し、再確認できるようにします。店側が手動で注文をキャンセルしない限り、この支払いは処理され、顧客に請求されることに注意してください。

Review if :charge_description: = 'Trial class'

2 つの商品 (「トライアルクラス」と「10 クラスパッケージ」) を販売していて、Stripe に支払いの説明として商品名を送信しているとします。このルールでは、Stripe ダッシュボードの手動レビューリストに、支払いの説明が「トライアルクラス」であるすべての注文を掲載し、再確認できるようにします。売り手が手動で注文をキャンセルしない限り、この支払いは処理され、顧客に請求されることに注意してください。

プリペイドカードのトライアル乱用の防止に役立つルール

Block if :card_funding: = 'prepaid' OR :card_funding: = 'unknown'

貴社が在宅治験のサービスを提供している小売業者であると想定します。後から請求することができないプリペイドカードを使った不正使用者が急増していることに気付きました。このルールでは、クレジットカードまたはデビットカード以外を使って支払われるすべての注文がブロックされます。

不正利用を分析してルール作成に役立てる

不正利用の確認

最も効果的なルールを作成するには、自身のアカウントで発生している不正行為を十分に理解する必要があります。行われているさまざまな種類の不正利用ベクトルの特徴を把握することが重要です。以下のような問いについて検討してください。

  • アカウントは、登録してすぐに新しいメールアドレスとカード保有者名を使用して不正な購入を行っていますか?

  • 不正利用者は、長期間存在しているアカウントにアクセスして、異常に多額の購入を行っていますか?

  • 不正利用は、特定のカードネットワーク、またはカード発行国に偏っていますか?

  • 高速の不正利用が発生していますか (短時間での、同じカード、メールアドレス、または IP アドレスからの複数回数の試行)。

上記のスクリーンショットで、高速で発生する不正利用を見ると、authorized_charges_per_card_number_hourly または authorized_charges_per_ip_address_hourly を利用したルールではこのタイプの不正利用方法に対処できる可能性があります。

不正利用の推進要因に関する詳細なインサイトを得る

不正利用に関するインサイトを活用することで、取引データを手動で分析することなく、不正利用の原因を素早く特定して対処することができます。ダッシュボードのインサイトタブに、不正取引に関連した上位の属性が表示されます。インサイトタブから直接、その属性に対処するルールを追加できます。

ルールを作成するための 3 種類の属性

タイプ 1

オーソリ後の属性: 誰もが使用できる属性です。これらの属性を使用する際には、:cvc_check: のようにオーソリ後属性の前後にコロンを使用する必要があります。

属性
説明

:address_line1_check:

カード発行会社による確認。指定された請求先住所の 1 行目 (通常は町名と番地) がカード保有者の登録情報と照合されます。

:address_zip_check:

カード発行会社による確認。提供された郵便番号がカード保有者の登録情報と照合されます。

:cvc_check​:

カード発行会社による確認。提供されたセキュリティコード (CVV とも呼ばれる) がカード保有者の登録情報と照合されます。
指定できる値
説明

pass

提供されたデータは正しいです。

fail

提供されたデータは正しくありません。

unavailable

顧客のカード発行会社は提供されたデータを確認しません。すべてのカード発行会社または国が住所確認に対応しているわけではありません。

unchecked

データは提供されましたが、まだ確認されていません。顧客のカード発行会社が最終的に提供されたデータを確認します。

not_provided

データが Stripe に提供されませんでした。
値の大文字と小文字は区別されます。

以下は、オーソリ後属性の使用例です。

  • Block if :address_line1_check: != 'pass' このルールを使用すると、カード発行会社により、入力された請求先住所の 1 行目がカード保有者の記録にある情報と照合され、一致しない場合には、支払いがブロックされます。このため、この確認が ‘unavailable’ の場合、このデータがカード発行会社で ‘unchecked’ の場合、またはこのデータがカード発行会社で ‘not_provided’ の場合、その決済はブロックされることになります。

タイプ 2

標準属性: 誰もが使用できる属性です。標準属性には、:card_bin: のように前後にコロンを使用する必要があります。標準属性は、4 つのカテゴリーに分けられています。

  • 頻度に基づく属性 (カードテスティングやカードキャッシングの防止に有益)
  • カードの詳細に基づいた属性
  • 決済の詳細に基づいた属性
  • 顧客の詳細に基づいた属性

一部の属性では値を文字列にする必要があり、また他の属性では値を数値にする必要があります。これを分かりやすく説明するため、各属性の例を示します。:card_bin: のように属性が文字列を必要とする場合には、例の中で数値は ‘ ’ に囲まれています。たとえば、:card_bin: = ‘424242’ のようになります。一方、数値が必要とされる場合には、:amount_in_usd: > 250 のように ‘ ’ がありません。

頻度に基づく属性

盗難にあったカードの不正使用、カードテスティング、カードキャッシングを防止するために特に有益な、頻度に基づく 4 種類の属性があります。

  1. オーソリ: カード発行会社のオーソリに基づく
  2. 支払い: 支払いに基づく
  3. 支払い拒否: カード発行会社による支払い拒否に基づく
  4. ブロック: Radar の機械学習によるブロックに基づく

さらに、オーソリ (発行会社によるオーソリ成功に基づく)、支払い (支払い試行に基づく)、支払い拒否 (カード発行会社による支払い拒否に基づく)、不審請求の申請 (不正使用として不審請求の申請が行われた以前の取引)、ブロック (Radar の機械学習によるブロックに基づく) を含む、支払い結果に基づく属性もあります。結果は、顧客の詳細 (メールアドレス、IP アドレス、氏名、または顧客 ID) と組み合わされて属性を形成します。

さらに、顧客の詳細 (メールアドレス、氏名) の頻度を、取引に使用されたカードや IP アドレスと組み合わせることもできます。言い換えると、頻度ルールには 2 つのタイプがあります。

  1. 結果がオーソリ成功、支払い試行、支払い拒否、不審請求の申請、ブロックの場合の支払い結果に基づく (authorized_charges_per_email_hourlyblocked_charges_per_email_hourly など)
  2. 顧客の情報とカードまたは IP の間のリンクに基づく (name_count_for_card_weeklyemail_count_for_ip_hourly など)

頻度ルールでは、現在処理中の決済は含まれません。たとえば、authorized_charges_per_email_hourly は、過去 1 時間に特定のメールアドレスから発生した、支払い試行の成功数を示します。このため、特定時間における特定のメールアドレスからの初回の支払い試行では、authorized_charges_per_email_hourly の値は 0 です。初回が成功すると、同じ 1 時間内におけるそのメールアドレスからの 2 番目の支払い試行では、値は 1 となります。

属性
説明

:authorized_charges_per​_card_number_all_time:

アカウントで、このカードのオーソリに成功した支払い件数。2020 年以降の支払いが対象となります。(注: 上限は <= 25)

:authorized_charges_per​_card_number_weekly:

アカウントで、過去 1 週間にこのカードのオーソリに成功した支払い件数。(注: 上限は <= 25)

:authorized_charges_per​_card_number_daily:

アカウントで、過去 1 日間にこのカードのオーソリに成功した支払い件数。(注: 上限は <= 25)

:authorized_charges_per​_card_number_hourly:

アカウントで、過去 1 時間にこのカードのオーソリに成功した支払い件数。(注: 上限は <= 25)

:authorized_charges_per​_email_all_time:

アカウントで、このメールアドレスからのオーソリに成功した支払い件数。2020 年以降の支払いが対象となります。(注: 上限は <= 25)

:authorized_charges_per​_email_weekly:

アカウントで、過去 1 週間にこのメールアドレスからのオーソリに成功した支払い件数。(注: 上限は <= 25)

:authorized_charges_per​_email_daily:

アカウントで、過去 1 日間にこのメールアドレスからのオーソリに成功した支払い件数。(注: 上限は <= 25)

:authorized_charges_per​_email_hourly:

アカウントで、過去 1 時間にこのメールアドレスからのオーソリに成功した支払い件数。(注: 上限は <= 25)

:authorized_charges_per​_ip_address_all_time:

アカウントで、この IP アドレスからのオーソリに成功した支払い件数。2020 年以降の支払いが対象となります。(注: 上限は <= 25)

:authorized_charges_per​_ip_address_weekly:

アカウントで、過去 1 週間にこの IP アドレスからのオーソリに成功した支払い件数。(注: 上限は <= 25)

:authorized_charges_per​_ip_address_daily:

アカウントで、過去 1 日間にこの IP アドレスからのオーソリに成功した支払い件数。(注: 上限は <= 25)

:authorized_charges_per​_ip_address_hourly:

アカウントで、過去 1 時間にこの IP アドレスからのオーソリに成功した支払い件数。(注: 上限は <= 25)

:authorized_charges_per​_customer_daily:

過去 24 時間に、アカウントで特定の顧客が正常にオーソリされた回数。(カウントには、現在評価中の支払いは含まれません。)

:authorized_charges_per​_customer_hourly:

過去 1 時間に、アカウントで特定の顧客が正常にオーソリされた回数。(カウントには、現在評価中の支払いは含まれません。)

:blocked_charges_per​_card_number_daily:

過去 24 時間に、アカウントで Stripe の機械学習モデルによって 1 つのカード番号がブロックされた回数。カウントには、現在評価中の支払いは含まれません。(例: 4)

:blocked_charges_per​_card_number_hourly:

過去 1 時間に、アカウントで Stripe の機械学習モデルによって 1 つのカード番号がブロックされた回数。カウントには、現在評価中の支払いは含まれません。(例: 4)

:blocked_charges_per​_customer_daily:

過去 24 時間に、アカウントで Stripe の機械学習モデルによって特定の顧客がブロックされた回数。カウントには、現在評価中の支払いは含まれません。(例: 4)

:blocked_charges_per​_customer_hourly:

過去 1 時間に、アカウントで Stripe の機械学習モデルによって特定の顧客がブロックされた回数。カウントには、現在評価中の支払いは含まれません。(例: 4)

:blocked_charges_per​_ip_address_daily:

過去 24 時間に、アカウントで Stripe の機械学習モデルによって 1 つの IP アドレスがブロックされた回数。カウントには、現在評価中の支払いは含まれません。(例: 4)

:blocked_charges_per​_ip_address_hourly:

過去 1 時間に、アカウントで Stripe の機械学習モデルによって 1 つの IP アドレスがブロックされた回数。カウントには、現在評価中の支払いは含まれません。(例: 4)

:total_charges_per​_card_number_daily:

過去 24 時間に、アカウントに登録されているあるカードに対して支払いが試みられた回数。この回数には、現在評価中の支払いは含まれません。(例: 4)

:total_charges_per​_card_number_hourly:

過去 1 時間に、アカウントで 1 つのカードに対して支払いが試みられた回数。カウントには、現在評価中の支払いは含まれません。(例: 4)

:total_charges_per​_customer_daily:

過去 24 時間に、アカウントで特定の顧客が支払いを試みた回数。カウントには、現在評価中の支払いは含まれません。(例: 4)

:total_charges_per​_customer_hourly:

過去 1 時間に、アカウントで特定の顧客が支払いを試みた回数。カウントには、現在評価中の支払いは含まれません。(例: 4)

:total_charges_per​_ip_address_daily:

過去 24 時間に、アカウントで 1 つの IP アドレスが支払いを試みた回数。カウントには、現在評価中の支払いは含まれません。(例: 4)

:total_charges_per​_ip_address_hourly:

過去 1 時間に、アカウントで 1 つの IP アドレスが支払いを試みた回数。カウントには、現在評価中の支払いは含まれません。(例: 4)

:declined_charges_per​_card_number_daily:

過去 24 時間に、アカウントで 1 つのカード番号がカード発行会社によって拒否された回数。カウントには、現在評価中の支払いは含まれません。(例: 4)

:declined_charges_per​_card_number_hourly:

過去 1 時間に、アカウントで 1 つのカード番号がカード発行会社によって拒否された回数。カウントには、現在評価中の支払いは含まれません。(例: 4)

:declined_charges_per​_customer_daily:

過去 24 時間に、アカウントで特定の顧客がカード発行会社によって拒否された回数。カウントには、現在評価中の支払いは含まれません。(例: 4)

:declined_charges_per​_customer_hourly:

過去 1 時間に、アカウントで特定の顧客がカード発行会社によって拒否された回数。カウントには、現在評価中の支払いは含まれません。(例: 4)

:declined_charges_per​_ip_address_daily:

過去 24 時間に、アカウントで 1 つの IP アドレスがカード発行会社によって拒否された回数。カウントには、現在評価中の支払いは含まれません。(例: 4)

:declined_charges_per​_ip_address_hourly:

過去 1 時間に、アカウントで 1 つの IP アドレスがカード発行会社によって拒否された回数。カウントには、現在評価中の支払いは含まれません。(例: 4)

:declined_charges_per​_email_all_time:

アカウントで、このメールアドレスから拒否された支払い件数。2020 年以降の支払いが対象となります。(注: 上限は <= 25)

:declined_charges_per​_email_weekly:

アカウントで、過去 1 週間にこのメールアドレスから拒否された支払い件数。(注: 上限は <= 25)

:declined_charges_per​_email_daily:

アカウントで、過去 1 日間にこのメールアドレスから拒否された支払い件数。(注: 上限は <= 25)

:declined_charges_per​_email_hourly:

アカウントで、過去 1 時間にこのメールアドレスから拒否された支払い件数。(注: 上限は <= 25)

:dispute_count_on_ip_all_time:

アカウントで、この IP アドレスからの支払いに対し発生した不正利用に関する申請件数。この値には、2020 年以降の支払いが含まれます。(注: 上限は <= 25)

:dispute_count_on_ip_weekly:

アカウントで、この IP アドレスからの支払いに対し、過去 1 週間に発生した不正利用に関する申請件数。(注: 上限は <= 25)

:dispute_count_on_ip_daily:

アカウントで、この IP アドレスからの支払いに対し、過去 1 日に発生した不正利用に関する申請件数。(注: 上限は <= 25)

:dispute_count_on_ip_hourly:

アカウントで、この IP アドレスからの支払いに対し、過去 1 時間に発生した不正利用に関する申請件数。(注: 上限は <= 25)

:email_count_for​_card_all_time:

アカウントでの取引のうち、このカードに関連付けられたメールアドレスの件数。2020 年以降の支払いが対象となります。(注: 上限は <= 25)

:email_count_for​_card_weekly:

過去 1 週間に行われたアカウントでの取引のうち、このカードに関連付けられたメールアドレスの件数。(注: 上限は <= 25)

:email_count_for​_card_daily:

過去 1 日間に行われたアカウントでの取引のうち、このカードに関連付けられたメールアドレスの件数。(注: 上限は <= 25)

:email_count_for​_card_hourly:

過去 1 時間に行われたアカウントでの取引のうち、このカードに関連付けられたメールアドレスの件数。(注: 上限は <= 25)

:email_count_for​_ip_all_time:

アカウントでの取引のうち、この IP アドレスに関連付けられたメールアドレスの件数。2020 年以降の支払いが対象となります。(注: 上限は <= 25)

:email_count_for​_ip_weekly:

過去 1 週間に行われたアカウントでの取引のうち、この IP アドレスに関連付けられたメールアドレスの件数。(注: 上限は <= 25)

:email_count_for​_ip_daily:

過去 1 日間に行われたアカウントでの取引のうち、この IP アドレスに関連付けられたメールアドレスの件数。(注: 上限は <= 25)

:email_count_for​_ip_hourly:

過去 1 時間に行われたアカウントでの取引のうち、この IP アドレスに関連付けられたメールアドレスの件数。(注: 上限は <= 25)

:name_count_for​_card_all_time:

アカウントでの取引のうち、このカードに関連付けられた名前の件数。2020 年以降の支払いが対象となります。(注: 上限は <= 25)

:name_count_for​_card_weekly:

過去 1 週間に行われたアカウントでの取引のうち、このカードに関連付けられた名前の件数。(注: 上限は <= 25)

:name_count_for​_card_daily:

過去 1 日間に行われたアカウントでの取引のうち、このカードに関連付けられた名前の件数。(注: 上限は <= 25)

:name_count_for​_card_hourly:

過去 1 時間に行われたお客様のアカウントでの取引のうち、このカードに関連付けられた名前の件数。(注: 上限は <= 25)

:total_charges_per​_card_number_all_time:

アカウントでの、このカードの支払い合計件数。2020 年以降の支払いが対象となります。(注: 上限は <= 25)

:total_charges_per​_card_number_weekly:

アカウントでの、過去 1 週間におけるこのカードの支払い合計件数。(注: 上限は <= 25)

:total_charges_per​_card_number_daily:

アカウントでの、過去 1 日間におけるこのカードの支払い合計件数。(注: 上限は <= 25)

:total_charges_per​_card_number_hourly:

アカウントでの、過去 1 時間におけるこのカードの支払い合計件数。(注: 上限は <= 25)

:total_charges_per​_email_all_time:

アカウントでの、このメールアドレスからの支払い合計件数。2020 年以降の支払いが対象となります。(注: 上限は <= 25)

:total_charges_per​_email_weekly:

アカウントでの、過去 1 週間におけるこのメールアドレスからの支払い合計件数。(注: 上限は <= 25)

:total_charges_per​_email_daily:

アカウントでの、過去 1 日間におけるこのメールアドレスからの支払い合計件数。(注: 上限は <= 25)

:total_charges_per​_email_hourly:

アカウントでの、過去 1 時間におけるこのメールアドレスからの支払い合計件数。(注: 上限は <= 25)

:total_charges_per​_ip_address_all_time:

アカウントでの、この IP アドレスからの合計支払い件数。2020 年以降の支払いが対象となります。(注: 上限は <= 25)

:total_charges_per​_ip_address_weekly:

アカウントでの、過去 1 週間におけるこの IP アドレスからの支払い合計件数。(注: 上限は <= 25)

:total_charges_per​_ip_address_daily:

アカウントでの、過去 1 日間におけるこの IP アドレスからの支払い合計件数。(注: 上限は <= 25)

:total_charges_per​_ip_address_hourly:

アカウントでの、過去 1 時間におけるこの IP アドレスからの支払い合計件数。(注: 上限は <= 25)

カードの詳細に基づいた属性

属性
説明

:card_bin:

支払いに使用されているカードの銀行識別番号 (BIN)。カード番号の最初の 6 桁です ('424242' など)。

:card_brand:

支払いに使用されているカードブランド。サポートされる値は、'amex' (アメリカン・エキスプレス)、'visa' (Visa)、'mc' (Mastercard)、'dscvr' (ディスカバー)、'diners' (ダイナースクラブ)、'interac' (Interac)、'jcb' (JCB)、'cup' (銀聯) です。

:card_country:

カードが発行された国に対応する 2 文字のコード ('US' など)。国コードの一覧については、こちらのページを参照してください。複数の国を指定するには、IN 演算子を使用して IN ('GB', 'DE', 'AE') のようにします。

:card_fingerprint:

支払いに使用されているカードのフィンガープリント。カードフィンガープリントは、特定のカード番号の一意の識別子です。この番号は、「支払い」の下に移動して「決済手段」セクションで支払いを調べると確認できます ('VfE3rx3VlaQhS8Lp' など)。大文字と小文字は区別されます。

:card_funding:

プリペイドカード、デビットカード、クレジットカードなどのカードの種類。サポートされる値は、 'credit'、'debit'、'prepaid'、'unknown' です。

:card_3d_secure_support:

支払いに使用されているカードの 3D セキュアのサポートレベル。サポートされる値は、'required'、'recommended'、'optional'、'not_supported' です。

決済の詳細に基づいた属性

属性
説明

:amount_in_xyz:

xyz で指定された通貨に換算された支払い額 (amount_in_usd など)。サポートされる通貨である aud、brl、cad、chf、dkk、eur、gbp、hkd、inr、jpy、mxn、nok、nzd、ron、sek、sgd、usd のいずれかを指定すると、Stripe は使用する換算後の金額を自動的に計算します。下位の単位は使用しないでください。たとえば、セントではなくドルを使用します。(:amount_in_usd: > 250 など)

:average_usd_amount​_attempted_on_card_all_time:

アカウントで、このカードを対象に試行された取引の平均金額 (USD)。2020 年以降の支払いが対象となります。

:average_usd_amount​_successful_on_card_all_time:

アカウントで、カードのオーソリが発生した取引の平均金額 (USD)。2020 年以降の支払いが対象となります。

:risk_level:

Stripe によって決定された特定の支払いのリスクレベル。サポートされる値は、‘normal’、‘elevated’、‘highest’、‘not_assessed’ です。

:risk_score:

Stripe によって決定された特定の支払いのリスクスコア (たとえば、> 50)。値の範囲は 0 (最もリスクが低い) から 100 (最もリスクが高い) です。65 以上のリスクスコアは ‘elevated’ のリスクレベルに該当し、75 以上のリスクスコアは ‘highest’ のリスクレベルに該当します。

:charge_description:

支払い時に提供された説明 (‘Class trial’ など)。

:is_recurring:

支払いが (サブスクリプションなどによる) 継続的なものであるかどうかを示します。(これは Boolean なので、True の場合は :is_recurring:、True でない場合は NOT :is_recurring: を使用します。!= を使用することはできません。)

:is_off_session:

Stripe Billing の支払いがユーザーの直接的な行動によってトリガーされたものではない場合、または PaymentIntent の確認で off_session フラグが設定されている場合を示します。(これは Boolean なので、True の場合は :is_off_session:、True でない場合は NOT :is_off_session: を使用します。!= を使用することはできません。)

:digital_wallet:

決済情報の保存に使用されるデジタルウォレットのタイプ。サポートされる値は、‘android_pay’、‘amex_express_checkout’、‘apple_pay’、‘masterpass’、‘samsung_pay’、‘unknown’、’visa_checkout’、‘none’ です。

:destination:

デスティネーション支払いを作成する Connect ユーザーの場合、代わりに支払いを行うデスティネーションアカウント (‘acct_19KCB9AlaaEw6AgR’ など)。大文字と小文字は区別されます。

:is_checkout:

Checkout で支払いが処理されるかどうかを示します。この属性は、新しいバージョンの Checkout で処理された支払いにのみ適用され、従来の Checkout での支払いはキャプチャーされません。(これは Boolean なので、True の場合は :is_checkout:、True でない場合は NOT :is_checkout: を使用します。!= を使用することはできません。)

:is_3d_secure​_authenticated:

認証を使用して正常に完了した 3D セキュア検証の後に支払いを行うかどうかを示します。認証はリスクベースまたはチャレンジベースのいずれかとなります。(これは Boolean なので、True の場合は :is_3d_secure_authenticated:、True でない場合は NOT :is_3d_secure_authenticated: を使用します。!= を使用することはできません。)

:is_3d_secure:

支払いで 3D セキュアソースが使用されているかどうかを示します。(これは Boolean なので、True の場合は :is_3d_secure:、True でない場合は NOT :is_3d_secure を使用します。!= を使用することはできません。)

:has_liability_shift:

この支払いについて不正使用に関するライアビリティ がシフトした場合は True。(これは Boolean なので、True の場合は :has_liability_shift:、True でない場合は NOT :has_liability_shift を使用します。!= を使用することはできません。)

:seconds_since_card​_first_seen:

支払いのカードがアカウントで最初に確認されてからの秒数。2020 年以降の支払いが対象となります。

:seconds_since_first_successful​_auth_on_card:

支払いに関連付けられたカードの最初のオーソリが、アカウントで成功してからの秒数。2020 年以降の支払いが対象となります。

:total_usd_amount_failed​_on_card_all_time:

アカウントで、このカードからの取引のうち失敗 (ブロック、または拒否された) した取引の合計金額 (USD)。2020 年以降の支払いが対象となります。

:total_usd_amount_successful​_on_card_all_time:

アカウントで、カードのオーソリが発生した取引の合計金額 (USD)。2020 年以降の支払いが対象となります。

顧客の詳細に基づいた属性

属性
説明

:ip_country:

支払い元の IP アドレスの国に対応する 2 文字のコード ('GB' など)。国コードの一覧については、こちらのページを参照してください。複数の国を指定するには、IN 演算子を使用して IN ('GB', 'DE', 'AE') のようにします。

:ip_address:

支払い元の IP アドレス。(1 つの IP アドレスを指定するには、'192.168.0.1' などを使用します。指定する範囲を広げる場合は、INCLUDES '192.168' を使用すると、最初の 6 桁を共有するすべての IP アドレスを含めることができます。)

:is_anonymous_ip:

支払い元の IP アドレスが既知のプロキシなのか Tor 出口ノードなのかを示します。この情報は毎日更新されます。(これは Boolean なので、True の場合は :is_anonymous_ip:、True でない場合は NOT :is_anonymous_ip: を使用します。!= を使用することはできません。)

:is_my_login_ip:

支払い元の IP アドレスが Stripe アカウントへのログインに使用されたことがあるかどうかを示します。この属性は、「is my IP address」 の代わりに使用できます。(これは Boolean なので、True の場合は :is_my_login_ip:、True でない場合は NOT :is_my_login_ip: を使用します。!= を使用することはできません。)

:email:

支払い時に提供されたメールアドレス ('user@example.com' など)。

:email_domain:

支払い時に提供されたメールアドレスのドメイン ('example.com' など)。

:is_disposable_email:

支払い時に提供されたメールアドレスが、既知の使い捨てメールアドレスプロバイダーで使用されているものであるかどうかを示します。Stripe はこの属性を提供するために、使い捨てのメールアドレスに対応するドメインリストを保有しています。(これは Boolean なので、True の場合は :is_disposable_email:、True でない場合は NOT :is_disposable_email: を使用します。!= を使用することはできません。)

:billing_address:

指定されたカード保有者の完全な請求先住所。('510 Townsend, San Francisco, CA 94110' など)

:billing_address_line1:

カード保有者の指定された請求先住所の 1 行目。通常は町名と番地。('510 Townsend' など)

:billing_address_line2:

カード保有者の指定された請求先住所の 2 行目。通常は建物名と部屋番号。('Apt 5b' など)

:billing_address_postal_code:

カード保有者の指定された請求先住所の郵便番号 (ZIP)。('94110' など)

:billing_address_city:

カード保有者の指定された請求先住所の市区町村。('San Francisco' など)

:billing_address_state:

カード保有者の指定された請求先住所の都道府県/州。 ('CA' など)

:billing_address_country:

カード保有者の請求先住所の国に対応する 2 文字のコード ('US' など)。国コードの一覧については、こちらのページを参照してください。複数の国を指定するには、IN 演算子を使用して IN ('US', 'DE', 'AE') のようにします。

:seconds_since​_email_first_seen:

支払いで入力されたメールアドレスがアカウントで最初に確認されてからの秒数。2020 年以降の支払いが対象となります。

:seconds_since​_email_first_seen_on_stripe:

支払いで入力されたメールアドレスが Stripe 全体で最初に確認されてからの秒数。2020 年以降の支払いが対象となります。

:shipping_address:

指定された完全な配送先住所。('510 Townsend, San Francisco, CA 94110' など)

:shipping_address_line1:

指定された配送先住所の 1 行目。通常は町名と番地。('510 Townsend' など)

:shipping_address_line2:

指定された配送先住所の 2 行目。通常は建物名と部屋番号。('Apt 5b' など)

:shipping_address_postal_code:

指定された配送先住所の郵便番号 (ZIP)。('94110' など)

:shipping_address_city:

指定された配送先住所の市区町村。('San Francisco' など)

:shipping_address_state:

指定された配送先住所の都道府県/州。 ('CA' など)

:shipping_address_country:

指定された配送先住所の国に対応する 2 文字のコード ('US' など)。国コードの一覧については、こちらのページを参照してください。複数の国を指定するには、IN 演算子を使用して IN ('US', 'DE', 'AE') のようにします。

以下は、標準的な属性の使用例です。

  • Block if :card_country: IN ('CA', 'DE', 'AE')

このルールを使用すると、カナダ、ドイツ、アラブ首長国連邦で発行されたカードからの支払いはブロックされます。

タイプ 3

メタデータ属性: これらの属性は、お客様が Stripe に送信する属性によって決まります。これらの属性では、::Customer Age:: のように標準属性の前後に 2 重のコロンを使用する必要があります。メタデータ属性は、文字列または数値として機能できます。文字列として使用された場合には、メタデータ属性では大文字と小文字が区別されます

メタデータを使用して、購入された SKU に基づいて支払いを手動レビュー対象としたり、またはリピート顧客の負担を減らすなどの、非常に強力なルールを作成できます。より多くのメタデータを渡す方法については、ガイドをご覧ください。

メタデータ属性は、以下の構造で記述されます。

  • ::[メタデータ属性名]:: [演算子] [メタデータ値]

メタデータフィールドに、以下のキーと値のデータが保存された決済があると仮定します。

メタデータ名
メタデータ値
Customer age
22
Item ID
5A381D
Category ID
groceries

以下の条件に一致する決済をレビュー対象とするルールを記述できます。

  • Review if ::Customer Age:: < 30

さらに、このドキュメントで触れたメタデータ属性とサポートされるその他の属性の両方を使用してルールを記述できます。たとえば、Item ID が 5A381D に一致し、および決済額が US$1,000 を超える決済のみをレビュー対象にするルールを記述できます。

  • Review if ::Item ID:: = '5A381D' and :amount_in_usd: > 1000

メタデータ属性は、複数の値に対して照合する IN 演算子もサポートしています。たとえば、Category ID が「groceries」、「electronics」または「clothing」のいずれかの場合にレビュー対象にするルールを記述できます。

  • Review if ::Category ID:: IN ('groceries', 'electronics', 'clothing')

INCLUDES 演算子は、メタデータ属性とその他の文字列属性のルールで使用して、文字列の部分を照合できます。たとえば、Item ID に文字列 A381 が含まれる場合に決済をレビュー対象にするルールを記述できます。このルールは、「A381」、 「5A381D」、「A381D」、「5A381」などに一致します。

  • Review if ::Item ID:: INCLUDES 'A381'

メタデータには、Customer オブジェクトと Destination オブジェクトでもアクセスできます (これらのオブジェクトが特定の決済で使用された場合)。これらの属性は、以下の構造で記述されます。

  • ::[customer|destination]:[metadata attribute name]::[operator][metadata_value]:

以下のメタデータを持つ顧客がいると仮定します。

メタデータ名
メタデータ値
Trusted
true

顧客の Trusted メタデータフィールドが true の場合は常に支払いを許可するというルールを作成できます。

  • Allow if ::customer:Trusted:: = 'true'

または、デスティネーションに以下のメタデータがある場合:

メタデータ名
メタデータ値
Category
new

デスティネーションの Category メタデータフィールドが new の場合に、決済をレビュー対象とするルールを記述できます。

  • Review if ::destination:Category:: = 'new'

ルールで保存されたリストを使用する (許可リストやブロックリストなど)

以前に作成したリスト (許可リストやブロックリストなど) を通じて、ルールで値のグループを参照できます。メールアドレスのリストをブロックするには、ブロックする各メールに対してルールを作成する代わりに、ブロックリストを作成します。

ルールで参照されるすべてのリストエイリアスは、 @ で始まる必要があります。リストを参照するルールを作成するには、以下の構造に従う必要があります。

  • {action} [attribute] in [list]

たとえば、ブロックしようとしているカード国のリストがあるとします。この場合、いくつかの OR 句を使用してルールを記述します。

  • Block if :card_country: = 'CA' OR :card_country: = 'DE' OR :card_country: = 'AE'

または、インラインリストを使用してリストを記述することもできます。

  • Block if :card_country: IN ('CA', 'DE', 'AE')

または、card_countries_to_block という名前の、ブロック対象のカード国のリストを作成することもできます。国をそのリストに追加し、リストをルールで参照します。

  • Block if :card_country: in @card_countries_to_block

リストを使用したルールは簡潔であるだけでなく、編集や多数のアイテムの追加が容易です。

メモ: EU の加盟店は、Geo-blocking Regulation によって EU 加盟国に在住の顧客からの支払いをブロックすることが禁じられていることに注意する必要があります。この規制の詳細については、こちらをご覧ください

複数の条件を組み合わせて複合ルールを記述する

演算子 ANDORNOT を使用して基本条件を組み合わせることにより、複合条件を作成できます。これらの演算子に対応する記号である &&||! も使用できます。Stripe は C、Python、SQL などのプログラミング言語と同様に、標準演算子の「優先順位」(演算の順序) に対応しています。たとえば、以下のような複合条件があるとします。

  • {condition_X} OR NOT {condition_Y} AND {condition_Z}

これは、以下のように解釈されます。

  • {condition_X} OR ((NOT {condition_Y}) AND {condition_Z})

括弧を使って、複合条件内のサブ条件をグループ化することもできます。たとえば、上の例を変更して、サブ述部の評価順序を明示的に変更することができます。

  • ({condition_X} OR (NOT {condition_Y})) AND {condition_Z}

  • {condition_X} OR NOT ({condition_Y} AND {condition_Z})

括弧を使用する位置が異なれば、複合条件の結果も異なります。

is_missing 関数は、OR または AND 結合でも使用できます。

  • Review if is_missing(:email_domain:) OR :email_domain: IN ('yopmail.net', 'yandex.ru')

または、欠落値がなければ is_missing 関数を使用することもできます。以下の場合、:ip_country: が欠落しておらず、かつ IP が US か PR であれば、決済をブロックします。

  • Block if !(is_missing(:ip_country:))AND :ip_country: IN ('US', 'PR')

バックテストのルール

ルール分析における一般的な考え方として、不正利用を防ごうとすると、誤検知によって正常な取引もブロックされる確率が高まります。バックテストを行うと、リスク選好度の範囲に収まるルールや、不審請求の申請の防止と誤検知増加の適度なバランスを保つルールを見つけることができます。ルールの影響を推定するには、Radar ダッシュボードにある過去 6 カ月間の取引データを組み合わせてバックテストを行い、より焦点を絞った分析を実施して、そのルールが最近適用されていた場合、どのように機能していたかを確認します。

ダッシュボードでバックテストを行う

不正使用とその他の正常な決済の構成要素の定義は、テストするルールタイプによって異なります。

ブロックルール

  • 不審請求の申請が行われた、不正使用の早期警告を受信した、または不正使用として返金された: 不正使用のために不審請求の申請や返金が行われた成功した支払い、または不正使用のために不審請求の申請や返金が行われた、レビュー対象となった成功した支払い

  • その他の成功した決済: 不正使用のために不審請求の申請や返金が行われなかった成功した支払いまたはレビュー対象となり、不正使用のために不審請求の申請や返金が行われなかった成功した支払い

  • 失敗した決済の試行: カード発行会社によって拒否されたまたは Radar によってブロックされた

レビュールール

  • 不審請求の申請が行われた、不正使用の早期警告を受信した、または不正使用として返金された: 不正使用のために不審請求の申請や返金が行われた成功した支払い

  • その他の成功した決済: 不正使用のために不審請求の申請や返金が行われなかった成功した支払い

  • 失敗した、またはすでにレビュー対象となった: カード発行会社によって拒否された、Radar によってブロックされた、またはレビュー対象となった成功した支払い (不審請求の申請や返金の状況に関係なく)

許可ルール

  • Stripe またはカスタムルールによってブロックされた: Radar によってブロックされた支払い

  • 不審請求が申請された、不正使用の早期警告を受信した、または不正使用として返金された: 不正使用のために不審請求の申請や返金が行われた成功した支払い、または不正使用のために不審請求の申請や返金が行われた、レビュー対象となった成功した支払い

  • その他の成功した、または銀行によって拒否された決済: カード発行会社によって拒否された、不審請求が申請されなかった成功した支払い、 または不正使用のために返金されたか、または不正使用のための返金が行われなかった、レビュー対象となった成功した支払い

カスタムのバックテストによる分析を実行する

Radar ダッシュボードのバックテスト機能は、過去 6 カ月間の取引に焦点を当て、不審請求の申請、不正使用の早期警告、および不正使用として返金された支払いを対象とします。

たとえば、(不正使用の早期警告のみに焦点を当てた) Visa 不正使用モニタリングプログラムの対象となるリスクがある場合や、特定の IP 国やウォレットタイプからの不正使用が最近急増している場合には、より的を絞って分析することもできます。このためには、Sigma で SQL クエリを構築するか、ダッシュボードで決済データのレポートをエクスポートして分析できます。カスタムのバックテストを行うことで、時間枠が柔軟になり (6 カ月以上)、より的を絞った分析が可能になります (たとえば、不審請求の申請のみや EFW のみなど)。以下のクエリ例では、$100 を超える取引の Visa 不正使用の早期警告 (EFW) について、最近高額取引で不正使用が急増していて、リスクスコアの高い取引で監視プログラムのリスクが発生していると仮定してバックテストを行っています。

Using fields and tables available in Sigma

with base as (
    select
        c.id,
        c.amount,
        c.captured,
        e.created as efw_created
    from charges c
    left join early_fraud_warnings on e.charge_id = c._id
    where card_brand = ‘visa’
    and (c.amount / 100) >= 100
    and c.captured >= dateadd(‘day’, -180, current_date)
)

select 
    count(case when efw_created >= dateadd(‘day’, -60, current_date) then id else null end) as fraud_charge_count,

sum(case when efw_created >= dateadd(‘day’, -60, current_date) then amount else null end) as fraud_amount,

count(case when efw_created is null and captured between dateadd(‘day’, -120, current_date) and dateadd(‘day’, -60, current_date) then id else null end) as false_positive_charge_count,

count(case when efw_created is null and captured between dateadd(‘day’, -120, current_date) and dateadd(‘day’, -60, current_date) then amount else null end) as false_positive_amount

from base

EFW 作成日を基に過去 60 日間のデータをバックテストすると、直近の不正利用に焦点を当てることができます。一方、過去 60 ~ 120 日間の不正利用以外の販売データをバックテストした場合は、より進化した不正利用を確認できます。

不正利用の一般的な傾向

不正利用者の大半は、共通のパターンで不正利用を行います。まず、盗んだ決済情報(カードなど)を認証します。決済情報が機能していることを確認したら、その認証情報を使用して、さまざまな形で価値を引き出します。具体的には、個人使用または転売のための物理的商品 (高級品や電化製品) やサービス (食品配達サービス)、または別の不正利用に役立つサービスや製品 (ウェブホスティングサービスやメッセージスパムサービスなど) です。

最も一般的な不正利用の傾向や、それらを Radar ルールで軽減する方法については、以下の詳細をご覧ください。

テスト

カードテスティングとは、不正利用者がスクリプトや手動プロセスによって、盗んだカード番号がまだ有効かどうかを確認することです。この段階の目的は、物理的商品やサービスを得ることではなく、カードの有効性を検証することです。このような支払いは、一般的には少額の取引やオーソリです。基本的にカードテスティングは、短時間に連続して高速で行われます。これを検出するには、以下のようなグループ分けや速度の機能が役立ちます。

  • total_charges_per_customer

  • card_count_for_email

  • card_count_for_ip_address

  • total_charges_per_ip

これらを回避するために、不正利用者は偽のメールアドレスを複数作成して、それらを使い分ける傾向があります。より高度なテクニックを使用する不正利用者は、IP アドレスを秘匿したり、複数のデバイスを用いたりして一意のデバイスデータを提供します。この時点では、正常かつ典型的な顧客の操作を把握しておくことが重要です。さまざまなカテゴリーの中でも、メールドメインや IP の割り当て国などは、高リスクの取引を判断するのに役立ちます。不正利用者の多くは、gmail.com など、広く知られたメールプロバイダーの一般的なメールドメインを使用します。gmail.comms や gomail.co などのドメインも見られますが、これらは不正利用者が身元を隠ぺいするために使用しています。カードの発行国と IP の割り当て国によって顧客を分類し、ユーザーベースに多い地域からの取引であるかを確認することもできます。それ以外の地域からの取引は、レビューやブロックの対象にできます。

このテスティング行為を抑止する最後の方法は、 CAPTCHA の設定です。

Stripe Checkout では、機械学習がカードテスティング攻撃を検知すると、CAPTCHA チャレンジが自動的に表示されます。Stripe はカードテスティングを減らすために、カードテスティングモデルのトレーニングとあわせて、レートリミッターやアラート、継続的なレビューなど、一連の自動および手動のコントロールによって攻撃を自動検出しています。これらのモデルは、カードテスティング攻撃の進行中にのみ CAPTCHA チャレンジを表示するため、実際のユーザーにはほとんど表示されず、ボットに対してのみ CAPTCHA が表示されます。これにより、Stripe Checkout を使用している事業者ではカードテスティングが 80% も減少しましたが、購入完了率への影響はほとんどありませんでした。

すべての Checkout ユーザーに、Stripe が管理する CAPTCHA を追加したところ、カードテスティングが 80% 減少し、オーソリ率への影響は 2bps (0.02%) 未満でした。

なお、「特定の IP アドレスについて 3 回を超えて支払いを拒否された場合はブロックする」といったカスタムルールを作成することでも、カードテスティング攻撃を減らすことができます。

値の抽出

盗難クレジットカード (新しい行為)

この不正利用ベクトルでは、不正利用者が、確認済みの盗難カードを自分の個人用デバイスまたは不正利用行為に利用するデバイスで使用します。

このベクトルは通常、スクリプト化された大規模攻撃、またはより標的を絞った不正組織による小規模な攻撃によって悪用されます。いずれにしても、hours_since_email_first_seen_on_stripe など、Stripe でアカウント登録をして間もないかを確認するルール属性と、risk_score やその他の機能を組み合わせて使用することで、このようなまったく新しいカード保有者を阻止できます。さらに、IP、メール、カードに速度制限をかけることにより、不正利用者が盗んだ認証情報をできるだけ速く金銭化しようとする大量の攻撃から加盟店を保護できます。

盗難クレジットカード (隠ぺい行為)

この不正利用ベクトルでは、不正利用者が、個人のデバイス、または不正利用行為に利用するデバイスで、確認済みの盗難カードを使用するか、またはサブスクリプションアカウントを侵害し、アカウントに保存されているクレジットカード情報にアクセスします。

不正利用者は以下の方法を利用して、できる限り自身の存在を隠ぺいしようとします。

  • 以前に完了した取引と同じ名前を使用する。

  • 以前に完了した取引と同じ請求先住所を使用する。

  • VPN を使用して、本来のカード保有者であるかのように見せかける。VPN で本来のカード保有者と同じ市や、時には同じ町内に見せかけることもあります。

  • メールアドレスや電話番号など、あまり目立たない詳細のみを変更する。

  • 物品の場合に、配送先住所を以前の取引のものから変更する。請求先住所と配送先住所の距離が大きく離れることもあります。この兆候はそれほど精度が高くありません。

上記で説明したような隠ぺい行為により、本来のカード保有者とアカウントを侵害した不正利用者のどちらが実際に取引を行っているかを解析することが困難になります。このため、加盟店も本来のカード保有者も、この種類の不正利用に長期間気付かないことがよくあります。

ここでも戦略は同じです。不正利用者は、盗んだ認証情報からできるだけ多くの価値を得ようとします。速度制限機能を使用するルールと、riskscore、cvccheck の失敗、または郵便番号の確認失敗を併用することにより、このような行為を防ぐことができます。

その他のベストプラクティス

以下に、Radar でのルール作成の最適化に役立つその他のベストプラクティスを紹介します。

決済フロー
決済フローには、利用規約への明示的な参照を含めます
チャージバックが発生した場合は、決済フローに表示される ToS のスクリーンショットを明確に示し、その重要性を説明します。そうすることで、相手の主張を退けられる可能性が高まります。
セキュリティコードと郵便番号の検証
カード発行会社がカード保有者を確認できるようにします。不審請求の申請に対する主張が認められる可能性が高まり、多くの場合、オーソリ率が向上します。確認に失敗したものはブロックすることを検討してください。
できるだけ多くの顧客情報を収集する
この詳細情報を収集することで、チャージバックの発生時にカード発行会社がケースを評価できるようになり、相手の主張を退けられる可能性が高まります。これはデューデリジェンスと見なされます。
代表的な情報としては、セキュリティコードと郵便番号、顧客の名前、メールアドレス、請求先住所、IP アドレス、デバイス情報などがあります。
Stripe.js を実装すると、Radar に IP アドレス、デバイス、行動に関する情報が提供され、不正使用の検知精度が向上します。
顧客とのやり取り
「不正請求」カテゴリーのチャージバックがあるカードをブロックリストに追加する
顧客が不正使用として支払いの不審請求を申請する場合、今後の支払いも不審請求を申請される可能性が高いです。
疑わしい支払いや不正な支払いに対する返金
TC40 の取引の 70 ~ 85% において不審請求の申請が行われています。不審請求の申請を防止するには、全額返金する以外に方法はありません。
明確な明細書表記を使用する
身に覚えがないという不審請求の申請件数を削減します。

Stripe.js を使用することの重要性

  • 不正使用の信号を最適化するため、stripe.js を支払いの完全なパスに含める
  • ページ読み込み時間に影響を与えずに Radar を最大利用するため、決済以外のページには stripe.js async を読み込む
  • 一番シンプルなのは Google Analytics スクリプトタグの横に挿入すること
  • gzip で圧縮された stripe.js バンドルの全体サイズは 29.6kb
    • 今後の状況: radar.js を stripe.js とは別に含められるようになる予定

結論

ルールは、不正使用に対する保護をカスタマイズする上で非常に強力なツールとなり得ます。このガイドで説明されている、ベストプラクティスに基づいた一意のロジックを実装することで、Radar にお客様のビジネスニーズ特有の不正防止設定を作成できます。

Radar for Teams の詳細については、こちらをご覧ください。

Radar for Teams をすでにお使いの場合には、ダッシュボードでルールのページを参考にして、ルールの記述を開始できます。

その他のメモ

プラットフォームでの Radar

Stripe Connect をお使いのプラットフォームの場合には、お客様が作成するルールはプラットフォームアカウントで作成された決済のみに適用されます (Connect の用語では、これらはデスティネーション支払いまたは代理支払いと呼ばれます)。
連結アカウントで直接作成された決済は、そのアカウントのルールの対象となります。

Terminal での Radar

Terminal の支払いは、Radar で評価されません。このため、Terminal を使用する場合、IP の頻度に基づいたルールを記述しても、対面支払いをブロックする心配はありません。

今すぐ始めましょう

アカウントを作成し、支払いの受け付けを開始しましょう。契約や、銀行情報の提出などの手続きは不要です。貴社ビジネスに合わせたカスタムパッケージのご提案については、営業担当にお問い合わせください。