EMV2000-第四册.doc

EMV2000-第四册.doc

《EMV2000-第四册.doc》由会员分享，可在线阅读，更多相关《EMV2000-第四册.doc（68页珍藏版）》请在冰豆网上搜索。

持卡人、服务员和收单行接口需求

第四部分

持卡人、服务员和收单行

接口需求

1.范围

《支付系统持卡人、服务员和收单行接口需求》定义了接受集成电路（IC）卡的终端的必须、推荐和可选的需求，本文档与《应用无关的IC卡和终端接口要求》（第一册）、《安全和密钥管理》（第二册）、《应用规范》（第三册）是相一致的。

对应具体支付系统特定应用的终端需求以及不要求支持互通互用的功能没有包含在本文档中。

本文档应用于工作在有人值守或无人值守的操作环境、具有联机或脱机能力、支持交易类型如购物、服务、取现等的所有终端。

这里指的终端包括（但不仅限于）ATM、网点终端、无人值守的终端、电子收银机、个人计算机以及POS终端。

本文档还特别描述了：

·功能方面的要求，与《安全和密钥管理》和《应用规范》中类似

·一般的物理特性

·软件结构（包括软件和数据管理）

·持卡人的接口

·收单行的接口

本文档给出了支持IC卡功能所必须的需求。

这些需求不包括具体支付系统和收单行对于支持磁卡的终端所定义的部分。

接受IC卡和磁卡的能力可以共存于同一台终端上。

本文档假定读者已经熟悉了《应用无关的IC卡和终端接口需求》、《安全和密钥管理》及《应用规范》。

本文档面向的读者对象为支付系统成员、终端开发商以及IC卡应用设计人员。

遵行强制要求（定义为‘必须’）使终端与《应用无关的IC卡和终端接口需求》、《安全和密钥管理》、《应用规范》以及本文档相一致。

推荐要求定义为‘应该’，可选要求定义为‘可以’。

显而易见，根据不同的商业环境及用途终端的实现也不同。

本文档定义的是应用于终端特定操作环境中的特征和功能需求。

本文档没有涉及持卡人和商户操作流程，这些由具体的支付系统规定。

本文档不提供完成终端所需的全部细节。

具体支付系统和收单行将定义不同情况下的补充需求，以提供终端设备的更详细规范。

2.标准参考

下面这些标准被本文档所引用：

EMV2000Version4.02000/12:

IC卡支付系统规范：

第一册-《应用无关的IC卡和终端接口需求》

EMV2000Version4.02000/12:

IC卡支付系统规范：

第二册-《安全和密钥管理》

EMV2000Version4.02000/12:

IC卡支付系统规范：

第三册-《应用规范》

ISO8583:

1987 银行卡发起的报文－交互报文规范－金融交易内容

ISO8583:

1993 金融卡发起的报文－交互报文规范

ISO8859:

1987 信息技术-8位单字节图形编码字符集

ISO9564-1:

1991 银行业-个人密码管理和安全-个人密码保护原则和技术

ISO9564-2:

1991 银行业-个人密码管理和安全-个人密码加密认证算法

3.定义

如下术语被应用于本文档：

应用 卡和终端之间的应用协议及相关的数据集。

字节 8位二进制数。

卡 由支付系统定义的支付卡

认证机构 利用公开密钥和其它相关数据为所有者提供可靠校验的第三方机构。

命令 终端发送给IC卡的报文，以启动一个操作或请求IC卡的应答。

密码 加密操作的结果

异或 二进制无进位加法,如下结果:

0+0=0

0+1=1

1+0=1

1+1=0

功能 由一个或多个命令实现的过程，其执行结果完成了部分或全部交易。

集成电路 为执行处理和存储功能而设计的电子器件

集成电路（IC）卡 含有一个或多个集成电路的卡片，用来执行处理和存储功能。

接口设备 终端上用来插入IC卡的部分，包括机械和电气设备组成部分。

内核 每个实现了具体的解释器的终端所必需的一组功能的集合。

