サービス比較の記事一覧

余剰資金を有効活用したい(預金・投資・運用)
法人保険でリスクに備えたい

サービス比較の記事一覧

余剰資金を有効活用したい(預金・投資・運用)
法人保険でリスクに備えたい

オンラインサービスに決済を導入したい

オンライン決済システム・代行サービス
の関連情報


関連サービス資料を
無料で一括ダウンロード

,

Webスキミング対策とは?ECサイトがやるべき対策一覧とPCI DSS v4.0の要件をわかりやすく解説

Webスキミング対策とは?EC事業者がやるべき対策とPCI DSS v4.0の要件のサムネイル画像

自社のECサイトでクレジットカード決済を受け付けていると、「決済ページが改ざんされてカード情報が抜き取られる」というWebスキミングの被害が、他人事ではなくなってきます。言葉は見聞きしていても、自社で具体的に何をすればよいのか、どこまでが義務なのかまでは、意外とはっきりしないのではないでしょうか。

Webスキミング(Webスキミング攻撃)とは、ECサイトの決済ページなどに不正なプログラムを埋め込み、利用者が入力したクレジットカード番号やセキュリティコードを、入力されたその瞬間に盗み取る攻撃です。正規のサイトが改ざんされるため、利用者も運営者も気づきにくく、対策の遅れがそのまま被害につながります。

本記事では、EC事業者がやるべきWebスキミング対策の一覧を最初に示します。そのうえで、各対策の具体的なやり方、攻撃の手口と仕組み、PCI DSSや割賦販売法でどこまでが義務なのか、そして「カード情報の非保持化をしていれば安全」という誤解までを一続きで整理します。あわせて、決済ページを自社に持たない構造を実現できる決済代行サービスも紹介します。

まずは打つべき対策の全体像を掴み、自社で対応することと決済代行会社に任せられることを切り分けたうえで、資料請求や比較検討という次の一歩につなげていきましょう。

オンライン決済システム・代行サービスの関連サービス資料
PR
本セクションにはプロモーションが含まれており、表示順は当社独自の基準や提携状況に基づいています。

Webスキミング対策の一覧|EC事業者がやるべき対策と実現方法

ここからは、EC事業者がWebスキミングからサイトと顧客のカード情報を守るために打つべき対策を、一覧で示します。まず全体像として、それぞれの対策が「何を防ぐのか」と「自社で行うのか、ツールや決済代行に任せるのか」を次の表で整理します。

← 横にスクロールできます →
対策カード情報の非保持化(決済ページを自社に持たない)ソフトウェア・プラグイン・カートの最新化管理画面の多要素認証・アクセス制限外部スクリプトの管理(CSP・SRI)決済ページの改ざん検知WAF(Webアプリケーションファイアウォール)の導入脆弱性診断の定期実施
何を防ぐか決済ページの改ざん自体を、自社サイトの外に切り離す既知の脆弱性を突いたサイト改ざん管理者アカウントの乗っ取りによる改ざん外部サービス経由での不正スクリプトの読み込み改ざんの見逃し(起きたら速やかに気づく)サイトへの不正アクセスや改ざんの試み気づかないうちに残った穴の放置
実現の仕方決済代行に相談(リンク型・リダイレクト型の導入)自社(更新運用の徹底)自社(設定・運用)自社(開発・設定)ツール/決済代行に相談ツール(専門ベンダー)ツール/専門ベンダー

※各対策の詳細と、なぜその手当が必要かは次章で解説します。

これらの対策は、どれか一つで完結するものではなく、攻撃の入口を複数の面から塞ぐ組み合わせで効果を発揮します。とくに一番上の「カード情報の非保持化」は、決済ページを自社に持たない構造にすることで、他の対策の負担そのものを下げる土台になります。この点は記事の後半で詳しく掘り下げます。

各対策の具体的なやり方(自社でやること/決済代行・専門ベンダーに任せること)

ここからは、一覧で挙げた7つの対策を一つずつ、なぜ効くのか・どう実現するのか・誰が担うのかに分けて解説します。自社の担当者だけで抱え込む必要はなく、決済代行会社や専門ベンダーに任せられる部分を見極めることが、着実な対策への近道になります。

カード情報の非保持化(決済ページを自社に持たない)

非保持化とは、自社のサーバーやネットワークでカード情報を保存・処理・通過のいずれも行わない状態にすることです。決済代行会社が用意する決済画面へ利用者を遷移させるリンク型(リダイレクト型)の決済を導入すると、カード番号の入力そのものが自社サイトの外で行われます。決済ページの改ざんという攻撃の入口を、自社から切り離せるわけです。

