越境ECサイトに決済を導入した後、注文の二重請求をどう防ぐ？

購入者が支払いを実行した後、ページが読み込み中のままになり、更新して再試行したところ、管理画面には成功した取引が2件表示されていた。越境ECシステムの決済連携では、このような問題は決済ボタンの不具合ではなく、ネットワークのタイムアウト、同時リクエスト、非同期通知の間で一貫した制御ルールが欠けていることが原因である場合が少なくない。二重請求を防ぐには、決済リクエストの冪等性、コールバックの重複排除、注文ステータスの検証、異常時の照合を同時に適切に行う必要があり、フロントエンドでクリックを制限するだけでは不十分だ。

まず確認すること：通知が重複したのか、実際に二重請求されたのか？

同じ決済成功イベントがゲートウェイから複数回送信されても、購入者に二重請求されたことを意味するわけではない。技術的な調査では、同じ取引に対するコールバックの重複、同じ注文で複数の決済セッションが作成されたケース、異なる取引番号でそれぞれ資金が引き落とされたケースの3つを区別する必要がある。それぞれ対処方法は異なる。

また、与信と本決済も区別する必要がある。一部のカードでは、最初に資金が一時的に保留され、その後に引き落としが確定する。購入者の請求明細のスクリーンショットだけで二重決済と判断してはならない。決済サービス事業者の取引番号、与信および引き落としのステータス、金額、通貨、精算記録を照合する必要がある。システムを評価する際は、重複防止の対象が決済の作成、与信、最終的な引き落としのどれなのかも明確にし、いずれか1つのインターフェースだけを保護することのないようにする。

越境ECシステムの決済連携：冪等キーは同一の業務操作に対応させる

決済APIのタイムアウトが示すのは、ECサイトが結果をすぐに取得できなかったということだけであり、ゲートウェイがリクエストを受け付けなかったという意味ではない。再試行のたびにプログラムが新しいリクエスト識別子を生成すると、ゲートウェイが別の正当な決済として認識する可能性がある。

より確実な方法は、まず決済試行の記録をデータベースに保存してからゲートウェイを呼び出し、同一の業務操作に対して一貫した冪等キーを割り当てることだ。接続の切断、ページの更新、タスクの再試行が発生しても、同じキーを再利用する必要がある。また、リクエストの金額や通貨などのパラメーターも一致させなければならない。冪等キーの適用範囲、有効期間、パラメーターが競合した場合の処理はゲートウェイごとに異なるため、APIドキュメントを項目ごとに確認する。

• 注文番号：売買関係を識別するもので、特定の決済リクエストと単純に同一視してはならない。
• 決済試行番号：追跡可能な1回の決済プロセスを記録し、決済チャネル、金額、通貨、ゲートウェイ取引番号と関連付ける。
• 操作冪等キー：作成、引き落とし、返金などの操作ごとに設計し、異なる操作で同じキーを使い回してはならない。

前回の決済ステータスが不明な場合、すぐに別のキーで再度引き落としを行ってはならない。失敗、取消、またはセッションの無効化を確認した後にのみ、ルールに従って新たな決済試行を開始できるようにする。ゲートウェイの冪等キーの保持期間を過ぎたリクエストも、安易に再送せず、まず元の取引を照会する。

ボタンの無効化より、同時リクエストの防止が重要

ボタンを無効化すれば誤操作を減らせるが、複数のタブ、モバイル端末からの重複送信、APIへの直接呼び出しは防げない。バックエンドでは、決済試行番号の一意性、該当する加盟店アカウント内でのチャネル取引番号の一意性、同一注文に対してルールなく複数の有効な決済試行を作成できないようにすることなど、データベースで重要な制約を保証する必要がある。

決済を作成する前に、トランザクション内で注文の支払いが完了していないこと、金額に変更がないことを検証し、行ロック、バージョン番号、条件付き更新などで競合を制御する。分散ロックは負荷制御の補助として利用できるが、データベース制約の代わりにはならない。ロックの期限切れやプロセスのクラッシュに備え、永続化された記録も必要だ。

