Apple Payの決済は、プラスチックカードに印字された番号をそのまま送る方式ではない。Appleの日本向け説明によると、カード発行元が作る端末固有の番号と取引ごとの動的セキュリティコードが使われ、実際のカード番号は加盟店やアプリへ送られず、Appleのサーバにも保存されない。

ただし、「カード番号が渡らない」と「加盟店が個人情報を受け取らない」は同じ意味ではない。オンライン購入では、配送先やメールアドレスなど注文に必要な情報が加盟店へ渡る。Apple Payの仕組みを読むには、決済用の情報と注文用の情報を分ける必要がある。

スマートフォンのウォレット、クレジットカード、セキュアエレメントを配置した決済トークン化の図（イメージ）
カードをApple Payに追加すると、カード発行元が端末固有の決済番号を作る。（イメージ）

支払いトークン化──カード番号を用途の限られた代替値へ

この設計の土台が、支払いトークン化（Payment Tokenisation）である。ここで置き換える対象は、元のカード番号（Primary Account Number、PAN）だ。決済仕様を管理するEMVCoは、PANを固有の代替値であるEMV決済トークン（EMV Payment Token）へ置き換え、その利用範囲を特定の加盟店、端末、決済場面などに制限する仕組みと説明している。

トークンは、加盟店から加盟店契約会社、決済ネットワークを経てカード発行元の承認へ進む既存の経路で使われる。仮に決済情報が漏れても、元のカード番号より転用しにくくするのが狙いだ。カード発行元による承認や拒否まで置き換える仕組みではなく、トークンだけで支払い成立が保証されるわけでもない。

カード登録から店頭決済まで

登録──利用可否を決めるのはカード発行元

利用者がウォレットにカードを追加すると、入力した情報は暗号化されてAppleへ送られ、決済ネットワーク向けに再暗号化される。発行元はカードと端末の情報を照合し、追加を承認するか判断する。Appleの設定案内は、対応端末、対応カード、Apple Account、Face IDやTouch IDなどの認証設定を利用条件に挙げ、発行元が追加の認証や専用アプリを求める場合があるとしている。

承認後、発行元または正規サービス事業者は、デバイスアカウント番号（Device Account Number）を作る。Appleによると、この番号と動的セキュリティコードを生成する鍵は暗号化され、端末内のセキュアエレメント（Secure Element）に保管される。Appleは番号を復号できず、Appleのサーバへの保存やiCloudへのバックアップも行われない。同じ実カードをApple Watchなど別の端末へ追加する場合も元の端末から情報はコピーされず、登録処理をやり直して端末固有の番号が割り当てられる。

店頭──NFCで端末固有の番号と取引コードを送る

店頭では、近距離無線通信（Near Field Communication、NFC）が端末とPOSをつなぐ。Apple Platform Securityは、NFCコントローラがアプリケーションプロセッサとセキュアエレメントの間、およびセキュアエレメントとPOS端末の間の通信を中継すると説明している。カード情報を保管するセキュアエレメントと、認証を管理するセキュアエンクレーブ（Secure Enclave）は役割が異なる。

支払いは、セキュアエレメントがセキュアエンクレーブから承認を受けた後に進み、利用者は生体認証、端末のパスコード、またはロック解除済みApple Watchのサイドボタン操作で意思を確認する。認証後にPOSへ渡るのは、デバイスアカウント番号、取引固有の動的セキュリティコード、決済に必要な補足情報である。元のカード番号はこの経路に出ない。

スマートフォンを非接触型決済端末にかざし、取引ごとのセキュリティコードを示す画面（イメージ）
NFCが近距離の通信を担い、発行元または決済ネットワークが取引固有のコードを検証する。（イメージ）

アプリとWeb──支払い情報は暗号化、注文情報は別に提供

アプリやWebの決済では、店頭のNFCとは異なる経路を取る。Apple Payは暗号化された取引情報を受け取り、開発者固有の鍵で再暗号化して加盟店または決済代行業者へ渡す。Webサイトにはドメインの検証も要る。ここでも支払い情報の中心はデバイスアカウント番号と取引固有のコードで、実際のカード番号ではない。