内核包括设备驱动程序、接口函数、安全与控制功能函数以及将虚拟机器语言移植到现实机器语言所用的软件等。

也就是说，内核是虚拟机器在一个特定现实机器上的实现。

键盘 数字键，命令键，功能键和（或）字母键（如果需要）按照特定的方式的一种排列。

库 一组使用公开接口实现的高级软件函数，提供对终端和（或）应用程序编程的通用支持。

磁条 含有磁编码信息的带状物。

半字节 一个字节中的高4位或低4位。

支付系统 在本规范中指，EuropayInternationalS.A.、MasterCard国际股份公司或Visa国际服务协会。

密码键盘 用来输入个人密码（PIN）的数字键和命令键的排列。

响应 IC卡处理完接收到的命令报文之后给终端返回的报文。

脚本 发卡行传送给终端的一个命令或命令串，由终端按顺序发送给IC卡。

套接字 在应用程序的特定位置定义地一个执行向量，并被赋予一个唯一的数字以被引用。

终端 为完成金融交易在交易地点与IC卡连接的设备。

终端包括接口设备，也可以包括其他部件和接口，例如通信主机。

交易 在用户的请求下由终端完成的操作。

对于一个POS终端，交易可以是商品的付款等。

交易在一个或多个应用中选择作为其处理流程的部分。

虚拟机 一个理论上的微处理器体系结构，它形成在特定的解释器软件实现下编写应用程序的基础。

4.缩写、符号和术语

本规范使用以下的缩写和符号：

AAC：

应用认证密码

AAR：

应用授权参考

AC:

应用密码

AID：

应用标识号

API：

应用程序接口

ARQC:

授权请求密码

ATM:

自动柜员机

CAD:

读卡设备

CPU:

中央处理单元

CVM:

持卡人身份验证方法

DDOL:

动态数据认证对象列表

EN:

欧洲标准

IC：

集成电路

ICC:

集成电路卡

IEC:

国际电工委员会

IFD:

接口设备

I/O:

输入/输出

ISO:

国际标准化组织

MMDD:

月日

NF:

法国标准

PAN：

主账号

PC:

个人计算机

PDOL:

处理选项数据对象列表

PIN:

个人密码

POS:

服务点终端

pos.:

位置

RFU:

保留将来使用

RID:

注册的应用提供商标识

SW1:

状态字1

SW2:

状态字2

TC：

交易证书

TDOL:

交易证书数据对象列表

UL:

（美国）保险商实验所

YYMM：

年月

YYMMDD:

年月日

本规范使用了如下术语：

专用的 本规范未定义和在本规范范围之外的。

必须 表示一种强制性的要求。

应该 表示一种建议。

第一部分 一般要求

315

1．终端类型和性能

1.1终端类型

正如在“范围”部分所描述，本规范涉及很多种终端。

本规范将终端按以下特征分类：

●工作环境：

有人值守的或无人值守的

●通讯功能：

联机或脱机

●操作控制方：

金融机构、商户或持卡人

在本规范内，联机是指与收单行（或其代理）的联机通讯。

已假定收单行能够与发卡行（或其代理）建立通讯。

终端的类型必须用终端类型变量来指示，终端类型的编码使用附录A中的三种分类。

对有人值守、无人值守的、联机、脱机和操作控制方的解释如下：

有人值守：

服务员（商户或收单行代理）位于交易点并输入相关交易数据。

交易的发生是“面对面地”。

无人值守的：

持卡人在交易点进行交易而没有服务员（商户或收单行代理）的参与。

交易的发生不是“面对面地”。

仅联机：

交易仅能实时联机完成，例如传送一个授权报文。

具有联机能力的脱机：

根据交易特性，交易能被终端脱机或实时联机完成。

它等同于“具有脱机能力的联机”。

仅脱机：

交易仅能被终端脱机完成。

操作控制方：

为终端操作负责的实体，不一定是终端的实际拥有者。

1.2终端性能