フローは、注文の検証と決済試行の作成 → ゲートウェイの呼び出し → 返却結果の保存 → 通知の受信または能動的な照会 → 条件付きでの注文更新、という形で設計することを推奨する。通常、外部決済の呼び出し中にデータベーストランザクションを長時間保持するのは避けるべきだ。

注文と決済試行では、それぞれ別個にステータスを管理するのが望ましい。注文は支払い待ちのままでも、決済試行は処理中または結果確認待ちの状態になり得る。APIがタイムアウトしたからといって、直ちに失敗と判定してはならない。注文で分割払いを認める場合は、確認済みの入金総額に基づいて検証し、「1注文につき取引は1件のみ」と単純に制限してはならない。

コールバックは「繰り返し受信でき、処理は一度だけ」にする

決済通知は、重複、遅延、または順不同で届くことがある。受信側ではまずゲートウェイのルールに従って署名を検証し、加盟店アカウント、注文との関連付け、金額、通貨を照合する必要がある。「成功」フィールドがあるだけで処理を許可してはならず、ブラウザーが戻った先の成功ページを信用してはならない。

続いてイベントを永続化し、チャネルイベント番号に一意制約を設ける。安定したイベント番号がない場合は、チャネルの仕様に基づいて重複排除用の識別子を設計する。同時に取引番号と業務ステータスを照合し、異なるイベントが同じ引き落としを示している場合に処理が重複しないようにする。条件付き更新によるステータス遷移が完了した後にのみ、後続の業務処理を開始する。

イベントの重複排除記録、注文の更新、送信待ちの業務イベントは、できる限り同一トランザクション内でコミットし、その後、信頼性の高いメッセージ機構を使って在庫、出荷、通知を処理する。後続のコンシューマー側でも冪等性を確保し、「二重請求はないが、出荷は重複する」という事態を防ぐ。ゲートウェイに受信確認を返す前に、イベントが確実に保存されていることを確認する。一時的な処理失敗については、プロトコルで認められた方法に従って再試行する。

タイムアウト、決済チャネルの切り替え、遅れて届く成功通知を個別に設計する

越境決済には、認証コードによる認証、リダイレクト決済、現地の決済方法などがあり、結果がフロントエンドの待機時間を超えて届くことがある。ページでは「決済結果を確認中」と表示し、照会できる手段を提供する。すぐに購入者に再決済を促してはならない。バックエンドでは、能動的な照会と補償タスクによってステータスを収束させ、照会頻度はチャネルの制限に従う。

購入者が決済チャネルを切り替える際は、可能な限り古いセッションを終了し、終了によって後続の引き落としが本当に阻止されるのかを明確にする。古い取引の成功通知が遅れて届き、新しい取引も成功していた場合は、すべての取引記録を保持し、過剰入金を検出したうえで、手動審査または管理された返金フローに進める。返金自体にも冪等性が必要で、返金の着金結果を追跡しなければならない。「返金申請済み」を「資金の返還完了」と見なしてはならない。

技術検収では、障害発生後の挙動を重点的に確認する

越境ECの決済ソリューションを評価する際は、正常な決済を一度完了するだけでなく、次のシナリオのデモを依頼することを推奨する。

• ゲートウェイがリクエストを受け付けた後にAPIがタイムアウトした場合、再試行後も元の取引に関連付けられるか。
• 2つのページから同時に決済した場合、制御されない重複した決済試行が発生しないか。
• 成功通知が重複または順不同で届いた場合、記帳と出荷はそれぞれ1回だけ行われるか。
• 引き落とし後、データベースへの保存前にサービスがクラッシュした場合、照会と照合によって復旧できるか。
• チャネル切り替え後に古い取引の成功通知が遅れて届いた場合、過剰入金を検出して処理できるか。

易營宝のように、サイト構築と海外マーケティングを一体で提供するプラットフォームでは、決済の検収を「決済の接続が完了した」という段階にとどめず、ECサイトの注文、決済チャネルの取引記録、アフターサービスの処理フロー全体にわたって実施する必要がある。技術選定で本当に確認すべきなのは、リクエストを安全に再試行できるか、ステータスを追跡できるか、異常を補償できるかという点だ。これらのルールをデータベース制約、API仕様、検収テストに反映することで、二重請求のリスクを低減し、支払いを待つ購入者の不安も軽減できる。