1、交通一卡通二維碼支付技術要求范圍本技術要求規(guī)定了交通一卡通二維碼（以下簡稱“二維碼”）支付的應用場景、系統(tǒng)框架及流程、二維碼數據結構、信息接口、安全要求、終端要求、手機客戶端要求等。本技術要求適用于交通行業(yè)二維碼支付的相關系統(tǒng)、終端、手機客戶端的設計與研發(fā)。規(guī)范性引用文件GM/T 0002 SM4分組密碼算法GM/T 0003 SM2橢圓曲線公鑰密碼算法JT/T 978.4-2015 城市公共交通IC卡技術規(guī)范 第4部分：信息接口JT/T 978.6-2015 城市公共交通IC卡技術規(guī)范 第6部分：安全術語和定義發(fā)碼平臺支持生成交通一卡通互聯(lián)互通二維碼、認證用戶身份、控制二維碼生成與交易風險等

2、功能，確保二維碼及支付安全性的平臺。發(fā)卡機構發(fā)行城市公共交通卡，并對清分結算的跨機構交易數據進行驗證的機構。收單機構布放交通一卡通二維碼終端，為交通一卡通二維碼提供掃碼、資金結算服務，并對清分結算的跨機構交易數據進行收集、上送的機構。手機客戶端指安裝在手機上的應用，用來生成二維碼的應用軟件。受理終端指可以識別和受理本要求中二維碼的終端設備。公私密鑰對非對稱密鑰中的公鑰和私鑰。公鑰非對稱密鑰對中公開的密鑰。私鑰非對稱密鑰對中非公開的密鑰。符號和縮略語下列符號和縮略語適用于本文件。符號定義SM2國家密碼管理局于2010年12月17日發(fā)布的橢圓曲線公鑰密碼算法。https是以安全為目標的 HTTP通

3、道Cn壓縮數字碼，即BC網B用于表示變長的二進制數，后跟數字表示二進制數據所占字節(jié)（Byte）的個數n數值，09,靠右，首位有效數字前填 0.若表示人民幣金額，則最右側兩位為角、分MM月份，0112DD日期，0131YY年份，0099hh時，0023mm分，0059ss秒,0059M必用數據元，如此域沒內容，信息出錯C可選數據元ans字母、數字和特殊字符，靠左，右邊多余位填空格。an字母和數字字符，靠左，右邊多余位填空格應用場景二維碼是一種通過特定的編碼格式來展示信息的方式，本技術要求主要規(guī)定了二維碼在交通行業(yè)中公交、地鐵的應用場景。用戶是采用被掃模式即用戶手機客戶端生成進出站二維 碼，由受理

4、終端進行掃碼。系統(tǒng)架構及流程交通一卡通二維碼支付系統(tǒng)結構交通一卡通二維碼支付系統(tǒng)結構如圖1所示。發(fā)卡機構手機客戶端申請開通風控系統(tǒng)支付結算系統(tǒng)CA1理系統(tǒng)發(fā)碼平臺用使臺平碼發(fā)權授二維碼收單機構收單平臺清分結算機構賬戶系統(tǒng)CA1理系統(tǒng)CA管理系統(tǒng)終端管理系統(tǒng)清分結算系統(tǒng)受理終端交易計費系統(tǒng)清分結算系統(tǒng)受理終端 終端管理系統(tǒng) _CA管理系統(tǒng)圖1交通一卡通二維碼支付系統(tǒng)結構圖交通一卡通二維碼支付系統(tǒng)結構中涉眾如下：清分結算機構的CA管理系統(tǒng)：負責為入網機構簽發(fā)機構公鑰證書，此證書用 于二維碼互聯(lián)互通使用；清分結算系統(tǒng)：負責采集收單機構交易數據、解析交易數據、針對不同入網機 構間交易數據進行清分結算以

