技術記事
ペイメントゲートウェイ統合をはじめよう
決済アプリを稼働させるには、少なくとも2種類の異なる統合に対応できる必要があります。まず、必要なハードウェア（つまりカードリーダーと、それを接続する機器）の統合方法を知る必要があります。次に、オンラインのペイメントゲートウェイ（取引を「承認」し、決済処理を行う事業者）などの決済「バックエンド」との統合方法を理解する必要があります。
過去の 投稿このパズルのうちハードウェア統合の部分については、これまでにも多くお話ししてきました。実はそれほど難しいものではなく、ID TECHのカードリーダーであれば、当社の ユニバーサル SDK を使って高水準言語環境からデバイスと通信できますし、Node JSをアーキテクチャに組み込んでもよければ、純粋なJavaScriptソリューションで対応することも可能です。いずれにせよ、ID TECHデバイスとの通信はそれほど大変ではありません。
しかし依然として疑問が残ります。クレジットカードリーダーでカードのチップやストライプを読み取った後、その情報をどうやって承認済み取引に変換するのでしょうか？
おそらく、どのクレジットカード処理業者がリクエストを処理するかはすでにご存じでしょう。そのため、問題は実質的に、処理業者やゲートウェイがオンラインリクエストを処理するためにどのようなSDKサポートを提供しているかを確認することに集約されます。
ほとんどのゲートウェイや処理業者は、決済アプリ構築用のSDKを入手できる開発者プログラムまたはオンライン開発ポータルを用意しています。SDKを利用すると、通常、処理業者の決済APIにアクセスするためのフロントエンドおよびバックエンドのコンポーネントを組み合わせて構築できます。決済APIは、リアルタイム承認を取得する目的で、磁気ストライプデータやICC（チップカード）データをバックエンド処理業者へネットワーク経由で送信することをサポートしています。
決済の承認は、サポートが必要となるであろう複数のオンラインリクエストの一種に過ぎません。その他のリクエストの種類を以下の表に示します。
リクエスト種別
説明
オーソリ
支払い承認の要求
設定
既存の承認リクエストの確定
オフライン
オフラインEMV取引の精算
事前オーソリ
少額の取引を使ってカード情報の有効性を確認
返金
精算済み取引の返金
テスト
処理業者との接続テスト
音声照会通知
音声照会リクエストの結果を処理業者に通知
取消
未精算の取引を取り消すために使用
利用する決済処理業者のSDKドキュメントを読むと、各取引種別に対してかなり多くの結果コードやエラーコードが適用されていることに気付くでしょう。これらの想定されるエラーをすべてどうやってテストするのか？答え：ほとんどの処理業者は、テスト用サンドボックス環境において、取引の小数点以下の金額を特定の値に設定することで特定のエラーを誘発できる仕組みを備えています。（たとえば、金額過大のエラーコードが1243である場合、SDK上で12.43ドルのテスト取引を送信することで、そのエラーを発生させられる仕組みです。）詳細はご利用のプロバイダーのSDKドキュメントをご確認ください。
多くの決済処理業者は、事前認定済み（セミインテグレーテッド）の「アプリ内」ソリューションを提供しており、暗号化されたカードデータを比較的透過的にバックエンドへ直接ルーティングできるため、決済アプリを「PCIスコープ」の外に保てます。一方、他の業者では「スコープ」の課題を自社で引き受ける前提となっており、その場合、暗号化されたカードデータをファイアウォール内の自社サーバーアプリへネットワーク経由で送信し、（HSMの助けを借りて）カードデータを復号した上でアクワイアラやゲートウェイへ転送することになります。
高レベルの概要はこのくらいにして、決済バックエンドとの統合が実際にはどのようなものを意味するのか、お話ししましょう。
この具体例がすべてのケースに当てはまるわけではないことは明らかですが（ひとつの例で全てを示すことは不可能です）、バックエンドとの統合時に直面する可能性のあることの雰囲気はある程度伝わるでしょう。
今回のケースでは、EMV取引のライブ承認を取得するために取引データを送信する「バーチャルターミナル」のデモアプリを構築するという任務を担当しました。送信先は CreditCall のテストサーバーです。CreditCallは、HTTPS経由でアクセス可能なバックエンドサーバーAPIを提供しており、それが ChipDNA Direct APIで、Java、C++、Perlなどの言語のSDKを使って開発することができます。今回はJava版を選択しました。
場所は ChipDNA Direct Webサイトで開発者アカウントを登録すると、すぐにCreditCallのテストサーバーへアクセスするための認証情報がメールで届きました。さらにCreditCallのJava SDKをダウンロードし、サンプルコードを確認し始めました。特に学びたかったのは、EMVトランザクションをオーソリゼーションのために送信する方法でした。幸運なことに、サンプルコードファイルの一つであるExampleAuthEMV.javaに、まさに必要なコードが示されていました。
私は2つのJavaクラスを書く作業に取り掛かりました。1つはブラウザベースのフロントエンドからのHTTPリクエストを処理するサーブレットクラス、もう1つはサーブレットが取得したブラウザデータをCreditCallのバックエンドに渡す「ワーカー」クラスです。前者は約250行、後者は92行のJavaコードになりました。
サーブレットクラスのコードはここでは紹介しません。標準的なJavaサーブレットコードとほぼ同じであり、唯一の違いは、TLV値（AJAXを用いてフォームフィールド値として送信されたもの）を実行時にjava.util.Hashtableオブジェクトに格納している点だけだからです。そのHashtableは、私のワーカークラスのstaticなauthorize()メソッドに渡されます。ワーカークラスはCreditCall ChipDNA Direct SDKのヘルパー（ライブラリ）クラスを使ってcom.creditcall.Requestオブジェクトを作成し、それをClientオブジェクトに渡して、CreditCallサーバーを呼び出します。コードは以下の通りです。
このコードは非常に短く、説明不要なほど明快です。注目すべき点は、CreditCallの お問い合わせ までメールでお問い合わせいただき、 クライアント クラスが、最終的にCreditCallサーバーへ送信される必要なXMLドキュメントの作成を引き受けてくれることです。開発者として、生のXMLを見たり、触ったり、パースしたり、気にしたりする必要は一切ありません（自然の摂理どおり、そうあるべきです）。
18行目と19行目で、テストアカウントの認証情報を指定する必要がある点に注意してください。（上記の認証情報はダミーです。コードをそのまま使用しないでください！）69行目でCreditCallのエンドポイントURLを設定します。72行目で実際の送信用HTTPS呼び出しを行います。
CreditCallサーバーは、トランザクションデータにどのTLVタグを含めるかについて、必須のカードデータを含むタグ（例えば接触EMVの場合はタグ5Aと57、非接触の場合はタグ56、加えて暗号情報を含む9F26と9F27）が含まれてさえいれば、特に厳格ではありません。EMVデータに対する応答として、CreditCallサーバーは通常、タグ8A、89、91のTLVを返し、必要に応じて71または72（ICカードへ伝達するスクリプトがある場合）も返します。必要なオーソリゼーションコードはタグ89に含まれています。
試行錯誤の中で分かったのは、CreditCallのサーバーアプリは、カードがAAC暗号文を提示したからといって、即座にトランザクションを拒否するわけではないということです。（暗号文の種類は、タグ9F27の上位ビットを調べることで判別できます。ゼロであればAAC、すなわち拒否を意味します。）ただしこれは想定内のことです。なぜなら、カードからの判定はあくまで「助言」に過ぎないからです。EMVトランザクションの最終的な承認・拒否は通常、アクワイアラーの判断に委ねられます。カードの判定は覆される可能性があり、実際そうなることも珍しくありません。
ご覧の通り、こうしたものを実際にいじってみることで、EMVについて多くの興味深い詳細を学ぶことができます。ペイメントアプリのコードを検証する際は、実際にライブオーソリゼーションを実行するのが何より一番です！
EMVトランザクションについてさらに知りたい方は、ID TECH ナレッジベースの 開発者ホーム ページをご覧ください。また、 EMV開発に関するホワイトペーパーをダウンロードしてください。あるいは、評価キットの導入についてご相談いただける専門家まで、フリーダイヤルでお電話ください。