カードを再発行してもサブスクが続くのはなぜ?Stored Credentialとカードオンファイルの仕組み

スマートフォンでオンライン決済を行う人とクレジットカード 決済・クレジットカード統計データ

最終確認:2026年9月21日

カードの有効期限が切れたり、紛失で再発行したりしたのに、登録していたサブスクリプションの支払いがそのまま続くことがあります。

「新しいカード番号を入力していないのに、なぜ決済できるのか」。

答えは、加盟店が古いカード番号を勝手に推測しているからではありません。カード業界には、Stored Credential(保存済み決済情報)、Account Updater、そしてPayment Tokenという、継続的なオンライン決済を支える仕組みがあります。

ただし、すべての加盟店・カード・取引で自動更新されるわけではありません。発行会社、加盟店、アクワイアラ、ネットワークなどの参加状況や取引条件によって動作は異なります。

本稿では、Amazonの1-Clickのような「一度登録した情報を次回も使う」という発想が、カードネットワークのルールとしてどのように整理され、再発行・サブスク・アプリ決済・ホテルの追加請求まで支えるようになったのかを一次資料からたどります。

図1 カードを再発行しても登録済み決済が続くことがある理由

カード会員
カードが更新・再発行される
↓
発行会社
新しいアカウント情報やトークンのライフサイクルを管理
↓
Account Updater
参加する加盟店・アクワイアラへ更新情報を連携
Payment Token
元のPANが変わってもトークン側のライフサイクルを更新できる場合がある
↓
登録済みの継続決済
条件が整えば、利用者が新番号を再入力しなくても処理を継続できる

重要:自動更新は万能ではありません。サービスへの参加、発行会社・加盟店の設定、カードの状態、取引種別などで結果は変わります。

「保存したカード」は、単にカード番号をメモしているだけではない

Visaが2017年に公開したStored Credential Transaction Frameworkでは、Stored Credentialを、加盟店やその代理人、Payment Facilitator、一定のデジタルウォレット事業者などが将来の取引を処理するために保存する決済情報と定義しています。そこにはカード番号だけでなく、payment tokenも含まれます。

Mastercardの現行Transaction Processing Rulesでも、カード会員が加盟店に対し、将来の取引に使うためアカウント情報を保存することを明示的に認め、その後その保存情報を使って取引するCredential-on-Fileのルールが定められています。

つまり、画面上では同じ「登録済みカード」に見えても、裏側ではPAN(カード番号)そのものを扱う場合もあれば、トークン化された別の識別子を使う場合もあります。

出発点は「次回、もう一度入力させない」だった

オンライン決済の歴史を見ると、「一度入力した決済情報を次回も使いたい」という要求は早い時期からありました。

1997年にAmazonが発表した1-Click orderingは、購入者の情報を保存し、再訪時に注文情報を毎回入力する手間を減らすものでした。1-Clickの特許とBarnes & Nobleとの訴訟については、「なぜ『1クリック』で買えるようになったのか?」で詳しく整理しています。

しかし、EC、アプリ、サブスクリプション、配車、デジタルサービスが広がると、単に「保存する」だけでは足りなくなります。

同じ保存済みカードを使った決済でも、利用者本人がその瞬間に「買う」と押した取引と、利用者がその場にいない状態で加盟店が契約に基づいて請求する取引では意味が違うからです。

2016〜2017年、VisaはStored Credentialを世界共通の分類へ整理した

Visaの2017年ガイドは、その背景を明確に説明しています。デジタルコマースの成長と新しいビジネスモデルの登場により、カード会員の同意に基づいて保存済み決済情報を使う取引がsignificant levelsまで増えたため、取引を明確に識別する必要が生じたとしています。

Visaは2016年10月からStored Credentialに関する既存ルールを拡張し、2017年10月14日のVisaNet Business Enhancements Releaseから、開示・同意と適切な取引識別子の利用を世界的に必須としました。

加盟店などには、主に次のことが求められました。

  • 決済情報をどのように使うかをカード会員へ開示する
  • 保存することについてカード会員の同意を得る
  • 利用条件が変わった場合に通知する
  • 決済情報を保存することを取引メッセージで発行会社側へ知らせる
  • 保存済み情報を使う取引を適切なindicatorで識別する

そしてStored Credentialを使う取引では、POS Entry Mode Codeに「10」を使う仕組みが導入されました。

この変更のポイントは、単なる事務ルールではありません。発行会社から見ると、同じカード番号を使ったオンライン取引でも、「誰が、どの関係性に基づいて、この請求を始めたのか」が分かるようになるからです。

CITとMIT――同じ保存済みカードでも、取引の意味は違う

Stored Credentialの世界を理解するうえで重要なのが、CIT(Cardholder-Initiated Transaction)とMIT(Merchant-Initiated Transaction)の違いです。

図2 保存済みカードで払う=すべて同じ取引、ではない

