【ITニュース解説】Authorization holds expire before you think they will

クレジットカード決済において、システムエンジニアが直面する可能性のある重要な問題の一つに、「オーソリゼーションホールド」（与信枠確保）の有効期限がある。これは、顧客がクレジットカードで商品やサービスを予約したり、一時的に利用したりする際に、そのカードが有効であり、かつ必要な金額分の利用可能枠が確保できるかどうかを、カード会社に問い合わせて一時的に確保する処理のことだ。例えば、レンタカーの予約時やホテルのチェックイン時などに、実際の支払い確定よりも前に、将来の支払いに備えて利用可能枠を確保するためにこの処理が行われる。

この与信枠確保は、永久に続くものではなく、一定の有効期限が設けられている。一般的には、Visaの場合、ほとんどの業種で7日間が有効期限とされている。しかし、ホテルやレンタカーのように、より長期間の与信枠確保が必要な特定の業種（加盟店カテゴリ、MCCと呼ばれる）では、正しく設定されていれば30日間まで延長されることがある。一方、Mastercardの場合は、カードを発行した金融機関（イシュア）によって有効期限が異なり、Visaよりも短い期間がデフォルトで設定されているケースも多い。

問題は、このオーソリゼーションホールドがシステム上で有効であると表示されていても、カード会社側のシステムでは既に有効期限が切れてしまい、与信枠確保が無効になっている状態が発生することだ。これは、決済処理の応答コードとして明確に「オーソリが切れました」といった情報が通知されないため、システム開発者はこの状況を事前に知ることが非常に難しい。システム側では「承認済み、売上保留中」と表示され続けているため、問題に気づきにくいのだ。

このようにオーソリゼーションホールドが切れてしまった後に、実際に利用料金をカード会社に請求して売上を確定させる処理、これを「キャプチャ」と呼ぶが、これを実行しようとすると、予測できない様々な問題が発生する。この時の挙動は、利用している決済代行会社（プロセッサー）によって異なり、それがシステム運用上の大きなリスクとなる。

あるプロセッサーの場合、オーソリが切れた状態でキャプチャを試みると、単に「一般的な拒否」というエラーが返ってくる。これは、与信枠が確保されていないため売上を確定できないという分かりやすい結果だ。

別のプロセッサーの場合、オーソリ切れを検知すると、キャプチャ時に自動的にその取引を「新しい売上」として扱い、改めてその時点で利用者のカードに対して与信枠の確保（再オーソリ）を試みることがある。この再オーソリが成功すれば問題なく売上が確定されるが、もし利用者がカードを紛失して新しいカードに切り替えていたり、あるいは利用限度額を超えていたりする場合には、再オーソリが失敗し、結果として売上を確定できないという事態に陥る可能性がある。システムは、再オーソリが失敗した場合の適切な代替処理を考慮する必要がある。

さらに厄介なケースとして、オーソリが切れているにもかかわらず、プロセッサーがキャプチャ処理をそのまま受け付けてしまうことがある。この場合、決済処理上は一時的に成功したかのように見えるが、実際には与信枠が確保されていないため、カード加盟店契約を結んでいる銀行（アクワイアラー）がそのリスクを一時的に背負うことになる。そして後日、顧客がその取引について「身に覚えがない」と異議申し立て（チャージバック）を行った場合、アクワイアラーや最終的には加盟店がその損失を負担することになる。これは、システムが気づかないうちに潜在的な金融リスクを抱え込んでしまうことを意味し、非常に危険な状態と言える。

これらのプロセッサーごとの挙動の違いは、実際に問題が発生し、キャプチャを試みるまで、開発者には予測がつかないという課題があった。このような不確実性は、決済システムを安定的に運用する上で、予期せぬエラーや売上の損失、顧客からの信頼低下、さらにはチャージバックによる損害に繋がるため、深刻な問題である。

このような問題を解決するために、ある企業では具体的な対策を講じている。それは、システム内で「承認済み、売上保留中」となっている取引の中で、例えば5日以上経過したものを対象に、夜間バッチ処理を実行するというものだ。このバッチ処理では、実際に売上を確定する前に、期限が切れそうな保留中の売上に対して、強制的に再度与信枠の確保（再オーソリ）を試みる。これにより、もし与信枠が既に失効していれば、キャプチャ処理を行う前にその事実を検知できる。そして、事前に問題を把握し、顧客への連絡や代替決済手段の案内といった適切な対応を取ることが可能になる。これにより、売上確定時の予期せぬエラーを減らし、決済処理全体の安定性と信頼性を向上させることができる。

この事例は、クレジットカード決済のような複雑なシステムを構築・運用する上で、APIの応答コードだけでなく、その背後にあるカードブランドや金融機関のルール、そして決済代行会社の挙動といった、多岐にわたる要素を深く理解することの重要性を示唆している。単に決済APIを呼び出すだけでなく、潜在的なリスクを予測し、それに対する防御策をシステムに組み込むことが、安定したサービス提供には不可欠となる。システムエンジニアを目指す上で、このような複雑な商取引の仕組みと、それに伴うリスク管理の重要性を理解しておくことは、非常に価値のある経験となるだろう。