この対策は自社単独では実現できず、決済代行会社への相談が起点になります。ただし後述するとおり、非保持化の方式によって効き目が変わるため、決済画面を自社に残さない完全リダイレクト型かどうかが選定のポイントです。

ソフトウェア・プラグイン・カートの最新化

Webスキミングの多くは、ECサイトが使うCMSやカートシステム、プラグインの既知の脆弱性を突いてサイトを改ざんすることから始まります。提供元が公開する修正プログラム(セキュリティパッチ)を速やかに適用し、常に最新の状態を保つことが、改ざんの入口をふさぐ基本の対策です。

これは自社で運用する対策です。使っているソフトウェアの一覧を把握し、更新情報を定期的に確認する体制を整えることが重要になります。サポートが終了した古いバージョンを使い続けている場合は、移行を検討する必要があります。

管理画面の多要素認証・アクセス制限

サイトの管理画面のIDとパスワードが破られると、攻撃者は正規の管理者として不正なスクリプトを埋め込めてしまいます。パスワードに加えてスマートフォンアプリなどによる確認を求める多要素認証(複数の要素を組み合わせた本人確認)を設定し、管理画面にアクセスできるIPアドレスを制限することで、乗っ取りのリスクを下げられます。

設定・運用は自社の担当範囲になります。推測されにくいパスワードの徹底とあわせて、退職者のアカウントを残さないなどの運用ルールも重要になります。

外部スクリプトの管理(CSP・SRI)

広告やアクセス解析など、ECサイトが読み込む外部サービスのスクリプトが改ざんされると、自社サイト本体に問題がなくても被害を受けます。読み込みを許可する送信元を制限するCSP(コンテンツ・セキュリティ・ポリシー)や、読み込むスクリプトが改ざんされていないかをハッシュ値で照合するSRI(サブリソース完全性)といった仕組みで、想定外のスクリプトの実行を防ぎます。

この対策はWebサイトの設定・開発を伴うため、自社の開発担当者や制作会社と連携して進めることになります。使っている外部サービスを洗い出し、本当に必要なものだけに絞ることも、あわせて有効です。

決済ページの改ざん検知

改ざんをすべて未然に防ぐのは難しいため、改ざんが起きたら速やかに気づく仕組みも欠かせません。決済ページのスクリプトやHTTPヘッダの変化を監視し、不正な変更を検知して管理者に通知する改ざん検知の仕組みを導入すると、被害が長期化する前に対処できます。

改ざん検知は専用ツールを導入するか、決済代行会社が提供する機能を利用する形で実現します。後述するPCI DSSの新しい要件でも、この改ざん検知の仕組みが求められています。

WAF(Webアプリケーションファイアウォール)の導入

WAF(Webアプリケーションを狙う攻撃を検知・遮断する防御の仕組み)は、サイトの脆弱性を突く不正な通信をブロックし、改ざんの試みそのものを防ぎます。SQLインジェクションやクロスサイトスクリプティングといった、サイト改ざんにつながる攻撃への備えとして機能します。

WAFは専門ベンダーが提供するツールやクラウドサービスを導入して運用します。導入後も検知ルールの調整や監視が必要になるため、監視・運用まで任せられるサービスを選ぶ選択肢もあります。

脆弱性診断の定期実施

自社では気づかないうちに、サイトに攻撃の糸口となる穴が残っていることがあります。脆弱性診断(サイトやシステムの弱点を専門的に洗い出す点検)を定期的に実施することで、攻撃者に突かれる前に問題を把握し、修正できます。

脆弱性診断は専門ベンダーのサービスや診断ツールを利用します。後述するクレジットカード・セキュリティガイドラインでも、EC加盟店の脆弱性対策の一つとして、脆弱性診断やペネトレーションテストの定期実施が示されています。

Webスキミングとは?手口・仕組みと攻撃の流れ

ここからは、なぜこれらの対策が必要なのか、その理由となる攻撃の仕組みを解説します。Webスキミングは、攻撃者集団の手口を指す「Magecart(マジェカート)」や、フォームへの入力を狙う「フォームジャッキング」とも呼ばれ、決済ページに不正なスクリプトを仕込んで、利用者が入力したカード情報を盗み取ります。手口と流れを押さえておくと、前章の各対策が何を防ぐためのものかが腑に落ちます。

Webスキミング攻撃が成立する流れ

Webスキミングは、次のような流れで成立します。読者が対策を判断する土台として、まず攻撃の全体像を掴んでおきましょう。