本规范内的终端性能在“终端性能和终端附加性能”一章中讨论。

下面这些部分应在终端性能中描述：

l卡片数据输入性能：

表示终端支持的将卡内信息输入到终端的所有方法。

l持卡人身份验证方法（CVM）性能：

表示终端支持的在终端验证持卡人身份的所有方法。

l安全性能：

表示终端支持的所有在终端上验证卡片的方法，以及终端是否能够吞卡。

下面这些部分应在终端附加性能中描述：

l交易类型性能：

表示终端支持的所有交易类型。

l终端数据输入性能：

表示终端支持的输入交易有关数据的所有方法。

l终端数据输出性能：

表示终端打印或显示消息以及终端支持的ISO8859字符集编码表的能力。

描述这些性能的终端性能和终端附加性能变量的位定义在附录A中说明。

1.3终端配置

终端性能和设备部件随终端的用途和物理环境的不同而不同。

下面是几个配置示例。

图1是一个有人值守的终端，其中IC卡接口模块和密码键盘集成在一起，但与POS设备相分离（如电子基金转账终端和电子收银机）。

图1–有人值守终端示例

图2是一个集成多个POS设备的商户主机，它可以有不同的类型和性能。

在本规范中，一组POS设备连接到一台商户主机，可以将它整体上看成是一个“终端”，而不用关心主机和POS设备之间的功能分布。

（终端数据管理需求方面的内容请参看本规范的第六部分）

图3是持卡人控制的终端，它通过一个公共网络连接到商户或收单行主机。

2．功能需求

本册不重复第一册《应用无关的IC卡和终端接口要求》、第二册《安全和密钥管理》和第三册《应用规范》中的内容，但本册描述实现中的问题和这些部分对终端的影响。

这部分使用在规范7.2节描述的标准消息说明下面的交易事件相应显示的消息。

授权响应代码、CVM执行结果和发卡行命令执行结果的用法在本部分说明。

要获得编码方面的信息，请参看附录A。

2.1应用无关的IC卡和终端接口的需求

终端应遵循《应用无关的IC卡和终端接口的要求》中的所有部分。

并且在2.3部分描述的条件下，终端应该支持所有数据元和命令。

2.2安全和密钥管理

终端应该遵循《安全和密钥管理》（第二册）中的所有部分。

并且在2.3部分描述的条件下，终端应该支持所有数据元和命令。

2.3应用规范

终端应遵循第三册《应用规范》。

并且在2.3部分描述的条件下，终端应该支持所有功能。

2.3.1到2.3.9进一步描述《应用规范》中的终端功能。

2.3.1初始化应用过程

当PDOL（处理选项数据对象列表）包含了一个金额域（授权金额或其他金额），商户控制终端（终端类型＝‘2x’）在交易处理到此点时应提供交易金额。

如果还没有获得交易金额，终端应当获取金额，并显示“请输入金额”。

正如在《支付系统IC卡应用规范》所描述的，如果卡响应GETPROCESSINGOPTIONS命令的结果中返回状态字SW1SW2=‘6985’，表明交易不能在该应用中进行，终端应该显示‘不接受’消息，并返回到应用程序选择。

终端应该使这个应用不能被再次选择。

2.3.2数据验证

对不支持无格式数据验证的只联机使用的终端（如同在终端性能部分说明的那样），应当将终端验证结果TVR中的‘未执行数据验证'位设置为‘1’。

其他类型终端应该支持静态数据验证，也可以支持动态数据验证。

（参见第三册《应用规范》）

2.3.3处理限制

如果卡和终端的应用版本不同，终端应继续处理交易。

如果不能继续，终端应该中止交易并显示‘不接受’消息。

当处理应用用途控制（AUC）时，终端必须知道其是否是ATM。

请参考附录A的终端类型获取关于判断是否是ATM的信息。

如果应用用途控制不允许返现（cashback）选项，则支持返现的终端不应该给持卡人提供返现服务。

2.3.4持卡人验证处理