5、及下發(fā)清算文件、對賬文件、結算報表等文件；支付賬戶系統(tǒng)：負責對二維碼消費行為進行記錄和管理的系統(tǒng)；二維碼發(fā)碼管理系統(tǒng)：負責生成二維碼數據并將二維碼數據下發(fā)到手機客戶端 的管理系統(tǒng)；發(fā)碼平臺的CA管理系統(tǒng)：負責為用戶分配公私鑰的管理系統(tǒng)；風控系統(tǒng)：發(fā)碼機構根據用戶交易情況、信用等級等進行風險控制的系統(tǒng)，負 責二維碼發(fā)碼安全管理；g)支付結算系統(tǒng)：發(fā)碼機構為發(fā)行的二維碼消費記錄進行支付、結算等資金操作的系統(tǒng)；發(fā)卡機構中收單平臺的賬戶系統(tǒng)：負責管理發(fā)卡機構交通一卡通賬戶、賬戶消費記錄等；發(fā)卡機構的CA管理系統(tǒng)：負責與清分結算機構的 CA系統(tǒng)進行對接，提交申請 本機構證書文件、接收清分結算機構下發(fā)的入

6、網機構證書、向終端管理系統(tǒng)下發(fā)入網機構證書等；發(fā)卡機構/收單機構的清分結算系統(tǒng)：負責與清分結算機構進行對接，上傳、 下載相關接口文件等；交易計費系統(tǒng)：負責采集受理終端上傳的原始交易數據，匹配進出站交易并根據計費規(guī)則計算交易金額；收單機構的CA管理系統(tǒng)：負責與清分結算機構的 CA管理系統(tǒng)進行對接，接收 清分結算機構下發(fā)的機構證書，并與本機構終端管理系統(tǒng)進行對接，將機構證書下發(fā)至終端管理系統(tǒng)；m)終端管理系統(tǒng)：負責下發(fā)證書、管理終端軟件更新、遠程監(jiān)控終端等；n) 手機客戶端：負責展示二維碼數據、為用戶提供界面展示、用戶消費記錄查詢、 賬戶信息查詢等。6.2 交通一卡通二維碼支付工作流程交通一卡通二

7、維碼支付工作流程如圖2所示。圖2交通一卡通二維碼支付工作流程圖交通一卡通二維碼支付工作流程中重點流程說明如下：a.參與交通一卡通二維碼支付的發(fā)卡機構CA管理系統(tǒng)需要定時向清分結算機構CA管理系統(tǒng)申請簽發(fā)交通行業(yè)二維碼支付互聯(lián)互通的機構證書；b.清分結算機構的CA管理系統(tǒng)應將根公鑰下發(fā)到收單機構，收單機構負責將中心公鑰下發(fā)到所有受理終端；d.二維碼發(fā)碼平臺負責結合賬戶的信用等級、風險等級等綜合因素決定用戶可進行預付費交易或信用支付交易，同時，該系統(tǒng)應根據用戶賬戶信息、二維碼有效期等因素生成二維碼數據；e.用戶持二維碼進行掃碼時，受理終端應驗證二維碼的真實性、有效性、完整性，成功識別二維碼后將該信

8、息記錄并準實時發(fā)送至系統(tǒng)后臺；f.交易計費系統(tǒng)接收到終端上傳的交易數據后，將進出站記錄進行匹配，并計算交易金額，最終將統(tǒng)計好的交易數據上傳至清分結算機構；并對跨區(qū)域交易數據進g.清分結算機構的清分結算系統(tǒng)將交易數據轉發(fā)至賬戶發(fā)行方， 行清分結算；h.發(fā)卡機構清分結算系統(tǒng)根據用戶消費情況向發(fā)碼平臺進行請款，并完成支付結算。交通一卡通二維碼支付交易流程交通一卡通二維碼支付交易流程如圖35所示。生成二維碼圖3申請交通一卡通二維碼流程圖記錄交易數據并完 成驗證，提示用戶 刷卡成功/上車圖4受理終端識別二維碼驗證流程圖圖5跨區(qū)域交易清分結算流程圖密鑰工作原理二維碼數據加密流程交通一卡通二維碼需要使用二級