Webスキミング攻撃が成立する流れを4ステップで示した図。STEP1改ざん:攻撃者がECサイトの脆弱性や管理画面の乗っ取りから不正なスクリプトを埋め込む。STEP2入力:利用者が正規のECサイトの決済ページでカード情報を入力する。STEP3窃取:利用者のブラウザ上で不正なスクリプトが動き入力情報をその場で読み取る。STEP4送信:読み取った情報が気づかれないまま攻撃者のサーバーへ送信される。
  1. 攻撃者が、ECサイトの脆弱性や管理画面の乗っ取りを通じて、サイトに不正なスクリプトを埋め込む
  2. 利用者が、いつもどおり正規のECサイトを訪れて商品を選び、決済ページでカード情報を入力する
  3. 利用者のブラウザ上で不正なスクリプトが動き、入力されたカード番号やセキュリティコードをその場で読み取る
  4. 読み取った情報が、利用者にも運営者にも気づかれないまま、攻撃者のサーバーへ送信される

正規のサイトが改ざんされているため、URLも決済画面も一見して正常に見えます。利用者が偽サイトを見抜く余地がほぼない点が、Webスキミングの検知を難しくしています。

手口①:ECサイト自体を改ざんする

一つ目の手口は、ECサイトそのものを改ざんして不正なスクリプトを直接埋め込む方法です。CMSやカートシステム、プラグインの脆弱性を突いたり、管理画面のパスワードを破ったりして、攻撃者がサイトのファイルを書き換えます。前章で挙げたソフトウェアの最新化や管理画面の多要素認証は、この手口への備えにあたります。

手口②:ECサイトが利用する外部サービスを改ざんする

二つ目の手口は、ECサイトが読み込んでいる広告・アクセス解析・チャットなどの外部サービスを経由する方法です。ECサイト本体に問題がなくても、組み込んでいる外部サービスが攻撃を受ければ、そのスクリプトを通じて被害を受けます。外部サービス経由の攻撃は自社のログに痕跡が残りにくく、CSPやSRIによる外部スクリプトの管理が備えになります。

Webスキミングとスキミング・フィッシングの違い

「スキミング」や「フィッシング」と混同されがちですが、それぞれ別の攻撃です。違いを押さえておくと、対策の当てどころがはっきりします。

← 横にスクロールできます →
比較項目Webスキミングスキミング(従来型)フィッシング
どこで盗むか改ざんされた正規ECサイトの決済ページ(オンライン)店舗のカードリーダーやATMに仕込んだ機器(対面)本物を装った偽サイトへ誘導し入力させる
利用者が見抜けるかURLも画面も正常に見え、見抜くのは困難不審な機器に気づけば防げる場合があるURLや差出人を確認すれば見分けられる場合がある
主な対策の担い手ECサイト運営者(事業者側)カード会社・店舗・利用者利用者(カード保有者)

※攻撃の特徴を整理したものです。実際の手口は組み合わせて用いられる場合があります。

Webスキミングは正規サイトの改ざんが起点であるため、利用者側の注意だけでは防ぎきれず、サイトを運営する事業者側の対策が中心になります。この点が、利用者の注意で一定程度見分けられるフィッシングとの大きな違いです。

Webスキミングの被害事例と放置した場合のリスク

次に、実際の被害事例と、対策を怠った場合に事業者が負うリスクを見ていきます。Webスキミングが遠い話ではないことが、具体像から掴めるはずです。

国内外で相次ぐ被害事例

海外では、2018年に英国の航空会社ブリティッシュ・エアウェイズが、決済ページの改ざんによって約38万件の決済情報が漏えいしたと発表した事例が広く知られています。この攻撃は前述のMagecartと呼ばれる攻撃者集団によるもので、決済ページ改ざんの脅威が世界的に注目される契機となりました。

国内でも、2022年から2024年にかけて、ECサイトからのクレジットカード情報漏えい事案が相次いで公表されています。

出典・参考資料(1件)

被害の規模感は、クレジットカード全体の不正利用被害額からも読み取れます。日本クレジット協会の集計によると、2025年(1月〜12月)のクレジットカード不正利用被害額は510.5億円にのぼります。そのうち、漏えいしたカード番号を悪用する「番号盗用」による被害が475.4億円と、全体の約93%を占めています。Webスキミングは、この番号盗用の温床となるカード情報漏えいの主要な経路の一つです。

出典・参考資料(1件)

対策を放置した場合のリスク

