不正注文を防ぐ方法15選｜ECサイトの不正利用対策を徹底解説

ECサイトでは、盗まれたクレジットカード情報による注文、会員アカウントの乗っ取り、カード番号が利用できるかを確認する大量決済、転売目的の不正購入など、さまざまな不正注文が発生します。不正注文を見逃して商品を発送すると、商品代金を回収できないだけでなく、送料、仕入れ費用、調査対応、問い合わせ対応などの損失も生じます。

一方で、不正対策を厳しくしすぎると、正当な利用者の注文まで拒否する「誤判定」が増えます。住所が異なる、海外から接続している、高額商品を初めて購入したという一つの条件だけで注文を拒否すると、売上機会と顧客の信頼を失う可能性があります。不正注文対策では、複数の情報を組み合わせ、危険度に応じて本人認証、保留、目視確認、拒否を使い分けることが重要です。

日本のクレジットカード・セキュリティガイドライン6.0版では、EC加盟店に対し、EMV 3-Dセキュアの導入、適切な不正ログイン対策、Webサイトの脆弱性対策に加え、不正利用状況に応じた追加対策が求められています。単独の機能だけに依存せず、決済前、決済時、決済後を通した複層的な防御を構築する必要があります。

1. 不正注文とは

不正注文とは、購入者本人の正当な意思や権限に基づかず、盗用した決済情報、乗っ取ったアカウント、虚偽の個人情報などを使って商品やサービスを取得する注文です。第三者による明確な犯罪だけでなく、購入者本人が商品受領後に利用を否認する場合もあります。

1.1 不正注文の定義

不正注文は、第三者が他人のカード情報を使用する「なりすまし注文」、既存会員のアカウントを奪って登録済みカードを使う「アカウント乗っ取り」、返金や割引制度を悪用する注文などに分けられます。

注文情報が形式上正しく、カード会社の承認を得ていても、正当なカード会員が注文したとは限りません。決済承認は、利用可能枠やカード状態などを確認する処理であり、注文者の正当性を完全に保証する仕組みではありません。

1.2 不正注文で発生する損失

不正注文による直接的な損失には、商品原価、送料、決済手数料、返金費用、請求取消し手数料などがあります。高額商品や換金しやすい商品では、一件の被害でも大きな損失になる可能性があります。

さらに、注文調査、カード会社への資料提出、顧客対応、配送会社への連絡など、従業員の作業時間も必要です。不正利用率が高まると、決済サービスの利用条件や審査へ影響する場合もあるため、継続的な管理が欠かせません。

1.3 請求取消しとの関係

カード会員が利用を否認し、カード会社が申立てを認めた場合、EC事業者の売上が取り消されることがあります。一般にチャージバックと呼ばれますが、本記事では「請求取消し」と表記します。

請求取消しが発生した後に商品を回収できるとは限りません。カード決済が承認された時点で直ちに商品を発送するのではなく、注文の危険度を確認する時間を確保することが重要です。

1.4 正常注文との違い

不正注文には、通常とは異なる兆候が現れることがあります。しかし、同じ特徴が正常な注文にも存在するため、一つの情報だけで不正と断定してはいけません。

たとえば、請求先と配送先が異なる注文は、盗用カードによる可能性がある一方、贈答品や職場への配送でも発生します。複数の兆候、過去の注文履歴、本人認証結果などを組み合わせて判断します。

1.5 不正対策の目的

不正対策の目的は、すべての注文を疑うことではありません。危険度の高い注文を早期に検出し、正常な利用者には可能な限り負担をかけずに購入してもらうことです。

不正率だけを下げようとして拒否条件を増やすと、正当な注文の拒否率も上がります。不正損失、正常注文の承認率、審査時間、購入完了率を同時に確認する必要があります。

2. 不正注文の主な手口

不正注文対策を設計するには、どのような手口で被害が発生しているかを把握する必要があります。手口によって有効な対策が異なるため、すべてを同じ条件で判定する方法は適切ではありません。

2.1 盗用カードによる注文

漏えい、フィッシング、マルウェアなどによって取得された他人のカード情報を使い、商品を購入する手口です。換金しやすい電子機器、ブランド品、商品券、デジタル商品などが狙われやすくなります。

カード番号、有効期限、確認番号が一致し、決済承認を得られる場合でも、注文者がカード名義人とは限りません。EMV 3-Dセキュア、不正検知、配送審査を組み合わせます。

2.2 アカウント乗っ取り注文

攻撃者が正規会員のIDとパスワードを使ってログインし、保存されているカードやポイントで注文する手口です。漏えいした認証情報を他サービスへ自動入力する攻撃は、認証情報詰め込み攻撃と呼ばれます。

