クレジットカード決済の仕様 取引データはシンプル、ただ難解【JavaScript - EMV Tag Decoder】

なんの話か

クレジットカード決済で決済端末からブランドネットワークを介してブランド(VisaとかMastercardとかAmerican ExpressとかJCBとか)に送る取引データのデコーダー作ったという話です。¹

EMV Tag Decoder

ソースコード：
https://github.com/taukuma/emv-tag-decoder

デモ：
https://taukuma.github.io/emv-tag-decoder/
※ブラウザ上で動作します(JSだけです)。入力したデータはどこにも送られませんので、安全です。

クレジットカード決済をしたときに、ブランド（イシュア）に送っているTVLデータをデコードするツールです。単純にTLVデータをTag・Length・Valueに分割するだけでなく、EMV標準タグとその値の意味するところをBook 3やBook 4（Book Cシリーズの一部）に定義されている情報をもとに解析するようにしています（もう、Bookに散りばめられている各種Tableを見なくて済むように・・・）。

経緯

PSP(Payment Service Provider)関連の仕事をした際に、興味がでてEMVの仕様書を読み込んで、その備忘録としてツールにまとめてみました。実際には、さんざんググりましたが、なかなかいいツールがみつからなかったので自作しちゃったのが本音です。EMVの仕様書は、後述しますが、とても読めたものではないボリュームがありますが、読まないといけない状況になることが多かったです。何度も仕様書の同じ箇所を調べる羽目になり、なんとか手助けしてくれるツールはないか？と考えたのがきっかけです。

クレジットカード決済の取引仕様

クレジットカードの取引データは国際的なスタンダードがあって、各ブランドはその仕様に準拠しています。この記事ではネットショッピングでのクレジットカード決済ではなく、実店舗での商品購入のときのクレジットカード決済のお話です。クレジットカード決済は大きく分けて3種類あります。

• 磁気ストライプでの決済
• 接触決済(カードを端末に差し込んで決済)
• 非接触決済(タッチ決済やコンタクトレスとも)

ここで該当するのは接触と非接触決済での取引データです。磁気ストライプでの決済はもはやほとんど使われてないのではと思います(新規にICチップのついていない、磁気ストライプのみのクレジットカードを発行することは、どのブランドももう許可していないのではないかと。未確認ですが。)

クレジットカードのICチップ(クレジットカードの表面についている金色の正方形の部分)はISO 7816やISO 14443規定されていて、それをベースにEMV Coが国際的なスタンダードを定義しています。どの国際ブランドもこれに準拠しているから、世界のどこにいても滞りなく決済ができるわけです。²

特にICチップとコマンドのやり取りをする決済端末(決済端末のKernel)の挙動や、どのように本人確認（暗証番号やサインやデバイス認証）するのかということが決められています。

領域ごとに仕様書がわかれていて、それをBookと呼んでいます。EMV Bookといえばこのスタンダードのことです。

接触決済のBook

接触決済は、カードを決済端末にブスッと挿す一番メジャーな方法です。クレジットカード上のICチップに決済端末の読み取り部分が物理的に接触するので、接触決済(もしくは、コンタクト決済)と呼ばれます。Bookは以下の構成です。³

• Book 1：ＩＣチップと決済端末の機能要求の規定
• Book 2：セキュリティと暗号鍵
• Book 3：アプリケーション仕様（決済フローやタグ定義など）
• Book 4：表示するメッセージや挙動等

※EMV Book以外にもブランドレギュレーションがあったりします。

タッチ決済のBook

最近VisaやJCB、AMEX(American Express)がテレビCMをやっていますが、決済端末にカードをかざしてピっとなる、決済する方法です。読み取り部分が非接触なので、非接触決済(もしくはタッチ決済 NFC決済 コンタクトレス決済 CL決済)と呼ばれます。ちょっと気を付けたいのが、SUICAやEdyやWAONやnanaco等の電子マネー決済ときちんと区別をすることです。なので個人的にはNFC決済と呼ぶのは適切ではないと思ってます⁴。

各ブランドでも呼称が分かれていてたりします（VisaやJCBはタッチ決済、MastercardやAmexはコンタクトレス）。

非接触決済(タッチ決済)のベースは接触決済と同じです。なのでBook1～Book 4を踏襲しています。追加して非接触特有の内容がBook A～Book Dに記載されてます。

• Book A：アーキテクチャ
• Book B：エントリーポイントの規定
• Book C：各ブランドごとの仕様
  • Book C-1：むかーしの仕様（VisaやJCBで使ってたらしい、今はEMV CoでもN/A扱い）
  • Book C-2：Mastercardの仕様
  • Book C-3：Visaの仕様
  • Book C-4：American Expressの仕様
  • Book C-5：JCBの仕様
  • Book C-6：DiscoverとDinersの仕様
  • Book C-7：UnionPay（銀聯）の仕様