CIT:カード会員が開始

本人がその時点で取引に能動的に参加。

例:
アプリで配車を注文する
保存済みカードでEC購入する
アプリで鉄道チケットを買う

MIT:加盟店が開始

過去のカード会員との合意・取引関係に基づき、本人がその場にいない状態で加盟店が処理。

例:
定期購読の次回請求
ホテルのチェックアウト後のミニバー請求
no-show charge
自動チャージ

Visaのガイドには、非常に分かりやすい例があります。

配車アプリで利用者自身が「乗る」と操作して、その登録済みカードで支払う取引はCITです。カード番号を再入力しなくても、その瞬間の購買判断には本人が参加しています。

一方、ホテルの宿泊後に判明したミニバー代を追加請求する場合や、雑誌の定期購読の次回料金を請求する場合はMITです。

「カード情報が保存されているか」だけではなく、取引を開始したのが誰なのかが重要なのです。

なぜカード会社はCITとMITを見分けたいのか

発行会社は、届いたオーソリメッセージを基に、その取引を承認するか判断します。

VisaはStored Credentialを明確に識別できるようにするメリットとして、発行会社が取引リスクをより見分けやすくなり、取引ごとに異なる扱いができることを挙げています。その結果として、承認率の改善、売上機会の確保、顧客からの苦情削減などにつながり得ると説明しています。

これは、Otakuwalletで整理しているオーソリの歴史ともつながります。カードネットワークは単に「番号を運ぶ」だけではなく、その取引がどういう文脈で発生したのかという情報も運ぶようになったのです。

しかし、CVVまで保存してよいわけではない

ここで誤解しやすい点があります。

オンラインショップでカードを「保存」できるなら、裏面のCVV/CVCなども保存しているように感じるかもしれません。しかしPCI Security Standards Councilは明確に否定しています。

カード確認コードはSensitive Authentication Data(SAD)であり、その取引の承認後に保存することは禁止されています。暗号化して保存することも不可です。

さらに重要なのは、カード会員自身が「保存してよい」と同意しても、この禁止を上書きできないことです。

したがってStored Credentialや定期課金は、CVVを毎回保存して使い回す仕組みではありません。保存してよい情報と、保存してはいけない認証情報を分けることで成り立っています。

2014年、カード番号そのものを保存しない方向へ――Payment Token

便利さを保ちながら、加盟店に本物のカード番号を持たせるリスクを下げる。その答えの一つがPayment Tokenisationです。PANからApple Pay、Network Tokenへ至る標準化と主導権争いの歴史は、「なぜカード番号そのものを使わなくなっているのか?」で詳しく整理しています。

2014年9月9日、VisaはVisa Token Service(VTS)の開始を発表しました。同じ日、Apple Payを新しいiPhone 6、iPhone 6 Plus、Apple Watchで支えることも発表しています。

Visaの当時の発表によると、この立ち上げには世界で750人以上のVisaスタッフが関与しました。

仕組みは、16桁のPANをそのままデジタル環境に置くのではなく、代わりとなるtokenを使うものです。tokenは、特定の加盟店、デバイス、利用シナリオなどに用途を制限できます。

翌2015年、Visaはこのtoken技術をVisa Checkoutだけでなく、cards-on-fileにも広げると発表しました。月額サブスクリプションや継続請求で加盟店が保存していたカード番号を、ネットワークtokenへ置き換える方向が明確になります。

2026年現在、Tokenisationは業界標準のインフラになっている

EMVCoは現在、EMV Payment Tokenisationを、PANを固有の代替値に置き換え、盗まれた決済情報の価値や利用範囲を制限する技術として定義しています。

2026年7月9日にはEMV Payment Tokenisation Specification – Technical Framework v2.4が公開されています。

EMV Payment Tokenは、特定の加盟店・デバイス・支払シナリオに利用範囲を制限できます。仮にtokenが漏えいしても、元のPANと同じようにどこでも使えるとは限りません。

さらにtokenは、カードの再発行や更新時に、カード会員が毎回サービスへ新番号を入力し直さなくても継続利用できるよう、ライフサイクル管理と組み合わせることができます。

図3 「保存する決済」は、番号保存からライフサイクル管理へ

1997 Amazon 1-Click
再訪時の入力を減らし、保存済み情報で注文する体験を提示。

↓

2014 Visa Token Service
PANをtokenへ置き換えるネットワークtokenisationを本格展開。Apple Pay開始と同日に発表。

↓

2015 Tokenisationをcards-on-fileへ
サブスク・継続請求などの保存済みカードにもtokenを広げる。

↓

2016〜2017 Stored Credential framework
保存、同意、CIT/MIT、transaction indicatorを世界的に整理。

↓

2026 EMV Payment Tokenisation v2.4
tokenはデジタル決済の標準インフラとして継続進化。

カード再発行後の「新番号を入れ直す手間」も消しにいった