9、密鑰進行保護，包括：發(fā)卡機構級和發(fā)碼平臺用戶級， 工作原理如圖所示，其中：a）發(fā)卡機構公鑰證書是使用清分結算機構私鑰對發(fā)卡機構公鑰進行簽名生成的 證書；b）發(fā)碼平臺用戶公/私鑰是發(fā)碼平臺為其用戶分配的獨立、不重復的密鑰對；c）用戶密鑰可安全存儲于手機客戶端，此時應保證手機客戶端的安全性，并保證 秘鑰存儲的安全性；d）用戶密鑰可存放于支付賬戶系統(tǒng)中，且應以密文形式存儲。注1:使用發(fā)卡機構私鑰對二維碼數據進行簽名形成二維碼發(fā)卡機構授權數據簽名；注2:使用發(fā)碼平臺用戶私鑰對二維碼數據以及二維碼發(fā)卡機構授權簽名數據進行簽名形成發(fā)碼平臺用戶 簽名。圖6交通一卡通二維碼數據安全結構圖受理終端驗簽流程受理終

10、端驗證二維碼的合法性流程如圖7所示，其中：a.受理終端使用發(fā)卡機構公鑰驗證發(fā)卡機構授權簽名數據的合法性、有效性；b.受理終端使用二維碼中包含的發(fā)碼平臺用戶公鑰驗證二維碼中的發(fā)碼平臺用戶簽 名數據的合法性、有效性。發(fā)卡機構授權數據 簽名圖7交通一卡通二維碼終端驗簽流程圖交通一卡通二維碼數據結構編碼格式符合QRCodeg家標準GB/T 18284-2000規(guī)范，采用二進制(8bit-byte )編碼方式。結構定義交通一通二維碼結構交通一卡通二維碼結構如圖 8所示。二維碼數據頭二維碼版本號二維碼類型發(fā)碼方式發(fā)卡機構證書編號1214二維碼數據體機構授權數據長度支戶號發(fā)構號發(fā)碼平臺編號交通一卡通卡號卡類

11、型單次消費金額上限批次號支付賬戶用戶公鑰支付賬戶系統(tǒng)授權過期時間二維碼有效時間發(fā)卡機構授權數據簽名用戶授權數據長度二維碼生成時間支付賬戶用戶私鑰簽名21644101333342652465圖8交通一卡通二維碼結構圖交通一通二維碼結構定義交通一卡通二維碼數據結構定義見表1。表1交通一卡通二維碼數據結構表序號字段名字節(jié) 長度描述格式是否 必填1二維碼版本1二維碼結構版本號。0 x800 xFF交通一通二維碼標準版本，當前 0 x80BM2二維碼類型2定義二維碼的類型：JT00-公交；JT01-地鐵；JT02-出租車；JT03-公共自行車；JT04JT99本要求保留。Cn4M3發(fā)碼方式1定義發(fā)碼的方

12、式：00-聯(lián)機發(fā)碼；01-脫機發(fā)碼。BM4發(fā)卡機構證書編號4發(fā)卡機構證書編號，編號在發(fā)卡機構向清分 結算機構申請證書時分配，發(fā)卡機構可申請 多份證書，證書編號發(fā)卡機構不可隨意改動。BM5發(fā)卡機構授權數據長度2發(fā)卡機構數據長度。BM6支付賬戶號16由支付賬戶系統(tǒng)自定義。ansM7發(fā)卡機構號4由清分結算機構統(tǒng)一分配。BM8發(fā)碼平臺編號4由清分結算機構統(tǒng)一分配。BM9交通一卡通卡號10同JT/T 978中卡號的要求BM10卡類型1見JT/T 978.2中表A.1中發(fā)卡機構特殊數據元BM第20字節(jié)卡種類型。11單次消費金額上限3二維碼支付單次消費金額上限，由支付賬戶 系統(tǒng)根據當前用戶消費狀態(tài)進行授權。

13、nM12批次號3表示針對當前用戶聯(lián)機下發(fā)一組二維碼數據 的批次。BM13支付賬戶用戶公鑰33經過壓縮的支付賬戶系統(tǒng)中用戶公鑰數據， 壓縮方法見 GM/T 0003.1中A.5。BM14支付賬戶系統(tǒng)授權過期時間4支付賬戶系統(tǒng)授權過期時間BM15二維碼有效時間2二維碼有效時間，與二維碼生成時間一起控 制二維碼有效時間。以秒為單位，此域在填 寫時無需帶單位。BM16發(fā)卡機構授權簽名65發(fā)卡機構私鑰簽名，簽名數據包括：本表中 517字段。BM17用戶授權數據長度2用戶授權數據長度BM18二維碼生成時間4二維碼生成時間戳BM19支付賬戶用戶私鑰簽名65支付賬戶用戶私鑰簽名數據，此簽名是對二 維碼數據體進