Appleのプライバシー通知は、決済承認後に端末または店舗固有のアカウント番号と、加盟店が求めた配送先住所やメールアドレスなどが提供される一方、クレジットカード、デビットカード、プリペイドカードの番号は提供されないとしている。つまり、トークン化が守るのは決済口座の番号であり、注文を履行するための氏名、連絡先、住所まで匿名化する機能ではない。

日本で使う前に確かめる三つの条件

第一はカードだ。Appleは日本の対応銀行・カード発行元を公式一覧で示す一方、掲載された発行元のカードでもApple Payに対応しないものがあるとして、個別の利用可否は発行元への問い合わせを案内している。「銀行が対応している」という情報だけでは、手元のカードが追加できるかまでは決まらない。

第二は端末と決済方式だ。Appleの日本向け案内では、店舗側にEMV非接触型決済などの対応マークがあり、利用するカードと決済ネットワーク、読み取り端末のすべてが対応している必要がある。アプリとWebではApple Payのボタンや支払い方法の表示が目印になる。

第三は認証の例外だ。一部の交通系ICカード、決済カード、パス、キーをエクスプレスモードに設定すると、端末のスリープやロックを解除せず、Face ID、Touch ID、パスコードによる認証も省いて使える。通常の店頭カード決済と同じ認証手順が常に当てはまるわけではない。

日本の店舗のレジでスマートフォンをかざして支払う様子（イメージ）
日本での利用可否は、発行元、カード商品、決済ネットワーク、読み取り端末の組み合わせで決まる。（イメージ）

端末を紛失した時──支払いカードを端末単位で止める

iPhoneやApple Watchを紛失した場合は、「探す」の紛失モード、Apple Accountからのカード削除、またはカード発行元への連絡で、その端末に登録したクレジットカードやデビットカードを止める。Apple Platform Securityによると、利用者が支払いカードを一時停止または削除すると、カード発行元か決済ネットワークがApple Payでの支払い機能を停止または取り消し、紛失端末がオフラインでも処理は有効になる。

同じ実カードを別のApple製端末にも追加している場合、各端末の決済資格情報は別に管理される。紛失した1台を止める操作と、手元に残る端末の状態を混同しないことが重要だ。実カードそのものの停止が必要かは、紛失状況を伝えた上で発行元の判断を仰ぐことになる。

加盟店は支払いトークンと注文データを分けて管理

Appleの開発者向け資料では、アプリやWebサイトが受け取る決済オブジェクトに、端末固有のアカウント番号、金額、1回限りの暗号値を含む暗号化済みトークンが入り、請求先・配送先の連絡先は暗号化済みトークンとは別に扱われる。トークンの復号と決済処理は、加盟店または決済代行業者が担う。

加盟店側の確認事項は三層に分かれる。決済層ではトークンと取引コードを処理できるか、業務層では注文、売上、取消、照合を同じ取引に結び付けられるか、データ管理層では氏名、メールアドレス、住所の保存期間と閲覧権限を定めているかを見る。Apple Payが実カード番号を渡さない設計でも、加盟店のアカウント管理や注文データの保護まで代行するわけではない。

オンライン決済画面と支払いトークン、注文データの管理画面（イメージ）
暗号化された支払いトークンと、注文・連絡先の情報は分けて管理する必要がある。（イメージ）

よくある質問

Apple Payは実際のカード番号を加盟店へ渡すのか
渡さない。店頭、アプリ、Webの決済では、端末固有のアカウント番号と取引固有の動的セキュリティコードが使われる。ただし、オンライン注文では配送先やメールアドレスなど、購入に必要な情報が加盟店へ渡る。

対応銀行のカードなら必ずウォレットへ追加できるのか
必ず追加できるとは限らない。Appleの公式一覧は、掲載された発行元にも対象外のカードがあると明記している。端末のOS、Apple Account、認証設定を確認した上で、個別カードの資格は発行元に問い合わせる必要がある。

iPhoneを紛失したら、Apple Payのクレジットカードはどう止めるのか
「探す」で紛失モードにするか、Apple Accountから対象端末のカードを削除する。カード発行元へ利用停止を依頼する経路もあり、端末がオフラインでもクレジットカードやデビットカードをApple Pay上で停止できる。