以招商银行信用卡为例来描述 Apple Pay 的运行机制：
1.用户向招商银行申请一张银联标准信用卡，并获得批准：
在这一步，招行会：
键入用户的申请资料，对用户进行资产和信用调查（征信）；
批准用户的申请请求，对用户进行授信（颁发信用额度）；
通过申请人档案生成客户档案；
在客户档案下新建一个名叫“个人消费账户”的贷记账户并报告给人行及建立信用记录；
在“个人消费账户”下新建一张银联标准信用卡（生成卡号【主账号、PAN】、有效期、CVN2）；
通知厂家制作这张卡片，邮寄。
2.用户开卡使用。
3.用户用这张招商银行银联标准信用卡申请 Apple Pay 服务。
在这一步：
用户使用手机键入或拍照卡信息（卡号、有效期、CVN2）；
手机将上述信息发给 Apple Pay 的专用服务器（Token Requestor）；
Apple Pay 的专用服务器将卡信息发送给令牌服务器提供商（Token Service Provider、Token SP），就是银联云闪付的令牌服务系统；
Token SP 将卡信息和针对这个卡预生成的虚拟卡号（Payment Token、token）发给发卡行验证；
发卡行通过验证，向 Token SP 授权，并在数据库中建立 PAN 和 token 的唯一对应关系，并将这张银联标准信用卡和 token 做出账务关联；
Token SP 获得授权，将 token 回送给 Apple Pay 的专用服务器；
Apple Pay 的专用服务器先将设备唯一标识和 Token 进行绑定，然后将 token 回送至 iphone 的 Secure Element 进行硬件加密保护。
通俗来讲，这个过程就是：
用户在手机上输入卡号 6255 7500 0000 0000 ，有效期 99/99，CVN2 999，手机把这些信息发给 Apple Pay 的专用服务器；
Apple Pay 的专用服务器把这三个信息发送给银联的 Token SP；
Token SP 启动一种算法，针对 6255 7500 0000 0000 生成了一个虚拟卡号 6211 8888 8888 8888 ，并把（6255 7500 0000 0000，99/99，999，6211 8888 8888 8888）发送给招商银行信用卡中心；
招行一看，卡号、有效期、CVN2 正确，便在自己的系统里偷偷地将 0000 卡和 8888 虚拟卡关联了起来，并告诉 Token SP ：“来信收到，内容无误，你的请求已经得到了批准”（以上几部在 iphone 上显示为“正在与发卡行通信”）；
Token SP收到回信后，将 6211 8888 8888 8888 回送给 Apple Pay 专用服务器。（这步在 iPhone 上显示为“正在设置用于 Apple Pay 的卡片”）；
Apple Pay 专用服务器将 6211 8888 8888 8888 存储在 iPhone 的 Secure Element 里面。（这步在 iPhone 上显示为“正在将卡片添加到 Wallet”）；
于是，用户的手机上就显示了主账号 6255 7500 0000 0000 ，设备账号号码6211 8888 8888 8888。
4.用户使用 Apple Pay 在商户进行交易。
在这一步：
NFC 芯片将 Token 发送给 POS；
POS 将 Token 和其他交易信息发送给收单行；
收单行将 Token 和其他交易信息发送给银联交易转接服务器；
银联交易转接服务器将 Token 发给 Token SP；
Token SP 通过 Token 对应出 PAN，将 PAN 回送至银联交易转接服务器；
银联交易转接服务器将 Token、PAN 和其他交易发给发卡行；
发卡行进行交易授权，并将 PAN 和授权信息回送至银联交易转接服务器；
银联交易转接服务器将 Token 和授权信息回送至收单行；
收单行将 Token 和授权信息回送至 POS；
POS 提示交易成功，打单。
从上述过程看出，商户、收单行和交易转接服务器之前采用 Token 来标识卡片，而 PAN 在且仅在交易转接服务器、Token SP 和发卡行之间进行传送。
5.如果发生了风险
手机丢失时：
用户会登录 iCloud 网站，登录并停用用户手机上的 Apple Pay 服务；
Apple Pay 的专属服务器会立即向 Token SP 发出请求，按照自己存储的该设备对应的 Token 列表逐一申请吊销这些 Token；
捡到手机的人在尝试支付时，在交易进行到“Token SP 通过 Token 对应出 PAN”这一步时，因为 Token 已被吊销，所以交易无法继续；
用户找回或购买了新设备，重复申请 Apple Pay 的流程，获取全新的 Token。
在用 Token 出现交易风险时：
发卡行会对该 Token 取消授权，并通告 Token SP；
Token SP 会向 Apple Pay 专属服务器回送 Token 失效的信息；
Apple Pay 专属服务器向 iPhone 发送指令，将这张卡片标记为不可用；
用户重复申请 Apple Pay 的流程。
比较传统支付和 Apple Pay，实际上后者比前者多了两个参与方，就是令牌申请方 Token Requestor 和令牌服务提供商 Token SP，这两方的存在保障了用户 PAN 的安全，降低了 PAN 邪路的概率。
