クレジットカード情報のトークン化を採用する際の
注意点は?

クレジットカード情報のトークン化とは?

かつて、オンライン取引でクレジットカード決済を用いる際には、ECサイトの決済フォームにクレジットカード情報を入力させ、そのシステムにカード情報を記録しておくことが認められていました。そのため、「繰り返しの課金に備えたい」等の理由で、実際に多くの事業者がクレジットカード情報を保持していました。
しかし、2016年にクレジット取引セキュリティ対策協議会が発表した「実行計画」と、2018年に行われた割賦販売法の改定により、現在ではPCI DSS非準拠のECサイトでカード情報の保存・通過・処理が行えなくなりました。

PCI DSSの準拠には、システムと運用ルールの審査があり、通過するためには専門の設備や監査への対応といった大きなコストがかかります。
そこで、代替手段として私たちのような決済代行会社から提供されるようになった決済手段が「トークン化」です。

トークン化とは、消費者が決済システムに対して直接カード情報(カード番号と有効期限)を送信して、全く別の文字列に変換する技術です。これを使うことで、ECサイト側でカード情報を保持することなく、保持している状態と同様の運用ができます。

トークン化のメリット①:
ECサイト側がカード情報を保持していないので、漏洩しづらい

ECサイトのシステムが保持するのは、クレジットカード情報ではなくトークンです。
トークンは、その発行元のシステムにその加盟店のシステムから送信した場合のみ、課金が可能な決済手段です。そのため、仮に漏洩してしまった場合でも他で使うことはできず、重要な個人情報には該当しない価値のないものであるため、消費者に対する責任範囲を小さくすることができます。

トークン化のメリット②:
任意のサイクルと金額で課金できる

従来、カード情報を保持していなければ難しかった不定期の課金や、従量課金のように毎回変動する金額の決済も、トークンを保持することで問題なく行えます。
また、繰り返し注文することが多いECサイトやサービスの場合、消費者が毎回カード情報を入力する手間を省くことができます。

継続的な課金でのメリット

カード情報を通過させずトークン化するには

このように大変便利なトークン化ですが、ECサイトのシステムをカード情報が通過しないように実装するには、大まかに分けて以下いずれかの手段を用いる必要があります。

ユーザーを決済代行会社のフォームに遷移させる

クレジットカード情報を、ネットショップのシステム内を通過させずにトークン化するためには、私たちのような決済代行会社のサーバー内にある決済フォームにユーザーを遷移させ、そこにカード情報を入力してもらう必要があります。

ハイパーリンクを設置するだけなので実装は簡単※なのですが、申込手続きの過程で画面遷移が多くなることの煩わしさや、別ドメインに移動することに対しするユーザーの不信感が原因となり、離脱率を上げてしまう可能性があります。

※この方法で発行されたトークンを取得するには、別途プログラムを作成する必要があります。

当社では、こちらをリンク方式と呼びます。

決済代行会社のフォームをECサイト側に呼び出す

この方法では、画面遷移がよりシンプルになります。ECサイトの申込手続きの途中に決済代行会社の提供する決済フォームを埋め込んでおくことで、ユーザーに画面やドメインの遷移をさせることなく、クレジットカード情報をトークン化することが可能です。
インラインフレームやモーダルウインドウを使うため、フォームのデザインをサイトに合わせて細かく調整しできるのも、大きなメリットです。

実装方法は、Javascriptや数行のタグを記述(注文内容に合わせて出力)し、完了後に発行されるトークンを受け取って結果表示をするプログラムを作成するだけ。それほど難しいものではありません。

当社では、こちらをインラインフォーム方式ウィジェット方式という二つの方式で提供しています。

トークン化の中で要注意な方式

既にご説明した通り、ECサイトへの組み込みには画面遷移を伴わないシンプルな決済方式のトークン化の仕組みが好まれます。しかし中には、思わぬ事故のきっかけになり得る決済方式も存在します。いわゆる「Javascript型/方式」と呼ばれるものです。当社でもかつては提供していましたが、現在は推奨しておりません。

Javascript型/方式で問題となる点は、以下の4つです。

  • カード情報の送信先と処理のプロセスがスクリプト内に記述されているため、改ざんしてカード情報を他のサーバーに送信することが比較的容易である
  • 本来の動作を維持しながら継続的にカード情報を不正取得しやすい
  • 本来の動作を維持された場合、加盟店が異常を察知しづらい
  • スクリプトを正しく設置したかどうかのチェック機能が当社になく、設置後に変更されたかどうかを察知する仕組みもない

では、実際にどのような状態が予測されるか、ご紹介します。

正しく実装され、ハックされなかった場合

javascript方式のトークン化を正しく実装した場合、以下のような仕組みが完成します。

ハッキングの実例
ハッキングの実例

正しく実装されなかった、またはハックされてしまった場合

javascript方式のトークン化をハックされてしまうと、以下のような仕組みが完成してしまう恐れがあります。

ハッキングの実例
ハッキングの実例

このように、正常な動作を維持されてしまう分だけ事態の察知が遅れ、大量のカード情報が漏洩する可能性が高まります。
特に、便利で気軽に使えるオープンソースのショッピングカートシステムやCMSでは、その反面セキュリティホールを発見されることも多く、これらのシステムを利用しているECサイトなどでは、例に挙げたような漏洩事故が頻発しています。

当社は「完全非通過型」の決済方式を提供します。

カード情報の漏洩を防ぎながら便利なトークン化の仕組みを使うには、以下のような条件が必須です。

  • カード情報を送信するためのコードや、取得するAPIが、第三者の閲覧できない場所にあること
  • 重要なソースコードを管理しているサーバーが、PCI DSS準拠であること

当社の提供しているすべての決済方式がこの条件を満たしており、クレジットカード情報などを店舗で保持する事がない完全非通過型※のフォームとなっています。

※カード情報の送信先APIを外部から閲覧できず、加盟店サイト側でカード情報を用いた処理が一切行われない、かつカード情報の入力先であるフォームがPCI DSSの適用されたシステム内に存在している状態を、当社では「完全非通過型」と呼びます。

当社の提供する決済方式についてのご紹介はこちら