14、行簽名。BM總計長度為226字節(jié)。數據簽名使用SM第法的簽名數據內容見表2。表2數據簽名字段名長度描述格式是否 必填簽名的數據格式1十六進制，值為15BM數字簽名64二維碼中數據計算的SM簽名r|sBM發(fā)卡機構公鑰數據發(fā)卡機構公鑰數據是發(fā)卡機構提供的本機構公鑰數據，見表3。表3發(fā)卡機構公鑰數據字段名長度描述格式是否必填證書格式1十六進制，值為14bM證書失效日期2MMYY在此日期后，這張證書無效n4M證書序列號3由發(fā)卡機構分配給這張證書的唯一的二進制數bM二維碼公鑰簽名算法標識1標識使用在二維碼公鑰上的數字簽名算法。SM簟法為04。bM二維碼公鑰加密算法標識1標識二維碼公鑰對應的加密算法，暫不

15、使用，取值00。BM二維碼公鑰參數標識1用于標識橢圓曲線，同時確定 NIC。見附錄A.1bM二維碼公鑰長度1標識二維碼公鑰的字節(jié)長度bM二維碼公鑰64如果二維碼公鑰算法標識對應于 SMZ該字段為橢圓曲線上的一bM個點。發(fā)卡機構公鑰和證書使用SM第法，清分結算機構私鑰對 7.2.4數據進行簽名的證書數據格式，本部分總長度為106字節(jié)，見表4。表4機構公鑰及證書字段名長度描述格式是否必填證書格式1十六進制，值為14BM證書失效日期2MMYY在此日期后，這張證書無效n4M證書序列號3由發(fā)卡機構分配給這張證書的唯一的二進制數BM二維碼公鑰簽名算法標識1標識使用在二維碼公鑰上的數字簽名算法。SM寫法為0

16、4。BM二維碼公鑰加密算法標識1標識使用在二維碼公鑰上的加密算法，暫不使用，取值00。BM二維碼公鑰參數標識1用于標識所用的橢圓曲線。見附錄A.1BM二維碼公鑰長度1標識二維碼公鑰的字節(jié)長度BM二維碼公鑰6432位好由曲線，終端卞g據件由曲線計算出丫軸曲線，合成XY1圓曲 線。BM數字簽名64發(fā)卡機構對表2數據計算的SM簽名r|sBM7.2.6算法與密鑰本技術要求中清分結算機構私鑰對發(fā)卡機構公鑰數據進行簽名、發(fā)卡機構使用機構私鑰對二維碼數據進行簽名以及支付賬戶系統(tǒng)用戶私鑰對二維碼數據進行簽名時使用的密碼算 法應符合GM/T 0003的規(guī)定。受理終端驗證證書、簽名數據的合法性以及受理終端根據公鑰

17、X軸數據計算Y軸數據時使用的算法應符合 GM/T 0003的規(guī)定。信息接口一般要求交易記錄是由收單機構交易計費系統(tǒng)根據受理終端上傳的進出站記錄整理的，且已計算出乘車消費金額的交易記錄， 收單機構需要將此記錄上傳至中心的清分結算系統(tǒng)，清分結算系統(tǒng)根據清算規(guī)則對交易記錄進行清分結算，并將清分結算結果下發(fā)至相關機構。發(fā)卡機構、收單機構與清分結算機構間系統(tǒng)對接時，應進行安全傳輸，并約定交易保護密鑰及通訊保護密鑰。8.2文件類型文件類型包括交易類接口和清算類接口見表5。表5文件類型文件類型文件名文件標識說明交易類接口文件二維碼交易明細文件BCPD/BCPR收單機構上傳的二維碼消費明細文件。清算類接口文件

