DBJT02T 001-2021 交通一卡通二维码支付技术指南

爱来自氢气工艺喵!(づ。◕◡◡◕。)づ

标准信息

标准正文

0 前言

本标准参照 《广西交通一卡通二维码支付技术指南》 为基。
由 Larker_package 起草。
本标准实行于全服,强制实行于恒夏。

1 范围

本文件规定了恒夏交通一卡通二维码支付技术的术语和定义、 缩略语、 应用场景、 支付体系框架和流程、 二维码数据结构、 信息接口、 安全要求、 受理终端要求以及客户端软件要求。
本文件适用于恒夏交通一卡通二维码支付技术的相关系统、 受理终端、 智能终端客户端软件等的设计、 研发和应用。

2 规范性引用文件

下列文件中的内容通过文中的规范性引用而构成本文件必不可少的条款。其中, 注日期的引用文件,仅该日期对应的版本适用于本文件。 不注日期的引用文件, 其最新版本(包括所有的修改单) 适用于本文件。

  • GB/T 2312 信息交换用汉字编码字符集 基本集
  • GB/T 18284 快速响应矩阵码
  • GB/T 32905 信息安全技术 SM3密码杂凑算法
  • GB/T 32907 信息安全技术 SM4分组密码算法
  • GB/T 32918 (所有部分) 信息安全技术 SM2椭圆曲线公钥密码算法
  • JR/T 0025. 7 中国金融集成电路(IC) 卡规范 第7部分: 借记/贷记应用安全规范
  • JT/T 978. 2—2015 城市公共交通IC卡技术规范 第2部分: 卡片
  • JT/T 978. 3 城市公共交通IC卡技术规范 第3部分: 读写终端
  • JT/T 978. 4—2015 城市公共交通IC卡技术规范 第4部分: 信息接口
  • JT/T 978. 6—2015 城市公共交通IC卡技术规范 第6部分: 安全
  • JT/T 1179—2018 交通一卡通二维码支付技术规范

3 术语和定义

下列术语和定义适用于本文件。

3.1 二维码 two-dimensional code

用二进制数据相对应的图形来表示数据信息的几何形体。 [来源: JT/T 1179—2018, 3. 1]

3.2 恒夏交通一卡通二维码支付体系 Hengxia two-di mensi onal code payment system of transport card

恒夏交通一卡通应用场景支付所涉及的运营方、 系统和受理终端等的统称。 [来源: JT/T 1179—2018, 3. 2, 有修改]

3.3 发码平台 publishing two-dimensional code platform

支持生成广西交通一卡通二维码、 认证用户身份、 控制二维码生成与交易风险等功能, 确保二维码及支付安全性的平台。 [来源: JT/T 1179—2018, 3. 3, 有修改]

3.4 受理终端 terminal

可识别和受理二维码的终端设备。 [来源: JT/T 1179—2018, 3. 4]

3.5 发卡机构 card issuer

发行城市公共交通IC卡和恒夏交通一卡通二维码, 并对清分结算交易数据进行验证的机构。 [来源: JT/T 1179—2018, 3. 5, 有修改]

3.6 收单机构 acquirer

通过受理终端, 为恒夏交通一卡通二维码提供扫码、 资金结算等服务, 并对清分结算交易数据进行 收集和上传的机构。 [来源: JT/T 1179—2018, 3. 6, 有修改]

3.7 入网机构 institution

拥有发卡、 收单中至少一种职能或拥有清分结算职能的恒夏交通一卡通运营的实体。 [来源: JT/T 1179—2018, 3. 7, 有修改]

3.8 清分结算机构 clearing and settlement institution

对入网机构的跨机构交易数据提供清分、 清算以及结算服务的机构。 [来源: JT/T 1179—2018, 3. 8]

3.9 支付账户 payment account

为恒夏交通一卡通二维码支付提供资金来源的用户个人账户。 [来源: JT/T 1179—2018, 3. 9, 有修改]

3.10 用户账户 card account

恒夏交通一卡通发卡机构用于记录与管理用户所有交易状态的账户。 [来源: JT/T 1179—2018, 3. 10, 有修改]

3.11 公钥 public key

非对称密钥对中公开的密钥。 在数字签名时, 公钥用于验证。 [来源: JT/T 1179—2018, 3. 11]

3.12 私钥 private key

非对称密钥对中非公开的密钥。 在数字签名时, 私钥用于签名。 [来源: JT/T 1179—2018, 3. 12]