Webスキミングの被害に遭うと、事業者は複数の面で損失を被ります。とくに、顧客のカード情報という機微な情報を預かる立場として、金銭面にとどまらない影響が及びます。

  • 情報漏えいと二次被害:顧客のカード情報が流出し、不正利用などの二次被害につながります。後述するとおり、漏えい時には個人情報保護委員会への報告や本人への通知が求められます。
  • 金銭的な損失:原因調査(フォレンジック調査)やサイト改修の費用、カード決済の一時停止による売上機会の損失、被害者への対応費用などが発生します。
  • 信頼の失墜:漏えいの公表による顧客離れやブランドイメージの低下は、復旧に時間を要します。

これらのリスクを避けるためにも、対策は「余裕があれば」ではなく、EC事業者が果たすべき責務として捉える必要があります。次章では、どこまでが法令上の義務なのかを整理します。

Webスキミング対策はどこまで義務?PCI DSS・割賦販売法・個人情報保護法の要件

続いて、Webスキミング対策が「どこまで義務なのか」を、関係する3つの制度から整理します。社内で対策の予算や体制を通す際の根拠にもなる部分です。まず全体像を次の表で俯瞰し、続けて制度ごとに詳しく見ていきます。

← 横にスクロールできます →
制度PCI DSS v4.0.1(カード業界のセキュリティ基準)割賦販売法/クレジットカード・セキュリティガイドライン(6.1版)個人情報保護法
主な対象決済ページで自社がカード情報を扱う(決済画面を自社に持つ)EC加盟店クレジットカード決済を扱うEC加盟店個人データを扱う全事業者
求められること決済ページスクリプトの管理(要件6.4.3)と、変更・改ざん検知の仕組み(要件11.6.1)。2025年3月31日以降は必須カード情報の非保持化、または保持する場合はPCI DSS準拠。加えて自社システム・Webサイトの脆弱性対策安全管理措置の実施と、漏えい等が起きた場合の個人情報保護委員会への報告・本人通知
根拠・所管PCI Security Standards Council経済産業省/クレジット取引セキュリティ対策協議会(日本クレジット協会)個人情報保護委員会

※制度の要点を要約したものです。適用の詳細は各制度の原典をご確認ください。

PCI DSS v4.0.1の決済ページ要件(6.4.3・11.6.1)と適用期限

PCI DSS(クレジットカード業界の国際的なセキュリティ基準)は、最新版のv4.0.1(v4.0の限定改訂版)で、Webスキミングを念頭に置いた決済ページ保護の要件を新たに設けました。中心となるのが、要件6.4.3と要件11.6.1の2つです。

要件6.4.3は、消費者のブラウザで読み込まれ実行されるすべての決済ページのスクリプトを管理することを求めます。具体的には、各スクリプトが承認されたものであることの確認、スクリプトの完全性(改ざんされていないこと)の確保、そして各スクリプトがなぜ必要かを技術的・業務的に正当化した一覧の維持の3点です。この完全性を確保する実装例として、前述のCSPやSRIが挙げられています。

要件11.6.1は、消費者のブラウザが受け取る決済ページのスクリプト内容や、セキュリティに影響するHTTPヘッダについて、不正な変更・改ざんを検知する仕組みを導入することを求めます。検知は少なくとも週1回、またはリスク分析にもとづく頻度で行うとされています。前章で挙げた改ざん検知の対策が、この要件に対応します。

これら2つの要件は、2025年3月31日まではベストプラクティス(推奨)として扱われ、同日を過ぎた以降は必須となっています。ただし、後述するとおり、決済ページを自社に持たない構成の場合は、これらの要件の適用範囲が変わります。

出典・参考資料(2件)

割賦販売法とクレジットカード・セキュリティガイドラインの非保持化・脆弱性対策

国内では、割賦販売法にもとづき、クレジットカード情報の適切な管理と漏えい防止措置が加盟店に求められています。その具体的な指針を示すのが、クレジット取引セキュリティ対策協議会がまとめるクレジットカード・セキュリティガイドライン(以下、ガイドライン)です。現行の6.1版では、EC加盟店に対して非保持化に加えて脆弱性対策を講じることが示されています。

カード情報を保持しない非保持化、又はカード情報を保持する場合は PCI DSS に準拠する。さらに、EC 加盟店のシステム及び Web サイトの「脆弱性対策」を講じる。

出典:クレジットカード・セキュリティガイドライン【6.1版】|クレジット取引セキュリティ対策協議会

ここでいう脆弱性対策には、システム管理画面の多要素認証、脆弱性診断やペネトレーションテストの定期実施、SQLインジェクションやクロスサイトスクリプティングへの対策などが含まれます。前章で挙げた各対策の多くが、このガイドラインの指針対策と重なっていることが分かります。ガイドラインは、この脆弱性対策を割賦販売法上の漏えい防止措置の指針対策の一つと位置づけています。