既存会員による注文として表示されるため、新規注文だけを厳しく審査しているサイトでは見逃す可能性があります。新しい端末、配送先の突然の変更、パスワード変更直後の高額購入などを確認します。

2.3 カード番号試行

攻撃者が多数のカード番号や有効期限を少額決済へ入力し、利用可能な組み合わせを確認する手口です。短時間に大量の決済失敗が発生したり、同じ端末から異なるカードが試されたりします。

カード番号試行は、EC事業者の商品を取得することより、利用可能なカード情報を発見することが目的です。決済回数制限、端末単位の制御、ボット判定、少額注文の監視が必要です。

2.4 割引・返品制度の悪用

複数アカウントを作って初回割引を繰り返し使用する、商品を使用してから返品する、未着を虚偽申告するなど、販売制度を悪用する手口です。

カード盗用とは異なり、購入者本人が正規の決済情報を使用している場合があります。会員、端末、住所、電話番号、決済手段の関連性を確認し、返品・割引規約を明確にします。

2.5 転送先・受取代行の悪用

不正注文の商品を、空室、短期滞在先、転送サービス、受取代行者などへ配送する手口です。攻撃者自身の住所を使用せず、商品回収後に追跡を困難にします。

ただし、転送サービスやホテルへの配送を利用する正当な顧客もいます。住所の種類だけで拒否せず、高額商品、初回購入、本人認証結果、端末情報などと合わせて判断します。

3. 決済前・決済時・決済後で対策する

不正注文対策は、注文確定時だけに実施するものではありません。ログイン、カート操作、決済認証、注文審査、発送、請求取消し対応までを一続きの流れとして設計します。

3.1 決済前の対策

決済前には、不正ログイン、ボットによる操作、会員登録の乱用、配送先の不審な変更などを検出します。ログイン時の多要素認証や試行回数制限は、アカウントを利用した不正注文を防ぐうえで重要です。

商品をカートへ追加する段階でも、異常な速度や大量購入を検出できます。限定商品を数秒で大量に確保する操作など、人間による通常操作とは考えにくい行動を監視します。

3.2 決済時の対策

決済時には、EMV 3-Dセキュア、カード確認番号、請求先情報、端末情報、IPアドレス、不正検知サービスなどを利用します。

日本のガイドライン6.0版では、EC加盟店にEMV 3-Dセキュアの導入と適切な不正ログイン対策が求められています。また、不正発生状況に応じた追加対策も必要です。

3.3 決済後の対策

決済が承認された後も、商品を発送する前に注文内容を確認できます。危険度が高い注文だけを保留し、目視確認や本人確認を行います。

配送後は、追跡番号、配達完了情報、受領証明、顧客との連絡記録を保存します。請求取消しが発生した場合に、注文が正当に履行されたことを示す資料として利用できる場合があります。

3.4 複層的な対策

一つの対策だけですべての不正注文を防ぐことは困難です。3-Dセキュアを導入しても、アカウント乗っ取り、返品制度の悪用、配送先変更など、決済認証以外の手口は残ります。

経済産業省の検討資料でも、EMV 3-Dセキュアだけに依存せず、決済前、決済時、決済後を通した複層的な対策と、属性・行動分析の高度化が示されています。

3.5 危険度に応じた対応

すべての利用者へ強い本人確認を要求すると、購入途中の離脱が増える可能性があります。危険度の低い注文は円滑に処理し、危険度が高まった注文へ追加認証や審査を適用します。

Mastercardも、低危険度の取引は負担を抑えて処理しながら、危険な取引では本人確認を強化する考え方を示しています。危険度に応じた対応は、不正防止と購入体験を両立するために重要です。

4. EMV 3-Dセキュアを導入する

EMV 3-Dセキュアは、オンラインのカード決済時にカード発行会社が取引の危険度を判定し、必要に応じて利用者へ追加の本人認証を求める仕組みです。

4.1 EMV 3-Dセキュアの仕組み

決済時に端末、取引、加盟店などの情報がカード発行会社へ送られ、危険度が評価されます。危険度が低いと判断された取引では、利用者の追加操作なしで認証が完了する場合があります。

追加確認が必要な場合は、ワンタイムパスワード、カード会社アプリ、生体認証などによる本人認証が表示されます。Visaは、3-Dセキュアがカード会員の確認と非対面不正利用の抑止に役立つと説明しています。

4.2 日本のEC加盟店における位置付け

2025年3月に改訂されたクレジットカード・セキュリティガイドライン6.0版では、EC加盟店にEMV 3-Dセキュアの導入が求められています。適切な不正ログイン対策や脆弱性対策も同時に求められている点が重要です。

決済代行サービスが対応していても、自社店舗側の設定が無効になっていれば認証されないことがあります。契約中の決済代行会社へ、導入状況と認証条件を確認します。

