付款标记化(Tokenisation)规范
技术架构
2014 年 3 月
*
EMV 是美国和其他地区的一个注册商标，属于 EMV 公司。
EMV 公司保留所有权利。任何对本规范的使用都应该遵照许可协议的条款和条
件。该条款和条件可以在 上找到。
这些规范的提供没有任何形式的保证，并且 EMV 公司没有假想或者接受任和错
误或者遗漏中包含这些规范。根据本规范，EMVCO 并不承认任何声明、保证、
明示、暗示，包含但不限于对特殊目的、主题和非侵犯性内容的适销性和适用性
的隐含保证。
EMVCo 不对任何第三方团体或者有关规范做任何方面的知识产权的声明与保
证。对于对本规范的使用可能造成的对于专利、版权、商标商业秘密、技术和其
他第三方知识产权的违反、侵犯或者其他的方式，EMVCo 概不负责。因此任何
人在使用本规范的任何内容前应当咨询知识产权律师。
在上述限制之外，本规范可以提供公钥使用和其他技术，这可能是其他国家的专
利主题。任何准备使用此规范的团体须独立决定是否需要对这些技术进行许可，
包括专利公钥加密技术。理论上 EMVCo 不应该对任何团体对任何有关本规范的
知识产权的侵权行为负责。
目录
1 引言 ..................................8
总览..................................8
使用者.... ..............................9
引用标准...........................10
术语.............................10
缩写.....................................10
定义.......... .......................11
参考信息.........................20
2 限制 ....................................21
系统限制 .......................21
3 电子令牌系统环境...............................22
令牌支付系统 .....................22
令牌服务提供方 ...................25
持卡人 .........................25
发行方..........................25
商家 ..............................26
需求方 ...........................26
支付网络 .....................26
令牌请求方......................26
4 令牌支付标准数据元素 ................28
数据元素..............................28
5 令牌服务提供方资格 .......................33
引言........................33
令牌库需求 ..................33
支付令牌生成 ..........33
支付令牌发行和供应......34
安全与控制........35
令牌请求登记.. ...35
令牌保险........... 36
令牌域约束限制...........37
令牌请求者 ID........37
POS 机输入模式 ........37
商业信息...........38
报告和原始数据.........38
需求方要求 .............38
支付网络要求..................38
6 令牌保证的 ID 和 V 方法 ............39
通则 ...........................39
卡发行商保护的概念和 ID&V 方法.........39
非 ID&V 执行 ...............41
账户验证 .....41
令牌服务提供方保证 ........41
含请求数据的令牌服务提供方保证 ...42
持卡者的卡发行商验证.......42
7 令牌服务提供方 API..........44
通则..................44
令牌服务参与点 ..........44
接口分类 ................45
令牌请求和保护 .............45
数据元素输入端 ..........45
数据元素输出端 ..........49
令牌更新方法级别保证 ...........51
数据元素输入端 .........51
数据元素输出端 ..........53
De-tokenisation 查询........54
数据元素输入端........54
数据元素输出端 ......55
含验证的 De-tokenisation...........56
数据元素输入端.........56
数据元素输出端 ........57
令牌生命周期管理 ........59
8 令牌支付过程..........62
通则 ............62
路由和账户类别表 .........62
交易授权 .........62
交易时令牌域限制.......63
捕捉过程 ........63
清帐.............63
异常处理 .........64
9 支付令牌交易流............65
通则 ............65
用例 1: 销售点的手机 NFC .......66
用例 2: 手机/电子钱包的电子商务.......70
用例 3: 卡存档电子商务......73
用例 4: 销售点扫描.........76
捕捉和结算流程 ......79
异常流程 .........81
图示
图示 1: 令牌支付配置概述.........23
图示 2: 令牌支付交易概述............... 24
图示 3: 令牌请求者注册过程 ...........36
图示 4: 销售点手机 NFC 流...........67
图示 5: 手机/电子钱包的电子商务的授权....71
图示 6: 卡存档电子商务的授权........74
图示 7: 销售点扫描流程.........77
图示 8: 捕捉和结算流程..........80
图示 9: 数据元素退款流程 ..........82
表格
表格 1-1: 引用标准...............10
表格 1-2: 缩语.............................10
表格 1-3: 定义 ..............11
表格 4-1: 数据元素支付标准............28
表格 6-1: ID&V 样例............40
表格 7-1: 令牌请求的数据元素...........46
表格 7-2: 令牌请求响应的数据元素...........50
表格 7-3: 令牌请求更新等级保证的数据元素.51
表格 7-4: 令牌请求更新等级保证响应的数据元素.............53
表格 7-5: De-tokenisation 查询请求的数据元素 .........55
表格 7-6: De-tokenisation 查询请求的响应的数据元素...........56
表格 7-7: 含有认证请求的 De-tokenisation 数据元素.........57
表格 7-8: 含有认证请求响应的 De-tokenisation 数据元素.........58
表格 7-9: 事件周期 ........................60
1.引言
本文档旨在提供一个详细的为了行业一致化和可交互操作的付款标记化方案
而制定的技术规范，此方案将有惠于收购者、商家、发行商、持卡人。
本规范描述了付款标记化的概况，定义了支持付款标记化的必要实体的关键角色
定位，确认了这个规范的重要影响，指定了和令牌请求、发行和供应还有交易处
理相关联的必须和可选的数据字段，并确认了必要的 API
本规范也试图提供一个对付款标记化系统、术语定义、主要职责的详尽的描述并
控制该系统中的每一个实体。另外，文档还提供了潜在的用例、相关的事务流和
这些事物流中通过传统支付功能中必须和可选字段的标准化，这些传统支付功能
比如：授权、捕获、结算、异常处理等。
概述
支付行业正在发展提供支付形式因素这些形式可以提供更多对于假冒、账户滥用
和其他形式的欺诈的保护。虽然 EMV 芯片可以提供牢固的对有卡交易事务的保
护，但是有一个类似的需求存在，这个需求就是减少未授权使用持卡账户数据，
和减少对于无卡交易的跨渠道和一种新兴的结合了有卡交易和无卡交易的交易
环境的欺诈行为。付款标记化系统对满足这些需求非常有保证。
支付令牌是支付系统中可以代替主账号（PAN）。支付令牌可以用于生成付款交
易，而非支付令牌可以用与一些辅助过程，比如真实性跟踪。本规范描述了创造
和使用支付令牌的最小需求。但是本规范并不用于处理非支付令牌，但并不排斥
其使用。
支付令牌应该与持卡人认证方法(CVMs)一起使用，这些方法包括签名、在线或
线下 PIN 和无方法。根据 ISO-9564-1 PIN Block 形式 0 或者 3，如果一个在线 PIN
码和一个支付令牌一起使用，这个 PIN Block 将包含支付令牌来代替 PAN。令牌
服务提供方(可参考 章 令牌服务提供方)有责任确保卡发行方收到确认，确认
是 PAN 或支付令牌的 PIN Block 视情况而定。
为了提供进一步的对于滥用的保护，支付令牌被限制用于一个明确的域，比如特
定的客商或者通道中。这些潜在的用途控制是支付令牌和本规范描述实现的方法
的关键的好处。
另外，支付令牌发行的时候应该采取一些步骤来确保令牌请求者使用支付令牌取
代 PAN 是合法的。这个过程被称作识别和验证 (ID&V)，每次支付令牌被请求
的时候都应当被执行。
不同的令牌保护等级对应不同的识别和验证方法。例如，无或者最小化的识别和
验证应当用于低保护的支付令牌，而高等级的识别和验证可能用于高保护的支付
令牌。
以下是支付系统中各方采用支付令牌的好处。
卡发行商和持卡人可以获益于一种更加安全的支付方式，一个更高
等级的交易批准，还可以降低在支付令牌而不是 PAN 在暴露时，数据泄
露而导致的被诈骗的风险。
对于卡请求者和商家，在线攻击和数据泄露的危险减少了，因为限
制了特定的域，支付令牌的数据库降低了吸引力。卡请求者和商人也将
从支付令牌提供的更高的安保等级中获益。
支付过程网络也可以采取一种开放的规范，这个规范可以促进互操
作性，帮助降低支付网络和其参与者的数据保护需求。
读者
文档适合支付产业系统内的所有参与者阅读。比如卡发行方、商家、请求者、支
付网络、支付加工者、第三方服务提供者。
引用标准
表 1-1 列出了本文档将可能用于处理令牌支付过程的参考文献。最新版本适用，
除非显式声明一个出版日期。
表 1-1 引用标准
参考文献 文档标题
ISO 7812 标识卡-发行者识别
ISO 8583 金融交易卡原始电文-交换电文规范
ISO 9564-1 金融服务-个人标识号管理与安全 第 1 部分：基于卡的系统中个
人识别码基本原理与要求
ISO 13491 银行业-安全加密装置(各部分)
ISO 27001 信息技术-安全技术-信息安全管理系统
PCI DSS 支付卡产业数据安全标准
术语
本术语无法代表本规范的需求，也不应当代表本规范推荐的指导方针。
缩略语
表 1-2 缩略语
缩略语 定义
API Application Programming Interface 应用编程接口
AVS Address Verification Service 地址认证服务
ICC Integrated Circuit Card 集成电路卡
NFC Near Field Communication 近距离无线通信
TEE Trusted Execution Environment 可信任执行环境
名词解释
表 1-3 名词解释
名词 定义
3-D Secure
3D 安全
电子商务中证明持卡人身份真实性的协议。
Agent
代理人
有卡发行方指定的实体，负责完成代表卡发行方具体的
功能。如卡处理、使用 3D 安全协议的持卡人认证和令
牌服务都是这些功能的案例。
Bank Identification
Number
(BIN)
银行身份码
BIN 由支付网络分配给卡发行方，符合 ISO7812 标准的
识别基于 BIN 和关联账号范围内的支付网络的要求
BIN Controller/Manager
BIN 控制者/管理者
根据本规范，BIN 控制者/管理者是一个控制发行，分
配那些用于发行的支付令牌的 ISO BIN 码的实体。
Card
卡
任何可以用于发起交易的持卡人设备或者一些电子器
件，比如手机。
Cardholder
持卡人
任何被卡发行方发给一个由卡的形式而表现的一个金
融账号的独体。
Card Acceptor
接卡人
发起一次付款事件并且把数据提交给需求方的人，典型
的需求方如商人。
Card Acceptor ID
接卡人 ID 号
接卡人的身份证明。
Card Issuer
卡发行商
发行卡和持卡人的金融机构和其代理。
Card Issuer Access
Control Server (ACS)
卡发行商访问控制服务
器
为识别和认证而提供 3D 安全服务的卡发行商的代理。
DE-Tokenisation
去令牌化
补偿一个支付令牌因为基于支付令牌和 PAN 的分布式
存储于令牌库而导致其与 PAN 相关联的过程。代替其
关联支付令牌检索一个 PAN 的能力应当被特定官方的
实体、应用或者系统所限制。
Identification and 一个实体可以成功确认持卡人和持卡人的账号，从而建
Verification
(ID＆V)
识别和检验
立一个支付令牌和 PAN 持卡人绑定的信用等级的有效
的方法。ID＆V 方法的例子如下：
账号认证信息
基于 PAN 的风险评估
卡发行商或者其代理使用一次性密码来确认持卡
人
Payment Network
支付网络
用于接收、发送、处理由支付卡产生的金钱、商品或者
服务的事务，转化发行者、请求者、支付过程、商家和
持卡人之间的信息和资金的电子支付系统。
Payment Processor
支付处理机
为请求者和发行者提供支付处理服务的实体。另外，一
个支付处理机还可能为请求者和发行者处理提供操作
性的、报告和其他服务。
Payment Token
支付令牌
在支付行业中支付令牌可以是多种形式。对于本规范来
说，术语“支付令牌”代表一个数值，这个数值就是 PAN
码，一种必须通过基本账号的验证规则的 13-19 位，其
中包括一个 Luhn 校验位的数值。支付令牌只能在 BIN
范围内产生，这个 BIN 范围根据一张合适的 BIN 码表
来标记，并且被指定为一种令牌 BIN 范围。支付标记
不得和一个真实的 PAN 码有完全一样的数值，那样会
和真实的 PAN 码冲突。
Primary Account
Number (PAN)
基础账号码
由 13-19 个数字的可变长度组成，由 ISO 7812 协议兼
容的账号，生成于和卡发行商的 BIN 相关联的账号范
围。
Requested Token
Assurance Level /
Assigned Token
Assurance Level
被请求令牌保险等级/
已分配令牌保险等级
被请求令牌保险等级由令牌请求者从令牌服务提供者
处请求。被请求令牌保险等级的概念在令牌请求的范围
内。已分配令牌保险等级是由令牌服务提供者安排的真
实数值，作为 ID&V 过程的结果，并且反过来提供给令
牌响应者用于应对令牌请求。
Token Assurance Level
令牌保险等级
一个数值，用来表示令牌服务提供者对支付令牌和
PAN 或者持卡人的绑定的信任等级。由识别和认证的
执行类型和实体的执行类型来决定。也可能被附加的一
些因素影响，比如令牌的位置。
令牌保险等级在发行支付令牌时被设置，并且可能在额
外的识别和认证被执行的时候更新。令牌保险等级的指
有令牌服务提供方来定义。
Token BIN
令牌 BIN 码
一个特定的 BIN 码，或是一个已经被设计成只为发行
支付令牌并被在 BIN 码表内被标记的 BIN 码。
Token BIN Range
令牌 BIN 码范畴
一个主要由令牌 BIN 码前 6-12 位组成的独特的标识符。
令牌 BIN 码范畴可能被设计用于携带和关联卡发行商
的卡范畴相同的属性并将被包括在分布于参与请求方
和商家的 BIN 路由选择表以用于支持路由选择。
Token Cryptogram
令牌密码电文
使用支付令牌和额外的事务数据生成的用于创造一个
该事务特有的值的密码电文。计算方法和形成方法可能
因用例而异。
Token Domain
令牌域
可能使用到支付令牌的事务的类别。令牌域可能是一个
特定的频段(比如：只允许 NFC 接收)，特定的商家、
特定的数字钱包或者是以上任几个的联合。
Token Domain
Restriction Controls
令牌域限制控制
由令牌服务提供商建立的，作为令牌服务安保的一部分
的一系列参数，这些参数可以加强交易行为中支付令牌
的适当使用。一些控制的例子如：
·使用特殊陈述模式的支付令牌，如非接触令牌或
者电子商务
·可以被特别标注出来的特殊用户使用的支付令
牌
·对于每个事务很特别的令牌密文的认证
Token Expiry Date
令牌到期日期
由令牌库生成并且维持，在交易过程中被传递给 PAN
到期日期以确保交互性并且使得令牌规范安装的影响
最小化。令牌到期日期是一个和 ISO8583 格式一致的
4 位数值。
Token Interoperability
令牌互用性
当使用有本规范定义的新的字段和字段值的支付令牌
时被保持的通过现有的互用的能力来确保团体间事务
的进行和交换的过程。
Token Issuance
令牌发布
一个支付令牌被创造和交付给令牌请求者的过程。支付
令牌可能为多种使用方式和单个使用方式而发行。
Token Location
令牌位置
在从令牌服务提供方申请一个支付令牌的时候，由令牌
申请者提供的为一个支付令牌和任何相关数据的存储
的计划模式的一个表示。
位置的安全性可能影响支付令牌被为人的令牌安保等
级。由令牌申请者提供的安全性的应有职责，是每一个
令牌服务提供方和分配到每个令牌请求者将在每个令
牌服务提供者的自由裁量权来负责。
目前支持的位置类型是：
·远程存储：卡上的文件是一个例子。
·EMVCo/安全元素批准的支付网络类型/ICC
·本地设备存储：使用消费者控制的设备来进行支
付令牌的标准数据存储是一个例子。
·本地硬件安全存储：使用一个 TEE 来确保合适
的数据使用限制是一个例子。
·远程硬件安全存储：符合 ISO-13491 的存储器是
一个例子。
更多存储位置的种类可能随着时间增加。
Token Presentment
Mode
令牌陈述模式
通过支付令牌提出付款的模式。这个信息将会如同在
ISO-8583 信息定义的那样，决定一个现存的叫做 POS
进入模式的范围，可以强化到包含新的本规范中的潜在
价值。每一额支付网络都将定义并且发布一个新的 POS
进入模式作为其现存的信息规范和客户须知的过程。为
了支持现有的无触点的值，如果还没有已经存在的值得
话，新的值将会被指定，通过以下的方式参与到支付网
络中：
·服务器初始(卡中文件的用例)
·扫描(可选)
Token Processing
令牌配置
事务处理的支付令牌存在代替 PAN 和处理的交互通过
支付网络和令牌服务提供者库来去令牌化使事务完成。
令牌处理可能跨越付款流程,包括授权、捕获、清算和
异常处理。
Token Processing
令牌供应
提供支付令牌的行为和相关的值给令牌位置，可能包括
一个或多个密码生成密钥。
Token Reference ID
令牌关联 ID
用作代替非公开支付令牌或者支付令牌代表的 PAN 码
的信息的值。
Token Request
令牌请求
一个令牌请求者向令牌服务提供者请求一个支付令牌
的过程。这个过程的结果是表明，ID&V 使用令牌请求
指示器来表明 ID&V 机制的目的是为了使用令牌的请
求,而非其他目的。
Token Request Indicator
令牌请求指示器
一个用来表明身份验证/确认消息令牌请求有关的值。
这是选择性地传递到卡发行商作为识别和验证 API 的
一部分，来通知卡发行商的帐户状态检查正在执行的原
因。
Token Requestor
令牌请求方
一个寻求根据这个规范来实现付款标记化，并发起
PAN 通过向令牌服务提供方提交被标记请求来实现付
款标记化的功能的实体。每个令牌请求者将注册并由令
牌服务提供者惟一地识别付款标记化系统。
Token Requestor
Registration
令牌请求方注册
令牌服务提供者提供正式的流程令牌请求者应用程序
参与令牌服务计划的流程。令牌服务提供者可能收集关
于付款请求者的性质和相关使用令牌验证和正式批准
令牌请求者和建立适当的令牌控制域限制的信息。成功
注册的令牌请求者将被指派一个令牌请求者 ID,并加入
维护中的令牌库。
Token Service
令牌服务
一个由关键功能组成的系统，这个系统可以促进从令
牌 BIN 中产生和发行支付令牌,并在当令牌请求者请求
的时候维持既定的支付令牌到 PAN 的分布。它还包括
建立令牌的能力来表示支付令牌到 PAN/持卡者绑定的
信用等级。这个服务还通过将支付令牌去令牌化来维持
真实的 PAN 码来支持支付事务的令牌过程。
Token Service Provider
令牌服务提供者
一个提供一个由令牌库和关联过程组成的令牌服务的
实体。令牌服务提供者将有能力预留许可 ISO 的 BIN
码来作为令牌的 BIN 码来为根据本规范提交的 PAN
码发出支付令牌。
Token Vault
令牌库
一个通过一个维护已经建立的支付令牌到 PAN 映射的
令牌标记化系统来实现的存储库。这个存储库称为令牌
库。令牌库也可以维护其他属性的令牌请求者在决定注
册时,可以使用的令牌服务提供者应用域限制或其他控
件在事务处理。
Tokenisation
令牌标记化
PAN 被替换为一个被称为支付令牌的代理值的过程。
付款标记化可能提高交易效率,提高交易安全,增加服务
透明度,或为第三方提供方法支持。
补充材料
其他支付令牌实现信息可以在 上找到
2 约束
系统约束
本规范的目的是工作在一个数量的限制的支付生态系统,包括各种实体的角色、
事务流,定义,和相关的用例。这些限制包括如下：
本规范无意于代替或者干扰任何国际间的、国家、地区或者地方法律法规，这些
政府间的需求高于任何工业规范。
本规范并不排除现有的申请者或其他第三方支付令牌实现解决方案中,这些实体
在其系统中生成支付令牌并执行支付令牌和 PAN 的映射。
基于每个支付网络的政策和业务需求，额外的数据(如全部或部分的 PAN)可能提
供给收购方和/或商家。重要的是要注意，提供完整的 PAN 给商人会减少令牌给
商人带来的价值。
产品属性,例如产品类型(例如,借记卡或信用卡)保持令牌化的交易，以确保现有
的支付行业中的相关产品属性的业务需求的连续性来支付行业参与者的透明度。
令牌 BIN 付款范围和这些 BIN 范围内的支付令牌的分配将使当事人接受事务做
出路由决策。
根据本规范，因为生命周期导致的从支付令牌到 PAN 的映射将被令牌服务者实
施，比如 PAN 更新、丢失、设备失窃和客户和令牌请求者的关系终止导致的令
牌失活。
一个提供令牌服务提供商能力的实体必须认识到支付处理环境中,服务将提供和
确保付款标记化引入环境的令牌服务提供者对现有流程没有不利的影响，例如信
用卡发行商的转换,商人转换和本地网络/对我们的汇款线路。
3 付款标记化生态环境
支付令牌环境
支付令牌的解决方案以本规范列出的来实现，并在某种程度上符合本规范本身，
包括一个生态系统内的角色。有些是传统的支付行业内现有的角色，也有些是本
规范介绍的其他角色。
下面的图提供了各种参与支付令牌生态系统的角色的一个概述。每个支付令牌的
角色和功能将会在随后的章节更详细地描述。
令牌服务提供方
令牌服务提供方是付款标记化系统内，被授权给注册的令牌请求者提供支付令牌
的实体。
令牌服务提供商负责大量的离散功能作为付款授权方发行的令牌。这些职责包括
但不
限于:
·令牌库的运行和维护
·支付令牌的产生和发行
·安全和控制的应用
·支付令牌监督
·令牌请求者登记的功能
令牌服务提供商负责建立和管理自己的专有令牌请求者 API，令牌库、令牌供应
平台和令牌注册。本规范本身不详细描述各个功能需求包含这些专有平台和相关
系统。然而,令牌服务提供者应确保令牌 BIN 或令牌 BIN 范围从传统的 BIN 或
BIN 范围，来避免任何疏忽重叠的 PAN 和支付令牌。
持卡人
本规范不改变持卡人的身份。卡发行商将持续的给持卡人发行信用卡和信用卡账
户。大多数情况下，持卡人预计不会知道支付令牌已经发给代表他们的账户了。
非强制的，令牌请求者可以选择让持卡人了解，也可以要求持卡人参加 ID&V 过
程令牌保证。
卡发行商
根据拥有与持卡人的账户关系，以及拥有授权和支付令牌生态系统中正在进行的
风险管理，卡发行商将继续维持目前的身份。任何卡发行令牌服务应考虑遵守此
规范,来保持可互操作的并符合使用该规范部署解决方案。
商家
商人将继续维持目前的身份，但这取决于具体的用例，可能是收件人支付令牌代
替一个 PAN，如在销售点的 NFC 用例。商家可能也是一个令牌请求者,如在卡上
文件的用例。用例在后面的部分中定义的规范。商家将继续以同样的方式处理所
有事务现在一样,包括授权和捕获，将需要实现任何必需的或可选的数据元素，
如同这个规范引用的那样，和任何处理需求建立了商人的需求或支付处理器。在
商人也是一个令牌请求者的用例中，,商人需要本规范中引用的适应的令牌服务
API，随后由令牌服务提供者实现的解决方案。
更多信息请参阅部分 9，支付令牌事务流。
请求者
请求者将以今天同样的方式处理所有事务,包括授权、捕获、清算和异常处理。
可能需要额外的字段来支持该规范。
支付网络
支付网络继续在他们当前的身份，可能另外执行令牌服务提供者的功能，包括这
个规范为令牌服务提供者定义所有相关的角色。
作为令牌服务提供商执行的支付系统负责建立和管理自己的专有令牌请求者
API，令牌库,令牌提供平台。令牌注册与 节中列出的令牌服务提供者。支付
系统也负责定义和发布授权，清算和异常处理消息的影响他们的令牌服务。
非令牌服务提供商支付网络应该支持处理功能的实现，以允许和令牌服务提供者
信息交换，来实现去令牌化，以确保支付令牌的互操作性。
令牌请求者
令牌请求者可能是支付产业传统的和新生的参与者。可能的令牌请求者包括但不
限于：
·卡上文件的商家
·收购者、收购处理机和代表商家支付的支付网关，如原始设备制造商、
设备制造商
·数字钱包提供者
·卡发行商
令牌请求者将被要求登记与令牌服务提供商并遵守他们的私有注册中心需求、系
统和流程。令牌服务提供者成功注册后,令牌请求者将被分配一个令牌请求者 ID。
在和一个指定的令牌服务提供者注册并被分配一个令牌请求者 ID 后，令牌请求
者将获得一个特定的令牌 API。在令牌请求者在生产中安装了令牌 API 后，令牌
请求者可以初始化支付令牌请求实现此 API 的流程和技术的特化。当令牌请求
者初始化了一个支付令牌请求后，该请求将被令牌服务提供方处理，支付令牌将
被发行。
4 支付令牌规格数据元素
数据元素
作为本说明书的一部分，下面的数据元素可以是那些具有一支付令牌发起的交易
中使用。这些数据元素将被映射并流通过现有的支付消息传递基础结构。
虽然每个数据元素可能需要在一个特定的信息或 API 调用的上下文条件或可选，
以保证支付网络之间的互联互通，所有这些数据元素参与的支付网络应支持事务
处理。
表 4-1：支付令牌规格数据元素
字段名称 ISO 8583 场 长度 格式 评论
支付令牌 2 13 至
19
数字 支付令牌数量是指一个替代值
的 PAN，那就是通过一个账号基
本的验证规则，包括卢恩校验位
13 至 19 位的数值。已被指定为
令牌 BIN 范围，并在所有适当
的 BIN 表标记相应的一个 BIN
范围或卡的范围内产生的支付
令牌。生成支付令牌，使得它们
将不会有相同的值或与真正的
PAN 冲突Ⅰ
支付令牌数量的交易信息将通
过授权，捕获，清算和异常信息
代替 PAN 的传递。 Ⅰ支付令牌
数目可任选地从所述令牌传递
服务提供商向发卡人的授权请
求的一部分。
令牌到期日 14 4 数字 是受产生并保持在令牌保管库
的支付令牌的到期日期。令牌到
期日期字段带有一个 4 位数字
的值，是与 ISO 8583 的格式一致。
Ⅰ令牌到期日的交易信息传递代
替 PAN 有效期。 Ⅰ的值被替换
为令牌服务提供商与 PAN 到期
日，然后传递给发卡作为授权请
求的一部分。
格 式 评 论 最
后位
支 付 网 络 中 的
特定
:4 数字 以有选择地提供通过收购来的
商户为客户服务使用情况 PAN
4 数字的最后四位数字，如被印
在消费者的收据。
PAN ID 产品 支 付 网 络 中 的
特定
3 字 母 数
字
PAN 产品 ID 是用于确定卡的产
品被符号化的类型可选标识符。
它可以被包括在的情况下的这
种信息的透明度是必须的。
交易信息：
PAN 产品 ID 可以任选地从所述
令牌服务提供商向收单传递到
授权响应的一部分。
POS 输 入 模
式
22 2 数字 此规范使用 POS 输入模式字段，
表示通过支付令牌呈现 FO 模式
支付。每个支付网络将定义和发
布任何新的 POS 输入模式值作
为其现有的信息规范和客户通
知程序的一部分。交易信息：POS
输入模式是，将通过授权，捕获，
清算和异常信息传递现有领域。
令 牌 请 求 者
ID
支 付 网 络 中 的
特定
11 数字 数字此值唯一标识令牌请求者
与令牌域配对。因此，如果一个
给定的令牌请求需要令牌为多
个域，这将有多个令牌请求程序
的 ID，每个域一个。它是由令牌
服务供商分配一个 11 位数字的
值，是令牌库中是唯一的：Ⅰ位
置 1-3：令牌服务提供商代码，
唯一的每个令牌服务提供商Ⅰ位
置 4-11：通过令牌服务分配供应
商为每个请求的实体和令牌域
名
交易信息
令牌请求者 ID 可以任选通过授
权，俘获，清算和异常消息。
令 牌 保 证 级
别
支 付 网 络 中 的
特定
2 数字 令牌保证级别是一个值，允许令
牌服务提供商，以指示支付令牌
的置信水平为 PAN /持卡人具有
约束力。它被确定为标识＆V 执
行的类型和所执行的实体的结
果令牌保证级别的发布支付令
牌，可能更多的 ID＆V 执行，如
果被更新时设置。它是一个 2 位
数的值从 00 其指示支付令牌不
具有的 ID＆V 已经执行到 99 的
值，表示最高可能的保证。产生
的值的具体方法由令牌服务提
供商所定义。
交易信息：令牌保证级别将由令
牌服务提供商来提供。 Ⅰ该值可
以任选传递给发卡作为授权请
求的一部分。该值可任选地传递
到收单/商人在授权响应，捕获，
清算和异常处理的消息。
令牌保证数据:支付网络中的特
定由令牌服务提供商提供的可
变二进制数据包含支持信息的
令牌保证级别。
交易信息：这个数据可以任选传
递给发卡作为授权请求的一部
分。
令牌密文 支 付 网 络 中 的
特定
可变 二进制 该密码电文唯一地由令牌请求
生成验证授权使用的令牌。该密
会在不同的领域中，基于交易类
型的交易信息进行。
相关的用例：Ⅰ
NFC 非接触式交易，将开展令牌
密文在现有的芯片的数据字段。
其他交易，如那些从数字钱包始
发，可携带的令牌密文中的现有
字段。
交易信息：
令牌密文将被传递的授权请求，
并通过所述令牌服务提供商和/
或发卡验证
下面的数据元素 ID＆V 令牌服务在提供商和发行人之间的过程中只是作为一个
可选字段
字段名称：令牌请求指示
ISO 8583 场：支付网络中的特定/ ID＆V 过程中的具体
长度：可变的
格式：支付网络的特定/ ID＆V 具体过程
评论：一个指示器用于表示该消息的目的是在一个支付令牌请求来验证持卡人。
简介
本节介绍令牌服务提供商需要实现提供令牌服务，它与本规范相一致的要求。
多重责任分配给令牌服务提供商，包括令牌库，令牌颁发，令牌保证使用 ID＆V
方法，令牌服务的 API，令牌处理功能和令牌生命周期管理。
虽然说明书描述了令牌请求者和一个令牌服务提供商之间的直接关系，但并
不排除作为聚合器或网关媒介实体，提供表示该令牌请求到多个令牌服务提供商，
只要令牌域限制控制是维持。
令牌库需求
令牌服务提供者应当建立并运营一个令牌库将提供生成和发布支付令牌的
能力，建立和维护支付令牌，以 PAN 映射，并提供基本的安全及相关处理控制，
如事务处理过程中域限制。令牌 Vault 提供机制，支付令牌，以平底锅进行映射
事务处理过程中提供，如授权，捕获，清算和异常处理。令牌拱顶需要保持映射
到其整个生命周期中给定的 PAN 所有相关的支付令牌。
支付令牌生成
令牌服务提供商产生响应支付令牌请求支付令牌。支付令牌世代只使用指定
的令牌桶或距离单元，以保证有生成付款的可能性和令牌与 PAN 进行冲突。在
支付令牌生成时，令牌服务提供者应当识别和存储支付令牌，以 PAN 映射在令
牌库在随后的事务处理使用。令牌 Vault 还应当对各自产生的支付令牌的令牌请
求发起通过捕获和存储令牌请求 ID 请求相关联。
业务功能包括授权，清算和异常处理的传统处理将其所需要的应用的付款网
络被集成及相关令牌保管库的解决方案，以确保令牌服务是指在保持互操作性和
这些交易过程的正在进行的完整性的方式进行的。
任何发卡实现令牌服务应考虑以下这个标准的互操作性和一致性与使用本
规范部署的解决方案。
所产生的应包括令牌到期日支付令牌。令牌到期日期应满足的 PAN 到期日期的
格式要求。支付令牌概以这样的方式，以确保在所有现有的事务处理产物和 PAN
的其他属性的保存使用令牌的 BIN 生成。
响应来自于给定令牌请求支付令牌请求生成的支付令牌仅适用于令牌域到该支
付令牌已经发出内的事务。
支付令牌发行与配置
支付令牌应通过响应仅注册令牌请求令牌请求的令牌服务提供者进行有效
的令牌请求者 ID 认可发行。支付令牌请求应受基础上，要求保证级别同意由令
牌请求和令牌服务供应商指定的 ID＆V 保证方法。
支付令牌发放也可能涉及到支付令牌的令牌请求的配置。支付令牌已经产生
并保证步骤完成后，会发生支付令牌配置。与配置相关联的方法可以是专有的每
个令牌服务提供商并且是本说明书的范围之外。
支付令牌配置通过令牌请求和令牌服务进行提供商之间的接口交流。
令牌服务提供商也可以选择通过使用特别指定的标记 ISO 8583 的授权请求
报文来实现支付令牌发放和配置进行支付令牌请求和传输 ID＆V 信息令牌服务
提供商进行后续处理。在这样的情况下，ISO 8583 的授权响应消息可以用来支
付令牌和相关的令牌到期日返回到令牌请求。
安全性和控制
由于存储和管理他们的数据映射的敏感性质，令牌拱顶由每个行业标准的强
大的物理和逻辑安全的措施加以保护。
令牌服务供应商，在支付交易处理的同时，应负责限制基于令牌的交易与给定令
牌请求截至令牌请求报名时确定相关的相应的域。
令牌请求登记，确保令牌服务通过注册，审批和注册实体令牌请求者的完整
性。令牌服务提供者应当至少分配一个唯一的令牌请求 ID 给定的令牌请求，并
应负责令牌请求者和它们相关的令牌请求 ID 的生命周期管理。作为注册的一部
分，令牌服务提供商也应该捕获与给定的令牌请求相关的请求令牌保证级别和令
牌域限制控制，并确保这些域限制提供给令牌库支付令牌交易过程中应用这些限
制处理。
令牌请求注册
令牌服务提供者应当建立一个过程来注册申请指定为令牌请求的实体。那些
选择实体根据每个令牌服务提供商建立了专有工艺被承认为一个令牌请求多个
令牌服务提供商可能会与每个令牌服务提供商单独注册。
令牌请求注册流程：
*令牌请求者 到令牌服务提供商：
1. 令牌请求信息Ⅰ
2. 令牌域限制控制Ⅰ
3. 要求保证级别
.
*令牌服务提供商到令牌请求者：令牌请求者 ID
每个令牌服务提供商确定从令牌请求收集的信息，并建立自己的专有流程，
收集，审查和批准。收集的信息可以包括，除其他外，典型的了解你的客户
（KYC）的信息，以及支付令牌的用例，该招收令牌请求程序将支持，包括可
能需要被内实现的任何适当的域限制和其他交易控制标记库。
注册函数的结果是对未来的令牌请求的注册申请批准或拒绝的决定。批准令
牌请求者被分配一个唯一的令牌请求者 ID。域限制及其他交易控制应通知并配
合令牌库实施。
令牌保证
令牌服务提供者应当确定保证每个批准令牌请求相关的预期水平，并根据使
用的情况下，在确定支付令牌申请和审批程序应用于哪些类型的 ID＆V 的。初
始令牌保证级别将在支付令牌请求时间来确定和基于该 ID＆V 方法的类型和结
果。令牌保证级别可更新，以支付令牌发放后续。
令牌域限制控制
为了确保支付令牌作为意在通过令牌请求，需要额外的控制来管理和验证的
支付令牌的基本用法。这些控制应通过基于条件的令牌服务提供商，其中包括用
例和令牌域名，如商家标识和 POS 进入模式在令牌请求登记过程中确定了定义
和实施。这些令牌域限制控制的目的是保证支付令牌的任何曝光不会导致显著随
后欺诈的水平。允许令牌域限制控制一个给定的令牌请求是通过在令牌请求注册
时间令牌服务提供商指定并批准支付令牌用例驱动的一部分。这些令牌域限制控
制应被存储在令牌库或具有同等安全保护的位置。实际令牌域限制控制应用和令
牌服务提供商及其专有标记库执行。
令牌请求者 ID
每个令牌请求 ID 由令牌服务提供商分配将是惟一的，而不是与其他分配令
牌请求 ID 的来自同一令牌服务提供商或其他令牌服务提供者发生冲突。
每个令牌请求应指定一个令牌请求者 ID，每个域一个。它具有以下约定分
配的令牌服务提供商的 11 位数字的值：Ⅰ位置 1-3：令牌服务提供商的代码，唯
一的每个令牌服务提供商Ⅰ 位置 4-11：为每个请求分配的令牌服务提供商实体
和令牌域名
令牌服务提供商的代码分配给每个令牌服务提供商和 EMVCo 标准维护。看
到的 EMVCo 网站了解更多信息：。
令牌请求 ID 是应该出现在交易的底层控制数据元素。在令牌请求者 ID 传
递给商家使用的情况下，这些交易不应该允许成功处理如果令牌请求 ID 出现在
事务不匹配令牌请求 ID 存储在令牌库的支付令牌。
这是旨在限制与特定令牌请求相关交易 POS 进入模式的其他控制包
括使用那些在 POS 输入模式代码字段进行 POS 输入模式的值限制使用令牌，只
有那些 POS 进入模式令牌请求注册时同意。
商家信息。
在使用中的情况下的商人可以是令牌请求程序，商户相关的数据元素，如卡
片接受器的 ID 与收单识别数据元素的组合，应使用以限制使用的支付令牌的比
较在事务处理每个令牌请求注册期间确定的信息建立在令牌库控制消息的这些
领域。这样一个用例是通过卡上文件招商局召开的 PAN 的断词。
报告和原始数据
令牌服务供应商应必须提供报告或将数据输出到报告工具的能力有关已批准，待
或拒绝令牌请求，包括任何指定的令牌请求的 ID。
令牌服务提供者也应该有提供数据输出到相关的能力，基于令牌的交易报告
工具和应用程序，并提交支付令牌和/或 PAN 适当的报告输出。应令牌请求者被
撤销或者被分配新的令牌请求的 ID，这些信息也应受到报告和审计，并调和与
令牌库。
收单行要求
作为参考在本说明书中，并且由支撑支付网络的消息规范进一步定义收单行
应实现任何所需的或可选的数据元素。
付款网络要求
支付网络必须实现所有领域，包括必需和可选字段，在其专有信息的规格范
围内本规范中定义的沟通和通过现有沟通渠道的变化。
6 令牌保证 ID＆V 方法
一般
令牌保证 ID＆V 的方法提供了一组允许的支付令牌，以一个 PAN 从授权持
卡人一个可信的关联的功能和服务，以支持与支付令牌发起的安全和可靠的支付
交易。
该规范涉及令牌保证级别的重要组成部分，包括 ID＆V 方法，从 ID＆V 方
法得到令牌保证级别，并支持令牌保证数据。
在令牌颁发/配置的时间拍摄，以及在支付令牌使用的领域，ID＆V 的步骤是确
定令牌保障水平的重要因素。令牌保证级别又可以使用的令牌服务提供商来建立
特定方案，交易分类，或其他专有业务划定。任何这样的程序或分类是本规范的
范围之内。
两个新的数据元素被用来传达支付令牌保证和由令牌服务提供商认为，支付
令牌的 ID＆V 步骤进行： *令牌保证级别Ⅰ*令牌保证数据
每个令牌服务提供者应当实施方法和流程进行通信的令牌保证级别和令牌
保证数据的发卡就保证水平和 ID＆V 的实力上的支付令牌执行的平移/持卡人具
有约束力。
发卡保证的概念和 ID＆V 方法
ID＆V 方法可以单独使用或组合使用，以提供一个特定令牌保证级别。这些
级别范围从没有保证，高可靠性取决于执行的 ID＆V 方法和令牌服务提供商，
确认评估结果。的 ID＆V 方法举例如下：Ⅰ*帐户验证Ⅰ*令牌服务提供商的风险
评分Ⅰ*令牌服务提供商风险评分与令牌请求数据持卡人Ⅰ*发卡行认证
可替代地，ID＆V 不必执行。在这种情况下，一个令牌请求程序是提供不能
保证使用卡的数据的真实性，并仅请求支付令牌来表示的数据。
其他方法可以在令牌服务提供商的自由裁量权来实现。
令牌服务提供者应当实现一个或多个 ID＆V 方法。此外，令牌服务提供者
应当保证（S）发出令牌时始终进行适当的令牌保证级别的 ID＆V 方法。
ID＆V 步骤可以由令牌服务提供商，所述令牌请求程序，或第三者进行。在
由比令牌服务提供商以外的实体执行的 ID＆V 措施情况下，可核实的证据，应
当提供证明进行的步骤，并提供所产生的结果。可验证的证据可能包括提供给令
牌服务供应商，该令牌服务提供商可以验证 ID＆V 处理实体的任意值。什么构
成核查的证据的细节不属于本说明书的范围之外，但实例包括密码文字或一个授
权码。这些要求适用于所有的 ID＆V 方法，与其中该 ID＆V 不进行异常的条件。
令牌服务提供者应当在令牌的时间设定令牌保证水平为适当的值的 ID＆V 进行
的基础上，（00 =没有 ID＆伏，99 =最高保证），以及由令牌请求中提供的令牌
存储和使用信息请求注册。
下表提供了导出令牌保障水平的基础上进行 ID＆V 的步骤。其他 ID＆V 方
法可能在将来的补充或修订本规范中定义。
表 6-1：
ID＆V 的例子
ID＆V 保证方法 保证执行者 潜在用途
无 ID＆V 进行 无 卡上文件的帐号替换令牌
帐户验证（0 美元授权，有无 AVS
和信用卡验证号）
令牌请求
令 牌 服 务 提 供
商
卡上的文件账号替换令牌
风险评分来自令牌服务提供商 令 牌 服 务 提 供
商
中等保证水平与支持令牌身份验证
数据
风险评分来源于支付令牌的用户
数据加上支付网络数据
令 牌 服 务 提 供
商
中，高保障水平令牌认证数据的支
持
持卡人的发卡机构认证 发 卡 机 构 或 代
理
高保证水平与支持令牌身份验证数
据的特定频道或域
无 ID＆V 演出
当支付令牌已经没有在令牌发行时进行任何 ID＆V 步发出令牌保障水平应
设置为无担保的价值。根据令牌用例和令牌服务提供商的规则，所述支付令牌仍
然可以用于发起付款交易，但将不携带任何令牌保证。使用令牌没有保证水平的
额外限制在本规范后面的章节解释。
帐户验证
这个 ID＆V 保证方法提供了一个基本的帐户验证检查，以验证是否 PAN 是积极
有效的，在发卡机构。验证的方法可包括但不限于：Ⅰ
美元授权Ⅰ
2.信用卡验证号码验证Ⅰ
3.支持邮编和地址验
帐户验证方法可以由令牌请求启动，并报告给令牌服务提供商通过令牌服
务 API，或者通过令牌服务提供商在令牌发放时间。
令牌服务提供商保证
此 ID＆V 保证方法涉及使用由令牌服务提供商维护来执行的可能性，为了
Tokenise PAN 中的请求是有保证的置信足够水平基于风险的评估风险和认证数
据。令牌服务提供者应建立并维护评估技术和工具，以支持基于风险的评估。
令牌服务提供者定义的方法来保证水平传达给当事人适用的，包括发卡机构。
令牌服务提供商保证与请求数据
此 ID＆V 保证方法涉及使用由令牌请求提供的数据元素可以是预测欺诈的。
数据元素的例子包括，但不限于：Ⅰ
（1）账龄和历史Ⅰ
（2）法案/船的地址和联系Ⅰ
（3）地理位置Ⅰ
（4）交易速度信息Ⅰ
（5）.IP 地址Ⅰ
（6）设备 ID 和设备信息
令牌服务供应商应具备相应的评估技术和工具到位，以实现这个 ID＆V 方
法和应结合所产生的 ID＆V 的数据与相关的 PAN 来确定分配的令牌保证等级
的令牌服务提供商的风险和认证数据。发卡机构可能参与了这一过程。
令牌服务提供者定义的方法来沟通的保证水平，并执行适用的各方，包括发
卡机构的 ID＆V 的步骤。
持卡人
卡发行商确认
这个 ID＆V 方法涉及与发卡机构或其代理交互执行持卡人验证，以满足必
要的保证，以完成支付令牌的 PAN 的结合。用于验证的方法应该被设计成提供
根据设备类型可接受的用户体验;例如，移动电话或计算机;持卡人可以在认证过
程中使用。设备的准则应建立和遵循，以确保一致的用户体验。
发卡认证的设计应充分利用输入数据和得分令牌请求，以便发卡机构为客户
提供最智能的体验给消费者。利用这些数据将在许多情况下，允许卡发行者有信
心的真正的和授权的持卡人实际上请求支付令牌，而无需添加额外的步骤的过程。
持卡人的卡发行商确认可以通过通道，包括执行，但不限于：（1）使用的
3-D 安全持卡人的 ACSⅠ
（2）手机银行核查与认证码Ⅰ
（3）联邦登录系统
（4）API 功能能够发电，交付和令牌请求Ⅰ
（5）一次性密码（OTP），激活码，或其他共享秘密发卡机构和持卡人Ⅰ
（6）双向电子邮件确认的验证数据
当发卡确定有必要验证消费者请求通过一个明确的验证的支付令牌;例如，
使用一个 OTP 或激活码;共享秘密应该通过带外的通道被递送给消费者。
发卡机构可使用多个对持卡人的身份验证方法;在持卡人身份验证的时间。但是，
下面的方法不能用于 ID＆V
*静态认证数据
*在入学身份验证服务
相比之下，一次性口令应使用由发卡机构或其代理持卡人身份验证。
发卡机构或其代理应使用一次性口令以下标准：Ⅰ
(1)为了安全和方便之间的平衡，用 OTP 的长度应至少有 6 也没有超过 8
个字符Ⅰ
（2）用 OTP 应该以这样的方式产生使得它们递送不可预测Ⅰ
（3）优选的方法是从卡发行给客户设备，安全通道，例如安装在消费设备
上的移动银行应用程序
另外的方法，也可以使用在卡片发行人的判断，而应按照类似的方法在本说明书
中所定义。
7 令牌服务提供商的 API
一般
本节中规定，每一个令牌服务提供者应当用于从外部提供的一个特定令牌服
务提供商的 API 的支持的接口的公共数据元。
接口应该实施，并提供由令牌服务提供商要使用与令牌服务提供商交互的所
有参与实体。
该规范并没有提供对每个接口的技术水平实现细节或详细规定，将每个令牌
服务提供商可以实现的接口。
令牌服务提供者应当使用令牌服务参与实体实现互动的安全方法。
本节本规范并没有解决令牌处理接口。欲了解更多信息，请参见第 9 支付令
牌交易流程。
令牌服务端点参与
令牌服务提供者应当提供建立和使用标准接口或原料药是通过互动与令牌
服务安全的方法验证了实体的能力。通过这可能会发生这些相互作用的验证方法
举例如下：（1）ⅠWeb 服务Ⅰ（2）ISO 通过现有的支付网络接口Ⅰ（3）文件/
批 8583 消息交换
Ⅰ下面举例说明可能参与并使用令牌服务接口实体：
*令牌请求Ⅰ*收购Ⅰ*支付网络Ⅰ*其他网络Ⅰ*商家Ⅰ*收购和发卡处理器Ⅰ*发卡
Ⅰ*发卡 3-D 安全 ACS
接口分类
本节介绍会由令牌服务提供者实施提供令牌服务的接口和消息。这些接口分
为以下几类：（1）Ⅰ令牌请求和发放Ⅰ（2）令牌保证（ID＆V）Ⅰ（3）DE-断
词Ⅰ（4）令牌路由（5）Ⅰ令牌生命周期管理
每个类别应具有一个或多个定义的接口和/或消息以执行特定令牌相关的操作。
令牌请求和发行
令牌服务提供者应当提供注册令牌请求者可以通过使用标准接口提交请求
输入原来的支付凭证，并获得支付令牌响应的标准方法。
令牌服务提供者应当采取适当的控制和流程的基础上输入 PAN 生成令牌。
此外，基于该请求，可以执行保证步骤。其中，这种保证步骤涉及的机制也可用
于其它目的（例如 3- D 安全），一个令牌请求指示符应该被用来指示该机制被
用作令牌请求的一部分。
令牌请求接口可以通过在其中生成，并在大批量发出令牌，并返回到令牌请
求程序的安全接口文件支持需要发出一个支付令牌的请求的每个 PAN 实时请求，
或者在散装的请求。
输入数据元素输入到这个请求应最低限度包括下列数据元素：(1)Ⅰ令牌请
求者 ID (2) PANⅠ(3)PAN 有效期
请求的保证级别存在，如果一个特定的保证水平正在请求。
令牌位置提供了有关其中所述令牌的数据将被存储的信息。此位置的安全性
可能会影响可被分配给一个令牌的保证级别。通过令牌请求者提供的安全的尽职
调查是一个位置类型的每个令牌服务提供商，并分配给每个令牌请求的责任将在
每个令牌服务提供者的自由裁量权。令牌位置支付令牌的使用寿命内不得变更。
目前确定的位置类型有：Ⅰ
*远程存储：如卡片式文件数据库Ⅰ
*EMVCo 标准/支付网络型式认可安全元件/ ICCⅠ
*本地设备存储：如使用消费者受控设备Ⅰ
*本地硬件安全存储：如使用 TEE，以确保适当限制对数据的访问
*远程硬件安全存储：如 ISO 13491 标准的存储
该协议提供了有关如何令牌请求与持卡人沟通信息。使用可能会影响可被分
配到一个支付令牌的保证等级的通信信道的安全性。
帐户验证结果包含先前执行帐户验证交易，如 0 美元权威性带或不带地址验
证的结果。
可选持卡人数据元素可以包括附加的数据，例如但不限于，纸币向/船舶地
址和邮政编码进行令牌保证 ID 与 V 法。这不是一个详尽的清单，并有可能在将
来增长。
设备的信息是用于标识其中一个支付令牌被储存在特定的设备。实例包括安
全元件的 ID 和/或设备的特性，例如 MAC 地址，操作系统版本，语言等。
. 表 7-1：数据元素的令牌请求
字段名称 长度 格式 R / C / O 描述
版本号 3 R 此信息版本号
令牌请求者 ID 11 数字 R 请参阅表 4-1：支付令牌规范
数据元素进行了详细的描述。
PAN 长 2 数字 R PAN 场长度
PAN 变 量
（ 13
〜 19
位）
数字 R PAN 为其支付令牌请求
PAN 到期日 4 数字 R PAN 到期日为其支付令牌请求
要求令牌保证级别 2 数字 O 目前如果保证水平正在请求，
请参考表 1-3：定义进行了详
细的描述。
标记位置 2 数字 C 要求，除非内在的令牌请求
API 中。指示支付令牌的存储
位置：
Ⅰ01 - 远程存储
Ⅰ02 - EMVCo 标准/支付网络
型式认可安全元件/ ICC
Ⅰ03 - 本地设备的存储Ⅰ
04 - 本地硬件安全存储Ⅰ
05 - 远程硬件安全存储Ⅰ
06 - 99 保留供未来使用
协议 2 数字 C 要求，除非内在的令牌请求
API 中。描述了令牌请求使用
什么协议与持卡人进行沟通。
价值观是令牌服务提供商具体
可能包括值：Ⅰ移动应用程序
APIⅠ浏览器
帐户验证结果 2 数字 O 指示帐户验证，如果表现，如
结果及格，不及格（值将是支
付网络的具体）
帐户验证参考长度 2 数字 R 该帐户验证参考的长度，将置
零（0），如果不存在
帐户验证参考 变量 字母 O 参考由令牌请求进行帐户验证
交易。
注意：参考应包含足够的信息，
以确定执行的身份验证的类型，
如果需要的话
令牌请求风险评分 4 数字 O 由令牌请求提供的欺诈风险评
分
地址不匹配指示器 2 数字 O 如果填充的发货和账单地址不
同
持卡人数据的长度 4 数字 R 持卡人的数据的长度，将置零
（0），如果不存在
持卡人数据 变量 字母 C 数据所必需的支持请求保证级
别。例子包括，但不限于：Ⅰ
账 单 地 址 Ⅰ 发 货 地 址 Ⅰ 邮 编
ⅠCAV2 / CVC2 / CVV2 / CID
请参考有关 ID＆V 方法的详
细说明第 6 部分令牌保证 ID
＆V 方法。
设备信息长度 2 数字 R 设备信息长度，将置零（0），
如果不存在
设备信息 变量 字母 O 该装置可用于识别它的属性
，
R - 要求，C - 条件，哦 - 对字段格式可选实现由每个令牌服务提供商的 API 定
义
输出数据元素
接口应提供响应消息包含在响应以下数据元素：Ⅰ
*请求的状态 - 成功或失败Ⅰ
&原因码 - 代码说明故障的类型
对于成功的请求，下面附加的数据元件应在响应中返回：
Ⅰ*支付令牌Ⅰ
*支付令牌到期日
当令牌保障法已在令牌请求时进行，接口可以选择性地提供计算的支付令牌的分
配令牌保证级别。
表 7-2：数据元素的响应令牌请求
字段名称 长度 格式 R / C /
O
描述
版本号 3 C 此消息的版本号
请求状态 1 数字 R 指示成功请求或失败
原因代码长度 2 数字 R 原因代码的长度，将置（0），如果不存在
原因代码 变量 字母 C 目前，如果请求状态不成功
令牌长度 2 数字 R 支付令牌的长度，将置零（0），如果不存在
支付令牌 变量 （ 13 〜
19 位）
C 如果请求状态是成功的数值存在，支付令牌
由令牌服务提供商产生。
令牌参考 ID 长度 2 数字 R 令牌参考 ID 的长度，将置零（0），如果
不存在
令牌引用 ID 变量 数字 O 对于支付令牌变量数值 OA 参考标识符
令牌到期日 4 数字 C 当前如果请求状态成功，令牌到期日由令牌
服务提供商产生。
分配令牌保证级别 2 数字 C 当前如果请求状态是成功的，ID＆V 一直要
求，请参考表 4-1：支付令牌规范数据元素进
行了详细的描述。
，
令牌保证级别更新方法
此方法用于情形签发支付令牌之后，令牌请求希望有分配给该支付令牌更新
保证水平。
输入数据元素输入到这个请求应最低限度包括下列数据元素：Ⅰ支付令牌
Ⅰ令牌到期日Ⅰ令牌请求者 ID
请求的保证级别存在，如果一个特定的保证水平正在请求。
可选持卡人数据元素可以包括附加的数据，例如但不限于，纸币向/船舶地址和
邮政编码进行令牌保证 ID 与 V 法。这不是一个详尽的列表，并且可以在将来进
行扩展。
表 7-3：数据元素令牌保证级别更新请求
字段名称 长度 格式 R / C / O 描述
版本号 3 R 此消息的版本号
令牌长度 2 数字 R 支付令牌的长度
支 付 令 牌 / 令
牌参考 ID
变量 （ 13
〜 19
位）
R 本支付令牌或令牌参考标识符
令 牌 请 求 者
ID
11 数字 R 正在请求支付令牌分配给该登记的商业实体唯一
值
要求令牌保证
级别
2 数字 C 指示验证级别令牌请求者希望被执行。目前，如果
令牌请求是请求特定的令牌保证水平（而不仅仅是
一个，保证水平重新评估。
帐户验证结果 2 数字 O 指示帐户验证，如果表现，如结果及格，不及格
（值将是支付网络的具体）
帐户验证参考
长度
2 数字 R 该帐户验证参考的长度，将置零（0），如果不存
在
帐户验证参考 变量 字母 O 参考由令牌请求进行帐户验证交易
注意：参考应包含足够的信息，以确定执行的身份
验证的类型，如果需要的话。
令牌请求风险
评分
4 数字 O 由令牌请求提供的欺诈风险评分
地址不匹配指
示器
1 布尔 O 收货和付款与否地址的指示是不同的
持卡人数据的
长度
4 数字 R 持卡人的数据长度，将置零（0），如果不存在
持卡人数据 变量 字母 C 数据所必需的支持请求保证级别。例子包括，但不
限 于 ： Ⅰ 账 单 地 址 Ⅰ 发 货 地 址 Ⅰ 邮 编 ⅠCAV2 /
CVC2 / CVV2 / CID
请参考有关 ID＆V 方法的详细说明第 6 部分令牌
保证 ID＆V 方法。
设备信息长度 2 数字 R 设备信息的长度，将置零（0），如果不存在
设备信息 变量 字 母
数字
O 该装置可用于识别它的属性
R - 要求，C - 条件，O - 对字段格式可选实现由每个令牌服提供商的 API 定义
输出数据元素的界面应提供一个响应消息，其中包含在响应中的以下数据
元素：Ⅰ*请求的状态 - 成功或失败Ⅰ*原因代码 - 代码说明故障的类型
对于成功的请求，下表中示出的附加的数据元素中的响应被返回。
表 7-4：数据元素的响应令牌保证级别更新请求
字段名称 长度 格
式
R / C / O 描述
版本号 3 R 此消息的版本号
请求状态 1 数
字
R 指示成功请求或失败
原因代码长度 2 数
字
R 原因代码的长度，将置
零（0），如果不存在
原因代码 变量 字
母
C 当前，如果请求状态不
成功
令牌长度 2 数
字
R 支付令牌的长度
支付令牌 变量（13〜19
位）
数
字
R 如果请求状态是成功
的，支付令牌由令牌服
务提供商生成的。
分配令牌保证级别 2 字
母
R 当前，如果请求状态是
成功的，ID＆V 已要求。
R - 要求，C - 条件，O- 对字段格式可选实现由每个令牌服务提供商的 API 定
义
-词查询
去断词查询接口提供了必要的机制，通过映射原 PAN 和 PAN 有效期凭证返
回认证实体交换支付令牌。
无交易的具体验证这一要求进行的：它的目的是使原来的信用卡资料提供给
一个值得信赖的党，没有在事务处理中。
令牌服务提供者应当采取适当的访问安全控制，特别是令牌服务提供者应当
确保提出的要求是从认可，授权和认证的源接收。
输入数据元素的输入，以该请求包含下表中示出的数据元素。
表 7-5：数据元素的德断词查询请求
字段名称 长度 格
式
R / C / O 描述
版本号 3 R 此消息的版本号
令牌请求者 ID 11 数
字
C 存在的时候提供给 DE-断词请求。
请参阅表 4-1：支付令牌规范数据
元素进行了详细的说明
令牌长度 2 数
字
R 支付令牌的长度
支付令牌 变量（13〜19
位）
数
字
R 本发行支付令牌
令牌到期日 4 数
字
R 本发行支付令牌的到期日
R - 要求，C - 条件，O - 对字段格式可选实现由每个令牌服务提供商的 API 定
义
输出数据元素的接口应提供响应消息包含以下数据元素：
Ⅰ*请求的状态 - 成功或失败Ⅰ
*原因码 - 代码解释故障的类型
对于成功的请求，下面附加的数据元素在响应中返回：Ⅰ*PANⅠ
*PAN 有效期
表 7-6：数据元素的响应去断词查询请求
字段名称 长度 格式 R / C / O 描述
版本号 3 R 此消息的版本号
请求状态 1 数字 R 指示成功请求或失败
原因代码长度 2 数字 R 原因代码的长度，将置零（0），如果不存
在
原因代码 变量 字母 C 如果当前请求状态不成功
PAN 长 2 数字 C 如果当前请求状态是成功的，与 PAN 字
段的长度
PAN 变 量
（13〜
19 位）
数字 C 当前，如果与 PAN 的请求状态是成功的
PAN 到期日 4 数字 C 如果当前与 PAN 到期日请求状态是成功
的，
R - 要求，C - 条件，O- 对字段格式可选实现由每个令牌服务提供商的 API 定
义
-断词核查
DE-断词核查接口提供了必要的机制，通过返回的映射原 PAN 和 PAN 有效期证
书的认证机构，以交换支付令牌，而执行任何所需要的支付令牌验证和执行相关
联的令牌域限制控制支付令牌。
输入数据元素
输入以该请求包含下表中示出的数据元素
表 7-6：对非标记化查询请求的数据元素应答
字段名称 长度 格式 R/C/
O
描述
版本号 3 数字.数字 R 该消息的版本号
请求状态 1 数字 R 指出请求成功或失败
理想代码长
度
2 数字 R 理想代码长度，如果不
设置将包含 0
理想代码 可变 字母数字 C 当请求状态不成功时出
现
永久账号长
度
2 数字 C 当请求状态成功时出现，
带永久账号长度字段
永久账号 可变（从 13
到 19 个数字）
数字 C 当请求状态成功时出现，
带永久账号
永久账号到
期日期
4 数字 C 当请求状态成功时出现，
带永久账号到期日期
R-必有的，C-有条件的，O-可选的
字段格式的实现由各个标记服务提供商的应用程序接口定义
非标记验证
非标记验证接口提供了必要的机制来交换支付令牌通过返回原始 PAN 映射
和 PAN 到期日期凭证给授权实体，同时执行任何要求的令牌验证和与支付令牌
相关的令牌域限制控制。
输入数据元素
请求的输入包括下表展示的数据元素：
表 7-7： 非标记验证请求的数据元素
字段名称 长度 格式 R/C/
O
描述
版本号 3 数 字 . 数
字
R 该消息的版本号
令牌请求
者 ID
11 数字 C 当对令牌请求者可用时必须被包括。
参见表 4-1：支付令牌规格数据元素
的详细描述
令牌长度 2 数字 R 支付令牌的长度
支付令牌 可变（从 13
到 9 个 数
字）
数字 R 发行的支付令牌
令牌到期
日期
4 数字 R 发行的支付令牌的到期日期
交易数据
元素长度
3 数字 R 交易数据元素字段的长度，如不设置
将包括 0
交易数据
元素
可变 独 立 实
现
O 其它的令牌服务提供者执行请求所
必要的交易数据元素，内容为令牌服
务提供者所私有
R-必有的，C-有条件的，O-可选的
字段格式的实现由各个标记服务提供商的应用程序接口定义
输出数据元素
接口 SHALL 提供包括以下数据元素的应答消息：
表 7-8：对非标记验证请求的应答数据元素
字段名称 长度 格式 R/C/
O
描述
版本号 3 数字.数字 R 该消息的版本号
请求状态 1 数字 R 指出请求成功或失败
理想代码长度 2 数字 R 理想代码长度，如果不设置将
包含 0
理想代码 可变 字母数字 C 当请求状态不成功时出现
PAN 长度 2 数字 C 当请求状态成功时出现，带永
久账号长度字段
PAN 可变（从 13
到 19 个 数
字）
数字 C 当请求状态成功时出现，带永
久账号
PAN 到 期 日
期
4 数字 C 当请求状态成功时出现，带永
久账号到期日期
交易数据元素
长度
3 数字 R 交易数据元素字段的长度，如
不设置将包括 0
交易数据元素 可变 独立实现 O 令牌服务提供者执行请求所
必要的交易数据元素，内容为
令牌服务提供者所私有
R-必有的，C-有条件的，O-可选的
字段格式的实现由各个标记服务提供商的应用程序接口定义
令牌生命周期管理
支付令牌可能因为 PAN 和 PAN 到期日期的改变而需要持续的管理和更新
和那些可能要求映射失效的事件。
令牌服务提供者的 SHALL 通过接口提供生命周期更新来管理影响发行的支
付令牌的改变。这些接口可能被大量的同行所使用，包括令牌请求者，卡发行者
和支付网络。
令牌生命周期管理可能被要求支持现存的一般商务流程如卡发行商投资组
合转换。
下表提供了一组应该被令牌服务提供商设为可用的接口的作为样本的生命
周期事件。注意这些并不是被要求的，令牌服务提供商采取措施描述每个事件：
这些行为听凭令牌服务提供商的处置。
在先前部分定义的数据元素也适用于这些接口。
表 7-9： 生命周期事件
# 接口 样例事件/描述 发动方 采取的措施
1 断 开 令 牌 连
接
·丢失或设备被盗
·被始证书不再有效
·令牌请求者不再在卡存档中
·PAN 丢失或被盗
·PAN 有诈骗警报
·支付令牌有诈骗警报
令 牌 请 求
者
卡发行者
支付网络
支付令牌与 PAN
断开连接且映射
不能进一步使用
2 挂起令牌 ·临时失去作用因为设备丢失 令 牌 请 求 支付令牌到 PAN
或被盗 者
卡发行者
支付网络
的映射被临时挂
起且进一步使用
被截留
3 激活令牌 ·第一次激活或者支付令牌
到 PAN 映射从临时挂起状
态继续
令 牌 请 求
者
卡发行者
支付网络
支付令牌到 PAN
映射被激活
# 接口 样例事件/描述 发动方 采取的措施
4 更 新 令 牌 保
证
·持续管理支付令牌的令牌保
证等级
令 牌 请 求
者
卡发行者
支付网络
令 牌 服 务
提供者
支付令牌到 PAN
映射的令牌保证
等级的更新基于
ID&V 方 法 或 者
内部操作的结果
5 更新 PAN 属
性
·对初始证书的更新，如 PAN
到期日期
卡发行者
令 牌 服 务
提供者
对 PAN 属性的更
新，如 PAN 到期
日期，是被用来延
长 支 付 令 牌 到
PAN 映射的使用
时间
8 支付令牌处理
总述
规格包括对现有数据字段的使用，包含在当前字段和新字段中与支付令牌有
关的数据，其中的一些是被要求的以提供整个支付系统的实现和互操作性的一致
性。其他介绍的新字段作为本规范的一部分是可选的。
在交易流程中与支付标记有关的当前字段根据使用条件不同将改变正如在
第九部分：支付令牌交易流所强调的一样。
路由和账户表范围
路由和帐户范围表需要明确区分令牌桶和令牌桶值域从传统的桶和桶的值
域里以确保支付令牌交易处理的潜在完整性。这就要求令牌服务提供商分配的令
牌是独特的且与那些传统的在所有路由和帐户范围表被相应的标记的桶和桶值
域不同。
交易授权
交易授权信息，尤其是从商人流到需方，从需方流到支付网络，从支付网络
到卡发行方的请求信息，和相应的应答信息是受这个规范影响的。影响的程度因
使用情况而不同且在授权信息规范中被限定，它通过参与支付网络做为他们的基
于这个规范的标记解决方案的实现的一部分而沟连起来。
下述是支付令牌交易处理的关键要求：
·支付服务提供者的 SHALL 在有针对数据元素的授权信息到来时验证支付令牌，
包括令牌请求者 ID（如果可用），和提供在令牌域限制控制内的支付令牌的有
效性结果给支付网络。
·支付网络应运用令牌服务提供商在授权信息到来时进行从支付令牌到 PAN 的
映射来优先发送信息给卡发行商，还应该总是在有应答信息发送给需方时从
PAN 映射回支付令牌（除了卡发行商扮演令牌服务提供者的情况）。
·令牌服务提供者应该就支付令牌状态的任何变化向支付网络说明，如支付令牌
已被相信丢失/被盗且/或被标记为挂起。
在交易过程中的令牌域限制控制
令牌服务提供者和多方参与的支付网络提供应用专门的令牌域限制控制来
给考虑到的令牌请求者和使用情况加给限制。令牌域限制控制依赖在交易处理信
息和底层数据完整性方面的专门的控制相关的数据元素的可用性，因为这些数据
元素在确保支付令牌在控制下使用极其重要。域可能包含一个或多个通道，只要
令牌域限制控制被完全实施防止交叉通道欺诈。
捕获处理
该规范有关捕获处理效力被诸如需方或支付处理方基于多方参与的支付网
络的结算要求所限定。结算要求在规范中被限定、被由支付网络操作的结算系统
环境实现，决定关于需方或支付处理方和相关商人的捕获处理效力的限定。
结算
从需方流入支付网络，由支付网络流入卡发行者的结算信息被该规范影响。
影响程度因使用情况而不同且在由多方参与的支付网络联系的结算信息规范中
被限定，它作为基于该规范的支付标记解决方案的实现的一部分。这些结算相关
的规范决定由需方和支付处理者限定的他们的捕获处理信息规范的改变。
异常处理
从卡发行方流入支付网络，从支付网络流入需方的扣款信息被该规范影响。
影响程度因使用情况而不同且被由多方参与的支付网络联系的扣款信息规范限
定，它作为基于该规范的支付标记解决方案的实现的一部分。
9 支付令牌交易流
总述
基于这个规范的一个令牌服务的实现并不意在改变那些传统的方法和流，在
这些方法和流中支付交易使用的 PAN 被当前处理。然而，支付令牌的引入确实
需要在新数据元素中传递数据，在现有数据元素中携带一些令牌相关的数据，确
保支付网络能识别支付令牌交易，这是为了确保在交易过程中支付令牌被合适的
令牌服务提供商去令牌化。该规范在支付令牌交易流中的影响必须为每一种可能
的使用情况独立的检测以理解潜在的需要。
每一个令牌服务提供者有责任通知卡发行商授权（和其它）信息的任何改变，
尤其是哪些字段用法改变和哪些字段是新的。每一个令牌服务提供者也有责任确
保卡发行商明白在处理支付令牌交易时的角色划分，例如在通过 NFC 在销售使
用情况下令牌服务提供商可能会验证支付令牌的有效性但发卡银行还必须在需
要的情况下进行持卡人验证。
该规范限定的使用样例包括在 POS 机上使用移动 NFC，电商移动/数字钱包，
电商在档卡和销售点浏览。依赖于使用情况，在授权、提示、扣款交易流程和潜
在信息需求中有不同等级的影响。这其中的每种使用情况按照现有字段的使用，
当前字段的支付令牌数据的提示，必须和可选的新数据字段，包括令牌服务提供
商在连接支付网络时用来支持令牌域限制控制时的支付令牌控制字段。下面的图
示识别一些可能出或不出现在授权、捕获、结算和异常处理流程中的关键数据元
素，这取决于使用情况和是否数据元素被认为是必需的或可选的。对每条消息，
附加数据字段依使用情况、支付品牌等呈现。这些数字并不尝试呈现每条信息完
整的数据元素清单。展示的使用情况仅是例子，并不一定要被支持，它们也不意
在成为可能使用情况的一个详尽的清单。该规范可以被运用到此处提到的这些情
况以外的更多的情况中。
使用情况 1：销售点的移动 NFC 支付
在这种使用情况下，支付令牌被存储在有 NFC 功能的移动设备或者在远端
服务器上并被实时传回到设备。令牌服务开通可以通过令牌请求者与令牌服务提
供者完成。当一个交易被初始化，移动设备和/或远端服务器将激活一个包含支
付令牌、令牌到期日期、令牌密码和其它芯片数据元素的非接触交易，然后通
过 NFC 接口传送交易给商人的销售终端。
该用例定义的效果在下图示中展示：
图 4： 移动 NFC 在销售点流的情况
下面的步骤解释授权消息在移动设备在支持 NFC 的销售终端使用时的标准
支付令牌数据字段流。
1. 移动设备将通过支付应用与 NFC 终端作用并传递下面的关键的支付令
牌数据元素给商人终端：
a. 支付令牌将传递给现有的 PAN 字段。
b. 令牌到期日期将传递给 PAN 到期日期字段。
c. 令牌密码基于令牌数据元素被激活且传递给芯片的密码域（密码可能
是完全的芯片密码，或是一个缩略的 TRACK 2 等值密码。）。
d. 令牌请求者 ID 作为一个可选字段被传递。
e. 其它所有非接触数据元素被创建并按非接触数据标准传递。
注意
通过移动设备和 POS 机的入口模式激活的令牌密码将作为域限制控制字段被令
牌服务提供商来验证使用该支付令牌的交易的完整性。
2. 商人终端传送非接触授权请求给需方，携带着所有的标准的支付令牌数
据字段和非接触数据字段；POS 入口模式将被设置以指示非接触交易。
3. 需方会进行常规处理检查并传递令牌数据字段和非接触数据给支付网络。
4. 支付网络将连接支付服务提供商以便：
a. 搜索 PAN。
b. 验证支付令牌到 PAN 的状态，在令牌库进行映射激活的支付令牌
和其它可能对支付令牌限定的控制。
c. 验证令牌密码和对应令牌密码的令牌域限制控制（或者卡发行商
可能验证密码如果它有必需的密钥）。
d. 如果在授权信息里没有提供就搜索令牌请求者 ID。
5. 支付网络将发送授权请求给卡发行商，下面的授权请求信息将会改变：
a. 用 PAN 代替支付令牌。
b. 用 PAN 到期日期代替支付令牌到期日期。
c. 增加一个指示器告诉卡发行商支付令牌的支付服务提供商的一个
验证已经完成。
d. 下面的支付有关的字段在授权请求时传递给卡发行商：
Ⅰ.支付令牌
Ⅰ.令牌到期日期（可选）
Ⅰ.令牌保证数据（可选）
Ⅰ.令牌保证等级
Ⅰ.令牌请求者 ID
Ⅰ.POS 入口模式码
6. 卡发行商完成账户等级验证和授权检查，并在向支付网络授权应答时回
发 PAN。
7. 支付网络（可能与支付令牌服务提供者进行通信）可能生成一个应答密
码并用基于映射的支付令牌代替 PAN，且传递下面的必选字段给需方以
作为授权应答的一部分，并加入其它的标准数据元素：
a. 支付令牌
b. 令牌保证等级
c. PAN 末尾四个数字
d. PAN 产品 ID
8. 需方传递授权应答给商人。
9. 消费者被告知交易成功或失败。
注意
该使用情况也适用于支付令牌被上传到一个接触和/或非接触的芯片在该芯
片第一次发行时。这样的支付令牌不同于浮/打印在卡上并在磁条上编码的 PAN。
使用情况 2：移动/数字钱包电子商务
该使用情况涉及这样的情景：卡持有者开启一个到电商网站的支付使用一个
移动/数字钱包来传递支付和其它命令信息。钱包可能由卡发行商、支付网络或
第三方操作，数字钱包操作者很可能成为令牌请求者。在该情况下，钱包操作者
使用支付标记是因安全或其它商业理由不再需要在钱包平台存储 PAN。当卡持
有者在支持钱包电商商人处开启一个支付时，钱包会通过钱包的 API 传递给商
人代替 PAN 的支付令牌和其它支付相关的字段。商人将用支付令牌来启动授权
且伴随的令牌到期日期由现有的 PAN 和 PAN 到期日期所携带。分开发货和循环
支付可以用支付网络现有的流程来支持，虽然去标志和令牌域限制控制也需要执
行。
该用例的效果定义在下图展示。
图 5：授权-移动/数字钱包电子商务流
下面的步骤解释当消费者在移动设备上使用商业应用或数字钱包开启一
个电商交易的支付时授权信息的标准支付令牌数据字段的传递。
1. 移动设备上的商业应用/数字钱包将与支付应用相互作用并传递下面的关
键支付令牌数据字段给相关的商业平台：
a. 支付令牌会传给现有的 PAN 字段。
b. 令牌到期日期会传给 PAN 到期日期字段。
c. 令牌密码会基于支付令牌数据字段生成且会传入令牌密码字段。
d. 令牌请求者 ID 会作为可选字段被传递。
e. 所有其它的必需数据元素也会被创建和传递。
2. 商业平台会传递携带着全部标准支付令牌字段的授权请求给需方，POS
入口模式将被设置以指示电商交易。
3. 需方会执行对数据元素的流程检查，并传递支付令牌数据字段给支付网
络。
4. 支付网络会连接支付服务提供商以便：
a. 搜索 PAN。
b. 验证支付令牌到 PAN 的状态，在令牌库进行映射激活的支付令牌和
其它可能对支付令牌限定的控制。
c. 验证令牌密码和对应令牌密码的令牌域限制控制（或者卡发行商可能
验证密码如果它有必需的密钥）。
d. 如果在授权信息里没有提供就搜索令牌请求者 ID。
5. 支付网络将发送授权请求给卡发行商，下面的授权请求信息将会改变：
a. 用 PAN 代替支付令牌。
b. 用 PAN 到期日期代替支付令牌到期日期。
c. 增加一个指示器告诉卡发行商支付令牌的支付服务提供商的一个验
证已经完成。
d. 下面的支付有关的字段在授权请求时传递给卡发行商：
Ⅰ.支付令牌
Ⅰ.令牌到期日期（可选）
Ⅰ.令牌保证数据（可选）
Ⅰ.令牌保证等级
Ⅰ.令牌请求者 ID
Ⅰ.POS 入口模式码
6. 卡发行商完成账户等级验证和授权检查，并向支付网络发送授权应答。
7. 支付网络将用基于映射的支付令牌代替 PAN，且传递下面的必选字段给
需方以作为授权应答的一部分，并加入其它的标准数据元素：
a. 支付令牌
b. 令牌保证等级
c. PAN 末尾四个数字
d. PAN 产品 ID
8. 需方传递授权应答给商人。
9. 消费者被告知交易成功或失败。
使用情况 3：信用卡电子商务
该作例涉及的情景是：把支付信用卡数据档案存在数据库的电商商人寻求通
过用支付令牌代替 PANS 来除去存储信用卡的潜在安全暴露风险。在该情景下，
这些商人很可能成为令牌请求者。一旦支付令牌回到这些信用卡商人处，所有随
后被处理的电子商务交易将使用支付令牌和支付令牌到期日期代替 PAN 和
PAN 到期日期字段。
该用例定义的效果在下面的图示中展示：
图示 6：授权-信用卡电子商务流程
下面的步骤解释当消费者与信用卡商人开启一个电商交易的支付时授权信息
的标准支付令牌数据字段的传递。
1. 卡持有人与信用卡商人联机并开始一个电商交易。商业网站传递下面关
键的支付令牌数据元素给商业平台：
a. 支付令牌会传给现有的 PAN 字段。
b. 令牌到期日期会传给 PAN 到期日期字段。
c. 令牌请求者 ID 会作为可选字段被传递。
d. 令牌密码会基于支付令牌数据字段生成且会传入令牌密码字段（可
选）。
e. 所有其它的必需数据元素也会被创建和传递（可选）。
注意
令牌请求 ID 和相关的商业标识将作为域限制控制字段被用来验证交易的完
整性。
2. 商业平台会传递携带着全部标准支付令牌字段和其它所有必需的商业特
有的标识信息的授权请求给需方，POS 入口模式将被设置以指示电商交
易。
3. 需方会执行对数据元素的流程检查，并传递包含令牌密码的支付令牌数
据字段给支付网络。
4. 支付网络会连接支付服务提供商以便：
a. 搜索 PAN。
b. 验证支付令牌到 PAN 的状态，在令牌库进行映射激活的支付令牌和
其它可能对支付令牌限定的控制。
c. 验证令牌密码和对应令牌密码的令牌域限制控制（或者卡发行商可能
验证密码如果它有必需的密钥）。
d. 如果在授权信息里没有提供就搜索令牌请求者 ID。
5. 支付网络将发送授权请求给卡发行商，下面的授权请求信息将会改变：
a. 用 PAN 代替支付令牌。
b. 用 PAN 到期日期代替支付令牌到期日期。
c. 增加一个指示器告诉卡发行商支付令牌的支付服务提供商的一个验
证已经完成。
6. 下面与支付令牌相关的字段在授权请求时传递给卡发行商：
a. 支付令牌
b. 令牌到期日期（可选）
c. 令牌保证数据（可选）
d. 令牌保证等级
e. 令牌请求者 ID
f. POS 入口模式码
g. 卡发行商完成账户等级验证和授权检查，并向支付网络发送授权应答。
7. 支付网络将用基于映射的支付令牌代替 PAN，且传递下面的必选字段给
需方以作为授权应答的一部分，并加入其它的标准数据元素:
a. 支付令牌
b. 令牌保证等级
c. PAN 末尾四个数字
d. PAN 产品 ID（可选）
8. 需方传递授权应答给商人。
9. 消费者被告知交易成功或失败。
使用情况 4：销售点扫描
在销售点的移动快速应答码（QR）用例涉及在可以接受这种支付形式的商
人的销售点让移动设备去开启一个基于 QR 的支付。在该用例中，移动设备上的
应用在每次开启一个安全方式的支付时生成一个动态 QR 码。当一个交易开启后，
移动设备生成一个包含支付令牌，令牌到期日期，令牌密码元素和其它来自 QR
码的数据的事务，并把它传给商人的销售点终端。
该用例定义的效果如下图所示
图示 7：销售点扫描流程
下面的步骤解释当移动设备在销售点使用 QR 码呈现支付令牌时授权信息的标
准支付令牌数据字段的流动。
1. 移动设备将与能够读取 QR 码的商业终端作用，并传递下面的关键支付令
牌数据字段给商人终端：
a. 支付令牌会传给现有的 PAN 字段。
b. 令牌到期日期会传给 PAN 到期日期字段。
c. 令牌密码会基于支付令牌数据字段生成。
d. 令牌请求者 ID 会作为可选字段被传递。
e. 所有其它 QR 数据元素会被创建并传入各自的交易数据字段。
注意
令牌密码被生成且当作用时将作为域限制控制字段被令牌服务提供商来验
证使用该支付令牌的交易的完整性。
2. 商人终端会传递携带着如上图所示的全部标准支付令牌字段的授权请求
给需方，POS 入口模式将被设置以指示基于 QR 码的交易。
3. 需方会执行标准流程检查，并传递支付令牌数据字段给支付网络。
4. 支付网络会连接支付服务提供商以便：
a. 搜索 PAN。
b. 验证支付令牌到 PAN 的状态，在令牌库进行映射激活的支付令牌和
其它可能对支付令牌限定的控制。
c. 验证令牌密码和对应令牌密码的令牌域限制控制（或者卡发行商可能
验证密码如果它有必需的密钥）。
d. 如果在授权信息里没有提供就搜索令牌请求者 ID。
5. 支付网络将发送授权请求给卡发行商，下面的授权请求信息将会改变：
a. 用 PAN 代替支付令牌。
b. 用 PAN 到期日期代替支付令牌到期日期。
c. 增加一个指示器告诉卡发行商支付令牌的支付服务提供商的一个验
证已经完成。
d. 下面与支付令牌相关的字段在授权请求时传递给卡发行商：
Ⅰ. 支付令牌
Ⅰ. 令牌到期日期（可选）
Ⅰ. 令牌保证数据（可选）
Ⅰ. 令牌保证等级
Ⅰ. 令牌请求者 ID
Ⅰ. POS 入口模式码
6. 卡发行商完成账户等级验证和授权检查，并向支付网络发送授权应答。
7. 支付网络将用基于映射的支付令牌代替 PAN，且传递下面的必选字段给
需方以作为授权应答的一部分，并加入其它的标准数据元素:
a. 支付令牌
b. 支付令牌保证等级
c. PAN 末尾四个数字
d. PAN 产品 ID（可选）
8. 需方传递授权应答给商人。
9. 消费者被告知交易成功或失败。
捕获和结算流
下图展示支付令牌交易的捕获和结算处理。
图 8：捕获和结算流程
下面的步骤描述作为交易周期的一部分的捕获和结算处理中的标准支付令
牌数据字段流。
1. 捕获文件处理的信息在交易发起时由基于消费者提供的信息被需方创建。
支付令牌传递给数据采集文件的现有 PAN 字段并和其它标准支付令牌
数据元素传递给需方：
2. 需方会执行对数据元素的标准流程检查，并使用下面的支付令牌数据字
段来创建结算文件并传递给支付网络：
a. 支付令牌会传给现有的 PAN 字段。
b. POS 入口模式将被设为标准 POS 入口模式以进行专用通道交易，并包
含在结算文件中。
c. 令牌保证等级将被包含在结算文件中且用于支付令牌交易的一个新
的数据字段将被引入。
d. 令牌请求者 ID 作为可选字段传入结算文件。
3. 支付网络会连接支付服务提供商以便：
a. 搜索 PAN。
b. 验证支付令牌到 PAN 的状态，在令牌库进行映射激活的支付令牌和
其它可能对支付令牌限定的控制。
c. 验证支付令牌的令牌域限制控制。
4. 支付网络将发送结算文件给卡发行商，包含以下信息：
a. 用 PAN 代替支付令牌。
b. 增加一个指示器告诉卡发行商支付令牌的支付服务提供商的一个验
证已经完成。
c. 下面与支付令牌相关的字段传递给结算文件。这些在结算文件中的新
字段可选择性传递给卡发行商：
Ⅰ. 支付令牌
Ⅰ. 令牌到期日期（可选）
Ⅰ. 令牌请求者 ID
Ⅰ. 令牌保证等级
5. 卡发行商执行对结算文件的验证并完成结算过程。
异常流
下图展示退款请求的令牌处理流程
图 9：退款数据元素流
下面的步骤解释作为交易周期的一部分的异常处理流程中的标准支付令牌
数据字段流。
1. 卡发行商通常在验证最初事务是有效退款事务时申请退款，卡发行商有
适当的退款权利。
2. 卡发行商申请退款并提供下面的支付令牌数据字段以创建退款记录然后
发送给支付网络：
a. 在最初的支付交易中使用的 PAN。
b. 支付令牌作为一个新的数据字段被引入可以被提供的退款记录。
c. 令牌请求者 ID 作为可选项由卡发行商传递。
3. 支付网络会连接支付服务提供商以便：
a. 搜索 PAN。
b. 验证支付令牌到 PAN 的状态，在令牌库进行映射激活的支付令牌和
其它可能对支付令牌限定的控制。
c. 如果支付令牌不是由卡发行商发送的，搜索该用于交易的有争议的支
付令牌并发送给需方。
4. 发送包含下面信息的退款记录给需方：
a. 用 PAN 代替支付令牌。
b. 令牌请求者 ID 作为可选字段进行传递。
5. 需方基于对情况调查验证退款记录，然后进入争议处理的其它阶段或完
成退款。
