DB32／T 4753-2024 文化场馆和旅游景区电子票务系统技术规范

DB32/T4753—2024

文化场馆和旅游景区电子票务系统

技术规范

1范围

本文件规定了文化场馆和旅游景区电子票务系统业务描述、系统应用架构、系统功能要求、系统性能

要求、外部接口要求和安全要求等方面的内容。

本文件适用于实行各类票务管控的文化场馆和旅游景区电子票务系统建设。

2规范性引用文件

下列文件中的内容通过文中的规范性引用而构成本文件必不可少的条款。其中，注日期的引用文

件，仅该日期对应的版本适用于本文件；不注日期的引用文件，其最新版本（包括所有的修改单）适用于本

文件。

GB/T20988—2007信息安全技术信息系统灾难恢复规范

GB/T22239信息安全技术网络安全等级保护基本要求

GB/T32918.2—2016信息安全技术SM2椭圆曲线公钥密码算法第2部分：数字签名算法

LB/T034—2014景区最大承载量核定工作导则

DB32/T4754—2024文化场馆和旅游景区身份核验系统一卡通技术规范

3术语和定义

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

3.1

电子票务系统e⁃ticketingsystem

使用包括但不限于电子技术、条形码技术、单片机技术、双机热备技术、自动控制技术、无线传输技

术、精密机械加工技术及计算机网络技术、加密技术等信息技术，实现网络售票、检票、查询、汇总、统计、

报表、防伪等各种门票通道门禁控制管理功能的信息系统。

3.2

门票介质ticketmedium

包括但不限于基于射频识别技术（RFID）、二维码和生物识别等技术，可储存门票和游客（访客、读

者）身份信息，用于系统核销的凭证载体门票介质。

注：包括但不限于身份证、社保卡、数字旅游卡、电子门票码和纸质门票和生物特征等。

3.3

数字旅游卡digitaltravelcard

文旅产品和服务在线定制的数字化卡。

3.4

生物特征biologicalcharacteristic

人体中可被电子设备采集和识别的具有个体唯一性的部位特征。

1

DB32/T4753—2024

3.5

核销终端verificationterminal

用于对电子票务系统售出的门票进行合法性的验证及票务核销的终端硬件设备。

3.6

自有电商平台selfbuilte⁃commerceplatform

隶属于文旅场所、旅游景区自主搭建的电商营销平台，区别于OTA第三方电商平台。

4缩略语

下列缩略语适用于本文件

HIM：人机界面模块（HumanMachineInterface）

OTA：在线旅行社（OnlineTravelAgency）

RFID：射频识别（RadioFrequencyIdentification）

5系统业务描述

5.1概述

系统业务应包括文化场馆和旅游景区票务中心的票务管理、售票和检票三个方面内容，负责业务交

互的HIM界面的终端宜由PC端、移动端、自助售取票终端和核销终端等组成。

5.2票务管理

票务管理业务宜包括票种设置、库存管理、门票出入库，宜通过PC端进行业务交互。相关业务流程

如图1所示。

图1电子票务系统票务管理流程

5.3售票

售票业务应包括散客和团队的线下售票、线上售票、下单支付、生成票务凭证等业务，宜通过PC端、

移动端和自助售取票终端开展业务。相关业务流程如图2所示。

图2电子票务系统售票流程

2

DB32/T4753—2024

5.4检票

检票业务应包括核销设备检票、读取门票介质信息、上传信息至电子票务系统、判断有效性、反馈信

息至核销设备和最终实现入园成功或禁止入园。相关业务流程如图3所示。

图3电子票务系统检票流程

6系统应用架构

宜符合如下要求，如图4所示：

a）交互层：系统与用户的交互场景应包括售票场景、检票场景和票务管理场景；

b）应用层：宜包括中心管理、库存管理、财务结算管理、售票管理、检票管理和分销与渠道管理；

c）基础支撑层：应为系统运行提供支撑性底层服务，宜实现系统感知、数据传输与存储、识别对比、

操作互动、硬件控制、安全防护和数据分析等功能，宜包括基础操作系统和基础硬件，如网络设

备、数据库软件、WEB服务器、硬件服务器、售检票端软硬件等。

图4电子票务系统技术架构

3

DB32/T4753—2024

7系统功能要求

7.1基础支撑

7.1.1基础操作系统

系统PC端桌面应用程序，应支持至少在一种主流操作系统上运行。主流的操作系统包含Win⁃

dows、macOS、Linux等。

7.1.2基础硬件