4.3 危険度に応じた認証

すべての取引で必ず入力画面を出すのではなく、カード発行会社の危険度判定により、追加認証なしで完了する場合があります。これにより、正常な購入者の負担を抑えながら危険な取引を確認できます。

決済サービスによっては、自社側の不正検知結果に応じて3-Dセキュアを要求する条件も設定できます。Stripeの公式資料では、危険度や金額に基づいて認証を要求するルール例が示されています。

4.4 3-Dセキュアだけでは防げない手口

アカウント乗っ取り後に本人の端末や認証手段まで悪用された場合、3-Dセキュアだけで防げない可能性があります。代引き、銀行振込、後払いなど、カード以外の不正注文には直接作用しません。

さらに、返金制度の悪用、商品未着の虚偽申告、注文後の配送先変更も別の対策が必要です。3-Dセキュアを中心にしつつ、ログイン、配送、注文審査を組み合わせます。

4.5 認証失敗時の処理

認証に失敗した注文を、自動的に別の認証なし決済へ切り替えると、対策を回避される可能性があります。認証結果ごとの処理を決済代行会社の仕様に沿って設定します。

通信障害や利用者の操作中断による失敗もあるため、すべてを不正と断定してはいけません。再試行方法、別決済手段、問い合わせ案内を用意し、顧客体験にも配慮します。

5. 決済情報と注文情報を照合する

不正検知では、カード情報だけでなく、請求先、配送先、IPアドレス、端末、注文履歴などを組み合わせます。情報の不一致は危険信号になりますが、不一致だけで自動拒否するのは避けます。

5.1 カード確認番号を利用する

カード確認番号は、カード裏面などに記載されている番号です。カード番号だけが漏えいしている場合の不正利用を減らす補助情報になります。

カード確認番号が一致しても、カード自体の情報がすべて盗まれている可能性があります。確認番号は3-Dセキュアや不正検知の代わりではなく、複数対策の一つとして使用します。

5.2 請求先住所を確認する

一部のカードや地域では、入力された請求先住所とカード会社の登録情報を照合する住所確認機能が利用できます。郵便番号や住所の不一致は審査材料になります。

日本国内ではカード会社や決済方式により取得できる情報が異なります。住所照合が使えない場合でも、過去の購入住所、配送先、電話番号との関連を確認できます。

5.3 請求先と配送先を比較する

請求先と配送先が大きく異なる注文は、盗用カードの可能性を検討します。初回購入、高額商品、即日発送、別名義の配送が重なると危険度が高まります。

Stripeの不正検知ルールでは、請求先と配送先、IPアドレスと各住所の距離などを判定材料にできます。住所の差だけではなく、距離、頻度、注文履歴を組み合わせる方法が有効です。

5.4 IPアドレスの位置情報を確認する

接続元の国や地域と、カード発行国、請求先、配送先が大きく異なる場合は確認対象になります。短時間に複数国から同一アカウントへ接続している場合も注意が必要です。

ただし、携帯通信、企業ネットワーク、仮想私設網などにより、IPアドレスの位置が実際の利用場所と異なることがあります。IP位置情報だけで拒否せず、他の情報と合わせます。

5.5 注文頻度を確認する

同じカード、端末、IPアドレス、メールアドレス、配送先から短時間に多数の注文が発生した場合、カード番号試行や転売目的の可能性があります。

正常な法人注文や人気商品の販売開始時にも大量注文が発生します。商品別、顧客別、時間帯別の通常値を把握し、異常な増加を検出します。

6. アカウント乗っ取りを防ぐ

会員アカウントにカード情報、ポイント、住所が保存されている場合、ログイン機能自体が不正注文の入口になります。決済だけでなく、認証とセッションの安全性を強化します。

6.1 パスワードの使い回しを防ぐ

利用者には、長く推測されにくいパスワードを設定し、他サービスと使い回さないよう案内します。漏えい済みパスワードの登録を拒否する仕組みも検討できます。

IPAは、不正ログイン対策として、長く、複雑で、使い回さないパスワードと多要素認証を推奨しています。

6.2 多要素認証を導入する

多要素認証では、パスワードに加え、認証アプリ、端末、生体情報など、異なる要素を使用します。管理者アカウントと高額購入を行う会員には特に重要です。

OWASPは、多要素認証をパスワードに関係する攻撃への強力な防御策として位置付けています。少なくとも、管理画面、住所変更、保存カードの利用、ポイント全額使用などで追加認証を検討します。

6.3 ログイン試行を制限する

同じIPアドレスやアカウントに対する短時間の大量ログインを制限します。一定回数を超えた場合は、待機時間、追加認証、通知などを適用します。

