割賦販売法が改正され、クレジットカード情報を取り扱う事業者は「PCI DSS準拠」または、「クレジットカード情報の非保持化」が必要です。当記事では、守るべきクレジットカード情報とは何かから、キャッシュレス決済を取り巻く状況、ガイドラインの解釈、対応策、PCI DSS最新バージョン4.0など、すべてを徹底解説します。
PCI DSSとは(ペイメントカード業界データセキュリティ基準)
PCI DSS(Payment Card Industry Data Security Standard の略)とは、クレジットカード会員の情報を保護することを目的に定められた、クレジットカード業界の情報セキュリティ基準です。
PCI DSSは2004年に国際カードブランドのAmerican Express、Discover、JCB、MasterCard、VISAの5社によって策定されました。現在はその5社が共同設立した組織であるPCI SSC(PCI Security Standards Council)によって運営/管理されています。※Diners Club は Discover のグループであり、PCI DSS においては Discover の基準を適用している。
安全なネットワークの構築やカード会員データの保護など、12 の要件に基づいて約 400 の要求事項から構成されており、「準拠」とは、このうち該当する要求事項に全て対応できていることをいいます。PCI DSS 準拠の検証方法としては、①オンサイトレビュー(認定セキュリティ評価機関(QSA)による訪問審査)又は②自己問診(SAQ、自己評価によって PCI DSS 準拠の度合いを評価し、報告することができるツール)による方法があります。
PCI DSSが策定されるまでは、カードブランドなどが独自にセキュリティ基準を定めていたため、加盟店は各ブランドの求める要求に応える必要がありました。しかし、現在はひとつの加盟店で複数のカードが使える仕組みが一般的なため、各ブランドの要求に対応するのは、非常に大きな負荷となっていました。
一方で、サイバー攻撃は巧妙化かつ多様化し、その結果、カード会員データの流出事故は大規模になってきました。このような状況のため、American Express、Discover、JCB、MasterCard、VISAの5社は共同で、セキュリティリスクの低減と効率的な運用を目的として、クレジットカード情報保護のための統一的なセキュリティ基準を策定。それがPCI DSSです。
PCI DSS準拠が必要な企業とは
一般に「カード会社」と呼ばれる企業には、VisaやMastercardなどの国際ブランドと契約して加盟店との契約や決済と精算業務を行うカード会社(アクワイアラ)と同じく国際ブランドと契約してカード会員に対してクレジットカード発行業務を行うカード会社(イシュア)の2種類があります。カード会員がカードを加盟店に提示すると、その情報は決済ネットワークを通してアクワイアラに送られ、さらにイシュアへと連携されます。この過程でカード情報が通過・処理・保存される事業者は、外部の業務委託先も含め、全てPCI DSSに準拠しなくてはなりません。

日本政府は、2020年の東京オリンピック・パラリンピック開催を踏まえ、キャッシュレス決済普及と訪日外国人増加を踏まえたATMの海外発行カードの対応やカードを消費者が安心して利用できる環境整備に向けた対策の取りまとめを関係省庁に指示しました。これを受け、経済産業省をオブザーバーとしたクレジット取引セキュリティ対策協議会が、「クレジットカード取引におけるセキュリティ対策の強化に向けた実行計画」(以下実行計画)を2016年から発行しており、2020年まで毎年アップデートが行われました。
実行計画内では、クレジットカード取引にかかわる事業者の種類別に、PCI DSS準拠の期限が決められています(加盟店についてはカード情報の非保持化も選択可能)。間に合わなかった場合、罰則規定はありませんが、決済代行事業者についてはアクワイアラは契約を見直すよう求められています。また2018年6月1日に施行される改正割賦販売法では、加盟店もカード情報保護について法律上の義務を負い、アクワイアラからの指導強化や、最悪の場合は加盟店契約が解除になるといった影響が考えられます。
PCI DSSにおけるカード情報の定義
PCI DSSでは、保護の対象となるカード情報を「アカウントデータ」と呼んでいる。アカウントデータに含まれる項目は「カード会員データ」と「機密(センシティブ)認証データ」の2種類に分けられます。

