“トークン決済”で「カード情報の非保持化」を行う場合のモデルケース（第6回）

【経済産業省が発表したEC事業者が2018/3までにするべきこと -第6回-】

----------------------------------------------
◆本コラムについて◆
2016年2月、経済産業省より、EC事業者は2018年3月までに、「カード情報の非保持化」もしくは「PCI DSS準拠」の対応をしなければいけないという指針が公表されました。
このコラムでは、その内容や対策方法についてお話していきます。
ECサイト・通販を運営している事業者の皆さまは、対応が必要かもしれませんので、是非ご一読いただければと思います。

【第1回】クレジットカードのセキュリティ対策は2018年3月までに！
https://www.ecnomikata.com/column/10973/

【第2回】“トークン決済” なら、ECサイトそのままで「カード情報の非保持化」
https://www.ecnomikata.com/column/11417/

【第3回】“リンクタイプ” で簡単・短期間に「カード情報の非保持化」
https://www.ecnomikata.com/column/11888/

【第4回】「カード情報の非保持化」と一緒にやっておきたい「不正使用対策」
https://www.ecnomikata.com/column/12470/

【第5回】カード情報漏えいは「トークン決済」「リンクタイプ」で未然に防ぐ
https://www.ecnomikata.com/column/13076/

経済産業省より出された「実行計画」（*1）では、「カード情報の非保持化」として、“トークン決済”と”リンクタイプ”が推奨されています。
EC事業者の皆さまはどのようにいずれかの決済システムを選んでいるのか？
今回と次回の2回にわたり、モデルケースを通して見ていきたいと思います。

今回のモデルケースは、”トークン決済”を選んだECサイトです。

“トークン決済”とは、クレジットカード情報をトークン（＝乱英数字の文字列）に置き換えて決済処理をするサービスのことでしたね。
詳しくは本コラムの第2回（URL： https://www.ecnomikata.com/column/11417/ ）をご参照ください。

EC事業はメインでないため、最小限で”トークン決済”に切り替えるケース

まずは、ある程度ECサイトで売上があるものの、会社の全事業でみるとメインではないため、時間・手間・ユーザーインターフェース（UI）変更など、なるべく最小限で「カード情報の非保持化」に対応をしたいと考えたA社の例です。

A社は、元々食品メーカーです。販路チャネルの拡大を見込んで大手ECモールに出店したところ、EC経由の売上の割合が増えてきたため、数年前から自社のオンラインショップも始めたのが、ECサイトを開始したきっかけです。

EC運営が中心の会社ではないためECやシステム開発に詳しい社員が少なく、ECサイト全般のシステム開発は、ECパッケージの会社に委託しました。
その際、決済システムはECパッケージ会社に勧められた決済代行事業者が提供する、モジュール/プロトコルタイプを選びました。

その後、ECサイトの利用客も増え、順調に売上を伸ばすなか発表されたのが「実行計画」です。

最初A社は、「実行計画」がEC業界で話題になっているとは知りつつも、 “決済システムは、決済代行事業者を利用し、クレジットカード情報を預けているので、自社のECサイトには関係ないだろう”と考えていました。
しかしながら、2016年の夏頃、決済代行事業者から「実行計画」についてのメールマガジンが届き、“自社のECサイトも関係するかもしれない”と、念のため決済代行事業者に問合せをしました。

すると、以下のことが分かりました。


----------------------------------------
●決済代行事業者を利用していても、「実行計画」の対応が必要な場合がある

●A社では、クレジットカード情報を決済代行事業者に預け「保存」はしていないものの、自社のECサイトを「処理」「通過」しているため、対応をしなければならない

●対応方法としては、「カード情報の非保持化」か「PCI DSS準拠」
----------------------------------------


「実行計画」への対応が必要なことがわかったA社は、運用上、クレジットカード情報を「保存」｢処理｣「通過」する必要がないことから、「PCI DSS準拠」ではなく「カード情報の非保持化」の対応を選びました。

“トークン決済”か”リンクタイプ”か、「カード情報の非保持化」の方法を決めるにあたり、A社には大きく3つの課題があります。


--------------------
①自社にECシステム開発に詳しい技術者がいない
②「カード情報の非保持化」対応に時間や手間をかけたくない
③リピートユーザーが減ることは避けたく、ECサイトのUIは同じままとしたい
--------------------


そこで、A社は、ECパッケージ会社や決済代行事業者に相談しました。
利用していたECパッケージ会社が”トークン決済”に対応していたこともあり、A社での大きなシステム開発の必要がなく、かつ、今の決済システムをいかしつつ「カード情報の非保持化」ができる”トークン決済”を選びました。

”トークン決済”はECパッケージ側で実装されているものがすでにリリースされており、A社のように利用しているECパッケージが”トークン決済”に対応している場合は、カード決済システムの大規模な改修は要らず、ECサイトのUIも変更しなくて済むのです。

こうしてA社は、大規模な改修をせずに”トークン決済”に切り替え、「実行計画」にある「カード情報の非保持化」に対応することができました。

自社開発の決済システムを切り替えに伴い、カスタマイズ力を維持できる”トークン決済”を選ぶケース

次に、決済システムも含めてECサイトを全て自社で構築しているB社が、「実行計画」の「カード情報の非保持化」に対応した例を見てみましょう。

B社は、先ほどのA社とは異なり、メイン事業がECサイトで衣類等を販売する会社です。
ECサイトは全て自社で構築しており、EC運営にあたっては、常にサイトをカスタマイズして利用ユーザーを増やしています。
最近では、海外からの購入（越境EC）の割合も増え、毎年成長を続けています。

海外からの購入が増えてきたため、これまで以上にセキュリティ面での強化が必要と考え、関連事項を調査していたところ、「実行計画」の存在を知りました。