単純にアカウントを長時間ロックすると、攻撃者が他人のアカウントを意図的に使用不能にする可能性があります。段階的な遅延や危険度に応じた認証を利用します。

6.4 重要な変更時に再認証する

ログイン済みであっても、パスワード、メールアドレス、電話番号、配送先、保存カードなどを変更する際は再認証を求めます。

変更直後の高額注文やポイント使用は、通常より危険度を上げます。変更通知を旧メールアドレスにも送り、本人が身に覚えのない操作を早期に発見できるようにします。

6.5 セッションを安全に管理する

ログイン状態を保持するセッション識別子が盗まれると、パスワードを知らなくても会員として操作される可能性があります。HTTPS、適切なCookie属性、ログイン後のセッション再発行、期限設定を行います。

OWASPは、ログインなど権限が変わる場面でセッション識別子を再生成し、安全な通信と推測困難な識別子を使用することを推奨しています。

7. ボットとカード番号試行を防ぐ

人間では実行できない速度や件数でアクセスするボットは、カード番号試行、アカウント乗っ取り、限定商品の買い占めに利用されます。画面単位ではなく、サービス全体の行動を監視します。

7.1 回数制限を導入する

ログイン、会員登録、クーポン入力、カード登録、決済などの操作に回数制限を設定します。IPアドレスだけでなく、アカウント、端末、メールアドレス、カード指紋など複数単位で判定します。

IPアドレスだけの制限は、攻撃者が多数の接続元を使うと回避されます。一方、共有ネットワークの利用者をまとめて遮断する可能性もあるため、段階的な制限にします。

7.2 人間確認を使用する

不審な速度や大量試行が検出された場合は、人間による操作かを確認する機能を表示します。すべての利用者へ毎回表示するのではなく、危険な操作へ限定します。

人間確認機能だけで高度なボットを完全に防ぐことはできません。行動速度、端末情報、失敗回数、決済情報と組み合わせます。

7.3 メール・電話番号を確認する

新規アカウント作成時にメールアドレスを確認し、高額購入や重要な変更では電話番号の確認も検討します。

使い捨てメールや仮想電話番号も存在するため、確認済みであることだけで安全とは判断できません。登録日時、過去の利用実績、端末との関連を確認します。

7.4 少額決済を監視する

攻撃者は損失を抑えながらカードの有効性を確認するため、最も安い商品や寄付、少額課金を狙う場合があります。少額だから危険度が低いとは限りません。

同一端末からカード番号だけを変えて複数の少額決済を試している場合は、即時に制限します。商品価格ではなく、試行回数と情報の切替頻度を監視します。

7.5 決済失敗の詳細を表示しすぎない

「カード番号が正しいが有効期限が違う」など、失敗理由を細かく利用者へ表示すると、攻撃者がカード情報を絞り込める場合があります。

利用者向けには「決済を完了できませんでした」など必要最小限の案内にし、詳細な理由はサーバーの安全な記録へ保存します。問い合わせ担当者にも、本人確認前に詳細情報を開示しない手順を設定します。

8. 注文の危険度を点数化する

不正注文の判定では、複数の危険信号を点数化し、合計点に応じて承認、追加認証、保留、拒否を決める方法があります。

8.1 判定項目を選ぶ

判定項目には、注文金額、初回購入、配送先変更、決済失敗回数、端末の新規性、IP位置、購入商品、過去の請求取消しなどを使用できます。

氏名、国籍、年齢など、差別的な判断につながり得る属性を安易に使用してはいけません。実際の不正との関連が説明でき、購入処理に必要な信号へ限定します。

8.2 項目ごとの重みを設定する

すべての危険信号を同じ強さで扱う必要はありません。カード番号の大量試行や乗っ取り兆候には高い点数を与え、単なる請求先と配送先の違いには低い点数を与えます。

点数は担当者の感覚だけで決めず、過去の不正注文と正常注文を比較します。不正発生後は、その注文を検出できなかった理由を確認して重みを見直します。

8.3 判定基準を分ける

低危険度は自動承認、中危険度は3-Dセキュアや目視確認、高危険度は保留または拒否とするなど、複数の基準を用意します。

二択だけにすると、危険な注文を通すか、正常注文を拒否するかの極端な判断になります。中間の保留・追加確認を用意することで、誤判定を減らせます。

8.4 外部の不正検知を利用する

決済代行会社やEC基盤が提供する不正検知では、自店舗だけでなく、より広い取引情報から危険度を評価できる場合があります。

Stripeは、取引をリアルタイムで評価し、危険度に応じて許可、拒否、審査、3-Dセキュア要求などのルールを設定できると説明しています。Shopifyも住所確認、カード確認番号、IP情報、通常と異なる購入行動などを注文審査の指標として利用しています。

