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

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

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

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

デモ：
https://taukuma.github.io/emv-tag-decoder/
※ブラウザ上で動作します(JSだけです)。入力したデータはどこにも送られませんので、安全です。
![EMV Tag Decoder](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2187642/1df34dc5-48e7-ec20-3650-38d7e52866a2.jpeg)

クレジットカード決済をしたときに、ブランド（イシュア）に送っている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](https://en.wikipedia.org/wiki/ISO/IEC_7816)や[ISO 14443](https://en.wikipedia.org/wiki/ISO/IEC_14443)規定されていて、それをベースに[EMV Co](https://www.emvco.com/)が国際的なスタンダードを定義しています。どの国際ブランドもこれに準拠しているから、世界のどこにいても滞りなく決済ができるわけです。[^NOTE_EMV]
[^NOTE_EMV]: EMVを「エンヴ」って発音したりする方が多いですが、「イー・エム・ヴィーと発音してください」ってお願いしてました。環境変数(env)やEnvironemntとごっちゃにしない意図でそうお願いしてましたが、正しくはどう発音すべきなのか実は知りません

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

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

## 接触決済のBook
接触決済は、カードを決済端末にブスッと挿す一番メジャーな方法です。クレジットカード上のICチップに決済端末の読み取り部分が物理的に接触するので、`接触決済`(もしくは、`コンタクト決済`)と呼ばれます。`Book`は以下の構成です。[^NOTE_FALLBACK]
* `Book 1`：ＩＣチップと決済端末の機能要求の規定
* `Book 2`：セキュリティと暗号鍵
* `Book 3`：アプリケーション仕様（決済フローやタグ定義など）
* `Book 4`：表示するメッセージや挙動等

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

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

## タッチ決済のBook
最近VisaやJCB、AMEX(American Express)がテレビCMをやっていますが、決済端末にカードをかざしてピっとなる、決済する方法です。読み取り部分が非接触なので、`非接触決済`(もしくは`タッチ決済` `NFC決済` `コンタクトレス決済` `CL決済`)と呼ばれます。ちょっと気を付けたいのが、SUICAやEdyやWAONやnanaco等の電子マネー決済ときちんと区別をすることです。なので個人的にはNFC決済と呼ぶのは適切ではないと思ってます[^NOTE_NFC]。
[^NOTE_NFC]: `NFC決済`という表現はは不適切ではないかと思ってます。`NFC決済`だとクレジットカードのNFC TypeA/Bと電子マネー決済のNFC TypeF両方を指しちゃうので、特に日本では分けて表現した方が良いと思ってます。私個人としては電子マネーは`電子マネー` `電マネ` `emoney`と言うように心がけ、クレジットカードの非接触は`(EMV)非接触` `(EMV)コンタクトレス` `(EMV)タッチ決済`と言うようにしています。

各ブランドでも呼称が分かれていてたりします（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チップや決済端末の設定によってだいぶ分岐します）。[^NOTE_CVM] [^NOTE_IC_FLOOR_LIMIT] [^NOTE_CL_NOCVM] [^NOTE_CL_2NDGENAC]
```mermaid
sequenceDiagram
  actor USER as ユーザー
  participant CARD as クレジットカード
  participant TERMINAL as 決済端末
  participant CENTER as 決済センター
  participant BRAND as ブランド
  USER->>+CARD: お財布からカードを<br>取り出して挿入
  CARD->>+TERMINAL: 
  TERMINAL->>TERMINAL: アプリケーションの選択<br>（ICチップのAIDから決済端末のKernelの選択）
  CARD-->>TERMINAL: データ読み取り
  TERMINAL->>TERMINAL: Risk Management
  Note right of TERMINAL: Risk Managementでは、<br>決済端末(のKernel)とICチップが<br>いくつかのリスク管理を実施します。<br>ICデータや決済端末の設定値を<br>もとにしたチェックです。
  TERMINAL->>USER: 暗証番号 要求
  Note right of USER: Risk Managementの中で、<br>どのように本人確認を行うかの決定<br>がされます。多くのカードでは暗証番号<br>を要求しますが、一定金額未満の場合は、<br>No CVMつまり本人確認なしでオーソリ<br>することもあります。カードのICチップの<br>設定によっては、暗証番号ではなく、サイン<br>を要求するケースもあります。<br>サインの場合は、先にオーソリ枠を確保して<br>オペレーター（お店のレジ打ちする方）が<br>サインを確認したら、「売上」という流れ<br>になります。
  USER->>TERMINAL: 暗証番号 入力
  TERMINAL->>CARD: First Generate AC (判定)
  CARD->>TERMINAL: 
  Note left of TERMINAL: First Generate Application Cryptogram<br>この時点で、カードと決済端末が<br>オフラインで決済を承認しても<br>OKもしくはNGと判定すると、<br>後続には行かず、そのまま決済終了となる
  rect rgba(255, 0, 255, 0.2)
    TERMINAL->>+CENTER: オーソリ要求<br>(ARQC、取引データ)
    CENTER->>+BRAND: オーソリ要求<br>(ARQC、取引データ)
    BRAND-->>-CENTER: オーソリ応答<br>(ARPC、ARC等)
    CENTER-->>-TERMINAL: オーソリ応答<br>(ARPC、ARC等)
  end
  TERMINAL->>CARD: Issuer Scriptの実行
  CARD->>TERMINAL: 
  Note left of TERMINAL: ARPCでIssuer Scriptが帰ってきたら、<br>ICチップに対してScriptを実行する
  TERMINAL->>CARD: Second Generate AC (判定)
  CARD->>TERMINAL: 
  Note right of TERMINAL: 2回目のGENERATE ACで最終判定
  TERMINAL->>USER: 結果
  USER-->>TERMINAL: カード抜き取り
  TERMINAL-->>-USER: 
```
このシーケンスのピンク色部分が`オーソリ`になります。

オーソリ要求では取引データと`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`と呼びます。この記事と作ったツールではここには触れてません。

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

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

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

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

### で、オーソリのときの取引データって？
先ほどのシーケンスのピンク色の部分でやり取りしているデータのことです。前置きが長くなりましたが、取引データの中にカードデータという項目があり、その部分をデーコードするツールを作りました、という話の本題です。
>ソースコード：
https://github.com/taukuma/emv-tag-decoder
デモ：
https://taukuma.github.io/emv-tag-decoder/
※ブラウザ上で動作します(JSだけです)。入力したデータはどこにも送られませんので、安全です。

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

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


## 取引データの構造
取引データは`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 Tag Decoder](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2187642/1df34dc5-48e7-ec20-3650-38d7e52866a2.jpeg)
これでも、EMV Bookを参照する必要があるにはありますが、タグと値がすぐにわかるので、最低限欲しいと思った機能は作れました。

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