要約

  • RFC 3538 は、SET の各メッセージを生成または処理した節目に 20、40、60、80、100 を割り当てた。この数値は IOTP ブリッジの進捗であり、商取引の完了率ではない。
  • 100 に対応する PRes は、承認済みのオーソリゼーションの場合も、成功した売上確定の場合もあった。さらに CompletedOK は取消後に Failed へ移り得たため、精算や引き渡しの最終性までは証明しなかった。

運用画面のバーが右端まで伸びた場面を考えよう。そこで確定したのは、利用枠の承認だろうか、売上の確定だろうか、金融機関間の精算だろうか、倉庫からの出庫だろうか。それとも、もう取消できないという意味だろうか。現在の製品画面では、これらが一つの「完了」にまとめられやすい。2003年6月に Informational RFC として公開された RFC 3538 は、もっと狭く答える。SET と IOTP の間のブリッジが、対応表の最後のメッセージまで進んだのである。

IOTP は、個別の決済方式を Payment API の内側に置きながら、インターネット取引に共通の枠組みを与えようとした。RFC 3538 は Secure Electronic Transaction のメッセージと状態を IOTP 1.0 に接続する補足仕様である。凍結した資料には、普及率も、実在する店舗の取引も、障害事例もない。したがって、ここから市場での成功を作り出してはならない。重要なのは、仕様が局所的な観測を局所的な主張として残したことだ。

第8.12節の表では、最初の SET Initiation Response を生成または処理すると PercentComplete は20になる。PinitReq は40、PinitRes は60、PReq は80、PRes は100である。Consumer と Payment Handler は、生成と処理を反対側から見る。開始段階のメッセージ数は可変なのに、最初の応答には20が与えられる。つまり、この尺度は同量の作業を測るものでも、残り時間を予測するものでもない。実装者が選んだインターフェース上の道標である。

最後の道標の中身は一種類ではない。PRes の成功として、仕様は authorizationPerformed と承認された AuthCode の組合せ、または capturePerformed と成功した CapCode の組合せを扱う。オーソリゼーションは進行を許す判断であり、キャプチャは別の商業段階である。同じメッセージ形式と同じ100が、異なる事象を包み得る。画面が満杯でも、何が完了したかは completion code を読まなければ分からない。

Payment Handler の状態機械は、終端らしい名前にも留保を付ける。進行中の SET 取引は CompletedOK へ移る一方、支払いが取り消された場合には、状態変更または CancelPayment によって CompletedOK -> Failed という遷移が許される。「完了」は、ある構成要素がある時点で記録した状態である。遷移履歴を消せば、可逆なチェックポイントを不可逆な結論へ変えてしまう。

領収情報の扱いは、さらに明瞭な警告になる。CheckPayReceipt は Payment Receipt Information そのものを特別に検査せず、要求メッセージが有効であれば一般的な応答を返す。API の責務としては正しい。しかし、UI がこれを「取引内容を検証済み」と表示すれば、主張は仕様を越える。正しい形式、認識できる領収コンテナ、商業的事実の独立確認は、別々の証拠である。

物理的な引き渡しも決済ブリッジの外に残る。物品について RFC は IOTP Delivery Exchanges を省くよう勧める。配送照会用の場所を指定でき、Payment Handler と Delivery Handler の間の信用承認照会は IOTP 外で処理できる。デジタル商品ではリアルタイムの承認を勧める。これは配送を軽視したのではなく、所有者を分けた設計だ。決済メッセージの完走は、荷物を動かすことも、データが読者へ届いたことも証明しない。

照会とエラーも同じ原則に従う。SET Inquiry Initiation は使わず、照会要求と応答を IOTP の PaySchemeData に格納する。ブリッジの技術エラーは HardError であり、業務上の失敗とは別経路で表す。発生層を捨てると、正常に運ばれた拒否を通信障害と誤認し、正常に運ばれたメッセージを商取引の成功と誤認する。

この論点は、IOTP v2 要件と構成・承認の境界を扱った RFC 3354 の既存記事とは異なる。また、IOTP 1.0 の訂正、取引識別子、照会、支払い・精算・配送の大枠を扱った RFC 3504 の記事も反復しない。RFC 3538 固有の材料は、五つの数値、PRes の二つの成功意味、限定された領収検査、そして完了後の取消遷移である。

設計上の教訓は、すべての進捗表示に分母と所有者を付けることだ。どのメッセージを誰が生成・処理したか、どの completion code が含まれたか、その後どの遷移が起きたかを保存する。そうすれば100は有用な証拠になる。保存しなければ、100は測っていない結果から確実さを借りる記号にすぎない。

情報源