8.5 誤判定を継続的に確認する

不正注文を止められていても、正常注文を大量に拒否していれば対策は成功とはいえません。拒否された注文のうち、顧客から問い合わせがあった件数や再注文の有無を確認します。

不正率、承認率、目視確認率、購入完了率を商品や地域ごとに比較します。ルール変更後に拒否件数が急増した場合は、条件が広すぎないか確認します。

9. 危険な注文を目視確認する

自動判定で中程度以上の危険度となった注文は、担当者が複数の情報を確認します。すべてを目視確認すると作業量が増えるため、対象を限定します。

9.1 注文情報を横断確認する

氏名、メールアドレス、電話番号、請求先、配送先、IP位置、注文商品、決済結果を一つの画面で確認します。

情報が不一致でも、それぞれに合理的な理由がある場合があります。単純な赤信号の数だけではなく、不一致同士の関係を確認します。

9.2 関連する過去注文を探す

同じメールアドレス、端末、カード、IPアドレス、配送先を使用した過去注文を確認します。異なる名義で同じ配送先へ高額商品が繰り返し注文されている場合は注意が必要です。

Stripeの審査画面では、同じメール、IP、カード番号を使用した関連決済を確認できます。このような関連性は、単独注文だけでは見えない不正の発見に役立ちます。

9.3 購入者へ連絡する

注文内容に疑問がある場合は、登録済みの連絡先へ確認します。商品名、注文日時など、必要最小限の情報を使い、注文意思を確認します。

カード番号全体、確認番号、パスワードなどを電話やメールで尋ねてはいけません。本人確認方法は事前に定め、担当者ごとの対応差を減らします。

9.4 決済確定を保留する

決済サービスが対応している場合は、カードの利用枠だけを確保し、審査後に売上を確定する方法があります。危険な注文を調査する時間を確保できます。

Shopifyの公式資料でも、決済を確定する前に注文を調査したい場合は手動売上確定を利用できると案内されています。高危険度注文を自動で確定しない処理も構築できます。

9.5 審査記録を残す

確認した項目、判断理由、顧客への連絡内容、最終処理を注文へ記録します。個人の記憶だけに依存しないようにします。

同じ特徴の注文が再び発生したときに、過去判断を参照できます。請求取消しへの対応でも、注文時に実施した確認内容が必要になる場合があります。

10. 発送と受け渡しを管理する

決済時に不正を見逃しても、商品発送前に止められれば直接的な商品損失を防げます。配送速度を重視しつつ、危険な注文だけを保留する仕組みを設けます。

10.1 高危険度注文を保留する

危険度が一定以上の注文は、自動的に出荷指示を作成しないようにします。審査完了後に担当者が保留を解除します。

出荷システムとEC管理画面が分離している場合、注文取消しが倉庫へ反映されない事故が起こります。保留状態を配送システムまで連携します。

10.2 決済後の住所変更を確認する

決済後にメールや電話で配送先変更を依頼された場合は、通常より厳しく確認します。攻撃者が、本人認証を通過した住所から別の受取先へ変更する可能性があります。

変更依頼を受けたら、ECサイトへ再ログインして本人が操作する方式や、再認証を求めます。担当者が口頭だけで住所を書き換える運用は避けます。

10.3 追跡可能な配送を利用する

高額商品は、追跡番号、配達完了情報、受取署名などを取得できる配送方法を使用します。置き配や郵便受け配送では、受取人を確認しにくい場合があります。

追跡情報は請求取消しを必ず防ぐものではありませんが、注文が指定先へ配送されたことを示す資料になります。配送記録の保存期間も定めます。

10.4 高換金商品に追加条件を設ける

電子機器、ブランド品、ゲーム機、商品券など、換金しやすい商品は不正注文の対象になりやすいため、購入数量や配送方法へ追加条件を設定します。

高換金商品だけを一律に販売停止するのではなく、初回注文の上限、店舗受取時の本人確認、発送保留時間などを組み合わせます。

10.5 デジタル商品の即時提供を制御する

デジタル商品、電子コード、オンラインサービスは、提供後に回収しにくいため、物理商品より早い段階で不正判定を完了する必要があります。

高危険度注文では即時発行せず、追加認証や審査後に提供します。同じ端末から複数アカウントでコードを購入する行動も監視します。

11. 商品と販売形態に合わせて対策する

不正注文の危険度は、扱う商品、金額、配送速度、販売地域によって異なります。すべての店舗が同じルールを使うのではなく、自店舗の被害傾向に合わせます。

11.1 高額商品の対策

高額商品は一件当たりの損失が大きいため、低額商品より厳しい基準を設定します。高額という条件だけで拒否せず、本人認証と目視確認を追加します。