「プライマリアカウント番号(PAN)」とは、カード表面に印字された16桁(American Expressは15桁)のいわゆるカード番号である(将来的には19桁化が予定されている)。「CAV2/CVC2/CVV2/CID」とは、カード裏面に印字された3桁(American Expressはカード表面の4桁)の数字で、一般的には「セキュリティコード」と呼ばれている。「全トラックデータ」は、カードの磁気ストライプに含まれる72 バイト(69 桁)の文字列で、「全磁気ストライプ情報」ともいう。対面決済で利用されるが、非対面決済の与信照会(オーソリゼーション)に必要なPANと有効期限も含まれています。
(参考:
PCI DSSにおけるカード情報の定義)
コラム:時代遅れの「セキュリティコード」に頼る理由
クレジットカードを利用し、ECサイトなどで買い物をする際に、カード番号、氏名、有効期限とともに「セキュリティコード」の入力を求められることがあります。セキュリティコードとは、カードの裏面に印字されている3桁(American Expressのみ表面の4桁)の数字です。ECサイトを利用するときに、このセキュリティコードを要求しないカード加盟店もあります。例えばAmazonでは「1クリック」購入ボタンを押せば、登録してあるカード情報だけで決済が完了します。
セキュリティコードは、安全性を高める仕組みですが、ECサイトからすれば悩ましい存在だです。決済時にセキュリティコードの入力を求められると、利用者は正規のカードを準備してコードを確認しなければならない。これが面倒で、購入をやめてしまう人が少なからずいます。ECサイトでは、このような「カゴ落ち」と呼ばれる購入者の離脱率にきわめて敏感で、セキュリティコードの入力をあえて省略しているところも。つづきは
こちらから
クレジットカード漏洩時のビジネスインパクト
守るべきクレジットカード情報

