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

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

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