一定金額以上では、3-Dセキュア、追跡付き配送、受取確認を必須にする方法があります。法人注文など正常な高額購入へ対応できる確認手順も用意します。

11.2 限定商品の対策

限定商品では、ボットによる買い占めや複数アカウントの利用が問題になります。アカウント単位だけでなく、端末、住所、電話番号、決済手段の関連性を確認します。

購入数量制限を画面表示だけで実装すると、APIへ直接アクセスして回避される可能性があります。サーバー側でも上限を検証します。

11.3 定期購入の対策

定期購入では、初回注文だけでなく、支払方法や配送先の変更、再開処理も監視します。乗っ取られたアカウントから配送先だけを変更される場合があります。

初回の大幅割引を複数アカウントで繰り返す悪用には、端末や配送先の関連性を確認します。正常な家族利用を誤って拒否しないよう、確認手段も用意します。

11.4 海外注文の対策

海外注文では、カード発行国、接続国、請求先、配送先が異なることがあります。国の違いだけで不正と判断すると、正当な越境購入を失います。

配送追跡の有無、転送サービス、商品種類、過去実績を加えて判断します。危険度の高い地域や配送方法は、商品や金額に応じて制限します。

11.5 法人注文の対策

法人注文では、請求先と配送先が異なる、大量購入、高額注文など、一般消費者向けの危険信号が正常に発生します。

会社名、会社ドメインのメールアドレス、代表電話、注文書、過去取引などを確認します。個人向けと法人向けで異なる審査ルールを用意すると、誤判定を減らせます。

12. EC基盤と決済サービスを活用する

すべての不正対策を自社開発する必要はありません。EC基盤、決済代行会社、不正検知サービスが提供する機能を確認し、自社の運用と組み合わせます。

12.1 Shopifyで確認する

Shopifyの注文不正分析では、住所確認、カード確認番号、IP情報、通常と異なる購入行動などの指標が表示されます。注文を低・中・高危険度として確認できる場合があります。

危険度の高い注文を自動取消しする前に、自店舗で誤判定がどの程度発生するかを確認します。注文保留、決済確定、在庫戻しなどの処理も連携させます。

12.2 WooCommerceで確認する

WooCommerceでは、利用中の決済代行プラグインがEMV 3-Dセキュアや不正検知に対応しているか確認します。プラグインを追加しただけで自動的にすべての対策が有効になるとは限りません。

WordPress本体、テーマ、プラグインを更新し、不要な管理者アカウントを削除します。決済情報を自社サーバーへ保存せず、対応する決済画面やトークン化を利用します。

12.3 独自ECサイトで実装する

独自ECでは、決済代行会社が提供する公式の組込み方法を使用し、端末情報、IPアドレス、顧客メール、請求先など、不正検知に必要な情報を適切に送ります。

Stripeは、端末特性、IPアドレス、顧客メール、氏名、請求先などの情報が不正判定の改善に役立つと案内しています。必要な情報を送信しない独自実装は、検知精度を下げる可能性があります。

12.4 決済代行会社へ相談する

不正注文が急増した場合は、決済代行会社へ認証結果、拒否理由、ルール設定、請求取消し状況を相談します。自店舗だけでは把握できない傾向を持っている場合があります。

現在の3-Dセキュア設定、危険度ルール、カード番号試行対策が有効か確認します。古い接続方式を使用している場合は、新しい決済画面や公式組込み方式への移行を検討します。

12.5 外部サービスへ依存しすぎない

不正検知サービスは危険度の判断を支援しますが、すべての不正や請求取消しを保証するものではありません。Shopifyも、不正分析機能が請求取消し損失を必ず補償するものではないと案内しています。

自店舗の商品特性、配送方法、過去被害を理解し、外部判定へ独自ルールを追加します。サービス障害時の処理も決めておきます。

13. 不正注文対策のコード例

独自ECサイトでは、危険度の点数化、回数制限、決済通知の検証、重複処理の防止、監査記録などをサーバー側へ実装できます。以下は考え方を示す簡略例であり、本番では使用中の言語、決済サービス、個人情報保護方針に合わせて調整します。

13.1 注文リスクを点数化する

注文情報から複数の危険信号を加点し、点数に応じて処理を分けます。クライアントから送られた「危険度」を信用せず、サーバー側で計算します。

点数と条件は固定せず、実際の不正注文と正常注文を基に見直します。国や住所の不一致だけで拒否しないよう、複数条件を組み合わせます。

注文リスク判定のコード例