18、二維碼交易清算反饋文件FB消費清算反饋文件，反饋給收單機構。二維碼交易清算明細文件CL下發(fā)給發(fā)卡機構的二維碼消費清算明細 文件。報文交互流程發(fā)卡機構、收單機構與清分結算機構間以流的方式進行文件傳輸，傳輸方式及報文要求詳見JT/T 978.4-2015中7.3節(jié)。發(fā)卡機構、收單機構與清分結算系統(tǒng)間報文交換流程見圖 9和圖10。發(fā)卡/收單機構文件發(fā)送請求報文（4001）應答報文（4008）4清分結算機構1-文件數通知報文（4006 ） .應答報文（4008）*.十侔七自誦知相十/ anna、.|P斷點通知烈文4 4005）跖十足十口十/ ACCA .應答報文（4008）文件傳輸結束報文（4007）

19、4應答報文（4008）圖9上傳文件交互流程圖文件下載請求報文（4002）.應答報文（4008） 文件數通知報文（4006 ） _.應答報文（4008）發(fā)卡/收單機構清分結算機構文件信息通知報文（4003）.斷點通知報文（4005）應答報文（4008）數據報文（4004）應答報文（4008）文件傳輸結束報文（4007）應答報文（4008）圖10下載文件交互流程圖交易記錄文件命名規(guī)則交易記錄文件命名規(guī)則見表6。表6交易記錄文件命名規(guī)則數據元說明數據類型長度（字節(jié)）說明文件標識a4BCPD/BCPR日期n24年份用后兩位，YYMMDDhhmmss機構代碼n16清分結算機構分配序列號ans20機構自定

20、義文件標志an2H-手工賬，A-自動賬交易記錄文件結構交易記錄文件采用順序文件結構，且以流文件的方式進行傳輸。順序文件結構見JT/T-2015 中 6.1.3 。交易記錄結構交易記錄文件是由交易記錄頭、交易記錄體和交易記錄尾組成。交易記錄頭 TOC o 1-5 h z 交易記錄頭內容見表7。表7交易記錄頭字段名長度描述格式是否 必填說明開始標志5標志記錄頭的開始。anM由發(fā)送方填寫，內容為JTPAY交易總筆數4交易記錄文件中包含的交易記錄筆數，不包含記錄頭和記錄尾nM由發(fā)送方填寫。交易總金額12本域中不帶小數點。交易金額為 人民幣的時候，本域的最后兩位 應包含人民幣的角和分。nM由發(fā)送方填寫。

21、交易記錄文件 中包含的交易記錄的總金額。版本標記4版本標記(TEST/PRODan只填寫TES成PROD a) TEST測試版本； b) PRO性產版本。版本號8版本號anM版本號為000000018.6.2交易記錄尾 TOC o 1-5 h z 交易記錄尾內容見表8。表8交易記錄尾字段名長度描述格式是否 必填說明版本標記4版本標記(TEST/PRODan只填寫TES成PROD c) TEST測試版本； d) PRO性產版本。MAC16交易數據校驗碼anMMAC； 16個0F之間的16進制 字符，A應為大寫。按照MA算法按JR/T 0025.72013,初始因子為000000000000000

22、0o TOC o 1-5 h z 交易記錄體交易記錄數據結構見表9。表9交易記錄數據格式字段名長度內容格式是否 必填說明記錄長度2本條交易記錄總長度BM交易類型4見表1中二維碼類型。CnM消費類型2消費類型nM消費類型：00-表示單次消費；01-表示復合消費。掃碼類型2掃碼類型nM掃碼類型：字段名長度內容格式是否 必填說明00-主動掃碼，即用戶使 用手機掃描二維碼；01-被動掃碼，即受理終 端掃描用戶生成的二維 碼。系統(tǒng)跟蹤號66位定長數字字符，受理機 構向交易清分結算機構發(fā)送 的每一筆交易，必須賦予一 個交易流水號。nM支付賬戶號16主賬號CnM在右邊補上十六進制數 F收單機構號4收單機構標