应包括票务数据库服务器、票务系统应用部署服务器、售票端硬件、核销端硬件和网络安全防护设

备等。

应具有完整的架构体系、安全防护能力和数据安全。网络线路和设备宜具有实时热备份和应急处理

手段。

7.2应用层

7.2.1内部管理

中心管理

.1设备管理

应对销售终端设备、移动终端设备、核销终端设备以及其他终端设备进行管理。

.2用户及权限管理

应支持创建不同用户角色，如售票员、财务员、管理员等，并进行权限管理。

.3日志管理

应记录系统用户操作系统记录，包含后台登录日志、后台操作日志、窗口登录日志和窗口操作日志。

.4配置管理

应满足不同场馆或景区票务的集中配置、快捷配置等操作，具体包括：

a）对售票规则、检票规则、退票规则和打印规则等门票业务规则进行配置；

b）对门票的单张与多张打印，计时与计次规则、次数限制与购票、生效、过期时间的门票属性进行

配置。

.5数据推送

应实时统计门票销售、检票、退票等数据，并进行数据推送。

库存管理

.1预约库存管理

应依据景区承载量通过控制票务库存的方式进行管理，包含分时（门票）预约管理、实名制管理；对文

化场馆内部分收费的临时展览应预设时段性的预约库存管理。

4

DB32/T4753—2024

.2分时（门票）预约管理

应采用分时间段预约的方式，对园区的门票进行预约管控。

.3实名制预约管理

应对游客采取实名制预约管理。对外宾或持有军人证、残疾证等游客应进行相关证件有效识别后提

供换取票服务。

.4门票入/出/退库

应支持对门票的入/出/退库操作，显示操作明细、入/出/退库明细。

.5票型票价管理

应支持对各票种及票型的管理，并进行系统审核。

财务结算管理

.1支付结算

应支持OTA电商和自有电商平台、人工窗口、旅行社签单、自助等渠道的支付结算，支持现金、银行

卡、互联网（支付宝、微信、银联、数字人民币）等多种支付方式，设置支付方式的优先级，应通过标准接口

或授权充值等形式支持与所有售票渠道的每日交易对账与结算。

.2对账报表

应支持生成对账报表，包括销售报表、线上（下）营销报表，具体如下：

a）销售报表是所有营收门票的销售数量和金额；

b）线上营销报表是OTA电商和自有电商平台的票务销售数量和金额报表；

c）线下营收报表是窗口、自助售取票机门票的销售数量和金额报表。

.3电子发票

应支持与电子发票系统对接，开具电子发票、冲红、作废、参数配置等功能。

7.2.2对客服务

售票管理

.1售票服务

应提供在线、窗口、自助和旅行社签单购票等多种售票服务。

.2电子年卡

应提供电子年卡的销售、激活与线上预约服务。

.3取票管理

应支持游客（访客、读者）凭游客（访客、读者）身份证、购票订单号、手机号、电子票二维码等介质进行

取票。

5

DB32/T4753—2024

应支持人工取票和自助取票方式。

.4退票管理

订单退票退款应采取原路返回原则，宜对已检票未入园的游客进行退票服务，并提供现场或在线退

改咨询服务。

.5订单管理

应提供票务订单信息的查询、筛选、处理等功能，具体要求包括：

a）对订单的票种名称、票价、售票时间、使用时间、使用次数、门票状态、入园设备信息的查询筛选；

b）对错误订单的纠正处理的订单冲正功能；

c）门票重新打印及重打印信息的记录。

检票管理

.1检票模式

检票模式应包括散客/团队身份证或电子身份证检票、二维码检票、年卡检票、数字旅游卡检票和生

物特征识别检票及一票多日、一票多次入园核销等模式，应运用于同一台固定式或可移动式核销终端检

票设备（检票设备标准参考GA/T1260人行出入口电控通道闸通用技术要求），具体检票模式要求包括：

a）团队检票应支持实名制或非实名制，实行一人一票（证）或一团一票；

b）年卡的检票应支持有效门票凭证介质（卡、身份证、二维码或生物特征）；

c）系统应支持数字旅游卡（IC卡、入园身份码）的刷卡、码核销和数据上传与留存。

.2门票介质

应支持二代身份证或电子身份证、三代社保卡、电子社保卡、数字旅游卡（入园身份码、IC卡）、中华

人民共和国外国人永久居留身份证、二维码（电子门票码）和生物特征（人脸）作为门票入园凭证。

.3门票编码

门票编码规则详见附录A。