终端支持的CVM在终端性能部分已经做了说明。

除此之外，终端还应该能够识别‘无需CVM’和‘CVM处理失败’这些可能在卡中的CVM列表里出现的CVM代码。

2.3.4.1脱机CVM

当可应用的CVM是一个脱机PIN,终端应该在发出VERIFY命令或GETCHALLENGE命令之前给卡发一个GETDATA命令去获取PIN重试次数。

如果PIN重试次数不可获得，或者IC卡不支持GETDATA命令，终端应该提示输入PIN。

如果PIN重试次数是零，表示不能再试，终端就应该不允许脱机PIN输入。

终端应该设置在终端验证结果中的‘超过PIN限试次数’位为‘1’。

终端不显示任何关于PIN的消息，不设置CVM结果，并根据卡中的CVM列表继续处理持卡人身份验证过程。

如果PIN重试次数不为零，表明还可以重试PIN，终端应该提示输入PIN，如显示‘输入PIN’消息。

如果IC卡执行脱机PIN验证成功，终端应该置CVM结果的第3个字节为‘成功’。

否则，终端不设置CVM结果，并根据卡的CVM列表继续处理持卡人身份验证过程。

2.3.4.2联机CVM

如果可应用的CVM是联机PIN，终端不发送VERIFY命令。

密码键盘应加密输入的PIN，PIN密码在授权或金融交易报文中发送。

即使已经超过了IC卡的PIN限试次数，终端也应允许输入用于联机认证的PIN，

终端将CVM结果的第3字节设置为‘未知’。

2.3.4.3跳过PIN输入

如果卡的CVM列表中的设置要求输入PIN，具有可操作的密码键盘的有人值守的终端可以在几次不成功的PIN尝试之前或之后跳过PIN输入过程1。

如果这样，终端应设置终端验证结果中的‘要求输入PIN，有密码键盘，但未输入PIN’位为‘1’，‘超过PIN限试次数’位不设置为‘1’。

终端应该认为这个CVM不成功，不设置CVM结果，并根据卡中的CVM列表继续处理持卡人身份验证过程。

2.3.4.4签名（纸质）

如果可应用的CVM是签名，终端应该设置CVM结果的第3字节为‘未知’。

交易结束时，终端应打印给持卡人留有签名行的收据。

（要了解支持将签名当作CVM的终端的要求，参看附录A终端性能。

）

2.3.4.5CVM结果

当可应用的CVM是‘无需CVM’时，如果终端支持‘无需CVM’,终端将CVM结果的第3字节设置为‘成功’。

当可应用的CVM是‘CVM处理失败’，终端将CVM结果中的第3字节设置为‘失败’。

终端应设置CVM结果中的第1、2字节分别为上一次执行的CVM的方法代码和条件代码。

如果上一次执行的CVM不成功（CVM结果的第3字节未被置为‘成功’或‘未知’），终端将CVM结果中的第3字节设置为‘失败’。

如果没有执行过CVM（无CVM列表或CVM条件不满足），终端将把CVM结果中的第1字节置为‘未执行CVM’。

2.3.5终端风险管理

除了第三册《应用规范》中对终端风险管理功能的描述外，不管卡内的应用交互特征（AIP）变量的“要执行终端风险管理”位如何设置，终端还可以为每个应用支持一个异常文件。

当终端有一个列出卡及其相关应用的异常文件时，终端就检查当前选择的卡应用是否存在于异常文件中（通过比较PAN和PAN序列号来判断）。

如果在异常文件中找到匹配，终端将TVR中的‘卡在异常文件中出现’位设置位‘1’。

2.3.6终端行为分析

正如第三册《应用规范》中描述，在终端行为分析期间，终端通过比较TVR与终端行为代码（TAC）－拒绝和发卡行行为代码（IAC）－拒绝，终端行为代码（TAC）－联机和发卡行行为代码（IAC）－联机，终端行为代码（TAC）－缺省和发卡行行为代码（IAC）－缺省来决定交易是脱机批准，脱机拒绝或联机处理。