3.13 发送方 sender

信息交流中, 信息输出方为发送方。

3.14 接收方 accepter

信息交流中, 信息输入方为接收方。

3.15 短连接 short connection

数据传送过程中, 当需要发送数据时, 才建立连接, 数据发送完成后, 则断开此连接。

4 缩略语

下列缩略语适用于本文件。

  • CA: 电子商务认证授权机构(Certificate Authority)
  • DES: 数据加密标准(Data Encryption Standard)
  • FTP: 文件传输协议(File Transfer Protocol)
  • HTTPS: 超文本安全传输协议(Hyper Text Transfer Protocol over Secure Socket Layer)
  • IIN: 发卡机构识别码(Issuer Identification Number)
  • I/O: 输入输出端口(Input/Output)
  • MAC: 报文鉴别码(Message Authentication Code)
  • MAK: MAC密钥(MAC Key)
  • MMK: 成员主密钥(Member Master Key)
  • QR Code: 快速响应矩阵码(Quick Response Code)
  • SM2: SM2椭圆曲线公钥密码算法(Public Key Cryptographic Algorithm SM2 Based on Elliptic

Curves)

  • SM3: SM3密码杂凑算法(SM3 Cryptographic Hash Algorithm)
  • SM4: SM4分组密码加密算法(SM4 Cryptographic Algorithm)
  • SSL/TLS: 安全套接层/传输层安全(Secure Sockets Layer/Transport Layer Security)
  • TC: 交易证书(Transaction Certificate)
  • TLV: 标签、 长度、 值(Tag Length Value)
  • UTC: 协调世界时(Coordinated Universal Time)
  • VPN: 虚拟专用网络(Virtual Private Network)

5 应用场景

在恒夏公共交通应用场景中, 用户使用智能终端设备中的客户端软件生成恒夏交通一卡通二维码,采用被扫模式实现受理终端对恒夏交通一卡通二维码读取、 验证与支付。

6 支付体系架构及流程

6.1 体系架构

恒夏交通一卡通二维码支付体系架构由发卡机构、 收单机构、 证书管理中心、 清分结算机构等各系 统组成。

6.1.1 发卡机构

支付账户系统
对支付账户的交易进行记录和管理
二维码发码管理系统
生成二维码数据,并将二维码数据下发到客户端软件
风控系统
根据用户交易情况、 信用等级等进行风险控制, 负责二维码发码安全管理
支付结算系统
为发行的二维码消费记录进行支付、 结算等资金操作
用户账户系统
对用户账户所有交易进行记录与管理
发卡平台 CA 管理系统
向证书管理中心申请发卡机构公钥证书, 并存储证书
清分结算系统
接收跨区域清分结算数据, 并对跨区域交易数据进行验证
客户端软件
展示二维码数据、 为用户提供界面展示、 用户消费记录查询、 账户信息查询等

6.1.2 收单机构

终端管理系统
与收单机构的 CA 管理系统进行对接, 将中心根公钥证书下发至所有受理终端、 管理受理终端软件更新、 远程监控终端等
CA 管理系统
与证书管理中心的 CA 管理系统对接, 接收并存储证书管理中心下发的中心根公钥证书
交易计费系统
采集受理终端上传的原始交易数据, 匹配进出站原始交易并根据计费规则计算交易金额
清分结算系统
上传跨区域二维码交易数据, 接收清分结算机构的清算结果文件

6.1.3 证书管理中心

CA 管理系统为入网机构签发机构公钥证书, 实现二维码互联互通

清分结算机构

清分结算系统, 实现二维码交易数据收发、 数据验签、 实时记账、差错处理和清分结算等

6.2 工作流程

6.2.1 证书准备工作

证书准备工作的具体流程如下:

  1. 恒夏二维码证书中心的 CA 管理系统向交通运输部证书管理中心(以下简称“证书管理中心” )

的 CA 管理系统申请签发广西交通一卡通二维码支付互联互通发卡机构公钥证书;

  1. 恒夏二维码证书中心接收证书管理中心公钥证书并下达至收单机构, 收单机构负责将证书管理

中心公钥证书下发至其所有二维码受理终端。

6.2.2 支付和清算工作