出典・参考資料(2件)

個人情報保護法の安全管理措置と漏えい時の報告義務

個人情報保護法は、個人データを扱う事業者に安全管理措置を求めるとともに、漏えい等が起きた場合の報告・通知の義務を定めています。カード情報の漏えいは、この報告義務の対象となります。

個人情報取扱事業者は、その取り扱う個人データの漏えい、滅失、毀損その他の個人データの安全の確保に係る事態であって個人の権利利益を害するおそれが大きいものとして個人情報保護委員会規則で定めるものが生じたときは、個人情報保護委員会規則で定めるところにより、当該事態が生じた旨を個人情報保護委員会に報告しなければならない。

出典:個人情報の保護に関する法律(第26条)|e-Gov 法令検索

報告の対象となる具体的な事態は、同法の施行規則で定められています。クレジットカード番号のように不正利用で財産的被害が生じるおそれがある情報の漏えいや、本人の数が1,000人を超える漏えいなどが該当します。

さらに、2024年4月に施行された施行規則の改正で、不正の目的による行為で漏えいした情報の範囲に、「取得し、又は取得しようとしている個人情報」が加わりました。これにより、Webスキミングのように利用者が入力している途中で盗まれた情報も、報告の対象に含まれることが明確になっています。

報告の期限は、速報として事態を知った後すみやかに、確報として原則30日以内(不正の目的による行為の場合は60日以内)と定められています。カード情報の漏えいは、対応を誤ると法令上の義務違反にもなりうるため、平時からの備えが欠かせません。

出典・参考資料(1件)

「非保持化していれば安全」は誤解|決済ページを自社に持たない構造の効き目

Webスキミング対策を考えるうえで、事業者が誤解しやすい点があります。「カード情報を非保持化していれば安全」という思い込みです。ここを正確に理解すると、自社が取るべき構造が見えてきます。

なぜ非保持化していても盗まれるのか

非保持化は、カード情報を自社のサーバーに蓄積しない有効な対策です。しかしWebスキミングは、利用者がブラウザ上でカード情報を「入力する瞬間」に盗み取るため、サーバーに保存する前に情報が抜かれてしまいます。非保持化そのものは、入力時点の窃取を防ぐ対策にはなりません。この実態は、制度側の文書でも次のように示されています。

カード情報の漏えいは主に加盟店において発生していることから、カード情報を加盟店で保持しないこと(非保持化)が有効なセキュリティ対策と考えられてきたが、現在の主な情報漏えいは、非保持化を実現した EC 加盟店において Web サイトの脆弱性等を原因としてカード情報が窃取されているものである。

出典:クレジットカード・セキュリティガイドライン【6.1版】|クレジット取引セキュリティ対策協議会

ガイドラインが非保持化に加えて脆弱性対策を求めるようになった背景には、まさにこの実態があります。「非保持化しているから大丈夫」と対策を止めてしまうことが、かえって危ういわけです。

決済ページを自社に持たない完全リダイレクト型で、負担が下がる

一方で、非保持化の「方式」によって、Webスキミングへの効き目は変わります。ガイドラインでは、決済代行会社を使った非保持化の方式を、次の2つに整理しています。

  • リダイレクト(リンク)型:決済代行会社の決済画面に遷移させてカード決済を行う方式。カードの入力画面そのものが決済代行会社側にある
  • JavaScript型(トークン型):加盟店の決済画面に、決済代行会社が提供するプログラムを組み込んで決済を行う方式。入力画面は加盟店のサイトに残る

自社が今どちらの方式かは、決済時にカード番号の入力画面が自社サイト上に表示されるか、決済代行会社のページへ切り替わるかで見分けられます。すでにカード決済を導入している場合は、まずこの点を確認すると、自社の負担がどこにあるかを把握しやすくなります。

この違いが効いてくるのが、前述したPCI DSSの決済ページ要件です。カードの入力画面を完全に決済代行会社側へ移す完全リダイレクト型では、決済ページが自社サイトに存在しないため、要件6.4.3・11.6.1が「該当なし」となります。

この場合、加盟店が自らの対策状況を確認する自己評価の様式(SAQ)のうち、対象範囲が最も狭く簡易なSAQ Aの範囲に収まりうるとされています。決済ページの改ざん検知やスクリプト管理といった負担を、構造的に自社の外へ切り離せるわけです。

ただし、これは「リンク型にすれば何もしなくてよい」という意味ではありません。完全リダイレクト型でも、自社サイトがスクリプト攻撃の影響を受けないことを確認する要件は残ります。