• Book D：プロトコル仕様

どのBookを読めばいいのか

基本は全部なんでしょうが、PSP(Payment Service Provider)として特に大事なのは、Book 3 Book 4かと思います。タグの仕様やクレジットカード決済の基本的なフローがまとまっているためです。

非接触決済(タッチ決済)の場合も基本的には、Book 3とBook 4に準じていて、一部ブランドごとにシーケンスが違っているので、参考程度にBook Cシリーズを見ておく方がいいかもです。

ただ、Bookはそれぞれ100ページ以上あるので最初から最後まで読み込んだことは無いです。本当に1から決済サービスの構築をするような仕事でなければ、リファレンスに使う程度で十分です。

本題の取引データの中身

その前に、取引データと一口に言ってますが、どの部分か、を説明させてください。クレジットカードは決済するのにいくつかのプロセスがります。通常はオーソリで与信枠確保して、売上して完了です。もしカード使いすぎてて、もう利用可能枠を超えてたり、カードが停止されてたりすると、オーソリでエラーとなります。ここでは、普通の商品を購入する際のオーソリに特化した話とします。
※決済センターとブランド（イシュア）とのやりとりの部分は省略します。

オーソリってどういうプロセスなのか

決済プロセスの内容は、Book 3に主に記載されています。だいぶ省きますが、以下のようなシーケンスです。実は決済端末とクレジットカードのICチップとの間で結構いろいろなことが実行されてます（かなりはしょったシーケンスです。実際にはICチップや決済端末の設定によってだいぶ分岐します）。^{5 6 7 8}

このシーケンスのピンク色部分がオーソリになります。

オーソリ要求では取引データとARQC(Authorization ReQuest Cryptogram)と呼ばれる計算結果があります。後述しますが、決済端末とICカードが通信を行い生成する値で、端末にインジェクションされている暗号鍵をベースに算出されます。正しい要求かどうかというのを判別するためです。このためオーソリ要求全体のことをARQC(エー・アール・キュー・シー)と言っても通じます。

オーソリ応答ではARPC(Authorization ResPonse Cryptogram)とARC(Authorization Response Code)とAuthorization Code(承認番号)、ブランドが返してくればIssuer Scriptが返却されます。ARPCも暗号鍵をベースに生成された計算結果で正しい応答であることを判別するために使われます。そのためオーソリ応答全体のことをARPC(エー・アール・ピー・シー)と行っても通じます。

ARCは結果コードで、オーソリ結果が承認の場合は00 (ASCIIコードで3030)が帰って来て、拒否の場合は05 (ASCIIコードで3035)が帰ってきます。それ以外にも条件によっていろいろ値があります。Authorization Code(承認番号)はレシートにも印字される、ブランドが発行する番号です。もしカード使いすぎてて、もう利用可能枠を超えてたり、カードが停止されてたりすると、オーソリ応答でエラーが帰ってきます。ARCとIssuer Scriptは決済端末とクレジットカードのICチップに返却されて最終的な判定の2nd Generate ACを実行します。

Generate ACは決済端末からクレジットカードのICチップに送るコマンドです。ARQCの前にリスク管理の結果などを含めて実行する1回目のGenerate AC(First Generate AC)とオーソリ結果を含めて実行する2回目のGenerate AC(Second Generate AC)があります。どちらもICチップがACと呼ばれる計算結果を生成してくれます。Application Cryptogramなので略してAC、それを生成するのでGenerate ACです。

ACは3種類あって

• ARQC(Authorization ReQuest Cryptogram)
  →1回目のGenerate ACでこれがでるとオンライン要求、つまりブランドに与信枠の問合せと承認を取りに行きます。
• TC(Transaction Certificate)
  →取引が承認されたという意味です。つまり決済成功です。クレジットカードや決済端末の設定によってはARQCなしでTCが出ます。
• AAC(Application Authentication Cryptogram)
  →取引拒否の場合です。

暗号化の部分はPCI P2PEという規格があり決済端末はこれに準拠しなければなりません。PCI Security Councilが規定するPoint-to-Point Encryptionの仕様をPCI P2PEと呼びます。この記事と作ったツールではここには触れてません。

で、オーソリのときの取引データって？

先ほどのシーケンスのピンク色の部分でやり取りしているデータのことです。前置きが長くなりましたが、取引データの中にカードデータという項目があり、その部分をデーコードするツールを作りました、という話の本題です。