クレジットカード情報はどのように盗まれるのか
まず、最も典型的な手法としてあげられるのが、「SQLインジェクション」によるカード情報の抜き取りです。SQLインジェクションとは、ECサイトなどのWebサーバに対して、不正なデータベースコマンドを入力して、データベースサーバに保存されている情報を抜き取るという方法です。
また、バックドアによるカード情報の詐取の手口が有名です。バックドアをECサイトなどの決済を行うWebサイトのカード決済画面やアプリケーションサーバに潜ませることにより、カード情報を悪意のある第三者のサーバにも送信することができます。特徴的なのは、カードの決済情報は通常通りPSP(決済代行事業者)にも送られているため、決済は正規に完了します。そのためカード情報の流出に気付かず、長い期間に渡ってカード情報が流出し続けるということが多いです。
最後に、現在米国で急増中のPOSマルウェアによるカード情報盗難の事例を紹介します。POSマルウェアは、加盟店の店舗内のPOSマシンで使用しているネットワークと接続しているネットワーク(Wi-Fiなど)を利用しているPCなどから感染し、POSマシンやストアサーバからカード情報を検索し、外部に不正に送信を行います。(参考:
PCI DSSとは? カード情報漏えいとセキュリティ対策)
盗まれたカード情報はどう換金されるのか
抜き取ったカード情報は、本人確認の比較的甘いプリペイドカードへの残高チャージや、モバイルペイメントアプリに登録して使用されるケース、他人のクレジットカードをiPhoneに支払カードとして登録して、不正利用されるなどが考えられます。
また、入手したカード情報を自分で使用せず、偽造や不正利用に使えるカード情報リストとして販売するブラックマーケットも存在しています。カード番号・有効期限がセットになったデータが販売されています。こうして不正に得たお金が組織犯罪やテロの資金源となっているとも言われています。
カード情報が情報漏えいした加盟店の支出(例)
万一、加盟店がカードデータを流出してしまった時、ビジネスに対してどのようなインパクトがあるか。直接的な金銭支出について考えてみます。
[1]調査のコスト:500万円~1,000万円
[2]お客様へのお詫びのコスト:1人あたり500円程度
[3]他の加盟店でカード情報が不正に使用された場合:損失負担は流出させた加盟店
[4]二次被害を防ぐためにカード会社や国際ブランドによるモニタリング:加盟店負担
[5]カード会社の再発行手数料:1枚あたり2,000〜3,000円を加盟店が負担
[6]カード会社が対応するためのコールセンター運営:加盟店負担
原因を明らかにしてセキュリティ対策が完了するまではカード情報の流出が続いている疑いがあります。そのため、原則としてクレジットカード決済は一時停止措置が取られます。その間当該加盟店は顧客にクレジットカードによる支払手段を提供出来ません。(参考:
PCI DSS準拠の必要性 クレジットカード漏洩時のビジネスインパクト)
コラム:狙われる「ブランドプリペイドカード」
ブランドプリペイドはカード、発展途上国で銀行口座を持っていない人でもVisaやMasterCardを利用することを可能にするために作られたものです。アフリカなどの国では、治安の悪さ、マネーロンダリングや脱税防止の観点からも、振込んだ年金をそのままカードで使用してもらう方が国民にとっても為政者のとっても好ましいため、推進を進めている国もあります。またプリペイドカードは、国際ブランドにとっても先進国で飽和したクレジットカード市場を拡大していくために重要な戦略でです。若い世代を取りこむ戦略であることは理解できます。しかし、本人確認をほとんどせずにクレジットカードやデビットカードとほぼ同じ機能を持つカードを配布することにより、新たなカード犯罪の温床になる可能性があります。つづきは
こちらから
クレジットカード取り扱い事業者が実施すべきセキュリティ対策
クレジットカード取り扱い事業者が実施するべきセキュリティ対策として、クレジット取引セキュリティ対策協議会が取りまとめた、「
クレジットカード・セキュリティガイドライン」に基づいた対策が必要です。このガイドラインは、セキュリティ対策置の実務上の指針と位置づけられていた「クレジットカード取引におけるセキュリティ対策の強化に向けた実行計画」(実施期限は2020年3月末)の後継文書となります。
クレジットカード・セキュリティガイドラインは、「割賦販売法(後払分野)に基づく監督の基本方針」において割賦販売法で義務付けられているカード番号等の適切管理及び不正利用防止措置の実務上の指針として位置付けられるものです。本ガイドラインに掲げる措置又はそれと同等以上の措置を講じている場合には、セキュリティ対策に係る法令上の基準となる「必要かつ適切な措置」を満たしていると認められます。
クレジットカード取引におけるセキュリティ対策の強化に向けた実行計画
日本政府は、2020年の東京オリンピック・パラリンピック開催を踏まえ、キャッシュレス決済普及と訪日外国人増加を踏まえたATMの海外発行カードの対応やカードを消費者が安心して利用できる環境整備に向けた対策の取りまとめを関係省庁に指示しました。これを受け、経済産業省をオブザーバーとしたクレジット取引セキュリティ対策協議会が、「クレジットカード取引におけるセキュリティ対策の強化に向けた実行計画」を2016年から発行しており、2020年まで毎年アップデートが行われました。
実行計画内では、クレジットカード取引にかかわる事業者の種類別に、PCI DSS準拠の期限が決められています(加盟店についてはカード情報の非保持化も選択可能)。間に合わなかった場合、罰則規定はありませんが、決済代行事業者についてはアクワイアラは契約を見直すよう求められています。また2018年6月1日に施行される改正割賦販売法では、加盟店もカード情報保護について法律上の義務を負うこととなっています。
必要なセキュリテュ対策内容とは
割賦販売法の改正により拡充されたクレジットカード番号等取扱業者に対するクレジットカード・セキュリティガイドラインにおけるセキュリティ対策の一覧(『クレジットカード・セキュリティガイドライン【3.0版】』P15より) 以下は抜粋した図です。

