【ITニュース解説】The FX rate nobody locked between auth and capture

システム開発において、お金のやり取り、特にオンライン決済は非常に複雑で、多くの要素が絡み合っている。その中でも、為替レートの変動は、思わぬ問題を引き起こすことがある。今回取り上げるのは、クレジットカード決済における「承認」と「売上確定」という二つの段階の間で為替レートが変動し、顧客と事業者双方に混乱をもたらす可能性のある事例とその解決策だ。

まず、クレジットカード決済の基本的な流れを理解する必要がある。顧客がオンラインストアで商品を購入し、クレジットカード情報を入力して決済を行う際、最初のステップは「承認（Authorization）」と呼ばれる。これは、顧客が入力したクレジットカード情報が有効であるか、そして指定された金額を支払うための利用限度額があるかを確認するプロセスだ。この承認が成功すると、その金額分の利用枠が一時的に確保される。しかし、この時点ではまだ実際の支払いは行われていない。例えるなら、「このカードでこの金額を支払う準備ができていますよ」という予約のようなものだ。

次に、「売上確定（Capture）」というステップがある。これは、商品が実際に発送されたり、サービスが提供されたりした後に実行される。売上確定が行われて初めて、確保されていた利用枠が実際に顧客のクレジットカードから引き落とされ、事業者の口座へ支払いが進められる。承認と売上確定が別々のステップになっているのは、例えば商品が品切れになったり、発送が遅れたりした場合に、すぐに顧客から引き落としを行わないようにするためだ。万が一の場合でも、承認を取り消すだけで済み、顧客に無駄な請求をせずに済む。

ここまでは一般的な話だが、問題は、この承認と売上確定の間に「時間差」があり、さらに「異なる通貨」が関わってくる場合に発生する。例えば、ヨーロッパの顧客が日本のオンラインストアで買い物をした場合を考えてみよう。顧客のクレジットカードはユーロ（EUR）建てだが、日本のオンラインストアは円（JPY）で決済を受け取りたいとする。この場合、承認時にはユーロから円への為替レートが適用され、顧客にはユーロ建てでの概算金額が提示される。しかし、商品が発送されるまで数日かかり、その間に売上確定が行われるとする。この数日の間にユーロと円の為替レートが変動した場合、売上確定時に再度その時点での為替レートが適用されると、承認時の金額と売上確定時の金額に差が生じてしまうのだ。

記事の事例では、ユーロ建てで承認が行われた注文が、数日後の売上確定時には米ドル（USD）で決済された。この間にユーロと米ドルの為替レートが1.1%も変動したため、顧客のクレジットカード明細に記載された金額が、注文時に提示された金額よりも高くなってしまったのだ。顧客からすれば、「最初に提示された金額と違う」という不満につながり、事業者は顧客からの問い合わせ対応に追われることになる。これは、顧客体験の悪化だけでなく、事業者の信頼性にも関わる重大な問題だ。

なぜこのような問題が起こるのか。クレジットカードネットワークや決済代行会社の仕様に理由がある。一般的に、クレジットカードネットワークは、承認時に保証する為替レートの期間を限定している。この保証期間はプロセッサーによって異なるが、通常24時間から72時間程度だ。つまり、承認からこの保証期間内に売上確定が行われれば、承認時の為替レートが適用されるが、期間を過ぎて売上確定が行われると、一部のアクワイアラー（クレジットカード決済を受け付ける側の金融機関）は、その時点の最新の為替レートで金額を再計算してしまうのだ。しかも、この再計算が行われたかどうか、あるいは金額が変更されたかどうかは、決済APIのレスポンスには明示されないことが多い。事業者は、取得した売上確定金額が承認時の金額と少しだけずれていることに、後になって気づくことになる。このわずかなずれが、数セントから数ドル、あるいはそれ以上の差になることもある。

システムエンジニアの視点から見ると、これはデータ不整合とエラーハンドリングの問題だ。顧客に提示した金額と、実際に引き落とされる金額が異なるというのは、システムの信頼性に関わる重大なバグにも等しい。この問題を解決するため、記事の筆者の企業は、いくつかの対策を講じた。まず、承認が行われた時点で、その時の為替レートを自社のシステム内に記録するようにした。そして、売上確定後に決済代行会社から送られてくる決済レポートと、自社で記録した承認時の為替レートを基にした金額を、一件ずつ比較照合する仕組みを導入した。

この比較照合の結果、わずかな差額であれば、事業者がその差額を負担して吸収することにした。例えば、数セント程度の小さな差額であれば、顧客に返金する手間や、そのためのシステム改修コストを考慮すると、事業者が吸収する方が効率的だという判断だ。しかし、一定の閾値（例えば、数ドル以上）を超える大きな差額が発生した場合は、自動的に処理せず、手動での確認と対応（顧客への連絡や返金処理など）を行うようにした。これにより、システムが自動的に吸収しきれない大きな問題を見落とすことを防ぎ、かつ日常的な小さなずれは効率的に処理できるようになった。

この事例は、単に決済システムを導入すれば終わりではなく、そこから派生する様々なビジネス上の課題や、システム間の連携、データ管理の重要性を示している。システムエンジニアは、単に機能を実現するだけでなく、その機能が現実世界でどのように利用され、どのような影響を与えるかまで深く考える必要がある。特に、お金に関わるシステムでは、たとえ小さなずれであっても、顧客の信頼を損なうことになりかねないため、厳密な設計と検証が求められるのだ。為替レートの変動は常に起こり得る外部要因であり、それをシステムがどのように吸収し、適切に処理するかは、サービスの品質を左右する重要な要素なのである。