- ISO 8583は、クレジットカードネットワーク間で行われるリアルタイムのメッセージ交換標準
- この標準は、POS端末でカードをタッチしたり、オンラインで「購入」をクリックしたりしたときに発生するメッセージを定義する
- 初期にはPOSやATMが直接メッセージを生成していたが、現在はJSONのような高水準形式に変換した後、ISO 8583へ変換する方式が主に使われている
- メッセージ構造はシンプルだが、詳細な実装は複雑であり、ネットワーク間の互換性のために柔軟性を持っている
基本的なメッセージ形式
メッセージタイプ識別子 (Message Type Indicator)
- 4桁のコードでメッセージ種別を表す（例:
0100 は承認リクエスト）
- 受信側が想定されるフィールドを把握するのに役立つ
- ネットワークごとにシリアライズ方式が異なる場合がある（BCD、ASCII など）
ビットマップ (Bitmap)
- フィールドの存在有無を示す
- 1はフィールドが存在することを、0はフィールドがないことを表す
- 8バイトのサイズで最大64個のフィールドを表せる
データ要素 (Data Elements)
- ビットマップの後にフィールドがシリアライズされる
- 固定長 フィールドは常に同じサイズで、可変長 フィールドは長さ情報を含む
- フィールドのエンコーディング方式にはASCII、BCD、バイナリなどが使われる
ネストされたメッセージ構造
- ISO 8583標準では、ネットワークが ネットワーク固有のユーザー定義データ を含めることを許可している
- ネストされたメッセージは、テーブル、ビットマップ、TLV(Tag-Length-Value) 形式で実装できる
テーブル
- すべてのフィールドが固定長で含まれる
- 空間の無駄を減らすため、追加で可変長サブフィールドもサポートする
ビットマップメッセージ
- 各サブフィールドの存在有無をビットマップで表す
- フィールドがない場合の空間の無駄を防ぐ
TLVメッセージ
- フィールドがタグ、長さ、値のタプルとしてシリアライズされる
- 順序に依存せず拡張可能
パーサー設計
- ISO 8583パーサーは、ビットマップの解析と各フィールドのシリアライズ定義から始まる
- ネストされたメッセージ処理と、ネットワークごとの実装差異を考慮する必要がある
- RubyのSorbet型システム を使って安全なメッセージクラスを定義する
- 固定長フィールドと可変長フィールド、パディング処理などを設定できる
エラー処理
- フィールドのパースに失敗しても、次のフィールドをパースできるように設計する
- メッセージのシリアライズを維持しつつ、部分的なエラーを処理する
- 致命的なエラーが発生した場合はメッセージ処理を中断する
結論
- ISO 8583標準は1987年に定義されて以来、継続的に発展しながらさまざまなネットワーク要件を満たしてきた
- IncreaseはISO 8583メッセージを処理し、ユーザーがプロダクト開発に集中できるよう支援する
- APIドキュメントを参照するか、Increaseチーム に問い合わせ可能
1件のコメント
Hacker Newsのコメント
VisaとMastercardは、ISO 8583を標準化された形では実装していない。各社は何千ページもの文書を公開し、標準フィールドの使い方や、独自データをメッセージに含める方法を説明している。ほとんどのカード管理／発行プラットフォームは、これをうまく抽象化している。ISO 20022への移行は前向きな改善だが、ROIの基準を満たす可能性は低い。
この種のプロトコル（メッセージタイプ、フィールド定義ビットマップ、固定長および可変長の値セット）は、開発当時としては一般的だった。受信側では動的なフィールド長を検証し、メッセージの終端を超えて読み取らないよう注意する必要がある。ただし、こうした問題は今では十分に理解されている。
ISO 8583標準が、フィールドやメッセージタイプをどのようにエンコードするかを明示していないのは当惑させられる。そのせいで、受信側はメッセージを理解できない単なるランダムなバイト列を受け取ることになりうる。
最近は決済に関する議論が多く、patio11が素晴らしいコンテンツを提供している。25年前には、このような視覚的に説明してくれるウェブサイトはなかった。EBCDICに言及した別のコメントにもあるように、エンディアン間の変換は複雑だ。2000年代初頭にDiscoverカードと協力して、ISO8583仕様にGUIDフィールドを追加した経験は面白かった。
金融システムは、変化の最前線の一つだ。多くの人はこうした変化を認識していない。大手テック企業は独自の決済エコシステムを所有しており、これに気づいていない人々に洞察を提供する必要がある。いくつかの国はこの流れに従っている。
Charles StrossはISO 8583標準のせいで少しおかしくなっていて、それがAccelerandoを書くきっかけになったのかもしれない。この標準は、おそらく70年代の曖昧なプロトコルを置き換えた新しい標準なのだろう。
ISO20022がなぜ8583を置き換えるべきなのかを説明する素晴らしい記事だ。特に、M/Vの独占的なネットワークが支配していない地域ではそうだ。クレジットカードは、新しい決済システムにおいて、銀行が提供する与信口座とともに実装できる。口座間の即時決済、低コストの固定料金取引などが可能になる。
ISO 8583の制限を回避するさまざまな方法を見るのは面白かった。最近では、ISOメッセージの前後にAPI呼び出しを行い、決済取引の外側にある追加情報を渡す方法が多く使われている。市場投入までの時間を短縮できるが、新たな障害モードを生む可能性がある。
この形式は面白かった。ISO-8583メッセージを解析していると、歴史が展開していくのが見えた。私が解析したメッセージはEBCDICではなくBCDだった。しかし、あるフィールドにはXMLが含まれていて、そのXMLの中にはJSONが入っていた。メッセージを拡張するたびに、その年代の流行が反映されている。
VisaやMastercardと違って、AMEXの取引通知はほぼ即時に届く。カードをスワイプした瞬間にスマホや時計に通知が出るのは魔法のようだ。V/MCに存在するレイヤーが、AMEXにはないように思える。
Goライブラリを使ったiso8583で大きな成功を収めた。
システムログ内の、base64でエンコードされた（あるいはEBCDICでエンコードされたbase64でエンコードされた）ISO 8583クレジットカードデータに対するマスキングロジックをレビューするのは面白かった。