分销与渠道管理

.1电商（OTA和自有）平台分销管理

电商平台分销应包括OTA电商和自有电商平台，其预约管理应与系统进行数据对接。

.2团队（旅行社）分销管理

团队（旅行社）分销的预约管理应与系统进行数据对接。

应对旅行社分销商的审核、分类和年审管理功能。

.3异常名单

应设置异常名单和个人身份证异常名单的限制分销功能。

应具备异常名单的解封功能。

6

DB32/T4753—2024

.4分销财务管理

应提供预付金管理和团队（旅行社）价格管理功能。

8系统性能

应实时处理业务请求，在3s内下达命令并返回处理结果。

应对保存的数据进行统计及报表查询，在10s内显示并返回查询结果。

宜每日处理10万笔以上数据和每秒能处理100条以上交易数据的能力。

9外部接口要求

9.1外部接口概述

外接接口宜包括票务数据上报接口、社保卡一卡通核验接口、数字旅游卡业务数据接口和互联网直

分销支撑数据接口。

9.2票务数据上报接口

9.2.1对接内容

应包含实时客流数据、预约数据和开放状态数据，并遵循DB32/T4754—2024相关要求。

9.2.2对接要求

应遵循DB32/T4754—2024关于对接方式、频次、规则和路径的要求。

9.3社保卡一卡通核验接口

9.3.1对接内容

应满足用户使用多种身份核验介质（社保卡、身份证、市民卡、电子社保卡）核验要求，应遵循省级文

旅行政主管部门的要求提供的标准化接口实现数据对接，实现用户身份转换。

应遵循DB32/T4754—2024中身份核验数据部分要求。

9.3.2对接要求

应遵循DB32/T4754—2024关于对接方式、频次、规则和路径的要求。

当系统与省级文旅行政主管部门提供的标准化接口通信链路断开时，应自动切换为离线模式，只使

用身份证核验入园，保障游客入园不受影响。

9.4数字旅游卡业务数据接口

9.4.1对接内容

应包括数字旅游卡业务核验数据和核销数据，应遵循所对接的数字旅游卡业务平台数据接口技术规

范，应符合附录B中B.3定义的数字旅游卡业务数据接口技术规范。

对接内容包括：

a）联机核销；

b）套餐情况查询；

7

DB32/T4753—2024

c）明细查询；

d）汇总查询；

e）预约明细查询；

f）签名算法。

9.4.2对接要求

应实时调用数字旅游卡业务平台数据接口。

9.4.3对接流程图

对接流程图见图5。

图5数字旅游卡业务对接流程图

应支持用户使用多种身份核验介质（社保卡、身份证、市民卡、电子社保卡）核验数字旅游卡要求，具

体内容包括：

a）票务系统应支持同步用户刷卡介质（社保卡、电子社保卡、数字旅游卡、入园码等）至省文旅一卡

通数据应用共享中台，根据中台返回的用户身份信息核验是否有实名购票记录，对未购票用户，

同步用户身份信息至中台获取用户是否具有数字旅游卡权益；

b）省文旅一卡通数据应用共享中台应支持对接省人社厅、省数字旅游卡等外部平台，将社保卡、电

子社保卡、数字旅游卡、入园码等介质数据统一转换为用户身份数据，并获取用户标签，包括是

否为70周岁以上老人、是否为退休职工等，同时通过省数字旅游卡平台获取用户是否具有数字

旅游卡权益，同步结果至票务系统；

c）省数字旅游卡平台应支持核验用户是否具有数字旅游卡、是否已预约、当前景区是否使用超限

等权益，并反馈结果。

9.5互联网直分销支撑数据接口

9.5.1对接内容

应符合B.2定义的互联网分销支撑接口技术规范。对接内容包括：

a）商品库存和价格数据；

b）订单下单数据；

c）订单预下单数据；

d）订单支付确认数据；

8

DB32/T4753—2024

e）订单详情数据；

f）订单信息修改数据；

g）门票凭证重发数据；

h）订单凭证数据；

i）退订数据；

j）验证消费通知数据；

k）退票通知数据；

l）下单通知数据；

m）分时预约时段和库存数据；

n）开票数据；

o）开票结果数据。

9.5.2对接要求

互联网渠道平台应实时调用系统互联网直分销支撑数据接口。

9.6数据接口协议

9.6.1接口要求

数据接口协议宜遵循附录B。

9.6.2接口方式

宜采用HTTPS+JSON方式。

9.6.3接口说明

具体接口说明包括：

