ちょっと気になったので、決済サービス各社はカード情報をどう守っているのか調べてみた

Posted at 2026-06-01

はじめに

こんばんは、mirukyです。

ネットで買い物をするとき、クレジットカードを直接入力することもあれば、Apple Pay、Google Pay、PayPal、Amazon Pay、PayPay、楽天ペイ、d払い、au PAY、メルペイなど、様々な決済サービスを選択することもありますよね。

どれも「決済サービス」としてひとまとめに見えますが、実際にはカード情報の守り方が大きく違います。カード番号をそのまま入力する方式もあれば、実カード番号の代わりになる番号を使う方式もあります。決済サービスのアカウントを経由して、購入先にカード番号を入力しないで済む方式もあります。

個人的に海外のよくわからない企業の、よくわからない決済サービスにクレカ情報を入力するのはかなり怖いですし、昨今安易なクレカ情報の入力によるカード番号やセキュリティコードの流出などによる不正利用がよく起きています（身近でもありました）。そこで、既存有名サービスはどんな仕組みで情報を守っているのかがちょっと気になりました。

この記事では、各サービスの公式情報をもとに、決済サービスがカード情報やアカウントをどう守っているのかを興味本位で調べてみたので、整理しました。
優劣をつけたいわけではなく、あくまでも公開情報からセキュリティ担保の仕組みの違いを楽しんでいただけるように作成しておりますので、そこはご了承ください。

セキュリティ対策がすべて公開されているわけではなく、具体的な実装部分はブラックボックスです。そのため、この記事はコードの実例を用いた解説ではありません。
各サービスが公開している情報をもとに、カード情報や決済アカウントを守るための設計方針を整理する記事です。

決済サービスを見るときの前提
カード番号を直接入力する決済
Apple Pay
Google Pay
PayPal
Amazon Pay
PayPay
楽天ペイ
d払い
au PAY
メルペイ
Stripe Checkout
サービス別に見る守り方の違い
利用者が普段から意識したいこと
サイトを作る側が意識したいこと

1. 決済サービスを見るときの前提

決済の安全性というと、つい「カード番号が漏れるかどうか」だけを考えがちです。しかし、実際に守るべきものはカード番号だけではありません。

ネット決済では、カード番号、有効期限、セキュリティコード、決済アカウント、ログインパスワード、住所、氏名、電話番号、購入履歴、端末情報など、さまざまな情報が関係します。

たとえば、カード番号が外に出にくい仕組みになっていても、決済サービスのアカウント自体を乗っ取られれば、不正に支払われる可能性があります。逆に、アカウントログインが強くても、カード番号を多くのサイトへ直接入力していれば、入力先サイト側の管理状態に影響を受けます。

この記事では、購入先にカード番号を入力するのか、別の番号やサービス経由にするのかを最初に見ます。そのうえで、生体認証、パスコード、2段階認証、本人確認書類、3Dセキュア、不正検知、補償制度がどこで関係するのかを整理します。

ここで大切なのは、どれか1つの仕組みだけで安全になるわけではない、ということです。カード番号を外に出しにくくする仕組み、本人を確認する仕組み、怪しい取引を止める仕組み、被害が起きたときの補償制度が重なって、ようやく安全性が高くなります。

セキュリティでありがちな、多層防御的な考え方です。

2. カード番号を直接入力する決済

昔からある形が、ECサイトの決済画面にクレジットカード番号、有効期限、セキュリティコードを入力する方法です。

この方式では、どの会社がカード情報を扱っているかが重要になります。購入先のサイトが自社でカード番号を保存している場合もあれば、Stripeや決済代行会社の画面や部品を使い、購入先のサーバーにはカード番号を通さない設計もあります。見た目は同じ「カード入力」でも、裏側の責任範囲は大きく違います。

個人的には、明らかにスクラッチで作成されているよくわからない企業の決済フォームよりも、Stripeを使用したフォームの方が安心しますし、前者である場合は入力しません。

なおIPA試験の勉強で必ず出てくるPCI DSSの基準では、カード検証コードなどの機密認証データの扱いが定められており、PCI SSCの日本語ドキュメントライブラリでは、現行のPCI DSS v4.0.1が公開されています。セキュリティコードは本人確認のために入力する情報であり、サイト側が保存してよい情報ではありません。なので、毎回セキュリティコードだけ入力している覚えのある方も多いのではないでしょうか。カード番号を扱う設計では、こうした保存してよい情報と保存してはいけない情報の切り分けも重要になります。