改正割賦販売法(抜粋)
PCI DSS準拠が求められるユーザー企業(2021年改正割賦販売法で定義される1号~7号事業者に該当)としてどの事業者に該当するか、確認可能です。
事業者種別 |
具体的な業種例 |
---|
1号事業者 |
・カード発行会社(イシュア) |
2号事業者 |
・加盟店(対面/非対面) |
3号事業者 |
・加盟店契約会社(アクワイアラ) |
4号事業者 |
・決済代行業者等
決済代行業者、ECモール事業者、ショッピングセンター・モール等、CCT端末先 等 |
5号事業者 |
・QRコード決済事業者等
QRコード決済事業者、スマートフォン決済事業者、ID決済事業者等、名称にかかわらずカード情報と紐づけた他の決済用番号で決済を行う事業者 |
6号事業者 |
・第5号事業者からカード情報の管理を受託している事業者 |
7号事業者 |
・加盟店向け決済システム提供事業者
EC システム提供会社(ASP/SaaS として EC 事業者にサービス提供する事業者、EC 事業者に購入プラットフォームを提供する事業者) 等
※カード会員データの伝送処理保存を行っている事業者、決済代行会社又はアクワイアラに接続できる決済モジュールを提供している事業者も含まれます。 |
(2022年3月9日更新) 「
クレジットカード・セキュリティガイドライン【3.0版】が取りまとめられました」
・「クレジットカード・セキュリティガイドライン」とは、安全・安心なクレジットカード利用環境を整備するため、クレジットカード取引に関わるカード会社、加盟店、決済代行業者等の関係事業者が実施するべきクレジットカード情報漏えい・不正利用防止のためのセキュリティ対策の取組を取りまとめたものです。
・また、同ガイドラインは、割賦販売法に規定するセキュリティ対策義務の「実務上の指針」として位置づけられており、同ガイドラインに掲げられている措置又はそれと同等以上の措置を適切に講じている場合には、同法で定めるセキュリティ対策の基準を満たしていると認められます。
・なお、[3.0版]では、関係事業者における適切なセキュリティ対策の実施を促進するため、割賦販売法に規定するセキュリティ対策の義務対象となる事業者の例示を記載するなどの具体化を図っています。
コラム:個人情報保護法が求めるカード番号漏えい時の対応
個人情報保護法において、ある情報が個人情報に当たるかどうかを判断する際の根拠となるのが「容易照合性」。ほかの情報と容易に照合することができ、それにより特定の個人を識別できるかどうかということです。
カード発行会社では、カード番号から会員の氏名、住所などの個人情報を照合することは容易です。このため、カード発行会社にとってカード番号は個人情報となります。しかし、カード発行会社以外では、カード番号だけでは個人を識別できません。したがって、カード発行会社以外の事業体にとっては、カード番号のみの場合は個人情報とは見なされません。ただし、カード情報が外部に流出する際に、カード番号だけが漏えいすることはほとんどありません。つづきは
こちらから
クレジットカード情報の非保持とは
クレジットカード情報の非保持化とは、カード情報を保存する場合、それらの情報は紙のレポートやクレジット取引にかかる紙伝票、紙媒体をスキャンした画像データ等のネットワークにおいて「カード情報」を『保存』、『処理』、『通過』しないこと」をいいます。
クレジットカード情報保護において、非保持化がPCI DSS準拠と同等であると見なされるのは、クレジットカード加盟店だけであることに留意する必要がある。実行計画では、カード発行会社(イシュアー)、加盟店契約会社(アクワイアラー)、サービスプロバイダー(PSP、プロセシング事業者=決済データの処理などを受託する会社など)といった加盟店以外でカード情報を取り扱う事業者に対しては、カード情報の保持を前提とした適切な対策の構築を求めています。そのため、それらの事業者には非保持化という選択肢はなく、PCI DSSへの準拠が求められます。
(参考:
「カード情報非保持」の定義とは)
PCI SSCが提供するドキュメント・ライブラリー
PCI Security Standards Council は、PCI セキュリティ基準の開発、管理、教育、 および認知を担当する、オープンなグローバルフォーラムです。下記サイトでは、PCI DSS準拠を実現するのに役立つさまざまなツール、問診、ガイダンス、FAQ、トレーニングリソースなどの資料や情報が提供されます。是非参考にしてください。
▼参考:PCI Data Security Standard Self-Assessment Questionnaireはこちらから
https://www.pcisecuritystandards.org/document_library
認定審査機関一覧(QSA=Qualified Security Assessor)
日本国内においてPCI DSSの審査が可能なQSA(認定審査機関)は、下記のPCI SSCのサイトで、実施場所や言語で絞り込むことで、認定審査機関(QSA)の一覧が確認できます。クレジットカード情報を保存、処理、通貨する企業で、例えば、カード加盟店やカード会社、銀行、決済代行、BPO事業者などのサービス・プロバイダーが対象です。
https://www.pcisecuritystandards.org/assessors_and_solutions/qualified_security_assessors
また、QSA企業一覧は
日本カード情報セキュリティ協議会(JCDSC)のQSA/ASV企業一覧のページにも掲載されています。
PCI DSSで求められる要件
具体的にどのような基準が定められているのか、PCI DSSでは6つの目標とそれに対応する12の要件が定められています。また、カード会員データを扱う範囲と保護が必要な箇所が特定することで、効率的な準拠が実現できます。具体的にPCI DSSで定められている6つの目標とそれに対応する12の要件は以下となります。(参考:
PCI DSS 6つの目標と12の要件 PCI DSS準拠が必要な企業とは)
6つの目標 |
12の要件 |
---|
安全なネットワークとシステムの構築と維持 |
要件1 カード会員データを保護するために、ファイアウォールをインストールして構成を維持する
要件2 システムパスワードおよび他のセキュリティパラメータにベンダ提供のデフォルト値を使用しない
|
カード会員データの保護 |
要件3 保存されるカード会員データを保護する
要件4 オープンな公共ネットワーク経由でカード会員データを伝送する場合、暗号化する
|
脆弱性管理プログラムの維持 |
要件5 すべてのシステムをマルウェアから保護し、ウイルス対策ソフトウェアまたはプログラムを定期的に更新する
要件6 安全性の高いシステムとアプリケーションを開発し、保守する
|
強力なアクセス制御方法の導入 |
要件7 カード会員データへのアクセスを、業務上必要な範囲内に制限する
要件8 システムコンポーネントへのアクセスを識別・認証する
要件9 カード会員データへの物理アクセスを制限する
|
ネットワークの定期的な監視およびテスト |
要件10 ネットワークリソースおよびカード会員データへのすべてのアクセスを追跡および監視する
要件11 セキュリティシステムおよびプロセスを定期的にテストする
|
情報セキュリティポリシーの整備 |
要件12 すべての担当者の情報セキュリティに対応するポリシーを維持する
|
コラム:DUKPTによる暗号化の仕組み
DUKPT(Delivered Unique Key Per Transaction)は、米国国家規格協会の「ANSI X9.24 Part1」として規定されている、暗号化のためのプロトコルです。トランザクションごとに異なる暗号鍵による暗号化処理を行うことが大きな特徴。
サーバー側で保持しているシステム鍵(Base Derivation Key:BDK)を用いて決済トランザクションごとに異なる暗号鍵を生成、決済端末の初期設定時に、端末ベンダーが端末固有ID情報をサーバーに渡し、サーバー側はそれを基に端末用の初回鍵を作成します。つづきは
こちらから
PCI DSS準拠への対応プロセス
PCI DSS対象範囲策定
クレジットカード会員情報の取り扱い範囲特定し、PCI DSS準拠対応が必要な範囲を確定します。PCI DSS準拠対応においては、この最初の対象範囲を確定する作業がとても重要な作業となります。
FIT&GAP分析、対応方法の検討(ツール/サービス選定)
現在のセキュリティ対策状況を洗い出し、PCI DSSの要求事項とギャップ分析を行います。分析結果に基づいて、対応策の検討を行います。
システムへの実装と文書作成
システム仕様の策定をおこない、実装および運用手順/帳票などのポリシー文書作成を行います。また、執務エリアや店舗など環境整備も必要です。
運用と審査
内部スキャンや外部スキャン、ペネトレーションテストをを行います。検出事項への対応から、審査機関(QSA)へ提出する各種ドキュメント準備をおこないます。
PCI DSSの準拠対応後
PCI DSS 準拠は、お客様ビジネスの保護に不可欠な一手ですが、それだけでは十分ではありません。日々の運用改善、継続的な努力が必要です。企業が成長するにつれ、また時代とともにリスクも大きく変化しますので、各事業者は、最新の情報に基づいて、多面的・重層的な対策をする必要があります。
PCI DSS v4.0 今後のスケジュールと最新情報
PCI DSS v4.0 公開(2022年4月20日更新)
2022年3月31日、PCI DSS v4.0が公開された。同時に、Summary of Changes(v3.2.1とv4.0の変更点の概要)、準拠報告書(RoC)テンプレート、加盟店向けおよびサービスプロバイダー向けの準拠証明書(AoC)テンプレートが公開された。