a）身份校验接口遵循DB32/T4754—2024中A.2的要求；

b）实时客流数据上报接口遵循DB32/T4754—2024中A.3的要求；

c）预约数据接口遵循DB32/T4754—2024中A.4的要求；

d）文化场馆和旅游景区状态数据接口遵循DB32/T4754—2024中A.5的要求；

e）获取商品库存和价格接口遵循B.2.1的要求；

f）订单下单接口遵循B.2.2的要求；

g）订单预下单接口遵循B.2.3的要求；

h）订单支付确认接口遵循B.2.4的要求，该接口实现方式为异步方式，异步通知由B.2.11下单通知

接口实现；

i）订单详情接口遵循B.2.5的要求；

j）订单信息修改接口遵循B.2.6的要求；

k）门票凭证重发接口遵循B.2.7的要求；

l）退订接口遵循B.2.8的要求，该接口实现方式为异步方式，异步通知由B.2.10退订通知接口

实现；

m）验证消费通知接口遵循B.2.9的要求，改接口发起方为电子票务系统，接收方分销商平台；

n）退订通知接口遵循B.2.10的要求，改接口前置接口为B.2.8退订，发起方为电子票务系统，接收

方分销商平台，退票通知接口遵循B.2.11的要求；

o）下单通知接口遵循B.2.12的要求；

9

DB32/T4753—2024

p）查询分时预约时段和库存接口遵循B.2.13的要求；

q）开票接口遵循B.2.14的要求；

r）开票查询接口遵循B.2.15的要求；

s）数字旅游卡联机核销接口遵循B.3.1的要求；

t）数字旅游卡套餐情况查询接口遵循B.3.2的要求；

u）数字旅游卡明细查询接口遵循B.3.3的要求；

v）数字旅游卡汇总查询接口遵循B.3.4的要求；

w）数字旅游卡预约明细查询接口遵循B.3.5的要求；

x）数字旅游卡签名算法遵循B.3.6的要求。

10安全要求

10.1基本要求

一般情况下，业务系统安全宜不低于GB/T22239—2019中二级标准要求，在业务系统达到百万数

据级别时，安全宜不低于GB/T22239—2019中三级标准要求。

10.2系统安全

10.2.1权限

电子票务系统为操作用户提供独立的账号。应包括但不限于登录用户名、登录密码、角色、操作

权限。

10.2.2系统用户口令

具备完整的口令管理，包括口令有效期、限制口令重用、口令错误的忽略、警告、审计、失效、中

断操作、强迫签退和口令挂起等。

口令宜根据系统重要性和用户权限采取不同的有效期（30d/60d）。

10.2.3日志

应建立文件系统的行为日志、访问日志、接口日志、服务日志。

10.2.4操作安全的保证

应对系统内所有操作进行必要的保护，对可能出现的误操作应予以提示，尽可能方便用户操作，引导

操作者完成正确操作。

10.2.5通信安全

数据传输在进行通信时应对数据进行加密，采用国标密码算法要求GB/T32918.2—2016。数据接

收端应能安装国密证书。

10.3数据安全

10.3.1数据库安全运维服务

应提供数据安全运维服务，在数据传输过程中或在数据库存储时进行加密，确保关键数据不被窃取。

10

DB32/T4753—2024

10.3.2隐私数据安全

应按照GB/T22239—2019，具体要求如下。

a）数据完整性

应采用校验技术或密码技术保证重要数据的完整性，包括但不限于鉴别数据、重要业务数据、重

要审计数据、重要配置数据、重要视频数据和重要个人信息等。

b）数据保密性

应采用密码技术保证重要数据在传输、存储过程中的保密性，包括但不限于鉴别数据、重要业务

数据和重要个人信息等。

c）剩余信息保护

应保证鉴别信息、存有敏感数据所在的存储空间被释放或重新分配前得到完全清除。

d）个人信息保护

应对采集和保存业务必需的用户个人信息进行（数据变形处理）脱敏存储使用，不应未授权访问

和非法使用用户个人信息。对用户个人信息数据应当使用后及时销毁处理。应对用户个人信

息的采集增加授权和撤销信息的通知通道。

在处理个人信息前，均应以显著方式、清晰易懂的语言真实、准确、完整地向个人告知相关事项。

10.3.3数据全生命周期安全

数据库数据存储应对数据进行分类分级存储，确保全周期数据安全且应根据数据全生命周期各阶段

特点，采取相应的数据安全保护措施，建立数据分类分级管理制度处置，加强对重要数据、企业商业秘密

