城市公共交通IC卡业务及技术应用规范（征求意见稿） 第5部分 信息技术接口规范

JT/T xxxxxxxxxXXXXXXXXXXXXXX 发布201x-xx-xx实施201x-xx-xx发布城市公共交通IC卡业务及技术应用规范（征求意见稿）第5部分：信息技术接口规范 The Application Standards of business and technology of City Public Transportation IC Card Part ：Information Technology Interface Specification JT/T xxxxxxxxxJT中华人民共和国xx标准ICS xxxxxxX xx备案号：目 次前 言III引 言V1术语和定义12缩略语 Abbreviations43交易处理说明43.1交易分类说明43.2交易的一般处理流程53.3清分清算处理产生的交易54报文接口说明284.1报文结构284.2报文头284.3报文类型354.4位图364.5报文域说明384.6报文的匹配414.7报文格式说明435文件接口说明485.1文件存取方式说明485.2基本约定565.3跨域交易清算文件列表及相关说明606通讯接口说明736.1系统网络结构736.2系统接入接口746.3通讯接口协议756.4 协议定义 83附录A （规范性附录） 标准代码定义94A.1 入网机构标识码94A.2 应答码94A.3 报文原因码104A.4 拒绝码114 II前 言城市公共交通IC卡业务及技术应用规范分为8个部分： 第1部分：总则； 第2部分：城市公共交通IC卡技术要求； 第3部分：城市公共交通IC卡读写终端技术要求； 第4部分：业务规则规范； 第5部分：信息技术接口规范； 第6部分：通讯报文接口规范； 第7部分：安全规范（密钥系统）； 第8部分：检测规范。本部分为规范的第5部分。本部分按照GB/T 1.1-2009给出的规则起草。本部分由中华人民共和国交通运输部提出。本部分主要起草单位：本部分主要起草人：本部分为首次发布：引 言本部分为城市公共交通IC卡业务及技术应用规范的第5部分，与规范的第1部分、第2部分、第3部分、第4部分、第6部、第7部分和第8部分一起构成城市公共交通IC卡业务及技术应用规范。 VJT/T xxxxxxxxx城市公共交通IC卡业务及技术应用规范第5部分：信息技术接口规范1 术语和定义下列术语和定义适用于本标准。1.1 请求类交易 request transaction从交易的请求方（如：受理方）发送至接收方（如：发卡机构），且等待该交易的响应。接收方接收到交易请求后应直接给予交易批准或拒绝的应答。如果交易的接收方不是该交易的最终接收机构，则接收方负责将交易向下一机构转发。1.2 响应码/应答码 Response Code是接收方接收到的请求或通知后，返回给发送方表示处理结果的代码。1.3 冲正Reversal一种特殊的交易。由报文的发送方发起，用于通知接收方先前一笔授权类或消费类交易没有按预定流程完成，应该取消其处理结果。1.4 存储转发 Store and Forward发送方将报文存放在存储转发队列中，在一定次数内每隔一段时间重复发送。1.5 清分Clearing对交易数据依据机构和交易类型进行分类汇总，并计算结算金额的过程。1.6 清算Settlement指根据清分结果对交易数据进行净额轧差和提交并完成资金划拨的全过程。1.7 结算Settlementof Accounts指完成资金划拨的全过程。1.8 交易Transaction用于完成发起方意图的一个或多个相关报文的集合。1.9 单信息 Single Message指受理方将交易信息提交给发卡机构，然后由转接清算机构以日志进行清算，受理方不必提交清算文件的交易方式。1.10 单信息交易 Single Message Transaction一笔交易被发送一次，同时用于授权、清分和结算。即，授权、清分和结算全部在线发生。1.11 双信息 Dual Message指受理方先将授权请求信息提交给发卡机构，在后来的某个时间再集中将清算信息以清算文件的形式提交给发卡机构的交易方式。1.12 双信息交易 Dual Message Transaction一笔交易被发送两次，第一次仅用于授权，第二次的附加信息用于清分和结算。即，授权实时处理，清分和结算非实时处理。1.13 通知 Advice将已经发生的动作通知有关方的报文，不要求认可。1.14 自主清算Self-Determination Settlement两个机构之间的一种清算约定，当清算由一方发起并以该方的数据为准时，该方称该类交易为自主清算。1.15 非自主清算Unself-Determination Settlement两个机构之间的一种清算约定，当清算由一方发起并以该方的数据为准时，另一方称该类交易为非自主清算。1.16 文件发送方 File Sender在文件收发过程中，将文件传送出去的一方。1.17 文件接收方 File Accepter在文件收发过程中，将文件接收进来的一方。1.18 个人标识码 PINpersonal identification number个人标识码是在联机交易中识别持卡人身份合法性的数据信息，在计算机和网络系统中任何环节都不允许PIN以明文的方式出现。1.19 报文鉴别码 MACmessage authentication code报文鉴别码，是消息来源正确性鉴别的数据。1.20 硬件加密机 HSMhardware and security module硬件加密机，对传输的数据进行加密的外围硬件设备，用于PIN的加密和解密、验证报文和文件来源的正确性以及存储密钥。1.21 SDH Synchronous Digital HierarchySDH即同步数字体系，根据ITU-T的建议定义，它为不同速度的数字信号的传输提供相应等级的信息结构，包括覆用方法和映射方法，以及相关的同步方法组成的一个技术体制。1.22 MSTP Multi-Service Transport PlatformMSTP（基于SDH 的多业务传送平台）是指，基于SDH 平台同时实现TDM、以太网等业务的接入、处理和传送，提供统一网管的多业务节点。1.23 TCP transport control protocol是一种可靠的传输控制协议。本规范中除了指传输控制协议外，还特指各系统中实现TCP协议的协议栈。1.24 通信主机Communications Host通信主机指入网机构进行联机交易处理时，与转接清算机构的通信服务器建立通信连接的通信前置机或业务主机。1.25 长连接 persistent connect长连接是指通信双方连接建立后不再关闭，在通信正常情况下一直保持连通状态。1.26 短连接transitory link短连接是指通信双方每次通信时建立连接，通信结束后关闭连接。1.27 脱机类交易 offline transaction脱机类交易由终端直接承兑或拒绝，因此需要通过受理方事后提交文件或交易，来补全转接清算系统和发卡机构的交易记录并清算。1.28 周期计费各结算单位本金按日清算，手续费逐笔计算，每月、季度、年等周期向发卡机构、转接清算机构、收单方结算一次。1.29 包月计费按照每个各结算单位每月、季度、年等固定费用结算各结算单位手续费，并按比例在发卡、收单和转接清算机构之间分润。1.30 受理方服务机构除收单机构以外，向收单方提供服务的机构。示例：为部省市级结算单位（下简称：各结算单位）提供结算服务的开户银行，提供渠道接入服务的第三方服务机构，提供机具租赁的机具产权机构，提供机具维护服务的机具维护机构等。1.31 发卡机构服务机构除发卡机构以外，向发卡机构提供服务的机构。示例：提供发卡接入服务的发卡接入机构，提供支付工具服务的联名卡合作发卡机构等。1.32 垫付若各结算单位出现清算资金为付差时，则付差资金清算对象应为收单机构，各结算单位的付差资金由收单机构垫付，即称“收单垫付”。1.33 回补因各结算单位付差而造成收单机构资金垫付，待各结算单位后期清算出现正向清算资金后，由转接清算机构扣除收单机构垫付部分资金。1.34 暂扣收单机构根据本机构设定的风险规则，判断当日交易存在风险时，通过转接清算机构外围业务（服务）平台向转接清算机构发出交易暂扣指令，对各结算单位该笔交易清算资金进行挂账处理。1.35 追扣对已经清算的历史交易，在规定期间内（时间可以由转接清算机构参数设置，默认时间为60日内），如果收单机构判断此交易也需要进行资金扣回的，收单机构可通过向清算系统发出交易追扣指令，完成交易追扣，对各结算单位该笔交易清算资金进行挂账处理，资金从各结算单位当日清算资金中扣除。1.36 释放收单机构根据风险规则，判断原挂帐交易风险解除时，将原先存放在本机构的挂帐资金清算给各结算单位。1.37 挂帐收单机构根据风险规则，判断交易存在风险时，先将各结算单位资金暂时存放在本机构，而不清算给各结算单位。挂账资金对于收单机构而言，是暂收的应付清算款项，是收单机构的负债；对于各结算单位而言，是各结算单位的应收款项，是各结算单位的债权。1.38 批量方式批量方式指由各结算单位以文件形式发起交易，收单机构在规定时间内上送转接清算机构，经转接清算机构处理后转发给发卡机构的交易方式。2 缩略语 Abbreviations下列符号和缩略语表示适用于本文件。DES数据加密标准(Data Encryption Standard)IC集成电路(Integrated Circuit)MAC报文鉴别码(Message Authentication Code)MAKMAC密钥(MAC Key)MK主密钥(Master Key)MMK成员主密钥(Member Master Key)POS销售点终端(Point Of Sale)3 交易处理说明3.1 交易分类说明按交易处理流程分类，可以将交易分为脱机类和批量类。其中，对于按交易的功能分类，可以将交易分为金融类、管理及安全控制类、差错处理类和风险控制类等。其中只有金融类交易有单信息和双信息的概念，管理及安全控制、差错处理类和风险控制类不存在单信息和双信息的概念。由于IC卡提供了一些专有的业务功能和交易流程，本规范将在下文中用独立章节描述基于IC卡的特殊应用。3.2 交易的一般处理流程脱机类交易是指交易由终端直接承兑或拒绝，受理方在交易完成之后再提交文件或将脱机消费转为联机报文上送，用以补全转接清算机构和发卡机构的交易记录并清算。另一种脱机交易是指交易通过文件来完成，不存在联机报文。3.3 清分清算处理产生的交易3.1.1 转接清算机构的日期切换通知交易（0820/0830）转接清算机构利用日期切换交易来通知入网机构转接清算机构清算日期的变化。转接清算机构的日期切换交易有两种：日切开始(CutOff Start)、日切结束(CutOff End)。转接清算机构将日期切换交易发送给各入网机构，入网机构接收到该交易后将应答返回给转接清算机构。交易流程为：转接清算机构将日期切换通知发送给各入网机构，入网机构接收到该通知后将应答返回给转接清算机构。当转接清算机构不能将日切通知发送给入网机构或收不到机构的应答时，不进行存储转发，直接丢弃该通知。1转接清算机构发送给入网机构的日切通知（0820）2入网机构发往转接清算机构的应答（0830）图1 转接清算机构的日期切换通知交易流程3.1.2 自主清分清算产生的交易处理流程3.1.2.1 转接清算机构日期切换情况下的报文发送处理流程1转接清算机构向入网机构发送日切开始通知（0820）2入网机构向转接清算机构返回应答报文（0830）3转接清算机构向入网机构发送日切结束通知（0820）4入网机构向转接清算机构返回应答报文（0830）图2 转接清算机构日期切换情况下的报文发送处理流程3.1.2.2 清分清算的文件处理对于单信息方式的入网机构，转接清算机构清分清算处理后将向其下发交易流水文件。对于双信息发卡机构，日切后转接清算机构根据该清算日单转双的交易向发卡机构发送转换后的双信息清算文件。3.1.2.3 转接清算机构清分清算的时序时序指一个功能的执行必须以其他功能的完成为前提，或者一个功能的完成是其他功能继续执行的前提条件。3.1.2.4 自主清算方式的时序配合3.1.2.4.1 清分场次切换时序点表1 清分场次切换时序点控制关系序号交易名称关键功能步骤描述1转接切换前的所有交易请求纳入前一个清分场次切换后的所有交易请求纳入后一个清分场次2清分按交易请求标识的场次进行清分3.1.2.4.2 日切开始时序点的控制步骤日切切换开始时序点的控制关系如下表所示：表2 日切开始时序点的控制步骤序号交易名称关键功能步骤描述1转接日切前的所有交易请求纳入第一天清算日切后的所有交易请求纳入第二天清算，拒绝前一清算日的撤销交易2代授权沿用转接交易的日期划分3清算单信息：按转接结束时标识的日切时间进行清算。双信息：按转接结束时标识的日切时间进行清算4差错1. 日切前必须完成已经提交的差错文件处理；2. 日切前必须完成差错联机通知的转发处理。3.1.2.4.3 日切结束时序点的控制步骤日切结束时序点的控制关系如下表所示：表3 日切结束时序点的控制步骤序号交易名称关键功能步骤描述1转接1. 为了给原交易的后续交易一定的处理缓冲时间，在日切开始点和日切结束点之间设定3分钟的日切窗口，3分钟一到窗口将自动关闭。2. 在日切窗口内到达的所有原始请求交易纳入第二天清算，日切窗口内正在处理的所有应答交易、冲正和撤销交易的清算日期沿用原交易的清算日期。若这些交易在日切窗口内没有处理完，则按交易失败处理。日切窗口内，拒绝所有前一个清算日期的撤销交易（可隔日上送的撤销交易除外）。3. 日切结束后，拒绝所有前一清算日期的冲正交易；3.1.3 交易的异常处理流程3.1.3.1 概述本章主要约定入网机构之间进行应用交互的过程中对各种异常情形的处理方法。可能出现的异常情形主要包括：报文格式错误；数据安全保密错误；通信异常；终端操作错误。3.1.3.2 异常处理原则3.1.3.2.1 原则1请求类报文中预授权类报文和交易类报文，在出现异常时以冲正通知报文取消原交易。异常情况为：机构无法将交易的承兑响应转发至交易的发送方时；收到交易发送方的冲正通知时；当一个请求类报文超时未收到应答时；当收到迟到的对请求报文的承兑应答时。3.1.3.2.2 原则2入网机构不能正确发送冲正通知时，应进行存储转发。3.1.3.2.3 原则3入网机构在收到冲正通知时，应匹配原交易。若原交易成功，则取消原交易，返回冲正成功应答(Response Code为00)并参与清算。否则应根据情况给出不同的拒绝码。发卡机构必须严格处理好重复冲正问题，以免发生账务信息混乱现象。3.1.3.2.4 原则4除网络管理类通知（包括签到/签退、日切开始、日切结束等）外，城市公共交通IC卡系统或入网机构应利用存储转发机制将通知送达接收方。3.1.3.3 报文格式错误本节约定入网机构对所接收的报文的判断及处理，在此只定义报文中数据元的语法错或语义错。3.1.3.3.1 报文语法错误语法错误是指：所收到的报文中，数据取值范围或数据类型不符合报文标准。这一类错误如发生在请求报文或通知报文中，城市公共交通IC卡系统会将原始请求或通知报文原样返回，并在返回的新增报文头中置入相应的拒绝码，该拒绝码与城市公共交通IC卡系统检测到的第一个报文语法错误相对应。这一类错误如发生在授权或交易承兑的应答报文中，若城市公共交通IC卡系统或受理方检查出此类错误，则丢弃该应答报文，待超时后发送冲正通知。若发生在通知类（网络管理类通知除外）交易应答报文中，则通知的发送方存储转发该通知报文。数据取值范围或数据类型错误代码的详细定义请参见报文接口规范的附录A 拒绝码。3.1.3.3.2 报文语义错误报文语义错误是指：报文中的数据尽管在语法上符合银行卡信息交换的报文标准，但是在语义上对交易无效（见表4数据内容无效错误表）。这类错误若发生在一般请求报文或通知报文中，城市公共交通IC卡系统将直接向受理方发送拒绝的应答，其中的应答码见下表。表4 数据内容无效错误表位号数据内容错误描述应答码4Amount of transaction 为 013冲正、撤销和差错处理交易请求中可能出现的数据内容无效情况如下表所示：表5 冲正、撤销和差错处理交易请求的数据内容无效表数据内容错误描述应答码交易请求未能与原始交易相匹配25交易未能与原始交易金额相一致64交易未能与原始交易卡号相一致14交易未能与原始交易终端相一致97交易的原始交易未承兑12交易应答未能与冲正请求相匹配记载日志，以后备查。这类错误若发生在交易承兑的应答报文中，则城市公共交通IC卡系统丢弃该应答报文，待超时后发送冲正通知。若发生在通知类（网络管理类通知除外）交易应答报文中，则通知的发送方存储转发该通知报文。3.1.3.3.3 数据安全保密错误本节是对城市公共交通IC卡系统、受理方及发卡机构在交易过程中所发生的数据安全保密错误的处理约定。这些错误的现象为：l 请求报文中MAC计算错误；l 通知报文中MAC计算错误；l 对请求的应答报文中MAC错误；l 对通知的应答报文中MAC错误。3.1.3.3.4 请求报文中MAC计算错误错误现象：在报文的接收方一侧检测到MAC不匹配。城市公共交通IC卡系统处理：向受理方发送拒绝应答，其中，Response Code=A0。发卡机构处理：向城市公共交通IC卡系统发送拒绝应答，其中，Response Code=A0。3.1.3.3.5 通知报文中MAC计算错误错误现象：在报文的接收方一侧检测到MAC不匹配。城市公共交通IC卡系统处理：向受理方发送拒绝应答，其中，Response Code=A0。发卡机构处理：向城市公共交通IC卡系统发送拒绝应答，其中，Response Code=A0。3.1.3.3.6 对请求的应答报文中MAC错误一般交易错误现象：在报文的接收方一侧检测到MAC不匹配。城市公共交通IC卡系统处理：向受理方发送拒绝应答报文。若为承兑的交易，则还需向发卡机构引发冲正报文冲正原因（即60域中的Reason Code）为4362，该笔冲正参与对账。受理方处理：向终端发送拒绝应答报文，若为承兑的交易，则还需向城市公共交通IC卡系统引发冲正报文，冲正原因码为4355，该笔冲正参与对账。3.1.3.3.7 对通知的应答报文中MAC错误错误现象：在报文的接收方一侧检测到MAC不匹配。城市公共交通IC卡系统处理：记载日志，以后备查分析。3.1.3.3.8 通信异常本节叙述了入网机构对交易过程中所发生的通信故障的处理约定。这些通信故障的现象为：发送请求报文失败；发送对请求报文的应答报文失败；发送请求报文后，收不到应答报文；发送冲正通知报文失败；发送对冲正通知报文的应答报文失败；发送冲正通知报文后，收不到应答报文；收到迟到的对请求报文的应答报文。这些故障根据一笔完整交易所需经过的各个环节的先后次序进行排列。当入网机构根据上述故障现象检测到与其他入网机构的通信异常时，入网机构的处理原则如下：入网机构每隔一定时间发一次0820回响测试（echo test）报文，测试是否恢复连接；丢弃未发出的响应报文；对需要转发的请求报文，则以“91 (发卡机构或城市公共交通IC卡系统不能操作)”向受理方发拒绝应答；对通知报文(022X、042X)，则存入存储转发队列中，待连接恢复后发出。当收到“echo test”应答（0830）后，表示连接恢复，入网机构将存储转发队列中的报文依次发送出去。在以下的故障处理中，不再重复通信异常到恢复的处理过程。3.1.3.3.9 单次故障本节的异常处理编排次序按照交易报文的流转次序编写。对于一些简单步骤没有进行特别的描述，只针对特殊、难点步骤进行了详细说明。在流程描述之前，首先介绍一些容易混淆的概念。发送方无法发送请求和发送方发送的请求在中途丢失的区别“发送方无法发送请求”指发送方因为通讯故障不能将请求发出，这种现象发送方是能够探测知道的，在下文的流程图中用“x”表示。“发送方发送的请求在中途丢失”指发送方发出的请求因为通讯故障在中途丢失，这时发送方并不能探测知道该请求出了什么状况，它所知道的只是没有收到接收方的应答，因此最终反映出的现象是交易超时，在下文的流程图中用“？”表示。由于这两种现象的最终反映情况不同，导致它们的处理也不同，具体可参见下文的相关描述。接收方没有收到发送方请求、接收方无法发送应答和接收方的应答在中途丢失的区别这三种情况对发送方而言处理都是一样的，但接收方反映出的情况却不一致。“接收方没有收到请求”的情况是接收方没有收到原始交易请求。“接收方无法发送应答”的情况是接收方因为通讯故障不能将应答发出，这种现象接收方是能够探测知道的。“接收方的应答在中途丢失”的情况是因为通讯故障其应答在中途丢失，但这种现象接收方是不能够探测知道的。由于这三种现象的最终反映情况不同，因此接收方的处理也是不同的，具体可参见下文的相关描述。受理方无法转发来自终端的请求故障现象：因通信故障，受理方不能向城市公共交通IC卡系统转发请求2。受理方处理：受理方直接向终端发送拒绝应答3。受理方无法转发来自终端的请求城市公共交通IC卡系统收不到请求故障现象：因通信故障，受理方的请求2在中途丢失，受理方因收不到城市公共交通IC卡系统的应答而引起交易超时。受理方处理：如果是交易请求，则向终端发送超时引起的拒绝应答3，同时向城市公共交通IC卡系统发送冲正4，其Reason Code为4354，该笔冲正不参与清算。城市公共交通IC卡系统处理：向受理方发送冲正的拒绝应答5，其中，Response Code为25，该笔冲正不参与清算。城市公共交通IC卡系统收不到请求城市公共交通IC卡系统不能向发卡机构转发请求故障现象：因通信故障，城市公共交通IC卡系统不能把受理方的请求2转发至发卡机构。城市公共交通IC卡系统处理：向受理方发送拒绝请求的应答4，其中，Response Code为91。城市公共交通IC卡系统不能向发卡机构转发请求发卡机构收不到请求故障现象：因通信故障，城市公共交通IC卡系统的请求3在中途丢失，城市公共交通IC卡系统因为收不到发卡机构的应答而引起交易超时。城市公共交通IC卡系统处理：超时后向受理方发送拒绝的应答4，如果是金融交易请求，则还需向发卡机构发送冲正报文5，其中，Reason Code为4361，该笔冲正不参与清算。发卡机构处理：向城市公共交通IC卡系统发送冲正的拒绝应答6，其中，Response Code为25，该笔冲正不参与清算。发卡机构收不到请求发卡机构不能向城市公共交通IC卡系统发送对请求的应答。故障现象：因通信故障，发卡机构不能向城市公共交通IC卡系统发送对请求的应答4。发卡机构处理1：如果是交易请求，且已承兑，则作内部冲正，该笔冲正参与清算。城市公共交通IC卡系统处理：向受理方发送超时引起的拒绝请求的应答5，其中，Response Code为98。如果是交易请求，则还需向发卡机构发送冲正7。其中，Reason Code为4361。发卡机构处理2：向城市公共交通IC卡系统返回冲正的拒绝应答8，该笔冲正不参与清算。发卡机构不能向城市公共交通IC卡系统发送对请求的应答城市公共交通IC卡系统收不到发卡机构的应答故障现象：城市公共交通IC卡系统在向发卡机构转发请求3后，收不到发卡机构的应答4，即检测到超时。城市公共交通IC卡系统处理：向受理方发送超时引起的拒绝请求的应答5，其中，Response Code为98。如果是金融交易请求，则还需向发卡机构发送冲正7。其中，Reason Code为4361。原交易和冲正交易都不参与清算。发卡机构处理：向城市公共交通IC卡系统返回冲正应答8，发卡机构对该笔冲正是否参与清算视发卡机构收到该冲正时原交易是否承兑而定。若原交易已承兑则该笔冲正参与清算，否则该笔冲正不参与清算。城市公共交通IC卡系统收不到发卡机构的应答城市公共交通IC卡系统收到发卡机构迟到的承兑应答故障现象：城市公共交通IC卡系统检测到发卡机构超时，向受理方发送拒绝的应答4后，并按照0进行后续处理后，收到来自发卡机构迟到的承兑应答6。城市公共交通IC卡系统处理：再次向发卡机构发送冲正通知7，其中，Reason Code为4360。该笔冲正不参与清算。发卡机构处理：向城市公共交通IC卡系统返回冲正应答8，该笔冲正参与清算。城市公共交通IC卡系统收到发卡机构迟到的承兑应答城市公共交通IC卡系统不能向受理方转发对请求的应答故障现象：因通信故障，城市公共交通IC卡系统不能向受理方转发发卡机构对请求的应答5。城市公共交通IC卡系统处理1：如果是交易请求，且已承兑，则向发卡机构发送冲正通知7，其中，Reason Code为4363。发卡机构处理：向城市公共交通IC卡系统返回冲正应答8，如果是交易请求，且已承兑，则该笔冲正参与清算。受理方处理：向终端发送超时引起的拒绝请求的应答6。如果是交易请求，则还需向城市公共交通IC卡系统发送冲正通知9，其中，Reason Code为4354。城市公共交通IC卡系统处理2：向受理方发送冲正应答10，该笔冲正不参与清算。城市公共交通IC卡系统不能向受理方转发对请求的应答城市公共交通IC卡系统收到受理方发送的早冲正故障现象：在正常的超时时段内，城市公共交通IC卡系统未收到发卡机构的应答就先收到受理方的冲正通知4。城市公共交通IC卡系统处理：向受理方返回冲正应答5，Response Code为“00”。，并向发卡机构发送冲正通知6。发卡机构处理：向城市公共交通IC卡系统返回冲正应答7，发卡机构对该笔冲正是否参与清算视发卡机构收到该冲正时原交易是否承兑而定。若原交易已承兑则该笔冲正参与清算，否则该笔冲正不参与清算。城市公共交通IC卡系统处理2：在收到发卡机构返回的原交易的应答8后，若该应答为承兑应答，则向发卡机构再次发冲正9，Reason Code为4360。如果原始交易未承兑，则城市公共交通IC卡系统直接丢弃该应答。发卡机构处理2：向城市公共交通IC卡系统返回冲正应答10。城市公共交通IC卡系统收到受理方发送的早冲正受理方收不到城市公共交通IC卡系统的应答故障现象：受理方在向城市公共交通IC卡系统发送请求2后，收不到城市公共交通IC卡系统的应答5，即检测到超时。受理方处理：向终端发送超时引起的拒绝请求的应答6，如果是交易请求，则还需向城市公共交通IC卡系统发送冲正通知7。其中，Reason Code为4354。该笔冲正不参与清算。城市公共交通IC卡系统处理：收到冲正请求7后，查原始请求的应答报文，如果发卡机构已承兑，则向发卡机构发送冲正通知9，其中，Reason Code为4354。并返回给受理方应答码为00的冲正应答报文。该笔冲正参与清算。如果发卡机构未承兑，则直接向受理方发送冲正应答报文8。其中应答码为12。该笔冲正不参与清算。发卡机构处理：向城市公共交通IC卡系统返回冲正应答10，对发卡机构该笔冲正参与清算。受理方收不到城市公共交通IC卡系统的应答受理方从城市公共交通IC卡系统收到迟到的承兑应答故障现象：受理方检测到城市公共交通IC卡系统超时，并向终端发送拒绝的应答5后，同时按照0执行了后续操作以后又收到来自城市公共交通IC卡系统的迟到的承兑应答6。受理方处理：再次向城市公共交通IC卡系统发送冲正通知7，其中，Reason Code为4353。该笔冲正参与清算。城市公共交通IC卡系统处理：城市公共交通IC卡系统收到冲正请求后，立即给予受理方应答8。该笔冲正不参与清算。受理方从城市公共交通IC卡系统收到迟到的承兑应答受理方不能向终端发送操作命令故障现象：因通信故障，受理方不能向终端发送操作命令6。受理方处理：如果是金融交易请求，且已承兑，则向城市公共交通IC卡系统发送冲正通知7，其中，Reason Code为4356。该笔冲正参与清算。城市公共交通IC卡系统处理：城市公共交通IC卡系统收到冲正通知后，立即给予受理方应答8。并向发卡机构发送冲正通知9，其中，Reason Code为4356。该笔冲正参与清算。发卡机构处理：向城市公共交通IC卡系统返回冲正应答10，对发卡机构该笔冲正也参与清算。受理方不能向终端发送操作命令3.1.3.3.10 双重故障城市公共交通IC卡系统不能向受理方发送拒绝的应答故障现象：因检测到发卡机构通信故障，城市公共交通IC卡系统向受理方发送对交易请求拒绝的应答3，但由于另遇通信故障使发送应答失败。城市公共交通IC卡系统处理：丢弃应答报文，不需向发卡机构发送冲正通知。受理方处理：检测到城市公共交通IC卡系统超时，向终端发送拒绝请求的应答。如果是金融交易请求，则向城市公共交通IC卡系统发送超时冲正5，其中，Reason Code为4354。城市公共交通IC卡系统收到冲正通知后，立即给予受理方拒绝应答6，其中应答码为12。该笔冲正对受理方和城市公共交通IC卡系统均不参与清算。城市公共交通IC卡系统不能向受理方发送拒绝的应答城市公共交通IC卡系统不能向发卡机构发送冲正通知故障现象：因检测到通信故障，城市公共交通IC卡系统向发卡机构发送冲正通知7见：0城市公共交通IC卡系统不能向受理方转发对请求的应答；0城市公共交通IC卡系统收到发卡机构迟到的承兑应答。但由于另遇通信故障，使发送冲正失败。城市公共交通IC卡系统处理：将未发出的冲正存入存储转发队列中，待连接恢复后重发。城市公共交通IC卡系统不能向发卡机构发送冲正通知受理方不能向城市公共交通IC卡系统发送冲正通知故障现象：受理方因检测到上一次通信故障而向城市公共交通IC卡系统发送冲正通知7见：0受理方不能向终端发送操作命令；0受理方从城市公共交通IC卡系统收到迟到的承兑应答，但由于再遇通信故障使受理方发送冲正失败。受理方处理：将未发出的冲正通知存入存储转发队列中，待连接恢复后重发。受理方不能向城市公共交通IC卡系统发送冲正通知3.1.3.3.11 终端操作错误本节约定受理方和城市公共交通IC卡系统对终端操作错误的处理约定，在此，终端错误仅指终端不能正确执行主机发送的命令，即对交易的最终处理。3.1.3.3.12 无通信故障终端引发冲正故障现象：终端因无法正常操作，向受理方发送出错状态受理方处理：在冲正通知中，Reason Code=4351表示终端上交易不成功。终端引发冲正受理方、城市公共交通IC卡系统、发卡机构三方对于该冲正交易均参与清算。3.1.3.3.13 通信故障受理方不能向城市公共交通IC卡系统发送终端操作错误引起的冲正故障现象：因通信故障，受理方不能向城市公共交通IC卡系统发送终端操作出错引起的冲正通知9。受理方处理：将冲正通知存入存储转发队列中，待连接恢复后重发。受理方不能向城市公共交通IC卡系统发送终端操作错误引起的冲正表6 异常处理中使用的原因码原因码说明4351终端引发冲正（全额）4352终端引发冲正（部分）4353受理方收到城市公共交通IC卡系统迟到的应答4354受理方检测到超时4355受理方检测到应答报文的MAC不对4356受理方不能向终端发操作命令4360城市公共交通IC卡系统收到发卡机构迟到的应答4361城市公共交通IC卡系统等发卡机构应答到超时4362城市公共交通IC卡系统检测到发卡机构应答报文的MAC不对4363城市公共交通IC卡系统不能向受理方转发发卡机构应答报文3.1.3.4 特殊交易异常处理流程本节集中描述基于电子钱包标准的IC卡圈存交易。本节的异常处理编排次序按照交易报文的流转次序编写。对于一些简单步骤没有进行特别的描述，只针对特殊、难点步骤进行了详细说明。在某些情况下，城市公共交通IC卡系统的处理虽然相同，但受理方和发卡机构的处理却各有不同。“发送方无法发送请求”和“发送方发送的请求在中途丢失”；“接收方没有收到发送方请求”、“接收方无法发送应答”、“接收方的应答在中途丢失”。3.1.3.4.1 IC卡电子现金应用指定账户圈存/现金充值交易指定账户圈存交易出现异常时，采用冲正的方式，处理流程及原则请参见本版标准中的3.1.3.3.9单次故障。现金充值交易相当于存款，考虑到圈存交易必须由终端承兑，因此不能发送确认通知，只能发送冲正通知，若终端写卡不成功，终端也应发送冲正。3.1.3.4.2 IC卡电子现金应用非指定账户圈存交易处理原则如下：（1）终端、受理方均能发起冲正；（2）城市公共交通IC卡系统只对转出方发起冲正；（3）城市公共交通IC卡系统不对电子钱包行做任何操作。受理方无法转发来自终端的请求故障现象：因通信故障，受理方无法向城市公共交通IC卡系统转发终端的请求2。受理方处理：直接向终端发送拒绝应答3。城市公共交通IC卡系统收不到请求故障现象：因通信故障，受理方的请求2在中途丢失，受理方因为收不到城市公共交通IC卡系统的应答而引起超时。受理方处理：受理方向终端发送拒绝应答，Response Code为98。同时向城市公共交通IC卡系统发送冲正4，Reason Code为4354。该笔冲正不参与清算。城市公共交通IC卡系统处理：城市公共交通IC卡系统直接返回应答5，Response Code为25，该笔冲正不参与清算。城市公共交通IC卡系统不能向转出方转发请求故障现象：因通信故障，城市公共交通IC卡系统不能把受理方的请求2转发至转出方。城市公共交通IC卡系统处理：向受理方发送拒绝请求的应答4，其中，Response Code为91，域121.1为A。转出方收不到请求故障现象：因通信故障，城市公共交通IC卡系统的请求3在中途丢失，城市公共交通IC卡系统因为收不到转出方的应答而引起交易超时。城市公共交通IC卡系统处理：超时后向受理方发送拒绝的应答4，同时向转出方发送冲正报文5，其中，Reason Code为4361，该笔冲正不参与清算。转出方处理：向城市公共交通IC卡系统发送冲正的拒绝应答6，其中，Response Code为25，该笔冲正不参与清算。受理方处理：向终端发送拒绝应答7。转出方不能向城市公共交通IC卡系统发送对请求的应答故障现象：因通信故障，转出方不能向城市公共交通IC卡系统发送对请求的应答4。城市公共交通IC卡系统处理：向受理方发送超时引起的拒绝请求的应答5，其中，Response Code为98。同时还需向转出方发送冲正7。其中，Reason Code为4361。8为转出方收到7后的应答。该笔冲正不参与清算。转出方处理：如果已承兑，则作内部冲正，该笔冲正参与清算。城市公共交通IC卡系统收不到转出方的应答故障现象：城市公共交通IC卡系统在向转出方转发请求3后，收不到转出方的应答4，即检测到超时。城市公共交通IC卡系统处理：向受理方发送超时引起的拒绝请求的应答5，其中，Response Code为98。同时需向转出方发送冲正7。其中，Reason Code为4361。8为转出方收到7后的应答，该笔冲正不参与清算。转出方处理：转出方对该笔冲正是否参与清算视转出方收到该冲正时原交易是否承兑而定。若原交易已承兑则该笔冲正参与清算，否则该笔冲正不参与清算。城市公共交通IC卡系统收到转出方迟到的应答故障现象：城市公共交通IC卡系统检测到转出方超时，向受理方发送拒绝的应答4后，并按照0进行后续处理后，收到来自转出方迟到的应答6。城市公共交通IC卡系统处理：若该迟到的应答为承兑的应答，城市公共交通IC卡系统再次向转出方发送冲正通知7，其中Reason Code为4360，表示城市公共交通IC卡系统收到转出方迟到的应答。如果该迟到的应答为非承兑的应答，直接丢弃该应答。城市公共交通IC卡系统收到迟到的承兑应答后发送的冲正将不参与清算。发卡机构处理：向城市公共交通IC卡系统返回冲正应答8。若收到冲正时原交易已承兑，则该笔冲正参与清算，否则该冲正不参与清算。城市公共交通IC卡系统无法将交易请求传递给转入方故障现象：因通信故障，城市公共交通IC卡系统无法将交易请求5发送给转入方。城市公共交通IC卡系统处理：向受理方发送拒绝请求的应答6，其中Response Code为91，域121.1为B。同时向转出方发送冲正通知8，其中，REASON CODE为4364。该笔冲正参与清算。转出方处理：向城市公共交通IC卡系统返回冲正应答9。该笔冲正参与清算。转入方收不到请求故障现象：因通信故障，城市公共交通IC卡系统的请求5丢失，城市公共交通IC卡系统等待转入方的应答超时。城市公共交通IC卡系统处理：超时后向受理方发送拒绝应答6，此时Response Code为98。同时向转出方发送转出冲正8，其中，REASON CODE为4361。该笔冲正参与清算。转出方处理：向城市公共交通IC卡系统返回冲正应答9。该笔冲正参与清算。转入方无法将应答报文传递给城市公共交通IC卡系统故障现象：因通信故障，转入方不能向城市公共交通IC卡系统发送对请求的应答6。城市公共交通IC卡系统处理：超时后向受理方发送拒绝应答7，此时Response Code为98。同时向转出方发送转出冲正9，其中Reason Code 为4361。该笔冲正参与清算。转出方处理：向城市公共交通IC卡系统返回冲正应答10。该笔冲正参与清算。转入方处理：由于这里的转入方只是一个虚拟账户，转出金额只是在这里过渡一下，金额最终要到达卡片。转入方交易标识为不清算，不参与对帐，不对该笔账务做处理，转入方通过日终对帐进行账务调整处理，就可保证账务的平衡。账务情况分析：由于城市公共交通IC卡系统拒绝了受理方和终端，因此，终端不会写卡，卡上金额不变。而城市公共交通IC卡系统也冲掉了转出方的金额，因此，转出方账务平衡。转入方通过日终核对账务，账务也是平衡。总体分析下来，该种情况账务平衡。城市公共交通IC卡系统收不到转入方的应答故障现象：因通信故障，城市公共交通IC卡系统收不到转入方的应答6。城市公共交通IC卡系统收到转入方迟到的应答故障现象：城市公共交通IC卡系统检测到转入方超时，向受理方发送拒绝应答6后，同时按照执行了后续操作以后又收到来自转入方迟到的应答8。城市公共交通IC卡系统处理：丢弃该应答，不做任何处理（是否特殊标志）。如转入方帐务不平，日终城市公共交通IC卡系统发送对帐文件，转入方冲账。城市公共交通IC卡系统不能向受理方转发对请求的应答故障现象：因通信故障，城市公共交通IC卡系统不能向受理方转发转入方的请求应答7。城市公共交通IC卡系统处理：城市公共交通IC卡系统向转出方发送转出冲正，其中Reason Code 为4363。该笔冲正参与清算。转入方交易标识为不清算，不参与对帐。转出方处理：返回应答9，该笔冲正参与清算。受理方处理：受理方超时后，直接向终端发送拒绝应答12，Response Code为98。同时向城市公共交通IC卡系统发送冲正10，Reason Code为4354，城市公共交通IC卡系统收到该冲正后直接应答。该冲正不参与清算。受理方收不到城市公共交通IC卡系统的应答故障现象：因为通信故障，受理方没有收到城市公共交通IC卡系统的应答7。受理方处理：受理方超时后直接向终端发送拒绝应答10，Response Code为98。同时向城市公共交通IC卡系统发送冲正通知8，Reason Code为4354，城市公共交通IC卡系统收到后给予应答9。该冲正不参与清算。城市公共交通IC卡系统处理：向转出方转发送冲正通知11，Reason Code为4354。该冲正参与清算，转入方交易标识为不清算，不参与对帐。转出方处理：返回冲正应答12，该冲正参与清算。受理方从城市公共交通IC卡系统收到迟到的应答故障现象：受理方检测到城市公共交通IC卡系统超时，并向终端发送拒绝信息7，所述操作后，则收到来自城市公共交通IC卡系统的迟到应答8。受理方处理：直接丢弃该应答。受理方不能向终端发送操作命令故障现象：因通信故障，受理方不能向终端发送操作命令8。受理方处理：向城市公共交通IC卡系统发送冲正通知9，Reason Code为4356。城市公共交通IC卡系统收到后给予应答10。该冲正参与清算。城市公共交通IC卡系统处理：向转出方转发转出冲正11，Reason Code为4356。该冲正参与清算，转入方交易标识为不清算，不参与对帐。转出方处理：转出方返回应答12，该笔冲正参与清算。终端处理：超时后，向受理方发送冲正，Reason Code为4351，受理方收到后直接给予应答14，该冲正不参与清算。终端接收不到受理方发送的操作命令故障现象：因通信故障，受理方发送的应答8在中途丢失，终端会超时。终端处理：超时后，向受理方发送冲正9，Reason Code为4351，受理方收到后直接给予应答10，该冲正不参与清算。受理方处理：向城市公共交通IC卡系统转发冲正通知11，Reason Code为4356。城市公共交通IC卡系统收到后给予应答12。该冲正参与清算。城市公共交通IC卡系统处理：向转出方转发转出冲正13，Reason Code为4356。该冲正参与清算，转入方交易标识为不清算，不参与对帐。转出方处理：转出方返回应答14，该笔冲正参与清算。终端写卡不成功故障现象：因终端原因，写卡不成功。转入方拒绝转入交易故障现象：转入方拒绝转入交易。城市公共交通IC卡系统处理：向受理方发送拒绝应答7，同时向转出方发送转出冲正9，Reason Code为4366，该冲正参与清算，转入方交易标识为不清算，不参与对帐。转出方处理：返回应答10，该冲正参与清算。4 报文接口说明4.1 报文结构4.1.1 报文结构说明联机交易报文包含四个组成部分，依次是：报文头、报文类型标识符、位图和报文域。其结构如图3所示：报文头报文类型标识符位图报文域图3 报文结构报文头是报文的第一个数据元素，主要记录了报文的长度、路由、批次号等基本信息。报文类型标识符是报文的第二个数据元素，是最高级别报文类型定义，定义了报文一般性分类，比如是交易类报文还是管理类报文。位图定义了哪些报文域会出现在报文中。位图区可以包含一个位图也可以包含两个位图。位图个数的选择根据交易类型而定。IC卡交易将用到55域中定义的IC卡特征信息域。位图一定义域2到域64，位图二定义域66到域128。报文域构成了报文的主体，其中大部分由ISO 8583定义，其它域由城市公共交通IC卡系统自定义并由城市公共交通IC卡系统使用。报文域的具体定义参见第4.5章内容。4.1.2 报文结构分析报文结构如图4所示：图4 报文结构4.2 报文头本节描述了报文头的产生及其各域的用法。描述中的“b”表示bit；“n”表示十进制数字。另外，本文中所有数字编码均采用ASCII编码方式。报文头在报文中位置如图5所示：报文头报文类型标识符位图报文域图5 报文头4.2.1 报文头位置和基本说明报文头与报文类型标识符、位图和报文域一块组成了一个完整的报文。凡符合报文接口的所有联机报文都必须带有报文头。用于文件传递的8000号系列报文不使用报文头。4.2.2 报文头的基本组成表7 报文头的组成域域名长度（单位：Byte）Field1头长度（Header Length）1Field2头标识和版本号（Header Flag and Version）