最近のオンライン決済では、3Dセキュアも重要です。3Dセキュアは、カード番号だけで決済を通すのではなく、カード発行会社側で本人確認を行う仕組みです。ワンタイムパスワード、アプリ承認、生体認証などが求められることがあります。

日本でも、経済産業省が公表したクレジットカード・セキュリティガイドラインの改訂内容では、EC加盟店の不正利用対策としてEMV 3-Dセキュアの導入と適切な不正ログイン対策の実施が示されています。カードを直接入力する決済は今後も残りますが、「カード番号を入れたら終わり」ではなく、カード発行会社や決済代行会社を含めた複数の層で守る形に近づいています。

3. Apple Pay

Apple Payは、実カード番号をそのまま決済のたびに出すのではなく、デバイスに紐づく番号や端末側のセキュリティ機能を使って支払いを保護する仕組みです。

Apple Payでは、実カード番号そのものではなく、カード発行会社が作成するデバイス固有のDevice Account Numberが使われます。この番号はSecure Elementに保存され、支払い時の認証はFace ID、Touch ID、パスコード、Apple Watchのサイドボタン操作などを通じて行われます。Secure Enclaveは主に認証プロセスを管理し、承認された取引を進める役割を持ちます。

日常の感覚で言うと、Apple Payは「カード番号を何度も店に渡す」のではなく、「iPhoneやApple Watchの中で支払い用の資格情報を管理し、端末の認証を通して支払う」形です。端末そのものが重要になるため、スマホのロック、紛失時の対応、Apple Accountの保護も安全性に直結します。

Apple Payの強みは、カード番号そのものを直接見せる場面を減らし、端末認証を支払いの流れに組み込んでいることです。一方で、端末をロックしていない、Apple Accountを弱いパスワードで使っている、紛失時にすぐ止められない、といった状態ではせっかくの仕組みを活かしきれません。

4. Google Pay

どうでも良いですが、私が一番よく使っている決済サービスです。

Google Pay / Googleウォレットによる支払いも、実カード番号をそのまま毎回見せるのではなく、仮想カード番号を使って支払い情報を守る考え方です。この記事では、ユーザー向けアプリとしてのGoogleウォレットを中心に書きますが、公式ページやヘルプではGoogle Payという表記も使われています。

Google Payヘルプでは、対応カードについて実カード番号の代わりに仮想カード番号が使われると説明されています。店舗やオンライン決済では、実カード番号そのものを加盟店へ渡さずに支払えるため、カード情報の露出を減らせます。ただし、取引用の仮想カード番号が加盟店側に共有される場合はあります。

また、店頭でカードを使うには端末の画面ロックが必要です。スマホをなくした場合は、Googleの「デバイスを探す」からロックやログアウト、データ消去ができることも案内されていました。

Googleウォレットの守り方は、カード番号を置き換えることと、GoogleアカウントやAndroid端末の保護を組み合わせる形です。したがって、Googleアカウントの保護、画面ロック、紛失時の遠隔ロックは、決済の安全性にも関係します。

5. PayPal

日本人的感覚からすればパっと見PayPayに見える決済サービスです。

PayPalは、購入先ごとにカード番号を入力するのではなく、PayPalアカウントに支払い方法を登録し、購入時にPayPalへログインして支払う形です。いわゆる、アカウント型の決済サービスです。

PayPalの公式ページでは、クレジットカードやデビットカードなどをPayPalアカウントに登録し、PayPalが使える店でログインして支払う流れが案内されています。購入先のサイトに毎回カード番号を入力しないで済む点が、利用者から見た大きな違いです。

PayPalは買い手保護制度も説明しています。注文した商品が届かない、説明と大きく異なる商品が届いた、といった場合に、条件を満たせば購入金額を保護する仕組みです。これはカード番号の保護とは別の話ですが、オンライン取引全体の安心材料になります。

一方で、PayPalアカウント自体が支払いの入口になるため、フィッシングに弱い使い方をしていると危険です。PayPalを名乗る偽メールからログイン情報を入力してしまえば、カード番号を直接入力していなくても被害につながります。

6. Amazon Pay

Amazon Payは、Amazon.co.jpアカウントに登録している支払い方法や住所情報を使って、Amazon以外の対応サイトで支払う仕組みです。

Amazon Payの購入者向けFAQでは、Amazon PayはAmazon.co.jpアカウントに登録された支払い方法と住所情報を使って商品やサービスの支払いができると説明されています。また、Amazon.co.jpは、利用者の同意なしにクレジットカード情報を第三者と共有しないとも説明しています。