23、志碼。nM發(fā)卡機構號4發(fā)卡機構標志碼。nM發(fā)碼平臺編 號4發(fā)碼平臺標志碼。nM商戶類型4收單機構商戶類型嗎表示商戶分類編碼（MCC nM進站二維碼長度2進站二維碼數據總長度BC當掃碼類型為01時，任 意消費類型均需填寫此 域。交易金額12本域中不帶小數點。交易金 額為人民幣的時候，本域的 最后兩位應包含人民幣的角 和分。nM貨幣代碼3交易幣種anM人民幣CNY進站二維碼 內容259進站二維碼數據內容BC當掃碼類型為01時，任 意消費類型均需填寫此 域。出站二維碼長度2出站二維碼數據總長度C當掃碼類型為01且消費 類型為01時，則此域必 填。出站二維碼 內容259出站二維碼數據內容BC當掃碼類型

24、為01且消費 類型為01時，則此域必 填。進站終端ID8同JT/T 978中終端編號的要 求。ansM出站終端ID8同JT/T 978中終端編號的要 求。ansM進站時間14二維碼用戶進站時間。格式為 YYYYMMDDhhmmssnM出站時間14二維碼用戶出站時間。格式為 YYYYMMDDhhmmssnM字段名長度內容格式是否 必填說明檢索參考號n12取值范圍000000000001 999999999999FB二維碼交易清算反饋文件用途向收單機構下發(fā)當日清分結算機構對二維碼交易的清算處理結果，供收單機構進行明細匹配。8.7.2 文件格式數據元說明數據類型長度說明文件說明區(qū)版本號n201回車符

25、s20 x0D 和 0 x0A交易頭記錄總數n6取值范圍000001999999清分結算機構清算日期n8YYYYMMDD收單機構代碼n11右補空格單筆交易長度n4包含回車換行：取值范圍 00019999保留域ans20全F回車符s20 x0D 和 0 x0A交易數據體清分結算機構流水號n12取值范圍 000000000001 999999999999收單機構流水號n12取值范圍 000000000001 999999999999收單機構受理日期n8YYYYMMDD檢索參考號n12取值范圍 000000000001 999999999999交易類型an4666-二維碼支付發(fā)卡機構清算機構標識n1

26、1右補空格，發(fā)卡機構的清結算上級單位發(fā)卡機構代碼n11右補空格，收單機構清算機構標識n11右補空格，收單機構的清結算上級單位收單機構代碼n11右補空格，交易發(fā)生地機構代碼MCCan4參考MCCt檔渠道類型an204-二維碼掃碼POSI交通一卡通卡號n2016位19位。不足右補空格卡消費計數器n6填充000000交易金額n12取值范圍 000000000001 999999999999交易日期n8YYYYMMDD交易時間n6HHMMSS算法標識（也加到FBC件中）an2a) 01-3desb) 02-SM2c) 04-SM4錯誤代碼n6清分結算機構定義，取值范圍000000999999。錯誤描述

27、ans40錯誤描述測試標志n10為正式數據；1為測試數據。手續(xù)費ans28字段格式為小數，以分為單位，保留到小數點后7位，右補空格例如：手續(xù)費為1.3333 元，字段應填寫為：133.3333333右補空格17位手續(xù)費為0.123元，字段應填寫為：12.3000000右補空格18位發(fā)卡分潤ans28字段格式為小數，以分為單位，保留到小數點后7位，右補空格例如：手續(xù)費為1.3333 元，字段應填寫為：133.3333333右補空格17位手續(xù)費為0.123元，字段應填寫為：12.3000000右補空格18位收單分潤ans28字段格式為小數，以分為單位，保留到小數點后7位，右補空格例如：手續(xù)費為1.

28、3333 元，字段應填寫為：133.3333333右補空格17位手續(xù)費為0.123元，字段應填寫為：12.3000000右補空格18位預留字段ans28保留域ans40全F回車符s20 x0D 和 0 x0ACL二維碼交易清算明細文件用途清分結算機構向發(fā)卡機構下發(fā)當日清分結算機構的清算結果，供發(fā)卡機構進行處理。8.8.2 文件格式數據元說明數據類型長度說明文件說明區(qū)版本號n201回車符s20 x0D 和 0 x0A交易頭記錄總數n6取值范圍000001999999清分結算機構清算日期n8YYYYMMDD接收機構代碼n11右補空格單筆交易長度n4包含回車換行：取值范圍 00019999。保留域a