ソースコード：
https://github.com/taukuma/emv-tag-decoder
デモ：
https://taukuma.github.io/emv-tag-decoder/
※ブラウザ上で動作します(JSだけです)。入力したデータはどこにも送られませんので、安全です。

実際の取引は国内の場合は決済センターから先がCARDNETやCAFISなどの伝送サービスに繋がって、そこからブランドに行ったり、直接VisaのVisa NetやMastercardのBanknetに繋がったりするので、カードデータ以外にも様々なデータが付加されます（電文と行った場合は、決済センターから各ブランドネットワークに送っているメッセージを指すことが多いと思います）。⁹

取引データの構造

取引データはTLVというフォーマットです。TLVはTag-Length-Valueの略で、実際には以下のような感じになってます。

TLVの例1

TLV Sample

5F2009544553542055534552

TLVフォーマットで意味するところは以下です。

TLV Sample

5F20               => Tag
09                 => Length
544553542055534552 => Value

5F20というタグで、長さが9バイトで、値が544553542055534552ですよ、って意味になります。9バイトなので続く18文字が値だとわかるようになってます。

5F20というタグをBook 3でみてみるとCardholder Nameつまりカード所有者氏名であるということが分かり、値はASCIIコードとのこと。ちなみにASCIIで544553542055534552はTEST USERを意味してます。

TLV Sample(Decoded)

5F20               => カード所有者氏名
09                 => データの長さは9バイト(18文字)
544553542055534552 => ASCIIコードで実際の値は「TEST USER」

クレジットカードの取引データはこのTag Length Valueが羅列されているだけという、非常にシンプルなものです。このTLVデータのことをEMV TagやTLV Dataや単純にTagって呼んだりしてます。

あとはどういうタグがあるのかさえ分かっていれば、デコードできます。

私が探した限りだと、ここまでしかしてくれないデコーダーか、よくてASCIIコード変換と16進数→2進数変換しかしてくれないようなデコーダーしかありませんでした。

EMVのタグが全てASCIIとかだったなら、既存のデコードツールでも良かったのですが、以下のように難解なタグもあり、Book 3やBook 4を調べる必要があります。

TLVの例2

TLV Sample

9F34031E0300

短いのでBook 3やBook 4をみなくても何となく以下という想像ができます。

TLV Sample

9F34   => Tag
03     => Length
1E0300 => Value

実はこれであっていて、構造がとてもシンプルだと思う所以です。ただ構造はシンプルですがその値が意味するところが難解だったりします。Book 3によると、9F34はCardholder Verification Method (CVM) Resultsなので「本人確認方法の結果」ということのようです。では値の1E0300の意味はというと、今度はBook 4を見て、先ほどのように単純な変換ではないことが分かります。

9F34は3バイト構成で、以下の構成です。

• 1バイト目: CVM Performed
• 2バイト目: CVM Condition
• 3バイト目: CVM Result
  更に、それぞれのバイトの値でビット単位で意味が違うという定義になります。

1E0300
> 1E (1バイト目)
> 03 (2バイト目)
> 00 (3バイト目)

さらに、１バイト目はビット単位で意味がことなり、実際には1E0300は以下を意味します。

1バイト目の「1E」の意味 (CVM Performed ※実際に実行された最後のCVM)

1E = 0001 1110
ビット8 = 0
ビット7 = 0 ⇒ もし、ビット6～ビット1に定義しているCVMが失敗するなら、本人確認失敗とするという意味
ビット6 = 0 
ビット5 = 1
ビット4 = 1
ビット3 = 1
ビット2 = 1
ビット1 = 0 ⇒ ビット6～ビット1が011110の場合、Signatureを意味する

2バイト目の「03」の意味 (CVM Condition)

03 = 「If terminal supports the CVM」の意味
※2バイト目はビット単位の評価ではない

3バイト目の「00」の意味 (CVM Result)

00 = 1バイト目が1Eもしくは5Eの場合で、3バイト目が00なら、Signatureを意味する

つまるところ、この決済の本人確認方法はSignature（サイン）でやったよ、というのを1E0300という値で意味しています。

ここまで理解するために、Book 3のSection 10.5 Cardholder Verificationを読み込んで、Annex C3に記載してあるビットテーブルから、1バイト目と2バイト目の値が意味するところを確認。そのあと、Book 4のSection 6.3.4.5とTable 2から1～3バイト目がそもそも何を意味しているのかを確認。というような流れで調べていました。

ここまでくると、既存のデコードツールのありがたみが感じられなくなり、もう少し踏み込んだ「意味」までデコードしてくれるツールが欲しくなりました。

それでEMV Tag Decoderツールを作ってみました

