クレジットマスター攻撃の対策｜売上がなくても生じる処理手数料
商品を発送していなくても、大量のカード試行で処理費用や決済停止の損失が生じることがあります。課金対象の確認と、注文成立前の試行を止める対策が必要です。
公開： ／ 公式資料確認：2026-10-14
売上も発送もないのに、被害が生じることがある
クレジットマスター攻撃は、生成・推測されたカード情報などを使い、決済やカード登録の機能で有効性を大量に確かめる不正な試行です。盗まれたカード情報を試す「カードテスティング」も、ショップを有効性確認の場として使う点が共通します。商品を買うことだけが目的ではないため、注文一覧に残らない試行にも注意が必要です。
カードの利用可否を照会する処理をオーソリ（与信・承認照会）と呼びます。成功・失敗を問わず、課金対象となる照会や認証の回数が増えれば、売上がなくても費用負担が生じる場合があります。ただし、どの処理が有料かは決済事業者と加盟店の契約によって異なります。
DGフィナンシャルテクノロジーの解説は、大量の与信リクエストによるトランザクション費用、サイトの負荷、カード決済の停止などをEC事業者のリスクとして挙げています。試行が失敗しただけで「ショップには損害がない」とは判断できません。 Stripeの案内も、カスタム料金プランの与信手数料などが増える可能性を示しています。
少額決済が成功した場合は、後で不正利用の異議申立てやチャージバックにつながることもあります。また、決済エラーが増えると正常な購入者にも影響します。カード試行が見つかったことだけで、自店からカード情報が漏えいしたと断定することはできませんが、サイト改ざんや漏えいの有無は別に確認します。
手数料は「何を1件と数えるか」まで確認する
売上金額に料率を掛ける決済手数料と、リクエスト・処理回数に応じた手数料は別です。「決済手数料は○%」という表示だけでは、大量試行時の請求額を判断できません。見積書、加盟店契約、管理画面の料金設定を照合し、不明な点は書面で事業者に確認します。
| 費用の項目 | 確認する課金条件 | 確認を求める内容 |
|---|---|---|
| 売上に対する決済手数料 | 売上確定・取消・返金時の扱い | 取消した売上の料率手数料が戻るか |
| トランザクション・オーソリ処理料 | 承認された処理だけか、失敗した照会も含むか | 否認・エラー・再試行の課金対象と、同じ取引の数え方 |
| カード登録・有効性確認の費用 | 登録・更新・確認だけでも課金されるか | 注文を伴わない処理が請求の件数に含まれるか |
| 3Dセキュア等の本人認証料 | 認証を開始した時点か、完了した時点か | 認証失敗・中断や繰り返しの扱い、与信処理料との重複 |
| 不正検知・ブロック機能の費用 | 検査・遮断された試行も件数に含むか | 遮断の位置、無料枠、上限、追加オプション料 |
| 取消・返金・異議申立ての費用 | 処理ごとに追加料金があるか | 少額決済の返金手順、手数料の返還・免除条件 |
課金対象2万件なら、1件の単価が小さくても積み上がる
仮定：成功・失敗のどちらも1件3円（税別）の与信処理料が掛かる契約で、攻撃由来の課金対象が20,000件の場合。
20,000件 × 3円 ＝ 60,000円（税別）
これは売上金額とは別の処理料です。実際には契約の単価・無料枠・上限・免除条件で変わり、本人認証料などが別に掛かる場合もあります。アクセス回数や注文数を、そのまま請求件数に置き換えないでください。
「攻撃だから自動的に請求されない」「3Dセキュアを使えば処理料も免除される」とも限りません。攻撃時の減免制度があるか、申告期限と必要な証拠まで確認します。
注文数より、決済試行と失敗率を見る
| 兆候 | 確認する記録 | 正常な原因も確認する |
|---|---|---|
| 注文は増えないのに決済試行が急増 | 決済・カード登録のリクエスト数、取引ID、発生時刻 | 画面の二重送信、外部連携の自動再試行 |
| 否認・入力エラーが普段より多い | 承認照会の件数、成功・失敗の内訳、認証の結果 | 事業者の障害、設定変更、購入者の入力ミス |
| 少額決済やカード登録が短時間に続く | 普段の単価との差、同一端末・アカウント等の関連 | 会員登録キャンペーンや正常な少額商品の販売 |
| 処理料の件数が受注件数と合わない | 請求対象の処理種別、件数の明細、取消の履歴 | 課金の集計期間や、1注文で複数回ある正常処理 |
件数と、試行に占める失敗の割合を普段の同じ時間帯と比べます。一つのIPアドレスだけで判定すると、複数の接続元から来る試行を見逃したり、共有回線の正常な購入者を止めたりします。決済事業者・カート側の判定と、サイト全体の増加を組み合わせます。
攻撃を疑ったら、費用が増える処理を先に止める
- 決済事業者とカート・サイトの運用担当へ連絡する。発生時刻、増加した処理の種類、成功・失敗の件数、取引ID、サイトや購入者への影響を伝えます。カード番号全桁やセキュリティコードはメール添付しません。
- 事業者の案内で対象の決済・カード登録機能を制限する。管理画面の遮断機能や、連携先に到達する前の制限を確認します。画面上の購入ボタンを隠すだけで、直接呼び出される決済処理まで止まるとは限りません。
- 自動再試行と出荷を確認する。エラーを繰り返す連携を止め、攻撃中に成功した注文は発送を保留します。取消・返金は事業者の案内に従い、進行中の異議申立てとの重複を避けます。
- ログと請求明細を保全する。アクセス、決済、認証の時刻と件数、実施した制限と解除時刻を記録します。保全は閲覧者と保存期間を限定し、不要なカード情報を残しません。
- 請求対象・減免条件を問い合わせる。どの試行が何件課金されたか、遮断後に件数が増えていないかを確認します。免除を前提にせず、申告期限と必要な記録をそろえます。
カード決済を止める場合は、正規の購入者へ「現在カード決済を一時停止しています」と案内し、利用可能な別の支払い方法と問い合わせ先を示します。止める範囲と解除の判断は、決済事業者・カート側と合わせます。
決済に到達する前の制限と、決済側の対策を組み合わせる
本人認証、不正検知、Bot対策、リクエスト回数の制限を、提供されている機能と自店の取引に合わせて使います。CAPTCHAを表示するだけでは、決済処理への直接アクセスを制限できません。認証が完了したことをサーバー側で確かめる設定も必要です。実装や設定の確認はカート・開発担当に依頼し、画面に置いただけで対策済みとしないでください。
注文を受ける画面だけでなく、会員のカード登録・更新も確認します。WAF等で連携先へ送る前に遮断できるか、決済側のブロックがどの段階にあるか、各段階の試行が課金対象かを確認すると、被害と費用を切り分けられます。3Dセキュアだけで全ての大量試行や費用負担を防げるわけではありません。
ペイジェントの大量トランザクションブロッカーの案内は、加盟店が設定する条件に応じてオーソリを遮断する機能を説明しています。2024年のリリース案内なので、現在の契約で使えるか、通知・遮断の設定と料金は窓口で再確認してください。
再開前には、試行数が落ち着いたこと、正常な購入者が利用できること、課金対象の増加が収まったことを確認します。実在するカード情報を使った大量試行は行わず、事業者が指定するテスト環境・方法で確かめます。