Stored Credentialには、別の摩擦があります。

有効期限切れ、紛失、盗難などでカードが変わるたび、すべてのサブスクや通販サイトに新しいカード情報を登録し直すのは面倒です。加盟店側にとっても、カード情報が古くなれば本来継続するはずの売上がdeclineになります。

Visa Account Updater(VAU)は、参加する発行会社がカード再発行などの更新情報を提供し、参加する加盟店・アクワイアラが保存済みcredentialを更新できる仕組みです。

現在のVisa Developerの説明では、発行会社が新しいPANや有効期限をVAUへ登録し、加盟店側が保存済みcredentialについて照会して、利用可能な更新情報を受け取る流れが示されています。

Payment Tokenの場合も、tokenの裏側にあるcredentialのライフサイクルを更新することで、再登録の摩擦を減らせる場合があります。

これが、「カードを再発行したのに一部のサブスクはそのまま続いた」という現象の背景にある代表的な仕組みです。

便利になるほど「どこにカードを登録したか」が見えにくくなる

摩擦を減らした結果、新しい問題も生まれます。

カードを多数の通販サイト、アプリ、サブスクに登録すると、利用者自身がどこにcredentialを保存しているか分からなくなることがあります。

VisaはCard-On-File Data Inquiryという仕組みを提供しており、対応する発行会社は、自社のオンライン・モバイルチャネルを通じて、カード会員にCOF加盟店の情報を表示できます。

Visaは、消費者がより多くのオンライン加盟店やサービス事業者にカードcredentialを保存する一方、どこに保存されているのか、再発行時にどこを更新すべきかが見えにくいことを、このサービスの背景として説明しています。

決済を「覚えなくてよい」ものにすると、今度は覚えていない決済関係を可視化する技術が必要になるわけです。

Stored Credentialは「見えない決済インフラ」である

利用者から見れば、保存済みカードは単純です。

一度カードを登録する。次回は番号を入力しない。定期課金なら何もしなくても支払いが続く。

しかし、その裏では、

  • カード会員の保存同意
  • CITとMITの識別
  • 取引メッセージ上のindicator
  • CVVを保存しないセキュリティルール
  • Account Updaterによるcredential更新
  • Payment TokenによるPANの置き換え
  • tokenやPANのライフサイクル管理

が組み合わさっています。

前の記事で見たAmazon 1-Clickは、購入者から見える「入力の摩擦」を消しました。その後カードネットワーク側では、その摩擦を消しても安全に・継続的に決済できるようにする見えないルールが整えられていったのです。

一方、不正利用を防ぐため、必要な場面ではEMV 3-Dセキュアなどで本人確認を追加します。詳しくは日本のクレジットカードセキュリティ対策の変遷で整理しています。

カードネットワークの価格と参加者の関係については、加盟店手数料とインターチェンジフィーの歴史も参照してください。

「カード番号を毎回入力しなくてよい」という小さな便利さの裏側には、決済情報を保存し、識別し、更新し、安全に使い続けるための巨大なインフラがあります。

Featured photo: Vitaly Gariev / Unsplash

主な出典

出典 公開日・版 対象・用途 取得日
Visa, “Improving Authorization Management for Transactions with Stored Credentials” 2017年5月10日 Stored Credential定義、CIT/MIT、2016〜2017年ルール変更、同意・indicator、ホテル・定期購読等の事例 2026年9月21日
Mastercard Transaction Processing Rules 2025年6月10日版 Credential-on-Fileの現行定義・取引識別ルール 2026年9月21日
PCI Security Standards Council FAQ 1280 2023年10月 COF・継続課金でCVV等を保存できないこと、カード会員同意でも例外にならないこと 2026年9月21日
Visa, “Visa Launches Innovative Token Service” 2014年9月9日 Visa Token Service開始、tokenの仕組み、750人超の開発体制 2026年9月21日
Visa, “Visa and Apple Opening a New Era of Payments on Mobile Devices” 2014年9月9日 Apple PayとVisa Token Serviceの同時期展開 2026年9月21日
Visa, “Visa Brings Token Security to eCommerce” 2015年10月26日 Visa Checkoutとcards-on-fileへのtokenisation展開 2026年9月21日
EMVCo, “EMV Payment Tokenisation” Technical Framework v2.4:2026年7月9日 PANとPayment Token、利用範囲制限、tokenライフサイクル、現行仕様 2026年9月21日
Visa Developer, “Getting Started with Visa Account Updater” 現行公開ページ カード再発行時のPAN・有効期限更新とCOF加盟店への連携 2026年9月21日
Visa Developer, “Card-On-File Data Inquiry” 現行公開ページ CIT/MITの整理、COF加盟店情報の可視化 2026年9月21日

シリーズ全体:決済の歴史としくみ|カード・EC・タッチ・認証の進化をたどる

関連記事

タイトルとURLをコピーしました