B社では、自社で決済システムも構築していたので、クレジットカード情報を「保持（保存・処理・通過）」しており、このまま「保持」を続けるには「PCI DSS準拠」する必要がありました。

「PCI DSS準拠」は大変そうなこともあり、クレジットカード情報を決済代行事業者に預けることも検討することにしました。

検討するなかで、以下のことが分かりました。


----------------------------------------
●「PCI DSS準拠」は一回準拠したら終わりではなく、毎年維持する必要があり時間・費用・人員などを要する

●クレジットカード情報を決済代行事業者に預けるだけでは不十分である

●「カード情報の非保持化」に対応するには、決済代行事業者等が提供する決済システム（“トークン決済”か”リンクタイプ”）を利用しなければならない
----------------------------------------


B社は、準拠以降の継続も考慮すると「PCI DSS準拠」は難しいと判断し、決済代行事業者を利用することにしました。
自社の決済システムから、決済代行事業者が提供する決済システムに変えるにあたり、B社では2つの希望がありました。


--------------------
①現在運営しているECサイトのカスタマイズ力を下げない
②ユーザーに対してUI面での負担を増やさない
--------------------


新しく決済システムを導入する場合、決済代行事業者で『決済画面』をテンプレートとして用意している”リンクタイプ”は比較的簡単に構築できますが、B社はこれまで全て自社開発でECサイトを構築しており、システム開発力があります。
また、「実行計画」の対応期限である2018年3月までにはまだ時間もあります。

そこで、開発工数がかかったとしても、希望に近いものができる”トークン決済”を選びました。

”トークン決済”は”リンクタイプ”とは異なり、『決済画面』を自社で自由にカスタマイズできるため、ユーザーが『氏名・配送情報を入力』から『カード情報入力』へと進むときの画面遷移が無く、別ドメインにならない（*2）等、ユーザーに負担をかけることが少ないのです。

このように、B社は、「実行計画」の非保持化への対応とECサイトのクオリティ維持のため、”トークン決済”を選びました。

“アクセス集中”という商材の特性を”トークン決済”で対応するケース

最後に、「チケット」のECサイトを立ち上げるC社の例を見てみます。
C社の場合、チケット販売で生じる“アクセス集中”によるリスクを軽減するのがポイントでした。

C社はイベント企画やWEBサービス・スマホアプリ開発など幅広く事業を行う会社です。
事業の一つであるイベント企画では、各イベントのチケット販売は別の会社に委託していましたが、近年、企画するイベントの数も多くなり、会社の規模も拡大してきたので、イベントの案内からチケット販売まで全て一貫して自社で行えるよう、新しくECサイトを立ち上げることにしました。

WEBサービス事業の経験はありましたが、ECサイト構築・運営は初めてだったのでECに関する情報収集を行い、その中で「実行計画」を知りました。

ECサイトの開設は早ければ早いほど良いと考えていたので、「PCI DSS準拠」ではなく、より手軽に導入できる”リンクタイプ”の決済システムで、「カード情報の非保持化」をすることを決めていました。
ECサイト開発自体は、WEBサービスの知識も豊富なので自社構築の予定です。

しかしながら、”リンクタイプ”導入の際に決済代行事業者とコンタクトをとると、以下のことが分かりました。


----------------------------------------
●チケットのEC販売は、商材の特性上、ユーザーのアクセス集中が起こりやすい

●アクセス集中が生じると、”リンクタイプ”では、ユーザー側に「決済画面に遷移しづらい」「決済に時間がかかる」などの負荷がかかる可能性が高い
----------------------------------------


かつ、C社の現状は、


--------------------
①イベントは大規模なものが多い
②自社のシステム開発力は申し分ない
--------------------


これにより、C社は、ECサイト開設スピードよりもその後のユーザー満足度が優先と考え、”トークン決済”を選びました。

”リンクタイプ”は、『決済画面』が決済代行事業者のサーバーに遷移する決済システムのため、ユーザーが『決済画面』に遷移する際にどうしても時間を要してしまいます。
その点、”トークン決済”は『決済画面』はC社のサーバー上にあり、クレジットカード情報だけがJavaScriptという技術を使って決済代行事業者のサーバー上に送信され、ECサイト上での「カードの非保持化」を実現しているため、アクセス集中時のユーザー負荷を軽減するとこができるのです。

C社は、販売する商品の特性上、”トークン決済”を選び、実行計画の「カード情報の非保持化」に対応しました。

”トークン決済”を選ぶ理由は様々

モデルケースではありますが、このように「カード情報の非保持化」の決済システムとして、”トークン決済”を選ぶケースは様々です。
その理由も、EC事業者の目線で考えることもあれば、ユーザー目線で考えることもあります。

自社の状況をふまえて、「カード情報の非保持化」の対応方法を検討いただければと思います。

GMOペイメントゲートウェイでは、”トークン決済” をはじめ、各ECサイトに適切な「カード情報非保持化」のご相談にのっておりますので、ぜひお気軽にお問い合わせください。
【お問合せフォーム】　　https://krs.bz/gmopg/m?f=504/?s=ecmikata170215


次回は、”リンクタイプ”で「カード情報の非保持化」を行う場合のモデルケースをご紹介したいと思います。




（*1）実行計画：経済産業省などからなる「クレジット取引セキュリティ対策協議会」より発表された、「クレジットカード取引におけるセキュリティ対策の強化に向けた実行計画」を指す。このなかで、EC事業者は2018年3月までに、「カード情報の非保持化」もしくは「PCI DSS準拠」の対応をしなければいけないという指針が発表されている

（*2）ドメイン：インターネット上にあるコンピューターを特定するために使われる、一定のルールに従って作られた文字列