和个人信息的保护。

10.3.4非规范操作

应在出现非规范操作时（如非正常关机、断电等）保持票、款和相关数据的一致性。

10.3.5数据库备份和恢复

应具备数据库数据备份的功能，每天应至少进行一次备份。

应具备备份数据恢复的功能。应符合GB/T20988—2007中信息系统灾难恢复的要求。有条件的

单位宜考虑异地备份。

10.3.6数据传输安全

应对数据通信进行加密并支持数据重传。

10.3.7数据库审计

应对数据库的各类操作行为进行监视、记录、分析，生成审计报表。对于监测到的风险事件，及时生

成告警并以邮件、短信等方式通知相关人员。确保系统符合各类法律法规对数据库审计的要求。

10.4用户认证安全

10.4.1内部人员身份认证

应有效区分业务人员和数据管理人员等内部人员身份，进行身份认证。

11

DB32/T4753—2024

10.4.2外部人员身份证

应有效区分第三方开发、运维和常驻人员的外部人员身份，进行身份认证。

10.4.3账户安全

应采取安全认证措施和安全管理策略，确保系统账号安全，支持对信息访问者进行身份识别和接入

位置识别，并对信息访问者的访问权限进行控制。

12

DB32/T4753—2024

附录A

（规范性）

文化场馆和旅游景区电子票务系统门票编码规则

A.1统一编码规则

单位编码采用注册制，由单位在初次申报文化场馆、旅游景区信息中生成。若对已申报单位信息进

行变更，需要由单位向省文化和旅游厅申报核准后再执行。

单位统一编码规则见表A.1。

表A.1统一编码规则

数据项规则类型位数说明

城市（地区）行政

字符4位见国家统计局《城市（地区）行政区划代码标准》

代码

单位代码

按照流水号罗列，位数不足3位高位补0。一个行政管辖单位分配一

单位序号字符3位

个独立序号

景点类型字符2位如：00：主园；01：园中园；10：独立园区

景点代码单位下属二级景按照流水号罗列，包含景点、重点流量监控区域，如独立单位无分支

字符2位

点序号景点按照00补位

按照LB/T034—2014相关规定并结合文化场馆或旅游景区实际上

最大承载量代码字符6位

报承载量综合核算确认

承载量代码

景点最大承载量按照LB/T034—2014相关规定并结合文化场馆或旅游景区实际上

字符6位

代码报承载量综合核算确认

单位类型字符3位如：国家AAAAA级旅游景区、博物馆、图书馆等

单位属性

单位收费类型字符1位详见表A.3

单位全称同工商登记名称字符100位如：敦煌莫高窟

单位简称字符100位如：莫高窟

最长游玩天数以“天”计字符1位如：2天

A.2基础信息

基础信息见表A.2。

表A.2基础信息

数据项规则类型位数说明

按照LB/T034—2014相关规定并结合文化场馆或旅游景区实际

最大承载量代码字符6位

上报承载量综合核算确认

承载量代码

景点最大承载量按照LB/T034—2014相关规定并结合文化场馆或旅游景区实际

字符6位

代码上报承载量综合核算确认

13

DB32/T4753—2024

表A.2基础信息（续）

数据项规则类型位数说明

单位类型字符3位如：代码表示国家AAAAA级旅游景区、博物馆、图书馆等

单位属性

单位收费类型字符1位详见表A.3

单位全称同工商登记名称字符100位如：敦煌莫高窟

单位简称字符100位如：莫高窟

最长游玩天数以“天”计字符1位如：2（天）

A.3收费形式

收费形式见表A.3。

表A.3收费形式

代码编号类型名称说明

1免费开放

2有限开放

3封闭式

A.4门票票号编码规则

门票票号由系统生成，编码规则见表A.4。

表A.4门票票号编码规则

数据项类型位数说明

单位统一编码字符11单位代码+景点代码，下同

售票时间（年月日）字符6格式为YYMMDD

每日出票流水号字符8保证不重复，位数不足高位补零

A.5门票预约、预订编码规范

分销渠道商编码采用注册制，由渠道商在初次申报信息时生成。若对已申报渠道商信息进行变更，

需要由渠道商向省文化和旅游厅申报核准后再执行。编码规则见表A.5。

表A.5门票分销商渠道商编码

数据项类型位数说明

分销渠道商字符6例如，携程为100001

14

DB32/T4753—2024

A.6门票票面类型规范

门票票面类型规范见表A.6。

表A.6门票票面类型规范