(参考:
PCI DSS v4.0公開と移行のスケジュール)
PCI DSS v4.0で顕在化するクラウドサービスの課題
現行のv3.2.1からの改訂ポイントは、主に4つありますが、その中でも課題となるのが、「④クラウドサービスの要件への取り込み」です。PCI DSS準拠企業は、さまざまな外部委託先を活用しています。近年では、PCI DSS準拠対象となるシステムにSaaS、PaaSなどのクラウドサービスやセキュリティサービスを活用されることが増えています。ところが、日本で展開されるそれらのサービスの多くにPCI DSS準拠に活用できることをうたっているにも関わらず、自身はPCI DSS準拠をしていないという現状があります。
仮に、この問題を放置してPCI DSSに準拠していないサービスプロバイダーのサービスを使い続けた場合、認定審査機関(QSA)の審査からの指摘事項となりPCI DSS完全準拠とは言えないと判断されるケースが想定されます。
もう一点、「外部委託先との間の責任区分の明確化」についても注意が必要です。
PCI DSS準拠企業に対し、PCI DSS要件ごとの責任区分の明確化を求めています。しかし、サービスプロバイダーから情報開示が無いと、準拠側の責任範囲が分からないので、この要件を満たすことができず、PCI DSSに準拠できないことになってしまいます。言い換えると、責任区分を明示した文書を提供していないクラウドサービスを利用してPCI DSSに準拠することはできない可能性があるため注意が必要です。(参考:
PCI DSS準拠のために導入したクラウドサービスがPCI DSS準拠してない矛盾)
PCI DSS準拠のためのコンサルティング/クラウドサービス
PCI DSS Cloud プライベートクラウドモデル
プライベートクラウド環境を利用したい決済代行事業者、サービスプロバイダー、BPO事業者等向けにPCI DSS Ready CloudはPCI DSSの全要件の準拠を支援します。クレジットカードを取り扱う事業者向けのマルチテナント型プロバイダー、クラウドサービスを展開する事業者に利用されており、フルカスタマイズ、スケールアップが可能なサービスです。
PCI DSS Cloud AWSモデル
決済ソフトウェア会社、カード会社、スタートアップ事業者、Fintec事業者向けにAWSに最適化されたPCI DSS Ready CloudでPCI DSSの全要件の準拠を支援します。現在最も多くのお客さまに利用されており、AWSのPCI DSS準拠済コンポーネントと組み合わせることで最も短期で、リーズナブルに構築、運用が可能です。
PCI DSS準拠支援コンサルティング
PCI DSS準拠またはクレジットカード情報非保持化に伴う、PCI DSS対象範囲の策定、ギャップ分析、最適なツールやサービス選定支援、ドキュメント作成支援、審査支援まで幅広くサービスを提供します。本コンサルティングは国内トップクラスの実績と、可能な限り、運用コストを下げる構築支援が特長です。
BIZTELコールセンター PCI DSS
コールセンターで保存、処理、通過されるクレジットカード情報を、セキュリティを確保しながら取り扱うことができる PCI DSS要件に準拠済みのクラウド PBX サービスを、低コストで提供しています。国内導入実績トップのBIZTELにPCI DSS準拠したことで、アウトソーサーは電話によるクレジットカード決済処理など、新たな事業展開での利用が広がっています。
PCI DSS 事例
クレジットカード情報非保持化 事例 オルビス 様
“Pay TGは非対面加盟店の現場に寄り添い、一から設計されたサービス。オペレーターの負担を最小限に、スムーズにカード情報非保持化を実現できるサービスです”