function calculateOrderRisk(order) {  let score = 0;  const reasons = [];  if (order.customer.orderCount === 0 && order.total >= 100000) {    score += 25;    reasons.push("初回の高額注文");  }  if (order.payment.failedAttemptsLastHour >= 4) {    score += 35;    reasons.push("短時間の決済失敗");  }  if (order.account.shippingAddressChangedWithinHours <= 1) {    score += 25;    reasons.push("配送先変更直後");  }  if (order.device.isNew && order.account.hasStoredPaymentMethod) {    score += 15;    reasons.push("新規端末から保存済み決済を使用");  }  if (    order.network.ipCountry !== order.billing.country &&    order.shipping.expressDelivery  ) {    score += 15;    reasons.push("接続国不一致と速達指定");  }  let action = "approve";  if (score >= 70) {    action = "hold";  } else if (score >= 40) {    action = "require_authentication";  }  return { score, action, reasons }; }

13.2 決済試行を制限する

カード番号試行を防ぐには、アカウント、IPアドレス、端末などの単位で短時間の試行回数を制限します。実際には、複数サーバー間で共有できるデータストアを使用します。

制限を超えた場合は、永久拒否ではなく、一定時間の待機や追加確認へ切り替えます。成功・失敗の両方を記録し、攻撃の兆候を監視します。

回数制限のコード例

async function checkPaymentAttemptLimit({  accountId,  ipAddress,  deviceId,  store }) {  const windowSeconds = 15 * 60;  const limits = [    { key: `pay:account:${accountId}`, max: 5 },    { key: `pay:ip:${ipAddress}`, max: 12 },    { key: `pay:device:${deviceId}`, max: 8 }  ];  for (const limit of limits) {    const count = await store.increment(limit.key, windowSeconds);    if (count > limit.max) {      return {        allowed: false,        retryAfterSeconds: windowSeconds      };    }  }  return { allowed: true }; }

13.3 決済通知を検証する

決済完了画面を表示したことだけで、注文を支払済みにしてはいけません。決済代行会社からサーバーへ届く通知の署名を公式ライブラリで検証します。

通知内容の金額、通貨、注文番号、決済状態を自社注文と照合します。署名検証に失敗した通知は処理せず、安全な記録へ残します。

決済通知処理の疑似コード

async function handlePaymentWebhook(request, response, paymentProvider) {  let event;  try {    event = paymentProvider.verifyWebhook({      rawBody: request.rawBody,      signature: request.headers["payment-signature"]    });  } catch (error) {    response.status(400).send("Invalid signature");    return;  }  if (event.type !== "payment.succeeded") {    response.status(200).send("Ignored");    return;  }  const order = await findOrder(event.orderId);  if (!order) {    response.status(404).send("Order not found");    return;  }  if (    event.amount !== order.total ||    event.currency !== order.currency  ) {    await holdOrder(order.id, "決済金額または通貨の不一致");    response.status(409).send("Payment mismatch");    return;  }  await markOrderAsPaid(order.id, event.paymentId);  response.status(200).send("OK"); }

13.4 注文の重複処理を防ぐ

決済通知は通信上の理由で複数回送られる場合があります。同じ決済を複数回処理しないよう、決済識別子や注文識別子を使って重複を防止します。

商品発送、ポイント付与、電子コード発行も一度だけ実行されるようにします。データベースの一意制約と取引処理を使用します。

重複防止のコード例

async function processPaidOrder(orderId, paymentId, database) {  return database.transaction(async (transaction) => {    const existing = await transaction.paymentEvents.findUnique({      paymentId    });    if (existing) {      return { processed: false, reason: "already_processed" };    }    await transaction.paymentEvents.insert({      paymentId,      orderId,      receivedAt: new Date()    });    await transaction.orders.update(orderId, {      paymentStatus: "paid",      fulfillmentStatus: "risk_review"    });    return { processed: true };  }); }

13.5 個人情報を隠して監査記録を残す

不正調査には記録が必要ですが、カード番号、確認番号、パスワード、完全なセッション識別子などをログへ保存してはいけません。

PCI DSSは、決済アカウントデータを保護するための技術的・運用上の基準を定めています。必要な情報だけを保存し、アクセス権、保存期間、暗号化を管理します。

安全な監査記録の例

function createRiskAuditLog(order, assessment) {  return {    orderId: order.id,    customerId: order.customer.id,    emailHash: hashWithSalt(order.customer.email),    ipPrefix: maskIpAddress(order.network.ipAddress),    riskScore: assessment.score,    action: assessment.action,    reasons: assessment.reasons,    createdAt: new Date().toISOString()  }; }

14. 不正注文が発生した場合の対応

不正注文を完全になくすことは難しいため、発生時の初動手順を事前に決めておきます。判断が遅れると、商品発送やデジタル商品の利用が進み、損失が拡大します。

14.1 未発送の商品を止める

