公共交通硬件钱包支付方法、装置、设备以及存储介质与流程

1.本技术涉及数字支付技术领域，尤其涉及一种公共交通硬件钱包支付方法、装置、设备以及存储介质。


背景技术：

2.目前，数字人民币硬件钱包交通卡的一种支付模式为“先乘后付”，也即，用户先刷卡乘坐公共交通工具，在用户完成乘车后，相应的乘车交易订单由公共交通终端传输到后台系统，后台系统与运营银行系统对接进行乘车费用扣款。此时，若用户的硬件钱包交通卡中的余额足够支付乘车费用，则乘车费用扣款成功；反之，则乘车费用扣款失败。
3.但是，公共交通工具的运营企业一般不会承担因扣费失败所产生的资金费用，而是由通卡公司、运营银行或其他机构兜底支付，导致兜底企业的经济损失提升。
4.是以，有必要提出一种先乘后付的支付模式中，减少扣款失败的用户乘车费用的支付方案。


技术实现要素：

5.本技术的主要目的在于提供一种公共交通硬件钱包支付方法、装置、设备以及存储介质，旨在解决先乘后付的支付模式中的用户乘车费用扣款失败率高的技术问题。
6.为实现上述目的，本技术提供一种公共交通硬件钱包支付方法，所述公共交通硬件钱包支付方法包括：在检测到交通预付费卡执行进站操作时，查询所述交通预付费卡中的预存资金是否满足预设乘车条件，其中，所述交通预付费卡预先关联有智能合约；若所述预存资金满足所述乘车条件，则允许所述进站操作通过；在检测到所述交通预付费卡执行出站操作后，基于所述智能合约，从所述预存资金中划扣对应的乘车资金。
7.可选地，所述交通预付费卡包括硬件钱包，所述在检测到交通预付费卡执行进站操作时，查询所述交通预付费卡中的预存资金是否满足预设乘车条件的步骤之前，还包括：响应于实名应用程序上的绑定操作指令，绑定所述硬件钱包与所述实名应用程序的软件钱包，所述实名应用程序预先绑定有第三方运营系统，所述第三方运营系统包括所述智能合约；响应于所述实名应用程序上的资金存入指令，通过所述软件钱包，向所述硬件钱包存入所述预存资金。
8.可选地，所述查询所述交通预付费卡中的预存资金是否满足预设乘车条件的步骤包括：根据所述交通预付费卡的卡片信息以及预先获取的公共交通票价，生成余额查询请求；发送所述余额查询请求给所述第三方运营系统，以供所述第三方运营系统根据所
述余额查询请求，确定所述交通预付费卡中的预存资金是否满足所述乘车条件。
9.可选地，所述根据所述余额查询请求，确定所述交通预付费卡中的预存资金是否满足所述乘车条件的步骤包括：根据所述余额查询请求，判断所述预存资金是否满足所述公共交通票价；若所述预存资金满足所述公共交通票价，则确定所述预存资金满足所述乘车条件；若所述预存资金不满足所述公共交通票价，则根据所述公共交通票价，从所述软件钱包中充值对应的资金到所述硬件钱包，并判断是否充值成功；若充值成功，则确定所述预存资金满足所述乘车条件；若充值失败，则确定所述预存资金不满足所述乘车条件。
10.可选地，所述基于所述智能合约，从所述预存资金中划扣对应的乘车资金的步骤包括：接收所述交通预付费卡发送的乘车交易记录；根据所述乘车交易记录，生成乘车扣款请求并发送给所述第三方运营系统，以供所述第三方运营系统根据所述智能合约以及所述乘车扣款请求，从所述预存资金中划扣所述乘车资金到对应的企业对公钱包。
11.可选地，所述公共交通硬件钱包支付方法还包括以下步骤：在接收到余额退还申请时，根据所述智能合约，退回所述预存资金至所述软件钱包。
12.可选地，所述查询所述交通预付费卡中的预存资金是否满足预设乘车条件的步骤之后，还包括：若所述预存资金不满足所述乘车条件，则不允许所述进站操作通过，并执行余额不足的提示操作。
13.本技术实施例还提出一种公共交通硬件钱包支付装置，所述公共交通硬件钱包支付装置包括：获取模块，用于在检测到交通预付费卡执行进站操作时，查询所述交通预付费卡中的预存资金是否满足预设乘车条件，其中，所述交通预付费卡预先关联有智能合约；检测模块，用于若所述预存资金满足所述乘车条件，则允许所述进站操作通过；支付模块，用于在检测到所述交通预付费卡执行出站操作后，基于所述智能合约，从所述预存资金中划扣对应的乘车资金。
14.本技术实施例还提出一种终端设备，所述终端设备包括存储器、处理器及存储在所述存储器上并可在所述处理器上运行的公共交通硬件钱包支付程序，所述公共交通硬件钱包支付程序被所述处理器执行时实现如上所述的公共交通硬件钱包支付方法的步骤。
15.本技术实施例还提出一种计算机可读存储介质，所述计算机可读存储介质上存储有公共交通硬件钱包支付程序，所述公共交通硬件钱包支付程序被处理器执行时实现如上所述的公共交通硬件钱包支付方法的步骤。
16.本技术实施例提出的公共交通硬件钱包支付方法、装置、设备以及存储介质，通过在检测到交通预付费卡执行进站操作时，查询所述交通预付费卡中的预存资金是否满足预设乘车条件，其中，所述交通预付费卡预先关联有智能合约；若所述预存资金满足所述乘车
条件，则允许所述进站操作通过；在检测到所述交通预付费卡执行出站操作后，基于所述智能合约，从所述预存资金中划扣对应的乘车资金。通过在检测到用户使用交通预付费卡完成乘车后，基于交通预付费卡所预先关联的智能合约，划扣交通预付费卡中的预存资金来支付相应的乘车费用，可以改善先乘后付的支付模式中的用户乘车费用扣款失败的技术问题，进而降低兜底企业的经济损失。
附图说明
17.图1为本技术公共交通硬件钱包支付装置所属终端设备的功能模块示意图；图2为本技术公共交通硬件钱包支付方法第一示例性实施例的流程示意图；图3为本技术公共交通硬件钱包支付方法第二示例性实施例的流程示意图；图4为本技术公共交通硬件钱包支付方法第三示例性实施例的流程示意图；图5为本技术公共交通硬件钱包支付方法第四示例性实施例的流程示意图；图6为本技术公共交通硬件钱包支付方法第五示例性实施例的流程示意图。
18.本技术目的的实现、功能特点及优点将结合实施例，参照附图做进一步说明。
具体实施方式
19.应当理解，此处所描述的具体实施例仅仅用以解释本技术，并不用于限定本技术。
20.本技术实施例的主要解决方案是：在检测到交通预付费卡执行进站操作时，查询所述交通预付费卡中的预存资金是否满足预设乘车条件，其中，所述交通预付费卡预先关联有智能合约；若所述预存资金满足所述乘车条件，则允许所述进站操作通过；在检测到所述交通预付费卡执行出站操作后，基于所述智能合约，从所述预存资金中划扣对应的乘车资金。通过在检测到用户使用交通预付费卡完成乘车后，基于交通预付费卡所预先关联的智能合约，划扣交通预付费卡中的预存资金来支付相应的乘车费用，可以改善先乘后付的支付模式中的用户乘车费用扣款失败的技术问题，进而降低兜底企业的经济损失。
21.本技术实施例考虑到，针对先乘后付的支付模式中的用户乘车费用扣款这一问题，数字人民币硬件钱包交通卡有一种支付模式为“先乘后付”，即用户先刷卡乘坐公交、地铁，乘车交易订单将延迟由公交、地铁设备端传输到后台系统，由后台系统与运营银行系统对接进行乘车费用扣款。
22.但是，当用户的数字人民币硬件钱包中余额不够时，乘车费用扣费将失败，因公交、地铁运营企业一般不承担扣费失败的损失，用户欠费通常由通卡公司或运营银行或其他机构兜底，进而造成兜底企业资金损失问题。
23.因此，本技术实施例方案，从数字人民币硬件钱包先乘后付的支付模式中的用户乘车费用扣款的实际问题出发，提出一种基于智能合约的数字人民币交通预付费卡产品方案，结合基于智能合约的数字人民币交通预付费卡所内置的交通应用和数字人民币硬件钱包应用，其中，交通应用与公交车载终端、地铁闸机交互，负责识卡通行、行程计费、交易生成等功能，数字人民币硬件钱包应用负责交通费用支付功能，可以有效改善先乘后付的支付模式中的用户乘车费用扣款失败的技术问题，进而降低兜底企业的经济损失。
24.具体地，参照图1，图1为本技术公共交通硬件钱包支付装置所属终端设备的功能模块示意图。该公共交通硬件钱包支付装置可以为独立于终端设备的、能够进行公共交通
硬件钱包支付的装置，其可以通过硬件或软件的形式承载于终端设备上。该终端设备可以为手机、平板电脑等具有数据处理功能的智能移动终端，还可以为具有数据处理功能的固定终端设备或服务器等。
25.在本实施例中，该公共交通硬件钱包支付装置所属终端设备至少包括输出模块110、处理器120、存储器130以及通信模块140。
26.存储器130中存储有操作系统以及公共交通硬件钱包支付程序，公共交通硬件钱包支付装置可以将在检测到交通预付费卡执行进站操作时，查询的交通预付费卡中的预存资金是否满足预设乘车条件，其中，交通预付费卡预先关联有智能合约；在检测到交通预付费卡执行出站操作后，基于智能合约，从预存资金中划扣对应的乘车资金等信息存储于该存储器130中；输出模块110可为显示屏等。通信模块140可以包括wifi模块、移动通信模块以及蓝牙模块等，通过通信模块140与外部设备或服务器进行通信。
27.其中，存储器130中的公共交通硬件钱包支付程序被处理器执行时实现以下步骤：在检测到交通预付费卡执行进站操作时，查询所述交通预付费卡中的预存资金是否满足预设乘车条件，其中，所述交通预付费卡预先关联有智能合约；若所述预存资金满足所述乘车条件，则允许所述进站操作通过；在检测到所述交通预付费卡执行出站操作后，基于所述智能合约，从所述预存资金中划扣对应的乘车资金。
28.进一步地，存储器130中的公共交通硬件钱包支付程序被处理器执行时还实现以下步骤：响应于实名应用程序上的绑定操作指令，绑定所述硬件钱包与实名应用程序的软件钱包，所述实名应用程序预先绑定有第三方运营系统，所述第三方运营系统包括所述智能合约；通过所述第三方运营系统将所述交通预付费卡关联所述智能合约；响应于所述实名应用程序上的资金存取指令，通过所述软件钱包，向所述硬件钱包存入所述预存资金。
29.进一步地，存储器130中的公共交通硬件钱包支付程序被处理器执行时还实现以下步骤：根据所述交通预付费卡的卡片信息以及预先获取的公共交通票价，生成余额查询请求；发送所述余额查询请求给所述第三方运营系统，以供所述第三方运营系统根据所述余额查询请求，确定所述交通预付费卡中的预存资金是否满足所述乘车条件。
30.进一步地，存储器130中的公共交通硬件钱包支付程序被处理器执行时还实现以下步骤：根据所述余额查询请求，判断所述预存资金是否满足所述公共交通票价；若所述预存资金满足所述公共交通票价，则确定所述预存资金满足所述乘车条件；若所述预存资金不满足所述公共交通票价，则根据所述公共交通票价，从所述软件钱包中充值对应的资金到所述硬件钱包，并判断是否充值成功；若充值成功，则确定所述预存资金满足所述乘车条件；若充值失败，则确定所述预存资金不满足所述乘车条件。
31.进一步地，存储器130中的公共交通硬件钱包支付程序被处理器执行时还实现以下步骤：接收所述交通预付费卡发送的乘车交易记录；根据所述乘车交易记录，生成乘车扣款请求并发送给所述第三方运营系统，以供所述第三方运营系统根据所述智能合约以及所述乘车扣款请求，从所述预存资金中划扣所述乘车资金到对应的企业对公钱包。
32.进一步地，存储器130中的公共交通硬件钱包支付程序被处理器执行时还实现以下步骤：在接收到余额退还申请时，根据所述智能合约，退回所述预存资金至所述软件钱包。
33.进一步地，存储器130中的公共交通硬件钱包支付程序被处理器执行时还实现以下步骤：若所述预存资金不满足所述乘车条件，则不允许所述进站操作通过，并执行余额不足的提示操作。
34.本实施例通过上述方案，具体通过在检测到交通预付费卡执行进站操作时，查询所述交通预付费卡中的预存资金是否满足预设乘车条件，其中，所述交通预付费卡预先关联有智能合约；若所述预存资金满足所述乘车条件，则允许所述进站操作通过；在检测到所述交通预付费卡执行出站操作后，基于所述智能合约，从所述预存资金中划扣对应的乘车资金。通过在检测到用户使用交通预付费卡完成乘车后，基于交通预付费卡所预先关联的智能合约，划扣交通预付费卡中的预存资金来支付相应的乘车费用，可以改善先乘后付的支付模式中的用户乘车费用扣款失败的技术问题，进而降低兜底企业的经济损失。
35.基于上述终端设备架构但不限于上述架构，提出本技术方法实施例。
36.参照图2，图2为本技术公共交通硬件钱包支付方法第一示例性实施例的流程示意图。所述公共交通硬件钱包支付方法包括：步骤s210，在检测到交通预付费卡执行进站操作时，查询所述交通预付费卡中的预存资金是否满足预设乘车条件，其中，所述交通预付费卡预先关联有智能合约；本实施例方法的执行主体可以是一种公共交通硬件钱包支付装置，也可以是一种公共交通硬件钱包支付终端设备或服务器，本实施例以公共交通硬件钱包支付装置进行举例，该公共交通硬件钱包支付装置可以集成在具有数据处理功能的交通预付费卡上，其中，交通预付费卡的形态不受限制，可以为ic卡、sim卡、穿戴设备、手机等终端设备。
37.本技术实施例考虑到，数字人民币硬件钱包交通卡有一种支付模式为“先乘后付”，即用户先刷卡乘坐公交、地铁，而相应的乘车交易订单会延迟由公交、地铁设备端传输到后台系统，由后台系统与运营银行系统对接进行乘车费用扣款。当用户的数字人民币硬件钱包中余额足够时，乘车费用扣费成功；但是，当用户的数字人民币硬件钱包中余额不够时，乘车费用扣费将失败，因公交、地铁运营企业一般不承担扣费失败的损失，用户欠费通常由通卡公司或运营银行或其他机构兜底，造成兜底企业资金损失问题。
38.因此，本技术实施例方案，从先乘后付的支付模式中的用户乘车费用扣款的实际问题出发，提出一种基于智能合约的数字人民币交通预付费卡产品方案，结合基于智能合约的数字人民币交通预付费卡所内置的交通应用和数字人民币硬件钱包应用，可以有效改
善先乘后付的支付模式中的用户乘车费用扣款失败的技术问题，进而降低兜底企业的经济损失。
39.具体地，交通预付费卡可以是基于智能合约的数字人民币交通预付费卡，也即，交通预付费卡可以是以数字人民币硬件钱包的形式存在，交通预付卡可以包括交通应用和数字人民币硬件钱包应用，交通应用可以与公共交通终端（公交车载终端、地铁闸机）交互，用于识卡通行、行程计费、交易生成等功能，数字人民币硬件钱包应用可以用于交通费用支付功能，使得交通预付费卡可以用于乘坐公共交通工具，并存储和支付公共交通费用。
40.通过预先将交通预付费卡与智能合约进行关联，使得用户需要在预付费片中的硬件钱包预先充值满足乘车条件的数字人民币的资金，得到预存资金，进而可以使用预付费卡的硬件钱包功能进行支付。其中，基于智能合约，预存资金由相应的运营银行进行监管，且预付费卡中的预存资金用于特定的“先乘后付”公共交通模式中进行乘车支付。
41.步骤s220，若所述预存资金满足所述乘车条件，则允许所述进站操作通过；具体地，乘车条件可以是公共交通的最高票价，其中，公共交通最高票价是指在一个特定的公共交通系统中，为一次乘车所需支付的最高费用。无论用户在公共交通系统中的乘车距离有多远，所支付的费用都不会超过最高票价。
42.如果用户的预存资金满足公共交通最高票价，则表示预存资金满足乘车条件，那么系统会授权用户进站并乘坐公共交通工具。
43.步骤s230，在检测到所述交通预付费卡执行出站操作后，基于所述智能合约，从所述预存资金中划扣对应的乘车资金。
44.具体地，每当用户使用数字人民币交通预付费卡乘坐公共交通工具时，交通预付费卡或公共交通系统可以产生相应的乘车交易记录，后台系统接收到乘车交易记录，向运营银行发送乘车扣款请求，使得运营银行可以基于智能合约，根据乘车交易记录会从用户的预存资金中扣除相应的乘车资金，并将笔乘车资金划扣给通卡企业。
45.示例性地，在用户准备进入公共交通系统（如地铁站或公交车站）时，可以使用交通预付费卡进行刷卡乘车；在用户进站闸机刷卡时，闸机会读取交通预付费卡内的硬钱包相关信息，并向后台系统发送余额查询请求（例如，查询余额是否大于20元）。后台系统将余额查询请求传递给运营银行，运营银行查询交通预付费卡内的预存资金并将结果返回给闸机端；如果查询结果显示交通预付费卡余额符合最低资金要求，闸机会开闸放行，允许用户进站。如果余额不足，闸机将提示余额不足，不允许用户通行。在用户完成乘车行程后，再次刷卡出闸，闸机放行。然后，地铁闸机和/或交通预付费卡会生成一条乘车交易记录，并将该记录上传至后台交易处理系统。后台交易处理系统根据接收到的交易记录向运营银行系统发起扣款请求。根据智能合约，运营银行会从预存资金中划扣交易资金至通卡企业的对公钱包，并向用户发送扣费成功通知。
46.本实施例通过上述方案，具体通过在检测到交通预付费卡执行进站操作时，查询所述交通预付费卡中的预存资金是否满足预设乘车条件，其中，所述交通预付费卡预先关联有智能合约；若所述预存资金满足所述乘车条件，则允许所述进站操作通过；在检测到所述交通预付费卡执行出站操作后，基于所述智能合约，从所述预存资金中划扣对应的乘车资金。通过在检测到用户使用交通预付费卡完成乘车后，基于交通预付费卡所预先关联的智能合约，划扣交通预付费卡中的预存资金来支付相应的乘车费用，可以改善先乘后付的
支付模式中的用户乘车费用扣款失败的技术问题，进而降低兜底企业的经济损失。
47.参照图3，图3为本技术公共交通硬件钱包支付方法第二示例性实施例的流程示意图。基于上述图2所示的实施例，步骤s210，在检测到交通预付费卡执行进站操作时，查询所述交通预付费卡中的预存资金是否满足预设乘车条件之前，还包括：步骤s310，响应于实名应用程序上的绑定操作指令，绑定所述硬件钱包与实名应用程序的软件钱包，所述实名应用程序预先绑定有第三方运营系统，所述第三方运营系统包括所述智能合约；通过所述第三方运营系统将所述交通预付费卡关联所述智能合约；本技术实施例考虑到，目前普通的交通卡大多数是不记名交通卡，当使用不记名交通卡时，用户需要预先将满足乘车条件的资金充值到不记名交通卡上，以便在乘坐交通工具时进行支付。但是，不记名交通卡没有与个人身份相关联的信息，通常只包含用于支付的卡号，而不与特定的个人身份相关联。在不记名交通卡不幸丢失、损坏或不再使用，卡内的余额通常无法退还给用户。
48.因此，本技术实施例，具体通过用户在注册数字人民币应用程序时进行实名认证，并将硬件钱包与数字人民币应用程序中的软件钱包进行绑定，使得硬件钱包中的资金将与用户的真实身份相关联，进而使得运营银行可以基于智能合约对预先关联的硬件钱包中的预存资金进行监管。此外，用户还可以在数字人民币应用程序中管理和控制硬件钱包的预存资金。
49.具体地，第三方运营系统可以是运营银行，可以是负责管理软件钱包中预存资金的机构，用于处理卡片余额、交易扣款等操作。当用户完成乘车并通过硬件钱包发起乘车支付时，公共交通终端或硬件钱包可以生成相应的乘车交易记录，并将乘车交易记录发送给第三方运营系统，使得第三方运营系统可以基于智能合约，并负责将预存资金从硬件钱包中划拨到通卡企业的对公钱包。
50.步骤s320，响应于所述实名应用程序上的资金存取指令，通过所述软件钱包，向所述硬件钱包存入所述预存资金。
51.具体地，将硬件钱包（交通预付费卡内的硬件设备）与软件钱包（应用程序内的虚拟钱包）进行关联，使得用户可以通过软件钱包向硬件钱包存入预存资金，也就是将数字资产存入交通预付费卡中。
52.示例性地，用户在数字人民币应用程序中注册账户并创建软件钱包；用户将硬件钱包与自己的数字人民币应用程序账户进行关联；在绑定成功后，用户可以通过数字人民币应用程序管理硬件钱包中的数字资产，进行充值、支付、查询余额等操作。
53.本实施例通过上述方案，具体通过将交通预付费卡中的硬件钱包与数字人民币应用程序的软件钱包绑定，使得用户可以在充值后将数字人民币存入卡片中的硬件钱包，并在特定的公共交通场景中，基于智能合约来使用预存资金进行乘车支付，可以提供便利、安全的支付方式，并受到智能合约的严格控制。
54.参照图4，图4为本技术公共交通硬件钱包支付方法第三示例性实施例的流程示意图。基于上述图2、3所示的实施例，步骤s210，在检测到交通预付费卡执行进站操作时，查询所述交通预付费卡中的预存资金是否满足预设乘车条件，包括：步骤s410，根据所述交通预付费卡的卡片信息以及预先获取的公共交通票价，生成余额查询请求；
具体地，卡片信息可以包括卡号、持卡人信息以及其他安全性验证数据。此外，为了查询交通预付费卡中的预存资金是否足够支付乘车费用，可以通过后台系统预先获取公共交通的最高票价信息。余额查询请求用于查询交通预付费卡中的预存资金是否满足公共交通票价。
55.其中，公共交通票价可以是指在一个特定的公共交通系统中，为一次乘车所需支付的最高费用。无论用户在公共交通系统中的乘车距离有多远，所支付的费用都不会超过最高票价。
56.步骤s420，发送所述余额查询请求给所述第三方运营系统，以供所述第三方运营系统根据所述余额查询请求，确定所述交通预付费卡中的预存资金是否满足所述乘车条件。
57.具体地，由于预存资金由第三方运营系统所监管，因此，通过后台系统发送余额查询请求给第三方运营系统，以供第三方运营系统可以根据余额查询请求查询预存资金是否满足公共交通票价，并生成相应的查询结果。
58.进一步地，步骤s420，根据所述余额查询请求，确定所述交通预付费卡中的预存资金是否满足所述乘车条件，包括：步骤s421，根据所述余额查询请求，判断所述预存资金是否满足所述公共交通票价；具体地，在第三方运营系统收到余额查询请求后，可以根据预存资金与公共交通票价进行对比，如果预存资金大于公共交通票价，也即，如果预存资金足够支付公共交通票价，那么后台系统会判定预存资金满足乘车条件。
59.步骤s422，若所述预存资金满足所述公共交通票价，则确定所述预存资金满足所述乘车条件；具体地，如果预存资金足够支付公共交通票价，第三方运营系统可以确定预存资金满足乘车条件，并将该查询结果返回给地铁闸机，以使地铁闸机向用户开闸放行，允许用户进行进站操作。
60.步骤s423，若所述预存资金不满足所述公共交通票价，则根据所述公共交通票价，从所述软件钱包中充值对应的资金到所述硬件钱包，并判断是否充值成功；具体地，如果预存资金不足以支付公共交通票价，第三方运营系统可以采取进一步措施。首先，为了确保用户能够顺利进行乘车根据公共交通票价，第三方运营系统可以从用户的软件钱包中充值对应的资金到硬件钱包。由于软件钱包中的资金向硬件钱包中充值之后也不一定足够支付公共交通票价，因此第三方运营系统会进一步地判断是否充值成功。
61.步骤s424，若充值成功，则确定所述预存资金满足所述乘车条件；具体地，如果从用户的软件钱包中充值对应的资金到硬件钱包成功，第三方运营系统会再次判定预存资金满足乘车条件，因为此时用户的硬件钱包已经被充值足够的资金以满足乘车需要。
62.步骤s425，若充值失败，则确定所述预存资金不满足所述乘车条件。
63.具体地，如果从用户的软件钱包中充值对应的资金到硬件钱包失败，第三方运营系统会确认预存资金不足以满足乘车条件，也即，表示用户不能继续乘车，用户在下一次乘
车时将无法继续使用卡片，直至充值问题得到解决。
64.进一步地，后台系统接受第三方运营系统返回的查询结果，查询结果可以是预存资金满足公共交通票价或预存资金不满足公共交通票价。若预存资金满足公共交通票价，则闸机开闸放行，若预存资金不满足公共交通票价，则闸机提示余额不足，不能通行。
65.本实施例通过上述方案，具体通过数字人民币交通预付费卡的预存资金余额低于最低限额时，第三方运营系统可自动完成预存资金的充值，保证用户可连续使用交通预付费卡乘车，即使其预存资金已经接近最低限额，也即，第三方运营系统可以根据预先设定的策略，从用户绑定的软件钱包中自动向卡片的硬件钱包进行资金充值，可以避免出现预存资金不足而无法乘车的情况，从而有效实现了便捷的使用和连续的乘车服务。
66.参照图5，图5为本技术公共交通硬件钱包支付方法第四示例性实施例的流程示意图。基于上述图2所示的实施例，步骤s230，基于所述智能合约，从所述预存资金中划扣对应的乘车资金，包括：步骤s510，接收所述交通预付费卡发送的乘车交易记录；具体地，当用户使用数字人民币交通预付费卡完成乘车之后，交通系统会接收到来自卡片的乘车交易记录。这些记录包括了用户的乘车信息，如时间、地点、乘车费用等。
67.其中，乘车交易记录可以是用户完成乘车之后即刻生成，也可以是用户完成乘车的一段之间之后生成，或在当日的某一时间点统一生成。
68.步骤s520，根据所述乘车交易记录，生成乘车扣款请求并发送给所述第三方运营系统，以供所述第三方运营系统根据所述智能合约以及所述乘车扣款请求，从所述预存资金中划扣所述乘车资金到对应的企业对公钱包。
69.具体地，在后台系统接收到乘车交易记录时，可以相应生成对应的乘车扣款请求并发送给第三方运营系统。乘车扣款请求用于后台系统向第三方运营系统发送一个信号，表明用户已经完成了乘车，并且需要进行资金扣款以支付相应的乘车费用。
70.第三方运营系统在收到乘车扣款请求后，可以会根据智能合约的相关规则进行处理。其中，智能合约是一种自动执行的程序，根据预先设定的条件和逻辑，执行扣款操作。在数字人民币交通预付费卡的后台系统中，智能合约被用来管理卡内预存资金的使用。根据智能合约的设定，预存资金只能用于特定的用途，即公共交通场景的乘车支付。
71.基于智能合约和乘车扣款请求，第三方运营系统会从该用户的预存资金中划扣相应的乘车资金。这个扣款会将用户的实际乘车费用从预付费卡的预存资金中扣除。扣款完成后，所述乘车资金会被划扣到对应的企业对公钱包中，以完成整个资金流转过程。
72.本实施例通过上述方案，具体通过预存资金由第三方运营系统监管，且每笔乘车交易会导致第三方运营系统从用户的数字人民币交通预付费卡的预存资金中扣款，并将扣款金额划扣给通卡企业，可以改善先乘后付的支付模式中的用户乘车费用扣款失败的技术问题，进而降低兜底企业的经济损失的同时，保障了资金的安全和流动。
73.参照图6，图6为本技术公共交通硬件钱包支付方法第五示例性实施例的流程示意图。基于上述图2所示的实施例，所述公共交通硬件钱包支付方法还包括以下步骤：步骤s610，在接收到余额退还申请时，根据所述智能合约，退回所述预存资金至所述软件钱包。
74.具体地，在数字人民币交通预付费卡丢失或用户不再需要使用时，用户可以向后
台系统发起预存资金的余额退还申请，以便将卡内剩余的预存资金退还给用户。在用户发起预存资金退还申请后，后台系统向第三方运营系统发送退还指令，使得第三方运营系统根据退还指令自动处理预存资金退还流程。其中，预存资金退还流程可以包括验证用户身份、核对卡内余额等步骤。
75.本实施例通过上述方案，具体通过在数字人民币交通预付费卡丢失或不再需要使用的情况下，用户可以根据自己的需要随时决定是否退还预存资金来发起资金退还申请，进而使得第三方运营系统可以根据智能合约，将卡内剩余的预存资金退还至其指定的软件钱包账户，可以有效解决普通交通卡丢失后余额不能找回的问题，提升了用户的预存资金安全性以及灵活性。
76.此外，本技术实施例还提出一种公共交通硬件钱包支付装置，所述公共交通硬件钱包支付装置包括：获取模块，用于在检测到交通预付费卡执行进站操作时，查询所述交通预付费卡中的预存资金是否满足预设乘车条件，其中，所述交通预付费卡预先关联有智能合约；检测模块，用于若所述预存资金满足所述乘车条件，则允许所述进站操作通过；支付模块，用于在检测到所述交通预付费卡执行出站操作后，基于所述智能合约，从所述预存资金中划扣对应的乘车资金。
77.本实施例实现公共交通硬件钱包支付的原理及实施过程，请参照上述各实施例，在此不再赘述。
78.此外，本技术实施例还提出一种终端设备，所述终端设备包括存储器、处理器及存储在所述存储器上并可在所述处理器上运行的公共交通硬件钱包支付程序，所述公共交通硬件钱包支付程序被所述处理器执行时实现如上所述的公共交通硬件钱包支付方法的步骤。
79.由于本公共交通硬件钱包支付程序被处理器执行时，采用了前述所有实施例的全部技术方案，因此至少具有前述所有实施例的全部技术方案所带来的所有有益效果，在此不再一一赘述。
80.此外，本技术实施例还提出一种计算机可读存储介质，所述计算机可读存储介质上存储有公共交通硬件钱包支付程序，所述公共交通硬件钱包支付程序被处理器执行时实现如上所述的公共交通硬件钱包支付方法的步骤。
81.由于本公共交通硬件钱包支付程序被处理器执行时，采用了前述所有实施例的全部技术方案，因此至少具有前述所有实施例的全部技术方案所带来的所有有益效果，在此不再一一赘述。
82.相比现有技术，本技术实施例提出的公共交通硬件钱包支付方法、装置、设备以及存储介质，通过在检测到交通预付费卡执行进站操作时，查询所述交通预付费卡中的预存资金是否满足预设乘车条件，其中，所述交通预付费卡预先关联有智能合约；若所述预存资金满足所述乘车条件，则允许所述进站操作通过；在检测到所述交通预付费卡执行出站操作后，基于所述智能合约，从所述预存资金中划扣对应的乘车资金。通过在检测到用户使用交通预付费卡完成乘车后，基于交通预付费卡所预先关联的智能合约，划扣交通预付费卡中的预存资金来支付相应的乘车费用，可以改善先乘后付的支付模式中的用户乘车费用扣款失败的技术问题，进而降低兜底企业的经济损失。
83.需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者系统不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者系统所固有的要素。在没有更多限制的情况下，由语句“包括一个
……”
限定的要素，并不排除在包括该要素的过程、方法、物品或者系统中还存在另外的相同要素。
84.上述本技术实施例序号仅仅为了描述，不代表实施例的优劣。
85.通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本技术的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在如上的一个存储介质(如rom/ram、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，ic卡，sim卡，穿戴设备，服务器，被控终端，或者网络设备等)执行本技术每个实施例的方法。
86.以上仅为本技术的优选实施例，并非因此限制本技术的专利范围，凡是利用本技术说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本技术的专利保护范围内。

