クレジットカード処理を担う「ISO8583」とは？ Go言語でパーサーを開発したエンジニアが中身と苦労を明かす：謎の「業界の通例」があるカード決済の仕組み

2019年8月29〜31日に開催された「builderscon tokyo 2019」のセッション「クレジットカードの通信プロトコル ISO8583 と戦う」で、カード決済システムを自社開発したエンジニアがISO8583の中身を明かした。

[高橋睦美，＠IT]

カンム バックエンドエンジニア 佐野裕章氏

　キャッシュレス決済の一環として、クレジットカード決済の利用がまた広がっている。その裏でやりとりされるデータは、多くの人が想像するJSONやXMLではなく「ISO8583」という規格にのっとって行われている。1980年代に策定されたこの標準規格、扱いはなかなか一筋縄ではいかないようだ。

　Go言語でISO8583のパーサーを書いたというカンムのバックエンドエンジニアである佐野裕章氏は、2019年8月29〜31日に開催された「builderscon tokyo 2019」のセッション「クレジットカードの通信プロトコル ISO8583 と戦う」で、その過程で得られた知見を紹介した。

クレジットカード業界のエコシステム

　クレジットカードというと「Visa」「Mastercard」といった「ブランド」のイメージが強いが、決済処理にはもっと多くの登場人物が関わっている。加盟店、いうなれば「使う場所」を増やす「アクワイアラー」と、利用者を増やす「イシュアー」があり、それぞれがブランドの間で通信を行っている。

クレジットカード業界のエコシステム（各登場人物の関係）

　例えば店舗で何らかの買い物を行う際には、実売り上げが発生する前に仮売り上げの形で「オーソリゼーション」という処理が走り、有効期限や限度額のチェックなどが行われる。

クレジットカード業界のエコシステム（データやお金の流れ）

　佐野氏が所属するカンムはイシュアーとして事業を展開してきた。「これまではブランドとの間に決済代行業者を挟み、そこがISO8583の通信を処理して結果のみを受け取る形だったが、事業拡大に伴って内製化に取り組み、直接ブランドに接続してISO8583を処理しようと試みたことが、今回の話の背景にある」という。

クレジットカード業界のエコシステム（ISO8583）

　「国際標準で、しかもTCPでやりとりされるものだから、パーサーくらいGitHubにあるだろうと思っていたら、各社が独自に拡張を加えていたり、エンコーディングが異なっていたりで、それをそのまま使うわけにはいかなかった。そこで@moriyoshi（GitHubアカウント）さんの協力を得ながら、Go言語でパーサーを書いていった」（佐野氏）

データの種類によってフォーマットが異なったり、入れ子だったり……ISO8583との格闘

　続けて佐野氏は、ISO8583のデータの例を挙げながら、構造を説明していった。

ISO8583のデータの16進数記（「0x0100」がMessage Type、赤文字がBitmap、緑文字がData Element）

　ISO8583のデータは「Message Type」「Bitmap」「Data Element」という3つのパートで構成されている。Message Typeは「HTTPの世界で言うステータスコードのようなもの」で、4つの桁それぞれに意味があり、ISO8583のバージョンや目的、メッセージの種類や発信元を示す。

Message Typeと処理の関係

　次のBitmapは、ビットが立った場所のData Elementが存在することを表すデータだ。

Bitmapのフォーマット

　そして、クレジットカード番号（PAN：Primary Account Number）や金額、有効期限といった実データはData Elementに格納される。

ISO8583のデータの16進数記（Data Element内の詳細な表記）

　ここでややこしいのは、PANならば「可変長、数字でBCD」、有効期限ならば「固定長、数字でBCD」、利用店舗の名前なら「固定長、英数字特殊文字でEBCDIC」といった具合に、データの種類によってフォーマットがそれぞれ異なっていることだ。

Data Elementのフォーマット

　同氏が開発したパーサーでは、「論理積などを活用しながら、ひたすらデータの存在をチェックしてはパースする」処理を行うという。

Data Elementのパース例

　その上、「得られた長さによって解釈を変えなければいけなかったり、Data Elementの中にさらにBitmapがあって、入れ子で読んでいかなければいけなかったりと、中にはいろいろなパターンがあった」と、佐野氏は苦心したポイントを紹介した。

業界での「普通」って何？　やはり不可欠な業務知識

　パーサーを開発してみて感じたのは、「業務ロジック」「業務知識」の重要性だったそうだ。「この会社に入るまで金融関連の仕事に携わったことがなかったため、聞き慣れない単語が多い上に、ドキュメントに『Important』『Mandatory』と重要そうな言葉で説明が書かれているが、その説明を読んでも何がどう重要なのか、どのデータが重要なのかがはじめはよく分からなかった。最終的には理解できましたが」（佐野氏）

　そこで佐野氏はドキュメントの読み込みに加え、「至るところで自社のカードを使って、内製化する前のシステムに出てくるログをひたすら読み、いろんなパターンを調べて理解する泥臭いやり方でパースを進めた」という（残念ながら、その際使った費用の経費精算はし忘れてしまったそうだが）。

　また、「自社アプリでは使わない、あまり重要ではないものは読み飛ばす方針で、効率よく処理しようとしたら、実は重要ではないと思っていたData Elementに重要なデータがありバグが発生した」（佐野氏）こともあったそうだ。

　謎の「業界の通例」に悩んだこともあったそうだ。「ApprovalCodeは、仕様では『6桁の英数字』と規定されているけれど、対向試験を行ったら『ApprovalCodeに英字が混ざっています。普通は数字ですよ』と言われて……そもそも『普通』って何だろうと（苦笑）。仕様で許可されていても、業界の通例というものがあると知りました」（佐野氏）

ApprovalCode

　こんなふうに慣れない用語や通例に悩まされながらも、「プロトコルを攻略するのは楽しい」と佐野氏。悩むことがあってもドキュメントを読んで実験すれば何とかなると述べた。そして、「業界の知識や暗黙値はどうしようもないですが、慣れれば大丈夫」と講演を締めくくった。

　なお、続いて行われた質疑応答によると、「プロトコルの構造自体に変更や拡張はないが、半年に1回程度のペースで『今後、このData Elementについてはこんな解釈が増えるので注意してください』と、ブランドから連絡が来ます」

　また決済処理はさまざまな事業者を経由して行われるだけに、途中でエラーが発生したり、再送で二重に処理されたりする恐れもあるが、そこは「直前に同じようなオーソリゼーションがないかをチェックしています。不正なフォーマット、仕様違反のフォーマットが送られてくることもたまにあり、その場合ははじくようにしていますが、返品処理のときはお客さまが困ることになるので、大目に見るようにしている」と、仕様と現実の間で苦心しながら取り組んでいることをうかがわせていた。