数据项类型位数说明

门票票号字符26遵循门票票号编码规则

有效使用期限字符4单位天。预约、预订出票后多久有效。（示例：0010）

允许单次入园人数字符4同一张电子门票允许单次入园的游客数量（示例：0006）

门票类型字符201：全价票；02：半价票；03：免费票；04：年卡；05：其他类型（示例：01）

出入园类型字符201：单次入园；02：当日不限次数；03：多日不限次数；04：其他类型（示例：01）

A.7门票预约数据规范

根据电子门票出票日期统计，未付款的订单门票为预约门票，其数据规范见表A.7。

表A.7门票预约数据规范

数据项类型位数说明

单位统一编码字符11

分销渠道商字符6（示例：100001）

出票时间字符122019年10月1日10时0分1秒（示例：20191001100001）

门票类型字符201：全价票；02：半价票；03：免费票；04：年卡；05：其他类型（示例：01）

计划出行日期字符82019年10月2日（示例：20191002）

订单游客人数字符410人（示例：0010）

购票者姓名字符5（示例：张三）

01：身份证；02：护照；03：军官证；04：港澳通行证；05：湾居民往返大陆通行证；06：其他

购票者证件类型字符2

（示例：01）

购票者证件号字符18

购票者手机号字符11中国大陆手机号

A.8门票预订数据规范

根据电子门票出票日期统计，已付款的订单门票为预订门票，其数据规范见表A.8。

表A.8门票预订数据规范

数据项类型位数说明

单位统一编码字符11

分销渠道商字符6（示例：100001）

出票时间字符122019年10月1日10时0分1秒（示例：20191001100001）

15

DB32/T4753—2024

表A.8门票预订数据规范（续）

数据项类型位数说明

门票类型字符201：全价票；02：半价票；03：免费票；04：年卡；05：其他类型（示例：01）

计划出行日期字符82019年10月2日（示例：20191002）

订单游客人数字符410人（示例：0010

购票者姓名字符5（示例：张三）

购票者证件类型字符201：身份证；02：护照；03：军官证；04：港澳通行证；05：台湾居民往返大陆通行证；06：其他

购票者证件号字符18

购票者手机号字符11中国大陆手机号

A.9现场售票数据规范

现场售票数据是指直接现场售票出票，或者通过网络预约渠道进行下单后在现场完成支付后出票行

为中产生的现场售票数据，其数据规范见表A.9。

表A.9现场售票数据规范

数据项类型位数说明

单位统一编码字符11

销售终端号字符4单位定义

出票时间字符122019年10月1日10时0分1秒（示例：20191001100001）

入园日期字符82019年10月2日

门票类型字符201：全价票；02：半价票；03：免费票；04：年卡；05：其他类型（示例：01）

订单游客人数字符410人（示例：0010）

购票者姓名字符5（示例：张三）

购票者证件类型字符1801：身份证；02：护照；03：军官证；04：港澳通行证；05：台湾居民往返大陆通行证；06：其他

购票者证件号字符18

购票者手机号字符11中国大陆手机号

A.10入园凭证规范

入园凭证规范见表A.10。

表A.10入园凭证规范

数据项类型位数说明

门票票号字符26遵循门票票号编码规则

分销渠道商字符6（示例：100001）

入园凭证编码字符8预制随机字符，用于标示入园凭证（示例：0dfeva39）

16

DB32/T4753—2024

表A.10入园凭证规范（续）

数据项类型位数说明

入园身份证号码字符18无身份证信息时用0补位

有效使用期限字符4单位天。预约、预订出票后多久有效。（示例：0010）

允许单次入园人数字符4同一张电子门票允许单次入园的游客数量（示例：0006）

门票类型字符201：全价票；02：半价票；03：免费票；04：年卡；05：其他类型（示例：01）

出入园类型字符201：单次入园；02：当日不限次数；03：多日不限次数；04：其他类型（示例：01）

A.11出入园闸机编码规范

入园闸机编码规范见表A.11。

表A.11入园闸机编码规范

数据项类型位数说明

单位统一编码字符11

入园时间字符122019年10月1日10时0分1秒（示例：20191001100001）

入园人数字符42人次入园（示例：0002）

单位出园数据实时记录规范见表A.12。

表A.12单位出园数据实时记录规范

数据项类型位数说明

单位统一编码字符12

出园时间字符122019年10月1日16时0分1秒（示例：20191001160001）

出园人数字符41人次出园（示例：0001）

A.12出入园验票与计数