利用者目線では、初めて使うECサイトにカード番号を直接入力しなくて済むのがわかりやすい利点です。支払い情報はAmazonアカウント側に寄せられるため、Amazonアカウントの保護がとても重要になります。

Amazon Payの購入者向けFAQでは、不明な請求があった場合の確認や問い合わせ方法も案内されています。ただし、補償や返金は条件や調査によって変わります。利用できる支払い方法も時期や条件で変わる可能性があるため、最新の購入者向けFAQを確認するのが安全です。支払い履歴を見て、覚えのない取引に早く気づくことも大切です。

7. PayPay

PayPayは、コード決済として使われることが多いサービスです。割り勘がしやすく、最近の日本人はかなり多数が使用しているため、色々と便利なサービスです。当初はポイントの還元率だったり特典が凄まじかったのですが、時を経た現在でも、一応使えば使うほどお得になることが多いです。

PayPayは、カード番号の保護だけでなく、アカウント、端末、残高、チャージ元の金融機関を含めた守り方を見る必要があります。

PayPayの公式ページでは、24時間365日の不正検知、セキュリティ専任スタッフによる監視、お客様情報の暗号化、不正利用時の即時アカウント停止、銀行口座登録時の本人確認などが説明されています。支払いに設定されたクレジットカードや口座情報は暗号化して管理しているとされています。

補償制度についても公開されています。PayPayアカウントが第三者に不正利用された場合や、PayPayアカウントを持っていないにもかかわらずPayPayからの請求が発生していた場合に、条件を満たせば申請できます。全額補償を受けるには本人確認が必要であること、原則として損害発生日から60日以内に申請する必要があること、故意または重大な過失がある場合には補償できない場合があることも示されています。

PayPayは便利なぶん、電話番号、端末、アカウント、銀行口座、カードがつながります。フィッシング、SIMスワップ、端末紛失の影響を受けやすい領域でもあるため、端末認証や利用可能額の設定をしておく意味があります。

8. 楽天ペイ

楽天ペイは、楽天IDと楽天ペイアプリを軸にした決済サービスです。楽天カード、楽天キャッシュ、楽天ポイントなど、楽天の他サービスとつながる点が特徴です（~~楽天経済圏御用達~~）。

楽天ペイの公式ページでは、不正利用防止策として、電話番号認証、本人認証、端末認証、ご利用内容確認などが説明されています。本人認証には、カードスキャン認証や本人認証サービス、つまり3Dセキュアが含まれます。

楽天ペイでは、支払い元のカード登録時や支払い時に、別途本人認証が必要になる場合があると説明されています。カード情報だけでなく、楽天ID、端末、支払い元の設定を一緒に守る構造です。

不正利用時の補償についても公開されています。第三者が不正に利用し、楽天ペイの利用者が被害にあった場合、その損害を補償すると説明されています。ただし、補償には申告期限や除外条件があります。家族や同居人による利用、虚偽申告、利用者側の重大な過失などは補償対象外になる場合があるため、規約の確認が必要です。

9. d払い

d払いは、dアカウントを使って街やネットで支払えるサービスです。ドコモ回線を持っていない人でも、dアカウントがあれば利用できます。

d払いの公式ページでは、24時間365日の不正モニタリング、不正利用被害の補償制度、本人確認の実施が説明されています。不正の疑いがあるとドコモが判断したアカウントには、d払いなどの利用停止やdアカウントの利用停止を実施するとされています。

クレジットカードを使う場合は、3Dセキュアも重要です。d払いのヘルプでは、d払いの決済時やドコモの料金支払い方法としてクレジットカードを設定する際、カード情報の入力に加えて3Dセキュアによる本人認証を加えることで、第三者による不正利用を防止できると説明されています。

d払いは、dアカウントが入口になります。そのため、dアカウントのID、パスワード、2段階認証、利用履歴の確認が安全性に直結します。

10. au PAY

au PAYは、au IDを軸にしたコード支払い、ネット支払い、プリペイドカードなどを含む決済サービスです。

au IDの公式ヘルプでは、au IDでログインする際やauかんたん決済を利用する際に、登録済みの携帯電話やEメールを使って本人確認を行う2段階認証が説明されています。IDとパスワードだけに頼らず、別の確認手段を組み合わせる考え方です。

au PAYでは、補償制度についても案内があります。公式ページでは、au PAY、au PAY プリペイドカードにおける不正利用被害について、利用者が申請し、KDDIが補償対象と判断した場合に補償されると説明されています。ただし、申告時期や利用者側の重大な過失など、補償されないケースもあります。

