カード支払いをレビューする

Stripe の自動化されたシステムはお客様のアカウントに対する不正利用を防止するよう機能しますが、審査を使用して、手動でカード決済を検査することにより、さらに不正利用対策を強化できます。

たとえば、以下のような取引は審査が必要になる場合があります。

• Stripe の不正防止システムによって、不正利用のリスクが比較的高いとマークされた
• お客様の国以外からの取引である
• 一定の金額を超えている
• 通常とは異なるドメインのメールアドレスを使用している

Stripe Radar for Teams の審査リストを使用すれば、通常とは異なる支払いを調べる際に各支払いを個別に見直す必要がなくなります。任意に条件を指定してターゲットを絞った支払いリストを作成し、ダッシュボードから審査できます。

支払いのレビュー

ダッシュボードのレビューリストは、詳細な調査が必要になる可能性のある、完了した支払いまたはキャプチャーされる支払いの優先順位が付けられたリストです。次の方法で支払いを確認できます。

• リストビュー: 各支払いの詳細を表示せずにレビューのリストをスキャンします。
• 詳細ビュー: 特定のレビュー項目のカスタマイズ可能な支払いコンテキストを確認します。

リストビュー

リストビューには、各支払いの不正使用リスクを素早く判断するために役立つ情報が含まれています。

Stripe ダッシュボードの手動審査キュー

リストビューでは以下の情報が重要です。

• 支払いの評価後に Stripe が割り当てるリスクレベル。
• 顧客名
• 支払い方法に関する情報
• 顧客情報
• 支払い金額、日付、時刻
• クライアント

詳細ビュー

レビューリスト内で支払いを選択すると、その詳細ページが表示されます。詳細ページには、決定に役立つメタデータが含まれている可能性があります。前へボタンと次へボタンを使用して、レビュー対象の支払い間を移動できます。

Stripe Radar の AI モデルは、支払いにスコアを付ける際に数百ものシグナルを評価します。支払いページのリスクに関するインサイトセクションには、最も関連性の高いシグナルのいくつかが、支払いの不正利用の評価に役立ついくつかの主要データポイントとともに表示されます。関連する支払いセクションには、現在審査中の支払いと同じメールアドレス、IP アドレス、またはカード番号を使用して行われた他の支払いが表示されます。

Smart Refunds

Radar for Fraud Teams ユーザーは、不正利用リスクが高いと予測されるため、スマート返金を使用して、返金の支払いに関する推奨事項を受け取ることができます。スマート返金は、Radar AI モデルを使用して、取引が不正な不審請求の申し立てにつながる可能性を評価します。この可能性は、取引の完了後数時間に Stripe が処理する他の取引からの追加のシグナルに基づいています。スマート返金を使用すると、Radar は支払いの完了後まで不正防止を拡張します。

You can view Smart Refunds recommendations in the Smart Refunds quick filter in the Dashboard review queue. By default, you see recommendations that have a high or very high likelihood of turning into an early fraud warning or fraudulent dispute. You can view additional Smart Refunds recommendations by changing the Refund confidence level. The following table shows the expected chance of an early fraud warning or fraudulent dispute at each refund confidence level.

アクション

完了した支払いの審査後は、以下のアクションのいずれかを行うことで、審査リストからその支払いを削除できます。

• 承認: 支払いに変更を加えずに審査を終了します。承認済みの支払いについては、引き続き返金を行い、必要に応じて不正利用を報告できます。
• 後で支払いをキャプチャーする場合は、キャプチャー ボタンもあります。承認の前または後に支払いをキャプチャーできます。
• 返金: Stripe に不正利用として報告せずに支払いを返金します。返金が完了すると、アクションを取り消すことはできません。新しい支払いを処理する必要があります。後で支払いをキャプチャーすると、このボタンはキャンセルに変わります。この審査プロセスについてはこちらから詳細を確認できます。
• 返金して不正利用を報告: 支払いに返金するとともに Stripe に不正利用として報告し、たとえば不審請求の申請の処理手数料を節約します。これによって関連付けられているカードのフィンガープリントと顧客のメールアドレスがブロックリストに追加され、Stripe の不正防止効果が向上します。

