【ITニュース解説】The stored-credential flag only some issuers enforce

システムエンジニアを目指す上で、クレジットカード決済のような金融システムがどのように動作し、どんな課題があるのかを理解することは非常に重要だ。今回取り上げるニュースは、定期購入サービスなどで利用されるクレジットカード決済の裏側にある、複雑で時に厄介なルールについて深く掘り下げている。

まず、定期購入やサブスクリプションサービスで毎月自動的に料金が引き落とされる仕組みについて考えてみよう。顧客は一度カード情報を登録すれば、その後は何も操作しなくても自動的に決済が完了する。この利便性を支えているのが「Stored-Credential (SC) Framework」、つまり「保存された認証情報に基づくフレームワーク」と呼ばれる仕組みだ。このフレームワークでは、決済を「顧客が開始する取引（CIT：Customer-Initiated Transaction）」と「加盟店が開始する取引（MIT：Merchant-Initiated Transaction）」の二種類に明確に区別する。

初回に顧客が商品を購入したり、サービスに登録したりする際の決済は、顧客自身がカード情報を入力し、支払いボタンを押すため、CITとして扱われる。この初回取引で、その決済を識別するための一意の番号、すなわち「Original Transaction ID」が生成される。このIDは、その後の継続的な支払いの「源流」となる非常に重要な情報だ。

そして、毎月の利用料金や年会費など、定期的に自動で引き落とされる決済は、加盟店側が顧客の同意を得て、保存されたカード情報を使って開始するため、MITとして扱われる。SC Frameworkのルールでは、このMITを行う際には、初回に生成されたCITのOriginal Transaction IDを一緒に提示することが求められる。これは、このMITが過去に顧客が同意したCITに基づいていることをカード会社に証明するための連結情報のようなものだと考えると良い。このOriginal Transaction IDを継続して提示することで、カード会社は、この継続的な支払いが顧客の同意に基づいた正当な取引であることを確認しやすくなる。

ニュース記事では、あるシステムがこのSC Frameworkに沿って定期購入機能を実装し、テスト環境では問題なく動作したという。最初のCITでOriginal Transaction IDを生成し、その後のMITでこのIDを引き継いで決済処理を行っていた。しかし、本番環境で運用を開始すると、特定のカード発行会社（イシュア）が発行したカードの一部で、継続決済が突然拒否されるという問題が発生した。拒否された際のコードは「05」（Do Not Honor、つまり「承認しない」）であり、特定のカード番号の範囲（BINレンジ）に集中していた。

この予期せぬ問題の原因は、顧客がカード情報を更新した際に、システムの処理に隠されていた。顧客が有効期限の切れたカード情報を新しいカード情報に更新する際、その更新フローが誤って「新たなCITイベント」として扱われ、その結果、新しいOriginal Transaction IDが生成されてしまっていたのだ。つまり、それまで継続して使われていたOriginal Transaction IDの連結が、カード更新のタイミングで途切れてしまい、新しい連結が始まってしまった形になる。

ほとんどのカード発行会社（イシュア）は、カード情報そのものが有効であれば、Original Transaction IDがリセットされても特に問題視せず、継続決済を承認していた。これは、イシュアが主にカード番号、有効期限、セキュリティコードといった「カード認証情報」そのものの有効性を重視し、Original Transaction IDの連結の検証をそこまで厳密に行っていなかったためだ。

しかし、ニュース記事で問題を引き起こした一部のイシュアは違った。彼らはMITが本当に過去のCITに紐づいているか、つまりOriginal Transaction IDの連結が正しくつながっているかを厳格に検証していたのだ。このイシュアにとって、カード情報が更新された際にOriginal Transaction IDがリセットされ、新しいIDが生成されてしまうことは、MITが過去のCITと断絶した不正な取引と見なされ、結果として決済が拒否される要因となった。

SC Frameworkの仕様書では、Original Transaction IDは「指標の一つ」とされている。この表現は、イシュアによってその解釈や適用に幅があることを示唆している。つまり、実際にシステムを運用してみると、「Original Transaction IDを完全に無視するイシュア」から「Original Transaction IDの連結を厳格な要件とするイシュア」まで、その対応は多岐にわたる。この差は、テスト環境では見つけにくく、実際に多くのカード発行会社を経由する本番環境で決済を処理し、デクラインコード（承認拒否コード）の発生状況を特定のBINレンジごとに数週間監視することで初めて明らかになる、という実態がある。

この事例は、システムエンジニアを目指す上で非常に重要な教訓を含んでいる。外部システム、特に金融機関のような厳格なルールを持つシステムと連携する際には、仕様書に書かれていることだけでなく、「実際の運用における癖」や「解釈の幅」を深く理解する必要があるということだ。

システム設計の観点から見ると、カード情報更新のようなイベントが発生した際に、関連する決済履歴やIDの扱いは非常に慎重に行わなければならない。顧客のカード情報が変わっても、その顧客が継続して利用しているサービスであることに変わりはないため、MITの連結を途切れさせないような設計が求められる。例えば、カード情報が更新されたとしても、最初のCITのOriginal Transaction IDを永続的に保持し、それを後続のMITに常に引き継ぐようなロジックが必要となるだろう。あるいは、カード更新時に特定のフラグを立てて、イシュアが「これはカード情報更新に伴う正当なIDリセットである」と判断できるようにする、といった工夫も考えられる。

このような問題は、テスト環境だけでは見つけにくい。なぜなら、テスト環境で用意されるカード発行会社の模擬システムは、多くの場合、一般的な挙動のみをシミュレートし、特定のイシュアが持つような厳格なチェックまでは再現しないことが多いからだ。したがって、実際のシステム開発では、本番環境での監視体制をしっかりと構築し、デクラインコードの傾向を分析することで、潜在的な問題を早期に発見し、対応できるような運用体制も重要となる。

また、このような問題に直面した際に、他の事業者がどのように対応しているのか、情報共有を行うことの重要性も示唆されている。複雑な決済の世界では、すべてのルールや運用パターンを事前に把握することは困難であり、コミュニティや業界内での知見の共有が、より堅牢で信頼性の高いシステムを構築するための鍵となる。システムエンジニアとして、常にアンテナを張り、最新の情報や他社の事例から学ぶ姿勢が求められるのだ。このニュースは、単なるバグ修正の話題に留まらず、外部システム連携の奥深さ、そしてシステム設計における細心の注意と、継続的な監視・改善の重要性を教えてくれる貴重な事例と言えるだろう。