恒夏交通一卡通二维码支付和清算工作具体流程如下:

  1. 发码平台应评定账户的信用等级、风险等级等,并综合各因素决定可否为该用户生成二维码数据。若可生成二维码,发码平台应根据用户账户信息、 二维码有效期等生成二维码数据;
  2. 用户持恒夏交通一卡通二维码进行扫码时,受理终端应验证二维码的真实性、有效性和完整性,成功识别二维码后进行记录, 并将二维码交易信息准实时发送至收单机构交易计费系统;
  3. 收单机构的交易计费系统接收到受理终端上传的交易数据后, 根据分时分段消费和单次消费的计费规则进行计费。 分时分段消费交易根据进出站交易记录进行匹配,计算交易金额。单次消费交易根据受理终端或后台计算交易金额。交易计费系统根据交易记录以及交易金额组成完整的交易记录并传送至收单机构清分结算系统;
  4. 收单机构清分结算系统根据发卡机构代码判断跨区域交易数据, 并将跨区域交易数据上传至清分结算机构;
  5. 清分结算机构的清分结算系统将跨区域交易数据转发至发卡机构, 并对跨区域交易数据进行清

分结算;

  1. 发码平台根据发卡机构清分结算系统的用户消费情况进行记账, 并完成支付结算。

6.3 交易流程

6.3.1 申请二维码

申请交通一卡通二维码流程具体内容如下:

  1. 客户端软件采集用户申请生成恒夏交通一卡通二维码的请求信息, 包括用户账户信息等;
  2. 发码平台判断申请用户账户信息是否可生成恒夏交通一卡通二维码, 包括下列情况:
  • 若允许用户生成恒夏交通一卡通二维码, 发码平台根据联机或脱机发码方式, 生成恒夏交通一卡通二维码数据;
  • 若发码平台支持联机发码, 发码平台应将完整的二维码数据下发至客户端软件;
  • 若发码平台支持脱机发码, 应将发卡机构签名后的数据下发至客户端软件, 并由客户端软件生成最终的二维码数据;
  • 若发码平台拒绝二维码生成请求, 交易终止。
  1. 发码平台向发卡平台申请发卡平台签名。发码平台在得到用户签名后, 决定联机或者脱机发码,并根据情况将签名(脱机发码) 或者二维码(联机发码) 安全下发;
  2. 客户端软件收到来自发码平台发送的二维码数据后, 对二维码数据的完整性与有效性进行验证。
  • 若验证通过, 则根据用户选择判断是否在客户端软件上展示二维码, 若不需要展示则将生成的二维码存储在客户端软件的安全区域中
  • 若验证不通过, 则交易终止。客户端可根据实际情况,重新向发码平台申请重新分发签名(脱机发码)或者二维码(联机发码),以同样的步骤进行校验使用。
6.3.2 受理终端验证二维码
  1. 用户将生成的二维码放置在受理终端二维码扫码处,受理终端读取二维码信息,并判断是否可以接受二维码头对应版本。若不可以接受,则交易终止;若可以接受,则受理终端进行以下验证流程。
  2. ~

= 7 二维码数据结构

7.1 数据结构

数据主要由以下字段组成。格式为纯文本格式。

表 二维码数据结构组成部分
序号 字段名称 长度 字段说明
1 二维码头 10 用来辨识是否为一卡通二维码。字段内容强制为 02001JTCODE
2 发卡机构代码 4 由证书中心指定。实例值"恒夏交通一卡通" 2500
3 发码平台代码 4 由证书中心指定。实例值"爱恒夏APP" 7530
4 用户识别号 10 由发码平台自定,用以识别用户。
5 支付识别号 4 由发码平台自定,用以确认支付时所使用的支付方式
6 用户账户类型 1 判断二维码用户类型,给予相应优惠。值1:儿童 (14-) / 值2:青年 (14-22) / 值3:普通 / 值4:优待 / 值5:应急
7 消费金额上限 5 支付金额上限,超出则无法乘车。单位:分
8 生码时间戳 8 生成二维码时的时间戳
示例 示例 示例 示例
示例 示例 示例 示例
示例 示例 示例 示例
示例 示例 示例 示例
示例 示例 示例 示例
示例 示例 示例 示例
示例 示例 示例 示例
示例 示例 示例 示例
为了让您的浏览体验更加高效、方便和个性化,遵照《中华人民共和国网络安全法》和《信息安全技术个人信息安全规范》,我们需要您允许本站使用Cookies。在某些情况下,Cookies是使网站正常运行的必要条件。