城市智慧卡互联互通 充值数据接口

上传人:木92****502 文档编号:123899738 上传时间:2020-03-10 格式:DOC 页数:15 大小:1.46MB
返回 下载 相关 举报
城市智慧卡互联互通 充值数据接口_第1页
第1页 / 共15页
城市智慧卡互联互通 充值数据接口_第2页
第2页 / 共15页
城市智慧卡互联互通 充值数据接口_第3页
第3页 / 共15页
城市智慧卡互联互通 充值数据接口_第4页
第4页 / 共15页
城市智慧卡互联互通 充值数据接口_第5页
第5页 / 共15页
点击查看更多>>
资源描述

《城市智慧卡互联互通 充值数据接口》由会员分享,可在线阅读,更多相关《城市智慧卡互联互通 充值数据接口(15页珍藏版)》请在金锄头文库上搜索。

1、ICS35.240.60P 07中华人民共和国国家标准GB/T XXXXXXXXX城市智慧卡互联互通 充值数据接口City smart card union Charing Data Interface (本稿完成日期:20190426)XXXX - XX - XX发布XXXX - XX - XX实施GB/T XXXXXXXXX目次1范围12规范性引用文件13术语和定义14缩略语15系统要求16报文和接口数据定义37充值申请58充值操作89充值异常处理910对账结算文件10 13城市智慧卡互联互通 充值数据接口1 范围本标准规定了城市智慧卡互联互通充值的系统要求、报文和接口数据定义、充值申请、

2、充值操作、充值异常处理及对账结算文件等。本标准适用于城市智慧卡互联互通系统中进行互联网充值系统建设与运营。2 规范性引用文件下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件,仅注日期的版本适用于本文件。凡是不注日期的引用文件,其最新版本(包括所有的修改单)适用于本文件。GB/T 31778-2015 数字城市一卡通互联互通 通用技术要求CJ/T 166-2014 建设事业集成电路(IC)卡应用技术条件GB/T 1988 信息技术 信息交换用七位编码字符集3 术语和定义下列术语和定义适用于本文件。3.1 城市一卡通 system of citys card满足于城市内综合交通(公共汽车

3、、地铁、轻轨、轮渡、出租车、公共自行车)、公共事业缴费、风景园林、社区/园区应用、停车场管理等多项业务需求的系统。3.2互联互通 City Union(参考GB/T 31778-2015)实现用户卡跨城市一卡通的应用。3.3终端 Terminal计算机网络中处于网络最外围的设备。3.4清分 clearing当日的全部网络交易数据按照各成员行之间本代他、他代本、贷记、借记、笔数、金额、轧差净额等进行汇总、整理、分类。4 缩略语下列缩略语适用于本文件。MAC 媒体访问控制(Media Access Control)JSON JS对象简谱(JavaScript Object Notation)APD

4、U 应用协议数据单元(Application Protocol Data Unit)FTP 文件传输协议(File Transfer Protocol)5 系统要求5.1 系统框架互联互通互联网架构如图1所示:图1 城市智慧卡第三方充值架构5.2 功能要求城市一卡通互联互通平台各充值接口应符合下列要求:a) 城市一卡通互联互通平台应完成第三方充值平台的充值申请、充值操作和充值异常处理接口的处理;b) 城市一卡通互联互通平台应完成充值数据的清分清算和第三方充值平台对账文件的处理,清分内容应满足GB/T 31778-2015要求;c) 充值数据接口适用于手机APP充值终端、自助充值终端、手机eSE

5、钱包和手机HCE钱包等充值方式。6 报文和接口数据定义6.1 报文格式说明1.通信方式采用http,使用POST方式提交请求参数,字符集UTF-8。数据的格式应为JSON格式。示例: Version:1.0,Format:JSON,Charset:UTF-8,Charset:UTF-8,Timestamp:2019-03-28 11:30:45,Sign_type:RSA,sign:*,Requeststr:请求参数报文集合(注意:发送报文为:data=Version:1.0,Format:JSON,Charset:UTF-8,Charset:UTF-8,Timestamp:2019-03-2

6、8 11:30:45,Sign_type:RSA,sign:*,Requeststr:请求参数报文集合)报文体内容也应为JSON格式。示例: Name:charge,Plat_id:2253123456781234,App_id:123456790010,App_id :123456790010, CardNo:1234567890123456 2.应答参数数据格式应为JSON格式示例: Version:1.0,Format:JSON,Charset:UTF-8,Charset:UTF-8,Timestamp:2019-03-28 11:30:45,Sign_type:RSA,sign:*,R

7、equeststr:返回参数集合报文体内容也应为JSON格式。示例: Name:charge,Plat_id:2253123456781234,App_id :123456790010,App_id :123456790010, CardNo:1234567890123456 3.报文中的数据区分大小写。4.通讯使用短链接。6.2 报文安全说明报文内容中包含签名信息,报文发送方用本方的私钥对报文签名,报文接收方用对方的公钥验签,如果服务端验签失败,则返回失败,丢弃报文。通卡平台下发公钥给充值平台,充值平台接入通卡平台前,需要提供公钥给通卡平台,通卡平台将充值平台的公钥配置在通卡平台中。6.3

