你在便利店买完咖啡，双击 iPhone 侧边键，通过面容 ID 验证后，把手机贴近 POS 机的刷卡区域。“滴”的一声，屏幕上出现蓝色勾号，提示支付完成。整个过程只要两三秒。
很多人的直觉反应是：银行卡被装进了手机，手机代替了塑料卡片，甚至会以为苹果自己在后台搭了一套类似支付宝、微信支付的独立账户与清算网络。
Apple Pay 没有建立自己的发卡行和收单行，也没有建立一套绕过现有银行卡体系的跨行清算网络。消费者手机里绑定的银行卡，资金依然存放在银行账户中；商户仍通过原有的银行卡收单通道收款；后台的报文路由、跨机构清分与净额清偿，也仍由 Visa、Mastercard 或中国银联等卡组织处理。
在《你刷卡的100元，究竟经过了谁？——一文看懂发卡行、收单行、卡组织和商户》中，我们详细拆解过银行卡“四方模式”的底层骨架：持卡人、商户、发卡行、收单行与居中连接的卡组织。Apple Pay 真正做的事情，是在持卡人与既有银行卡网络之间，重新搭建了一套由硬件安全隔离、生物识别认证和支付标记化驱动的全新交互层。
Apple Pay 改变了支付凭证的生成和核验方式，没有改变底层的账户与清算基础设施。
一、Apple Pay 到底是什么
要理解 Apple Pay 在支付链条中的位置，可以回到它发布时的选择。2014 年 9 月，苹果正式发布 Apple Pay。当时可以从零搭建一套钱包和账户系统，也可以让智能设备接入既有的银行卡网络。苹果选择了后者。[1]
Apple Pay 上线时便与美国运通（American Express）、万事达卡（Mastercard）、维萨（Visa）以及多家大型商业银行合作。2015 年底，苹果宣布与中国银联达成合作，次年通过银联云闪付（QuickPass）网络进入中国市场，使用银联已铺设的线下非接触式受理终端。[2]
要看清 Apple Pay 的边界，可以区分三个常被混淆的概念：
| 概念 | 核心定位 | 解决的问题 |
|---|---|---|
| Apple 钱包（Apple Wallet） | 本地数字凭证容器 | 在操作系统层管理银行卡、交通卡、门禁卡、登机牌等凭据 |
| Apple Pay | 移动支付技术服务 | 调用硬件安全模块与生物识别，为既有银行卡发起交易请求与动态认证 |
| 银行卡账户（Bank Account） | 底层金融账户与资金来源 | 银行提供活期存款或信贷额度，并承担合规与最终清偿责任 |
在实际分工中：
- Apple Wallet 只是一个本地软件容器，保管各类数字凭据；
- Apple Pay 是一项支付技术服务，负责在用户使用这些凭据时，调度底层硬件发起支付；
- 真正提供资金、承担信用风险与监管责任的，自始至终是商业银行；
- 连接发卡端与收单端、处理报文交换与轧差清算的，依然是卡组织。
Apple Pay 将银行卡凭证配置到手机的安全硬件中，并接入既有卡组织网络；它没有建立新的 Visa 或银联。在 Luminale 的支付基础设施分析框架下，下图展示了 Apple Pay 与传统银行卡四方模式各组成部分的关系：
二、把银行卡加入 Apple Pay 时，到底发生了什么？
有些用户会以为，在 iPhone 上扫描银行卡或手动输入卡号，就是把卡片信息复制到了手机里。
实际上，后台会完成卡片配置（Card Provisioning）与支付标记化（Payment Tokenization）。[3]
消费者输入卡号与卡片信息（主账号 PAN）
↓
Apple Pay 发起标记化配置申请（Token Provisioning）
↓
发卡行与卡组织标记服务机构（Token Service Provider, TSP）
↓
风控核验与开通资格审批
↓
生成设备账号（Device Account Number, DAN）并配置密钥
↓
通过端到端加密通道下发
↓
安全芯片（Secure Element）硬件隔离存储1. 从主账号（PAN）到支付标记（Payment Token）
在传统塑料银行卡时代，刷卡交易的核心要素是印在卡面上的主账号（Primary Account Number, PAN）。无论是在超市刷卡、在餐厅将卡片交给服务员，还是在电商网站输入卡号、有效期和卡片验证码（Card Verification Value, CVV），原始卡号都在整个交易链条中直接暴露。一旦某个商户的数据库被攻击，或者刷卡终端被安装了侧录设备，真实的卡号就会外泄。
国际芯片卡标准化组织（EMVCo）制定了支付标记化（Payment Tokenization）技术规范，用来降低这类风险。[4]
支付标记化是指用一串与原卡号结构相似、长度相近的替代值（Payment Token）来取代原始 PAN。这串 Token 可以被限定在极其严格的使用边界内：
- 限定设备：仅允许在特定的安全芯片中发起调用；
- 限定渠道：仅限线下非接触式终端（NFC），或者仅限特定 App / 网页环境；
- 限定商户：部分场景下仅能向特定商户发起支付。
离开限定的设备或场景，这串 Token 便无法完成交易，即便外泄也失去了流通价值。
2. 设备账号（Device Account Number, DAN）
在 Apple Pay 语境中，存放在设备内部的支付标记通常被称为设备账号（Device Account Number, DAN）。
它相当于银行卡在这台苹果设备上的数字化替身。如果你将同一张招商银行信用卡分别绑定到自己的 iPhone 和 Apple Watch 上，两台设备并不会共享同一个 DAN。发卡行与卡组织会分别为 iPhone 和 Apple Watch 的安全芯片各自生成一个完全独立的 DAN 与专用密钥。如果你不慎丢失了 Apple Watch，通过“查找”功能将手表上的凭证挂失注销即可，iPhone 上的 Apple Pay 依然可以正常使用，甚至连你钱包里的实体塑料信用卡都不需要去银行挂失换卡。
3. Token 是谁生成并管理的？
一种常见的误解是，苹果生成 Token，并把卡号加密后保存在自己的服务器里。
苹果公司的服务器不存储真实银行卡卡号，也不负责生成支付标记。
真正拥有标记生成、映射管理和状态维护权限的，是发卡银行以及卡组织授权的标记服务提供商（Token Service Provider, TSP）。例如维萨的 Visa Token Service（VTS）、万事达卡的 Mastercard Digital Enablement Service（MDES），以及中国银联的标记服务平台。
在这个体系中，苹果是标记申请者（Token Requestor）：
| 机构角色 | 具体实体 | 核心职责 |
|---|---|---|
| Token Requestor | Apple Pay / 设备侧 | 采集用户意图，代表持卡人向网络发起标记开通申请 |
| Token Service Provider (TSP) | 维萨 / 万事达卡 / 银联 / 发卡行平台 | 负责生成 Token、建立 Token 与真实 PAN 的映射关系数据库（Token Vault） |
| Token Vault | 标记保管库 | 高度安全的后台核心数据库，存储所有 Token、真实 PAN 与设备绑定关系 |
| Issuer | 发卡银行 | 执行最终风控决策，决定是否批准向该设备签发凭证 |
当你在 iPhone 上点击添加银行卡时，苹果将卡片信息加密打包后发送给发卡银行或卡组织。发卡行在确认持卡人身份合法、完成短信动态码或银行 App 认证后，通知 TSP 生成设备账号（DAN）。
随后，TSP 将这个 DAN 以及对应的公私钥、密钥衍生参数直接通过端到端加密通道下发至 iPhone，由手机底层的安全芯片进行解密并写入硬件。整个下发过程中，苹果无法获知 DAN 的底层明文映射，更无法接触到核心密钥。
4. 安全芯片（Secure Element）筑起的物理防线
生成的 DAN 和生成交易密文所需的密钥，最终会被写入终端设备专用的安全芯片（Secure Element, SE）。
安全芯片是一枚符合金融级安全认证标准的独立防篡改微控制器，拥有独立的运算核心、安全内存与加密存储空间。它在硬件上与运行 iOS 系统的应用处理器（Application Processor）隔离。[5]
这意味着，即便恶意软件攻破了 iOS 操作系统，甚至获取了系统最高权限，它也无法直接读取安全芯片内部受保护的密钥与凭证数据。在线下刷卡场景中，POS 机发起的近场通信（Near Field Communication, NFC）射频信号，是通过专门的硬件通路直接连接到安全芯片，无需绕经 iOS 主系统。
三、一笔 Apple Pay 交易到底怎么走？
用户手持 iPhone 在收银台完成一次非接触式支付时，交易会在几秒内经历几个阶段。
第一阶段：本地设备的用户认证
用户双击 iPhone 侧边键，系统调起面容 ID（Face ID）或触控 ID（Touch ID）。
生物识别数据本身不是银行卡支付报文的一部分。面容数据不会传给 POS 机、收单机构或银行。
生物识别的本质是本地授权门禁：
- 用户的面部特征由隔离开的安全隔区（Secure Enclave）完成比对；
- 比对通过后，Secure Enclave 向安全芯片发出一条受硬件保护的确认信号；
- 安全芯片接收到信号后，解除对对应设备账号（DAN）的锁定，允许它对外响应 NFC 射频交互，时限通常仅有几十秒。
通过本地认证，设备确认当前使用者已获授权。
第二阶段：设备生成单次有效的动态交易凭证
当手机靠近 POS 终端，安全芯片与终端完成 NFC 通信握手。
此时安全芯片并不会简单地把设备账号交出去，而是会动态生成两项关键要素：
- 设备账号（Device Account Number, DAN）：替代真实卡号的基础标记；
- 动态交易密文（Payment Cryptogram）：利用安全芯片内存储的交易计数器（Transaction Counter）、专属衍生密钥，结合终端传过来的交易随机数、金额及商户代码，经过特定加密算法计算出的一次性交易密文。
在传统磁条卡时代，卡片背面的磁条记录着静态卡号和静态验证码，只要被复制就可以反复盗刷。即使是传统芯片卡，很多时候也仅靠卡面信息进行基础交互。
而在 Apple Pay 体系中，支付凭证变成了：
由于动态密文是一次性有效的，即便有人使用无线监听设备在空中截获了本次 NFC 交互的全部数据包，也无法将这组数据用于下一笔交易，因为交易计数器已经自增，旧的密文会被发卡行和卡组织判定为非法重放而直接拦截。
第三阶段：重返传统银行卡四方网络
POS 机读取 DAN 和动态密文后，交易进入既有的银行卡四方流程，不再经过苹果设备服务。
iPhone / 安全芯片 (SE)
↓ (NFC 交互: 传递 DAN 与 Cryptogram)
商户 POS 终端
↓
商户收单机构（Acquirer / PSP）
↓
卡组织网络与标记服务机构（Card Scheme & TSP）
↓ (验证 Cryptogram，从 Token Vault 检索映射关系)
发卡银行（Issuer）
↓ (风控核验、额度检查、扣减活期存款/可用信用额度，返回授权响应)
授权结果沿原路返回 POS 终端显示成功这其中有一个至关重要的技术细节：在整个交易链条中，到底由谁在何时还原真实卡号？
一种常见的误解是，POS 机收到标记后会联系苹果，由苹果解密出真实卡号再发送给银行。
实际上，苹果完全不参与线下刷卡交易的实时报文处理。整个过程遵循 EMVCo 的标记化报文规范：
- 收单行视角：POS 机将设备账号（DAN）和动态交易密文打包在标准的金融交易报文（如 ISO 8583 标准）中，发送给商户的收单机构。收单机构看到的完全是一个格式合法的标准卡号，正常进行前置风险检查并向对应卡组织交换中心路由；
- 卡组织与 TSP 视角：报文到达卡组织（Visa、Mastercard 或银联）后，卡组织识别出该卡号属于一个已登记的标记区间（Token BIN Range）。卡组织系统随即与 TSP（通常是其内部的标记管理平台）联动，首先对动态密文进行解密与防重放验签；验签通过后，在标记保管库（Token Vault）中检索该 DAN 对应的底层真实卡号（PAN）；
- 发卡行授权视角：卡组织将真实卡号或带有标记属性的授权请求报文转达给发卡银行。发卡银行核查账户状态、可用余额或信贷额度。确认无误后，发卡行扣减可用余额，生成授权批准码（Approval Code），沿着来时的网络链路原路返回；
- 终端提示成功：POS 收到收单行传回的批准指令，打印凭条或在屏幕上显示扣款成功。
在这个流程中，信息流（授权报文）会在几秒钟内经过收单行、卡组织和发卡行；资金流（清偿与结算）此时还没有发生。
在随后的日终或营业周期结束时，收单行汇总全天的交易数据向卡组织提交批处理清算文件。卡组织在日终对各成员机构进行双向净额轧差计算（Multilateral Net Settlement），得出每一家发卡行和收单行的净应收或净应付金额，并最终通过中央银行的清算账户（如央行大额实时支付系统，在我国为中国人民银行大额支付系统 HVPS）进行中央银行准备金账户之间的最终清偿，收单行随后将款项结算到商户的结算账户中。
在整个清算与结算过程中，Apple 公司既没有持有交易资金，也没有参与准备金划转，更没有在中央银行开立清算账户。
第四阶段：Apple Pay 交易结果与记录查询
不少用户在完成支付后会发现，iPhone 屏幕立刻弹出银行扣款通知，打开 Apple 钱包也可以查看交易金额与商户。但线下 POS 没有连接苹果的服务器，手机是怎么知道交易结果的？
钱包显示交易状态，依托两套并行的信息流机制：
机制 A（离线即时性）：POS 终端 ──(NFC 响应)──> 安全芯片 (SE 本地更新日志) ──> 钱包呈现初始状态
机制 B（在线最终性）：发卡行/卡组织 ──(后台入账)──> Apple 推送服务 (APNs) ──> 钱包呈现完整对账数据- 终端回执与安全芯片本地日志（即时感知）：
在线下 NFC 交互的最后一步，POS 终端在得到收单行授权确认后，会通过 NFC 向手机安全芯片返回一条执行结果报文。安全芯片内部维护着一个受硬件保护的轻量级交易日志计数器，记录着最近几笔交易的终端随机数、简要时间与状态。iOS 系统的 PassKit 框架通过专用硬件接口读取这层受限的本地日志，从而在屏幕上即时打出蓝色对勾，并记录一笔本地初始交易。[5]
- 银行与卡组织的异步推送通知（最终同步）：
本地日志获取的信息非常有限，甚至可能无法包含商户的完整中文名称。真正完整的交易流水，是由发卡银行或卡组织系统在完成授权记账后，向苹果推送通知服务（Apple Push Notification service, APNs）派发一条加密的静默更新消息。[6]
用户的 iPhone 接收到推送指令后，钱包应用在后台向发卡行或卡组织的数据接口请求增量对账详情，拉取官方记账金额、商户清晰名称、消费类别乃至地理位置信息，最终将初步的本地日志刷新为权威交易记录。这种机制既保障了断网或弱网环境下刷卡反馈的毫秒级响应，又确保了后续账单信息的准确性。
电商平台 App 如何拉起 Apple Pay 的？
除了在线下收银台使用 POS 机，用户在京东、淘宝、拼多多等电商平台购物时，也可以在结账页面调起 Apple Pay。
线上 App 支付以系统支付请求替代了线下 NFC 交互，后续处理仍使用银行卡四方清算网络：
电商 App (京东/拼多多/淘宝)
↓ (1. 创建 PKPaymentRequest，调起 Apple Pay 弹窗)
用户使用 Face ID 完成设备生物认证
↓ (2. 安全芯片生成 DAN 与动态密文 Cryptogram)
Apple Pay 支付服务器
↓ (3. 使用商户/收单机构的支付处理公钥证书重加密，生成 PKPaymentToken)
电商商户后台服务器
↓ (4. 密文直接透传，商户端不可解密真实卡号)
商户收单机构 / 支付网关（Acquirer / PSP，如银联在线、网联渠道）
↓ (5. 使用对应私钥解密，恢复出 DAN 与 Cryptogram，打包成标准网络报文)
卡组织网络与发卡银行（重返四方模式授权与清算链条）在线上电商场景中：
- 替代了什么：它替代了线下 POS 机与手机之间的物理 NFC 射频感应环节。原本由物理机具采集的信息，改由电商 App 调用 iOS 系统的
PassKit框架，构建一个包含商户标识符（Merchant Identifier）、交易总金额、币种及商品描述的PKPaymentRequest支付请求对象直接唤起支付面板。[7] - 复用了什么：它完整复用了安全芯片的硬件隔离认证、设备账号（DAN）体系以及动态密文计算。安全芯片同样会在本地计算出一组专为该商户、该金额生成的动态 Cryptogram。
- 线上支付数据的公钥加密：在线上环境中，为了防止恶意 App 窃听或中间人攻击，安全芯片生成的支付数据并不会直接交给电商平台。Apple Pay 服务器会调取商户在苹果开发者后台预先登记的支付处理证书公钥（Payment Processing Certificate Public Key），将设备账号、动态密文及交易流水打包加密成一个加密数据包（
PKPaymentToken）。[7]
京东或拼多多的 App 拿到这个 Token 后，自身及服务器端没有任何私钥可以解密它，只能原封不动地将其透传给背后的收单机构（如中国银联或合作商业银行收单网关）。收单机构使用妥善保管在硬件安全模块（HSM）中的配对私钥进行解密，提取出 DAN 与 Cryptogram，随后同样按照经典的银行卡网络规则发送至卡组织和发卡行请求授权。
通过这套流程，线上商户可以使用与线下刷卡相同的支付标记和动态密文机制。消费者也无需在手机电商中反复输入 16 位银行卡号、短信验证码和卡背 CVV。
四、Apple Pay 的商业模式是什么？
如果底层网络依然是发卡行、卡组织和收单行，那么苹果为什么要做 Apple Pay？银行和商户又为什么愿意接入？
Apple Pay 能在多个市场推广，在于它复用了原有四方模式的基础设施并且融入了原有的四方模式，原有的参与主体没有增加额外的改造成本，并且原有的收费和分润机制也并没有打破。
1. 对消费者：没有新增收费，降低凭证泄露风险
苹果官方对普通消费者实行免手续费政策，用户在商店、App 或网页端使用 Apple Pay 无需向苹果支付额外费用。
消费者获得的收益非常直接：
- 便利性：摆脱了携带实体钱包和多张塑料卡的负担；
- 防盗刷安全性：不再需要将卡片交予他人，商户无法获取真实卡号和三位 CVV 码；
- 线上支付提效：在电商网站或移动应用中一键支付，省去了反复手动输入姓名、地址和16位卡号的繁琐体验。
2. 对商户：零改造负担，平滑复用既有收单体系
商户接入 Apple Pay 后，仍可使用既有的财务和对账系统。
苹果不向商户开立收款结算账户，也不向商户收取专门的“Apple Pay 交易服务费”。商户依然按照原有的商户收单协议，向自己的收单机构或支付服务提供商（Payment Service Provider, PSP）支付正常的银行卡刷卡手续费（Merchant Discount Rate, MDR）。任何支持非接触式 IC 卡（如银联 QuickPass、Visa payWave、Mastercard PayPass）的标准 POS 终端，都天然兼容 Apple Pay。商户无需为单一手机品牌单独投资更换收单设施。
3. 对发卡银行：多一个前端入口，但仍保留客户关系
在智能手机兴起之初，商业银行担心大型科技公司自建钱包后，客户会更多通过科技公司的服务使用支付，银行与客户之间的直接联系因此减弱。
而 Apple Pay 的接入方案为银行保留了底线：
- 保留金融资产与核心关系：客户依然是银行的储蓄和信用卡客户，资金留在银行体系内部；
- 保留信贷与利息收益：信用卡的分期收入、循环利息和违约金依然归发卡行所有；
- 降低伪冒欺诈损失：因为引入了动态 Cryptogram 和生物识别设备认证，由失窃卡、伪造卡导致的欺诈交易发生率明显降低，直接减轻了发卡行的风险拨备压力。
银行让出了用户发起支付时的手机界面入口，同时让银行卡继续用于移动支付。
4. Apple 的商业考量与平台定位
Apple Pay 也服务于苹果的硬件业务。通过在 iPhone 和 Apple Watch 上提供支付功能，苹果增加了设备的日常使用场景，并有助于维持用户对其硬件和服务的持续使用。
关于苹果在 Apple Pay 交易中的直接收益和分润安排，目前并没有明确披露的文件可供查阅。但是 2024 年 3 月，美国司法部在针对苹果公司发起的反垄断诉讼中指出，在美国市场，苹果与发卡银行达成协议，针对通过 Apple Pay 发生的信用卡交易，向发卡机构收取约 15 个基点（即 0.15%）的费用；对于借记卡交易，收取每笔 0.5 美分的固定费用。[8]
需要澄清的是，这是美国司法部诉状中所列举的特定市场商业安排，并不代表苹果在全球所有国家和地区均采用统一比例收费。在欧洲、中国，发卡行佣金体系有着完全不同的协商条款。
对苹果来说，Apple Pay 的价值也体现在硬件、操作系统、安全芯片和生物识别功能与支付服务的结合上。
传统银行卡交易路径：
持卡人 ── 实体塑料卡 ── POS 机 ── 收单行 ── 卡组织 ── 发卡行
移动智能时代交易路径：
持卡人 ── 操作系统与设备交互层 ── 支付标记与安全芯片 ── POS 机 ── 收单行 ── 卡组织 ── 发卡行
↑
(Apple 占据的新生态位)苹果没有成为发卡银行，也没有掌控中央结算账户，但 Apple Pay 将支付入口放在了苹果设备和操作系统中。
五、从 Apple Pay 到 Apple Cash、Apple Card：不同定位的产品
消费者有时会把 Apple Pay、Apple Cash 和 Apple Card 混为一谈，也可能会问：如果 Apple Pay 只是支付服务，苹果为什么还提供余额和信用卡产品？
这三个产品对应金融服务的不同环节：
| 产品名称 | 产品本质 | 资金与账户所有者 | 主要服务场景 |
|---|---|---|---|
| Apple 钱包 (Apple Wallet) | 操作系统级凭证容器 | 本地存储，不涉及资金 | 存放借记卡、信用卡、交通卡、证件等 |
| Apple Pay | 移动支付标记化服务 | 映射绑定的外部银行账户 | 线上线下替代实体卡完成交易 |
| Apple Cash | 储值余额与 P2P 转账账户 | 格林多特银行（Green Dot Bank） | 美国用户个人之间小额转账、零钱存储 |
| Apple Card | 无实体卡优先的信用卡产品 | 高盛银行（Goldman Sachs）/ 摩根大通（Chase） | 消费信贷、透支与分期偿还 |
1. Apple Pay：无余额的支付通道
Apple Pay 本身不存在资金账户。如果你在 Apple Pay 中绑定了一张中国工商银行的借记卡，你无法把 1000 元“存进 Apple Pay”。当你消费时，资金是实时从工商银行的借记卡活期存款账户中支取。
2. Apple Cash：被存款保险保障的钱包
Apple Cash（前身为 Apple Pay Cash）则真正引入了“余额”概念。用户可以通过 iMessage 在朋友之间互相转账，收到的资金会存留在 Apple Cash 账户中，形成数字余额。
但苹果并没有因此成为吸纳公众存款的金融机构。苹果官方服务协议明确披露，Apple Cash 的账户和借记功能是由美国格林多特银行（Green Dot Bank）提供，受联邦存款保险公司（FDIC）承保；苹果旗下的 Apple Payments Services LLC 仅作为技术与信息撮合服务商提供界面接入。[9]
收到的 Apple Cash 余额可以转回个人的商业银行账户，也可以直接作为一张虚拟借记卡，通过 Apple Pay 在日常商户中刷卡消费。
3. Apple Card：商业银行信用卡
Apple Card 将苹果的业务延伸到消费信贷领域，但苹果并不承担这张卡的发卡行资产负债表风险。
Apple Card 是一张真正的信用卡，支持透支消费、按月还款和计息分期。自 2019 年上线以来，其实际发卡机构一直为高盛商业银行（Goldman Sachs Bank USA），底层支付清算网络则为万事达卡（Mastercard）。苹果主要负责前端产品交互、钱包界面设计、每日返现（Daily Cash）计算以及系统集成。
2026 年 1 月，苹果宣布与摩根大通（JPMorgan Chase）达成合作，由摩根大通接替高盛成为 Apple Card 的新发卡行，预计过渡期约为 24 个月；这期间万事达卡继续担任底层支付网络。[10]
这组产品的分工可以概括为：
Apple Card (信用额度与消费透支)
↓ 消费获得 Daily Cash
Apple Cash (数字余额零钱罐)
↓ 作为支付凭证调用
Apple Pay (无接触支付技术能力)
↓ 统一界面呈现
Apple Wallet (手机系统级容器)用户使用 Apple Card 消费，获得 1% 至 3% 的返现（Daily Cash）；返现金额自动转入由格林多特银行托管的 Apple Cash 余额账户；用户在日常消费时，又可以通过 Apple Pay 调用 Apple Cash 余额或 Apple Card 信用额度完成交易。
这些产品在 Apple 钱包中可以连贯使用，但账户、发卡和清算仍由传统商业银行（高盛、摩根大通、格林多特）及卡组织（万事达卡）承担相应的风险、合规与资金清算职责。
苹果没有替代金融基础设施，而是通过设备和软件提供面向消费者的操作界面。
结语：在既有网络上改进支付体验
回顾 Apple Pay 面世以来的发展历程，很多人最初的感受只是“出门不用再带钱包了”。
从支付基础设施的角度看，Apple Pay 展示了一种改进支付体验的方式：改变消费者使用支付工具的方式，不一定要重建原有的银行账户、卡组织报文网络和跨行清算体系。
金融交易依赖信用、风险管理和资金最终清偿。商业银行与中央银行参与的清算体系已运行多年，提供信用、流动性支持和大额结算服务，并受法律规则约束。如果绕开既有网络另建体系，还需要处理监管和合规要求，并推动商户部署新的收单设备。
Apple Pay 沿用既有金融基础设施，并在银行卡四方模式之上加入支付标记化（Tokenization）、安全芯片（Secure Element）和单次有效的动态交易密文（Cryptogram）。在收银台使用 iPhone 支付时，传给 POS 机的是支付标记和动态交易密文，而不是印在塑料卡上的原始卡号。银行卡网络仍按原有流程处理交易，消费者则通过手机完成认证和支付。
这也给我们带来一个值得关注的启示：在一个已经高度成熟的零售支付市场中，真正有价值的支付创新，往往并不是脱离现有体系、重新搭建一套全新的支付网络，而是在充分理解既有金融基础设施、清算结算机制和商业模式的基础上，尽可能复用现有能力，围绕尚未被充分满足的用户需求，对支付体验、连接方式和服务边界进行重新设计。
换句话说，支付创新很多时候不是“重建基础设施”，而是“重新组合基础设施”。谁能够更好地理解现有体系的运行逻辑，并找到技术能力、商业模式与真实用户需求之间的结合点，谁就更有可能创造出能够真正落地并形成规模的支付产品。
参考资料
[1]: Apple Inc. Apple Announces Apple Pay. Apple Newsroom, September 9, 2014. https://www.apple.com/sg/newsroom/2014/09/09Apple-Announces-Apple-Pay/ ↩
[2]: Apple Inc. Apple & China UnionPay to Bring Apple Pay to China. Apple Newsroom, December 18, 2015. https://www.apple.com/newsroom/2015/12/18Apple-China-UnionPay-to-Bring-Apple-Pay-to-China/ ↩
[3]: Apple Inc. Apple Platform Security: Apple Pay overview & card provisioning. Apple Support Guide, 2024. https://support.apple.com/guide/security/sec0f005981a/web ↩
[4]: EMVCo. Payment Tokenisation Specification: Technical Framework. EMVCo Official Specifications, 2021. https://www.emvco.com/emv-technologies/payment-tokenisation/ ↩
[5]: Apple Inc. Apple Platform Security: Secure Element. Apple Support Guide, 2024. https://support.apple.com/guide/security/seccb53a35f0/web ↩
[6]: Apple Inc. Apple Support: View your account balance and transaction history in the Wallet app. Apple Support, 2024. https://support.apple.com/en-us/111117 ↩
[7]: Apple Developer Documentation. Payment Token Format Reference & About Apple Pay. Apple Developer, 2024. https://developer.apple.com/documentation/PassKit/payment-token-format-reference ↩
[8]: U.S. Department of Justice. Justice Department Sues Apple for Monopolizing Smartphone Markets. Office of Public Affairs, March 21, 2024. https://www.justice.gov/opa/pr/justice-department-sues-apple-monopolizing-smartphone-markets ↩
[9]: Apple Inc. Apple Cash Terms and Conditions. Apple Support, 2024. https://support.apple.com/apple-cash ↩
[10]: Apple Inc. Chase to become the new issuer of Apple Card. Apple Newsroom, January 13, 2026. https://www.apple.com/newsroom/2026/01/chase-to-become-new-issuer-of-apple-card/ ↩
本文首发于 Luminale 金融科技观察：https://luminale.cn/articles/what-happens-behind-apple-pay-payment-token-clearing