【ITニュース解説】Partial refunds break when there were multiple captures

決済システムを構築する際、特にオンラインショッピングのような場面では、クレジットカードによる決済が一般的に利用される。この決済処理には、「オーソリゼーション」と「キャプチャ」という二つの重要なステップがある。オーソリゼーションとは、顧客がクレジットカード情報を入力し、購入ボタンを押した際に、そのカードが有効であり、指定された金額の支払いが可能かどうかをカード会社に確認するプロセスだ。これは、まだ実際の引き落としではなく、単に与信枠が一時的に確保される状態を指す。例えるなら、お店が「このお客さんはこの金額を払う能力がありますか？」と銀行に尋ね、銀行が「はい、大丈夫です」と保証するようなものだ。

一方、キャプチャとは、オーソリゼーションで確保された金額を、実際にカード保有者の口座から引き落とし、加盟店側の口座へ振り込みを指示するプロセスである。これは通常、商品が発送されたり、サービスが実際に提供されたりした後に実行される。オーソリゼーションが「予約」だとすれば、キャプチャは「実際の購入」に当たる。今回のニュース記事が取り上げる問題は、このキャプチャが複数回にわたって行われるケースで発生した。

具体的な事例では、顧客が複数の商品を注文したが、在庫状況や物流の都合で商品が一度に全て発送されず、二回に分けて発送されたとする。例えば、半分が即日発送され、残りが三日後に発送されたという状況だ。この場合、それぞれの発送タイミングで、その分の金額だけをキャプチャするという処理が行われることがある。最初のオーソリゼーションは一つだが、それに対して二つのキャプチャが行われたわけだ。どちらのキャプチャも、同じクレジットカード情報と注文IDに基づいて実行されている。

問題が発生したのは、顧客が注文した商品の一部、具体的には二回目の発送に含まれていた商品をキャンセルし、その分の返金を求めた時だった。システムは、キャンセルされた商品の金額を決済プロセッサ（決済処理を代行する外部サービス）に返金するようリクエストした。この時、システムはプロセッサに対して、最初に実行された「元のオーソリゼーション参照」という情報を渡した。しかし、返金対象となる「具体的なキャプチャID」（つまり、二回行われたキャプチャのうち、どちらに返金すべきかを示す情報）は指定しなかった。

その結果、決済プロセッサは、システムが意図した二回目のキャプチャではなく、一枚目のキャプチャに対して返金を適用してしまった。自社システム側の帳簿（レジャー）では、顧客がキャンセルした「商品二」が返金されたと記録された。しかし、決済プロセッサから提供される決済レポートを確認すると、返金が適用されたのは「商品一」を含む一枚目のキャプチャの金額が減額されていることが判明したのだ。

なぜこの問題がすぐに発覚しなかったのかというと、注文全体で見た場合、返金処理が行われたことで合計金額は一致していたためだ。特定の「商品二」が返金されたかどうかを詳細に追跡しない限り、プロセッサが意図しないキャプチャに対して返金を行ったことには気づけない。このため、問題は発覚しにくい形で潜在し、顧客からの問い合わせや、システム内部での詳細なデータ突合が行われるまで見過ごされる可能性が高かった。

この根本原因は、返金リクエスト時に、どのキャプチャに対して返金を行うかを明示的に指定しなかったことにある。多くの決済プロセッサは、特定のキャプチャIDが指定されない場合、独自のルールに基づいて返金対象となるキャプチャを選択する。例えば、最も古いキャプチャから優先的に返金を行うプロセッサもあれば、残高やその他の条件に基づいて判断するプロセッサもある。そして、こうしたプロセッサのデフォルトの挙動は、しばしば公式ドキュメントに明確に記載されていないことが多い。特に、返金APIのドキュメントではなく、キャプチャに関するセクションにひっそりと記述されている場合があり、開発者が見落としやすいポイントとなる。

この問題を解決するためには、システム設計の見直しが必要となる。具体的には、自社システム内で各キャプチャの情報を個別に保存し、それぞれに割り振られたユニークな「キャプチャID」を厳密に管理することが不可欠だ。そして、顧客からの返金リクエストがあった際には、「元のオーソリゼーション参照」だけでなく、返金対象となる「特定のキャプチャID」を決済プロセッサに対して明示的に指定して返金処理を行うようにする。親となるオーソリゼーション全体に対して返金するのではなく、常に具体的なキャプチャに対して返金することで、プロセッサが誤ったキャプチャに返金を適用するリスクを回避し、自社システムの記録とプロセッサの記録との一貫性を確実に保つことができる。

システムエンジニアを目指す上で、このような決済処理の細かな挙動は非常に重要だ。特に、部分的なキャプチャや部分返金といった複雑なフローを持つシステムを扱う際には、決済プロセッサとの連携方法を深く理解し、その挙動を過度に信頼せず、自社システム側で可能な限り厳密に状態を管理する設計が求められる。複数の部分的な決済が発生する可能性を考慮に入れ、各ステップの識別子（ID）を適切に追跡・管理することが、将来的なトラブルを防ぎ、システムの正確性と信頼性を確保するための鍵となる。