オルビス株式会社 CRM・顧客満足推進部 部長 橋本 祥永 氏
改正割賦販売法の技術的指針である実行計画に基づいた高いセキュリティレベルを担保したうえで、現場のオペレーターが使いやすい仕組みであることが大切です。その点で、Pay TGは、非対面加盟店の現場に寄り添い、一から開発していることに強みがあると感じます。
一つ例を挙げると、テンキーでカード番号を入力した際の表示があります。他社サービスの場合「*****」といったように、入力したカード番号が見えないようマスクされるケースがありますが、Pay TGは、確定されるまではカード番号がそのまま画面に表示される仕様となっています。(参考:
オルビス株式会社 様 導入事例)
クレジットカード情報非保持化 事例 株式会社はとバス 様
“セキュリティに関して安心して利用できるPay TG。訪日外国人と邦人向け受注コールセンターで安心して利用しています”

特に重要視したのがセキュリティ面です。内回り方式も検討してましたが非保持化“同等”である事と、社内ネットワークを通過しているため、何かあった場合のインパクトを考慮して、外回り方式を採用しているPay TGをメインに検討を進めていました。
最終的には、入金を確認して初めて旅行契約が締結し、その後に予約番号やお座席をご案内するという当社の運用方法も踏まえ、Pay TGの導入に決定しています。旅行商品は約款上、決済して初めて契約が締結されるという事情などがあります。各種決済方法を検討している中、決済代行会社からのアドバイスもあり、当社の運用上一番スムーズで、しかも手軽に利用できることからPay TG導入を決めました。(営業企画部 通信販売課 高木 滉平氏)(参考:
株式会社はとバス 様 導入事例)
クレジットカード情報非保持化 事例 JIMOS 様
“Pay TG は利用するユーザーの意見を取り込んだサービスの開発スタンスが非常に柔軟です。さまざまな企業の運用課題をしっかりヒアリングし、要望を取り入れることでより良いサービスを提供するという企業姿勢を高く評価しました”