8、接口及数据域定义序号内容名称类型备注1通用请求参数VersionString接口版本号2FormatString请求参数格式,仅支持JSON3CharsetString字符集,UTF-84TimestampString发起请求的时间, yyyy-MM-dd HH:mm:ss格式5Sign_typeString签名方式,SM2、MD5、RSA等6SignString签名7ParastrString参数集合8充值交易参数NameString交易类型名称,含验卡、圈存、查询9Plat_idString发起充值请求的平台标识10App_idString充值服务提供商在充值平台上的注册ID11CardN

9、oString卡号,卡密钥分散因子12OrderidString充值订单号(流水号)13OrderStatusString充值订单状态,分订单创建、充值成功、充值失败、充值异常、订单关闭、订单处理中等用于标识订单在交易流程中的不同情况。14AmountString充值金额15Pay_typeString交易支付类型16APDUsetStringAPDU指令序列(可包含多个APDU指令)17APDUrespStringAPDU指令执行结果(可包含多个APDU)18APDUverString支持多版本APDU,可用于标识APDU是否加密19APDUflagString0:APDU 指令信息为非空,

10、下发 apdu 指令,执行完 APDU 指令后 提交结果继续圈存过程。 1:APDU 指令信息为空,圈存结束。20TerminalNoString终端机编号21StatuscodeString状态码,0-成功,非0为其它错误码22StatusdescriptionString状态描述7 充值申请7.1 操作流程 充值申请操作包括订单预处理和订单确认两部分。持卡人通过充值终端连接充值平台,通过充值平台与通卡后台的充值申请接口进行通讯,实现卡片的充值申请操作,并完成向通卡平台账户的充值。终端设备应满足CJ/T 166-2014的要求。充值申请的具体操作流程如图2所示:图2 充值申请流程图7.2 通

11、卡平台充值申请流程通卡平台的充值申请业务流程如图3所示:图3 通卡平台充值申请业务流程图7.2.1订单预处理当充值平台接收到充值终端发起的充值申请请求时,需要验证申请请求的报文是否符合接口要求,同时将订单请求上送给通卡平台验证订单状态是否合法。得到通卡平台的验证结果后,如果不合法,则申请终止,否则组织并下发读取卡片指令,启动充值申请操作。7.2.2订单确认充值终端接收并转发读取卡片指令至IC卡, IC卡执行相应指令,并将结果返回。充值终端收到命令响应报文后,通过充值平台将响应数据传给通卡后台。通卡平台确认该卡片是否正常,从而做最终的订单确认。如若订单确认成功,进行接下来的充值操作。否则,需返回

12、错误状态至充值平台,充值平台通知充值终端中止交易。订单确认包含的内容如下:a) IC卡读取指令返回码认证;b) 卡片是否为本系统卡;c) 卡片是否为黑名单;d) 卡片状态是否正常(是否锁定,退卡);e) 充值余额是否达到上限。8 充值操作8.1 概述持卡人通过充值终端连接充值平台,通过充值平台与通卡后台的充值接口进行通讯,实现卡片充值(圈存)操作,持卡人可将其相应账户上的资金划入电子存折或电子钱包中。充值操作接口应当支持在用户充值平台和通卡后台间进行信息交互,交易过程可能存在多次交互。充值(圈存)具体操作流程如图4所示:图4 充值(圈存)具体操作流程充值(圈存)时序图如图所示:图5 充值(圈存

13、)时序图8.2 流程说明8.2.1 组织INITIALIZE FOR LOAD 指令当充值平台接收到充值终端发起的充值请求时,需要组织并下发INITIALIZE FOR LOAD指令启动充值(圈存)操作。8.2.2 处理INITIALIZE FOR LOAD 指令充值终端接收并转发INITIALIZE FOR LOAD指令至IC卡, IC卡将进行以下操作: 检查钱包是否被灰锁。如果灰锁,则回送状态码9408(钱包灰锁锁定),但不回送其它信息,同时终止命令的处理过程。 检查是否支持命令中包含的密钥索引号。如果不支持,则回送状态码9403(不支持的密钥索引),但不回送任何其他数据,同时终止命令的处

14、理过程。 产生一个伪随机数(ICC),过程密钥SESLK和一个报文签别码(MAC1),用以供通卡后台验证充值(圈存)操作及IC卡的合法性。IC卡将INITIALIZE FOR LOAD响应报文回送给充值终端处理。如果IC卡回送的状态码不是9000,则充值操作终止。8.2.3 验证 MAC1收到INITIALIZE FOR LOAD命令响应报文后, 充值终端通过充值平台将响应数据传给通卡后台。通卡后台将生成SESLK并确认MAC1是否有效。如果MAC1有效, 充值操作将继续执行。否则,需返回错误状态至充值平台,平台通知充值终端中止交易。8.2.4 组织CREDIT FOR LOAD指令在确认能够进行充值(圈存)交易后,充值平台将从持卡人在的相应帐户中扣减充值(圈存)金额,并通知通卡平台。通卡平台产生一个报文签别码(MAC2),用于IC卡对通卡平台进行合法性检查。成功地进行了充值(圈存)交易后,通卡平台将电子存折联机交易

展开阅读全文
相关资源
相关搜索

当前位置:首页 > 行业资料 > 国内外标准规范

电脑版 |金锄头文库版权所有
经营许可证:蜀ICP备13022795号 | 川公网安备 51140202000112号