また、JavaScript型(トークン型)は入力画面が加盟店側に残るため、非保持化を実現していても決済ページ要件の対象になります。負担が明確に下がるのは、決済画面を決済代行会社へ遷移させる完全リダイレクト型である点を、正しく押さえておく必要があります。

出典・参考資料(2件)

決済ページを自社に持たない構造も含め、実店舗・EC・サブスクといった形態ごとに自社へ合うオンライン決済システムをどう選ぶかは、次の記事で選び方や機能を詳しく比較・解説しています。決済まわりの見直しを検討する方は、あわせてご覧ください。

自社サイトが感染していないか確認する方法

「すでに盗まれているのではないか」という不安に対しては、感染の有無を確認する手段があります。Webスキミングは気づきにくいからこそ、被害後に早く気づく仕組みが重要になります。

  • 決済ページのソースコード・通信の点検:ブラウザの検証ツール(デベロッパーツール)で決済ページを開き、身に覚えのない外部ドメインへの通信や、意図しないスクリプトが読み込まれていないかを確認します。自社で見きれない場合は制作会社や開発担当に依頼するとよいでしょう。
  • 脆弱性診断・改ざん検知の利用:専門ベンダーの脆弱性診断で弱点を洗い出し、改ざん検知の仕組みで変更を継続的に監視します。
  • 顧客からの申告への注意:「このサイトで買い物をした後にカードが不正利用された」という問い合わせが複数寄せられた場合、Webスキミングの兆候である可能性があります。

自社だけで判断が難しい場合は、セキュリティ専門ベンダーの調査サービスに相談するのが確実です。感染が疑われる場合は、被害の拡大を防ぐため、速やかにカード決済の停止や決済代行会社への連絡を検討する必要があります。

脆弱性診断を実際にどのサービスへ依頼するか迷う場合は、次の記事で診断方法や費用相場、無料ツールを含めた選び方を比較できます。自社サイトの弱点を洗い出す第一歩の参考にしてください。

Webスキミング対策に対応した決済代行サービスの活用

ここまで見てきたとおり、Webスキミング対策の土台は、決済ページを自社に持たない構造をつくることにあります。ECサイトのチェックアウトから決済代行会社の決済画面へ遷移させるリンク型(リダイレクト型)を使えば、カード情報の入力を自社サイトの外で受けられます。

ここでは、こうした非保持化(リンク型・リダイレクト型の決済)に対応し、PCI DSSに準拠した決済代行サービスを紹介します。前述のとおり負担が明確に下がるのは完全リダイレクト型のため、各サービスがどの方式に対応するかにも注目しながら、自社の決済まわりを見直す比較材料としてご活用ください。

← 横にスクロールできます →
比較項目Paysys(ペイシス)サブスクペイ
提供会社株式会社ペイメントフォー株式会社ROBOT PAYMENT
非保持化の方式メールリンク型(リダイレクト)
フォーム型・API連携型も選択可
メールリンク決済(リダイレクト)
トークン決済
主な決済手段クレジットカード5ブランド
PayPay・コンビニ・ペイジー
バーチャル口座・WEB口座振替
クレジットカード
口座振替・コンビニ
銀行振込・掛け払い ほか
PCI DSS準拠PCI DSS準拠PCI DSS準拠
EMV 3-Dセキュア標準対応(追加費用なし)標準対応(追加費用なし)
初期費用0円〜
(BtoB限定プラン。BtoCは要問い合わせ)
要問い合わせ
決済手数料〜1.99%
(BtoB限定プラン。BtoCは要問い合わせ)
2.5%〜
(+トランザクション7円/件)
詳細情報公式資料を見る公式資料を見る

※2026年8月時点の各社公式情報にもとづきます。最新の料金・仕様は各社公式サイトをご確認ください。

Paysys(ペイシス)(株式会社ペイメントフォー)

Paysys(ペイシス)のウェブサイト

Paysys(ペイシス)は、株式会社ペイメントフォーが提供する、システム開発を必要とせずに導入できるオンライン決済サービスです。管理画面から請求用のURLを発行し、メールやSMSなどで取引先に案内するだけで決済が完結する仕組みで、決済画面を自社に持たない運用がしやすい点が特徴です。

導入方式は、決済画面へ遷移させるメールリンク型、決済機能付きのフォーム型、既存システムと統合するAPI連携型の3つから選べます。Webスキミング対策として決済ページの負担を下げたい場合は、決済画面を決済代行会社側へ遷移させるメールリンク型(リダイレクト)が適しています。