マキアレイベル事業部コンタクトセンターチーム アシスタントマネージャー 神田 剛志 氏
Pay TG は、従来のオペレーションを変更することなく、オペレーションミスが発生しない仕組みを構築可能であること、入力したクレジットカード番号が全桁表示されるのでオペレーターが復唱できること、基幹システムと決済端末のAPI 連携の開発コストが他社サービスの半額で済む、大きくこの3点を評価して、Pay TG に決定しました。
サービスの開発スタンスが非常に柔軟な点も高く評価しています。Pay TG は、さまざまな企業の運用課題をしっかりヒアリングし、要望を取り入れることでより良いサービスを提供するという姿勢は、長く付き合いができるパートナーとして、大変ありがたいです。(参考:
株式会社JIMOS 様 導入事例)
クレジットカード情報非保持化/サブスク決済 ユースケース PCショップ 様
“パソコンの初期設定、お客さま過失の故障やデータ復旧などを行う月額課金型PCサポートサービス。店頭受付でのクレジットカード決済業務のペーパーレス化と二度打ちから発生する打ち間違いをゼロに。”

(導入前)
・来店されたお客様に、申込書(紙)を記入頂いているが、ペーパーレス化を行いたい。
・紙の申込書をデータ化する時間がかかるため、お客様をおまたせしていた。
・クレジットカード情報を決済端末に手入力するため、たびたび打ち間違いが発生していた。
(導入効果)
・お客様はタブレットに申込情報を入力。タブレットと基幹システム、SmartTGが連携することで、ペーパーレス化を実現。
・お客様の待機時間が大幅減。三密を回避し、満足度アップ。
・Smart TGの磁気/ICでカード情報を読み込ことで、打ち間違いもなく、業務効率がアップ。
(参考:
PCショップ 様 ユースケース)
PCI DSS準拠 事例 メトロエンジン 様
“ 新サービスの宿泊予約エンジン「メトロブッキング」に必須となる、PCI DSS 準拠のシステムを1ヵ月で構築。
低コストで、スピード感あるローンチに成功しました ”