ソースコード：
https://github.com/taukuma/emv-tag-decoder
デモ：
https://taukuma.github.io/emv-tag-decoder/
※ブラウザ上で動作します(JSだけです)。入力したデータはどこにも送られませんので、安全です。

先ほどの例の値5F20095445535420555345529F34031E0300をツールに入れると、以下の様にデコードするようにしました。

これでも、EMV Bookを参照する必要があるにはありますが、タグと値がすぐにわかるので、最低限欲しいと思った機能は作れました。

まとめ

• クレジットカードの取引データはTLVフォーマットというシンプルな構成
• ただし実際のタグと値の意味を知るには、EMV Bookという遠大なドキュメントを読む必要がある

1. 免責としまして、記載している内容はすべて、Githubで公開しているソースコード含めて、一般に広く入手できる公開情報をもとにしており、特定のブランド、イシュア、アクワイアラ、決済センター、決済サービスプロバイダー等の非公開情報を一切含んでおりません。また本記事記載のソースコードやデモを用いて発生したいかなる事象や不具合、不利益や損害についても一切の責任を負いません。 ↩

2. EMVを「エンヴ」って発音したりする方が多いですが、「イー・エム・ヴィーと発音してください」ってお願いしてました。環境変数(env)やEnvironemntとごっちゃにしない意図でそうお願いしてましたが、正しくはどう発音すべきなのか実は知りません ↩

3. たまーにお店でICチップ付きクレジットカードを一生懸命スワイプして決済できてない方を見かけますが、これはICチップ付いているカードはICチップで決済するように、つまり磁気ストライプで決済できないように決済端末で制御をかけてます(かけることをEMV Bookで要求されてます)。逆にICチップが読み取れないときに、同一の決済シーケンス内で同一カードの磁気ストライプを許可して磁気ストライプで決済させる方法もあります(MS Fallbackといいます)が、セキュリティ上問題があるので非推奨としているブランドが多いです。 ↩

4. NFC決済という表現はは不適切ではないかと思ってます。NFC決済だとクレジットカードのNFC TypeA/Bと電子マネー決済のNFC TypeF両方を指しちゃうので、特に日本では分けて表現した方が良いと思ってます。私個人としては電子マネーは電子マネー 電マネ emoneyと言うように心がけ、クレジットカードの非接触は(EMV)非接触 (EMV)コンタクトレス (EMV)タッチ決済と言うようにしています。 ↩

5. 本人確認方法(CVM: Cardholder Verification Method)は暗証番号 (PIN)(平文か暗号文か、オンラインPIN認証かオフラインPIN認証か)、サイン(レシートに実際に描くか、端末にペンなどで描く電子サインか)、タッチ決済の場合はスマートフォンにクレジットカードをプロビジョニングするので端末認証(CDCVM: Consumer Device Cardholder Verification Method)、本人確認が不要なカード(No CVM)等があります。日本国内の場合は暗証番号(PIN)はオフラインPINがほとんどなのでシーケンスはオフラインPINとして記載してます。 ↩

6. 接触決済の場合は決済端末の設定(Floor Limit)によって、一定金額未満は本人確認しないというというのもあります(オフライン承認)。よく大型商業施設では、10,000円〜15,000円くらいまではクレジットカード決済の時に暗証番号も入力しなかったりしますが、この設定がされているためかと思います。その分盗難カードや不正利用が発生するリスクが増えますが、裏を返せばそれを上回る企業体力があるんだなーと。 ↩

7. タッチ決済の場合はブランドやアクワイアラによりますが、2022年6月時点(日本国内)ではCVM Required Limitつまり本人確認が必要な金額が10,001円に設定されてることが多いと思います。なので10,000円以下でタッチ決済のする場合は、本人確認が不要で、10,001円以上なら本人確認が必要です。スマートフォンでタッチ決済する場合は、決済するタイミングで指紋認証やFaceID、ロック解除等で本人確認をするCDCVMが実行されてるので、本人確認済みとして10,001円以上でもサインをしないで決済できます。ただし、決済端末の設定によってはContactless Limitつまりタッチ決済上限額が10,000円と設定されていて、10,001円以上のタッチ決済ができない場合もあります(こういう値はPSPが勝手に決めれるのではなく、アクワイアラ要求になります)。その場合はタッチ決済ではなく接触決済をする流れになります。 ↩

8. タッチ決済の場合は、タッチした後(1st Generate ACの後)は、既にカードが離れているのでオーソリ(ARQCとレスポンスのARPC)の後の2nd Generate ACはなく、決済終了します ↩

9. ISO 8583:クレジットカード決済の電子メッセージの標準規格　(https://ja.wikipedia.org/wiki/ISO_8583) ↩