不正使用防止のベストプラクティス
不審請求の申請と不正な支払いから保護するためのベストプラクティスは以下のとおりです。
お客様のビジネスに最適な効果的な不審請求の申請と不正使用を防止する戦略を立てることは、不正使用の発生防止に役立ちます。お客様の全体的戦略の一環としてこれらのベストプラクティスのいくつかを採用することにより、過度なチャージバックを防止し、顧客の負担や損失を軽減することができます。
あらゆる人が使用できるツール
開発者であるかどうか、Radar などの専門的な Stripe ツールを使用しているかどうかにかかわらず、すべての Stripe ユーザーが不正使用と不審請求の申請の問題を軽減するために活用できるツールをご紹介します。
顧客に明確かつ明白に対応する
顧客と頻繁に明確なコミュニケーションをとることで、不審請求の申請原因の多くを回避することができます。迅速に問題に対応し、返金や交換注文の処理を行うことで、顧客が支払いに対して不審請求を申請する機会を大幅に減らすことができます。また、カスタマーサービスの連絡先を目立つように表示し、顧客が常に注文プロセスや配送状況について最新状況を把握できるようにします。
注意
利用規約では、返金ポリシーとキャンセルポリシーを明確に記載します。ユーザーに利用規約への同意を求めることで、不審請求の申請が発生した場合にカード発行会社がお客様のポリシーを考慮する可能性を高めることができます。
一般に、利用規約およびポリシーは、ウェブサイト上の分かりやすい場所に提示し、顧客に同意するように要求します。決済時にリンクを表示するだけではなく、決済ページ上、またはポップアップ形式で全文を表示し、注文を送信する前の必要事項として顧客の同意を求めます。
カード発行会社は、顧客へのポリシーの提示方法について非常に厳密なことがあります。顧客が同意するチェックボックスにリンクしか含まれていない場合、カード発行会社は、顧客がポリシーを認識していたと判断するには不十分な証拠として、却下することがあります。購入の前に、顧客にポリシーの全文が提示されたという合理的な証拠が必要です。
顧客に物品を発送する場合には、できる限りオンライン追跡と配達確認に対応している運送業者やサービスを利用します。この情報は入手次第、すぐに顧客に提供します (不審請求の申請に対する反証資料として追跡情報を提出する場合には、カード発行会社はリンクにアクセスしないため、スクリーンショットを提出する必要があります)。
アカウント設定で明細書表記に分かりやすい名前を設定します。顧客が明細書で購入を簡単に確認できるように、貴社のウェブサイトドメインまたはビジネス名を使用することをお勧めします。
明細書表記は 5 ～ 22 文字です。5 文字以上で構成します。特殊文字
<,>、\、'、"は使用できません。異なる事業に同じ Stripe アカウントを使用することは避けてください。事業ごとに Stripe アカウントを 1 つ使用する必要があります。これにより、事業ごとに異なる明細書表記と連絡先情報を使用できます。複数の事業の支払いを処理する必要がある場合には、それぞれに追加アカウントを作成してください。
疑わしい支払いに対して事前に返金することを検討する
不正利用であることが確かな支払いに対しては即時に返金すべきです (3D セキュアなどの何らかの形でライアビリティシフトの対象となっている場合を除く)。不審請求の申請を受けることがわかっている場合は、不正な支払いに対して全額返金することで、不審請求の申請手数料、不審請求の申請率の増加、商品の潜在的損失を防ぐことができます。
注意
全額返金された支払いに対しては、顧客が不審請求の申請を行うことはできませんが、一部返金済みの支払いに対しては不審請求の申請を行うことができます。カードネットワークのルールでは、一部返金済みの支払いに対して全額返金を求める不審請求の申請を行うことができます。
ただし、支払いに不正使用の疑いがあっても、それが確信に至らない場合があります。こうした曖昧な分類の支払いに対して、積極的に返金することが合理的な場合と、そうでない場合があります。
以下のいずれかが該当する場合、積極的な返金戦略を実行することができます。
- まだフルフィルメントが行われていない注文。商品の損失は、返金によって防げる可能性があります。不正使用の疑いが発覚した時点で、商品またはサービスの提供を取り消せる場合は、より積極的に返金できます。一方、商品がすでに配送されていたり、サービスがすでに利用されている場合など、取り返しのつかない状態であれば、返金「せず」、不正使用であるかどうか様子を見る方が合理的です。
- 過度の不審請求の申請。カードネットワークの定義により、最近の不審請求の申請アクティビティが過度であると判断される場合です。貴社の Stripe アカウントの状態にリスクが及ぶ、またはチャージバックモニタリングプログラムの対象となるリスクが生じます。
- チャージバックモニタリングプログラム。すでにチャージバックモニタリングプログラムに登録されていて、プログラムを終了する必要がある場合です。
- 新規企業または中小企業。企業で発生する支払い額が相当に低い (たとえば、毎月 100 件の支払い) 場合です。この場合、不審請求の申請アクティビティがほとんど発生していなくても、数件の申請が、不審請求の申請率に非常に大きく影響することがあります。
上記のいずれも該当しない場合は、不正使用が疑われる支払いを事前に返金する頻度についてより慎重になることをお勧めします。
不正使用のための支払いの返金
支払いを返金するには、ダッシュボードで支払いを選択して、カード不正使用のため返金をクリックします。これにより、支払いが返金されるとともに Stripe に不正使用が報告され、不正使用検出機能の向上に役立てることができます。
注文配送の遅延
物品を発送する場合は、配送に 24 ～ 48 時間の遅延を設けることを検討します。この時間はカード保有者にアカウントでの不正使用を明らかにして報告する機会を与えます。このようなシナリオでも不審請求の申請を受ける可能性はありますが、少なくとも商品の損失を防げます。ただし、カード保有者の全員が毎日明細書をチェックしているわけではなく、またカード発行会社が取引について前もってカード保有者に連絡を取らない場合もあります。
翌日または急送便での配送をリクエストする顧客は高リスクであると考えるべきです。これは詐欺師にとって、そのようなサービス料金の増加はまったく影響しないためです。そのような種類の支払いを識別する方法の 1 つは、同日配送や翌日配送の料金を、提供している他の配送オプションと比較して何倍にもなる非常に高額な料金にすることです。
正当な顧客がこのような高い料金を支払う可能性がきわめて低いのに対して、商品をできるだけ早く配送してもらうことを望む不正使用者は、追加コストを気にしません。そこで、異常に高額の配送オプションを選んだ顧客を手動で選別し、注文を綿密に調査することで、正当な顧客かどうかを判断できます。オーソリとキャプチャーの分離プロセスを Radar 審査と併用するとよいでしょう。
確認済みの住所への配送
郵便番号と番地のチェックが適用された確認済みの請求先住所に配送することが、最も安全性の高いオプションです。確認されていない住所を使用すると、後で支払いに対する不審請求が申請された場合に、注文が正当なカード保有者に配送されたことを証明できません。
これは、異なる住所への配送を阻むものではありませんが、関連するリスクを低減するためにできる対策はすべて行う必要があります。たとえば、すでに正当であることがわかっているリピート顧客、または完全に確認可能な請求先住所を指定した顧客の場合にのみ、異なる住所に注文を配送することをお勧めします。また、以下のいずれかの項目は疑わしい支払いを表している可能性があります。
- 通常よりはるかに規模の大きな注文、または最も高価な商品のみの注文
- 注文後の顧客による配送先住所の変更
- 顧客が急送便での配送をリクエストした
- 再販価値の高い商品の注文
- 配送先が請求先住所またはカード発行国と異なる (請求先住所がスペインだが、配送先住所がフランスの場合など)
注文と配送先住所情報の審査は、注文に受け入れ難いリスクがあるかどうかを判断するのに役立ちます。
不審請求の申請率のベンチマーク
アカウントの不審請求の申請率は、不審請求の申請および不正防止対策の効果を確認する際に使用される重要な基準です。Stripe ダッシュボードで定期的にこれを確認して、不審請求の申請の防止対策の効果を測ることができます。
Radar for Teams のユーザー向けのツール
Radar は、不正利用に対処するために Stripe に組み込まれた一連の機能とツールであり、追加の導入作業を行う必要はありません。
手動での支払いの確認
Radar for Teamsには、特定の支払いを審査対象にできる審査機能が含まれています。ただし、オーソリとキャプチャーの分離プロセスを使用している場合を除き、対象となる支払いは引き続き処理され、クレジットカードへの請求が行われることに注意してください。これらの支払いは、より詳しく調査するために審査リストに追加されます。調べた結果、支払いに不正利用の疑いがあると判断した場合は、それを返金できます。
Stripe が審査リストに追加した支払いはできる限り早く審査する必要があります。不正利用に対する比較的リスクの高い支払いは、自動的に審査対象としてマークされます。追加のルールを作成して、審査リストへの追加が必要な支払いのタイプをカスタマイズすることもできます。
支払いを審査する際の考慮事項を以下に示します。
- 請求先住所と配送先住所が一致しているか。
- 請求先住所は AVS による検証を受けているか。また、カードの発行国と一致しているか。
- 顧客のメールアドレスとカード保有者の名前が一致しているか。
- 顧客から急送が依頼された注文であるか
- 同じ IP アドレスから異なるクレジットカードで複数の注文が実行されていないか。
- この顧客は支払い拒否された注文を多数試行していないか。
審査時に支払いに不明な点がある場合は、必ず電話またはメールで顧客に連絡してください。支払いの請求先住所と配送先住所が一致しない場合は、Google マップとストリートビューを使用して配送先住所を調査し、詳細を確認します。不正使用者がよく利用するのは、貨物/郵便物転送サービスや保管施設に注文を配送させ、そこから商品を実際の宛先に転送する方法です。
Radar ルールを使用して、支払いを自動的にブロックするか、審査の対象にする
Radar for Teams は、決済フローに直接組み込まれす。カスタマイズ可能なルールエンジンと高性能の機械学習アルゴリズムを組み合わせ、決済に Stripe を使用するすべてのビジネスの支払いのパターンを検出し、各支払いのリスクを評価します。
ルールを使用すると、特定の検出基準に基づいて支払いを自動的に評価し、適切な措置を取ることができます。また、複数の基準を使用するルールを作成することで、複数の条件に該当する支払いを許可またはブロックすることができます。事業ごとにリスクは異なります。
国およびカードタイプの制限
特定の国々からの不正使用が増加している場合、:ip_ および :card_ というルール属性を使用して、支払いを受け入れたくない国からの支払いをブロックするルールを設定できます。たとえば、Block if :ip_ というルールを作成して、カナダから行われた支払いとカナダで発行されたカードをブロックできます。同様に、ビジネスを運営している国のみに対応する場合、その他の国からのあらゆる支払いをブロックするルールを作成できます。たとえば、Block if :ip_ というルールは、オーストラリア以外から行われた支払いをブロックします。
ブランドごと (Mastercard など)、または資金調達タイプ (プリペイドなど) ごとに、受け付けるカードのタイプに制限を設定できます。これは特に、特定のカードタイプで過剰な不正使用が発生している場合に有益です。たとえば、Visa 発行のデビットカードからの支払いをブロックするルール例は、Block if :card_ のようになります。
開発者向けのツール
以下は、実装に開発作業が必要となるツールです。Stripe パートナーを利用して決済の実装を提供する場合、ご自身で直接実装することはできなくなります。
Stripe で取引を処理する
Visa Compelling Evidence 3.0 ルールでは、取引履歴を使用して、指定された期間における同じカード保有者との過去の不正利用ではない取引を提示することで、フレンドリー詐欺に異議を申し立てます。Visa 不正利用の不審請求の申請を受けた場合、Stripe は、プラットフォームの履歴で適格な取引を特定して、必要となる反証資料の大部分を不審請求の申請に対する回答に事前入力します。この反証資料を使用して、不審請求の申請を貴社の意向に沿ったかたちで覆すことができる確率を大きく高めます。
Stripe では、外部で処理された取引の適格性を判断したり、反証資料を提出することはできないため、以下をお勧めします。
- 可能な限り、Stripe の処理を使用する
- Stripe との取引に顧客の IP アドレス、メールアドレス、配送先住所、商品の説明を含める
できるだけ多くの支払い情報の収集
決済時に要求した情報が最小限だったために、不審請求の申請に対する主張が認められない結果に終わる場合があります。利用できる情報が少なければ、顧客が正当であるかどうかを Stripe やカード発行会社が判断することが困難 (時には不可能) になります。たとえば、カード決済の処理で請求先郵便番号は常に必要なわけではありませんが、これを含めることで、カード発行会社はその支払いを検証できるようになります。検証に失敗すれば、不正使用の兆候となりうるため、その支払いの拒否を検討します。
Checkout または高度な不正利用検知機能を使用すると、実装で以下のような決済関連情報を把握できます。
- 顧客の名前
- 顧客のメールアドレス
- セキュリティコード番号
- 請求先住所と郵便番号
- 配送先住所 (請求先住所と異なる場合)
- 追跡情報
3D セキュアなどのカード保有者の認証方法を実装する
3D セキュアは、顧客とカード発行会社の間での確認ステップを決済フローに追加するものです。3D セキュアによって認証された支払いは、ライアビリティシフトと呼ばれるルールを通じて、不正利用に関する申請のほとんどから保護される可能性があります。ただし、不正利用の早期警告は受けることになります。この警告はカードブランドモニタリングプログラムにおいて不利に作用します。
詳細については、カード認証と3D セキュアをご覧ください。
プログラムによる顧客の本人確認
場合によっては、顧客の本人確認を行うと有益です。Stripe Identity を使用して政府発行の身分証明書を確認し、証明書の保有者の顔写真と照合することを検討してください。あるいは、さらなる本人確認手段として、顧客に Facebook や LinkedIn のアカウントをリンクするように求めることもできます。これは、不正利用者が実行できない追加ステップになり得ます。正当な顧客の中にもこの追加ステップを希望しない人がいる場合もあるため、結果として購入完了率が低下する可能性があります。
支払い作成時のオーソリとキャプチャの使用
クレジットカードの支払い試行は 2 つの段階で処理されます。最初に支払いの「オーソリ」が行われ、支払い金額に対するカード発行会社のオーソリがリクエストされます。 支払いが承認されると、デフォルトでは、その後すぐに「キャプチャー」が行われ、カードからその金額が差し引かれます。
キャプチャーを後から行う決済フロー (「オーソリとキャプチャー」とも呼ばれます) とは、これらの 2 つのステップを別々に実行するプロセスです。オーソリをまず実行して、カードでその金額を確保します。これは顧客の明細書で、保留中取引として表示されますが、顧客の口座から資金が実際に移動されることはありません。この支払いは、オーソリ後、最長 7 日後までキャプチャーできます。支払いは、キャプチャーされると完了し、顧客のカードから支払い額が差し引かれます。期限内に支払いがキャプチャーされない場合は、オーソリは自動的にリリースされます。
遅延配送と同様に、この方法では潜在的な不正使用を明らかにするための十分な時間を確保でき、取引を慎重に確認し、場合によっては返金する機会が得られます。カード保有者が不審請求の申請を行えるのは、キャプチャーされた支払いだけであり、キャプチャー前のオーソリに対しては不審請求の申請を行うことはできません。Radar for Teams を使うと、審査プロセスの段階の支払いを手動でキャプチャーできます。
各支払いにカスタムの明細書表記を設定
明細書表記とは、顧客のカード明細書で、支払いに関連付けられた会社の情報が表示されるテキストです。明細書表記を使用する方法の 1 つは、短いランダムなコードを挿入し、顧客に確認を求めることです。取引に不正使用の可能性が疑われる場合には、顧客に連絡し、 オンライン明細書に表示されたコードを尋ねることができます。コードが提供されない場合は、支払いを返金することができます。
ダッシュボードでデフォルトの明細書表記を編集するか、または API で支払いを作成するたびに動的な明細書表記を設定できます。
この方法は、不正使用者がカード保有者のオンラインカード発行会社またはクレジットアカウントにアクセスできる場合には役立ちませんが、そのようなケースは稀です。こうした方法で明細書表記を使用すると、正当な顧客である可能性をさらに確認できます。他の不正使用防止対策と同様、この方法によって顧客の負担が増えることで、正当な支払いが返金される可能性があります。