株式会社メトロエンジン 取締役 和田拓馬 氏
PCI DSS Ready Cloud AWSモデルを採用した最も大きな理由は、システムを自社で構築する方法、他社のサービスを利用する方法と比較して低コストで準拠環境を実現できることです。
コスト以外の理由が、短納期での対応ですね。当社はスピード感のある経営を心がけており、サービスのアイデアが生まれ、プロジェクトが始まってから、だいたい1、2ヵ月で、MVP※を完成し、市場でテストマーケティングさせることを目指しています。メトロブッキングも、4月末にプロジェクトが始まり、6月中にリリースするというタイトなスケジュールを組みました。リンクにそのような短期の構築が可能であるか否か確認したところ、自信をもって「できる」との回答をいただき、本当に心強く感じましたね。(参考:
株式会社メトロエンジン 様 導入事例)
PCI DSS準拠 事例 北の達人コーポレーション 様
“あらゆる事業リスクを低減させ、お客さまに安心して利用いただけるEC サイトを目指して。低コストでPCI DSS 準拠し、効率の良い運用体制を実現しました”

人事総務部 事業推進部長 兼 台湾支社長 川森 さや香氏
準拠に必要なセキュリティ機能がパッケージ化されたサービスを用意していたため、そのサービスを活用すれば、PCI DSS 準拠が最短で実現できます。しかもコストもリーズナブルで、AWS を利用した準拠実績が多数あったため、リンク社のサービス利用を決断しました。
PCI DSS の運用に必要な定形、非定形作業を委託できるマネージド・サービスも利用しています。PCI DSS に精通したエンジニアにアウトソースすることで、より効率的な運用体制が構築できたと思います。(参考:
株式会社 北の達人コーポレーション 様 導入事例)
PCI DSS準拠 事例 JFRカード株式会社 様
“データレイクを構築するプロジェクトにPCI DSS Ready Cloudを採用しました。プロジェクトは大変手離れが良く、リンクの技術者にぜひ感謝の旨、お伝えいただければと思います”

左から 執行役員兼システム業務企画本部 本部長 武井 匡仁氏 システム企画部 部長 義友 建弘氏 システム企画部 岩森 吏央氏
PCI DSS準拠という当たり前に求められるセキュリティ対策で、絶対に事故を起こさないことを念頭に置きながら、グループの一つの大きな柱を担っていければと考えています。あらゆる施策を実現するために一丁目一番地は「データの利活用」だと確信しています。
今回のデータレイク構築の取り組みにより、カード事業のOne to Oneマーケティング、マーケティングオートメーションが可能になります。今後、タンキングするデータレイクには、コールセンターの音声データ、外部から購入などするマーケティング関連データを入れるなど、“器”としての機能をより充実させていきます。(参考:
JFRカード株式会社 様 導入事例)