29、ns20全F回車符s20 x0D 和 0 x0A交易數據體清分結算機構流水號n12取值范圍 000000000001 999999999999收單機構流水號n12取值范圍 000000000001 999999999999收單機構受理日期n8YYYYMMDD檢索參考號n12取值范圍 000000000001 999999999999交易類型an4666-二維碼支付收單機構清結算機構代碼n11右補空格，交易發(fā)生地單位收單機構代碼n11右補空格，交易發(fā)生地單位發(fā)卡機構清算機構代碼n11右補空格，交易發(fā)生地單位發(fā)卡機構代碼n11右補空格，發(fā)卡地MCCan4參考MCCt檔渠道類型an204-二維碼掃碼

30、POSI交通一卡通卡號n2016位到19位不足右補空格卡消費計數器n6填充全0交易金額n12取值范圍 000000000001 999999999999交易日期n8YYYYMMDD交易時間n6hhmmss算法標識an2d) 01-3dese) 02-SM2f) 04-SM4錯誤代碼n6清分結算機構定義，取值范圍000000999999錯誤描述ans40錯誤描述測試標志an10-正式數據1-測試數據手續(xù)費ans28字段格式為小數，以分為單位，保留到小數點后7位，右補空格例如：手續(xù)費為1.3333 元，字段應填寫為：133.3333333右補空格17位手續(xù)費為0.123元，字段應填寫為：12.30

31、00000右補空格18位發(fā)卡分潤ans28字段格式為小數，以分為單位，保留到小數點后7位，右補空格例如：手續(xù)費為1.3333 元，字段應填寫為：133.3333333右補空格17位手續(xù)費為0.123元，字段應填寫為：12.3000000右補空格18位收單分潤ans28字段格式為小數，以分為單位，保留到小數點后7位，右補空格例如：手續(xù)費為1.3333 元，字段應填寫為：133.3333333右補空格17位手續(xù)費為0.123元，字段應填寫為：12.3000000右補空格18位預留字段ans28回車符s20 x0D 和 0 x0A安全要求存儲安全二維碼支付交易中涉及關鍵、敏感數據需要進行安全保護，例

32、如：私鑰應存儲在手機安全區(qū)域如SE TEE等，防止信息泄露和篡改。通信安全傳輸安全二維碼支付交易涉及各系統(tǒng)之間進行信息傳輸，各系統(tǒng)之間應建立安全通信信道， 應對交易數據采用數字簽名和加密等安全方式進行傳輸，確保數據不對監(jiān)聽和篡改， 例如：基于SSL/TLS的HTTPS進行傳輸等。公網環(huán)境下，二維碼信息不應以明文形式傳輸。傳輸數據的完整性應具備對傳輸數據的鑒別機制，確保發(fā)出數據的完整性和接收數據完整性的校驗。傳輸數據的保密性應對傳輸的數據進行保密性保護，不應引起信息泄露。應用軟件安全合法性檢查和風險控制應用軟件與后臺系統(tǒng)應具備合法性檢查，通過簽名驗簽等密碼技術與后臺系統(tǒng)進行雙向認證，確保后臺系統(tǒng)

33、和應用軟件的合法性，并設置超時時間。密鑰更新要求若應用軟件涉及存儲通訊、數據加密的安全密鑰，應保證密鑰定期更新，以防密鑰丟失。應用軟件安全應用軟件應保證如下要求：a.應確保應用程序源代碼存儲的安全性，即應用程序源代碼不可泄露；b.客戶端中涉及聯(lián)機獲取的二維碼中的敏感數據應采用一定的機制進行分散存儲。c.對客戶端中敏感數據以及涉及處理該數據的程序邏輯進行保護，例如采取代碼 混淆、加殼、加密等方式，防范攻擊者對客戶端進行靜態(tài)分析、逆向工程、調 試；d.應從木馬病毒防范、信息加密保護、運行環(huán)境可信等方面提升安全防控能力。支付安全用戶支付過程中涉及的安全要求如下：a.二維碼具備分鐘級時效性，并且時效性具備動態(tài)調整能力；b.每個用戶只可單終