·如果终端决定脱机批准交易，则将“授权响应代码”设置为“脱机批准”。

·如果终端决定脱机拒绝交易，则将“授权响应代码”设置为“脱机拒绝”。

·如果终端决定联机传送交易，不设置“授权响应代码”的值，也不应改变在联机响应消息中返回的“授权响应代码”的值。

2.3.7卡行为分析

根据IC卡对命令GENERATEAPPLICATIONCRYPTOGRAM（AC）（产生应用密文）的响应返回的密文信息数据（CID）的值，终端应如下处理交易：

l如果卡指示接受，终端应该显示“批准”信息,并完成交易。

l如果卡指示拒绝，终端应该显示‘拒绝’信息，并拒绝交易。

l如果卡指示联机处理，终端应该发送授权或金融交易请求（如果不能够，参见本规范的8.2.1节获取关于终端无法联机的异常处理）。

l如果卡指示授权参考（Referral），终端应按照2.5.2节所描述执行授权参考。

l如果卡请求了一个通知消息（Advice），并且终端收单行接口协议支持通知消息，那么：

-如果交易被收集，终端不生成通知消息。

-如果交易未被收集（如一个拒绝），终端应该发送联机通知消息（如果收单行执行了联机数据收集），或者在批数据收集中生成一个脱机通知消息。

l如果卡指示‘服务不被允许’，终端应该显示‘不接受’消息并中止交易。

l如果象第二册《安全和密钥管理》6.6.2一样,复合DDA/AC生成失败，终端应当将TVR中的复合DDA/AC生成位设置为1。

-如果卡在CID对应位中指示返回TC，终端应该拒绝交易。

-如果卡在CID对应位中指示返回ARQC，终端应通过立即执行第二个GENERATEAC命令请求AAC来完成结束交易处理。

2.3.8联机处理

根据联机响应消息中的授权响应代码，终端决定是否接受或者拒绝本次交易，并根据此结果给IC卡发送第二个GENERATEAC命令。

终端通过IC卡返回的密码信息数据知道IC卡执行卡风险管理的结果。

交易证书（TC）表示批准，应用认证密码（AAC）表示拒绝。

当由收单行执行联机数据收集时，如果卡的最终决定是拒绝交易但授权响应代码是“联机批准”，终端应发送一个冲正消息（Reversal）。

2.3.9发卡行脚本处理

终端应能支持授权或金融交易响应中返回的一个或多个发卡行脚本，发卡行脚本的总长度应小于或等于128字节。

终端应能识别响应消息中的发卡行命令的标记。

如果标记是‘71’，终端应在发出第二个GENERATEAC命令之前处理脚本；如果标记是‘72’，终端则应在发出第二个GENERATEAC命令后处理脚本。

对于处理的每条发卡行脚本，终端应在“发卡行脚本结果”中报告脚本标识（如果存在）以及脚本执行结果。

如果卡对某个脚本命令返回错误代码，终端应将“发卡行脚本结果”第1字节的高半字节设置为“脚本处理失败”，低半字节设置为出错脚本命令在发卡行脚本中的序号。

如果卡没有返回错误代码，终端应将“发卡行脚本结果”第1字节的高半字节设置为“脚本处理成功”，低半字节设置为‘0’。

终端应在批数据收集消息（金融记录或者脱机通知）、金融交易确认消息或冲正消息中传送“发卡行脚本结果”。

如果交易没有产生消息（例如交易被拒绝）并且终端支持通知消息，那么终端应生成一个通知消息来传送“发卡行脚本结果”。

2.4功能支持的条件

支持脱机PIN验证的终端应当支持VERIFY命令，支持脱机PIN加密的终端应当支持GETCHALLENGE命令。

不支持脱机PIN验证的终端不必支持VERIFY命令。

支持动态数据验证的终端也应支持静态数据验证。

仅可脱机使用的终端和具有联机能力的脱机终端要支持静态数据验证。