技术特征：
1.一种公共交通硬件钱包支付方法，其特征在于，所述公共交通硬件钱包支付方法包括以下步骤：在检测到交通预付费卡执行进站操作时，查询所述交通预付费卡中的预存资金是否满足预设乘车条件，其中，所述交通预付费卡预先关联有智能合约；若所述预存资金满足所述乘车条件，则允许所述进站操作通过；在检测到所述交通预付费卡执行出站操作后，基于所述智能合约，从所述预存资金中划扣对应的乘车资金。2.如权利要求1所述的公共交通硬件钱包支付方法，其特征在于，所述交通预付费卡包括硬件钱包，所述在检测到交通预付费卡执行进站操作时，查询所述交通预付费卡中的预存资金是否满足预设乘车条件的步骤之前，还包括：响应于实名应用程序上的绑定操作指令，绑定所述硬件钱包与实名应用程序的软件钱包，所述实名应用程序预先绑定有第三方运营系统，所述第三方运营系统包括所述智能合约；通过所述第三方运营系统将所述交通预付费卡关联所述智能合约；响应于所述实名应用程序上的资金存取指令，通过所述软件钱包，向所述硬件钱包存入所述预存资金。3.如权利要求2所述的公共交通硬件钱包支付方法，其特征在于，所述查询所述交通预付费卡中的预存资金是否满足预设乘车条件的步骤包括：根据所述交通预付费卡的卡片信息以及预先获取的公共交通票价，生成余额查询请求；发送所述余额查询请求给所述第三方运营系统，以供所述第三方运营系统根据所述余额查询请求，确定所述交通预付费卡中的预存资金是否满足所述乘车条件。4.如权利要求3所述的公共交通硬件钱包支付方法，其特征在于，所述根据所述余额查询请求，确定所述交通预付费卡中的预存资金是否满足所述乘车条件的步骤包括：根据所述余额查询请求，判断所述预存资金是否满足所述公共交通票价；若所述预存资金满足所述公共交通票价，则确定所述预存资金满足所述乘车条件；若所述预存资金不满足所述公共交通票价，则根据所述公共交通票价，从所述软件钱包中充值对应的资金到所述硬件钱包，并判断是否充值成功；若充值成功，则确定所述预存资金满足所述乘车条件；若充值失败，则确定所述预存资金不满足所述乘车条件。5.如权利要求2所述的公共交通硬件钱包支付方法，其特征在于，所述基于所述智能合约，从所述预存资金中划扣对应的乘车资金的步骤包括：接收所述交通预付费卡发送的乘车交易记录；根据所述乘车交易记录，生成乘车扣款请求并发送给所述第三方运营系统，以供所述第三方运营系统根据所述智能合约以及所述乘车扣款请求，从所述预存资金中划扣所述乘车资金到对应的企业对公钱包。6.如权利要求2所述的公共交通硬件钱包支付方法，其特征在于，所述公共交通硬件钱包支付方法还包括以下步骤：在接收到余额退还申请时，根据所述智能合约，退回所述预存资金至所述软件钱包。7.如权利要求1所述的公共交通硬件钱包支付方法，其特征在于，所述查询所述交通预
付费卡中的预存资金是否满足预设乘车条件的步骤之后，还包括：若所述预存资金不满足所述乘车条件，则不允许所述进站操作通过，并执行余额不足的提示操作。8.一种公共交通硬件钱包支付装置，其特征在于，所述公共交通硬件钱包支付装置包括：获取模块，用于在检测到交通预付费卡执行进站操作时，查询所述交通预付费卡中的预存资金是否满足预设乘车条件，其中，所述交通预付费卡预先关联有智能合约；检测模块，用于若所述预存资金满足所述乘车条件，则允许所述进站操作通过；支付模块，用于在检测到所述交通预付费卡执行出站操作后，基于所述智能合约，从所述预存资金中划扣对应的乘车资金。9.一种终端设备，其特征在于，所述终端设备包括存储器、处理器及存储在所述存储器上并可在所述处理器上运行的公共交通硬件钱包支付程序，所述公共交通硬件钱包支付程序被所述处理器执行时实现如权利要求1-7中任一项所述的公共交通硬件钱包支付方法的步骤。10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有公共交通硬件钱包支付程序，所述公共交通硬件钱包支付程序被处理器执行时实现如权利要求1-7中任一项所述的公共交通硬件钱包支付方法的步骤。

技术总结
本申请公开了一种公共交通硬件钱包支付方法、装置、设备以及存储介质，其公共交通硬件钱包支付方法包括：在检测到交通预付费卡执行进站操作时，查询交通预付费卡中的预存资金是否满足预设乘车条件，其中，交通预付费卡预先关联有智能合约；若预存资金满足乘车条件，则允许进站操作通过；在检测到交通预付费卡执行出站操作后，基于智能合约，从预存资金中划扣对应的乘车资金。通过在检测到用户使用交通预付费卡完成乘车后，基于交通预付费卡所预先关联的智能合约，划扣交通预付费卡中的预存资金来支付相应的乘车费用，可以改善先乘后付的支付模式中的用户乘车费用扣款失败的技术问题，进而降低兜底企业的经济损失。进而降低兜底企业的经济损失。进而降低兜底企业的经济损失。


技术研发人员：梁靖 杨向民 赵凯 杨东奇 陈龙芳
受保护的技术使用者：深圳市深圳通有限公司
技术研发日：2023.09.13
技术公布日：2023/10/20