カード情報の入力を決済代行会社側で受ける方式のため、非保持化と相性がよく、事業の成長に合わせて方式を切り替えられる拡張性も備えています。セキュリティ面では、PCI DSS(SAQ Type-D)に準拠し、本人認証のEMV 3-Dセキュアを追加費用なしで標準対応しています。

クレジットカード5ブランドに加え、PayPay・コンビニ・ペイジー・バーチャル口座などの決済手段に対応し、法人間取引(BtoB)向けのプランも用意されています。専任担当者が導入から運用までサポートする体制も、はじめてオンライン決済を導入する事業者にとって有力な選択肢となります。

サブスクペイ(株式会社ROBOT PAYMENT)

サブスクペイのウェブサイト

継続課金・サブスクリプションの代金回収に特化しているのが、株式会社ROBOT PAYMENTが提供するサブスクペイです。定期購入や会費徴収など、繰り返しの支払いを伴うビジネスを主な対象とし、決済と顧客・契約管理を一元的に扱えます。同社は東証グロース市場に上場しています。

決済手段としてメールリンク決済やトークン決済に対応し、カード情報を自社で保持しない運用が可能です。決済ページの負担軽減を重視する場合は、決済画面を決済代行会社側へ遷移させるメールリンク決済(リダイレクト)が選択肢になります。

セキュリティ面では、PCI DSS(v4.0)に準拠し、本人認証のEMV 3-Dセキュア(3Dセキュア2.0)を標準機能として追加料金なしで提供しています。情報セキュリティマネジメントの国際規格であるISMS認証も取得しています。

クレジットカードに加え、口座振替やコンビニ決済にも対応し、決済失敗時の自動リトライやカード有効期限切れ前の更新案内など、継続課金の取りこぼしを防ぐ機能が充実しています。サブスクリプション型のビジネスで、非保持化とあわせて回収の安定を図りたい事業者に適しています。

ここで取り上げた2サービス以外にも、非保持化に対応した決済代行会社は数多くあります。手数料相場や失敗しない選び方まで含めて広く比較したい場合は、次の記事もあわせてご覧ください。

まとめ

Webスキミング対策は、ソフトウェアの最新化や管理画面の多要素認証、改ざん検知や脆弱性診断といった複数の対策を組み合わせて進めるものです。そのなかでも、決済ページを自社に持たない完全リダイレクト型の非保持化は、決済ページ改ざんのリスクとPCI DSSの決済ページ要件の負担を構造的に下げる土台となります。

「非保持化していれば安全」ではなく、方式まで踏み込んで自社の決済構造を見直すことが、Webスキミングへの本質的な備えになります。まずは自社で対応することと決済代行会社に任せられることを切り分け、対応する決済代行サービスの資料を取り寄せて比較検討することから始めてください。

Webスキミング対策に関するよくある質問(FAQ)

Q. Webスキミングとは何ですか?

A. Webスキミングとは、ECサイトの決済ページなどに不正なプログラムを埋め込み、利用者が入力したクレジットカード番号やセキュリティコードを、入力されたその瞬間に盗み取る攻撃です。攻撃者集団の手口を指す「Magecart(マジェカート)」や、フォームへの入力を狙う「フォームジャッキング」とも呼ばれます。正規のサイトが改ざんされるため、利用者も運営者も気づきにくい点が特徴です。

Q. Webスキミングとフィッシングは何が違うのですか?

A. Webスキミングとフィッシングの違いは、カード情報を盗む場所にあります。フィッシングが本物を装った偽サイトへ利用者を誘導して入力させるのに対し、Webスキミングは本物の正規サイトそのものを改ざんして盗み取ります

フィッシングはURLや差出人を確認すれば見分けられる場合がありますが、Webスキミングは正規サイトのURLも決済画面も一見して正常に見えるため、利用者が見抜くのは困難です。このため、対策は利用者の注意だけでは足りず、サイトを運営する事業者側が中心となって講じる必要があります。

Q. カード情報を非保持化していてもWebスキミングの被害に遭いますか?

A. カード情報を非保持化していても、Webスキミングの被害に遭う可能性があります。非保持化は自社のサーバーにカード情報を蓄積しない有効な対策ですが、Webスキミングは利用者がブラウザ上でカード情報を「入力する瞬間」に盗み取るため、サーバーに保存される前に情報が抜き取られてしまうからです。

実際にクレジットカード・セキュリティガイドライン【6.1版】でも、現在の主な情報漏えいは、非保持化を実現したEC加盟店においてWebサイトの脆弱性などを原因として起きていると示されており、非保持化に加えた脆弱性対策が求められています。

