城市公共交通IC卡業(yè)務(wù)及技術(shù)應(yīng)用規(guī)范（征求意見稿） 第5部分 信息技術(shù)接口規(guī)范

《城市公共交通IC卡業(yè)務(wù)及技術(shù)應(yīng)用規(guī)范（征求意見稿） 第5部分 信息技術(shù)接口規(guī)范》由會員分享，可在線閱讀，更多相關(guān)《城市公共交通IC卡業(yè)務(wù)及技術(shù)應(yīng)用規(guī)范（征求意見稿） 第5部分 信息技術(shù)接口規(guī)范（128頁珍藏版）》請在裝配圖網(wǎng)上搜索。

JT/T xxxxx—xxxx XXXXXXXXXXXXXX 發(fā)布 201x-xx-xx實施 201x-xx-xx發(fā)布 城市公共交通IC卡業(yè)務(wù)及技術(shù)應(yīng)用規(guī)范（征求意見稿） 第5部分：信息技術(shù)接口規(guī)范 The Application Standards of business and technology of City Public Transportation IC Card Part Ⅴ：Information Technology Interface Specification JT/T xxxxx—xxxx JT 中華人民共和國xx標準 ICS xxxxxx X xx 備案號：  目 次 前 言 III 引 言 V 1術(shù)語和定義 1 2縮略語 Abbreviations 4 3交易處理說明 4 3.1交易分類說明 4 3.2交易的一般處理流程 5 3.3清分清算處理產(chǎn)生的交易 5 4報文接口說明 28 4.1報文結(jié)構(gòu) 28 4.2報文頭 28 4.3報文類型 35 4.4位圖 36 4.5報文域說明 38 4.6報文的匹配 41 4.7報文格式說明 43 5文件接口說明 48 5.1文件存取方式說明 48 5.2基本約定 56 5.3跨域交易清算文件列表及相關(guān)說明 60 6通訊接口說明 73 6.1系統(tǒng)網(wǎng)絡(luò)結(jié)構(gòu) 73 6.2系統(tǒng)接入接口 74 6.3通訊接口協(xié)議 75 6.4 協(xié)議定義 83 附　錄　A （規(guī)范性附錄） 標準代碼定義 94 A.1 入網(wǎng)機構(gòu)標識碼 94 A.2 應(yīng)答碼 94 A.3 報文原因碼 104 A.4 拒絕碼 114  II 前 言 《城市公共交通IC卡業(yè)務(wù)及技術(shù)應(yīng)用規(guī)范》分為8個部分： —— 第1部分：總則； —— 第2部分：城市公共交通IC卡技術(shù)要求； —— 第3部分：城市公共交通IC卡讀寫終端技術(shù)要求； —— 第4部分：業(yè)務(wù)規(guī)則規(guī)范； —— 第5部分：信息技術(shù)接口規(guī)范； —— 第6部分：通訊報文接口規(guī)范； —— 第7部分：安全規(guī)范（密鑰系統(tǒng)）； —— 第8部分：檢測規(guī)范。 本部分為規(guī)范的第5部分。 本部分按照GB/T 1.1-2009給出的規(guī)則起草。 本部分由中華人民共和國交通運輸部提出。 本部分主要起草單位： 本部分主要起草人： 本部分為首次發(fā)布：   引 言 本部分為城市公共交通IC卡業(yè)務(wù)及技術(shù)應(yīng)用規(guī)范的第5部分，與規(guī)范的第1部分、第2部分、第3部分、第4部分、第6部、第7部分和第8部分一起構(gòu)成城市公共交通IC卡業(yè)務(wù)及技術(shù)應(yīng)用規(guī)范。 V JT/T xxxxx—xxxx 城市公共交通IC卡業(yè)務(wù)及技術(shù)應(yīng)用規(guī)范 第5部分：信息技術(shù)接口規(guī)范 1 術(shù)語和定義 下列術(shù)語和定義適用于本標準。 1.1　 請求類交易 request transaction 從交易的請求方（如：受理方）發(fā)送至接收方（如：發(fā)卡機構(gòu)），且等待該交易的響應(yīng)。接收方接收到交易請求后應(yīng)直接給予交易批準或拒絕的應(yīng)答。如果交易的接收方不是該交易的最終接收機構(gòu)，則接收方負責將交易向下一機構(gòu)轉(zhuǎn)發(fā)。 1.2　 響應(yīng)碼/應(yīng)答碼 Response Code 是接收方接收到的請求或通知后，返回給發(fā)送方表示處理結(jié)果的代碼。 1.3　 沖正Reversal 一種特殊的交易。由報文的發(fā)送方發(fā)起，用于通知接收方先前一筆授權(quán)類或消費類交易沒有按預(yù)定流程完成，應(yīng)該取消其處理結(jié)果。 1.4　 存儲轉(zhuǎn)發(fā) Store and Forward 發(fā)送方將報文存放在存儲轉(zhuǎn)發(fā)隊列中，在一定次數(shù)內(nèi)每隔一段時間重復發(fā)送。 1.5　 清分Clearing 對交易數(shù)據(jù)依據(jù)機構(gòu)和交易類型進行分類匯總，并計算結(jié)算金額的過程。 1.6　 清算Settlement 指根據(jù)清分結(jié)果對交易數(shù)據(jù)進行凈額軋差和提交并完成資金劃撥的全過程。 1.7　 結(jié)算Settlementof Accounts 指完成資金劃撥的全過程。 1.8　 交易Transaction 用于完成發(fā)起方意圖的一個或多個相關(guān)報文的集合。 1.9　 單信息 Single Message 指受理方將交易信息提交給發(fā)卡機構(gòu)，然后由轉(zhuǎn)接清算機構(gòu)以日志進行清算，受理方不必提交清算文件的交易方式。 1.10　 單信息交易 Single Message Transaction 一筆交易被發(fā)送一次，同時用于授權(quán)、清分和結(jié)算。即，授權(quán)、清分和結(jié)算全部在線發(fā)生。 1.11　 雙信息 Dual Message 指受理方先將授權(quán)請求信息提交給發(fā)卡機構(gòu)，在后來的某個時間再集中將清算信息以清算文件的形式提交給發(fā)卡機構(gòu)的交易方式。 1.12　 雙信息交易 Dual Message Transaction 一筆交易被發(fā)送兩次，第一次僅用于授權(quán)，第二次的附加信息用于清分和結(jié)算。即，授權(quán)實時處理，清分和結(jié)算非實時處理。 1.13　 通知 Advice 將已經(jīng)發(fā)生的動作通知有關(guān)方的報文，不要求認可。 1.14　 自主清算Self-Determination Settlement 兩個機構(gòu)之間的一種清算約定，當清算由一方發(fā)起并以該方的數(shù)據(jù)為準時，該方稱該類交易為自主清算。 1.15　 非自主清算Unself-Determination Settlement 兩個機構(gòu)之間的一種清算約定，當清算由一方發(fā)起并以該方的數(shù)據(jù)為準時，另一方稱該類交易為非自主清算。 1.16　 文件發(fā)送方 File Sender 在文件收發(fā)過程中，將文件傳送出去的一方。 1.17　 文件接收方 File Accepter 在文件收發(fā)過程中，將文件接收進來的一方。 1.18　 個人標識碼 PINpersonal identification number 個人標識碼是在聯(lián)機交易中識別持卡人身份合法性的數(shù)據(jù)信息，在計算機和網(wǎng)絡(luò)系統(tǒng)中任何環(huán)節(jié)都不允許PIN以明文的方式出現(xiàn)。 1.19　 報文鑒別碼 MACmessage authentication code 報文鑒別碼，是消息來源正確性鑒別的數(shù)據(jù)。 1.20　 硬件加密機 HSMhardware and security module 硬件加密機，對傳輸?shù)臄?shù)據(jù)進行加密的外圍硬件設(shè)備，用于PIN的加密和解密、驗證報文和文件來源的正確性以及存儲密鑰。 1.21　 SDH Synchronous Digital Hierarchy SDH即同步數(shù)字體系，根據(jù)ITU-T的建議定義，它為不同速度的數(shù)字信號的傳輸提供相應(yīng)等級的信息結(jié)構(gòu)，包括覆用方法和映射方法，以及相關(guān)的同步方法組成的一個技術(shù)體制。 1.22　 MSTP Multi-Service Transport Platform MSTP（基于SDH 的多業(yè)務(wù)傳送平臺）是指，基于SDH 平臺同時實現(xiàn)TDM、以太網(wǎng)等業(yè)務(wù)的接入、處理和傳送，提供統(tǒng)一網(wǎng)管的多業(yè)務(wù)節(jié)點。 1.23　 TCP transport control protocol 是一種可靠的傳輸控制協(xié)議。本規(guī)范中除了指傳輸控制協(xié)議外，還特指各系統(tǒng)中實現(xiàn)TCP協(xié)議的協(xié)議棧。 1.24　 通信主機Communications Host 通信主機指入網(wǎng)機構(gòu)進行聯(lián)機交易處理時，與轉(zhuǎn)接清算機構(gòu)的通信服務(wù)器建立通信連接的通信前置機或業(yè)務(wù)主機。 1.25　 長連接 persistent connect 長連接是指通信雙方連接建立后不再關(guān)閉，在通信正常情況下一直保持連通狀態(tài)。 1.26　 短連接transitory link 短連接是指通信雙方每次通信時建立連接，通信結(jié)束后關(guān)閉連接。 1.27　 脫機類交易 offline transaction 脫機類交易由終端直接承兌或拒絕，因此需要通過受理方事后提交文件或交易，來補全轉(zhuǎn)接清算系統(tǒng)和發(fā)卡機構(gòu)的交易記錄并清算。 1.28　 周期計費 各結(jié)算單位本金按日清算，手續(xù)費逐筆計算，每月、季度、年等周期向發(fā)卡機構(gòu)、轉(zhuǎn)接清算機構(gòu)、收單方結(jié)算一次。 1.29　 包月計費 按照每個各結(jié)算單位每月、季度、年等固定費用結(jié)算各結(jié)算單位手續(xù)費，并按比例在發(fā)卡、收單和轉(zhuǎn)接清算機構(gòu)之間分潤。 1.30　 受理方服務(wù)機構(gòu) 除收單機構(gòu)以外，向收單方提供服務(wù)的機構(gòu)。 示例：為部省市級結(jié)算單位（下簡稱：各結(jié)算單位）提供結(jié)算服務(wù)的開戶銀行，提供渠道接入服務(wù)的第三方服務(wù)機構(gòu)，提供機具租賃的機具產(chǎn)權(quán)機構(gòu)，提供機具維護服務(wù)的機具維護機構(gòu)等。 1.31　 發(fā)卡機構(gòu)服務(wù)機構(gòu) 除發(fā)卡機構(gòu)以外，向發(fā)卡機構(gòu)提供服務(wù)的機構(gòu)。 示例：提供發(fā)卡接入服務(wù)的發(fā)卡接入機構(gòu)，提供支付工具服務(wù)的聯(lián)名卡合作發(fā)卡機構(gòu)等。 1.32　 墊付 若各結(jié)算單位出現(xiàn)清算資金為付差時，則付差資金清算對象應(yīng)為收單機構(gòu)，各結(jié)算單位的付差資金由收單機構(gòu)墊付，即稱“收單墊付”。 1.33　 回補 因各結(jié)算單位付差而造成收單機構(gòu)資金墊付，待各結(jié)算單位后期清算出現(xiàn)正向清算資金后，由轉(zhuǎn)接清算機構(gòu)扣除收單機構(gòu)墊付部分資金。 1.34　 暫扣 收單機構(gòu)根據(jù)本機構(gòu)設(shè)定的風險規(guī)則，判斷當日交易存在風險時，通過轉(zhuǎn)接清算機構(gòu)外圍業(yè)務(wù)（服務(wù)）平臺向轉(zhuǎn)接清算機構(gòu)發(fā)出交易暫扣指令，對各結(jié)算單位該筆交易清算資金進行掛賬處理。 1.35　 追扣 對已經(jīng)清算的歷史交易，在規(guī)定期間內(nèi)（時間可以由轉(zhuǎn)接清算機構(gòu)參數(shù)設(shè)置，默認時間為60日內(nèi)），如果收單機構(gòu)判斷此交易也需要進行資金扣回的，收單機構(gòu)可通過向清算系統(tǒng)發(fā)出交易追扣指令，完成交易追扣，對各結(jié)算單位該筆交易清算資金進行掛賬處理，資金從各結(jié)算單位當日清算資金中扣除。 1.36　 釋放 收單機構(gòu)根據(jù)風險規(guī)則，判斷原掛帳交易風險解除時，將原先存放在本機構(gòu)的掛帳資金清算給各結(jié)算單位。 1.37　 掛帳 收單機構(gòu)根據(jù)風險規(guī)則，判斷交易存在風險時，先將各結(jié)算單位資金暫時存放在本機構(gòu)，而不清算給各結(jié)算單位。掛賬資金對于收單機構(gòu)而言，是暫收的應(yīng)付清算款項，是收單機構(gòu)的負債；對于各結(jié)算單位而言，是各結(jié)算單位的應(yīng)收款項，是各結(jié)算單位的債權(quán)。 1.38　 批量方式 批量方式指由各結(jié)算單位以文件形式發(fā)起交易，收單機構(gòu)在規(guī)定時間內(nèi)上送轉(zhuǎn)接清算機構(gòu)，經(jīng)轉(zhuǎn)接清算機構(gòu)處理后轉(zhuǎn)發(fā)給發(fā)卡機構(gòu)的交易方式。 2 縮略語 Abbreviations 下列符號和縮略語表示適用于本文件。 DES 數(shù)據(jù)加密標準(Data Encryption Standard) IC 集成電路(Integrated Circuit) MAC 報文鑒別碼(Message Authentication Code) MAK MAC密鑰(MAC Key) MK 主密鑰(Master Key) MMK 成員主密鑰(Member Master Key) POS 銷售點終端(Point Of Sale) 3 交易處理說明 3.1 交易分類說明 按交易處理流程分類，可以將交易分為脫機類和批量類。其中，對于按交易的功能分類，可以將交易分為金融類、管理及安全控制類、差錯處理類和風險控制類等。其中只有金融類交易有單信息和雙信息的概念，管理及安全控制、差錯處理類和風險控制類不存在單信息和雙信息的概念。 由于IC卡提供了一些專有的業(yè)務(wù)功能和交易流程，本規(guī)范將在下文中用獨立章節(jié)描述基于IC卡的特殊應(yīng)用。 3.2 交易的一般處理流程 脫機類交易是指交易由終端直接承兌或拒絕，受理方在交易完成之后再提交文件或?qū)⒚摍C消費轉(zhuǎn)為聯(lián)機報文上送，用以補全轉(zhuǎn)接清算機構(gòu)和發(fā)卡機構(gòu)的交易記錄并清算。 另一種脫機交易是指交易通過文件來完成，不存在聯(lián)機報文。 3.3 清分清算處理產(chǎn)生的交易 3.1.1 轉(zhuǎn)接清算機構(gòu)的日期切換通知交易（0820/0830） 轉(zhuǎn)接清算機構(gòu)利用日期切換交易來通知入網(wǎng)機構(gòu)轉(zhuǎn)接清算機構(gòu)清算日期的變化。轉(zhuǎn)接清算機構(gòu)的日期切換交易有兩種：日切開始(CutOff Start)、日切結(jié)束(CutOff End)。 轉(zhuǎn)接清算機構(gòu)將日期切換交易發(fā)送給各入網(wǎng)機構(gòu)，入網(wǎng)機構(gòu)接收到該交易后將應(yīng)答返回給轉(zhuǎn)接清算機構(gòu)。 交易流程為：轉(zhuǎn)接清算機構(gòu)將日期切換通知發(fā)送給各入網(wǎng)機構(gòu)，入網(wǎng)機構(gòu)接收到該通知后將應(yīng)答返回給轉(zhuǎn)接清算機構(gòu)。當轉(zhuǎn)接清算機構(gòu)不能將日切通知發(fā)送給入網(wǎng)機構(gòu)或收不到機構(gòu)的應(yīng)答時，不進行存儲轉(zhuǎn)發(fā)，直接丟棄該通知。 1—轉(zhuǎn)接清算機構(gòu)發(fā)送給入網(wǎng)機構(gòu)的日切通知（0820） 2—入網(wǎng)機構(gòu)發(fā)往轉(zhuǎn)接清算機構(gòu)的應(yīng)答（0830） 圖1　 轉(zhuǎn)接清算機構(gòu)的日期切換通知交易流程 3.1.2 自主清分清算產(chǎn)生的交易處理流程 3.1.2.1 轉(zhuǎn)接清算機構(gòu)日期切換情況下的報文發(fā)送處理流程 1－轉(zhuǎn)接清算機構(gòu)向入網(wǎng)機構(gòu)發(fā)送日切開始通知（0820） 2－入網(wǎng)機構(gòu)向轉(zhuǎn)接清算機構(gòu)返回應(yīng)答報文（0830） 3－轉(zhuǎn)接清算機構(gòu)向入網(wǎng)機構(gòu)發(fā)送日切結(jié)束通知（0820） 4－入網(wǎng)機構(gòu)向轉(zhuǎn)接清算機構(gòu)返回應(yīng)答報文（0830） 圖2　 轉(zhuǎn)接清算機構(gòu)日期切換情況下的報文發(fā)送處理流程 3.1.2.2 清分清算的文件處理 對于單信息方式的入網(wǎng)機構(gòu)，轉(zhuǎn)接清算機構(gòu)清分清算處理后將向其下發(fā)交易流水文件。 對于雙信息發(fā)卡機構(gòu)，日切后轉(zhuǎn)接清算機構(gòu)根據(jù)該清算日單轉(zhuǎn)雙的交易向發(fā)卡機構(gòu)發(fā)送轉(zhuǎn)換后的雙信息清算文件。 3.1.2.3 轉(zhuǎn)接清算機構(gòu)清分清算的時序 時序指一個功能的執(zhí)行必須以其他功能的完成為前提，或者一個功能的完成是其他功能繼續(xù)執(zhí)行的前提條件。 3.1.2.4 自主清算方式的時序配合 3.1.2.4.1 清分場次切換時序點 表1　 清分場次切換時序點控制關(guān)系 序號 交易名稱 關(guān)鍵功能步驟描述 1 轉(zhuǎn)接 切換前的所有交易請求納入前一個清分場次 切換后的所有交易請求納入后一個清分場次 2 清分 按交易請求標識的場次進行清分 3.1.2.4.2 日切開始時序點的控制步驟 日切切換開始時序點的控制關(guān)系如下表所示： 表2　 日切開始時序點的控制步驟 序號 交易名稱 關(guān)鍵功能步驟描述 1 轉(zhuǎn)接 日切前的所有交易請求納入第一天清算 日切后的所有交易請求納入第二天清算，拒絕前一清算日的撤銷交易 2 代授權(quán) 沿用轉(zhuǎn)接交易的日期劃分 3 清算 單信息： 按轉(zhuǎn)接結(jié)束時標識的日切時間進行清算。 雙信息： 按轉(zhuǎn)接結(jié)束時標識的日切時間進行清算 4 差錯 1. 日切前必須完成已經(jīng)提交的差錯文件處理； 2. 日切前必須完成差錯聯(lián)機通知的轉(zhuǎn)發(fā)處理。 3.1.2.4.3 日切結(jié)束時序點的控制步驟 日切結(jié)束時序點的控制關(guān)系如下表所示： 表3　 日切結(jié)束時序點的控制步驟 序號 交易名稱 關(guān)鍵功能步驟描述 1 轉(zhuǎn)接 1. 為了給原交易的后續(xù)交易一定的處理緩沖時間，在日切開始點和日切結(jié)束點之間設(shè)定3分鐘的日切窗口，3分鐘一到窗口將自動關(guān)閉。 2. 在日切窗口內(nèi)到達的所有原始請求交易納入第二天清算，日切窗口內(nèi)正在處理的所有應(yīng)答交易、沖正和撤銷交易的清算日期沿用原交易的清算日期。若這些交易在日切窗口內(nèi)沒有處理完，則按交易失敗處理。日切窗口內(nèi)，拒絕所有前一個清算日期的撤銷交易（可隔日上送的撤銷交易除外）。 3. 日切結(jié)束后，拒絕所有前一清算日期的沖正交易； 3.1.3 交易的異常處理流程 3.1.3.1 概述 本章主要約定入網(wǎng)機構(gòu)之間進行應(yīng)用交互的過程中對各種異常情形的處理方法。可能出現(xiàn)的異常情形主要包括： ——報文格式錯誤； ——數(shù)據(jù)安全保密錯誤； ——通信異常； ——終端操作錯誤。 3.1.3.2 異常處理原則 3.1.3.2.1 原則1 請求類報文中預(yù)授權(quán)類報文和交易類報文，在出現(xiàn)異常時以沖正通知報文取消原交易。異常情況為： ——機構(gòu)無法將交易的承兌響應(yīng)轉(zhuǎn)發(fā)至交易的發(fā)送方時； ——收到交易發(fā)送方的沖正通知時； ——當一個請求類報文超時未收到應(yīng)答時； ——當收到遲到的對請求報文的承兌應(yīng)答時。 3.1.3.2.2 原則2 入網(wǎng)機構(gòu)不能正確發(fā)送沖正通知時，應(yīng)進行存儲轉(zhuǎn)發(fā)。 3.1.3.2.3 原則3 入網(wǎng)機構(gòu)在收到?jīng)_正通知時，應(yīng)匹配原交易。若原交易成功，則取消原交易，返回沖正成功應(yīng)答(Response Code為00)并參與清算。否則應(yīng)根據(jù)情況給出不同的拒絕碼。 發(fā)卡機構(gòu)必須嚴格處理好重復沖正問題，以免發(fā)生賬務(wù)信息混亂現(xiàn)象。 3.1.3.2.4 原則4 除網(wǎng)絡(luò)管理類通知（包括簽到/簽退、日切開始、日切結(jié)束等）外，城市公共交通IC卡系統(tǒng)或入網(wǎng)機構(gòu)應(yīng)利用存儲轉(zhuǎn)發(fā)機制將通知送達接收方。 3.1.3.3 報文格式錯誤 本節(jié)約定入網(wǎng)機構(gòu)對所接收的報文的判斷及處理，在此只定義報文中數(shù)據(jù)元的語法錯或語義錯。 3.1.3.3.1 報文語法錯誤 語法錯誤是指：所收到的報文中，數(shù)據(jù)取值范圍或數(shù)據(jù)類型不符合報文標準。 這一類錯誤如發(fā)生在請求報文或通知報文中，城市公共交通IC卡系統(tǒng)會將原始請求或通知報文原樣返回，并在返回的新增報文頭中置入相應(yīng)的拒絕碼，該拒絕碼與城市公共交通IC卡系統(tǒng)檢測到的第一個報文語法錯誤相對應(yīng)。 這一類錯誤如發(fā)生在授權(quán)或交易承兌的應(yīng)答報文中，若城市公共交通IC卡系統(tǒng)或受理方檢查出此類錯誤，則丟棄該應(yīng)答報文，待超時后發(fā)送沖正通知。若發(fā)生在通知類（網(wǎng)絡(luò)管理類通知除外）交易應(yīng)答報文中，則通知的發(fā)送方存儲轉(zhuǎn)發(fā)該通知報文。 數(shù)據(jù)取值范圍或數(shù)據(jù)類型錯誤代碼的詳細定義請參見《報文接口規(guī)范》的附錄A 拒絕碼。 3.1.3.3.2 報文語義錯誤 報文語義錯誤是指：報文中的數(shù)據(jù)盡管在語法上符合銀行卡信息交換的報文標準，但是在語義上對交易無效（見表4數(shù)據(jù)內(nèi)容無效錯誤表）。 這類錯誤若發(fā)生在一般請求報文或通知報文中，城市公共交通IC卡系統(tǒng)將直接向受理方發(fā)送拒絕的應(yīng)答，其中的應(yīng)答碼見下表。 表4　 數(shù)據(jù)內(nèi)容無效錯誤表 位號 數(shù)據(jù)內(nèi)容錯誤描述 應(yīng)答碼 4 Amount of transaction 為 0 13 沖正、撤銷和差錯處理交易請求中可能出現(xiàn)的數(shù)據(jù)內(nèi)容無效情況如下表所示： 表5　 沖正、撤銷和差錯處理交易請求的數(shù)據(jù)內(nèi)容無效表 數(shù)據(jù)內(nèi)容錯誤描述 應(yīng)答碼 交易請求未能與原始交易相匹配 25 交易未能與原始交易金額相一致 64 交易未能與原始交易卡號相一致 14 交易未能與原始交易終端相一致 97 交易的原始交易未承兌 12 交易應(yīng)答未能與沖正請求相匹配 記載日志，以后備查。 這類錯誤若發(fā)生在交易承兌的應(yīng)答報文中，則城市公共交通IC卡系統(tǒng)丟棄該應(yīng)答報文，待超時后發(fā)送沖正通知。若發(fā)生在通知類（網(wǎng)絡(luò)管理類通知除外）交易應(yīng)答報文中，則通知的發(fā)送方存儲轉(zhuǎn)發(fā)該通知報文。 3.1.3.3.3 數(shù)據(jù)安全保密錯誤 本節(jié)是對城市公共交通IC卡系統(tǒng)、受理方及發(fā)卡機構(gòu)在交易過程中所發(fā)生的數(shù)據(jù)安全保密錯誤的處理約定。這些錯誤的現(xiàn)象為： l 請求報文中MAC計算錯誤； l 通知報文中MAC計算錯誤； l 對請求的應(yīng)答報文中MAC錯誤； l 對通知的應(yīng)答報文中MAC錯誤。 3.1.3.3.4 請求報文中MAC計算錯誤 錯誤現(xiàn)象： 在報文的接收方一側(cè)檢測到MAC不匹配。 城市公共交通IC卡系統(tǒng)處理： 向受理方發(fā)送拒絕應(yīng)答，其中，Response Code=A0。 發(fā)卡機構(gòu)處理： 向城市公共交通IC卡系統(tǒng)發(fā)送拒絕應(yīng)答，其中，Response Code=A0。 3.1.3.3.5 通知報文中MAC計算錯誤 錯誤現(xiàn)象： 在報文的接收方一側(cè)檢測到MAC不匹配。 城市公共交通IC卡系統(tǒng)處理： 向受理方發(fā)送拒絕應(yīng)答，其中，Response Code=A0。 發(fā)卡機構(gòu)處理： 向城市公共交通IC卡系統(tǒng)發(fā)送拒絕應(yīng)答，其中，Response Code=A0。 3.1.3.3.6 對請求的應(yīng)答報文中MAC錯誤 一般交易 錯誤現(xiàn)象： 在報文的接收方一側(cè)檢測到MAC不匹配。 城市公共交通IC卡系統(tǒng)處理：向受理方發(fā)送拒絕應(yīng)答報文。若為承兌的交易，則還需向發(fā)卡機構(gòu)引發(fā)沖正報文沖正原因（即60域中的Reason Code）為4362，該筆沖正參與對賬。 受理方處理：向終端發(fā)送拒絕應(yīng)答報文，若為承兌的交易，則還需向城市公共交通IC卡系統(tǒng)引發(fā)沖正報文，沖正原因碼為4355，該筆沖正參與對賬。 3.1.3.3.7 對通知的應(yīng)答報文中MAC錯誤 錯誤現(xiàn)象： 在報文的接收方一側(cè)檢測到MAC不匹配。 城市公共交通IC卡系統(tǒng)處理： 記載日志，以后備查分析。 3.1.3.3.8 通信異常 本節(jié)敘述了入網(wǎng)機構(gòu)對交易過程中所發(fā)生的通信故障的處理約定。這些通信故障的現(xiàn)象為： ——發(fā)送請求報文失敗； ——發(fā)送對請求報文的應(yīng)答報文失敗； ——發(fā)送請求報文后，收不到應(yīng)答報文； ——發(fā)送沖正通知報文失敗； ——發(fā)送對沖正通知報文的應(yīng)答報文失敗； ——發(fā)送沖正通知報文后，收不到應(yīng)答報文； ——收到遲到的對請求報文的應(yīng)答報文。 ——這些故障根據(jù)一筆完整交易所需經(jīng)過的各個環(huán)節(jié)的先后次序進行排列。 當入網(wǎng)機構(gòu)根據(jù)上述故障現(xiàn)象檢測到與其他入網(wǎng)機構(gòu)的通信異常時，入網(wǎng)機構(gòu)的處理原則如下： ——入網(wǎng)機構(gòu)每隔一定時間發(fā)一次0820回響測試（echo test）報文，測試是否恢復連接； ——丟棄未發(fā)出的響應(yīng)報文； ——對需要轉(zhuǎn)發(fā)的請求報文，則以“91 (發(fā)卡機構(gòu)或城市公共交通IC卡系統(tǒng)不能操作)”向受理方發(fā)拒絕應(yīng)答； ——對通知報文(022X、042X)，則存入存儲轉(zhuǎn)發(fā)隊列中，待連接恢復后發(fā)出。 當收到“echo test”應(yīng)答（0830）后，表示連接恢復，入網(wǎng)機構(gòu)將存儲轉(zhuǎn)發(fā)隊列中的報文依次發(fā)送出去。 在以下的故障處理中，不再重復通信異常到恢復的處理過程。 3.1.3.3.9 單次故障 本節(jié)的異常處理編排次序按照交易報文的流轉(zhuǎn)次序編寫。對于一些簡單步驟沒有進行特別的描述，只針對特殊、難點步驟進行了詳細說明。 在流程描述之前，首先介紹一些容易混淆的概念。 發(fā)送方無法發(fā)送請求和發(fā)送方發(fā)送的請求在中途丟失的區(qū)別 “發(fā)送方無法發(fā)送請求”指發(fā)送方因為通訊故障不能將請求發(fā)出，這種現(xiàn)象發(fā)送方是能夠探測知道的，在下文的流程圖中用“x”表示。 “發(fā)送方發(fā)送的請求在中途丟失”指發(fā)送方發(fā)出的請求因為通訊故障在中途丟失，這時發(fā)送方并不能探測知道該請求出了什么狀況，它所知道的只是沒有收到接收方的應(yīng)答，因此最終反映出的現(xiàn)象是交易超時，在下文的流程圖中用“？”表示。 由于這兩種現(xiàn)象的最終反映情況不同，導致它們的處理也不同，具體可參見下文的相關(guān)描述。 接收方?jīng)]有收到發(fā)送方請求、接收方無法發(fā)送應(yīng)答和接收方的應(yīng)答在中途丟失的區(qū)別 這三種情況對發(fā)送方而言處理都是一樣的，但接收方反映出的情況卻不一致。 “接收方?jīng)]有收到請求”的情況是接收方?jīng)]有收到原始交易請求。 “接收方無法發(fā)送應(yīng)答”的情況是接收方因為通訊故障不能將應(yīng)答發(fā)出，這種現(xiàn)象接收方是能夠探測知道的。 “接收方的應(yīng)答在中途丟失”的情況是因為通訊故障其應(yīng)答在中途丟失，但這種現(xiàn)象接收方是不能夠探測知道的。 由于這三種現(xiàn)象的最終反映情況不同，因此接收方的處理也是不同的，具體可參見下文的相關(guān)描述。 受理方無法轉(zhuǎn)發(fā)來自終端的請求 故障現(xiàn)象： 因通信故障，受理方不能向城市公共交通IC卡系統(tǒng)轉(zhuǎn)發(fā)請求2。 受理方處理： 受理方直接向終端發(fā)送拒絕應(yīng)答3。 受理方無法轉(zhuǎn)發(fā)來自終端的請求 城市公共交通IC卡系統(tǒng)收不到請求 故障現(xiàn)象： 因通信故障，受理方的請求2在中途丟失，受理方因收不到城市公共交通IC卡系統(tǒng)的應(yīng)答而引起交易超時。 受理方處理： 如果是交易請求，則向終端發(fā)送超時引起的拒絕應(yīng)答3，同時向城市公共交通IC卡系統(tǒng)發(fā)送沖正4，其Reason Code為4354，該筆沖正不參與清算。 城市公共交通IC卡系統(tǒng)處理： 向受理方發(fā)送沖正的拒絕應(yīng)答5，其中，Response Code為25，該筆沖正不參與清算。 城市公共交通IC卡系統(tǒng)收不到請求 城市公共交通IC卡系統(tǒng)不能向發(fā)卡機構(gòu)轉(zhuǎn)發(fā)請求 故障現(xiàn)象： 因通信故障，城市公共交通IC卡系統(tǒng)不能把受理方的請求2轉(zhuǎn)發(fā)至發(fā)卡機構(gòu)。 城市公共交通IC卡系統(tǒng)處理： 向受理方發(fā)送拒絕請求的應(yīng)答4，其中，Response Code為91。 城市公共交通IC卡系統(tǒng)不能向發(fā)卡機構(gòu)轉(zhuǎn)發(fā)請求 發(fā)卡機構(gòu)收不到請求 故障現(xiàn)象： 因通信故障，城市公共交通IC卡系統(tǒng)的請求3在中途丟失，城市公共交通IC卡系統(tǒng)因為收不到發(fā)卡機構(gòu)的應(yīng)答而引起交易超時。 城市公共交通IC卡系統(tǒng)處理： 超時后向受理方發(fā)送拒絕的應(yīng)答4，如果是金融交易請求，則還需向發(fā)卡機構(gòu)發(fā)送沖正報文5，其中，Reason Code為4361，該筆沖正不參與清算。 發(fā)卡機構(gòu)處理： 向城市公共交通IC卡系統(tǒng)發(fā)送沖正的拒絕應(yīng)答6，其中，Response Code為25，該筆沖正不參與清算。 發(fā)卡機構(gòu)收不到請求 發(fā)卡機構(gòu)不能向城市公共交通IC卡系統(tǒng)發(fā)送對請求的應(yīng)答。 故障現(xiàn)象：因通信故障，發(fā)卡機構(gòu)不能向城市公共交通IC卡系統(tǒng)發(fā)送對請求的應(yīng)答4。 發(fā)卡機構(gòu)處理1： 如果是交易請求，且已承兌，則作內(nèi)部沖正，該筆沖正參與清算。 城市公共交通IC卡系統(tǒng)處理：向受理方發(fā)送超時引起的拒絕請求的應(yīng)答5，其中，Response Code為98。如果是交易請求，則還需向發(fā)卡機構(gòu)發(fā)送沖正7。其中，Reason Code為4361。 發(fā)卡機構(gòu)處理2： 向城市公共交通IC卡系統(tǒng)返回沖正的拒絕應(yīng)答8，該筆沖正不參與清算。 發(fā)卡機構(gòu)不能向城市公共交通IC卡系統(tǒng)發(fā)送對請求的應(yīng)答 城市公共交通IC卡系統(tǒng)收不到發(fā)卡機構(gòu)的應(yīng)答 故障現(xiàn)象： 城市公共交通IC卡系統(tǒng)在向發(fā)卡機構(gòu)轉(zhuǎn)發(fā)請求3后，收不到發(fā)卡機構(gòu)的應(yīng)答4，即檢測到超時。 城市公共交通IC卡系統(tǒng)處理： 向受理方發(fā)送超時引起的拒絕請求的應(yīng)答5，其中，Response Code為98。如果是金融交易請求，則還需向發(fā)卡機構(gòu)發(fā)送沖正7。其中，Reason Code為4361。原交易和沖正交易都不參與清算。 發(fā)卡機構(gòu)處理： 向城市公共交通IC卡系統(tǒng)返回沖正應(yīng)答8，發(fā)卡機構(gòu)對該筆沖正是否參與清算視發(fā)卡機構(gòu)收到該沖正時原交易是否承兌而定。若原交易已承兌則該筆沖正參與清算，否則該筆沖正不參與清算。 城市公共交通IC卡系統(tǒng)收不到發(fā)卡機構(gòu)的應(yīng)答 城市公共交通IC卡系統(tǒng)收到發(fā)卡機構(gòu)遲到的承兌應(yīng)答 故障現(xiàn)象：城市公共交通IC卡系統(tǒng)檢測到發(fā)卡機構(gòu)超時，向受理方發(fā)送拒絕的應(yīng)答4后，并按照0進行后續(xù)處理后，收到來自發(fā)卡機構(gòu)遲到的承兌應(yīng)答6。 城市公共交通IC卡系統(tǒng)處理：再次向發(fā)卡機構(gòu)發(fā)送沖正通知7，其中，Reason Code為4360。該筆沖正不參與清算。 發(fā)卡機構(gòu)處理：向城市公共交通IC卡系統(tǒng)返回沖正應(yīng)答8，該筆沖正參與清算。 城市公共交通IC卡系統(tǒng)收到發(fā)卡機構(gòu)遲到的承兌應(yīng)答 城市公共交通IC卡系統(tǒng)不能向受理方轉(zhuǎn)發(fā)對請求的應(yīng)答 故障現(xiàn)象：因通信故障，城市公共交通IC卡系統(tǒng)不能向受理方轉(zhuǎn)發(fā)發(fā)卡機構(gòu)對請求的應(yīng)答5。 城市公共交通IC卡系統(tǒng)處理1： 如果是交易請求，且已承兌，則向發(fā)卡機構(gòu)發(fā)送沖正通知7，其中，Reason Code為4363。 發(fā)卡機構(gòu)處理：向城市公共交通IC卡系統(tǒng)返回沖正應(yīng)答8，如果是交易請求，且已承兌，則該筆沖正參與清算。 受理方處理：向終端發(fā)送超時引起的拒絕請求的應(yīng)答6。如果是交易請求，則還需向城市公共交通IC卡系統(tǒng)發(fā)送沖正通知9，其中，Reason Code為4354。 城市公共交通IC卡系統(tǒng)處理2： 向受理方發(fā)送沖正應(yīng)答10，該筆沖正不參與清算。 城市公共交通IC卡系統(tǒng)不能向受理方轉(zhuǎn)發(fā)對請求的應(yīng)答 城市公共交通IC卡系統(tǒng)收到受理方發(fā)送的早沖正 故障現(xiàn)象：在正常的超時時段內(nèi)，城市公共交通IC卡系統(tǒng)未收到發(fā)卡機構(gòu)的應(yīng)答就先收到受理方的沖正通知4。 城市公共交通IC卡系統(tǒng)處理：向受理方返回沖正應(yīng)答5，Response Code為“00”。，并向發(fā)卡機構(gòu)發(fā)送沖正通知6。 發(fā)卡機構(gòu)處理：向城市公共交通IC卡系統(tǒng)返回沖正應(yīng)答7，發(fā)卡機構(gòu)對該筆沖正是否參與清算視發(fā)卡機構(gòu)收到該沖正時原交易是否承兌而定。若原交易已承兌則該筆沖正參與清算，否則該筆沖正不參與清算。 城市公共交通IC卡系統(tǒng)處理2：在收到發(fā)卡機構(gòu)返回的原交易的應(yīng)答8后，若該應(yīng)答為承兌應(yīng)答，則向發(fā)卡機構(gòu)再次發(fā)沖正9，Reason Code為4360。如果原始交易未承兌，則城市公共交通IC卡系統(tǒng)直接丟棄該應(yīng)答。 發(fā)卡機構(gòu)處理2： 向城市公共交通IC卡系統(tǒng)返回沖正應(yīng)答10。 城市公共交通IC卡系統(tǒng)收到受理方發(fā)送的早沖正 受理方收不到城市公共交通IC卡系統(tǒng)的應(yīng)答 故障現(xiàn)象：受理方在向城市公共交通IC卡系統(tǒng)發(fā)送請求2后，收不到城市公共交通IC卡系統(tǒng)的應(yīng)答5，即檢測到超時。 受理方處理：向終端發(fā)送超時引起的拒絕請求的應(yīng)答6，如果是交易請求，則還需向城市公共交通IC卡系統(tǒng)發(fā)送沖正通知7。其中，Reason Code為4354。該筆沖正不參與清算。 城市公共交通IC卡系統(tǒng)處理： 收到?jīng)_正請求7后，查原始請求的應(yīng)答報文，如果發(fā)卡機構(gòu)已承兌，則向發(fā)卡機構(gòu)發(fā)送沖正通知9，其中，Reason Code為4354。并返回給受理方應(yīng)答碼為00的沖正應(yīng)答 報文。該筆沖正參與清算。如果發(fā)卡機構(gòu)未承兌，則直接向受理方發(fā)送沖正應(yīng)答報文8。其中應(yīng)答碼為12。該筆沖正不參與清算。 發(fā)卡機構(gòu)處理：向城市公共交通IC卡系統(tǒng)返回沖正應(yīng)答10，對發(fā)卡機構(gòu)該筆沖正參與清算。 受理方收不到城市公共交通IC卡系統(tǒng)的應(yīng)答 受理方從城市公共交通IC卡系統(tǒng)收到遲到的承兌應(yīng)答 故障現(xiàn)象：受理方檢測到城市公共交通IC卡系統(tǒng)超時，并向終端發(fā)送拒絕的應(yīng)答5后，同時按照0執(zhí)行了后續(xù)操作以后又收到來自城市公共交通IC卡系統(tǒng)的遲到的承兌應(yīng)答6。 受理方處理：再次向城市公共交通IC卡系統(tǒng)發(fā)送沖正通知7，其中，Reason Code為4353。該筆沖正參與清算。 城市公共交通IC卡系統(tǒng)處理：城市公共交通IC卡系統(tǒng)收到?jīng)_正請求后，立即給予受理方應(yīng)答8。該筆沖正不參與清算。 受理方從城市公共交通IC卡系統(tǒng)收到遲到的承兌應(yīng)答 受理方不能向終端發(fā)送操作命令 故障現(xiàn)象：因通信故障，受理方不能向終端發(fā)送操作命令6。 受理方處理：如果是金融交易請求，且已承兌，則向城市公共交通IC卡系統(tǒng)發(fā)送沖正通知7，其中，Reason Code為4356。該筆沖正參與清算。 城市公共交通IC卡系統(tǒng)處理： 城市公共交通IC卡系統(tǒng)收到?jīng)_正通知后，立即給予受理方應(yīng)答8。并向發(fā)卡機構(gòu)發(fā)送沖正通知9，其中，Reason Code為4356。該筆沖正參與清算。 發(fā)卡機構(gòu)處理：向城市公共交通IC卡系統(tǒng)返回沖正應(yīng)答10，對發(fā)卡機構(gòu)該筆沖正也參與清算。 受理方不能向終端發(fā)送操作命令 3.1.3.3.10 雙重故障 城市公共交通IC卡系統(tǒng)不能向受理方發(fā)送拒絕的應(yīng)答 故障現(xiàn)象： 因檢測到發(fā)卡機構(gòu)通信故障，城市公共交通IC卡系統(tǒng)向受理方發(fā)送對交易請求拒絕的應(yīng)答3，但由于另遇通信故障使發(fā)送應(yīng)答失敗。 城市公共交通IC卡系統(tǒng)處理： 丟棄應(yīng)答報文，不需向發(fā)卡機構(gòu)發(fā)送沖正通知。 受理方處理： 檢測到城市公共交通IC卡系統(tǒng)超時，向終端發(fā)送拒絕請求的應(yīng)答。如果是金融交易請求，則向城市公共交通IC卡系統(tǒng)發(fā)送超時沖正5，其中，Reason Code為4354。城市公共交通IC卡系統(tǒng)收到?jīng)_正通知后，立即給予受理方拒絕應(yīng)答6，其中應(yīng)答碼為12。該筆沖正對受理方和城市公共交通IC卡系統(tǒng)均不參與清算。 城市公共交通IC卡系統(tǒng)不能向受理方發(fā)送拒絕的應(yīng)答 城市公共交通IC卡系統(tǒng)不能向發(fā)卡機構(gòu)發(fā)送沖正通知 故障現(xiàn)象： 因檢測到通信故障，城市公共交通IC卡系統(tǒng)向發(fā)卡機構(gòu)發(fā)送沖正通知7〔見：0城市公共交通IC卡系統(tǒng)不能向受理方轉(zhuǎn)發(fā)對請求的應(yīng)答；0城市公共交通IC卡系統(tǒng)收到發(fā)卡機構(gòu)遲到的承兌應(yīng)答?！车捎诹碛鐾ㄐ殴收希拱l(fā)送沖正失敗。 城市公共交通IC卡系統(tǒng)處理： 將未發(fā)出的沖正存入存儲轉(zhuǎn)發(fā)隊列中，待連接恢復后重發(fā)。 城市公共交通IC卡系統(tǒng)不能向發(fā)卡機構(gòu)發(fā)送沖正通知 受理方不能向城市公共交通IC卡系統(tǒng)發(fā)送沖正通知 故障現(xiàn)象：受理方因檢測到上一次通信故障而向城市公共交通IC卡系統(tǒng)發(fā)送沖正通知7〔見：0受理方不能向終端發(fā)送操作命令；0受理方從城市公共交通IC卡系統(tǒng)收到遲到的承兌應(yīng)答〕，但由于再遇通信故障使受理方發(fā)送沖正失敗。 受理方處理：將未發(fā)出的沖正通知存入存儲轉(zhuǎn)發(fā)隊列中，待連接恢復后重發(fā)。 受理方不能向城市公共交通IC卡系統(tǒng)發(fā)送沖正通知 3.1.3.3.11 終端操作錯誤 本節(jié)約定受理方和城市公共交通IC卡系統(tǒng)對終端操作錯誤的處理約定，在此，終端錯誤僅指終端不能正確執(zhí)行主機發(fā)送的命令，即對交易的最終處理。 3.1.3.3.12 無通信故障 終端引發(fā)沖正 故障現(xiàn)象：終端因無法正常操作，向受理方發(fā)送出錯狀態(tài) 受理方處理：在沖正通知中，Reason Code=4351表示終端上交易不成功。 終端引發(fā)沖正 受理方、城市公共交通IC卡系統(tǒng)、發(fā)卡機構(gòu)三方對于該沖正交易均參與清算。 3.1.3.3.13 通信故障 受理方不能向城市公共交通IC卡系統(tǒng)發(fā)送終端操作錯誤引起的沖正 故障現(xiàn)象：因通信故障，受理方不能向城市公共交通IC卡系統(tǒng)發(fā)送終端操作出錯引起的沖正通知9。 受理方處理：將沖正通知存入存儲轉(zhuǎn)發(fā)隊列中，待連接恢復后重發(fā)。 受理方不能向城市公共交通IC卡系統(tǒng)發(fā)送終端操作錯誤引起的沖正 表6　 異常處理中使用的原因碼 原因碼 說明 4351 終端引發(fā)沖正（全額） 4352 終端引發(fā)沖正（部分） 4353 受理方收到城市公共交通IC卡系統(tǒng)遲到的應(yīng)答 4354 受理方檢測到超時 4355 受理方檢測到應(yīng)答報文的MAC不對 4356 受理方不能向終端發(fā)操作命令 4360 城市公共交通IC卡系統(tǒng)收到發(fā)卡機構(gòu)遲到的應(yīng)答 4361 城市公共交通IC卡系統(tǒng)等發(fā)卡機構(gòu)應(yīng)答到超時 4362 城市公共交通IC卡系統(tǒng)檢測到發(fā)卡機構(gòu)應(yīng)答報文的MAC不對 4363 城市公共交通IC卡系統(tǒng)不能向受理方轉(zhuǎn)發(fā)發(fā)卡機構(gòu)應(yīng)答報文 3.1.3.4 特殊交易異常處理流程 本節(jié)集中描述基于電子錢包標準的IC卡圈存交易。 本節(jié)的異常處理編排次序按照交易報文的流轉(zhuǎn)次序編寫。對于一些簡單步驟沒有進行特別的描述，只針對特殊、難點步驟進行了詳細說明。 在某些情況下，城市公共交通IC卡系統(tǒng)的處理雖然相同，但受理方和發(fā)卡機構(gòu)的處理卻各有不同。 “發(fā)送方無法發(fā)送請求”和“發(fā)送方發(fā)送的請求在中途丟失”； “接收方?jīng)]有收到發(fā)送方請求”、“接收方無法發(fā)送應(yīng)答”、“接收方的應(yīng)答在中途丟失”。 3.1.3.4.1 IC卡電子現(xiàn)金應(yīng)用指定賬戶圈存/現(xiàn)金充值交易 指定賬戶圈存交易出現(xiàn)異常時，采用沖正的方式，處理流程及原則請參見本版標準中的3.1.3.3.9單次故障。 現(xiàn)金充值交易相當于存款，考慮到圈存交易必須由終端承兌，因此不能發(fā)送確認通知，只能發(fā)送沖正通知，若終端寫卡不成功，終端也應(yīng)發(fā)送沖正。 3.1.3.4.2 IC卡電子現(xiàn)金應(yīng)用非指定賬戶圈存交易 處理原則如下： （1）終端、受理方均能發(fā)起沖正； （2）城市公共交通IC卡系統(tǒng)只對轉(zhuǎn)出方發(fā)起沖正； （3）城市公共交通IC卡系統(tǒng)不對電子錢包行做任何操作。 受理方無法轉(zhuǎn)發(fā)來自終端的請求 故障現(xiàn)象：因通信故障，受理方無法向城市公共交通IC卡系統(tǒng)轉(zhuǎn)發(fā)終端的請求2。 受理方處理：直接向終端發(fā)送拒絕應(yīng)答3。 城市公共交通IC卡系統(tǒng)收不到請求 故障現(xiàn)象：因通信故障，受理方的請求2在中途丟失，受理方因為收不到城市公共交通IC卡系統(tǒng)的應(yīng)答而引起超時。 受理方處理：受理方向終端發(fā)送拒絕應(yīng)答，Response Code為98。同時向城市公共交通IC卡系統(tǒng)發(fā)送沖正4，Reason Code為4354。該筆沖正不參與清算。 城市公共交通IC卡系統(tǒng)處理：城市公共交通IC卡系統(tǒng)直接返回應(yīng)答5，Response Code為25，該筆沖正不參與清算。 城市公共交通IC卡系統(tǒng)不能向轉(zhuǎn)出方轉(zhuǎn)發(fā)請求 故障現(xiàn)象：因通信故障，城市公共交通IC卡系統(tǒng)不能把受理方的請求2轉(zhuǎn)發(fā)至轉(zhuǎn)出方。 城市公共交通IC卡系統(tǒng)處理：向受理方發(fā)送拒絕請求的應(yīng)答4，其中，Response Code為91，域121.1為A。 轉(zhuǎn)出方收不到請求 故障現(xiàn)象：因通信故障，城市公共交通IC卡系統(tǒng)的請求3在中途丟失，城市公共交通IC卡系統(tǒng)因為收不到轉(zhuǎn)出方的應(yīng)答而引起交易超時。 城市公共交通IC卡系統(tǒng)處理：超時后向受理方發(fā)送拒絕的應(yīng)答4，同時向轉(zhuǎn)出方發(fā)送沖正報文5，其中，Reason Code為4361，該筆沖正不參與清算。 轉(zhuǎn)出方處理：向城市公共交通IC卡系統(tǒng)發(fā)送沖正的拒絕應(yīng)答6，其中，Response Code為25，該筆沖正不參與清算。 受理方處理：向終端發(fā)送拒絕應(yīng)答7。 轉(zhuǎn)出方不能向城市公共交通IC卡系統(tǒng)發(fā)送對請求的應(yīng)答 故障現(xiàn)象：因通信故障，轉(zhuǎn)出方不能向城市公共交通IC卡系統(tǒng)發(fā)送對請求的應(yīng)答4。 城市公共交通IC卡系統(tǒng)處理：向受理方發(fā)送超時引起的拒絕請求的應(yīng)答5，其中，Response Code為98。同時還需向轉(zhuǎn)出方發(fā)送沖正7。其中，Reason Code為4361。8為轉(zhuǎn)出方收到7后的應(yīng)答。該筆沖正不參與清算。 轉(zhuǎn)出方處理：如果已承兌，則作內(nèi)部沖正，該筆沖正參與清算。 城市公共交通IC卡系統(tǒng)收不到轉(zhuǎn)出方的應(yīng)答 故障現(xiàn)象：城市公共交通IC卡系統(tǒng)在向轉(zhuǎn)出方轉(zhuǎn)發(fā)請求3后，收不到轉(zhuǎn)出方的應(yīng)答4，即檢測到超時。 城市公共交通IC卡系統(tǒng)處理：向受理方發(fā)送超時引起的拒絕請求的應(yīng)答5，其中，Response Code為98。同時需向轉(zhuǎn)出方發(fā)送沖正7。其中，Reason Code為4361。8為轉(zhuǎn)出方收到7后的應(yīng)答，該筆沖正不參與清算。 轉(zhuǎn)出方處理：轉(zhuǎn)出方對該筆沖正是否參與清算視轉(zhuǎn)出方收到該沖正時原交易是否承兌而定。若原交易已承兌則該筆沖正參與清算，否則該筆沖正不參與清算。 城市公共交通IC卡系統(tǒng)收到轉(zhuǎn)出方遲到的應(yīng)答 故障現(xiàn)象：城市公共交通IC卡系統(tǒng)檢測到轉(zhuǎn)出方超時，向受理方發(fā)送拒絕的應(yīng)答4后，并按照0進行后續(xù)處理后，收到來自轉(zhuǎn)出方遲到的應(yīng)答6。 城市公共交通IC卡系統(tǒng)處理：若該遲到的應(yīng)答為承兌的應(yīng)答，城市公共交通IC卡系統(tǒng)再次向轉(zhuǎn)出方發(fā)送沖正通知7，其中Reason Code為4360，表示城市公共交通IC卡系統(tǒng)收到轉(zhuǎn)出方遲到的應(yīng)答。如果該遲到的應(yīng)答為非承兌的應(yīng)答，直接丟棄該應(yīng)答。城市公共交通IC卡系統(tǒng)收到遲到的承兌應(yīng)答后發(fā)送的沖正將不參與清算。 發(fā)卡機構(gòu)處理：向城市公共交通IC卡系統(tǒng)返回沖正應(yīng)答8。若收到?jīng)_正時原交易已承兌，則該筆沖正參與清算，否則該沖正不參與清算。 城市公共交通IC卡系統(tǒng)無法將交易請求傳遞給轉(zhuǎn)入方 故障現(xiàn)象：因通信故障，城市公共交通IC卡系統(tǒng)無法將交易請求5發(fā)送給轉(zhuǎn)入方。 城市公共交通IC卡系統(tǒng)處理：向受理方發(fā)送拒絕請求的應(yīng)答6，其中Response Code為91，域121.1為B。同時向轉(zhuǎn)出方發(fā)送沖正通知8，其中，REASON CODE為4364。該筆沖正參與清算。 轉(zhuǎn)出方處理：向城市公共交通IC卡系統(tǒng)返回沖正應(yīng)答9。該筆沖正參與清算。 轉(zhuǎn)入方收不到請求 故障現(xiàn)象：因通信故障，城市公共交通IC卡系統(tǒng)的請求5丟失，城市公共交通IC卡系統(tǒng)等待轉(zhuǎn)入方的應(yīng)答超時。 城市公共交通IC卡系統(tǒng)處理：超時后向受理方發(fā)送拒絕應(yīng)答6，此時Response Code為98。同時向轉(zhuǎn)出方發(fā)送轉(zhuǎn)出沖正8，其中，REASON CODE為4361。該筆沖正參與清算。 轉(zhuǎn)出方處理：向城市公共交通IC卡系統(tǒng)返回沖正應(yīng)答9。該筆沖正參與清算。 轉(zhuǎn)入方無法將應(yīng)答報文傳遞給城市公共交通IC卡系統(tǒng) 故障現(xiàn)象：因通信故障，轉(zhuǎn)入方不能向城市公共交通IC卡系統(tǒng)發(fā)送對請求的應(yīng)答6。 城市公共交通IC卡系統(tǒng)處理：超時后向受理方發(fā)送拒絕應(yīng)答7，此時Response Code為98。同時向轉(zhuǎn)出方發(fā)送轉(zhuǎn)出沖正9，其中Reason Code 為4361。該筆沖正參與清算。 轉(zhuǎn)出方處理：向城市公共交通IC卡系統(tǒng)返回沖正應(yīng)答10。該筆沖正參與清算。 轉(zhuǎn)入方處理：由于這里的轉(zhuǎn)入方只是一個虛擬賬戶，轉(zhuǎn)出金額只是在這里過渡一下，金額最終要到達卡片。轉(zhuǎn)入方交易標識為不清算，不參與對帳，不對該筆賬務(wù)做處理，轉(zhuǎn)入方通過日終對帳進行賬務(wù)調(diào)整處理，就可保證賬務(wù)的平衡。 賬務(wù)情況分析：由于城市公共交通IC卡系統(tǒng)拒絕了受理方和終端，因此，終端不會寫卡，卡上金額不變。而城市公共交通IC卡系統(tǒng)也沖掉了轉(zhuǎn)出方的金額，因此，轉(zhuǎn)出方賬務(wù)平衡。轉(zhuǎn)入方通過日終核對賬務(wù)，賬務(wù)也是平衡。總體分析下來，該種情況賬務(wù)平衡。 城市公共交通IC卡系統(tǒng)收不到轉(zhuǎn)入方的應(yīng)答 故障現(xiàn)象：因通信故障，城市公共交通IC卡系統(tǒng)收不到轉(zhuǎn)入方的應(yīng)答6。 城市公共交通IC卡系統(tǒng)收到轉(zhuǎn)入方遲到的應(yīng)答 故障現(xiàn)象：城市公共交通IC卡系統(tǒng)檢測到轉(zhuǎn)入方超時，向受理方發(fā)送拒絕應(yīng)答6后，同時按照執(zhí)行了后續(xù)操作以后又收到來自轉(zhuǎn)入方遲到的應(yīng)答8。 城市公共交通IC卡系統(tǒng)處理：丟棄該應(yīng)答，不做任何處理（是否特殊標志）。如轉(zhuǎn)入方帳務(wù)不平，日終城市公共交通IC卡系統(tǒng)發(fā)送對帳文件，轉(zhuǎn)入方?jīng)_賬。 城市公共交通IC卡系統(tǒng)不能向受理方轉(zhuǎn)發(fā)對請求的應(yīng)答 故障現(xiàn)象：因通信故障，城市公共交通IC卡系統(tǒng)不能向受理方轉(zhuǎn)發(fā)轉(zhuǎn)入方的請求應(yīng)答7。 城市公共交通IC卡系統(tǒng)處理：城市公共交通IC卡系統(tǒng)向轉(zhuǎn)出方發(fā)送轉(zhuǎn)出沖正，其中Reason Code 為4363。該筆沖正參與清算。轉(zhuǎn)入方交易標識為不清算，不參與對帳。 轉(zhuǎn)出方處理：返回應(yīng)答9，該筆沖正參與清算。 受理方處理：受理方超時后，直接向終端發(fā)送拒絕應(yīng)答12，Response Code為98。同時向城市公共交通IC卡系統(tǒng)發(fā)送沖正10，Reason Code為4354，城市公共交通IC卡系統(tǒng)收到該沖正后直接應(yīng)答。該沖正不參與清算。 受理方收不到城市公共交通IC卡系統(tǒng)的應(yīng)答 故障現(xiàn)象：因為通信故障，受理方?jīng)]有收到城市公共交通IC卡系統(tǒng)的應(yīng)答7。 受理方處理：受理方超時后直接向終端發(fā)送拒絕應(yīng)答10，Response Code為98。同時向城市公共交通IC卡系統(tǒng)發(fā)送沖正通知8，Reason Code為4354，城市公共交通IC卡系統(tǒng)收到后給予應(yīng)答9。該沖正不參與清算。 城市公共交通IC卡系統(tǒng)處理：向轉(zhuǎn)出方轉(zhuǎn)發(fā)送沖正通知11，Reason Code為4354。該沖正參與清算，轉(zhuǎn)入方交易標識為不清算，不參與對帳。 轉(zhuǎn)出方處理：返回沖正應(yīng)答12，該沖正參與清算。 受理方從城市公共交通IC卡系統(tǒng)收到遲到的應(yīng)答 故障現(xiàn)象：受理方檢測到城市公共交通IC卡系統(tǒng)超時，并向終端發(fā)送拒絕信息7，所述操作后，則收到來自城市公共交通IC卡系統(tǒng)的遲到應(yīng)答8。 受理方處理：直接丟棄該應(yīng)答。 受理方不能向終端發(fā)送操作命令 故障現(xiàn)象：因通信故障，受理方不能向終端發(fā)送操作命令8。 受理方處理：向城市公共交通IC卡系統(tǒng)發(fā)送沖正通知9，Reason Code為4356。城市公共交通IC卡系統(tǒng)收到后給予應(yīng)答10。該沖正參與清算。 城市公共交通IC卡系統(tǒng)處理：向轉(zhuǎn)出方轉(zhuǎn)發(fā)轉(zhuǎn)出沖正11，Reason Code為4356。該沖正參與清算，轉(zhuǎn)入方交易標識為不清算，不參與對帳。 轉(zhuǎn)出方處理：轉(zhuǎn)出方返回應(yīng)答12，該筆沖正參與清算。 終端處理：超時后，向受理方發(fā)送沖正，Reason Code為4351，受理方收到后直接給予應(yīng)答14，該沖正不參與清算。 終端接收不到受理方發(fā)送的操作命令 故障現(xiàn)象：因通信故障，受理方發(fā)送的應(yīng)答8在中途丟失，終端會超時。 終端處理：超時后，向受理方發(fā)送沖正9，Reason Code為4351，受理方收到后直接給予應(yīng)答10，該沖正不參與清算。 受理方處理：向城市公共交通IC卡系統(tǒng)轉(zhuǎn)發(fā)沖正通知11，Reason Code為4356。城市公共交通IC卡系統(tǒng)收到后給予應(yīng)答12。該沖正參與清算。 城市公共交通IC卡系統(tǒng)處理：向轉(zhuǎn)出方轉(zhuǎn)發(fā)轉(zhuǎn)出沖正13，Reason Code為4356。該沖正參與清算，轉(zhuǎn)入方交易標識為不清算，不參與對帳。 轉(zhuǎn)出方處理：轉(zhuǎn)出方返回應(yīng)答14，該筆沖正參與清算。 終端寫卡不成功 故障現(xiàn)象：因終端原因，寫卡不成功。 轉(zhuǎn)入方拒絕轉(zhuǎn)入交易 故障現(xiàn)象：轉(zhuǎn)入方拒絕轉(zhuǎn)入交易。 城市公共交通IC卡系統(tǒng)處理：向受理方發(fā)送拒絕應(yīng)答7，同時向轉(zhuǎn)出方發(fā)送轉(zhuǎn)出沖正9，Reason Code為4366，該沖正參與清算，轉(zhuǎn)入方交易標識為不清算，不參與對帳。 轉(zhuǎn)出方處理：返回應(yīng)答10，該沖正參與清算。  4 報文接口說明 4.1 報文結(jié)構(gòu) 4.1.1 報文結(jié)構(gòu)說明 聯(lián)機交易報文包含四個組成部分，依次是：報文頭、報文類型標識符、位圖和報文域。其結(jié)構(gòu)如圖3所示： 報文頭 報文類型標識符 位圖 報文域 圖3　 報文結(jié)構(gòu) 報文頭是報文的第一個數(shù)據(jù)元素，主要記錄了報文的長度、路由、批次號等基本信息。 報文類型標識符是報文的第二個數(shù)據(jù)元素，是最高級別報文類型定義，定義了報文一般性分類，比如是交易類報文還是管理類報文。 位圖定義了哪些報文域會出現(xiàn)在報文中。位圖區(qū)可以包含一個位圖也可以包含兩個位圖。位圖個數(shù)的選擇根據(jù)交易類型而定。IC卡交易將用到55域中定義的IC卡特征信息域。位圖一定義域2到域64，位圖二定義域66到域128。 報文域構(gòu)成了報文的主體，其中大部分由ISO 8583定義，其它域由城市公共交通IC卡系統(tǒng)自定義并由城市公共交通IC卡系統(tǒng)使用。報文域的具體定義參見第4.5章內(nèi)容。 4.1.2 報文結(jié)構(gòu)分析 報文結(jié)構(gòu)如圖4所示： 圖4　 報文結(jié)構(gòu) 4.2 報文頭 本節(jié)描述了報文頭的產(chǎn)生及其各域的用法。描述中的“b”表示bit；“n”表示十進制數(shù)字。另外，本文中所有數(shù)字編碼均采用ASCII編碼方式。報文頭在報文中位置如圖5所示： 報文頭 報文類型標識符 位圖 報文域 圖5　 報文頭 4.2.1 報文頭位置和基本說明 報文頭與報文類型標識符、位圖和報文域一塊組成了一個完整的報文。凡符合報文接口的所有聯(lián)機報文都必須帶有報文頭。 用于文件傳遞的8000號系列報文不使用報文頭。 4.2.2 報文頭的基本組成 表7　 報文頭的組成 域 域名 長度 （單位：Byte） Field1 頭長度（Header Length） 1 Field2 頭標識和版本號（Header Flag and Version）