仅可联机使用的终端不必支持动态数据验证，也不必支持静态数据验证。

具体支付系统会对这种情况作出规定。

仅可脱机使用的终端和具有联机能力的脱机终端要支持终端风险管理。

仅可脱机使用的终端和仅可联机使用的终端不必支持随机交易选择。

仅可联机使用的终端不需支持全部终端风险管理功能。

在这种情况下，应该由收单行（或其代理）而不是如第三册“应用规范”所述由终端来处理交易。

换而言之，收单行应该执行其余的终端风险管理功能。

这种情况的具体规则由各支付系统自己定义。

金融机构或商户控制的终端（“终端类型”＝'1x'或'2x'）应支持第三册“应用规范”中描述的终端风险管理功能。

持卡人控制的终端（“终端类型”＝'3x'）不需支持终端风险管理。

2.5其它功能需求

2.5.1金额的输入和管理

交易的金额应通过终端显示器或标签，如自动售货机上的价格标签，或通过在收据上打印的方式显示给持卡人。

当金额通过键盘输入时，终端应当允许在输入过程中显示金额。

服务员或持卡人应能在授权之前更改输入的金额并继续处理交易，或发现金额输入错误而取消交易。

若交易金额在授权前已知，持卡人应能核对最初的或更改过的交易金额。

如在金额输入后，立即输入PIN，则PIN的输入可视为对金额的确认（参见第二册“安全和密钥管理”）。

若非如此，终端应显示“（金额）确认？

”消息以供持卡人确认。

若授权发生在知道最终交易金额之前（例如加油站加油金额，餐馆支付小费前的金额），“授权金额”数据对象代表交易的估计金额，而“交易金额”数据对象代表交易结束时才知道的最终交易金额

如果终端支持返现，并且卡的“应用用途控制”指示交易允许返现，则持卡人应该能够在授权之前单独输入或认可一个返现金额。

在返现允许时，返现金额必须在“其它金额”数据对象中传送。

“授权金额”和“交易金额”中都必须包括购货金额和返现金额（假如有的话）。

当“授权金额”、“交易金额”作为命令数据的一部分被发送到IC卡时，它们应当由隐含的小数点表达（例如，当货币代码是‘826’时，‘123’代表£1.23）。

2.5.2语音参考

人工语音参考处理可以由卡或发卡行发起进行，只有有人值守终端才要求支持语音参考处理。

有人值守的终端应当具有处理语音参考的功能（也就是说，当卡或发卡行要求参考时，终端能显示合适的消息），无人终端不要求支持语音参考。

如果语音参考无法进行，由具体支付系统定义的缺省过程来处理（例如联机处理，脱机批准或脱机拒绝）。

2.5.2.1由卡发起的语音参考

如果卡响应第一个GENERATEAC命令，请求一个语音参考（在“密码信息数据”中示出），有人值守的终端应当向服务员显示“请与你的银行联系”，相应的应用数据如“应用PAN”应当显示或打印给服务员看，以便进行语音参考。

终端应显示相应的信息要求服务员输入数据，指明交易作为语音参考的执行结果被批准或还是拒绝的数据。

服务员可以人为越过语音参考过程，在没有进行语音参考的情况下，批准或拒绝交易，或者强制交易联机进行。

执行了语音参考或跳过后，如果交易被批准，终端应设置“授权响应代码”为“批准（卡发起语音参考后）”。

如果交易被拒绝则设置“授权响应代码”为“拒绝（卡发起语音参考后）”。

终端不发EXTERNALAUTHENTICATE命令而直接向卡发第二个GENERATEAC命令，请求一个TC（批准）或AAC（拒绝）。

如果交易被强制联机（由终端或服务员），终端不设“授权响应代码”，用AAR作为ARQC发送授权或金融交易请求报文。

终端继续进行正常联机交易处理（参看2.3.8部分）。

2.5.2.2由发卡行发起的语音参考

如果授权响应报文中的“授权响