游客（访客、读者）持含有入园（馆）凭证信息的门票（FRID介质、纸质门票、二维码、人脸识别）通过

闸机或其他验票设备出入园（馆），按单次出入园（馆）人数进行计数，无出园闸机的，应通过相关辅助识别

的方式实现人流量的统计。

a）单文化场馆或旅游景区出入园（馆）；

b）出入园（馆）包括单次出入园（馆）及多次出入园（馆）的情况，系统应能分别记录出入园（馆）的次

数和出入园（馆）的人数；

c）单文化场馆或旅游景区内多景点开放式出入园（馆）；

d）系统应能记录并上报文化场馆或旅游景区人数和景点人数；

e）单文化场馆或旅游景区多景点园中园式出入园（馆）；

f）系统应能记录文化场馆或旅游景区人数和景点人数；针对文化场馆或旅游景区多景点园中园式

入园（馆）游客（访客、读者）有二次出入单位的情况，系统应能分别记录出入园（馆）的次数和出

17

DB32/T4753—2024

入园（馆）的人数；

g）多文化场馆或旅游景区联合售票出入园（馆）；

h）针对多文化场馆或旅游景区联合售票出入园（馆）的情况，系统应能记录并上报文化场馆或旅游

景区人数和景点人数；针对多文化场馆或旅游景区联合售票出入园（馆）游客（访客、读者）有二

次出入的情况，单文化场馆或旅游景区系统应能分别记录出入园（馆）的次数和出入园（馆）的

人数。

A.13实时流量计算规则

文化场馆或旅游景区实时流量计算规则为系统中记录的实时入园人数总和减去实时出园人数总和。

A.14统计流量计算规则

文化场馆或旅游景区统计流量计算口径为单位接待人次，即系统中记录的入园游客总人次（1人2次

入园按2人次计）。

18

DB32/T4753—2024

附录B

（规范性）

文化场馆和旅游景区电子票务系统数据接口规范

B.1数据总线

B.1.1数据总线对接电子票务系统业务流程

B.1.1.1互联网预约订单同步推送到现场电子票务系统流程

互联网预约订单通过网络预约平台推送至数据总线，数据总线查找到对应的门票服务接口，将订单

信息数据路由推送到现场电子票务系统中，从而实现游客通过网络渠道购票，实现闸机检票入园。

B.1.1.2互联网预约平台信息上报至数据上报服务平台流程

工作人员通过登录互联网预约平台，设置不同时段入园游客人数，设置完成以后，网络预约平台把数

据实时通知到旅游企业服务总线系统，系统通过电商服务模块把入园游客人数等原始数据实时推送到数

据中心的数据仓库中。

经过数据仓库汇总统计后的电商预约信息，通过旅游企业总线系统的对外数据开放接口推送上报到

数据上报服务平台，或者数据上报服务平台通过旅游企业服务总线系统对外数据开放接口，主动查询预

约相关信息。

B.1.1.3门票管理系统信息上报至数据上报服务平台流程

门票管理系统提供的标准的对外数据接口，旅游企业总线系统通过管理平台配置的数据对接策略，

把门票管理系统的原始数据通过旅游企业总线票务接口推送到数据中心仓库中。

经过数据仓库汇总统计后的票务系统数据通过旅游企业总线系统的对外数据开放接口推送上报至

数据上报服务平台，或者数据上报服务平台通过旅游企业总线系统对外数据开放接口，主动查询门票系

统相关信息。

B.1.2旅游企业服务总线系统对接门票管理系统标准数据接口

B.1.2.1对接门票管理系统订单数据标准接口

对接门票管理系统订单数据标准接口包含：对接在线监测接口、订单（非实名制）下单推送接口、订单

（实名制）下单推送接口、订单（分时预约）下单推送接口、订单预下单推送接口、订单信息修改接口、订单

退单接口、订单退单回滚接口、订单详情查询接口、获取订单凭证接口、订单凭证重发接口、订单下单通知

接口、订单线上检票接口、订单核销通知接口

B.1.2.2对接电商服务平台标准数据接口

对接电商服务平台标准数据接口包含：单位基本信息接口、票型信息接口、订单基本信息查口、订单

明细信息查口、订单实名制信息接口、订单检票信息接口、订单退票基本信息接口、订单退票明细信息

接口。

19

DB32/T4753—2024

B.1.2.3对接分时预约平台标准数据接口

分时预约库存信息推送接口。

B.1.2.4对接门票管理系统基础数据标准接口