不正の疑いが判明したら、最初に出荷状態を確認します。倉庫、配送会社、店舗受取拠点へ連絡し、可能であれば発送や引き渡しを止めます。

EC管理画面で注文を取消しただけでは、倉庫側の出荷処理が停止しない場合があります。注文管理と配送管理の両方を確認します。

14.2 決済を取消す

売上確定前なら承認取消し、確定後なら返金など、決済状態に合った処理を行います。自己判断で複数回処理せず、決済代行会社の手順へ従います。

カード番号全体などの機密情報をメールで送信してはいけません。注文番号、決済識別子、発生日時など必要な情報で問い合わせます。

14.3 アカウントを保護する

アカウント乗っ取りが疑われる場合は、該当セッションを無効化し、パスワード再設定を求めます。保存カード、配送先、メールアドレスなどの変更履歴も確認します。

同じ認証情報を使った他アカウントへの攻撃が発生していないか確認します。必要に応じて、影響を受ける利用者へ安全な方法で通知します。

14.4 証拠と記録を保存する

注文内容、認証結果、端末情報、配送記録、利用者との連絡、審査内容を保存します。ただし、保存が禁止される決済情報や不要な個人情報は保持しません。

Webサイト侵害やカード情報漏えいが疑われる場合は、証拠を上書きしないようにし、決済代行会社や専門家へ相談します。PCI SSCも、決済環境を外部サービスへ委託していても、ECサイト自体の安全管理を忘れてはいけないと説明しています。

14.5 原因とルールを見直す

対応完了後は、どの段階で検出できたか、なぜ通過したか、どの情報が不足していたかを確認します。

一件の不正を受けて極端な拒否ルールを追加すると、正常注文への影響が大きくなる場合があります。過去データへ新ルールを適用し、検出できる不正件数と誤判定件数を比較します。

15. 不正注文対策を継続的に改善する

不正手口は、店舗のルールや販売商品に合わせて変化します。一度設定した条件を放置せず、被害と正常注文への影響を継続的に確認します。

15.1 指標を定期確認する

不正注文額、請求取消し額、拒否件数、目視確認件数、正常注文の承認率、審査時間を確認します。

不正率だけが下がっていても、売上や購入完了率が大きく落ちている場合は、対策が厳しすぎる可能性があります。複数の指標を合わせて評価します。

15.2 ルールの効果を測定する

各ルールが何件の注文に一致し、その中にどれだけ不正注文と正常注文が含まれていたかを確認します。

Stripeの公式資料でも、ルール一致件数の急増や急減を監視し、許可・拒否条件が広すぎないかを確認する方法が案内されています。

15.3 従業員の権限を管理する

注文取消し、返金、住所変更、審査ルール変更などの権限を、業務に必要な担当者だけへ与えます。

共有アカウントを避け、操作履歴を残します。管理者アカウントには多要素認証を必須にし、退職者や異動者の権限を速やかに削除します。

15.4 Webサイトの脆弱性を修正する

不正注文対策は決済画面だけでは完了しません。ECサイトの脆弱性から管理画面や顧客情報へ侵入されると、不正注文や情報漏えいにつながります。

クレジットカード・セキュリティガイドライン6.0版でも、EC加盟店のシステムとWebサイトの脆弱性対策が明記されています。ソフトウェア更新、脆弱性診断、不要機能の停止を継続します。

15.5 個人情報と決済情報を保護する

不正検知のために必要以上の個人情報を収集すると、漏えい時の影響が大きくなります。利用目的を明確にし、必要最小限の情報へ限定します。

カード情報を自社で保持する範囲を減らし、PCI DSSに対応した決済代行会社の仕組みを利用します。ただし、決済を外部委託しても、自社ECサイトの脆弱性、アカウント管理、外部プログラムの安全性は継続して管理する必要があります。

おわりに

不正注文を防ぐには、EMV 3-Dセキュアを導入するだけでなく、アカウント乗っ取り対策、カード番号試行対策、注文リスク判定、配送保留、目視確認を組み合わせる必要があります。決済前、決済時、決済後の各段階で対策を行うことで、一つの機能を回避された場合でも被害を止めやすくなります。

特に、初回の高額注文、短時間の決済失敗、配送先変更直後の購入、新規端末からの保存カード利用など、複数の危険信号が重なった注文を優先的に確認します。一つの条件だけで注文を拒否せず、危険度に応じて追加認証、発送保留、本人確認を使い分けることが重要です。

対策導入後は、不正率だけでなく、正常注文の承認率、購入完了率、審査時間も確認します。不正手口と店舗の販売状況に合わせてルールを更新し、顧客の利便性を保ちながら損失を抑える運用を続けることが、不正注文対策の最終的な目的です。