EMV2000 第四册.doc

持卡人、服务员和收单行接口需求第四部分持卡人、服务员和收单行接口需求1. 范围支付系统持卡人、服务员和收单行接口需求定义了接受集成电路（IC）卡的终端的必须、推荐和可选的需求，本文档与应用无关的IC卡和终端接口要求（第一册）、安全和密钥管理（第二册）、应用规范（第三册）是相一致的。对应具体支付系统特定应用的终端需求以及不要求支持互通互用的功能没有包含在本文档中。本文档应用于工作在有人值守或无人值守的操作环境、具有联机或脱机能力、支持交易类型如购物、服务、取现等的所有终端。这里指的终端包括（但不仅限于）ATM、网点终端、无人值守的终端、电子收银机、个人计算机以及POS终端。本文档还特别描述了： 功能方面的要求，与安全和密钥管理和应用规范中类似 一般的物理特性 软件结构（包括软件和数据管理） 持卡人的接口 收单行的接口本文档给出了支持IC卡功能所必须的需求。这些需求不包括具体支付系统和收单行对于支持磁卡的终端所定义的部分。接受IC卡和磁卡的能力可以共存于同一台终端上。本文档假定读者已经熟悉了应用无关的IC卡和终端接口需求、安全和密钥管理及应用规范。本文档面向的读者对象为支付系统成员、终端开发商以及IC卡应用设计人员。遵行强制要求（定义为必须）使终端与应用无关的IC卡和终端接口需求、安全和密钥管理、应用规范以及本文档相一致。推荐要求定义为应该，可选要求定义为可以。显而易见，根据不同的商业环境及用途终端的实现也不同。本文档定义的是应用于终端特定操作环境中的特征和功能需求。本文档没有涉及持卡人和商户操作流程，这些由具体的支付系统规定。本文档不提供完成终端所需的全部细节。具体支付系统和收单行将定义不同情况下的补充需求，以提供终端设备的更详细规范。2. 标准参考下面这些标准被本文档所引用：EMV2000 Version 4.0 2000/12:IC卡支付系统规范：第一册-应用无关的IC卡和终端接口需求EMV2000 Version 4.0 2000/12:IC卡支付系统规范：第二册-安全和密钥管理EMV2000 Version 4.0 2000/12:IC卡支付系统规范：第三册-应用规范ISO 8583:1987银行卡发起的报文交互报文规范金融交易内容ISO 8583:1993金融卡发起的报文交互报文规范ISO 8859:1987信息技术-8位单字节图形编码字符集ISO 9564-1:1991银行业-个人密码管理和安全-个人密码保护原则和技术ISO 9564-2:1991银行业-个人密码管理和安全-个人密码加密认证算法3. 定义如下术语被应用于本文档：应用 卡和终端之间的应用协议及相关的数据集。字节 8 位二进制数。卡 由支付系统定义的支付卡认证机构利用公开密钥和其它相关数据为所有者提供可靠校验的第三方机构。命令 终端发送给IC卡的报文，以启动一个操作或请求IC卡的应答。密码 加密操作的结果异或 二进制无进位加法, 如下结果:0 + 0 = 00 + 1 = 11 + 0 = 11 + 1 = 0功能 由一个或多个命令实现的过程，其执行结果完成了部分或全部交易。集成电路 为执行处理和存储功能而设计的电子器件集成电路（IC）卡 含有一个或多个集成电路的卡片，用来执行处理和存储功能。接口设备 终端上用来插入IC卡的部分，包括机械和电气设备组成部分。内核 每个实现了具体的解释器的终端所必需的一组功能的集合。内核包括设备驱动程序、接口函数、安全与控制功能函数以及将虚拟机器语言移植到现实机器语言所用的软件等。也就是说，内核是虚拟机器在一个特定现实机器上的实现。键盘 数字键，命令键，功能键和（或）字母键（如果需要）按照特定的方式的一种排列。库 一组使用公开接口实现的高级软件函数，提供对终端和（或）应用程序编程的通用支持。磁条 含有磁编码信息的带状物。半字节 一个字节中的高4位或低4位。支付系统 在本规范中指，Europay International S.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:状态字1SW2:状态字2TC：交易证书TDOL:交易证书数据对象列表UL:(美国)保险商实验所YYMM：年月YYMMDD:年月日本规范使用了如下术语：专用的本规范未定义和在本规范范围之外的。必须表示一种强制性的要求。应该表示一种建议。第一部分 一般要求3171终端类型和性能1.1 终端类型正如在“范围”部分所描述，本规范涉及很多种终端。本规范将终端按以下特征分类： 工作环境：有人值守的或无人值守的 通讯功能：联机或脱机 操作控制方：金融机构、商户或持卡人在本规范内，联机是指与收单行（或其代理）的联机通讯。已假定收单行能够与发卡行（或其代理）建立通讯。终端的类型必须用终端类型变量来指示，终端类型的编码使用附录A中的三种分类。对有人值守、无人值守的、联机、脱机和操作控制方的解释如下：有人值守：服务员（商户或收单行代理）位于交易点并输入相关交易数据。交易的发生是“面对面地”。无人值守的：持卡人在交易点进行交易而没有服务员（商户或收单行代理）的参与。交易的发生不是“面对面地”。仅联机：交易仅能实时联机完成，例如传送一个授权报文。具有联机能力的脱机：根据交易特性，交易能被终端脱机或实时联机完成。它等同于“具有脱机能力的联机”。仅脱机：交易仅能被终端脱机完成。操作控制方：为终端操作负责的实体，不一定是终端的实际拥有者。1.2 终端性能本规范内的终端性能在“终端性能和终端附加性能”一章中讨论。下面这些部分应在终端性能中描述：l 卡片数据输入性能：表示终端支持的将卡内信息输入到终端的所有方法。l 持卡人身份验证方法（CVM）性能：表示终端支持的在终端验证持卡人身份的所有方法。l 安全性能：表示终端支持的所有在终端上验证卡片的方法，以及终端是否能够吞卡。下面这些部分应在终端附加性能中描述：l 交易类型性能：表示终端支持的所有交易类型。l 终端数据输入性能：表示终端支持的输入交易有关数据的所有方法。l 终端数据输出性能：表示终端打印或显示消息以及终端支持的ISO 8859字符集编码表的能力。描述这些性能的终端性能和终端附加性能变量的位定义在附录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卡应用规范所描述的，如果卡响应GET PROCESSING OPTIONS 命令的结果中返回状态字SW1 SW2 = 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 命令或 GET CHALLENGE 命令之前给卡发一个 GET DATA 命令去获取PIN重试次数。如果PIN重试次数不可获得，或者IC卡不支持GET DATA命令，终端应该提示输入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.5 CVM结果当可应用的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卡对命令 GENERATE APPLICATION CRYPTOGRAM (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，终端应通过立即执行第二个GENERATE AC命令请求AAC来完成结束交易处理。2.3.8 联机处理根据联机响应消息中的授权响应代码，终端决定是否接受或者拒绝本次交易，并根据此结果给IC卡发送第二个GENERATE AC命令。终端通过IC卡返回的密码信息数据知道IC卡执行卡风险管理的结果。交易证书（TC）表示批准，应用认证密码（AAC）表示拒绝。当由收单行执行联机数据收集时，如果卡的最终决定是拒绝交易但授权响应代码是“联机批准”，终端应发送一个冲正消息（Reversal）。2.3.9 发卡行脚本处理终端应能支持授权或金融交易响应中返回的一个或多个发卡行脚本，发卡行脚本的总长度应小于或等于128字节。终端应能识别响应消息中的发卡行命令的标记。如果标记是71，终端应在发出第二个GENERATE AC命令之前处理脚本；如果标记是72，终端则应在发出第二个GENERATE AC命令后处理脚本。对于处理的每条发卡行脚本，终端应在“发卡行脚本结果”中报告脚本标识（如果存在）以及脚本执行结果。如果卡对某个脚本命令返回错误代码，终端应将“发卡行脚本结果” 第1字节的高半字节设置为“脚本处理失败”，低半字节设置为出错脚本命令在发卡行脚本中的序号。如果卡没有返回错误代码，终端应将“发卡行脚本结果” 第1字节的高半字节设置为“脚本处理成功”，低半字节设置为0。终端应在批数据收集消息（金融记录或者脱机通知）、金融交易确认消息或冲正消息中传送“发卡行脚本结果”。如果交易没有产生消息（例如交易被拒绝）并且终端支持通知消息，那么终端应生成一个通知消息来传送“发卡行脚本结果”。2.4 功能支持的条件支持脱机PIN验证的终端应当支持VERIFY命令，支持脱机PIN加密的终端应当支持GET CHALLENGE命令。不支持脱机PIN验证的终端不必支持VERIFY命令。支持动态数据验证的终端也应支持静态数据验证。仅可脱机使用的终端和具有联机能力的脱机终端要支持静态数据验证。仅可联机使用的终端不必支持动态数据验证，也不必支持静态数据验证。具体支付系统会对这种情况作出规定。仅可脱机使用的终端和具有联机能力的脱机终端要支持终端风险管理。仅可脱机使用的终端和仅可联机使用的终端不必支持随机交易选择。仅可联机使用的终端不需支持全部终端风险管理功能。在这种情况下，应该由收单行（或其代理）而不是如第三册“应用规范”所述由终端来处理交易。换而言之，收单行应该执行其余的终端风险管理功能。这种情况的具体规则由各支付系统自己定义。金融机构或商户控制的终端（“终端类型”1x或2x）应支持第三册“应用规范”中描述的终端风险管理功能。持卡人控制的终端（“终端类型”3x）不需支持终端风险管理。2.5 其它功能需求2.5.1 金额的输入和管理交易的金额应通过终端显示器或标签，如自动售货机上的价格标签，或通过在收据上打印的方式显示给持卡人。当金额通过键盘输入时，终端应当允许在输入过程中显示金额。服务员或持卡人应能在授权之前更改输入的金额并继续处理交易，或发现金额输入错误而取消交易。若交易金额在授权前已知，持卡人应能核对最初的或更改过的交易金额。如在金额输入后，立即输入PIN，则PIN的输入可视为对金额的确认（参见第二册“安全和密钥管理”）。若非如此，终端应显示“（金额）确认？”消息以供持卡人确认。若授权发生在知道最终交易金额之前（例如加油站加油金额，餐馆支付小费前的金额），“授权金额”数据对象代表交易的估计金额，而“交易金额” 数据对象代表交易结束时才知道的最终交易金额如果终端支持返现，并且卡的“应用用途控制”指示交易允许返现，则持卡人应该能够在授权之前单独输入或认可一个返现金额。在返现允许时，返现金额必须在“其它金额”数据对象中传送。“授权金额”和“交易金额”中都必须包括购货金额和返现金额（假如有的话）。当“授权金额”、“交易金额”作为命令数据的一部分被发送到IC卡时，它们应当由隐含的小数点表达（例如，当货币代码是826时，123代表1.23 ）。2.5.2 语音参考人工语音参考处理可以由卡或发卡行发起进行，只有有人值守终端才要求支持语音参考处理。有人值守的终端应当具有处理语音参考的功能（也就是说，当卡或发卡行要求参考时，终端能显示合适的消息），无人终端不要求支持语音参考。如果语音参考无法进行，由具体支付系统定义的缺省过程来处理（例如联机处理，脱机批准或脱机拒绝）。2.5.2.1 由卡发起的语音参考如果卡响应第一个GENERATE AC命令，请求一个语音参考（在“密码信息数据”中示出），有人值守的终端应当向服务员显示“请与你的银行联系”，相应的应用数据如“应用PAN”应当显示或打印给服务员看，以便进行语音参考。终端应显示相应的信息要求服务员输入数据，指明交易作为语音参考的执行结果被批准或还是拒绝的数据。服务员可以人为越过语音参考过程，在没有进行语音参考的情况下，批准或拒绝交易，或者强制交易联机进行。执行了语音参考或跳过后，如果交易被批准，终端应设置“授权响应代码”为“批准（卡发起语音参考后）”。如果交易被拒绝则设置“授权响应代码”为“拒绝（卡发起语音参考后）”。终端不发 EXTERNAL AUTHENTICATE 命令而直接向卡发第二个GENERATE AC命令，请求一个TC（批准）或AAC（拒绝）。如果交易被强制联机（由终端或服务员），终端不设“授权响应代码”，用AAR作为ARQC发送授权或金融交易请求报文。终端继续进行正常联机交易处理（参看2.3.8部分）。2.5.2.2 由发卡行发起的语音参考如果授权响应报文中的“授权响应代码”指示要求服务员执行语音参考，终端应在发出第二个GENERATE AC命令之前向服务员显示“请联系你的银行”。相应的应用数据如“应用PAN”应当显示或打印给服务员看，以便进行语音参考。终端应显示相应的信息要求服务员输入表示交易被批准或拒绝的数据，作为语音参考的执行结果。服务员可以人为越过语音参考过程，在没有进行语音参考的情况下，批准或拒绝交易，或者强制交易联机进行。终端不应修改“授权响应码”。应发出第二个GENERATE AC命令请求TC批准交易或AAC拒绝交易。如果在授权响应报文包含有“发卡行认证数据”，终端可以在人工输入授权数据之前或之后发出EXTERNAL AUTHENTICATE（外部认证）命令。2.5.3 强制交易联机在服务员对持卡人有怀疑的情况下，有人值守的终端可以允许服务员强制交易联机。如果要执行此项功能，应在交易开始时进行。这时，终端应设置“终端验证结果”（TVR）中的“商户强制交易联机”位为1。具体支付系统规则决定是否允许服务员执行此项功能。2.5.4 强制交易接受即使卡返回一个AAC指示该交易被拒绝，有人值守的终端仍可允许服务员强制批准交易。如果出现这种情况，通过发送一个联机金融通知或者在批数据记录之内保存交易数据，以便进行交易结算。终端不修改“授权响应代码”，而应在联机通知或批数据记录中设置表明服务员强制批准交易的指示符。具体支付系统决定是否允许服务员执行此项功能。2.5.5 交易序列计数器终端应维护一个“交易序列计数器”，每执行一个交易终端将该值加1。IC卡和非IC卡交易可以共用一个“交易序列计数器”。该计数器的初始值是1，当计数器的值达到最大值时复位为1。计数器的值不能设置为0。（要了解关于这个数据元的详细情况，请参看第三册应用规范）“交易序列计数器”可以用作交易日志记录或审核，也可以用作应用密码计算的输入。2.5.6 不可预知数终端必须能生成一个“不可预知数”，用作应用密码算法的输入，以保证应用密码计算以及终端风险管理中随机交易选择的输入数据的不可预知性。不可预知数产生算法依照各具体支付系统的规范而定。例如，产生不可预知数的方法之一是对所有先前的ARQC、TC、 AAC和 AAR执行异或运算异或运算是对每个GENERATE AC响应的当前应用密码和存在终端里的前一个异或运算的结果进行的。（要了解关于这个数据元的详细情况，请参看第三册应用规范）2.6 读卡如果终端内没有集成式IC和磁条读卡器，当卡的磁条被读取且服务代码是以2或6开始（表明卡上有IC），终端应显示“用芯片读卡器”提示将卡插入IC读卡器。如果终端内有集成式IC和磁条读卡器，当卡的磁条被读取且服务代码是以2或6开始（表明卡上有IC），终端应使用IC处理交易。2.6.1 IC读卡器接口设备（IFD）应该在插卡槽旁有一示意图，指示如何把卡插入IC读卡器。卡一插入后，终端应显示“请稍候”，提示持卡人或服务员交易正在处理中，不要提前将卡取出。不过当卡插入了接口设备（IFD）后，持卡人应该在交易期间的任何时间都可以得到卡。如果卡无法取到，或者终端锁卡装置锁住了卡，应该有相应的机制（如一个按钮）取回或释放卡，以防终端出现故障，甚至终端掉电，使持卡人无法取回自己的卡。对具有锁卡能力的无人终端，卡被保留在终端内安全的地方（如ATM），可以没有释放卡的功能。一旦卡插入接口设备，持卡人和服务员应不能无意中将卡拔出读卡器。如果在交易完成之前卡被拔出，终端应中止交易，显示“处理错误”，并确保卡和终端不会因此而损坏。（要了解关于交易处理异常中止方面的其他要求，请参看第三册应用规范）2.6.2 异常处理如果有人值守的终端尝试读取IC卡并失败，但成功地读取了磁条，并且磁条上的服务代码表明有IC存在，终端应在交易报文中设置“POS输入方式代码”为“读取磁条，上次交易读IC未成功”这并不意味着终端一定要支持ISO 8583：1987数据元。发卡行或收单行可以定义类似的数据元，具体代码由各支付系统设置。 2.7 日期管理2.7.1 数据认证终端要能正确计算有关数据认证方面的日期（如“证书失效期”），包括2000年、之前和之后的日期。2.7.2 处理限制终端要能正确计算有关处理限制方面的日期（如“应用失效期”、“应用有效期”），包括2000年、之前和之后的日期。2.7.3 数据管理为了确保“交易日期”（当地日期）和“交易时间”（当地时间）的正确，终端要保证它能准确计算、存储和显示跟2000年及以后年份的日期有关的数据域，而不会破坏日期及包括闰年计算等使用的完整性。这一要求对支持时钟的终端和基于联机消息更新日期和时间的终端也同样适用。终端应如下对待2位数字的年份（YY）：l YY范围在00到49之间，就认为是20YYl YY范围在50到99之间，就认为是19YY如果终端将2位的年份YY转换为4位的格式YYYY，也必须使用同样的规则。3. 物理特性物理特性随着终端的用途、交易点的环境（包括安全性）和终端的配置不同而有所差异。3.1键盘终端应该由键盘来输入与交易相关的数据和选择功能操作。键盘要支持以下的一种或多种键： 数字键：09 字母键和特殊键：如A-Z,*,# 命令键：取消、确认，清除 功能键：依赖于应用的键，如选择键、F1、F2、退格和Esc等。键盘也可以由单个按键组成，如售货机上用来选择应用或打印单据的功能键按钮。触摸屏可以被看作是一个键盘（关于其安全需求，请参看第二册安全和密钥管理）。3.1.1 命令键命令键用来控制持卡人或服务员输入的数据的流向。以下是命令键的描述：确认键确认一个动作。取消键取消整个交易，如果没有清除键，则用来取消正在进行的操作。清除键清除先前输入的所有数字和字母。如果绿色、红色或黄色用于按键文字或按键本身，推荐按如下方式分配颜色：确认键绿色取消键红色清除键黄色当命令键水平排列，取消和确认键应该在键盘的最下面一行，并且取消键在最左边，确认键在最右边；当命令键垂直排列，取消键应该在最上边，确认键在最下边。3.1.2 密码键盘如果终端还没有密码键盘，应设计并配置成可外接密码键盘，例如通过一个串口连接。如果终端支持PIN输入，可以由一个单独的键盘用来输入PIN，或者PIN输入与其他交易数据输入使用同一个键盘。PIN键盘应包含数字键和确认、取消键。如果有必要，也可以包括清除键。推荐PIN键盘的数字键的布局应该遵循ISO9564标准，如图4所示。但是持卡人控制的终端，例如个人计算机（PC）可以例外，键盘可以包含一个使用不同布局的数字键盘来输入PIN。一个将取消和确认键放置在最下面一行的例子见图4。键5上应该有一个可触摸到的标记（如一个凹痕或凸起的点），以使视力不佳者知道这是键盘的中间按键，以此推断出其他键的位置。3.2 显示器显示器用来帮助持卡人或服务员监视交易处理流和数据输入，确认交易相关的数据，并选择选项。有人值守的终端必须给服务员提供显示器，也可以在例如有密码键盘时给持卡人提供一个额外的显示器。建议有人值守的终端配备两个独立的显示器，以适应持卡人和服务员使用不同语言以及显示不同信息时的需要。无人终端应该有一个持卡人显示器。作为最低要求，显示器应至少能一次显示32个字符（分两行，每行16个字符），两行应能同时显示出来。为了便于在不同地理区域显示不同语言，终端还应支持图形显示器。支持多应用的终端应该配备一个显示IC卡中存在的“应用优先名称”或“应用标签”供持卡人进行应用选择的显示器。3.3 存储数据保护软件、终端中初始化的数据或者终端的任何其他部分，包括密钥，在软件和数据有效期间不能被删除或修改。如果终端支持批数据记录，则在到下一次与收单行系统进行联机对帐之前，终端中存储的交易和通知记录不能被删除和修改。3.4 时钟仅可脱机使用的终端和具有联机能力的脱机终端必须要有一个带本地日期和时间的时钟。日期用于在数据认证过程和脱机PIN加密过程中检查证书失效期，处理限制过程检查应用失效/有效期。时间用于确保交易识别的唯一性，也可用作应用密码算法的输入。3.5 打印机终端应有打印交易凭证的打印机，打印机要能每行至少打印20个字符（参看本规范的7.4部分）。持卡人控制的终端（终端类型3x）可以没有打印机。3.6 磁条读卡器除了IC卡读卡器，终端还应配备磁条读卡器，支付系统规定不要求的可以除外，这些规定包括了金融机构终端或商户控制终端（终端类型1x或2x）不要求或不允许配置磁条读卡器的情况。持卡人控制的终端（终端类型3x）可以不配备磁条读卡器。磁条读卡器应能够读取整个1磁道和2磁道，并根据支付系统规则作相应的处理。第二部分 软件结构4终端软件结构本章为终端制造厂商在将来的支付系统应用及随后对终端功能的需求方面提供了一个指导。尽管没有这种功能的终端在当前的环境中也能够很好的工作，但结合本章中的软件设计原则所作的改进，会提高终端的使用期限并且给终端提供诸多功能上的优点。4.1 环境的改变在现在的环境中，支付系统的功能支持是在典型的POS终端上通过一种或者两种应用提供的。这些应用基于支付系统卡上的磁条中得到少量数据，卡上所体现的不同主要包含在主机系统中，对终端的软件来说通常是透明的。IC卡以多种不同的应用、支持大量选项的众多数据取代了这种环境。典型的终端将支持多个具有不同相似性程度的应用。应用可以逐年改动，这给终端上软件移植带来额外的挑战。在终端的使用期限里，几乎肯定会增加新的应用。这就有必要高效地向终端增加新应用而不会有改变现有应用的风险。应用的修改和增加应当遵循这样的原则：未影响到的应用不需要再去进行认证。代码应在足够的安全控制下可重用和共享，以便高效、完整地实现移植。通过包含在IC卡中的数据，支付系统之间更多的差异将体现在终端上。这也许（可能将要）具体到地区甚至发卡行这一层，要求终端提供一个函数库让卡选择使用。终端可以只支持可选函数库的一个子集，但终端支持的功能函数越多在市场上也将会更有竞争力。在本规范中，对于所提出的要求，支付系统描述了两个可供选择的软件结构，这两者分别是“应用程序接口(API)”和“解释程序”方法。4.2 应用库应用C无论是API还是解释程序方法，终端都必须有维护应用模块库或者程序库的能力，这些模块或程序可以动态地结合到特定的交易处理中。应用库中的模块可以是完整的应用程序或者是根据终端或卡中数据的指示被调用的函数。在解释程序方法中，这些模块是用在终端上实现的虚拟机指令集写成的代码。而在API方法中，这些模块是与终端体系结构相关的目标代码。在任一种方式下，应用库的这些模块可以根据终端应用软件的逻辑或IC卡内的参考数据的指示来动态调用。外部参考的格式和说明由具体支付系统控制。一个终端可以包含多个库，其中的一些可被所有的应用访问，另一些则可限定于某些特定应用或支付系统。4.3 应用程序接口这部分描述了终端API软件结构，在此软件结构下，应用程序可以通过一个标准接口API使用终端提供的一组基本及常用的函数。API采取函数库的形式，能被终端里所有的应用使用。库里的函数可以被动态地链接进调用它们的应用中。将这些函数作为终端里的一个库来提供有很多优点：l 终端里的每个应用程序不需要包含相同的代码来完成标准的功能。在每个终端中对这些功能只使用代码的一个拷贝，有效地节省了终端内存。l 应用程序不需要考虑具体的终端硬件配置，因为这些在API上对应用程序是透明的。具体终端硬件执行功能的实现已被封装在经过认证的终端库函数代码中。l 新的终端应用程序的认证将基于终端上已认证过的标准化的API函数库上进行，不需要对终端现有的应用程序做再次认证（对单一程序终端则须这样做）。在这种结构下应用程序之间防火墙的验证也大大简化了。用一个单一的函数库建立API时，这个库包括两大类函数：l 在第一册中描述的完成应用选择功能的函数。l 执行基本的常用的终端硬件功能性的函数(如显示、取按键值等)。库里的函数可以调用库中的其他函数。例如：静态数据认证可以用一个终端硬件函数从卡应用中读取数据。库里的函数可以用依赖于终端的目标代码或更通用的虚拟机指令集编写。4.4 解释器4.4.1概念这部分主要描述解释器方案下的一般结构，并简单概述其与未来的支付系统应用环境如何联系。IC卡技术的应用使得在所有受理IC卡的终端上更新相应固件成为必要。解释器作为一种适应未来支付系统要求的软件系统，紧凑、高效、易于维护和升级，有助于实现这种转变。解释器这个名字来源于包含CPU无关的应用程序和插件的终端的一种性能，这些程序和插件在交易过程中被解释执行，以决定终端的行为。一个解释器定义了一个单独的软件内核，可应用于多种终端类型，这个内核产生可在每种CPU类型上实现的一个虚拟机，该虚拟机提供终端I/O驱动、所有底层CPU特定的逻辑驱动以及算法函数。使用标准内核函数的高级库函数、终端程序和支付应用仅需开发和认证一次；之后，它们可以不作改变地运行在其它所有实现了相同虚拟机的类似终端上。因此，解释器带来的一个重要好处就是使所有终端函数的测试和认证过程都变得简单、统一。综上所述，解释器提供了如下几个主要优点：l 提供通用化的支持IC卡的函数内核，在每个终端上只需安装一次。内核的预计使用期限与终端相似（7-10年）。l 多种处理器与终端类型只需一个版本的终端软件内核。因此，对使用一个共同的解释器/虚拟机的一组不同类型的终端，上面的软件库、终端程序和支付应用仅需一次认证和确认。l 终端内核的认证与应用独立，因此，对使用一个共同的解释器/虚拟机的每种终端类型仅需作一次认证。这里终端类型定义为终端CPU和I/O函数的一种特定结构。l 支持CPU无关的插件，这些插件在交易过程中被解释执行以增强终端的行为。CPU无关意味着对代码的认证和确认只需进行一次。4.4.2 虚拟机每个使用解释器方法的终端里的应用软件按照虚拟机方式编写。虚拟机是一个具有标准特征例如定义了地址模式、寄存器、地址空间等的理论上的微处理器。虚拟机在两个区域访问存储器：代码空间和数据空间。所有代码访问只在虚拟机内部进行而不开放给程序。存储器的存取操作只在数据区进行，解释过的程序代码只存在于代码区。没有终端软件能够看到代码区的属性和内容，或试图通过某种手段修改代码区。这个严格的限制，加上完全没有一个符号表，大大增加了程序的安全性。4.4.3 内核内核包含了所有依靠某个特殊平台（CPU和操作系统）而实现的函数。它包括选定的一组命令集，加上一些专门的函数，例如终端I/O支持、程序装载/解释支持。4.4.4 应用代码的可移植性虚拟机仿真可由下面三种方法之一来实现：解释虚拟机指令，将虚拟机语言翻译成可直接执行的“线程代码”形式，或者将它翻译成目标CPU的实际代码。后两种方法以适度的复杂性为代价提供了改进的性能。为每种特定CPU类型而编写的内核使该处理器能够模拟虚拟机。虚拟机的概念使得在大量不同类型CPU上实现高度标准化成为可能并且简化了程序的移植、测试和认证。程序可以被转化成介于程序员使用的高级源程序语言与微处理器所要求的低级机器代码两者之间的一种中间语言，随后被传送到目标终端上，并被处理成一种可执行的形式。4.5 插件和套接字IC卡的功能之一就是：通过结合及管理加密数据和积极参与交易验证过程来提高交易安全性。在这个概念下，支付系统定义了一组过程（即套接字），这些过程可以被程序员插入到应用中（因而受到收单行的控制和支付系统的监督）作为位置标示符以便在交易过程中添加增强代码。套接字可以被放置在已有的终端应用不同位置甚至终端程序自身中。它们用来引用库函数，甚至如果支付系统预见到改变库函数行为方式的需要，也可以出现在库函数里面。套接字初始化成缺省操作。如果终端程序没有进一步的操作定义，缺省方式下这些过程在执行时将不做任何事。插件是可执行的代码，用机器语言或终端所支持的虚拟机指令集写成，可以被插入套接字定义的位置，以增强终端缺省逻辑。插件可以预先存在终端里，根据IC卡中的数据和终端逻辑调用。插件也可以来自于一个输入设备（如IC卡或与终端相连的主机系统），但这只能在支付系统、发卡行、收单行和商户的同意之下进行。如果IC卡插件能够更改套接字的行为或放在程序流中成功进行卡认证之前的位置，则也许会要求一些特殊考虑，以保证程序安全。交易结束时，套接字恢复到初始的应用缺省操作。推荐的终端结构不主张IC卡包含完整的应用，而仅包含一些增强终端已有应用的插件。图六描述了插件和套接字之间的关系：5. 软件管理在不与国家相关法律法规相冲突情况下终端应当支持软件升级。软件升级可以通过网络远程进行或本地下载。软件升级可以在终端应用、终端拥有者或收单行人员的控制之下进行。如果软件升级在终端应用的控制下进行，在接受新的软件之前终端应当：l 认证软件下载者的身份。因为只有由终端厂商、终端拥有者或收单行授权的第三方发放的软件，才可以被下载到终端中。l 验证软件下载的完整性。当这两步测试都成功后，终端应告知下载方软件下载是否成功。为了便于IC卡应用从一个版本升级到另一个，终端应至少能支持IC卡应用的两种版本（由终端的“应用版本号”来标识）。6. 数据管理这一节所列的数据元应在终端上初始化或者可以在交易过程中得到（这些数据的定义见第三册应用规范）。也许还会有附加的数据元需要初始化，例如那些在现在的磁条卡交易中所用的数据。无论何时一个数据元被初始化或更新，数据完整性应该得到保证。存在终端上的数据元必须由下列各方之一控制：l 终端制造商：例如，IFD序列号。l 收单行(或其代理)： 例如，商户类别代码。l 商户：例如，当地日期及时间（可由商户或收单行控制）终端应按如下方式设定：l “终端性能”和“附加终端性能”在终端运行之前初始化。l “终端类型”在安装时初始化。l “终端性能”、“附加终端性能”和“终端类型”不能被无意中或