3Dセキュアについては、au PAYカードやau PAYプリペイドカードなどカード系サービスで説明されています。auの公式FAQでは、クレジットカードをより安全に利用するための仕組みとして3Dセキュアを説明し、auにおける各種支払いにクレジットカードを登録する場合は本人認証サービスによる認証が必須としています。

11. メルペイ

メルペイは、メルカリの売上金やポイント、メルペイ残高、メルカードなどとつながる決済サービスです。カード情報だけを見るより、メルカリアカウント全体の安全性を見るほうが実態に近いサービスです。

メルカリは、安心・安全への取り組みとして、不正出品や不正行為の監視、商品代金を一時的に預かる売買システム、匿名配送、365日24時間のサポートなどを公開しています。2025年5月からは不正利用者の排除と利用者救済の強化を説明しています。また、2025年7月1日からは、条件を満たす取引について全額補償サポートプログラムを開始しています。

メルペイを使う場合、メルカリアカウントにログインできること、スマホを持っていること、支払い方法や残高を扱えることが支払いにつながります。つまり、メルペイの安全性は、カード番号の扱いだけでなく、メルカリアカウント、端末ロック、本人確認、取引履歴の確認とセットで考える必要があります。メルカリがパスキー登録を案内している点も、アカウント保護の文脈では重要です。

12. Stripe Checkout

Stripe Checkoutは、ECサイトやサービス運営者が決済画面を用意するときに使う決済基盤です。ここまで見てきた決済サービスとは少し立場が違い、利用者というより、サイトを作る側に関係します。

決済フォームでよく見るこれがStripeです。LinkはStripeが提供する高速チェックアウト機能の一つです。

Stripeの公式ドキュメントでは、StripeがPCIレベル1のサービスプロバイダーとして毎年認定を受けていることが説明されています。

また、Stripeは3Dセキュアの利用、Stripe Radarによる不正リスク評価、Webhook署名の検証なども提供しています。利用者から見ると「普通のカード入力画面」に見えても、サイト側がStripe CheckoutやElementsを正しく使っていれば、購入先の自社サーバーにカード番号を直接通さない設計にできます。

ただし、決済を外部サービスに委託しても、加盟店側のPCI DSS上の確認、委託先管理、実装責任が完全になくなるわけではありません。PCI SSCの日本語ドキュメントライブラリで公開されているPCI DSSでも、決済環境や決済業務を第三者にアウトソースする事業体は、第三者によってアカウントデータが保護されることに対する責任を負うと説明されています。

ここは重要です。カード番号を入力する画面があるからといって、必ずしも購入先サイトがカード番号を保存しているとは限りません。逆に、見た目だけでは判断できないため、運営者がどの決済基盤をどう実装しているかが大切になります。

13. サービス別に見る守り方の違い

ここまで見てきた内容を、外から確認できる範囲で整理します。

カードを直接入力する決済では、3Dセキュア、PCI DSS、決済代行会社の設計が重要になります。入力先サイトがカード番号をどう扱うかは外から見えにくいため、3Dセキュア対応、利用通知、明細確認を組み合わせて考える必要があります。

Apple PayとGoogleウォレットは、実カード番号をそのまま毎回見せない方向の守り方です。Apple PayはDevice Account Number、Secure Element、端末認証を使い、Googleウォレットは仮想カード番号や端末保護を使います。このタイプは、スマホの画面ロック、Apple AccountやGoogleアカウントの保護、紛失時の停止がとても大切です。

PayPalとAmazon Payは、購入先ごとにカード番号を入力しないで済む方向の守り方です。支払い情報をそれぞれのアカウント側に寄せるため、PayPalアカウントやAmazonアカウントの保護が重要になります。便利な一方で、フィッシングでログイン情報を渡してしまうと被害につながります。

PayPay、楽天ペイ、d払い、au PAY、メルペイは、カード番号だけではなく、アカウント、端末、本人確認、不正検知、補償制度まで含めて見るサービスです。支払い元にカードや銀行口座を設定する場合もあるため、アプリ側の端末認証、利用可能額の設定、利用通知、本人確認の状態が安全性に関係します。

Stripe Checkoutは、利用者が直接選ぶ決済サービスというより、サイト運営者が安全な決済画面を作るための基盤です。サイト側が正しく実装すれば、カード番号を自社サーバーに通さず、決済IDやWebhookイベントをもとに注文処理を進められます。ただし、外部委託によってPCI DSS上の責任が完全になくなるわけではないため、委託先管理や実装確認は残ります。

