【ITニュース解説】Settlement batches group by capture date, not auth date, and reconciliation breaks on day boundaries

システムエンジニアを目指す初心者の皆さんにとって、決済システムは一見複雑に感じるかもしれないが、その裏側では様々な仕組みが動いている。今回取り上げるニュース記事は、クレジットカード決済における「承認（Authorization）」と「売上計上（Capture）」、そして「照合（Reconciliation）」という重要な概念が、実際のシステム運用でどのような課題を生み出すかを示す具体的な事例だ。

まず、クレジットカード決済の基本的な流れから説明しよう。私たちがお店でカードを提示してから、実際に銀行口座からお金が引き落とされるまでに、いくつかの段階を踏む。特に重要なのが、「承認」と「売上計上」の二つだ。承認とは、買い物をした時点で、そのクレジットカードが有効であり、指定された金額を支払うだけの利用限度額があるかを確認するプロセスだ。この段階ではまだ実際にお金が動くわけではないが、カード会社が支払いを保証してくれる状態になる。一方、売上計上は、商品やサービスを実際に提供した後に、その承認された金額をカード会社に請求し、銀行口座へ入金してもらうための手続きだ。多くの場合、承認と売上計上はほぼ同時に行われるが、例えば商品を後日発送する場合など、承認だけを先に行い、売上計上は後から行う「遅延売上計上（Delayed Capture）」という形もある。

これらの決済処理は、一つ一つが個別に銀行へ送られるのではなく、効率化のために、ある一定期間や件数ごとにまとめて処理される。このまとめられた単位を「決済バッチ（Settlement Batch）」と呼ぶ。アクワイアラーと呼ばれる決済代行会社や銀行は、この決済バッチ単位で決済データを集計し、処理を進める。企業側では、日々発生する売上と、銀行から実際に振り込まれる金額が正しいかを突き合わせる作業が必要になる。これが「照合（Reconciliation）」だ。自社の会計システムに記録されたデータと、アクワイアラーが提供する決済レポートのデータを比較し、金額や件数が一致していることを確認することで、不正やシステムエラーがないかをチェックし、正確な会計処理を行うことができる。

今回ニュースになったのは、この照合のプロセスで発生したある問題に関する話だ。ある企業が、B2B（企業間取引）の請求書発行フローで、クレジットカード決済を利用しており、承認と売上計上を時間差で行う「遅延売上計上」を採用していた。具体的な状況を見てみよう。顧客がクレジットカード情報を入力し、午後11時40分に決済の「承認」が完了した。しかし、請求書の発行が確定するのは夜中なので、実際の「売上計上」は、翌日の午前0時10分にバックエンドのジョブによって実行された。つまり、承認と売上計上が日付をまたいでしまったわけだ。

この「日付をまたぐ」という点が、今回の問題の鍵となる。アクワイアラーのシステムは、決済バッチを「売上計上日（Capture Date）」に基づいて区切るというルールを持っていた。つまり、午前0時を過ぎて売上計上された取引は、前日のバッチではなく、翌日のバッチとして処理されるのだ。一方、この企業の社内システムでは、決済の「注文ID」と「承認日」に基づいて照合を行っていた。彼らは、承認と売上計上がほぼ同時に行われることが大半であるため、これらが常に同じ決済バッチに入るだろうと仮定していた。実際、95%以上のケースでは承認と売上計上が数秒しか離れていないため、この仮定で問題は起きなかった。

しかし、今回のように承認が午後11時40分、売上計上が翌日の午前0時10分というように、日付をまたいでしまうとどうなるか。アクワイアラーのルールでは、承認は前日のバッチに属し、売上計上は翌日のバッチに属することになる。つまり、一つの注文に対する承認と売上計上という二つのイベントが、別々の決済バッチに分割されてしまったのだ。結果として、企業の社内システムでの照合では、「午後11時40分の承認記録はあるものの、それに紐づく売上計上の記録がアクワイアラーの当日の決済バッチレポートに見当たらない」という状況が発生した。システム上では、その注文が「承認済みだが、決済がまだされていない」という未解決の状態として24時間表示され続けた。実際には決済は正常に進んでいるにも関わらず、システムが一時的に不整合と判断してしまったのだ。この状況は、アクワイアラーの翌日の決済バッチレポートが届き、そこに午前0時10分の売上計上データが含まれていることが確認されると、自動的に解決された。つまり、処理自体に何も間違いはなかったが、自社システムの照合ロジックが、アクワイアラーのバッチ処理ルールやタイムゾーンの違いを考慮していなかったために、一時的な「不一致」が生じてしまったのだ。

この問題を受けて、企業は照合ロジックを修正した。一つ目の修正は、アクワイアラーから提供されるレポートに記載されている「決済バッチID（Settlement Batch ID）」を直接利用するようにしたことだ。これにより、自社のタイムスタンプからバッチを推測するのではなく、アクワイアラーが公式に発行するバッチIDを基に照合を行うため、バッチの区切りがずれるという問題は解消された。二つ目の修正は、承認された取引が未決済状態である場合に、エラーとしてフラグを立てるまでの猶予期間を延長したことだ。以前は、例えば24時間以内に決済が確認できない場合にエラーとしていたかもしれないが、これを48時間などの猶予期間を設けるように変更した。これにより、日をまたいで別バッチになった場合でも、次の決済バッチが処理されるまでの時間を考慮し、焦ってエラーと判断しないようになった。

この事例は、システム設計において非常に重要な教訓を与えてくれる。外部システム、特に決済システムのような金融に関わるシステムと連携する際には、その外部システムの厳密な仕様を理解することが不可欠だ。特に、日付や時刻の扱いは、タイムゾーンの違いやシステム間の処理タイミングによって、自社の想定と大きく異なる場合がある。今回のように、わずかな時間のずれが、システム間のデータの不整合を引き起こす可能性があるのだ。「ほとんどのケースでは問題ない」という仮定でシステムを構築することは、一見効率的に見えるが、残りのわずかなエッジケース（境界条件）で思わぬ問題を引き起こすことがある。システムエンジニアは、こうしたエッジケース、特にタイムゾーンをまたぐ処理や、時間差のある処理について、常に意識しておく必要がある。さらに、外部システムから提供されるIDや参照情報（今回の場合は決済バッチID）は、自社で情報を推測するよりもはるかに信頼性が高い。可能な限り、そうした公式な情報を利用してシステム間の整合性を取るべきだ。また、照合の際には、一時的な不整合を許容し、最終的な整合性が取れるまでの猶予期間を設けるといった、柔軟な設計も重要になる。この経験は、アクワイアラーの決済タイムゾーンと加盟店のビジネスタイムゾーンが異なる場合、遅延売上計上が夜中をまたぐと必ず発生する。この点を明示的に追跡するような照合システムを最初から設計するか、あるいは今回の事例のように「ハードな経験」を通じて学ぶことになるか、という問いを投げかけている。システム設計者は、このような細部に注意を払い、堅牢なシステムを構築する責任があることを、改めて認識させる事例だ。