ここではリアルな決済バグの事例から原因・対策を分析していきます。
🎯 リアルな決済バグ事例
🧨 事例①：二重課金（最も多い）
💥 何が起きたか
- ユーザーが「購入」ボタンを連打
- または通信遅延で再送信
👉 同じ決済が2回実行された
🔍 原因
- リクエストの重複防止なし
- トランザクション管理なし
💣 結果
- 二重請求
- クレーム大量発生
- 返金対応地獄
🛠 防止策
- 冪等性キー（idempotency key）
- ボタン連打防止
- サーバ側で重複チェック
🧨 事例②：決済成功なのに注文未登録
💥 何が起きたか
- 決済API → 成功
- その後DB保存でエラー
👉 お金だけ取られて注文がない
🔍 原因
- 処理が分離されている
- トランザクション未管理
💣 結果
- 「払ったのに注文されてない」
- 信用崩壊
🛠 防止策
- 決済と注文の整合性管理
- 失敗時のリカバリ処理
- 非同期処理の設計見直し
🧨 事例③：在庫オーバー販売
💥 何が起きたか
- 在庫1の商品に2人が同時購入
👉 両方成功してしまう
🔍 原因
- 同時アクセス制御なし
- 在庫チェックが甘い
💣 結果
- 在庫マイナス
- キャンセル対応発生
🛠 防止策
- 排他制御（ロック）
- 在庫更新のトランザクション化
🧨 事例④：決済失敗なのに注文確定
💥 何が起きたか
- 決済API → 失敗
- でも注文登録は成功
👉 商品だけ発送される
🔍 原因
- 状態管理のミス
- エラーハンドリング不足
💣 結果
- 無料配送状態
- 損失発生
🛠 防止策
- 決済状態と注文状態の同期
- ステータス管理を明確にする
🧨 事例⑤：リトライ地獄（非同期バグ）
💥 何が起きたか
- タイムアウト → 自動リトライ
- 実際は成功していた
👉 何度も決済される
🔍 原因
- 成功・失敗の判定ミス
- 冪等性なし
💣 結果
- 多重課金
- 返金対応祭り
🛠 防止策
- リトライ時の状態確認
- 決済IDで一意管理
🧠 決済バグの共通パターン
全部まとめると👇
👉 「状態のズレ」
- フロントとサーバ
- 決済とDB
- 同時処理
🎯 テストで絶対見るべきポイント
① 二重処理
- 連打
- リトライ
- 再送信
② 状態遷移
- 決済成功 → 注文確定
- 決済失敗 → 注文未確定
③ 同時アクセス
- 在庫
- 同時購入
④ 例外系
- 通信エラー
- DBエラー
- タイムアウト