Q. 外部サービスを使っているだけでもWebスキミングの被害を受けますか?

A. ECサイト本体に問題がなくても、読み込んでいる広告・アクセス解析・チャットなどの外部サービスが改ざんされれば、そのスクリプトを通じてWebスキミングの被害を受けます。外部サービス経由の攻撃は、自社のログに痕跡が残りにくい点も厄介です。

対策としては、読み込みを許可する送信元を制限するCSP(コンテンツ・セキュリティ・ポリシー)や、スクリプトが改ざんされていないかを照合するSRI(サブリソース完全性)といった外部スクリプトの管理が備えになります。使っている外部サービスを洗い出し、本当に必要なものだけに絞ることも有効です。

Q. PCI DSS v4.0.1の決済ページ要件(6.4.3・11.6.1)はいつから必須ですか?

A. PCI DSS v4.0.1の決済ページ要件6.4.3・11.6.1は、2025年3月31日まではベストプラクティス(推奨)として扱われ、同日を過ぎた以降は必須とされています。要件6.4.3は決済ページで読み込まれるすべてのスクリプトを管理することを、要件11.6.1は決済ページの変更・改ざんを検知する仕組みを導入することを求めるものです。

ただし、決済ページを自社に持たない完全リダイレクト型の構成では、これらの要件が「該当なし」となり適用範囲が変わるため、自社の決済構造に応じた確認が必要です。

Q. 自社サイトがWebスキミングに感染していないか確認する方法はありますか?

A. 自社サイトの感染は、決済ページのソースコードの点検、脆弱性診断・改ざん検知の利用、顧客からの不正利用の申告への注意などで確認できます。決済ページに身に覚えのない外部ドメインへの通信や意図しないスクリプトが埋め込まれていないかを点検し、改ざん検知の仕組みで継続的に監視します。

自社だけで判断が難しい場合は、セキュリティ専門ベンダーの調査サービスに相談するのが確実です。感染が疑われる場合は、被害の拡大を防ぐため、速やかにカード決済の停止や決済代行会社への連絡を検討する必要があります。

Q. Webスキミング対策は決済代行会社に任せられますか?

A. Webスキミング対策は、一部を決済代行会社に任せられますが、すべてを任せきることはできません。カード情報の非保持化(決済ページを自社に持たない構造)や決済ページの改ざん検知は決済代行会社に相談して実現できる一方、ソフトウェアの最新化、管理画面の多要素認証、脆弱性診断などは自社で担う対策です。

まず自社で対応することと決済代行会社に任せられることを切り分けたうえで、決済ページを自社に持たない構造に対応した決済代行サービスを検討するのが、着実な進め方になります。

オンライン決済システム・代行サービスの料金・手数料を一括チェック

MCB FinTechカタログでは、カード情報の非保持化に対応したオンライン決済システム・決済代行サービスの最新資料をまとめてダウンロードできます。各サービスの決済方式や手数料、セキュリティ対応、サポートの範囲を比較し、Webスキミング対策と自社に合った決済構造の検討にご活用ください。

MCB FinTechカタログに掲載しませんか?

MCB FinTechカタログでは、掲載企業様を募集しています。マネックスグループの金融実務ノウハウを活かした独自の評価軸と検索設計により、導入検討者が最適なサービスを効率的に発見できる法人向け比較プラットフォームです。掲載後は管理画面から料金表や導入事例を随時更新でき、常に最新の情報を訴求可能。まずは下記フォームより、お気軽にお問い合わせください。

監修者

マネックス証券 フィナンシャル・インテリジェンス部 暗号資産アナリスト

松嶋真倫

都市銀行にて金融実務を経験後、暗号資産関連スタートアップの創業期に参画し、市場分析・業界調査に従事。2018年にマネックスグループ入社。以降、ビットコインをはじめとするデジタルアセットからマクロ経済環境まで、金融市場を横断した調査・分析および情報発信を担う。FinTech・次世代金融領域のリサーチ統括、各種レポートや書籍の執筆、日本経済新聞など国内主要メディアへのコメント・寄稿、イベント登壇などを行う。2021年3月より現職。
記事内でご紹介している製品・サービスは監修者が選定したものではなく、編集部が独自に選定したものです。
監修の範囲は記事の一般的な解説部分であり、比較表および各製品・サービスの紹介内容は監修の対象外です。
オンライン決済システム・代行サービスの関連サービス資料

PR

本セクションにはプロモーションが含まれており、表示順は当社独自の基準や提携状況に基づいています。

関連記事

新着記事

オンライン決済システム・代行サービス
おすすめの診断サービス