14. 利用者が普段から意識したいこと

決済サービスの安全性は、サービス側だけでは完結しません。利用者側の設定や行動でも大きく変わります。

スマホの画面ロックは必須です。Apple PayやGoogle Payのようなウォレット型だけでなく、PayPayや楽天ペイ、d払い、au PAY、メルペイでも、スマホを開ける人がそのまま決済アプリを触れる状態は危ないです。

決済アカウントのログイン保護も欠かせません。PayPalならPayPalアカウント、Amazon PayならAmazonアカウント、楽天ペイなら楽天ID、d払いならdアカウント、au PAYならau ID、メルペイならメルカリアカウントが入口になります。ここが取られると、カード番号が直接漏れていなくても支払いに悪用される可能性があります。

3Dセキュアに対応したカードを使うことも大切です。最近は、カード登録時や決済時に本人認証が求められる場面が増えています。ワンタイムパスワードやアプリ承認が面倒に感じることもありますが、カード番号だけで支払いが通る状態よりは安全です。

利用通知もちょっと鬱陶しいかもしれませんが、あると安心です。決済サービスやカード会社の通知をオンにしておくと、覚えのない支払いに早く気づけます。不正利用の補償制度は、多くの場合、申告期限や調査条件があります。早く気づくこと自体が防御になります。

そして、最も現実的な危険はフィッシングです。決済サービスを名乗るメールやSMSからログイン情報を入力してしまうと、どれだけ裏側の決済基盤が強くても、アカウントを使われる可能性があります。ログインはメールのリンクからではなく、公式アプリやブックマークから開くほうが安全です。（最近、iCloudの請求に偽装したかなり周到なメールが送られてきました。ドメインもかなりappleのものと似ていたため、危なかったです。なぜか請求額がiCloudの値上げ前の値段だったので、気づけました）

セキュリティ攻撃が巧妙になるにつれて、我々利用者側の認証プロセスが増えたり複雑になったり、正直「なんでこんなことしないといけないんだよ〜」という気持ちにもなりますが、被害を受けないためにはグッと堪えましょう、、。

15. サイトを作る側が意識したいこと

ECサイトやWebサービスを作る側にも、利用者とは別の注意点があります。

利用者にとっては「カード番号を入力する画面」に見えても、サイト側の設計には大きな差があります。もっとも避けたいのは、カード番号を自社サーバーで直接受け取り、自社で保存し、自社で守る構成です。カード情報を扱う責任が一気に重くなります。

現実的には、Stripe Checkout、Stripe Elements、PayPal、Amazon Pay、各種決済代行会社のホスト型画面やトークン型の仕組みを使い、カード番号を自社サーバーに通さない設計を優先します。これにより、カード番号そのものではなく、決済ID、注文ID、WebhookイベントIDなどを扱う形にできます。ただし、外部サービスを使う場合でも、委託先のPCI DSS準拠状況や責任分界点を確認する必要は残ります。

決済完了画面だけを信用しないことも大切です。利用者のブラウザ上では「支払い完了」に見えても、サーバー側ではWebhookやAPIで決済状態を確認し、注文を確定する必要があります。Webhookを受ける場合は、署名検証を行い、偽の通知を受け取って注文を確定しないようにします。

また、3Dセキュアをどの場面で求めるか、不正注文をどう検知するか、チャージバックや返金をどう運用するかも設計に含める必要があります。決済は「支払いボタンを置く」だけではなく、失敗時、不正時、返金時、問い合わせ時まで含めて設計するものです。

おわりに

ここまでお読みいただきありがとうございます。

決済サービスは、どれも同じように見えて、守り方は大きく違います。

Apple PayやGoogleウォレットは、実カード番号の代わりになる情報や端末認証を使って、カード番号の露出を減らす方向です。PayPalやAmazon Payは、購入先ごとにカード番号を入力しないで済む方向です。PayPay、楽天ペイ、d払い、au PAY、メルペイは、決済アカウント、端末、本人確認、不正検知、補償制度まで含めて見る必要があります。

大切なのは、どのサービスにも万能な安全はないということです。サービス側の仕組みに加えて、スマホの画面ロック、アカウントの保護、3Dセキュア、利用通知、フィッシング対策を組み合わせることで、日常の決済はより安全に近づきます。

普段何気なく押している支払いボタンの裏側には、思った以上に多くの防御層があります。具体的なセキュリティ部分はブラックボックスなのでわかりませんが、何個か種類があるんだ、程度に雑学として楽しんでいただければ幸いです。