レビューリストのカスタマイズ

Stripe Radar for Teams を使用することで、ビジネス固有のニーズに基づいて自動的に支払いを審査対象とするルールを作成できます。これにより、さらに調査が必要な支払いを識別してから、十分な情報に基づいて判断することができます。

レビューの割り当て

審査リストを管理している人物は、自身を審査に割り当て、作業の重複を防ぐことができます。

審査アは、他の人が処理している審査を確認でき、自身を審査に割り当てたり、割り当てを解除したりすることができます。また、審査リストをフィルタして自身に割り当てられている審査を確認したり、現在未割り当ての審査を調べることもできます。

リストビューで、クイックアクションまたはオーバーフローメニューを使用して、自身を審査に割り当てることができます。

リストビューで自分をレビューに割り当てるには、レビューにカーソルを合わせ、人物アイコンまたはオーバーフローメニューの自分に割り当てるボタンをクリックします ()。詳細ビューで、自分に割り当てるをクリックします。

別のチームメンバーに割り当てられたレビューに対してアクションを実行することも、そのようなレビューを自分に割り当てることもできます。レビュータイムラインには、割り当ての変更とその他のアクションの完全な履歴が表示されます。

詳細ビューのタイムラインには、割り当て変更の履歴が表示されます。

レビューイベントをリッスンする

レビューアクティビティに関連する Webhook イベントをリッスンして、関連する応答処理をトリガーできます。Stripe は、次のレビューイベントを送信します。

• review.opened: 取引がレビューリストに追加され、レビューオブジェクトが生成されたことを示します。
• review.closed: レビューオブジェクトがクローズされ、reason が提供されたことを示します。

ベストプラクティス

審査を最大限に活用し、効率的に作業するためには、以下のベストプラクティスを利用できます。

• 人間の判断によって決定に重要な洞察を加えることができる支払いに時間を集中する

  大半の支払いは、自動システムによって決定を下すことができますが、人間の方がシステムよりも非常に高い精度で不正利用を識別できるケースもあります。ただしすべてのケースで人間の関与が有益なわけではないため、明らかに有益だと思われる取引を選択してください。

• リスクに関する知見と関連付けられた支払いを使用して、情報に基づく決定をする

  リスクに関するインサイトセクションにあるデータを使用して、Stripe Radar が支払いに対してどのようにスコアを付けたかを確認します。スコアの理由、お客様のビジネスに関する知識、人間による不正取引の判別を組み合わせることで、Radar によって割り当てられたスコアを信頼するか無視するかを、状況に基づいて選択することができます。

• 審査担当者から得たインサイトを活用し、不正利用防止戦略のための仮説を立てる

  審査担当者が取引の調査を続けるにつれて、不正防止のための洞察力が鍛えられ、それを優れたルールの作成に活かすことができます。審査担当者からの知見を収集して、アカウントでカスタムルールをテストしましょう。

• 審査時にお客様のビジネスに独自のデータを提示してプロセスをカスタマイズする

  顧客や注文の追加情報をメタデータとして渡し、審査の際にダッシュボードであらゆる関連情報を使用できるようにします。有益なメタデータの例を紹介します。

  • 注文および配送情報に関する追加情報
  • Google マップ やストリートビューが顧客の配送先住所にリンクされるため、審査アはその住所がドロップシッピングや転送サービスであるかどうかを確認できます。

• 顧客の体験を滞らせない

  審査を行うということは、注文が行われてから配送までにしばらくかかる可能性があるということです。ビジネスの性質上このような遅延が存在する場合には (物品を配送する場合など)、取引の審査に時間をかけても顧客の配送の期待には影響しません。ただし、注文からフルフィルメントまでに遅延が発生しないビジネスの場合は、審査プロセスを追加すると注文が遅延し、問題のない顧客に対してボトルネックが生じることがあります。審査プロセスを導入する前に、顧客への影響を考慮してください。