对接门票管理系统基础数据标准接口包含：客户（旅行社）基本信息接口、单位基本信息接口、票型信

息接口、线上交易明细接口、线下交易明细接口、线下支付方式交易流水接口、线上实名制信息接口、线下

实名制信息接口、线上检票明细接口、线下检票明细接口、线上退单明细接口、线下退单明细接口、线上退

单流水接口、离园信息接口、IC卡交易信息（开卡，补卡）接口、IC卡入园刷卡信息接口、订单详情快照信

息接口、订单核销接口

B.1.2.5对接数据上报服务平台标准数据接口

对接数据上报服务平台标准数据接口包含：客户（旅行社）基本信息接口、单位基本信息接口、票型信

息接口、线上交易明细接口、线下交易明细接口、线下支付方式交易流水接口、线上实名制信息接口、线下

实名制信息接口、线上检票明细接口、线下检票明细接口、线上退单明细接口、线下退单明细接口、线上退

单流水接口、离园信息接口、IC卡交易信息接口、IC卡入园刷卡信息接口。

B.1.3旅游企业服务总线系统接口说明

B.1.3.1接口通信方式

旅游企业服务总线系统与门票管理系统或者数据上报服务平台通过HTTPS的POST方式请求，

JSON格式报文进行数据交互。

B.1.3.2消息报文格式

请求和响应消息报文具有统一的格式，采用JSON格式进行通讯。

B.1.3.3参数兼容性

请求是否成功，与请求参数的顺序无关。

请求是否成功，与请求JSON中的键值对出现的顺序无关。

处理应答时，不应假设应答JSON中的键值对出现的顺序。

新的API版本可能在请求或应答中加入新的参数或者JSON的键值对。

新的API版本不会去除请求和应答中已经存在的必填参数或者JSON的键值对。

当请求或应答中的JSON键值对的值为空（null）时，可以省略。

B.1.3.4请求头参数说明

所有请求应添加请求头。

请求头参数构成见表B.1。

表B.1请求头参数构成

数据项类型位数说明

appId字符32应用ID，由平台分配（示例：S20229191）

requestId字符32请求编号，唯一标识本次请求（示例值：T202206141614236660001）

20

DB32/T4753—2024

表B.1请求头参数构成（续）

数据项类型位数说明

timestamp数字16时间戳（毫秒）（示例：1655261377448）

nonceStr字符32随机字符（示例值：593BEC0C930BF1AFEB40B4A08C8FB242）

version字符16协议版本（示例：V1）

sign字符32签名（示例值：863AHF0C930BF1AHKU40B4A25C6FK298）

B.1.3.5响应参数说明

响应参数为json格式见表B.2。

表B.2响应参数说明

数据项类型位数说明

code数字10状态码0表示成功，1表示失败（示例：0）

msg字符128状态描述（示例：成功）

data字符10000响应数据，B.2及B.3中各接口响应参数皆做为data子节点

B.1.3.6消息签名sign规则

假设请求头如下：

appId：S20229191

requestId：T202206141614236660001

timestamp：1655261377448

nonceStr：593BEC0C930BF1AFEB40B4A08C8FB242

version：V1

假设请求体json如下（如无请求体，取值{}）：

{"userName"："张小明"，"age"：30}

第一步：对所有参数按照key=value的格式，并按照参数名ASCII字典序排序，请求体key名为

body，示例如下：

appId=S20229191&body={"userName"："张小明，"age"：30}

&nonceStr=593BEC0C930BF1AFEB40B4A08C8FB242&requestId=T202206141614236660001&

timestamp=1655261377448&version=V1

第二步：拼接appSecret密钥（不含{}），示例如下：

{上一步排序后的字符串}&key=xxxxxxxxxxx

第三步：MD5加密（不含{}），大写，示例如下：

MD5（{拼接后的完整字符串}）.toUpperCase（）

21

DB32/T4753—2024

B.2互联网分销支撑接口技术规范

B.2.1获取商品库存和价格接口

B.2.1.1请求参数

获取商品库存和价格请求参数见表B.3。

表B.3获取商品库存和价格请求参数

数据项类型位数说明

goodsCode字符40商品编号

startDay字符20商品库存开始日期

endDay字符20商品库存结束日期

B.2.1.2响应参数

获取商品库存和价格响应参数见表B.4。

表B.4获取商品库存和价格响应参数

数据项类型位数说明

goodsCode字符40商品编号

商品库存信息，可含多条库存信息；

goodsInfos字符500

库存信息如下：sto